OOAD利器之UML基础

UML：Unified Modeling Language，即统一建模语言，简单地说就是一种有特殊用处的语言。本文是我初步学习UML的学习笔记，对于我们菜鸟码农来说，让我们做设计的可能性不大，但至少能看懂是必要的。

一、所谓模型

1.1 模型是对现实的简化

　　模型是提供系统的蓝图，模型可是包括详细计划。也可是是从更高程度考虑系统的总体计划，每个系统可以从不同的方面用不通过的模型来描述。因而每个模型都是在语义上闭合的抽象系统。模型可以是结构性的，强调系统的组织。也可是是行为性的，强调系统的动态方面。

1.2 为什么要建模？

　　有人云：建模是为了能够更好地理解正在开发的系统！

　　通过建模可以达到如下目的：

　　1、模型有助于按照实际情况或按照所需的样式对系统进行可视化；

　　2、模型能够规约系统的结构或行为；

　　3、模型给出了构造系统的模板；

　　4、模型对做出的决策进行文档化；

PS：对于一个复杂的系统，如银行、电信系统建模的重要性就越大。如果不能很好的理解一个复杂系统，盲目开发，失败的可能性很大。

二、小谈UML

2.1 神马是UML？

　　统一建模语言(Unified Modeling Language , UML) 是一种绘制软件蓝图的标准语言，可以用UML对软件密集的制品进行可视化、详述、构造和文档化。

2.2 UML的优点

　　1、可视化：清晰的模型有利于交流

　　2、详述：可以使用UML对分析、设计、实现等决策进行详细描述

　　3、构造：把UML描述映射成编程语言

　　4、文档化：系统的所有细节都可以是UML进行描述。如：项目计划、发布活动等

2.3 应用领域

　　1、企业信息系统

　　2、银行与金融服务

　　3、电信

　　4、国防、航天

　　5、科学

　　6、基于Web的分布式服务

三、类图—分析业务模型

3.1 类

　　类是一组具有相同属性、操作、关系和语义的对象描述，一个类可是实现一个或者多个接口。下图是类在VS里面的图形表示：

　　（1）UML预设了四种可见性，分别为公开(public)、私有(private)、保护(protected)、包(package) 减号(-)为私有可见性，加号(+)为公开可见性。可见，上图中的类图所有都为public。

　　（2）在UML中抽象类与普通是同一个是图表示，只是名字会变成斜体，如下图所示，调整IsAbstract属性为True后类名变为斜体：

3.2 关系

　　关系是事物之间的联系，在面向对象的建模中，有三种重要的关系是依赖、泛化、关联。

　　（1）依赖

　　依赖是一种使用关系，一个事物使用另一个事物。在图形上，把依赖画成一条有方向的虚线，指向被依赖的事物。如果被使用的类发生变化,那么另一个类的操作必然受影响。依赖关系在.net语言中体现为 局部变量、方法的参数或者对静态方法的调用，如工具类，现实生活中人与锤子。

　　（2）泛化

　　在泛化关系中，子类继承了父类的行为和含义，子类也可以增加新的行为和含义或覆盖父类中的行为和含义。在图形上，在泛化画成一个带有空心三角行指向父类。泛化在.net中就是一个继承的关系。

　　（3）关联

　　关联是一种结构关系，它指明一个对象与另一个对象间的关系。

　　①相互关联体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，是一种长期的稳定的关系；表现在代码层面，为被关联类以类属性的形式出现在关联类中，也可能是关联类引用了一个类型为被关联类的全局变量。

　　上图中ClassA与ClassB相互关联，在代码中各自有对方类型实例的一个属性。

　　②单向关联表现在代码层面，为被关联类B 以类属性的形式出现在关联类 A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；

　　上图中Subject关联Observer，并且是一个一对多的关系，那么在代码中Subject类中会有一个Observer类对象的集合属性。

　　下面我们来看看几种特殊的关联关系，他们是：

　　③聚合关系：

　　聚合是关联关系的一种特例，他体现的是整体与部分拥有的关系。此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如汽车与发动机；表现在代码层面，和关联关系是一致的，只能从语义级别来区分。

　　④组合关系：

　　组合也是关联关系的一种特例，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束。例如：孕妇死了胎儿自然也就死了（有点血腥的例子，抱歉！）；表现在代码层面，和关联关系是一致的，只能从语义级别来区分。

3.3 接口

　　接口(interface)如同契约，负责的类必须负责实现它的公开操作，以及负责维护它的公开属性。

3.4 综合案例：公司-部门-员工类图关系

四、用例图—描述系统的行为

　　用例图用来表达系统对外提供的服务或功能，适合用来作为需求搜集阶段的工作。

4.1 用例与执行者

　　实际设计中，常用用例(UseCase)来表达系统需求或者系统对外呈现的行为。用例采用椭圆图示，参与者(Actor)是人型图示。由于它会参与系统的运作，因此它跟用例之间有连接线段。

4.2 包含关系

　　包含（include）关系指的是两个用例之间的关系，其中一个用例（称作基本用例，base use case）的行为包含了另一个用例（称作包含用例，include case）的行为。如下图，取款的时候会包含一个用户验证的用例。

4.3 扩展关系

　　扩展（extend）关系将基本用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。如下图，我们在取完款后，可以打印凭条，也可以不用打印凭条。这个功能就可以使用扩展来表示。