| 编辑推荐: |
| 本文来源csdn,本文由浅入深,将简单的介绍如何使用使用UML建模中的各个结构图与行为图，去完成抽象模型的建立。 |
|
一、上章回顾
上篇文章《系统架构师谈企业应用架构之系统建模1》主要简单的介绍了建模中使用的标准建模语言UML的相关内容，包括用例图与类图的使用方法及如何建模。相信大家对UML建模语言已经有了初步的认
识，还请大家谨记UML不同的建模图形的用处。比如，用例图主要用来描述系统的功能需求。类图主要用来描述实体间的关系。谨记这些就可以帮助我们在系统架构的
过程中深入的分析。
首先向大家道歉，上篇中有部分描述错误的地方，可能对大家造成一定的错误引导。
这是上篇给出的图，我描述的是组合关系。
特别更正为：
这是正确的结果。箭头指向聚合类。描述的信息并无任何错误。希望能对大家指正。
二、摘要
本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作和学习过程中的总结和经验，不足之处还请大家多多批评指出，有更好的建议也可以留言
说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具，或者不熟悉如何根据需求去建立模型的角度出发，简单的阐述了在系统架构的过程中我们应
该从什么样的角度出发去分析需求并且建立抽象模型。这应该说是架构师必备的技能。
本文由浅入深，本篇将简单的介绍如何使用使用UML建模中的各个结构图与行为图，去完成抽象模型的建立。
本文主要讲解以下几个建模图形：顺序图、组件图、状态图、活动图、部署图。当然本文也只是讲述了基本理论介绍及如何设计使用，系统架构师-基础到企业应
用架构-系统建模[下篇] 将会详细的讲解通过具体实例讲解如何使用这些已经介绍的抽象模型图形去描述。
三、本章内容
1、上章回顾。
2、摘要。
3、本章内容。
4、建模中的抽象模型图。
5、本章总结。
6、系列进度。
7、参考文献。
8、下篇预告。
四、建模中的抽象模型图。
1、顺序图。
介绍
顺序图也称序列图，主要用来系统中的某个流程的详细步骤。顺序图能够给出流程中一系列对象的交互顺序。通过顺序图可以让我们更好的了解如何实现某个用例
的方法。我们知道用例图用来描述系统的功能需求。而顺序图清晰的描述了某个用例也就是系统功能的的实现方法。
详解
在顺序图中包含的元素：
对象：用来标识流程中的详细步骤中的对象。
活动条：用来标识当前对象是活动的，如果想表示某个对象是活动的，那么必须使用一个虚线+活动图的形式来构建。
例如我们现在要标示一个简单的做公交车的刷卡流程：
IC卡刷卡操作。
相关解释说明：
公交卡,首先放在刷卡终端上，终端读取卡中的余额信息，然后刷卡终端与终端中的扣款程序对象交互，扣款程序根据读取的余额信息，与刷卡终端中的固定刷卡
金额对比，如果当前IC卡的余额大雨刷卡终端的固定金额则,扣除金额，并且返回一个消息，提示刷卡成功的操作。
途中的实线表示调用被调用对象的方法，虚线表示当被调用对象执行成功后，返回的虚线上表示返回值的逻辑名称，这样可以提高了可读性。
在公交卡与活动条之间，应有一个虚线链接。
在上图中我们使用了活动条，活动条作为生命线的一部分。我们并没有定义对象的创建和销毁，因此我们来看UML建模语言提供的描述对象的创建与销毁实例。
上图中的X符号的图标代表的时候对象的销毁。创建对象通过new来创建，上图中，我用中文描述“创建对象”来完成对象的创建，那么在生命线下的的X符号代
表销毁对象，从内存中移除对象。当然这个对象的销毁对不同的开发语言有这不同的处理方式。C++中的销毁对象，必须调用析构函数来销毁对象。C#与JAVA语言中
则只是说明当前需要销毁的对象没有被其他的对象引用，那么这类语言编译器提供垃圾回收器来完成回收。
注意：当某个对象引用了另外一个对象，该对象有责任销毁被引用对象并且必须显示销毁该被引用对象时，那么必须要显示的发送被引用对象销毁的通知消息。白
话文来说就是显示的调用被引用对象的销毁方法。
顺序途中的同步与异步。
顺序图中的同步与异步与我们平时书写代码中的同步与异步的解释意思差不多。这里不过多解释，通过图例说明：
客户去餐厅吃饭，首先要点餐，必须等待点餐完了才能上菜。意思就是可以这样简单描述。A简单调用B方
法，必须等待，等到B方法执行完毕后,继续执行。
函数A调用函数B，如果B需要的时间特别长，那么此时A可以去继续执行做其他的事情比如做和函
数C交互，等B函数执行完了，只需要回调通知A，B函数执行完了即可。在函数调用中的术语就是回调。
UML建模语言中同步与异步消息的标识格式：
UML提供了一些顺序图的高级功能：例如可以通过顺序图实现流程的控制。具体的实现工具是通过UML提出的交互框来实现流程条件的控制。
交互框其实就是定义了流程控制图中的控制逻辑，基于交互框定义流程执行的条件。如果满足这个条件，那么则执行交互框中已定义好的顺序步骤。否则不做任何
操作。交互框中除了定义流程控制的条件外，还有一些自己特殊的操作符，具体的操作符及其作用，如下列表：
每个关键字代表的含义都有相应的描述。大家应该都可以看明白，上述的所有含义都是针对交互框来说的。
总结
如果在系统功能中有特殊需求，那么顺序图中的交互框是可以支持嵌套的。嵌套交互框的话，会提高顺序图的复杂度，降低可读性。因此我们设计时的原则尽量把复
杂的流程拆分成几个简单的，分别绘制顺序图来完成相应步骤。
2、组件图。
简介
众所周知，组件图是用来描述系统中的各组件之间的关系。首先我们必须知道组件的定义是什么，然后组件之间有哪些关系。理清楚这些，我们在以后的设计中才能
派上用场。UML语言对组件的定义已发生了巨大变化。在之前的版本里面，UML如下定义组件的：
UML1.1语言中对组件的描述：把某个文件或者可以运行的程序称之为组件。但是我们知道，UML出现组件图以前，组件一般用来描述COM组件或者其他的组件，因此造成冲突，所以随着后续UML语言的发布，修改了原有的含义。
UML2.x语言中对组件的的描述：组件是独立的，是运行在一个系统中的封装单位，提供了一系列的服务。
通过上述UML语言中的变迁，目前的理解是：一个系统，可以随意更换系统中的某个组建。而不会影响系统的运行。这可以理解为类似，大家熟悉IOC容器的都应该
知道，运行在IOC容器中的对象，可以看作组件，那么替换其中的提供某一服务的组件，只要满足该组件服务的相关契约就能自动完成替换。而不会影响系统的运行。
每个组件都封装了一些特殊的行为,实现了特定的服务。
组件之间的关系有哪些呢？我们通过下图来看看，组件直接可能存在的关系：
组件直接的关系基本上来说就这2种。下面会举例区别2中关系。
组件图提供的服务：组件图为系统架构师提供了解决方案的自然形式。组件图允许架构师验证系统的必需功能是由组件来完成的。组件是可以复用的。
详解
组件图中包含的元素：
下面我们分别讲解：
(1)、组件：我们知道组件是组件图中最基本的组成元素，组件上面已经讲述了组件的定义。这里就不在多介绍，组件图组成的基本单位即组件。
(2)、容器：可以为多个组件提供服务的管理容器，容器中的组件相互交互。
(3)、包：可以看作一个子系统,其实也可以看作是特殊的组件。
(4)、约束：用于定义接口规范。
(5)、给组件图中的相应元素添加相应注释信息。
组件上可以定义自己的接口。例如上图，人这个组件提供了2个接口。Thinking与Sleep接口。
组件关系的建模：
我们来看看组件之间的关系的表示，根据上面讲解的组件的关系有依赖和泛化，参考类图中的依赖和泛化。
依赖关系，标识一个组件依赖另外一个组件，如果被依赖组件无法正常运行，那么该组件也无法运行。
泛化关系。标识一个组件与其他多个组件的关系为继承关系。
总结：
通过上面的学习我们知道：组件图主要是为系统架构师对整个系统的解决方案的自然形成，可以通过组件图的形式把系统的大体功能进行区分和设计。通过组件图把
系统功能进行抽象和分离。然后通过顺序图把功能流程细分成多个步骤，然后通过类图去构建每个流程步骤中的每个类应具有的个方法。最后形成一个完整的设计文
档。
3、状态图。
简介
状态图其实是针对一个对象(实体、组件其他元素等)来说的。主要是描述了，对象的行为如何改变状态的反映。我们研究UML状态图的目的就是为了搞清楚，对
象状态的变化与行为的关系。建模对象的实时行为。创建状态图的条件：当对象行为的改变与状态有关的时候才创建状态图。状态图反映了对象如何改变状态相应行为
的变化和展示对象的生命周期的创建和删除的全过程。
详细
状态图可建模的对象：
用例：可以描述用例图中的某个用例状态的变化。
类：可以描述某个类的状态的变化。
子系统：可以描述某个子系统中状态的变化。
整个系统：类似(WF)工作流中的流程，每个节点其实就相当于一个状态。
上面简单的绘制了一个去餐厅吃饭的状态变化，每个状态变化的行为都有描述，当然我这里只是简单的举例说明状态图的变化，并没有详细分析的所有可能状态都画出来。
具体的状态还请大家自己练习画出来，此处只是简单的举例说明。
状态图中的元素：
状态标记：
状态图中可以标识一个或多个初始状态，也可以包含一个或多个结束状态。
状态图中不同状态之间的关系：
转移关系，用来描述对象的状态从一个状态转移到另外一个状态的处理流，箭头指向转移后的状态。
状态图中提供了类似流程图中的判定的功能元素：决策点。
通过元素决策点来完成：
决策点，用来决策跳向不同的状态。
具体用例如下：
就是起到了一个决策的作用。这里不在复述。
状态图中的同步：
状态图中的同步主要是为了说明并发工作流的分岔和联合。下图描述了状态图中的同步条：
初始状态进入到同步条中分岔同步执行操作A与B，分别进入A状态、B状态，然后分别执行A1,B1联合进入到结束状态。
一个对象可以通过同步操作同事拥有多个状态。有时候一个对象还可以拥有不同层次的多个状态。当单个状态拥有独立的附加子状态时就可以在状态图中使用层次结
构的状态。
组合状态就是这样的比较复杂的状态结构图，有时候我们需要把一个复杂的状态细化成多个子状态的合成，那么这个复杂的状态就可以叫组合状态。
下面举例说明：
组合状态B，也即复合状态B，内部可能有比较复杂的状态(C-D状态)。这种只是组合状态B中存在单个状态变化流程的情况，还可能组合状态B中包含更多的状态流。
那么我们就要用如下的状态图完成:
上图中1代表的是下单的流程，2代表付款流程。
总结
通过上面的学习我想大家对状态图有了一定的了解，那么我们来总结下，如何建模状态图。
第一步：我们知道建模状态图，首先需要抽象出来要建模的对象。
第二步：我们基于这个对象分析出该对象具有的所有状态及发生状态改变的行为。
第三步：标识每个对象状态的起始状态与结束状态。
第四步：开始创建对象的状态图，分析是否有必要创建复杂的组合状态。
系统架构设计的过程中，我们首先要分析出哪些对象需要使用状态图来描述。如果某个对象具有复杂的行为，那么可以使用活动图来建模比使用状态图更适合。每个
状态图必须至少有一个起始状态和结束状态。并且详细的分析对象发生状态改变的行为。从某个状态转移到另外一个状态的行为是什么。在某些情况下，如果对象的某
个状态无法清晰的表达时，可以通过创建组合状态来进一步细化该状态，这样能更清晰的表达对象的状态变化。
五、本章总结。
本章主要讲述了UML建模图形中的顺序图、状态图、组件图。并且分析了什么情况下使用各种UML建模图进行建模。并且通过简单实例说明如何使用。等UML所有的
建模图形介绍完毕后，我将针对如何我目前遇到一些问题进行分析讲解，如何遇到功能需求进行功能的分离及建模。希望大家多多提出宝贵意见。
六、系列进度。
1、系统架构师-基础到企业应用架构系列之--开卷有益
2、系统架构师-基础到企业应用架构-系统建模[上篇]
3、系统架构师-基础到企业应用架构-系统建模[中篇](上)
4、系统架构师-基础到企业应用架构-系统建模[中篇](下)
5、系统架构师-基础到企业应用架构-系统建模[下篇]
|
