UML建模相关概念

1. UML--Unified Modeling Language

language: 语言
modeling: 建模   

unified: 统一的

2. 模型

简单理解：是对现实的简化，是对系统从语义上近似的抽象。

模型的作用：

• 精确捕获和表达项目的要求与应用领域中的知识，以使各方面利益相关者能够理解并达成一致；
• 便于用户和各个领域的专家评审；
• 降低复杂度；
• 提高开发效率和质量；
• 模型可以作为软件系统维护和升级时的文档。

建模方法 = 建模语言 + 建模过程
建模语言定义了用于表示设计的符号(通常是图形符号)
建模过程描述进行设计所需要遵循的步骤

建模的四原则：

1. 选择建立什么样的模型对如何发现和解决问题具有重要的影响。 
2. 每个模型可以有多种表达方式。 
3. 最好的模型总是能够切合实际。 
4. 孤立的模型是不完整的。任何好的系统都是由一些几乎独立的模型拼凑出来的。

3. 面向对象的基本观点

• 客观世界由对象组成。
• 具有相同数据和相同操作的对象可以归并为一个类。从一个类可以派生出许多对象。
• 类可以派生出子类，子类和父类形成类的层次结构。
• 对象之间通过消息相互联系。
• 面向对象=对象+类+继承+通信

一般/特殊（分类）结构：表现事务的一般与特殊的关系。术语称为泛化与特化的关系。

组装结构：表现对象类之间的部分与整体关系。

实例连接：表现对象间的静态联系。通过对象的属性来表现对象之间的关系。

消息连接：对象之间的通信联系。表现对象行为的动态联系。

4. 面向对象分析的基本过程

1. 发现对象，从对象中抽象出类的定义。
2. 识别对象的内部特征。定义属性和服务
3. 识别对象的外部关系。建立一般/特殊结构、整体/部分结构、实例连接、消息连接
4. 划分主题，建立主题图。 
5. 定义用例，建立交互图。发现活动者、定义用例
6. 建立详细说明。模型的详细定义与解释，分散在其它活动之中
7. 原型开发。可反复进行

5. 面向对象分析的层次

对象模型通常由五个层次组成：

1. 类与对象层
2. 属性层
3. 服务层
4. 结构层
5. 主题层

主题（Subject）层：主题给出分析模型的总体概貌，是控制读者在同一时间所能考虑的模型规模的机制。
类-&-对象（Class & Object）层：对象是数据及其处理的抽象。它反映了保存有关信息和与现实世界交互的能力。
结构（Structure）层：结构表示问题域的复杂性。类 - 成员结构反映了一般 - 特殊关系，整体 - 部分结构反映了整体 - 部分的关系。
属性（Attribute）层：属性是数据元素，用来描述对象或分类结构的实例，可在图中给出并在对象的储存中指定，即给出对象定义的同时，指定属性。
服务（Serves）层：服务是接收到消息后必须执行的一些处理，可在图上标明它并在对象的储存中指定，即给出对象定义的同时，定义服务。
五个层次就像合并在一起的五个透明的图层一样，每一层从不同角度将对象模型更细化、更具体化。

面向对象的模型的五个层次对应着分析建模的五个主要活动。这五个活动的工作可以不按顺序进行，也没必要完成一项活动后才开始另一项活动工作。也就是说，五个主要活动可以同时（并行）处理；可以从较高抽象层转移到较低的具体层，然后再返回到较高抽象层继续处理；当系统分析员在确定类-&-对象的同时，想到该类的服务，则可以先确定服务后，再返回去继续寻找类-&-对象；没有必要遵循自顶向下，逐步求精的原则。

6. 面向对象分析的基本原则

1. 抽象原则（类 对象 一般类 属性 服务）
2. 分类原则（把具有相同属性和服务的对象化为一类）
3. 聚合原则（将整体化为若干部分）
4. 关联原则（用关联原则可以明确的表示对象之间的静态联系，实例连接）
5. 消息通信原则（动态联系）

7. 面向对象设计基本过程

1. 设计对象与类；
2. 设计系统结构；
3.  设计问题论域子系统；
4. 设计人机交互子系统；
5. 设计数据管理子系统；
6. 设计任务管理子系统；
7. 设计优化，提高系统的性能。

