逻辑架构和UML包图
目标：
- 介绍使用层的逻辑架构。
- 阐述使用UML包图的逻辑架构。
我们就从面向分析的工作过度到软件设计，首先从大型事物开始。在这一级别上，典型OO系统设计的基础是若干架构层。本章简要考察逻辑分层架构和UML表示法。
UML包图可以作为设计模型的一部分，用来描述LA。UML包图也可以作为软件架构文档中的视图。其主要的输入是补充性规格说明中记录的架构方面的约束和要点。LA定义了包，包中有关于软件类的定义。
示例
什么是逻辑架构和层
逻辑架构（logical architecture）是软件类的宏观组织结构，它讲软件类组织为包、子系统和层等。之所称其为逻辑架构，是因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署架构的一部分）。
层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。同时，层按照较高层可以调用较低层的服务，而反之则不然的方式组织。OO系统中通常包括的层有：
- 用户界面。
- 应用逻辑和领域对象：表示领域概念的软件对象，这些对象实现了应用需求。
- 技术服务：提供支持性技术服务的常用对象和子系统。这些入伍通常是独立于应用的，也可在多个系统中复用。
在严格分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。在信息系统中通常使用宽松的分层架构，其中较高层可以调用其下任何层的服务。
逻辑架构并非一定要组织为层。但这种方式极为常用，因此在这里加以介绍。
案例研究中应该关注的层
尽管OO技术可以用于所有级别，但本书对OOA/D的介绍着重于合影应用漏极层，其次才是对其他层的讨论。
对其他层的设计探讨讲这种于该层于应用逻辑层的接口。
什么是软件架构
前面已经提及逻辑架构和部署架构，所以下面要介绍软件架构的定义。
架构是一组重要的决策，其中涉及软件系统的组织，对结构元素及其组陈高雄他那个所籍接口的选择，这些元素特定于其相互协作的行为，这些结构和行为元素到规模更大的子系统的组陈，以及指导该组织结构（这些元素及其接口、协作和组成）的架构风格。
不管哪种定义，所有软件架构定义的共同主题是，必须于宏观事物有关：动机、约束、组织、模式、职责和系统之连接的重要思想。
应用UML：包图
UML包图通常用于描述逻辑架构：层、子系统、包等。层可以监门卫UML包。
UML包图提供了组织元素的方式。UML包能够组织任何事物：类、其他包、用例等。
如果包内部显示了其成员，则在标签上标识包名；否则，可以在包体内标识包名称。
人们通常系统现实包之间的依赖性，以便开发者能够看到系统内大型事物之间的耦合。UML的依赖线即可用于此目的，依赖线是由箭头的虚线，箭头指向被依赖的包。
UML包代表命名空间。
UML工具：从代码逆向工程产生包图
在开发过程的早期，我们会画出UML包图的草图，然后根据这些草图来组织代码。随着时间的流逝，代码库不断增长，同时我们在编程上花费的时间更多，并减少了建模或绘制UML图的时间。此时，可以利用UML CASE工具对源代码进行逆向工程，从而自动生成包图。
准则：使用层进行设计
使用层的本质思想很简单：
- 讲系统的大型逻辑结构组织为独立的、职责相关的里三层，具有清晰、内聚的关注分离。
- 协作和耦合是从较高层到较低层涉及的，要避免从较低层到较高层的耦合。
使用层有助于解决如下问题：
- 源码的变更波及整个系统
- 应用逻辑于用户界面交织在一起，因此无法服用于其他不同界面或分布到其他处理节点之上。
- 潜在的一般性技术服务或业务逻辑于更特定于应用的逻辑交织在一起，因此无法被服用、分布到其他节点或方便地使用不同实现替换。
- 不同的关注领域之间高度耦合。因此难以为不同开发者清晰地界定和分配任务。
使用层的好处
- 总的来说，使用层可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰。
- 封装和分解了相关的复杂性。
- 某些层能够用新的实现替换。
- 较低层包含可复用功能。
- 某些曾使可以分布式的。
- 通过逻辑花费，有助于团队开发。
准则：内聚职责：使关系分离
同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责不应该混淆。
代码：讲代码组织映射为层和UML包
大部分流行的OO语言都提供了对包的支持。
定义：领域层与应用逻辑层：领域对象
典型的软件系统都有UI逻辑和应用逻辑，现在，关键问题使：我们如何使用对象设计应用逻辑？
我们可以创建一个称为XYZ的类，然后将所有方法置入其中，以实现所有需要的逻辑。这一方法在技术上使可行的，但是OO思想并不提倡这种方法。
那么，提倡的方法是什么？答案是：创建软件对象，使其名称和信息类似于真实世界的领域，并且为其分配应用逻辑职责。这种软件对象称为领域对象。领域对象标识问题领域空间的事物，并且与应用或业务逻辑相关。
以这种方式设计对象，则可以将应用逻辑层更准确地称为架构的领域层，即包含领域对象，处理应用逻辑的层。
领域层和领域模型之间的关系
领域层和领域模型之间具有怎样的关系。我们应着眼于领域模型以获取领域层类命名的灵感。
领域层是软件的一部分，领域模型是概念角度分析的一部分，它们是不同的，但是利用来自领域模型的灵感创建领域层，我们可以获得实现世界和软件设计之间的低表示差异。
定义：层、层和分区
层（tier）在架构中最初表示的是逻辑层，而不是物理节点，但是现在，这个词被广泛用于表示物理进程节点。
架构中的层（layer）表示对系统在垂直方向的划分，而分区（partition）则表示对层在水平方向进行划分，形成相对平行的子系统。
准则：不要将外部资源表示为最底层
大部分系统依赖于外部资源或服务，这些是物理实现构件，而不是逻辑架构中的层。
将外部资源表示为低于基础层的层，是对漏极试图和架构部署视图的混淆。
就逻辑架构及其层而言，对某个持久数据集合的访问可以视为领域层中的子领域-库存子领域。而提供数据库房屋内的一般性服务则可以视为技术服务分区：持久性服务。
准则：模型-试图分离原则
该原则至少具有两部分：
1. 不要将非UI对象直接与UI对象连接或耦合。
2. 不要在UI对象方法中加入应用逻辑。UI对象应只初始化UI元素、接受UI事件、将应用逻辑的请求委派到非UI对象。
在这种语境下，模型是领域层对象的同义词。视图时UI对象的同义词。
模型-视图分离原则规定，模型对象不应该直接与视图对象连接，对于视图对象也是如此。
观察点模式时对该原则的合理扩展，即领域对象只能通过PropertyListener的接口向视图的UI对象发送消息。基于该模式，领域对象不知道UI对象的存在，即不知道它的具体窗口类。领域对象只需发送消息给实现了PropertyListener接口的对象。
该原则的进一步应用就是，领域类封装了与应用逻辑相关的信息和行为。
模型-视图分离的动机包括：
- 支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。
- 允许对模型和用户界面层分别进行开发。
- 使界面的需求变更对领域层的影响最小化。
- 允许新视图能够被方便地连接到现有的领域层之上，而不会对领域层产生影响。
- 允许对同意模型对象同时使用多个视图。
- 允许模型层的运行不依赖于用户界面层。
- 允许简单模型层能够简便地一致到另一用户接口框架下。
SSD、系统操作和层之间的联系
通过分析工作，我们为用例场景绘制了一些SSD草图。我们确定了从外部参与者到系统的输入事件。
SSD描述了这些系统操作，但是隐藏了特定的UI对象。
设计良好的分层架构支持高内聚和关系分离，UI层对象将从UI层向领域层转发请求以进行处理。
从UI层发送到领域层的消息将是SSD中所描述的信息。