逻辑架构与UML包图详解解析.ppt

第13章 逻辑架构和UML包图 目标 介绍使用层的逻辑架构 阐述使用UML包图的逻辑架构 简介 现在，我们就从面向分析的工作过渡到软件设计 典型OO系统设计的基础是若干架构层，例如UI层、应用逻辑（或“领域”）层等。 UP制品相互影响 业务建模 领域模型 需求 用例模型 设想 补充性规格说明 词汇表 设计 逻辑架构的包图(静态视图） 交互图(动态视图） 类图（静态视图) UP制品相互影响 强调的是逻辑架构（LA) 主要的输入是补充性规格说明中记录的架构方面的约束和要点 LA定义了包，包中有关于软件类的定义 示例 逻辑架构（logical architecture） 逻辑架构是软件类的宏观组织结构，它将软件类组织为包(或命名空间）、子系统和层等。 为何称其为逻辑架构？ 因为并未决定如何在不同的操作系统进程或网络中物理的计算机上对这些元素进行部署（后一种决定是部署架构的一部分）。 层（Layer） 层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。 层按照“较高”层（例如UI层）可以调用“较低”层的服务 OO系统中通常包括的层有： 用户界面 应用逻辑和领域对象 技术服务（例如数据库接口或错误日志）独立于应用的，也可在多个系统中复用的服务。 架构分层 在严格的分层架构中，层只能调用与其相邻的下层的服务。这种设计在网络协议栈中比较常见，而在信息系统中不太常见。在信息系统中通常使用宽松的分层架构，其中较高层可以调用其下任何层的服务 例如，UI层可以调用与其相邻的应用逻辑层，也可以调用更下面的技术服务层中的元素，完成日志记录等工作 逻辑架构并非一定要组织为层。但这种方式极为常用 案例研究中应该关注的层 尽管OO技术可以用于所有级别，但本课程对OOA/D的介绍着重于核心应用逻辑（或“领域”）层，其次才是对其他层的讨论。 软件架构 软件架构（宏观） 架构是一种重要决策，其中涉及软件系统的组织 对结构元素及其组成系统所籍接口的选择 这些元素特定于其相互协作的行为 这些结构和行为元素到规模更大的子系统的组成 以及指导该组织结构的架构风格－ 这些元素及其接口、协作、和组成 软件架构师是做什么的？ 软件架构师的职责是把需求转换为软件世界的模型。4+1视图中以use case作为核心，其中功能性需求以及部分非功能性需求会被软件架构师通过分析和设计，映射为各种软件设计模型。从OOA/OOD角度说，use case 在这个过程中是要转换为各种UML，其中类图，序列图，状态图是最常用到的。这个转换过程是需要智慧的，use case是目的，各种OO的原则是指导，设计模式是经验，灵活运用是能力。里面蕴涵了设计的美感，我觉得这个过程是衡量一个软件架构师的最重要的指标。这个过程是需要创造力和想象力的。可能很多人认为这个地方正是软件架构师体现能力的地方。 UML包图 UML包图通常用于描述系统的逻辑架构 层 子系统 包（就Java）而言等 层可以建模为UML包。例如，UI层可以建模为名为UI的包 UML包图 UML包图提供了组织元素的方式（类，其他包，用例，…） 嵌套包十分常见 UML包是比Java包和.NET命名空间更为通用的概念 如果包内部显示了其成员，则在标签上标识包名；否则，可以在包体内标识包名称 人们通常希望显示包之间的依赖性(耦合），以便开发者能够看到系统内大型事物之间的耦合。 UML的依赖线即可用于此目的，依赖线是有箭头的虚线，箭头指向被依赖的包 完全限定的名称 例如Java::util::Date UML工具：从代码逆向工程产生包图 开发早期，根据绘制的UML包图的草图来组织代码； 随着代码库的不断增长，编程上花费的时间更多，减少了建模或绘制UML图的时间，可以利用UML CASE工具对源代码进行逆向工程，从而自动生成包图。 准则：使用层进行设计 使用层时： 将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。这样，“较低”的层是低级别和一般性服务，较高的层则是与应用相关的。 协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。 设计问题 使用层有助于解决如下问题： 源码的变更波及整个系统－大部分系统是高度耦合的。 应用逻辑与用户界面交织在一起，因此无法复用于其他不同界面或分布到其他处理节点之上 潜在的一般性技术服务或业务逻辑与更特定于应用的逻辑交织在一起，因此无法被复用、分布到其他节点或方便地使用不同实现替换 不同的关注领域之间的高度耦合。因此难以为不同开发者清晰地界定和分配任务 典型的层 信息系统逻辑架构中常见的层 使用层的好处 关系分离、高级服务与低级服务分离、特定于应用