第11章 系统结构与包模型模型

OO 分析模型到 OO 设计模型的映射

包图 概述 包 包之间的关系 包图建模技术

概述 包图是维护和控制系统总体结构的重要建模工具 包图方便理解和处理整个模型

包 包是将多个元素组织为语义相关组的通用机制 包的内容 拥有或引用的模型元素 作为模型组织结构的一种分组机制，包的实例没有任何语义。因此，包仅在建模时有意义，而不必转换到可执行的系统中

包模型 包(package)是一种分组机制，也可以认为是一种集合元素或者容器元素，其中可以包含不同类型的产品。 类似于文件管理中的文件夹

包 包的名称 每个包必须有一个与其他包相区别的名称 两种形式：简单名和路径名

包 包拥有的元素 包拥有的元素：类、接口、组件、节点、协作、用例、图以及其他包 一个模型元素不能被一个以上的包所拥有 如果包被撤销，其中的元素也要被撤销 一个包形成了一个命名空间

包 包内元素的可见性 公有的（public） “＋” 受保护的（protected） “＃” 私有的（private）“－”

包的类型 虚包(facade) 一个包只是其他包的视图。 定义虚包，仅仅是引入而不是拥有 框架(framework ) 描述一个主要由模式组成的包 桩(stub) 作为另一个包的公共内容代理的包 子系统(subsystem) 整个系统独立部分的包 系统(system) 整个系统的包

Façade 子系统中的一组接口提供一个一致的界面，facade 定义了一个高层接口，这个接口使得这一子系统更加容易使用。 应用场合： 当需要构建一个层次结构的子系统时，使用Facade 定义子系统中每层的入口点。如果子系统之间是相互依赖的，可以让它们仅通过Facade 进行通讯，从而简化了它们之间的依赖关系。

Façade 为子系统中的一组接口提供一个一致的界面 。

Façade 为子系统中的一组接口提供一个一致的界面 。

框架 MVC模式 View层 Control层 Model层

逻辑框架 UI ActiveX组件 Microsofte基类 应用窗口 业务对象 控制业务对象 《Facade》服务接口 外部业务对象 实体业务对象 数据库 SQL产生器 《Facade》 对象到关系转换包 设计的逻辑架构

包之间的关系(依赖) 引入（import） 输出（export） 引入和访问依赖不是可传递的 允许一个包中的元素可以单向访问另一包中的元素 包的公共部分 引入和访问依赖不是可传递的

包、元素、接口之间关系 1、包与包： 依赖关系 2、元素与包： 依赖关系 3．包与接口： 实现关系

包图建模技术 对成组的元素建模 浏览特定体系结构视图中的建模元素，找出由在概念和语义上相互接近的元素所定义的组块，把每一个这样的组块放到一个包中 对每一个包找出可以在包外访问的元素，将这些元素标记为公有的，把其他的元素标记为受保护的或私有的。如果不确定时，就隐藏该元素 确定包与包之间的依赖关系，特别是引入依赖

系统的包图

包图建模技术 对体系结构视图建模 找出问题语境中一组有意义的体系结构视图 找出对于可视化、详述、构造和文档化每个视图的语义来说充分必要的元素（和图），并将它们放到合适的包中 如有必要，将这些元素进一步地组合到它们自己的包中 不同视图中的元素之间通常存在依赖关系

包模型表示系统体系结构

系统的包图 体系结构包图

软件体系结构的层次模型

软件体系结构的层次模型

软件体系结构的层次模型

软件体系结构的层次模型

软件体系结构的层次模型

软件体系结构的层次模型

以服务对象分层 以服务对象分层把持久对象作为界面对象的服务类。 这个结构有两层：界面层和持久层。在构造对象时，系统先构造或提取持久对象，然后在构造界面层的对象。 具体又分为全显露法和单显露法。

全显露法

单显露法

三层系统 用户界面层、商业逻辑层以及数据管理层

多层系统 n级系统中，有n-1对客户机/服务器。 在上述三级系统中增加一个网络服务器（Web server）和轻便客户机，就得到四级系统。

应用程序的分层体系结构 软件层的特征 1.每个层由一组相关的类或组件构成，共同完 成特定功能。 2. 层与层之间存在自上而下的依赖关系。不存在 跨层访问。 3.每个层对上层公开API，但具体的实现细节 不对外透明。

应用程序的分层体系结构 软件分层的优点 1.伸缩性:能否支持更多用户。 2.可维护性:需求变化时，影响一部分，不影 响其它部分的代码。 3.可扩展性:增加薪功能的难以程度。 4.可重用性:代码没冗余，满足多种需求。 5.可管理性:管理系统的难易程度。

应用程序的分层体系结构 软件分层缺点 1.设计人员要求高 2.体细结构合理划分，耗时大 3.调试困难 4.对于规模较小的应用，软件分层会降低开发 效率。

应用程序的分层体系结构 Java应用的持久化层 表述层 表述层 业务逻辑层 业务逻辑层 持久化层 数据库层 数据库层

包设计原则 包保持高内聚、低耦合的特点

包设计原则 1、重用等价原则 包的粒度接近包的重用程度。 核心：接口和实现类分离。

包设计原则 2、共同闭包原则 需要修改的类放在一个包内。即两个类耦合强时，放在一个包中，提高包的内聚性。 划分包的原则：概念或语义的相似性。

包设计原则 3、共同重用原则 包中的所有类应该是共同重用的。

包设计原则 4、非循环依赖原则 包之间不形成循环依赖关系

包设计原则 5、稳定依赖原则SDP 包的设计应该朝着稳定的方向进行依赖，即不稳定的包总是依赖稳定的包。应该把封装系统高层设计的软件模块（比如抽象类）放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件（比如具体类）。 例如：业务规则和业务对象相比较界面来说，是稳定的，因此界面依赖于业务规则和业务实体包。

包设计原则 6、稳定抽象原则 包的抽象程度应该和其稳定程度一致。抽象的元素相对于具体的元素更为稳定。 从本质上来说，系统开发中的所有元素包括模型元素和程序元素都是对现实世界的抽象，只不过抽象的程度的是不一样的，抽象的层次越高，则其适用面越广，稳定性也就越强。