系列之--介绍篇

什么是系统架构

软件架构的起源

软件中的系统架构，其实是从建筑行业中的架构设计参考过来的，但是软件中的系统架构又有很大的特殊性。特殊性表现在，软件的架构可以在设计完毕后，项目进行的过程中进行相应的变化，或者可以推到重来，但是建筑行业中却不能这么做。软件行业有着很大的变化性。

什么是架构

架构总体来说就是实现需求功能的较复杂组件的设计与不能精简的较复杂组件。ISO与IEEE对系统架构的定义：一致认为软件密集型系统的架构分为主要模块，组织模块与支撑模块3部分。

系统架构的目标

功能：功能上必须满足需求。

可靠性：系统系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

可用性：系统必须可用。

可维护性：系统的维护包括两方面，一是排除现有的错误，二是将新的需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费

安全性：系统所承担的交易的商业价值极高，系统的安全性非常重要。

可扩展性：必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

系统架构师的职责

系统分析员通过与项目干系人的沟通或者是与客户的沟通整理出来功能需求，形成需求文档，然后将文档交付给系统架构师，系统架构师负责将分析员整理的需求转换为详细设计说明书。这个详细设计书作为与开发人员沟通的主要工具。

系统架构师可以通过使用UML建模工具,在详细设计说明书中书写每个组件的设计用力图或者流程图，或者是通过IBM的relations Rose工具来实现相应的建模。

系统架构师在设计时遵循的原则是：

1、低耦合：就是要求不同的组建之间的耦合度最低。每个组建的功能应尽量的分离，他们直接的调用关系进行把对象的引用转换为接口的引用。

2、高内聚：功能相像的功能放在一个组件中，对外提供接口调用的方式来整理。

系统架构师作为需求分析师与软件开发工程师之间的核心关键。好的系统架构不但可以满足软件的功能需求有更好的扩展性，可维护性，安全性，可靠性的等等。

系统架构师必须参与到开发的全过程。

系统的需求

一般来说。系统的需求分为：功能性需求与非功能性需求。

系统架构设计影响的原因

系统架构师在进行系统设计的时候一般采用的方式是通过逻辑分层将功能相像的模块放在单独的层中，然后通过分层来实现系统的功能分离与低耦合、高内聚的原则。

系统架构的设计与系统采用的开发方式有关，软件的开发方式可简单分为：传统方式与敏捷开发。

传统方式：大家熟知的瀑布型模式，软件的过程严格的按照上级步骤执行完毕后开始下一步骤。

敏捷开发：则是递增需求的迭代开发。每个阶段都会新增一个需求，完成这个需求之后变发布软件，虽然软件的功能不全，但是至少是可以使用的。

系统架构师的设计方案，最后由项目干系人进行确定，确定采用哪个设计方案，当然最后也可能不采用，造成这样的结果，可能的原因是非功能性需求的原因。非功能性的需求：例如与之前系统的继承，硬件设备，网络环境等等。

系统架构的设计方案

系统架构可以简单的分为隐式架构与显示架构，例如：盖一个小狗的棚子，有经验的架构师在自己的脑海中就已经有了如何去架构。这就是隐式架构。有些情况下：系统的功能比较复杂和细化，我们不可能在脑海中就能想出来如何架构，需要通过做demo或者模块化的划分来设计，这就是显示架构。

系统的架构设计，必须考虑设计的可行性，可扩展性，健壮性，可用性，高效性，安全性等方面，还要考虑软件所处的环境等等，各方面的因素都要考虑，否则等软件开发的过程中发现系统架构设计中的不足再去修改，代价是很昂贵的。

系统架构说明

因为本人初次写博。部分描述不清楚的部分在所难免，错字方面还请见谅，还请大家多多提出交流意见，大家共同提高。

系列之--开卷有益

开篇说明

由于是自己对这些技术的学习总结和心得体会，错误之处在所难免，怀着技术交流的心态，现在发表出来，所以希望大家能够多多指点，这样能使一部分人受益同时也能纠正我的错误观点，以便和各位共同提高！

软件架构到底是什么

软件架构可以被简单的描述为，一系列组件之间的组合，交互，继承的关系。当然这样的解释基本上人人都可以接收。不过在我们看来，这样的说法有点过于抽象。

