| 编辑推荐: |
文章主要介绍了UML的概述、定义、组成及五类图形。
本文来自于csdn，由火龙果软件Linda编辑、推荐。 |
|
为什么需要UML？ 
建模是管理软件开发复杂性的有效手段，使用UML给出的需求规格、总体设计、概要设计、详细设计等的图形表示，有助于参加软件产品开发的各方更好的交流，沟通、讨论。由于软件的逻辑复杂、需求易变性，使得软件的开发、测试和维护活动很复杂，并且软件的发展使得软件成为市场竞争中的一个关键因素。因此，开发者需要更好的理解他们正在构建什么，建模可以提供有效的方法，并且不一定要影响开发速度。客户和业务用户始终希望软件能够按时交付，以能够像所期望的那样具有随需应变的功效。
通过软件建模，开发人员能够：
1）在提交额外的资源之前创建并交流软件设计。
2）从设计追溯到需求阶段，有助于确保构建正确的系统。
3）进行迭代开发，在开发中，模型和其他的更高层次的抽象推动了快速而频繁的变更。
UML的概述
模型是对现实世界中的物体或系统的简化或图形表示。例如，地球仪、建筑模型、工程中的设计图纸、机器零件的设计图纸等。所以，我们要用工程化的方法开发软件产品，自然就引入了软件模型的概念。UML可以用于对任何复杂的系统建模，主要还是对软件系统建模。
建模应用于复杂的系统构建中，有时候是物理模型，如飞机、汽车、房子等的按照一定比例制作的实物模型，有时候是商业金融模型、市场贸易模拟以及电子电路图。 
UML的定义
Unified Modeling Language（UML），统一建模语言，UML的定义包括UML语义和UML表示法两个部分。
（1）UML语义
指UML元素符号代表的含义，描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
（2）UML表示法
定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。 UML的组成
模型 是一个特定系统的完整描述。 
UML中的视图
1.用例视图（Use Case View），强调从用户的角度看到的或需要的系统功能，是参与者的外部用户所能观察到的系统的功能的模型图。
2.逻辑视图（Logical View），展示系统的静态或结构组成及特征，也称为结构模型视图（Structural
Model View）或静态视图（Static View）。
3.并发视图（Concurrent View）体现了系统的动态或行为特征，也称为行为模型视图（Behavior
Model View）或动态视图（Dynamic View）。
4.组件视图（Component View）体现了系统实现的结构和行为特征，也称为实现模型视图（Implementation
View)。
5.配置视图（Deployment View）体现了系统实现环境的结构和行为特征，也称为环境模型视图（EnvironmentModel
View）或物理视图（Physical view）。
UML中的5类图形 
在需求阶段，通过用例建模，描述用户感兴趣的系统功能。
在静态分析阶段，主要识别系统中的类及其关系，用UML类图来描述系统。
在动态分析阶段，尝试组织多个对象，并构思对象的交互与协作，以实现和检验用例的可行性，可以用UML动态模型来描述。
在测试阶段，不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用组件图和协作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段时确定的需求。
类图
**类(class)：**一类或一组具有类似属性和共同行为的事物。 
建立类图的步骤：
1.研究分析问题领域，确定系统需求
2.发现对象和类，明确他们的含义和责任，确定属性和操作
3.发现类之间的静态联系。（关联、泛化、聚合、组合、依赖）
4.设计类和联系，调整和精化已得到的类之间的联系，解决命名冲突和功能重复问题
5.绘制类图并编制相应的说明
对象图
某台具体的洗衣机就是洗衣机类的一个对象。
比如：小明家的海尔洗衣机 
用例图
1.用例(use case)：从用户的观点对系统行为的一个描述。
2.用来从用户的观察角度收集系统需求。
3.用例图表达系统的外部事物（参与者）与系统的交互，它表达了系统的功能，即系统所提供的服务。
4.整个软件项目的开发可以采用Use Case 驱动的方式进行。 
一个Use Case图可以按照下列步骤建立
1.找出系统外部的活动者和外部系统，确定系统的边界和范围
2.确定每一个活动者所期望的系统行为
3.把这些系统命名为Use Case
4.把一些公共的系统行为分解为一批新的Use Case,供其它的Use Case引用。把一些变更的行为分解为扩展的Use
Case
5.编制每一个Use Case的剧本(一系列步骤地描述，这些不走构成了剧本)
6.绘制Use Case 图
7.区分主业物流和例外情况的事件流。可以把表达例外情况的事件流的Use Case画成一个单独的子Use
Case图
8.精化use Case图。解决Use Case间的重复与冲突问题，简化use Case中的对话序列。Use
Case图可以有不同的层次，高层次的Use Case可以分解为若干个下属子系统中的Use Case
活动图
活动图实质上是一种流程图，只不过表现的是从一个活动到另一个活动的控制流。活动图描述活动的序列，并且支持对带条件的行为和并发行为表达。
1.活动图着重描述活动和大的过程，它们可能与方法或成员函数及其活动序列相对应，也可能不对应。从这种意义上，它很像流程图，而不同之处是活动图显式支持并发活动和它们的同步。
2.活动图最大的不足之处是它们没有显式表示出哪个对象执行哪个活动以及它们之间的消息工作方式。你可以为每个活动标记上负责的对象，但那不会使对象之间的交互变得清晰（那就是你要使用交互图的时候了）。一种常能凑效的方法是，在为一个过程建模的早期，先画活动图来帮助你获得对整个过程的理解。然后你可以用交互图来帮助你将活动分配到类中。
状态机图
1.在任一给定的时刻，一个对象总是处于某一特定的状态。
2.状态机图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作。 
顺序图
1.在一个运行的系统中，对象之间要发生交互，并且这些交互要经历一定的时间。
2.顺序图表达的正是这种基于时间的动态交互。重点是完成某个行为的对象类和这些对象类之间所传递的消息的时间顺序。 
序列图的内容
在序列图中可以有对象和actor实例，以及说明它们如何交互的消息。序列图描述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对象如何通过相互发送消息进行通信。您可以为用例事件流的各种不同形式制作序列图。
什么时候使用
在你要分析一个用例中多个对象的行为时，就应该使用交互图。它们很有效地表示对象之间的合作，但并不那么适用于精确定义行为。
如果你想分析一个对象在多个用例中的行为，请使用状态转移图。如果你想分析交叉于多用例或多线程中的行为，考虑用活动图吧。 
通讯图
通讯图通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。
通讯图的图例
协同图的建立步骤：
1.确定交互的上下文
2.找出参与交互的对象角色，把他们作为图形的节点安置在协同图中
3.设置对象的初始性质
4.说明对象之间的链接，首先给出对象之间的关联链接，然后给出其他链接
5.从初始化交互的消息开始，在链接上安置相应消息。给出消息序号。注意用箭头的形势区别同步消息和异步消息。根据协作图是属于说明曾换是属于实例层，给出消息标签的内容，以及必要的构造型约束。
6.处理一些特殊情况，如循环、自调用、回调、多对象等。
交互图
1.顺序图和通讯图都是交互图，它们既是等价的，又是有区别的。
2.顺序图和通讯图都能等价的表现系统运行中对象通过消息发生的交互行为。
3.顺序图表示了时间的消息序列，便于分析交互的时序，但没有表示静态对象关系，顺序图可以有效地帮助人们观察系统的顺序行为。
4.通讯图着重表示一个协作中的对象之间的联系和消息。
构件图
构件图是代码构件的物理结构，以及构件之间的依赖关系。在物理层面对系统结构及内容的直观描述，最接近于通常意义上的模块结构图。 
部署图
显示基于计算机系统的物理体系结构。
UML的应用领域
1.UML的目标是以面向对象图的方式来描述任何类型的系统。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。
2.UML模型可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和协作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。 
——————————————————————————————————
选取一个过程——RUP
一个简单的案例
1.CMS系统
2.该系统需求非常简单，大致课做如下描述：
3.这个系统主要用来发布新闻，管理员只需要一个，登录后可以在后台发布新闻。任何人可以浏览新闻，浏览者可以注册成为系统会员，注册后可对新闻进行评论。管理员在后台可以对新闻、评论、注册会员进行管理，如修改、删除等。 
——————————————————————————————————
1.与用户进行访谈，并且做好记录，了解用户的业务流程。
2.在访谈过程中，抽象出系统的“词汇”，画出领域类图。
3.画出业务用例图，用来与用户沟通”系统应该实现什么样的业务”。
——————————————————————————————————
完成了业务用例图后，我们要为每一个业务用例绘制一幅活动图。活动图描述了这个业务用例中，用户可能会进行的操作序列。活动图有个很重要的使命：从业务用例分析出系统用例。例如，下面是“新闻管理”的活动图。 
——————————————————————————————————
1.将每个业务用例都绘制出相应的活动图，再将其中的“活动”整合，就得出所有备选系统用例。
2.找出所有的备选系统用例后，我们要对他们进行合并和筛选。合并就是将相同的用例合并成一个，筛选就是将不符合系统用例条件的备选用例去掉。一个系统用例应该是实际使用系统的用户所进行的一个操作。 
——————————————————————————————————
得出系统用例图后，我们应该对每一个系统用例给出用例规约。关于用例规约，没有一个通用的格式，大家可以按照习惯的格式进行编写。对用例规约唯一的要求就是“清晰易懂”。
下面给出“登录”这个系统用例的一个规约： 
——————————————————————————————————
在设计阶段，需要绘制实现类图和包图。同时还涉及到组件图，时序图，协作图等。
实现类图和领域类图不一样，它描述的是真正系统的静态结构，是和最后的代码完全一致的。因此，它和平台关系密切，必须准确给出系统中的实体类、控制类、界面类、接口等元素以及其中的关系。—————————————————————————————————— 
有了静态结构，我们还要给出动态结构，这样，才能看清系统间的类是如何交互的，从而有效帮助程序员进行编码工作。
时序图在实际中是很多的，几乎每个类方法都配有相应的时序图。 
|
