UML建模

以下内容来自《UML2.0 学习指南》一书，作者Russ Miles

.

..

...

贯穿模型的两种UML表示法元素

·注释符(notes)：注释可使用点线附着在另一元素上。

·构造型(stereotypes)构造图表示特殊的用途或意图，几乎可以用于UML表示法的任何元素。构造型修改元素的含义，描述元素在模型中扮演的角色。构造图有时有一个关联图标（如人形图标），但更多是通过名称两端加上海鸟括号来表示构造型（如<>）。

.

..

...

uml建模中“4+1”模型（Philippe Kruchten提出）

·逻辑视图(Logical View)

·流程视图(Process View)

·开发视图(Development View)

·实体视图(Physics View)

·用例视图(Use Case View)

 

(1)逻辑视图
逻辑视图描述系统组成部件的抽象描述。用来对系统由什么组成和各组成部件之间如何结合进行建模。组成这种视图的代表性UML图类型包括类图、对象图、静态机械图和交互图。
(2)流程视图
流程视图描述系统内的流程，尤其在具体化系统内必须发生的内容时更为有益，其代表性视图是活动图。
(3)开发视图
开发视图描述系统的部件如何组成模块和组件。它在管理系统体系结构内部的层时特别有用。这种视图主要包括包图和组件图。
(4)实体模型
实体视图描述前三种视图描述的系统设计如何落实到真实世界的实体中。这种视图中的图显示设计的抽象部分如何映射到最终部署的系统中。其代表是部署图。
(5)用例视图
用例视图描述根据外部世界为系统建模时系统的功能性。这种视图需要描述系统应该做什么。所以其他视图都通过用例视图来引导。这也是模型成为“4+1”的原因。这类视图通常包括用例图、用例描述和用例概括图。

.

..

...

1、用例(use case)：为需求建模

用例是一种案例（或状况）。在用例中，系统用来满足一个或多个用户需求，而用例捕捉系统所提供功能的片段。

用例是模型的核心，它们影响并引导系统设计的所有其他元素。（对面向对象的系统设计、开发、测试及文档编制的各方面来说，用例是极佳的起点。它们以外部的观点严谨地描述系统的需求，指定系统该交付给用户的价值）

 

标示行为者

行为者不必是真实的人，也可能是第三方的系统等等。在模型中识别行为者时，很容易只将焦点集中于系统用户。但是，别忘了还有其他人，如系统的安装人员、维护人员、负责升级的人员等等。

 

产生用例

要牢记的重点是：从用户的观点看，用例是系统一项完整的功能，有一些与系统的交互以及这些交互所产生的输出。经验有助于确定何时会有良好的用例，但是有一个基本的经验原则能用来指定用例：用例能向用户或外部系统提供某种可测量的结果。

 

通信线

通信线连接行为者与用例，以显示行为者参与用例。使用通信线的目的只是显示行为者的确参与到用例中，而不是要暗示信息按任何特定方向在交流，也不是暗示由行为者启动用例（这类信息被包含在用例的细节描述里）。因此，把导航功能应用于通信线并不是合理的。

 

用例描述(use case description)

每个用例应带有一个用例描述。用例描述让用例变得完整，没有描述的用例没什么用。

注：需要确保用例图与详细的用例描述相匹配。此外，拥有正确的用例比用例的数量更重要。

 

用例关系

·<include>关系：支持用例间的重用

·特殊用例：一般化—>特殊，类似类的继承。

·<extend>关系：表示可选择性的重用。注意UML中的<>构造性和OO中的继承几乎没什么共同点，两者是不相同的概念。

.

..

...

2、活动图(activity diagram)：为系统工作流程建模

用例显示系统应该做什么，活动图则指明系统将如何实现它的目标。活动图显示链接在一起 的高级动作(action)，代表系统中发生的流程。活动图是系统模型的流程视图中唯一的UML图，它关注流程，有助于更好地显示用例的步骤。

主要部件

·起始节点(initial node)：实心圆，标志活动开始的方式之一

·活动最终节点(activity final node)：内含实心圆的圆圈

·动作(action)：圆角矩形

·链(edge)或路径(path)：带箭头的直线（有一个名为连接符connector的符号可以代替纷杂的连接线。连接符成对出现，但应谨慎使用）

·判断节点(decision)与合并节点(merge)：菱形节点（判断节点有一条进入链及多条退出链，合并节点有多条进入链及一条退出链）

·分叉点(fork)与结合点(join)：代表活动图的平行动作，这些动作将同时执行（虽不一定同时结束，但结合点迫使在所有动作完成之后才能通过它）

·时间事件(time event)：沙漏（包括具有进入链和不具有两种情况）

·对象节点(object node)：显示在活动里流动的数据

·信号(signal)：代表与外部参与者的交互，信号可以是被发送或接收的信息

·活动框(activity frame)：圆角矩形，包含活动的动作

·干草叉(pitchfork)调用其他活动（与调用软件程序相似）

