系统分析师UML项目实战
1. UML项目现场
只有平庸的人,才会提出复杂的解决方案
UML建模顺序: 流程建模 -> 用例建模 ->领域建模
活动图,用例图,类图的图标名称介绍.
2. 业务流程建模
业务流程定义:
- 特定的客户
- 特定的目标
- 特定的服务
对于不重要的工作,不做活动图
表2-1 活动图用于表示业务流程或系统流程
| 项目\活动图 | 业务流程 | 系统流程 |
|---|---|---|
| 主要作用 | 表示企业组织的未来流程 | 表示系统内部的系统流程 |
| 人工操作 | 可能出现人工操作 | 不会出现人工操作 |
| 生成机时 | 需求分析阶段 | 系统设计时间 |
| 相关文件 | 收录在系统需求的规格书(SRS) | 收录在系统设计规格书(SDS) |
| 绘制者 | 系统分析师 | 系统设计师 |
| 观看者 | 客户/用户(系统设计师也会参考使用) | 程序设计师 |
| 粒度 | 一张活动图对应多个用例(即将用例视为黑箱) | 一张活动图对应一个用例(即将用例视为白盒) |
表2-2 于系统设计时间的活动图和顺序图
| 项目/图类型 | 活动图(系统流程) | 顺序图(对象互动) |
|---|---|---|
| 主要作用 | 表示系统内部的系统流程 | 表示系统内部的对象互动 |
| 主要特色 | 凸显流程与控制节点 | 凸显对象依序调用方法或函数 |
| 生成时机 | 高级的系统设计时间 | 细部的系统设计时间 |
| 相关文件 | 收录在系统设计规格书(SDS) | 同左 |
| 实作情况 | 无法直接对应程序代码 | 可以直接对应程序代码(有些UML工具可以自动产码) |
| 绘制者 | 系统设计师 | 同左 |
| 观看者 | 程序设计师 | 同左 |
| 粒度 | 一张活动图对应一个用例(即将用例视为白箱) | 同左 |
活动图图标:
- 起始节点: 实心小圆 (建议一个活动图 一个起始节点)
- 活动终点: 双圆,内实外空
- 判断节点: 空心菱形
动作: 圆角矩形 动作粒度要与用例粒度相近
4.1 第一行: (一个动作负责人)
4.2 第二行: 动作名称,动词开头
- 合并节点: 空心菱形
- 活动: 圆角矩形,右下角三叉图标 (活动可拆分外令一个活动图 )
- 分叉与会合: 粗线段 (等所有条件具备进行下一阶段 建议分叉与会合成对出现)
- 对象节点: 矩形 (代表流入/流出的数据项)
3. 用例建模
用例来源:
- 业务流程
- 功能流程
- 其他用例
建议同时生成用例图和功能架构图.
用例图作用:
- 规范一套动作
- 明确结果
- 表明参与者 (参与者包括主要参与者(启动者)和次要参与者)
业务流程导出初版用例
- 查看动作,动作负责人即为参与者,动作即为用例
- 查看判断节点,判断判断节点是否需要其他用例支持
功能划分->业务流程->初版用例->功能架构->用例图->用例描述
用例描述:
- 前置条件: 执行流程前必须要满足的条件
- 主要流程: 一般正常的流程 (主要详细分为参与者输入,系统处理过程,及输出,要求非常详细!)
- 替换流程: 特殊情况 (替换流程的编号,紧跟发生特殊情况的主要流程编号)
- 后置条件: 必须要完成的结果
包含关系与扩展关系
包含关系:
<<include>>虚线箭头指向被包含 被包含可视为前置条件1.1 被包含的小用例无法脱离基础用例而单独存在
1.2 基础用例一定执行被包含的小用例
1.3 两者加起来是一条流程
扩展关系:
<<extends>>虚线箭头直线被扩展 扩展可不执行 ,可视为替换流程2.1 拓展的小用例无法脱离基础用例而单独存在
2.2 基础用例不一定执行拓展的小用例
2.3 两者加起来是两条流程,其一是单独的基础用例,其二是基础用例外加拓展用例
4. 领域建模
领域模型:
- 一种概念模型,呈现问题领域中的重要概念
- 描述问题领域中的实体,实体属性,操作,角色,关系和限制.
- 对于用例所描述的互动过程,领域模型可以为用例起支持结构作用.
- 通常用类图描述领域模型.
- 领域模式可用于出代码
类图:
- 类用矩形表示,第一行为名称,第二行为属性,第三行为操作
- 属性 属性名称:数据类型=初始值
- 操作 操作名称(参数,数据类型):返回值数据类型
结合关系: 实线 表示两个领域存在重要且需要永久保存的静态关系
4.1 单向结合 无法从目标端找回来源端
4.2 双向结合
4.3 聚合关系 空心菱形 指向聚合类 整体-部分
4.4 组合关系 实心菱形 组合关系具有聚合关系的所有特性另加部分对象只会链接到一个整体对象,不允许数个整体对象共用一个部分对象,部分对象跟随整体对象的存活.
4.3 个体数目 下限..上限 表明关系:一对一,一对多,多对多.多对一.
用例描述推导领域模型
- 查看用例描述,把其中的数据项归到领域中.
- 类代表领域,数据项代表属性
- 查看概念之间的关系
- 根据关系在两端添加数量
领域模型呈现业务规则
- 通过结合关系和个体数目来表达关系静态结构的业务规则
- 通过操作来表达计算公司以及一些需要查验或检核的业务规则
5. 模型走读
作用:检测模型质量
走读功能架构图与用例图
- 是否可以从功能架构图追溯到用例图 (最好情况: 直接采用用例作为功能架构图中的功能)
- 检测功能架构图中的系统,功能模块,用例名称是否和用例图一致
- 若功能模块和底下的功能模块与客户的征求建议书(RFP)不一致,则需请求客户同意,看功能模块的切割、名称、地下的功能归属是否恰当.
走读中遇到的问题及其解决方案:
- 出现多个用例参与一个用例入口 解决:用例图中参与者第二行标明{or }
走读用例图和用例描述
- 检测参与者是否摆在系统方框之外,在系统方框和功能模块方框最上方要用标注<\<系统>>或<\<功能模块>>
- 用例描述每一个步骤都以参与者或系统开头
界面雏形工具: Pencil
走读用例描述与领域模型
- 主要查看是否遗漏数据项(属性)、业务规则和重要操作
善用对象图
对象图是系统的快照,可表示某一时刻或某一场景系统内有哪些重要对象,属性的数值以及他们之间的关系.
在绘制对象图,想好场景,一边套场景,一边通过对象图走读领域模型
用对象图发现用例描述某一动作不能执行, 解决方案 增加用例辅助完成.
领域模式描述:
领域模式主要通过文字记录类别、属性、结合、限制的定义或解释、操作
6. 继续走读
走读中做了几个调整.
1.整合应整合用例(自动汇整集锦交易与自动申购基金)
非功能性需求可以添加到用例描述中或建立单独一个表格供整个系统参考.
走读领域,可搭配情景对象图.这个很重要,其实在做系统测试时候,完全可以按照这个来.
7. 基金系统范例
以功能模块拆分用例图.
主要把前面章节的图 汇总在一起.
总结
第四章的结合实例来说领域模型很精彩
重复地方很多,有利有弊.
对于整个系统流程来说,算是不错的体验.能够让读者大概明白UML的大概过程,每一步应该做什么.然后循环迭代.这和敏捷开发的思想很像.