- 1、本文档共21页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
UML餐馆系统:业务建模
第4章 餐馆系统:业务建模
接下来的四章将考虑一个简单的案例,并给出一个从需求获取到实现的完整开发过程。我们将考虑一次单独的迭代,它通过统一过程标识的主要工作流之中的四个:即需求、分析、设计和实现,用例子说明UML表示法在软件开发中的使用。
由于本案例研究的意图在于强调开发的产品而不是过程,所以不会详细考虑由统一过程定义的这些工作流的结构,而在真正需要的地方将在介绍UML表示法的同时,简略介绍开发中涉及的活动。
4.1 非正式的需求
要开发的系统的意图是,通过改进为顾客预定和分配餐台的过程,支持一家餐馆的日常经营。这家餐馆当前采用一个手工预约系统,使用的是保存在一个大文件夹中的手写预约单。
图4.1是当前的预约单的一个例子,预约单中的每一行对应餐馆中一张特定的餐台。预约是对特定的一个餐台登记的,每个预约中记录有“餐具” 的数目,或者预期进餐者的数目,这样就能够分配一个大小适当的餐台。这家餐馆在晚间供应三次餐点,称为“简餐”、“正餐”和“夜点”时段。但如同预约单所表明的,这些时段无须严格遵守,可以预约跨多个时段的时间。最后,每个预约中要记录联系人的姓名和电话。
图4.1 手工预约单
为了记录各种事情,要在预约单上加一个注文。当一行用餐者到来并在他们的餐台就座时,就划掉相应的预约登记。如果他们就座的不是他们预约的餐台,就画一个箭头从最初预约的餐台指向新的餐台。如果顾客打电话取消预约,并不能从表中真正地擦除,而是做一个预约已经取消的注文。其他的信息,比如到什么时间餐台必须空出来,也可以写在预约单上。
如果有空闲的餐台,用餐者当然也可以不提前预约就进餐馆用餐,这被称为“未预约的顾客(walk-in)”,并在预约单中作为预约登记以表示餐台的占用,但不记录顾客的姓名或电话。
4.1.1 对计算机化系统的需要
这家餐馆的管理人员已经确认了很多与手工系统相关的问题。手工系统速度慢,而且,预约登记单很快就变得难以理解。这可能导致经营上的问题,例如,实际上有空餐台而由于这个预约单不是很明显,会妨碍顾客进行预约。没有备份系统:如果一张预约单被毁坏了,餐馆就没有了那个晚上有什么预约的记录。最后,从现有的预约单获取即使很简单的管理数据也很费时,例如餐台的使用率。
由于这些以及其他原因,该餐馆意欲开发一个现行的预约单的自动化版本。新系统应该和现有的预约单显示同样的信息,并且有大致相同的格式,使餐馆员工易于转换到新系统。当记录了新的预约时,或者对已有的预约进行修改时,应该立即更新显示,使餐馆员工在工作时总能使用可获得的最新信息。
系统必须易于记录餐馆营业时发生的有意义的事情,例如顾客的到来。系统的操作应当尽可能是直接操作屏幕上显示的数据。例如,可以简单地将预约拖动到屏幕上一个适当的位置以改变一个预约的时间或者分配的餐台。
4.1.2 定义一次迭代
迭代和增量的方法建议,一个系统的第一次迭代应该只交付足够使系统提供某些确实有商业价值的核心功能。在餐馆预约系统这个例子中,基本需求是餐馆在营业时记录预约和更新预约单信息的能力。如果这些功能可以使用,则可能用这个系统代替现有的预约单,然后在随后的迭代中再开发其他功能。
4.2 用例建模
在一个系统可能采用的不同视图中,用例视图(use case view)被认为是UML中起着支配作用的视图。用例视图描述的是系统外部可见的行为。因此,在软件开发开始于考虑所提出的系统的需求的情况下,用例视图确立了一种强制力量,驱动和约束着后续的开发。
用例视图展示的是系统功能的结构化视图。这个视图定义了若干参与者(actors)和这些参与者可以参与的用例(use case)。这些参与者模型化了用户与系统进行交互时可能充当的角色,一个用例则描述了用户使用系统能够完成的一项特定的任务。用例视图应该包含一组定义了该系统的完整功能的用例,或者至少定义了当前迭代所规定的功能的用例,这些用例应该以在系统支持下能够完成的任务的措词给出。
理想地,用例视图应该是客户、最终用户、领域专家、测试人员和任何其他的涉及系统的人员,不需要详细了解系统结构和实现就容易理解的。用例视图不描述软件系统的组织或结构,它的作用是给设计者施加约束,设计者必须设计出一个能够提供用例视图中指定的功能的结构。
4.2.1 用例
一组用例是一个系统的用户能够使用系统完成的不同任务。在这个例子中,我们将简单描述预约系统可能有的一组用例,但是在真正的开发中,用例一般是由分析人员与系统未来的用户进行磋商确定的。
餐馆预约系统第一次迭代的意图是允许用户使用一个自动化的预约单。可以通过考虑在系统实现后餐馆员工能够用它来做什么,简单地草拟出这次迭代的一组初步的用例。下面列出了这些用例所支持的主要任务:
1.记录一个新的预约信息(“记录预约”)。
2.取消一
您可能关注的文档
最近下载
- 2025款比亚迪宋PLUS EV豪华尊贵旗舰型_用户手册驾驶指南车主车辆说明书电子版.pdf VIP
- 第1课《初三,我来了》课件北师大版心理健康教育九年级全一册.ppt
- 2023全域用户经营白皮书:STAR模型,从用户运营到生意增长.doc VIP
- NBT 35042-2014 水力发电厂通信设计规范.pdf
- 《小学英语单元整体作业设计的实践研究》开题报告.docx VIP
- “三个聚焦”内容个人自查报告.docx VIP
- 2024年充电宝市场现状分析:充电宝全球市场销售额达到224亿元.docx
- 各种烟气焓温、密度、比热计算表.xls VIP
- 考试妇科试题.docx VIP
- 德国科技创新与产业趋势.pptx VIP
文档评论(0)