基于GRAPPLE和XP的管理信息系统的开发

开篇：润墨网以专业的文秘视角，为您筛选了一篇基于GRAPPLE和XP的管理信息系统的开发范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：我国业界软件的开发现仍采用的是小作坊式或天才式的开发模式，为了使中小型软件企业摆脱这种作坊式或是天才式的开发模式，进入标准化、团队化、规范化的阶段，本文提出了一套GRAPPLE和xp整合设计的软件开发过程框架。本文主要对GRAPPLE和XP整合设计的管理信息系统进行了详细的探讨。

Abstract: This paper firstly introduces the basic concept of GRAPPLE and XP, whose application is fi-nally analyzed by developing a enterprise inventory management system.

关键词：GRAPPLE；XP；UMLs；软件工程

Key words: GRAPPLE；XP；UMLs；software engineering

中图分类号：TP315 文献标识码：A文章编号：1006-4311（2010）35-0047-03

1GRAPPLE和XP简介

由于受到软件危机的影响，软件的开发过程对软件开发团队提出了更高的要求，比如需要更多考虑用户需求、开发速度要求更快，同时要保证软件的质量绝对可靠等问题。一直以来业界软件的开发过程都是采用瀑布模型等早期的传统软件工程方法，瀑布模型的特点是层次很清晰，从系统的问题定义、可行性分析、需求定义等一路下来，每一步的开始都要以上一步的完成作为前提。随着业界对用户需求、软件的扩展性等问题考虑的越来越多的情况下，一些新的软件开发方法和思想涌现了出来，其中影响比较大的是敏捷方法学，而其中更为使用的普遍的是GRAPPLE和XP极限编程方法。XP是一种软件过程思想，旨在解决软件生命周期中存在的问题。

极限编程主要是由十二大简单却互相依赖的基本原则组成。这些原则结合在一起形成了1个胜于部分结合的整体。它们分别是:计划游戏、小型、简单设计、测试驱动开发、持续集成、重构、结对编程、代码共享、可持续进度、现场客户、隐喻及编码标准。下面将结合个人实践主要对（小型、代码共享、隐喻及编码标准）原则进行浅析。

XP的小型：小型就是快速地将简单系统做成产品，接着在较短的周期内新版本。小型版本是1个可交流的好办法,用户可以尽早针对性提出反馈，开发人员根据用户的反馈纠正瑕疵,那么系统就不会偏离用户的真正需要太远。

国外研究者进过总结，Rational公司融合Grady Booch、James Rumbaugh、Ivar Jacobson三位软件工程大师的理论，提出了Rational Unified Process(软件统一开发过程)。但RUP有其自身的缺陷：它本身结构复杂和知识点多难以把握，还有它支持多项目开发的能力较弱。

Grady Booch、James Rumbaugh、Ivar Jacobson三位软件工程大师的理论又提出了GRAPPLE开发过程，它也高度支持UML，且比RUP易于操作，适用于中小型组织MIS的开发，但GRAPPLE不是固定不变的，“它是一组可自适应的、灵活的开发思想，它为项目经理留有余地，以便让他们发挥自己的创造力和好的思想来适应自己的组织，减少不必要的一些开发步骤。”

GRAPPLE由5个段组成，提出使用“段”而不是“阶段”为的是说明不是通常意义上的那种一个阶段完成后，下一阶段才开始。每个段又由许多动作（action）组成。每个动作产生一个工作产品，并且每个动作都是一个特定的执行者（player）的职责。

GRAPPLE有下列段：①需求收集；②分析；③设计；④开发；⑤部署。其中需求收集段包括发现领域过程、领域分析、识别协作系统、发现系统需求和将结果提交客户；分析段包括理解系统的用法、充实用例、细化类图、分析对象状态变化、定义对象之间的交互、分析与协作系统的集成；设计段包括开发和细化对象图、开发构件图、指定部署计划、设计和开发用户界面原型、测试设计和开始编制文档；开发段包括编制代码、测试代码、构件用户界面和用户界面到代码的连接测试和完成文档；部署段包括编制备份和恢复计划、在硬件上安装最终系统和庆祝。

总之，GRAPPLE的运动方式是从一般到具体――从不精确到精确。它开始于一个对领域的概念理解，然后是系统的高层功能，接着继续深入每个用例、细化模型，最后设计、开发和部署系统。

UML是由著名的面向对象专家Grady Booch，James Rumbaugh 和Ivar Jacobson共同设计的一种软件建模语言，它功能强大，易于表达，全面支持面向对象的整个开发过程。

统一建模语言UML包括13种图形，构建一个系统不是每种图都能用上，其中重要的内容可有由5类图来定义：①是用例图，用来描述系统边界和主要功能，并指出各功能的操作者。②是静态图，包括类图、对象图和包图。用来描述系统的静态结构。③是行为图，包括状态图和活动图。用来描述对象的动态特征。④是交互图，包括顺序图和协作图，主要通过对象间的交互关系来描述系统的动态实现。⑤是实现图，包括构件图和配置图。构件图描述代码部件的物理结构及各部件之间的依赖关系。配置图定义系统中软硬件的物理体系结构。

简言之，UML可以从静态结构和动态行为两方面来描述系统。静态结构定义了系统中的对象和操作以及它们之间的联系,动态行为描述了对象之间的交互过程及通信机制。因此，UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

2应用实例――小型超市进销存销售管理系统

2.1 需求收集段在需求收集段，主要工作是发现业务过程、进行领域分析、识别协作系统、发现系统需求及提交结果等。核心就是通过与用户的各种交流,发现用户的需求并进行初步的分析。结果可以用反应业务流程的活动图、反应业务领域的高层的UseCase图，初步的类图和其他的文档形式表达。

