UML建模语言入门-视图,事物,关系,通用机制

.

作者 :万境绝尘 

转载请注明出处 : http://blog.csdn.net/shulianghan/article/details/18964835

.

一. UML视图

1. Rational Rose浏览器中的四个视图

用例视图(Use Case View) : 用例视图中包括 参与者, 用例, 用例图, 时序图 和 协作图, 用例视图与代码实现无关, 该视图关注系统的高层, 不关注如何具体实现.

逻辑视图(Logical View) : 逻辑视图中包括需要的特定类, 类图 和 状态图; 逻辑视图关注如何实现用例视图中的具体功能, 将组件之间的关联, 系统如何运作的详细图形画出来.

组件视图(Component View) : 组件视图包括模型代码库, 可执行文件, 运行库等组件信息; 组件是代码的实际模块, 组件 和 组件图在组件视图中显示, 组件视图显示代码模块之间的关系.

配置视图(Deployment View) : 配置视图 相当于 系统的实际配置, 与逻辑结构有所不同, 系统结构是三层的, 但是对应的配置视图可能是两层的.

2. RUP 4+1 视图

四种视图之间的关系 :用例视图(Use Case View)是系统的核心, 其它的四个视图都要基于Use Case View展开;逻辑视图(Logical View)中包括静态结构和动态行为,实现视图(Implementation View)依赖逻辑视图的静态结构,进程视图(Process View)依赖逻辑视图的动态行为;配置视图依赖进程视图 与 实现视图;

(1) 逻辑视图(Logical View)

使用者 : 设计人员, 开发人员.

实现需求 : 系统功能.

作用 : 揭示系统的内部设计和协作情况, 逻辑视图实现系统功能角度 : 静态结构 , 动态行为.

静态结构 : 描述 类, 对象, 关系.

动态行为 : 描述对象之间发动消息产生的动态协作, 一致性, 并发.

UML对等视图: 逻辑视图(Logical View).

(2) 实现视图(Implementation View)

使用者 : 码农

实现需求 : 系统的可扩展性, 可移植性, 可重用性, 易用性, 易测试性.

作用 : 描述软件的静态结构, 显示代码之间的组织方式, 通过系统输入输出关系的模型图 和 子系统图, 来描述实现模块之间的依赖关系. 

内部需求 : 开发难易程序, 重用可能性, 通用性, 局限性等; 层次越低的组件通用性越好.

UML对等视图 : 组件视图(Component View). 

(3) 进程视图(Process View)

使用者 : 系统集成.

实现需求 : 稳定性, 安全性, 伸缩性, 鲁棒性.

作用 : 显示系统并发性, 解决在并发系统中存在的通信和同步问题, 该视图显示进程, 线程, 对象等运行时状态, 以及相关同步, 并发, 通信等问题.

进程视图与实现视图关系 : 实现视图显示的是编译时的静态关系, 进程视图显示的是编译完之后运行时的对象, 线程, 进程之间的交互问题.

UML对等视图 : 并发视图(Concurrency View).

(4) 配置视图(Deployment View)

使用者 : 运维

实现需求 : 拓扑结构, 系统安装, 通信.

作用 : 软件到硬件的映射, 目标程序及其依赖的运行库和系统软件部署到物理机器上去, 以及部署机器和网络配合软件系统的可靠性,可伸缩性等要求. 配置视图综合考虑软件系统和整个IT系统相互影响的架构视图.

配置视图与进程视图关系 : 进程视图关注程序的动态执行情况, 配置视图关注程序的静态位置.

UML对等视图 : 配置视图(Deployment View).

(5) 用例视图(Use Case View)

使用者 : 全部人员

作用 : 描述用户需要的系统功能. 用例是客户要求的系统中的一个功能单元, 相当于参与者与系统之间的一次交互. 用例模型列出系统中的用例和参与者, 显示哪个参与者执行哪个用例.

核心 : 用例视图是其它四种视图的核心, 其作用是驱动其它视图开发.