设计系统结构：一个软件由若干子系统组成，一个子系统由若干组件构成，设计系统结构的主要任务就是设计组件与子系统，以及它们相互的静态和动态关系。
系统结构两种形式：层次结构、块状结构。

问题论域子系统：问题论域子系统负责实现领域的业务服务。应包括与应用领域的业务直接相关的全部类与对象。对OOA模型中的某些类、对象、结构、属性、操作进行调整。

人机交互子系统：主要任务是设计系统界面。内容包括：用户分类、描述交互场景、设计人机交互操作命令、操作顺序，设计人机交互类如窗口、对话框、菜单等。

数据管理子系统：数据管理子系统负责数据的管理：录入、操纵、检索、存储、输出等。设计数据管理子系统的主要任务是：确定数据管理方法，设计数据库逻辑结构和物理结构，设计实现数据管理的对象类。

任务管理子系统：一个系统运行时将有相当数量的进程被激活执行。任务管理子系统的任务就是协调和管理进程。设计软件系统内部模块运行的管理机制，把事件驱动、时钟驱动、优先级管理等任务分配给软、硬件执行。

设计优化：设计的结果要尽可能的优化，尽量提高系统的性能。各性能指标之间常存在矛盾，应权衡考虑选取一个折衷方案。 准则：弱耦合、强内聚、减少通信开销、良好的可扩充性。

8. 类的设计原则

1. 类公共接口的单独成员应该是类的操作符。
2. 类A的实例不应该直接发送消息给类B的成员。
3. 操作符是公共的，当且仅当类实例的用户可用。
4. 属于类的每个操作符要么访问、要么修改类的某个数据。
5. 类必须尽可能少地依赖其他类。
6. 两个类之间的互相作用应该是显式的。
7. 继承结构的父类应该是目标概念的抽象模型。
   

9. 基于UML的面向对象分析设计过程

步骤：

1. 识别系统的用例和角色。通过需求分析；最后得到用例图。
2. 进行系统分析，并抽象出类。
3. 设计系统和系统中的类及其行为。
   

• 结构设计   定义包（子系统）、包间依赖关系、主要通信机制

• 详细设计    细化包内容，清晰描述类及其实例行为

详细的步骤（不是固定的）：

1. 发现对象，从对象中抽象出类的定义。
2. 识别对象的内部特征。定义属性和服务。
3. 识别对象的外部关系。建立一般/特殊结构、整体/部分结构、实例连接、消息连接。
4. 划分主题，建立主题图。
5. 定义用例，建立交互图。发现活动者、定义用例。
6. 建立详细说明。模型的详细定义与解释，分散在其它活动之中。
7. 原型开发。可反复进行
   

10. 发现对象和定义类

（1）发现对象
根本出发点：问题域和系统责任
问题域侧重于从客观存在的事物发现系统中的对象，系统责任侧重于从系统范围内的每一项职责由哪些对象来完成发现对象，两者同时考虑，只考虑问题域导致不知道哪些事物以及他们的那些特征该舍弃，那些该提取，容易使某些功能实现不了；只考虑系统责任，使系统中的对象不能真实反映问题域。
例如：书和衣服若从问题域抽象得到的一定是完全不同的类，如果在系统中仅被作为销售商品时，那么他们就具有相同的属性和方法，此时，我们就可以将他们合并为一个类商品

（2）抽象出对象类
几种常见问题：

• 从问题域抽象出的完全不同的若干类对象经系统责任为目标的抽象保留下来的属性和方法完全相同。解决方法：合并

• 出现属性和服务相似的类。解决方法：建立一般/特殊结构或整体/部分结构

• 出现对同一事物的重复描述。

11. UML中的视图

视图的分类：

1. 用例视图   系统使用实例
2. 逻辑视图   系统逻辑结构
3. 组件视图   系统构成
4. 并发视图   系统并发特性
5. 配置视图   系统的配置
   

这5种视图组合构成UML完整模型。

下面详细分析这五种视图：

• 用例视图

用途：描述系统应该具备的功能，即被称为参与者的外部用户所能观察到的功能。