软件架构有这标准的定义，就是参考ANSI/IEEE的标准，软件架构可以理解为软件密集型系统中对系统的实现和部署起决定性作用的的系统。

软件架构中的关键点是应该符合项目干系人的目标，功能上当然细分成功能性的和非功能性的需求。

软件架构有一定的特殊性，架构设计必须开发的初期就确定，架构设计作为关键决策必须前期确定。

软件架构其实主要是要符合项目干系人的目标，如果无法满足项目干系人的目标，那么这个架构方案就行不通，下图是ANSI/IEEE标准中定义的系统、架构与项目干系人直接的关系。

开篇中已经介绍了系统架构的表述工具有UML和Relation Rose，UML基本上已经成为国际的标准。

UML的类图：主要是描述类之间的关系。

用例图：描述使用场景。

组件图：用来描述系统中的可重用部分。并且容易看出组件与二进制文件之间的对应关系。

通过UML工具，我们能够更深层次对系统架构进行不同角度的描述。抓住其核心。

软件架构的验证，目前没有什么好的办法可以自动验证软件架构是否可以达到项目干系人的目标，只有通过多种方式多个级别的测试。

例如通过单元测试，来验证单一的功能，集成测试来评估系统的兼容性，验收测试来验证用户的满意度,程序是否提供必要的功能。

除了UML建模工具之外，还有IBM比较著名的Relation Rose，这里大概介绍下该工具具有的视图模式：

系统的架构

可以这样说，软件系统的架构过程中没有什么系统是不可拆分的，系统的开发方法越敏捷，为开发人员实现架构是预留的空间越大。

系统架构师将系统分解的过程，其实最终形成的就是一份为开发人员提供的详细设计说明书。当然详细设计说明书的内容和格式也取决于开发方法。

架构是什么

架构大多体现在难以改变或者改变起来代价较大的决定上。但是最终还是需要有人做决定。

系统分析师分析系统做什么，架构师设计如何去做。

架构师是需求与详细说明的纽带。

架构师的职责：架构师应该参与到开发的全过程当中。包括分析需求与架构设计、实现、测试、继承与部署。

按照ISO的定义架构师的定义如下：负责系统架构的人、团队或组织。

微软则对系统架构是做了如下的划分：

1、企业架构师。

2、基础架构师。

3、特定技术架构师。

4、解决方案架构师。

最后总结软件开发过程中的一些法则：

1、为了一个赶不上进度的项目增加人手，只会让项目更加落后于进度。

2、程序的复杂性会一直的增加，直到维护人员感觉到力不从心为止。

3、建筑师与开发人员写程序不同，如果建筑师按照开发人员的方式开建造，只会成为历史中的败笔。

系列之---系统建模[上篇]

一、摘要

本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作和学习过程中的总结和经验，不足之处还请大家多多批评指出，有更好的建议也可以留言说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具，或者不熟悉如何根据需求去建立模型的角度出发，简单的阐述了在系统架构的过程中我们应该从什么样的角度出发去分析需求并且建立抽象模型。这应该说是架构师必备的技能。

本文由浅入深，本篇将简单的介绍如何使用使用UML建模中的各个结构图与行为图，去完成抽象模型的建立。

二、本章内容

1、摘要。

2、本章内容。

3、建模工具介绍及使用。

4、建模中的抽象模型图。

5、本质总结。

6、系列进度。

7、下篇预告。

三、建模工具介绍

介绍建模工具之前，我们先来简单介绍下建模语言的定义。建模语言就是基于一系列规则、符号、图表、关键字的图形化或文本语言。建模语言的主要作用是对模型的结构与行为进行描述。并且能够将知识和信息通过模型传递给熟悉该描述语言的人。

当今的建模语言其实并不少，其中比较有规模的如下图：

不过最流行、最常用的当属UML建模语言(Unified Modeling Language) 统一建模语言。经过不断的发展，目前UML已成为业界公认的标准的建模语言。

我们先来了解下UML建模语言的起源：

回顾20世纪晚期--准确地说是1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）。UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。UML提出了一套IT专业人员期待多年的统一的标准建模符号。通过使用UML，这些人员能够阅读和交流系统架构和设计规划--就像建筑工人多年来所使用的建筑设计图一样。