二. UML中的事务

UML中事务是模型中首要成分的抽象,关系把事务结合在一起,图聚集了相关事务.

事务是UML中面向对象的基本模块, UML中事务包括 结构事务,行为事务,组织事务,辅助事务. 事务在模型中属于静态部分, 代表物理上或概念上的元素.

1. 结构事物(Structure Things)

      

结构事务是模型中的 静态事务, 主要包括7种, 类 接口 用例 协作 活动类 组件 节点.

(1) 类 (Class)

类具有相同属性, 方法, 语义, 关系的集合; 一个类可以实现一个或者多个接口, UML中, 类包括类名, 属性名, 方法;

(2) 接口 (Interface)

接口是类或组件提供的可以完成特定功能的操作集合, 接口描述了类或者组件对外的可见的操作. 一个类可以实现多个接口.

(3) 用例 (Use Case)

用例定义了系统的一组操作, 特定的用户可以执行该操作.

(4) 协作 (Collaboration)

协作是交互的操作, 角色和其它元素一起工作, 提供一些合作的动作 . 类可能是协作的组成部门, 协作代表构成的系统的实现.

(5) 活动类 (Active Class)

类对象有一个或多个进程或线程的类是活动类, 活动类与类相似, 活动类对象代表的元素的行为与其它的元素同时存在.

(6) 组件(Component)

组件是物理上可替换的, 实现一个或多个接口的系统元素. 

(7) 节点(Node)

节点是物理元素, 运行时存在, 代表一个可计算的资源, 例如服务器, 进程等. 

2. 行为事物(Behavior Things)

行为事务又叫动作事务, 与结构事务不同, 是UML模型中的动态部分, 代表时间和空间上的动作, 结构事务是UML模型中的静态部分.

行为事务有两种 : 交互 ,状态机. 它们是UML模型中最基本的两个动态事务元素, 

(1) 交互(Interaction)

交互是在特定上下文中的一组对象, 这一组对象为共同完成一定的任务进行一系列消息交换所组成的动作就是交互. 交互包括消息,动作序列(消息产生的动作),对象之间的连接组成. 交互中的消息通常画成带箭头的直线.

(2) 状态机(State Machine)

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

3. 组织事物 (Grouping Things)

组织事物又叫分组事物, 只有一种, 就是 包(Package).

组织事物是UML模型中组织部分, 相当于一个盒子, 每个盒子中的对象关系比较复杂;盒子与盒子之间的关系相对简单.

包是一种将一系列元素分组的机制;组件也是元素分组的机制; 

包与组件区别 : 包是一种概念上的东西, 仅存在与开发阶段, 组件是一种物理元素,存在于运行时.

4. 辅助事务(Annotation Things)

辅助事务就是注释.

三. UML中的关系(Relationship)

UML中的关系主要有5种 : 关联关系, 聚合关系, 依赖关系, 泛化关系, 实现关系.

(1) 关联关系(Association)

关联关系是结构化关系, 指一种对象和另一种对象有关联. 两个对象有关联就是从一个对象中可以访问到另一个对象, 即就是在类中将另一个类的对象声明为成员变量. 

双向关联 : 如果两个类互相声明对方对象为成员变量, 那么这个关联就是双向关联; 

单向关联 : 如果两个类中只有一个类声明另一个类对象为成员变量, 那这个关联成为单向关联.

关联关系表示 : 关联关系用一条实线表示.

(2) 聚合关系

聚合概念 : 类之间的关系是整体与部分之间的关系, 一个表示整体的模型元素可能由多个表示部分的模型元素聚合而成, 如汽车由发动机, 轮胎聚合而成.

共享聚合 : 如果聚合中表示部分的模型还参与其它整体对象的聚合, 那么该聚合是共享聚合;

复合聚合 : 如果聚合中表示部分的模型只隶属于整体类, 那么该聚合就是复合聚合.

复合聚合表示 : 聚合关系用一端带空心菱形的直线表示, 菱形端连接表示整体事物的模型元素.

