第第 1313 章 逻辑架构和章 逻辑架构和 UMLUML 包包图图

暨南大学计算机系暨南大学计算机系黄战黄战

目标目标

介绍使用层的逻辑架构介绍使用层的逻辑架构 阐述使用阐述使用 UMLUML 包图的逻辑架构包图的逻辑架构

简介简介

现在，我们就从面向分析的工作过渡到现在，我们就从面向分析的工作过渡到软件设计软件设计

典型典型 OOOO 系统设计的基础是若干架构层，系统设计的基础是若干架构层，例如例如 UIUI 层、应用逻辑（或“领域”）层、应用逻辑（或“领域”）层等。层等。

UPUP 制品相互影响制品相互影响 业务建模业务建模

– 领域模型领域模型 需求需求

– 用例模型用例模型– 设想设想– 补充性规格说明补充性规格说明– 词汇表词汇表

设计设计– 逻辑架构的包图逻辑架构的包图 (( 静态视图）静态视图）– 交互图交互图 (( 动态视图）动态视图）– 类图（静态视图类图（静态视图 ))

UPUP 制品相互影响制品相互影响

强调的是逻辑架构（强调的是逻辑架构（ LA)LA) 主要的输入是补充性规格说明中记录的主要的输入是补充性规格说明中记录的

架构方面的约束和要点架构方面的约束和要点 LALA 定义了包，包中有关于软件类的定定义了包，包中有关于软件类的定

义义

示例示例

图图 13.213.2 所示为使用所示为使用 UMLUML 包图表示法绘包图表示法绘制的部分分层逻辑架构制的部分分层逻辑架构

逻辑架构逻辑架构

