逻辑架构与UML包图详解课件

1、第13章 逻辑架构和UML 包图 1 目标目标 ?介绍使用层的逻辑架构 ?阐述使用UML 包图的逻辑架构 2 简介简介 ?现在，我们就从面向分析的工作过渡到 软件设计 ?典型OO系统设计的基础是若干架构层， 例如UI层、应用逻辑（或“领域”） 层等。 3 UP制品相互影响制品相互影响 ?业务建模 ?领域模型 ?需求 ?用例模型 ?设想 ?补充性规格说明补充性规格说明 ?词汇表 ?设计 ?逻辑架构的包图(静态视图） ?交互图(动态视图） ?类图（静态视图) 4 : Register enterItem (itemID, quantity) : ProductCatalog spec = getP

2、roductSpec( itemID ) Require- ments Business Modeling Design Sample UP Artifact Relationships VisionGlossary The logical architecture is influenced by the constraints and non-functional requirements captured in the Supp. Spec. Domain Model * * Supplementary Specification Use-Case Model Register . ma

3、keNewSale() enterItem(.) . ProductCatalog . getProductSpec(.) . 1 1 class diagrams (a static view) interaction diagrams (a dynamic view) UI package diagrams of the logical architecture (a static view) Domain Tech Services Design Model 5 UP制品相互影响制品相互影响 ?强调的是逻辑架构（LA) ?主要的输入是补充性规格说明中记录的 架构方面的约束和要点 ?LA定

