软件工程——用例分析.docVIP

自从1992年 Ivar Jacobson 发表了关于如何使用用例，从系统用户的角度来提取软件需求的方法的论文之后，这种方法已经逐渐流行起来。但是有一个最常见的问题是：当我得到了用例之后，如何才能把他们用代码实现出来？本文由两部份组成，将会用一个实际的案例来说明这一点。如何从用例中提取需求，并加以分析，进一步将其转化为可以直接进行编码的格式。我希望能够把这一过程讲清楚，这样你在当前的，或是下一个软件项目中就可以使用它们了！ IBM Rational Unified Process(RUP) 提倡通过用例来提取系统中可操作的需求。 1 软件需求说明书，即 Software Requirements Specification (SRS)，包括软件的所有需求，其中包括很多相关的文档。用例就是其中的一个重要部分。 SRS主要包括以下几部分： 用例模型，包括： 用例图：可视化的描述系统用户，和系统为用户提供的服务。 角色定义：用文字描述系统功能，和系统所需的服务。 用例描述：用文字描述系统提供的主要功能。 软件补充规格文档：这个文档包括了整个系统相关的各种需求，和一些与对系统用户和用例都不直接相关的隐藏需求。 在RUP方法中，这个需求文档是后续的分析和设计工作的起点。不同的开发方式，对项目的推动力是不同的，也就会产生不同的文档。如果软件发布之后，你还总是在不停的修补缺陷，你很可能根本没有需求文档。只能从Bug报告中看出，软件已经和最开始设计的样子不一样了。如果你在维护或者改进一个软件版本（比如增加一项新功能），你可能有一两个用例，他们描述了这些新功能和用户之间如何交互，但是你不会有软件补充规格文档，因为这些功能之外的部分并没有改变。 在这里，用一个虚构的软件项目green-field 作为例子。这是一个面向对象的软件项目，使用UML来描述系统中的各种概念与关系。读者需要具有对象和类的基础知识，熟悉UML 版本1.x 或者2.0中的类图、顺序图和协作图。 用例分析活动 下面我们讨论一下RUP中的用例分析。如图1所示，将RUP中结构分析的结果整合起来。 图1： 结构分析的工作流程(early Elaboration) 显而易见，严格来说的话，软件开发过程应该侧重于企业系统级的架构设计，以及软件重用。但是基于以下三点原因，在这里我不会长篇大论的讲述结构分析： 我的目标不是结构分析设计，而是面向开发人员的更底层的日常工作。 这不是一本专著，没有那么多篇幅来讲述结构分析。 根据我多年在软件架构和软件过程方面的咨询经验来看，只有很少的软件开发组织能够很规范的进行结构分析。如果你正在从事结构分析，你一定曾经经历过本文中的一些内容。对一个新的，或是一个大型的软件项目来说，采用结构分析是明智的选择。但是如果你不太熟悉结构分析，本文的内容将会对你有所裨益。 用例分析的目的： 找出用例中的执行流程、事件的各个类。 通过实现用例，把用例的行为指定到具体的类。 找出类的责任、属性和他们相互的关系。 规范地确定系统中各用例的职责。 我们也可以认为，用例分析的目标，就是把我们对用例的理解，转变为与业务一致的形式，实现需求的价值。在用例设计的时候，我们把业务概念抽象成类、对象、关系、组件、接口等等，这些都与目标系统直接对应。 图2引自RUP分析和设计概述部分，描述了需要使用用例分析的场景，和用例分析与其它步骤之间的关系。 图2：RUP中的用例分析 在RUP [RUP2003]中的用例分析由几部分组成： 每个用例包括： 建立一个用例实现 用例的补充描述（如果需要） 从用例的行为中，找出分析类(Analysis Classe) 把行为指定到具体的分析类 对每个分析结果的类： 类的职责 类的属性和关系 定义类的属性 分析类直接的关系 分析类间事件与事件之间的相关性 整合所有的用例实现 建立跟踪机制 建立分析机制 对用例分析的结果进行评估 请注意这些步骤的次序不是一成不变的。 你实际所采用的次序取决于你对于分析的领域的理解程度、你对RUP或UML的经验、你所采用的模型、或者是你自己的确定分析类的属性的一种习惯方式。(例如，以职责为中心，以行为为中心，或者以数据为中心) 关键只在于你是否能够对问题建立一个准确的描述，而不是对我们的用例设计的准确描述－－这将是本文的第二部分的内容)。我会遵循本文中的大多数（但不是全部）步骤，而且我会改变一些步骤的次序。在每个步骤的具体内容中，我会说明为什么这样做有助于RUP和OOAD的新手更好的学习OOAD。 如图3所示，一些步骤把编写用例和实现代码分隔开了。还列出了RUP中用例分析部分推荐使用的一些步骤。这张图将会指出在后面部分中，我们的前进方向。 图3：用例分析的步骤  回页首 用例的具体