Chapter 13 逻辑架构和UML包图·。 ●●●●● ●●●● ●●。●●
Chapter 13 逻辑架构和UML包图
Sample UP Artifact Relationships Domain ●●●●● Business ●●●● ●●● ●●●● ●●0● Use-Case Model Supplementary Vision Specification The logical architecture is influenced by the captured in the Supp. Spec Design Model Tech Services Design interaction diagrams (a dynamic view emiD, quanti Productcatalog class diagrams makeNewsaleo getProductspec(.)
: Register enterItem (itemID, quantity) : ProductCatalog spec = getProductSpec( itemID ) Requirements Business Modeling Design Sample UP Artifact Relationships Vision Glossary 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 ... makeNewSale() enterItem(...) ... ProductCatalog ... getProductSpec(...) ... class diagrams 1 1 (a static view) interaction diagrams (a dynamic view) UI package diagrams of the logical architecture (a static view) Domain Tech Services Design Model
●●●● ●●● Architectural layers ●●●●● ●●●● ●●0● The Fo0 Store 回区 Clarity minor focus Interface explore how to connect to Enter lem And so on. other layers application primary focus of case study ogic and Sale Payment domain object xplore how to layer secondary focus technical services layer Log PersistenceFacade explore how to desig
Architectural Layers
●●●●● ●●●● Architectural Layers ●●● ●●●● ●●0● UI not the java Swing qp- Swing libraries,but Web our Gul classes based on Swing Domain Sales Payments Taxes Technical Services Persistence Logging Rules Engine
Architectural Layers Domain UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Sales Payments Taxes Technical Services Persistence Logging RulesEngine
●●●●● ●●●● 为什么要分层 ●●●●● ●●●● ●●0● ●分层是处理复杂性的有效手段 复杂性和分布性是目前应用系统 分层中的每一层都可以被单独理解,无需对其他部分做深 入研究 ●每一层都可以被实现了同样功能的其他实现所替代。 ●建立在标准化机制上 ●层次之间具有单向的依赖关系,高层使用底层的资源,高 层的改动不影响底层的改动
为什么要分层 ⚫ 分层是处理复杂性的有效手段 ⚫ 复杂性和分布性是目前应用系统 ⚫ 分层中的每一层都可以被单独理解,无需对其他部分做深 入研究。 ⚫ 每一层都可以被实现了同样功能的其他实现所替代。 ⚫ 建立在标准化机制上 ⚫ 层次之间具有单向的依赖关系,高层使用底层的资源,高 层的改动不影响底层的改动
●●●●● ●●●● 三个主要的层次 ●●● ●●●● ●●0● 表示层 用于处理用户和软件系统之间的交互。 ●数据/技术服务层 处理那些需要持久化的数据和操作这些数据的事务 随着对分层理解的深入,一些诸如日志、审计和安全的处理也归 入了这一层。 ●业务逻辑层 表示领域中的基本概念和他们之间的关系 ●领域逻辑相对而言是最重要的,也是比较稳定的 不要将领域逻辑和表示层、数据/技术服务层混淆
三个主要的层次 ⚫ 表示层 ⚫ 用于处理用户和软件系统之间的交互。 ⚫ 数据/技术服务层 ⚫ 处理那些需要持久化的数据和操作这些数据的事务。 ⚫ 随着对分层理解的深入,一些诸如日志、审计和安全的处理也归 入了这一层。 ⚫ 业务逻辑层 ⚫ 表示领域中的基本概念和他们之间的关系 ⚫ 领域逻辑相对而言是最重要的,也是比较稳定的。 ⚫ 不要将领域逻辑和表示层、数据/技术服务层混淆
●●● ●●● ●●●●● ●●● 使用UML包图来表示层 ●●● ●●●● ●●0● ●命名空间 子系统 Domain 依赖性 Sale Ul: Swing UI:: Web Swing Domain Sales Sales
使用UML包图来表示层 ⚫ 命名空间 ⚫ 子系统 ⚫ 依赖性 Domain::Sales UI::Swing UI::Web Sales Swing Web UI Domain UI Domain Swing Web Sales
●●●●● ●●●● UML工具:逆向工程 ●●● ●●●● ●●0● 在开发过程的早期,我们会画出UML包图的草 图,然后根据这些草图来组织代码。随着代码 不断增长,可以利用 UML Case工具对源代码 进行逆向工程,自动生成包图
UML工具:逆向工程 ⚫ 在开发过程的早期,我们会画出UML包图的草 图,然后根据这些草图来组织代码。随着代码 不断增长,可以利用UML Case工具对源代码 进行逆向工程,自动生成包图
●●● ●●● ●●●●● ●●● 准则:利用层进行设计 ●●● ●●●● ●●0● ●将系统的大型逻辑结构组织为独立的、职责相 关的、离散的层,每个层具有较好的内聚。较 低的层是低级别和一般性的服务,较高层则是 与应用相关。 协作和耦合是从较高的层到较低的层进行的, 要避免从较低层到较高层的耦合
准则:利用层进行设计 ⚫ 将系统的大型逻辑结构组织为独立的、职责相 关的、离散的层,每个层具有较好的内聚。较 低的层是低级别和一般性的服务,较高层则是 与应用相关。 ⚫ 协作和耦合是从较高的层到较低的层进行的, 要避免从较低层到较高层的耦合
●●● ●●●●● ●●●● 准则:利用层进行设计 ●●●●● ●●●● ●●0● ●使用层主要解决了以下的问题: ●如果系统耦合度很高,源代码的变更会波及整个系 统。 应用逻辑与用户界面交织在一起,因此代码无法复 用于其他不同界面或分布到不同的节点。 潜在的一般性技术服务或业务逻辑与特定于应用的 逻辑交织在一起,因此无法实现复用,或分布到不 同的节点
准则:利用层进行设计 ⚫ 使用层主要解决了以下的问题: ⚫ 如果系统耦合度很高,源代码的变更会波及整个系 统。 ⚫ 应用逻辑与用户界面交织在一起,因此代码无法复 用于其他不同界面或分布到不同的节点。 ⚫ 潜在的一般性技术服务或业务逻辑与特定于应用的 逻辑交织在一起,因此无法实现复用,或分布到不 同的节点