用例图

合集下载

02-用例和用例图

02-用例和用例图

3.4.4 几种关系的比较
关系类型
说明
表示符号
关联
actor与use case之间
泛化
actor之间或use case之间
包含
use case之间
扩展
use case之间
用例图
用例图(use case diagram)是显示一组用例、角色以及它 们之间的关系的图.
在UML中, 一个用例模型若干个用例图描述.
角色
由于Actor实际上是一个特殊类, 因此它们之间可以 存在一定的关系,如:
脚本/场景
脚本(scenario)在UML中指贯穿用例的一条单一路径, 用 来显示用例中的某种特殊情况.
其它译名: 情景、情节、剧本.
每个用例有一系列脚本, 包括一个主要脚本, 以及几个 次要脚本. 相对于主要脚本, 次要脚本描述了执行路径 中的异常或可选择的情况.
实例分析:语音邮箱系统----用例脚本
用例3: 登录系统 1. 邮箱用户完成邮箱号输入操作. 2. 邮箱用户键入密码并后跟#键.(默认号码与邮箱号相同) 3. 语音邮件系统播放邮箱菜单: 按1键接收信息. 按2键更改密码. 按3键更改问候语.
实例分析:语音邮箱系统----用例脚本
用例4: 接收信息 1. 邮箱用户完成登录操作. 2. 邮箱用户选择 “接收信息”菜单选项. 3. 语音邮件系统播放信息菜单: 按1收听当前信息; 按2存储当前信息; 按3删除当前信息; 按4返回邮箱菜单. 4. 邮箱用户选择“收听当前信息”菜单选项. 5. 语音邮件系统播放当前新信息,若无新信息,播放当前已有信 息.(注意: 只播放,不删除) 6. 语音邮件系统播放信息菜单. 7. 用户选择”删除当前信息”,则信息被永久删除. 8. 继续执行第3步.

第5章 用例图

第5章 用例图

用例与事件流
• 用例分析处于系统的需求分析阶段,这个
阶段应该尽量避免考虑系统实现的细节问 题,这些细节问题写在事件流文件中。事 件流文件即用例的逻辑流程文档包括:
• 1. 简要说明:描述用例的作用; • 2. 前提条件:用例之前必须满足的条件;例:用户是否有运行权限 • 3. 事件流(主事件流、其他事件流、错误流 ):描述参与者执行用
习题:
• 2、一台饮料自动售货机能提供6种不同的 、一台饮料自动售货机能提供6
饮料。售货机上有6 饮料。售货机上有6个按钮,分别对应于这 6中饮料,顾客可以通过按钮来选择所要的 饮料。每个按钮旁边有一个指示灯,用来 表明该售货机中是否还有这种饮料可售。 售货机有一个硬币槽的找零槽,用来收钱 和找钱。
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
3. 系统管理员进行系统维护的用例
① 查询借阅者信息 ② 查询书籍信息 ③ 增加书目 ④ 删除或更新书目 ⑤ 增加书籍 ⑥ 删除书籍 ⑦ 添加借阅者帐户 ⑧ 删除或更新借阅者帐户
5.3.4 使用Rational Rose绘制用例图 使用Rational Rose绘制用例图 的步骤
扩展关系
• 扩展用例被定义为基础用例的增量扩展,这称作
扩展关系。
用例间的扩展关系
扩展关系例子
扩展关系指的是基础用例执行的情况下可选择是否执行提供者用例。
泛化关系
• 父用例也可以被特别列举为一个或多个子用例。 • 子用例从父用例处继承行为和属性,还可以添加
行为或覆盖、改变继承的行为。
用例间的泛化关系 泛化关系例子
例的具体步骤; • 4. 事后条件:用例执行完毕后必须为真的条件。例:用例完成之后 设置一个标志,这种信息就是事后条件。

第6章 用例图

第6章 用例图

