书评

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

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

结论：三星推荐。

需求分析

Class Diagram 包含 Attribute(属于) 和Operation(操作)
如果类是一个Abstract Class，则需要用斜体表示

类之间的关系
Class之间的关系可以用Association表示，直线，上面可以加箭头（关系方向）、数量（1:1 1:N M:N)、文字（关系）
Class之间也可以有包含关系，实心菱形表示强包含（Compostion 组合），空心菱形表示弱包含（聚合 Aggregation 即子对象可以独立于父对象存在）
继续关系（Generalization），用三角简表示
信赖关系（Dependency) 用带虚线的箭头表示
递归关系（Recursion），可以用到自身的包含(Aggregation/Compostion)，当然也可以用关系(Association)
三角关系（Triangle）

对象图（Object Diagram)

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

结构建模一般用Class Diagram等Stracture Diagram表示，行为建模一般用Activity Diagram等Behavior Diagram表示
活动图包含
- Iniital State 实心圆
- Final State 实心套实心小圆
- 活动Activity 圆角矩形
- 判断Decision 菱形
- Guard 监护，下图中[]内的文字
- Merge 合并从Decision合并后的菱形
- 泳道 Swimlane 表示活动的发起者
- Fork 分支表示并行中的开始
- Join 汇合表示并行中的结束，和Fork是成对出现
在Activity Diagram中可以引入对象(用矩形表示)，用来表示工作成品（如需求说明书，规格说明书等），对象之间的连线叫Object Flow, 活动之间的连线叫Control Flow.

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

用命图用业回复下面的两个问题：
- 系统有谁在用？
- 系统用户使用这个系统能完成什么事？
Use Case Diagram的组成：
- Actor：小人表示
- Use Case: 圆圈表示
- System Boundary：系统边界用大的方框表示
用例的使用一般是采用一个大的use case来表示整个系统的功能，再分别用小的use case分场景细化。
用例之间可以用继续（Inherit）、包含(Include)、扩展(Extend)的关系，需要注意箭头的方向代表着谁《》谁，读的时候先读不带箭头端，再读箭头端。
use case的表达方式为动宾方式
用例一般还需要加以用例表来完整的表达需求
用例表中的基本流程的编写部分约定：
- 以阿拉伯数字编号
- 执行者的操作顶头写
- 系统的操作空两格
- 以用户的语言写，而不是以计算机语言写
需求分析时对UML的综合运用：
- 采用类图表示业务概念
- 通过用例来表示详细业务需求
- 使用流程三剑客（activity/state machine /sequence diagram)来表示业务流程
- *从用户痛点开始，理解每一个需求背后的业务痛点，意义，带来的价值，理清业务流程，梳理用户 *

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