UML软件开发过程.docVIP

第3章 软件开发过程 如在第一章所讨论的，每种软件开发方法学都包括两个主要构成部分，即软件开发活动实施过程的描述和对该过程的结果进行文档化的表示法。并且强调了UML是一种语言而不是方法学，也不是为支持任何特殊过程而专门设计的。UML定义的图和表示法可以成功地用于各式各样的不同过程。 本章描述有关软件开发过程的一些思想的发展，从第一个广为人知的过程模型开始，以对统一过程的简要描述结束。尽管几乎可以肯定地说，统一过程不是过程建模的最终结论，但是将统一过程和UML结合起来考虑很有意义，因为二者是由同一组研究人员开发的。本章将以讨论统一过程所强调的不同UML图之间的逻辑关系而结束。 3.1 瀑布模型 定义一个软件开发过程的早期尝试，主要是以从其他工程学科获得的思想为基础，把这些思想应用于这个新的领域。关键的思想是标识在生产软件中涉及的不同的活动，例如设计、编码和测试，并定义应当以怎样的次序实施这些活动。这导致了过程模型的产生，例如经典的“瀑布”模型，见图3.1。 图3.1瀑布模型（Royce,1970） 虽然这些阶段的确切数目和命名在瀑布模型的不同版本中不尽相同，但是在所有版本中，这个过程总是系统地从高层开始，说明性地描述系统应当做什么，经由详细描述，最终是用代码详细描述系统将如何做，最后，以系统部署和后续运行所涉及的活动的一些阶段的描述而结束。 因此，大多数瀑布模型提供的是软件系统的整个生命周期的一个模型，而不仅仅是软件系统的开发模型。但是，系统的开发构成了模型的很大一部分，无疑地，也是在软件工程文献中受到最多注意的部分。 瀑布模型中的每个阶段定义一个各自独立的活动。瀑布中连续的阶段通过箭头连接，向下的箭头表示阶段的时间次序。因此，模型的基本结构暗示了不同的阶段是依顺序进行的。所设想的过程并不是像建造一所房子那样，电工、水工、屋顶工等等可能同时工作，而是更像一条生产线，比如，分析人员完成他们的工作，接着将产品移交给设计人员进行下一个阶段的工作。这个模型中隐含的是，期望每个阶段完成的工作都以某种方式形成文档，而且该文档将被传递下去，并成为下一阶段要做的工作的基础。 因此，瀑布模型提出了软件开发的一种理想化的构想，项目将从文档化需求开始，经历分析和设计活动，接着是编码和测试系统。在部署之后，只要它还在使用，系统将被维护。这种经过这些阶段的工作流是将这类模型命名为“瀑布”的缘由。 当然，实际上，以这样一种没有疑问的方式开发的项目很少。更典型地是，一个阶段中的工作将暴露前面阶段所做的工作中的问题、错误和遗漏。显然，在继续之前纠正问题是明智的，而不是在有错误的工作的基础上前进。图中向上的箭头表示了这种反馈过程，由此在一个阶段做的工作可能引起前面阶段的修改和返工。 在图3.1中没有明确这种反馈是否可以往回延伸越过多个阶段。瀑布模型的一些最初的版本限制只能反馈到过程中的前一个阶段。尽管从管理的角度这显得很有吸引力，但是看来这可能像是一个相当武断的限制。例如，如果编码暴露了该系统设计中的重大问题，完全可以想象的是这些问题本身可能严重到了需要改变分析阶段所作的工作。如果说事实上问题是在编码阶段碰巧发现的，而不是在设计审查阶段，这似乎并不是拒绝考虑对分析进行必要修改的非常有说服力的理由。 总之，瀑布模型代表了一种直观的、切合实际的、通用的工程方法在软件工程中的应用。它强调在执行活动之前先进行设计的重要性，并因此提供了一种有价值的平衡，平衡软件开发中对总体体系结构或程序结构不作任何考虑就开始编码的普遍倾向。与此相关，它建议一种自顶向下的方法，由此一个系统最初在一个高的抽象层次上描述，随着开发的继续增加更多的细节。最后，至少在理论上，它提供了控制软件过程的一种有力的管理工具：使用该模型，能够给予项目一个清晰的结构，在每个阶段的最后有一个里程碑，标志着该阶段的完整文档的产生并为下一阶段做好了准备。 然而，实际上，瀑布模型的应用并没有真正做到它所承诺的那样，提供一种组织软件项目的方法，使得项目将会是可控制的，按时产生在预算内交付功能正确的系统。造成这种失败的两个主要原因是，该模型对项目中涉及的风险的管理的方式和模型中对系统需求的处理。 3.1.1瀑布模型中的风险管理 与瀑布模型建议的相反，在软件开发中，尤其是新系统或者复杂系统的开发中，存在着高度不可预知的活动。有许多软件项目失败或取消，是因为含有需要花很大代价去更正的错误或者由于性能问题而使系统不能使用，或者很简单只是因为它们不能可靠地工作。任何开发过程的一个主要目标是，寻找方法，使导致项目以彻底失败告终的风险最小化。 尽管已经有很多相关工作是关于开发可证明正确的软件的技术，但在任何软件开发过程中，测试仍然是极其重要的部分。虽然远不够完美，但是，保证在合理的时间内程序做的是假定要做的事情，测试是