3、构建用例模型
采 购 员 用 例 图
采购员能够通过该系统进行订货管理活动。采购员首先根据经营情 况统计所缺的生产资料,根据需要制定出订单。
UML统一建模语言
五、使用Rose创建用例图的步骤说明
3、构建用例模型
会 计 用 例 图
会计负责产品的统计分析 管理,它能够通过该系统 进行如下活动: (1)查询基本信息。会计 能够查询产品的基本信息, 根据产品的基本信息,制 定出相应的方案。 (2)查询销售信息。会计 根据销售情况汇总后交销 售部制定合理的销售方案。 (3)查询供应商信息。会 计能够查询供应商信息。 (4)查询缺货信息。会计 能够查询缺货信息。 (5)查询报损信息。会计 能够查询报损信息。
1、需求分析
“企业进、存、销管理系统” 功能性需求包括以下内容: (1)采购员根据生产原料的使用情况判断采购用品,对需要订购产品信息 统计订货的,并制作产品订单。最后根据订单进行采购活动。 (2)仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、 处理报损产品信息和一些信息的设置。这些设置信息,包括:供应商信息、产 品信息。仓库管理员每天对产品进行一次盘点,当发现库存产品有损坏时,及 时处理报损信息。当产品生产后,将产品进行入库。当产品销售后时,产品进 行出库处理。 (3)统计人员负责统计分析管理,包括:查询产品信息、查询销售信息、 查询供应商信息、查询缺货信息、查询报表信息,并制作报表。统计分析员使 用系统的统计分析功能,了解产品信息、销售信息、供应商信息、库存信息。 (4)在销售员为客户提供售货服务时,接受客户购买产品,根据系统的定 价计算出产品的总价,客户付款,系统自动保存客户购买记录。 (5)系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、 供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登 录到各自的管理系统中。

用例图

用例图

用例图百科名片用例图就是由主角、用例以及它们之间的关系构成的图。

该图说明了用例模型中的关系。

简介用例图(User Case)是被称为参与者的外部用户所能观察到的系统功能的模型图,呈现了一些参与者和一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。

用例图展示了用例之间以及同用例参与者之间是怎样相互联系的。

用例图用于对系统、子系统或类的行为进行可视化,使用户能够理解如何使用这些元素,并使开发者能够实现这些元素。

将每个系统中的用户分出工作状态的属性和工作内容,方便建模,防止功能重复和多余的类。

用例图定义了系统的功能需求,它是从系统的外部看系统功能,并不描述系统内部对功能的具体实现。

ps: 提取出“名词”,画用例图构成用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。

参与者参与者不是特指人,是指系统以外的,在使用系统或与系统交互中所扮演的角色。

因此参与者可以是人,可以是事物,也可以是时间或其他系统等等。

还有一点要注意的是,参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。

比如小明是图书馆的管理员,他参与图书馆管理系统的交互,这时他既可以作为管理员这个角色参与管理,也可以作为借书者向图书馆借书,在这里小明扮演了两个角色,是两个不同的参与者。

参与者在画图中用简笔人物画来表示,人物下面附上参与者的名称。

用例用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。

这是UML对用例的正式定义,对我们初学者可能有点难懂。

我们可以这样去理解,用例是参与者想要系统做的事情。

对于对用例的命名,我们可以给用例取一个简单、描述性的名称,一般为带有动作性的词。

用例在画图中用椭圆来表示,椭圆下面附上用例的名称。

系统边界系统边界是用来表示正在建模系统的边界。

边界内表示系统的组成部分,边界外表示系统外部。

系统边界在画图中方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。

用例及用例图案例

用例及用例图案例
第3章
用例及用例图-案例
3.7 业务用例图 3.8 案例
1
3.7 业务用例图
• 作用
– 帮助了解机构及其软件系统(或工作内容) – 帮助业务过程重建工程工作 – 帮助员工(小组内成员)充分了解业务及其角色
• 什么时候需要
– 对机构不熟悉 – 机构业务发生变更 – 机构中主要部分使用的软件需建立 – 机构中有些大型复杂工作流的文档不足
20
● ⑤ 绘制用例图。
21
● ⑥ 编制用例说明。
● 用例:客房预订 ●参与者:柜台工作人员 ●说明:
① 工作人员启动预订功能。 ② 根据预订需求查看客房空闲信息。 ③ 输入预订人信息。 ④ 安排客房。 ⑤ 预订成功。
22
● ⑥ 编制用例说明。
● 用例:预订变更 ●参与者:柜台工作人员 ●说明:
A2:有冲突。
⑧系统添加新课程,并提示添加成功。
⑨系统回到管理主界面,显示所有课程,用例结束。
14
● ⑦ 对异常流程确定单独用例。 ⑧ 优化用例图,解决用例之间的冲突和重复。
15
案例3:
宾馆客房业务管理用例分析
宾馆客房业务管理提供客房预订、预订变更、 客房入住、退房结帐、旅客信息查询几个方面的 功能。
第3章 用例和用例图
● 3.4 用例图 3.4.1 用例图的作用 3.4.2 用例图的形式
● 3.5 用例描述 ● 3.6 用例分析 ● 3.7 业务用例图
● —— 重要知识点
26
本章作业
(1) 什么叫用例? (2) 用例图在软件建模中的作用是什么? (3) 用例之间存在那几种关系? (4) 包含关系和扩展关系有什么区别? (5) 参与者可以是那几种形式? (6) 什么叫事件流,作用是什么?

用例图

用例图

顾客顾客用户2.1 用例建模技术2.1.1 参与者和用例参与者(actor )是系统外部与系统有交互的任何事物,是为了完成一个事件而与系统交互的外部实体。

