第 13 章逻辑架构和 UML 包图

第13章逻辑架构和UML包图 暨南大学计算机系黄战

目标 • 介绍使用层的逻辑架构 • 阐述使用UML包图的逻辑架构

简介 • 现在，我们就从面向分析的工作过渡到软件设计 • 典型OO系统设计的基础是若干架构层，例如UI层、应用逻辑（或“领域”）层等。

UP制品相互影响 • 业务建模 • 领域模型 • 需求 • 用例模型 • 设想 • 补充性规格说明 • 词汇表 • 设计 • 逻辑架构的包图(静态视图） • 交互图(动态视图） • 类图（静态视图)

UP制品相互影响 • 强调的是逻辑架构（LA) • 主要的输入是补充性规格说明中记录的架构方面的约束和要点 • LA定义了包，包中有关于软件类的定义

示例 • 图13.2所示为使用UML包图表示法绘制的部分分层逻辑架构

逻辑架构 • 逻辑架构是软件类的宏观组织结构，它将软件类组织为包(或命名空间）、子系统和层等。 • 之所以称其为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署的一部分）

层 • 层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。 • 层按照“较高”层（例如UI层）可以调用“较低”层的服务 • OO系统中通常包括的层有： • 用户逻辑 • 应用逻辑和领域对象 • 技术服务（例如数据库接口或错误日志）

架构分层 • 在严格的分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。在信息系统中通常使用宽松的分层架构，其中较高层可以调用其下任何层的服务 • 例如，UI层可以调用与其相邻的应用逻辑层，也可以调用更下面的技术服务层中的元素，完成日志记录等工作 • 逻辑架构并非一定要组织为层。但这种方式极为常用

案例研究中应该关注的层 • 尽管OO技术可以用于所有级别，但本书对OOA/D的介绍着重于核心应用逻辑（或“领域”）层，其次才是对其他层的讨论

软件架构 • 软件架构（宏观） • 架构是一种重要决策，其中涉及软件系统的组织 • 对结构元素及其组成系统所籍接口的选择 • 这些元素特定于其相互协作的行为 • 这些结构和行为元素到规模更大的子系统的组成 • 以及指导该组织结构的架构风格－ • 这些元素及其接口、协作、和组成

UML包图 • UML包图通常用于描述系统的逻辑架构 • 层 • 子系统 • 包（就Java）而言等 • 层可以建模为UML包。例如，UI层可以建模为名为UI的包

UML包图 • UML包图提供了组织元素的方式（类，其他包，用例，…） • 嵌套包十分常见 • UML包是比Java包和.NET命名空间更为通用的概念 • 如果包内部显示了其成员，则在标签上标识包名；否则，可以在包体内标识包名称 • 人们通常希望显示包之间的依赖性(耦合），以便开发者能够看到系统内大型事物之间的耦合。 • UML的依赖线即可用于此目的，依赖线是有箭头的虚线，箭头指向被依赖的包 • 完全限定的名称例如Java::util::Date

准则：使用层进行设计 • 使用层时： • 将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。这样，“较低”的层是低级别和一般性服务，较高的层则是与应用相关的。 • 协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合

设计问题 • 使用层有助于解决如下问题： • 源码的变更波及整个系统－大部分系统是高度耦合的。 • 应用逻辑与用户界面交织在一起，因此无法复用于其他不同界面或分布到其他处理节点之上 • 潜在的一般性技术服务或业务逻辑与更特定于应用的逻辑交织在一起，因此无法被复用、分布到其他节点或方便地使用不同实现替换 • 不同的关注领域之间的高度耦合。因此难以为不同开发者清晰地界定和分配任务

典型的层

使用层的好处 • 关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性、增加内聚性、提高潜在的复用性并且使概念更加清晰 • 封装和分解了相关的复杂性 • 某些层能够使用新的实现替换。

内聚 • 同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责则不应该混淆 • 例如，UI层中的对象应该关注于UI工作，例如创建窗口和小部件、捕获鼠标和键盘事件等。应用逻辑或“领域”层中的对象应该关注应用逻辑，例如计算销售总额或税金，或在棋盘上移动棋子－UI对象不应该处理应用逻辑！ • 否则将违反关系分离和高内聚原则（这是基本架构原则）

层、层和分区 • 层－在架构中最初表示的是逻辑层，而不是物理节点，但是现在，这个词被广泛用于表示物理进程节点（或节点簇），例如“客户层”（客户计算机） • 架构中的层表示对系统的垂直方向的划分。 • 分区－表示对层在水平方向进行划分，形成相对平行的子系统。例如，技术服务层可以划分为安全和统计等分区。

模型－视图分离原则 • 其他包应该对UI层具有何种可见性？ • 非窗口类应该如何与窗口通信？

模型－视图分离原则 • 原则： • 不要将非UI对象直接与UI对象连接或耦合。 • 不要在UI对象方法中加入应用逻辑 • 模型←→领域层对象 • 视图←→UI对象

模型－视图分离原则 • 模型－视图分离原则规定，模型（领域）对象不应该直接与视图（UI）对象连接，对于视图对象也是如此。

模型－视图分离原则 • 动机： • 支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。 • 允许对模型和用户界面层分别进行开发。 • 使界面的需求变更对领域层的影响最小化。 • 允许新视图能够被方便地连接到现有的领域层之上，而不会对领域层产生影响。 • 允许对同一模型对象同时使用多个视图，例如销售信息同时具有表格和业务图表视图。 • 允许模型层的运行不依赖于用户界面层，例如，消息处理或批处理模式的系统。 • 允许模型层能够简便地移植到另一个用户接口框架下。

SSD、系统操作、层 • SSD描述了系统操作，但使隐藏特定的UI对象 • 系统UI层对象捕获系统操作请求 • Fig.13.8

第 13 章 逻辑架构和 UML 包图