软件开发的OOP实践指南.doc

软件开发的OOP实践指南 [第二版] czw 2007-2-12 第1章 需求分析：追求完美与容忍缺陷 ·指导软件分析和设计的基本思路 当项目组面临两难选择时，首先要用鱼和熊掌来识别矛盾的两个对立面。项目组用“小鱼”来比喻那些开发和维护代价较小、结构较简单但是缺乏某些灵活性的设计方案；用“熊掌”来比喻那些灵活、易扩展，但结构复杂，开发和维护成本较高的设计方案。在最终进行抉择的时候，项目组必须坚持如下准则：在满足需求的情况下，尽量选择“小鱼”而舍弃“熊掌”；只有存在无庸置疑的理由时，才选择“熊掌”作为设计方案。 ·需求分析的基本概念与思想 1.什么是需求（Requirement） IEEE在其发布的《软件工程标准词汇表》中，将需求定义为 [IEEE, 1990] ： ①用户解决问题或达到目标所需的条件或能力 ②系统或组件为满足合同、标准、规范或其他正式规定文档所需具有的条件或能力 ③一种反映上述两种条件或能力的文档描述 2.软件需求——功能性需求和非功能性需求 IEEE将两者分别定义为 [Thayer, 1990] ： ★功能性需求：一个系统、软件或组件所必须完成的功能，它定义了系统的行为 ★非功能性需求：描述软件如何完成这些功能（难测试，只进行主观评估） 3.项目干系人（Stakeholder） 敏捷建模理论创始人Scott W. Ambler将其定义为 [Ambler, 2003] ： 和项目有直接利益关系的人，包括“直接用户，间接用户，用户经理，高级经理，运营人员，客户支持人员和项目有集成或交互的其他项目开发人员，受软件产品的开发、发布的潜在影响的维护人员等”。 4.需求分析——“知道要做什么” ★确定项目的目标和范围 ★根据项目的目标和范围分析出所有的项目干系人 ★提取出所有的非功能性要求 ★分析出所有的功能性要求（一般采用用例分析方法进行） ★撰写出项目的《需求说明书》 5.基本原则——“只实现你真正需要的东西” 极限编程（Extreme Programming）理论中有一个基本原则[Kibitz, 1999] ： “只实现你真正需要的东西，不要去实现你认为需要的东西。” 6.挖掘需求——“利用具体的软件原型” 在具体的软件原型面前，用户可根据自己的想法指出需要改进或需要添加的内容。 这种采用简单的原型替代具体项目的做法利于将复杂问题简单化，是迭代开发过程（增加反馈环节）所推崇的有效的手段。 7. 撰写需求说明书 文档名称 XXX需求说明书 密级 内部 文档编号 Xxxx 编写人 小W 编写日期 2003-11-11 版本号 0.1 审核人 审核日期 总页数 批准人 批准日期 版本修订记录 编号 日期 版本 修订人 修订内容 项目名称 XXX 项目描述 用户简介 功能性需求 用例 系统的局限性 非功能性要求 值得注意的是： ★选择简约方案并容忍一定的缺陷是最明智的做法。 ★需求分析过程中，有效的交流与沟通最为重要。 ★应对项目过程中的需求分析的变化做好充分准备。 第2章 用例分析：海底总动员与云中漫步 ·为什么使用UML 用例分析和用例建模是了解用户行为、细化软件需求的关键工作阶段，在用例建模时首选的辅助设计工具是UML语言。简单地说，UML的主要价值在于，它为我们使用面向对象概念进行可视化设计提供了一套丰富的表达和符号描述。 需要注意的是，UML只是一种描述语言，其作用只在于忠实地记录和表述程序员的分析结果和设计思想。UML无法告诉开发人员如何进行面向对象分析与设计，也无法提供任何有关设计原则和设计技巧指南；其次，UML本身并无定义一个标准的开发过程，它不关心程序员使用何种开发模型和设计流程，事实上，UML就像是一种程序员使用的世界语，能有效的促进开发人员间的交流和沟通。总之，UML只是开发人员在设计过程中表达思想、进行交流和沟通的一种工具，使用时应该“点到为止”。 ·用例模型 1.什么是用例模型 在UML中，用例模型是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（Actor，可能是最终用户，也可能是外围系统）与系统间的交互关系描述了系统对外提供的功能特性——这种参与者与系统功能特性之间的交互关系就是我们所说的“用例（Use Case）”。 2.用例的三要素： ★用例是由系统的最终用户或外部环境发起的，用例的发起者被称为参与者。 ★每个用例只描述单独的任务，且所描述的任务必须是符合用户意图的、完整的工作内容。 ★用例必须产生一个对用户有意义的结果。 3.场景 用例的一个执行实例，是用例执行过程中的一条路径。一个用例可能会包括多个场景，如成功的场景，失败的场景等。 4.用例模型的应用价值 ★是一种标准