用例-UML

合集下载

uml的用例模型

uml的用例模型

UML(Unified Modeling Language)统一建模语言是一种用于对软件密集系统进行可视化建模的标准化建模语言。

用例模型是UML中的一个重要概念,主要用于描述系统的功能需求和行为。

用例模型主要由三个部分组成:参与者(Actor)、用例(Use Case)和它们之间的关系。

参与者(Actor):参与者是与系统进行交互的用户或其他系统,可以是外部实体或内部实体。

用例(Use Case):用例描述了系统执行的功能,即参与者与系统之间的交互行为。

一个用例通常描述了一个单一的功能或业务过程。

关系:关系描述了参与者与用例之间的交互,包括关联(Association)、泛化(Generalization)和依赖(Dependency)等。

在构建用例模型时,通常首先识别参与者,然后确定系统的功能需求,为每个功能需求创建一个用例。

接着,通过添加关系来描述参与者与用例之间的交互。

用例模型的主要目的是帮助开发人员理解系统的功能需求和行为,以便更好地设计和实现系统。

通过用例模型,开发人员可以更好地理解系统的边界、参与者与系统的交互以及系统的功能需求,从而更好地进行系统设计和开发。

UML用例和用例图

UML用例和用例图

h
18
主要内容
基本概念:Use case、Actor、
Scenario Use case间的关系 Use Case 分析技术 案例讲解
h
19
关系
• 参与者与用例之间
– 关联关系
• 用例与用例之间
– 包含关系 (include) – 扩展关系 (extend) – 泛化关系 (generalization)
• 主事件流: • 1、系统显示ID和密码窗口; • 2、顾客键入ID和密码,然后按OK键; • 3、系统验证顾客ID和密码,并显示个人信息窗口; • 4、顾客键入姓名、街道地址、城市、邮政编码、电话号码,然
后按OK键; • 5、系统验证用户是否为老顾客; • 6、系统显示可以卖的商品列表; • 7、顾客在准备购买的商品图片上单击,并在图片旁边输入要购
• 用例结束后的系统状态
• 其他需要描述的内容
用例描述原则:尽可能写的“充分”,而不是追求写的形 式化、完整或漂亮。
h
32
h
33
书写用例文档
——路径交互步骤的描述
只书写“可观测”的 使用主动语句 句子必须以执行者或系统作为主语 每一句都要朝目标迈进 分支和循环 不要涉及界面细节
h
34
书写用例文档
买的数量。选购商品完毕后按Done按钮; • 8、系统通过库存系统验证要购买的商品是否有足够库存; • …….(后续描述省略)
问题:对用户界面的描述过于详细,对于需求文档来说, 详细的用户描述对获取需求并无帮助。
h
45
改进后的描述
• Use Case:Buy Something • 参与者:Customer • 主事件流: • 1、顾客使用ID和密码进入系统; • 2、系统验证顾客身份; • 3、顾客提供姓名、地址、电话号码; • 4、系统验证顾客是否为老顾客; • 5、顾客选择要购买的商品和数量; • 6、系统通过库存系统验证要购买的商品是否有足

第四章 用例图-UML面向对象分析、建模与设计-吕云翔-清华大学出版社

第四章 用例图-UML面向对象分析、建模与设计-吕云翔-清华大学出版社
定是否要中断基用例的执行从而执行扩展用例中的片段。
依赖关系
特性 作用 执行过程 对基用例的要求
include
extend
增强基用例的行为
增强基用例的行为
包含用例一定会执行
扩展用例可能被执行
在没有包含用例的情况下,在没有扩展用例的情况下, 基用例可以是也可以不是 基用例一定是良构的 良构的
表示法
箭头指向包含用例
是用例的重要服务对象,而次参与者处于一
种协作地位。
系统管理员
用例与参与者
在确定用例时可以通过参与者入手来寻找用例:
参与者的主要任务是什么? 参与者需要系统的什么信息? 参与者可以为系统提供什么信息? 系统需要通知参与者发生的变化和事件吗? 参与者需要通知系统发生的变化和事件吗?
用例的特征
用例的特征保证用例能够正确地捕捉功能性需求,同时也是判断用 例是否准确的依据。
不改变基用例的同时,根据需要自由地向用
例中添加行为。
检查实名信息
依赖关系——扩展
扩展用例的使用包括四个部分:
基用例:需要被扩展的用例,如图5-10中的“注册”用例。 扩展用例:提供所添加的行为序列的用例,如图5-10中的“检查实名信
息”用例。 扩展关系:使用虚线箭头表示,箭头指向基用例。 扩展点:基用例中的一个或多个位置,表示在该位置会根据某条件来决
一个父参与者的直接实例,这就要求属于抽象父
直接客户
电话客户
参与者的外部对象一定能够属于其子参与者之一。
网上客户
用例的概念 用例与参与者 用例的特征 用例的粒度
用例
用例的概念
用例是类元提供的一个内聚的的功能单元,表明系统与 一个或多个参与者之间信息交换的顺序,也表明了系统 执行的动作。

