一  标准建模语言

UML面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法,而且对其作了进一步的发展,并最终统一为大众所接受的标准建模语言。

面向对象技术和UML的发展过程可用下图来表示,标准建模语言的出现是其重要成果。在美国,截止1996年10月,UML获得了工业界、科技界和应用界的广泛支持,已有700多个公司表示支持采用UML作为建模语言。1996年底,UML已稳占面向对象技术市场的85%,成为可视化建模语言事实上的工业标准。1997年11月17日,OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。UML代表了面向对象方法的软件开发技术的发展方向,具有巨大的市场前景,也具有重大的经济价值和国防价值。

图1 UML的发展历程

UML 1.0 Team

Digital Equipment	Contributions include
*  Hewlett-Packa	multi-modeling and refinements
i-Logi	x business modeli
* ICON Computing	use cases and responsibilities,
* Intellicorp	state machine semantics,
* MCI Systemhouse	types, classes and instances
* Microsoft	interfaces and components,
* Oracle	collaborations and patterns,
* Rational Software	distribution and concurrency,
* Texas Instruments	meta-metamodel,
* Unisys	glossary
* = co-submitter	OMG and RM-ODP technology perspective

二 UML语言的特征

• 不是一种可视化的程序设计语言，而是一种可视化的建模语言。
  
• 是一种建模语言规格说明，是面向对象分析与设计的一种标准表示。
  
• 不是过程，也不是方法，但允许任何一种过程和方法使用它。

三 UML语言的目标

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

四 UML语言概述

由视图view，图diagram，模型元素model element和通用机制general mechanism等几个部分组成

• 视图是表达系统的某一方面特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。
  
• 图是模型元素集的图形表示，通常为弧（关系）和顶点（其他模型元素）相互连接构成的。
  
• 模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。
  
• 通用机制用于表示其它信息，比如注释、模型元素的语义等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程），或扩充至一个组织或用户。

在后续文章中，我继续介绍UML的模型、视图、图与系统架构建模。

五  UML的模型、视图、图与系统架构建模

UML是用来描述模型的，用模型来描述系统的结构或静态特征，以及行为或动态特征。从不同的视角为系统的构架建模，形成系统的不同视图（VIEW）

• 用例视图(use case view)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图；
  
• 逻辑视图(logical view)，展现系统的静态或结构组成及特征，也称为结构模型视图(structural model view)或静态视图（static view）；
  
• 并发视图(concurrent view)，体现了系统的动态或行为特征，也称为行为模型视图（behavioral model view）、动态视图(dynamic view)；
  
• 组件视图(component view)，体现了系统实现的结构和行为特征，也称为实现模型视图(implementation model view) ；
  
• 配置视图(deployment view)，体现了系统实现环境的结构和行为特征，也称为环境模型视图（environment model view）或物理视图(physical view)。
  

九种图

• 用例图use case diagram，描述系统功能
  
• 类图class diagram，描述系统的静态结构
  
• 对象图object diagram，描述系统在某个时刻的静态结构
  
• 序列图sequence diagram，按时间顺序描述系统元素间的交互
  
• 协作图Collaboration diagram，按照时间和空间顺序描述系统元素间的交互和它们之间的关系
  
• 状态图state diagram，描述了系统元素的状态条件和响应
  
• 活动图activity diagram，描述了系统元素的活动
  
• 组件图component diagram，描述了实现系统的元素的组织
  
• 配置图deployment diagram，描述了环境元素的配置，并把实现系统的元素映射到配置上
  根据它们在不同架构视图的应用，可以把9种图分成：
  
• 用户模型视图：用例图
  
• 结构模型视图：类图、对象图
  
• 行为模型视图：序列图、协作图、状态图、活动图（动态图）
  
• 实现模型视图：组件图
  
• 环境模型视图：配置图

1.  USE CASE图

图3.1: USE CASE图

图3.2: USE CASE图

　

元素之间的关系

• 角色之间的关系：拥有与类相同的关系描述，用通用化关系描述若干个角色之间的行为。
• 用例之间的关系：
  （1） 扩展关系：插入基用例所未知的附加行为，只有基用例能实例化。
  （2） 概括关系：一般化关系，特殊用例继承和增加了基用例的特征。
  （3） 包含关系：用例可以简单的合并其他的用例，将其作为自身行为的片段。
  

 

图3.3: USE CASE图

图3.4: USE CASE图

图3.5: USE CASE图

图3.6: USE CASE图

实现

• 用例实现为协作：序列图、协作图、活动图
• 功能分配
• 边界对象、控制对象、实体对象
  

1.理解Use Case和Actor

1.Use Case绝不是锦上添花的东西，一方面它可以促进与用户沟通，理解正确的需求，另一方面它可以划分系统与外部实体的界限，是系统设计的起点，而最终应该落实到类和实现代码上。

2.Use Case View与Logical View应该有明确的相关性。UML中从Use Case到类包的关联可以用依赖（或实现）关系描述。

3.Actor不是指人，而是指代表某一种特定功能的角色，因此同一个人可能对应很多个Actor。Actor是虚拟的概念，可以指外部系统和设备。

4.Use Case是对系统行为的动态描述，它是OO设计的起点，是类、对象、操作的来源，而通过逻辑视图的设计，可以获得软件的静态结构。

2. 类图Class Diagram

• 名字、属性、操作、可见性、关系
• 关联关系：普通、递归、限定、或关联、有序关联，关联类
• 聚合：复合聚合-实心菱形
• 通用化：普通、受限
• 依赖：两个模型元素（类、组合、用例）之间的语义上的连接关系。
• 包（Package）