从用例到代码:用例分析

发表于:2014-08-06来源:uml.org.cn作者:不详点击数: 标签:测试用例
自从1992年 Ivar Jacobson 发表了关于如何使用用例,从系统用户的角度来提取软件需求的方法的论文之后,这种方法已经逐渐流行起来。但是有一个最常见的问题是:当我得到了用例之后,

  自从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)

  把行为指定到具体的分析类

  对每个分析结果的类:

  类的职责

  类的属性和关系

  定义类的属性

  分析类直接的关系

  分析类间事件与事件之间的相关性

原文转自:http://www.uml.org.cn/Test/200904165.asp