【UML初识】-三大结构

开篇

对于UML结构做了一个简单整理，当然，UML的结构还包括UML的规则和UML中的公共机制，导图中没有展现出来，在后边的内容中会有呈现。

内容

一、基本构造块：事物，关系，图

1、事物：是对模型中最具代表性的成分的抽象，包括结构事物，行为事物，分组事物和注释事物四种。

1.1 结构事物

1.1.1 类

类是具有相同属性，相同操作的一组对象的集合的抽象描述。

在图形上，类用一个矩形表示，包括名称，属性，操作三部分。

1.1.2  组件

组件是系统中物理的，可替代的部件，是一个描述了一些逻辑元素（如类、接口）的物理包，可以复用，实现一组接口，使用更换都很方便。

在图形上，组件由一个带有小方框的矩形表示，通常在矩形中只写该组件的名字。

1.1.3 接口

接口是描述了一个类或组件的一个服务的操作集，接口仅仅是定义了一组操作的规范，并没有给出具体的实现方法。例如“去学校”是个接口，但是具体是骑车去还是坐车去没有给出，具体方法就的看使用接口的对象了，

在图形上，接口用一个带有名称的圆表示。

1.1.4 协作

协作是说对象之间的交互作用，对象之间的联系和作用是如何完成的。

在图形上，协作用一个包含名称的虚线椭圆表示。

1.1.5 用例（Use case）

用例是对序列动作的描述。

在图形上，用例用实线的椭圆表示，参与者用一个人形的图案表示。

1.1.6 主动类

主动类可以启动控制活动。

在图形上，主动类的表示方法和普通类相似，也是使用一个矩形，只是最外面的边框使用粗线。

1.1.7  节点

节点是一个物理元素，在运行时存在，代表一个可计算资源，比如说一台数据库服务器。

在图形上，节点用一个立方体来表示。

1.2 行为事物：描述模型的动态部分

1.2.1  交互事物：对象都不是孤立存在的，他们之间通过传递消息进行交互。

                              在图形上，交互的消息通常用带箭头的直线表示

1.2.2  状态机（State machice）：一个行为既是一个状态机，描述一个对象或一个交互在生命周期内相应事件所经历的状态

 

1.3 分组事物：负责分组的部分

1.3.1 包package

包是进行封装的，把元素组织成组的机制。结构事物，行为事物都可以放进包内。

在图形上，包用一个在左上角带有一个小矩形的大矩形表示。

1.4 注释事物：负责解释的部分，用来描述，说明和标注模型的任何元素。

1.4.1 注解

注解一种主要的注释事物。

在图形上，注解用一个右上角是折角的矩形表示。

2、关系

2.1关联

关联是一种强依赖，不存在依赖关系的偶然性和临时性。例如朋友关系，这种关系依赖比较强，为关联关系。在图形上，关联用一条实线表示，可能有方向，偶尔在其上还有一个标记。

2.1.1普通关联

图中用实线表示关联关系，同时关联中有关联的名称，角色名称。

2.1.2聚合

聚合是关联关系一种特例，体现的是整体和部分的拥有关系，但是部分可以离开整体依然可以工作。

图中以空心的菱形指向整体，但部分脱离整体仍可以工作。例如学生和班级

2.1.3组合

依然是整体和部分的关系，这种关系比较聚合强，部分必须依赖整体存在。

图中以实心的菱形指向整体，如果大脑脱离了人，那么就无法工作了。

 

2.2 依赖

依赖是两个事物间的语义关系，一个事物（独立事物）发生变化，会影响到另一个事物（依赖事物）。

在图形上，用带箭头的虚线表示

 

2.3 泛化

泛化是一般事物（父类）和该事物较为特殊的种类（子类）之间的关系，子类继承父类的属性和操作，除此之外，子类通常还添加新的属性和操作。在图形上用带有空心三角的直线表示

 

2.4 实现

实现是一个类实现接口的功能，实现是类和接口之间最常见的关系。在图形上，用带有空心三角的虚线表示。

 

关联和依赖的区别：我用锤子修了一下桌子，我和锤子之间就是一种依赖，我和我的同事就是一种关联。依赖是一种弱关联，只要一个类用到另一个类，但是和另一个类的关系不是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖，依赖也可说是一种偶然的关系，而不是必然的关系。关联是类之间的一种关系，例如老师教学生，老公和老婆这种关系是非常明显的。依赖是比较陌生，关联是我们已经认识熟悉了。

