【UML 建模】UML建模语言入门 -- 静态图详解 类图 对象图 包图 静态图建模实战

发现个好东西思维导图, 最近开始用MindManager整理博客

.

作者 :万境绝尘 

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

.

一. 静态图概述

1. 静态图引入

(1) 图的分类

图的分类 : 图分为结构行为图 和动态行为图,结构行为图包括 用例图, 类图,对象图,组件图,配置图; 动态行为图 包括状态图,活动图,时序图,协作图;

(2) 静态图内容

静态图概念 :类图,对象图,包图 是静态图;

静态图内容 : 静态图显示系统的静态结构, 显示事物种类的内部结构, 事物种类之间的相互关系;

(3) 静态图性质

静态图永久性 : 静态图可能包含描述暂时行为, 但是静态图不显示暂时性信息;

静态图不包括动态行为 : 静态图将行为的实体描述成离散的模型元素, 但是不包括动态行为细节; 静态图将这些行为实体看做是被类所指定 并 拥有使用的物体, 这些实体的动态行为细节由交互视图 和状态视图描述; 
静态图是基础 : 静态图描述动态交互的事物, 是建立其它图的基础;

2. 类图

类图概念 : 类图描述系统中类的静态结构;
类图作用 : 定义系统中的类, 表示类之间的关系(关联, 依赖, 聚合等), 描述类的内部结构(属性, 方法等);
类图有效期 : 类描述的是静态关系, 在整个系统的生命周期都是有效的.
分析系统层次方法 : 分析用例 和 问题, 就可以得到相关的类, 然后将逻辑上相关的类封装成包, 分成包以后就能很好的体现系统的结构.

3. 对象图

对象图概念 : 对象图是类图的实例, 与类图的标示几乎完全相同;
对象图与类图区别 : 对象图显示类图的多个对象实例, 对象图是类图的实例;
对象图生命周期 : 对象存在生命周期, 对象图的生命周期就是对象存在的过程, 对象图只在系统的某一段时间存在;

4. 包图

包图的组成 : 包是由包和类组成; 
包图作用 : 包图可以表示包与包之间的关系, 用来描述系统的分层结构. 

二. 类图

1. 类图基本概述

建模起点 : 系统建模时, 通常从构造系统的基本事物开始, 包括构造这些基本事物的 基本属性 和行为;
通过关系认识系统 : 构造好基本事物之后, 考虑这些事物之间的 关系, 这样系统分析师就可以 从结构上对该系统有清晰的认识;
类图是基础 : 类图是面向对象系统建模中最基础的图, 是其它图的基础,状态图,协作图,组件图,配置图 都在类图的基础上进一步描述系统的其它方面特性.

2. 类图的概念和内容

类图概念 : 类图是描述类,接口,协作 以及它们之间的关系的图, 显示系统中类的静态结构;
类图如何描述系统 : 类图可以根据系统中各个类之间的关系描述系统的静态图, 一个静态图中可以包括多个类图;

结构模型可视化的实现 : 静态图可以包括许多类图, 静态图构造系统的词汇和关系, 结构模型的可视化就是通过类图来实现的;

类图元素(7个) :类,接口,协作,依赖关系,泛化关系,实现关系,关联关系;

类图中的通用元素 : 类图中还可以包含注解,约束, UML建模任何图都可以含有 注解 约束;

模型元素聚集 : 类图中可以包含包或子系统, 这使得模型元素聚集成了更大的模块; 

3. 类图的用途

类描述软件系统静态结构图, 支持系统功能需求, 系统分析师以支持软件系统的功能需求为目的设计静态图;

(1) 对系统词汇建模

构造边界 : UML建模之初, 就要构造系统词汇, 这些词汇可以描述系统边界, 哪些在边界之内, 哪些在边界之外;
类图描述边界 : 系统最基本的元素在构造边界的时候确定, 系统分析师用类图描述词汇 和它们的职责;

(2) 对简单协作建模

事物总有协同类 : 类之间都有相互关系相互影响, 孤立的类很少存在, 类总是与其它类协同工作;
类图描述协同 : 可视化和详述 词汇中事物协同工作方式;

(3) 对逻辑数据库模式建模

