办理发文用例模型
1、办理公文用例图
在设计办理发文用例模型之前，先要识别活动者和用例，活动者和用例识别以后，才能建立用例模型。
1.1 活动者识别
活动者是系统分析员与用户交流的起点，也是项目获得后续产品的关键。活动者可以是使用系统功能的人，也可以是软件系统和硬件设备，凡是与系统进行信息交换的外部实物，都可以归为系统的活动者。系统分析员与系统用户深入交流后，明确系统范围，系统功能和外部关联的事物。识别活动者需要往复多次，可以通过向用户询问类识别活动者。如：谁/什么对系统运行的结果感兴趣，会改变系统中的数据，从系统中获取信息，与系统交互。通过对具备这些需求的用户进一步分析，即可识别系统活动者。
1.2 识别过程
与系统发生交互的外部实体有草拟人、审核人、复核人、签发人和分发人。草拟人可识别为发文草拟人，审核人可设别为发文审核人、复核人可识别为发文复核人，签发人一般由相关领导担任，可识别为发文签发人，分发人可识别为分发人。
1.3 用例识别
发文草拟人 新拟发文 编辑发文并保存在系统中 新拟发文用例
发文草拟人 修改发文 修改发文并保存所做操作 修改发文用例
发文审核人 审核发文 编辑审核意见并保存在系统中 审核发文用例
发文复核人 复核发文 编辑复核意见并保存在系统中 复核发文用例
发文签发人 签发发文 编辑签发意见并保存在系统中 签发发文用例
分发人 分发发文 对分发进行登记并保存在系统中 分发发文用例
发文草拟人 送档案室 将发文转入档案室 送发文至档案室用例
1.4 用例图
2、用例描述
2.1 新拟发文
用例目标：当发文草拟人新拟一份发文时用例开始。它处理有关发文的初始化定义及编辑发文等问题，当发文草拟人结束编辑以后用例结束。
前提条件：发文草拟人登录进入系统
成功后件：增加一份草拟发文，发文办理人改为发文审核人
主路径：草拟发文—>提交发文审核人 可选路径：草拟发文—>保存不提交 草拟发文—>放弃新拟发文
2.2 修改发文
用例目标：当发文草拟人修改一份发文时用例开始，它处理对发文的修改，当发文草拟人结束编辑后用例结束。
前提条件：发文草拟人登录进入系统
成功后件：保存对发文的修改，发文办理人改为发文审核人，删除发文草拟人修改该发文的待办事项，增加发文审核人审核该发文的待办事项。
主路径：修改发文—>提交发文审核人 可选路径：修改发文—>保存不提交 修改发文—>放弃对发文修改
2.3 审核发文
用例目标：当发文审核人审核一份发文时用例开始，它处理对审核意见的编辑，当发文审核人结束编辑以后用例结束。
前提条件：发文审核人登录进入系统
成功后件：保存审核意见，发文办理人改为发文复核人，删除发文审核人审核该发文的待办事项，增加发文复核人复核该发文的待办事项
主路径：编辑审核意见—>提交发文复核人 可选路径：编辑审核意见—>提交发文草拟人 编辑审核意见—>保存不提交 编辑审核意见—>放弃对审核意见编辑
2.4 复核发文
用例目标：当发文复核人复核一份发文时用例开始，它处理对复核意见的编辑，当发文复核人结束编辑以后用例结束。
前提条件：发文复核人登录进入系统
成功后件：保存复核意见，发文办理人改为发文签发人，删除发文复核人复核该发文的待办事项，增加发文签发人签发该发文的待办事项
主路径：编辑复核意见—>提交发文签发人 可选路径：编辑复核意见—>提交发文审核人 编辑复核意见—>保存不提交 编辑复核意见—>放弃对复核意见编辑
2.5 签发发文
用例目标：当发文签发人签发一份发文时用例开始，它处理对签发意见的编辑，当发文签发人结束编辑以后用例结束。
前提条件：发文签发人登录进入系统
成功后件：保存签发意见，发文办理人改为分发人，删除发文签发人签发该发文的待办事项，增加分发人签发该发文的待办事项
主路径：编辑签发意见—>提交分发人 可选路径：编辑签发意见—>提交发文复核人 编辑签发意见—>保存不提交 编辑签发意见—>放弃对签发意见编辑
2.6 分发发文
用例目标：当分发人分发一份发文时用例开始，它处理对分发登记，当分发人结束登记以后用例结束。
前提条件：分发登录进入系统
成功后件：保存发文分发结果，发文办理人改为发文草拟人，删除分发人分发该发文的待办事项，增加发文草拟人发文存档该发文的待办事项
主路径：分发人登记分发结果—>提交发文草拟人 可选路径： 编辑复核意见—>保存不提交 分发人登记分发结果—>放弃对分发登记编辑
2.7 送发文至档案室
用例目标：当分发草拟人送一份发文至档案室时用例开始，它处理将发文转至档案室问题，当完成转移以后用例结束。
前提条件：发文草拟人进入系统
成功后件：发文草拟人办理发文转移档案室
主路径：发文草拟人—>送发文至档案室 可选路径： 发文草拟人—>送发文至档案室登录后，放弃送发文至档案室 发文草拟人—>送发文至档案室后，但没有需要送档案室的发文。
