第4章餐馆订餐系统的业务模型讲解.ppt

第四章 餐馆系统的业务模型 陈立岩 业务模型（Business Modelling） 软件开发的早期阶段 输入: 非形式化的规格说明 活动: 创建用例模型（use case model） 创建领域模型（domain model） 创建词汇表（ glossary） 本章内容 4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系统的用例编写，基本的事件路径） 4.1.4 组织用例模型（调整优化用例图） 4.1.5 完成用例模型（用例图的第二次迭代） 4.2 建立领域模型 4.3 建立词汇表 本章内容 4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系统的用例编写，基本的事件路径） 4.1.4 组织用例模型（调整优化用例图） 4.1.5 完成用例模型（用例图的第二次迭代） 4.2 建立领域模型 4.3 建立词汇表 本章内容 4.1 建立用例模型 4.1.1 非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系统的用例编写，基本的事件路径） 4.1.4 组织用例模型（调整优化用例图） 4.1.5 完成用例模型（用例图的第二次迭代） 4.2 建立领域模型 4.3 建立词汇表 4.1.1 非正式需求  原有功能 采用手工预约单： 预约的信息 姓名和电话号码 就餐者人数 调换餐桌 取消预约作注释 未预约顾客（‘Walk-in’） 就餐人数 本章内容 4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系统的用例编写，基本的事件路径） 4.1.4 组织用例模型（调整优化用例图） 4.1.5 完成用例模型（用例图的第二次迭代） 4.2 建立领域模型 4.3 建立词汇表 4.1.2 用例建模 第一次迭代应该只交付足够使系统提供某些确实有商业价值的核心功能。 定义基本功能—建立初始用例图 系统应取代手工预约单 用例建模的步骤 1.识别用例的步骤 找出系统边界和范围 识别参与者 确定每个参与者所期望的系统行为 找出用例 2.定义初始用例图 识别用例——第一步：系统边界 考虑构造系统时，你所需要做的第一件事情是确定系统的边界在哪里，需要定义什么是系统的组成部分（系统的边界内）和什么是系统的外部（系统边界外）。 系统边界是定义由谁或什么（参与者）使用系统，系统能够为哪些参与者提供什么特定利益（用例）。 系统边界绘制为方框，标有系统名称，参与者绘制在边界外部，用例绘制在边界内部。 识别用例—第二步：识别参与者 谁或什么使用该系统？ 谁对某个特定功能感兴趣？ 谁负责支持和维护系统？ 系统有哪些外部资源？其它还有哪些系统将需要与该系统进行交互？ 参与者-Actors 人与系统进行交互时能够担任的不同角色 eg: 接待员Receptionist (makes bookings) 领班Head waiter (assigns tables etc) 一个用户在不同的时间可以扮演一个或多个角色 顾客不是参与者 识别用例—第三步：描述用例 建立一组用例，使系统的用户能够使用系统完成的不同的任务。 餐馆预约系统需完成的主要任务: 记录一个新的预约信息 取消一个预约信息 记录一位顾客的到来 将一位顾客的餐桌从一张餐桌移到另一张餐桌（“调换餐桌”） 建立初始用例图（Use Case Diagrams） 以图解的形式概括系统中的不同参与者和用例，并显示哪些参与者能够参与哪些用例。 本章内容 4.1 建立用例模型 4.1.1非正式的需求 4.1.2 用例建模 4.1.3 描述用例（系统的用例编写，基本的事件路径） 4.1.4 组织用例模型（调整优化用例图） 4.1.5 完成用例模型（用例图的第二次迭代） 4.2 建立领域模型 4.3 建立词汇表 用例描述模板，见上章 用例描述没有统一的标准模板，可采用与项目一致的格式。 从实用上，应更重视编写完整的和可理解的事件路径，而不是按指定的模板填写每个部分。 基本事件路径 正常交互的情况下的路径—不中断。 记录预约 接待员输入要预约的日期 系统显示该日的预约 有一张合适的餐桌可以使用：接待员输入顾客的姓名、电话、预约的时间、用餐人数和餐桌号 系统记录并显示新预约。 可选事件路径 记录预约—没有可用的餐桌: 接待员输入要求的预约日期； 系统显示该日的预约； 没有合适的餐桌可以使用，用例终止 例外事件路径 记录预约—餐桌过小 接待员输入要求的预约日期； 系统显示该日的预约； 接待员输入顾客的姓名电话预约时间，用餐人数和餐桌号 用