UML - 系统分析和设计

前言

通过计算机建模解决复杂问题的流程:分析和明确问题,寻求解决方案,最后编程解决。

在软件工程中,一个系统的生命周期涉及领域有需求分析、系统设计、软件设计、软件编程、软件测试、软件部署、软件维护。软件工程涉及相关概念有数据建模,软件架构,软件开发过程,项目质量,项目管控等内容,我们熟知的软件开发模式有瀑布、螺旋、迭代、敏捷、XP等模式。

针对软件工程的生命周期,我们需要一种标准的,行之有效的描述系统开发的方式或方法。UML虽然非工业标准,但UML逐渐成为工业界的标准,并打算成为可以对并发和分布式系统的标准建模语言。

1. UML背景

软件分析和设计过程中,迫切需要某种标识法,以前的尝试有:流程图、数据流图、实体关系图都是尝试结果。

OOP编程出现,引起表示图的激增,最具代表的:Booch94、OMT(对象建模技术)、RDD(职责驱动开发)等,Booch94在设计表示上更优(设计师更爱),OMT在分析表示上更优(分析师更爱),UML的出现就是设计和分析方法的结合表现。

2. UML概述

UML(统一建模语言)是一种开放的方法,用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。

UML可以描述相关系统分析和设计的几个关键内容:这个系统/软件做什么用,有哪些关键对象,对象间如何交互的。

UML符合模型驱动架构(Model Driven Architecture)的思想,同时在2.0版本做了系列图示的增加和改动,新增和替换了部分图示

UML核心是图表,最重要的是建模的符号,图表构成由视图(view)、图(diagrams)、模型元素(model element)、通信机制构成,图表涵盖设计、实现、处理、部署几个大的维度,分类下来UML图表可以分为结结构图和行为图两大类。

系统的架构设计,很关键的一步就是抽象,UML建模可以把在复杂世界的许多重要的细节给抽象出来,以图表的形式体现。

3. UML模型分类(功能模型、对象模型、动态模型)

  • 功能模型:用户视角描述系统,包含用例图
  • 对象模型:强调系统的整体结构和基础,通过对象,属性,操作,关联概念描述系统应用,包含类图、对象图
  • 动态模型:系统动态运行视角,展现系统的内部行为,包括序列图,活动图,状态图

总结下来,UML可以描述相关内容:这个系统做什么用,有哪些关键对象,对象间如何交互的

4. UML图形表示

实际上,UML并不限定UML要素型别非得是某图形上的型别(这种弹性在UML2.0部分被限定),一般来说,每个UML要素大约会出现在图的所有型别,综合来更好的描述系统的整体设计。

为了要保持工程图的传统,在UML图上加注用途、约束、或意图永远无伤大雅。

4.1. 结构图(系统式的建模)

  • 包图
  • 类图
  • 对象图
  • 元件图
  • 部署图
  • 剖面图
  • 符合结构图

4.2. 行为图 (强调事件与交互)

  • 活动图
  • 状态图
  • 用例图
  • 时序图/交互图/序列图:强调时间点以及消息传递
  • 交互概述图
  • 通信图
  • 时间图

5. 图标示例

6. 常见代表性术语

  • 对于结构而言:包、类、对象、属性、元件、接口、执行者
  • 对于行为而言:活动、事件、消息、方法、操作、状态、用例、参与者
  • 对于关系而言:聚合、关联、组合、继承、相依

7. 用例图:问题描述

需求分析的一个任务就是识别参与者(actor)和用例,常说的用例测试中的用例也是由此而来。

虽然不是每个系统都需要用例,但事实上,分析清楚开始做什么比从哪里开始重要,即把问题定义清楚。

7.1. 参与者

那些和系统交互,但又位于系统之外的实体,它们通常是系统用户,有时候也可以是系统。

  • 参与者举例:学生、登记人员、厂务人员
  • 参与者通常用一个小人描述。

7.2. 用例

用例用于描述参与者和系统之间的交互,从参与者角度描述了和系统之间的交互,是抽象的,不会涉及任何系统内部的工作方式,也没有界面操作等描述信息。