数据库模式 : 设计数据库时, 使用数据库模式来描述数据库的概念设计; 
类图描述数据库 : 数据库模式建模是数据库概念设计的蓝本, 可以使用类图对这些数据库模式进行建模.

4. 类(类图元素)

(1) 类的概述

类是核心 : 类是面向对象组织系统的核心; 类是对一组具有相同属性,操作,关系 和语义行为的对象描述,对象是类的具体实现;
类的组成 : 类中定义了一组状态 和行为; 
-- 状态 : 属性 和关联 描述状态, 属性通常没有身份的数据值, 如数字, 字符串; 关联是有身份的对象之间的关系表示; 
-- 行为 : 行为由操作来描述,方法是操作的实现;
类状态机 : 类的状态机描述对象的生命周期;

类在UML中表示 : 
-- 名称部分(Name) : 在顶端存放;
-- 属性部分(Attribute) : 在中间存放属性,属性类型(AttributeType),初始值(InitialValue);
-- 方法部分(Operation) : 底部存放操作,参数表(arg:ArgumentType),返回值(ReturnType);

(2) 类名称(ClassName)

类名称分类 :简单名称,路径名称;
-- 简单名 : 不包含冒号的单独名称叫简单名;
-- 路径名 : 用包名做前缀的类名叫做路径名;

(3) 属性(Attribute)

属性语法 : [可见性]属性名[ :类型][ =初始值][{属性字符串}];
-- 注意 : [] 中的内容可有可无;

