《系统设计功能分析研究 计算机科学和技术专业》由会员分享，可在线阅读，更多相关《系统设计功能分析研究 计算机科学和技术专业（15页珍藏版）》请在金锄头文库上搜索。
1、2.1.3系统开发模式本文主要研究将（RUP）模式运用于系统开发，该模式作为一种软件开发过程在面向对象开发领域中是较为流行的。该模式运用统一建模语言(UML)对需求进行分析和设计，其主要特点为迭代开发、以构架为中心以及用例驱动等，所以说软件开发过程的首选模式就是（RUP）模式，而UML建模语言则是系统进行需求分析和设计的首选语言。此外，本系统在数据库设计方面采用了Power Design数据库设计工具，其中一些功能模块借助于处于主流位置的VB开发工具来实现，同时，JAVA开发模式也本应用到本系统的开发之中。但是，在对数据及业务流程进行描述方面，UML处于一定的弱势，类图、用例图、时序图等描述工
2、具对于流程的描述更为专业，为有效提高各功能模块之间的关联性可以采用功能模块图、数据流图及E-R图等传统描述工具来实现。采用UML语言对系统分析及设计进行描述，其中，用例是系统功能划分的最小粒度，描述时可以采用活动图、时序图、类图以及用例图和用例规约等方法进行。此外，通过在需求分析文档中加入业务流程图来对系统的应用界面进行更为形象的描述，可以提高客户的可读性。同时，为了便于软件开放人员工作的开展，将设计的详细内容及补充设计文档都通过用例加入了系统设计文档中，从而有效避免因设计文档与程序的不相一致而对系统开发过程造成影响。2.2需求描述方法由于新版RUP模式加强了对业务建模的重视，因此本文在系统开
3、发中采用RUP模式，如图3-1所示，系统需求分析也就是对业务及用例进行建模的两个步骤。图中，所构建的业务模型仅仅对客户的业务现状进行了描述，却无法代表其全部功能，进而要求以业务模型为基础，对信息系统的需求进行分析并以此完成需求分析的第二步-用例建模。其中，信息系统的需求主要有功能性和非功能性需求，主要用于对需求分析进行描述。2.3需求分析过程对用户需求进行描述，可以通过建模来构建一个多方交流平台，在该模型中，用户需求被抽象化，同时为用户提供了一个可视化的沟通桥梁。对用户需求进行分析的步骤基本类似于对用户需求进行获取的步骤，其区别在于在进行用户需求分析时所需要的用户需求信息更为准确，这就需要借助
4、于模型来完成，基本步骤为：1.运用图形对系统的边界与接口以及整体结构进行描述。为了更好地了解客户的业务，需要业务模型首先应该对客户的总体业务及流程进行描述，通过对客户业务的总体描述实现对客户所有业务模块的充分了解，进而对其现在及不足进行分析，以针对性地提出优化思路。为了进一步提高业务需求的准确度，需要加强与客户的交流与互动，通常采用对问题进行提出、分析和解决的方法来引起客户的兴趣，以吸引客户参与其中。以邮储银行的对账集中处理系统为例，其业务描述方法着重于易于客户理解，其主要任务是对自账单产生到完成核对的所有步骤进行描述，在图3-2中展现了其整体结构及流程。邮储银行对账集中处理系统主要包括了数据
5、的采集与筛选、账单的打印与封装及回收与验印等几个阶段的工作，这些阶段的工作受流程的严格控制，只有前一阶段的工作完成，才可以开始下一阶段的工作。2.需求建模当前，需求建模的主要方式有UML、ERD（实体关系图）、DFD（数据流图）等三种方式，其中，DFD被广泛应用于结构化系统分析与设计，该方法运用四种基本元素对系统的数据流、数据存储以及系统的实体和过程进行描述。该方法的优点在于其所需的逻辑模型及物理模型易于获得，缺点在于对活动的时序关系难以做出有效判断。运用ERD在需求分析阶段对系统的实体逻辑关系进行描述，而在设计阶段对物理表间的关系进行描述。运用ERD进行系统描述的缺点在于ERD仅对系统数据间
6、的关系进行关注，尚未描述系统功能，若想获得对系统需求更为准确的描述，则需要将DFD与ERD进行结合。本系统需求建模采用的是UML的状态图、活动图及用例图。用例图对系统行为的描述主要通过对参与者之间交互的描述来实现。采用用例图对活动者的活动步骤进行描述，从而实现系统目标。该方法的优点在于用户导向，运用该方法既便于系统功能测试用例的获得，还可以方便用于对照用例对自己的需求进行细化。UML活动图被广泛应用于单个操作或方法的逻辑、单个用例以及商业逻辑流程等的记录。通常来讲，活动图等同于结构化开发中的数据流程图。用UML状态图对实体因事件而引发的动态反应进行描述，可以对实体在不同状态下做出的不同反应进行
7、体现。UML状态图多用于对组件、子系统、角色等复杂行为的研究及建模使用。3.通过向用户提供页面、原型及可视化界面等方式方便用户合理评价自身需求。系统开发方可以通过原型分析法来对用户需求作进一步获取，或者让用户自行对需求进行确认。采用这种方法需要开发方首先向用户提供一个原型，对用户所需的功能通过可视界面进行演示。在本系统中，通过对C/S结构系统开发特点的运用来向用户提供可视化的界面。用户通过可视化界面对原型功能进行了解并提出建议，以便于开发人员对系统作进一步完善。此外，后续开发人员也可以通过借鉴该原型来提前完成系统其他阶段的工作。2.3.1系统功能性需求基于RUP模式的基本结构，在描述系统功能性
8、需求的时候，将用例(Use Case)作为主要描述工具来使用，具体方法为采用分解的方式，将系统功能性需求通过多个用例表现出来。而RUP的好处在于可以通过角色(Actor)对用例进行识别，并且在识别中会反复辨识需求中的漏洞，而且也是系统构架的主要方式。通过分包的形式，将系统用例中的每一层结构都清晰地描述出来，一组用例就是一个分包。如下图3-3中，RUP系统在进行功能分类的时候，采用的是包图形式，可以非常清晰显示系统结构，其中的包图是作为子系统存在的。我们再分析邮储银行的系统功能，邮储银行利用这套系统要实现的对账功能主要有打印对账单、发送、接收以及处理对账单、管理对账信息和数据以及对账任务等方面。
9、另外，还要管理系统的基本数据，包括用户管理、机构管理、角色管理等系统参数。通过包图分类形式，我们将这套系统分为封装账单、账单打印、回收验印系统以及系统基础管理等子包图系统来进行。下文将对系统的功能性需求通过用例模型进行进一步确定并标明范围：1、封装以及账单打印子系统的主要功能及需求这套子系统的功能其实就是通过打印程序来启动打印模板，将账单打印出来，然后启动封装设备将打印出来的账单封装并转入邮寄程序。主要要实现以下功能：（1） 需要从数据库将业务数据进行提取，并导入系统运行，可以根据多种文件格式对接数据格式。（2）可以实现数据的计算、各种分析以及不同数据格式的转换等。（3） 需要根据实际需要按照
10、不同的类别进行排序，如网点分发、邮局投递以及大客户分类等，然后进行打印。（4）打印时，可以自动识别不同的纸张类型并自动适应。（5）根据账单的不同格式，设计精美的模板，方便自己操作，而且不同模板可以打印同一种账单，模板自带广告设计功能，可以设计基本的彩页或者是宣传页面。（6）打印封装接口要多种设备兼容，对各种单体设备或者是一体设备都能兼容支持。根据实际需要对纸张进行切割，而且要实现客户分类功能，同一个客户的多个账单只需要一次封装。（7）自动进行打印优先识别和统筹，自动优化打印方案。（8）银行对账单一般都设有防伪标识，还有条码等索引管理，需要通过扫码设备自动识别并实现软件自动验证。（9）需要实现无
11、人值守自动工作，定时处理进行数据的自动处理，如果出现打印不标准或者其他问题，可以进行重打和补打等。（10）建立安全运作管理，数据的储存和传输需要进行加密处理，防止数据风险。（11）可以通过多种账号类型进行对账处理。（12）对需要冻结打印的客户区分类别并执行冻结打印的操作。2、验印系统，账单回收系统的主要功能及需求这部分子系统的功能主要是通过电子技术对纸质账单进行自动处理，首先在系统中对客户的印章影响进行备案保存，然后通过电子成像技术来进行验证。主要包含以下功能需求。（1）通过扫描成像基础处理所有的回收账单，然后对回收的账单进行处理。（2）得到的对账单影像通过OCR技术进行识别，获得对账单信息，
12、然后导入系统进行验证，确认对账数据准确。（3） 如果客户出现没有确认的对账单或者是未达账需要通过OCR技术进行识别。（4）对账号进行识别，然后自动调取预留印章信息并进行验证。（5）将对账信息和获取的影像直接上传到银行内部数据库中。下图3-5显示了此部分系统的用例示意图：3、系统管理部分的主要功能及需求系统管理主要是进行管理用户信息、机构信息以及进行账单的查询和统计等。基本的功能需求为以下几个方面。（1）对于机构和柜员进行便捷管理，可以灵活进行机构撤并和权限调整。（2）设置所有账单打印、任务管理的详细参数。（3）账户的权限和功能授权维护和管理。（4）管理冻结账单以及客户账单的邮寄。（5）对批打单
13、和补打单进行统计，并且统计打印和邮寄产生的费用，统计对账单回收的具体量和数据。（6）监控对账单处理，通过电子手段量化考核对账中心绩效。（7） 批量验证回收账单，自动审核信息，处理影像存储等。下图3-6显示了此系统模块的功能用例示意图：2.3.2非功能性需求除了系统的功能性需求以外，还有一些需求是非功能性的，例如系统约束，系统模拟假设，系统的稳定性、兼容性以及运行能力，可以达到的服务水平等，系统运行时间外的性能属性和相关的约束规定，这些都非功能性需求。通常系统的非功能性需求不需要进行量化指标说明，只需要通过描述进行衡量。但是，有些系统中也通过量化指标对非功能性需求进行描述，是为了让需求更为准确，
14、可以对照测试，从而获得与某个具体标准的对照，验证系统非功能性需求的情况。此外，系统的故障率高低以及是否可以进行便捷维护和损害恢复表示了系统的可靠性。表示系统性能的内容很多，本文所研究的系统主要从作业响应时间来进行约定。我们通常所说的作业就是用户从一个事件的触发然后到事件的处理并执行结果，包括对数据库的访问和存储，是与所有服务器层都有重要关联的。这里的作业响应时间就是系统在完成目标任务时所需要交互处理的时间。在本文研究的系统中，作业类型主要分为两个部分，一种是交互类作业，一种是查询类作业，文章给出了相对应的参考数据，详细包括识别时间、印章鉴别效率、参数化处理效率以及交易处理量和系统流量管理等。1
15、、印章鉴别效率。自动识别印章的效率可以达到百分之百，而识别后的验证通过率也要达到百分之九十以上。2、账单和印章识别时间。电子验印的时候，系统对于每个识别对象在1.5秒内完成识别，这个时间不计算扫描时间。3、参数化处理效率，也就是统计报表灵活多样，而且支持定制化报表。操作时仅仅对参数配置文件做小范围修改就可以快速实现业务更改。4、系统有时候会遇到超流量访问，需要服务器自动控制流量，后端在处理交易的时候，每笔不能超过1秒时间，这样才能满足前端大量访问的需要。5、交易处理量。根据邮储银行目前出现过的业务峰值扩大几倍吞吐量进行设计，保证单位时间交易的处理量。如果其他的非功能性需求可以用测试指标来表示，
16、也可以量化表示。2.4需求获取模式一般用户对产品的需求以及要求就是需求。那么开始进行软件系统研发的时候，我们必须首先要明白客户到底对系统有什么功能需求，如果没有没有明确的需求，就会造成漫无目的的工作。需求分析就是要根据开发理论确定正确的系统开发方向。所以，必须在系统开发前对需求进行详细描述，而且此需求必须是客户和开发者共同认可的。需求调研必须要面向工作流程。在此之前，要对于业务相关的流程以及与系统相关的流程进行识别，然后按照流程进行需求调研。对于每一个流程的需求调研，必须从流程的开始到结束全部理清。这里需要关注的就是要准确描述需求，保证客户充分参与需求描述。邮储银行的这要财务对账集中处理系统在研发前，对省、市、县各级分行也基层网点进行了大量的需求调研工作，具体方式为会议交流、业务人员座谈以及书面文档等。具体
