2 设计用例图的案例
- 格式:ppt
- 大小:589.50 KB
- 文档页数:54
《UML2面向对象分析与设计》综合案例:员工考勤系统作业评分实施细则一、第四章作业(用例图和用例文档)1. 评分档次用例图和用例文档分别按照满分10分计算,以此作为评分标准,基本的评分准则如下:●一档(10分):图形(文本)条理清楚,无任何明显错误●二档(8-9分):图形/文本清楚,存在个别错误●三档(6-7分):图形/文本一般,存在一定的错误●四档(5分):图形/文本条理不清,存在致命错误或错误数过多一般情况下按错别个数扣分,每个错误按严重程度扣0.5、1、2分,最终成绩向上取整;同类错误不重复扣分。
2. 参考答案作业答案部分仅供参考,学生的作业可能会多种多样,具体按照第三部分的典型错误扣分,用例图:用例文档:员工(含小时工和普通员工)相关用例无前置条件员工已正确登录到该系统后置条件无(将在下次迭代中确定)涉众利益员工:准确地维护自己的考勤信息公司:要求员工的信息准确基本路径1—添加新的考勤1.1、用例起始于用户需要记录新的考勤信息1.2、系统显示当前日期和时间,并提醒用户该时间即为用户的上班时间1.3、用户确认该信息1.4、系统记录当前日期和时间,并将其作为用户考勤信息的上班时间2—提交考勤信息2.1、任何时刻用户都可以提交自己的考勤信息2.2、系统查询用户上班时的考勤记录(E-1)2.3、系统记录当前的日期和时间,作为用户考勤信息的下班时间2.4、系统显示用户今天完整的考勤信息2.5、用户确认提交考勤信息2.6、系统保存考勤信息,并将考勤信息的状态改为“已提交”(D-1)备选路径E-1 如果系统没有找到用户上班时的考勤信息,则用例终止;用户可以通过项目经理为其添加上班的考勤信息数据需求A-1 考勤信息主要包括:用户名、日期、上班时间、下班时间、状态D-1 考勤信息的状态有:“新考勤”(只有上班时间,没有下班时间的考勤信息)、“已提交”(有完整的上下班时间,但还没有进行工资结算的考勤)、“已完成”(已结算工资的考勤)业务规则B-1 作为用户考勤信息的上下班时间由系统自动获取,不允许用户编辑B-2 状态为“已提交”的考勤信息不允许普通用户进行任何操作;非功能需求无设计约束无待解决问题无参与者时间、项目管理数据库(外部系统)相关用例无前置条件无后置条件无(将在下次迭代中确定)涉众利益员工:…(包括临时工、普通员工、销售人员)公司:…基本路径—计算普通员工和销售人员工资1.用例起始于系统时间到达每月末晚上,需要计算普通员工和销售人员工资(E-1);2.系统查询所有的普通员工和销售人员的个人信息(D-1);3.对于每一个员工(普通员工、销售人员):3.1.根据员工的类别获得其考勤信息或订单信息(E-2);3.1.1.如果是普通员工,则获得本月的考勤信息(D-2);3.1.2.如果是销售人员,则获得本月的销售信息(D-3);3.2.系统从项目管理数据库中获得员工的工资级别信息(E-3);3.3.系统根据员工的考勤信息(或销售信息)和工资级别信息计算该员工的工资,保存;4.计算完成后,系统产生一个提醒信息,以便于项目经理确认备选路径E-1—计算临时工工资1. 用例起始于系统时间达到每个周末的晚上,需要计算临时工工资2. 系统查询所有临时工的个人信息3. 对于每一个临时工:3.1. 获得员工的考勤信息3.2 从项目管理数据库中获得员工的工资级别信息;3.3 系统根据员工的考勤信息和工资级别信息计算该员工的工资,保存;4. 计算完成后,系统产生一个提醒信息,以便于项目经理确认E-2 如果找不到该员工的考勤信息或订单信息,则记录相关日志,并转回3计算下一个员工E-3 如果无法获得员工工资级别信息,则记录相关日志,并转回3计算下一个员工数据需求D-1. 员工信息=员工编号+员工姓名D-2 考勤信息参见“登记考勤”用例D-3 订单信息参见“登记订单”用例业务规则暂不明确非功能需求暂不明确设计约束3. 典型错误情况3.1 用例图部分3.1.1 参与者本系统中包含的参与者有:小时工、普通员工、销售人员、项目经理、项目管理数据库、时间,其中由于小时工和普通员工有关考勤的处理细节完全相同,因此为了便于简化和复用,可将他们统一合并为员工(不合并也可以,不算错误),但不能和销售人员合并,因为销售人员没有考勤信息,而是登记订单信息,需要明确区分。
UML中的用例图实践案例UML(统一建模语言)是一种用于软件开发的标准化建模语言,它提供了一套丰富的图形符号和概念,用于描述和设计软件系统的各个方面。
其中,用例图是UML中最为常用和重要的一种图形表示方法,它用于描述系统的功能需求和用户与系统之间的交互关系。
本文将通过一个实践案例,介绍用例图在软件开发中的具体应用。
假设我们要开发一个在线购物系统,该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。
首先,我们需要明确系统的角色和用例。
在这个案例中,系统的角色包括用户、管理员和支付网关。
用户可以注册账号、浏览商品、添加购物车、下单和支付;管理员可以管理商品信息;支付网关负责处理支付请求。
接下来,我们可以使用用例图来表示这些角色和用例之间的关系。
首先,我们可以在用例图中用椭圆形表示各个用例。
在本案例中,我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。
然后,我们可以用矩形表示各个角色,即用户、管理员和支付网关。
接着,我们可以使用实线箭头来表示角色与用例之间的关系。
例如,用户可以注册账号,我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。
除了角色和用例之间的关系,用例图还可以表示用例之间的关系。
在本案例中,用户可以浏览商品、添加购物车、下单和支付,这些用例之间存在一定的先后顺序。
我们可以使用虚线箭头来表示这种顺序关系。
例如,用户可以先浏览商品,然后将商品添加到购物车,最后下单和支付。
我们可以在浏览商品和添加购物车之间画一条虚线箭头,表示用户在浏览商品后可以将商品添加到购物车。
此外,用例图还可以表示用例之间的包含和扩展关系。
在本案例中,用户下单时可能需要选择配送地址,我们可以将选择配送地址作为一个包含关系,用一个带有加号的实线箭头表示。
另外,用户下单时还可以选择使用优惠券,这可以作为一个扩展关系,用一个带有箭头和加号的虚线箭头表示。
通过用例图,我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。
UML在ATM自动取款机中的应用(一)Uml 基础知识Uml 概述UML (Unified Modeling Language)是软件界第一个统一的建模语言,该方法结合了Booch , OMT ,和OOSE 方法的优点,统一了符号体系,并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术.它是一种标准的表示,已成为国际软件界广泛承认的标准。
是一种基于面向对象的可视化的通用(General )建模语言。
为不同领域的用户提供了统一的交流标准 — UML 图。
UML 应用领域很广泛,可用于软件开发建模的各个阶段,商业建模(Business Modeling ), 也可用于其它类型的系统。
UML 是一种定义良好,易于表达,功能强大且普遍实用的建模语言,不是一种方法,它独立于过程。
利用它建模时,可遵循任何类型的建模过程。
建模过程:UML 的主要构成向对象分析与设计的一种UML 是一种标准化的图形建模语言,它是面向对象分析与设计的一种标准表示.由:● 视图(views ), ● 图(Diagrams ),● 模型元素(Model elements ) ● 通用机制(general mechanism )等几个部分构成。
视图(views)一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图(view)。
视图由多个图(Diagrams)构成,它不是一个图表(Graph),而是在某一个抽象层上,对系统的抽象表示。
如果要为系统建立一个完整的模型图,需定义一定数量的视图,每个视图表示系统的一个特殊的方面。
另外,视图还把建模语言和系统开发时选择的方法或过程连接起来。
图(Diagrams)UML语言定义了五种类型9种不同的图,把它们有机结合起来就可以描述系统的所有视图。
用例图(Use case diagram)从用户角度描述系统功能,并指出各功能的操作者。
静态图(Static diagram),表示系统的静态结构.包括类图、对象图、包图。
1、设计一个饮料自动售货机系统,其主要功能是向顾客出售饮料,同时供应商需要向其中放置饮料,收银员需要向其中放置零钱和收回营业收入。
画出该系统的用例图。
2、仔细分析下面对某公司“会见顾客”业务流程的描述,画出带泳道的活动图。
(1)公司业务员打电话给客户,确定一个会面。
(2)如果会面地点在公司内,公司技术人员需要为会面准备一间会议室,同时,咨询顾问需要为准备一份陈述报告。
(3)如果会面地点在公司外,则只需咨询顾问需要为准备一份陈述报告。
(4)咨询顾问与顾客在约定的时间和地点见面。
(5)业务员随后为他们准备好会议用纸。
(6)如果会面得到了一个解决方案,则咨询顾问根据解决方案编写一个报告,并将报告发给顾客。
3 所谓基金定投指的是投资者在每个月固定的时间(如每月10日)以固定的金额(如1000
元)投资到指定的开放式基金中,类似于银行的零存整取方式。
具体实现过程如下:定投约定的日期一到,系统首先检查客户设定的扣款账户余额,确认余额是否足够支付交易款项,如果足够,则扣交易款项,更新客户基金账户中基金的份额,交易成功,并且把交易扣款失败次数归零。
否则检查累计失败次数,如果累计失败次数超过三次,则停止扣款,并且更改交易情况为“停止扣款”。
请采用活动图模型对这个业务进行建模。
实验二:建立动态模型一旦定义了一个工程的用例,就可以用它们来指导对系统的进一步开发。
用例的实现描述了相互影响的对象的集合,这些对象将支持用例所要求的功能。
给出系统用例的实现,是从外部视图转到内部结构的第一步。
在UML中,用例的实现用交互图来指定和说明。
交互图通过显示对象之间的关系和对象之间处理的消息来对系统的动态特性建模。
有两种交互图:序列图和协作图。
1、创建交互图的步骤交互图一步一步地显示用例的实现流程。
它包括流中需要什么对象、对象之间发送什么、什么角色启动流、消息按什么顺序发送等。
系统要求实现的所有不同情形都在交互图中记录。
通过从用例建模得到的用例文档说明、词汇表和用例图来创建交互图。
2、实例本节主要以选课系统中的选课用例(Select Course)为例,来学习序列图的设计与实现。
2.1 分析为了使问题更简单一些,不考虑学生的登陆。
假设学生已经成功登陆系统,选课的事件流如下:(1)学生进入选课主界面。
(2)学生点击选课。
(3)系统显示所有课程信息。
(4)学生选择课程。
(5)系统验证课程是否可选。
A1:课程不可选(6)系统提示课程选择成功,提示学生交费。
(7)用例结束。
A1:课程不可选(1)系统提示课程不可选及原因。
(2)学生重新选课。
(3)重新验证直至成功。
(4)转选课事件流第6步。
首先,查找Select Course用例的对象。
从事件流中发现涉及以下对象:(1)界面。
(2)课程。
(3)对于业务层的操作,也应该有对象进行处理。
(4)事件流中设计的角色有:学生、数据库。
然后,分析对象、角色之间交互的消息。
本用例主要有以下交互:(1)学生通过界面发送选课命令。
(2)界面向控制对象请求课程信息。
(3)控制对象向数据库发送查询数据消息。
(4)控制对象暂存数据库的查询结果。
(5)界面对象从控制对象中取得所有的课程信息。
(6)在界面上显示所有的课程信息。
(7)界面对象发送命令要求控制对象删除课程信息。