UML用例图描述

UML用例图描述
用例“系统管理员登录”的描述
用例名称
系统管理员登录
标识符001用Fra bibliotek描述系统管理员通过设置的用户名和密码登录到学生管理系统
参与者
系统管理员
优先级
1
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
如果管理员登录成功,则可以对学生基本信息进行管理,包括录入,删除,修改,查询学生基本信息,并且可修改自己的密码;如果管理员登录不成功,则不能对学生基本信息进行操作。
2.系统管理员无用户名先进行注册,再输入正确的用户名和密码顺利登录,并对学生基本信息进行操作
3.系统管理员忘记用户名和密码,通过手机动态密码进行验证,找回密码,再输入正确的用户名和密码顺利登录,并对学生基本信息进行操作
被泛化的用例

被包含的用例
查学生基本信息
被扩展的用例

用例“查学生基本信息”的描述
基本操作流程
1.系统管理员进入学生管理系统
2.系统管理员输入用户名和密码
3.系统管理员提交输入信息
4.系统对系统管理员输入的用户名和密码进行有效性检查
5.系统管理员对学生基本信息进行操作
可选操作流程
1.系统管理员输入正确的用户名和验证码,错误的密码无法顺利登录,重新输入正确的用户名和密码顺利登录,并对学生基本信息进行操作
用例名称
查学生基本信息
标识符
002
用例描述
系统管理员输入要查看的学生的基本信息,系统显示该学生的详细信息
参与者
系统管理员
优先级
2
状态
等待审查
前置条件
学生管理系统正常运行
后置条件
系统管理员输入学生的基本信息,可查看学生的详细信息

UML用例图的基本概念

UML用例图的基本概念
UML通过统一的符号和图形表示,将复杂的软件系统分解为 更小、更易于理解的组件,帮助开发人员更好地理解和管理 复杂的软件系统。
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求,通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计,通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一:简单登录系统用例图分析
总结词:简单明了
详细描述:简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中,可以清晰地表示出系统的主要功能和参与者的角色。
案例二:网上购物系统用例图分析
总结词:复杂多样
详细描述:网上购物系统涉及到多个参与者,如顾客、管理员和供应商等,以及多种复杂的业务功能,如商品展示、购物车 管理、订单处理和支付等。在UML用例图中,需要对各个功能进行详细的描述和分类,以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计,通过分析用例之间 的关系和交互,设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口,明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程,通 过分析用例的执行顺序和交互逻辑, 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示,可以作为沟通 工具,帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图,可以与利益相关者讨论和确认 系统的需求,确保对需求的理解和期望是一致的。

UML之用例图详解

UML之用例图详解

UML之⽤例图详解原⽂链接:https:///mj_ww/article/details/53020080 UML,即Unified Model Language,统⼀建模语⾔。

百度百科对他的定义是:它是⼀个⽀持模型化和软件系统开发的图形化语⾔,为软件开发的所有阶段提供模型化和可视化⽀持,包括由到规格,到构造和配置。

作为⼀个软件⼯程师,很多技能并不⼀定说⾮得具备,但是,⼀旦我们具备了,很多时候机会总是会多那么⼀点点。

对于⽤例图来说我们需要了解的是什么叫⽤例图,构成⽤例图的要素,⽤例图有哪些重要的元素,各个⽤例之间的关系。

当然最重要的是如何根据需求创建⽤例图。

具体的创建通过⼀个简单的学⽣管理的例⼦说明创建的过程和例⼦。

我的所有例⼦都是是使⽤Rose这个软件来画的,现在虽然有新的UML模型画图软件,但是我⽐较喜欢⽤这个Rose,如果你还没有装这个软件需要先装⼀个,或者使⽤你⽐较喜欢的UML画图软件。

下⾯我们直接进⼊正题吧,学习⼀下⽤例图的相关概念和具体的创建过程。

什么叫⽤例图1. ⽤例图的含义 由参与者(Actor)、⽤例(Use Case)以及它们之间的关系构成的⽤于描述系统功能的动态视图称为⽤例图。

