第0章 案例介绍及分析

本章将从软件工程角度来描述城市公交行车安全管理系统的事故信息管理系统，着重讲述系统的需求分析过程，包括业务分析、用例分析及流程分析。该系统已经在某公共交通公司使用4年，效果良好，本书作者均参与了该系统的开发和设计工作。案例的分析将遵循工程开发的特点，本书中的实例均来自本案例。

本章学习要点：了解本案例主要内容；了解需求分析方法。

0.1 案例介绍

0.1.1 城市公交行车安全管理系统

城市交通网络在城市发展中占有至关重要的地位。长期以来，交通事故和违章问题已成为困扰城市发展的重要问题，这些问题的解决必须依赖信息技术与管理技术的有机结合。公交行车安全管理系统的研究开发和推广应用必须建立在整个城市公交网络的建设和应用的基础上。近年来，特别是2003年以后，随着公交网络的建设趋于成熟，公交行车安全管理系统的开发引起国内公交部门和相关公司的关注，并投入大量人力、物力进行研发，开始了该系统研究开发的高潮。

城市公交行车安全管理系统主要由四大功能模块组成，分别是基础信息管理模块、事故信息管理模块、违章信息管理模块和安全台账信息管理模块，如图0-1所示。基础信息管理模块包括公交司机管理、系统用户管理、车辆信息管理、单位信息管理、安全辅助信息管理等，它的功能是管理系统正常运行所需的基础数据。

事故信息管理模块的主要功能是登记公交事故基础信息（包括事故基础信息、事故伤情信息、事故中第三者相关信息），形成公交事故信息工作流审批机制，处理事故借款和事故退款，登记直接事故费用明细。

违章信息管理模块的主要功能是登记公交车辆违法违章信息，形成公交违章信息工作流审批机制，处理司机违法违章处罚信息。

安全台账信息管理模块的主要功能是针对各种安全隐患（包括线路、车辆、人员、环境）进行定期梳理、分析，将梳理结果录入系统，制定安全计划和安全对策。

本书的案例采用了城市公交行车安全管理系统中的事故信息管理模块。以下将从需求分析和数据库设计方面来介绍和剖析其中的事故信息管理模块。

0.1.2 事故信息管理系统

事故信息管理系统主要用于登记公交司机肇事相关信息，并提交给公交企业内各部门核准。在事故信息管理系统中，事故统计的粒度是一起司机肇事事故记录。该记录包含三部分内容，分别是事故场景信息、事故登记信息、事故费用明细。事故场景信息主要描述事故发生时的外在因素，包括天气、道路状况等。事故登记信息主要包括事故发生时事故双方情况、责任、性质等。事故费用明细是指事故发生后，面向公交企业所涉及的各种收入和支出费用，包括撞坏车修理费、保险费等。在公交企业内，有四种角色涉及事故管理，分别是安全员、安全部门、计财部门和经理室。

目前公交企业处理交通事故主要采用多级审批制度。一起事故发生后，由安全员登记事故明细信息，包括事故发生的场景信息、登记信息和部分事故费用的信息，登记完后，安全员将登记完成的事故向安全部门申报。申报的事故需要经过三个部门的审核，分别是安全部门、计财部门和经理室，其中安全部门负责确定事故的性质和责任（即定性定责），计财部门负责审核事故发生后的费用明细，经理室确定事故结案与否。如果安全部门判定该事故需要向公司借款，那么司机就向当事的安全员申请，安全员将借款申请递交给公司的计财部门，由计财部门审核款项并实行借款流程，待整个事故的收入和支出的款项不再发生变动时，再由安全部门向计财部门申报该起事故，计财部门再次进行收入和支出款项的审核，审核完毕后向经理室申报，在通过经理室审核后，该起事故才能结案。但是大部分事故会涉及第三者费用，此时事故就将处于未结案状态，等待费用结算清楚，通过经理室审核后才能结束。事故在审核过程中，如果有一个部门审核不通过，那么该事故就会退回到登记该事故的安全员这里，安全员必须重新核实这起事故，并修改事故信息，重新申报。事故申报流程见图0-2。

0.2 系统需求分析

0.2.1 系统设计的目标及原则

在本系统设计前，公交企业所使用的是手工处理事故单及纸质审批流程，信息化方面仅限于报表的生成及司机安全公里的统计。因此现行系统没有考虑到事故的跟踪手段和审批控制；现行系统的事故登记是纸质材料登记，缺乏有效的数据分类，无法进行后期的数据统计和分析；现行系统的数据共享比较困难，各个部门无法实时查询本部门关心的数据。综上所述，本系统设计的目标及原则有以下几点：

1）提高事故处理规范性、提高事故处理效率。主要原则：

●对事故发生时的场景信息进行标准化及量化，以便统计分析。

