您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 薪酬管理 > 第15讲 面向对象设计
第15讲面向对象的设计Object-OrientedDesignUML中各种图的关系CollaborationClass(Complex)ObjectStateRequirementUsecaseSequenceClass(Simple)ActivityRequirement阶段Analysis阶段Design阶段内容概述15.1从分析到设计15.2体系结构设计15.3用例设计15.4类设计15.5数据库设计第15讲面向对象设计15.1从分析到设计从系统分析与系统设计第二种观点认为系统分析与系统设计仅仅是在工作空间上面有所不同。分析阶段是在问题域空间上描述系统的,而系统设计阶段则是在系统分析的基础上,扩大为实现空间。也就是说,系统分析与系统设计之间是一种增量的关系。面向对象方法就是采用的这种观点。这种观点强调分析阶段应该建立一个与实现无关的模型,与实现有关的问题(编程语言、数据库、图形用户界面等)则是系统设计阶段的任务。第2种观点:增量关系系统设计:实现域系统分析:问题域15.1从分析到设计15.1从分析到设计分析:做什么Analysisemphasizedthebusinessproblem设计:怎么做Designfocusesonthetechnicalorimplementationconcernsofthesystem15.1从分析到设计RequirementModel------------------------------------------------------------------------------------------------------------------------------------------------------------------------SupplementarySpecificationGlossaryAnalysisworkflowAnalysisModelUseCaseRealization-Anaysis::AnalysisClass从需求到分析15.1从分析到设计DesignModelUseCaseRealization-Design:::InterfaceDesignClassSubsystemAnalysisModelUseCaseRealization-Anaysis::AnalysisClassDesignworkflow分析模型虽然有效地确定了将要构建的内容,但是却没有包含足够的信息来定义如何构建系统,而面向对象的设计用来填补分析和实现之间的差距15.1.1分析模型VS.设计模型需要维护两个模型吗?策略结果制作分析模型并精化成设计模型有了单独的设计模型,但失去了分析模型制作分析模型并精化成设计模型,然后用CASE工具重新获得分析模型有了单独的设计模型,但是用CASE工具重新获得的分析模型可能并不令人满意在细化阶段的某个点将分析模型冻结,然后把分析模型的一份拷贝精化成设计模型有了两个模型,但是它们步调不一致维护两个独立的模型—分析模型和设计模型有了两个模型,并且它们步调一致,但是这增加了维护的负担15.1.1分析模型VS.设计模型需要保留分析模型吗?易于理解:分析模型提供系统的“大场景”,它可能只包括设计模型中的1%到10%的类价值:–介绍新人加入项目–在交付几个月或几年后重新理解系统–理解系统是怎么满足客户需求以及提供可跟踪性–计划维护和增强–理解系统的逻辑架构–外包系统的构造–……15.1.1分析模型VS.设计模型需要分别维护分析模型和设计模型的系统庞大的复杂的战略性的受经常变更所支配的期望长期运行的外包的15.1.2软件设计的概念IEEE1990:设计是体系结构、构件、接口、以及系统其它特征定义的过程软件设计(的结果)必须描述系统的体系结构(architecture)–系统如何分解(decompose)和组织(organize)构件描述构件间的接口(interface)描述构件(component):必须详细到可进一步构造的程度15.1.2软件设计的概念按ISO/IEC12207软件开发生存周期过程,软件设计由两个活动组成软件体系结构设计-softwarearchitecturaldesign–顶层设计(top-leveldesign)–描述系统顶层的结构和组织–标识各个构件软件详细设计-softwaredetaileddesign–充分描述每个构件使之可以编码15.1.2软件设计的概念软件设计的作用软件设计在软件系统开发过程中扮演重要角色–开发者作出各种模型,形成实现时解决方案的蓝图–对这些模型进行分析和评价,以判定是否满足各种需求–便于考察备选方案和可行的替换措施–设计模型也可用于规划后续的开发活动–是编码和测试的输入连接需求和构造的桥梁软件设计软件设计基本概念软件设计的关键问题软件结构和体系结构软件设计质量分析和评价软件设计表示法软件设计策略和方法一般的设计概念软件设计的上下文软件设计过程软件设计使能技术并发性事件控制和处理分布性异常处理交互式系统持久性体系结构的结构和视点体系结构风格设计模式程序族和框架质量属性质量分析和评价工具量度软件设计评审静态分析模拟和原型结构描述行为描述一般策略面向功能设计面向对象设计以数据为中心的设计其它方法面向功能的设计量度面向对象的设计量度15.2体系结构为什么需要体系结构?我们所定义的类或者对象其关注的重点是定义了一个系统的核心概念和行为一个系统是由多个子系统组成,每个子系统中的领域对象都不只一个这些类如何组织、分布并协同完成所需的功能?因此系统应该要有一个总体的体系结构,它定义了各子系统之间的通信和耦合体系结构包图(architecturepackagediagram)15.2体系结构定义软件体系结构描述软件系统的子系统和构件及其相互关系体系结构的概念从研究软件的结构和风格开始,导致家族式(产品线)软件,可重用软件和类属设计UMLReferenceManual:体系结构是一个系统的组织结构,包括系统分解成的各个部分、它们的连接性、交互机制和通知系统设计的向导规则软件体系结构将多组类结合起来,形成一个有机的整体,并且展示各部分之间结构上的相互关系15.2体系结构体系结构的全部内容就是复杂性管理:将解决方案划分成多个小的组成部分,再将这些小的部分结合起来,构成更大的、更加一致的结构包(package)包依赖关系图(packagedependencydiagram)子系统(subsystem)层(layer)15.2.1包-package包:UML用包来对模型进行分组组织,一个包中包括若干个相关的模型元素。包主要用于组织模型元素配置管理单元包的表示15.2.1包-package分包的原则职责相似:将一组职责相似、但以不同方式实现的类归为一组有意义的包;–如java类库中的javax.swing.border协作关系:包含了各种不同类型的类,它们之间通过相互协作实现一个意义重大的职责15.2.1包-package包之间存在着依赖关系如果Client包依赖于Supplier包:Supplier包的改变将影响到Client包Client包不能够独立的重用,因为它依赖于Supplier包ClientPackageSupplierPackage15.2.1包-packageABABCA'ABC循环依赖使得任何一个包都不能独立的重用,修改任何一个包都会引起所有的包的变化避免循环依赖15.2.2体系结构设计过程1.确立目标2.将类分组3.展示技术4.抽取子系统5.针对准则和目标对体系结构进行评估1.确立目标一个好的体系结构其实是不断权衡、妥协、折衷的产物可扩展性可维护性可靠性可伸缩性……2.将类分组并评估各个类目标使每个包具有清晰的且严格定义的目的和职责结合体系结构模式,考虑分组方式实体类用户界面类控制类系统接口类……评估将分析类划分成几个候选包,并对它们的内聚性进行评估描述包之间的耦合度:包依赖关系图考勤卡系统的体系结构包图TimecardUITimecardWorkflowTimecardDomainBillingystemInterfacesubsystem3.展示技术TimecardUITimecardWorkflowTimecardDomainBillingystemInterfacesubsystemjspEntityBean(fromejb)SessionBean(fromejb)io(fromjava)4.抽取子系统TimecardUITimecardWorkflowTimecardDomainBillingystemInterfacesubsystemIBillingSystemInterfaceInterface5.针对准则和目标进行评估TimecardUITimecardWorkflowTimecardDomainBillingystemInterfacesubsystemEntityBean(fromejb)SessionBean(fromejb)io(fromjava)httpjspIBillingSytemInterfaceInterface15.2.3子系统设计子系统是一种介于包和类之间的一种设计机制,它实现一个或多个接口所定义的行为具有包的语义:能够包含其它模型元素具有类的语义:具有行为表示方式InterfacesubsystemInterfacesubsystem15.2.3子系统设计完全封装了行为利用清晰的接口代表所拥有的能力可以定义不同的实现子系统VS.包ClientClassSubsystemAsubsystemPackageBClassB1ClassB2子系统:提供行为完全封装实现细节容易替换包:不提供行为不完全封装实现细节难以替换关键在于封装15.2.3子系统设计子系统的作用子系统可以将系统划分成独立的部分,以利于:–排序、配置、分发–开发,只要保持接口不变–部署到不同分布的节点上–变更,而不影响到其它系统在设计阶段,子系统还可用于打包遗留系统子系统代表了粗粒度的组件15.2.3子系统设计子系统的设计原则目标–松散耦合–可替换的,plug-and-play–隔离变更–自身可独立的改进好的建议–不要暴露细节,只有接口–仅依赖于接口AsubsystemBsubsystemCsubsystem15.2.3子系统设计子系统的设计步骤将子系统的行为分发到各个子系统元素中:分发子系统的职责描述子系统中的元素描述子系统的依赖关系接口设计–接口说明了一组操作,隐藏子系统的实现细节15.2.3子系统设计在GoF的23种设计模式中,Façade模式是一种很好的接口的设计模式确定系统的内聚部分将这些打包到一个subsystem为该子系统设计接口考勤卡系统中的子系统设计TimecardUITimecardWorkflowTimecardDomainBillingystemInterfacesubsystemEntityBean(fromejb)SessionBean(fromejb)io(fromjava)httpjspIBillingSytemInterfaceInterface利用子系统来打包遗留系统15.3用例设计Use-CaseModelUseCase(fromUseCaseView)Use-CaseRealizationDesignModel----------------------------------------------------------------------------------------------------------------:::
本文标题:第15讲 面向对象设计
链接地址:https://www.777doc.com/doc-4020818 .html