逻辑架构与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工具对源代码进行逆向工程，从而自动生成包图。,准则：使用层进行设计,使用层时： 将系统的大型逻辑结构组织为独立的、职责相关的离散层，具有清晰、内聚的关注分离。这样，“较低”的层是低级别和一般性服务，较高的层则是与应用相关的。 协作和耦合是从较高层到较低层进行的，要避免从较低层到较高层的耦合。,设计问题,使用层有助于解决如下问题： 源码的变更波及整个系统大部分系统是高度耦合的。 应用逻辑与用户界面交织在一起，因此无法复用于其他不同界面或分布到其他处理节点之上 潜在的一般性技术服务或业务逻辑与更特定于应用的逻辑交织在一起，因此无法被复用、分布到其他节点或方便地使用不同实现替换 不同的关注领域之间的高度耦合。因此难以为不同开发者清晰地界定和分配任务,典型的层,信息系统逻辑架构中常见的层,使用层的好处,关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。层可以减少耦合和依赖性、增加内聚性、提高潜在的复用性并且使概念更加清晰 封装和分解了相关的复杂性 某些层能够使用新的实现替换。对于较低级的技术服务层或基础层来说不大可能（例如java.util）但是对UI、应用层和领域层来说是可能的。 较低层包含可复用功能 某些层（主要是领域层和技术服务层）可以是分布式的。 通过逻辑划分，有助于团队开发。,准则：内聚职责；使关系分离,同一层内的对象在职责上应该具有紧密关联，不同层中对象的职责则不应该混淆 例如，UI层中的对象应该关注于UI工作，例如创建窗口和小部件、捕获鼠标和键盘事件等。应用逻辑或“领域”层中的对象应该关注应用逻辑，例如计算销售总额或税金，或在棋盘上移动棋子； UI对象不应该处理应用逻辑！例如Java Swing Jframe（窗体）对象不应该包含计算税金或移动棋子的逻辑。而应用逻辑类不应该捕获UI鼠标或键盘事件。否则将违反关系分离和高内聚原则（这是基本架构原则）,将代码组织映射为层和UML包,/-UI包 com.mycompany.nextgen.ui.swing com.mycompany.nextgen.ui.web /-领域层 /-特定于NextGen项目的包 com.mycompany.nextgen.domain.sales com.mycompany.nextgendomain.payments /-技术服务层 /-我们自己的持久（数据库）访问层 com.mycompany.service.persistence /第三方 org.apache.log4j org.apache.soap.rpc /-基础层 /-我们小组自己创建的基础包 pany.util,Java中称为包package C#和C+中称为命名空间namespace,领域层和领域模型之间的关系,领域层是软件的一部分，领域模型是概念角度分析的一部分，它们是不同的。 利用来自领域模型的灵感创建领域层，可以获得在实现世界和软件设计之间的低表示差异。 例如：领域模型中的Sale领域层中创建的Sale软件类。,层、层和分区,层在架构中最初表示的是逻辑层，而不是物理节点，但是现在，这个词被广泛用于表示物理进程节点（或节点簇），例如“客户层”（客户计算机） 架构中的层表示对系统的垂直方向的划分。 分区表示对层在水平方向进行划分，形成相对平行的子系统。例如，技术服务层可以划分为安全和统计等分区。,层和分区,准则：不要将外部资源表示为最底层,大部分系统依赖于外部资源或服务，例如MySQL库存数据库和Novell LDAP命名和目录服务。物理实现构件非逻辑架构中的层。 将外部资源（如某个数据库）表示为“低于”（例如）基础层（Foundation）的层，是对逻辑视图和架构部署视图的混淆。 就逻辑架构及其层而言，对某个持久数据集合（例如库存数据）的访问可以视为领域层中的子领域库存子领域。而提供数据库访问的一般性服务则可以视为技术服务分区（Partition）持久性服务。,架构的混合视图,模型视图分离原则,其他包应该对UI层具有何种可见性？ 非窗口类应该如何与窗口通信？,模型视图分离原则,原则： 不要将非UI对象直接与UI对象连接或耦合。 不要在UI对象方法中加入应用逻辑 模型领域层对象（如Sale、Payment） 视图UI对象（如：窗口、web页、applet和reports报表）,模型视图分离原则,模型视图分离原则规定，模型（领域）对象不应该直接与视图（UI）对象连接，对于视图对象也是如此。 MVC： M：Model模型指领域层（数据对象） V：View视图指UI层（GUI小部件，web页） C：Control控制器指应用层的工作流对象。（鼠标、键盘事件控制器（句柄）,模型视图分离原则,动机： 支持内聚的模型定义，这些定义只关注领域过程，而不是用户界面。 允许对模型和用户界面层分别进行开发。 使界面的需求变更对领域层的影响最小化。 允许新视图能够被方便地连接到现有