面向对象的分析和设计

面向对象的分析和设计第1页，课件共38页，创作于2023年2月前言在很多学科中，人们早就认识到模式在构造复杂系统时的重要性。软件设计模式可以帮助开发人员描述设计片断、重要设计思想、使用其他人的专业经验。模式给出了抽象的探索式过程的名称和形式，以及面向对象技术的规则和最佳实践。明智的工程师是不会完全从头开始工作的，而是查询可以使用的模式。统一建模语言（UML)已经成为被用户广泛接受的描述软件设计蓝图的语言。UML是用来传递设计理念的可视化语言。本书的重点讲述开发者如何真正地应用常用地UML元素而不是讲述UML的特征。第2页，课件共38页，创作于2023年2月本章目标目标和范围OOA/D的定义OOA/D的一个简单例子UML和可视化敏捷建模历史第3页，课件共38页，创作于2023年2月目标和范围开发OOA/D的核心技能掌握这些技能是基本要求对于创建：设计良好健壮性可维护的软件使用面向对象技术和语言如Java第4页，课件共38页，创作于2023年2月目标和范围

“拥有一把锤子未必能成为建筑师“需要了解“对象”思想应用统一建模语言（UML)和模式基本原理的掌握

。分配职责给对象。常用的UML表示法。常见的设计模式。框架设计和架构分析第5页，课件共38页，创作于2023年2月目标和范围UMLvs.对象思想标准图形表示法不是OOA/D也不是方法没有面向对象设计UML是没有意义的在OOA/D中应用UML第6页，课件共38页，创作于2023年2月目标和范围OOD：原则和模式如何为对象类分配职责？对象之间应该如何协作？什么样的类应该做什么样的事情？

OO设计之象征：职责驱动设计（responsibility-drivendesign)

模式：某些针对设计问题的，经过反复验证的解决方案可以（和已经）被表示成为最佳实践的原则、启示。已命名问题—解决方案公式，这些公式是系统化、典范的设计原则。

第7页，课件共38页，创作于2023年2月目标和范围案例研究用例

需求分析敏捷方法到UP

使用著名的统一过程的敏捷（轻量的、灵活的）方法作为迭代开发过程。

第8页，课件共38页，创作于2023年2月面向对象分析和设计分析强调的是对问题和需求的调查研究，而不是解决方案设计强调的是满足需求的概念上的解决方案（在软件方面和硬件方面）第9页，课件共38页，创作于2023年2月面向对象分析和设计面向对象分析强调的是在问题领域内发现和描述对象（或概念）例如，在航班信息系统里包含飞机、航班、飞行员等概念面向对象设计强调的是定义软件对象以及它们如何协作以实现需求。例如，在航班信息系统里软件对象Plane可以有tailNumber属性和getFightHistory方法。第10页，课件共38页，创作于2023年2月面向对象分析和设计PlanetailNumberpublicclassPlane{privateStringtailNumber;publicListgetFlightHistory(){...}}领域概念领域概念的可视化-在面向对象编程语言中的表示第11页，课件共38页，创作于2023年2月UML根据OMG规格说明统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

第12页，课件共38页，创作于2023年2月UML应用UML的方式：

UML作为草图非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。

UML作为蓝图相对详细的设计图，用于：1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前向工程）。

UML作为编程语言用UML完成软件系统可执行规格说明。第13页，课件共38页，创作于2023年2月UML应用UML的三种透视图

概念透视图用图来描述现实世界或关注领域中的事物规格说明（软件）透视图用图来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现

实现（软件）透视图用图来描述特定技术中的软件实现（例如：Java)第14页，课件共38页，创作于2023年2月OOA/D的历史1960s到1970s－OO编程语言（例如Simula和Smalltalk)开始崭露头角AlanKay–Smalltalk，“面向对象编程”，个人计算“1982年OOD形成－GradyBooch(也是UML创立者之一),完成第一篇论文“Object-OrientedDesign”;IvarJacobson(UML创立者之一)1988Object-OrientedSoftwareConstruction–MellorandSchlaer;“Object-OrientedAnalysis”1991–RumbaughOMT方法1994–UML=Booch+OMT(+Rationallater)三剑客=Booch+Rumbaugh+Jacobson1997–UML1.0;OMG(对象管理组织)第15页，课件共38页，创作于2023年2月资料MartinFowler–UMLDistilledRumbaugh–TheUnifiedModelingLanguageReferenceManual第16页，课件共38页，创作于2023年2月第2章迭代、进化和敏捷暨南大学计算机系黄战第17页，课件共38页，创作于2023年2月本章目标动机 迭代过程敏捷过程统一过程第18页，课件共38页，创作于2023年2月动机:迭代和进化式瀑布生命周期在编程之前就预先完成需求和设计步骤软件项目的高失效率迭代和进化式开发及早地引入编程和测试,并重复这一循环会在还没有详细定义所有需求的情况下假设开发开始使用反馈来明确和改进演化中的规格说明依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计软件项目的较高成功率第19页，课件共38页，创作于2023年2月动机:统一过程(UP)软件开发过程描述了构造、部署以及维护软件的方式统一过程已经成为一种流行的构造面向对象系统的迭代软件开发过程

