uml实验 需求模型的建立.doc

实 验 报 告（2013 / 2014学年 第 2 学期）课程名称 统一建模语言实验名称 需求模型的建立 实验时间2014年06月04日指导单位 计算机学院软件工程系指导教师 胥备 学生姓名 班级学号学院(系)通达学院专 业软件工程实 验 报 告实验名称需求模型的建立指导教师胥备实验类型验证型实验学时42实验时间2014-06-04一、 实验目的和要求 目前餐馆采用手工预约系统，使用如“手工预约单”记录订餐用户的信息：餐桌号、联系人姓名、电话、进餐人数等，但由于顾客常出现更改订餐信息，造成手工预约单的杂乱不堪，给顾客和工作人员造成诸多不便。为改善工作环境，提高工作效率，餐馆拟开发使用计算机管理系统，实现订餐预约的计算机化管理：允许预约跨时段（如设某餐馆企业在晚间供应三餐： 简餐(counter meal)：时间17:3019:30 正餐(dinner)：时间19:4521:45 夜点(midnight meal)：时间22:0023:30）允许取消预约允许调整预约（日期、时间段、人数发生变化）允许不预约，直接进店就餐注： 系统实现与手工的预约手册显示同样信息，格式大致相同，便于员工快速接受操作灵活 即时更新掌握用例模型的建立方法，使用 IBM Raional 等工具，根据给出 餐馆预约系统的需求，进行用例模型的建模。 1 熟悉 IBM Raional 等工具的基本用法及文档的组织管理2理解用例模型，能用 IBM Raional 等工具正确绘制用例模型 二、实验环境(实验设备) 1) 硬件：PC 机一台、计算机局域网络 2) 软件：Windows 操作系统、IBM Rational Rose 工具软件 三、实验原理及内容1. 描述餐馆的业务功能，进行业务用例建模，画出业务用例图某餐馆企业在晚间供应三餐：简餐(counter meal)：时间 17:3019:30 正餐(dinner)：时间 19:4521:45 夜点(midnight meal)：时间 22:0023:30 为改善工作环境，提高工作效率，餐馆拟开发使用计算机管理系 统，实现订餐预约的计算机化管理： 允许预约跨时段1. 允许取消预约2. 允许调整预约（日期、时间段、人数发生变化）3. 允许不预约，直接进店就餐注： 系统实现与手工的预约手册显示同样信息，格式大致相同， 便于员工快速接受 操作灵活 即时更新 功能需求系统实现与手工的预约手册显示同样信息格式大致相同，员工快速接受记录新的预约修改、删除、查询预约性能需求操作灵活即时更新提高工作效率业务用例图如下：2. 对系统进行用例建模，分析系统的活动者和用例，画出用例 图，并对用例进行描述 （1）分析活动者(Actor)活动者是用户与系统交互时所扮演的角色负责记录预约和取消预约：Receptionist顾客到达时，负责分配餐桌和调换餐桌：Head Waiter（2）分析用例(Use Case)分析员与系统用户协商一个用例表示用户使用系统完成一次任务用例的初始清单：新增预约信息：Add Booking取消预约信息：Delete Booking查询预约信息：Query Booking修改预约信息：Update Booking记录顾客到来：Record Arrival餐桌调换：Table Transfer“扩展”依赖关系考虑“顾客不预约直接来餐馆就餐”的情况，添加用例“Record Walk-in”，与“Record Arrival”之间是扩展依赖用例“Record Arrival”与“Table Transfer”之间是扩展依赖“包含”依赖关系用例“Add Booking”、“Delete Booking”、“Update Booking”与“Query Booking”之间是包含依赖用例“Record Walk-in”与“Add Booking”之间是包含依赖用例“Record Arrival”、“Table Transfer”与“Update Booking”之间是包含依赖用例之间的“依赖”关系活动者之间的“泛化”关系3. 进行系统的原型设计，以界面的形式给出系统原型4. 构建系统的领域模型，画出系统的概要类图 领域模型(domain model)定义最重要的业务概念，一组具有属性和关系的类使用UML类图构建一个真实世界的系统模型概要类图5. 定义术语表，收集系统的核心词汇 系统的核心词汇（1）预约(booking)：分配餐桌给将要来用餐者（2）就餐人数(coverNum)：预约来用餐的人数（3）顾客(customer)：进行预订的人（4）就餐者(diner)：在餐馆就餐的人（5）预订(reservation)：提前预约特定时间用餐（6）未预约(walk-in)：没有预约直接用餐（7）座位数(seatNum)：餐桌容纳的就餐人数 精化实验1 得到的领域模型，增加控制类 提示：实验 1 得到的领域模型仅仅表示了业务实体，没有 定义类响应用户消息的职责，必须为系统增加控制类 为系统添加控制类在应用层分析实现系统的业务功能考虑功能内聚特性，增加两个控制类类BookingSystem：处理单个预约类Restaurant：维护所有预约信息，在收到查询请求时，返回特定的预约2. 实化实验 1 得到的用例模型，面向业务的功能实现，画出每 个用例的交互图示例（顺序图或协作图任选） （1）查询预约(Query Booking)顺序图（2）新增预约(Add Booking) 顺序图 （3）取消预约(Delete Booking)顺序图（4）修改预约(Update Booking)可以看做是删除和插入的复合过程直接更新过程顺序图（5）记录顾客到来(Record Arrival)顺序图（6）未预约顾客到来(Record Walk-in)顺序图（7）调整餐桌(Table Transfer)顺序图3. 实化领域模型，构建分析模型，画出系统的分析模型。 提示：要标注类的版型。 1实化领域模型 2系统的分析模型 精化实验 2 得到的分析模型，增加边界类，深化实体类 提示： 实验 2 得到的分析模型仅仅在业务实现的角度，定义了业 务功能。 增加边界类，对系统进行输入输出设计 深化实体类，对系统进行存储设计 在显示层增加边界类StaffUI，职责：接收用户消息，转发给控制类实例显示系统的输出，将应用数据或模型呈现给用户用户需求：即时更新，用户看到的和系统状态一致解决方案：轮询(polling)或观察者模式(Observer pattern)轮询(polling)技术定期查询，代价高昂观察者(Observer)模式对象间存在依赖关系，当某对象状态改变时，所有依赖于它的对象都得到通知并被自动更新输入输出设计Observer Pattern在餐馆系统的应用显示层的类StaffUI实现了BookingObserver接口系统工作时，BookingSystem类实例对象通过方法addObserver()向其观察者列表加入一个StaffUI类实例当模型改变时，通过notifyObservers()向每个观察者发送update消息，基于动态联编， StaffUI类实例会收到发自观察者列表的update消息类StaffUI实例对象收到update消息，会查明什么发生了改变存储设计回顾完整分析模型模型中的实体类ReservationWalkinCustomerTable数据库的模式设计概念模式关系模式2. 实化分析模型，构建设计模型 在分析模型的基础上加入输入输出和存储设计类的详细设计，类图动态行为建模，状态图或活动图系统层次架构设计模型3. 进行类的详细设计，定义类的职责（属性、操作） 详细类设计对每一个类进行详细设计，定义类的职责属性操作：收集顺序图中的消息，增加参数和返回值如类BookingSystem4. 进行系统动态行为建模 提示：增加边界类后，深化分析模型中定义的交互图。 画出主要类的