用例视图是几个视图的核心，它的内容直接驱动其他视图的开发。

• 逻辑视图
  

用途：描述用例视图中提出的系统功能的实现。逻辑视图既描述系统的静态结构，也描述系统内部的动态协作关系。

组成：静态结构在类图和对象图中进行描述；动态模型在状态图、时序图、协作图以及活动图中进行描述。

• 并发视图
  

用途：考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理。

组成：状态图、协作图和活动图。

• 组件视图
  

用途：描述系统的实现模块以及它们之间的依赖关系

• 配置视图

用途：显示系统的物理部署，并描述位于节点实例上的运行组件实例的部署情况 。例如一个程序或对象在哪台计算机上执行，执行程序的各节点设备之间是如何连接的。

12. UML中包含九种图

主要分为两类：静态图和动态图。
（1）静态图
    UML中有5种静态图：用例图、类图、对象图、组件图和配置图。

（2）动态图：

       UML中有4种动态图：时序图、协作图、状态图、活动图

13. UML中的事物

UML中的事物包括结构事物、行为（动作）事物、组织（分组）事物、注释事物。

• 结构事物

         结构事物包括7种：类、接口、协作、用例、活动类、组件和节点。

                类：类是具有相同属性、相同方法、相同语义和相同关系的一组对象的集合。

                接口： 接口是指类或组件所提供的、可以完成特定功能的一组操作的集合，换句话说，接口描述了类或组件的对外的、可见的动作。
               协作：协作定义了交互的操作，是一些角色和其他元素一起工作，提供一些合作的动作。这些动作比元素的总和要大。因此，协作具有结构化、动作化、维的特性。一个给定的类可能是几个协作的组成部分。这些协作代表构成系统的模式的实现。协作在UML中用一个虚线画的椭圆和它的名字来表示。
              用例：用例描述一系列的动作，这些动作是系统对一个特定角色执行，产生值得注意的结果的值。在模型中use case通常用来组织动作事物。Use case是通过协作来实现的。

在UML 中，use case为一个实线椭圆，通常还有它的名字。
              活动类：活动类是对拥有线程并可发起控制活动的对象（往往称为主动对象）的抽象。它的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的。

在UML 中活动类的画法和类相同，只是边框用粗线条。
              组件：组件是物理上或可替换的系统部分，它实现了一个接口集合。在一个系统中，你可能会遇到不同种类的组件，例如COM+ 或JAVA BEANS。

组件在UML中用如下的图表示：

             节点：节点是一个物理元素，它在运行时存在，代表一个可计算的资源，如一台数据库服务器等。通常占用一些内存和具有处理能力。一个组件集合一般来说位于一个节点，但有可能从一个结点转到另一个节点。

节点通常用如下的图形表示：

• 动作事物

动作事物主要有两种：交互和状态机。
（1）交互
    是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作），连接（对象之间的连接）。

在UML 中消息画成带箭头的直线，通常加上操作的名字。

（2）状态机

       状态机是对象的一个或多个状态的集合。     

• 分组事物
  

分组事物是UML模型中负责分组的部分，可以把它看作一个个盒子，每个盒子里面的对象关系相对复杂，而盒子与盒子之间的关系相对简单。成组事物只有一种：包。
       包是一种有组织地将一系列元素分组的机制。

• 注释事物

属于这一类的只有注释。注释即是UML模型的解释部分。
在UML图中，一般表示为折起一角的矩形。

14. UML通用机制

• 修饰
  

为图中的模型元素增加了语义。

• 注释

以自由的文本形式出现的。
信息类型是不被UML解释的一个字符串。

•  规格说明

UML 中预定义的特性：
    文档（Documentation）
   职责（Responsibility）
   永久性（Persistence）
   并发性（Concurrency）

• 通用划分
  

两种通用划分(General Division)：
1.  型-实例（值）

描述一个通用描述符与单个元素项之间的对应关系。

2.  接口-实现

实例：

• 扩展机制

（1）构造型

由建模者设计的新的模型元素。
新的模型元素的设计要以UML已定义的模型元素为基础。

（2）标记值

附加到任何模型元素上的命名的信息块。

（3）约束
用某种形式化语言或自然语言表达的语义关系的文字说明。