要在⽤例图上显⽰某个⽤例,可绘制⼀个椭圆,然后将⽤例的名称放在椭圆的中⼼或椭圆下⾯的中间位置。

要在⽤例图上绘制⼀个参与者(表⽰⼀个系统⽤户),可绘制⼀个⼈形符号。

参与者和⽤例之间的关系使⽤带箭头或者不带箭头的线段来描述,箭头表⽰在这⼀关系中哪⼀⽅是对话的主动发起者,箭头所指⽅是对话的被动接受者。

在⽤例建模中,为了更加清楚的描述⽤例或者参与者,会使⽤到注释。

2. ⽤例图的作⽤ ⽤例图是需求分析中的产物,主要作⽤是描述参与者和⽤例之间的关系,帮助开发⼈员可视化的了解系统的功能。

借助于⽤例图,系统⽤户、系统分析⼈员、系统设计⼈员、领域专家能够以可视化的⽅式对问题进⾏探讨,减少了⼤量交流上的障碍,便于对问题达成共识。

UML用例图和需求分析的关系深度解析

UML用例图和需求分析的关系深度解析

UML用例图和需求分析的关系深度解析需求分析是软件开发过程中至关重要的一环,它的目的是明确和理解用户的需求,为软件设计和开发提供指导。

而UML(统一建模语言)用例图则是一种常用的需求分析工具,它能够帮助开发团队更好地理解用户需求,并将其转化为可执行的软件功能。

本文将深度解析UML用例图与需求分析之间的关系,探讨其在软件开发中的作用和应用。

首先,我们需要了解UML用例图的基本概念和结构。

UML用例图是一种图形化工具,用于描述系统与外部参与者之间的交互。

它由参与者(actors)和用例(use cases)两个主要元素组成。

参与者代表系统的外部用户、其他系统或设备,用例则表示系统所提供的功能或服务。

用例图通过参与者和用例之间的关系,展示了系统的功能和用户之间的交互过程。

在需求分析过程中,UML用例图起到了至关重要的作用。

首先,用例图帮助分析人员更好地理解用户需求。

通过与用户沟通和交流,分析人员能够识别出系统的参与者和用例,并将其绘制成用例图。

用例图能够直观地展示系统与用户之间的交互过程,帮助分析人员更好地理解用户的需求和期望。

其次,用例图能够帮助开发团队明确系统的功能和边界。

通过绘制用例图,开发团队可以清晰地了解系统提供的功能和服务,并确定系统的边界。

用例图可以帮助开发团队明确系统的功能范围,避免功能的重复或缺失,从而提高开发效率和软件质量。

此外,用例图还能够帮助开发团队进行系统的需求验证和验证。

通过用例图,开发团队可以将用户需求转化为可执行的软件功能,并进行需求验证和验证。

用例图能够帮助开发团队检查和验证系统的功能是否满足用户需求,以及系统的交互过程是否符合用户的期望。

通过用例图,开发团队可以及时发现和修复需求中的问题,提高软件的质量和用户满意度。

此外,用例图还能够帮助开发团队进行系统的需求管理和变更控制。

在软件开发过程中,用户需求往往会发生变化。

通过用例图,开发团队可以及时发现和识别需求的变化,并进行相应的管理和控制。

面向对象系统分析与设计-UML基础-用例图

面向对象系统分析与设计-UML基础-用例图

27
参与者
参与者(Actor)是指处于系统边界之外的,与系 统发生交互作用的外部用户、设备或其他系统。在系 统的实际运作中,一个实际用户可能对应系统的多个 参与者。不同的用户也可以只对应于一个参与者,从 而代表同一参与者的不同实例。在处理参与者时,重 要的是角色,而不是人的职务等属性。
28
关系
用例除了与参与者有联系以外,用例之 间还存在着一定的关系。参与者之间还存有 关系。关系类型包括:
25
用例图的图形符号
图形符号
名称
用例
角色(参与者)
网上商店客户
关联关系
描述
26
用例
用例(Use Case)是对系统的用户需求(主要是功能 需求)的描述。用例也称案例,用况等。
(1)用例是指一个或多个参与者为达到某个目的与 要设计的系统进行的典型交互作用。
(2)用例表达了系统的功能,即系统提供的服务。
面向对象系统 分析与设计方法
——UML基础
主要内容
面向对象的主要概念 UML相关概念 UML模型 UML的扩展
2
面向对象基本概念——对象
1.定义: 对象(Object)是系统中一个用来描述客观事物的实
体。 2.特征:
对象具有自己的静态特征和动态特征。 其中:
静态特征是对象自身所要维护的信息,称为属 性,可用值来描述;
23
用例图
用例图(Use Case Diagrams)是显示一组用例、 参与者,以及它们之间关系的图。用于描述系统的 功能集。用例图是其它模型的核心和基础。
但是,用例图只能静态地描述系统功能,为了 描述系统的行为,可以使用活动图、顺序图等。
24
用例图
用例图(Use Case Diagrams)是显示一组用例、参与者 ,以及它们之间关系的图。用例图用来描述用户的功能需 求。用例图一般由参与者和用例构成。