进销存管理系统首先应包括三个子系统：销售管理子系统、采购管理子系统、仓库管理子系统。根据GRAPPLE，分析人员先与企业人员面谈，了解企业的业务流程以及对企业所处的领域进行分析，由此分析人员得到一组关于业务过程的活动图（如图1所示）和一个高层的类图和会谈记录。之后，分析人员需识别企业是否还使用其他的系统，如财务管理系统，进销存系统不是独立存在于企业，它必须与企业中其他的系统协作。

此处采用XP的小型，主要是企业人员因为是非专业人员，通常不能准确描述用户的需求，所以分析人员通过和企业人员面谈，先自行快速开发出一个业务模型，以及借助于这个业务模型，快速进行软体测试版的代码编写工作。

然后我们采用联合应用开发会议（Joint Application Development session，JAD session），来进行需求收集。采取JAD而不是单独会谈获取需求，一是因为系统的开发是一个很短的开发时限，而单独会谈可能耗时数周或更长的时间，而且单独会谈时可能产生意见上的分歧，解决这些分歧又要浪费更多的时间。由此得到的是一个表示高层领域的用例图包（如图2所示）。

最后开发人员完成需求段的动作后，把这些动作产生的结果提交给客户，这是一个迭代的过程。

2.2 分析段在这一段里，应深入分析需求收集段获得结果并增进对问题的理解。其中主要工作是进一步理解系统，充实用例，细化类图，分析对象状态变化，定义对象之间的交互以及分析与协作系统的集成。事实上，分析段和需求段之间是没有严格的界限的，分析段的部分工作在需求段就已经开始。

进销存管理系统由仓库管理、销售管理、采购管理三部分组成。由于进销存管理系统比较复杂，限于篇幅，以下就仅以销售子系统为例说明UML在分析段中的应用。销售管理还可以分解成以下一些用例：“销售合同管理”、“大客户管理”、“产品推销企划”、“销售计划管理”、“售后服务管理”如图3所示。

其中销售合同管理又可以分解为“增加新合同”、“修改合同”、“打印综合报表”、“收款单处理”、“打印催款单”、“查询合同”、“存入历年库”、“检查合同履约”等用例，如图4所示。

进过以上的步骤，再进一步细化需求阶段得到的类图、分析对象状态的变化、定义对象之间的交互、分析与协作系统的集成。在需求段得到的类图中加入关联名称，多重性，泛化等。针对用例，在时序图和协作图中描述对象间的交互，用作对类图的方法的补充。

为节省篇幅，仅对销售合同管理子系统中的收款单处理用例进行描述，如图5所示。

2.3 设计段在本段中，可以使用分析段的结果来设计系统的解决方案。设计和分析都可以重复迭代直到设计完成。主要工作是开发和细化对象图、开发构件图、制定部署计划、设计和开发用户界面原型、测试设计、开始编制文档。

在销售管理子系统中，销售管理业务包括制定产品销售计划、推销本企业的产品（包括大客户资讯管理和产品推销策略计划的制定与实施），与客户签订销售合同、产品销售后及时追缴客户的应付货款、检查合同履约率、提供售后服务等。

对销售管理用例进行细化分析，得到细化的类图和对象图如图6所示。其中，实体类有销售人员、客户、经理、销售部门、财务管理部门、合同履约、生产调度管理部门、大客户、货款、产品、销售计划、履约合同、销售合同、付款单、催款单、库存管理部门。

通过进一步分析细化，将以上的实体类进一步合并为以下10个实体类：客户类、大客户类、销售人员类、公司经理类、产品类、销售计划类、销售合同类、履约合同类、付款单类、催款单类。

而且还需添加销售管理的边界类以及控制类，边界类主要包括：销售计划管理窗口类、客户（大客户）管理窗口类、销售合同管理窗口类、产品管理窗口类、履约合同管理窗口类、付款单管理类、催款单管理窗口类，控制类就是销售管理子系统的主管理窗口类。

2.4 开发段这个阶段，根据前期快速编写的测试版，结合以上各个时期的软件构建模型，通过修改测试版的代码，将设计结果付诸实施编制代码，测试代码，构建用户界面和用户界面到代码的连接测试，并进一步完成文档。

2.5 部署段当开发完成后，系统就要被部署到适当的硬件上运行并要与协同系统集成起来。主要工作是编制备份和恢复计划，在硬件上安装最终系统，测试安装后的系统等。不过，在第一段时该段就可以开始。

3结束语

通过“进销存管理系统”实例分析，可以看出，整合设计的过程框架分别吸收借鉴了GRAPPLE与XP的优秀方法与思想。通过对GRAPPLE和XP的整合分析与设计可以看出，GRAPPLE需要XP 为其提高敏捷性，提高其对变化的快速反应能力，以适应市场的不断变化和客户需求的不断变化；而XP可以利用GRAPPLE深刻的理论基础作为其发展的基石。总结出GRAPPLE与XP整合的过程模式是一个以用户为中心、架构为中心、用例驱动、测试驱动、风险驱动、即时沟通与反馈、易变更的有序软件开发过程。GRAPPLE和XP的结合能够适应变化，使得开发团队更有效率的工作。

参考文献：

[1]Joseph Schmuller，李虎著，赵龙刚译.基于UML以RUP为过程指导的业务建模[M].人民邮电出版社.

[2]王永贵，王璐.RUP与XP软件过程整合设计研究[J].计算机系统应用，2009，（8）：81-83.

[3]钟琪，何文孝.RUP与XP中的模式应用及比较[J].计算机时代，2009，（9）：4-5，8.

[4]李云超.XP结对编程探究[J].电脑知识与技术，2009，（5）24：7058-7059.