面向对象的分析和设计精选文档.ppt

《面向对象的分析和设计精选文档.ppt》由会员分享，可在线阅读，更多相关《面向对象的分析和设计精选文档.ppt（38页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、面向对象的分析和设计本讲稿第一页，共三十八页前言n在很多学科中，人们早就认识到模式在构造复杂系统时的重要性。n软件设计模式可以帮助开发人员描述设计片断、重要设计思想、使用其他人的专业经验。n模式给出了抽象的探索式过程的名称和形式，以及面向对象技术的规则和最佳实践。n明智的工程师是不会完全从头开始工作的，而是查询可以使用的模式。n统一建模语言（UML)已经成为被用户广泛接受的描述软件设计蓝图的语言。nUML是用来传递设计理念的可视化语言。本书的重点讲述开发者如何真正地应用常用地UML元素而不是讲述UML的特征。本讲稿第二页，共三十八页本章目标n目标和范围nOOA/D 的定义nOOA/D 的一个简

2、单例子nUML和可视化敏捷建模n历史本讲稿第三页，共三十八页目标和范围n开发OOA/D的核心技能掌握这些技能是基本要求对于创建：q 设计良好q 健壮性q 可维护的软件q 使用面向对象技术和语言如Java本讲稿第四页，共三十八页目标和范围 “拥有一把锤子未必能成为建筑师“n需要了解“对象对象”思想n应用统一建模语言（UML)和模式q 基本原理的掌握 。分配职责给对象 。常用的UML表示法 。常见的设计模式 。框架设计和架构分析本讲稿第五页，共三十八页目标和范围nUML vs.对象思想q 标准图形表示法q 不是OOA/D也不是方法q 没有面向对象设计UML是没有意义的q 在OOA/D中应用UML本

3、讲稿第六页，共三十八页目标和范围nOOD：原则和模式q 如何为对象类分配职责？q 对象之间应该如何协作？q 什么样的类应该做什么样的事情？q OO设计之象征：n 职责驱动设计（responsibility-driven design)q 模式：n某些针对设计问题的，经过反复验证的解决方案可以（和已经）被 表示成为最佳实践的原则、启示。n 已命名问题解决方案公式，这些公式是系统化、典范的设计原则。本讲稿第七页，共三十八页目标和范围n案例研究n用例q 需求分析n敏捷方法到UPq 使用著名的统一过程的敏捷（轻量的、灵活的）方法作为迭代开发过程。本讲稿第八页，共三十八页面向对象分析和设计n分析q强调的

4、是对问题和需求的调查研究，而不是解决方案n设计 q强调的是满足需求的概念上的解决方案（在软件方面和硬件方面）本讲稿第九页，共三十八页面向对象分析和设计n面向对象分析q强调的是在问题领域内发现和描述对象（或概念）q例如，在航班信息系统里包含飞机、航班、飞行员等概念n面向对象设计q强调的是定义软件对象以及它们如何协作以实现需求。q例如，在航班信息系统里软件对象Plane可以有tailNumber属性和getFightHistory方法。本讲稿第十页，共三十八页面向对象分析和设计PlanetailNumberpublic class Planeprivate String tailNumber;pu

5、blic List getFlightHistory().领域概念领域概念的可视化-在面向对象编程语言中的表示 本讲稿第十一页，共三十八页UMLn根据OMG规格说明q 统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。q www.omg.orgq www.uml.org本讲稿第十二页，共三十八页UMLn应用UML的方式：q UML作为草图n非正式的、不完整的图，借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。q UML作为蓝图n 相对详细的设计图，用于：1）逆向工程，即以UML图的 方式对现有代码进行可视化，使其易于理解。2）代码生成（前向工程）。q UML作为编程语

6、言n用UML完成软件系统可执行规格说明。本讲稿第十三页，共三十八页UMLn应用UML的三种透视图q 概念透视图n 用图来描述现实世界或关注领域中的事物q 规格说明（软件）透视图n用图来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现q 实现（软件）透视图n 用图来描述特定技术中的软件实现（例如：Java)本讲稿第十四页，共三十八页OOA/D的历史n1960s到1970sOO编程语言（例如Simula和Smalltalk)开始崭露头角nAlan Kay Smalltalk，“面向对象编程”，个人计算“n1982年OOD形成Grady Booch(也是UML创立者之一),完成第一篇

7、论文“Object-Oriented Design”;Ivar Jacobson(UML 创立者之一)n1988 Object-Oriented Software Construction Mellornand Schlaer;“Object-Oriented Analysis”n1991 Rumbaugh OMT 方法n1994 UML=Booch+OMT(+Rational later)n三剑客=Booch+Rumbaugh+Jacobsonn1997 UML 1.0;OMG(对象管理组织)本讲稿第十五页，共三十八页资料nMartin Fowler UML DistillednRumbau

8、gh The Unified Modeling Language Reference Mnwww.cetus-本讲稿第十六页，共三十八页第2章 迭代、进化和敏捷 暨南大学计算机系 黄战本讲稿第十七页，共三十八页本章目标n动机n迭代过程n敏捷过程n统一过程本讲稿第十八页，共三十八页动机:迭代和进化式n瀑布生命周期q 在编程之前就预先完成需求和设计步骤q 软件项目的高失效率n迭代和进化式开发q及早地引入编程和测试,并重复这一循环q会在还没有详细定义所有需求的情况下假设开发开始q使用反馈来明确和改进演化中的规格说明q依赖于短时快速的开发步骤、反馈和改写来不断明确需 求和设计q软件项目的较高成功率本讲