UML学习(一)-----用例图

UML学习(一)-----用例图

UML学习(⼀)-----⽤例图1、什么是⽤例图 ⽤例图源于Jacobson的OOSE⽅法,⽤例图是需求分析的产物,描述了系统的参与者与系统进⾏交互的功能,是参与者所能观察和使⽤到的系统功能的模型图。

它的主要⽬的就是帮助开发团队以⼀种可视化的⽅式理解系统的功能需求,包括基于基本流程的“⾓⾊”关系以及系统各个功能之间的关系。

它通过⽤例(Use Case)来捕获系统的需求,再结合参与者(Actor)进⾏系统功能需求的分析和设计。

2、⽤例图的组成 ⽤例图有四部分组成:⽤例(Use Case)、参与者(Actor)、系统边界、关联2.1 参与者 在⼀个系统开发前,我们必定⾸先要确定系统的⽤户,系统的⽤户就是系统的参与者。

除此以外,我们还会想打,我们开发的系统与其他的系统有什么关联?因此,系统的参与者可分为两类,⼀类是⼈,包括系统的使⽤者、维护者等,另外⼀类是其他系统。

2.2 ⽤例 ⽤例(Use Case)是参与者(Actor)可以感受到的系统服务或功能单元。

任何⽤例都不能在缺少参与者的情况下独⽴存在。

同样,任何参与者也必须要有与之关联的⽤例,所以识别⽤例的最好⽅法就是从分析系统参与者开始,在这个过程中往往会发现新的参与者。

⽤例是有粒度的,⽤例的粒度指的是⽤例所包含的系统服务或功能单元的多少。

⽤例的粒度越⼤,⽤例包含的功能越多,反之则包含的功能越少。

2.3 系统边界 所谓系统边界是指系统与系统之间的界限。

把系统边界以外的同系统相关联的其他部分称之为系统环境。

2.4 关联 为了减少模型维护的⼯作量、保证⽤例模型的可维护性和⼀致性,可以在⽤例之间抽象出包含(Include)、扩展(Extend)和泛化(Generalization)这⼏种关系 包含关系是指⽤例可以简单地包含其他⽤例具有的⾏为,并把它所包含的⽤例⾏为作为⾃⾝⾏为的⼀部分。

扩展关系是指在⼀定条件下,把新的⾏为加⼊到已有的⽤例中,获得的新⽤例称为扩展⽤例(Extension),原有的⽤例称为基础⽤例(Base)。

UML用例图介绍

UML用例图介绍

UML用例图介绍目录1、UML用例图概述 (1)2、用例图怎么使用? (1)3、UML用例图的目的 (2)4、如何画用例图? (3)1、UML用例图概述用例图捕捉了模拟系统中的动态行为,并且描述了用户、需求以及系统功能单元之间的关系。

用例图展示了一个外部用户能够观察到的系统功能模型图。

用例图由主角,用例和它们之间的关系组成。

2、用例图怎么使用?要了解一个系统的动态,我们需要使用不同类型的图表。

用例图就是其中之一,其具体目的是收集系统的的需求和参与者。

用例图指定系统的事件和他们的流向。

但从未用例图描述了他们是如何实现的。

可以被想象成一个黑盒子,只有输入,输出和黑盒子的功能被称为用例图。

在这些图中使用的设计在一个非常高的水平。

那么这种高层次的设计高雅,一遍又一遍完善使系统得到一个完整实用的图片。

一个结构良好的用例,还介绍了前置条件,后置条件和例外。

而这些多余的元素在执行测试时被用来制造测试的情况下。

用例都不是正向和反向工程,但他们仍然使用略有不同的方式。

同样是真实的逆向工程。

仍用例图的使用方式不同,使其逆向工程的一个候选。

在正向工程用例图是用来做测试案例和逆向工程中的使用情况下是用来准备从现有的应用程序的需求细节。

