UML系列 - 序列图知识总结

    现在软件项目的迭代越来越快，一般不会有太多的前期设计时间，而且往往企业主，管理者对软件的开发过程并不是十分了解（或者存在盲目乐观，认为程序员无所不能，），对工期的限定可能会不切实际。层层压缩下，UML设计过程就变得可有可无了。

    软件开发中，开发者的三种面向对象设计方式：

1. 直接编码 开发者一般在草稿上简单画一下，然后凭着自己的想象直接在IDE开发工具中开发（类、接口、继承等），但这非常依赖开发者的经验，他无法凭着想象写出超出自己的水平的编码。

2. 绘简单图，然后编码

   通过记事本或者UML工具画简要的图型，然后编码，编码过程中根据思路反复调整UML图型。

3. 绘详尽图，然后生成代码

   即所谓的【正向工程】，把UML模型直接映射为代码，妄想着模型解决一切，这样的功能和期望已不适合时代潮流了。

    前面第二种方式，通过绘制简要的常用图型来理清思路是比较合适，不会太耗时，磨刀不误砍柴工。

    那么UML这 5 种主要图型在项目是否真的可有可无呢？

1.  用例：系统的功能点归纳，配合规格说明，是开发、测试和维护的依据。但有时会被功能清单代替。

2. 序列图：对象交互建模，往往被忽略，由产品经理通过页面流来代替，但页面流仅是分析界面层面的序列。

3. 活动图：对于复杂的流程是无法绕开的，流程图都不正确，开发出来的东西肯定是错的。

4. 状态图：对于有状态的领域模型（比如订单）才需要，这种情况下状态图是绕不开的，否则状态流都不对，怎么编码也都不对了。

5. 类图：面向对象设计阶段的最终产出，设计原则和设计模式的体现，优质代码的基础，但依然会被一些程序员所忽略。
   

    所以，序列图还是有绘制的必要的，它可以让我们从整体的角度来观察和分析一个业务的走向，而不是只是关注界面或者只是关注类、接口等。

• 参与者和用例图中的参与者概念一致，表示发起本次交互行为的人、系统或设备。

• 生命线：表示和参与者发生交互的系统、界面、设备和软件模块。一般从左到右是逐步的细化，有设备、界面到内部细节。生命线主要有两种：

• 边界生命线：设备、界面或者子系统等。

• 生命线：常规生命线，一般用于表示模块、类或接口等。

• 消息定义

  指参与者和生命线，生命线之间或者生命线本身的信息传递。

• 消息和传回消息

• 序列图最基本的消息类型，一般有消息就有传回消息

• 对于事件（观察者模式）可能没有传回消息

• 消息为实线箭头

• 传回消息为虚线箭头
  

• 自身消息

• 用嵌套的活动条表示对象发送给自身的消息。

• 比如清空缓存、保存日志、发布事件等都可以用自身消息
  

• 递归消息

• 用来表示递归类型、递归算法的消息类型。

• 表现形式也是传递给生命线自身。
  

     图框是序列图中比较复杂的环节，一般简单的序列图就是从参与者开始，逐层传递消息 和 传回消息直到结束。

    但我们知道一般的业务都是没有这么简单的，所以这时需要图框来帮助我们表达更复杂的业务。

    比如如下图：

    这是电商网站，顾客查看购物车或者更改购物车中选中的商品的序列图。

    图中有两类生命线，界面用边界生命线表示，其它为普通生命线。

    图中涉及两类图框，alt为判断（即if else），loop为循环。

    【注】图框是可以嵌套的，如上图，alt图框中就嵌套了loop图框。    

    下面为常见图框类型的介绍：

    使用UML Visual Paradigm来画图时，可以通过右键点击图框的左上角（标识位置），在弹出的层中选择操作种类来切换：

    对比前面的序列图，这里将促销规则的细节涵盖在促销规则生命线下面的一个 ref 类型的图框中。

    右键该图框，可以选择：参照 xxx 序列图。

【注】最后两张图是网上找的，供读者参考借鉴。

    说明：本图重点看loop、alt和opt三种图框，alt中分为if else两部分，当大于$10000时走上面的分支，否则走下面。 loop和alt存在嵌套。 

    说明：本图涉及loop和alt两种图框，还涉及自身消息的使用。上面生命线涉及边界生命线和实体生命线（最右侧那个，比较少用的一种生命线，可以用普通生命线来代替）