一. 用例视图概述
用例视图表述哪些事物 :谁是相关用户,用户希望从系统获得的服务,用户需要为系统提供的服务.
用例视图的作用 : 使用户容易理解 其中元素的用途 , 使码农更容易实现这些元素.
软件产品外部特性 :软件功能的合理性,使用方便程度,UI界面;
用例视图角度 : 用例视图是从用户角度来描述软件产品的需求, 可以准确的描述软件产品的外部特性.
用例视图元素 :参与者,用例, 参与者 用例之间的关系(泛化, 包含, 扩展); 用例图还可以包含注解, 约束, 包.
二. 参与者
1. 参与者概念
定义 : 参与者是系统外部的实体, 参与了系统用例执行过程.
参与者与用例交互方式 : 参与者通过交换信息与用例发生交互.
参与者种类 :
a. 用户 : 真实的人, 这类参与者命名按照业务命名.
b. 其它系统 : 程序边界之外的系统, 例如 银行支付系统也是电商网站的参与者.
c. 进程 : 一些可以运行的进程也可以做参与者, 例如到某个时间触发某时间, 时间就是参与者.
2. 确定参与者
(1) 如何识别参与者
a. 系统使用者 : 使用系统的用户或者系统是参与者;
b. 交互中角色 : 在交互中参与者扮演的角色;
c. 系统安装者 : 安装这个系统的人也可能是参与者;
d. 系统启动者 : 开启关闭系统的人可能是参与者;
e. 系统维护者 : 维护这个系统的人可能是参与者;
f. 交互的系统 : 与该系统交互的系统可能是参与者;
g. 信息获取者 : 从系统获取信息的人可能是参与者;
h. 信息提供者 : 为系统提供信息的人可能是参与者;
i. 定时执行者 : 在固定时间执行某个用例.
(2) 参与者注意事项
a. 系统之外 : 参与者是系统外部的元素, 是不可控制的;
b. 系统边界 : 参与者同系统交互, 可以定义系统的边界;
c. 注重业务 : 参与者是人活着事务与系统发生交互时所扮演的角色, 而不是人或者事务, 例如 电商卖家登陆后台就是卖家, 登陆前台就是卖家, 注重业务而不是注重人.
d. 人多角色 : 一个人或事务可能扮演多个角色;
e. 业务命名 : 参与者命名是按照业务来命名的;
f. 业务描述 : 每个参与者必须有简短的描述, 从业务角度描述参与者是什么;
g. 属性方法 : 参与者也可以有属性和方法, 不常用;
3. 参与者之间关系
参与者之间有泛化关系, 就是接口与实现类之间的关系. 例如在OA系统中, 项目经理 客户经理 都是员工, 项目经理与员工之间的关系就是泛化关系.
三. 用例
1. 用例概述
用例概念 : 用例是对一个系统或一个应用的一种单一的使用方式所做的描述, 是关于单个活动者在与系统对话中所执行的处理行为的陈述序列(用例不是单一的动作, 是一系列的动作).
用例描述的事物 : 用例表示参与者使用系统完成某个事件时事情发生的序列, 用例是系统的使用过程, 展示和体现了其描述的过程中的需求情况.
2. 用例图表示
用例用椭圆表示, 名称可以写在椭圆的内部或者下方. 用例的名字包括简单名(simple) 和 路径名(path name), 简单明就是只写用例名, 路径名就是在用例名前加上其所属的包名.
3. 识别用例
从分析系统参与者开始, 考虑参与者怎样使用系统, 这样既可以分析用例, 又可以找出一个新的参与者, 对完善系统建模很有帮助.
用例建模就是这样迭代和逐步精华的过程, 这是属于系统分析师的职责.
识别用例的方法 :
a. 根据参与者 : 特定参与者希望系统提供的功能;
b. 根据系统行为 : 系统对数据库进行操作, 是哪个参与者通过什么用例触发;
c. 状态改变 : 系统状态改变的时候,是否通知参与者;
d. 外部事件 : 是否存在影响系统的外部事件;
e. 通知者 : 哪个参与者通知系统这些事件;
4. 用例与事件流
事件流产生原因 : 用于分析出息系统的需求分析阶段, 在这个阶段应该避免考虑系统实现的细节问题, 因此我们将用例的细节写在事件流文件中,事件流是用来描述用例的详细执行过程的;
事件流概念 : 事件流用来说明一个用例的具体的行为, 何时开始, 何时结束, 与参与者有什么交互.
事件流分类 :基本流,可选流; 基本流就是主事件流, 一个用例的正规流程没有任何意外就是主事件流, 如果中间出了一场, 那么就是可选事件流, 又叫异常事件流.
举例 : 用户登录
主事件流 : 参与者输入账号密码, 登陆开始,服务器判断密码是否正确, 密码正确, 进入系统;
异常事件流1 : 密码错误, 重新登陆;
异常事件流2 : 密码提交前用户清除密码, 重新填写.
5. 参与者与用例之间的关系
参与者与用例之间的关系是关联关系, 使用带箭头的实线表示关联关系, 例如 : OA系统客户登陆, 用户签到, 写文件, 审批文件.