所以下面的地方使用用例图:2.1.需求分析和高水平的设计。

2.2.模拟系统的上下文。

2.3.逆向工程。

2.4.Forward engineering.3、UML用例图的目的用例图的目的是捕捉到一个系统的动态方面。

用例图是用来收集系统的要求,包括内部和外部的影响。

这些要求大多是设计要求。

所以,分析一个系统时要收集其功能用例和确定参与者。

简单来说,用例图的目的如下:3.1.用例图用来收集系统的要求。

3.2.用例图用于获取系统的外观图。

3.3.用例图识别外部和内部因素影响系统。

3.4.用例图显示要求之间的相互作用是参与者。

4、如何画用例图?用例图被认为是高层次的需求分析系统。

因此,当系统的要求,分析被捕获在用例的功能。

UML用例图模板

UML用例图模板

UML用例图模板定期存款存款业务员ULM用例图1、UC1用例名称:查看客户资料⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流1)基本流12)基本流1[把所有的基本流列出来]★备件流1)基本流12)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景1)成功场景12)成功场景2★失败场景1)失败场景12)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]2、UC2用例名称:活期存款⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流3)基本流14)基本流1 [把所有的基本流列出来]★备件流3)基本流14)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景3)成功场景14)成功场景2★失败场景3)失败场景14)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]。

uml用例描述

uml用例描述

uml用例描述在软件开发过程中,用例是一种用来描述系统功能和用户需求的工具。

UML(Unified Modeling Language)是一种常用的建模语言,其中用例图是用来描述系统功能和行为的图形表示方法。

本文将使用UML用例图的描述方式,来介绍一个名为“在线购物系统”的软件系统。

1. 引言在线购物系统是一个电子商务平台,为用户提供了在线购买商品的功能。

本系统的主要参与者包括注册用户、游客和管理员。

注册用户可以浏览商品、添加商品到购物车、下单购买商品等;游客可以浏览商品,但无法添加商品到购物车或下单购买;管理员负责管理商品信息和用户信息。

2. 用例图下面是“在线购物系统”的用例图:- 注册用户用例:注册用户可以执行的操作包括浏览商品、搜索商品、添加商品到购物车、下单购买商品、查看订单状态和评价商品。

- 游客用例:游客可以执行的操作包括浏览商品、搜索商品和查看商品详情。

- 管理员用例:管理员可以执行的操作包括添加商品、编辑商品信息、删除商品、管理用户信息和查看订单信息。

3. 详细描述3.1 注册用户用例- 浏览商品:注册用户可以浏览系统中的商品列表,查看商品的基本信息和价格。

- 搜索商品:注册用户可以根据关键词搜索系统中的商品,系统会返回符合条件的商品列表。

- 添加商品到购物车:注册用户可以将感兴趣的商品添加到购物车中,以便稍后进行结算。

- 下单购买商品:注册用户可以选择购物车中的商品,生成订单并进行支付。

- 查看订单状态:注册用户可以查看自己的订单状态,包括待支付、待发货、已发货等。

- 评价商品:注册用户可以给已购买的商品进行评价,以供其他用户参考。

3.2 游客用例- 浏览商品:游客可以浏览系统中的商品列表,查看商品的基本信息和价格。

- 搜索商品:游客可以根据关键词搜索系统中的商品,系统会返回符合条件的商品列表。

- 查看商品详情:游客可以查看具体商品的详细信息,包括商品介绍、规格、用户评价等。

uml用例与用例之间的关系

uml用例与用例之间的关系

UML用例与用例之间的关系1. 引言在软件系统开发过程中,需求分析是一个至关重要的环节。

用例是一种常用的需求表示工具,用来描述系统与用户之间的交互过程。

用例图是一种在统一建模语言(UML)中常用的图形化表示工具,它能够清晰地描述不同角色之间的交互以及系统的功能。

在用例图中,用例之间存在着不同的关系,这些关系能够帮助我们更好地理解和分析需求,从而有助于正确地设计系统。

2. 用例与用例之间的关系用例与用例之间的关系主要体现在用例图中的连接关系,以下是用例与用例之间可能存在的几种关系:2.1 包含关系(include)包含关系描述了一个用例(被包含用例)在执行过程中调用了另一个用例(包含用例)的场景。

被包含用例是包含用例的一部分,它们之间有一个可选的包含关系,即被包含用例可以选择是否执行包含用例。

包含关系在用例图中用带箭头的虚线表示。

