面向对象的分析和设计

第一章面向对象的分析和设计暨南大学计算机系黄战前言在很多学科中，人们早就认识到模式在构造复杂系统时的重要性。软件设计模式可以帮助开发人员描述设计片断、重要设计思想、使用其他人的专业经验。模式给出了抽象的探索式过程的名称和形式，以及面向对象技术的规则和最佳实践。明智的工程师是不会完全从头开始工作的，而是查询可以使用的模式。统一建模语言（UML)已经成为被用户广泛接受的描述软件设计蓝图的语言。UML是用来传递设计理念的可视化语言。本书的重点讲述开发者如何真正地应用常用地UML元素而不是讲述UML的特征。本章目标目标和范围OOA/D的定义OOA/D的一个简单例子UML和可视化敏捷建模历史目标和范围开发OOA/D的核心技能掌握这些技能是基本要求对于创建：设计良好健壮性可维护的软件使用面向对象技术和语言如Java目标和范围“拥有一把锤子未必能成为建筑师“需要了解“对象”思想应用统一建模语言（UML)和模式基本原理的掌握。分配职责给对象。常用的UML表示法。常见的设计模式。框架设计和架构分析目标和范围UMLvs.对象思想标准图形表示法不是OOA/D也不是方法没有面向对象设计UML是没有意义的在OOA/D中应用UML目标和范围OOD：原则和模式如何为对象类分配职责？对象之间应该如何协作？什么样的类应该做什么样的事情？OO设计之象征：职责驱动设计（responsibility-drivendesign)模式：某些针对设计问题的，经过反复验证的解决方案可以（和已经）被表示成为最佳实践的原则、启示。已命名问题—解决方案公式，这些公式是系统化、典范的设计原则。目标和范围案例研究用例需求分析敏捷方法到UP使用著名的统一过程的敏捷（轻量的、灵活的）方法作为迭代开发过程。面向对象分析和设计分析强调的是对问题和需求的调查研究，而不是解决方案设计强调的是满足需求的概念上的解决方案（在软件方面和硬件方面）面向对象分析和设计面向对象分析强调的是在问题领域内发现和描述对象（或概念）例如，在航班信息系统里包含飞机、航班、飞行员等概念面向对象设计强调的是定义软件对象以及它们如何协作以实现需求。例如，在航班信息系统里软件对象Plane可以有tailNumber属性和getFightHistory方法。面向对象分析和设计PlanetailNumberpublicclassPlane{privateStringtailNumber;publicListgetFlightHistory(){...}}领域概念领域概念的可视化-在面向对象编程语言中的表示UML根据OMG规格说明统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。应用UML的方式：UML作为草图非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。UML作为蓝图相对详细的设计图，用于：1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前向工程）。UML作为编程语言用UML完成软件系统可执行规格说明。UML应用UML的三种透视图概念透视图用图来描述现实世界或关注领域中的事物规格说明（软件）透视图用图来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现实现（软件）透视图用图来描述特定技术中的软件实现（例如：Java)OOA/D的历史1960s到1970s－OO编程语言（例如Simula和Smalltalk)开始崭露头角AlanKay–Smalltalk，“面向对象编程”，个人计算“1982年OOD形成－GradyBooch(也是UML创立者之一),完成第一篇论文“Object-OrientedDesign”;IvarJacobson(UML创立者之一)1988Object-OrientedSoftwareConstruction–MellorandSchlaer;“Object-OrientedAnalysis”1991–RumbaughOMT方法1994–UML=Booch+OMT(+Rationallater)三剑客=Booch+Rumbaugh+Jacobson1997–UML1.0;OMG(对象管理组织)资料MartinFowler–UMLDistilledRumbaugh–TheUnifiedModelingLanguageReferenceManual章迭代、进化和敏捷暨南大学计算机系黄战本章目标动机迭代过程敏捷过程统一过程动机:迭代和进化式瀑布生命周期在编程之前就预先完成需求和设计步骤软件项目的高失效率迭代和进化式开发及早地引入编程和测试,并重复这一循环会在还没有详细定义所有需求的情况下假设开发开始使用反馈来明确和改进演化中的规格说明依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计软件项目的较高成功率动机:统一过程(UP)软件开发过程描述了构造、部署以及维护软件的方式统一过程已经成为一种流行的构造面向对象系统的迭代软件开发过程UP实践提供了如何实施OOA/D的示范例子UP具有灵活性,可以应用于轻量级和敏捷方法,这些方法包括其他敏捷方法(诸如XP或Scrum)的实现Rational统一过程对统一过程的详细精化,并且已经被广泛采纳迭代过程迭代开发UP和大多数其他现代方法中的关键实践在这种的生命周期方法中,开发被组织成一系列固定的短期小项目,称为迭代每次迭代都产生经过测试、集成并可执行的局部系统每次迭代都具有各自的需求分析、设计、实现和测试活动迭代过程迭代和进化式(增量式)开发迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化早期迭代过程的思想是螺旋式开发和进化式开发每次迭代都产生可执行的但不完整的系统,它不是已经准备好可以交付的产品直到多次迭代(如10次或15次迭代)之后,系统才可能合格地用于产品部署迭代的输出不是实验性的或将丢弃的原型,迭代开发也不是构造原型.与之相反,其输出是最终系统的产品子集迭代项目中的变更迭代开发抱以接受变更和改写的态度,并以此为真正本质的驱动力—而不是企图全面和正确地规格化、冻结需求集(瀑布模型)UP-平衡需求和稳定性(VS反应式的特性蔓延)迭代开发的优点减少项目失败可能性,提高生产率、降低缺陷率在早期缓解高风险早期可见的进展早期反馈、用户参与和调整,会产生更接近涉众真实需求的精华系统可控复杂性一次迭代中的经验可以被系统地用于改进开发过程本身一次迭代的时间定量时间定量时长固定推延时间则违约从本次迭代中除去一些任务或需求,并将其分配在将来的迭代中瀑布生命周期瀑布顺序生命周期试图在编程之前详细定义所有或大部分需求研究表明,在20世纪60年代到70年代,瀑布方法对于大多数软件项目是拙劣的实践它与高失败率、低生产率和高缺陷率具有极大关系瀑布方法需求中45%的特性从未被使用,其早期时间表和估计与最终实际情况可相差400%为什么瀑布模型具有错误倾向假设规格说明是可预知的和稳定的,并且能够在项目开始时就正确定义典型的软件项目在需求上会经历25%的变更“新产品开发”领域-软件开发是(平均而言)变更极大且不稳定的领域反馈和改写的必要性在复杂、变更系统中,反馈和调整是成功的关键要素早期开发中的反馈来自测试中的反馈,有助于开发者精化设计或模型来自团队处理早期特性过程的中反馈,有助于精化时间表和估计来自客户和市场的反馈,有助于重新定义下一次迭代实现特性的优先级如何进行迭代和进化式分析和设计看第１８－２０页的例子一般错误认为偏激的认为“完整”的编程前分析和设计是十分有价值的风险驱动和客户驱动的迭代计划ＵＰ提倡风险驱动和客户驱动相结合的迭代计划早期的迭代目标识别和降低最高风险构造客户最关心的可视化特性风险驱动迭代开发更明确地包含了以构架为中心迭代开发的实践早期迭代致力于核心架构的构造、测试和稳定没有稳定的架构就会带来高风险敏捷开发敏捷开发方法通常应用时间定量的迭代和进化式开发使用自适应计划提倡增量交付并包含其他提倡（快速和灵活的响应变更）的价值和实践敏捷方法具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所共有的基本实践．除此之外，它们还倡导反映简易、轻量、沟通、自组织团队等更多敏捷的实践和原则敏捷方法实践范例(Scrum)公共项目工作室自组织团队ＸＰ：结队编程和测试驱动开发ＵＰ：“不管黑猫还是白猫，抓到耗子就是好猫”的态度敏捷建模建模的目的主要是为理解，而非文档敏捷建模采用敏捷方法并不意味着不进行任何建模建模和模型的目的主要用于理解和沟通不要对所有或大多数软件设计建模或应用ＵＭＬ尽可能使用最简单的工具不要单独建模，而是结队（或三个人）在白板上建模并行地创建建模“足够好”的简单表示法知道所有模型都可能不准确的开发者应该进行ＯＯ设计建模敏捷ＵＰ可以采纳和应用可适应性和轻量级的精神推荐使用ＵＰ活动和制品的简集实现前的需求和设计是不完整的以敏捷建模实践应用ＵＭＬ对于整个项目不应有详细的计划阶段计划－评估项目结束日期和主要里程碑迭代计划－详细计划是由一次次迭代的调整而完成的ＵＰ的阶段四个主要阶段初始大体上的构想、业务案例、范围和模糊评估细化已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估构造对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署移交进行beta测试ＵＰ科目科目－在一个主题域中的一组活动，例如需求分析中的活动业务建模需求设计ＵＰ实现表示编程和构建系统，而不是部署ＵＰ开发案例为项目选择实践和ＵＰ制品可以编写为简短文档，这称为开发案例第三章案例研究暨南大学计算机系黄战核心应用逻辑层逻辑核心层的ＯＯ设计对各种技术来说是相似的在应用逻辑层语境中学习到的基本ＯＯ设计技巧适用于所有其他层或够件当新框架或技术出现时，其他层的设计方法和模式呈现出快速变化的趋势案例学习策略迭代开发的策略多次迭代，第一次迭代用于一些核心功能例子ＰＯＳＭonopoly游戏系统