usecase模型与usecase描述.doc

1 认识Use Case 1.1 什么是Use Case Use Case在确保系统的可用性(usability)上，是个强有力的工具(tool)。它擅长于分析用户(user)为什么(why)要使用(use)系统，或如何(how)使用系统。在传统的计算机系统开发上，软件设计者大多带着计算机技术的眼光来看整个相关的事情。一直忽略了人们使用系统的感受，Thomas Erickson说到： “Designers who know enough to incorporate a technology into a product(system) know too much understand how users will perceive it.” (十足了解如何运用技术于产品的设计师，常因了解太多技术而无法弄清用户的观点和感觉。) 因而，目前的困境是软件开发人员并不够了解用户的实际工作情形，以致软件与用户的需要无法吻合。因此，著名的软件专家Larry L. Constantine也提到： “You have to understand the users work before your software can fit it.” (只有了解了用户的工作情形，您的软件才能契合其工作。) Constantine继续提到： “Users are not the center of the universe. The most important issue in designing more-usable software is usage.” (用户本身并非焦点，想设计出更适用的软件时，使用才是最重要的问题所在。) 也就是我们必须深入去了解许多“为什么”，例如：为什么需要这软件？为何用户要去接触这软件？用户欲达成什么事？当我们用心探索围绕在“使用”的一连串“为什么”问题之后，就能导出高度可用性的软件了。在这个过程中，就已厘清了用户的外部行为(external behavior)，以及其与系统的交互情形(interaction)，也因而定义出系统应有的外部行为，以协助用户完成其工作。根据IEEE Standard 729 对需求(requirements)一词的定义： “The conditions or capabilities needed by a user to solve a problem or achieve an objective.” (User为了解决一个问题或达成一个目标时，所需要的条件或能力。) 于是，可知在弄清用户为什么“使用”这系统时，其实就已定义出用户对这个系统的需求了。Use Case能描述用户的外部行为及其与系统的交互情形，也因而表达出了系统的责任(responsibilities)，即用户对系统的需求。 简单地说，Use Case是个强有力的工具让软件人员暂时不考虑软件系统内部的行为和结构，而专注于厘清用户“为什么”去“使用”这个系统，充分正确地掌握用户的需求，然后才能设计出好用的软件。 1.2 认识Use Case及其场景 Use Case用来描述人们使用某系统的途径(way)。每个人使用系统时，其目的是期望系统提供服务或产品。系统在提供完整的服务或产品的过程中，会执行一连串的小活动。在这活动中，也常会跟用户沟通，取得用户的指示而调整其活动或顺序。例如，人们去麦当劳餐厅买汉堡时，柜台人员会向用户询问是“外带”还是“内用”而决定其包装程序。因此，每个人去买汉堡时，其使用“麦当劳服务系统”的途径会有些相同，也可能有些不同。其中，每个人使用系统的途径就是个实例(instance)，称为场景(scenario)或实景。 虽然每个人使用系统的场景会有些差异，但是若用户的目标(goal)是相同的，则其场景常会极为类似。那么这些类似的场景的集合就是类(class)，这种类就称为Use Case，其实例就是场景。至于一般的类，其实例是对象(object)，两者有所区别。归纳如下。 Use Case类：其实例是场景。 一般类：其实例是对象。 由上所述，人们根据用户的目的将场景分门别类(classify)而得到不同的Use Case。由于同类(Use Case)内场景大同小异，所以就可把其共同而重要的特点(如活动和顺序)以文字描述出来，根据 Wirfs-Brock 的建议，可只描述用户与系统间的对话，Use Case描述如下所示： 这就称为“Use Case描述”(Use Case Description，简称UCD)，也称为Use Case说明。因此，Use Case是一群类似的场景的抽象表达或描述。由于场景很多，且各有些微小的差异，不易逐一去描述或定义它，所以就借助Use Case来描述一群类似场