Objected-Oriented Analysis and Design-2

本文为华东师范大学开设的面向对象分析与设计慕课课程第二周笔记，主要介绍了UML统一建模语言。

UML (Unified Modeling Language) 统一建模语言

由于客户和编程人员对需求理解的差异，且完整地理解一个复杂的系统很困难，所以需要建模。建模是为了能够更好地理解正在开发的系统。

建模

• 所谓建模就是把不太理解的东西和一些已经较为理解、且十分类似的东西做比较，从而对这些不太理解的东西产生更深刻的理解

模型

• 建模产生的结果就是模型，模型是对现实的简化、对事物的一种抽象
• 模型可以帮助人们更好地了解事物的本质，抓住问题的要害
• 在模型中，人们总是剔除那些与问题无关的、非本质的东西，从而使模型与真实的实体相比更加简单、易于把握

建模的目的

• 帮助我们按照需要对系统进行可视化
• 允许我们详细说明系统的结构和行为
• 给出了一个指导我们构造系统的模板
• 对我们所做出的决策进行文档化

建模的四项基本原理

• 选择要创建什么模型，不同的模型会有不同的启发

• 每一种模型可以在不同的精度级别上表示

• A model is an abstraction of the real world. Good models are still connected with reality. 最好的模型都是与现实相关联的

  • 模型都是对现实的简化，但是简化不能掩盖掉任何重要的细节

• 单个模型是不充分的, 对每一个重要的系统最好用一组几乎独立的模型去处理。

UML统一建模语言

• “事实上的”工业标准，相当于软件工程师的工具包
• UML的构造块 (记住它们的常用符号)
  • 事物（结构事物，行为事物，分组事物，注释事物）
  • 关系（依赖，关联，泛化，实现）
  • 图（类图，对象图，顺序图，通信图，构建图，活动图，包图，用例图，状态图，部署图）
• UML公有机制
  • 详述
  • 修饰
  • 通用划分
  • 扩展机制
    • 构造型 (用于自定义)，标记值，约束

UseCase Diagram 用例图

用例图的建模元素有边界，参与者，用例，关系

Actor 参与者

• 代表位于系统之外并和系统进行交互的一类事物（人、物、其他软件子系统等）
• 通过它，可以对软件系统与外界发生的交互进行分析和描述
• 通过它，可以了解客户希望软件系统提供哪些功能

如何确定参与者

• 谁使用系统？Who or what uses the system
• 谁安装系统、维护系统？Who installs the system? Who maintains the system
• 谁启动系统、关闭系统？Who starts and stops the system
• 谁从系统中获取信息，谁提供信息给系统？Who gets and provides information to the system
• 在系统交互中，谁扮演了什么角色？What roles do they play in the interaction
• 系统会与哪些其他系统相关联？What other systems interact with this system
• 内/外部定时器 Does anything happen at a fixed time?

需要注意的是，Actor是某个系统时，应使用构造型《actor》

UseCase 用例

• 系统为响应参与者引发的一个事件而执行的一系列的处理/动作，而这些处理应该为参与者产生一种有价值的结果，这些动作不但应包含正常情况的各种动作序列，而且应包含对非正常情况时软件系统的动作序列的描述。用例名称一般用短小精悍的“动名词”

寻找用例

• 参与者希望系统提供什么功能 Start with actors, then identify what they want to do What functions will the actor want from the system ?
• 系统是否存储和检索信息
• 当系统改变状态时，是否通知参与者 Are any actors notified when the system changes ?
• 是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件 Are there external events that notify the system ?
• 哪个参与者触发了活动？Which actors trigger activity ?

用例图中的关系

• 参与者与用例之间
  • 关联关系
• 参与者与参与者之间
  • 泛化关系
• 用例之间的关系
  • 泛化关系
    • 如下订单和网上下订单
  • 包含关系 include
    • 如取钱用例的输入密码，因为你做任何事情都需要输入密码
  • 扩展关系 extend
    • 如取钱用例的打印单据，你可以选择在取钱以后是否打印单据

用例注意事项

• 用例步骤最好不要有涉及到具体界面的描述，这样的话，适用面会比较广。我们学习分析、设计，目的是应对所要开发的系统的不断演变、需求的不断更改。
• 合适的粒度
• 用例图中，用例与用例之间，只有三种关系： 泛化、包含、扩展。千万不要随随便便地在用例与用例之间画一条直线 (关联关系) ！这样做的话，就变成“糖葫芦串”了。

UseCase description 用例描述

一般由一个主事件流和多个异常事件流描述

• 主事件流：一切正常时的动作序列
• 异常事件流或可选事件流流：主事件流的每一步都有可能出现异常，此处描述异常情况的处理

Activity Diagram 活动图

活动图描述了在一个过程中，顺序的/并行的活动及其之间的关系，一般用于业务过程，复杂算法建模。

活动图是顶点和弧的集合，包括活动节点，动作，流，对象值，注解和约束等

开始、结束、对象

活动节点

• 一个活动是一个过程中进行的非原子的执行单元
• 活动的执行最终延伸为一些独立动作 (Action) 的执行

分支

• 一个分支可以有一个进入流和多个离去流
• 在每个离去流上必须设置一个监护条件
  • 条件放在方括号里
  • 条件不能重叠，以免二义性
  • 可以有 [else] 分支
• 两个控制路径可以重新合并，无需监护条件

Forking and Joining 分岔和汇合