●简化事故流程，采用信息化工作流形式审核事故信息。

●每级审核均有记录，该记录包括审核时间、审核人等关键信息。

●建立统一的事故定性定责衡量标准，规范事故评定。

2）真实记录和反映事故处理全过程，保留完整信息、形成完整事故电子案卷、保留全部管理信息，为事故管理提供依据。主要原则：

●系统充分结合事故处理过程来记录信息，使信息能够及时、按阶段完整采集，提高信息的准确性、及时性、完整性。

●事故信息不仅仅包括文本的事故基本情况信息，还有照片、现场记录视频、证明材料复印件等，系统可以实现完整的案卷管理、电子调卷阅卷。

3）加强对事故数据的整理、统计分析，以求降低事故发生几率，为管理提供辅助决策的依据。主要原则：

●以大量的、详尽的事故数据为基础，创建数据分析模型。

●以数据仓库方式建模，形成大数据视图，为查询提供支持。

●完善事故成因分析，事故多发分布分析，事故信息与违章、流量、设施信息叠加分析等。

●为其他系统提供必要的接口。

系统的主要设计工具如下：需求分析主要工具为Microsoft Visio 2010，数据库设计主要工具为PowerDesigner 15.1。

系统名词解释：

结案：是指一起事故处理完毕案子结束状态，包括没有纠纷、收入和支出的款项一致、总经理审核通过。

事故借款：是指事故发生后，公交企业为解决公交事故而预支（垫付）的款项。

司机累积公里：是指司机从停车场出发至下班回到停车场所运营的里程数。

司机安全公里：司机累积公里减去司机违章事故等扣罚的公里。

0.2.2 系统业务分析

根据0.1.2节中现行事故信息管理系统的介绍，可以将一起事故划分为4种主要状态，分别是初始状态、一般未结案、借款未结案、结案。

事故发生后，由安全员登记事故明细信息，此时，事故状态是“初始状态”；安全员将登记完成的事故向安全部门申报，此时，这起事故的状态被置为“一般未结案”状态；申报的事故经过三个部门的审核，分别是安全部门、计财部门和经理室，如果安全部门判定该起事故需要向公司借款，那么事故状态就变成“借款未结案”，待收入和支出的款项不再发生变动时，再由安全部门将该起事故置为“一般未结案”状态；事故信息在通过经理室审核后，状态置为“结案”。通过这样的流程，一起事故处理才算真正结束。

一般事故处理程序如下：

事故在审核过程中，如果有一个部门审核不通过，那么该事故就会退回到登记该事故的安全员这里，状态又会变更为“初始状态”，安全员必须重新核实这起事故，并修改事故信息，重新申报。

综上所述，可以将事故信息管理系统细分为公共信息管理、事故信息管理、事故处理和报表统计四个子模块，见图0-3。

（1）公共信息管理子模块业务分析

该子模块是整个系统的外围辅助模块，主要功能是维护整个行车安全管理系统中的基础数据，包括权限管理、人车基础信息管理、字典管理和日志管理。权限管理基于“用户–角色–功能”的传统结构，即角色是功能的集合，用户属于角色，“功能”就是权限，它包含了菜单项和界面中按钮的使能；人车基础信息管理是对使用该系统的人员（用户）和公交车辆的增、删、改；字典管理是对常用的参数、属性的管理；日志管理记录了系统操作过程中发生的错误信息，包含日志内容、日志时间、操作者等属性。

（2）事故信息管理子模块业务分析

该子模块管理的数据是事故信息管理系统中用到的基础数据，包括司机基础信息管理和路口基础信息管理。司机基础信息管理不同于单纯的人员管理，它包含了更多的司机专门信息，如司机初领证时间、准驾车型、驾驶证编号等；路口基础信息管理将城市中所有的路口进行统一编号，并且路口还有一些特殊属性，如限速、有无斑马线、路口形状等，这些信息的量化方便管理层进行数据分析和统计。

（3）事故处理子模块业务分析

该子模块是系统的核心模块，处理事故信息登记、事故流程管理、事故借款流程管理等，包括第三者信息管理、事故伤情管理、事故管理、安全公里管理和事故借款管理等。第三者信息管理用于登记事故中第三者的相关信息，事故伤情管理用于登记事故中伤者相关信息，事故管理包含事故信息录入和审核（工作流方式），安全公里管理用于计算定性定责的事故中司机被扣罚的公里数，事故借款管理用于完成事故中的款项预支的申请、审批等事宜。

（4）报表统计子模块业务分析

该子模块为用户提供直接查询结果，生成月报和年报，即将之前的数据整合形成完备性视图来完成查询统计，包括查询统计和报表输出。

综上所述，我们可以将一起事故看作一个实体，事故处理均围绕这个实体展开，事故的审核过程看作工作流形式，这个工作流有多种状态。下面将从软件工程的用例分析来剖析事故信息管理系统。