·中断区域(interruption region)：显示可以被中断的流程。以虚线圆角矩形画出一个中断区域，围绕那些可能被中断的动作，以及造成这些中断的事件。中断事件后面接着一条看起来像闪电的线。

·活动分区(partition)或泳道(swimlane)：将活动图划分成栏或列，并且包含由负责群组所完成的动作，显示出哪个参与者负责哪些动作

 

活动与动作

活动(activity)与动作(action)是不同的。

活动是被建模的流程(process)，如洗车。动作则是整体活动中的一个步骤，如喷泡沫、冲洗、干燥。

 

判断与合并：监护条件(guard condition)根据UML规范，加入多个监护条件计算结果为真，只只有一个链会被执行，除非特别指明顺序，否则无法控制选择。通过使监护条件互斥，可以避免这类情况。另一种要避免的情况是不完整的监护条件，这种状况无法在判断节点之后按照任何链来执行，这意味着活动被冻结在判断节点。所以监护条件应该总是包含所有可能的状况（在活动图里使用else标示一条路径，会很有用，类似switch中的default）。

.
..
...
3、类与类图(class diagram)：为系统的逻辑结构建模
构成逻辑视图(logical view)的一部分。
用例将系统的行为描述为一组要点。类描述为满足这些要点系统所需的各种不同对象类型。
类描述系统中不同对象的类型，而类图显示出这些类及彼此间的关系。

可见性(visibility)
类如何选择性地将它的操作与数据开放给其他类？使用可见性。
(1)Public: +
(2)Protected: #
在类中被声明为Protected的元素，可被该类的其他方法访问，也可被任何相应继承类所声明的方法访问。非继承类无法访问Protected的元素（无论该类是否位于相同的包内）。
(3)Package: ~
如果在类里添加一个声明为Package可见性的属性或操作，则同一包中任何类可直接访问该属性或操作。包外的类无法访问Package属性或操作（即使是它的继承类也无法访问）。
(4)Privated: -
（注：从上到下，对系统其他部分而言可访问性递减）

类的静态部分
在UML中，静态的属性或操作通过在名称下加下划线表示。

类关系
类不是孤立存在的，它们通过不同类型的关系共同工作。
UML提供的5种不同类型的类关系（从上到下类间的关系递强，即依赖性越高）：
(1)依赖(Dependency)：虚线箭头
两个类彼此依赖，以确保在运行时一起工作。
依赖只意味着类的对象能一同工作，因此，它被认为是能存在于两类之间的最弱的直接关系。
(2)关联(Association)：简单的直线
依赖仅仅允许一个类使用另一个类的对象，而关联则意味着类实际上以属性的形式包含对其他类的一个（或多个）对象的引用。
(3)聚合(Aggregation)：空心菱形箭头
聚合只是关联的加强版，用来表明一个类实际上拥有但可能共享另一个类的对象。
(4)组合(Composition)：实菱形箭头
组合的内涵：为组成类的内在部分建模。
(5)继承(Inheritance)：空心三角箭头
虽然UML支持多重继承，但大多数情况下，仍不认为多重继承是实践中的最佳做法。主要是由于在两个父类具有重复的属性或行为时，多重继承里的父类会存在错综复杂的问题（如子类会获得重复属性的哪一副本？）。JAVA的接口机制可以规避这一问题。

抽象类
使用斜体字书写抽象操作的签名。如果类的任何部分均被声明为抽象的，则类本身也需要通过以斜体字书写其名称来声明为抽象的。
抽象类不能被实例化为对象，因为缺少一部分类定义：抽象的部分。

接口
在C++中，接口被实现为不包含操作实现的抽象类。
使用接口减弱类间的依赖是较好的实践做法。在实现设计模式时，使用接口（相对于抽象类）也是很有用的。在JAVA等语言里，不会仅仅为了使用设计模式，将单一的（唯一的）继承关系用完。一个JAVA类能实现任意数目的接口，因此提供一种强制执行设计模式的方式，而不需被迫要耗尽一个继承关系才能完成。

模板（Template）
当声明一个模板时，类似于声明：“我知道这个类必须使用其他类，但我不知道或不必知道最后究竟会用到哪些类”。
为了使用一个类模板，必须绑定其参数，可以通过两种方式将模板的参数绑定到一组特定的类:
(1)继承这个模板，绑定其参数
(2)在运行时绑定(binding at runtime)。随着被构造成对象，模板被告知它将有的参数类型。
.
..
...
对象图
在描述系统内的对象如何在特定情境下(scenario)一同工作时，对象图很有用（如显示运行时的配置）。
就像类一样，对象以矩形表示，但为了表示这是类的实例而非类本身，对象名称下加下划线强调。

对象之间的链接
对象图上对象之间的链接显示两个对象能彼此通信，但是不能随便将任意两个对象链接在一起。如果在两个对象之间建立链接，其类之间必定有相应的关联。

对象与它们的链接必须遵循OCL(object constraint language)语句所设置的规则，这也是OCL被称为对象约束语言而不是类约束语言的原因之一。