UML简介（二）
静态建模主要包括
1. 用例图，主要坐拥是描述需求；
2. 静态图，包括类图、对象图和包图，主要作用是描述类的结构；
3. 实现图，包括组件图、部署图，主要作用是描述软件结构；
动态建模主要包括
1. 行为图，包括状态图、活动图，主要作用是描述动态建模；
2. 交互图，包括序列图、协作图，主要描述交互关系。
UML每一个视图针对团队中的不同受众
1. 系统的用例视图面向最终用户和测试人员；
2. 系统的逻辑试图面向分析人员和设计人员；
3. 系统的组件试图面向系统集成人员和编程人员；
4. 系统的部署视图面向系统和网络工程师；
UML建模过程
1. 需求分析——用例图；
2. 系统分析：分析业务规则——状态图；
3. 系统分析：分析业务流程——活动图；
4. 系统设计：设计静态结构——类图和包图；
5. 系统设计：类被调用关系——序列图；
6. 系统设计：用户调用类的过程——协作图；
7. 系统架构——组件图和部署图。
用例图
用例图主要用于系统的初期进行系统需求分析，用于描述系统有哪些功能，从用户的角度观察系统应支持哪些功能，帮助分析人员理解系统的行为，同时也可以帮助测试人员了解系统有哪些功能，便于编写测试用例。
一个系统中可以有多个用例图，每个用例图可以用来表示其中一个模块应有的功能。
用例图主要包括参与者、用例、系统边界、通信关联 四种组成部分。
参与者是指与系统发生交互的人或者其它系统或者其它模块。
用例是指系统应该提供的服务。
系统边界，用于圈定系统所处子系统的范围。
通信关联描述了参与者与用例之间的交互关系。
面向对象的问题的处理的关键是建模问题。建模可以把在复杂世界的许多重要的细节给抽象出。许多建模工具封装了UML（也就是Unified Modeling Language"），这篇课程的目的是展示出UML的精彩之处。
UML中有九种建模的图标，即：
l 用例图
l 类图
l 对象图
l 顺序图
l 协作图
l 状态图
l 活动图
l 组件图
l 配置图
本课程中的某些部分包含了这些图的细节信息的页面链接。而且每个部分都有一个小问题，测试一下你对这个部分的理解。
―――――――――――――――――――――――――――――――――――――――
为什么UML很重要？
为了回答这个问题，我们看看建筑行业。设计师设计出房子。施工人员使用这个设计来建造房子。建筑越复杂，设计师和施工人员之间的交流就越重要。蓝图就成为了这个行业中的设计师和施工人员的必修课。
写软件就好像建造建筑物一样。系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。现在它已经成为了软件行业的一部分了。UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。
UML被应用到面向对象的问题的解决上。想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。一个模型model就是根本问题的抽象。域domain就是问题所处的真实世界。
模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。记住把一个对象想象成“活着的”。对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。对象的属性的值决定了它的状态state。
类Classes是对象的“蓝图”。一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。对象是类的实例instances。
――――――――――――――――――――――――――――――――――――――
用例图
用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。强调这个系统是什么而不是这个系统怎么工作。
用例图与情节紧紧相关的。情节scenario是指当某个人与系统进行互动时发生的情况。下面是一个医院门诊部的情节。
“一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录。”
用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和。角色actor是发动与这个工作有关的事件的人或者事情。角色简单的扮演着人或者对象的作用。下面的图是一个门诊部Make Appointment用例。角色是病人。角色与用例的联系是通讯联系communication association（或简称通讯communication）
角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线。
一个用例图是角色，用例，和它们之间的联系的集合。我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分。注意一个单独的用例可以有多个角色。
用例图在三个领域很有作用。
l 决定特征（需求）。当系统已经分析好并且设计成型时，新的用例产生新的需求
l 客户通讯。使用用例图很容易表示开发者与客户之间的联系。
l 产生测试用例。一个用例的情节可能产生这些情节的一批测试用例。
?/P>
类图
类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。
下面是一个顾客从零售商处预定商品的模型的类图。中心的类是Order。连接它的是购买货物的Customer和Payment。Payment有三种形式：Cash，Check，或者Credit。订单包括OrderDetails（line item），每个这种类都连着Item。
UML类的符号是一个被划分成三块的方框：类名，属性，和操作。抽象类的名字，像Payment是斜体的。类之间的关系是连接线。
类图有三种关系。
l 关联association－表示两种类的实例间的关系。如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联。在图中，关联用两个类之间的连线表示。
l 聚合aggregation－当一个类属于一个容器是的一种特殊关系。聚合用一个带菱形的连线，菱形指向具有整体性质的类。在我们的图里，Order是OrderDetails的容器。
l 泛化generalization－一个指向以其他类作为超类的继承连线。泛化关系用一个三角形指向超类。Payment是Cash，Check和Credit的超类。
一个关联有两个尾端。每个尾端可以有一个角色名role name来说明关联的作用。比如，一个OrderDetail实例是一个Order实例的项目。
关联上的方向性navigability箭头表示该关联传递或查询的方向。OrderDetail类可以查询他的Item，但不可以反过来查询。箭头方向同样可以告诉你哪个类拥有这个关联的实现；也就是，OrderDetail拥有Item。没有方向性的箭头的关联是双向。
关联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的格数，通过这种方式表达关联的多样性multiplicity。多样性的数字可以是一个单独的数字或者是一个数字的范围。在例子中，每个Order只有一个Customer，但一个Customer可以有任意多个Order。
下面这个表给出了最普遍的多样性示例。
| 多样性 |
意义 |
| 0..1 |
0或1个实例. n..m符号表示有n到m个实例 |
| 0..* or * |
没有实例格数的限制（包括没有）. |
| 1 |
只有一个实例 |
| 1..* |
最少一个实例 |
包和对象图
为了简单地表示出复杂的类图，可以把类组合成包packages。一个包是UML上有逻辑关系的元件的集合。下面这个图是是一个把类组合成包的一个商业模型。
包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线箭头表示依赖dependencies关系。如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。
对象图Object diagrams用来表示类的实例。他们在解释复杂关系的细小问题时（特别是递归关系时）很有用。
这个类图示一个大学的Department可以包括其他很多的Departments。
这个对象图示上面类图的实例。用了很多具体的例子。