逻辑架构是软件类的宏观组织结构，它逻辑架构是软件类的宏观组织结构，它将软件类组织为包将软件类组织为包 (( 或命名空间）、子或命名空间）、子系统和层等。系统和层等。

之所以称其为逻辑架构，是因为并未决之所以称其为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署物理的计算机上对这些元素进行部署（后一种决定是部署的一部分）（后一种决定是部署的一部分）

层层

层是对类、包或子系统的甚为粗粒度的层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的分组，具有对系统主要方面加以内聚的职责。职责。

层按照“较高”层（例如层按照“较高”层（例如 UIUI 层）可以调层）可以调用“较低”层的服务用“较低”层的服务

OOOO 系统中通常包括的层有：系统中通常包括的层有：– 用户逻辑用户逻辑– 应用逻辑和领域对象应用逻辑和领域对象– 技术服务（例如数据库接口或错误日志）技术服务（例如数据库接口或错误日志）

架构分层架构分层

在严格的分层架构中，层只能调用与其相邻在严格的分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。在信息较常见，而在信息系统中不太常见。在信息系统中通常使用宽松的分层架构，其中较高系统中通常使用宽松的分层架构，其中较高层可以调用其下任何层的服务层可以调用其下任何层的服务

例如，例如， UIUI 层可以调用与其相邻的应用逻辑层，层可以调用与其相邻的应用逻辑层，也可以调用更下面的技术服务层中的元素，也可以调用更下面的技术服务层中的元素，完成日志记录等工作完成日志记录等工作

逻辑架构并非一定要组织为层。但这种方式逻辑架构并非一定要组织为层。但这种方式极为常用极为常用

案例研究中应该关注的层案例研究中应该关注的层

尽管尽管 OOOO 技术可以用于所有级别，但本技术可以用于所有级别，但本书对书对 OOA/DOOA/D 的介绍着重于核心应用逻的介绍着重于核心应用逻辑（或“领域”）层，其次才是对其他辑（或“领域”）层，其次才是对其他层的讨论层的讨论

软件架构软件架构

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

UMLUML 包图包图

UMLUML 包图通常用于描述系统的逻辑架包图通常用于描述系统的逻辑架构构– 层层– 子系统子系统– 包（就包（就 JavaJava）而言等）而言等

层可以建模为层可以建模为 UMLUML 包。例如，包。例如， UIUI 层可层可以建模为名为以建模为名为 UIUI 的包的包

UMLUML 包图包图 UMLUML 包图提供了组织元素的方式（类，其他包，用例，包图提供了组织元素的方式（类，其他包，用例，…）…）

嵌套包十分常见嵌套包十分常见 UMLUML 包是比包是比 JavaJava包和包和 .NET.NET命名空间更为通用的概念命名空间更为通用的概念 如果包内部显示了其成员，则在标签上标识包名；否如果包内部显示了其成员，则在标签上标识包名；否则，可以在包体内标识包名称则，可以在包体内标识包名称

人们通常希望显示包之间的依赖性人们通常希望显示包之间的依赖性 ((耦合），以便开耦合），以便开发者能够看到系统内大型事物之间的耦合。发者能够看到系统内大型事物之间的耦合。

UMLUML 的依赖线即可用于此目的，依赖线是有箭头的虚的依赖线即可用于此目的，依赖线是有箭头的虚线，箭头指向被依赖的包线，箭头指向被依赖的包

完全限定的名称 例如完全限定的名称 例如 Java::util::DateJava::util::Date

准则：使用层进行设计准则：使用层进行设计

使用层时：使用层时：– 将系统的大型逻辑结构组织为独立的、职将系统的大型逻辑结构组织为独立的、职

责相关的离散层，具有清晰、内聚的关注责相关的离散层，具有清晰、内聚的关注分离。这样，“较低”的层是低级别和一分离。这样，“较低”的层是低级别和一般性服务，较高的层则是与应用相关的。般性服务，较高的层则是与应用相关的。

– 协作和耦合是从较高层到较低层进行的，协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合要避免从较低层到较高层的耦合

设计问题设计问题

使用层有助于解决如下问题：使用层有助于解决如下问题：– 源码的变更波及整个系统－大部分系统是高度耦源码的变更波及整个系统－大部分系统是高度耦合的。合的。

– 应用逻辑与用户界面交织在一起，因此无法复用应用逻辑与用户界面交织在一起，因此无法复用于其他不同界面或分布到其他处理节点之上于其他不同界面或分布到其他处理节点之上

– 潜在的一般性技术服务或业务逻辑与更特定于应潜在的一般性技术服务或业务逻辑与更特定于应用的逻辑交织在一起，因此无法被复用、分布到用的逻辑交织在一起，因此无法被复用、分布到其他节点或方便地使用不同实现替换其他节点或方便地使用不同实现替换

– 不同的关注领域之间的高度耦合。因此难以为不不同的关注领域之间的高度耦合。因此难以为不同开发者清晰地界定和分配任务同开发者清晰地界定和分配任务

典型的层典型的层

使用层的好处使用层的好处

关系分离、高级服务与低级服务分离、关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性、增加内聚性、层可以减少耦合和依赖性、增加内聚性、提高潜在的复用性并且使概念更加清晰提高潜在的复用性并且使概念更加清晰

封装和分解了相关的复杂性封装和分解了相关的复杂性 某些层能够使用新的实现替换。某些层能够使用新的实现替换。

内聚内聚

同一层内的对象在职责上应该具有紧密关联，同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责则不应该混淆不同层中对象的职责则不应该混淆

例如，例如， UIUI 层中的对象应该关注于层中的对象应该关注于 UIUI 工作，例工作，例如创建窗口和小部件、捕获鼠标和键盘事件等。如创建窗口和小部件、捕获鼠标和键盘事件等。应用逻辑或“领域”层中的对象应该关注应用应用逻辑或“领域”层中的对象应该关注应用逻辑，例如计算销售总额或税金，或在棋盘上逻辑，例如计算销售总额或税金，或在棋盘上移动棋子－移动棋子－ UIUI 对象不应该处理应用逻辑！对象不应该处理应用逻辑！

否则将违反关系分离和高内聚原则（这是基本否则将违反关系分离和高内聚原则（这是基本架构原则）架构原则）

层、层和分区层、层和分区

层－在架构中最初表示的是逻辑层，而层－在架构中最初表示的是逻辑层，而不是物理节点，但是现在，这个词被广不是物理节点，但是现在，这个词被广泛用于表示物理进程节点（或节点簇），泛用于表示物理进程节点（或节点簇），例如“客户层”（客户计算机）例如“客户层”（客户计算机）

架构中的层表示对系统的垂直方向的划架构中的层表示对系统的垂直方向的划分。分。

分区－表示对层在水平方向进行划分，分区－表示对层在水平方向进行划分，形成相对平行的子系统。例如，技术服形成相对平行的子系统。例如，技术服务层可以划分为安全和统计等分区。务层可以划分为安全和统计等分区。

模型－视图分离原则模型－视图分离原则

其他包应该对其他包应该对 UIUI 层具有何种可见性？层具有何种可见性？ 非窗口类应该如何与窗口通信？非窗口类应该如何与窗口通信？

模型－视图分离原则模型－视图分离原则

原则：原则：– 不要将非不要将非 UIUI 对象直接与对象直接与 UIUI 对象连接或耦对象连接或耦合。合。

– 不要在不要在 UIUI 对象方法中加入应用逻辑对象方法中加入应用逻辑 模型←→领域层对象模型←→领域层对象 视图←→视图←→ UIUI 对象对象

模型－视图分离原则模型－视图分离原则

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

模型－视图分离原则模型－视图分离原则 动机：动机：

– 支持内聚的模型定义，这些定义只关注领域过程，而不是用支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。户界面。

– 允许对模型和用户界面层分别进行开发。允许对模型和用户界面层分别进行开发。– 使界面的需求变更对领域层的影响最小化。使界面的需求变更对领域层的影响最小化。– 允许新视图能够被方便地连接到现有的领域层之上，而不会允许新视图能够被方便地连接到现有的领域层之上，而不会

对领域层产生影响。对领域层产生影响。– 允许对同一模型对象同时使用多个视图，例如销售信息同时允许对同一模型对象同时使用多个视图，例如销售信息同时

具有表格和业务图表视图。具有表格和业务图表视图。– 允许模型层的运行不依赖于用户界面层，例如，消息处理或允许模型层的运行不依赖于用户界面层，例如，消息处理或批处理模式的系统。批处理模式的系统。

– 允许模型层能够简便地移植到另一个用户接口框架下。允许模型层能够简便地移植到另一个用户接口框架下。

SSDSSD 、系统操作、层、系统操作、层

SSDSSD描述了系统操作，但使隐藏特定的描述了系统操作，但使隐藏特定的UIUI 对象对象

系统系统 UIUI 层对象捕获系统操作请求层对象捕获系统操作请求 Fig.13.8Fig.13.8