- 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.取消一
您可能关注的文档
- STS售电系统操作手册.doc
- ST九州退市原因分析及启示.doc
- success英文演讲稿.ppt
- Sun T4-2安装Solaris10 U10.doc
- struts2入门总结.doc
- SVK20-3S检修技术总结.doc
- SVN与bugzilla整合.doc
- SVN命令使用手册.doc
- SVN操作规范.doc
- SWOT分析:优势、劣势、机会与威胁.doc
- 第18讲 第17课 西晋的短暂统一和北方各族的内迁.docx
- 第15讲 第14课 沟通中外文明的“丝绸之路”.docx
- 第13课时 中东 欧洲西部.doc
- 第17讲 第16 课三国鼎立.docx
- 第17讲 第16课 三国鼎立 带解析.docx
- 2024_2025年新教材高中历史课时检测9近代西方的法律与教化含解析新人教版选择性必修1.doc
- 2024_2025学年高二数学下学期期末备考试卷文含解析.docx
- 山西版2024高考政治一轮复习第二单元生产劳动与经营第5课时企业与劳动者教案.docx
- 第16讲 第15课 两汉的科技和文化 带解析.docx
- 第13课 宋元时期的科技与中外交通.docx
文档评论(0)