9、稿第十九页，共三十八页动机:统一过程(UP)n软件开发过程q描述了构造、部署以及维护软件的方式n统一过程q已经成为一种流行的构造面向对象系统的 迭代软件开发过程q UP实践提供了如何实施OOA/D的示范例子q UP具有灵活性,可以应用于轻量级和敏捷方法,这些方法包括其他敏捷方法(诸如XP或Scrum)的实现nRational统一过程q对统一过程的详细精化,并且已经被广泛采纳 本讲稿第二十页，共三十八页迭代过程n迭代开发qUP和大多数其他现代方法中的关键实践q在这种的生命周期方法中,开发被组织成一 系列固定的短期小项目,称为迭代q每次迭代都产生经过测试、集成并可执行的局部系统q 每次迭代都具有各

10、自的需求分析、设计、实现和测试活动本讲稿第二十一页，共三十八页迭代过程n迭代和进化式(增量式)开发q迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化q早期迭代过程的思想是螺旋式开发和进化式开发q每次迭代都产生可执行的但不完整的系统,它不是已经准备好可以交付的产品q直到多次迭代(如10次或15次迭代)之后,系统才可能合格地用于产品部署q迭代的输出不是实验性的或将丢弃的原型,迭代开发也不是构造原型.与之相反,其输出是最终系统的产品子集本讲稿第二十二页，共三十八页迭代项目中的变更n迭代开发抱以接受变更和改写的态度,并以此为真正本质的驱动力而不是企图全面和正确地规格化、冻结需求集(瀑布模型)nU

11、P-平衡需求和稳定性(VS反应式的特性蔓延)本讲稿第二十三页，共三十八页迭代开发的优点n减少项目失败可能性,提高生产率、降低缺陷率n在早期缓解高风险n早期可见的进展n早期反馈、用户参与和调整,会产生更接近涉众真实需求的精华系统n可控复杂性n一次迭代中的经验可以被系统地用于改进开发过程本身本讲稿第二十四页，共三十八页一次迭代的时间定量n时间定量q时长固定q推延时间则违约q从本次迭代中除去一些任务或需求,并将其分配在将来的迭代中本讲稿第二十五页，共三十八页瀑布生命周期n瀑布q 顺序生命周期q试图在编程之前详细定义所有或大部分需求q研究表明,在20世纪60年代到70年代,瀑布方法对于大多数软件项目是

12、拙劣的实践q它与高失败率、低生产率和高缺陷率具有极大关系q瀑布方法需求中45%的特性从未被使用,其早期时间表和估计与最终实际情况可相差400%本讲稿第二十六页，共三十八页为什么瀑布模型具有错误倾向n假设规格说明是可预知的和稳定的,并且能够在项目开始时就正确定义n典型的软件项目在需求上会经历25%的变更n“新产品开发”领域-软件开发是(平均而言)变更极大且不稳定的领域本讲稿第二十七页，共三十八页反馈和改写的必要性n在复杂、变更系统中,反馈和调整是成功的关键要素q早期开发中的反馈q来自测试中的反馈,有助于开发者精化设计或模型q来自团队处理早期特性过程的中反馈,有助于精化时间表和估计q来自客户和市场

13、的反馈,有助于重新定义下一次迭代实现特性的优先级本讲稿第二十八页，共三十八页如何进行迭代和进化式分析和设计n看第页的例子n一般错误认为q偏激的认为“完整”的编程前分析和设计是十分有价值的本讲稿第二十九页，共三十八页风险驱动和客户驱动的迭代计划n提倡风险驱动和客户驱动相结合的迭代计划n早期的迭代目标q识别和降低最高风险q构造客户最关心的可视化特性n风险驱动迭代开发更明确地包含了以构架为中心迭代开发的实践q早期迭代致力于核心架构的构造、测试和稳定q没有稳定的架构就会带来高风险本讲稿第三十页，共三十八页敏捷开发n敏捷开发方法q通常应用时间定量的迭代和进化式开发q使用自适应计划q提倡增量交付q并包含其

14、他提倡（快速和灵活的响应变更）的价值和实践n敏捷方法具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所共有的基本实践除此之外，它们还倡导反映简易、轻量、沟通、自组织团队等更多敏捷的实践和原则本讲稿第三十一页，共三十八页敏捷方法n实践范例(Scrum)q 公共项目工作室q自组织团队q：结队编程和测试驱动开发：“不管黑猫还是白猫，抓到耗子就是好猫”的态度本讲稿第三十二页，共三十八页敏捷建模n建模的目的主要是为理解，而非文档n敏捷建模q采用敏捷方法并不意味着不进行任何建模q建模和模型的目的主要用于理解和沟通q不要对所有或大多数软件设计建模或应用q尽可能使用最简单的工具q不要单独建模，而是结

15、队（或三个人）在白板上建模q并行地创建建模q“足够好”的简单表示法q知道所有模型都可能不准确的q开发者应该进行设计建模本讲稿第三十三页，共三十八页敏捷n可以采纳和应用可适应性和轻量级的精神q推荐使用活动和制品的简集q实现前的需求和设计是不完整的q以敏捷建模实践应用q对于整个项目不应有详细的计划q阶段计划评估项目结束日期和主要里程碑q迭代计划详细计划是由一次次迭代的调整而完成的本讲稿第三十四页，共三十八页的阶段n四个主要阶段q初始n大体上的构想、业务案例、范围和模糊评估q细化n已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估q构造n对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署q移交n进行beta测试本讲稿第三十五页，共三十八页科目n科目在一个主题域中的一组活动，例如需求分析中的活动q业务建模q需求q设计n实现表示编程和构建系统，而不是部署本讲稿第三十六页，共三十八页开发案例n为项目选择实践和制品可以编写为简短文档，这称为开发案例本讲稿第三十七页，共三十八页案例学习策略n迭代开发的策略n多次迭代，第一次迭代用于一些核心功能n例子qqonopoly 游戏系统本讲稿第三十八页，共三十八页