参与者主要用于描述系统的边界。

例如,向银行提交贷款申请的顾客;通过因特网访问预订系统查询座位情况的旅行社,等等。

在UML 中,参与者经常用人形符号表示,或者用类的构造型《actor 》表示,如图2-3所示。

图2-3 参与者的UML 表示符号参与者并不一定是系统的用户。

它们可能是外部系统、外部机构、外部设备和其它与系统有交互的任何外部实体。

图2-4展示参与者是外部系统的例子。

图2-4参与者是外部系统的例子当参与者是人时,它是指一个与系统有交互的用户所扮演的角色。

一个参与者并不是指一个特定的人或一个特定的实体。

例如,参与者“顾客”是对顾客的概念建模,而不是对张三这个特定的顾客建模。

一个用例并不仅局限于一个参与者; 参与某用例的参与者可能是多个。

然而,一个用例况必须向至少一个参与者提供可度量的价值。

参与某用例的多个参与者各有不同的角色和职责:一些负责接收用例提供的价值,一些则负责向用例提供服务,其它则负责触发或初始化用例。

Ivar Jacobson[1992]将参与者划为两类:主要的和次要的。

主要参与者(primary actor)是从系统获得可度量价值的用户。

主要参与者的需求驱动了用例所表示的行为或功能。

如果他们的需求或角色发生了变化,那么系统将必须有重大的修改。

次要参与者(secondary actor)在用例中提供服务,并且不能脱离主要参与者而存在。

在图2-4所示的例子中,顾客是主要参与者,而客户关系系统则是次要参与者。

顾客<<Actor>>顾客 客户关系管理系统 (已有) 网上商店系统(要开发) 问卷调查系统 (已有)图2-5 抽象参与者的例子一些参与者只扮演概念上的角色,而另一些则更具体。

如图2-5所示,顾客共享用户的属性。

用例图(User Case)

用例图(User Case)

用例图(User Case)用例图是用来描述什么角色通过某某系统能做什么事情的图,用例图关系的是系统的外在表现,系统与人的交互,系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义:小人:对使用某系统的用户进行分类后,可以总结出使用本系统有哪些角色,不同的角色的工作责任不太一样,他们需要用到的系统的功能也会不太一样。

小人就是角色,它给了我们一个启示,我们思考某系统的需求时,可从不同角色的角度来思考。

例如:我们要做一个考勤系统,你会怎样思考呢?会一下子列出很多功能?比较好的方式,应该是先思考什么人会用这个系统,我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统,对于一般员工来说除了打卡,他还关注什么?对于前台,她是不是要做一些考勤的统计?而财务是不是要根据考勤情况来调整员工的薪金?这样的思考方式,会让我们更容易全面发掘系统的需求。

还需要特别说明的是:角色可能是人,也可能不是人,而是另外的一个系统,本系统与另外一个系统交互的话,可以将另外一个系统画成某某角色。

圈圈:圈圈里面会有一段动宾结构的文字,也就是“动词+名词”这样的方式,这个圈圈+圈圈里面的文字,就是用例,这些用例表明了系统能做什么事情。

以考勤系统为例:有两个用例叫“打卡”、“查看自己的考勤情况”,这个两个圈圈分别用一条线连到了“一般员工”这个角色,我们可以按这样的顺序来读这个图:先读出角色的名字,然后读出用例中的文字。

按着这样的读法,我们可以得到两句完整的句子:“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。

某用例不一定是只属于某个角色的,有不少用例是多个角色“共享”的。

大框框:在所有用例的外面,有一个方框,这个方框只框住了用例,没有框住角色,这个东西就叫做系统边界,框框的上部会注明本系统的名字。

我们所做的系统,是不可能包括角色的,系统要发挥各种作用,要靠各角色“穿越”系统边界来使用本系统的用例。

第3章 用例图

第3章 用例图

案例分析--用例图
实例:“杂志流通”
在杂志的内容被一个雇员分析之前,每个杂志 首先由图书馆登记;分析员认为有意义的文章 被汇总输入到系统中;随后,杂志在雇员中传 阅。在此过程中,要求生成流通通知。该通知 被附到杂志上,并且包含现在正在阅读杂志的 雇员的名字。最后,在最后一名读者把杂志返 回到图书馆时,它由图书馆来存档。
3.1 参与者
从上面的问答得到系统中初步的类和对象:
GUI(图形用户界面):识别用户的命令,接收 用户的输入,显示程序的结果。
Recorder(记录员):记录中奖信息。 Chooser(抽奖者):抽出中奖号码。 Printing(打印对象):打印中奖信息。 Searching(查询对象):为奖票持有者查询中
3.2 用例
问:抽奖主持人用这个系 抽奖程序初步的用例图
统做什么事情?兑奖人员
抽奖程序
如何用这个系统帮助兑奖

