用例图和类图课件

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,用例图和类图,桐城师范高等专科学校 孙兰兰,软件工程与UML案例解析课程,一、建立用例模型,用例（Use Case）是一种描述系统需求的方法，其描述的过程就是用例建模。,用例图的主要构成元素：,参与者（,Actor,）,参与者指存在于系统外部并与该系统发生交互的人或者其他系统，他们代表的是系统的使用者或者使用环境。,用例（,User Case,）,用例表示系统所提供的服务，它定义了系统是如何被参与者所使用的，描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。,关联（,Association,）,关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例）。,用例图的组成元素,用例图的组成元素包括：参与者、用例、一个方框和一些表示关系的连接线。,所有的用例都位于方框之内，该方框称为“系统边界”,参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的。,识别参与者,参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色,参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟。,其它系统：当系统需要与其它系统交互时，如,ATM,柜员机系统中，银行后台系统就是一个参与者；,硬件设备：如果系统需要与硬件设备交互时，如在开发,IC,卡门禁系统时，,IC,卡读写器就是一个参与者；,时钟：当系统需要定时触发时，时钟就是参与者。,怎样识别参与者？,识别参与者可以从以下问题入手：,系统开发完成后，那些人会使用这个系统？,系统需要从那些人或其他系统中获取数据？,系统为那些人或其他系统提供数据？,系统是否需要与其他系统交互？,系统由谁来维护或管理并保证其正常运行？,系统需要应付（处理）那些硬件设备？,谁（或什么）对系统运行的结果感兴趣？,有没有其他自动发生的事件？,识别参与者的用例案例,酒店管理系统（前台）,事件描述：客户前来酒店预定座位，由前台服务人员为其检查座位信息。如果客满或客户对座位不满意，则进入等待队列；如果有满意座位，则由前台服务人员为其安排座位。客户完成消费后，至前台服务人员处办理结账，其可选择现金付款或刷卡消费2种结账方式。,酒店管理系统用例图,（,识别参与者,）,酒店管理系统用例图,（,初稿,）,用例之间的关系,用例之间的关系：,包含关系（,include,）：,被包含的用例不是孤立存在的，通常作为某些包含它的更大的基用例的一部分出现。,扩展关系（,extend,）：,基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展,。,泛化关系（,generalization,）：,可以用来表示参与者与参与者之间，用例与用例之间的特殊,/,一般化关系（一般具有互斥性）。,酒店管理系统用例图,读图小结,这张用例图定义了三个基用例：预订座位、安排座位和处理结账。,客户通过“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。,总台服务员在客户到酒店时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。,当客户要离开酒店时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。,想一想,ATM,机服务中，无论取款、存款、还是转账，系统都会提示“是否打印回执单”，那么“打印回执”这个单独用例与取款、存款、转账这三个事件之间是什么关系？,对于电话业务，在基本通话事件中，还有一些增值业务，如：呼叫等待、呼叫转移、短信通知机主,它们之间是什么关系？,在有收银台的商场购物与在自动售货机上购物，购物者是否都作为售货系统的参与者？,二、建立分析模型,面向对象分析产生分析模型。分析时用例模型作为输入，对用例模型进行分析，把系统分解为相互协作的分析类边界类、控制类和实体类。通过类图来描述对象、对象的属性和对象之间的关系，产生系统的静态模型。,类图在UML中由类的名称、类的属性、类的操作三个部分组成。,类图的需求分析,小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。,该系统能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。,类图的需求分析,小王,是一个爱书之,人,，家里各类,书籍,已过千册，而平时又时常有,朋友,外借，因此需要一个,个人图书管理系统,。,该,系统,应该能够将书籍的,基本信息,按,计算机类,、,非计算机类,分别建档，实现按,书名,、,作者,、,类别,、,出版社,等,关键字,的组合,查询功能,。在使用该系统,录入新书籍,时,系统,会自动按,规则,生成,书号,，可以,修改信息,。该系统还应该能够对书籍的,外借,情况进行,记录,，可对,外借情况列表,打印。另外，还希望能够对书籍的,购买金额,、,册数,按,特定时间周期,进行统计。,筛选备选类(分析过程),“小王”、“人”很明显是系统外的概念，无须对其建模；,而“个人图书管理系统”和后面的“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；,很明显，“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”等则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。,筛选备选类(分析过程),“基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需专门对其建模；,“查询功能”、“录入新书籍”、“修改信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此可以先将其淘汰，再将其作为书籍列表的成员方法；,“计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；,筛选备选类(分析过程),“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”,借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；,筛选备选类(分析过程),“购买金额”、“册数”都是统计的结果，都只是一个数字，因此不用将其建模，只需做为书籍的属性之一即可。而“特定时间周期”则是统计的范围，也无需将其建模，可以加以函数约束；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类,书籍列表，它是执行统计的主体。,得到候选类,书籍,计算机类书籍,非计算机类书籍,借阅记录,借阅记录列表,书籍列表,关联分析，建模,多重性分析，再建模,职责分析,书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。,书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。,借阅记录类：借阅人（朋友）、借阅时间。,借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录,三、用例图和类图的区别,1.用例图(Use Case Diagram),用例视图强调从系统的外部参与者,(,主要是用户,),的角度看到的或需要的系统功能。,用例视图描述系统应该具备的功能，也就是外部参与者所需要的功能，但是并不描述这些功能在系统内部的具体实现。,用例是系统中的一个功能模块，一个用例对应着一个功能模块，系统要提供的功能都是在用例视图中描述的。,参与者可以是一个用户或是一个系统，一个参与者可以参与多个用例的执行，用例视图列出了哪个参与者参与了哪些用例的执行。,三、用例图与类图的区别,2.类图(Class Diagram),类图显示了系统的静态结构，表示不同的实体,(,人、事物,),是如何彼此相关联的。,绘制类图时使用由,3,个部分组成的矩形来描述，最上面的矩形部分显示类的名称，中间矩形部分显示了类的各种属性，下面的矩形部分显示了类的操作或方法。,在类图中要注意的是如何描述类与类之间的关系。类与类之间通常有关联关系、依赖关系和泛化关系。,绘图方法（学生注册事件）,一、用例图：,二、类图：,类的名称,类的属性,类的操作,参与者,用例,关联,课后作业,根据上例中的“个人图书管理系统”需求描述，绘制出其用例图。,查看答案,个人图书管理系统,欢 迎 指 导！,桐城师范高等专科学校 孙兰兰,