《《用例建模与分析》PPT课件.ppt》由会员分享,可在线阅读,更多相关《《用例建模与分析》PPT课件.ppt(59页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、3 GIS软件工程软件工程用例建模与分析用例建模与分析3.1 3.1 概述概述 用例建模是用来捕获用例建模是用来捕获系统场景系统场景的形式化过程,是的形式化过程,是识别和定义识别和定义任何类型软件系统需求任何类型软件系统需求的重要方法。本章将重点讲述如何利用用的重要方法。本章将重点讲述如何利用用例建模,例建模,有效获取软件系统需求有效获取软件系统需求。3.2 3.2 本章的重点本章的重点陈述用例模型的组件陈述用例模型的组件描述用例模型如何辅助解决常见的需求定义问题描述用例模型如何辅助解决常见的需求定义问题开发用例开发用例为用例编写文档为用例编写文档将用例建模贯穿到项目生命周期中将用例建模贯穿到
2、项目生命周期中3.3 3.3 需求获取需求获取 需求是描述系统应该具备的功能,以及为满足此功能需要具备的条件。需求是描述系统应该具备的功能,以及为满足此功能需要具备的条件。需求用来描述需求用来描述系统应该做什么,而不是如何构建系统系统应该做什么,而不是如何构建系统。可以直接从用户那。可以直接从用户那里获取需求,也可以在合同、标准、规范或其它正式使用的文档中来获得里获取需求,也可以在合同、标准、规范或其它正式使用的文档中来获得需求。需求。需求获取是定义系统的过程,包括对问题空间的清晰理解,然后定需求获取是定义系统的过程,包括对问题空间的清晰理解,然后定义解决问题的应用或系统义解决问题的应用或系统
3、。1.1.定义需求过程中的一般问题定义需求过程中的一般问题 软件需求规范中确定需求一般只是简单基于自然语言的说明性语句,软件需求规范中确定需求一般只是简单基于自然语言的说明性语句,开开发者总是使用规范中提供的经典场景来试图理解系统需求的含义以及期待发者总是使用规范中提供的经典场景来试图理解系统需求的含义以及期待系统如何运转系统如何运转,软件需求规范的编写方式非常低效。而用例是可以将场景,软件需求规范的编写方式非常低效。而用例是可以将场景捕获过程形式化的有用技术。捕获过程形式化的有用技术。2.2.用于需求获取的用例建模用于需求获取的用例建模 用例(用例(Use CaseUse Case)是系统执
4、行的一系列事件(操作),)是系统执行的一系列事件(操作),通过提供这些通过提供这些事件,事件,可以为特定参与者产生可度量的结果可以为特定参与者产生可度量的结果。参与者(参与者(ActorActor)是与系统)是与系统进行交互的某个人或者事物所扮演的角色。进行交互的某个人或者事物所扮演的角色。因此,因此,用例是由一系列动作组用例是由一系列动作组成,用户必须进行这些动作,以完成一些有用的工作并实现目标。成,用户必须进行这些动作,以完成一些有用的工作并实现目标。用例反用例反映了在实现参与者目标的过程中,系统可能发生的所有事件。映了在实现参与者目标的过程中,系统可能发生的所有事件。3 GIS软件工程软
5、件工程用例建模与分析用例建模与分析 用例必须从用户的角度描述所期望的系统行为,完整的用例集合确定了用例必须从用户的角度描述所期望的系统行为,完整的用例集合确定了系统的范围,包含了系统的所有行为。系统的范围,包含了系统的所有行为。用例应作为需求定义单元或仅仅作用例应作为需求定义单元或仅仅作为一个用户目标。为一个用户目标。3.4 3.4 用例建模技术用例建模技术 用例建模是一个从外部视角来描述目标系统行为的过程。用例建模是一个从外部视角来描述目标系统行为的过程。用于描述系统用于描述系统将要做什么,而不是如何做,将要做什么,而不是如何做,主要帮助设计师关注系统需求主要帮助设计师关注系统需求,而不是系
6、统,而不是系统实现。实现。用例图能够使系统设计师从用户的视角发现目标系统需求,是设计用例图能够使系统设计师从用户的视角发现目标系统需求,是设计师与用户进行沟通的有效工具。师与用户进行沟通的有效工具。用例模型(用例模型(Use Case ModelUse Case Model)是一幅图或一组图,还可能包含额外的)是一幅图或一组图,还可能包含额外的资料,用于表达所提交的软件系统要完成的工作。资料,用于表达所提交的软件系统要完成的工作。用例图由用例图由3 3部分组成:部分组成:参与者参与者 用例以及用例之间的通信用例以及用例之间的通信 额外文档额外文档 另外,用例图还包含系统边界。另外,用例图还包含
7、系统边界。1.1.参与者参与者 参与者是需要与系统交互信息的一切外部实体。参与者是需要与系统交互信息的一切外部实体。主要包括以下几类:主要包括以下几类:3 GIS软件工程软件工程用例建模与分析用例建模与分析人;人;计算机硬件或设备;计算机硬件或设备;外部系统。外部系统。参与者代表了用户可以扮演的角色,不是某个特定的用户,而是可以参与者代表了用户可以扮演的角色,不是某个特定的用户,而是可以扮演某个角色的一组用户。扮演某个角色的一组用户。一个人可能是某个参与者的实例,多个人也一个人可能是某个参与者的实例,多个人也可能扮演某个参与者的同一角色。可能扮演某个参与者的同一角色。识别用例的通用方法是与将要
8、直接操作该系统的用户交谈,该过程有识别用例的通用方法是与将要直接操作该系统的用户交谈,该过程有助于设计满足用户需求的系统。助于设计满足用户需求的系统。而系统的其它涉众可能在关键的开发阶而系统的其它涉众可能在关键的开发阶段漏掉,导致系统可能不满足所有涉众需求。段漏掉,导致系统可能不满足所有涉众需求。在同一个软件系统中,不在同一个软件系统中,不同涉众的需求可能存在冲突,开发小组的通行做法是召集所有涉众,以同涉众的需求可能存在冲突,开发小组的通行做法是召集所有涉众,以确定所有需求,同时解决存在矛盾的需求。确定所有需求,同时解决存在矛盾的需求。2.2.表示参与者表示参与者 参与者一般用人形简笔画来表示
9、,即便参与者不是人类时,仍然使用参与者一般用人形简笔画来表示,即便参与者不是人类时,仍然使用这种表示法。这种表示法。在在UMLUML中,可以用带有构造形的类图来表示参与者,将构中,可以用带有构造形的类图来表示参与者,将构造形放在位于图标上半部分类名的上方,如下图所示。造形放在位于图标上半部分类名的上方,如下图所示。3 GIS软件工程软件工程用例建模与分析用例建模与分析3.3.参与者类型参与者类型 参与者可以分为主要参与者和次要参与者。参与者可以分为主要参与者和次要参与者。所谓主要参与者是指主要所谓主要参与者是指主要用户或系统设计时主要面向的实体。主要参与者应具备的关键特征包括:用户或系统设计时
10、主要面向的实体。主要参与者应具备的关键特征包括:完全位于系统外部,并驱动系统需求;完全位于系统外部,并驱动系统需求;使用系统,以实现某个可观测的用户目标。使用系统,以实现某个可观测的用户目标。次要参与者是监督、操作和管理该系统的用户或者实体。次要参与者是监督、操作和管理该系统的用户或者实体。扮演支撑角扮演支撑角色,以帮助主要参与者实现他们的目标,次要参与者特征包括:色,以帮助主要参与者实现他们的目标,次要参与者特征包括:次要参与者经常更多地出现在系统的内部而不是外部;次要参与者经常更多地出现在系统的内部而不是外部;次要参与者经常指定很多系统需求,这些需求不能直接从需求陈述次要参与者经常指定很多
11、系统需求,这些需求不能直接从需求陈述中得到。如下面的例子所示。中得到。如下面的例子所示。ActorCustomer3 GIS软件工程软件工程用例建模与分析用例建模与分析报税表可以由纳税人(直接参与者)直接提交,也可以通过报税表可以由纳税人(直接参与者)直接提交,也可以通过InternetInternet或或邮寄进行,若是后面一种情况,就需要数据录入员将报税表单中的数据邮寄进行,若是后面一种情况,就需要数据录入员将报税表单中的数据录入系统,录入系统,数据录入员可视为次要参与者数据录入员可视为次要参与者,因为他们帮助报税人处理报,因为他们帮助报税人处理报税表单。税表单。4.4.参与者与角色参与者与
12、角色 在用例建模中,参与者的精确含义应该是一组角色在用例建模中,参与者的精确含义应该是一组角色,个人或其它外部,个人或其它外部系统都能扮演这些角色。同一个人可以在不同的时间扮演不同的角色,系统都能扮演这些角色。同一个人可以在不同的时间扮演不同的角色,具有相同职务头衔的职员,可以扮演不同的角色以适应业务需求的需要。具有相同职务头衔的职员,可以扮演不同的角色以适应业务需求的需要。5.5.用例用例 用例描述一系列动作,系统执行这些动作,以产生某个特定参与者能用例描述一系列动作,系统执行这些动作,以产生某个特定参与者能够观察到的结果。够观察到的结果。即用例是参与者与系统之间对话的抽象,描述可能的即用例
13、是参与者与系统之间对话的抽象,描述可能的交互,而不深入某个场景的详细细节。交互,而不深入某个场景的详细细节。在在UMLUML中,使用带有描述参与者目标标签的椭圆形表示用例中,使用带有描述参与者目标标签的椭圆形表示用例。使用直。使用直线表示通信链接,将用例连接到一个或多个参与者。如在与线表示通信链接,将用例连接到一个或多个参与者。如在与ATMATM系统的系统的交互过程中,客户目标之一是从账户中取款,其用例可表示如下。交互过程中,客户目标之一是从账户中取款,其用例可表示如下。3 GIS软件工程软件工程用例建模与分析用例建模与分析好的用例应该满足的条件:好的用例应该满足的条件:描述系统执行的一系列事
14、务,这些被执行的事务可为特定参与者产生可描述系统执行的一系列事务,这些被执行的事务可为特定参与者产生可度量的结果。度量的结果。从用户角度描述期望的系统行为。从用户角度描述期望的系统行为。使得系统分析使能够从高层次业务观点来理解系统,并为之建模。使得系统分析使能够从高层次业务观点来理解系统,并为之建模。表示系统提供给外部实体的接口,以及参与者与系统之间的相互关系。表示系统提供给外部实体的接口,以及参与者与系统之间的相互关系。6.6.系统边界系统边界 定义了开发中的系统范围,在定义了开发中的系统范围,在UMLUML中用矩形表示边界,所有用例都必须中用矩形表示边界,所有用例都必须放在边界以内。参与者
15、放在系统边界以外,所有用例共同组成了系统的总放在边界以内。参与者放在系统边界以外,所有用例共同组成了系统的总需求。需求。取款参与者、用例和通信链接参与者、用例和通信链接3 GIS软件工程软件工程用例建模与分析用例建模与分析3.5 3.5 用例建模示例用例建模示例 1.ATM1.ATM系统系统 ATM ATM通过计算机化银行网络进行账户交易,银行网络包含一台中通过计算机化银行网络进行账户交易,银行网络包含一台中心计算机,它连接着所有的心计算机,它连接着所有的ATMATM机和单个银行拥有的银行计算机,机和单个银行拥有的银行计算机,每台银行计算机用来处理由其客户请求的交易。每台银行计算机用来处理由其
16、客户请求的交易。在这个例子中,客户在这个例子中,客户CustomerCustomer是是ATMATM系统的一组参与者。他们系统的一组参与者。他们操作操作ATMATM存款、取款或者检查账户余额等。可以将这些可观察的服存款、取款或者检查账户余额等。可以将这些可观察的服务作为用来。务作为用来。3 GIS软件工程软件工程用例建模与分析用例建模与分析ATM Banking System取款存款查询余额客户系统名称用例系统边界联系ATM系统用例模型3 GIS软件工程软件工程用例建模与分析用例建模与分析2.2.酒店信息系统酒店信息系统 考虑简单的酒店信息系统,有两类客户,即团客和散客。考虑简单的酒店信息系统
17、,有两类客户,即团客和散客。前者是旅游承办商提前预定,后者是旅客直接与酒店进行预定。前者是旅游承办商提前预定,后者是旅客直接与酒店进行预定。两类客户都可以利用两类客户都可以利用InternetInternet或电话预定、取消、检入和检出或电话预定、取消、检入和检出房间。房间。基于这些需求,共有基于这些需求,共有4 4个可观测到的服务可作为用例:预定、个可观测到的服务可作为用例:预定、取消预定、检入和检出。其用例模型如下图所示。取消预定、检入和检出。其用例模型如下图所示。3 GIS软件工程软件工程用例建模与分析用例建模与分析Hotel Information System预定房间取消预定检入房间
18、检出房间客户团客散客处理房间预定的职员接待职员3 GIS软件工程软件工程用例建模与分析用例建模与分析3.6 3.6 用例分析技术用例分析技术3.6.1 3.6.1 进行用例分析进行用例分析 在用例分析过程中,通常可以访问客户和系统的典型用户。描述在用例分析过程中,通常可以访问客户和系统的典型用户。描述系统的用例是一个实用且非常重要的练习,它有助于识别冗余或不清系统的用例是一个实用且非常重要的练习,它有助于识别冗余或不清晰的功能,用例分析有助于解决一些潜在的沟通问题。晰的功能,用例分析有助于解决一些潜在的沟通问题。在以下领域中需要使用用例分析:在以下领域中需要使用用例分析:发现新功能(需求)。在
19、分析系统和深化设计的过程中,新的用例发现新功能(需求)。在分析系统和深化设计的过程中,新的用例常常可以帮助产生新的需求。常常可以帮助产生新的需求。与客户沟通。与客户沟通。产生测试案例。用例的场景结合还可以提供一个测试套件,并作为产生测试案例。用例的场景结合还可以提供一个测试套件,并作为形成用户界面的起点。形成用户界面的起点。场景是捕获某个用例的某此特定执行场景是捕获某个用例的某此特定执行。即用例。即用例是泛化描述或者是一系列事务的模板,而场景是用例的一个具体实例。是泛化描述或者是一系列事务的模板,而场景是用例的一个具体实例。3 GIS软件工程软件工程用例建模与分析用例建模与分析3.6.2 3.
20、6.2 用例建模的用例建模的UMLUML表示法小结表示法小结 现将用例建模的现将用例建模的UMLUML表示法小结如下:表示法小结如下:用例:系统执行的一系列事务,用例:系统执行的一系列事务,通过这些事务,系统产生某个特通过这些事务,系统产生某个特定用户可度量的结果。定用户可度量的结果。用例名参与者:用户在与这些用户交互参与者:用户在与这些用户交互时所扮演的一组角色。时所扮演的一组角色。参与者名称参与者名称系统边界:物理系统与该物理系统进行系统边界:物理系统与该物理系统进行交互的参与者之间的边界交互的参与者之间的边界系统名称系统名称3 GIS软件工程软件工程用例建模与分析用例建模与分析关联:参与
21、者在某个用例中的关联:参与者在某个用例中的参与,如参与者的某个实例与参与,如参与者的某个实例与用例的某个实例进行通信用例的某个实例进行通信泛化:一般用例与较特定用例泛化:一般用例与较特定用例之间的分类关系,箭头指向一之间的分类关系,箭头指向一般用例。般用例。扩展:扩展用例与其基本用例之扩展:扩展用例与其基本用例之间的关系,指定如何将扩展用例间的关系,指定如何将扩展用例的行为插入到基本用例所定义的的行为插入到基本用例所定义的行为中去,箭头指向基本用例。行为中去,箭头指向基本用例。extend包含:基本用例和包含用例之间包含:基本用例和包含用例之间的关系,指定为包含用例定义的的关系,指定为包含用例
22、定义的行为如何插入到基本用例的行为行为如何插入到基本用例的行为中去。箭头指向包含用例。中去。箭头指向包含用例。include3 GIS软件工程软件工程用例建模与分析用例建模与分析3.6.3 3.6.3 使用关系组织用例使用关系组织用例 在开发用例模型的过程中,在开发用例模型的过程中,可能会发现有些用例之间包含相同的行可能会发现有些用例之间包含相同的行为为。在有些情况下,除了一些额外的行为之外,有些用例很相似在有些情况下,除了一些额外的行为之外,有些用例很相似。在。在上面讲过的上面讲过的ATM系统中,取款、存款和查询余额都要先进行账户登录,系统中,取款、存款和查询余额都要先进行账户登录,因此可以
23、将用户登录作为单独的用例,其它用例可以共享这个用例。因此可以将用户登录作为单独的用例,其它用例可以共享这个用例。在在UML中,账户登录与取款和存款这两个用例之间的关系可以用中,账户登录与取款和存款这两个用例之间的关系可以用include来表示。来表示。取款存款账户登录includeinclude3 GIS软件工程软件工程用例建模与分析用例建模与分析 在在UMLUML中,支持中,支持3 3种用于用例的关系类型:种用于用例的关系类型:includeinclude、extendextend和和泛化。泛化。UMLUML构造型是书写在书名号()中的标签,表示某些超出构造型是书写在书名号()中的标签,表示
24、某些超出UMLUML基本定义的语义概念。使用基本定义的语义概念。使用UMLUML构造型,可扩展构造型,可扩展UMLUML语义,以便支持特定语义,以便支持特定的设计方法或设计师需求。的设计方法或设计师需求。1.1.includeinclude关系关系 includeinclude关系用于两个或多个用例中,以共享事件流中某些公共部关系用于两个或多个用例中,以共享事件流中某些公共部分。然后将该公共部分分组并提取出来,形成一个包含用例,在两个或多分。然后将该公共部分分组并提取出来,形成一个包含用例,在两个或多个用例中共享。个用例中共享。2.2.extendextend关系关系 如果两个用例相似,但一个
25、用例比另一个用例所做的事稍多一些,则可如果两个用例相似,但一个用例比另一个用例所做的事稍多一些,则可以使用以使用extendextend关系。例如,可以使用一个用例来捕获典型情况(基本关系。例如,可以使用一个用例来捕获典型情况(基本用例),然后使用扩展来描述各种变化,使基本用例可以有条件地调用某用例),然后使用扩展来描述各种变化,使基本用例可以有条件地调用某个用例。即扩展用例向基本用例中添加了一些额外的行为。如取款有一个个用例。即扩展用例向基本用例中添加了一些额外的行为。如取款有一个可能的行为,就是需要处理超额取款。可能的行为,就是需要处理超额取款。3 GIS软件工程软件工程用例建模与分析用例
26、建模与分析取款超额取款extend3.3.泛化关系泛化关系 子用例可以继承父用例中的行为、关系和通信连接。即可以将子用例子用例可以继承父用例中的行为、关系和通信连接。即可以将子用例放置在父用例出现的地方,子用例与父用例之间的关系是泛化关系。例如,放置在父用例出现的地方,子用例与父用例之间的关系是泛化关系。例如,假设假设ATMATM可以用于支付账单,则它有两个子用例。一为可以用于支付账单,则它有两个子用例。一为Pay Credit BillPay Credit Bill,其一为,其一为Pay Utility BillPay Utility Bill。3 GIS软件工程软件工程用例建模与分析用例建
27、模与分析4.4.基本用例与抽象用例基本用例与抽象用例 一旦识别出系统的一组用例,一旦识别出系统的一组用例,就可以找到公共行为,通过提取这些用就可以找到公共行为,通过提取这些用例的公共行为,就可以形成一个基本用例(具体用例)和抽象用例。例的公共行为,就可以形成一个基本用例(具体用例)和抽象用例。前前者基本上就是主用例,它可以直接由某个参与者实例化。它本身可实现者基本上就是主用例,它可以直接由某个参与者实例化。它本身可实现可观测的用户目标。后则只能由基本用例实例化,因为它只包含在两个可观测的用户目标。后则只能由基本用例实例化,因为它只包含在两个或多个用例之间共享部分的公共行为,即从用户角度看,或多
28、个用例之间共享部分的公共行为,即从用户角度看,它不是一个完它不是一个完整的用户目标。整的用户目标。如前面讲过的账号登录用例,就是一个抽象用例,它不如前面讲过的账号登录用例,就是一个抽象用例,它不能完成一个完整的用户目标。能完成一个完整的用户目标。PayBillCredit Card BillUtility Bill泛化关系泛化关系3 GIS软件工程软件工程用例建模与分析用例建模与分析 用例可能还展现多个场景,普通场景以及可能的几个其他场景。用例可能还展现多个场景,普通场景以及可能的几个其他场景。基本基本用例可以用来表示普通场景用例可以用来表示普通场景,而抽象用例则可以用来描述其他场景。,而抽象
29、用例则可以用来描述其他场景。下图给出了一个下图给出了一个ATMATM系统的用例模型,取款是一个基本用例,是用户系统的用例模型,取款是一个基本用例,是用户成功登录系统的普通场景,指定交易类型,并输入取款的有效金额。成功登录系统的普通场景,指定交易类型,并输入取款的有效金额。而处而处理超额属于抽象用例理超额属于抽象用例,因为用户的银行账户中可能有足够的钱供其取出。,因为用户的银行账户中可能有足够的钱供其取出。取款超额取款基本用例中的扩展点基本用例中的扩展点 参与者可能直接调用基本用例,参与者可能直接调用基本用例,而抽象用例只能由基本用例实例化而抽象用例只能由基本用例实例化。抽象用例的实例化必须返回
30、到调用用例(基本用例),返回位置就是进抽象用例的实例化必须返回到调用用例(基本用例),返回位置就是进行调用的那个地方行调用的那个地方。抽象用例由从其他用例中提取出来的部分组成,。抽象用例由从其他用例中提取出来的部分组成,抽抽象用例类似于子程序调用,而基本用例就像是主程序。象用例类似于子程序调用,而基本用例就像是主程序。基本用例用于实基本用例用于实现某个用户目标的全部行为,现某个用户目标的全部行为,抽象用例实现基本用例的部分行为。抽象用例实现基本用例的部分行为。3 GIS软件工程软件工程用例建模与分析用例建模与分析ATM System存款超额取款取款查询余额账户登录extendincludein
31、cludeinclude显示显示extend和和include关系的用例图关系的用例图 只有在定义了所有只有在定义了所有用例之后,才能识别用例之后,才能识别和提取不同用例中相和提取不同用例中相似的行为,以形成抽似的行为,以形成抽象用例。设计师要比象用例。设计师要比用户更加关注抽象用用户更加关注抽象用例的提取。例的提取。用例的组织和流图用例的组织和流图或数据流图的开发并或数据流图的开发并不相似,用例的组织不相似,用例的组织关注的是用户目标,关注的是用户目标,数据流图关注的是数数据流图关注的是数据的输入与转换。据的输入与转换。3 GIS软件工程软件工程用例建模与分析用例建模与分析3.6.4 3.6
32、.4 编写用例文档编写用例文档 用例关注系统的外部方面,用例关注系统的外部方面,捕获帮助用户执行任务所需的系统功能和捕获帮助用户执行任务所需的系统功能和行为。但用例并不能描述系统如何执行功能需求或行为需求。行为。但用例并不能描述系统如何执行功能需求或行为需求。即它用于描即它用于描述系统用来做什么及谁将使用它,但不描述系统如何执行其功能的详细细述系统用来做什么及谁将使用它,但不描述系统如何执行其功能的详细细节。节。用例描述了一组动作序列,系统通过这些动作可以产生参与者能够观测用例描述了一组动作序列,系统通过这些动作可以产生参与者能够观测得到的结果。得到的结果。用例实例只是用例的一个特定示例(特定
33、系统服务),用例用例实例只是用例的一个特定示例(特定系统服务),用例不仅仅有普通场景组成,还可以包括变种场景。这种情况下需要使用不仅仅有普通场景组成,还可以包括变种场景。这种情况下需要使用extendextend用例表示这种变种场景。用例表示这种变种场景。1.1.开发用例描述:开发用例描述:用例图是软件设计师和最终用户之间进行沟通的辅助工具用例图是软件设计师和最终用户之间进行沟通的辅助工具。因此不要在。因此不要在描述中使用计算机行话和用户不熟悉的语言,描述中使用计算机行话和用户不熟悉的语言,应该使用用户能够适应和理应该使用用户能够适应和理解的清晰简洁语言解的清晰简洁语言,设计师在构造用例时应该
34、关注用户和系统服务。专家,设计师在构造用例时应该关注用户和系统服务。专家建议使用用例模板来描述用例。建议使用用例模板来描述用例。2.2.用例模板用例模板3 GIS软件工程软件工程用例建模与分析用例建模与分析 用例模板捕获不同的信息,包括用例成功执行的主路径,还包括包含用例模板捕获不同的信息,包括用例成功执行的主路径,还包括包含于其中的所有其它路径。下面是用例模板的一个示例,常常使用类似下面于其中的所有其它路径。下面是用例模板的一个示例,常常使用类似下面的模板按照一种标准格式来描述用例。的模板按照一种标准格式来描述用例。表表3.1 3.1 用例模板的组件用例模板的组件用例名称用例名称用例描述用例
35、描述/一般用动宾词组表示一般用动宾词组表示用例用例ID用例的用例的ID/是用例的唯一标识,其格式类似于是用例的唯一标识,其格式类似于“UC+编号编号”。超用例超用例用例所属的泛化用例的名称用例所属的泛化用例的名称/指用例所继承的父用例的名称,该值可指用例所继承的父用例的名称,该值可以为空。以为空。参与者参与者参加本用例的参与者名称参加本用例的参与者名称/包括所有参与本用例执行的参与者,如人包括所有参与本用例执行的参与者,如人或系统。或系统。简要描述简要描述在参与者完成工作时本用例的目的或角色在参与者完成工作时本用例的目的或角色/定义用例的范围和参与者定义用例的范围和参与者可观察到的结果。可观察
36、到的结果。前件前件在调用本用例之前必须满足的条件在调用本用例之前必须满足的条件/指定用例调用之前必须满足的某指定用例调用之前必须满足的某些约束。些约束。后件后件调用用例之后的结果,调用建立的条件调用用例之后的结果,调用建立的条件/后件用于确保在调用之后该后件用于确保在调用之后该用例正确执行了任务。用例正确执行了任务。3 GIS软件工程软件工程用例建模与分析用例建模与分析优先级优先级开发本用例的优先级开发本用例的优先级/从开发团队的角度出发,指出该用例在从开发团队的角度出发,指出该用例在开发日程表中的优先级。一般在架构上非常重要、不确定性较大,开发日程表中的优先级。一般在架构上非常重要、不确定性
37、较大,且风险较高的用例,被指派较高的优先级。且风险较高的用例,被指派较高的优先级。事件流事件流一步步描述参与者与系统之间的交互,同时为了实现某个用户目一步步描述参与者与系统之间的交互,同时为了实现某个用户目标必须按照指定秩序执行函数标必须按照指定秩序执行函数/用于捕获用例的外部可观察行用于捕获用例的外部可观察行为,并侧重于描述当调用用例的时候用户与系统之间的交互。为,并侧重于描述当调用用例的时候用户与系统之间的交互。其他流和例外其他流和例外在事件流中可能发生的主要的其他事件和例外在事件流中可能发生的主要的其他事件和例外/部分描述用例在部分描述用例在事件流中没有涵盖的例外情况下的执行过程。事件流
38、中没有涵盖的例外情况下的执行过程。非行为需求非行为需求系统的非行为需求,比如硬件和软件平台需求、性能、安全等系统的非行为需求,比如硬件和软件平台需求、性能、安全等假设假设关于该用例的所有假设关于该用例的所有假设问题问题关于本用例的所有重要问题关于本用例的所有重要问题来源来源与本用例相关的引用资料与本用例相关的引用资料/包括在开发用例时用到的参考资料、包括在开发用例时用到的参考资料、如备忘录、会议等如备忘录、会议等3 GIS软件工程软件工程用例建模与分析用例建模与分析3.6.5 3.6.5 优先用例优先用例 用例模型不仅对于需求规约非常有用,用例模型不仅对于需求规约非常有用,且对系统开发周期的不
39、同阶段且对系统开发周期的不同阶段规划工作进度也很有用。规划工作进度也很有用。根据软件系统的规模,应该首先开发那些在架构根据软件系统的规模,应该首先开发那些在架构上非常重要的用例上非常重要的用例,其次再开发那些可选的或者重要性相对较低的系统功,其次再开发那些可选的或者重要性相对较低的系统功能。在涉及大型软件系统的开发时,多个用例将并行开发,能。在涉及大型软件系统的开发时,多个用例将并行开发,如何进行最优如何进行最优化用例的调度开发,是一件困难的事情。化用例的调度开发,是一件困难的事情。确定优先用例的指导原则是确定优先用例的指导原则是尽可能早地降低风险和不确定性尽可能早地降低风险和不确定性。下面的
40、。下面的因素通常可以提高用例的优先级:因素通常可以提高用例的优先级:用例在架构上的重要性用例在架构上的重要性 使用了未经测试的新技术使用了未经测试的新技术 需要仔细研究的问题需要仔细研究的问题 能够比较明显地提高业务处理效率能够比较明显地提高业务处理效率 支持主要业务过程的用例支持主要业务过程的用例 在确定用例的优先级顺序时需要考虑上述因素。常使用高在确定用例的优先级顺序时需要考虑上述因素。常使用高-中中-低模糊方低模糊方案来为用例的优先级排序。案来为用例的优先级排序。3 GIS软件工程软件工程用例建模与分析用例建模与分析3.7 3.7 用例建模与分析过程用例建模与分析过程3.7.1 3.7.
41、1 概论概论 在进行用例建模和分析前,在进行用例建模和分析前,必须进行背景研究,以获取系统需求必须进行背景研究,以获取系统需求,研,研究业务工作流或该组织已有的计算机系统。用例分析的输入可以是问题究业务工作流或该组织已有的计算机系统。用例分析的输入可以是问题描述,或者是采访系统用户之后准备好的业务模型。描述,或者是采访系统用户之后准备好的业务模型。用例分析的输出是用例分析的输出是从用户角度描述系统整体需求的用例模型从用户角度描述系统整体需求的用例模型,用例模型包括:,用例模型包括:用例图、用用例图、用例描述和用例实用场景三部分。例描述和用例实用场景三部分。3.7.2 3.7.2 开发用例模型开
42、发用例模型 在进行用例分析之前,必须采访用户,以获取对用户业务活动更好的在进行用例分析之前,必须采访用户,以获取对用户业务活动更好的理解。然后将采访的成果总结成问题描述或业务模型,用例分析是一个理解。然后将采访的成果总结成问题描述或业务模型,用例分析是一个包含下列步骤的迭代和增量过程。包含下列步骤的迭代和增量过程。开发初始用例模型:开发初始用例模型:开发问题描述开发问题描述 识别主要的参与者与用例识别主要的参与者与用例 创建初始用例图创建初始用例图 简要地描述用例简要地描述用例3 GIS软件工程软件工程用例建模与分析用例建模与分析使用文本分析来识别使用文本分析来识别/提取候选业务(领域)类提取
43、候选业务(领域)类 细化用例模型:细化用例模型:开发基本用例描述开发基本用例描述在基本用例描述的基础上逐步求精,并确定在基本用例描述的基础上逐步求精,并确定extendextend、includeinclude和泛化关系和泛化关系开发实例场景开发实例场景优选用例优选用例 上述步骤不一定按顺序执行。上述步骤不一定按顺序执行。3.7.3 3.7.3 开发初始用例模型开发初始用例模型 初始用例模型提供了系统功能的概貌,可以用作系统的一致需求规约,初始用例模型提供了系统功能的概貌,可以用作系统的一致需求规约,它可以有效用于规划不同用例开发的优先级。它可以有效用于规划不同用例开发的优先级。3 GIS软件
44、工程软件工程用例建模与分析用例建模与分析3.7.4 3.7.4 识别主要参与者识别主要参与者 在识别系统的参与者时,需要找出以下问题的答案:在识别系统的参与者时,需要找出以下问题的答案:谁将使用系统的主要功能;谁将使用系统的主要功能;谁的日常工作需要系统的支持;谁的日常工作需要系统的支持;谁将使用系统的结果及提交数据;谁将使用系统的结果及提交数据;谁将需要维护、管理和操作该系统?谁将需要维护、管理和操作该系统?系统必须与什么硬件系统交互?系统必须与什么硬件系统交互?系统必须与其它什么计算机系统交互?系统必须与其它什么计算机系统交互?3.7.5 3.7.5 邮购案例研究邮购案例研究 1.1.开发
45、问题描述开发问题描述 同学们自己看同学们自己看 2.2.识别主要参与者识别主要参与者 主要参与者包括:客户服务助理;订单处理员和库存控制员,并针对主要参与者包括:客户服务助理;订单处理员和库存控制员,并针对3 GIS软件工程软件工程用例建模与分析用例建模与分析每类参与者进行简短描述:每类参与者进行简短描述:如订单处理员描述:订单处理员处理销售单,提交重订请求,向会如订单处理员描述:订单处理员处理销售单,提交重订请求,向会员请求必要的押金,安排会员的交货事宜。员请求必要的押金,安排会员的交货事宜。实质上是对每类参与者主要实质上是对每类参与者主要任务的描述。任务的描述。(1 1)识别用例指南)识别
46、用例指南 寻找用例是一个迭代过程,该过程从采访客户(参与者)开始。因寻找用例是一个迭代过程,该过程从采访客户(参与者)开始。因客户直接或间接地与系统交互,通常采用自底向上方法,涉及客户描述客户直接或间接地与系统交互,通常采用自底向上方法,涉及客户描述业务活动的场景。每个这样的描述都可能是一个用例,将这些潜在的用业务活动的场景。每个这样的描述都可能是一个用例,将这些潜在的用例详细描述、修改、分解成更小的用例或整合到自己更大的用例中去。例详细描述、修改、分解成更小的用例或整合到自己更大的用例中去。在从用户那里收集信息时需要注意以下问题:在从用户那里收集信息时需要注意以下问题:每个参与者完成的主要任
47、务是什么?每个参与者完成的主要任务是什么?系统操作和处理什么数据?系统操作和处理什么数据?系统需要解决什么问题?系统需要解决什么问题?参与者使用本系统想要实现什么目标?参与者使用本系统想要实现什么目标?当前系统存在的主要问题,预期系统如何简化用户的工作?当前系统存在的主要问题,预期系统如何简化用户的工作?3 GIS软件工程软件工程用例建模与分析用例建模与分析(2 2)命名用例指南)命名用例指南 用例命名由一个动词和一个名词或名词短语构成。用例名称描述可实现用例命名由一个动词和一个名词或名词短语构成。用例名称描述可实现可观察用户目标的描述。如下订单、存款、取款等。可观察用户目标的描述。如下订单、
48、存款、取款等。3.3.识别用例识别用例 通过检查邮购系统中各参与者的职责,可以识别以下用例:通过检查邮购系统中各参与者的职责,可以识别以下用例:检查订单状态检查订单状态 下订单下订单 处理退货处理退货 更新会员关系记录更新会员关系记录 归档会员关系归档会员关系 注册新会员注册新会员 处理订单处理订单3 GIS软件工程软件工程用例建模与分析用例建模与分析安排交货安排交货订购货物订购货物接收货物接收货物发送货物发送货物 完整的初始用例模型如下图所示。完整的初始用例模型如下图所示。3 GIS软件工程软件工程用例建模与分析用例建模与分析邮购系统邮购系统检查订单状态处理订单下订单安排发货处理退货订单处理
49、会员关系更新会员记录归档会员关系注册新会员库存管理订货接收货物发送货物客户服务助理订单处理员库存管理员初始用例模型4.4.创建初始用例图创建初始用例图 在大型项目开发中,一般按包组织用例,并按层次结构来组织包。在大型项目开发中,一般按包组织用例,并按层次结构来组织包。5.5.描述用例描述用例 简单描述每个用例,但在分析用例时,可对用例的简单描述进行扩展,简单描述每个用例,但在分析用例时,可对用例的简单描述进行扩展,进行详细描述。进行详细描述。如订单处理员:订单处理员从已经填好的销售订单中选择订单,系统如订单处理员:订单处理员从已经填好的销售订单中选择订单,系统显示销售订单的详细信息,以及会员的
50、电话号码和地址。在通过电话与显示销售订单的详细信息,以及会员的电话号码和地址。在通过电话与会员进行交单之后,订单处理员输入交货日期和时间,系统在给发货小会员进行交单之后,订单处理员输入交货日期和时间,系统在给发货小组的发送请求中记录交货日期和时间。组的发送请求中记录交货日期和时间。识别识别/细化候选业务类:细化候选业务类:在为每个用例准备好简要描述后,尝试识别系统的类。对象和类的识在为每个用例准备好简要描述后,尝试识别系统的类。对象和类的识别在整个系统的开发生命周期中是一个连续的过程,类模型在生命周期别在整个系统的开发生命周期中是一个连续的过程,类模型在生命周期的每个阶段都将得到细化。的每个阶