用例描述时候,可能涉及扩展点(extension point),同时可能复用一些其他用例,可以通过包含(include)表示

扩展点和包含区别:包含用例会引用被包含的用例,但扩展另一个用例,则用例间无相互引用关系

  • 用例说明:登记一门课程、学生查看课程清单、登记人员登记一门课程
  • 包含用例:登记课程,其中包含学生查看课程清单
  • 扩展点(extending):填写支付方式

7.3. 用例使用注意

创建用例,用于描述用户期望的系统行为,但用例没有涉及UI细节,画用例图一方面是为了更好的描述和理解系统,同时展示给需要看的人(主要是分析师和系统关联者),以及提供他们交流使用。同时应该注意用例足够的轻量级,这样可以易于维护。

系统边界图:通过一个矩形框,将系统所有用例包含进来,参与者都放置在外,通过有数据流向的关联和用例连接起来。

用例不是必须的,但当你认为它是重要的和必须的就绘制它,否则可以一直不用,直到有这个需要为止。

文档第一定律:知道迫切需要,并意义重大时,才来编制文档。

8. 领域模型

领域(domain)模型是一组图,用于定义用例中的术语,显示了问题的对象以及他们之间的关系;在一个小的不成熟项目中,可以基于从分析中得到的领域模型进行编码,从而省略进一步的设计,健康的项目知道还有许多工作要做,包括诸如:并发、序列化、安全性、分布等问题。

概念图是用来帮助和涉众进行交流的,不具备软件结构方面的内容

  • 《type》:代表实体,同时具有操作和属性,也可以和其他《type》实体关联(但与类或对象不是映射关系)
  • 实体关联:支持0到多,1到多等关系

9. 类图

9.1. 属性和操作

  • 可见性修饰符:公有的:+、私有的:-、保护的:#
  • 属性说明:count:int
  • 函数说明:SetName(name:string)

9.2. 关联、聚合、组合

  • 关联(Assiation):
    • 被关联的两个类之间可以相互传递信息,比如雇主和雇员;
    • 单向关联:关联有方向性,比如Modem和拨号器
    • 箭头表示
  • 聚合(Aggregation):
    • 整体包含部分的关系,比如家庭和家庭成员的关系
    • 用菱形表示
  • 组合(Composition):
    • 整体负责部分的生存期,整体必须注意到部分以某种方式被删除,比如接收器(整体)和消息缓存(部分)
    • 用实心菱形+箭头表示

10. 包图

包代表了一种对系统的划分,增强了系统的开发性和发布性,同时可以被用于直观的描述系统,并在系统改变时候进行影响评估。

10.1. 基本画法

  • 高层次画法:只包含包名字
  • 低层次画法:包含包名、包中的方法(可以指明公有、私有、保护)

10.2. 关系

  • 导入(import):虚线箭头线,表示包依赖关系
  • 泛化(Generalization):空心三角形箭头和通用包或者抽象包相连,另一端和包的实现相连

11. 时序图/消息顺序图

11.1. 基本画法

  • 对象:矩形表示
  • 生存线:矩形下悬挂的虚线表示,生存线可以有长度不一致,表示开始和销毁时间不同
  • 消息:生存线之间的箭头,箭头标签是消息名称,时间是自顶向下流逝的,
  • 数据消息:若尾端为圆形表示数据消息,若和消息传递方向一致,表示消息参数,否则为消息返回
  • 程序激活:在生存线上的长方形,表示一个方法或函数执行的持续时间。
  • 循环区域:通过一个大的粗线条矩形框住部分代表一个循环区域

11.2. 使用场景

  • 复杂的业务流,进行关键消息扭转传递
  • 竞态条件的描述,比如多个线程或者goroutine并发处理情况下,对竞态条件的描述,便于梳理竟态的可能情况

12. 小结

简要介绍了UML模型分类(功能、对象、状态)以及从结构和行为方面划分了UML图像分类,同时描述了用例图、类图关系、消息顺序图进行简要介绍,后续会对状态机、活动图、协作图等UML图,在用到的时候再做单一介绍。

13. 更多参考