对象建模技术-用例图

1、第二章 需求(xqi)建模2.1 用例图 共五十八页本章(bn zhn)目标理解用例图的概念和内容(nirng)。理解活动图的概念和内容。能够使用用例图和活动图对一个简单的系统进行需求分析。 共五十八页章节(zhngji)安排2.1 用例图2.2活动(hu dng)图 共五十八页本节目标(mbio)理解需求分析与用例图之间的关系。掌握(zhngw)参与者、用例、关系的概念。学会通过分析需求画出用例图。 任务 分析本章的项目引入中的系统的需求，确定系统中的参与者和主要用例，并画出用例视图。共五十八页案例(n l)描述 HNS是一所以培养软件开发(kif)人才为目标的高等院校，为适应IT产业发展对

2、技术人才的需求，近年来扩大了招生规模，随着在校学生的增加，学院计划改善包括图书馆在内的各项教学设施，拟开发(kif)图书管理系统使其可以满足学生的要求。 共五十八页现实(xinsh)案例 建筑(jinzh)效果图 建筑(jinzh)规划图 建筑(jinzh)平面图共五十八页需求(xqi)需求是指系统必须符合的条件或具备的功能。需求问题是引起软件(run jin)项目的高风险率的最主要原因 缺乏需求对需求的不正确理解需求的不完整需求的变化 共五十八页需求(xqi)建模如何描述需求？图书管理系统的需求描述如下：1新书入库：当图书馆新进一批新书时，图书管理员需要登记入库信息，并为每一本新书制作一个图

3、书卡(书目条)。2借阅者信息维护：包括两个方面的工作：一是新读者的办证操作，二是读者基本信息的维护工作。3预约借书：当读者想借阅书不在时，可以通过(tnggu)预约的方式预定不在库的书籍。4借书：根据借阅者提供的书目编号，办理借书手续。5还书：根据借阅者归还书籍的书目编号，办理归还手续。6图书查询：读者在借书前，通过书目目录去查询所需书籍的书目编号。共五十八页需求(xqi)建模如何(rh)使用UML对需求建模呢？如图：共五十八页需求(xqi)建模使用UML对需求建模的优势(yush)？1、帮助项目人员按照实际情况对系统可视化。2、对系统的描述一目了然，方便与用户的交流和沟通。3、不易产生二义性

4、，利于系统的分析和设计。共五十八页用例图用例图是显示一组用例、参与者以及它们(t men)之间关系的图。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为 用例图常用来对需求建模，用例图是至关重要的，它的正确与否直接影响到客户对最终产品的满意度用例图的内容：参与者用例泛化、扩展和包含关系共五十八页参与者（Actor) 参与者( Actor) 是系统外部的一个人或物，它以某种方式(fngsh)参与了系统的执行过程。 参与者对系统而言总是外部的参与者在系统的不同组成部分可能扮演不同的角色 参与者用一个人形的图案表示 共五十八页识别(shbi)参与者 客户给销

5、售员发来传真订货(dng hu)， 销售员下班前将当日订货(dng hu)单汇总输入系统。 谁是系统的Actor？答案： 销售员共五十八页识别(shbi)参与者 寻呼台系统(xtng)。用户如果预定了天气预报，系统(xtng)每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？答案：用户，气温，时间都是Actor共五十八页识别(shbi)参与者 商品销售系统。顾客通过网络下单之后，系统计算出总计金额，税金，运费，并将数目传递给一个外挂的会计系统，该系统是另外购买(gumi)的。 有几个Actor？答案： 顾客(商品

6、销售系统)， 商品销售系统(会计系统)共五十八页参与者使用以下问题有助于发现系统的参与者谁使用系统？谁安装系统、维护系统？谁启动系统、关闭系统？谁从系统中获取信息，谁提供(tgng)信息给系统？在系统交互中，谁扮演了什么角色？系统会与哪些其他系统相关联？ 共五十八页用例 (UseCase)用例是对一组序列动作的描述，系统执行这些动作将对用例的参与者产生可以观察的结果。参与者和用例分别描述了“谁来做？”和“做什么？”这两个(lin )问题。 用例用实线的椭圆表示 共五十八页用例 识别用例的最好办法就是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。根据下面的一些问题来识别用例：参与者希望系