4、义了包，包中有关于软件类的定 义 6 示示 例例 Domain UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web SalesPaymentsTaxes Technical Services PersistenceLoggingRulesEngine 7 逻辑架构（逻辑架构（logical architecture） ?逻辑架构是软件类的宏观组织结构，它 将软件类组织为包(或命名空间）、子 系统和层等。 ?为何称其为逻辑架构？ 因为并未决定如何在不同的操作系统进 程或网络中物理的计算机上对这

5、些元素 进行部署（后一种决定是部署架构的一 部分）。 8 层（层（Layer） ?层是对类、包或子系统的甚为粗粒度的 分组，具有对系统主要方面加以内聚的 职责。 ?层按照“较高”层（例如UI层）可以调 用“较低”层的服务 ?OO系统中通常包括的层有： ? 用户界面 ? 应用逻辑和领域对象 ? 技术服务（例如数据库接口或错误日志） 独立于应用的，也可在多个系统中复用的 服务。 9 架构分层架构分层 ?在严格的分层架构中，层只能调用与其相邻 的下层的服务。这种设计在网络协议栈中比 较常见，而在信息系统中不太常见。在信息 系统中通常使用宽松的分层架构，其中较高 层可以调用其下任何层的服务 ?例如，U

6、I 层可以调用与其相邻的应用逻辑层， 也可以调用更下面的技术服务层中的元素， 完成日志记录等工作 ?逻辑架构并非一定要组织为层。但这种方式 极为常用 10 Domain UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web SalesPaymentsTaxes Technical Services PersistenceLoggingRulesEngine 11 案例研究中应该关注的层案例研究中应该关注的层 ?尽管OO技术可以用于所有级别，但本 课程对OOA/D的介绍着重于核心应用逻 辑（或“

7、领域”）层，其次才是对其他 层的讨论。 12 软件架构 ?软件架构（宏观） ? 架构是一种重要决策，其中涉及软件系统的组 织 ? 对结构元素及其组成系统所籍接口的选择 ? 这些元素特定于其相互协作的行为 ? 这些结构和行为元素到规模更大的子系统的组 成 ? 以及指导该组织结构的架构风格 ? 这些元素及其接口、协作、和组成 13 软件架构师是做什么的？ ?软件架构师的职责是把需求转换为软件世界的模型。 4+1 视图中以use case 作为核心，其中功能性需 求以及部分非功能性需求会被软件架构师通过分析 和设计，映射为各种软件设计模型。从 OOA/OOD 角度说，use case 在这个过程中是

8、要转换为各种 UML ，其中类图，序列图，状态图是最常用到的。 这个转换过程是需要智慧的， use case 是目的， 各种OO的原则是指导，设计模式是经验，灵活运 用是能力。里面蕴涵了设计的美感，我觉得这个过 程是衡量一个软件架构师的最重要的指标。这个过 程是需要创造力和想象力的。可能很多人认为这个 地方正是软件架构师体现能力的地方。 14 UML包图包图 ?UML 包图通常用于描述系统的逻辑架构 ? 层 ? 子系统 ? 包（就Java ）而言等 ?层可以建模为UML 包。例如，UI层可 以建模为名为UI的包 15 UML包图包图 ?UML包图提供了组织元素的方式（类，其他包， 用例，） ?

9、嵌套包十分常见 ?UML包是比Java包和.NET命名空间更为通用的概 念 ?如果包内部显示了其成员，则在标签上标识包名； 否则，可以在包体内标识包名称 ?人们通常希望显示包之间的依赖性(耦合），以 便开发者能够看到系统内大型事物之间的耦合。 ?UML的依赖线即可用于此目的，依赖线是有箭头 的虚线，箭头指向被依赖的包 ?完全限定的名称 例如Java:util:Date 16 Domain:Sales UI:WebUI:Swing Sales WebSwing UI Domain DomainUI Swing Sales Web 17 UML工具：从代码逆向工程工具：从代码逆向工程 产生包图 ?

10、开发早期，根据绘制的UML 包图的草图 来组织代码； ?随着代码库的不断增长，编程上花费的 时间更多，减少了建模或绘制UML 图的 时间，可以利用UML CASE 工具对源代 码进行逆向工程，从而自动生成包图。 18 准则：使用层进行设计准则：使用层进行设计 ?使用层时：使用层时： ?将系统的大型逻辑结构组织为独立的、职 责相关的离散层，具有清晰、内聚的关注 分离。这样，“较低”的层是低级别和一 般性服务，较高的层则是与应用相关的。 ?协作和耦合是从较高层到较低层进行的， 要避免从较低层到较高层的耦合。 19 设计问题 ?使用层有助于解决如下问题： ?源码的变更波及整个系统大部分系统是高度耦

11、合的。 ?应用逻辑与用户界面交织在一起，因此无法复用 于其他不同界面或分布到其他处理节点之上 ?潜在的一般性技术服务或业务逻辑与更特定于应 用的逻辑交织在一起，因此无法被复用、分布到 其他节点或方便地使用不同实现替换 ?不同的关注领域之间的高度耦合。因此难以为不 同开发者清晰地界定和分配任务 20 典型的层典型的层 21 UI (AKA Presentation, View) Application (AKA Workflow, Process, Mediation, App Controller) Domain (AKA Business, Application Logic, Model)

12、 Technical Services (AKA Technical Infrastructure, High-level Technical Services) Foundation (AKA Core Services, Base Services, Low-level Technical Services/Infrastructure) width implies range of applicability GUI windows reports speech interface HTML, XML, XSLT, JSP, Javascript, . handles presentat

13、ion layer requests workflow session state window/page transitions consolidation/transformation of disparate data for presentation 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 p

14、ossibility of multi-application services (relatively) high-level technical services and frameworks Persistence, Security low-level technical services, utilities, and frameworks data structures, threads, math, file, DB, and network I/O more app specific d e p e n d e n c y Business Infrastructure (AK

15、A Low-level Business Services) very general low-level business services used in many business domains CurrencyConverter 信 息 系 统 逻 辑 架 构 中 常 见 的 层 22 使用层的好处使用层的好处 ?关系分离、高级服务与低级服务分离、特定于应用 的服务与一般性服务分离。层可以减少耦合和依赖 性、增加内聚性、提高潜在的复用性并且使概念更 加清晰 ?封装和分解了相关的复杂性 ?某些层能够使用新的实现替换。对于较低级的技 术服务层或基础层来说不大可能（例如 java.util

16、） 但是对UI、应用层和领域层来说是可能的。 ?较低层包含可复用功能 ?某些层（主要是领域层和技术服务层）可以是分布 式的。 ?通过逻辑划分，有助于团队开发。 23 准则：内聚职责；使关系分离准则：内聚职责；使关系分离 ?同一层内的对象在职责上应该具有紧密关联，不 同层中对象的职责则不应该混淆 ?例如，UI层中的对象应该关注于UI工作，例如创 建窗口和小部件、捕获鼠标和键盘事件等。应用 逻辑或“领域”层中的对象应该关注应用逻辑， 例如计算销售总额或税金，或在棋盘上移动棋子； ?UI对象不应该处理应用逻辑！例如Java Swing Jframe（窗体）对象不应该包含计算税金或移动 棋子的逻辑。而

17、应用逻辑类不应该捕获UI鼠标或 键盘事件。否则将违反关系分离和高内聚原则 （这是基本架构原则） 24 将代码组织映射为层和UML包 /-UI包 com.mycompany.nextgen.ui.swing com.mycompany.nextgen.ui.web /-领域层 /-特定于NextGen项目的包 com.mycompany.nextgen.domain.sales com.mycompany.nextgen.domain.payments /-技术服务层 /-我们自己的持久（数据库）访问层 com.mycompany.service.persistence /第三方 org.apa

18、che.log4j org.apache.soap.rpc /-基础层 /-我们小组自己创建的基础包 pany.util ?Java中称为包package ?C#和C+中称为命名空间 namespace 25 领域层和领域模型之间的关系领域层和领域模型之间的关系 ?领域层是软件的一部分，领域模型是概 念角度分析的一部分，它们是不同的。 ?利用来自领域模型的灵感创建领域层， 可以获得在实现世界和软件设计之间的 低表示差异。 ?例如：领域模型中的Sale 领域层中 创建的Sale 软件类。 26 Payment amount Sale date time Pays-for Payment amou

19、nt: Money getBalance(): Money Sale date: Date startTime: Time getTotal(): Money . . . Pays-for UP Domain Model Stakeholders view of the noteworthy concepts in the domain. Domain layer of the architecture in the UP Design Model The object-oriented developer has taken inspiration from the real world d

20、omain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered. 11 1 1 A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same

21、thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. inspires objects and names in 27 层、层和分区层、层和分区 ?层在架构中最初表示的是逻辑层，而 不是物理节点，但是现在，这个词被广 泛用于表示物理进程节点（或节点簇）， 例如“客户层”（客户计算机） ?架构中的层表示对系统的垂直方向的划 分。

22、?分区表示对层在水平方向进行划分， 形成相对平行的子系统。例如，技术服 务层可以划分为安全和统计等分区。 28 PersistenceSecurityLogging Technical Services POSInventory Tax Domain Vertical Layers Horizontal Partitions 层和分区 29 准则：不要将外部资源表示为 最底层 ?大部分系统依赖于外部资源或服务，例如 MySQL库存数据库和Novell LDAP命名和目录 服务。物理实现构件非逻辑架构中的层。 ?将外部资源（如某个数据库）表示为“低于 ”（例如）基础层（Foundation）的层

23、，是 对逻辑视图和架构部署视图的混淆。 ?就逻辑架构及其层而言，对某个持久数据集 合（例如库存数据）的访问可以视为 领域层 中的子领域库存子领域。而提供数据库访 问的一般性服务则可以视为技术服务分区（ Partition）持久性服务。 30 架构的混合视图架构的混合视图 Domain(s) Technical Services Foundation MySQL Inventory Persistence Naming and Directory Services Web AppFramework Technical Services POS Inventory Domain(s) Founda

24、tion Worse mixes logical and deployment views Better a logical view a logical representation of the need for data or services related to these subdomains, abstracting implementation decisions such as a database. 玞omponent? Novell LDAP UML notation: A UML component, or replaceable, modular part of the physical system UML notation: A physical database in the UML. 31 模型视图分离原则模型视图分离原则 ?其他包应该对UI层具有何种可见性？ ?非窗口类应该如何与窗口通信？ 32 模型视图分离原则模型视图分离原则 ?原则： ? 不要将非UI对象直接与UI对象连接或耦合。 ? 不要在UI对象方法中加入应用逻辑 ?模型领域层对象（如Sale、Payment） ?视图UI对象（如：窗口、web页、 applet和reports报表） 33 模型视图分离原则模型视图分离原则 ?模型视图分离原则规定，模型（领域） 对象不