UML九种图与软件开发

 【前言】

 作为面向对象的设计工具，我们需要在具体的实践过程中不断熟识，在学习的过程中经常动手去画一画，实践是我们巩固知识的一把利刃。就在这一次次的操作实践的积累下，知识不断丰富，具体的一些操作问题也会解决。UML四种关系和九种图在UML学习中是重中之重，而在这九种图中最重要的是用例图，类图和顺序图，反复的学习才能将它消化。

 根据UML表示机制的层次划分为用例图、类图、行为图、实现图。也可以很具静态动态划分（静态图包括：类图，对象图，用例图，构件图，部署图；动态图包括：状态图，顺序图，活动图，协作图。）

• 用例图：从用户角度描述系统功能，并指出各功能的操作者。

• 静态图：包括类图和对象图。类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是一种静态关系，在系统的整个生命周期都是有效的。对象图是类图的实例，几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

• 行为图：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件，状态图是对类图的补充，活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并进行活动。

• 交互图：描述对象间的交互关系，包括时序图和协作图。时序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；协作图描述对象间的协作关系，协作图跟时序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系。如果强调时间和顺序，则使用时序图；如果强调上下级关系，则选择协作图。

• 实现图：包括组件图和部署图。组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度；部署图定义系统中软硬件的物理体系结构。

  
  

  【思维导图】

 【说明】

1、用例图

    描述角色以及角色与用例之间的连接关系。指出了使用者以及使用该系统可以做些什么。模型元素：系统、参与者和用例。并包含四种关系关系，如泛化、关联和依赖。

2、类图

    类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。

3、对象图

    与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。

4、活动图

    描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

5、状态图

    描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。

6、序列图

    序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图

    和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。

8、构件图 

    描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。

9、部署图 

    是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。

 【UML与软件开发】

  如果把软件开发比作学校建一座高楼，那么软件工程就是知道我们怎么盖，不至于在构建一座大楼的时候，最后不知不觉变成四不像。而UML图正是对大楼主体架构的设计。软件工程是软件开发设计的灵魂，是我们前进的思想性指导。它使我们的设计有法可依，有章可循。比如我们学校现在盖的大楼，必须要有蓝图来规划哪块哪块盖什么楼，什么类别的都是前期需要用例建模来具体协商的。

 具体步骤：

  1.前期的需求分析描述需要用例图，用例图的使用者是学校，了解这栋大楼的主体结构，功能是什么，教学楼还是宿舍。学校最关心的是楼质量问题和安全性，是否能够满足学生的基本使用。

  2.进一步需要设计楼内部的具体结构，此时就需要类图，对象图，组件图和部署图来制定标准化的结构，详细的描述内部需求和具体设施的安排，为具体施工指明工作点。

  3.接下来就需要安排具体的人员开工，活动图安排各个工种在自己的岗位工作；状态图安排施工设备的使用情况，表明设备的忙碌和空闲状态；而具体施工步骤需要工程安排每一块的开始，不能先上后下，从基地开始。此

外还需要各个施工队的协作，连接性是这个工程的最后标志，各个团队之间必须密切协作才能完成整体的。

             

【详解】

1、需求分析

   用例图用来建模客户的需求。角色以及系统功能建模是用例建模来画的。它们之间的关系建模被用于角色和用例。每个用例都代表了客户的需求。需求分析不仅适用于软件系统进行而且适用于建筑工程行业。

2、分析

   此阶段是寻找问题 -就是找刺的，需要考虑系统可能遇到的问题是主要的工作。借助于逻辑视图和动态视图实现。系统的静态由类图来建模，系统的动态则是协作图、序列图、活动图和状态图建模。只是列出系列的问题和稍微一点解决思路，不作出详细的解决方案。只是大方向上的做出引导，提纲，具体细节需要下一阶段结合实际分析。

3、设计

   将分析阶段列出的问题进行汇总，根据提纲作出具体、细节办法。进而把分析结果扩展为技术层次的解决依据，不在停留在文字方面，需要依靠用户接口提供技术基础结构。数据库在这个技术基础结构中，分析阶段的领域问题类被嵌入在其中。构造阶段的详细的规格说明是设计阶段的结果。

4)构造

   把设计阶段的类转换成某种面向对象程序设计语言的代码。只能在构造阶段实现代码的转变，其他阶段不能！在对UML表述的分析和设计模型进行转换时，最好不要直接把模型转化成代码。在早期阶段，模型是理解系统并对系统进行结构化的手段。

5)测试

   根据测试的先后顺序排序：单元测试、集成测试、系统测试和接受测试。不同的测试采用不同的UML图作为工作的基础。类图和类的规格说明是单元测试；组件图和协作图的是集成测试；系统测试实现用例图来确认系统的行为符合这些图中的定义。

   在系统测试阶段，UML模型还可以作为测试阶段的依据。如单元测试使用类图和类规格说明；集成测试使用组件图和协作图；系统测试用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。