OOSE10模型管理视图剖析.ppt

--模型管理视图 面向对象分析设计与UML 董瑞志 Email: hello_u@ MSN: nature_dong@ 联系电话引言 包是将多个元素组织为语义相关组的通用机制。一个包拥有或引用的模型元素称为该包的内容。 作为模型元素分组的一种机制，包的实例没有任何语义。 在图形上，包表示为带有标签的文件夹。 名称 每个包都必须有一个与其他包相区别的名称。 包的名称是一个字符串，它可以是简单名或路径名。通常在图形上仅仅显示简单名。 拥有元素(1/4) 包可以拥有其它元素，这些元素可以是类、接口、构件、节点、协作、用例等元素。 包和其中拥有的元素之间是组合关系，即如果包被撤销，包内拥有的元素都将被撤销。 还需指出，一个元素只能被一个包拥有。 拥有元素(2/4) 一个包形成一个命名空间—在一个包的语境中同一种元素的名称必须唯一。 包可以拥有其他包，允许按层次分解包的内容。 拥有元素(3/4) 拥有关系的语义，使得包成为一种按照规模处理问题的机制。如果没有包，我们将得到一个平坦、庞大且难以管理的系统；当引入的包机制之后，将有助于控制那些系统的组成元素，合理控制系统的演化。 拥有元素(4/4) UML允许显示表述包的内容，这时候通过包名作为标签处理，但是通常我们无需表述包的内容。 可见性 UML允许包内所有元素的可见性。包可见性有3种：public , protected, private。 通常包拥有的元素是公共的，它对引入其外围包的任何包的内容都是可见的。 受保护的元素仅仅对当前包及其子包的元素可见； 私有可见性仅仅对包内元素可见。 引入和示出 要使得简单、无约束的访问不至于按比例的增长，需要采用某种受控的包装来组织抽象：引入和示出 引入 引入授权一个包中的元素可以访问另一个包中的元素的单项许诺。在UML中使用一个由构造型import修饰的依赖为引入关系建模，通过把抽象包装成组块，然后用引入关系控制对它们的访问，就能够控制大量抽象的复杂性。 示出 包的公共部分称为示出。一个包示出的部分仅仅对显式引入这个包的那些包中的内容可见。 泛化 泛化关系用来说明包的家族树。 包间的泛化和类间的泛化关系采用相同的表示，功能类似。 涉及泛化的包遵循替代原理，特殊包可以应用到一般的包被使用的任何地方。 扩展机制(1/2) UML所有扩展机制都适用于包。经常使用标记值增加包的特性，采用构造型详述包的新类型。 UML定义了5种应用于包的标准构造型： 虚包fa?ade，描述一个包只是其他包的视图； 框架framework,描述一个主要由模式组成的包； 桩Stub,描述一个作为另一个包的公共内容代理的包； 子系统，描述一个表示被建模的整个系统的一个独立部分的包； 系统，描述一个表示被建模的整个系统的包。 扩展机制(2/2) 其中： fa?ade机制用来提供一些复杂包的简略视图； 当有一个工具可以把系统分解为在不同时间点和潜在的不同地点可以处理的包时，使用Facade，例如如果你有一个开发组在两处地点工作，其中一处的开发组可以为另一处的开发组提供所需的包提供代理—这种策略用代理包捕获必需认真管理的系统中的接缝，可以让各处的开发组独立工作，互不干扰。 应用 建模成组元素 建模软件体系结构视图 建模成组元素 使用包最常见的目的是把建模元素组织成为能作为一个集合进行命名和处理的组。 在多数情况下，使用包组合基本种类相同的元素，也可以用来组织不同种类的元素。 建模成组元素的准则 浏览特定体系结构中的建模元素，找出由在概念和语义上相近的元素所定义的组块。 把每一个这样的组块构建到一个包中； 对每一个包，区别包内元素的可见性。如果拿不准时候，即把其可见性设置为private; 使用引入、示出、泛化、依赖表示包与包之间的关系； 建模软件体系结构视图(1/3) 包是组合相关元素的重要机制，特别是当考虑软件体系结构的不同视图的时候。 视图是对系统的组织、结构的投影，它注重于系统的特定方面： 可以把系统分解成为几乎互不相关的包，每个包表达了一组体系结构的决策； 这些包都拥有与视图密切相关的抽象。 建模软件体系结构视图(2/3) 建模软件体系结构视图(3/3) 建模软件体系结构的准则 识别出问题语境中一组有意义的体系结构视图，在实际应用中，通常要包括设计视图、实现视图、部署视图、用例视图等 把对于可视化、详述、构造和文档化每个视图的语义充分而必要的元素放到合适的包中； 如果必要，进一步把这些元素组合到包中。 通常在不同的视图中的元素间具有依赖关系，因此一般要让系统顶层的各个视图对同层的其他视图开放。 提示 良好定义的包，应具有如下特征： 高内聚，给出围绕一组相关元素的明确边界； 松耦合，仅仅示出其他包确实需要看到的那些元素； 嵌套