抽出中奖号码
答:抽奖主持人用这个系统 活动主持人 抽出中奖号码,兑奖人员用
活动主持人
这个系统打印本次活动所有
打印中奖记录
的中奖记录。再对照记录兑 兑奖者
兑奖者
奖。
查询中奖情况
奖票持有者
奖票持有者
用例图的构成4要素:
参与者 用例 系统边界 关联
用例图的基本概念
3.1 参与者
1. 参与者(Actor)的概念
参与者是指存在于被定义系统外部并与该系统发生 交互的人或其他系统,他们代表的是系统的使用者 或使用环境。
在确定系统的用例时,首要问题就是识别参与者 (是一个类!!!!!!不是对象)。
如何识别用例?
参与者要向系统请求什么功能? 每个参与者的特定任务是什么? 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗? 是否任何一个参与者都要向系统通知有关突发性的、外部的改变?

《软件工程》第3章用例图及其应用

《软件工程》第3章用例图及其应用
用例与参与者之间存在关联关系,表示参与者可以参与用例的执行。这种关系有助于明确系统的边界和 交互方式。
用例图在软件开发中重要性
1
用例图是软件开发过程中的重要工具之一,它能 够帮助开发团队更好地理解用户需求,明确系统 的功能范围。
2
通过用例图,开发团队可以对系统的交互方式进 行模拟和验证,从而发现潜在的问题和缺陷,提 高软件的质量。
用例图的更新可以及时地反映到自 动化测试脚本中,保证测试脚本的 实时性和准确性。
评估测试覆盖率
用例图可以帮助测试人员评 估测试的覆盖率,确保所有 重要的功能和业务流程都被
测试到。
通过对比用例图和已执行的 测试用例,可以找出未被测 试到的功能和业务流程,从
而完善测试计划。
测试覆盖率的评估有助于提 高测试的质量和效率,降低 漏测的风险。
02
针对每个测试场景,细化出具体的测试用例,包括输
入数据、预期结果和测试步骤。
03
用例图可以帮助测试人员更好地理解系统需求,从而
设计出更全面的测试用例。
指导自动化测试脚本编写
用例图提供了系统的功能框架和业务流 程,为自动化测试脚本的编写提供了指 导。
测试人员可以根据用例图中的元素和关系, 编写出对应的自动化测试脚本。
验证设计满足原始需求
01 用例图是需求分析和设计阶段源自重要产物,它描 述了用户期望的系统功能和行为。
02 在系统设计完成后,可以通过与原始用例图进行 对比,验证设计是否满足原始需求。
03 如果设计不符合原始需求,则需要重新调整设计, 直到满足所有需求为止。
评估系统可扩展性和可维护性
用例图可以帮助评估系统的可扩展性和可维护性。
扩展关系
02
03

用例图

用例图

用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步,它描述人们如何使用一个系统。

用例视图显示谁是相关的用户、用户希望系统提供什么样的服务,以及用户需要为系统提供的服务,以便使系统的用户更容易理解这些元素的用途,也便于软件开发人员最终实现这些元素。

用例图在各种开发活动中被广泛的应用,但是它最常用来描述系统及子系统。

当用例视图在外部用户出现以前出现时,它捕获到系统、子系统或类的行为。

它将系统功能划分成对参与者(即系统的理想用户)有用的需求。

而交互部分被称作用例。

用例使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。

用例图包含六个元素,分别是:参与者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。

用例图可一个包含注释和约束,还可一个包含包,用于将模型中的元素组合成更大的模块。

有时,可以将用例的实例引入到图中。

用例图模型如下所示,参与者用人形图标来标识,用例用椭圆来表示,连线表示它们之间的关系。

一.参与者(Actor)1.参与者的概念参与者是系统外部的一个实体,它以某种方式参与用例的执行过程。

参与者通过向系统输入或请求系统输入某些事件来触发系统的执行。

参与着由参与用例时所担当的角色来表示。

在UML中,参与者用名字写在下面的人形图标表示。

每个参与者可以参与一个或多个用例。

它通过交换信息与用例发生交互(因此也与用例所在的系统或类发生了交互),而参与者的内部实现与用例是不相关的,可以用一组定义其状态的属性充分的描述参与者。

参与者有三大类:系统用户、与所建造的系统交互的其它系统和一些可以运行的进程。

第一类参与者是真实的人,即用户,是最常见的参与者,几乎存在于每个系统中。

命名这类参与者时,应当按照业务而不是位置命名,因为一个人可能有很多业务。

第二类参与者是其它的系统。

4.用例图

4.用例图

