第4章餐馆系统业务建模.doc

第4章餐馆系统:业务建模接下来的四章将考虑一个简单的案例,并给出一个从需求获取到实现的完整开发过程。我们将考虑一次单独的迭代,它通过统一过程标识的主要工作流之中的四个:即需求、分析、设计和实现,用例子说明UML表示法在软件开发中的使用。由于本案例研究的意图在于强调开发的产品而不是过程,所以不会详细考虑由统一过程定义的这些工作流的结构,而在真正需要的地方将在介绍UML表示法的同时,简略介绍开发中涉及的活动。非正式的需求要开发的系统的意图是,通过改进为顾客预定和分配餐台的过程,支持一家餐馆的日常经营。这家餐馆当前采用一个手工预约系统,使用的是保存在一个大文件夹中的手写预约单。 ,预约单中的每一行对应餐馆中一张特定的餐台。预约是对特定的一个餐台登记的,每个预约中记录有“餐具”的数目,或者预期进餐者的数目,这样就能够分配一个大小适当的餐台。这家餐馆在晚间供应三次餐点,称为“简餐”、“正餐”和“夜点”时段。但如同预约单所表明的,这些时段无须严格遵守,可以预约跨多个时段的时间。最后,每个预约中要记录联系人的姓名和电话。手工预约单为了记录各种事情,要在预约单上加一个注文。当一行用餐者到来并在他们的餐台就座时,就划掉相应的预约登记。如果他们就座的不是他们预约的餐台,就画一个箭头从最初预约的餐台指向新的餐台。如果顾客打电话取消预约,并不能从表中真正地擦除,而是做一个预约已经取消的注文。其他的信息,比如到什么时间餐台必须空出来,也可以写在预约单上。如果有空闲的餐台,用餐者当然也可以不提前预约就进餐馆用餐,这被称为“未预约的顾客(walk-in)”,并在预约单中作为预约登记以表示餐台的占用,但不记录顾客的姓名或电话。对计算机化系统的需要 这家餐馆的管理人员已经确认了很多与手工系统相关的问题。手工系统速度慢,而且,预约登记单很快就变得难以理解。这可能导致经营上的问题,例如,实际上有空餐台而由于这个预约单不是很明显,会妨碍顾客进行预约。没有备份系统:如果一张预约单被毁坏了,餐馆就没有了那个晚上有什么预约的记录。最后,从现有的预约单获取即使很简单的管理数据也很费时,例如餐台的使用率。 由于这些以及其他原因,该餐馆意欲开发一个现行的预约单的自动化版本。新系统应该和现有的预约单显示同样的信息,并且有大致相同的格式,使餐馆员工易于转换到新系统。当记录了新的预约时,或者对已有的预约进行修改时,应该立即更新显示,使餐馆员工在工作时总能使用可获得的最新信息。 系统必须易于记录餐馆营业时发生的有意义的事情,例如顾客的到来。系统的操作应当尽可能是直接操作屏幕上显示的数据。例如,可以简单地将预约拖动到屏幕上一个适当的位置以改变一个预约的时间或者分配的餐台。定义一次迭代迭代和增量的方法建议,一个系统的第一次迭代应该只交付足够使系统提供某些确实有商业价值的核心功能。在餐馆预约系统这个例子中,基本需求是餐馆在营业时记录预约和更新预约单信息的能力。如果这些功能可以使用,则可能用这个系统代替现有的预约单,然后在随后的迭代中再开发其他功能。用例建模 在一个系统可能采用的不同视图中,用例视图(usecaseview)被认为是UML中起着支配作用的视图。用例视图描述的是系统外部可见的行为。因此,在软件开发开始于考虑所提出的系统的需求的情况下,用例视图确立了一种强制力量,驱动和约束着后续的开发。 用例视图展示的是系统功能的结构化视图。这个视图定义了若干参与者(actors)和这些参与者可以参与的用例(usecase)。这些参与者模型化了用户与系统进行交互时可能充当的角色,一个用例则描述了用户使用系统能够完成的一项特定的任务。用例视图应该包含一组定义了该系统的完整功能的用例,或者至少定义了当前迭代所规定的功能的用例,这些用例应该以在系统支持下能够完成的任务的措词给出。 理想地,用例视图应该是客户、最终用户、领域专家、测试人员和任何其他的涉及系统的人员,不需要详细了解系统结构和实现就容易理解的。用例视图不描述软件系统的组织或结构,它的作用是给设计者施加约束,设计者必须设计出一个能够提供用例视图中指定的功能的结构。用例一组用例是一个系统的用户能够使用系统完成的不同任务。在这个例子中,我们将简单描述预约系统可能有的一组用例,但是在真正的开发中,用例一般是由分析人员与系统未来的用户进行磋商确定的。 餐馆预约系统第一次迭代的意图是允许用户使用一个自动化的预约单。可以通过考虑在系统实现后餐馆员工能够用它来做什么,简单地草拟出这次迭代的一组初步的用例。下面列出了这些用例所支持的主要任务:(“记录预约”)。(“取消预约”)。(“记录到达”)。(“调换餐台”)。 一个用例不单是简单地描述了该系统的部分功能,所以