餐馆系统的业务建模

第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页RecordbookingCancelbookingRecordarrivalTabletransferReceptionistHeadWaiter初始用例图第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:10FebBookingSystem

18:3019:3020:3021:3022:3023:302412345预约系统主屏幕一个原型MsBlue012176484495Covers:3MrWhite0865364795Covers:2Covers:4Covers:2MrBlack02084537646Walk-in第16页4.4组织用例模型统计抵达：基本事件路径(1)侍者领班输入当前日期(2)系统显示当日预约(3)侍者领班确认一个选定预约已经抵达(4)系统对此进行统计并更新显示器，将用户标识为已抵达第17页统计抵达——没有提前预定：可选事件路径(1)侍者领班输入当前日期(2)系统显示当日预约(3)系统中没有统计该用户预约，所以侍者领班输入预约时间、用餐人数和餐桌号，创建一个未预约登记(4)系统统计并显示新预约第18页4.4.1用例包含显示预约：基本事件路径(1)用户输入一个日期(2)系统显示当日预约统计预约：基本事件路径(修改)(1)接待员执行“显示预约”用例(2)接待员输入用户姓名和电话号码、预定时间、用餐人数以及预留餐桌(3)系统统计和显示新预约第19页RecordbookingDisplaybookingReceptionist<<include>>用例包含第20页4.4.2参加者泛化参加者之间泛化含义是，特化参加者能够参加和更普通参加者关联全部用例能够指派给特化参加者更多责任第21页DisplaybookingRecordbookingRecordarrivalReceptionistStaffHeadWaiter<<include>><<include>>参加者泛化第22页4.4.3用例扩展统计未预约用户：基本事件路径(1)侍者领班执行“显示预约”用例(2)侍者领班输入时间、用餐人数和分配给用户餐桌(3)系统统计并显示新预约包含依赖性对这种情况并不适合，因为在“统计未预约用户”中指定交互不是在每次执行“统计抵达”时都执行第23页“统计未预约用户”用例只是在“统计抵达”一些情况下被执行Recordwalk-inRecordarrivalReceptionist<<extend>>用例扩展第24页4.5完成用例模型取消预定：基本事件路径(1)接待员选择要求预约(2)接待员取消该预约(3)系统询问接待员确认取消(4)接待员回答“是”，系统记录用消并更新显示这个事件路径没有清楚地详细说明用户怎样完成这些任务，这为系统能提供多种方式完成该任务留下不受限制可能性第25页调换餐桌：基本事件路径(1)侍者领班选择需要预约(2)侍者领班改变该预约餐桌分配(3)系统统计改变并更新显示可选和例外事件路径能够从餐馆经营规则得到：和取消一样，应该不可能将一个过期预约调换到新餐桌，也应该不可能将一个预约移到已占用餐桌第26页4.5.1一个用例模型何时完成用例分析是一项非正式技术，在一定时间之后再花时间寻求对模型改进时会降低回报这对包含关系和扩展关系尤其适用：这些关系通常与从用例产生设计结构特征并不相当，所以缺乏一个可能依赖后果并不严重第27页RecordbookingCancelbookingDisplaybookingsReceptionistRecordarrivalRecordwalk-inStaffTabletransferHeadWaiter<<include>><<include>><<include>><<include>><<include>><<extend>>完成用例图第28页4.6领域建模领域模型：显示最主要业务概念和它们之间关系类图领域模型用关联和泛化显示了这些概念之间关系。领域模型通常不包含操作有时极难决定是应该将一个特殊信息作为一个类还是作为一个属性包含在领域模型中第29页要求关联重数，每个预定是由一个用户进行，这个人姓名和电话由系统统计，不过每个用户能够进行多个预定CustomerReservationMakes1*namephoneNumber用户和预定建模第30页CustomerReservationMakes1*namephoneNumbercoversdatetimeTableplaces1*{Reservationsforthesametablemustnotoverlap.}包含预定特征领域模型第31页CustomerMakes1*coversReservationWalk-inBookingdatetimeplacesTable*1{Bookingsforthesametablemustnotoverlap.}namephoneNumber包含未预约领域模型第32页4.6.1领域模型正确性要证实一个模型正确性或者即使是一个模型优于另一个模型，要更困难一些建立领域模型目标是确定一组对象，他们能够以有效地支持整个系统必须交付功效方式进行交互。所以，要评价领域模型中可供选择方式，能够从实现这一点程度来进行而且不能经过孤立地检验领域模型而简单地评定，还必须经过观察领域模型中类实例之间交互实际上是怎样支持需要功效，考虑模型实际上表示了什么第33页4.7术语表预约(Booking)：分配一张餐桌给一行用餐者进餐用餐人数(Covers)：预定未来用餐人数用户(Customer)：进行预定人用餐者(Diner)：在餐馆用餐人位子(Places)：在一张特定餐桌能够就座用餐者人数预定(Reservation)：提前预约一个特定时间餐桌未预约(Walk-in)：没有提前进行预约第34页4.8本章小结在业务建模活动结束时，系统文档包含一个用例模型、对各个用例文字描述、一个关键术语术语表以及一个领域模型用例图描述了参加者和用例以及他们之间各种关系用例表示了一类用户能够利用系统完成经典任务参加者表示了用户在与系统交互时能够充当角色。参加者和用例关联，表示以给定角色工作用户能够执行哪些任务。参加者能够经过泛化相关，以明确地表示它们共享能力一个用例能够包含