用例图(Use Case diagram)

用例是一个较新的,比较敏捷的捕获软件需求的形式。

用例描述了在一个场景中,系统是如何和最终用户或外部系统交互的(也就是谁可以使用系统做什么)。用例是基于场景的,这非常重要。

用例图并不是画成了图形的用例,用例图包含一组用例。用例也不是那个“椭圆”,椭圆只是一个描述用例的符号。

许多人通过UML认识了用例,UML的定义为“描述用例的图形符号”,它仅仅是符号。UML并没有为描述用例定义书写格式的标准,因此许多人误认为这些图形符号就是用例本身;然而,图形符号只能给出最简单的一个或一组用例的概要,所以,有“用例简述”和“用例规约”。UML是用例图形符号最流行的标准。但是,还有一些其它的可选择的标准。

正因为UML只能简单地描述用例,所以我们使用“用例简述”和“用例规约”来更加详细的描述用例。

编写详细的或完整的用例,尚无通用的模板(英语:template)。现在存在很多相互竞争的模板,同时,程序员们也被鼓励使用那些适合于他们工作的或者他们项目的模板,相对于指定某个模板来说,项目的标准化要重要的多。模板的关键部分都是大体相同的,虽然某些在某些术语上或者其他一些方面上存在不同,但是这些用例从本质上来说,是大同小异的。

典型部分包括:

  • 用例名称
  • 角色
  • 描述
  • 前置条件
  • 事件流
    • 基本流
    • 备选流
  • 后置条件
  • 扩展点
  • 业务规则
  • 特别要求
  • 迭代

不同的模板经常有其它部分,如,假设,异常流,建议,技术要求。也会有行业细节部分。

用例的优势

用例是一个较新的,比较敏捷的捕获软件需求的形式。用例经常和大的,统一的文档形成对比。这些大文档想要在新系统开始构成前,完整的表达出所有可能的需求,但这种做法通常都是失败的。

用例的几点优势:

  • 用例已经证实更容易被业务用户理解,因此它也是开发人员和最终用户的很好的沟通桥梁。
  • 用例对于确定范围很有用。用例使分阶段交付从而一步步完成项目变得容易;它们能够在优先度变化时相对较容易的添加或从软件项目移去。
  • 用例可跟踪。
  • 用例能够作为估计,制定进度和验证成果的基础。
  • 用例防止了不成熟的设计。
  • 用例不使用特定语言。
  • 用例允许我们去讲故事。能够容易的采用将需求转换为故事或场景这一具体的方法来描述用例。
  • 用例在项目中可复用。用例在每一次迭代中都能进一步演化,用例可以用于捕获需求,成为程序员的开发依据,发展为测试用例,到最后成为用户手册。
  • 用例与用户和系统交互相关。它们使软件开发者在开发之前或当中就能够开始用户接口设计。
  • 用例将需求置于上下文中,它们能够清楚地描述业务活动间的关系。

用例的局限性

用例不是没有局限性:

  • 用例在捕获系统功能需求上表现很优秀,但是它们并不适合方便的捕获非功能性需求,需要其它的方法去捕获非功能性需求。
  • 用例模板不能自动保证清晰。清晰要依靠书写者的技巧。
  • 用例并不像支持者说的那样易于理解。There is a learning curve involved in learning to interpret them correctly for end users and programmers alike.(如何正确地向最终用户和程序员解释这些用例是一个需要花费时间学习的事情。)
  • 极限编程的说明者通常认为用例是没用的文档,他们更喜欢用较简单的用户故事这一方法。
  • 可用性设计人员批评用例在开发过程中过早的引入了用户接口设计。他们指出用例描述用户和系统之间的交互,很显然它和用户接口设计重叠了。不好的用例描述将过细的,专断的用户接口设计包含于交互的描述中,即使用例的一个原则是不要加入实现的细节。

发表评论

电子邮件地址不会被公开。