UML和模式应用5：细化阶段（8)---逻辑架构和UML包图

1.前言

• 本章是从面向分析的工作过度到软件设计
• 典型的OO系统设计的基础是若干架构层，如UI层、应用逻辑（领域）层
• 本章简要考察逻辑分层架构和相关UML表示法

2.逻辑架构和层

• 逻辑架构

逻辑架构是软件类的宏观组织结构，它将软件类组织成包（命名空间）、子系统和层，并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署

• 层

对类、包或子系统的粗粒度的分组，具有对系统主要方面加以内聚的职责。较高层可以调用较低层的服务，OO系统通常包括的层：

用户界面

应用逻辑和领域对象，表示领域概念的软件对象

技术服务，提供支持性技术服务的常用对象和子系统，例如数据库接口或错误日志，这些服务通常独立于应用，可以在多个层复用

注：1. 在严格的分层架构中（如网络协议栈），层只能调用与其相邻的下层的服务；

在宽松的分层架构中（如信息系统），较高层可以调用其下任何层的服务。

2. 逻辑架构并非一定要组织成层，但这种方式极为常见

3.软件架构

• 软件架构是一组重要决策，涉及软件系统的组织，对结构元素及组成系统所使用接口的选择，结构和行为元素到规模更大子系统的组成，以及指导该组织结构的架构风格
• 软件架构的共同主题：必须与宏观事物有关-----动机、约束、组织、模式、职责和系统之连接的重要思想

4.UML包图

• UML包图常用于描述系统的逻辑架构-----层、子系统、包（就java语言）
• 层可以建模为UML包
• UML包图提供了组织元素的方式，可以组织任何事物：类、其他包、用例
• UML的依赖线可显示包之间的依赖性（耦合），以便开发者能够看到系统内大型事物之间的耦合，依赖线使用带箭头的虚线，箭头指向被依赖的包
• UML包代表命名空间，两个不同的包内可以有名称相同的类名
• UML包内可以嵌套其它UML包，如java::util::Date

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

图 信息系统逻辑架构中常见的层

• 使用层的本质思想

将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。较低的层是低级别和一般性服务，较高的层是与应用相关的

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

• 使用层有助于解决的问题

源码的变更波及整个系统---大部分系统是高度耦合的

应用逻辑与用户界面交织在一起，因此应用逻辑无法复用

潜在的一般性技术服务或业务逻辑与更特定于应用的逻辑交织在一起，无法复用

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

• 不同应用领域，层的数量和用途有所不同

如信息系统、操作系统等

• 使用层的好处

总的说，使用层可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般的服务分离

减少耦合和依赖性、增强内聚性、提高潜在的复用性并且概念更加清晰

封装和分解了相关的复杂度

较高级的技术服务层（如UI层、应用层和领域层）可以用新的实现替换。较低级的技术服务层不太可能

较低层包含可复用功能

某些层（主要是领域层和技术服务层）可以是分布式的

通过逻辑划分，有助于团队开发

• 几个主要概念

领域对象：表示问题领域空间的事物，并且与应用或业务逻辑有关

领域层   ：包含领域对象，处理应用逻辑的层

领域层与领域模型的关系： 领域层是软件的一部分，领域模型是概念角度分析的一部分。可以利用来自领域模型的灵感创建领域层，获得现实世界和软件设计之间的低表示差异。

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

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

图 层和分区

5.1 准则：内聚职责；使关系分离

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

例如：UI层中的对象关注UI工作，如创建窗口和小部件、捕获鼠标和键盘事件等；应用逻辑层对象关注应用逻辑，如计算销售总额或税金等

UI对象不应该处理应用逻辑

5.2 准则：为领域层和应用逻辑层创建领域对象

创建软件对象，使其名称和信息类似于真实世界的领域，并为其分配应用逻辑职责

5.3 准则：不要将外部资源表示为最底层

大部分系统依赖于外部资源或服务，将外部资源表示为领域层中的子领域，而提供外部资源的一般性服务可以视为技术服务分区

将外部资源（如某个数据库）表示为“低于”基础层的层，是对逻辑视图和架构部署视图的混淆

图 对外部资源-数据库访问的表示对比

6. 准则：模型--视图分离原则

6.1 模型--视图分离原则的内容

• 不要将非UI对象直接与UI对象连接或耦合（例如sale软件对象引用java swing JFrame窗口对象）

因为窗口与某个应用相关，而（理想情况下）非窗口对象可以在新应用中重用或附加到新界面

• 不要在UI对象中加入应用逻辑（例如税金的计算）

UI对象应该只初始化UI元素，接收UI事件（如鼠标点击）、将应用逻辑的请求委派到非UI对象

6.2 观察者模式

观察者模式是对模型--视图分离准则的合理扩展，即领域对象只能通过PropertyListener（Java中的常用接口）的接口向视图UI对象发送消息

6.3 为何要分离模型--视图？

支持内聚的模型定义，这些定义只注重领域过程，而非用户界面

允许对模型和用户界面层分别进行开发

使界面的需求变更对领域层的影响最小化

允许新视图能够方便的连接到现有的领域层之上，而不会对领域层产生影响

允许对同一模型对象同时使用多个视图

允许模型层的运行不依赖于用户界面层

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

7. SSD（顺序图）、系统操作和层之间的联系

从UI层发送到领域层的消息是SSD中所描述的系统操作，如下图：

图 SSD 系统操作和层的关系