7、统提供什么功能；系统是否(sh fu)存储和检索信息；当系统改变状态时，是否通知参与者；是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件。 共五十八页识别(shbi)用例 Email客户端（如：outlook express），A在北京(bi jn)发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。共五十八页识别(shbi)用例 一个论坛类的应用，用户可以提问，别人(birn)来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例共五十八页用例如何判断一个用例是否是一个优秀的用例呢？用例是否描述了应该做

8、什么，而不是如何做？用例的描述是否采取(ciq)了参与者的视点？用例是否对参与者有价值？用例描述的时间流是否是一个完整场景？是否所有的参与者、用例都有相应的关联用例或关联参与者？ 共五十八页用例与事件(shjin)流 用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。 事件流可分为：基本(jbn)事件流 、备选事件流 共五十八页用例与事件(shjin)流银行自动取款机(ATM)系统(xtng)中的“提款”用例可以用事件流表述如下 提款基本事件流基本流步骤1：用户插入信用卡基本流步骤2：输入密码基本流步骤3：输

9、入提款金额基本流步骤4：提取现金基本流步骤5：退出系统，取回信用卡共五十八页用例与事件(shjin)流提款备选事件流 备选流一：用户可以在基本流中的任何一步选择退出， 转至基本流步骤5。 备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。 备选流三：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次(sn c)输入密码错误后，信用卡被系统没收，用例结束。 共五十八页用例的重要(zhngyo)元素2. 用例的粒度用例的粒度指的是用例所包含的系统(xtng)服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之

10、则包含的功能越少。如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。共五十八页用例的重要(zhngyo)元素比如(br)：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。共五十八页用例的重要(zhngyo)元素3. 用例规约对于每一个用例，我们(w men)还需要有详细的描述信息，以便让别人对于整

11、个系统有一个更加详细的了解，这些信息包含在用例规约之中。每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所

12、处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。共五十八页用例之间的关系(gun x) 泛化关系 包含(bohn)关系 扩展关系共五十八页用例之间的关系(gun x)泛化：同一业务目的的不同技术实现包含：提取公共交互，提高复用扩展：“冻结(dngji)”基用例以保持稳定 *通过关系提高用例复用共五十八页泛化(generalization) 当多个用例共同拥有一种类似的结构和行为的时候我们可以将它们的共性(gngxng)抽象成为父用例，其他的用例作为泛化关系中的

13、子用例。共五十八页用例之间的关系(gun x)泛化的示例：银行存款有两种方式，一种是银行柜台(guti)存款，一种是ATM机存款。在这里，银行柜台(guti)存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台(guti)存款”和“ATM机存款”为子用例。共五十八页泛化(generalization)泛化举例(j l)（一）： 共五十八页泛化(generalization)泛化举例(j l)（二）：共五十八页（三）例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以(ky)做成泛化关系表示： 共五十八页包含(bohn)(include)包

14、含是指基本(jbn)用例(base use case)会用到包含用例(inclusion)，具体地讲，就是将包含用例的事件流插入到基础用例的事件流中。包含用例是可重用的用例多个用例的公共用例。 共五十八页包含(bohn)(include)共五十八页用例之间的关系(gun x)在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽 象成为一个用例，然后让其他用例来包含这一用例。第二，某一个用例的功能过多(u du)、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含

15、的用例，以达到简化描述的目的。共五十八页包含(bohn)(include)包含(bohn)举例（一）：共五十八页包含(bohn)(include)包含(bohn)举例（二）：共五十八页扩展(kuzhn)(extend)将扩展用例的事件流在一定的条件下按照(nzho)相应的扩展点插入到基础用例中。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。扩展用例的行为是否被执行要取决于主事件流中的判定点。 共五十八页扩展(kuzhn)(extend)共五十八页扩展(kuzhn)(extend)扩展(kuzhn)举例（一）：共五十八页扩展(kuzhn)(extend)扩展(kuzhn)举例（二）：

