第五章 包图
合集下载
包图
一个大型系统中往往包含了数量庞大的模型元素，如何组织管理这些元素是一个十分重要的问题。
包是一种常规用途的有效的组合机制。
包类似于文件系统中的文件夹或者是目录结构，它是一个容器，用来对模型元素进行分组，并且为这些元素提供一个命名空间。
UML中的一个包直接对应于Java中的一个包。
在Java中，一个包可能含有其他包、类或者同时含有这两者。
进行建模时，通常使用逻辑性的包，用于对模型进行组织。
而包图是由包和包之间的联系组成的，它是维护和控制系统总体结构的重要建模工具。
本章将详细介绍包图的各种概念、表示方法和实例应用。
1．包图的概念1.1包图和包当对大型系统进行建模时，经常需要处理大量的类、借口、构件、节点和图，这时就很有必要将这些元素进行分组，即把那些语义相近并倾向于一起变化的元素组织起来加入同一包中，这样便于理解和处理整个模型。
同时也便于控制包中元素的可见性。
包图是描述包及其关系的图。
与所有UML的其它图一样，包图可以包括注释、约束。
通过各个包与包之间关系的描述，展现出系统的模块与模块之间的关系。
图1是一个包图模型。
包是包图中最重要的概念，它包含了一组模型的元素和图，如图1中的Package A和Package B就是两个包。
Package BPackage A在面向对象软件开发的过程中，类显然是构建整个系统的基本元素。
但是对于大型的软件系统而言，其包含的类将是成百上千，再加上类间的关联关系、多重性等，必然是大大超出了人们对系统的理解和处理能力。
为了便于管理这些类，我们引入了“包”这种分组元素。
在包中可以拥有各种其它元素，包括类、接口、构件、节点、协作、用例，甚至是其它子包或图。
一个元素只能属于一个包。
包的作用是：1）对语义上相关的元素进行分组。
如，把功能相关的用例放在一个包中。
2）提供配置管理单元。
如，以包为单位，对软件进行安装和配置。
3）在设计时，提供并行工作的单元。
如，在设计阶段，多个设计小组，可以同时对几个相互独立包中的类进行详细设计。
静态视图—类图对象图和包图
1.1 类图概述——重要性
类图表述系统中类的静态结构，不仅描述 了系统中的类，还表示了类之间的各种关 系，比如：关联、依赖、泛化、实现等
James Rumbaugh对类的定义：类 （Classs）是具有相似结构、行为和关系 的一组对象的描述符 类 + 类的关系 = 类图
1.2 类图概述——类图的作用
salary:Dollars
Student
major:String
3.5 关联关系（Association）
关联是一种结构关系，它指明一个类与 另一个类在类间的联系，表示类之间的 连接，它使一个类的可见属性和方法被 另一个类使用
关联关系包括：双向关联，单向关联， 聚合和反射关联
除聚合关系外，关联关系通常使用实线 +箭头的方式表示
3.2 依赖关系（Dependency）
如果有两个类A与B，当我们修改A类时 会引起B类的修改，我们称类B依赖于类 A。
依赖关系可能由各种原因引起，比如一 个类向另一个类发送消息；一个类是另 一个类的数据成员，一个类是另一个类 的某个操作参数等(use a关系)
UML中包含了4种依赖关系：使用(Usage) 依赖，抽象(Abstraction)依赖，授权 (Permission)依赖和绑定(Binding)依赖
3.3.1 泛化关系的表示
在UML语言中，采用空心箭头+实线 （如果父类是接口，则采用虚线）的 方式表示泛化关系，箭头指向父类
类的继承
接口的继承
3.3.1 泛化关系的表示举例
BankAccount
owner:String balance:Dollars deposit(amount:Dollars) withdrawl(amout:Dollars)
uml-05包图与OCL
3、共同重用原则
把将会同时，或使用时间相隔不长的建模元 素放到同一个包中。不会一起使用的类不要放 在同一个包中。
4、非循环依赖原则
包之间的依赖关系不要形成循环：即A依赖 B，B依赖C，C又依赖A。
9.1.4 包图
包图由包和包之间的联系构成，包图中 的图形元素是包，包之间用依赖关系或泛 化关系连接。包图是对系统结构建模的重 要工具。
解释:
⑵ 实型
i1 = i2 等于,布尔型 (<>,>,<,<=,>=) i1 + i2 加法,实型 ( -, *, / ) i1.abs 取绝对值,实型
i1.max(i2) 取最大数,实型(min)
r1.round 四舍五入取整, 整型 r1.floor 向下取整, 整型
解释:
⑶ 字符串型
s1.conscat(s2) 连接,字符串 s1.size 字符串长度,整型 s1.toLwer 转换成为小写字母,字符串
包是一个“容器” ,包中可以包含类、接口、构件、用
例、结点、活动、状态、包等其他模型元素。 包是对软件模型进行分解、组织的有效的模型元素。
2.包的表示
UML用带把的矩形框来表示包。
简单包名
路径包名
路径包名中位于前面的是外围包，后面的是内部包。 注意包的嵌套层数不应过多。
3.包中元素的可见性
包中的元素对其他包可以访问，也可以隐藏， 可见性具有可见、保护和私有三种形式。
表示订单的税金是订单和的6.5% 。
● 蕴涵
context 订单 inv
订单的文章->size = 0 implies 订单和 = 0
表示 “订单的文章”的数量如果等于0，则“订 单”的“订单和”也必须等于0
包图PPT课件
7.8包图
.
1
包图就是用来描述包及其关系的图 ，常用包图来描述系统、子系统的宏观 组成和结构，或者用包图对成组元素分 组，以方便系统开发、维护和管理。
.
2
3
➢ 模型需要有自己的内部组织结构，一方面能够将一个 大系统进行分解，降低系统的复杂度；另一方面能够 允许多个项目开发小组同时使用某个模型而不发生过 多的相互牵涉。
Java中的一个包。在Java中，一个包可能含有其
他包、类或者同时含有这两者。UML中的包可以
包含子包、类、接口、构件和用例。
➢ 图5-1是一个典型的包，
包的名称是Client，包
中有2个类： OrderForm、
Order。
图5-1 包
.
包的表示
5
➢ 在UML中一个包由2个矩形框组成，上面是一 个小矩形，下面是一个大矩形。图5-2就是最 常见的包表示法。
.
14
6.访问权限
假设包X中的元素要访问包Y中的元素，则，表5-1列出了包间关系 、被访问元素的可见性与访问权限的关系。
表5-1 包X访问包Y中元素的条件
包Y（包Y中元素的可 见性）
包X（包X中元素素可以访问Y中可见性是+的
元素
#
若X继承了Y，则X中的任何元素可以访问Y中可见性是#的
图5-6 元素的2种表示方法
.
10
2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例，
它们是：取款用例和超额. 取款用例。
11
3．包中元素是包
12
包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有 一个类Page。
.
1
包图就是用来描述包及其关系的图 ，常用包图来描述系统、子系统的宏观 组成和结构，或者用包图对成组元素分 组，以方便系统开发、维护和管理。
.
2
3
➢ 模型需要有自己的内部组织结构，一方面能够将一个 大系统进行分解，降低系统的复杂度；另一方面能够 允许多个项目开发小组同时使用某个模型而不发生过 多的相互牵涉。
Java中的一个包。在Java中，一个包可能含有其
他包、类或者同时含有这两者。UML中的包可以
包含子包、类、接口、构件和用例。
➢ 图5-1是一个典型的包，
包的名称是Client，包
中有2个类： OrderForm、
Order。
图5-1 包
.
包的表示
5
➢ 在UML中一个包由2个矩形框组成，上面是一 个小矩形，下面是一个大矩形。图5-2就是最 常见的包表示法。
.
14
6.访问权限
假设包X中的元素要访问包Y中的元素，则，表5-1列出了包间关系 、被访问元素的可见性与访问权限的关系。
表5-1 包X访问包Y中元素的条件
包Y（包Y中元素的可 见性）
包X（包X中元素素可以访问Y中可见性是+的
元素
#
若X继承了Y，则X中的任何元素可以访问Y中可见性是#的
图5-6 元素的2种表示方法
.
10
2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例，
它们是：取款用例和超额. 取款用例。
11
3．包中元素是包
12
包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有 一个类Page。
包图组件图部署图
包(Package)
引入与输出:引入(import)允许一个包中的元素单向访问另一包中的元素 允许一个包中的元素单向访问另一包中的元素. 引入与输出 引入 允许一个包中的元素单向访问另一包中的元素
在UML中,用一个由构造型import修饰的依赖为 引入关系建模.通过把抽象包装秤有含义的组块, 然后用引入关系控制对它们的访问,就能控制 大量抽象的复杂性. 输出(export)就是包的公共部分 就是包的公共部分. 输出 就是包的公共部分 一个包输出的部分仅对显示地引入这个包 的其他包中的元素是可见的 注:引入和访问依赖是不可传递的.
虚包(Generic Package): 虚包
虚子程序(Generic Subprogram): 虚子程序
接口(Interface)
概述: 概述 在组件图中,组件可以通过其他组件的接口来使用其他组件中定义
的操作.通过使用命名的接口,可以避免在系统中各个组件之间直接发生依 赖关系,有利于组件的替换 接口和组件之间的关系: 实现关系(Realization): 依赖关系(Dependency): 组件接口的分类: 导入接口(import interface):供访问操作的组件使用 导出接口(export interface):由提供操作的组件提供
组件图(Component Diagram)
背景： 背景：在软件建模的过程中，使用用例图可以推断系统希望的行为；使用类图
可以描述系统中的词汇；使用时序图、组件图、状态图和活动图可以说明这些词 汇中的事物如何相互作用以完成某些行为。在完成系统的逻辑设计之后，下一步 要定义设计的物理实现，如可执行文件、库、表、文件和文档等。对面向对象系 统的物理方面进行建模时要用到两种图：组件图和配置图。 概述： 概述：使用组件图能够可视化物理组件以及它们之间的关系,并描述其构造细节. 组件图描述了软件的各种组件和它们之间的依赖关系.在UML中,组件图是系统实 现视图的图形表示,而其中的一个组件图只能表示系统实现视图的一部分,也即任 何一个组件图都不能描述系统实现的所 有方面,只有系统中的组件组合起来 才能表示完整的系统实现视图
(完整版)软件工程 第五章 面向对象的需求分析
第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML（Unified Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”，有许多不同的看法。
Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）一般意义来讲，对象是现实世界中存在的一个事物。
可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。
对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。
例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。
图 5-1-1 对象的定义（1）对象、属性、操作、消息定义对象可以定义为系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
第5章UML包图
17
5.6.2 调整候选包
在已经识别一组候选包后，减少包间依赖，最小化每个包中public、 protected元素的个数，最大化每个包中private元素的个数。做法如 下。 (1) 在包间移动类。 (2) 添加包、分解包、合并包或删除包。 通常，在分析阶段，将类封装为包模型时，应该尽量使包模型简单。 起初，将类图转换为包图时，不需考虑包间的泛化和依赖关系，仅 当使用诸如包泛化和依赖关系能简化包模型时，才使用这些包整理 技术。 除了保持简单，还应该避免嵌套包。包的嵌套结构越深，模型变得 越难理解。我们曾见过非常深层的嵌套包，而每个包仅包含一个或 两个类。这些模型更像是标准的、自上而下的功能分解，而不是包 模型。 作为经验法则，希望每个包具有4~10个分析类。然而，对于所有的 经验法则，却存在例外，如果打破某个法则使得模型更加清晰，就 采用这个法则。有时，必须引入只带有一个或者两个类的包，因为 需要断开包模型中的循环依赖，在这种情况下是完全合理的。
14
5.5 包的传递性
当客户包与提供者包之间是<<access>>依赖 时，提供者包中的公共元素就成为客户包中的 私有元素，这些私有元素在包外是不可以访问 的。如图5-15所示，Z包中的公共元素成为Y包 的私有元素，而X包只能访问Y包中的公共元素， 因此，X包不能访问Z包中的公共元素。所以， X、Y、Z包间的<<access >>关系不存在传递 性。
22
5.8 小
结
本章首先解释了几种常见的包图表示法， 并通过了一个简单的例子来说明包的可见 性、依赖关系、泛化等概念。其次，概要 地说明了5种包的构造型。 最后说明如何寻找包、确定包之间的依赖 关系，从而绘制出一个表明软件体系结构 的包图，并简要介绍了用包图表示系统体 系结构的建模方法。
大象：THINKING IN UML 第五章 UML核心建模
5.8 设计模型
设计模型是一个描述用例实现的对象模型， 它可作为对实施模型及其源代码的抽象。设 计模型用作实施和测试活动的基本输入。 设计模型是编码实现之前的最后一道建模工 序。
设计模型的主要Βιβλιοθήκη 入设计模型的主要内容从分析模型映射到设计模型
一个分析类可以成为设计模型中的单个类 一个分析类可以成为设计模型中某个类的一 部分 一个分析类可以成为设计模型中的一个聚合 关系类 一个分析类可以成为设计模型中从同一个类 继承而来的一组类 一个分析类可以成为设计模型中一组功能相 关的类
5.4.1 系统用例模型的主要内容
（1）业务用例。 （2）概念用例。 （3）用例视图。 （4）用例规约。 （5）补充规约。 （6）业务规则。 （7）用例实现。 （8）用例场景。 （9）分析对象。
5.4.2 获得系统用例
1.如果已经建立了业务用例，就可以从业务用例中导出系统用 例。 2.推导系统用例的基本方法是分析业务用例场景，尤其是活动 图。系统用例可以从这些职责中抽取出来。然后考虑以下问题： （1）排除用例。 （2）合并用例。 （3）抽象用例。 （4）补充用例。 （5）系统用例的粒度应当与概念用例相当。 （6）系统用例的抽象角度应当与概念用例相当。 （7）概念用例所表述出的核心业务是最需要关心的部分。
5.2 业务用例模型
业务用例模型位于RUP的先启阶段，在业务 建模核心工作流中完成。
5.2.1 业务用例模型主要内容
（1）业务用例视图。包括业务主角和业务 用例 （2）业务用例场景。说明业务用例的执行 过程 （3）业务用例规约。说明业务用例的使用 者、目标、场景、相关业务规则、相关业务 实体等 （4）业务规则。执行业务必需遵守的法律 法规、惯例、各种规定
第5章 包图
的WindowsGUI，一个是实现B/S的WebGUI。
包的构造型
• • •
《system》和《subsystem》构造型：《system》构造型 的包表示正在建模的整个系统，而《subsystem》构造
型的包则表示正在建模的系统中某个独立的部分
《facade》构造型：只是某个其它包的视图，它主要用 来为其它一些复杂的包提供简略视图 《stub》构造型：是一个代理包，它服务于某个其他包 的公共内容，这通常应用于分布式系统的建模中 《framework》构造型：用来表示一个框架的，框架是 一个领域内的应用系统提供可扩充模板的体系结构模式
知识图谱
Agenda
• • • • •
什么是包 如何阅读包图
如何绘制包图
包图应用说明 本章小结
Agenda
• • • • •
什么是包 如何阅读包图
如何绘制包图
包图应用说明 本章小结
什么是包
•
在面向对象软件开发的视角中，类显然是构建整个系统
•
的基本构造块。但是对于庞大的应用系统而言，其包含 的类将是成百上千，再加上其间“阡陌交纵”的关联关 系、多重性等，必然是大大超出了人们可以处理的复杂 度。这也就是引入了“包”这种分组事物构造块。
5 ．2
包的表示
UML中，用文件夹符号来表示一个包。包由一个矩形表示， 它包含2栏。下面是最常见的几种包的表示法，如图所示
包名放在第二栏 包名放在第一栏
PageName PageName ClassName-1 ClassName-2 …..
PageName 类名
包的表示法
Rose常用表示法
第二栏列出 包含的类名
包图的基本概念
第05章 类图、对象、包图
概念层（ 概念层（Conceptual）： ）： - 在需求分析阶段，类图主要用于领域内的一些概念类的描述，形成概念模型； 规格说明层：（ ：（Specification）： 规格说明层：（ ）： - 在设计阶段，类图着重描述类与类之间的接口等外部特性，形成设计模型； 实现层（ 实现层（Implementation）： ）： - 在实现阶段，类图主要用于描述类的在软件系统中的内部实现。
Page 2
(类目 分类器) 类目、 Classifiers (类目、分类器)
A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes data types, signals, components, nodes, use cases, and subsystems.
Page 10
属性的类型
type ：Examples of built-in attribute data types include Double, Int (short for Integer), and String . An attribute type can also be a user-defined type or the name of a class.
Page 7
属性 attribute
The full form of a UML attribute declaration is as follows:
[visibility] name [: type] [multiplicity] [= default-value] [{property-string}] visibility Name type multiplicity default-value property-string + (public), # (protected), - (private) e.g. CustomerName, DiscountRate e.g. Point, String, Date, etc. e.g. [0..1], [2..*] e.g. =(0,0), = null changeable (default), addOnly, frozen
Page 2
(类目 分类器) 类目、 Classifiers (类目、分类器)
A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes data types, signals, components, nodes, use cases, and subsystems.
Page 10
属性的类型
type ：Examples of built-in attribute data types include Double, Int (short for Integer), and String . An attribute type can also be a user-defined type or the name of a class.
Page 7
属性 attribute
The full form of a UML attribute declaration is as follows:
[visibility] name [: type] [multiplicity] [= default-value] [{property-string}] visibility Name type multiplicity default-value property-string + (public), # (protected), - (private) e.g. CustomerName, DiscountRate e.g. Point, String, Date, etc. e.g. [0..1], [2..*] e.g. =(0,0), = null changeable (default), addOnly, frozen
第5章 包图
LOGO 统一建模》 《UML 统一建模》
第5章 包图 章
目录
5 .1 包图的概念 5.2 包的表示 5.3 包图中的关系 5.4 阅读包图 5.5 创建包图 5.6 包图建模
5.1 包图的概念
模型的组织结构
先分层再细分成包的方式 系统的三层结构
用户界面层
用户界面代表 与用户进行交 互的界面
业务逻辑层用 来处理系统的 业务流程
5.1 包图的概念
1.包图 包图是描述包与包之间关系的图。包图可以包括注释、约束。包 间的关系有依赖关系和泛化关系。
包图
5.1 包图的概念
2. 包图的作用 1）对语义上相关的元素进行分组。 2）提供配置管理单元。 3）在设计时，提供并行工作的单元。 4）提供封装的命名空间。 3. 包图中的元素 在包中可以拥有各种其他元素，包括类、接口、构件、节点、协 作、用例，甚至是其它子包或图 。一个元素只能属于一个包。
5.5 创建包图
A B
合并
分解
C
A,B包合并
A
B
消除循环依赖的示例
5.6 包图建模
包图的主要用途： 1 对成组元素建模 对成组元素进行建模可以说是包图最常见的用途，它将建模元素 组织成组，然后对组进行命名，在对成组元素建模时，应遵循以下几 个策略： 每个包都应该是由在概念上、语义上相互接近的元素组成。 对于每个包，找出应标记为公共的元素，但应尽可能地少。 一般使用默认的《use》构造型，在实现类时，才用《import》 构造型代替《use》构造型。 采用泛化来对特殊包进行建模。 在构建包模型时，注意，在包中只标明对每个包起核心作用的元 素；也可以标识每个包的文档标记值，以使其更加清晰。
5.3 包图中的关系
3） 《access》关系 如果只想使用提供者包中的元素，而不想将两个包合并，则应使 用该关系。在客户包中必须使用路径名,才能访问提供者包中的所有 公共元素。 ４）《trace》关系： 想表示一个包到另一个包的历史发展，则需要使用《trace》关 系来表示。
第5章 包图 章
目录
5 .1 包图的概念 5.2 包的表示 5.3 包图中的关系 5.4 阅读包图 5.5 创建包图 5.6 包图建模
5.1 包图的概念
模型的组织结构
先分层再细分成包的方式 系统的三层结构
用户界面层
用户界面代表 与用户进行交 互的界面
业务逻辑层用 来处理系统的 业务流程
5.1 包图的概念
1.包图 包图是描述包与包之间关系的图。包图可以包括注释、约束。包 间的关系有依赖关系和泛化关系。
包图
5.1 包图的概念
2. 包图的作用 1）对语义上相关的元素进行分组。 2）提供配置管理单元。 3）在设计时，提供并行工作的单元。 4）提供封装的命名空间。 3. 包图中的元素 在包中可以拥有各种其他元素，包括类、接口、构件、节点、协 作、用例，甚至是其它子包或图 。一个元素只能属于一个包。
5.5 创建包图
A B
合并
分解
C
A,B包合并
A
B
消除循环依赖的示例
5.6 包图建模
包图的主要用途： 1 对成组元素建模 对成组元素进行建模可以说是包图最常见的用途，它将建模元素 组织成组，然后对组进行命名，在对成组元素建模时，应遵循以下几 个策略： 每个包都应该是由在概念上、语义上相互接近的元素组成。 对于每个包，找出应标记为公共的元素，但应尽可能地少。 一般使用默认的《use》构造型，在实现类时，才用《import》 构造型代替《use》构造型。 采用泛化来对特殊包进行建模。 在构建包模型时，注意，在包中只标明对每个包起核心作用的元 素；也可以标识每个包的文档标记值，以使其更加清晰。
5.3 包图中的关系
3） 《access》关系 如果只想使用提供者包中的元素，而不想将两个包合并，则应使 用该关系。在客户包中必须使用路径名,才能访问提供者包中的所有 公共元素。 ４）《trace》关系： 想表示一个包到另一个包的历史发展，则需要使用《trace》关 系来表示。
第五章 包图
第五章 包
主讲：张世铃
内容提要
1 2 3 4
为什么要使用包？ 什么是包？ UML中如何表示包？ 如何实现包？
7.1 包的基本概念 1. 包的定义
– 包(Package): 是UML用来组织模型元素的模型元 素。 – 包是一种分组事物 – 一个UML建模元素的容器 – 在UML中视为一个文件夹
包的基本概念
《use》关系：是一种默认的依赖关系 ，说明客户包 （发出者）中的元素以某种方式使用提供者包（箭头指 向的包）的公共元素，也就是说客户包依赖于提供者包 《import》关系：最普遍的包依赖类型，说明提供者包 的命名空间将被添加到客户包的命名空间中，客户包中 的元素也能够访问提供者包的所有公共元素 《access》关系：只想使用提供者包中的元素，而不想 将其命名空间合并则应使用该关系 《trace》关系：想表示一个包到另一个包的历史发 展，则需要使用《trace》关系来表示
说明
• 一个结构良好的包应满足以下要求：
– 包是强内聚的，它围绕一组相关元素来建立， 具有明确的边界。 – 包是松耦合的，只需显示出其他包确实需要用 到的那些元素即可。 – 包的嵌套层次不要太深。 – 包图的内容要均衡，系统中的各个包要彼此相 称，既不要太大（太大时可以进行分解），也 不要过小（太小时，可将一些相关元素组合成 组）。
7.3 设计包的原则
• 在设计包时，应遵循以下原则：
– 重用等价原则(Reuse Equivalency Principle, REP) – 共同闭包原则(Common Closure Principle, CCP) – 共同重用原则(Common Reuse Principle, CRP) – 非循环依赖原则(Acyclic Dependencies Principle,
主讲：张世铃
内容提要
1 2 3 4
为什么要使用包？ 什么是包？ UML中如何表示包？ 如何实现包？
7.1 包的基本概念 1. 包的定义
– 包(Package): 是UML用来组织模型元素的模型元 素。 – 包是一种分组事物 – 一个UML建模元素的容器 – 在UML中视为一个文件夹
包的基本概念
《use》关系：是一种默认的依赖关系 ，说明客户包 （发出者）中的元素以某种方式使用提供者包（箭头指 向的包）的公共元素，也就是说客户包依赖于提供者包 《import》关系：最普遍的包依赖类型，说明提供者包 的命名空间将被添加到客户包的命名空间中，客户包中 的元素也能够访问提供者包的所有公共元素 《access》关系：只想使用提供者包中的元素，而不想 将其命名空间合并则应使用该关系 《trace》关系：想表示一个包到另一个包的历史发 展，则需要使用《trace》关系来表示
说明
• 一个结构良好的包应满足以下要求：
– 包是强内聚的，它围绕一组相关元素来建立， 具有明确的边界。 – 包是松耦合的，只需显示出其他包确实需要用 到的那些元素即可。 – 包的嵌套层次不要太深。 – 包图的内容要均衡，系统中的各个包要彼此相 称，既不要太大（太大时可以进行分解），也 不要过小（太小时，可将一些相关元素组合成 组）。
7.3 设计包的原则
• 在设计包时，应遵循以下原则：
– 重用等价原则(Reuse Equivalency Principle, REP) – 共同闭包原则(Common Closure Principle, CCP) – 共同重用原则(Common Reuse Principle, CRP) – 非循环依赖原则(Acyclic Dependencies Principle,
第五章 包图
5．2 包的表示 ．
4．包的可见性 ． 公有的（ ① 公有的（public） “＋” ） 受保护的（ ② 受保护的（protected） “＃” ） 私有的（ ③ 私有的（private）“－” ）
5．2 包的表Leabharlann ．4．包的可见性 ． 包内元素的可见性控制了包外部元素访问包内 部元素的权限。 部元素的权限。 可见性 公有的 Public 受保护的 Protected 私有的 private 含义 此元素可以被任何引用该 包的包中的元素访问。 包的包中的元素访问。 此元素可被继承该包的包 中的元素访问。 中的元素访问。 此元素只能被同一个包中 的元素访问。 的元素访问。 前缀符号 + # -
若一个类的行为或结构的改变要求另一个类做相应的 改变； 改变； 删除了一个类后，另一个类成多余的； 删除了一个类后，另一个类成多余的； 两个类之间有大量的消息发送。 两个类之间有大量的消息发送。
设计包的原则
③
共同重用原则
——把不会一起使用的类不要放在同一个包中。 把不会一起使用的类不要放在同一个包中。 把不会一起使用的类不要放在同一个包中
5．1 包图的概念 ．
3．包中的元素 ． 包中的元素： 接口、组件、节点、协作、 包中的元素：类、接口、组件、节点、协作、用 以及其他包 其他包。 例、图以及其他包。 一个模型元素不能被一个以上的包所拥有。 一个模型元素不能被一个以上的包所拥有。 如果包被撤销，其中的元素也要被撤销。 如果包被撤销，其中的元素也要被撤销。
④
非循环依赖原则
——包之间的依赖关系不要形成循环。 包之间的依赖关系不要形成循环。 包之间的依赖关系不要形成循环
设计包的原则
A B
合并
分解
UML第5章 包图
• （1）在包间移动类。 • （2）添加包、分解包、合并包或删除包。
5.6.3 消除包的循环依赖
•应该尽量避免包模型中的循环依赖。 •如果包A以某种方式依赖包B，并且包B以某种方式依赖包A， 就应该合并这两个包，这是消除循环依赖非常有效的方法。 但是经常起作用的、更好的方法是，从A,B两个包中提起公 共元素，把它们封装为第三个包C。 •消除循环包的过程是一个多次迭代的过程。 •示例显示在后面图5-18中。
一种是在第二栏中列出包的所有元素名；另一种是在第二栏中 画出包中所有元素的图形和关系（参见图5-6）。
图5-6 元素的2种表示方法
• 2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例， 它们是：取款用例和超额取款用例。
3．包中元素是包 包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有一 个类Page。
UI
System:Web:UI
（a）简单名
（b）含路径名（全名）
图5-5 包称的2种书写格式
5.2.2 包中的元素
一个包中包含的元素可能是系统、子系统、子包、 用例、构件、接口和类。下面介绍包中元素的表示方 法和元素的可见性。
• 1.包中元素是类和接口 • 当包中的元素是类和接口时，可以有两种表示类和接口的方法：
称的书写格式有两种，即简单名和全名。 • 1.包名称的书写位置 • 包名称可以有两种书写位置：一种方式是将包名写在第一栏中，另一种方式是将包名
写在第二栏中。 • （1）包名写在第一栏 • 如图5-3所示，包名Server写在第一栏。在第二栏列出了该包包含的类。
图5-3 包名写在第一栏
5.6.3 消除包的循环依赖
•应该尽量避免包模型中的循环依赖。 •如果包A以某种方式依赖包B，并且包B以某种方式依赖包A， 就应该合并这两个包，这是消除循环依赖非常有效的方法。 但是经常起作用的、更好的方法是，从A,B两个包中提起公 共元素，把它们封装为第三个包C。 •消除循环包的过程是一个多次迭代的过程。 •示例显示在后面图5-18中。
一种是在第二栏中列出包的所有元素名；另一种是在第二栏中 画出包中所有元素的图形和关系（参见图5-6）。
图5-6 元素的2种表示方法
• 2.包中的元素是用例
图5-7 包中的元素是用例
图5-7表示，包ATM中包含两个用例， 它们是：取款用例和超额取款用例。
3．包中元素是包 包中元素是包时，就是包嵌套。图5-8所示，就是包嵌套的 例子。外部包System:Web里面嵌入了一个包UI,UI包中有一 个类Page。
UI
System:Web:UI
（a）简单名
（b）含路径名（全名）
图5-5 包称的2种书写格式
5.2.2 包中的元素
一个包中包含的元素可能是系统、子系统、子包、 用例、构件、接口和类。下面介绍包中元素的表示方 法和元素的可见性。
• 1.包中元素是类和接口 • 当包中的元素是类和接口时，可以有两种表示类和接口的方法：
称的书写格式有两种，即简单名和全名。 • 1.包名称的书写位置 • 包名称可以有两种书写位置：一种方式是将包名写在第一栏中，另一种方式是将包名
写在第二栏中。 • （1）包名写在第一栏 • 如图5-3所示，包名Server写在第一栏。在第二栏列出了该包包含的类。
图5-3 包名写在第一栏
第5章 信息系统分析与设计 包图
显现
隐藏
5.1.1 包的定义 5.包成员 包成员是包中的元素，例如下图中的“检索 图书”用例就是“处理订单”包的成员。
包成员
5.1.2 包的命名
1. 包名
包名应由标识符表示，并且用能够表示包含 义的名字。包的名字放到包的顶部，或包的内 面。例如：
5.1.2 包的命名
2. 包成员的命名
包中成员的名字不允许相同。 非限定名：成员的名字，不包括包的名字。 例如，下图“货品” 限定名： 成员前面缀包名。例如， B::货品
5.2.1 依赖关系
2. 包依赖的类型
2）抽象：如果一个包的元素是对另外一个包元 素的抽象，则两个包之间存在抽象关系 。
5.2.1 依赖关系
2. 包依赖的类型
3）跟踪：如果一个包的元素是对另外一个包元 素的的深化，则两个包之间存在跟踪关系 。
5.2.2 导入关系 1. 导入关系的含义
导入(import)是指将A包的元素导入到B包中，使得导入
1、重用等价原则
对于同类可重用的模型元素尽量放到一个包
中，不要把可重用模型元素和不可重用的模型
元素混到一个包中。
2、共同重用原则
把同一个应用要重用的多个模型元素放到同一
个包中，以减少包间的依赖，提高包的独立性。
3、共同封闭原则
把可能同时修改，同时维护的模型元素放到 一个包中，以便于维护和升级。
5.1.3 包的可见性
包的可见性是指包中成员被其他包或模 型元素访问的程度 ,分以下三种情况:
可见public : + 受限protected : # 私有private : -
5.1.4 包图
包图用来展现包和包之间的关系。
书店图书管理的包图：
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• •
构造性
<<system>>
<<subsystem>>
说明
表示正在建模的整个系统
表示正在建模的系统中某个独立的部分。 对于较大的系统，经常需要将其划分为几个独 立的子系统，每个子系统从较低的抽象层次观 察的时候就像一个较小的系统
<<facade>> <<stub>>
描述一个只引用其他包内元素的包，主要 用来为其他一些复杂的包提供简略视图 一个代理包，通常应用于分布式系统的建 模中，它服务于某个其他包的公共内容
总结：
本章介绍了UML包图，应用包图的目的是为了简化图， 通常当一个图变得庞大且在单一页中无法打印的时候引入 包。 • 包图中可以包含任何一种UML图，但通常更多的是用例 图或类图； • 创建用例包图，可以帮助组织需求，对需求进行高层次 的概述； • 创建类包图，可以在逻辑上组织类，对设计进行高层次 的概述。
在Rational Rose 中，支持4种包的构造型，如图5-6～
5-9。
5.2.4 子系统
•
系统是组织起来以完成一定目的的连结单元的集合，由 一个高级子系统建模，该子系统间接包含共同完成现实世 界目的的模型元素的集合。 子系统是指有单独说明和实现部分的包。它表示具有 对系统其他部分存在接口的连贯模型单元。 子系统使用具有构造型关键字subsystem的包表示，如 下图所示。
包的依赖性可以加上许多构造型规定它的语义，其中最 常见的是引入依赖。引入依赖（Import Dependency）是包与 包之间的一种存取依赖关系。 • 引入是指允许一个包中的元素存取另一个包中的元素， 引入依赖是单向的。引入依赖的表示方法是在虚箭线上标有构 造型Inport，箭头从引入方的包指向输出方的包。 • 如图所示
在创建类包图的时候，一般会采用垂直分层的方式 组织包中的类，以显示类以及类之间的关系。一般的，应 该把相同继承层次的类、彼此间有聚合或组合关系的类、
彼此合作频繁且信息能够通过UML顺序图和UML协作图反
映出来的类组织在相同的包中。 用例包图可以包含角色，可以水平地排列用例包图，
应该把关联的用例放在一起，即将具有include 、extend、
体系结构模式
<<framework>> 描述一个领域内的应用系统提供可扩充模板的
5.3 包图中的关系
包之间的关系总的来讲包括：依赖关系和泛化关系。 1、 依赖关系 对于由对象类组成的包，也就是如果两个包中的任意两个类存在 依赖关系，则称为包之间存在依赖关系。
领域
摩托车
车轮
•
在创建包的依赖关系时，尽量避免如图5-14所示的循 环依赖关系。为解决循环依赖关系，需要将Package A包 或者Package B包中的内容进行分解，将依赖于另一个包 中的内容转移到另外一个包中。如图5-15所示，Package A中依赖Package B中的类转移到Package C中。
generalization关系的用例放在相同的包中。
包建模的技巧
（1）包的命名要简单，可以用描述性的名称为包命名； （2）将高内聚的模型元素放在一个包中，例如， • 属于继承关系的父类和子类应放入相同个包内； • 类与类之间组成关联关系时，这些类应放入相同的包中； • 如果类与类之间有紧密的协作关系时，这些类应当放入 相同的包内。 （3）注意命名含义，即被导入到一个包中的元素并不知道 导入它的包对它做了什么。
2、泛化关系 • 泛化关系表示事物的一般和特殊的关系。如果两个包之 间存在泛化关系，就是指其中的特殊性包必须遵循一般性 包的接口。 • 就像类的继承一样，包可以替换一般的元素，并可以 增加新的元素。如图5-17所示
5.4 包的嵌套
包可以将其他包作为包内的元素，子包又可以拥有自己 的子包，这样就可以构成一个系统的嵌套结构，以表达系 统模型元素的静态结构关系。 • 包的嵌套可清晰地表现系统模型元素之间的关系，但在 建立模型时包的嵌套不宜过深，包的嵌套层数一般以2到3 层为宜。 如图5-18所示。 •
第五章 包图
本章要点： • • 理解包图和包的关系 理解包和包之间的关系
基础内容：模型的组织结构
重点掌握：包中的模型元素 一般了解：包的嵌套
5.1 包图的定义
包是用于把元素组织成组的通用机制。 UML模型中的组织是通过包（Package）来实现的，包 可以把所建立的各种模型组织起来，形成各种功能或用途 的模块。 在UML中对类或者其它模型元素分组时则使用包图。 包是用来对一个图的元素（如类和用例）进行分组的。把 分组后的元素用一个带有标签的文件夹图标包围起来，就 完成了对其打包。
•
业务逻辑层是用来处理系统的业务流程，它接受用 户界面请求的数据，并根据系统的业务规则返回最终的处 理结果。它将系统的业务规则抽象出来，按照一定的规则 形成在一个应用层上。
数据访问层是程序中和数据库进行交互的层。
•
包图和包
•
包是包图中最重要的概念，它包含了一组模型元素和图， 如图5-2所示。
•
组成包图的元素有：包、子系统、依赖关系
模型的组织结构
对系统模型的内部组织结构通常采用先分层再细分成包 的方式。 系统分层常用一种方式是将系统分为三层结构，即用户 界面层、业务逻辑层和数据访问层。
用户界面层
业务逻辑层
数据访问层
•
用户界面层代表与用户进行交互的界面，既可以是 Form窗口，也可以是Web的界面形式。一个应用可能有 很多不同的界面表示形式，通过对界面中数据的采集和处 理，以及响应用户的请求与业务逻辑层进行交换。
（4）避免包间的循环依赖：包A依赖于包B，包B依赖于包C， 而包C依赖于包A，这就形成一个循环：A——B——C— —A。循环依赖是一个很好的信号，意味着需要重构一个 或多个包，把导致循环依赖的因素从包中除掉。 （5） 包依赖应该反映内部关系：当一个包依赖于另一个包 时，意味着这两个包的内容间存在着一个或多个的关系。 例如，如果是一个用例包图，那么就有可能两个用例之间 存在include 、extend、 inheritance关系，而两个用例分 别处于不同的包中。
•
包的可见性
包的可见性用来控制包外元素对包内元素的访问权限。 包的可见性： （1） - 被private关键字定义的私有元素对包外部元 素完全不可见。意味着包中的元素只能被拥有或引用该元 素的包存取和使用。 （2）# 被protected关键字定义的被保护的元素只对那 些与包含这些元素的包有泛化关系的包可见。 （3）+ 被 public定义的公共元素对所有引入的包以及 它们的后代都可见。即允许其他元素存取和使用包中内容。
5.2 包的组成
•
在UML中，包的标准形式是使用两个矩形来表示的， 即一个小矩形（标签）和一个大矩形，小矩形紧紧连结 在大矩形的左上角上，包的名称位于大矩形的中间，如 图所示。
UtilityPackage
5.2 包的组成
• 和其他模型元素的名称一样，每个包都必须有一个 与其他包相区别的名称。包的名称是一个字符串，它有两 种形式：简单名（Simple Name）和路径名（Path Name）。 如：包名domain就是一个简单名 路径名com::bookshop::domain
订单获 取应用 问题域 订单
AWT
邮件发 送界面
邮件发 送应用
顾客
实例：建立“医院病房监护系统”的包图
将系统中具有依赖关系的模型元素放在一起构成包， 通过分组机制建立包图。包图按照层次结构组织，分为用 户层、应用层和数据库层。
• 通过前面的分析，得到下面的类： 值班护士、医生、病人、病症监视、标准病症信号 标准病症信号库、 病历库、病历、中央监护系统 病情报告、报警信号、病人病症信号
对“医院病房监护系统”进行分析，确定系统的主要功 能如下： 1. 病症监视器可以将采集到的病症信号（组合），格式 化后实时的传送到中央监护系统。 2. 中央监护系统将病人的病症信号分解后与标准的病症 信号库里的病症信号的正常值进行比较，当病症出现异常时 系统自动报警。 3. 当病症信号异常时，系统自动更新病历并打印病情报 告。 4. 值班护士可以查看病情报告并进行打印。 5. 医生可以查看病情报告，要求打印病情报告，也可以 查看或要求打印病历。 6. 系统定期自动更新病历。
一个包只能看到其他包中被指定为具有公共可见性 的元素。具有受保护可见性的元素只对包含它的包的后代 包具有可见性。 • 一个类的后代可以看到它的祖先中具有公共或受保 护可见性的成员，而其他类则只能看到具有公共可见性的 成员。 •
5.2.3 构造型
在UML中所有的扩展机制都适用于包，可以用标记值 描述包的新特性，用构造性描述包的新种类。包具有不同 的构造型，表现为不同的特殊类型的包。
包图举例
财务子系统
数据库子系统
数据库操作
数据库接口
Oracle 接口
Sybase接口
包图举例
包图举例
订单获 取界面 AWT 邮件发 送界面 用户接口包
订单获 取应用
邮件发 送应用
应用层包
订单
其中:AWT是Java中管理GUI类的包。
顾客
问题域包
包图另一种划分方式
用户接口
订单获 取界面 系 统应用