0.2.3 系统用例分析

本节的用例分析将以公共信息管理、事故信息管理和事故处理三个子模块为例来探讨，用例分析将结合上一节的业务分析，从业务分析中提取参与者和用例，获取它们之间的关系。由上可知事故信息管理系统中共有四种关键角色，分别是安全员、安全部门、计财部门、经理室。从整个系统的完整性来说，还需要增加管理员的角色。每个子模块的用例图都是利用Microsoft Visio完成的，各子模块的用例分析如下。

1.公共信息管理子模块用例分析

在上一节的业务分析中已经明确了公共信息管理子模块包含的主要内容，其中，权限管理是该子模块的核心，它实现了对“功能”、“角色”、“用户”、“系统”四者的融合，功能附在角色上，用户属于角色，功能归属于系统，用例图如图0-4所示。

因此，一个用户可以属于多个角色，一个角色可以拥有多个用户；一个角色可以是多个功能的组合，一个功能可以分配给多个角色；一个系统由多个功能组成，本案例中的“系统”主要为事故信息管理和公共信息管理。

2.事故信息管理子模块用例分析

事故信息管理子模块包括了司机基础信息管理和路口基础信息管理，用例图如图0-5所示。它们的增、删、改等管理操作均由安全员操作。司机基础信息管理中的司机部分属性在公共信息管理中，如司机姓名、司机所属单位等。

3.事故处理子模块用例分析

事故处理子模块的用例比前两个子模块稍显复杂，如图0-6所示，该子模块共有4个参与者，分别是安全员、安全部门、计财部门和经理。事故管理和事故借款管理是该子模块的核心，从上一节的业务分析中可以看出，事故管理包含了事故申报信息增、删、改的管理和事故审核工作流的管理，事故借款管理也类似包含了事故借款申报信息增、删、改的管理和事故借款审核工作流的管理，安全员主要录入事故申报信息、第三者事故信息、事故伤情信息和事故借款申报信息，安全部门、计财部门和经理负责审核申报的信息。一张事故申报单（简称事故单）可以关联多张事故借款申报单（简称事故借款单），一张事故单也可关联多个第三者信息及伤情信息。安全公里管理主要针对肇事司机累积公里扣罚的管理。

系统的用例把整体的业务逻辑进行了梳理，从中我们可以发现系统最关键的业务流程是事故审核流程和事故借款审核流程，下一节将着重讨论关键的业务流程，以便数据库概念结构设计的展开。

0.2.4 系统流程分析

从0.2.2节可以知道，一起事故共有4种主要状态，分别是“初始状态”、“一般未结案”、“借款未结案”、“结案”。我们先来讨论事故的正常结案流程（即不考虑借款情况）。在事故的正常结案中，事故审核过程符合简单工作流的处理过程，事故单是工作流程中活动的表单，它的生命周期如图0-7所示。

表0-1 事故性质与事故单状态对应关系

注意：事故性质和事故单状态是两个不同概念，事故性质是指该起事故从产生到结案所经历的过程中的状态；而事故单状态是指该起事故形成的事故单在各部门审核工作流中的状态。两者的区别是前者强调事故整体所处的阶段，后者只是指事故单审核所处的阶段，前者包含后者。两者的状态关系见表0-1。

事故单审批经历了三个部门，图0-7中就需要三个“泳道”来表达，事故单由安全员填写并申报后，由三个部门审核，审核有通过和不通过两种状态，共经历了安全主管、客运科长、计财部门、分管经理和总经理5个审核结点，每个审核结点有两种状态，那么审核过程就需要10种状态来表示；而事故单录入时也有两种状态，分别是“录入”和“申请”状态，处于“录入”状态的事故单还可以由安全员修改，并且在每一个审核结点不通过的情况下，事故单还会处于“录入”状态；事故单通过总经理审核后，表示该起事故可以结案。

综上所述，事故单在工作流程中有12种状态，这12种状态与事故性质的对应关系（不考虑事故借款情况）如表0-1所示。

以上流程分析未涉及事故借款的因素，如果该起事故需要先支付垫付款，那么就需要走事故借款流程，当安全员填写事故单时，认定事故需要借款，那么安全员就需要填写事故借款信息，生成事故借款单，此时这起事故的结案状态自动变为“借款未结案”，事故单就无法向上级部门申请审核，而生成的事故借款单由安全员向上级部门申请审核，共需要三个部门的审核，审核流程如图0-8所示。审核过程类似于事故单审核流程，只是事故借款单所经过的部门审核的顺序不同。如果该起事故相关的事故借款单均通过了计财部门的审核并且安全员不再申请新的事故借款单，那么安全员可以将该事故单性质置为“一般未结案”，并向安全部门申请审核，该事故单就可以走事故的正常结案流程。