UP实践提供了如何实施OOA/D的示范例子

UP具有灵活性,可以应用于轻量级和敏捷方法,这些方法包括其他敏捷方法(诸如XP或Scrum)的实现Rational统一过程对统一过程的详细精化,并且已经被广泛采纳

第20页，课件共38页，创作于2023年2月迭代过程迭代开发UP和大多数其他现代方法中的关键实践在这种的生命周期方法中,开发被组织成一系列固定的短期小项目,称为迭代每次迭代都产生经过测试、集成并可执行的局部系统每次迭代都具有各自的需求分析、设计、实现和测试活动第21页，课件共38页，创作于2023年2月迭代过程迭代和进化式(增量式)开发迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化早期迭代过程的思想是螺旋式开发和进化式开发每次迭代都产生可执行的但不完整的系统,它不是已经准备好可以交付的产品直到多次迭代(如10次或15次迭代)之后,系统才可能合格地用于产品部署迭代的输出不是实验性的或将丢弃的原型,迭代开发也不是构造原型.与之相反,其输出是最终系统的产品子集第22页，课件共38页，创作于2023年2月迭代项目中的变更迭代开发抱以接受变更和改写的态度,并以此为真正本质的驱动力—而不是企图全面和正确地规格化、冻结需求集(瀑布模型)UP-平衡需求和稳定性(VS反应式的特性蔓延)第23页，课件共38页，创作于2023年2月迭代开发的优点减少项目失败可能性,提高生产率、降低缺陷率在早期缓解高风险早期可见的进展早期反馈、用户参与和调整,会产生更接近涉众真实需求的精华系统可控复杂性一次迭代中的经验可以被系统地用于改进开发过程本身第24页，课件共38页，创作于2023年2月一次迭代的时间定量时间定量时长固定推延时间则违约从本次迭代中除去一些任务或需求,并将其分配在将来的迭代中第25页，课件共38页，创作于2023年2月瀑布生命周期瀑布顺序生命周期试图在编程之前详细定义所有或大部分需求研究表明,在20世纪60年代到70年代,瀑布方法对于大多数软件项目是拙劣的实践它与高失败率、低生产率和高缺陷率具有极大关系瀑布方法需求中45%的特性从未被使用,其早期时间表和估计与最终实际情况可相差400%第26页，课件共38页，创作于2023年2月为什么瀑布模型具有错误倾向假设规格说明是可预知的和稳定的,并且能够在项目开始时就正确定义典型的软件项目在需求上会经历25%的变更“新产品开发”领域-软件开发是(平均而言)变更极大且不稳定的领域第27页，课件共38页，创作于2023年2月反馈和改写的必要性在复杂、变更系统中,反馈和调整是成功的关键要素早期开发中的反馈来自测试中的反馈,有助于开发者精化设计或模型来自团队处理早期特性过程的中反馈,有助于精化时间表和估计来自客户和市场的反馈,有助于重新定义下一次迭代实现特性的优先级第28页，课件共38页，创作于2023年2月如何进行迭代和进化式分析和设计看第１８－２０页的例子一般错误认为偏激的认为“完整”的编程前分析和设计是十分有价值的第29页，课件共38页，创作于2023年2月风险驱动和客户驱动的迭代计划ＵＰ提倡风险驱动和客户驱动相结合的迭代计划早期的迭代目标识别和降低最高风险构造客户最关心的可视化特性风险驱动迭代开发更明确地包含了以构架为中心迭代开发的实践早期迭代致力于核心架构的构造、测试和稳定没有稳定的架构就会带来高风险

第30页，课件共38页，创作于2023年2月敏捷开发敏捷开发方法通常应用时间定量的迭代和进化式开发使用自适应计划提倡增量交付并包含其他提倡（快速和灵活的响应变更）的价值和实践敏捷方法具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所共有的基本实践．除此之外，它们还倡导反映简易、轻量、沟通、自组织团队等更多敏捷的实践和原则第31页，课件共38页，创作于2023年2月敏捷方法实践范例(Scrum)

公共项目工作室自组织团队ＸＰ：结队编程和测试驱动开发ＵＰ：“不管黑猫还是白猫，抓到耗子就是好猫”的态度第32页，课件共38页，创作于2023年2月敏捷建模建模的目的主要是为理解，而非文档敏捷建模采用敏捷方法并不意味着不进行任何建模建模和模型的目的主要用于理解和沟通不要对所有或大多数软件设计建模或应用ＵＭＬ尽可能使用最简单的工具不要单独建模，而是结队（或三个人）在白板上建模并行地创建建模“足够好”的简单表示法知道所有模型都可能不准确的开发者应该进行ＯＯ设计建模第33页，课件共38页，创作于2023年2月敏捷ＵＰ可以采纳和应用可适应性和轻量级的精神推荐使用ＵＰ活动和制品的简集实现前的需求和设计是不完整的以敏捷建模实践应用ＵＭＬ对于整个项目不应有详细的计划阶段计划－评估项目结束日期和主要里程碑迭代计划－详细计划是由一次次迭代的调整而完成的第34页，课件共38页，创作于2023年2月ＵＰ的阶段四个主要阶段初始大体上的构想、业务案例、范围和模糊评估细化已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估构造对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署移交