1、我们的进度，在这里1.根据访谈内容，进行业务用例建模提交内容1. 业务用例图我们的进度，在这里我们的进度，在这里什么是用例图（Use Case Diagram）用例图的应用用例图的组成参与者、用例的识别用例建模技术我们的进度，在这里在在UMLUML中，一个用例模型由若干个中，一个用例模型由若干个用例图用例图(use (use case diagram)case diagram)描述。用例图是显示一组用例、描述。用例图是显示一组用例、参与者以及它们之间关系的图参与者以及它们之间关系的图。用例图是从用户的角度用户的角度来描述对软件产品的需求，分析产品的功能和行为功能和行为，因此，对整个软件开发过程
2、而言，用例图是至关重要的。用例图定义和描述了系统的外部可见行为外部可见行为，是分析、设计直至组装测试的重要依据。让用户参与前期的系统分析与设计。实现实现测试测试需求需求分析和设计分析和设计Use Cases 把所有这些过程绑到一起把所有这些过程绑到一起用例（Use Case）参与者（Actor）关系(Relationship)参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者可能是人、另外一个系统、时间的流逝等。UML中，参与者用“人形”图标来表示，名字写在图标的下方。参与者用例（用例（use case）一个用例是用户与计算机之间的一一个用例是用户与计算机之间的一次典型交互
3、作用。在次典型交互作用。在UMLUML中中, ,用例被定义成系统执行的用例被定义成系统执行的一系列动作（功能）一系列动作（功能） 。参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题。 每个用例都必须有一个惟一的名字以区别于其他用例。用例用一个椭圆来表示，用例的名字可以书写在椭圆的内部或下方。用例的UML图标如图所示。 建立系统用例模型的过程就是对系统进行功能需求分析的建立系统用例模型的过程就是对系统进行功能需求分析的过程。过程。定义定义系统系统确定执行确定执行者和用例者和用例描述执行者描述执行者和用例关系和用例关系确认确认模型模型确定系确定系统范围；统范围；分析系分析系统功能。统功能
4、。 执行者通常是使执行者通常是使用系统功能的外部用系统功能的外部用户或系统。用户或系统。 用例是一个子系用例是一个子系统或系统的一个独统或系统的一个独立、完整功能。立、完整功能。各模型元素各模型元素之间有：关之间有：关联、使用、联、使用、扩展及泛化扩展及泛化等关系。等关系。确认用例模型确认用例模型与用户需求的与用户需求的一致性，通常一致性，通常由用户与开发由用户与开发者共同完成。者共同完成。识别参与者识别用例识别用例间的关系用例阐述谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要和
5、那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴趣时间、气温等内部外部条件 客户给销售员发来传真订货， 销售员下班前将当日订货单汇总输入系统。 谁是系统的Actor？答案： 销售员 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的。 有几个Actor？答案： 顾客(商品销售系统)， 商品销售系统(会计系统)例：图书管理系统的例：图书管理系统的参与者参与者：借阅者（借阅者（BorrowerBorrower）图书管理员（图书管理员（Librarian）参与者之间也可以象类一样存在泛化或者依赖关系。用例A雇员用例B经理
6、用例C如系统中经理可以参加雇员的所有用例参与者希望系统提供什么功能；系统是否存储和检索信息；如果是，这个行为由哪个参与者触发；当系统改变状态时，是否通知参与者；是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。 Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例1. 泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，
7、这被称为用例泛化。2. 包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。3. 扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。4.关联关系：关联关系表示参与者与用例之间的通信。四种关系的UML图释用例1用例2用例1用例2用例1用例2参与者用例1包含关系扩展关系泛化关系关联关系泛化：同一业务目的的不同技术实现包含：提取公共交互，提高复用扩展：“冻结”基用例以保持稳定 *通过关系提高用例复用通过关系提高用例复用 当多个用例共同拥有一种类似的结
8、构和行为的时候我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。泛化关系：用例可以被特别列举为一个或多个子用例，这被称做用例泛化。当父用例能够被使用时，任何子用例也可以被使用。如在下图中，订票是电话订票和网上订票的抽象。 客户订票电话订票网上订票泛化举例（一）： 泛化举例（二）：包含是指基本用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例多个用例的公共用例。 包含举例（一）：包含举例（二）：将扩展用例的事件流在一定的条件下按照相应的扩展点插入到基础用例中。 基础用例不必知
9、道扩展用例的任何细节，它仅为其提供扩展点。 扩展用例的行为是否被执行要取决于主事件流中的判定点。 扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；b.表明只在特定条件特定条件（如例外条件）下才执行的分支流； 超期赔偿图书归还(from 系统分析)图书馆工作人员(from 系统分析)扩展举例（一）：扩展举例（二）：包含用例与扩展用例的区别相对于基础用例，扩展用例是
10、可选的，而包含用例则不是。如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。扩展用例的执行需要满足某种条件，而包含用例不需要。扩展用例的执行会改变基础用例的行为，而包含用例不会。供货供货买买饮料饮料取货款取货款客户客户供货人供货人收银员收银员自动售货系统售货售货供货供货取货款取货款顾客顾客供货人供货人收银员收银员售散装售散装饮料饮料打开机器打开机器关闭机器关闭机器打开机器打开机器关闭机器关闭机器自动售货机系统自动售货机系统现在我们要对网上报名系统进行业务用例建模。在上次进行的访谈中，我们得知：1.该系统的使用者：各省队参赛报名负责人（各省队用户）和中国赛艇协会管理人员
11、。2.各省队用户的主要业务：（1）查看赛事信息（2）报名： i）参赛单位报名 ii）参赛运动员报名我们的进度，在这里3.中国赛艇协会管理人员的主要业务：（1）各省队用户管理（2）单位管理（3）运动员管理（4）竞赛项目管理（5）报名管理 i）报名单位 ii）报名运动员（6）赛事管理 i）赛事基本信息 ii）主要比赛项目我们的进度，在这里根据以上访谈内容，我们识别出参与者和用例。在Rational Rose中建模。打开模型：网上报名系统在UseCase中新建一个包，命名为“领域分析”，在其中创建一个用例图（UseCase Diagram，命名为：业务用例图我们的进度，在这里我们的进度，在这里注意：
12、这个用例图是从用户业务的视角出发，用来进行业务用例建模的。在今后的需求分析阶段，我们会从系统的视角来进行系统用例建模。我们的进度，在这里注意：这个用例图是从用户业务的视角出发，用来进行业务用例建模的。在今后的需求分析阶段，我们会从系统的视角来进行系统用例建模。 订票 旅客 查看今日航班 处理订票 旅客 显示今日航班1.完成系统用例建模.提交内容1. 系统用例图我们的进度，在这里我们的进度，在这里1. 泛化关系（Generalization）：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。2. 包含关系（Include）一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行
13、为作为自身行为的一部分，这被称作包含关系。3. 扩展关系（Extend）：一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系，扩展关系是把新行为插入到已有用例的方法。依赖泛化关联关系：关联关系表示参与者与用例之间的通信。系统用例“显示赛事信息”是对业务用例“查看赛事信息”的系统实现。系统显示赛事名称、举办地、报名时间、状态。我们的进度，在这里在业务用例“报名”的中，有两个泛化用例参赛单位报名和参赛运动员报名。在”参赛单位报名”用例中，应该提供相应的三种操作给用户，因此，得到系统用例“新增参赛单位信息”、“删除参赛单位信息”、“修改参赛单位信息” 。这三个系统用例是系统用例“参赛单位报名”
14、的泛化用例。在”参赛运动员报名”用例中，应该提供相应的三种操作给用户，因此，得到系统用例“新增参赛运动员信息”、“删除参赛运动员信息”、“修改参赛运动员信息” 。这三个系统用例是系统用例“参赛运动员报名”的泛化用例。我们的进度，在这里我们的进度，在这里报名省队用户参赛单位报名参赛运动员报名新增参赛运动员信息修改参赛运动员信息删除参赛运动员信息新增参赛运动员信息修改参赛运动员信息删除参赛运动员信息进一步分析省队用户管理。在本系统中，应该提供相应的四种操作给管理员，因此，得到系统用例“添加省队用户”、“删除省队用户”、“修改省队用户信息” 、“查询省队用户信息” 。这四个系统用例是系统用例“省队用
15、户管理”的泛化用例。图示表示如下：我们的进度，在这里我们的进度，在这里省队用户管理管理员新增省队用户信息修改省队用户信息删除省队用户信息查询省队用户信息在业务用例“报名管理”的中，有两个泛化用例“报名单位管理”和“报名运动员管理”。在”报名单位管理”用例中，应该提供相应的两种操作给用户，因此，得到系统用例“新增报名单位信息”、“查询报名单位信息” 。这两个系统用例是系统用例“报名单位管理”的泛化用例。在”报名运动员管理”用例中，应该提供相应的两种操作给用户，因此，得到系统用例“修改报名运动员信息”、“查询报名运动员信息” 。这两个系统用例是系统用例“报名运动员管理”的泛化用例。我们的进度，在这
16、里我们的进度，在这里报名管理管理员报名运动员管理报名单位管理新增报名单位信息查询报名单位信息修改运动员信息查询运动员信息为了保证该系统的使用安全，系统需要为工作人员提供两个操作“登录”和“注销”，其中，系统用例“登录”是所有其他系统用例的包含（include）用例，而其他系统用例是“注销”的包含（include）用例。而这两个系统用例并没有对应的业务用例。由此可见，业务用例描述的是用户的实际业务情况。而系统用例描述的是系统为用户的操作。每一个业务用例都必须在系统用例中找到对应。我们的进度，在这里我们的进度，在这里报名参赛单位报名参赛运动员报名新增参赛运动员信息修改参赛运动员信息删除参赛运动员信
17、息新增参赛运动员信息修改参赛运动员信息删除参赛运动员信息显示赛事信息注销登陆省队用户我们的进度，在这里报名管理报名运动员管理报名单位管理新增报名单位信息查询报名单位信息修改运动员信息查询运动员信息省队用户管理新增省队用户信息修改省队用户信息删除省队用户信息查询省队用户信息单位管理竞赛项目管理赛事管理主要比赛项目管理赛事基本信息管理注销登陆管理员在过去三次课的学习和工作任务完成中，大家可以发现，同一种UML图形可以反映不同的视角。用例图的视角：视角1：站在用户的角度看待用户的业务情况业务用例图视角2：站在用户的角度看待系统的功能系统用例图我们的进度，在这里在本次课中，我们学习了以下知识： 利用用例图进行业务建模和系统建模 使用Rational Rose绘制用例图
