逻辑架构与UML包图详解

· ·
low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O
Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure)
· · ·
handles application layer requests implementation of domain rules domain services (POS, Inventory) - services may be used by just one application, but there is also the possibility of multi-application services
· ·
(relatively) high-level technical services and frameworks Persistence, Security
Technical Services (AKA Technical Infrastructure, High-level Technical Services)
ProductCatalog
getProductSpec(...) ...
UP制品相互影响


强调的是逻辑架构（LA) 主要的输入是补充性规格说明中记录的 架构方面的约束和要点 LA定义了包，包中有关于软件类的定 义
UI
示 例
Swing
not the Java Swing libraries, but our GUI classes based on Swing
软件架构师是做什么的？

软件架构师的职责是把需求转换为软件世界的模型。 4+1视图中以use case作为核心，其中功能性需 求以及部分非功能性需求会被软件架构师通过分析 和设计，映射为各种软件设计模型。从OOA/OOD 角度说，use case 在这个过程中是要转换为各种 UML，其中类图，序列图，状态图是最常用到的。 这个转换过程是需要智慧的，use case是目的， 各种OO的原则是指导，设计模式是经验，灵活运 用是能力。里面蕴涵了设计的美感，我觉得这个过 程是衡量一个软件架构师的最重要的指标。这个过 程是需要创造力和想象力的。可能很多人认为这个 地方正是软件架构师体现能力的地方。
Domain (AKA Business, Application Logic, Model)
· ·
very general low-level business services used in many business domains CurrencyConverter
Business Infrastructure (AKA Low-level Business Services)
Application (AKA Workflow, Process, Mediation, App Controller)
使用层的好处




关系分离、高级服务与低级服务分离、特定于应用 的服务与一般性服务分离。层可以减少耦合和依赖 性、增加内聚性、提高潜在的复用性并且使概念更 加清晰 封装和分解了相关的复杂性 某些层能够使用新的实现替换。对于较低级的技 术服务层或基础层来说不大可能（例如java.util） 但是对UI、应用层和领域层来说是可能的。 较低层包含可复用功能 某些层（主要是领域层和技术服务层）可以是分布 式的。 通过逻辑划分，有助于团队开发。
: Register Design interaction diagrams (a dynamic view) enterItem (itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
ቤተ መጻሕፍቲ ባይዱ
Register class diagrams (a static view) ... makeNewSale() enterItem(...) ... 1 1 ...
准则：使用层进行设计

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

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

设计
逻辑架构的包图(静态视图） 交互图(动态视图） 类图（静态视图)
Sample UP Artifact Relationships Domain Model
Business Modeling
*
*
Requirements
Use-Case Model
Vision
Supplementary Specification
第13章 逻辑架构和UML包图
目标

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


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

业务建模
领域模型
需求
用例模型 设想 补充性规格说明 词汇表
Web
Domain
Sales
Payments
Taxes
Technical Services
Persistence
Logging
RulesEngine
逻辑架构（logical architecture）


逻辑架构是软件类的宏观组织结构，它 将软件类组织为包(或命名空间）、子 系统和层等。 为何称其为逻辑架构？ 因为并未决定如何在不同的操作系统进 程或网络中物理的计算机上对这些元素 进行部署（后一种决定是部署架构的一 部分）。
UI
Domain
Swing
Web
Sales
UI UI::Swing UI::Web
Swing Domain::Sales
Web Domain Sales
UML工具：从代码逆向工程 产生包图


开发早期，根据绘制的UML包图的草图 来组织代码； 随着代码库的不断增长，编程上花费的 时间更多，减少了建模或绘制UML图的 时间，可以利用UML CASE工具对源代 码进行逆向工程，从而自动生成包图。

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

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



在严格的分层架构中，层只能调用与其相邻 的下层的服务。这种设计在网络协议栈中比 较常见，而在信息系统中不太常见。在信息 系统中通常使用宽松的分层架构，其中较高 层可以调用其下任何层的服务 例如，UI层可以调用与其相邻的应用逻辑层， 也可以调用更下面的技术服务层中的元素， 完成日志记录等工作 逻辑架构并非一定要组织为层。但这种方式 极为常用
将代码组织映射为层和UML包
//---UI包 Java中称为包package com.mycompany.nextgen.ui.swing C#和C++中称为命名空间 com.mycompany.nextgen.ui.web //---领域层 namespace //---特定于NextGen项目的包 com.mycompany.nextgen.domain.sales com.mycompany.nextgen..domain.payments //---技术服务层 //---我们自己的持久（数据库）访问层 com.mycompany.service.persistence //第三方 org.apache.log4j org.apache.soap.rpc //---基础层 //---我们小组自己创建的基础包 com.company.util
层（Layer）



层是对类、包或子系统的甚为粗粒度的 分组，具有对系统主要方面加以内聚的 职责。 层按照“较高”层（例如UI层）可以调 用“较低”层的服务 OO系统中通常包括的层有：
用户界面 应用逻辑和领域对象 技术服务（例如数据库接口或错误日志） 独立于应用的，也可在多个系统中复用的 服务。
Glossary
The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Design Model package diagrams of the logical architecture (a static view) UI Domain Tech Services
width implies range of applicability
dependency
· · · · ·
handles presentation layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation
UML包图

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

层可以建模为UML包。例如，UI层可 以建模为名为UI的包
UML包图


UML包图提供了组织元素的方式（类，其他包， 用例，…） 嵌套包十分常见 UML包是比Java包和.NET命名空间更为通用的概 念 如果包内部显示了其成员，则在标签上标识包名； 否则，可以在包体内标识包名称 人们通常希望显示包之间的依赖性(耦合），以 便开发者能够看到系统内大型事物之间的耦合。 UML的依赖线即可用于此目的，依赖线是有箭头 的虚线，箭头指向被依赖的包 完全限定的名称 例如Java::util::Date
典型的层
信 息 系 统 逻 辑 架 构 中 常 见 的 层
· · · ·
GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, ...
UI (AKA Presentation, View)
more app specific
准则：内聚职责；使关系分离



同一层内的对象在职责上应该具有紧密关联，不 同层中对象的职责则不应该混淆 例如，UI层中的对象应该关注于UI工作，例如创 建窗口和小部件、捕获鼠标和键盘事件等。应用 逻辑或“领域”层中的对象应该关注应用逻辑， 例如计算销售总额或税金，或在棋盘上移动棋子； UI对象不应该处理应用逻辑！例如Java Swing Jframe（窗体）对象不应该包含计算税金或移动 棋子的逻辑。而应用逻辑类不应该捕获UI鼠标或 键盘事件。否则将违反关系分离和高内聚原则 （这是基本架构原则）
UI not the Java Swing libraries, but our GUI classes based on Swing
Swing
Web
Domain
Sales
Payments
Taxes
Technical Services
Persistence
Logging
RulesEngine
案例研究中应该关注的层