餐馆系统的业务建模教学

第4章餐馆系统的

业务建模第一页，共三十七页。4.1非正式的需求通过改进为顾客预定和分配餐桌的过程，支持一家餐馆的日常经营预约单中每一行对应餐馆中一张特定的餐桌。预约是对特定的一个餐桌登记的，每个预约中记录有“餐具”的数目，或者预期进餐者的数目，这样就能够分配一个大小适当的餐桌。这家餐馆在晚间供应三次餐点，称为“简餐”、“正餐”和“夜点”时段。可以预约跨多个时段的时间。每个预约中要记录联系人的姓名和电话。修改餐桌、电话取消预定、未预约的顾客处理第二页，共三十七页。4.1.1对计算机化系统的需要手工系统有很多问题：速度慢、预约单很快变乱、没有备份系统、获取管理数据不方便新系统应该和现有的预约单显示同样的信息，并且有大致相同的格式，使餐馆员工易于转换到新系统。记录新的预约和修改已有预约之后应该立即更新显示，使餐馆员工在工作时总能使用可获得的最新信息系统必须易于记录餐馆营业时发生的有意义的事情第三页，共三十七页。4.1.1定义一次迭代一个系统的第一次迭代应该只交付足够使系统提供某些确实有商业价值的核心功能在随后的迭代中再开发其他功能第四页，共三十七页。4.2用例建模用例视图是UML中起着支配作用的视图，描述的系统外部可见的行为基于系统需求的用例视图驱动和约束着后续的开发用例视图展示的是系统功能的结构化视图，视图定义了参与者和参与者可以参与的用例参与者模型化了用户与系统进行交互时可能充当的角色用例描述了用户使用系统能够完成一项特定的任务用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的第五页，共三十七页。4.2.1用例一组用例是一个系统的用户能够使用系统完成的不同任务可以通过考虑在系统实现后餐馆员工能够用它来做什么，简单地草拟出这次迭代的一组初步的用例这些用例所支持的主要任务：(1)记录一个新的预约信息(“记录预约”)(2)取消一个预约(“取消预约”)(3)记录一位顾客的到来(“记录到达”)(4)将一位顾客从一张餐桌移到另一张餐桌(“调换餐桌”)一个用例描述了系统能够为一个特定的用户做些什么，描述的是一个自包含的任务第六页，共三十七页。4.2.2参与者一个用例描述了系统及其用户之间的一类交互系统通常有不同种类的用户，他们能够执行系统功能的不同子集人与系统在进行交互时能够担任的不同角色称为参与者餐馆预约系统中用例可以分为两组：(1)维护提前预约信息有关的用例(2)需要在餐观营业时执行的任务参与者和用户之间不存在一对一的对应第七页，共三十七页。4.2.3用例图以图解的形式概括了系统中不同参与者和用例，并显示了哪些参与者能够参与哪些用例参与者用一个像人一样的图标表示用例用包含有用例名字的椭圆表示UML允许在用例图中包含更多的结构，来定义用例之间以及参与者之间的各种关系在实践中不值得花费很多时间细化用例图，额外的关系对后面的开发起不到很大作用第八页，共三十七页。RecordbookingCancelbookingRecordarrivalTabletransferReceptionistHeadWaiter初始用例图第九页，共三十七页。4.3描述用例用例描述了系统和它的用户之间在一定层次上的完整的交互在用例的不同实例中将发生什么样的细节，会在很多方面有所不同一个用例实例中可能会出现差错，将不能达到原来的目的一个用例的完整描述必须指明，在用例所有可能的实例中可能发生什么用例描述可能包含大量信息，需要某种系统的方法来记录这些信息UML没有定义一种描述用例的标准形式许多开发人员定义了用例描述的模板第十页，共三十七页。4.3.1事件路径用例描述必须定义在执行用例时用户和系统之间可能的交互基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达可选的事件路径：一些可选的功能会被调用例外的事件路径：发生错误时的处理第十一页，共三十七页。记录预约：基本事件路径(1)接待员输入要预约的日期；(2)系统显示该日的预约；(3)有一张合适的餐桌可以使用：接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号；(4)系统记录并显示该预约。事件路径要记录的重要事情是用户输入到系统的信息，而不是该信息是如何获得的。包含上下文的交互会降低用例的可复用性第十二页，共三十七页。记录预约——没有可用的餐桌：可选事件路径(1)接待员输入要求预约的日期(2)系统显示该日的预约(3)没有合适的餐桌可以使用，用来终止可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述第十三页，共三十七页。记录预约——餐桌过小：例外事件路径(1)接待员输入要求预约的日期(2)系统显示该日的预约(3)接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号(4)输入的预约用餐人数多于餐桌能容纳的人数，于是系统发出一个警告信息询问用户是否想要继续预约(5)如果回答“否”，用例将不进行预约而终止(6)如果回答“是”，预约将被输入，并附有一个警告标志不同类型的事件路径之间区分是非正式的，它可以使用例的总体描述组织得更容易理解不值得花过多时间去决定一个特定的情况是可选的还是例外的，更重要的是一定要确认给出了必须行为的详细描述第十四页，共三十七页。4.3.2用户界面原型在用例描述中详述用户界面不是个好主意用例描述的重点是定义系统和用户之间交互的总体结构，而包含用户界面的细节会使之不清晰对用户界面像什么样子有一个大概的看法，可能会有助于理解用例描述第十五页，共三十七页。Booking

Date:10Feb2004BookingSystem

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