UML用户指南(二)----类、关系、图、接口、包、实例

类

 

 

     UML为类提供了图形表示，强调抽象的最重要的部分。在用UML对类建模时，要记住: 对最终用户或实现者来说，各个类都应该映射到某个有形的或者概念性的抽象。一个结构良好的类，应符合如下条件：

 

     ①　为取自问题或者解域的词汇中的事物提供明确的抽象

     ②　嵌入一个小的，明确定义的责任集，并且能很好实现它们

     ③　把抽象的规约和它的实现清楚地分开

     ④　简单而且可以理解，并具有可适应性和可扩展性。

 

 

 

概念

 

 

1. 可见性：公用的(public)、受保护的(protected)、私有的(private)、包(package)

 

 

2. 实例范围和静态范围：前者表示每一个实例均有它自己的值，后者表示对于类目的所有实例，特征的值是唯一的，也称为类范围，通过对特性串加下划线来表示它。

 

3. 多重性

 

 

 

4. 抽象元素、叶子元素和多态性元素

 

 

 

 

 

把一个类名写为斜体表示是抽象的；指派leaf，表示它是叶子操作，意味着该操作不是多态的，不可以被覆写(这类似于java中的final操作)。除了leaf之外，还有：查询(query)，操作不会改变系统的状态；顺序(sequential)，调用者必须在对象外部进行协调；监护(guarded)，通过将所有对象监护操作的所有调用顺序化；并发(concurrent)，静态(static)；

 

 

 

5. 属性

 

[可见性] 属性名 [':' 类型] ['['多重性']'] ['=' 初始值] [特性串 {',特性串}]

 

 

6. 操作

 

[可见性] 操作名 ['('参数表')'] [':' 返回类型] [特性串 {',特性串}]

 

 

 

模板类

 

 

模板是一个被参数化的元素，最常见的用法是详述可以被实例化为特殊元素的容器，并保证它们的类型是正确的。在UML中，模板类的画法与普通类一样，只是在类的图标的右上角带有一个附加的虚框。

 

 

 

 

在UML中绘制类目时，要遵循如下策略：

 

 

仅显示语境中对理解抽象来说重要的类目特征

选择类目的意图提供最佳可视化提示的衍型化的版本。

 

 

 

关系

 

 

 

 1.依赖(dependency)

 

是UML中的语义关系，其中一个元素(独立元素)发生变化会影响到另一个元素(依赖元素)的语义。

 
 

 

 2.关联(association)：

 

是类之间的结构关系。两个类之间的简单关联表示了两个同等地位类之间的结构关系，这意味着这两个类在概念上是同个级别，一个类并不比另一个类重要。

 

 

 

 

有时候要对"整体/部分"关系建模，其中一个类描述了一个较大的事物       ("整体")，它由较小的事物("部分")组成。这就是组合和聚合。

 

 

 

 

A.聚合:它描述了"has-a"关系，意思是整体对象拥有部分。它被表示为一个整体的一端有一个空心菱形修饰的简单关联。

 

 

 

 

B.组合:是聚合的一种形式，它具有强的拥有关系，而且整体与部分的生命周期是一致的。一旦创建，它们就是同生共死。

 

 

 

 

 

 

 

    3.泛化(generalization)：是一种特殊/一般关系。

 

 

 

 4.实现(realization):是类目之间的语义关系，其中一个类目指定了由另一个铃木保证执行的合约。
 

 

 

 

下面给出一个学校的信息系统中的一组类:

 

 

 

 

 

 

 

在用UML绘制关系时，要遵循如下策略：

 

 

仅显示对理解特定的成组事物必不可少的关系。避免使用多余的关系。

 

 

 

 

 

图

 

 

在软件方面，有5种互补视图对于软件体系结构的可视化、详述、构造、和文档化是最重要的，分别是：用例图、设计图、交互图、实现图和部署图。

 

 

 

结构图：可以把系统的静态方面看做是对系统的相对稳定的骨架的表示。UML的结构图大致上是围绕着对系统建模时发现的几组主要事物来组织的。

 

 

 

①　类图

 

 

 

展示了一组类、接口、协作以及它们之间的关系。

 

 

②　构件图

 

 

展示了实现构件的内部部件。、连接件和端口

 

 

③　组合结构图

 

 

展示了类或者协作的内部结构。

 

 

④　对象图

 

 

展示了一组对象已经它们之间的关系。用对象图说明在类图中所发现的事物的实例的数据结构和静态快照。

 

 

⑤　制品图

 

 

展示了一组制品以及它们与其他制品、与它们所实现的类之间的关系。

 

 

⑥　部署图

 

 

展示了一组结点以及它们之间的关系。

 

 

行为图:把系统的动态方面看作是对系统变化部分的表示。

 

 

 

①　用例图(use case diagram)

 

 

描述了一组用例和参与者以及它们之间关系。可以用用例图表述系统的静态用例视图。

 

 

 

②　顺序图(sequence diagram)

 

 

强调消息的时间次序的交互图。

 

 

③　通信图(communication diagram)

 

 

强调收发消息的对象的结构组织的交互图。

 

 

④　状态图(state diagram)

 

 

展示了一个由状态、转换、事件和活动组成的状态机。

 

 

⑤　活动图

 

 

展示了计算机中一步步的活动六。

 

 

一个结构良好的图，应该满足如下要求：1.仅包含对于理解这个方面所必须的元素。2.不过分简化，以免读者误解重要的语义。

 

 

对复杂的视图建模，要遵循一下策略：

 

 

①　确信无法在更高的抽象层次上表达这些信息

 

②　如果已经尽可能地隐藏了能够隐藏的细节，但图仍然很复杂，就考了把一些元素组织到一些包或者较高层次的协作中，然后仅把这些包或者协作画在图中。

 

③　如果仍然复杂，就用注解和色彩作为可视化提示。

 

④　如果图还是很复杂，就打印出来挂在墙上。

 

接口

 

接口详述了类或构件的合约而不指定其实现。一个类或构件可以实现多个接口。提供服务的成为供接口(provided interface)。类似地，一个类所需要的来自其他类的服务集合是它的需接口(required interface)。

 

 

 

 

 

这个构件提供了3个接口:IUnkown、Component3、Component4。IUnkown接口是展开形式，另外两个以简单形式。还需要两个接口，即ITransaction、Component2。ITransaction为展开形式。

 

 

 

包

 

 

在UML中，把组织模型的组块称之为包。它不能执行。包可以拥有其他元素，这些元素可以是类、接口、构件、结点、协作、用例和图，甚至是其他包。

 

 

在包Vision中有一个名为Camera的类，而包Vision又在包Person中。类Camera的全名为Person::Vision::Camera。

 

 

应该记住，包只是为了帮助组织模型的元素。如果在实际系统中有些抽象表明它们本身就是对象，就不要使用包。

 

 

 

 

 

 

实例

 

实例(instance)是抽象的具体表现，可以对它施加一组操作，而且它可能由一组状态，用以存储操作的结果。

 

在建模时，要把它们放在对象图中(若想可视化它们的细节)，或者放在交互图和活动图中(若想可视化它们在动态情景中的参与情况)。如果要显示地表示对象与它的抽象之间的关系，可以把对象放在类图中。在表示法上，实例的名称后跟一个冒号再加上类型，例如    t:Transaction。