组合关系 : 组合关系是比聚合关系更紧密的耦合关系, 部分类需要整体类才能存在, 整体类被销毁, 部分类也要随之销毁.

组合关系表示 : 一端带有实心的小菱形直线表示, 小菱形端连接表示整体事物的模型元素.

(3) 依赖关系 (Dependency)

依赖关系描述两个模型元素之间的语义关系 : 一个模型元素是独立的, 另一个不是独立的, 非独立的模型元素依赖于独立模型元素, 独立模型改变将影响依赖于其的非独立模型. 

关联关系与依赖关系区别 : 依赖关系的对象间表现非固定关系, 如手机与充电器, 手机不是时刻都需要充电器的, 但是没有充电器, 手机就玩不转.

4. 泛化关系 (Generalization)

泛化关系定义了一般元素和特殊元素之间的分类关系, 泛化类似于继承关系. 可以分为普通泛化 和受限泛化.

普通泛化 : 没有给泛化添加约束, 普通泛化用一条带空心箭头的实线表示.

受限泛化 : 给泛化附加约束条件, 说明泛化关系的使用方法和扩充方法. 预定义的约束有4种 : 多重, 不相交, 完全, 不完全.

5. 实现关系 (Realization)

将一种模型元素(类)与另一种模型元素(接口)连接起来, 接口只是行为的说明, 不是结构或者实现.

两种实现关系 :接口与实现它的类之间的关系,用例和实现它的协作之间的关系.

实现关系表示 : 实现关系用一条带空心的虚线箭头表示.

四. UML 中的图

UML中的图分为两类, 结构行为图 和动态行为图. 

结构行为图 :类图 ,对象图 ,用例图 ,组件图 ,配置图 .

动态行为图 :状态图 ,活动图 ,时序图 ,协作图 .

每个图中的概念 

类图 : 类 , 关联 , 泛化 , 依赖关系 , 实现 , 接口 .

用例图 : 用例 , 参与者 , 关联 , 扩展 , 包括 , 用例泛化 .

组件图 : 组件 , 接口 , 依赖关系 , 实现 .

配置图 : 

状态图 : 

活动图 : 

时序图 : 

协作图 : 

1. 用例图 (Use Case Diagram)

用例图展现了一组 用例  参与者 它们之间的关系. 可以描述系统的静态使用情况. 

下面的用例图中 : 用户 和 ATM机 是参与者, 插入卡 输入密码是用例.

2. 类图 (Class Diagram)

类图展示了 类  接口  协作 之间的关系, 一个系统有多个类图, 高层建模给出类的主要职责, 底层建模给出类的属性和操作. 

下图中 人民币账户 美元账户 从账户类继承, 它们是泛化关系. 账户与ATM机 , 用户与两种账户是关联关系.

3. 对象图 (Object Diagram)

对象图 是 类图的变体, 对象图使用与类图相似的符号描述. 

对象图与类图的区别 : 

表示的概念 : 对象图显示的是类的多个对象, 而非实际的类. 对象图是类的一个例子, 显示系统执行时的一个快照, 即在某一个时间点上系统可能呈现的样子. 

表示不同 : 对象图使用带下划线的对象名称来表示对象, 显示一个关系中的所有实例.

4. 组件图

组件图 由 组件接口 组件之间的关系组成. 组件 可以是 源码 二进制码 可执行程序. 组件图表示系统不同的物理部件及其关系.

下图中, 组件1 和 组件3 都依赖于 组件2.

5. 配置图 (Deployment Diagram)

定义 : 配置图展现运行时处理节点(服务器,主机) 以及 其中组件的配置(打印机,扫描仪). 配置图可以说明系统结构的静态配置图, 即 分布 交付 安装 的物理系统. 

描述硬件 : 配置图描述系统硬件的物理拓扑结构, 即网络布局和组件在网络中的位置; 

描述软件 : 描述在设备上执行的软件, 即运行时软件在节点中的分布情况. 

