UML笔记01-UML的简介

UML简介

UML，统一建模语言（Unified Modeling Language），是第三代用来为面向对象开发系统的产品进行说明、可视化和编制文档的方法

什么是UML

UML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。它：

• 不是一种可视化的程序语言，而是一种可视化的建模语言；
• 不是工具或知识库的规格说明，而是一种建模语言规格的说明，它是一种表示标准；
• 不是过程，也不是方法，但允许任何过程和方法是用它；

UML的目标

• 易于使用、表达能力强，进行可视化建模；
• 与具体实现无关，可应用于任何语言平台和工具平台；
• 与具体过程无关，可应用于任何软件开发的过程；
• 简单并且可扩展，具有扩展和专有化机制，便于扩展，无对核心概念进行修改；
• 为面向对象与开发中涌现的高级概念（协作、框架、模式和组件）提供支持，强调在软件开发中，对架构、框架、模式和组件的重用；
• 与最好的软件工程实践经验集成；
• 可升级，具有广阔的适用性和可用性；
• 有利于面向对象工具市场成长。

UML的架构

UML由图和元模型组成。图是UML的语法，元模型则给出图的意思，是UML的语义。UML的语义定义在一个四层（四个抽象级）建模概念框架中：

• 元元模型（meta-metamodel）层，组成UML最基本的元素“事物（Thing）”，代表要定义的所有事物；
• 元模型（metamodel）层，组成UML的基本元素，每个概念都是元元模型中的“事物”概念的实例。
• 模型（model）层，组成UML的模型，每个概念都是元模型中概念的实例。这一层模型通常称为类模型（class model）或类型模型（type model）。
• 用户模型（user model）层，所有模型都是UML模型的例子，每个概念都是模型层和元模型的实例。这一层模型通常称为对象模型（object model）或实例模型（instance model）。

UML的视图（view）和图（diagram）

UML视图从不同视角为系统架构建模，有：

• 用例视图（use case view），起吊从用户角度看到的货需要的系统功能，也称为用户模型视图（user model view）或想定视图（scenario view）
• 逻辑视图（logical view），展现系统的静态货结构组成及特征，也称为结构模型视图（structural mdel view）或静态模型视图（static view）
• 并发视图（concurent view），体现系统的动态或行为特征，也称为模型视图（behavioral model view）、过程视图（process view）、协作视图（collaboratiive view ）、动态视图（dynamic view）
• 组件视图（conponent view），体现系统实现的结构和行为特征，也称为实现模型视图（implementation model view）、开发视图（development view）
• 展开视图（deployment view），体现系统实现环境的机构和行为特征，也成为环境模型视图（Environment model view）、物理视图（physical view）

每一种UML的视图都是由一个或多个图（diagram）组成的，一个图是系统架构在某个侧面的表示，它与其他图是一致的，所以图一起组成了系统的完整性。

UML提供了9种不同的图，可以分成两大类：静态图（用例图、类图、对象图、组件图、配置图）和动态图（序列图、协作图、状态图、活动图）。根据不同架构视图，也分成：

在用户模型视图：

• 用例图（User case diagram），描述系统功能。

在结构模型视图：

• 类图（Class diagram），描述系统的静态结构。
• 对象图（Object diagram），描述系统在某个时刻的静态结构。

在行为模型视图：

• 序列图（Sequence diagram），按时间顺序描述系统元素间的交互。
• 协作图（Collaboration diagram），按照时间和空间的顺序描述系统元素间的交互和他们之间的关系。
• 状态图（State diagram），描述系统元素的状态和响应。
• 活动图（Activity diagram），描述系统元素的活动。

在实现模型视图：

• 组件图（Component diagram），描述系统元素的组织。

在环境模型视图：

• 展开图（Deployment diagram），描述环境元素的配置，并实现系统元素的映射到配置上。

UML与面向对象软件分析与设计

UML的最终用途：表示方法的的标准化，有效地促进了不同背景人们的交流，有效地促进软件设计、开发和测试人员的相互理解，为不同领域的人们提供统一的交流标准。

在众多成功的软件设计与实现的经验中，最突出的两条，一是注重系统架构的开发，一是注重过程的迭代和递增型。尽管UML本身没有对过程有任何定义，但是UML对任何使用它的方法（或过程）提出的要求是：支持用力驱动（use-case driven），以架构为中心（architecture-centric）以及递增（incremental）和迭代（iterative）地开发。递增和递增的开发过程反映了项目开发的节奏。

UML在软件开发的不同阶段中的应用

• 需求分析。UML的用力视图可以表示客户的需求。通过用例建模，可以对外部的角色以及它们所需要的系统功能建模。角色和用例是用它们之间的关系、通信建模。每个用例都指定了客户的需求：他/她需要系统干什么。不仅要对软件系统，对商业过程也要进行需求分析。
• 分析。分析阶段主要考虑所要解决的问题，可用UML的逻辑视图和动态视图来描述：类图描述系统的静态结构，协作图、状态图、序列图、活动图描述系统的动态特征。在分析阶段，只为问题领域的类建模，不定义软件系统的解决方案细节（用户接口的类，数据库）。
• 设计。在设计阶段，把分析阶段的结果扩展成技术解决方案。加入新的类来提供技术基础结构（用户接口，数据库操作等）。分析阶段的领域问题类被嵌入在这个技术基础结构中。设计阶段的结果 是构造阶段的详细的规格说明。
• 构造。在构造（程序设计阶段），把设计阶段的类装换成某种面向对象程序设计语言的代码。在UML表示的分析和设计模式进行转换时，最好不要直接把模型转换为代码。因为在早期阶段，模型是理解系统并对系统进行结构化的手段。
• 测试。对系统的测试通常分为单元测、集成测试、系统测试和接受测试几个不同级别。单元测试时对几个类货一组类的测试，通常由程序员进行；集成测试集成组件和类，确认它们之间是否欠当地协作；系统测试把系统当作一个“黑箱”，验证系统是否具有用户所要求的所有功能。接受测试由客户完成，验证系统是否满足所有需求。不同测试小组使用不同UML作为他们的工作基础：单元测试使用类图和类说明规格，集成测试典型地使用组件图和协作图，而系统测试实现用例图来确认系统的行为符合这些图中的定义