可视化建模与UML I 项目指导书.doc

《可视化建模与UML I》课程 项目指导书 软件工程系 一：完成自拟项目的需求分析 （一）基本信息 本次实践是自拟项目（三级项目）。对自拟项目进行需求分析，构建用例模型解决该问题。 1、类型： □ 综合类 ■ 设计类 □ 创新类 □ 验证类 2、学时安排： 课上2学时。 3、教学目标： （1）理解用例模型对需求建模的重要性； （2）识记构建用例图的方法，并能够熟练运用用例图完成对系统的需求分析。 （3）识记书写用例描述的关键点，完成对每个用例的分析和描述。 （二）组织形式 课上完成本次实践的内容，采取分小组的方式，每组3—5人，包括1名组长。由组长负责分配工作。 （三）任务描述 每个小组自拟题目，完成该项目的需求分析，要求使用工具StarUML完成系统的总体用例图，并且对于关键用例要给出对应的用例描述。 （三）指导内容 1、相关知识： （1）用例图 ①识别参与者：参与者（也可以称为角色，Actor）是系统外部的一个人或者物，它以某种方式参与了系统的执行过程。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。参与者之间也可以象类一样存在泛化关系。 ②用例：用例是代表系统中各个项目相关人员之间根据系统的行为所达成的契约。用例描述了在不同条件下，针对某一项目相关人员的请求，系统对其作出的响应。用来描述参与者可以感受到的系统服务或功能。 ③用例和用例之间的关系：用例除了与参与者有关联关系外，用例之间也存在着一定的关系，如泛化关系、包含关系、扩展关系等。 例1： 例2： （2）用例描述 用例描述的组成部分： 用例标识 用例名称 涉及的参与者 用例概述 前置条件（Preconditions） 后置条件（Postconditions） 事件流（Flow of events） 基本流程，不考虑异常； 分支流程（Subflows） 例1： 用例标识 UC1 用例名称 上传课件 参与者 教师 前置条件 确认教师身份 后置条件 系统增加了新的课件信息 用例概述 教师将该课程的课件上传到服务器上。 基本事件流 参与者动作 系统动作 1.教师确认要上传的课件信息。 2.系统检查该课件信息的有效性。 3.系统从本地提取课件到服务器。 4.系统将课件信息保存到相应位置，并提示保存成功。 备选事件流 2.a 如果课件格式不符合要求，系统提示此信息，并返回到步骤1. 3.a 如果提取信息失败，提示此信息，返回到步骤1. 4.a 如果保存信息失败，提示此信息，返回到步骤1. 备注 服务器将记录每次上传的时间 （3）其他知识资源 详细内容请参见《第4章 用例与用例图》的PPT或者 教材P51-P68 。 2、过程与步骤： 第一步：分析项目需求，识别出参与者。 第二步：分析系统功能，识别出用例。 第三步：分析参与者之间的关系。 第四步：分析用例之间的关系。 第五步：绘制整体用例图的草图。 第六步：优化并调整用例图。 第七步：采用工具StarUML画出系统的用例图，具体过程useCaseModel Use Case Model(add Usecase Diagram，创建参与者actor和用例usecase。完成之后将用例图粘贴到需求报告中。 第八步：对用例进行优先级排序。 第九步：对优先级高的用例完成用例的详细描述。 （四）成果提交 组长将该小组的项目内容汇总到一个word文档中，形成一份完成的需求报告。小组成员每人提交一份该完整的需求报告，注明提交人的姓名、学号和任务分工。 需求报告中必须包含系统总体用例图和核心用例的用例描述，其余部分可以适当增加，比如项目概述等。 （五）考核方式与标准 1、考核方法 （1）评阅项目报告； （2）课堂检查小组项目的完成情况。 2、考核标准 本次实践占形成性考核成绩中的10分。 标准：能根据系统的概述完成系统的整体用例图，并对核心用例能够进行详细描述。 成绩构成：小组得分+个人得分。 小组得分共5分。 （1）任务分工合理，小组合作默契，系统选题新颖、分析透彻，给4-5分。 （2）部分同学参与度低，小组合作欠佳，选题普遍，分析不够透彻，给2-3分。 （3）主要工作全由组长一人完成，小组合作极差，选题陈旧，分析停留在表面，给0-1分。 个人得分共5分。 根据需求报告中小组成员的任务完成情况，给与适当的分数。 （1）用例图中参与者和用例的识别全面、正确，命名规范，关系正确；用例描述详细、流程正确，给4-5分。 （2）用例图中参与者或用例识别不够全面、正确，或者命名不符合规范，或者部分关系不正确；用例描述，不够详细，缺少关键流程，给2-3分。 （3）用例图中缺少关键参与者