举例来说,如果一个系统中有一个支付用例和一个生成订单用例,那么支付用例可以调用生成订单用例来创建订单。

但是在某些情况下,比如采用现金支付时,生成订单用例就可以不执行,所以这个关系是可选的。

2.2 扩展关系(extend)扩展关系描述了一个用例(扩展用例)在某个基本场景(基础用例)的执行过程中可以选择性地插入另一个场景(扩展用例)。

扩展关系使得系统的功能可以按需进行扩展,而不会影响基础用例的执行。

扩展关系在用例图中用带箭头的虚线表示。

以在线购物系统为例,基础用例是购物,而扩展用例可以是添加到购物车、查看商品详情等。

这些扩展用例可以根据用户的需求来选择性地应用,从而实现购物功能的扩展。

2.3 泛化关系(generalization)泛化关系描述了一个用例(子用例)继承了另一个用例(父用例)的属性和行为。

子用例可以复用父用例的功能,并在其基础上进行扩展或修改。

泛化关系在用例图中用带空心箭头的实线表示。

例如,一个系统有多种角色,比如管理员和普通用户,它们都可以登录系统,所以可以有一个登录用例作为父用例,而管理员登录和普通用户登录可以作为子用例,从而实现用例的复用。

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

产品需求文档的写作(五) – 用例文档(UML用例图、流程图)

在产品和技术领域里都有UML的技能知识,而对于产品人员的UML则更多的是指用例图,也就是我所称呼的用户流程图。

在讲PRD文档写作的第二篇文章里,我提到了用户流程图的制作,实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式,由于以结构化的方式描述用例太抽象,缺少逻辑性表达,并且那篇文章更偏向于功能性用户流程,还不是实际意义上的用例,因此今天我补文一篇,细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档,主要用于技术开发与测试使用,他是PRD中的重要辅助文档,用于讲解某个环节的功能逻辑,例如用户注册、活动报名等等功能都是需要用例辅助说明的。

用例文档的写作时间在原型设计之后,通常和PRD文档同步撰写。

用例文档中有两个关联文件,分别是用例图和流程图。

用例图是UML的一种类图表现方式,是从用户角度描述产品功能,并指出该用户在产品各功能中的操作权限。

流程图是通过线框图形的方式描述产品功能的处理过程,主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word,其中用例图和流程图的制作软件常用的是Visio,当然也有用Axure RP软件制作的,例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成,其中第3点的“用例”是描述功能逻辑的部分,根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下:1、修改记录:每次修改的备注记录,同PRD文档。

2、角色介绍:描述参与系统中的各个角色3、用例:同下方步骤的第4步,其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容,通过Word文档绘制表格,在表格中撰写用例描述,表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。

(如下图)2、第二步是以用例图的方式注明角色在前后端的用例关系。

uml用例图笔记

uml用例图笔记

UML 用例图
用例图包含6个元素:
1.
参与者(Actor ) 2.
用例(Use Case)即一个动作; 3.
关联关系(Association ) 4.
包含关系(Include ) 5.
扩展关系(Extend ) 6. 泛化关系(Generalization )
用例之间的关系包括包含关系、扩展关系、泛化关系。

1、关联关系
参与者与用例的关系
2、包含关系
若用例A 包含用例B ,执行A 肯定是要执行B 的(路径正常情况下)箭头指向子B 动作
例:若要网上订购则肯定需要填写电子表格
3、扩展关系
若用例A 在某个条件下执行用例B 的动作
则用例A 扩展用例B
若用例A 和用例B 是泛化关系(箭头指向A )
例:在还车时只有在超出期限时才需要交纳罚金
4、泛化关系
若AB 是泛化关系,则A 是父代B 是子代。

B 继承了A 的所有动作。

例:电话预订酒店和网上预订酒店是在订酒店的子类;其中前两者肯定继承了订酒店的所有动作;
注释:
包含和扩展都是用虚线和箭头表示,两者用extend 和include 来区分;泛化是用三角形箭头和实现表示;
参与者之间也有泛化的关系(即父子关系);。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

用例Use Case(用例)是一个UML中非常重要的概念,在使用UML的整个软件开发过程中,Use Case处于一个中心地位。

那么,到底什么是Use Case呢?在UML的文档中,Use Case的定义是:在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。

有点拗口,对吧?其实Use Case就是对系统功能的描述而已,不过一个Use Case描述的是整个系统功能的一部分,这一部分一定要是在逻辑上相对完整的功能流程。