6. 时序图 (Sequence Diagram)

时序图含义 : 

a. 动态协作 : 时序图显示多个对象间的动态协作, 主要是显示对象之间发送消息的时间顺序. 

b. 时间点预测 : 时序图也显示对象之间的交互, 即在系统执行的时候,某个时间点将会发生的事情. 

时序图用途 :表示用例中的行为顺序, 当执行一个用例行为的时, 时序图中每一条消息对应了一个类操作, 或状态机中引起装换的触发事件.

7. 协作图 (Collaboration Diagram)

组织结构建模 : 协作图对交互中有意义的对象和对象之间的连接建模, 强调收发消息对象的组织结构, 按照组织结构对控制流建模.

显示关系 : 除了显示消息的交互之外, 协作图还显示对象 及对象之间的关系.

8. 状态图 (Statechart Diagram)

状态图定义 : 状态图显示一个对象所有可能的状态 , 以及各种事件发生而引起的状态转移.

状态图的作用 : 状态图描述了一个状态机, 用状态图说明系统的动态视图. 

状态图建模 : 状态图对接口,类, 协作的行为建模很重视, 可以用来描述实例的生命周期.

开始结束分别用实心圈和带环的圈表示.

9. 活动图 (Activity Diagram)

活动图是状态图的变体, 显示系统从一个活动到另一个活动的流程, 活动图显示了一些活动, 强调是对象之间的流程控制. 

五. 通用机制

UML中的通用机制, 使UML变得简单, 易于使用. 使用通用机制可以为模型元素提供额外的注释,信息或语义. 

1. 修饰

修饰表示 : UML建模时, 可以将图形修饰附加到UML图形的模型元素上. 通常修饰写在相关元素旁边, 所有对修饰的描述与它们所影响的元素的描述放在一起.

修饰作用 : 为图形中的元素增加语义. 

修饰例子 : 当一个元素代表一个类型的时候, 名称可以用粗体来表示; 当一个元素代表一个类型的实例的时候, 名称可以用下划线表示; 当一个元素代表接口的时候, 那么其名称用斜体表示. 表示类的方法的时候 : "-"表示私有, "+"表示公有, "#"表示保护类型.

2. 注释

注释用一条虚线连接到其解释的元素上, 注释可以使模型更加清晰.

注释使用技巧 : 

a. 依赖 : 将注释放在需要注释的元素旁边, 使用依赖关系连接, 注释依赖于元素.

b. 隐藏 : 注释平时可以隐藏;

c. 嵌入 : 如果注释很长, 可以放到外部文本中, 然后嵌入到模型中.

3. 规格说明

模型元素具有许多用于维护该元素的数据值特性, 特性用名称和被称为标记值的值定义.

标记值 : 标记值是一种特定的类型, 如整型, 字符串.

名称 : UML中特性是预定义的, 如文档(Documentation), 职责(Responsibility), 永久性(Persistence), 并发性(Concurrency).

4. 通用划分 (General Division)

(1) 型-实例

定义 : 型-实例(Type-Instance)描述了一个通用描述符与单个元素之间的对应关系. 通用描述符成为型元素, 它相当于类, 单个元素是实例元素, 相当于类的实例; 一个型元素可以对应多个实例元素.

表示 : 实例元素使用与通用描述符相同的表示图形, 但是名称的表示不同. 实例元素名称带有下划线, 并且实例元素名称后面还要加上冒号和通用描述符.

举例 : 类 与 对象 相当于一种 型-实例划分, 数据类型 与 数据值 .

(2) 接口-实现

接口生命了一个规定了服务的约定, 实现负责执行接口的全部语义, 并实现该项服务.

5. 扩展机制

UML扩展机制允许UML使用人员根据需要自定义一些构造型语言, 扩展机制既可以扩展UML功能, 还可以使语言用户化.

.

作者 :万境绝尘 

转载请注明出处 : http://blog.csdn.net/shulianghan/article/details/18964835

.