可见性 : 属性的可见性只有公有(Public + ),私有(Private - ),受保护(Protected # ), UML中不存在默认, 如果没有显示任何符号, 就表示没有定义该属性;
-- 公有 : 用 "+" 表示, 可以在此类的外部使用查看该属性;
-- 私有 : 用 "-" 表示, 不可以从外部类中访问该属性;
-- 保护 : 用 "#" 表示, 常与 泛化 特化 一起使用;

属性名 : 类中属性名不能重复;
-- 属性名约定 : 单个单词名小写, 多个字母属性名 第一个单词小写, 其余单词首字母大写,驼峰命名;

类型 : 属性可以有类型, 该类型用来说明属性是什么数据类型;
-- 简单类型 : 编程语言中定义的 整型, 布尔型, 浮点型等;
-- 任意类型 : UML中属性类型可以使任意类型, 当类型是系统中的其它类的时候.
-- 对象状态 : 当一个类的属性被完整的定义之后, 该类任何状态都由这些属性的特定值决定;

初始值 : 对象创建设置属性初值;
-- 初始值作用 : ①保持完整性, 防止非法值破坏系统完整性; ② 为用户提供易用性;

属性字符串 : 属性字符串用来指定关于属性的其它信息, 不一定是是属性值, 如果希望添加一个属性定义规则, 但是没地方添加, 可以写在属性字符串中;

类属属性 : 相当于静态属性, 该属性被该类的所有对象共享; 类属属性带有一条下划线; 

(4) 操作(Operation)

操作服务分类 : 类的操作提供的服务可以分为两类, 一类是操作的结果引起对象状态的变化, 一类是为服务请求者提供返回值;

操作语法 : [可见性]操作名[( 参数表 )][ : 返回类型][ { 属性字符串 } ]
-- 注意 : [] 中的内容可有可无;

可见性 : 主要包括 公有(Public +), 私有(Private -), 受保护(Protected #), 包内公有(Package ~);
-- 公有 : 用 "+" 表示, 只要调用对象能访问操作所在的包, 就能访问公有操作;
-- 私有 : 用 "-" 表示, 同一个类的对象才能调用私有的操作;
-- 保护 : 用 "#" 表示, 子类对象才可以调用受保护操作;
-- 包内 : 用 "~" 表示, 同一个包内的对象才可以调用包内公有的操作;

操作名 : UML中默认驼峰式命名;

参数表 : 按顺序排列的属性 定义 操作输入; 
-- 定义方式 : 参数定义方式 "名称 : 类型", 多个参数用逗号隔开; 
-- 默认值 : 参数可以有默认值, 如果没有提供默认值, 参数将使用指定的默认值;

返回类型 : 可选, 大部分编程语言支持一个返回值类型, 如果没有返回类型, 编程语言注意加上 void;

属性字符串 : 如果需要加入预定义之外的信息, 可以在属性字符串中添加; 预定义信息就是前面的 可见性, 参数表, 返回类型等;

(5) 职责(Responsibility)

定义位置 : 在操作部分下面还可以指定职责, 职责是类或其它元素的契约或义务;
声明职责 : 创建一个类, 声明这个类所有对象具体的相同种类的状态 和 相同种类的操作, 在较高层次上, 还要声明这些属性和操作要完成的职责和特性;
职责的表述 : 职责可以写成自由形式的文本, 可以是短语, 句子, 或短文;

5. 接口(类图元素)

接口定义 : 在没有给出对象的实现和状态的情况下对对象的描述;

接口作用 : 
-- 边界清晰 : 拥有良好接口的类具有清晰的边界; 
-- 职责均衡 : 并能成为系统中职责均衡分布的一部分; 

类和接口的区别与联系 : 
-- 区别 : 接口包含操作, 不包含属性, 没有对外界可见的关联; 
-- 联系 : 一个类可以实现多个接口, 所有的类都可以实现接口中的操作; 

---接口与类的关联关系 : 接口 与 实现接口的类 通过一条实线连接;



---接口与类的依赖关联 : 使用该接口的类 通过 依赖关系 与 接口关联, 依赖关系是带箭头的虚线; 
---- 依赖接口操作 : 如果依赖类仅依赖于指定接口的操作, 那么依赖箭头指向接口;
---- 依赖实现类 : 如果依赖类依赖于接口实现类, 那么依赖箭头指向接口的实现类;



显示接口中的操作 : 接口使用普通类矩形符号, 只是在接口名称上方有 <<interface>>. 

6. 关系(类图元素)

(1) 依赖关系

1> 依赖概述

某种形式依赖 : 一个元素(生产者)的某些改变可能会影响 或者 提供消息给其它元素(客户), 客户以某种形式依赖于生产者;  



依赖表示方式 : 依赖用带箭头的虚线表示, 箭头指向生产者;
方法参数依赖 : 在类A中的方法参数是类B对象, 参数B的改变, 使A随之改变, 这样类A依赖于类B; 例如 TV 中change()方法传入频道channel, 频道改变, 电视状态改变, 这样TV依赖于channel;

2> 使用依赖(Usage)

使用依赖 : 关键字<<use>>, 声明一个模型元素A需要用到已存在的另一个模型元素B (即在A中定义一个B成员变量), 这样才能正确实现使用者的功能, 使用依赖的方式包括了 调用依赖,实例化依赖,参数依赖 和发送依赖; 
-- 调用依赖 : 关键字<<call>>, 一个类调用其它类的操作;
-- 参数依赖 : 关键字<<parameter>>, 声明一个操作和它的参数之间的关系, 客户类的操作使用提供者类的对象, 客户类的操作使用提供者类的参数;
-- 发送依赖 : 关键字<<send>>, 声明信号发送者 和信号接收者之间的关系;
-- 实例化依赖 : 关键字<<instantiate>>, 声明用一个类的方法创建另一个类的实例,客户类的操作返回提供者类的值, 类似于工厂类中创建类;

3> 抽象依赖

抽象依赖 : 客户与提供者之间的关系, 依赖于在不同层次上的事物;
-- 跟踪依赖 : 关键字<<trace>>, 声明不同模型中的元素存在一些连接, 通常这些模型是开发过程中不同阶段的模型;
---- 作用 : 追溯跨模型系统要求, 跟踪模型中会影响其它模型的模型所引起的变化;
-- 精化依赖 : 关键字<<refine>>, 具有两个不同语义层次上的元素之间的映射,不完善到完善之间的映射, 不会再最后模型中共存;
-- 派生依赖 : 关键字<<derive>>, 声明实例A可以从实例B导出;

4> 授权依赖

授权依赖 : 事物A访问事物B的能力是授权依赖; 提供者(被依赖者,独立)可以规定客户(依赖者,不独立)对齐访问权限, 可以控制客户对其内容访问的方法;
-- 访问依赖 : 关键字<<access>>, 允许包A问包B;
-- 导入依赖 : 关键字<<import>>, 允许包A访问包B, 并为包B的组成部分增加别名;
-- 友元依赖 : 关键字<<friend>>, 允许包A访问包B, 不管包B的元素是否具有可见性;

5> 绑定依赖

绑定依赖 : 关键字<<bind>>, 为模板参数指定值, 以生成一个新的模板元素; 将数值分配给模板参数, 可以通过取代模板备份中的参数实现;

(2) 泛化关系

泛化关系 : 泛化关系就是继承关系, 子类和父类之间的关系就是泛化关系;
泛化关系表示 : 泛化关系用空心三角箭头表示,箭头指向父类, 多个泛化关系可以用箭头线组成的树来表示;

(3) 关联关系

1> 关联关系的一些定义

关联关系定义 : 描述一组具有共同特征, 行为特征, 关系和语义的链接;
结构关系 : 关联关系是一种结构关系, 指明事物A对象与事物B对象间的关系;
链接是关联实例 : 两个对象存在链接, 那么对象对应的类之间存在关联关系, 链接是关联的实例;
关联关系表示 : 关联关系可以使用一条链接两个类的实现表示;



二元关系 : 关联的实例是链接, 每个链接由一组对象构成, 每个对象来自不同的类, 对象A与对象B一对一关系就是二元关系;

2> 关联关系的修饰

a. 名称

名称定义 : 关联的名称, 用来描述关联的性质;
名称命名规范 : 使用动词或动词短语命名关联, 表明源对象在目标对象上执行的动作;
方向指示符 : 在名称后面添加一个方向指示符(实心的三角形), 用来消除可能存在的歧义; (不知道怎么画)

b. 角色

角色定义 : 当类A处于关联的某一端时, 该类就在关联关系中扮演一个角色, 即类A对类B所表现的职责;
角色命名规范 : 角色名称使用名词或者名词短语命名;
修改角色名称 :  双击关联关系那条线, 在Role A/B General 中修改角色名称;

c. 多重性

多重性是约束 : 约束是UML三大扩展机制之一, 多重性是一种使用的最广泛的一种约束;
多重性表示 : 格式 "min .. max", min和max是int类型, 表示该端点有多少个对象可以与另一个端点的对象关联;

d. 聚合(Aggregation)

聚合关系定义 : 聚合表示整体与部分之间的关联;
聚合关系表示 : 聚合关系使用带空心零星箭头实线表示, 箭头方向指向整体;

该聚合关系解析 : 一所大学中有1个活多个学院, 一个学院只属于一个大学, 菱形箭头方向指向整体;

e. 组合关系(Composition)

强聚合 : 组合关系是聚合关系中的一种特殊形式, 是更强形式的聚合;
组合关系的特殊性 : 成员对象的生命周期取决于聚合的生命周期, 当主对象消失, 成员对象也随之消失;
组合关系表示 : 组合关系由实心菱形箭头表示, 箭头方向指向主体方向;

f. 导航性(Navigation)

导航性定义 : 对象A通过链可以访问对象B, 对一个关联关系设置导航型就是本端对象A可以访问另一端对象B;
单向关联 : 单向关联用一个带箭头的实现表示;
双向关联 : 双向关联用一条直线表示;

.

作者 :万境绝尘 

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

.

(4) 实现关系

实现关系定义 :规格说明和其实现之间的关系是实现关系;

实现关系组成 : 实现关系意味着要具有接口一样的说明元素, 也可以用一个具体的实现元素来暗示它的说明必须被支持, 例如实现关系可以用来表示类的一个优化形式和一个简单低效的形式之间的关系, 没有支持说明就变得很低效, 必须支持规格说明;

泛化实现区别 : 泛化关系的两个元素在相同语义层, 相同模型中; 实现关系的两个元素在不同语义层次, 不同模型中;

实现关系的使用情况 :接口与实现类之间,用例与实现该用例的协作之间;

实现关系表示 : 
-- 正常表示 : 指向接口的空心三角形虚线表示;
-- 省略表示 : 接口是小圆圈, 可以使用一条实线表示;

7. 类图建模技术

(1) 对协作建模

协作定义 : 类不是单独存在的, 需要与其它类协作, 协作是动态交互在静态图上的映射, 协作的静态结构通过类图来描述;

协作建模策略 : 
-- 识别建模机制 : 机制描述了正在建模的部分系统 的功能和行为, 这些功能和行为由 类, 接口 和 一些元素交互产生;
-- 识别机制组成 : 对每种机制, 识别参与协作的类,接口和其它协作, 并识别这些事物之间的关系;
-- 通过协作检错 : 用协作的脚本检测事物, 通过这种方法发现模型中被遗漏的部分 和有明显语义错误的部分;
-- 属性方法转换 : 将元素 和 它们的内 容聚合在一起, 即平衡类的职责,将职责转换成具体的 属性 和 方法;

(2) 对逻辑数据库模式建模

存储永久对象 : 许多系统中都存在永久对象, 使用关系数据库, 面向对象数据库 或混合关系/对象数据库 存储永久对象. 
ER图与UML建模区别 : 
-- 建模数据库局限性 : ER图只能针对逻辑数据库建模, UML可以对逻辑数据库 物理数据库进行建模,物理数据库中, 类图将逻辑操作转为触发器或存储过程;
-- 建模方式区别 : ER图只能针对数据建模, UML在数据基础上可以针对行为进行建模; 

数据库模式建模策略 : 
-- 类的生命周期 : 在模型中识别的类, 该类状态必须超过其应用系统的生命周期;
-- 类图特定标记 : 包含永久类的类图, 必须标记为永久的(persistent), 对特定的 数据库细节 可以定义自己的 标记值集合;
-- 注重详细细节 : 展开这些类的结构性细节, 详细描述属性细节,注重于关联和构造类的基数;
-- 简化逻辑结构 : 观察系统中的公共模式(关联方式), 它们经常造成物理数据库设计的复杂变化, 必要时可以创建简化逻辑结构的中间抽象; 
-- 业务逻辑封装 : 考虑这些类的行为, 扩展 对数据存储 和 数据完整性来说 重要的操作, 与对象集的操作相关的业务规则 应该被封装在 永久类的上一层;
-- 逻辑物理转换 : 尽量用工具将逻辑设计转换成物理设计;

(3) 正向工程

建模目的 : 建模时为了及时交付满足用户需求 及业务发展目标 的软件, 因此要保证创建的模型 与 交付产品 相匹配, 并使模型与产品 保持同步 的代价降到最低;
UML映射语言 : UML可以把类图清楚的映射到各种面向对象语言上;
映射信息损失 : 正向映射是 把 模型转为代码的过程,UML 中模型描述 比当前任何面向对象语言都要丰富, 映射的过程中会有一定信息损失, 因此UML模型不可或缺;

正向映射策略 : 
-- 识别映射语言 : 识别映射到所选择的的实现语言的规则;
-- UML信息有损失 : 选择的语言的语义, 可能会限定一些UML特性的使用, 即UML信息不能用语言完全表达出来, 会有一定的损失;
-- 精确控制层次 : 用标记值详细描述目标语言, 若需要精确控制, 该操作可以在单个类的层次 上进行, 也可以用在 较高层次(协作,包) 上运行;
-- 正向工程工具 : 使用工具对模型进行正向工程;

(4) 逆向工程

逆向工程定义 : 逆向工程是通过特定实现语言的映射, 将代码转换为模型的过程;
冗余信息 : 代码转为模型会有大量的细节层次, 对于模型来说这些细节太详细, 属于冗余信息;
信息缺失 : UML中的信息要比语言丰富, 因此逆向工程生成的模型是不完整的, 因为正向工程损失了一些编程语言不能表达的UML信息;

逆向工程策略 : 
-- 识别映射规则 : 识别从视线语言到所选择的语言进行映射的规则;
-- 逆向工程工具 : 使用工具指向要进行逆向工程的代码, 用工具生成新的模型或修改以前进行正向工程使已有的模型;
-- 查询模型创建 : 使用工具, 通过查询模型创建类图;

三. 对象图

(1) 对象图引入

静态和动态图 :类图描述的是系统的静态结构和关系,交互图描述的是系统的动态特性.
类图和交互图缺陷 : 跟踪系统的交互过程时, 经常涉及到交互过程中某一瞬间交互对象的状态, 但是系统的类图和交互图都没有对此进行描述.
对象图引入 : 对象图用来描述参与一个交互的各个对象的某一时刻的状态;

对象图作用 : 在复杂系统中, 出错时涉及的对象处于一个有众多类的关系网中, 系统测试人员需要为出错时刻系统各个对象的状态建立对象图, 这样能方便分析错误;

(2) 对象图概念和内容

对象图定义 : 对象图表示在某一时刻一组对象以及它们之间的关系, 可以被看做是类图在系统某一时刻之间的关系图;
对象图的表示 : 对象图由节点和连接节点的连线组成, 节点可以是对象, 也可以是类, 连线表示对象间的关系, 类名下面带下划线;
对象图内容 : 对象图除了对象节点 以及连线之外, 还可以包含标注 和约束; 如果有必要可以将 类 画到对象图中, 如果系统比较复杂还可以包含模型包 和 子系统; 

对象图侧重点 : 对象图可以对对 系统静态设计 或 静态进程视图建模, 但对象图更注重 现实 或 原型实例, 这种视图主要支持系统的功能需求(即提供给用户的服务);

(3) 对象图建模

对象图的两个来源 : 对象图主要用来描述类的实例在特定时刻的状态, 它可以是类的实例, 也可以是交互图的静态部分;
对象图与组件图和配置图的共同点 : 组件图和配置图可以包含 部件 或 节点 的实例, 如果它们只包含实例, 不包含任何信息, 可以将组件图和配置图看做是特殊的对象图;

对象图建模过程 : 
-- 确定对象 : 参考类图和交互图, 确定参与交互的对象;
-- 确定关系 : 确定类之间的关系, 例如 依赖, 泛化, 实现, 关联;
-- 交互建模 : 针对交互在某个特定时刻各个对象的状态, 使用对象图为这些对象建模;

-- 状态关系 : 系统分析师根据建模的目标, 绘制对象的 关键状态 和 关键对象 之间的连接关系;

四. 包图

1. 包的概述

包图的构成和作用 : 包图由包和包之间的关系构成, 它是维护和控制系统总体结构的重要建模工具;

模型分组控制 : 语义相近的 类, 接口, 组件, 节点和图组织起来放在一个包里, 可以方便理解和处理整个模型;

可见性控制 : 一些元素在包外可见, 一些隐藏在包内, 严密控制对包内元素的访问, 可以使包高内聚,低耦合;

2. 包的名字

简单名(simple name) : 一个简单的名称;

路径名(path name) : 包位于外围包的名字作为前缀的包名;

3. 包的元素

包可以拥有的元素 :类,接口,组件,节点,协作,用例和图, 还可以包含其它包;

包内元素命名规则 : 类和包都的路径名是上一级包名, 因此包为其拥有的模型元素构成一个命名空间,一个模型包内不能有名称相同的元素;

包和内部元素的关系 : 包拥有内部的元素, 这是一个组合关系, 如果包被删除, 其中的元素也随之删除;

4. 包的可见性

包不是孤立的 : 包在软件模型中不是孤立存在的, 包里面的模型元素 与外部的类存在着某些关系;

内聚耦合 : 为了使各个包能坐到高内聚,低耦合, 对包内的元素加以控制, 一些元素可以被外界访问到, 一些不能被外界访问;

包的可见性分类 :

-- 公有 (public) : 前缀符号 " + ", 该元素可以被任何引入该包的包中元素访问, 引入包就是 包A 引入包B, 包A的元素可以访问包B中的 +元素;

-- 受保护 (protected) : 前缀符号 " # ", 该元素可以被继承该包的包中元素访问, 包A 继承 包B, 包A可以访问包B中的 #元素;

-- 私有 (private) : 前缀符号 " - ", 该元素只能被同一个包中的元素访问, 包A中的私有元素只能被包A中的元素访问到;

举例 : 包A 中有四个公有元素, 包B引入包A, 包B中的元素都能看到包A中的四个公有元素;

嵌套可见性 : 元素A 对于 包B 是可见的, 包B 中还嵌套 包C, 那么包C也能看到 元素A; 被嵌套的包C可以看到包含该包(C) 的包(A)所能看到的所有的事物;

5. 引入与输出

引入 : 允许一个包中的元素单向访问另一个包中的元素;

引入关系建模 : 使用构造性引入修饰的依赖为引入关系建模; 通过把抽象包装成有含义的组块, 然后用引入关系控制对它们的访问, 就能控制大量抽象的复杂性;

输出 : 包的公共部分成为输出;

包之间的引入表示方法 : 使用虚线箭头表示引入,箭头方向表示被引入的包, 即输出元素的包;

引入分析 : 包1 引入 包2, 包2 引入 包3;

输出分析 :

-- 包2输出 : 包2 输出 B1 元素, 因为 B2 元素是私有的;

-- 包3输出 : 包3 输出 C1 元素, 因为 C2 元素是受保护的;

可见分析 : 可见只能在引用的双方进行,不包括隔代引用, 例如 包3 的C2 不能对于 包1 内容可见;

包1可见 : 包2 的 B1 对包1的内容是可见的;

包2可见 : 包3 的 C1 对包2的内容是可见的;

6. 包中的泛化关系

包中的两种关系 : 依赖(引入) 和 泛化;

-- 引入(访问依赖) : 在 包A 中引入 包B 的元素;

-- 泛化 : 说明包的家族;

泛化关系 : 包之间的泛化关系类似于类之间的泛化关系, 该关系也像类那样遵循替代原则, 包可以替换一般的元素, 并可以增加新的元素;

7. 标准元素

包的扩展机制 : UML的扩展机制同样适用于包, 可以使用标记值增加包的新特性, 用来描述包的新种类, 这种标记值有五种 :虚包(facade),框架(framework),桩(stub),子系统(subsystem),系统(system);
-- 虚包 : 描述只引用其他包内元素的包, 自己本身没有元素;

-- 框架 : 描述由模式组成的包;

-- 桩 : 描述一个作为另一个包的公共内容代理的包, 与虚包对应;

-- 子系统 : 描述正在建模中整个系统的独立部分的包;

-- 系统 : 描述建模中整个系统的包;

8. 包图建模

包的作用 : 将建模元素按语义分组, 使得复杂的系统模型能够被构造,表达,理解和管理;

包和类的区别 : 类是对问题领域 或 解决方案的抽象, 包是将事物组织成模型的一种机制; 包可以没有标志, 因为包没有实例, 在系统中不可见, 类必须有标志,因为其有实例;

包图建模策略 :

-- 分组 : 分析系统模型元素, 将概念上或语义上相近的模型元素放入一个包;

-- 可视性 : 将包中的每个元素都标出可见性 (公共, 受保护, 私有);

-- 依赖 : 确定包之间的依赖关系, 特别是输入依赖;

-- 泛化 : 确定包之间的泛化关系, 特别是多重性 与 重载;

-- 绘制 ,精化包图;

包图建模实例 :

-- 系统包 : 包含读者, 管理员, 借书相关业务的用例, 类等信息;

-- 界面包 : 包含操作界面, 窗体相关的用例, 类等信息;

-- 公共包 : 包含公共用例, 类等信息;

-- 数据包 : 包含数据库相关的用例, 类信息;

五. 图书管理系统静态图建模实战

静态图建立 : 建立系统的静态图是对系统领域问题及其解决方案的分析和设计的过程, 静态图设计的主要内容是建立类图, 找出系统中类之间的关系;

1. 建立对象图步骤

建立对象步骤 :

-- 确定需求 : 研究分析问题领域, 确定系统需求;

-- 属性操作 : 发现对象和对象类, 明确类的属性和操作;

-- 静态关系 : 发现类之间的静态关系, 泛化, 关联, 实现, 依赖关系;

-- 类与关系 : 设计类与关系;

-- 绘制类图 : 绘制对象类图, 并编制应用说明;

2. 使用Rational Rose绘制包图和类图

(1) 包图

先建包 : Rational Rose中可以创建多个类, 类的属性和方法都能在类图中体现, 为了方面管理, 通常先创建包, 在创建对应的类;

图书管理系统中的四个包 : 系统包 (System Service), 界面包 (System UI), 工具包(System Common Utilities), 数据库包(System Database);

(2) 类图(系统包)

类图解析 : Item 书目类, Tittle 书标题, Reservation 预借类, Borrower 借阅者类, Loan 借阅记录类;

.

作者 :万境绝尘 

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

.