(唔?Use Case也没什么特别的嘛!怎么这玩意儿会在开发中处于一个中心地位呢?)在使用UML的开发过程中,需求是用Use Case来表达的,界面是在Use Case的辅助下设计的,很多类是根据Use Case来发现的,测试实例是根据Use Case来生成的,包括整个开发的管理和任务分配,也是依据Use Case来组织的。

啊,Use Case,简直太重要了!好了,Use Case就吹到这儿,具体的使用还要在实践中去体会,“运用之妙,存乎一心”也!对于每个Actor来说,他都要使用系统的某项功能,所以我们识别和分析Use Case是,要对于每个Actor来逐个进行。

对于ToDo User,我们可以轻易的识别出两个Use Case:Add Task 和Remove Task。

ToDo User主动使用这两个Use Case所描述的系统功能,所以在我们的Use Case图上,ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。

对于FileSystem,我们识别出的也是同样的两个Use Case,不过这次箭头从Use Case指向FileSystem,表示FileSystem是被动的。

Use Case可以用很多方式来描述,我们可以用自然语言(英语,汉语,随您的便),可以用形式化语言(哇!太酷了吧!),也可以用各种图示。

在UML 中,通常用两种图来描述Use Case,它们就是顺序图(Sequence Diagram)和协作图(Collaboration Diagram)Use Case 由以下元素组成:名称简单描述事件流关系活动图和状态图Use Case 图特殊需求前条件后条件一、谈谈对use case有关术语翻译的看法。

笔者认为“用例”是目前较好的译法,这个词可能来源于大家熟知的“测试用例”。

有人认为把use case翻译成“用例”是错误的,理由是:“‘例’是被列举出来以说明某种情况的个别事物,use case是对一项系统功能使用情况的普遍适应的描述,而不是对个别actor或者在个别条件下使用这项功能才适应,它也不是通过举例的方式来描述的”,所以不能叫作“用例”。

此种说法不尽全面,而且有些牵强(先不管它正确与否),其实use case到底是个别的,还是群体的(普遍适应),取决于我们的视点。

虽然对于单个的scenario来说,use case是多个情节的叠加,是一个整体的复合概念,但是我们知道,一个系统的功能必定是可数的、有限的,而每一个功能都可以表示为一个use case,所以在观察系统提供的所有功能需求的集合这个层面上,use case又是一个一个可数的个体(“椭圆”),每一个都代表了不同的用户目标,适用于个别的actor和个别特定的前置条件。

同一个事物既是个体的又是整体的,这种现象并不足怪,例如在UML对象-类-类元关系中,通常对象是类的实例,而类又是类元的实例,对类元来说,类、接口、子系统、use case等等就是一个个个体的概念,类既是其对象实例的集合又是其类元集合的个别元素。

可见,把use case 的“case”译成“例”并没有错。

有的地方把use case翻译成“用况”,即“使用的情况”之意,意思的确不错(use case的另一种说法是“使用的方式”)!可我总感觉这个词比较突兀、拗口,类似的还有“用案”,把scenario叫作“案况”,大概这些词读起来不太符合大家的习惯(类似地,既然可以叫“用况”,为什么不能叫“用情”呢?),所以现在“用例”的叫法还是越来越多了。

其实“用例”这个译法还有个附带的好处,通过它我们很容易把原本就存在紧密联系的use case和test case(test case来自于对scenario的分析,而scenario是用例的一次执行)从中文名称上也方便地统一起来。

不过,这里我们需要做一个小小的改进。

中文的“测试用例”到底是指test case(带定语的名词词组)呢,还是指对用例进行测试(testing the use cases,动宾词组)呢?显然这两者不易分辨,而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中,常常会让人感觉嗦和便扭。

为了消除歧义,干脆以后把test case都叫做“测例”,这样不但比以前的叫法更加简洁明了,而且无论字面上还是语义上都很贴切。

当然,用例和测例是不同层面的“例”。

现在市面上Actor也有多种译法,常见的包括“参与者、执行者、主角”等等。

“参与者、执行者”的问题主要是不准确。

首先,“参与者”通常让大家马上想到的词是participant,而且请注意,一个用例的真正参与者决不是只有外部的Actor,它们必然还包括系统本身及其内部的各种元素。

“执行者”的问题与此类似:一个用例的真正执行者应该是系统本身!因此严格地讲这样译是错误的,兴许叫作“外部参与者”、“外部执行者”才更为恰当。

“主角”的译法同样存在着矛盾。

如果把Actor叫作“主角”,那么Primary Actor就应该叫作“主主角”了。

