4 用例分析 - ustc
TRANSCRIPT
1
第4章 用例分析
地址地址: : 安徽合肥安徽合肥
中国科大中国科大
20122012春春
讲
授：董兰芳
研究方向：科学计算可视化
图形、图像处理
模式识别
Telephone:0551-3603484 Email:[email protected]:http://staff.ustc.edu.cn/~lfdong中国科学技术大学
视觉计算与可视化实验室
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
2
内内
容容
需求
用户目标和系统交互功能
用例图
用例图内元素的关系
用例图的设计实例
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
3
4.1 4.1 需需
求求软件需求包括三个不同的层次：
业务需求说明了提供给客户和产品开发商的新系统的利益，反映了组织机构或客户对系统、产品高层次的目标要求，它们将在项目视图与范围文档中予以说明.
用户需求描述了用户使用系统必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明.
功能需求和非功能需求定义了开发人员必须实现的软件功能，使得用户能顺利完成他们的任务，从而满足了业务需求。
软件需求过程包括了5个主要活动：
需求获取
需求分析和确认
编写需求规格说明书
需求验证
需求管理
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
4
4.1 4.1 需需
求求
需求获取包括以下工作:编写项目视图和范围文档用户群分类选择用户代表建立核心队伍确定使用实例召开联合会议分析用户工作流程确定质量属性检查问题报告需求重用
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
5
4.1 4.1 需需
求求
需求分析需要完成的任务：
绘制关联图创建开发原型分析可行性确定需求优先级为需求建立模型编写数据字典质量功能调配
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
6中科大计算机系 图形图象实验室董兰芳 http://staff.ustc.edu.cn/~lfdong/
4.1 4.1 需需
求求
需求开发的最终成果是客户和开发小组对将要开发的产品达成一致协议，这一协议就是通过文档化的需求规格说明书来体现。需求规格说明书包括项目视图和范围文档，说明系统的业务需求；实例文档则说明了用户需求。
这个活动需要完成下面几个任务：采用模版指明需求来源为每项需求注上标号记录业务规范创建需求跟踪能力矩阵
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
7
4.1 4.1 需需
求求
需求验证是为了确保需求说明准确、完整，表达必要的质量特点。因为需求将要作为系统设计和最终验证的依据，所以一定要保证它的正确性。需求验证务必确保符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性等良好特征。这个活动需要完成下面几个任务：
审查需求文档
依据需求编写测试用例
编写用户手册
确定合格的标准
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
8
4.1 4.1 需需
求求
需求管理是组织、控制和文档化需求的系统方法，也是一种建立和维护用户和开发组织对于改变系统功能的协议。需求管理的几个任务：
确定变更控制过程
建立软件变更控制委员会
进行变更影响分析
跟踪变更影响的产品
建立基准和控制版本
维护变更的历史记录
跟踪每项需求的状态
衡量需求稳定性
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
9
一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。
用例的属性:描述了用户提出的一些可见的需求；可大可小；对应一个具体的用户目标。
4.2 4.2 用例分析用例分析
演示者
演示文稿备注
Ivar Jacobson首先提出了用例分析方法，并以此闻名于世。他对用例的使用进行了扩展，将其作用提高到项目设计和项目开发基本要素的高度。这种方法很快为大家所接受，并且成为面向对象方法的重要组成部分。 从本质上讲，一个用例是用户与计算机之间为达到某个目的的一次典型交互作用。以自动饮料售货机来说，“买饮料”和“放置饮料”便是两个典型的用例。从中可以看出用例的一些属性，即用例对应一个具体的用户目标，描述用户提出的一些可见的需求，规模可大可小。 与典型用户进行交谈是找出用例的简单而有效的用途，请用户讲明白他们希望系统做的事情以及提供的服务。软件开发人员则记下用户想做的每一件事，并为之取个名字，再写上简短的文字描述，这样便获取了所需要的用例。整个系统的需求是由一系列用例的集合组成的。这样的途径是一个由个体到一般，即由分析到综合的过程。这种方法适合对用户的整个任务尚不十分清楚的新任务的开发。
10
典型的用例建模方法: 找出系统边界 找出参与者 找出用例 说明用例 创建场景
用例模型包括四部分：参与者用例关系系统边界
大多数用例都是在定义过程中随着对用户需求理解的加深而不断得到细化。
4.2 4.2 用例分析用例分析
演示者
演示文稿备注
值得注意的是，不要在一开始就竭力去捕捉所有的细节，这是在细化阶段要进一步做的工作。但是，对于那些对系统的主要结构有重大影响的用例，则需要了解这些用例的更多的细节。大多数用例都是在定义过程中随着对用户需求理解的加深而不断得到细化。
11
4.3 4.3 用户目标与系统交互功能用户目标与系统交互功能
用例分析要注意的重要问题:是如何区分用户目标和系 统交互功能。
在实际工作中，首先应将注意力集中在用户目标上，然 后提供用例来满足这些目标。到细化阶段末期，再对每个 已经识别的用户目标，定义一系列规定系统交互功能的用 例。用户目标是目的，因此首要任务是开发满足用户目标 的用例。系统交互功能是达到目的的手段，也是不容忽视 的。否则开发出的系统是不能达到预定的目的，或者开发 出的系统用户不乐意使用。
演示者
演示文稿备注
在“找出参与者（活动者）与用例”活动中要注意的一个重要问题，是如何区分用户目标和系统交互功能。 在字处理软件中，很多都采用的带有文体格式的页，从系统交互功能的角度来看，用例可以是诸如“定义文体格式”、“改变文体格式”、“将文体格式从一个文档移植到另一个文档上”等功能。然而，这些用例反映的都是用户在系统中为达到某种目的所要做的事情，而不是他所要达到的真正目标。真正的用户目标可能被描述为“确保统一的文档格式”、“使两个文档的格式相同”或者“采用那个文档的格式”。 并非在所有情况下都可以把用户目标和系统交互功能分离。例如，为一文件建立其章节目录的过程，无论把它看成用户目标，还是把它看成系统交互功能，其结果是一样的。但是，某些时候用户目标与系统交互功能确实不完全相同，应给予重视。 这两种类型的用例都有其作用。反映系统交互的用例比较适合于进行意向设计。考虑用户目标也很重要，它使你能够仔细斟酌满足用户目标的各种可选择的方法。如果仓促考虑系统交互功能，则常常可能失去选择更有效的实现方法的机会。应当时常问一问自己为什么要这么做．这种自问常常会促使你更好地理解用户的目标。 在实际工作中，首先应将注意力集中在用户目标上，然后提供用例来满足这些目标。到细化阶段末期，再对每个已经识别的用户目标，定义一系列规定系统交互功能的用例。用户目标是目的，因此首要任务是开发满足用户目标的用例。系统交互功能是达到目的的手段，也是不容忽视的。否则开发出的系统是不能达到预定的目的，或者开发出的系统用户不乐意 使用。
12
内内
容容
需求
用户目标和系统交互功能
用例图
用例图内元素的关系
用例图的设计实例
13
4.4 4.4 用例图用例图
演示者
演示文稿备注
在UML中，用例图用椭圆(oval)来表示，它用来记录用户或外界环境从头到尾使用系统的一系列事件。用户被称为“活动者”(Actor)。活动者可以是人，也可以是另一个系统。它与当前的系统进行交互，向系统提供输入或从系统中获得输出，用一个人形（stickman）标记表示之。用例图显示了用例和活动者、用例之间以及活动者之间的关系(relation)，关系描述了模型元素之间的语义连接。在UML中，关系使用实线表示，实线可以有箭头，也可以没有箭头。图4.4是使用用例图的示意图。 要设计一个饮料自动售货机，首先要从用户的角度考察它的功能： 问: 自动饮料售货机能为您做什么? 答: 通过自动饮料售货机购买一听饮料。 自动饮料售货机的主要功能是卖给用户饮料，可为这种机器设计一个名字为“买饮料”的用例。图4.5就是自动饮料售货机中顾客买饮料的用例图。在这个用例中，顾客是活动者、用例是买饮料，顾客和系统之间通过界面（按键、菜单等等）进行交互。
14
4.4.1 4.4.1 系统边界系统边界
15
4.4.2 4.4.2 活动者活动者
活动者是人或与系统进行交互的外部系统.如何判别活动者？
谁对系统的某一需求感兴趣？
组织中哪一部分使用系统？
谁从系统的使用中受益？
谁向系统提供信息？
谁将维护系统？
系统使用外部资源吗？
系统和已经存在的系统交互吗？
演示者
演示文稿备注
活动者是人或与系统进行交互的外部系统，如何来判别活动者呢？首先分析如下问题： 谁对系统的某一需求感兴趣？ 组织中哪一部分使用系统? 谁从系统的使用中受益? 谁向系统提供信息？ 谁将维护系统？ 系统使用外部资源吗? 系统和已经存在的系统交互吗? 在自动饮料售货机中，除了买饮料的顾客，还有以下的活动者(参见图4.5)。 供应商向自动饮料售货机添加饮料。 收银员从自动饮料售货机。
16
4.4.2 4.4.2 活动者活动者
演示者
演示文稿备注
一个用例图(use case diagram)包括一个用例的集合，该集合定义整个系统的功能。
17
4.4.2 4.4.2 用例和用例图用例和用例图
用例是系统使用片断的集合，描述了所有的功能需求。它来自于对客户需求的分析，这个过程称为用例分析。
用例分析有助于如下工作：捕捉需求。计划开发过程的循环往复。验证系统。
动态分析从用例分析开始，它驱动整个开
发过程。
演示者
演示文稿备注
用例是活动者想要系统做的事情。它是特定活动者对于系统的“使用情况”。 （1）用例总是由活动者开始。 （2）用例总是从活动者的角度来编写的。 用例是系统使用片断的集合，描述了所有的功能需求。它来自于对客户需求的分析，这个过程称为用例分析，是整个系统开发中非常关键的过程。用例分析有助于如下工作： 捕捉需求。 计划开发过程的循环往复。 验证系统。 动态分析从用例分析开始，它驱动整个开发过程。 如何来标记一个用例呢？识别用例的最好方法是从活动者列表开始，然后考虑每个活动者如何使用系统。通过这一种方法，可以获得一组候选用例。每个用例必须被赋予一个简单、描述性名称。在识别用例的过程中，可能找出一些新的活动者。 用例建模是迭代的和逐步精化的过程。从用例名称开始，然后填充细节信息，这些细节由初始的简短描述组成，它们被精化成完整的规格说明。当试图识别用例时，可以从以下几个方面来考虑: (1) 活动者希望这个系统执行什么任务？ 活动者在系统中会访问哪些信息(创建，存储，修改，删除等)? 需要将外部的哪个变化告知系统？ 需要将系统的哪个事件告知活动者？
18
4.4.2 4.4.2 用例和用例图用例和用例图
标记用例:活动者希望这个系统执行什么任务？活动者在系统中会访问哪些信息
(创建, 存储, 修修改, 删除等) ？需要将外部的哪个变化告知系统？需要将系统的哪个事件告知活动者？如何维护系统？
19
4.4.2 4.4.2 用例和用例图用例和用例图
20
4.4.2 4.4.2 用例和用例图用例和用例图
21
4.4.3 4.4.3 项目词汇表项目词汇表
中科大计算机系 图形图象实验室董兰芳 http://staff.ustc.edu.cn/~lfdong/
项目词汇表是重要的项目制品之一。它应该被项目中的所有人员所理解，包括所有的利益相关人。除了定义术语，项目词汇表必须解决同义异音词和同音异义词的问题。（1）同义异音词是指相同事物的不同的词。（2）同音异义词是指相同的单词对不同的人表示
不同的事物。UML没有为项目词汇表设置任何标准。使它简单和保持
一致是很好的实践。
演示者
演示文稿备注
要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时，说明用例的逻辑流程。在这个文档中，详细描述系统用户的工作和系统本身的工作。事件流是独立于实现方法的。它通常包括：简要说明、前提条件、主事件流、其它事件流和事后条件。 1. 简要说明 每个用例应有一个相关说明，描述该用例的作用。例如 Purchase Ticket(买机票)用例可以说明为：Purchase Ticket用例供客户浏览客户航班信息、查询和用信用卡买票[7]。 2. 前提条件 列出开始用例之前必须满足的条件。例如，前提条件可能是另一个用例已经执行，或者用户具有运行当前使用案例的权限。 用例框图并不显示用例执行的顺序，但前提条件可以将这一方面的信息建档。 3. 主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流描述执行用例功能的具体步骤。事件流关注系统做什么，而不是怎么做，它是从用户角度写成的。 主事件流和其他事件流包括如下方面的工作: 用例如何开始； 用例的各种路径； 用例的正常(主)流程； 用例主事件流(其他事件流)的变形； 错误流。 4. 事后条件 事后条件是用例结束后执行的动作，比如一个用例结束后必须运行另一个用例。并不是每一个用例都有事后条件。 5. 设计实例 主事件流是正常情形，是用例中的最常用路径。现在来考察购买飞机票的事件流。买票时，主事件流是顺利买到票；其他事件流是从主事件流中分支出来的，但不是错误条件。例如客户用常客卡买票，客户信用卡无效或请求的航班没有票。这些情形是系统能够处理的合法情形，而不是系统中发生的错误。最后，错误流表示错误条件。例如系统无法验证信用卡或没有航班。错误流表示系统本身的问题。 书写主事件流例子的步骤如下： 1.客户选择浏览航班信息的选项时,用例开始。 2.系统提示输入出发站和到达站,出发时间和返回时间。 3.用户输入出发站和到达站,出发时间和返回时间。 4.系统显示航班清单及票价。 A1:没有这个航班 5.用户选择要定的航班 6.系统显示这个航班的所有票价选项. 7.用户选择要定的票价选项。 A2:用户用常客卡选择免费机票。 8.系统确认票价。 9.用户确认票价。 10.系统提示输入信用卡类型,号码,姓名和有效期。 11.用户输入信用卡类型,号码,姓名和有效期。 12.系统提交信用卡购买。 A6 账号找不到. A7 资金不足. E1 无法访问信用系统 13.系统对该用户订机票。 14.系统产生确认码并向用户显示。 15.用户确认收到代码。 16.用例结束。 书写其他事件流的步骤如下: A1:没有这个航班 1. 系统显示信息,没有所输入出发站和到达站以及出发时间和返回时间的航班。 2. 用户确认消息。 3. 返回主事件流第二步。 A2:用户用常客卡选择免费机票 1.系统提示输入常客卡号。 2.用户输入常客卡号。 3.系统确认卡号有效。 4.系统确认里程数足够兑换。 A4 :里程数不够兑换免费机票 A5: 没有常客免费票 5.票价设置为0美元 6.返回主事件流第8步。 A3:常客卡号无效 1.系统显示常客卡无效 2.用户重新输入卡号或选择取消免费票的要求。 3.如果用户重输卡号则流转入其他事件流A2第1步。 4.如果选择取消常客免费票要求,则流返回事件流第6步. A4:里程数不够兑换免费机票。 1.系统显示里程数不够兑换免费机票的消息,消息包含所需里程数和已累积里程数. 2.返回主事件流第6步。 A5:没有常客免费票 1.系统显示所选航班没有常客免费票的消息。 2.返回主事件流的第6步。 A6:账号找不到 1.系统显示账号找不到的消息。 2.返回主事件流的第10步。 A7:资金不足 1.系统显示资金不足的消息。 2.返回主事件流第10步。 错误流: E1:无法访问信用系统 1.系统显示无法访问信用系统的消息。 2.返回主事件流第10步。 建立事件流的主要问题是事件流需要的详细程度。要确定需要的详细程度，就要考虑文档的阅读者。 事件流的用户有如下3大类： (1) 客户通过审查这个文档相信其准确反映客户的期望。事件流应足够详细，使自己和客户对系统具有相同的理解程度。细节中留下的空白越多，产生分歧的可能性越大。与此同时，又不能涉及客户不了解或不关心的实现细节。 (2) 系统设计员用其创建系统设计和最终建立系统。事件流要提供足够的信息，以便理解用例中要发生的事件序列。尽管事件流不是针对实现方法的，但提供了系统行为的丰富信息。一定要明确指定用户要什么，使设计人员了解用户需求。 (3) 质检小组用事件流创建测试脚本。由于事件流一步步列出系统的工作，因此质检小组可以用事件流比较系统，看系统说的和做的是不是一回事。
22
4.4.3 4.4.3 项目词汇表项目词汇表一个课程注册系统的项目词汇表的文档：1.简介：这个文档用来定义问题域的技术，解释条目。2.定义：这个词汇表包括了课程注册系统中关键概念的
工作定义。课程：大学提供的课程类。学期课程：对于特定的学期提供的课程。课程目录：大学提供的没有删节的所有课程。教员：在大学从事教学工作的所有的教授。金融系统：处理付费信息的服务器。成绩：特定的学生的特定课程的评价。成绩卡：一个学生在特定的学期所选的所有课程的成绩。花名册：选一门特定课程的所有的学生。学生：在一所大学中注册的所有学生。日程：一个学生在当前学期中选择课程的日程安排。
演示者
演示文稿备注
要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时，说明用例的逻辑流程。在这个文档中，详细描述系统用户的工作和系统本身的工作。事件流是独立于实现方法的。它通常包括：简要说明、前提条件、主事件流、其它事件流和事后条件。 1. 简要说明 每个用例应有一个相关说明，描述该用例的作用。例如 Purchase Ticket(买机票)用例可以说明为：Purchase Ticket用例供客户浏览客户航班信息、查询和用信用卡买票[7]。 2. 前提条件 列出开始用例之前必须满足的条件。例如，前提条件可能是另一个用例已经执行，或者用户具有运行当前使用案例的权限。 用例框图并不显示用例执行的顺序，但前提条件可以将这一方面的信息建档。 3. 主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流描述执行用例功能的具体步骤。事件流关注系统做什么，而不是怎么做，它是从用户角度写成的。 主事件流和其他事件流包括如下方面的工作: 用例如何开始； 用例的各种路径； 用例的正常(主)流程； 用例主事件流(其他事件流)的变形； 错误流。 4. 事后条件 事后条件是用例结束后执行的动作，比如一个用例结束后必须运行另一个用例。并不是每一个用例都有事后条件。 5. 设计实例 主事件流是正常情形，是用例中的最常用路径。现在来考察购买飞机票的事件流。买票时，主事件流是顺利买到票；其他事件流是从主事件流中分支出来的，但不是错误条件。例如客户用常客卡买票，客户信用卡无效或请求的航班没有票。这些情形是系统能够处理的合法情形，而不是系统中发生的错误。最后，错误流表示错误条件。例如系统无法验证信用卡或没有航班。错误流表示系统本身的问题。 书写主事件流例子的步骤如下： 1.客户选择浏览航班信息的选项时,用例开始。 2.系统提示输入出发站和到达站,出发时间和返回时间。 3.用户输入出发站和到达站,出发时间和返回时间。 4.系统显示航班清单及票价。 A1:没有这个航班 5.用户选择要定的航班 6.系统显示这个航班的所有票价选项. 7.用户选择要定的票价选项。 A2:用户用常客卡选择免费机票。 8.系统确认票价。 9.用户确认票价。 10.系统提示输入信用卡类型,号码,姓名和有效期。 11.用户输入信用卡类型,号码,姓名和有效期。 12.系统提交信用卡购买。 A6 账号找不到. A7 资金不足. E1 无法访问信用系统 13.系统对该用户订机票。 14.系统产生确认码并向用户显示。 15.用户确认收到代码。 16.用例结束。 书写其他事件流的步骤如下: A1:没有这个航班 1. 系统显示信息,没有所输入出发站和到达站以及出发时间和返回时间的航班。 2. 用户确认消息。 3. 返回主事件流第二步。 A2:用户用常客卡选择免费机票 1.系统提示输入常客卡号。 2.用户输入常客卡号。 3.系统确认卡号有效。 4.系统确认里程数足够兑换。 A4 :里程数不够兑换免费机票 A5: 没有常客免费票 5.票价设置为0美元 6.返回主事件流第8步。 A3:常客卡号无效 1.系统显示常客卡无效 2.用户重新输入卡号或选择取消免费票的要求。 3.如果用户重输卡号则流转入其他事件流A2第1步。 4.如果选择取消常客免费票要求,则流返回事件流第6步. A4:里程数不够兑换免费机票。 1.系统显示里程数不够兑换免费机票的消息,消息包含所需里程数和已累积里程数. 2.返回主事件流第6步。 A5:没有常客免费票 1.系统显示所选航班没有常客免费票的消息。 2.返回主事件流的第6步。 A6:账号找不到 1.系统显示账号找不到的消息。 2.返回主事件流的第10步。 A7:资金不足 1.系统显示资金不足的消息。 2.返回主事件流第10步。 错误流: E1:无法访问信用系统 1.系统显示无法访问信用系统的消息。 2.返回主事件流第10步。 建立事件流的主要问题是事件流需要的详细程度。要确定需要的详细程度，就要考虑文档的阅读者。 事件流的用户有如下3大类： (1) 客户通过审查这个文档相信其准确反映客户的期望。事件流应足够详细，使自己和客户对系统具有相同的理解程度。细节中留下的空白越多，产生分歧的可能性越大。与此同时，又不能涉及客户不了解或不关心的实现细节。 (2) 系统设计员用其创建系统设计和最终建立系统。事件流要提供足够的信息，以便理解用例中要发生的事件序列。尽管事件流不是针对实现方法的，但提供了系统行为的丰富信息。一定要明确指定用户要什么，使设计人员了解用户需求。 (3) 质检小组用事件流创建测试脚本。由于事件流一步步列出系统的工作，因此质检小组可以用事件流比较系统，看系统说的和做的是不是一回事。
23
4.4.4 4.4.4 事件流事件流
要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时，说明用例的逻辑流程。在这个文档中，详细描述系统用户的工作和系统本身的工作。事件流包括：
简要说明 前提条件 主事件流 其它事件流 事后条件
演示者
演示文稿备注
要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时，说明用例的逻辑流程。在这个文档中，详细描述系统用户的工作和系统本身的工作。事件流是独立于实现方法的。它通常包括：简要说明、前提条件、主事件流、其它事件流和事后条件。 1. 简要说明 每个用例应有一个相关说明，描述该用例的作用。例如 Purchase Ticket(买机票)用例可以说明为：Purchase Ticket用例供客户浏览客户航班信息、查询和用信用卡买票[7]。 2. 前提条件 列出开始用例之前必须满足的条件。例如，前提条件可能是另一个用例已经执行，或者用户具有运行当前使用案例的权限。 用例框图并不显示用例执行的顺序，但前提条件可以将这一方面的信息建档。 3. 主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流描述执行用例功能的具体步骤。事件流关注系统做什么，而不是怎么做，它是从用户角度写成的。 主事件流和其他事件流包括如下方面的工作: 用例如何开始； 用例的各种路径； 用例的正常(主)流程； 用例主事件流(其他事件流)的变形； 错误流。 4. 事后条件 事后条件是用例结束后执行的动作，比如一个用例结束后必须运行另一个用例。并不是每一个用例都有事后条件。 5. 设计实例 主事件流是正常情形，是用例中的最常用路径。现在来考察购买飞机票的事件流。买票时，主事件流是顺利买到票；其他事件流是从主事件流中分支出来的，但不是错误条件。例如客户用常客卡买票，客户信用卡无效或请求的航班没有票。这些情形是系统能够处理的合法情形，而不是系统中发生的错误。最后，错误流表示错误条件。例如系统无法验证信用卡或没有航班。错误流表示系统本身的问题。 书写主事件流例子的步骤如下： 1.客户选择浏览航班信息的选项时,用例开始。 2.系统提示输入出发站和到达站,出发时间和返回时间。 3.用户输入出发站和到达站,出发时间和返回时间。 4.系统显示航班清单及票价。 A1:没有这个航班 5.用户选择要定的航班 6.系统显示这个航班的所有票价选项. 7.用户选择要定的票价选项。 A2:用户用常客卡选择免费机票。 8.系统确认票价。 9.用户确认票价。 10.系统提示输入信用卡类型,号码,姓名和有效期。 11.用户输入信用卡类型,号码,姓名和有效期。 12.系统提交信用卡购买。 A6 账号找不到. A7 资金不足. E1 无法访问信用系统 13.系统对该用户订机票。 14.系统产生确认码并向用户显示。 15.用户确认收到代码。 16.用例结束。 书写其他事件流的步骤如下: A1:没有这个航班 1. 系统显示信息,没有所输入出发站和到达站以及出发时间和返回时间的航班。 2. 用户确认消息。 3. 返回主事件流第二步。 A2:用户用常客卡选择免费机票 1.系统提示输入常客卡号。 2.用户输入常客卡号。 3.系统确认卡号有效。 4.系统确认里程数足够兑换。 A4 :里程数不够兑换免费机票 A5: 没有常客免费票 5.票价设置为0美元 6.返回主事件流第8步。 A3:常客卡号无效 1.系统显示常客卡无效 2.用户重新输入卡号或选择取消免费票的要求。 3.如果用户重输卡号则流转入其他事件流A2第1步。 4.如果选择取消常客免费票要求,则流返回事件流第6步. A4:里程数不够兑换免费机票。 1.系统显示里程数不够兑换免费机票的消息,消息包含所需里程数和已累积里程数. 2.返回主事件流第6步。 A5:没有常客免费票 1.系统显示所选航班没有常客免费票的消息。 2.返回主事件流的第6步。 A6:账号找不到 1.系统显示账号找不到的消息。 2.返回主事件流的第10步。 A7:资金不足 1.系统显示资金不足的消息。 2.返回主事件流第10步。 错误流: E1:无法访问信用系统 1.系统显示无法访问信用系统的消息。 2.返回主事件流第10步。 建立事件流的主要问题是事件流需要的详细程度。要确定需要的详细程度，就要考虑文档的阅读者。 事件流的用户有如下3大类： (1) 客户通过审查这个文档相信其准确反映客户的期望。事件流应足够详细，使自己和客户对系统具有相同的理解程度。细节中留下的空白越多，产生分歧的可能性越大。与此同时，又不能涉及客户不了解或不关心的实现细节。 (2) 系统设计员用其创建系统设计和最终建立系统。事件流要提供足够的信息，以便理解用例中要发生的事件序列。尽管事件流不是针对实现方法的，但提供了系统行为的丰富信息。一定要明确指定用户要什么，使设计人员了解用户需求。 (3) 质检小组用事件流创建测试脚本。由于事件流一步步列出系统的工作，因此质检小组可以用事件流比较系统，看系统说的和做的是不是一回事。
24
4.4.4 4.4.4 事件流事件流
事件流的3类用户:
客户通过审查这个文档相信其准确反映客户的期望。
系统设计员用其创建系统设计和最终建立系统。
质检小组用事件流创建测试脚本。
25
4.5 4.5 用例图内元素的关系用例图内元素的关系
一般将活动者和用例之间的关系称为通 信，而用例与用例之间可以存在的关系分为:
概括（Generalization） 包含(Include) 扩展(Extend)
活动者和活动者之间也可以存在概括 （Generalization）关系。
演示者
演示文稿备注
一般将活动者和用例之间的关系称为通信，而用例与用例之间可以存在的关系分为:概括（Generalization）、包含(Include)和扩展(Extend)3种。另外，活动者和活动者之间也可以存在概括（Generalization）关系。
26
4.5.1 4.5.1 概括关系概括关系
概括 表示几个元素某些共性,在用例图中 可分为活动者概括和用例概括。
演示者
演示文稿备注
概括表示几个元素某些共性。例如在买票系统中，个人购买和团体购买都是买票的特例，具有一些共同的特性，将这些共同的特征抽象出来，定义一个“买票”的基用例，个人购买和团体购买从“买票”基用例继承。可以用图4.8所示的用例图来表示。 如果多个活动者之间存在很多共性，就可以使用概括来分解共性行为。比如学生选课系统中，涉及用户包括注册管理员（Registrar）和学生(Student)，是用例图中的活动者，他们的主要特征相似，都具有姓名和学号等信息，所以可以抽象出“基”活动者People，而Registrar和Student则从People统一派生（图4.9）。
27
4.5.2 4.5.2 包含关系包含关系
包含使一个用例的功能可以在另一个用例中使用。
演示者
演示文稿备注
包含使一个用例的功能可以在另一个用例中使用。在这两种情况下，引入包含关系。如果两个以上的用例有相同的功能，则可以将这个功能分解到另一个用例中。 一个用例的功能太多时，可以用包含关系建模两个小用例。 在自动饮料售货系统中,用例“放置饮料”和“收钱”都包括打开和关闭机器的功能。下面将抽取出这两个用例，并让用例“放置饮料”和“收钱”包含它们(图4.10)。
28
4.5.3 4.5.3 扩展关系扩展关系
扩展关系允许一个用例（可选）扩展另一用例(基用例)提供的功能。
演示者
演示文稿备注
扩展关系允许一个用例（可选）扩展另一用例 (基用例)提供的功能。它与包含关系相似，这两个关系都是把相同功能分离到另一个用例中。外延只能在特定的设计点发生，称这个点为扩展点。 图4.11显示的是一个订货系统的用例框图, 订货过程包括客户填写客户信息，订货和付费。因为付费有现金支付和信用卡支付两种形式,所以概括出“付费”这一抽象的用例，“现金支付”和“信用卡支付”从“付费”用例中继承。客户可能会提出看一看货物目录的请求,所以从基用例扩展出“请求目录”的用例，以满足客户需要查看货物目录的要求。
29
内内
容容
需求
用户目标和系统交互功能
用例图
用例图内元素的关系
用例图的设计实例
30
4.6 4.6 用例图的设计实例用例图的设计实例
use case diagram
演示者
演示文稿备注
选课系统描述了某学校的网上选课系统，主要包括如下功能：管理员通过系统管理界面进入、建立本学期要开的各种课程、将课程信息保存在数据库中并同时可以对课程进行改动和删除。学生通过客户机浏览器根据学号和密码进入选课界面，这里学生可以进行三种操作:查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。本节将介绍这个选课系统用例图的设计和实现。 4.6.1 需求 本系统描述了某学校的网上选课系统，主要包括如下功能：管理员通过系统管理界面进入、建立本学期要开的各种课程、将课程信息保存在数据库中并同时可以对课程进行改动和删除。学生通过客户机浏览器根据学号和密码进入选课界面，这里学生可以进行三种操作:查询已选课程、选课以及付费。同样，通过业务层，这些操作结果存入数据库中。 4.6.2分析 本系统拟使用Java语言通过三层模型实现：数据核心层、业务逻辑层和接入层。其中，数据核心层包括对于数据库的操作；业务层作为中间层对于用户输入进行逻辑处理，再映射到相应的数据层操作；而接入层包括用户界面，包括系统登陆界面、管理界面、用户选课界面等。 本系统涉及用户包括注册管理员（Registrar）和学生(Student)，是用例图中的活动者，他们的主要特征相似，都具有姓名和学号等信息，所以可以抽象出“基”活动者People，而Registrar和Student则从People统一派生。数据库管理系统是另外一个活动者。 4.6.3 事件流 下面是系统中出现的一些事件流。 添加课程事件流： 1．管理员选择进入管理界面，用例开始。 2．系统提示输入管理员密码。 3．管理员输入密码。 4．系统验证密码。 A1：密码错误。 5．进入管理界面，系统显示目前所建立的全部课程信息。 6．管理员选择添加课程。 7．系统提示输入新课程信息。 8．管理员输入信息。 9．系统验证是否和已有课程冲突。 A2：有冲突。 10．系统添加新课程，提示课程添加成功。 11．系统重新进入管理主界面，显示所有课程。 12．用例结束。 其他事件流： A1：密码错误 1．系统提示再次输入。 2．用户确认。 3．三次错误，拒绝再次访问。 4．否则进入添加课程事件流第5步。 A2：有冲突 1．系统提示冲突，显示冲突课程信息。 2．用户重新输入。 3．继续验证直到无冲突。 4．进入添加课程事件流第10步。 删除课程事件流和修改课程事件流与此类似。 选课事件流： 1．学生进入选课登陆界面，用例开始。 2．系统提示输入学号和密码。 3．学生输入学号密码。 4．系统验证。 A1：验证失败。 5．进入选课主界面。 6．学生点击选课。 7．系统显示所有课程信息。 8．学生选择课程。 9．系统验证课程是否可选。 A2：不可选。 10．系统提示课程选择成功，提示学生交费。 11．用例结束。 错误流： A1：验证失败 1．系统提示验证失败，提示重新输入。 2．三次失败，拒绝访问。 3．成功，转选课事件流第5步。 A2：课程不可选 1．系统提示课程不可选及原因。 2．学生重新选课。 3．重新验证直至成功。 4．转选课事件流第10步。 因为付费方式多样，所以在本书中将不讨论付费用例。查询事件流比较简单。这里也不详细描述。
31
总总
结结
需求
用户目标和系统交互功能
用例图
用例图内元素的关系
用例图的设计实例