注意事项
同一个人或事物可以扮演不同的角色
参与者不是指人或事物本身,而是指人或事物 当时所扮演的角色。 不能将参与者的名字设置为参与者某个实例的 名字
参与者之间的关系
参与者实质上也是类,因此它拥有与类相同的关 系描述 参与者与参与者之间主要是泛化关系
用例的定义
定义:
是参与者可以感受到的系统服务或功能单元。 用文本的形式描述了参与者为了使用系统的某 项功能而与系统之间发生的交互过程
用例图中的注释

取款
持有银行信用卡的 自动取款机用户
查询
银行客户
转账
用例文档
用例文档(Documentation规约)
用例模型 =
用例图
+
用例文档
用例图只能勾勒一个大致的系统功能轮廓, 对于软件开发活动而言不够充分 一个完整的用例模型不仅包括用例图这个部 分,更重要的是它的用例描述部分 用例文档:
用例与场景
张三取款
李四取款 取款 …… XXX取款
用例
场景
场景举例
场景名称 取款3000元
参与者 客户小刘 事件流 (1) 小刘将银行卡插入柜员机。 (2)柜员机要求客户输入卡密码。 (3)小刘输入卡密码,并确认密码。 (4)柜员机屏幕提示,请客户选择服务类型。 (5)小刘选择取款服务。 (6)柜员机提示:请客户输入取款数目。 (7)客户输入3000,并确认。 (8)柜员机出钱口输出30张一佰元的人民币。 (9)小刘取回30张100元面额的人民币。 (10)柜员机提示服务类型:确认、或继续,或退卡。 (11)小刘选择服务类型退卡,结束服务。
泛化关系:一个父用例可以被特化形成多 个子用例,子用例继承了父用例所有的结 构、行为和关系,子用例是父用例的一种 特殊形式。 通过一个三角箭头从子用例指向父用例

用例图的画法

用例图的画法
第26页,共33页。
1. 借阅者请求服务的用例
① 登录系统 ② 查询自己的借阅信息 ③ 查询书籍信息 ④ 预定书籍 ⑤ 借阅书籍 ⑥ 归还书籍
第27页,共33页。
2. 图书馆管理员处理借书、还书的用例
① 处理书籍借阅 ② 处理书籍归还 ③ 删除预定信息
第28页,共33页。
3. 系统管理员进行系统维护的用例
① 识别系统外部的参与者。 ② 将类似参与者组织成泛化的结构层次。 ③ 在需要加深理解的地方,为每个参与者提
供一个构造型。 ④ 将参与者放入到用例图中,并说明参与者
与用例之间的通信路径。
第18页,共33页。
5.2.2 对需求建模
① 识别系统的外部参与者来建立系统的语境。 ② 考虑每一个参与者期望的行为或需要系统提供的行为。
用例图的画法
第1页,共33页。
5.1.1 概述
▪ 用例图显示谁将是相关的用户、用户希望系统提 供什么服务以及用户需要为系统提供的服务。
▪ 用例图最常用来描述系统以及子系统。
第2页,共33页。
5.1.1 概述
▪ 用例图包含6个元素: ① 参与者(Actor) ② 用例(Use Case) ③ 关联关系(Association) ④ 包含关系(Include) ⑤ 扩展关系(Extend) ⑥ 泛化关系(Generalization)
第5页,共33页。
确定参与者
▪ 如何寻找系统的参与者 ▪ 对参与者建模的过程中需要注意的问题
第6页,共33页。
参与者间的关系
▪ 在用例图中,使用泛化 关系来描述多个参与者 之间的公共行为。
▪ 参与者间的泛化关系示 例:
第7页,共33页。
5.1.3 用例
▪ 外部可见的系统功能单元。 ▪ 在不揭示系统内部构造的前提下定义连贯的

用例图及用例规约

用例图及用例规约

京胜校园软件综合实验室用例图用户登录用例图本图共有三个角色:operator、teacher、student,operator登录到管理员模块,teacher登录到指导教师模块,student登录到学生模块。

三大模块都可以实现退出功能。

学生模块用例图学生模块又分为四大模块:我的实训,我的课程,个人中心,资料中心(如图)。

我的实训我的实训又分为四个小模块:我的消息,通知公告,我的课表,我的实训(如图)。

1.我的消息学生可以查看收件箱和发件箱的信息,并且扩展发送消息、删除消息、回复消息三种功能。

2.通知公告3.我的课表4.我的实训。

我的课程我的课程里只有一个小的模块:我的课程(如图)。

1.我的课程在我的课程里可以查看我的课程,并且扩展功能:进入课程。

资料中心资料中心分为两个小模块:下载资料和链接资料1.下载资料学生选择某一文件,便能够查看要下载的资料,在此处可以下载。

