2222.doc

2.1.3系统开发模式本系统采用模式是在面向对象软件开发领域中流行的统一软件开发过程,也就是（RUP）模式。此模式进行需求分析和设计时使用统一建模语言(UML),用例驱动、以构架为中心和迭代开发是其突出特点,因此采用RUP作为软件开发过程模式是系统开发首选模式,系统需求分析和设计的描述语言当然归UML莫属,采用了数据库设计工具PowerDesign进行数据库的设计,同时采用了较主流的VB开发工具来实现一些功能模块,同时应用到JAVA开发模式。然而UML的弱点是在描述业务流程、数据流程方面,比较专业化的描述工具有时序图、用例图、类图等,采用传统的E-R图、数据流图、功能模块图等描述工具来避免各功能之间的关系相对比较松散。系统分析和设计采用UML语言作为描述方法,系统功能划分的最小粒度是用例,以用例图及类图、用例规约、时序图、活动图作为主要的描述方法。为了增加客户的可读性,在需求分析文档中,增加了描述业务流程的业务流程图,描述客户对系统应用界面的界面示意图。在系统设计文档中,为了让软件开发人员更好理解,对于用例不仅规定了设计的详细内容,还增加了描述用例的前台设计和后台设计的补充设计文档,这样可以避免在开发过程中设计文档和程序不一致的出现。2.2需求描述方法在新版RUP模型中,非常注重业务建模的重要性,因此采用RUP模式,需求分析实际上是用例建模和业务建模的过程,主要包括用例建模和业务建模二个步骤,如图3-1所示。如图3-1所示,业务模型不能代表业务模型中所有的功能,只是描述了客户的业务现状,因此需求分析的第二步就是根据业务模型分析出信息系统的需求进行用例建模。信息系统的需求可以分为功能性需求和非功能性需求,是需求分析描述的主要工具。2.3需求分析过程描述用户需求的主要方式是通过建立模型,为用户、客户和开发方等提供一个交流的平台。这些模型是将需求抽象化,将一个易于沟通的桥梁可视化。分析用户需求与获取用户需求基本步骤相似,不同点在于分析用户需求时使用模型来获取用户更明确的需求,分析需求需要如下:1、活动、描述系统的整体结构、系统的边界与接口用图形表示的方式。客户的总体业务和流程是业务模型应该首先进行描述的,这可以使客户的业务更好理解,具体到所有业务板块,则首先对业务有一个整体的描述和说明,然后描述对业务现状分析的不足之处,最后提出对现有业务的优化思路。采用提出问题、分析问题、解决问题的方法,可以较好地吸引客户参与的兴趣,可以更好地与客户交流互动,这样业务需求的准确度就有了明显提高。例如邮储银行对账集中处理系统总体业务描述采用的是客户易于理解的描述方法,如下所述,邮储银行对账集中处理系统的任务是从账单产生到账单核对正确的所有步骤。邮储银行对账系统整体的结构和流程如图3-2所示：邮储银行对账集中处理系统工作主要可分为以下几个阶段数据采集筛选阶段,账单打印封装阶段、账单回收验印阶段。这些阶段具有严格的流程控制,后一个阶段必须在前一个阶段完成的情况下进行操作。2、需求建模目前数据流图(DFD)、实体关系图(ERD)和UML三种方式是用于需求建模的主要方法,结构化系统分析与设计得到广泛应用的方法是DFD,它是使用四种基本元素来描述系统的实体、过程、数据流和数据存储。由于DFD方法简单,使用者可以方便地得到系统的物理模型和逻辑模型,唯一不足的是DFD图中无法判断活动的时序关系。需求分析阶段使用ERD描述系统中实体的逻辑关系,在设计阶段则描述物理表之间的关系。需求分析阶段描述现实世界中的对象。ERD缺乏对系统功能的描述而只是关注系统中数据间的关系,如果结合ERD与DFD两种方法,则能够更准确地描述系统的需求。本系统使用UML中的用例图、活动图、状态图来对需求建模。用例图是通过描述参与者之间的交互来描述系统的行为。通过分解系统目标,为了实现这些目标用用例图标描述活动者要执行的所有步骤。此方法具有用户导向的优点,使用用例不仅可以方便地得到系统功能的测试用例,用户还可以根据自己所对应的用例来不断细化自己的需求。单个用例或商业过程的逻辑流程、单个操作或方法的逻辑都是由UML活动图记录的。在很多方面,活动图是结构化开发中数据流程图和流程图的面向对象等同体。一个实体基于事件反应的动态行为用UML状态图描述,显示了该实体如何依据当前所处的状态对不同的时间做出反应的。UML状态图是为了研究类、角色、子系统、或组件的复杂行为,建模实时系统。3、用户可以对通过原型、页面或其它方式向用户提供可视化的界面需求做出自己的评价。使用原型分析方法来帮助开发方进一步获取用户需求或让用户确认需求。开发方往往先向用户提供一个布置必要的元素以演示用户所需要的功能可视界面作为原型。本系统充分利用利用客户端为用户提供一个标准的可视化界面,运用C/S结构系统开发的特点。用户可以根据看到系统的