UML基础学习及资源总结-控件新闻-慧都网

UML基础学习及资源总结

原创|使用教程|编辑：郝浩|2014-12-03 13:21:08.000|阅读 1874 次

概述：UML是学习软件工程的一门必修课，在这里我们总结了一些UML基础知识点和学习的相关资源。

1.什么是UML?

OMG组织规范声明如下 :

"统一建模语言(UML)是一种图形化的语言，用于软件密集系统要素的可视化、制定规范、构建对象和编写文档。UML提供了一种标准的方式来描述系统的设计图，既包括概念方面，例如业务过程和系统功能，也包括具体事务，如编程语言语句，数据库图示和可重用的软件组件。

这里着重指出的是UML是一种说明性的“语言”，而不是一种方法或程序。UML通常用来定义软件系统与细化、编写、构造系统中的要素，是“写”设计图的语言。UML可以用不同的方式来支持软件开发方法(例如：统一软件开发过程)-但是它本身并不指定某种方法或过程。

2.UML定义的标注和语义

用户交互或用例模型：描述系统和用户之间的界定和交互。在某些方面对应于一个需求模型。
交互或通信模型：描述系统中的对象彼此之间如何进行交互以完成工作。
状态或动态模型：状态图表描述随着时间变化，类所呈现的状态和条件。活动图则描述系统即将执行的工作流程。
逻辑或类模型：描述构成系统的类和对象。
物理组件模型：描述构成系统的软件(有时也包含硬件)。
物理部署模型：描述物理架构与物理架构中组件的部署。

UML 也定义了一些扩展机制，以扩展UML符合特别需要(例如：业务过程建模的扩展)。

3.UML中的13种基本图

1）结构建模图

结构图定义了一个模型的静态架构。它们通常被用来对那些构成模型的‘要素'建模，诸如：类，对象，接口和物理组件。另外，它们也被用来对元素间关联和依赖关系进行建模。

包图：用来将模型划分成不同的逻辑容器或“包”，并在更高层次上描述它们之间的交互关系。
类或结构图：用来定义模型的基本建立模块 : 类型、类和构成完整模型的一般素材。
对象图：显示结构元素的实例间如何关联，以及在运行时如何使用。
复合结构图：提供了一种对元素结构进行分层的方法，并着重体现了元素内部的细节，结构和关系。
组件图：被用来构造更高层次或更复杂的结构，通常由一个或多个类构成，并提供一个定义明确的接口。
部署图：显示现实环境中重要物件的物理配置。

2）行为建模图

行为图用来记录在一个模型内部，随时间的变化，模型执行的交互变化和瞬间的状态；并跟踪系统在真实环境下如何表现，以及观察系统对一个操作或事件的反应，以及它的结果。

用例图：用来对用户/系统的交互关系建模。用脚本和情形的形式来定义行为，要求和约束。
活动图：广泛使用于定义基本程序流程和在一般化过程中，记录判断点和动作。
状态机图：对于了解模型执行时的瞬时状态，即模型的运行状态是重要的。
通信图：显示协作实例中，对象间实时消息和通信的网络结构与顺序。
顺序图：与通信图联系紧密，并在垂直时间线上显示对象间消息传递的顺序。
时间图：融合顺序图和状态图，以提供观察对象随时间变化的状态和改变这个状态的消息。
交互概览图：融合活动图和顺序图，使交互部分容易与判断点和流程结合。

4.如何使用UML

一般地，UML作为软件开发过程的一部分，在具体的CASE工具支持下，用来定义所开发系统的需求，交互和元素。开发过程的确切性质则取决所采用的开发方法。一个典型的开发过程大致如下：

建立一个业务过程模型。业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程，并且是建立用例模型的基础。一般来说业务过程模型比一个软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。
映射用例模型到业务过程模型以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。
完善用例-包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。
有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。
在领域模型、用户接口模型和情形图的基础上，开始建立对象类模型。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。
当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从类模型的角度看，构造组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。
在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。
部署模型定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模、接口与支持软件，来构成新系统，和系统部署在那里，以及出现灾难性故障时的系统恢复，系统可靠性、系统备份与支持等方面所使用的参数。随着模型开发的不断进展，物理系统模型应该不断更新以反映所开发系统的实际情况。
构造系统：将模型的分散模块分配给一个或多个开发者。如果采用用例驱动的方法构造系统，这将意味分配一个用例给开发小组，让他们构造用户界面，业务对象，数据库表以及执行该用例所必须的相关组件。在构造每个用例时，应该同时完成单元测试、集成测试和系统测试。如果采用组件驱动的方法构造系统，则需将各个组件分配给开发小组。
对照模型中的元素，跟踪查找出现在测试阶段的缺陷。如：查看针对用例的系统测试缺陷，查看针对对象类的单元测试缺陷等等，跟踪相关模型元素的修改以防止范围漫延。
随着工作进展不断更新和完善模型-每次修改模型或完善模型，都要评价所做的修改或改善对后续工作的影响。在模块设计中使用反复式工作方法，评介当前构造的模块，新到达的需求，以及开发过程发现的任何问题。
将完整的，并经过测试的软件发送到测试生产环节。如果采用分阶段发送，那么这种软件生产方式需要从测试到生产的多次往复才能最终完成整个项目。