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

第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允许在用例图中包含更多的结构，来定义用例之间以及参与者之间的各种关系 在实践中不值得花费很多时间细化用例图，额外的关系对后面的开发起不到很大作用 4.3 描述用例 用例描述了系统和它的用户之间在一定层次上的完整的交互 在用例的不同实例中将发生什么样的细节，会在很多方面有所不同 一个用例实例中可能会出现差错，将不能达到原来的目的 一个用例的完整描述必须指明，在用例所有可能的实例中可能发生什么 用例描述可能包含大量信息，需要某种系统的方法来记录这些信息 UML没有定义一种描述用例的标准形式 许多开发人员定义了用例描述的模板 4.3.1 事件路径 用例描述必须定义在执行用例时用户和系统之间可能的交互 基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达 可选的事件路径：一些可选的功能会被调用 例外的事件路径：发生错误时的处理 记录预约：基本事件路径 (1)接待员输入要预约的日期； (2)系统显示该日的预约； (3)有一张合适的餐桌可以使用：接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号； (4)系统记录并显示该预约。 事件路径要记录的重要事情是用户输入到系统的信息，而不是该信息是如何获得的。 包含上下文的交互会降低用例的可复用性 记录预约——没有可用的餐桌：可选事件路径 (1)接待员输入要求预约的日期 (2)系统显示该日的预约 (3)没有合适的餐桌可以使用，用来终止 可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误 因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述 记录预约——餐桌过小：例外事件路径 (1)接待员输入要求预约的日期 (2)系统显示该日的预约 (3)接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号 (4) 输入的预约用餐人数多于餐桌能容纳的人数，于是系统发出一个警告信息询问用户是否想要继续预约 (5)如果回答“否