Chapter 13 逻辑架构和UML包图.

Presentation on theme: "Chapter 13 逻辑架构和UML包图."— Presentation transcript:

1 Chapter 13 逻辑架构和UML包图

2

3 Architectural Layers

4 Architectural Layers

5 为什么要分层 分层是处理复杂性的有效手段 分层中的每一层都可以被单独理解，无需对其他部分做深入研究。
复杂性和分布性是目前应用系统 分层中的每一层都可以被单独理解，无需对其他部分做深入研究。 每一层都可以被实现了同样功能的其他实现所替代。 建立在标准化机制上 层次之间具有单向的依赖关系，高层使用底层的资源，高层的改动不影响底层的改动。 在我们人类没有进化出能够处理网状结构的大脑前，我们最好还是将问题搞得简单些。

6 三个主要的层次 表示层 数据/技术服务层 业务逻辑层 用于处理用户和软件系统之间的交互。 处理那些需要持久化的数据和操作这些数据的事务。
随着对分层理解的深入，一些诸如日志、审计和安全的处理也归入了这一层。 业务逻辑层 表示领域中的基本概念和他们之间的关系 领域逻辑相对而言是最重要的，也是比较稳定的。 不要将领域逻辑和表示层、数据/技术服务层混淆。

7 使用UML包图来表示层 命名空间 子系统 依赖性

8 UML工具：逆向工程 在开发过程的早期，我们会画出UML包图的草图，然后根据这些草图来组织代码。随着代码不断增长，可以利用UML Case工具对源代码进行逆向工程，自动生成包图

9 准则：利用层进行设计 将系统的大型逻辑结构组织为独立的、职责相关的、离散的层，每个层具有较好的内聚。较低的层是低级别和一般性的服务，较高层则是与应用相关。 协作和耦合是从较高的层到较低的层进行的，要避免从较低层到较高层的耦合。

10 准则：利用层进行设计 使用层主要解决了以下的问题： 如果系统耦合度很高，源代码的变更会波及整个系统。
应用逻辑与用户界面交织在一起，因此代码无法复用于其他不同界面或分布到不同的节点。 潜在的一般性技术服务或业务逻辑与特定于应用的逻辑交织在一起，因此无法实现复用，或分布到不同的节点

11

12 代码：UML包组织映射为代码 大部分流行的OO语言都提供了包的概念（在C#和C++中成为命名空间）
下面是使用Java将UML包组织映射为代码的例子：

13 代码：UML包组织映射为代码 // --- UI Layer com.mycompany.nextgen.ui.swing
com.mycompany.nextgen.ui.web // --- DOMAIN Layer // packages specific to the NextGen project com.mycompany.nextgen.domain.sales com.mycompany.nextgen.domain.payments // --- TECHNICAL SERVICES Layer // our home-grown persistence (database) access layer com.mycompany.service.persistence // third party org.apache.log4j org.apache.soap.rpc // --- FOUNDATION Layer // foundation packages that our team creates com.mycompany.util

14 领域模型与领域层

15 准则：不要将外部资源表示为最底层 大部分系统依赖于外部资源或服务，例如MySQL数据库和Novell LDAP名字和目录服务，这些是物理实现构建，而不是逻辑架构中的层 将外部资源(如某个数据库)，表示为一个层，是对逻辑视图和架构部署视图的混淆。

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

17 部署试图示例

18 准则：模型-视图分离原则 不要将非UI对象直接与UI对象连接或耦合。 不要在UI对象方法中加入应用逻辑。

19 SSD、系统操作和层之间的关系