2.链接资料个人信息分为两个小模块:我的资料和修改密码1.我的资料2.更改密码指导教师模块指导教师模块分为信息管理、资源管理、实训组织、课程组织、资料管理5个模块。

信息管理信息管理又分为实训计划和投稿信箱两个模块1.实训计划指导教师可以在此查看实训计划,并且实现查看统计(查看被通知者查看信息的情况)、添加通知、删除通知、修改通知、查询(通过标题查找)5大功能。

2.投稿信箱指导教师可以在此查看投稿信箱,并且实现查询(通过投稿标题查询)功能。

资源管理资源管理模块里包含一个小模块内容管理。

1.内容管理实训组织实训组织模块又分为我的课程、实训管理、成绩管理3个小模块。

1.我的课程指导教师可以查看自己的课程,并实现查询(时间段或全部)功能。

2.实训管理3.成绩管理指导教师可以在此处查看成绩,并能实现查询(学期、班级、课程)、编辑成绩2大功能,其中编辑成绩又可以实现查看成绩、删除成绩、添加成绩、导入成绩(、查询(成绩名称)5大功能课程组织课程组织模块包含一个小的模块:课程管理。

用例图(User Case)

用例图(User Case)

用例图(User Case)用例图是用来描述什么角色通过某某系统能做什么事情的图,用例图关系的是系统的外在表现,系统与人的交互,系统与其它系统的交互。

下面逐一说明用例图中各种符号的意义:小人:对使用某系统的用户进行分类后,可以总结出使用本系统有哪些角色,不同的角色的工作责任不太一样,他们需要用到的系统的功能也会不太一样。

小人就是角色,它给了我们一个启示,我们思考某系统的需求时,可从不同角色的角度来思考。

例如:我们要做一个考勤系统,你会怎样思考呢?会一下子列出很多功能?比较好的方式,应该是先思考什么人会用这个系统,我们大概可以估计一般员工、高层领导、前台、财务等都会用这个系统,对于一般员工来说除了打卡,他还关注什么?对于前台,她是不是要做一些考勤的统计?而财务是不是要根据考勤情况来调整员工的薪金?这样的思考方式,会让我们更容易全面发掘系统的需求。

还需要特别说明的是:角色可能是人,也可能不是人,而是另外的一个系统,本系统与另外一个系统交互的话,可以将另外一个系统画成某某角色。

圈圈:圈圈里面会有一段动宾结构的文字,也就是“动词+名词”这样的方式,这个圈圈+圈圈里面的文字,就是用例,这些用例表明了系统能做什么事情。

以考勤系统为例:有两个用例叫“打卡”、“查看自己的考勤情况”,这个两个圈圈分别用一条线连到了“一般员工”这个角色,我们可以按这样的顺序来读这个图:先读出角色的名字,然后读出用例中的文字。

按着这样的读法,我们可以得到两句完整的句子:“一般员工打卡”“一般员工查看自己的考勤情况”大家可以用这样的方式来检查自己用例图是否画得合适。

某用例不一定是只属于某个角色的,有不少用例是多个角色“共享”的。

大框框:在所有用例的外面,有一个方框,这个方框只框住了用例,没有框住角色,这个东西就叫做系统边界,框框的上部会注明本系统的名字。

我们所做的系统,是不可能包括角色的,系统要发挥各种作用,要靠各角色“穿越”系统边界来使用本系统的用例。

02 UML用例图基础知识

02 UML用例图基础知识

表示符号
表示参与者与用例之间的通信,任何一方都可发送 或接收消息。
uc 继承关系,子用例将继承基用例 的所有行为、关系和通信关系,也就是说在任何使 用基用例的地方都可以用子用例来代替。
泛化关系在用例图中使用空心的箭头表示,箭头方 向从子用例指向基用例。 uc Use Case Model
参与者总是处在正在建模的系统的外部,不是系统
的组成部分,是与系统、子系统或类发生交互的外 部用户、进程或其他系统。
参与者有3大类,即系统用户、与本系统交互的其 他系统和一些可以运行的进程。
名称
说明

即用户,是最常用的参与者。例如,汽车租赁公司的汽车租赁者,即客
户。
其他的系统
在当前的项目范围外,建立与其他系统的接口。该类位于程序边界之外
注:任何用例都不能在缺少参与者的情况下独立存在。同样,任何参与者也必须要有与之关联的
用例。
2)用例图形表示
在UML中,用例使用一个椭圆来表示,用例的名称写在椭圆里,如 下图所示:
3)用例命名
用例是从用户的角度来描绘系统的功能,是根据所执行的实例来命名 的,通常情况下,用例名是一个短语,例如浏览帐户、登陆系统等。 命名的基本原则有以下几种:
一、什么是用例图(Use Case Diagram) 二、用例图的组成 三、用例建模技术
用例图也称为用户模型图,是由软件需求分析到最终实现的第1步, 它是从用户的角度来描述系统功能,描述人们希望如何使用一个系统。 用例图显示谁将是相关的用户、用户希望系统提供什么服务,以及用 户需要为系统提供的服务。
线上标注<u<c Usee CaxsetMoedenl d>>),箭头从子用例指向基用
例。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

