UML统一建模实用教程-包图

UI
System:Web:UI
简单名
含路径名(全名)
包的表示
• 包的元素 – 在一个包中可以拥有各种其他元素，包括类、接口、 构件、节点、协作、用例，甚至是其他包或图。这是 一种组成关系，意味着元素是在这个包中声明的，因 此一个元素只能属于一个包。 – 每一个包就意味着一个独立的命名空间，因此，两个 不同的包，可以具有相同的元素名，但由于所位于的 包名不同，因此其全名仍然是不同的。 – 在包中表拥有的元素时，有两种方法：一种是在第二 栏中列出所属元素名，一种是在第二栏中画出所属元 素的图形表示。
包图中的关系
• 包图中的关系有2种：依赖关系、泛化关系。 • 1、依赖关系 – 依赖关系可以分为4种。在依赖关系中 ，我们把箭尾端的包称为客户包,把 箭头端的包称为提供者包。 • （1） 《use》关系 • 《use》关系是一种默认的依赖 关系 ，说明客户包（箭尾端的包） 中的元素以某种方式使用提供者 包（箭头端的包）的公共元素， 也就是说客户包依赖于提供者包。 如果没有指明依赖类型，则默认 为《USE》关系。 • 例如 ，有两个《USE》依赖， Client包将通过Server包来完成 Order的存储，而Server包使用 System.Data.SqlClient包来实现数 据库的存储。
LOGO 统一建模》 《UML 统一建模》
第5章 包图 章
为什么要包
• 在面向对象软件开发的视角中，类显然是构建整个系统的 在面向对象软件开发的视角中，
基本构造块。但是对于庞大的应用系统而言， 基本构造块。但是对于庞大的应用系统而言，其包含的类 将是成百上千，再加上其间复杂的关联关系、多重性等， 将是成百上千，再加上其间复杂的关联关系、多重性等， 必然是大大超出了人们可以处理的复杂度。 必然是大大超出了人们可以处理的复杂度。这也就是引入 这种分组事物构造块。 了“包”这种分组事物构造块。 1）对语义上相关的元素进行分组 定义模型中的“语义边界” 2）定义模型中的“语义边界” 3）提供配置管理单元 在设计时， 4）在设计时，提供并行工作的单元 5）提供封装的命名空间，其中所有名称必须惟一 提供封装的命名空间，
• 2、泛化关系 • 包间的泛化关系类似于类间的泛化关系，使用一般包的地方，可以用 特殊包代替。 • 在系统设计中，对某一个特定的功能，有多种实现方法。例如，实现 多数据库支持；实现B/S和C/S双界面。这时就需要定义一些高层次的 “抽象包”和实现高层次功能的“实现包”。 • 在抽象包中定义一些接口和抽象类，在实现包中，定义一些包含实现 这些抽象类和接口的具体类。 • 例如，说明GUI有两种风格：一种是基于WinForm的C/S风格，一种是 WebForm的B/S风格。
包的表示
• 包的可见性 – 像类中的属性和方法一样，包中的元素也有可见性，包内元素的 可见性控制了包外部元素访问包内部元素的权限。 – 包的可见性有3种： • “+”表示“public” • “#”表示“protected” • “-”表示“private”
包的表示
• • 包内元素的可见性，标识了外部元素访问包内元素的权限。 下表列出了可见性与访问权限的关系。 可见性与访问权限(假设包B中的元素访问包A中的元素) 包A中元素的可见性 中元素的可见性 + # 包B中元素的访问权限 中元素的访问权限 若B引用了A,则B中的任何元素可以访问A中可见性是+的元素 若B继承了A,则B中的任何元素可以访问A中可见性是#的元素 可见性是-的元素，只能被同一个包中的其它元素访问
包图建模
• 2 对体系结构建模 • 体பைடு நூலகம்结构是一个软件系统的核心逻辑结构，常用的体系结构模式包 括分层、MVC、管道、黑板、微内核等，而在应用软件中，分层和 MVC是最常见的两种结构。 • 在分层的体系结构中，最常见的划分是表示层（present）、逻辑层 （business或domain）、数据层（包括数据访问、日记等）。如果采 用分层体系结构，我们就把每一层用一个包来表示，如图5-7所示。
2
• 包的作用是： 包的作用是：
包的概念
• 包是维护和控制系统总体结构的重要建模工具，有助于方 便理解和处理整个模型 • 分解 是软件开发中控制软件复杂性的重要手段 • 在OO方法中, 需要考虑如何把相关的类放在一起
3
包的概念
• 包是一种常规用途的组合机制。UML中的一个包直接对应 于Java中的一个包。 • 在Java中，一个包可能含有其他包、类或者同时含有这两 者。 • 进行建模时，通常使用逻辑性的包，用于对模型进行组织； 使用物理性的包，用于转换成系统中的Java包。
包图中的关系
• （3） 《access》关系 • 如果只想使用提供者包中的元素，而不想将两个包合并，则应使用该 关系。在客户包中必须使用路径名,才能访问提供者包中的所有公共元 素。 • （４）《trace》关系 • 想表示一个包到另一个包的历史发展，则需要使用《trace》关系来表 示
包图中的关系
包图中的关系
• （2） 《import》关系 • 《import》关系：最普遍的包依赖类型，说明提供者包的命名空间将 被添加到客户包的命名空间中，客户包中的元素也能够访问提供者包 的所有公共元素。 • 《import》关系使命名空间合并，当提供者包中的元素具有与客户包 中的元素相同的名称时，将会导致命名空间的冲突。这也意味着，当 客户包的元素引用提供者包的元素时，将无需使用全称，只需使用元 素名称即可。 • 例如，Client包引用了（import）了Rule包，Rule包又引用了GUI包。同 时，这还表示Client包间接引用了GUI包。
21
包图绘制举例
•
在建模时应该避免包之间的循环依赖，也就是不能够包 在建模时应该避免包之间的循环依赖， 含相互依赖的情况，对于这种情况应进行分析： 含相互依赖的情况，对于这种情况应进行分析：
22
包图建模
• 包图主要用于两种不同层次的用途：一是对成组元素建模；二是对体 系结构建模。 • 1 对成组元素建模 • 对成组元素进行建模可以说是包图最常见的用途，它将建模元素组织 成组，然后对组进行命名，在对成组元素建模时，应遵循以下几个策 略： • 每个包都应该是由在概念上，语义上相互接近的元素组成。 • 对于每个包，找出应标记为公共的元素，但应尽可能地少。 • 一般使用默认的《use》构造型，在实现类时，才用《import》构造型 代替《use》构造型。 • 采用泛化来对特殊包进行建模。
创建包图
• 绘制包图的基本过程主要有三个步骤：第一，寻找包；第二，确定包 之间的关系；第三，标出包内元素的可见性。 • 绘制包图的“最小化系统间的耦合关系”的原则： • 最大限度减少包之间的依赖，包封装时，避免包之间的循环依赖；最 小化每个包的public、protected元素的个数，最大化每个包中private 元素的个数。 • 1 寻找包 • 通过把具有很强语义联系的建模元素分组，找出分析包。分析包必须 反映元素的真实的语义分组，而不仅是逻辑架构的理想视图。 • 我们以对象模型和用例模型为依据，把关系紧密的类分到同一个包中， 把关系松散的类分到不同的包中。
创建包图
• 良好包结构的关键是包内高内聚，包间低耦合。 • 通常，当创建分析包模型时，应该尽量使包模型简单。获得正确的包 集合比使用诸如包泛化和依赖构造型的特征更加重要，这些特征可以 以后再添加，仅当使用诸如包泛化和依赖构造型的特征使得模型更加 容易理解时，才使用这些包整理技术。除了保持简单，还应该避免嵌 套包。物件在嵌套包结构中埋藏得越深，模型变得越晦涩。 • 作为经验法则，希望每个包具有4~10个分析类。然而，对于所有的经 验法则，却存在例外，如果打破某个法则使得模型更加清晰，就采用 这个法则！有时，你必须引入只带有一个或者两个类的包，因为你需 要断开包模型中的循环依赖。在这种情况下，这是完全合理的。
创建包图
• 1．标识候选包的原则： • (1)．把类图中关系紧密的类放到一个包中； • (2)．在类继承类层次中，把不同层次的类放在不同的包中。 • 也可以把用例模型作为包的来源。然而，用例横跨分析包是非常普遍 的——一个用例可以由几个不同包中的类实现。 • 2 2．调整候选包 • 在已经识别一组候选包后，然后减少包间依赖，最小化每个包的 public、protected元素的个数，最大化每个包中private元素的个数。 做法是： • (1).在包间移动类； • (2).添加包或删除包。
包的表示
• 包的构造型 • 为了表示包的新特性，用构造型来描述包的新特征。包的构造型有5 种，下面分别举例说明。 • １．《system》构造型：《system》构造型的包表示整个系统． • ２．《subsystem》构造型：subsystem》构造型的包则表示正在建模 的系统中某个独立的子系统． • ３．《facade》构造型：只是某个其它包的视图，它主要用来为其它 一些复杂的包提供简略视图 • ４．《stub》构造型：是一个代理包，它服务于某个其他包的公共内 容，这通常应用于分布式系统的建模中 ． • ５．《framework》构造型：用来表示一个框架的，框架是一个领域 内的应用系统提供可扩充模板的体系结构模式
包的表示
• UML中，用文件夹符号来表示一个包。包由一个矩形表示，它包含2 栏。下面是最常见的几种包的表示法
包名放在第二栏 包名放在第一栏
PageName PageName ClassName-1 ClassName-2 …..
PageName 类名
Rose常用表示法
第二栏列出 包含的类名
在第二栏画出所 包含的类图形表示
System:Web
UI class
嵌套包
包的表示
• 包的名称 – 每个包必须有一个与其他包相区别的名称。标识包名称的格式有 两种：简单名和全名。 – 其中，简单名仅包含包一个简单的名称；全名是用该包的外围包 的名字作为前缀，加上包本身的名字。 – 例如，Rose常用表示方法中，其包名UI就是一个简单名。而包 System.Web.UI才是一个完整带路径的名称，表示UI这个包是位于 System.Web命名空间中的。
20
设计包的原则
• 重用等价原则 重用等价原则(Reuse Equivalency Principle)
– 把类放入包中时 应考虑把包作为可重用的单元 把类放入包中时, 应考虑把包作为可重用的单元.
• 共同闭包原则(Common Closure Principle) 共同闭包原则
– 把需要同时改变的类放在同一个包中 把需要同时改变的类放在同一个包中.
阅读包图
• 例如，阅读下面的包图。
阅读包图
• 对上面包的理解如下： • （1）根据《use》关系可以发现Client包使用Server包，Server包使用 System.Data.SqlClient包，根据它们所包含的元素语义，可以得知Client 包负责Order(订单)的输入，并通过Server包来管理用户的登录 （LoggingService）和数据库存储（DataBase）；而Server包还通过.Net 的SQL SERVER 访问工具包，来实现与数据库的连接和通讯。 • （2）看《import》关系，从RULE包所包含的元素语义可知，该包负 责处理一些规则，并引用一个具体的窗体(Window)；而Client包通过 引用RULE来实现整个窗体和表单的显示，输入等，并且还将暂存 Order（订单）信息。 • （3）接着来看包的泛化关系。GUI有两个具体实现：一个是针对C/S 的WindowsGUI，一个是实现B/S的WebGUI.
包图建模
– 将一个框架的所有类放置在相同的包中 – 将相同继承层次的类放在相同的包中 – 彼此间有聚集或组成关系的类通常放在相同的包 中 – 彼此合作频繁的类、信息能够通过UML顺序图和 彼此合作频繁的类、信息能够通过 顺序图和 UML协作图反映出来的类，通常放在相同的包中 协作图反映出来的类， 协作图反映出来的类 – 确定包与包之间的依赖关系或泛化关系
• 共同重用原则 共同重用原则(Common Reuse Principle)
– 不会一起使用的类不要放在同一个包中. 不会一起使用的类不要放在同一个包中
• 非循环依赖原则 非循环依赖原则(Acyclic Dependencies Principl)
– 包之间的依赖关系不要形成循环 包之间的依赖关系不要形成循环.