读书笔记---《火球:UML大战需求分析》

书评

作为一本UML和需求分析的入门书来说还算可以，写的比较接地气，如果是做过很多项目的读者，很容易找到共鸣点。

美中不足：部分概念可能有错误，其中对于Component和Artifact的解释明显和Wikipedia的解释不一样，感觉应该是错误。

结论：三星推荐。

需求分析

1. 需求分析的难点
   • 屁股决定脑袋，眼界决定境界，各人有各人的想法
   • 词不达意，想到说不清楚，说清楚写不清楚，写清楚理解不清楚
   • 需求的持续演进，一天一个样
     • 自学业务，争取尽快超越客户对需求的理解
     • 认真考虑，认清客户真正的需求是什么，带来的价值是什么
   • BPR(Business Process Reenginerring),部分人员抗拒

Class Digram

1. Class Diagram 包含 Attribute(属于) 和Operation(操作)

2. 如果类是一个Abstract Class，则需要用斜体表示

   类之间的关系

3. Class之间的关系可以用Association表示，直线，上面可以加箭头（关系方向）、数量（1:1 1:N M:N)、文字（关系）

4. Class之间也可以有包含关系， 实心菱形表示强包含（Compostion 组合），空心菱形表示弱包含（ 聚合 Aggregation 即子对象可以独立于父对象存在）
   

5. 继续关系 （Generalization），用三角简表示
   

6. 信赖关系（Dependency) 用带虚线的箭头表示
   

7. 递归关系（Recursion），可以用到自身的包含(Aggregation/Compostion)，当然也可以用关系(Association)
   

8. 三角关系（Triangle）
   

   对象图（Object Diagram)

   一般使用比较少，多用于描述软件设计中的复杂算法和场景，需求分析中较少使用。

活动图Activity Diagram

1. 结构建模一般用Class Diagram等Stracture Diagram表示，行为建模一般用Activity Diagram等Behavior Diagram表示

2. 活动图包含

   • Iniital State 实心圆
   • Final State 实心套实心小圆
   • 活动Activity 圆角矩形
   • 判断Decision 菱形
   • Guard 监护，下图中[]内的文字
   • Merge 合并 从Decision合并后的菱形
   • 泳道 Swimlane 表示活动的发起者
   • Fork 分支 表示并行中的开始
   • Join 汇合 表示并行中的结束，和Fork是成对出现
     

3. 在Activity Diagram中可以引入对象(用矩形表示)，用来表示工作成品（如需求说明书，规格说明书等），对象之间的连线叫Object Flow, 活动之间的连线叫Control Flow.

State Machine Diagram (状态机图）

1. 活动图关注事务的状态，以及状态之间的转变
2. State Machine Diagram包含：
   • Iniital State 实心圆
   • Final State 实心套实心小圆
   • State 圆角矩形
   • Transition 转变 State之间箭头

Sequence Diagram

1. 顺序图的组成
   • Actor：小人
   • Message：实心箭头
   • 返回值： 虚拟箭头
2. Sequence Diagram可是以Actor为视角进行画，也可以以对象为视角进行画
3. UML2中增加了loop alt(alternative) opt（optional)三种情况， 表示特殊流程
4. 顺序图和加了泳道的活动图非常像， 一般是如果特殊流程较少，或强调主干流程时，优先选择顺序图，分支流程较多或是强调特殊流程时优先选择活动图
5. Communication Diagram即UML1.X中的Collabation Diagram是Sequence Diagram的一种，需要按标号去读。
   

用例图 Use Case Diagram

1. 用命图用业回复下面的两个问题：
   • 系统有谁在用？
   • 系统用户使用这个系统能完成什么事？
2. Use Case Diagram的组成：
   • Actor：小人表示
   • Use Case: 圆圈表示
   • System Boundary：系统边界 用大的方框表示
3. 用例的使用一般是采用一个大的use case来表示整个系统的功能，再分别用小的use case分场景细化。
4. 用例之间可以用继续（Inherit）、包含(Include)、扩展(Extend)的关系， 需要注意箭头的方向代表着谁《》谁， 读的时候先读不带箭头端，再读箭头端。
5. use case的表达方式为动宾方式

6. 用例一般还需要加以用例表来完整的表达需求
   

7. 用例表中的基本流程的编写部分约定：

   • 以阿拉伯数字编号
   • 执行者的操作顶头写
   • 系统的操作空两格
   • 以用户的语言写，而不是以计算机语言写
8. 需求分析时对UML的综合运用：
   • 采用类图表示业务概念
   • 通过用例来表示详细业务需求
   • 使用流程三剑客（activity/state machine /sequence diagram)来表示业务流程
   • *从用户痛点开始，理解每一个需求背后的业务痛点，意义，带来的价值，理清业务流程，梳理用户 *

部署图Deployment Diagram

1. 从硬件的角度、物理层次上进行系统的整体规划，包括当前的IT架构以及改造后的IT构架
2. deployment diagram 包括：
   • Node：用来表示物理的设备，如电脑、PC、服务器等
   • Tag 用来表示设备的数量 操作系统 供应端等相关信息
   • Communication Path 节点间的连线
3. Component的定义如下：
   • 能实现一定的功能，或者提供一些服务，如接口
   • 不能独立运行，要作为系统的一部分
   • 可单独维护，升级，替换，而不影响整个系统。
4. artifact 描述系统中的一个物理单元，同样是可替换的部分，如源文件，安装程序，脚本等。

需求分析

1. 需求分析的UML活动图示例