关系强调的顺序是：实现=泛化>组合>聚合>普通关联>依赖，依赖是最常见的，如果能用别的关系替代依赖，就不要用依赖。

3、图

3.1 用例图（use casediagrams）

    从用户的角度，描述待开发系统的功能需求，说白了就是谁要使用系统，他们用这个系统来做什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

3.2 类图（classdiagrams）

    类图是描述系统中的类，以及他们之间关系的静态图。类图是一种静态模型类型。

3.3 对象图（objectdiagrams）

    与类图很相似，但是对象是类的实例，他描述的是对象之间的关系，而并非类之间的。

3.4 活动图（activitydiagrams）

    用来描述用例要求索要进行的活动，类似与流程图，用来演示系统中那些地方存在功能，以及这些功能和系统中其他组件的功能是如何满足前面使用的用例建模的要求。

3.5 状态图（statediagrams）

    描述类的对象所有可能的状态，以及事件发生时状态的转移条件，状态图应该连接到清晰可标识的状态和复杂行为的类。状态图可以说是对类图的补充。

3.6 序列图（sequencediagrams）

    描述对象之间的消息传递，动态协作关系，在时间轴上，描述了对象之间是如何交互的。

3.7 协作图（collaborationdiagrams）

    与序列图相对应，只是协作图强调的是对象之间的交互，信息流的传递，而并非时间。

3.8 构件图（componentdiagrams）

    描述代码构件的物理结构，以及各种构件之间的依赖关系，可以实现同一接口的功能。构件是软件单元，替换灵活，可以是源代码文件，exe，库（DLL），数据文件或文档。

3.9 部署图(deploymentdiagrams)

是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。

 

简略来说，UML的9种图在软件生命周期中各个阶段的应用主要体现在：

1、在需求分析阶段：主要采用用例图来描述需求（角色、功能、外部交互等）；

2、在分析阶段：明确解决问题的细节，主要采用类图来描述静态结构，采用顺序图，协作图，活动图，状态图来描述系统动态行为；

3、在设计阶段：给出解决方案，主要采用类图、包，对类的接口进行设计；

4、在实现阶段：将类用一种面向对象语言实现；

5、测试阶段：单元测试使用类图和类的规格说明书。集成测试使用类图，包，构件图和协作图。系统测试使用用例图来测试系统的功能；

6、集成和交付阶段：主要采用构件图、包、部署图；

二、UML规则

不能简单的把UML的构造块按随机的方式放在一起。像任何语言一样，UML有一套规则，这些规则描述了一个结构良好的模型看起来应该像什么，UML有用于描述如下事物的语义规则

• 命名：也就是为事物、关系和图起名字。和任何语言一样，名字都是一个标识符
• 范围：与类的作用域相似.
• 可见性：怎样让其他人使用或看见名称。Public，Protected，Private，Package
• 完整性：事物如何正确、一致的相互联系
• 执行：运行或模拟动态模型的含义是什么

三、UML的公共机制

1、规格说明

UML不只是一种图形语言。实际上，在它的图形表示法的每部分背后有一个规格说明，这个规格说明提供了对构造块的语法和语义的文字叙述

UML的图形表示法用来对系统进行可视化；UML的规格说明用来描述系统的细节

2、修饰

在为了更好的表示这些细节，UML中还提供了一些修饰符号，例如不同可视性的符号、用斜体字表示抽象类

3、通用划分

3.1 类/对象二分法（class/object dichotomy）：类是一个抽象；对象是这种抽象的一个具体形式
接口/实现二分法（interface/realization dichotomy）：接口声明了一个契约，而实现则表示了对该契约的具体实施，它负责如实的实现接口的完整语义

4、扩展机制

4.1 构造型：在实际的建模过程中，可能会需要定义一些特定于某个领域或某个系统的构造块

4.2 标记值：则是用来为事物添加新特性的。标记值的表示方法是用形如“{标记信息}”的字符串

4.3 约束：是用来增加新的语义或改变已存在规则的一种机制（自由文本和OCL两种表示法）。约束的表示法和标记值法类似，都是使用花括号括起来的串来表示，不过它是不能够放在元素中的，而是放在相关的元素附近。

结语

目前只是一些理论性的总结，期待自己可以把这些知识真正掌握的时候，加油！