可以将用例图组织到用例包中，并归用例包所有，让特定包中仅显示互为关联关系的内容。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。比如小明是图书馆的管理员，他参与图书馆管理系统的交互，这时他既可以作为管理员这个角色参与管理，也可以作为借书者向图书馆借书，在这里小明扮演了两个角色，是两个不同的参与者。参与者在画图中用简笔人物画来表示，人物下面附上参与者的名称。
用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。这是UML对用例的正式定义，对我们初学者可能有点难懂。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
用例图主要的作用有三个：（1）获取需求；（2）指导测试；（3）还可在整个过程中的其它工作流起到指导作用。
□ 元素之间的关系
用例图中包含的元素除了系统边界、角色和用例，另外就是关系。关系包括用例之间的关系，角色之间的关系，用例和角色之间的关系。
1、角色之间的关系：
角色之间的关系。由于角色实质上也是类，所以它拥有与类相同的关系描述，即角色之间存在泛化关系，泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。
２、用例之间的关系：
包含关系：基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。在UML1.1中用例之间是使用和扩展这两种关系，这两种关系都是泛化关系的版型。在UML1.3以后的版本中用例之间是包含和扩展这两种关系。
泛化关系：代表一般于特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段，泛化使用在分析、设计阶段。在泛化关系中子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或者覆盖父用例中的行为和含义。
扩展关系的基本含义和泛化关系类似，但在扩展关系中，对于扩展用例有更多的规则限制，基本用例必须声明扩展点，而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样，扩展关系也是依赖关系的版型。在扩展关系中，箭头的方向是从扩展用例到基本用例，这与包含关系是不同的。
用例的泛化、包含、扩展关系的比较。一般来说可以使用“is a”和“has a”来判断使用那种关系。范化和扩展关系表示用例之间是“is a”关系，包含关系表示用例之间是“has a”关系。扩展与范化相比多了扩展点，扩展用例只能在基本用例的扩展点上进行扩展。在扩展关系中基本用例是独立存在。在包含关系中在执行基本用例的时候一定会执行包含用例。如果需要重复处理两个或多个用例时可以考虑使用包含关系，实现一个基本用例对另一个的引用。当处理正常行为的变形是偶尔描述时可以考虑只用泛化关系。当描述正常行为的变形希望采用更多的控制方式时，可以在基本用例中设置扩展点，使用扩展关系。扩展关系比较难理解，如果把扩展关系看作是带有更多规则限制的泛化关系，可以帮助理解。通常先获得基本用例，针对这个用例中的每一个行为提问：该步骤会出什么差错？该步骤有不同的情况吗？该步骤的工作怎样以不同的方式进行等，把所有的变化情况都标识为扩展。通常基本用例很容易构造，而扩展用例需要反复分析、验证。当我们发现已经存在的两个用例间具有某种相似性时，可以把相似的部分从两个用例中抽象出来单独作为一个用例，该用例被这两个用例同时使用，这个抽象出的用例和另外两个用例形成包含关系。
(1) 用例模型(Use case model)
长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需求。但是,这些使用情景是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由Ivar Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向
对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。
用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。
(2) 用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例,"将某些正文置为黑体"和"创建一个索引"便是两个典型的用例。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。
图1 用例图
在UML中,用例表示为一个椭圆。图1显示了一个金融贸易系统的用例图。其中,"风险分析","交易估价","进行交易","设置边界","超越边界的交易","评价贸易","更新帐目"等都是用例的实例。概括地说,用例有以下特点:
·用例捕获某些用户可见的需求,实现一个具体的用户目标。
·用例由执行者激活,并提供确切的值给执行者。
·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。
(3) 执行者(Actor)
执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图1中有四个执行者:贸易经理、营销人员、售货员和记帐系统。在某些组织中很可能有许多营销人员
,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理执行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。
图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。需要注意的是,尽管执行者在用例图中是用类似人的图形来表示的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐目。
通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。
(4) 使用和扩展(Use and Extend)
图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。例如图1中,基本的用例是"进行交易"。 交易中可能一切都进行得很顺利,但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。我们可在"进行交易"用例中做改动。但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起,使正常的流程晦涩不堪。图1中将常规的动作放在"进行交易"用例中,而将非常规的动作放置于"超越边界的交易" 用例中,这便是扩展关系的实质。当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即"评价贸易",而"风险分析"和"交易估价"用例将使用它。请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。
(5) 用例模型的获取
几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。
a. 获取执行者
获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考:
·谁使用系统的主要功能(主要使用者)。
·谁需要系统支持他们的日常工作。
·谁来维护、管理使系统正常工作(辅助使用者)。
·系统需要操纵哪些硬件。
·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
·对系统产生的结果感兴趣的人或事物。
b. 获取用例
一旦获取了执行者,就可以对每个执行者提出问题以获取用例。以下问题可供参考:
·执行者要求系统提供哪些功能(执行者需要做什么)?
·执行者需要读、产生、删除、修改或存储的信息有哪些类型。
·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能?
·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?
还有一些不针对具体执行者问题(即针对整个系统的问题):
·系统需要何种输入输出?输入从何处来?输出到何处?
·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
