Fork me on GitHub

UML（5）

Posted on | Edited on | In | Views:

面向对象系统分析与设计（5）

  • 为什么要对系统进行分析：
    1. 因为需求的特殊性；
    2. 用开发语言描述出来，更加正规且准确；
    3. 理解上的需要；
    4. 设计的需要。
  • 系统分析的过程：
    1. 分析结构；
    2. 分析用例；
    3. 分析 classes；
    4. 分析 packages；

1. analyze classes

  • 致力于解决功能性需求。
  • 对 class 的描述仍是概念上的，不涉及具体实现。
  • 分类：Boundary class、entity class、control class。
  • 理解：将一个 use-case 分为三类，相当于细节化这个 use-case。如下图：

1.1 boundary class

  • 边界类。
  • 定义：将 system 和 actors 之间的交互模型化，主要是界面。
  • 是对 UI 元素或者设备的抽象。举例：窗口、表格、控件、打印页面、传感器、终端等。不应太过细节，比如按钮、菜单项等是不合适的。

1.2 entity class

  • 实体类。
    太常见了，略

1.3 control class

  • 控制类。
  • 定义：体现应用程序的执行逻辑。
  • 举例：增加商品的行为，对应一个“增加商品类”。
  • tips：一个 control class 最多与一个 actor 相关联。

哪些可以直接相连：

actors boundary class entity class control class
actors × ✔️ × ×
boundary class ✔️ × ✔️ ✔️
entity class × ✔️ × ✔️
control class × ✔️ ✔️ ✔️

1.4 CRC cards 概念模型

Class name Class name
Responsibililities Collaborators
this class knows or does anothor class(this class interacts with) to fulfill its responsibilities

Tips:

  1. 有助于理解“面向对象”
  2. 如果 responsibilities 过多，会造成低内聚；
  3. 如果collaborators 过多，会造成高耦合。
  4. 以 3~5 个responsibilities 为宜。

2. statechart diagram

  • 推荐阅读：Guideline: Statechart Diagram
  • 定义：描述对象内部行为的图表，比如：当外界传来 message 时，这个对象内部会作出的反应。
  • 这个图表需要展示的信息：
    1. 以结点的形式，表示单个对象的状态；
    2. 以连线的形式，表示造成改变的原因；
    3. 如果 state 发生变化，会导致的 actions 要表现出来。
    4. 展示出这个 object 收发的所有 messages；
    5. 展示这个 object 生命周期内的所有 states；

什么是states？

2.1 states

  • 定义：一个 object 在其生命周期的某一刻的状态，具有 duration 的特点（指一段时间）。
  • 判定 object 是否处于某个 state，可以根据 ① 这个类的某些 attribute（有时属性的改变会触发 state 的变化）、② 这个类与其他类的 link（有时 link 的改变会触发 state 的变化）。

2.2 start state 和 stop state

  • start state：每个状态图，有且仅有一个 start state。在 UML 中用黑色实心圆表示。
  • stop state：每个状态图，可以有多个 stop state。在 UML 中用同心圆表示（内圆黑色实心，外圆环空心）。
  • 注：states 必须命名，未命名的将被当作匿名状态。

2.3 transitions

A state machine consists of states, linked by transitions.

  • 过渡态，在 UML 中用带箭头的实线表示，通常从一个 state 指向另一个 state（也可以指回自己 self-transition）。
  • 特点：
    • 过渡态通常在一瞬间完成，不会被打断。
    • 一个状态图中，某一时间点，只会有一个 transition 在发生。
  • transitions 的发生条件：
    1. 当一个 state activity 完成时，将会自动进入 transitions，进而进入下一个 state。关键词：自动。
    2. 被某 event 触发。关键词：非自动。
  • transitions 的伴随现象（可选）：
    1. event signature：[理解]transitions 一定程度上跟 event 是同一件事，所以要有自己的命名。
    2. guard condition：相当于先决条件
    3. action：当 transitions 发生时执行的一系列 actions
    4. message sending：给其他 objects 发消息

2.4 events

  • 瞬时发生的事件。
  • 两个事件之间，可能无关，可能相关（比如有时间先后关系等）
  • 分类：
    1. call event：做出某些操作，作为某 message 的回应；
    2. signal event：objects 之间的实时 signal；
    3. change event：判定事件，类似 if 语句。
    4. time event：定时/周期性的事件。

2.5 actions & activities

  • actions：瞬时、不会被中断；
  • activities：花时间才能完成，具有时间段的特性，可以被打断。

state 的五种 behavior：

  1. no behavior: 静等 event 发生后离开这个 state。
  2. event name[guard condition]/action: 等某 event 发生后，满足设定的条件后，执行 action。
  3. do/activity: 执行某个 operation。
  4. entry/action: 进入此 state 时会发生的 atomic action。
  5. exit/action: 离开此 state 时会发生的 atomic action。

3. composite statechart diagrams

  • 定义：有一个或多个重叠 statecharts 的状态图。

3.1 sequential composite statechart diagram

[理解]：上图的 substate 明显具有时序性。主要体现：abstract/generalize states。

3.2 concurrent composite statechart diagram

主要用来体现多线程的行为。

3.3 从 UML 上看 composite 状态图

  1. （从外界）指向状态图的边框，意味着进入 initial state。
  2. 自状态图的边框指向（外界），意味着触发 exit actions。

上面是状态图，下面是活动图

4. activity diagram

与状态图的区别：推荐阅读：状态图与活动图的联系和区别

状态图是描述某一对象的状态转化的，它主要展示的是对象的状态。描述的是一个对象的事情。从状态图中我们可以看出，对象在接受了事件刺激后，会做出什么样的反应。

活动图是描述系统在执行某一用例时的具体步骤的，它主要表现的是系统的动作，描述的是整个系统的事情。

4.0 活动图的应用场景

  1. 需要展示系统活动规律的场景。
  2. 并行工作流的建模中。

4.1 activity/action

与状态图中 activities/actions 的概念类似。

4.2 transitions

  1. 与状态图的 transitions 概念类似。
  2. 没有 internal transitions；
  3. 没有事件驱动的 actions；

4.3 一些特殊的 activities

  1. decision：多分支，每条分支都有自己的 guard condition；而且必须进入子分支中。
  2. dead end activity：允许 non-terminating 的活动图。

4.4 synchronization bar

Combines two concurrent activities and re-introduces them to a flow where only one activity occurs at a time. Represented with a thick vertical or horizontal line.

  • 不指定同步条件时，默认要等所有进入的 transitions 发生后，才能进入。

5. package

  • 为了使用的方便，将 analysis classes 等打包的一种机制。
  • 可以包含：
    1. analysis classes；
    2. use-case realizations；
    3. 其他 package，建议 2~3 层即可。
  • 包依赖：简单、不解释。
  • shared classes：将此 classes 独立打包，让其他 package 依赖它。
  • 命名空间：一个 package 对应一个命名空间。包内元素命名唯一。跨包访问时，要带上路径，举例：Package1::classname。
  • 使用 <<access>>和<<import>>标记。
  • 包可视化，同类，不赘述。
  • 包的设计原则：高内聚、低耦合。
  • 按照用途分类（分层或分区）：
    1. application-specific：不被其他包使用。
    2. application-general：能被其他包共享。
-------------The End-------------