ch05用例图用例图建模.ppt

软 件 需 求 分 析 与 建 模 * 会议管理实例分析－需求 会议是保证行政管理实施的手段，会议管理包括会议类别设置、会议室设置、会议申请、会议审核、会议通知、会议纪要、会议查询、会议归档。 会议类型设置是进行会议管理的基础，需要保存的信息包括：会议性质名称、备注，并可对会议类型设置进行修改和删除。会议室设置需要保存的信息包括：会议室名称、容纳人数、会议室资源、使用情况、说明，并可对会议室设置进行修改、删除以及查看使用情况。会议申请是由会议申请人草拟的会议安排，输入信息包括：会议性质、会议议题、预算、会议附件（有附件上传功能）、主持人、记录人员、参加人员、会议地点、会议室、会议开始时间、会议结束时间、会议内容、审批人。可以将会议申请暂存、也可发给审批人或者放弃该申请。 软 件 需 求 分 析 与 建 模 * 会议审核是办公室领导在阅读完申请后签署的修改意见，审核后可以发给办理人，让其发会议通知，或退回给会议申请人，由其发通知，接着由会议起草人起草会议纪要，内容包括：会议名称、纪要内容、附件（有附件上传功能）、记录员、管理员。会议纪要可以提交给会议申请人，由申请人归档或者直接保存。 会议查询包括：已开会仪查询、待开会议查询、会议纪要查询。待开会议查询显示信息包括：会议议题、主持人、地点、时间、与会人员，并可实现分页显示、删除、修改和结束会议。已开会议查询的显示信息和待开会议显示信息相同，可以对其进行删除。会议要的查询信息包括：会议名称、会议议题、主持人、开会时间、开会地点、与会人员，可以对会议纪要进行删除和修改和归档。 软 件 需 求 分 析 与 建 模 * 步骤1－识别参与者 1.角色识别:这是整个用例建模的第一步，那些人和事物能成为角色，首先要它是否要使用未来的系统，和系统发生交互行为，再者要看它使用未来的统是否对它来说具有经济价值，最后还要确定未来的系统是否要实现此需求特性。经过识别，确定一下系统角色：会议申请者，办公室主任，会议办理者，纪要起草人，参会者。 软 件 需 求 分 析 与 建 模 * 步骤2－识别用例 2.用例：在确定了系统角色以后，每一角色使用系统完成什么样的业务，就是用例，系统用例具有概括性和目标性，经过识别，确认一下系统用例：管理会议申请，获取会议纪要，管理会议纪要，分配会议室资源，发送会议信息，获取会议信息。 软 件 需 求 分 析 与 建 模 * 步骤3－关系 3.关系：在系统用例图中，主要识别角色和系统用例间的关系以及角色与角色之间的关系，根据用例的发起者不同，把角色和用例间的关联（通信）关系分为单向管理和双向关联，单向关联有：会议申请人和编辑会议申请，会议纪要起草人和编辑会议纪要，会议办理者和发送会议通知；双向关联有：办公室主任和分配会议室资源，参会者和获取会议信息。 软 件 需 求 分 析 与 建 模 * 步骤4－总结系统需求 4.系统：经过前面分析，未来系统将要实现的需求特征包含：编辑会议申请、编辑会议纪要、获取会议通知、分配会议室资源、发送会议通知，这些元素属于系统内，其余在系统外，属于系统环境。 软 件 需 求 分 析 与 建 模 * 步骤5－顶层用例图 软 件 需 求 分 析 与 建 模 * 步骤6－细化 软 件 需 求 分 析 与 建 模 * 步骤6－细化 软 件 需 求 分 析 与 建 模 * 步骤6－细化 软 件 需 求 分 析 与 建 模 * 步骤7－用例说明文档 用例模型充分反映了角色和系统之间的关系，作为角色和系统之间交互的模型，显然缺乏行为细节描述，因此，需要一份书面的说明文档，象写契约一样，把双方的都要遵守的规则都写进去，用来描述用例的模板很多，没有统一规范，下面就一些常用描述元素做以概括介绍： （1）前置条件：用例执行前必须满足的条件，如果不满足条件，用例不被执行，一般与系统的上下文环境和参数限定有关. （2）后置条件：在用例结束时，系统必须所处的状态，以防止用例执行的结果不确定，影响后续用例的执行。 软 件 需 求 分 析 与 建 模 * （3）基本事件流：路径是从用户角度来描述系统的使用，它关注系统干什么，而不关怎样干。基本事件流是用例中最常发生的路径。 （4）可选事件流：是系统合法的路径，但不是经常发生的路径。 （5）异常事件流：指未来系统要捕获错误的路径。 （6）参与者:触发用例的角色、系统、时间。 （7）用例名称：就是用例图中用例名。 软 件 需 求 分 析 与 建 模 * （1）用例名称：起草会议申请 参与者：会议申请人。 前置条件：会议申请人有条件通过网络访问系统并已成功地登录系统。 后置条件：系统保存一份新的会议申请。 基本事件流： 1.用户通过网络登录后成功访问系统。 2.用户选择会议管理后，再选择浏览会议信息。 3.浏览结束后用户选择查看暂存会