到了21世纪--准确地说是2003年，UML已经获得了业界的认同。在我所见过的专业人员的简历中，75%都声称具备UML的知识。然而，在同绝大多数求职人员面谈之后，可以明显地看出他们并不真正了解UML。通常地，他们将UML用作一个术语，或对UML一知半解。大家对UML缺乏理解的这种状况，促进我撰写这篇关于UML 建模。当阅读完本文时，您还不具备足够的知识可以在简历上声称自己掌握了UML，但是您已具有了进一步钻研该语言的良好起点。

四、建模中的抽象模型

既然UML语言如此流行，本系列中也只用UML语言来进行建模，本系列中的后续章节也将基于UML建模图来完成相应的设计。

学习过UML语言的开发人员都知道UML分为以下几类模型图：

通过上图我们知道UML的分类，分为结构型与行为型建模图形。下面的内容将详细的讲述每种建模图形的使用场景及如何使用。

行为型：

我们先从行为型的建模图形来开始讲起：

1、用例图：

我想用例图大家都应该基本上有所了解，只要使用过UML建模的除了基本的流程图基本上大家都会的使用外，用例图用过是最常见的一种建模图形。

用例图中主要包含的元素：系统、参与者、用例、关系。

用例图主要的应用场景：一般用例图用来描述需求中的系统应具有的功能,系统参与者(使用者,维护者、外部系统或者用户等)与系统如何交互进行一个模型话的描述。

用例图的目的：帮助开发团队以一种可视化的方式理解系统的功能需求。

一般使用如下方式来进行操作：

用来标识系统的参与者，任何与系统交互的对象，都可以叫参与者。

是用来描述系统中的某个模块与参与者的一次交互过程。

系统参与者与用例之间的具体关系通过如下连线标示：

这几类不同的连线来标识不同的用例之间或者用例与参与者或者2个参与者直接直接的关系。

UML定义了3类标准的关系：

第一种：包含，通过一条直线链接2个用例,因此是用例之间的关系链接，表述了箭头的开始一端包含箭头指向的一端的用例。

例如：

第二种：扩展，通过一个反向的直线来标识某个用例扩展了另外一个用例的行为，一般情况下箭头指向的用例即是被扩展的用例。

例如：

第三种：泛化，用来标识具有同质关系的参与者与参与者或者用例与用例之间的关系，泛化类似继承关系。箭头指向的为父元素。

例如：

除了以上的3中关系还有一种未列在规范关系的我们把它叫做关联关系。这种关系是用来描述用例与参与者直接的关系的。是通过一条直线来完成链接的，泛化关系描述了链接的2个部分存在某种程度的交付。一般情况下，我们可以系统的功能情况分析出系统中的主动发和被动方。

如何使用用例图:

第一步：先把系统按照功能进行划分，比如一个简单的内容管理系统。先把他细化，细化成多个模块功能。每个模块的功能相对独立，但是可能又与另外一个有交互。

第二步：把功能需求抽象,达到高内聚，低耦合的标准，然后分析出该模块功能的参与者是什么，例如用户是谁？或者细分成角色,与该模块交互还可能是数据库？等,把所有交互的对象分析出。

第三步：把系统模块中的每个功能模块看是否能再按照子功能进行细分，细分后形成具体的用例。

第四步：分析用例与参与者之间的关系，分析同质对象(参与者与参与者、用例与用例)之间的关系。

第五步：根据以上四步完成建模。在建模的过程如果发现某块功能不清晰或者参与者不清晰，可重复前4步。

2、类图：

类图也是UML建模中最常用的一种结构图，类图用来标示系统的静态结构。静态结构是由类型及关系构成。

类图表示不同的实体（人、事物和数据）如何彼此相关；换句话说，它显示了系统的静态结构。类图可用于表示逻辑类，逻辑类通常就是业务人员所谈及的事物种类--摇滚乐队、CD、广播剧；或者贷款、住房抵押、汽车信贷以及利率。类图还可用于表示实现类，实现类就是程序员处理的实体。实现类图或许会与逻辑类图显示一些相同的类。然而，实现类图不会使用相同的属性来描述，因为它很可能具有对诸如Vector和HashMap这种事物的引用。

类图其实就是一个长方形，内部分成3个区域。每个区域的含义不同。

类图中也有命名空间的概念，是通过包来实现的如果想定义该类在某个命名空间中，则在定义类名时按照如下类似格式标示

