用例分析.pptVIP

《面向对象程序设计》 中国科技大学计算机系 马建辉 内 容 需求 用户目标和系统交互功能 用例图 用例图内元素的关系 用例图的设计实例 4.1 需 求 4.1 需 求 4.1 需 求 4.1 需 求 4.1 需 求 4.1 需 求 4.2 用例分析 4.2 用例分析 4.3 用户目标与系统交互功能 内 容 需求 用户目标和系统交互功能 用例图 用例图内元素的关系 用例图的设计实例 4.4 用例图 4.4.1 系统边界 4.4.2 活动者 4.4.2 活动者 4.4.2 用例和用例图 4.4.2 用例和用例图 4.4.2 用例和用例图 4.4.2 用例和用例图 4.4.3 项目词汇表 4.4.3 项目词汇表 4.4.4 事件流 4.4.4 事件流 4.5 用例图内元素的关系 4.5.1 概括关系 4.5.2 包含关系 4.5.3 扩展关系 内 容 需求 用户目标和系统交互功能 用例图 用例图内元素的关系 用例图的设计实例 4.6 用例图的设计实例 总 结 需求 用户目标和系统交互功能 用例图 用例图内元素的关系 用例图的设计实例 在“找出参与者（活动者）与用例”活动中要注意的一个重要问题，是如何区分用户目标和系统交互功能。 在字处理软件中，很多都采用的带有文体格式的页，从系统交互功能的角度来看，用例可以是诸如“定义文体格式”、“改变文体格式”、“将文体格式从一个文档移植到另一个文档上”等功能。然而，这些用例反映的都是用户在系统中为达到某种目的所要做的事情，而不是他所要达到的真正目标。真正的用户目标可能被描述为“确保统一的文档格式”、“使两个文档的格式相同”或者“采用那个文档的格式”。 并非在所有情况下都可以把用户目标和系统交互功能分离。例如，为一文件建立其章节目录的过程，无论把它看成用户目标，还是把它看成系统交互功能，其结果是一样的。但是，某些时候用户目标与系统交互功能确实不完全相同，应给予重视。 这两种类型的用例都有其作用。反映系统交互的用例比较适合于进行意向设计。考虑用户目标也很重要，它使你能够仔细斟酌满足用户目标的各种可选择的方法。如果仓促考虑系统交互功能，则常常可能失去选择更有效的实现方法的机会。应当时常问一问自己为什么要这么做．这种自问常常会促使你更好地理解用户的目标。 在实际工作中，首先应将注意力集中在用户目标上，然后提供用例来满足这些目标。到细化阶段末期，再对每个已经识别的用户目标，定义一系列规定系统交互功能的用例。用户目标是目的，因此首要任务是开发满足用户目标的用例。系统交互功能是达到目的的手段，也是不容忽视的。否则开发出的系统是不能达到预定的目的，或者开发出的系统用户不乐意 使用。 Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。 值得注意的是，不要在一开始就竭力去捕捉所有的细节，这是在细化阶段要进一步做的工作。但是，对于那些对系统的主要结构有重大影响的用例，则需要了解这些用例的更多的细节。大多数用例都是在定义过程中随着对用户需求理解的加深而不断得到细化。 在UML中，用例图用椭圆(oval)来表示，它用来记录用户或外界环境从头到尾使用系统的一系列事件。用户被称为“活动者”(Actor)。活动者可以是人，也可以是另一个系统。它与当前的系统进行交互，向系统提供输入或从系统中获得输出，用一个人形（stickman）标记表示之。用例图显示了用例和活动者、用例之间以及活动者之间的关系(relation)，关系描述了模型元素之间的语义连接。在UML中，关系使用实线表示，实线可以有箭头，也可以没有箭头。图4.4是使用用例图的示意图。 要设计一个饮料自动售货机，首先要从用户的角度考察它的功能： 问: 自动饮料售货机能为您做什么? 答: 通过自动饮料售货机购买一听饮料。 自动饮料售货机的主要功能是卖给用户饮料，可为这种机器设计一个名字