基于UML信访信息系统建模.doc

基于UML的信访信息系统建模 4.1静态结构模型 4.1.1静态模型简介 系统需求建模后，我们将开始面向对象系统分析，其任务是:运用面向对象方法，对问题域和系统结构进行分析和理解，找出描述问题域以及系统结构所需的类和对象，定义这些对象的属性和操作，以及它们之间的静态和动态关系，最终产生一个用户需要的分析模型和详细说明。而分析模型和用例模型最大的不同就是分析模型使用开发人员的语言进行描述，并且反映系统的内部视图。 具体来说，建立系统静态结构模型阶段的活动主要是:发现对象，为对象分类，确定类的属性和操作，确定类之间的关系。系统的静态结构模型主要用类图和对象图来描述。 4.1.2用例图 描绘出顶层的用例图之后，对系统的整体要求和目标有了一个轮廓，此时的用例是比较粗糙的。我们采用了自顶向下的方法细化用例，先勾勒出系统服务的抽象模型，然后细化得出其细节。具体步骤[12]如下： 从用户需求阶段获取的所有用例中选择一个用例； 场景分析：根据参与者的目标确定顺利完成目标的基本交互序列，即先确定用例的主要场景，然后考虑其异常情况和其他可选项，确定次要场景。当得到用例的所有场景后，转入下一步； 用例分解：用例是场景的集合，场景中的每一步都可以看成一个小的子用例； 用例判定：把上面获取的子用例进行分析，如果可以归为参与者的一次简单行为就可以作为一个精细化用例。 我们遵循上面的步骤，完成了用例细化工作。鉴于篇幅原因，仅给出部分用例图。 （1）信访登记子用例 信访登记子用例如图4-1所示：上访群众填写信访基本信息，查询信访办理进度状态；信访工作人员检查信访基本信息的正确性，创建一个提案，对未上交的提案进行修改，取消不符合规定的上访案件，汇报上访登报情况；信访部门领导检阅案件情况，给出初步处理意见，作出指示。 （2）信访处理子用例 信访处理子用例如图4-2所示，包括信访部门员工向处委会提交一个新上访案件件，查询处理进度；信访部门领导审查上访案件，给出指示，交办上访案件；市领导审查上报案件，提交审阅结果。 （3）信访归档子用例 信访归档子用例如图4-3所示，包括归档管理员添加一个已结案的案件，结束案件办理过程，借阅已办上访案件。 （3）信访系统管理子用例 信访系统管理子用例如图4-4所示，包括权限管理员添加用户，删除用户，授予用户权限，回收权限，维护系统，包括备份数据库，恢复数据库，口令管理，日志管理；网络管理员参与系统维护。 4.1.3类图 在用例图的基础上，可以根据用例图来识别类。 从用例识别类，可以提出如下辅助识别问题： (1) 用例描述中出现了那些实体？或者用例的完成需要哪些实体的合作？ (2) 用例执行过程中会产生哪些信息，并储存哪些信息？ (3) 用例要求与之关联的每个角色的输入是什么？ (4) 用例反馈与之关联的每个角色的输出是什么？ (5) 用例需要操作哪些硬件设备？ 如果某个输入可以作为与之关联的角色的属性存在，那么就可以不必转换为类，否则就可以考虑识别为类。对于用例输出的情况，情况要复杂些。我们需要确定该输出的责任实体，如果该实体本身可以包容这个输出，那就无需将输出作为实体，否则将其识别为实体，进而将它们识别为类。在面向对象软件工程方法中，将类分为三种：实体类、边界类和控制类。 1．实体类 实体类是应用领域的核心内容，是与现实事物相对应的类，用于长期保存系统中的信息以及针对这些信息的相关处理行为 ，一般实体类的对象和应用系统本身有相同的生命周期。它们用来保存持久的应用程序实体的有关信息，并提供用于驱动应用程序中大多数交互所需要的服务。表4-1是信访系统实体类图： 表4-1 实体类图 实体类名称 实体类属性 PeopleInformation 人员信息 编号、出生年月、姓名、性别、职业、住址、工作单位姓名、所在公司 Login 用户登录 用户名、密码、权限、终止日期 AppealContent 来访内容 反映类型、涉及方面、单位、主题、摘要、涉案人、涉案人职务、涉案人单位、来源、日期、承办单位 AppealProperty 来访属性 来访人数、来访性质 ExceedAuthorityInfo 越权信息 上访层次、上访情况、超级与否、超级原因、报告、跟踪 ProcessState 处理状态 已办结、正在办理、转向其他机关、未办理 Files 文件信息 文件名称、附件、日期 LetterInfo 信件信息 案件编号、来信人信息、反映情况、性质、处理状态 ProcessInfo 处理信息 上级交办号、内容、登记、结案日期、类别、处理状态 来文编号、收文日期，来文标题、文号、查处情况、信访人情况、处理状态 RecordInfo 记录信息 归档号、文件名、经办人、日期、处理状态 在上表中列出的实体类中，类之间有包含的关系，如RecordInf