基于uml的信访信息系统建模

《基于uml的信访信息系统建模》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

第四章基于UML的信访信息系统建模4.1静态结构模型4.1.1静态模型简介系统需求建模后，我们将开始面向对象系统分析，其任务是:运用面向对象方法，对问题域和系统结构进行分析和理解，找出描述问题域以及系统结构所需的类和对象，定义这些对象的属性和操作，以及它们之间的静态和动态关系，最终产生一个用户需要的分析模型和详细说明。而分析模型和用例模型最大的不同就是分析模型使用开发人员的语言进行描述，并且反映系统的内部视图。具体来说，建立系统静态结构模型阶段的活动主要是:发现对象，为对象分类，确定类的属性和操作，确定类之间的关系。系统的静态结构模型主要用类图和对象图来描述。4.1.2用例图描绘出顶层的用例图之后，对系统的整体要求和目标有了一个轮廓，此时的用例是比较粗糙的。我们采用了自顶向下的方法细化用例，先勾勒出系统服务的抽象模型，然后细化得出其细节。具体步骤[12]如下：（1）从用户需求阶段获取的所有用例中选择一个用例；（2）场景分析：根据参与者的目标确定顺利完成目标的基本交互序列，即先确定用例的主要场景，然后考虑其异常情况和其他可选项，确定次要场景。当得到用例的所有场景后，转入下一步；（3）用例分解：用例是场景的集合，场景中的每一步都可以看成一个小的子用例；（4）用例判定：把上面获取的子用例进行分析，如果可以归为参与者的一次简单行为就可以作为一个精细化用例。我们遵循上面的步骤，完成了用例细化工作。鉴于篇幅原因，仅给出部分用例图。（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记录信息归档号、文件名、经办人、日期、处理状态在上表中列出的实体类中，类之间有包含的关系，如RecordInfo类包含ProcessState类，从人员信息实体类中可以派生出系统实际需要的实体类，结构图如图4-5所示： 2．边界类边界类是系统中与外界进行交互的对象中归纳和抽象出来的，边界类是系统内的对象和系统外的参与者的联系媒介，外界的消息只有通过边界类的对象才能发送给系统，大多数为用户界面(表示层)：可能是与其他系统之间交互的实际界面(Interface)，也有可能是与用户交互的用户界面(userInterface)。表4-2是信访系统边界类图：表4-2边界类图边界类名称边界类属性LoginSkin登录界面允许用户输入有效的用户名和密码，检验用户身份，登录后才能对自己权限里的项目进行操作VisitingSkin来访界面允许填报来访信息LetterSkin来信界面允许填报来信信息AuthorityDeliveringSkin转办界面允许领导对下级转办上访案件JuniorReportingSkin汇报界面允许下级向上级领导填写汇报信息LeaderAnsweringSkin批示界面允许领导填报批示信息 FileManageSkin文件管理界面允许管理员管理文件信息QuerySkin查询界面允许一般人没查阅信息SystemMaintainSkin维护界面允许系统管理员修改权限信息、备份、恢复数据库3.控制类控制类是管理实体对象与边界对象之间交互的仲裁对象，通过控制类协调系统内边界类与实体类之间的交互，可将案例的细节部分和复杂的计算或商务逻辑封装起来。控制类用于系统内的模型行为，用于对一个具体用例的控制或其他业务逻辑建模。如表4-3所示。表4-3控制类控制类名称控制类属性UserLogin用户登录根据不同的用户转向不同的界面NewInformation新增信息新增信息到数据库Researchnformation查询信息检索出用户查询信息ModifyInformation修改信息对修改请求进行处理DeleteInformation删除信息对删除请求进行处理BackupDatabase备份信息对备份请求进行处理RestoreDatabase恢复信息对恢复请求进行处理4.2动态行为模型4.2.1动态模型简介系统的动态行为模型由交互图、状态图和活动图表达。在系统的分析和设计中应当对主要的用例和对象类绘制这些图形，以便分析系统的行为，印证和修改系统的静态结构，满足用户的需求，达到系统的目标。本节用顺序图描述了用例的主要场景，用活动图描述了对象的过程。4.2.2顺序图在UML中，顺序图是一种交互关系，强调交互发生的时间顺序。它由活动者(actor )、对象(object)、消息(message)、生命线(lifeline)和控制焦点(focusofcontrol)组成[24]。用垂直虚线来表示生命线，水平方向上用一个带有垂直虚线的矩形框表示不同的对象，对象间的通信通过对象的生命线间的消息来表示。消息的箭头指明消息的类型。下面是系统的部分顺序图。（1）信访登记顺序图图4-6给出信访登记的顺序图，首先，信访部门员工向系统发送请求，要求系统实现输入操作，系统记下请求数据并发送消息给数据库服务器,通知数据库服务器实现检查数据合法性操作，这个操作决定是否接收录入的数据。处理完来自系统的消息后，返回应答消息，系统在收到确认消息后，向数据库服务器传送数据，数据库服务器向自己发送一条消息，实现数据存储操作,然后，数据库服务器返回处理的相关信息。（2）信访查询顺序图图4-7是信访查询顺序图，信访部门员工向系统提出查询请求，系统打开查询输入窗口，用户在窗口中输入查询的条件，并向系统提交查询命令，系统对查询命令作合法性检查操作后，通过查询提交操作向数据库服务器提交最终查询请求，数据库服务器将查询结果送回终端显示；用户可根据需要对查询结果进行更新操作，也可以对查询结果进行打印输出。 (3)信访归档顺序图图4-8是信访归档顺序图，归档管理员向系统提出归档请求，系统按案件编号向数据库服务器请求合法性检查操作，当案件处理符合归档要求，返回相关信息；归档管理员向系统增加结案案件，系统将结案信息写入结案清单表。 （4）存档借阅顺序图图4-9是存档借阅顺序图，借阅人员向系统提交借阅申请，系统检查借阅者权限，合法借阅申请的情况下，系统向数据库服务器发送执行消息，请求执行借阅操作，数据库服务器向自己发送一条消息，实现借阅查询操作，然后，数据库服务器返回相关信息给借阅人员。 4.2.3状态图状态图用来描述一个特定对象、子系统或者整个系统在其生命周期内的所有可能的状态及其引起状态转移的事件，是对类图的一种补充。状态是一种存在状况，它通常具有一定的时间稳定性，所有对象都具有状态，状态是对象执行了一系列活动的结果。状态图中定义的状态有：初态、终态、中间状态、复合状态。其中，初态是状态图的起始点，而终态则是状态图的终点。一个状态图只能有一个初态，而终态则可以有多个[27]。在建模时，没有必要对所有的对象描述状态变化，只需要将有多个状态且行为受外界环境的影响并且发生改变的对象画出状态图，以指导系统的具体实现。图4-10是信访办理的状态图，上访办理过程可看成是状态之间的迁移过程，宏观上有以下状态序列：注册上访信息；处理上访信息；归档上访信息；其中，处理状态是个复合状态，包含四个子状态，上访信息可能直接被批示或者转交相应单位办理，在批示状态后，上访人不满结果可以提出复查申请，进出复查申请状态。案件　督查状态表示在处理过程中随时接受督查。 图4-11是查询子状态，若查询请求具有合法性，状态由请求查询状态变迁到执行查询状态，若有相关记录，状态变迁到返回结果状态，在返回结果中要开始一个新查询，状态又变迁到请求查询状态。图4-12是借阅子状态图，系统由请求借阅状态变迁到执行状态，若有相关记录，状态变迁到返回结果状态，否则返回请求借阅状态。要开始一个新借阅请求，状态又变迁到请求借阅状态。4.2.4活动图活动图的核心是活动状态，它表示工作流过程中命令的执行或活动的进行。与等待发生的一般等待状态不同，活动状态用于等待计算处理工作的完成。当活动完成后，执行流程转入到活动图中的下一个活动状态[14,15]。用活动图为工作流建模时，一般应遵循以下步骤：（1）识别该工作流的目标；（2）利用一个开始状态和一个终止状态分别描述该工作流的前置状态和后置状态；（3）定义和识别出实现该工作流的目标所需的所有活动和状态，并按逻辑顺序放置在活动图中；（4）定义并画出活动图创建或修改的所有对象，并用对象流将这些对象和活动连接起来； （1）用变迁将活动图上的所有元素连接起来；（2）在需要将某个工作流划分为可选流的地方连接起来；（3）查看活动图是否有并行的工作流。若有，用同步表示分岔和汇合。下面是信访信息系统用到的部分活动图。1）信访处理活动图图4-13是信访处理过程活动图，处理过程活动序列如下：1．登记上访信息；2．初步核查了解情况；3．提出处理意见；4．分管副局长审查；5．如果是普通案件或个访，则作出批示，如果是重大事件或集体上访,则上报上级领导批示；6．转交相关单位办理；7．给出处理意见；8．如果上访人提出复查申请,则进行复查处理；9．结案；10．归档。 2）信访查询活动图图4-14是信访查询活动图，活动序列如下：1．提出查询请求； 2．填写查询条件；3．检查查询请求，如果查询条件不合法，重新输入，否则执行查询命令；4．执行查询命令，如果找到相关记录，返回查询结果，否则结束查询；5．返回查询结果，对返回的结果可以进行更新，保存，打印操作；6．对查询记录进行更新操作；7．保存更新结果；8．打印查询结果。4.3物理模型4.3.1组件图软件组件是软件系统的一个物理单元，作为一个或多个类的软件实现，组件贮留在计算机中，而不是只存在系统分析员的脑海里。组件提供和其他组件之间的接口。用来建模系统的各个组件，包括源代码文件、二进制文件、脚本、可执行文件之间的关系，它们是通过功能或者位置组织到一起的。使用组件图建立模型主要有以下用途： （1）使客户能够看到最终系统的结构和功能。（2）让开发者有一个工作目标。帮助我们了解某个功能位于软件包的哪个位置，以及各个版本的软件包各包含哪些功能。（3）让编写技术文档和帮助文件的技术人员能够理解所写的文档是关于哪方面内容。（4）利于复用。4.3.1.1系统软件包建模图4-15描述了系统几大功能模块组件图，系统包括信息注册包、信息管理包、归档管理包、系统管理包、应用包、数据库包六个功能包，信息注册包、信息管理包、归档管理包、系统管理包通过接口与应用包相连，应用包是一个中间件，通过接口又与数据库包相连。4.3.1.2源代码文件建模对源代码的图形化建模有助于可视化源代码文件之间的编译依赖关系[8]。可以有助于开发者利于开发工具去跟踪这些文件以及它们之间的依赖关系。图4-16所示的组件图表示了源文件间的依赖关系。RegisInfo头文件被RegisInfo.app和Interp.app引用，Interp.app引用Database.h文件，从依赖关系，很容易跟踪变化情况。 图4-16源代码文件组件图4.3.2部署图部署图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。部署图可以显示计算节点的拓扑结构和通信路径、节点上运行的软件、软件包含的逻辑单元（对象、类等）。特别是对于分布式系统，部署图可以清楚地描绘硬件设备的配置、通信以及在各设备上软件和对象的配置。部署图中的节点表示一个物理设备以及在其上运行的软件系统，节点之间的连线表示系统之间的通信路径，在UML中称为连接。部署图中的各个节点的安置不受地理位置的限制，小则可以放在一间房间内，大则可以安置在地球上的不同国家和地区。两个节点之间的通信路径仅仅表明节点之间存在着联系，该连接可以采用不同的通信协议。图4-17为信访信息系统的部署图。在服务器端使用了两台主机，一台作为数据库服务器，使用了SQLServer服务器，另一台是web服务器，使用IIS服务器，他们之间通过局域网连接。 4.4小结本章利用UML对信访信息系统进行分析与设计，分别进行系统静态结构建模、系统动态行为建模及物理建模，结合该系统建立了用例图、类图、包图、顺序图、合作图、状态图、活动图、组件图和布署图。