UML建模基础——用例图东软人才实训中心3 Sept. 2008©Neusoft Confidential第二章:用例图学时:1学时教学方法:讲授ppt+上机练习+案例分析目标:本章旨在向学员简要介绍用例模型及用例的关系,通过本课的学习,学员应该掌握如下知识:1)能区分角色和用例2)了解用例的关系图例---用例图•展示系统外部的各类执行者与系统提供的各种用例之间的关系。

用例模型•什么是用例模型–主要由用例、用例描述和用例图组成,用来描述系统的外部特征。

–用例模型代表了从系统外部的用户角度看的系统的功能和环境–只说明系统实现什么功能,不必说明如何实现。

–在Use-case View中创建–对于分析、设计和测试活动都是至关重要的–包括用例图、用例规约和补充规约,也可以包括活动图•为什么要创建用例模型–用例模型允许顾客和系统开发者之间用一种用户可以理解的语言交流系统要做什么–用例模型是顾客和开发者之间的可视化契约用例图(Use case diagram)•用例图表示了用例和角色以及用例和用例之间的关系–可视化的表示出了客户希望系统做什么–代表一些大的完整的功能–表示系统完成的有明确结果的对角色有价值的一系列动作•可以模型化–所有的角色和用例(global view)–某个选定角色的所有用例–一个用例以及它所有的关系–一个迭代的所有的用例用例图的元素•角色•用例Student •关系Registration角色(Actor)•定义:系统外的与系统进行交互的人、硬件设备、另一个系统。

•种类–人–外部系统–外部设备或TimerStudent角色(续)•如何判断一个事物是不是actor–首先它必须与系统有交互,如果与系统没有交互则不是角色–其次它必须是系统外的,如果它是我们将要开发的系统或是系统的一部分则不是角色•其它–用户如果通过标准的输入和输出设备与系统交互,则用户是Actor–用户如果通过特殊的设备与系统交互,则设备是Actor角色(Actor)•如何识别角色?–谁将使用系统的主要功能?–谁将需要系统的支持来完成他们的日常工作?–谁必须维护、管理和确保系统正常工作?–谁将给系统提供信息、使用信息和维护信息?–系统需要处理哪些硬件设备?–系统使用了外部资源吗?–系统需要与其它系统交互吗?–谁或者什么对系统产生的结果感兴趣?–有没有定时触发的行为?用例(Use Case)•定义:用例是可以被角色感受到的、系统的一个完整的功能。

是actor与系统的一系列交互。

•特点:–完成actor的某个目的(不是功能),一般会给actor一个有价值的结果–用例总是被角色启动,并向角色提供可识别的值。

–其中,系统是一个黑盒–用于描述系统行为,但不描述如何实现用例(续)•识别用例的依据就是用例的定义和特点•识别用例时需要注意–用例可大可小,但必须是完整的。

–用例描述的是系统做什么,初始识别用例的时候不要过多考虑系统的实现,即把系统作为黑盒–外部系统或设备的行为不是要开发的系统行为,不要识别出来用例用例(续)•有些用例不代表系统的主要功能,因而通常会被大家忽视,这些用例可能属于以下类型:–系统启动和停止–系统的维护。

例如,添加新用户和建立用户简档–维护在系统中存储的数据。

例如,所构建的系统和遗留系统平行工作,所以数据需要在两个系统之间达到同步–修改系统行为所需的功能。

例如创建新报告的功能,它不仅可以创建硬代码,还可以对系统中存储的数据创建一组特定报告用例(续)•如何寻找用例?–角色要向系统请求什么功能?–每个角色的特定任务是什么?–角色需要读取、创建、撤销修改或存储系统的某些信息吗?–是否任何一个角色都要向系统通知有关突发性的、外部的改变?或者必须通知角色关于系统中发生的事件?–这些事件代表了哪些功能?–系统需要哪些输入/输出?–哪些用例支持或维护系统?–是否所有的功能需求都被用例使用了?Actor 和Use case 的关系Sys temStar tup (f ro m Sy s tem)Driver(from A ctors)•Actor 与use case 之间的关系是association 关系,含义是“触发”,千万不要理解成数据流•从browser窗口中加入–选择要加入模型元素所在的package,单击鼠标右键,从弹出菜单中选择new-->模型元素种类(如class,package,use case diagram等),此时相应的包下面就会加入一个新的元素,你可以为它命名•从Diagram的toolbar中直接加入–从toolbar中选择要加入的元素类型,单击diagram窗口的某个位置,新的元素就会显示到diagram窗口中,此时你可以为新元素命名。