命名空间 :: 类名 [必须按照这样的形式才可以]。

类图中的有3类修饰符，每种修饰符标示的含义不同。

具体用法如下：

理解成具体的类代码的格式如下：

public class Product

{

Public string ProductName;

public void GetProductLists(string sWhere)

{

//TODO….

}

}

如果在类图中的属性定义与函数成员的定义是斜体表示的话，则表名该成员是虚成员。

虚成员

如果在类图中的属性定义与函数成员的定义是带下划线的话，则表名该成员是静态成员。

静态成员

当然这是最基本的类图，还有一种特殊的，类图支持参数化类型即是.NET中的特殊类型[泛型格式]标示。

参数化类图

具体的表示形式如：该符号在类的右上角有个长方形其中可输入类型如上图。

类图中属性包含的元素：

访问修饰符：Public、Protected、Private

特性/属性名称：特性/属性名称

类型：可以是自定义类型或者是系统类型。

默认值：即特性/属性的默认值，如果有的话。

重复性：可以用来定义多个对象的集合，特性值中包含的对象个数。

类图中操作包含的元素：

访问修饰符：Public、Protected、Private

操作名称：函数名称

操作列表：函数的参数列表。

返回值：函数的返回值，如果有的话。

函数参数列表中的参数方向：

类图之间的关联关系

首先我们知道，我们在设计类的时候就是把独立的功能放在一个类中，不同的类之间进行交互，那么我们在类图中如何去表述这样的类之间的关系呢？

类图直接的关系：

1、关联关系：关联标识2个类直接存在关系。是通过一条线来表示，关联关系中包含了2种特殊的关系：聚合和组合

聚合代表的2个类直接是has-a的关系，即部分与整体的关系，具体的图标通过一条虚线带有菱形箭头，箭头指向的方向即是整体的部分，代表该类包含另一部分。

聚合例如：

代表产品中具有ProductName这个成员。

组合举例：组合关系的标示与聚合比较类似，唯一区别实心的菱形。

组合例如：

组合与聚合的区别：

在聚合关系中被包含对象可能不完全依赖容器对象，也就是说ProductName不完全依赖Product。如果Product对象销毁，但是可能ProductName对象没有被销毁。可以这么想想产品的分类不会因为产品销毁而不存在。

组合关系中则是比聚合的关联程度更高,Product完全包含ProductName。如果销毁Product时，那么ProductName也一定被销毁。产品从数据库被删除了，那么与产品相关的的数据列属性也被删除了，这里只是举例子，可能不太合适。

类图之间的泛化关系

泛化关系：存在2个类之间。一个类是另外一个类的子类，表示一个类是另外一个类的特例。

表示方法：通过一个带有空的三角形箭头的线段标识，箭头指向父类型。

表示火车和汽车是交通工具的子类型。

类图之间的依赖关系

依赖关系描述为：一个类型必须依靠另外一个类才能实现相应的功能。最简单的理解方式：依赖注入中的构造函数注入。

具体的表示方法：一个带有箭头的虚线段。箭头方向标示被依赖的类型。

例如：

五、本章总结。

本章主要是对UML有个简单的介绍及详细介绍了如何构建UML图形中的用例图与类图。这是我们在建模时常用的2类图形。也是必须掌握的建模图形。

同时通过本质我们应该大脑中对UML有个新的认识，UML建模可以让我多个角度的去分析问题，然后不断的改进设计，同时能很清晰的表达功能需求功能的分离和组合关系。本文只是简单的抛砖引玉，不足之处，在所难免，请大家批评指出。

系列之---系统建模[中篇](上)

一、上章回顾

上篇文章主要简单的介绍了建模中使用的标准建模语言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所有的建模图形介绍完毕后，我将针对如何我目前遇到一些问题进行分析讲解，如何遇到功能需求进行功能的分离及建模。希望大家多多提出宝贵意见。

作者：CallHot

出处：http://www.cnblogs.com/hegezhou_hot/

关于作者：专注于微软平台项目架构、管理和企业解决方案。熟悉设计模式、极限编程、架构设计、敏捷开发和项目管理。现主要从事WinForm、ASP.NET、等方面的项目开发、架构、管理工作。如有问题或建议，请多多赐教！

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，如有问题，可以通过hegezhou_hot@163.com 联系我，非常感谢。