实用UML知识——如何看懂UML传递的软件架构信息

前公司的技术交流大体是靠口授, 个人会采用一些简单的架构文档+ 口述的方式, 描述一个软件产品的整体架构.  并且, 大多数情况是, 先有代码, 后有文档的方式, 这样做有以下优点:

• 1. 关注软件结构分层, 整体上对项目把握比较准确.

• 2. 架构设计者的思路一目了然, 整体思路非常清晰

缺点也是显然的:

• 风格不统一,  多人交流非常困难

• 细节描述不够, 细节补充需要口述或者看代码的方式. 交流成本很高.

• 承接性不够, 人员流动带来损失非常大.

 

目前开发采用的流程已经截然不同, 一般是先有文档, 后写代码, 即:

需求分析->概要设计->详细设计->编码->测试->交付

采用的是瀑布开发流程, 各个阶段占用的时间比例大致相等.

 

文档的描述方式采用UML, UML既然是业界通用语言的话, 其优点自然不用多说,  目前在解读UML文档中出现的问题:

1. 文档扁平化, UML描述一个项目需要从: 用例图, 模块关系图, 类图, 序列图, 活动图等来描述, 读者需要将这些所有的文档恢复成一个软件架构, 需要掌握好的学习方法, 否则这堆文档成了没有整理的杂货店.
2.  标记符号比较多. 理解起来遇到的问题自然比较多, 很多时候会让人有读代码的冲动, 但还是需要从文档的角度构建一个软件架构, 否则你就输了, 注意这里是: 先有文档, 后有代码的, 文档让你彻底理清楚软件架构图.

总之, 如果你的文档, 没有让你的读者构建出一副完整的架构图, 那说明文档制作者是有问题的, 同样, 如果你不能从标准化的文档中领会架构的秘密, 那说明你对UML的领会不够深入. 因此这里想好好梳理一下UML, 因此, 引出本文想解决的几个问题:

• 介绍如何读懂UML架构描述文档
• 这里不会告诉你细节知识, 但会给出引用的文章, 方便熟悉基础知识.
• 如何更容易的传达一个软件产品的知识信息.

学习的目的是看清楚背后的本质, 无论是什么方式表达, 能收到对方传递给你的信息, 这就是最好的方式, 作为一个业界标准, UML很大程度做到了这一点, 但是阅读者往往不这么认为, 阅读文档的时候, 还是需要承受比较多的压力. 本文的目的就是排除这样的压力, 轻松的实现UML信息的交流. 有些观点可能不正确, 希望有高手指点. 当然文章会不断重构. 以期帮助更多的朋友.

 

基础知识请参照以下文档, 其实重要概念并不多, 关键是要进行比较和对照, 从而达到理解的目的:

Use Case 中 include 与 extend 的区别

UML类图详解

类图实质是零件组织图, 从上文中可以总结以下特点:

1. 箭头的含义是导航, 从一个类中能找到另外一个类. 不管零时变量还是持有属性, 存在另外一个类, 就是可导航的. 下面描述的是属性, 在方法中临时使用的变量不算其中: 注意, 有必要的时候, 这个导航箭头才画出, 很多时候可能被省略

2. 空心菱形表示组合, 负责生死.

3. 实心菱形表示聚合, 不负责生死

UML:uml中四种关系

UML 基础: 序列图

UML时序图组合片段简要说明

为了方便理解问题, 我在这里用电脑的组装来说明UML各种关系图所起到的作用, 请各位务必要明白, 任何时候, 都不要做工具的使用者, 而是工具的制造者, 从这个角度考虑问题, 会让你真正成为一个设计者。 我这里要抛给大家的问题是: 为什么要这样设计UML, 如果是你交给你来设计这样的语言, 你会不会有更好的方式? 当时的设计者, 为什么没有像你这样的考虑? 是他的疏忽, 还是你的不成熟?

 

从一台电脑生产的角度来看,  我们可以发现有如下过程:

• 1. 电脑的功能需求
  • 电脑需要提供什么样的功能, 如输入的功能, 展示的功能, 保存的功能。相当于UML用例图
• 2. 架构分层
  • 比如数据层, 逻辑处理层, UI层, 可以称为模块关系图 (需要考证一下UML是否有这样的标准图)
  • 一般也可以视为层次结构图.
• 3. 电脑的各个元件, 以及这些元件的自身组成
  • 这里相当于类图 , 注意这样的称呼其实是不完美的, 类图描述的其实应该是一个实体对象的组成和对象之间的关系
    • 描述一个对象和另外一个对象的关系, 即:
    • 第一层关系:对象A和对象B之间是否存在包含与被包含关系, 以及包含的个数(关联关系 )
    • 第二层关系:对象A是否负责对象B的生存销毁(关联关系的进一步, 聚合关系 )
    • 另外这里有个不搭边类关系——继承(或者称为泛化)的关系. 比较好理解, 不做详述.
  • 这里最好有一个组装的概念, 机箱和显示器, 键盘和显示器, 鼠标和机箱之间的关系
  • 应该明白, 你组装一个电脑的时候, 如何描述元件之间的关系: 键盘有几个按键, 这些后面再补充说明, 以方便达到更好的理解
  • 也就是说, 这部分是对第二步的一个完善。是第二步的细节信息
  • 通过这个图, 你已经组装了整个电脑了. 但仅仅只是一个躯壳, 这个躯壳仅仅描述了元件接口, 元件的功能以及功能的使用,将是第四部分的内容(当然很多类图会将类的功能描述出来, 但请忽视之, 因为类图中的方法列表, 不会对你理解项目带来多大的帮助, 反而是混淆视听, 真正能给你帮助的是第四部分的序列图).
• 4. 元件的内部处理机制,  单个操作如何在元件之间传递
  • 即当你按下一个按键的时候, 消息如何最终显示的屏幕上的? 应该是按键->键盘->机箱->显示器这样的思路
  • 这样的描述是为了设计第三部的细节设计, 如何设计你的按键的逻辑方法
  • 在UML图里面, 这部分可以称为序列图 , 实际上是告诉你如何设计方法的。
  • 也就是说, 这部分是对第三步的完善. 是第二步的细节信息

不难看出, 这样的一个架构及其清晰, 假如你读过《金字塔原理》这本书的话, 你会发现, 这样的一个组织架构, 是一个完美的金字塔结构。UML这样设计, 完全是根据人脑的学习习惯来设计的, 假如你看不懂UML图, 说明缺乏对UML的深层次理解。