同时browser中也出现新的元素(新的模型元素会加入到相应的diagram所在的包中)。

•双击browser或diagram中的元素(或者单击鼠标右键,从弹出菜单中选择open specification)就会打开新建元素的specification,在specification对话框中,你可以更改名字以及做其他的设置•注意:diagram没有specification•注意:双击diagram中的package,不会打开它的specification,而是进入package下的某个类图•Delete from model:模型元素从模型中删除(也从它参与的所有图中删除)–从browser中选择要删除模型元素,单击鼠标右键,从弹出菜单中选择delete,或者–从diagram中选择要删除模型元素,从菜单中选择edit-->delete from model(快捷键ctrl+D)•Delete from diagram–从diagram中中选择要删除模型元素,从菜单中选择edit-->delete (快捷键Del)详细用例模型•Actor之间的关系——泛化(generalization)super actor sub actor •Use Case之间的关系–泛化(generalization):不常用–扩展(extend)–包含(include)用例之间的扩展关系•扩展关系的双方分别叫做基本用例(Base use case)和扩展用例(extension use case)•扩展用例用来模型化基本用例中–有条件的部分,只在某些环境下执行–复杂的或可选的路径。

•扩展关系用stereotype是“extend”的association关系来表示用例之间的扩展关系(续)•扩展用例和基本用例的关系–基本用例自身应是完整的,即基本用例在不必引用任何扩展用例的情况下,应该是可理解且有意义的–基本用例可以不依赖于扩展用例而单独的运行–扩展用例只有在基本用例中的某种条件满足时才能执行,如果没有基本用例,扩展用例不能运行–扩展用例可以扩展多个基本用例•扩展点–定义在基本用例的哪些位置插入扩展用例–包括一个名称和对用例事件流中一个或多个位置的引用•在电话系统中,为用户提供的主要服务通过用例“打电话”来表示。

可选服务的示例包括–能让第三方加入通话(召开电话会议)–允许接收方看到呼叫方的身份(显示呼叫方身份)•我们可以将这些可选服务所需的行为表示为基本用例“打电话”的扩展用例,由于“打电话”本身就具有意义,您无需阅读扩展用例的说明就可理解基本用例的主要目的C al ler CalleePlae Conference Call Show Caller IdentifyPlace Call <<extend>><<extend>>扩展关系的实例用例之间的包含关系•包含关系的双方分别叫做基本用例(Basic use case)(或具体用例, concrete use case)和包含用例(included use case)(或抽象用例, abstract use case)•包含用例用来模型化基本用例中–多个用例都包含的路径–复杂的路径–包含用例要能生成一个有意义的结果•包含关系用stereotype是“include”的association关系来表示<<include>>bas ic us e cas e included us e cas e用例之间的包含关系(续)•基本用例和包含用例–包含用例不能单独执行,必须与包括(也就是执行)它的基本用例一起执行–包含用例没有特定的actor,它的actor实际上包括它的基本用例的actor–包含用例可以被几个其他的用例复用–基本用例的基本流执行时,包含用例一定执行Withdraw Cas hTrans fer Funds Dopos it Cas h Identify Cus tomer<<include>><<include>><<include>>包含关系的实例•在ATM 系统中,用例Withdraw Cash 、Deposit Cash 和Transfer Funds 都需要包含系统识别客户的过程。

可以将此行为抽取到一个名为Identify Customer 的新包含用例中•从基本用例的角度来看,识别客户方法是读取银行磁卡还是执行视网膜扫描并不重要。

它们仅依赖于Identify Customer 的结果,即客户的身份。

•从Identify Customer 用例的角度来看,基本用例如何使用客户身份或者在执行包含用例之前基本用例中发生了什么并不重要:识别方法都会完全相同扩展关系和包含关系•共同点–扩展用例和包含用例都是基本用例的一部分–基本用例不执行,扩展用例和包含用例都不会执行–扩展用例可以扩展多个基本用例;包含用例可以被多个基本用例包含•区别–扩展关系中基本用例的基本流执行时,扩展用例不一定执行,即扩展用例只有在基本用例满足某种条件的时候才会执行–包含关系中基本用例的基本流执行时,包含用例一定会执行练习•画出ATM自动取款机的用例图小结•角色、用例、用例图•扩展用例、包含用例练习术语用例图Use case diagram Use case diagram 用例Use Case Use Case 角色Actor Actor解释英文全称缩语、术语。

相关文档
最新文档