UML联合重点.docVIP

UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。不是一种可视化编程语言，而是一种可视化建模语言。不是工具或知识库的规格说明，而是建模语言的规格说明，是一种面向对象分析与设计的表示标准。不是过程，也不是方法，但是允许任何一种过程和方法使用它。可视化建模就是将模型中的信息用标准的图形元素直观地显示出来。模型是对现实世界的简化和抽象。模型是沟通的手段。模型是系统的蓝图，可以帮你规划要开发的系统。 UML建模的目的 使用模型可以更好地理解问题 使用模型可以加强人员之间的沟通 使用模型可以更早地发现错误或疏漏的地方 使用模型可以获取设计结果 模型为最后的代码生成提供依据 UML中有3类主要元素 基本构造块（basic building block）包括3种类型：事物(thing)、关系(relationship)、图(diagram) 规则（rule）UML定义了5个方面的语义规则：命名(name)、范围（scope）、可见性（visibility）、完整性（integrity）和执行（execution) 公共机制（common mechanism）包括4种类型：规范说明（specification）、修饰（adornment）、通用划分（common division）和扩展机制（extensibility mechanism）。其中扩展机制包括版型、标记值和约束3种类型。 事物（thing）分4种类型 结构事物（structural thing）包括类、接口、协作、用例、主动类、构件和结点 行为事物（behavioral thing）包括交互、状态机和活动 分组事物（grouping thing）包 注释事物（annotational thing）注解 关系有4种类型 依赖（dependency） 关联（association） 泛化（generalization） 实现（realization） 类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系，在系统的整个生命周期都是有效的。 对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。 用例图是从用户角度描述系统功能，并指出各功能的操作者 。 状态图是对类图的补充。在使用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。 顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互。 协作图描述对象间的协作关系，协作图跟顺序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系。 活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。 构件图显示一组构件以及它们之间的相互关系，包括编译、链接或执行时构件之间的依赖关系。构件图可以对源代码文件之间的相互关系建模，并且可以对可执行文件之间的相互关系建模。 部署图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。一个系统模型只有一个部署图，部署图常常用于帮助理解分布式系统。 UML应用领域最常用的是为软件系统建模，但不限于软件系统建模。UML还可用来描述其他非软件系统，如一个机构的组成或机构中的工作流程等。 需求获取阶段 UML的用例视图可以表示客户的需求，通过用例建模可以对外部的角色以及它们所需要的系统功能建模。 分析阶段 分析阶段主要考虑所要解决的问题。可用UML的逻辑视图和动态视图来描述，类图描述系统的静态结构；协作图、状态图、顺序图和活动图描述系统的动态特征。在分析阶段，只为问题领域的类建模，不定义软件系统的解决方案的细节（如用户接口的类数据库等）。 设计阶段 在设计阶段把分析阶段的结果扩展成技术解决方案，引入具体的类来处理用户接口、数据库操作等。 分析阶段的领域问题类被嵌入在这个技术基础结构中，设计阶段的结果是构造阶段的详细的规格说明。 构造阶段 在构造（或程序设计）阶段把设计阶段的类转换成某种面向对象程序设计语言的代码。 测试阶段 对系统的测试通常分为单元测试、集成测试、系统测试和接受测试几个不同级别。 不同的测试小组使用不同的UML图作为他们工作的基础。单元测试使用类图和类的规格说明；集成测试典型地使用组件图和协作图；而系统测试使用用例图来确认系统的行为是否符合这些图中的定义。 用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一