uml 餐馆管理信息系统.pptVIP

用例建模 领域建模 系统顺序图 系统契约 对象交互图 设计类图 用例建模 用例视图应该包含一组定义了该系统完整功能的用例，或者至少定义了当前迭代所规定功能的用例 用例视图应该是客户、最终用户、领域专家、测试人员和任何其他涉及系统的人员，不需要详细了解系统结构和实现就容易理解的 餐馆预约系统的初始用例图 参与者：代表了与系统交互的事物 定义：是系统外部的一个实体，它以某种方式参与了用例的执行过程。 参与者可以是：人担当的角色、计算机系统、机械或者电子设备； 参与者由他们参与用例时所担当的角色来代表，例如，顾客。 一个参与者并不时指一个特定的人或一个特定的实体 如何写用例 也称之为用况，是一个描述型文档，用来描述一个参与者（一个外部的主动者）使用系统完成某个过程时的事件发生顺序。 通俗而言，用例就是如何使用系统来达到目标的一组情节，其本质是通过写出多种使用系统的情节来发现和记录功能性需求 一个用例格式模版 主要参与者 涉众及其兴趣 前置条件 成功后的保证（后置条件） 主要成功场景（或基本流程） 扩展（或替代流程） 特殊需求 技术与数据的变化列表 参与者与涉众的关系 涉众也称干系人,是与要建设的这个系统有利益相关的一切人和事,涉众的利益要求会影响系统的建设。 涉众不等于用户。 涉众建议并界定了系统必须要做的工作。用例应该满足包含所有涉众关注点的事物。 前置条件和后置条件 前置和后置条件表示用例开始状态和结束会发生什么 前置：规定了在用例中的一个场景开始之前必须为“真”的条件 后置：规定了在用例中的一个场景成功结束后必须为“真”的条件 事件路径 用例描述必须定义在执行用例时用户和系统之间可能的交互 基本事件路径：用例的主要目标可以没有任何问题并且不中断地到达 可选的事件路径：一些可选的功能会被调用 例外的事件路径：发生错误时的处理 主要的成功场景和步骤（基本路径） 它描述了能够满足项目相关人员兴趣的典型的成功路径 参与者的交互 一个验证动作 由系统完成的状态改变 （第一个步骤用来指示一个用来开始场景的触发事件） 例：“记录预约”基本事件路径 (1)接待员输入要预约的日期； (2)系统显示该日的预约； (3) 接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号； (4)系统记录并显示该预约。 扩展（例外/可选事件） 可选事件路径描述的情况，可以作为营业的一个正常部分出现，它们并没有指出产生了误解，或者发生了错误 因为一个错误和用户的疏忽而不可能完成基本事件路径，这些情况将由例外事件路径描述 例：“记录预约”可选事件路径 ——没有可用的餐桌 (1)接待员输入要求预约的日期 (2)系统显示该日的预约 (3)没有合适的餐桌可以使用，用来终止 (1)接待员输入要求预约的日期 (2)系统显示该日的预约 (3)接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号 (4) 输入的预约用餐人数多于餐桌能容纳的人数，于是系统发出一个警告信息询问用户是否想要继续预约 (5)如果回答“否”，用例将不进行预约而终止 (6)如果回答“是”，预约将被输入，并附有一个警告标志 扩展（例外/可选事件） 扩展场景是从主要成功场景中分支出来的，因此应该遵从主要成功场景的标记方式 1接待员输入要求预约的日期 2系统显示该日的预约 3接待员输入顾客的姓名和电话号码、预约的时间、用餐人数和餐桌号 3a没有餐桌号 1.系统指示没有餐桌号，并拒绝输入 3b.输入的预约用餐人数多于餐桌能容纳的人数 1.系统发出一个警告信息询问用户是否想要继续预约 2. 接待员响应该询问 2a.取消预约 2b.继续预约，系统记录警告信息 4系统记录并显示该预约。 一个用例模型何时完成 用例分析是一项非正式的技术，在一定时间之后再花时间寻求对模型的改进时会降低回报 这对包含关系和扩展关系尤其适用 特殊要求 特殊要求：如果有一些与此用例有关的非功能需求（象质量属性或约束条件），那么将它们和用例记录在一起。 技术和数据的变化列表 技术和数据的变化列表：系统通常有一些技术上的变化是关于“应该怎么做”，而不是“应该做什么”，需要在用例中将这种变化记录下来。 领域建模（概念模型） 建立一个领域模型 领域模型——添加关联 领域模型——添加属性 简介 领域模型：显示最重要的业务概念和它们之间的关系的类图 领域模型用关联和泛化显示了这些概念之间的关系。领域模型通常不包含操作 怎样识别概念类？ 识别概念的实用指导原则 最好是能够尽量充分地用细粒度地概念来描述模型，而避免粗略描述。 识别概念的方法 a、使用概念类分类列表来找出概念； b、根据名词性短语识别出概念类