IMZRH的日志

努力成为一个有用的人

导航

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

Posted on 2015-12-17 17:57  张荣华  阅读(3650)  评论(0)  编辑  收藏  举报

书评

作为一本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 即子对象可以独立于父对象存在）
    image

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

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

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

  8. 三角关系（Triangle）
    image

    对象图（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是成对出现
      image

  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的一种，需要按标号去读。
    image

用例图 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. 用例一般还需要加以用例表来完整的表达需求
    image

  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活动图示例
    image
    image