第11章UML例子-1.pptVIP

第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * “Record Time”用例： 看起来不是那么的集中，雇员可以用它来浏览、更新和增加新的时间条目。然而，这些活动没有一个看起来可以独自提供价值。尽管“Record Time”有一些不同的子活动，但是它有一个与众不同的价值。 当一个用例太大，而它的子用例又太小的时候，保留这个大用例还是比较明智的。 当然，“Record Time”用例本身也是有价值的，它是这整个系统的目标。 第11章 案例-1 * “Comment Time Entry”用例： 显然符合集中的准则，它有一个非常具体的用处。然而，它却通不过“独立提供价值”这个准则。“Comment Time Entry”是一个更大的活动“Record Time”的一个部分。所以“Comment Time Entry”这个用例就被删除，并成为“Record Time”用例的一个细节。 “Extract Time Entries”用例： 有严格定义的、有价值的目标，它允许管理员用户导出系统数据。 这个过程将用例裁减为:Create Employee、Create Charge Code、Record Time、Extract Time Entries。 第11章 案例-1 * 11.2.3确定参与者和用例之间的关系 每一个参与者都触发一个或更多的用例，每一个用例都由一个或多个参与者触发。 在创建高层用例图的最后一个步骤是描述用例和参与者之间的这种关系。 从参与者指向用例的实心箭头表明这个参与者触发这个用例。 分别考虑每一个参与者。从和客户的对话得知： “Employee”参与者不能触发“Create Employee ” 、“Create Charge Code”或者“Extract Time Entries”用例。当然，在正常的情况下，“Employee”参与者必须触发“Record Time”用例。 除了“Extract Time Entries”用例，支付系统不能触发其他用例。 第11章 案例-1 * 显然，“Administrative User”参与者触发“Create Employee”和“Create Charge Code”用例。 这个充当“Administrative User”参与者角色的人几乎肯定是这个机构的一个雇员，所以他也必须记录自己的时间。然而，执行这个任务时，他是在扮演雇员这个角色。当且仅当记录其他雇员的时间的时候，这个人才有必要以“Administrative User”的身份来执行这个活动。再看一遍会议记录就可以发现这也是一个需求，因为管理员用户需要为生病的或请假的雇员登记时间。 第11章 案例-1 * 下图显示这些关系。它是高层用例图的第一份草稿。在这时候，你需要和客户一起确认这个模型的准确性。客户必须认同所有的参与者和用例。 在这次会议上，你的客户必须执行一个有价值的、理性的检查，指出任何遗漏的特性。好的用例模型是需求的一个友善的、易懂的切入点。对你的客户来说，它容易理解。 第11章 案例-1 * 第11章 案例-1 * 11.3描述细节 用例图为整个系统提供一个高层次的视图。 对每一个用例，你需要确定用户是如何使用这个系统的。也就是，重点是在用例提供的价值和工作流程上，而不是特定的解决方案上。 细节描述准则 这个阶段需要考虑任何已知的部署约束(deployment constraint)。 在这个阶段为那些部署约束考虑解决方案。 一个经常犯的错误是从界面设计(screen design)上来考虑用例。这是很危险的，因为有些界面可能会支持好几个用例，有些用例在最终设计的时候要用到好几个界面。 第11章 案例-1 * 细节描述——用例模板。用例模板的组成： 用例名称 描述 前置条件 部署约束 正常事件流 可选事件流 异常或错误事件流 活动图 非功能性需求 说明（可选） 未解决的问题（可选） 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 第11章 案例-1 * 11.4收集更多的需求——需求评审会议 需求评审会议有两个目标： 验证和改进当前的用例模型，包括其中的事件流。 解决大多数突出的问题和未解决的问题。 要注意： 要从客户的角度来理解这个系统，集中在客户对系统的需求上。 要集中在“系统如何为客户提供价值”的问题上。 要严格控制自己，抵制住开始进行架构设计的诱惑。 需求评审会议将涵盖已开发的所有用例。 会议参加者(participant)必须为讨论这些用例细节做好准备，包括事件流和活动图、部署约束以及所有未解决的问题。为了保