UML及软件建模.pptVIP

UML及软件建模 第十三章 在建模过程中运用UML 3、软件开发过程 因为我们的软件建模就是在软件开发的过程中完成的， 这一节将讲解软件开发过程，以及如何软件开发的过程中完 成软件建模。 这一节还要谈论为什么要使用UML以及什么时候使用 UML才是最好的。 3.1.1、过程的一般定义 煮蛋的启示 软件过程是将用户的需求转化成有效的软件解决方案的一 系列活动。 许多软件组织无法正确定义和控制这一过程，但这恰恰是 组织改进的关键。 过程的好坏由结果状态与预期状态的差异决定，也就是目 标成果质量的好坏。 规程（Procedure）是人们对客观事物运动规律的理解和 掌握，是规范了的过程。 软件过程是为了获得高质量软件产品所需要完成的一系列 任务的框架，它规定了完成各项任务的工作步骤。 软件过程必须科学、合理，才能开发出高质量 的软件产品。 现在的软件生命周期过程包括： 早期： 立项、需求分析、设计、编码、 测试、交付、维护、退役 又加入了： 管理各种活动、质量保证 环境基础设施配置、文档管理等。 瀑布模型（Waterfall） 原型模型（Prototype） 增量模型（Incremental） 螺旋模型（Spiral） 迭代模型（Iterative） （1）瀑布模型(线性顺序模型) 瀑布式模型包含以下活动： 软件需求分析 设计 代码生成 测试 维护 （1-1）瀑布模型 — 传统的瀑布模型 传统的瀑布模型存在的问题 Tom Gilb：　 “假如你不积极地解决你项目中存在的风险，它们就会积极地解决掉你” 瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时 已无济于事。 （1－2）瀑布模型 — 实际的瀑布模型 瀑布模型的特点 文档驱动的模型 阶段间具有顺序性和依赖性 推迟实现的观点 质量保证的观点 瀑布模型的问题 实际项目很少按照该模型给出的顺序进行 用户常常难以清楚地给出所有需求 用户必须有耐心 开发者常常被不必要地耽搁 （2）原型模型 快速建立起来的可以在计算机上运行的程序，他所能完成 的功能往往是最终产品能完成的功能的一个子集。 原型模型的适用情况 用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求； 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式； …… 原型模型可能是最好的选择 原型模型从需求收集开始。 开发者和用户在一起定义软 件的总体目标，标识出已知的需求，并规划出进一步定义的 区域。 然后是“快速设计”，快速设计集中于软件那些对用户可见 部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步细化待开发软件的需求，逐步 调整原型使其满足客户的要求。同时开发者对将要做的事情 有更好的理解， 这个过程是迭代的。 原型模型 原型模型的存在的问题 用户似乎看到的是软件的工作版本，其实…… 开发者常常需要实现上的折衷，以使原型能够尽快工作 （3-1）增量模型 （3－2）增量模型 增量模型融合了瀑布模型的基本成分和原型的迭代特性。 例如，使用增量模型开发字处理软件 基本的文件管理、编辑和文档生成功能。 更完善的编辑和文档生成能力。 实现拼写和文法检查功能。 完成高级的页面布局功能。 第一个增量往往是核心产品 每一个增量均发布一个可操作产品 早期的增量是最终产品的“可拆卸”版本 （4）螺旋模型 基本思想 使用原型及其他方法来尽量降低风险。 (4-1)螺旋模型-简化 (4-2)螺旋模型完整 优点 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标； 减少了过多测试或测试不足； 维护和开发之间并没有本质区别。 特点 风险驱动的 主要适用于内部开发的大规模软件项目 （5）迭代模型　 建立在Barry Boehm 的螺旋模型基础上的。 (5-1)迭代模型 (5-2)迭代模型 特点　 这种方法可以在生命周期早期强制性的确定项目中存在的风险。 这种方法是一个连续地发现、创造和实现的过程。 在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动项目制品的生产和制作。 提供解决方案： 在生命周期的早期，这种方法可以及时地发现一些严重的需求理解错误，此时还可能修正这些错误。 允许并鼓励用户反馈信息，以明确系统的真实需求。 这种方法使开发小组重视项目中最关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。 不断地迭代测试能够给出项目状况的客观评价。 3.4、软件的价值 动力源泉，世界不可或缺的一部分 3.5.1、软件开发问题的症状 对于最终用户的需要理解得不够精确 对需求的改变束手无策 程序块不兼容 软件不易维护或不易扩展 对项