• 分岔表示把一个单独的控制流分成两个或多个并发的控制流
• 汇合表示两个或多个并发控制流的同步发生，一个汇合可以有两个或多个进入转移和一个输出转移在UML中，用同步棒来说明并行控制流的分岔和汇合

Swimlanes 泳道

• 将一个活动图中的活动分组，每一组表示一个特定的类别、人或部门，他们负责完成组内的活动
• 每个组被称为一个泳道
• 每个活动严格地属于一个用到，同步棒可以跨越泳道

活动图与用例模型互为补充，主要用于需求分析阶段

Class Diagram 类图

Class 类

• 具有相同属性、操作、方法、关系或者行为的一组对象的描述符
• 类是真实世界事物的抽象
• 问题领域的类：在对系统建模时，将会涉及到如何识别业务系统中的事物，这些事物构成了整个业务系统。在UML中，把所有的这些事物都建模为类 (class)

Object 对象

• 当这些事物存在于真实世界中时，它们是类的实例，并被称为对象
• 同一个类的各对象具有相同的属性，但属性的取值可以不同，提供相同的操作、有相同的语义

类图中的UML元素

• 类之间的关系：关联关系，依赖关系，泛化关系，实现关系
  • 关联的修饰
    • 名称及其方向
    • 关联关系的多重性
    • 角色
• 类：内容包括名称，属性，操作，职责
• 关联类，Association class is an association that is also a class, and consists of the class, association and the dashed line

Sequence Diagram 顺序图

一种详细描述对象之间以及对象与参与者之间交互的图，它由一组相互协作的对象或参与者实例以及它们之间发送的消息组成，强调消息之间的顺序，可用于动态验证模型的可行性。顺序图验证的某一功能，属于某个用例描述的功能中的一部分 (称为用例实现)。

顺序图的构成

参与者，对象生命线，执行规约，消息

对象生命线

• 表示对象在一段时间的存在

执行规约 (或称控制焦点)

• 执行规约 (execution specification) 是一个对象执行一个操作的时期

消息

• 对象间的协作与交流表现为一个对象以某种方式启动另一个对象的活动，这种交流在
  UML里被定义为消息
• 同步消息：如有对象A与对象B，A给B发送同步消息，要求对象B处理好消息并且返回结果，对象A才会继续往下
• 异步消息：如有对象A与对象B，A给B发送同步消息，这时候A是将消息发送到B的队列里面，接着A继续做自己的事情，等到有空的时候，就去看看自己的队列中有没有消息，如果有就把这个请求拿出来处理，如果没有就继续做自己的事情。B也是如此，当B闲下来后发现A发来了消息，那么它就会处理并返回给A结果，A在它空闲时查看队列就会得到返回结果，过程如下图：
  • 

结构化控制

在顺序图中，除了按顺序排列消息外，还应表示对消息进行选择、循环和并行处理

类图与顺序图、类图与用例模型之间的关系

• 用例是基础，是软件的需求
• 类图是在用例的基础上做的设计，是设计方案
• 顺序图是对设计方案的可行性进行验证的手段

Communication Diagram 通信图

顺序图与通信图本质上是一样的，在语义上是等价的。但建模的角度不同，前者反映了对象之间协作的时间顺序，后者反映了对象之间协作的结构关系，强调了对象之间的交流。

通信图的构成

对象，链接，在链接上的消息

State Diagram 状态图

描述了单个对象在其生命周期内响应事件所经历的状态序列以及动态行为

State machine状态机

• 是一种行为，说明对象在它的生命期中, 响应事件所经历的状态序列以及它们对每个事件的响应

State Diagram 状态图

• 状态机可以用状态图来可视化，状态图显示了一个状态机，它强调从状态到状态的控制流

State 状态

• 是对象的生命期中的一个条件或状况，在此期间，对象可以响应事件、执行某活动等
• 状态由以下几个部分组成
  • 名称
  • 进入/退出动作 (entry/exit action)
  • 内部迁移 (internal transition)
  • 子状态
  • 延迟事件 (deferred event)

Event 事件

• 是对一个在时间和空间上占有一定位置的有意义的事情的描述
  • 在状态机的语境中，一个事件是一个激励的发生，它能够触发一个状态迁移
• UML对四种事件进行建模
  • change event 参量变化
  • signal 信号 (异步)
  • call 调用 (同步)
  • 时间事件

Transition 迁移

• 在状态A，发生事件并满足一定条件，转到状态B。一个迁移由5部分组成：
  • source state 源状态
  • event trigger 事件触发器
  • guard condition 触发条件
  • effect 效应 (或称迁移动作)
  • 目标状态
• 特殊的迁移
  • self transition 自身迁移
  • internal transition 内部迁移

状态图建模注意事项

• 不允许孤立的状态存在
• 不允许只进不出的状态迁移
• 不允许只出不进的状态迁移
• 不允许没有事件发生的迁移

状态图、交互图 (顺序图与通信图) 和活动图的比较

• 交互
  • 对共同工作的对象群体的行为建模
  • 动态行为
• 状态机
  • 对单个对象的行为建模
    • 有时，可以对单个“完整系统”的行为建模
    • 说明对象在它的生命期中响应事件所经历的状态序列以及对那些事件的响应
  • 动态行为建模
• 活动图
  • 强调从活动到活动的控制流，多个业务角色，在需求分析时使用
  • 状态图是强调对象潜在的状态和这些状态之间的迁移