系统架构师-基础到企业应用架构-系统建模[上篇]
本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作和学习过程中的总结和经验，不足之处还请大家多多批评指出，有更好的建议也可以留言
说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具，或者不熟悉如何根据需求去建立模型的角度出发
一、摘要
本文主要从系统架构中的建模开始讲解，本文讲述的内容主要是我在工作和学习过程中的总结和经验，不足之处还请大家多多批评指出，有更好的建议也可以留言
说明。本意主旨是为不熟悉系统架构建模过程和不知道如何使用建模工具，或者不熟悉如何根据需求去建立模型的角度出发，简单的阐述了在系统架构的过程中我们应
该从什么样的角度出发去分析需求并且建立抽象模型。这应该说是架构师必备的技能。
本文由浅入深，本篇将简单的介绍如何使用使用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建模可以让我多个角度的去分析问题，然后不断的改进设计，同时能很清晰的表达功能需求功能的分离和组合
关系。本文只是简单的抛砖引玉，不足之处，在所难免，请大家批评指出。
六、系列进度。
4、系统架构师-基础到企业应用架构-系统建模[中篇](下)
5、系统架构师-基础到企业应用架构-系统建模[下篇]
不断更新中(请持续关注…)
七、下篇预告。
下一篇中将介绍UML建模过程中其他的比较常用的UML建模图形：顺序图、组件图、状态图等。