搜索
面向对象分析设计Object-OrientedAnalysis&Design谭火彬第08章面向对象的设计（构架设计）Object-OrientedDesign-RefineArchitecture-3-学习路线图OOUMLOOPDP…Case-Study…学习路线图::……………………12345678910-4-内容安排过渡到设计构架设计基础确定设计元素应用设计机制定义运行时构架描述分布-5-内容安排过渡到设计构架设计基础确定设计元素应用设计机制定义运行时构架描述分布-6-软件设计的定义IEEE1990：设计是构架、构件、接口、以及系统其它特征定义的过程-7-更精确定义软件设计（的结果）必须描述系统的构架（architecture）系统如何分解（decompose）和组织（organize）构件描述构件间的接口（interface）描述构件（component）：必须详细到可进一步构造的程度-8-软件设计知识域(SWEBOK)D-设计（Decompositiondesign）将系统映射为构件片（componentpieces）FP-设计（FamilyPatterndesign）目标是探求一定范围的通用性I-设计（Inventiondesign）基于概念化原型作系统分析，定义系统以满足所发现的需要和需求-9-从分析到设计分析是设计的输入，设计是分析的细化方法相同，但关注点不同分析：做什么(What)分析有效地确定了将要构建的内容分析重点关注业务(business)问题设计：怎么做(How)设计定义如何构建目标系统：采用何种技术、何种平台来实现分析模型设计关注于系统的技术(technical)和实现(implementation)细节-10-回顾：从需求到分析RequirementModel------------------------------------------------------------------------------------------------------------------------------------------------------------------------SupplementarySpecificationGlossaryAnalysisworkflowAnalysisModelUseCaseRealization-AnaysisAnalysisClass::-11-从分析到设计DesignModelUseCaseRealization-Design:::InterfaceDesignClassSubsystemDesignworkflowAnalysisModelUseCaseRealization-AnaysisAnalysisClass::-12-分析VS.设计分析关注问题的理解理想化设计行为系统结构功能需求一个小的模型设计关注解决方案的理解操作和属性性能接近实际的代码对象的生命周期非功能需求一个大的模型-13-并不是自下而上或自上而下的抽象具体化-14-从分析模型到设计模型设计是对分析的进一步细化，其根本思想是：对分析模型中的分析类进行进一步的设计，添加实现细节，这些分析类最终转变成设计元素面向对象的方法中，设计是分析的自然延续，在分析模型中添加特定的实现机制，得到可以实现的设计元素设计过程会直接覆盖分析模型的成果，随着设计的深入，分析模型将消失-15-保留分析模型迭代开发中，保留分析模型是必要的分析模型可以保持从需求、分析到设计的可跟踪性下一迭代的分析也需要前一迭代的分析模型分析模型提供了系统核心业务场景，对于理解大规模系统的核心机制有非常重要的意义需要采取一些手段来保留系统的分析模型在某个点冻结分析模型，保留一份历史拷贝；但这可能存在模型不一致性问题同时维护两个独立的分析模型和设计模型；但增加维护模型的成本-16-内容安排过渡到设计构架设计基础确定设计元素应用设计机制定义运行时构架描述分布-17-构架设计构架(Architecture)设计即在系统的全局范围内，以分析活动的结果为出发点：将现有的“分析类”映射成设计模型中的“设计元素”明确适用于系统的“设计机制”调整内容逐渐充实为系统“构架”-18-构架设计构架设计内容确定核心元素：在构架的中高层，以“分析类”为出发点，确定相应的“核心设计元素”引入外围元素：在构架的中低层，以“分析机制”为出发点，确定满足分析类要求的“设计机制”，并将相关的内容引入设计模型优化组织结构：按照高内聚、低耦合的基本原则，整理并逐渐充实构架的层次和内容定义设计后的组织结构：构架设计还应该考虑设计完成后系统实现、运行以及部署等阶段的组织结构-19-UML和构架设计构架的全部内容就是复杂性管理：将解决方案划分成多个小的组成部分，再将这些小的部分结合起来，构成更大的、更加一致的结构UML中提供了相关的模型支持构架层的建模包图(Packagediagram)包(Package)、依赖关系(Dependency)子系统(Subsystem)层(Layer)-20-包-package包是一种将模型元素分组的机制包主要用于组织模型元素配置管理单元分包的原则职责相似：将一组职责相似、但以不同方式实现的类归为一组有意义的包；如java类库中的javax.swing.border协作关系：包含了各种不同类型的类，它们之间通过相互协作实现一个意义重大的职责-21-依赖关系包之间存在着依赖关系如果Client包依赖于Supplier包：Supplier包的改变将影响到Client包Client包不能够独立的重用，因为它依赖于Supplier包ClientPackageSupplierPackage-22-定义依赖关系-包元素的可见性Public可见性Private可见性高级依赖关系合并关系（merge）定义一个包的内容如何被另一个包扩展包导入关系允许一个包可以不需要通过包名直接访问被导入包中的元素公有导入（导入关系（import））导入后的元素在当前包内的可见性不变私有导入（访问关系（access））导入后的元素是私有的，对外不可见等同于Java中的import关键词-23-示例：高级依赖关系-24-包设计原则包内聚性原则复用发布等价原则（REP）共同复用原则（CRP）共同封闭原则（CCP）包耦合性原则无环依赖原则（ADP）稳定依赖原则（SDP）稳定抽象原则（SAP）-25--26-包设计原则：无环依赖原则ABABCA'ABC依赖环使得任何一个包都不能独立的重用，修改任何一个包都会引起所有的包的变化-27-内容安排过渡到设计构架设计基础确定设计元素应用设计机制定义运行时构架描述分布-28-设计元素设计元素(DesignElements)是指能够直接用于实现(编码)的模型要素包(Package)设计类(DesignClasses)子系统(Subsystem)接口(Interface)确定设计元素的目的是改进(调整)分析类，使之成为适当的设计模型元素-29-从分析类到设计元素controlentityboundaryboundaryAnalysisClassesDesignElements-30-确定设计类分析类被直接映射到设计类，如果：该分析类是一个简单类该分析类表示一个简单逻辑抽象更复杂的分析类可能分成多个设计类成为一个包成为一个接口和子系统任何组合...-31-分析类到设计元素的映射一个分析类，可能一个简单的设计类一个设计类的一部分一个聚合类同一个类继承而来的一组类一组功能相关的类(如，一个包)一个子系统一个关系分析类间的一个关系可能成为设计中的一个类(关联类)一个分析类(或部分)可以被硬件(或已有构件)所实现，则根本不需要“设计”-32-利用包将设计类分组在分析阶段利用B-C-E的备选构架对分析类进行分组，而设计时，由于大量设计元素的引入，因此需要定义更合理的分组(封装)机制封装标准可以基于多种不同的因素：配置单元开发团队中的资源分配反映用户类型表示已有产品和服务PackageCPackageBPackageA-33-封装技巧：边界类(1)如果系统边界(用户界面、系统接口)可能进行相当大的更改边界类应被放置在几个单独的包-34-封装技巧：边界类(2)如果系统边界(用户界面、系统接口)不太可能进行大的更改将边界类和在功能上与它们相关的类打包到一起-35-封装技巧：功能相关的类(1)确定类在功能上是否相关的标准：如果某个边界类的功能是显示一个特定的实体类，它就可能在功能上与该实体类相关如果两个类与同一个参与者进行交互，或受到对同一个参与者更改的影响一个类的行为和（或）结构的变化使得另一个类也必须相应地变化一个类的删除影响其它类两个对象进行大量的消息交互，或者以一种复杂的方式相互通信两个类之间存在某些关系一个类创建另一个类的实例-36-封装技巧：功能相关的类(2)下列情况一般不应将两个类放在同一个包中与不同参与者相关的两个类不应放在同一个包中一个可选类和一个必选类不应放在同一个包中-37-实例：旅游申请系统分包考虑考虑的几个要素消除边界包和控制包之间的依赖环。将边界包中的接口类独立出来，建立新的外部接口包（ExternalInterfaces），剩余的用户界面保留为单独的界面包（UserInterface）控制类和申请业务相关的实体类打包为申请业务包（ApplicationServices），负责与前端进行交互，并处理与申请相关的业务与参与者相关业务可以考虑和其它系统的复用(如与CRM系统)，与路线管理相关的业务也存在一定的复用性，这些均可放在单独的包中，作为该旅游企业基础的业务服务单元(TourArtifacts)-38-实例：旅游申请系统分包结果-39-接口接口(Interface)是类、子系统或构件提供的操作的集合接口允许用户以公开的方式定义多态，并且和实现没有直接联系接口支持“即插即用”的结构实现(Realization)关系-40-子系统与接口子系统(Subsystem)是一种介于包和类之间的一种设计机制，它实现一个或多个接口所定义的行为具有包的语义：能够包含其它模型元素具有类的语义：具有行为-41-子系统的作用完全封装了行为利用清晰的接口代表所拥有的能力(便于复用)可以定义不同的实现-42-子系统VS.包子系统：提供行为完全封装实现细节容易替换包：不提供行为不完全封装实现细节难以替换ClientClassSubsystemAsubsystemPackageBClassB1ClassB2关键在于封装-43-子系统的主要用途子系统可以将系统划分成独立的部分，将被实现为独立的构件，这些构件在保持结构不变的情况下，可以独立地开发和部署，适应变更，而不影响到其它系统子系统也可用于将系统划分成若干单元表示设计中的既存产品或外部系统-44-候选子系统可能发展为子系统的分析类提供复杂服务和(或)通用功能的类边界类(用户界面和外部系统接口)设计中既存产品或外部系统通信软件数据库访问支持类型和数据结构通用程序专业应用软件产品-45-确定子系统如果分析类相当复杂，以致它所包含的行为无法由单个类(或几个类的简单组合)来独自负责执行，此时应该考虑将该分析类映射到设计子系统使用设计子系统来封装协作子系统客户在完全不知道内部设计的情况下可以很方便的使用它提供的服务子系统内部的实现细节则延迟到子系统设计阶段-46-确定子系统示意图SupermanClass-47-确定子系统的接口目的基于子系统的职责确定其接口步骤为每个子系