浙江省公安厅后勤处综合管理信息系统设计项目商务文件.docx
《浙江省公安厅后勤处综合管理信息系统设计项目商务文件.docx》由会员分享，可在线阅读，更多相关《浙江省公安厅后勤处综合管理信息系统设计项目商务文件.docx（30页珍藏版）》请在冰豆网上搜索。
浙江省公安厅后勤处综合管理信息系统设计项目商务文件
系统分析设计的方法
面向对象的分析设计
面向对象程序设计中的概念主要包括：
对象、类、数据抽象、继承、动态绑定、数据封装、多态性、消息传递。
1）对象对象是运行期的基本实体，它是一个封装了数据和操作这些数据的代码的逻辑实体。
2）类类是具有相同类型的对象的抽象。
一个对象所包含的所有数据和代码可以通过类来构造。
3）封装封装是将数据和代码捆绑到一起，避免了外界的干扰和不确定性。
对象的某些数据和代码可以是私有的，不能被外界访问，以此实现对数据和代码不同级别的访问权限。
4）继承继承是让某个类型的对象获得另一个类型的对象的特征。
通过继承可以实现代码的重用：
从已存在的类派生出的一个新类将自动具有原来那个类的特性，同时，它还可以拥有自己的新特性。
5）多态多态是指不同事物具有不同表现形式的能力。
多态机制使具有不同内部结构的对象可以共享相同的外部接口，通过这种方式减少代码的复杂度。
6）动态绑定绑定指的是将一个过程调用与相应代码链接起来的行为。
动态绑定是指与给定的过程调用相关联的代码只有在运行期才可知的一种绑定，它是多态实现的具体形式。
7）消息传递对象之间需要相互沟通，沟通的途径就是对象之间收发信息。
消息内容包括接收消息的对象的标识，需要调用的函数的标识，以及必要的信息。
消息传递的概念使得对现实世界的描述更容易。
面向对象设计的优点：
1）数据抽象的概念可以在保持外部接口不变的情况下改变内部实现，从而减少甚至避免对外界的干扰；
2）通过继承大幅减少冗余的代码，并可以方便地扩展现有代码，提高编码效率，也减低了出错概率，降低软件维护的难度；
3）结合面向对象分析、面向对象设计，允许将问题域中的对象直接映射到程序中，减少软件开发过程中中间环节的转换过程；
4）通过对对象的辨别、划分可以将软件系统分割为若干相对为独立的部分，在一定程度上更便于控制软件复杂度；
6）以对象为中心的设计可以帮助开发人员从静态（属性）和动态（方法）两个方面把握问题，从而更好地实现系统；
7）通过对象的聚合、联合可以在保证封装与抽象的原则下实现对象在内在结构以及外在功能上的扩充，从而实现对象由低到高的升级。
面向对象系统开发方法的特点是系统分析、系统设计、系统实施并不是线性的，各阶段的工作之间没有严格的界限，是一个边分析、边设计、边实施、边验证的进化过程。
面向对象的分析是通过分析系统中的对象和这些对象之问相互作用时出现的事件，以此来把握系统的结构和系统的行为。
面向对象的分析模拟人们理解和处理现实世界的方式，视系统为对象的集合，每个对象均处于某种特定的状态。
面向对象的设计则将分析的结果映射到某种实施工具的结构上，这个实施工具可以是面向过程的（如CoBO1、C等），也可以是面向对象的（如Sma11ta1k、C++等）。
当采用面向对象的实施工具时，这个映射过程有着比较直接的一一对应关系，因为面向对象的技术使得分析人员、设计人员、程序员和用户都使用相同的概念模型。
正因为如此，从分析、设计到实施的转变是非常自然的。
UML建模
统一建模语言（UML是UnifiedModelingLanguage的缩写）是用来对软件密集系统进行可视化建模的一种语言。
UML为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。
统一建模语言（UML）是非专利的第三代建模和规约语言。
UML是在开发阶段，说明，可视化，构建和书写一个面向对象软件密集系统的制品的开放方法。
UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面,特别是在软件架构层次已经被验证有效。
UML可以贯穿软件开发周期中的每一个阶段。
UML最适于数据建模，业务建模，对象建模，组件建模。
UML作为一种模型语言，它使开发人员专注于建立产品的模型和结构，而不是选用什么程序语言和算法实现。
当模型建立之后，模型可以被UML工具转化成指定的程序语言代码。
例如,IBM的RationalRose,Ssybase的PowerDesigner和MS的Visio都是UML工具。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
它溶入了软件工程领域的新思想、新方法和新技术。
它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
作为一种建模语言，UML的定义包括UML语义和UML表示法两个部分。
（1）UML语义描述基于UML的精确元模型定义。
元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明，使开发者能在语义上取得一致，消除了因人而异的最佳表达方法所造成的影响。
此外UML还支持对元模型的扩展定义。
（2）UML表示法定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。
这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图（共9种图形）来定义：
第一类是用例图，从用户角度描述系统功能，并指出各功能的操作者。
第二类是静态图（Staticdiagram），包括类图、对象图和包图。
其中类图描述系统中类的静态结构。
不仅定义系统中的类，表示类之间的联系如关联、依赖、聚合等，也包括类的内部结构（类的属性和操作）。
类图描述的是一种静态关系，在系统的整个生命周期都是有效的。
对象图是类图的实例，几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例，而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期，因此对象图只能在系统某一时间段存在。
包由包或类组成，表示包与包之间的关系。
包图用于描述系统的分层结构。
第三类是行为图（Behaviordiagram），描述系统的动态模型和组成对象间的交互关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常，状态图是对类图的补充。
在实用上并不需要为所有的类画状态图，仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动。
第四类是交互图（Interactivediagram），描述对象间的交互关系。
其中顺序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互；合作图描述对象间的协作关系，合作图跟顺序图相似，显示对象间的动态合作关系。
除显示信息交换外，合作图还显示对象以及它们之间的关系。
如果强调时间和顺序，则使用顺序图；如果强调上下级关系，则选择合作图。
这两种图合称为交互图。
第五类是实现图（Implementationdiagram）。
其中构件图描述代码部件的物理结构及各部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。
它可以显示实际的计算机和设备（用节点表示）以及它们之间的连接关系，也可显示连接的类型及部件之间的依赖性。
在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。
从应用的角度看，当采用面向对象技术设计系统时，首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构；第三步是描述系统的行为。
其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图（包含包）、对象图、组件图和配置图等五个图形，是标准建模语言UML的静态建模机制。
其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。
它包括状态图、活动图、顺序图和合作图等四个图形，是标准建模语言UML的动态建模机制。
因此，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。
面向服务的分析设计
面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。
由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA系统原型的一个典型例子是通用对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA），它已经出现很长时间了，其定义的概念与SOA相似。
然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensibleMarkupLanguage，XML）为基础的。
通过使用基于XML的语言（称为Web服务描述语言（WebServicesDefinitionLanguage，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前CORBA中的接口描述语言（InterfaceDefinitionLanguage，IDL）可比了。
Web服务并不是实现SOA的惟一方式。
前面刚讲的CORBA是另一种方式，这样就有了面向消息的中间件（Message-OrientedMiddleware）系统，比如IBM的MQseries。
但是为了建立体系结构模型，您所需要的并不只是服务描述。
您需要定义整个应用程序如何在服务之间执行其工作流。
您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。
因此，SOA应该能够将业务流程与它们的技术流程联系起来，并且映射这两者之间的关系。
例如，会计开发票的操作是业务流程，而更新您的凭据数据库却是技术流程。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。
因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
实施SOA可能带来的主要优势有5点：
一，SOA可通过互联网服务器发布，从而突破内网的限制，实现与各相关业务的紧密结合。
通过SOA架构，各业务间可以直接建立关联渠道，降低接口成本。
二，SOA与平台无关，减少了业务应用实现的限制。
要将各科室业务整合到后勤系统大业务中，对各子业务具体采用什么技术没有限制。
三，SOA具有低耦合性特点，增加和减少子业务对整个业务系统的影响较低。
在子业务系统可能不断发生变化的情况下节省的费用会越来越多。
四，SOA具有可按模块分阶段进行实施的优势。
可以成功一步再做下一步,提高项目实施的有效性。
五，SOA的实施可能并不具有成本显著性。
这要分三种情况加以讨论：
当从零开始构建业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。
当业务发展或发生重组等变化而原有系统不能满足需要，而需要重构业务系统时，采用SOA架构与不采用SOA架构成本可看做是相同的。
当业务发生缓慢变化并可预见到将来需要重构业务系统时，由于可以按模块分阶段逐步实施SOA以适应变化的需要，这样系统建设就不需一下投入一大笔经费进行系统改造，而是根据业务发展情况和资金情况逐步投入，缓解了信息投入的压力。
总结
结合浙江省公安厅后勤处由多个部门或科室组成，并且每个部门、科室均不同层度的应用信息系统的现状,以及系统重建逐步开展的指导思想,本次系统设计时采用面向服务的设计方法,分块抽象相关业务子系统,而在单独的某项子系统中采用面向对象的设计方法,在面向对象设计的过程中采用UML建模设计。
工作业务化（需求调研）
业务模型化（系统分析）
浙江省公安厅后勤处由多个部门或科室组成，每个部门、科室的所有业务流程共同组成了后勤处整体工作流程。
在需求调研阶段，我们采用多个需求调研方法，希望获取到每个科室的业务流程，加上合适的技术分析，将这些业务流程分解成若干不能再分的业务单元，并识别出这些业务单元的基本输入和输出、约束条件、时限性等内容，最终将这些业务单元提交给系统工作流程，形成完整的工作流程提取。
部门业务分解的目标是部门任务的最小化。
也就是说把部门所有的业务操作分解成为最小的不可再分的业务单元，这个业务单元应当包括：
业务单元名称、实现功能、触发（起始）条件、人员、地点、物品、财务、判断、限制条件、时效、输出、审核、存档、终止条件等信息。
1.业务流程分析
在对系统的组织结构和功能进行分析时,需从一个实际业务流程的角度将系统调查中有关该业务流程的资料都串起来作进一步的分析。
业务流程分析可以帮助我们了解该业务的具体处理过程,发现和处理系统调查工作中的错误和疏漏,修改和删除原系统的不合理部分,在新系统基础上优化业务处理流程。
调研阶段已经将业务功能一一理出,而业务流程分析则是在业务功能的基础上将其细化,利用系统调查的资料将业务处理过程中的每一个步骤用一个完整的图形将其串起来。
在绘制业务流程图的过程中发现问题,分析不足,优化业务处理过程。
业务流程图
（TransactionFlowDiagram,简称TFD）,就是用一些规定的符号及连线来表示某个具体业务处理过程。
业务流程图的绘制基本上按照业务的实际处理步骤和过程绘制。
换句话说,就是一“本”用图形方式来反映实际业务处理过程的“流水账”。
绘制出这本“流水账”对于开发者理顺和优化业务过程是很有帮助的。
业务流程图是一种用尽可能少、尽可能简单的方法来描述业务处理过程的方法。
由于它的符号简单明了,所以非常易于阅读和理解业务流程。
业务流程图的基本图形符号非常简单,只有6个。
有关6个符号的内部解释则可直接用文字标于图内。
这6个符号所代表的内容与信息系统最基本的处理功能一一对应。
圆圈表示业务处理单位；方框表示业务处理内容;报表符号表示输出信息（报表、报告、文件、图形等）；不封口的方框表示存储文件;卡片符号表示收集资料;矢量连线表示业务过程联系。
实例
数据流程图
（DataFlowDiagram，简称DFD）是描述系统数据流程的工具，它将数据独立抽象出来，通过图形方式描述信息的来龙去脉和实际流程。
为了描述复杂的软件系统的信息流向和加工，可采用分层的DFD来描述，分层DFD有顶层，中间层、底层之分。
（1）顶层。
决定系统的范围，决定输入输出数据流，它说明系统的边界，把整个系统的功能抽象为一个加工，顶层DFD只有一张。
（2）中间层。
顶层之下是若干中间层，某一中间层既是它上一层加工的分解结果，又是它下一层若干加工的抽象，即它又可进一步分解。
（3）底层。
若一张DFD的加工不能进一步分解，这张DFD就是底层的了。
底层DFD的加工是由基本加工构成的，所谓基本加工是指不能再进行分解的加工。
数据流程图的基本成分
系统部件包括系统的外部实体、处理过程、数据存储和系统中的数据流四个组成部分
1,外部实体
外部实体指系统以外又和系统有联系的人或事物，它说明了数据的外部来源和去处，属于系统的外部和系统的界面。
外部实体支持系统数据输入的实体称为源点，支持系统数据输出的实体称为终点。
通常外部实体在数据流程图中用正方形框表示，框中写上外部实体名称，为了区分不同的外部实体，可以在正方形的左上角用一个字符表示，同一外部实体可在一张数据流程图中出现多次，这时在该外部实体符号的右下角画上小斜线表示重复.
2,处理过程
处理指对数据逻辑处理，也就是数据变换，它用来改变数据值。
而每一种处理又包括数据输入、数据处理和数据输出等部分。
在数据流程图中处理过程用带圆角的长方形表示处理，长方形分三个部分，标识部分用来标识一个功能，功能描述部门是必不可少的，功能执行部门表示功能由谁来完成。
3,数据流
数据流是指处理功能的输入或输出。
它用来表示一中间数据流值，但不能用来改变数据值。
数据流是模拟系统数据在系统中传递过程的工具。
在数据流程图中用一个水平箭头或垂直箭头表示，箭头指出数据的流动方向，箭线旁注明数据流名。
4,数据存储
数据存储表示数据保存的地方，它用来存储数据。
系统处理从数据存储中提取数据，也将处理的数据返回数据存储。
与数据流不同的是数据存储本身不产生任何操作，它仅仅响应存储和访问数据的要求。
在数据流程图中数据存储用右边开口的长方条表示。
在长方条内写上数据存储名字。
为了区别和引用方便，左端加一小格，再标上一个标识，用字母D和数字组成.
1,画数据流程图的基本原则:
①数据流程图上所有图形符号必须是前面所述的四种基本元素。
②数据流程图的主图必须含有前面所述的四种基本元素，缺一不可。
③数据流程图上的数据流必须封闭在外部实体之间，外部实体可以是一个，也可以是多个。
④处理过程至少有一个输入数据流和一个输出数据流。
⑤任何一个数据流子图必须与它的父图上的一个处理过程对应，两者的输入数据流和输出数据流必须一致，即所谓“平衡”。
⑥数据流程图上的每个元素都必须有名字。
2,画数据流程图的基本步骤:
①把一个系统看成一个整体功能，明确信息的输入和输出。
②找到系统的外部实体。
一旦找到外部实体，则系统与外部世界的界面就可以确定下来，系统的数据流的源点和终点也就找到了。
③找出外部实体的输入数据流和输出数据流。
④在图的边上画出系统的外部实体。
⑤从外部实体的输入流（源）出发，按照系统的逻辑需要，逐步画出一系列逻辑处理过程，直至找到外部实体处理所需的输出流，形成数据流的封闭。
⑥将系统内部数据处理又分别看做整体功能，其内部又有信息的处理、传递、存储过程。
⑦如此一级一级地剖析，直到所有处理步骤都很具体为止。
3,画数据流程图的注意事项:
①关于层次的划分
逐层扩展数据流程图，是对上一层图中某些处理框加以分解。
随着处理的分解，功能越来越具体，数据存储、数据流越来越多。
究竟怎样划分层次，划分到什么程度，没有绝对标准，一般认为展开的层次与管理层次一致，也可以划分得更细，处理块的分解要自然，注意功能完整性，一个处理框经过展开，一般以分解为4个至10个处理框为宜。
②检查数据流程图
对一个系统的理解，不可能一开始就完美无缺，开始分析一个系统时，尽管我们对问题的理解有不正确、不确切的地方，但还是应该根据我们的理解，用数据流程图表达出来，进行核对，逐步修改，获得较为完美的图纸。
③提高数据流程图的易理解性
数据流程图是系统分析员调查业务过程，与用户交换思想的工具。
因此，数据流程图应简明易懂。
这也有利于后面的设计，有利于对系统说明书进行维护。
2.设计工具
ProcessModeler简介
在当前的软件开发过程中，系统分析和系统设计阶段普遍存在着较大的问题，一个开发团队，采用什么样的工作方式、采用什么样的描述方法，才能够保证所有团队成员对需求和设计的准确的、共同的理解，满足质量管理的要求，建模无疑是一种最佳的手段。
ProcessModeler（原BPwin）是用于业务流程可视化、分析和提高业务处理能力的建模环境。
它在一个工具中支持业务功能、数据流和工作流建模，它将这三个主要业务目标集成在一起同时满足业务建模和需求分析的要求。
业务过程模型还可作为需求文档，帮您确保项目投资满足业务需求。
ProcessModeler可与业界领先的模型管理系统ModelManager集成，支持分析团队分析复杂的企业业务模型。
并且，ProcessModeler业务模型可与DataModeler数据模型同步，帮助验证您的信息资源可以支持您的业务过程。
ProcessModeler主要技术特性:
使用业务策略，优化过程和信息
ProcessModeler模型为理解业务过程，决定业务事件的影响并定义过程是如何与数据交互的提供了框架。
所有无效的、浪费的、多余的行为都最终被改进、替换或消除。
强大、易用的过程建模
使用ProcessModeler，可以立竿见影地提高生产力。
只需点击几下鼠标，就可创建行为及对象，拖拽鼠标就可重新部署。
ProcessModeler的"探测"功能使浏览和编辑复杂的分层过程模型比以往更容易放大。
功能可使用户迅速地将注意力放在要工作的过程模型上
ProcessModeler将与建立过程模型有关的任务自动化，并提供逻辑精度保证结果的正确一致。
ProcessModeler保留了图形间的箭头关联，所以当模型变更时它们仍保持一致。
高亮的动态对象可指引您建立模型，并防止犯常见的建模错误。
此外，ProcessModeler支持用户定义属性（UserDefinedProperties），让您抓取与您需要相关的信息。
另外，灵活的字体、颜色及其它选项使您的文档更紧密。
您能够使用节点树状图浏览和打印模型。
设计上的不同之处及问题发生的地方都可以用FEO（ForExpositionOnly）图形探究出来，而不会对核心模型有所变更。
用户自定义颜料板可让您做调整，以满足您打印的需求。
从多角度理解用户业务
ProcessModeler支持功能建模、数据流建模和工作流建模，从三大业务角度满足业务分析人士和技术分析人士。
使用功能建模，可以系统地分析业务，着重于规律性执行的任务（功能），保证它们正常实施的控件，实施任务所需要的资源，任务的结果，任务实施的输入（原材料）等。
数据流建模，经常用于软件设计中，注重不同任务间数据的流动，包括数据是如何存储，使可用性最大化及使反映时间最小化。
工作流建模注重于一个特殊的过程，分析涉及的个别任务以及影响它们过程的决定。
使用ProcessModeler建模的好处
从企业的眼光来看，业务过程模型是非常庞大的。
ProcessModeler有许多功能可支持增量开发和过程模型。
它的合并功能可允许多个设计小组分析一个业务的不同部分，创建一个总体视图。
ProcessModeler可以将模型分离，单独修改，然后再重新集成在一起。
分析成本和性能Metrics
ProcessModeler提供对基于行为的成本计算（ABC），并优化过程分析。
详细的报告功能和与ABC工具的双向接口，可以使您更容易地实现基于行为的管理策略。
提供仿真接口，重用模型进行动态建模
对于复杂的操作环境来说，ProcessModeler提供了一个接口给仿真软件，您可重用ProcessModeler模型来探究您业务过程的不同时间的（动态的）交互。
这样可以优化资源分配和过程流，满足您目标工作量。
仿真能够动态地探究变更的影响。
变更实施前能够测试不同的脚本，确保为业务需求提
升级会员 