餐馆系统的业务建模教学PPT(共37页)

第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用户界面原型在用例描述中详述用户界面不是个好主意用例描述的重点是定义系统和用户之间交互的总体结构，而包含用户界面的细节会使之不清晰对用户界面像什么样子有一个大概的看法，可能会有助于理解用例描述BookingDate:10Feb2004BookingSystem18:3019:3020:3021:3022:3023:302412345预约系统主屏幕的一个原型MsBlue012176484495Covers:3MrWhite0865364795Covers:2Covers:4Covers:2MrBlack02084537646Walk-in4.4组织用例模型记录到达：基本事件路径(1)侍者领班输入当前日期(2)系统显示当天的预约(3)侍者领班确认一个选定的预约已经到达(4)系统对此进行记录并更新显示器，将顾客标记为已到达记录到达——没有提前预定：可选事件路径(1)侍者领班输入当前日期(2)系统显示当天的预约(3)系统中没有记录该顾客的预约，所以侍者领班输入预约时间、用餐人数和餐桌号，创建一个未预约的登记(4)系统记录并显示新预约4.4.1用例包含显示预约：基本事件路径(1)用户输入一个日期(2)系统显示当日的预约记录预约：基本事件路径(修改)(1)接待员执行“显示预约”用例(2)接待员输入顾客姓名和电话号码、预定的时间、用餐人数以及预留的餐桌(3)系统记录和显示新预约RecordbookingDisplaybookingReceptionistinclude用例包含4.4.2参与者泛化参与者之间泛化的含义是，特化的参与者可以参与和更一般的参与者关联的所有用例可以指派给特化的参与者更多的责任DisplaybookingRecordbookingRecordarrivalReceptionistStaffHeadWaiterincludeinclude参与者泛化4.4.3用例扩展记录未预约顾客：基本事件路径(1)侍者领班执行“显示预约”用例(2)侍者领班输入时间、用餐人数和分配给顾客的餐桌(3)系统记录并显示新预约包含依赖性对这种情况并不适合，因为在“记录未预约顾客”中指定的交互不是在每次执行“记录到达”时都执行“记录未预约顾客”用例只是在“记录到达”的某些情况下被执行Recordwalk-inRecordarrivalReceptionistextend用例扩展4.5完成用例模型取消预定：基本事件路径(1)接待员选择要求的预约(2)接待员取消该预约(3)系统询问接待员确认取消(4)接待员回答“是”，系统记录取消并更新显示这个事件路径没有清楚地详细说明用户如何完成这些任务，这为系统能提供多种方式完成该任务留下的不受限制的可能性调换餐桌：基本事件路径(1)侍者领班选择需要的预约(2)侍者领班改变该预约的餐桌分配(3)系统记录改变并更新显示可选和例外事件路径可以从餐馆的经营规则得到：和取消一样，应该不可能将一个过期的预约调换到新餐桌，也应该不可能将一个预约移到已占用的餐桌4.5.1一个用例模型何时完成用例分析是一项非正式的技术，在一定时间之后再花时间寻求对模型的改进时会降低回报这对包含关系和扩展关系尤其适用：这些关系通常与从用例产生的设计的结构特性并不相当，所以缺少一个可能的依赖的后果并不严重RecordbookingCancelbookingDisplaybookingsReceptionistRecordarrivalRecordwalk-inStaffTabletransferHeadWaiterincludeincludeincludeincludeincludeextend完成的用例图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本章小结在业务建模活动结束时，系统文档包含一个用例模型、对各个用例的文字描述、一个关键术语的术语表以及一个领域模型用例图描述了参与者和用例以及他们之间的各种关系用例表示了一类用户可以利用系统完成的典型任务参与者表示了用户在与系统交互时可以充当的角色。参与者和用例的关联，表示以给定角色工作的用户能够执行哪些任务。参与者可以通过泛化相关，以明确地表示它们共享的能力一个用例可以包含另一个用例：意思是被包含用例规定的交互构成包含用例每次执行的一部分一个用例可以扩展另一个用例：意思是扩展用例规定的交互构成被扩展用例一次执行的一个可选部分用例描述是文字形式的文档，详细描述在执行用例时在用户和系统之间可以发生的交互每个用例描述包含一个基本事件路径，描述用例的“正常”进行，以及一组可选和例外事件路径领域模型显示重要的业务概念