餐馆系统的业务建模教学.pptx

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,第4章 餐馆系统业务建模,餐馆系统的业务建模教学,第1页,4.1,非正式需求,经过改进为用户预定和分配餐桌过程，支持一家餐馆日常经营,预约单中每一行对应餐馆中一张特定餐桌。预约是对特定一个餐桌登记，每个预约中统计有“餐具”数目，或者预期进餐者数目，这么就能够分配一个大小适当餐桌。,这家餐馆在晚间供给三次餐点，称为“简餐”、“正餐”和“夜点”时段。能够预约跨多个时段时间。,每个预约中要统计联络人姓名和电话。,修改餐桌、电话取消预定、未预约用户处理,餐馆系统的业务建模教学,第2页,4.1.1 对计算机化系统需要,手工系统有很多问题：速度慢、预约单很快变乱、没有备份系统、获取管理数据不方便,新系统应该和现有预约单显示一样信息，而且有大致相同格式，使餐馆员工易于转换到新系统。,统计新预约和修改已经有预约之后应该马上更新显示，使餐馆员工在工作时总能使用可取得最新信息,系统必须易于统计餐馆营业时发生有意义事情,餐馆系统的业务建模教学,第3页,4.1.1 定义一次迭代,一个系统第一次迭代应该只交付足够使系统提供一些确实有商业价值关键功效,在随即迭代中再开发其它功效,餐馆系统的业务建模教学,第4页,4.2 用例建模,用例视图是UML中起着支配作用视图，描述系统外部可见行为,基于系统需求用例视图驱动和约束着后续开发,用例视图展示是系统功效结构化视图，视图定义了参加者和参加者能够参加用例,参加者模型化了用户与系统进行交互时可能充当角色,用例描述了用户使用系统能够完成一项特定任务,用例视图应该包含一组定义了该系统完整功效用例，或者最少定义了当前迭代所要求功效用例,用例视图应该是客户、最终用户、领域教授、测试人员和任何其它包括系统人员，不需要详细了解系统结构和实现就轻易了解,餐馆系统的业务建模教学,第5页,4.2.1 用例,一组用例是一个系统用户能够使用系统完成不一样任务,能够经过考虑在系统实现后餐馆员工能够用它来做什么，简单地草拟出这次迭代一组初步用例,这些用例所支持主要任务：,(1)统计一个新预约信息(“统计预约”),(2)取消一个预约(“取消预约”),(3)统计一位用户到来(“统计抵达”),(4)将一位用户从一张餐桌移到另一张餐桌(“调换餐桌”),一个用例描述了系统能够为一个特定用户做些什么，描述是一个自包含任务,餐馆系统的业务建模教学,第6页,4.2.2 参加者,一个用例描述了系统及其用户之间一类交互,系统通常有不一样种类用户，他们能够执行系统功效不一样子集,人与系统在进行交互时能够担任不一样角色称为参加者,餐馆预约系统中用例能够分为两组：,(1)维护提前预约信息相关用例,(2)需要在餐观营业时执行任务,参加者和用户之间不存在一对一对应,餐馆系统的业务建模教学,第7页,4.2.3 用例图,以图解形式概括了系统中不一样参加者和用例，并显示了哪些参加者能够参加哪些用例,参加者用一个像人一样图标表示,用例用包含有用例名字椭圆表示,UML允许在用例图中包含更多结构，来定义用例之间以及参加者之间各种关系,在实践中不值得花费很多时间细化用例图，额外关系对后面开发起不到很大作用,餐馆系统的业务建模教学,第8页,Record booking,Cancel booking,Record arrival,Table transfer,Receptionist,Head Waiter,初始用例图,餐馆系统的业务建模教学,第9页,4.3 描述用例,用例描述了系统和它用户之间在一定层次上完整交互,在用例不一样实例中将发生什么样细节，会在很多方面有所不一样,一个用例实例中可能会出现差错，将不能到达原来目标,一个用例完整描述必须指明，在用例全部可能实例中可能发生什么,用例描述可能包含大量信息，需要某种系统方法来统计这些信息,UML没有定义一个描述用例标准形式,许多开发人员定义了用例描述模板,餐馆系统的业务建模教学,第10页,4.3.1 事件路径,用例描述必须定义在执行用例时用户和系统之间可能交互,基本事件路径：用例主要目标能够没有任何问题而且不中止地抵达,可选事件路径：一些可选功效会被调用,例外事件路径：发生错误时处理,餐馆系统的业务建模教学,第11页,统计预约：基本事件路径,(1)接待员输入要预约日期；,(2)系统显示该日预约；,(3)有一张适当餐桌能够使用：接待员输入用户姓名和电话号码、预约时间、用餐人数和餐桌号；,(4)系统统计并显示该预约。,事件路径要统计主要事情是用户输入到系统信息，而不是该信息是怎样取得。,包含上下文交互会降低用例可复用性,餐馆系统的业务建模教学,第12页,统计预约没有可用餐桌：可选事件路径,(1)接待员输入要求预约日期,(2)系统显示该日预约,(3)没有适当餐桌能够使用，用来终止,可选事件路径描述情况，能够作为营业一个正常部分出现，它们并没有指出产生了误解，或者发生了错误,因为一个错误和用户疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述,餐馆系统的业务建模教学,第13页,统计预约餐桌过小：例外事件路径,(1)接待员输入要求预约日期,(2)系统显示该日预约,(3)接待员输入用户姓名和电话号码、预约时间、用餐人数和餐桌号,(4)输入预约用餐人数多于餐桌能容纳人数，于是系统发出一个警告信息问询用户是否想要继续预约,(5)假如回答“否”，用例将不进行预约而终止,(6)假如回答“是”，预约将被输入，并附有一个警告标志,不一样类型事件路径之间区分是非正式，它能够使用例总体描述组织得更轻易了解,不值得花过多时间去决定一个特定情况是可选还是例外，更主要是一定要确认给出了必须行为详细描述,餐馆系统的业务建模教学,第14页,4.3.2 用户界面原型,在用例描述中详述用户界面不是个好主意,用例描述重点是定义系统和用户之间交互总体结构，而包含用户界面细节会使之不清楚,对用户界面像什么样子有一个大约看法，可能会有利于了解用例描述,餐馆系统的业务建模教学,第15页,Booking,Date:10 Feb,Booking System,18,:30,19,:30,20,:30,21,:30,22,:30,23,:30,24,1,2,3,4,5,预约系统主屏幕一个原型,Ms Blue 0121 7648 4495,Covers:3,Mr White 0865 364795,Covers:2,Covers:4,Covers:2,Mr Black 020 8453 7646,Walk-in,餐馆系统的业务建模教学,第16页,4.4,组织用例模型,统计抵达：基本事件路径,(1)侍者领班输入当前日期,(2)系统显示当日预约,(3)侍者领班确认一个选定预约已经抵达,(4)系统对此进行统计并更新显示器，将用户标识为已抵达,餐馆系统的业务建模教学,第17页,统计抵达没有提前预定：可选事件路径,(1)侍者领班输入当前日期,(2)系统显示当日预约,(3)系统中没有统计该用户预约，所以侍者领班输入预约时间、用餐人数和餐桌号，创建一个未预约登记,(4)系统统计并显示新预约,餐馆系统的业务建模教学,第18页,4.4.1 用例包含,显示预约：基本事件路径,(1)用户输入一个日期,(2)系统显示当日预约,统计预约：基本事件路径(修改),(1)接待员执行“显示预约”用例,(2)接待员输入用户姓名和电话号码、预定时间、用餐人数以及预留餐桌,(3)系统统计和显示新预约,餐馆系统的业务建模教学,第19页,Record booking,Display booking,Receptionist,用例包含,餐馆系统的业务建模教学,第20页,4.4.2 参加者泛化,参加者之间泛化含义是，特化参加者能够参加和更普通参加者关联全部用例,能够指派给特化参加者更多责任,餐馆系统的业务建模教学,第21页,Display booking,Record booking,Record arrival,Receptionist,Staff,Head Waiter,参加者泛化,餐馆系统的业务建模教学,第22页,4.4.3 用例扩展,统计未预约用户：基本事件路径,(1)侍者领班执行“显示预约”用例,(2)侍者领班输入时间、用餐人数和分配给用户餐桌,(3)系统统计并显示新预约,包含依赖性对这种情况并不适合，因为在“统计未预约用户”中指定交互不是在每次执行“统计抵达”时都执行,餐馆系统的业务建模教学,第23页,“统计未预约用户”用例只是在“统计抵达”一些情况下被执行,Record walk-in,Record arrival,Receptionist,用例扩展,餐馆系统的业务建模教学,第24页,4.5 完成用例模型,取消预定：基本事件路径,(1)接待员选择要求预约,(2)接待员取消该预约,(3)系统询问接待员确认取消,(4)接待员回答“是”，系统记录用消并更新显示,这个事件路径没有清楚地详细说明用户怎样完成这些任务，这为系统能提供多种方式完成该任务留下不受限制可能性,餐馆系统的业务建模教学,第25页,调换餐桌：基本事件路径,(1)侍者领班选择需要预约,(2)侍者领班改变该预约餐桌分配,(3)系统统计改变并更新显示,可选和例外事件路径能够从餐馆经营规则得到：和取消一样，应该不可能将一个过期预约调换到新餐桌，也应该不可能将一个预约移到已占用餐桌,餐馆系统的业务建模教学,第26页,4.5.1 一个用例模型何时完成,用例分析是一项非正式技术，在一定时间之后再花时间寻求对模型改进时会降低回报,这对包含关系和扩展关系尤其适用：这些关系通常与从用例产生设计结构特征并不相当，所以缺乏一个可能依赖后果并不严重,餐馆系统的业务建模教学,第27页,Record booking,Cancel booking,Display bookings,Receptionist,Record arrival,Record walk-in,Staff,Table transfer,Head Waiter,完成用例图,餐馆系统的业务建模教学,第28页,4.6 领域建模,领域模型：显示最主要业务概念和它们之间关系类图,领域模型用关联和泛化显示了这些概念之间关系。领域模型通常不包含操作,有时极难决定是应该将一个特殊信息作为一个类还是作为一个属性包含在领域模型中,餐馆系统的业务建模教学,第29页,要求关联重数，每个预定是由一个用户进行，这个人姓名和电话由系统统计，不过每个用户能够进行多个预定,Customer,Reservation,Makes,1,*,name,phoneNumber,用户和预定建模,餐馆系统的业务建模教学,第30页,Customer,Reservation,Makes,1,*,name,phoneNumber,covers,date,time,Table,places,1,*,Reservations for the same,table must not overlap.,包含预定特征领域模型,餐馆系统的业务建模教学,第31页,Customer,Makes,1,*,covers,Reservation,Walk-in,Booking,date,time,places,Table,*,1,Bookings for the same,table must not overlap.,name,phoneNumber,包含未预约领域模型,餐馆系统的业务建模教学,第32页,4.6.1 领域模型正确性,要证实一个模型正确性或者即使是一个模型优于另一个模型，要更困难一些,建立领域模型目标是确定一组对象，他们能够以有效地支持整个系统必须交付功效方式进行交互。所以，要评价领域模型中可供选择方式，能够从实现这一点程度来进行,而且不能经过孤立地检验领域模型而简单地评定，还必须经过观察领域模型中类实例之间交互实际上是怎样支持需要功效，考虑模型实际上表示了什么,餐馆系统的业务建模教学,第33页,4.7 术语表,预约(Booking)：分配一张餐桌给一行用餐者进餐,用餐人数(Covers)：预定未来用餐人数,用户(Customer)：进行预定人,用餐者(Diner)：在餐馆用餐人,位子(Places)：在一张特定餐桌能够就座用餐者人数,预定(Reservation)：提前预约一个特定时间餐桌,未预约(Walk-in)：没有提前进行预约,餐馆系统的业务建模教学,第34页,4.8 本章小结,在业务建模活动结束时，系统文档包含一个用例模型、对各个用例文字描述、一个关键术语术语表以及一个领域模型,用例图描述了参加者和用例以及他们之间各种关系,用例表示了一类用户能够利用系统完成经典任务,参加者表示了用户在与系统交互时能够充当角色。参加者和用例关联，表示以给定角色工作用户能够执行哪些任务。参加者能够经过泛化相关，以明确地表示它们共享能力,一个用例能够包含另一个用例：意思是被包含用例要求交互组成包含用例每次执行一部分,餐馆系统的业务建模教学,第35页,一个用例能够扩展另一个用例：意思是扩展用例要求交互组成被扩展用例一次执行一个可选部分,用例描述是文字形式文档，详细描述在执行用例时在用户和系统之间能够发生交互,每个用例描述包含一个基本事件路径，描述用例“正常”进行，以及一组可选和例外事件路径,领域模型显示主要业务概念、它们之间关系和由系统维护业务数据。领域模型表示为类图，普通只显示类、属性、关联以及泛化,术语表定义业务领域中主要术语，为每个术语提供一个一致同意定义，定义了应该在用例描述中使用特定业务词汇,餐馆系统的业务建模教学,第36页,