16、共五十八页用例之间的关系(gun x)包含用例与扩展用例的区别(qbi)相对于基础用例，扩展用例是可选的，而包含用例则不是。如果缺少扩展用例，基础用例还是完整的，而缺少包含用例，则基础用例就不完整了。扩展用例的执行需要满足某种条件，而包含用例不需要。扩展用例的执行会改变基础用例的行为，而包含用例不会。共五十八页使用Rose创建用例的步骤(bzhu)说明需求分析“学生信息管理系统”部分功能性需求包括以下内容： （1）系统管理员登录后可以对班级的基本信息进行增加、删除、修改、查询等操作。学校领导登录后可以对班级基本信息进行查询操作。 （2）教师登录后可以对学生的考试成绩进行录入、删除、修改、查询等

17、操作。学生登录后可以对考试成绩进行查询操作。 （3）学生登录后可以了解所有选修(xunxi)课程的具体信息，可以根据自己的需要选择不同课程。系统管理员登录后可以增加、修改、查询、删除选修(xunxi)课程。 （4）系统管理员可以对账号进行创建、设置、查看、删除等操作。 共五十八页使用Rose创建(chungjin)用例的步骤说明2. 识别参与者对于一个学校来说，最重要的就是教育学生成才，所以我们首先要考虑到的参与者就是学生。要给学生上课，必然就需要教师。教师负责教育学生、并且在日常管理中可以查询学生的基本信息、查询学生的考试成绩。作为一个学校，除了教师和学生，还有不可或缺的就是校领导。为了便于

18、校领导掌握学校的基本情况(qngkung)，加强对学校的管理导. 不管什么系统，基本都会有比较专业的人员来负责管理系统，本系统也不例外。系统管理员除了负责维护系统的日常运行，还要进行录入学生基本信息、维护选课信息等工作。共五十八页使用(shyng)Rose创建用例的步骤说明3. 构建(u jin)用例模型系统管理员直接参与的用例为登录、找回密码、查看班级基本信息、删除班级基本信息、修改班级基本信息和录入班级基本信息。校领导直接参与用例登录、找回密码和查看班级基本信息。当登录过程中发生忘记密码的情况，就需要使用找回密码的功能来找回密码，而在正常情况下用不到找回密码这个功能所以用例找回密码”和用例

19、登录之间是扩展关系。 共五十八页使用Rose创建(chungjin)用例的步骤说明教师参与用例录入成绩、修改成绩、保存成绩、查询成绩、删除成绩和登录。学生参与用例登录和查询成绩。因为修改成绩和录入成绩的时候都要保存成绩，所以将保存成绩抽象出来(ch li)作为单独的一个用例。用例录入成绩、修改成绩和用例保存成绩之间是包含关系，用例找回密码和用例登录之间是扩展关系。共五十八页使用Rose创建(chungjin)用例的步骤说明学生作为参与者直接参与用例查看课程信息、按课程编号查看、按课程名查看、选择课程、删除已选课程、登录和找回密码。系统管理员参与用例登录、找回密码和“维护课程信息”。其中(qzh

20、ng)查看课程信息有两种方式，一种是按照课程名查看，另一种是按照课程编号查看。所以查看课程信息是父用例，而按照课程名查看和按照课程编号查看是子用例，他们之间的关系是泛化关系。用例找回密码和用例登录之间是扩展关系。共五十八页使用Rose创建用例的步骤(bzhu)说明系统管理员参与用例创建新账号、设置账号、设置账号基本信息、设置账号权限(qunxin)、查看账号和删除账号。在设置帐号时，主要分为设置账号的基本信息和设置账号的权限(qunxin)，为了便于修改和维护，将这两个功能分别抽象为两个用例。所以用例设置账号基本信息、设置账号权限(qunxin)和用例设置账号之间是包含关系。共五十八页任务(rn wu)解决系统中的主要活动，如下：读者需要借书籍(shj)，需要还书籍(shj)。读者可