看来Actor的译法中是不能含有“主”的,那么就剩下“角”了,而UML已经有了一个专门术语role(角色),我们又不能把Actor直接叫作“角色”。

目前看来,把Actor意译成“使用者”是比较妥当的。

在大多数情况下Actor的的确确就是用户(确切地说是系统用户所扮演的一种角色),所以我们可以用“使用者”这个词从字面上与“用户”(user)进行区分,但同时又保持两者语义上的联系。

我们还可以把为系统服务的Supporting/Secondary Actor(见下文)叫做“被使用者”(为了简化可以省略“被”字)或“辅使用者”。

除了指系统的用户之外,“使用者”还有另一层含义,即Actor是use case的使用者(或被使用者),这种关系在UML用例图上应该可视化地表示为它们之间的连线(关联)。

这样解释不但说的通,而且更便于不熟悉软件技术的业务人员理解。

当然,我们也不排除将来会找到“use case”、“actor”等术语更好的译法。

二、USE CASE的来历Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。

二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。

他造了一个术语anvendningsfall,大意是“使用情况”(situation of usage)或用况(usage case)。

但当用英文出版的时候,他发现“useage case”在英语里说不通,所以写作用例“use case”三、创建USE CASE的原则用例是短文用例可以是一个场景,包括动作和互交。

用例可以是一组场景,描述不同场景下的行为。

这种书写格式可以在任何时候描述有变体的行为,例如黑盒需求,业务流程,系统设计说明。

用例里不要有系统设计用例里不要有界面设计用例里不要有特性列表用例里不要有测试用例应该描述行为需求用例的主场景不要超过九步。

可以在适当的层次上得到子目标和移除设计说明。

用例的最大价值不在于主场景,而是在于备选行为。

主场景可能只占用例长度的四分之一到十分之一。

四、Use Case 事件流Use Case具有一个基本事件流(可称为"理想路径")、多个例外流,包括:基本变化特殊情况处理错误情况的异常事件流五、Use Case 说明书Use Case 说明书应包括以下内容:功能描述可用性可靠性性能可支持性设计约束六、Use Cases将做成多大?试图决定Use Case的大小是一个很有趣的话题,处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来,对于一个真正大的范围来说,一个Use Case并不要在一个系统中处理那么多,但这些系统都用于同一商业领域,称为Business Use Case,它把整个公司看作一个黑盒和Actor关于公司目标的说明。

这些Business Use Case的场景不允许假定任何公司内部的结构,一个客户将向公司下一个定单而不是客户服务部门。

对于系统发展而言,Use Case的范围限制一个单一的系统,这是Use Cases最通常的形式,我们称之为System Use Case,它把整个系统看作是一个黑盒,它不指定任何内部结构并且仅受限于问题域的语言描述。

Use Cases的另一范围是设计子系统和系统内部组件的,称为Implementation Use Cases,它把组件看作一个黑盒,并且这些Actors是区分它的成员。

例如:可能会用Implementation Use Cases去说明应用系统中email组件的需求。

给出了这些分类,关于Use Case的大小话题变得容易了,设计这些项的范围来调整整个大小。

帮助系统设计者,每个Use Case只描述没有大的分支的行为的单个线索。

违背这个规定,Use Case看起来通常是不准确的或含糊的,作为测试说明的资源和参考,它也是很难使用的。

七、Use Cases的说明Use Cases的好处是一些情节能用不同程度的正规化的文字说明。

每个情节涉及Use Cases中单一的途径,细节是条件组。

不正规的文本描述也能使用,不过当条件较多和可能失败的情况下它们很难跟随下去。

开始试图理解需求时,不正规的叙述风格也是非常有用的,然而随着Use Cases的进展,使用更加正规的机制去说明Use Cases才是有用的。

下面是客户对Use Case“下定单”的粗略概略:“确定客户,找出需要的并且仓库里还有的物品并检查客户信用额是否够用”结构化叙述的格式已经被证明是非常有效的。

这个格式所做的事是描述每一个情节的行为者:目标语句对顺序的叙述。

在这个顺序中,每一个行为者:目标的语句对都假设前一个的目标是成功的,右面是一个简单的范例:Use Cases认为我们正在设计的系统是一个单一的黑盒,根本没有任何内部结构被记录下来,并且它被认为是一个情节产生的目的及对应单一的行为者(Actor)。

这些Use Cases没有表示任何关于系统内部的东东,只是表示系统将达到什么样的目标及由什么(人或其它系统)操作和负责。

相关文档
最新文档