导入语
前几章的讨论已向我们充分展示了企业中的信息系统应用，能为企业提高生产经营效率、增强市场竞争力发挥重要作用。然而，在现代社会日趋激烈的竞争环境中，如何更好地利用信息资源，如何构建自己的信息系统，是购买现成的应用系统软件还是坚持自主开发？抑或委托专业公司有针对性地提出解决方案？系统的自主开发又有什么样的有效方法？这些正是企业在构建信息系统时不得不考虑的问题，也是本章的主要内容。
管理信息系统的开发方法是随着计算机技术和通信技术的发展而不断发展的。目前主要的开发方法有：结构化系统开发法、原型法、面向对象法以及计算机辅助软件工程法等。本章将主要介绍上述开发方法，并就系统开发过程中的管理问题做一个概括性的阐述。
学习本章，应掌握以下主要内容：
●了解构建信息系统的一般方法；
●系统开发的结构化方法；
●系统开发的原型法开发方法；
●面向对象系统开发主要特点；
●系统的组合开发方式。
8.1 构建信息系统的方法概述
管理信息系统的应用是一项耗资高、技术复杂、管理变革大和历时长的工程项目，如果不经过很好的规划就草率上马，可能会造成极大的损失，甚至带来管理混乱。企业或组织之所以要构建并使用一套新的信息系统，就是要以信息技术作为强有力的支持，以新的管理理念为指导，来改善现有管理方式的不足，提升企业管理水平，或者应对新的环境变化，以增强企业的竞争力。要达到这个目的，不仅要明确系统开发的原则，选择适合的系统构建策略，还要熟悉系统开发的整个流程，以及了解系统开发的各项前期准备工作。
8.1.1 系统构建的策略
就一个企业而言，构建一套管理信息系统，其最终结果是拥有一套业务处理或业务管理的计算机应用软件并成功投入使用。显然，系统开发的核心就是计算机软件的开发。所谓开发方式也就是围绕着如何快速开发软件。站在企业的角度，拥有软件的过程就是一个开发过程。这样看来，开发的方式一般可以有如下几种：自行独立开发、委托开发（外包）、合作开发、部分定制或购买成熟软件，企业应根据自身的实际情况选择合适的系统构建策略。
（一）购买成熟软件
如果有合适的软件，购买现成软件无疑是最快速、最直接的方式，也是成本费用最低的方式之一。买来后短期就可以投入使用。
软件开发是一件风险性较大的工作，需要各类专业人才和相对稳定的大量资金。专门从事管理信息系统开发的计算机软件公司已经开发出不少使用方便、功能强大的系统软件，包括国外和国内的大量软件都已得到许多企业的实际应用检验，效果明显。所以，为了尽快开展企业的核心业务，推动企业信息化建设，尽可能地购买专业的成熟软件。
目前较为成熟的MIS软件，不仅有全面解决方案，如ERp、CRM套件等，也有针对不同职能的专门软件，如财务管理系统、供销存系统、人力资源管理系统等。
但是，购买现成软件最大的缺点，就是软件的适应性较差，可能不一定完全适合本企业的业务处理要求。尤其是当今企业处于变革的时期，各企业为竞争需求，突出自身优势，时常会根据市场的变化快速应变，这时软件公司往往不能及时修改程序。企业要么很快淘汰旧软件重新购置（加大购置成本），要么只能用软件实现部分功能，达不到原有的效果。而且，后期的频繁修改软件，也会增加意想不到的维护成本。
（二）部分定制
因为通用的管理信息系统软件不一定完全适合本企业，或者总是或多或少存在一些不适用的部分。针对这一特点，也可以采取购买成熟软件，但对部分不适用的内容，请开发商专门开发定制。若定制部分所占比例不大，开发商也可能同意，当然费用需双方协商。这一方法可以部分解决完全购买的缺点。不利之处是定制部分的后期维护费用可能较高。
（三）委托开发（外包）
这种外包，主要指企业的整套信息系统软件完全委托外部的专业软件公司开发，也即完全的定制方式。这一方式的优点是委托方只须提出具体需求，定期检查系统开发过程的情况和后期验收就可以了。对企业而言开发过程简单。
适应企业：一方面是自身的业务处理专业化较强，市场上无法购买到通用的成熟软件，同时自身专业技术力量不足，无法承担自己开发的任务；当然，企业的资金力量应该比较雄厚，因为外包的投资一般较大。
除了上述的一些优点，完全委托也并非人人适合。比如投资较大的问题。许多企业采取委托方式，都希望最终获得软件的源代码，以便于今后自己对系统的维护，但对于被委托方而言，有些源代码本身就是一种企业的商业机密，若要移交费用不菲。而拿不到源代码，委托方的系统运作就必须有赖于开发方的长期支持，无论技术上还是双方合作上都存在一定风险。
此外，被委托方对企业的具体流程并不熟悉，开发过程中必须双方密切配合，尤其是系统分析阶段的需求定义过程，更需要最终用户的参与和反馈。
（四）合作开发
为避免上述几种方式的缺陷，可以采取企业与专业软件公司合作开发的方式。当然，前提是企业必须有一支相对完善的技术队伍，包括系统分析与设计人员、程序设计人员和系统维护人员，同时资金比较充足，时间充裕，而且企业也希望通过合作开发逐渐建立自己的技术开发队伍，便于将来的系统维护和升级。
（五）完全自行开发
对于有较强的管理信息系统分析与设计人员、程序设计人员、系统维护使用人员、资金充足、时间充裕的企业和组织，如大型集团公司等单位，可以考虑采用完全自行独立开发的方式。
该方式的主要优势在于企业可以最终拥有系统的源代码，方便对系统的升级和维护，并可以在此基础上开发其他类似系统。更为重要的是，新系统将更能贴近企业的实际需求，因为开发人员来源于自身企业，对组织的业务更了解。开发过程中，技术人员与业务人员的交流沟通更容易和方便，最终的产品更能满足需求。
主要不足也是明显的，因为不是专业开发队伍（尤其是首次开发），系统的开发经验不足，且容易受本身业务内容的限制，导致系统通用性优化不够。另外，开发人员往往从不同岗位临时抽调，容易造成系统开发周期过长，影响最终使用。
MIS完全独立开发通常需具备以下一些条件：
（1）领导重视，专业人员积极性高；
（2）有迫切建立管理信息系统的实际需求；
（3）必须有一定的科学管理基础；
（4）有必要的资金投入保证，包括系统维护人员的编制和费用；
（5）有一支技术力量较强的专业队伍；
（6）企业的基础业务数据齐全规范。
8.1.2 信息系统开发方法
这里所说的信息系统的开发，通常意义上都是指企业自主开发。而信息系统的开发，归根到底就是应用软件的开发，因而其开发方式，实际上也是借鉴了软件工程的概念。
从20世纪60年代开始，人们已经注意到管理信息系统的开发方法和工具。20世纪70年代，结构化系统开发方法诞生，它较好地给出了过程的定义，大大改善了开发的过程。该方法从整体出发，对软件开发和维护的复杂问题进行分解，把软件的开发划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务，前一个阶段任务完成后，才进行后一个阶段的工作。在每一个阶段结束之前需要从技术和管理两方面进行严格的技术审查和管理复审，审查的主要标准就是每个阶段都应该提交和欲开发系统完全一致的高质量的文档资料。如果文档不合格，需重新修改后再审查，直到符合规定的要求。
20世纪70年代末至80年代初，随着计算机硬件和软件技术，包括计算机网络和数据库技术不断更新，企业的管理模式、组织机构、人员的变动等带来了更多的需求变化。人们希望能够快速生成一个系统的“雏形”，然后在这个基础上进行修改完善，直至符合要求，于是系统开发的原型法产生了。原型法认为，需求的反复和多变是正常的、不可避免的，因此反复修改也是必要的，应该鼓励用户对需求提出更多、更高的要求，从而使未来的新系统提供的信息真正地满足管理和决策的需要。原型法的开发思想是：对需求简单快速分析后，利用先进的开发工具，尽快构造出一个原型系统提供给用户评价、试用，在试用中不断修改完原型系统，直到用户满意为止。如果原型系统离要求相差太远，需要重新构造。它的出发点是：用户只有看到一个具体的系统，才能清楚地了解到自己的需要及系统还存在的缺陷，这也说明了并非所有的需求都能预先确定。在最终评价系统之前，通过动态模型的演示将比书面的文档和图表的表达更为直观、更为生动，而且模型在演示的过程中可以修改和完善，运用模型方法构造原型，使用户和开发者协调一致，及早暴露出潜在问题以作修改。
面向对象法是在20世纪80年代末期各种面向对象的程序设计方法（如C++）的基础上逐步发展起来的。面向对象法在20世纪80年代初已用于计算机科学，20世纪80年代末开始用于管理信息系统。在面向对象法之前的程序设计是面向过程的，数据跟随过程，而面向对象法符合软件工程的快速原型开发要求，自顶向下，从抽象到具体，在最高层次上先设计系统的功能、接口界面，而推迟具体细节的实现。面向对象法的关键是将开发的程序分解为类，类有可继承性，使程序有可重用性。面向对象法有以下特点：把数据和操作绑扎在一起作为一个对象，数据是主动的，操作跟随数据，不像通常的程序，程序是主动的，数据是被动的；面向对象的方法很容易做到程序重用，使新系统开发和维护系统很相似，因为均是重复使用已有的部件；面向对象的方法用于企业管理时就像给出一个企业模型，模拟企业的运行，开发者和企业管理者之间只需用企业语言沟通，如会计、顾客、报告等；面向对象的方法也特别适用于图形、多媒体运用的复杂系统。
20世纪80年代末期，计算机辅助软件工程（Computer Aided Software Engineering，简称CASE）方法得到很大的发展，它是由各种计算机辅助软件和工具组成的大型综合性软件开发环境，用于开发过程中有关步骤的自动化，因此严格地讲，CASE只是一种开发环境而不是一种开发方法。目前，CASE仍是一个发展中的概念，各种CASE软件也较多，没有统一的模式和标准。采用CASE工具进行系统开发，必须结合一种具体的开发方法，如结构化系统开发方法、面向对象开发方法或原型化开发方法等。
传统的系统开发工具包括各种第三代、第四代工具，它们中的大多数主要集中在系统生命周期的实施阶段，传统的系统开发方法主要是手工方法，如结构化系统开发方法中的结构化分析、结构化设计和结构化程序编制。CASE技术是系统开发工具与方法的结合，它不同于以往的开发技术，因为它强调的是解决整个系统开发过程的效率问题，而不仅仅是实施阶段。由于跨越了系统生命周期的各个阶段，因此，CASE的目标是为具体的开发方法提供支持每一个过程的专门工具，为系统开发人员提供一组优化的、集成的且能大量节省人力的系统开发工具，它着眼于系统分析和设计以及程序实现和维护等各个环节的自动化，并使之成为一个整体。因而，CASE工具实际上把原先由手工完成的开发过程，尤其是系统实施阶段前的系统开发，转变为以自动化工具和支撑环境支持的自动化开发过程。现在，CASE中集成了多种工具，这些工具既可以单独使用，也可以组合使用，CASE的概念也由一种具体的工具发展成为开发信息系统的方法学。
【相关链接】
江淮汽车与安徽合力殊途同归 成功信息化（资料来源：《首席信息官》CIO。ICXO.COM。）
在风景秀丽的安徽省合肥市，相隔不到三公里有两家上市公司——安徽合力叉车集团（安徽合力600761）和安徽江淮汽车集团（江淮汽车600418）。经过15年的信息化建设，江淮汽车和安徽合力都成绩斐然。目前安徽合力叉车已占据国内市场的三分之一，还出口到世界40多个国家和地区，特别是大批出口到欧美市场，位列全国同行业冠军。江淮汽车连续14年年均增长速度为50%以上，全年主要经济指标的增幅位居国内汽车行业前列。然而，回顾其信息化建设历程，两家企业却走出了截然不同的道路，尤其是在某些关键问题和环节的理解和实践上甚至会背道而驰。
通过采访这两家企业信息化建设的“领军人”——安徽合力公司董事、计划信息处处长张孟青和江淮汽车信息中心副主任屈新龙，了解到两家企业在信息化建设道路上各有千秋的创新之举，也深刻体会到信息化成功的不二法门——自主创新，适者生存。
选型：引进还是开发？
江淮汽车和安徽合力信息化建设初期具有太多的相似点：老国企、制造业、各自领域的行业老大，2000年时年满40岁并面临WTO的压力，建设过CAD、MRp，都走到了以ERp为核心的制造业信息化的第三阶段。就连两家企业的CIO也是那样相似，年龄相仿，20年左右的厂龄，10多年信息化历练，在企业中举足轻重，在安徽省汽车制造行业中大名鼎鼎。然而，两位CIO在信息系统选型上却采取了截然不同的做法——江淮汽车选择了引进成熟产品，而安徽合力则选择自行开发。
江淮汽车始建于1964年，产品包括轻型卡车、新型客车底盘和2002年新推出的瑞风商务车，其生产的最大特点是“多品种、小批量”。从建设MRpII选择北京利玛软件公司的产品，到建设ERp系统选择用友软件公司的NC-BAAN系统，到今年携手明基逐鹿，在商用车制造领域应用其采购供应链解决方案。江淮汽车每一次都选择了引进成熟软件。
对此，江淮汽车信息中心副主任屈新龙认为：“引进成熟软件的最大好处，就是在信息系统实施的同时引入国内外先进的管理思想和管理技术，从而极大地提高了江淮汽车的整体管理水平。”
安徽合力始建于1958年，是原机械部定点生产叉车的大型重点骨干企业。1992年，安徽合力与高校合作设计了企业信息化的总体规划，并以此为蓝图在1997年开发MRpII，1999年自主开发出一套ERp软件系统——协同管理软件，2000年开发集团级的协同信息系统，通过网络技术覆盖全国乃至世界各地的分支机构，2005年进入信息系统的规模化和精细化实施阶段。
安徽合力计划信息处处长张孟青谈到这一点时说：“事实证明，选择自主开发是艰难而又重要的一步。虽然从成本的角度看，自己开发ERp软件并不比外购软件成本小，但是收益颇丰。首先，量身定做的信息系统非常合身，能够忠于安徽合力的需求，随时为我所用，紧密配合。其次，培养了自己的队伍，他们有着非常丰富的开发和实施经验，对企业信息化的理解和经验甚至超过了很多专业的软件供应商，除了服务集团内部用户以外，也能够独立发展。”
结合：系统主导还是业务主导？
在ERp实施过程中，信息系统与流程的整合是最关键的一部分，目前主要有两种建设模式：一是实现企业业务流程再造，以适应信息系统的规范化要求为主；二是按照企业目前的流程，调整信息系统以适应业务为主。这两种模式并不绝对区分，但在不同企业的应用中，因其侧重点不同而有明显的倾向性。江淮汽车与安徽合力的倾向就明显不同——江淮汽车选择了系统主导，而安徽合力则坚持业务主导。
江淮汽车在1997年上MRpII的时候，集团提出的“双向位移”的实施策略，寻找系统与业务的结合点。2002年实施ERp时，江淮汽车果断转向“单向位移”，就是要最大限度地采用ERp系统提供的先进管理思想和业务流程，尽可能实现与国际先进的管理方式接轨，不迁就落后的管理方式。根据这一指导思想，在ERp项目实施中，项目组始终坚持高标准，引入先进的管理思想和业务流程，涉及的业务变革的面更广了。
屈新龙解释说：“上系统的目的是提升管理水平，如果管理与系统不匹配，惟一的选择是改进管理，其中包括业务流程重组、工作岗位调整。业务流程的变革是痛苦的、也是有效的。如果没有公司组织结构、业务流程的巨大调整，江淮汽车管理水平就无法向上移动与MRpII、ERp成功对接，很可能会演变成穿新鞋走老路的局面。”
安徽合力选择的则是系统围绕业务流程调整，然后在发挥系统功效的同时潜移默化地变革业务流程。安徽合力的信息化建设中大的步骤就有三次，如果每次都因业务流程调整搞得伤筋动骨，可能会因为遇到太多阻力而影响进度，处理不好可能还会给企业带来负效应。所以在管理系统实施初期，安徽合力尽量不对业务流程和业务部门进行大的重组和调整，而是通过调整系统或培训的方式，使二者彼此适应。经过一段时间后，一些业务和岗位自然消失，这时调整就变得顺理成章、水到渠成。
张孟青说：“信息化并不是减人的工作、也不是减人的工具，在系统实施过程中，肯定会有一些岗位会消失，同时也会有一些新岗位出现。这个道理在系统初期大家很难理解，我们也不想激化矛盾，随着信息化的持续进行，业务流程调整也就越来越容易，越来越能体现管理系统的精髓。就这样在潜移默化中，我们完成了管理系统和业务流程的交替升级和螺旋上升，我们称之为‘蜕皮工程’。”据介绍，预计到2008年安徽合力集团业务才能全部搬迁到新系统上，实现“管理思想”“流程”及“运营模式”的全面提升。
出路：独立公司还是辅助部门？
随着企业信息化的深入发展，企业信息管理部门的职责和地位也在悄然发生着变化。江淮汽车信息中心依然是支持主业的重要辅助部门，而安徽合力的信息中心已经一步跨到主业之外，成为了一家独立软件供应商。
信息中心已经成为江淮汽车集团最紧密的一个组成部分，所以支持集团主业发展依然是信息中心最重要的职责。这一方面是由于江淮汽车的生产特点是“多品种、小批量”，这在汽车行业比较少见，所以其信息化系统也是非常个性化的，目前并不具有推广的环境。另一方面，在竞争激烈的市场环境中，江淮汽车面临着快速扩张的巨大压力，一直处于不断的企业并购和业务调整中。2005年底，江淮的制造部门扩张为4个，销售部门扩张为2个，一个公司裂变出6大部门，与此同时，上游600多家供应商和下游1300多家经销商都希望尽早进入信息系统，这些都需要企业信息部门全力快速地调整和扩展信息系统，从而跟上企业的发展。屈新龙认为：“我们感觉到，处于变革中的企业，上信息系统不容易，要保证信息系统与企业业务稳定有效地运行更不容易，更需要信息部门全心全意地投入与支持。”
安徽合力信息技术部门在2001年10月独立成为安徽叉车集团的控股子公司——合肥和谐软件有限公司，从用户转变成了独立软件供应商，张孟青也多了一个身份——和谐软件公司总经理。安徽合力的信息化可谓一举两得，不仅推动了合力信息化进程，而且还产生了一个副产品——和谐软件。兼具用户和供应商两种身份，这个形式在工业领域也有先例，例如现在最好的CAD软件就是从通用汽车厂出来的，每年在中国的销售额达数亿元。“我们也想走类似道路，”张孟青说，“所谓久病成医，从工厂出来的软件公司的优势是经验丰富，我们希望能把自己做信息化的酸甜苦辣和宝贵经验为同行提供更贴切更符合需求的服务，这也是其他专业软件公司做不到的。”目前，“和谐制造业管理软件”是安徽省重点科研计划项目，除主要在合力集团内部使用外，用户群逐步拓展到安徽省内、深圳和上海等地。
8.2 结构化系统开发方法
信息系统是20世纪60年代中后期才开始兴起的新领域，但近四十年来，发展十分迅速，人们对这类系统的建设缺乏历史经验，发展初期在建设方面呈现较为混乱的状态。系统生命周期概念在信息系统建设中的应用，使这类复杂系统的建设开始“有章可循”，因而早期出现的生命周期法为信息系统建设方法的科学化打下了一个良好的基础。但是，这些方法在实际应用中仍然出现不少问题，这些问题影响系统建设的质量与进程，有时甚至带来严重的后果，而系统生命周期的结构化方法（structured Approach）的出现，为解决这些问题提供了新的途径。下面分析早期的开发方法存在的主要问题，并讨论结构化系统开发方法的基本思想和主要原则。
8.2.1 早期的信息系统开发方法存在的主要问题
（一）工作阶段的划分原则不明确
各阶段的工作缺乏规范的规程、方法、表达工具与标准。信息系统建设的生命周期法主要借鉴复杂的工程技术系统的建设方法。但各类工程技术系统的建设除了遵循系统方法的基本原则、应用生命周期概念外，还有每类系统所涉及的专业的比较完整的工作规范、技术标准、基本方法与技能以及表达工具等等。但信息系统缺乏这些规范、标准、方法、技能及表达工具，并且工作阶段的划分和各阶段的工作内容的确定方面，不同类型的问题要求有所区别，信息系统的建设也不能完全照搬工程技术系统建设的经验。可是由于缺乏经验，早期经典方法中工作阶段的划分和每个工作阶段内容的确定缺乏明确的原则。这都给系统建设增加不确定性，建设进程和工作质量难以进行有效的控制。
（二）系统建设过程用户参与程度低
用户与专业人员的对话缺乏有效的手段。用户在管理活动中的信息需求是信息系统各阶段工作的重要依据。由于专业背景不同，信息系统专业人员对用户需求的理解和用户对计算机化的信息系统功能的理解只能随着建设工作的进展逐步加深。但早期的方法中，用户在建设过程中参与程度低，系统建设工作主要由信息系统专业人员承担，专业人员所习惯的工作结果的描述方式用户难以理解，双方缺乏有效的对话手段，用户的许多需求难以表达并在建设过程中反映出来。由于用户需求得不到比较全面、准确的反映，用户对系统建设中的问题、困难和制约条件也缺乏理解，使得系统建成后，遗留问题多，用户满意度低。
（三）系统开发的工作任务集中在系统实施阶段
系统分析、设计工作不深入。由于用户和专业人员都急于看到系统建设的具体成果，系统开发工作的注意力集中在系统实施阶段。系统分析和系统设计阶段的工作虽然也做了安排，但只着眼于形成系统建设所需的各种文件。本来文件应是工作成果的描述，由于缺乏科学的、严密的工作规范和用户的参与，加上急于物理实现的习惯势力的影响，系统分析和系统设计往往工作粗糙，随意性大，所形成的有关文件不能全面反映系统分析与系统设计阶段应该进行的工作，也难以和用户进行充分的交流，给系统实施和系统运行与维护阶段留下后遗症。经验表明，系统运行时发现的错误约三分之二产生于系统分析与设计阶段，其余约三分之一出自系统实施阶段。
（四）系统实施阶段的工作采取“自底向上”的方法
由于系统实施阶段的工作采取“自底向上”的方法，系统总体功能与目标的实现难以保证。在系统实施阶段，经典方法采用一些工程技术系统的方法，如先制造零件、再装配部件、最后总装的“自底向上”的实施方法，先实现系统最底层的功能模块，然后将若干底层模块联结起来实现上层模块的功能，最后实现整个开发项目的预定功能。这种“自底向上”的实施方法固然有效，但信息系统具有多个目标、多种功能，总系统与子系统以及子系统之间联系复杂，它们之间有的目标不一致，有的相互冲突，如果开始只注意到各部分的目标与功能，分别实现各底层模块，则因各部分目标不一致和相互冲突，导致上层模块以至整个系统的目标与功能难以实现。由于以上问题，常常造成所建系统用户不满意、不能完全实现预定的目标与功能、使用效果差、可行性低、维护工作量大、维护费用高等后果。
8.2.2 结构化系统开发方法
“结构化”一词在系统建设中的含意是用一组规范的步骤、准则和工具来进行某项工作。基于系统生命周期概念的结构化方法则为信息系统建设提供了规范的步骤、准则与工具，以弥补早期经典方法的不足。
（一）产生过程
结构化方法产生于20世纪70年代中期。“结构化”一词出自程序设计，即我们熟知的结构化程序设计。在结构化程序设计出现之前，同样一件事情，不同的程序员编写的程序所占用的内存空间、运行时间可能差异很大。更严重的是，这些程序的可读性和可修改性很差，一个程序员写的程序，别人可能看不懂，修改更是困难，往往修改不如重写。
1964年，波姆（Bohn）和雅科比尼（G.Jacopini）提出结构化程序设计的理论，认为任何一个程序都可以用三种基本逻辑结构来编制。戴克斯特拉（E.Dijkstra）等人主张程序中避免使用GO TO语句，而仅用上述三种结构反复嵌套来构造程序。在这一思想指导下，一个程序的详细执行过程可按“自顶向下，逐步求精”的方法确定，即把一个程序分成若干个功能模块，这些模块之间尽可能彼此独立，用作业控制语句或过程调用语句把这些模块联系起来，形成一个完整的程序。这种方法大大提高了程序员的工作效率，改进了程序质量，增强了程序的可读性和可修改性，修改程序的某一部分时，对其他部分的影响也不太大。可以说，这种方法使程序设计由一种“艺术”成为一种“技术”。
人们从结构化程序设计中受到启发，把模块化思想引入到系统设计中来，将一个系统设计成层次化的程序模块结构。这些模块相对独立、功能单一，这就是结构化系统设计的基本思想。
但是，结构化系统设计不能帮助系统设计人员建立一个直观的系统模型，使用户在实际得到并使用这个系统之前，就能够知道这个系统是不是所需要的计算机信息系统。用户关心的是这个系统的逻辑功能是否满足其需求，是否能解决要解决的问题。至于这个系统如何实现这些功能，并不是最关心的问题。为了使所设计的系统满足用户的要求，在设计之前，先要正确理解和准确表达用户的要求，解决的是系统“做什么”的问题，这就是系统分析阶段的基本任务。结构化系统分析，强调系统分析员与用户一起按照系统的观点对企业活动由表及里地进行分析，调查分析系统的逻辑功能，并用数据流程图等工具把系统功能描述清楚。用户可以判断未来的系统是否满足其功能要求，而系统设计人员根据这种描述进行系统设计，解决系统“怎么做”的问题，保证系统功能的实现。这就是结构化系统开发方法的由来。
（二）基本思路
结构化系统开发方法的基本思路是把整个系统开发过程分成若干阶段，每个阶段进行若干活动，每项活动应用一系列标准、规范、方法和技术，完成一个或多个任务，形成符合给定规范的产品（成果）。
（三）系统开发的生命周期
用结构化系统开发方法开发一个系统，将整个开发过程划分为五个首尾相连的阶段，称为系统开发的生命周期。各阶段的主要工作有：
1.系统规划阶段
战略规划、业务流程规划、信息系统总体结构规划、项目实施与资源分配规划；
2.系统分析阶段
系统初步调查、开发项目的可行性研究、系统详细调查、开发项目范围内新系统逻辑模型的提出；
3.系统设计阶段
系统总体结构设计、输入设计、输出设计、处理过程设计、数据存储设计、计算机系统方案选择；
4.系统实施阶段
软件编程和软件包购置、计算机和通信设备的购置，系统的安装、调试与测试，新旧系统的转换；
5.系统运行与维护阶段
系统运行的组织与管理，系统评价，系统纠错性维护、适应性维护、完善性维护、预防性维护。
系统开发的整个生命周期也可以用一种瀑布模型来描述。
（四）结构化系统开发方法的主要原则
1.用户参与的原则
前面已经指出，信息系统的用户是各级各类管理与业务人员。满足他们在管理活动中的信息需求，是信息系统建设的直接目的。由于系统本身和系统建设工作的复杂性，用户的需求不容易一次表达清楚。随着建设进程的推移和工作的深入，用户需求的表达和系统建设的专业人员对用户需求的理解才能逐步明确、深化和细化。并且，信息系统是人机系统，在实现各种功能时，人与计算机的合理分工和相互密切配合至关重要，这就需要用户对系统的功能、结构和运行规律有较深入的了解，专业人员也必须充分考虑用户的特点和使用方面的习惯与要求，以协调人机关系。信息系统的建设不同于一般工程项目的开发，不能简单地采用“交钥匙”的办法进行承包。用户必须作为信息系统主要建设者的一部分在系统建设的各个阶段直接参与工作。用户与建设工作脱节，常常是系统建设工作失败的重要原因之一。
信息系统的建设关系到一个组织的信息处理能力和管理决策的水平，是涉及该组织的全局，与近期和长远发展密切相关的战略问题。信息系统建设就是要用先进的管理模式、管理方法与手段代替落后的管理模式、管理方法与手段，这关系到组织改革与发展的大局，只有此组织的主要领导者亲自主持和直接参与，系统建设的目标才可望实现。在系统建设中，用户的高层领导要主持协调信息系统和其他部门之间的关系，调配所需资源，审核系统建设的阶段成果。国内外经验表明，各级管理人员，特别是主要决策者的参与和重视，是信息系统建设成功的重要条件。
2.严格划分工作阶段，“先逻辑，后物理”的原则
为了建立系统建设的科学秩序，保证建设工作的质量与效率，结构化方法严格按照系统生命周期划分工作阶段，每个工作阶段的活动内容、工作任务、所用方法、工具、准则都有明确的规定，每个阶段的工作成果（产品）也有具体要求。每个阶段有相对独立的任务，然后逐步完成每个阶段的任务，前一个阶段任务完成后，才进行后一个阶段的工作。在每一个阶段结束之前需要从技术和管理两方面进行严格的技术审查和管理复审，审查的主要标准就是每个阶段都应该提交和欲开发系统完全一致的高质量的文档资料。结构化方法总结了以往的信息系统建设成功和失败的经验，强调在进行技术设计和实施（即涉及计算机技术和资源的具体分配）之前，要进行充分的调查、分析、论证，进行逻辑方案的探索，弄清系统要为用户解决哪些问题，即解决系统“做什么”的问题。考虑到人们思维的习惯性，要尽量避免过早地进入物理设计阶段，也就是说，在进行系统开发时，要充分地进行系统分析，解决“做什么”问题，然后再进入系统设计阶段，解决“怎样做”问题。
3.“自顶向下”的原则
在系统分析、系统设计与系统实施各阶段，结构化方法强调在工作中贯彻执行“自顶向下”的原则，先把握系统的总体目标和功能，然后逐级分解，逐步细化。系统测试也从总体功能开始，先检查有关总体的问题，然后逐级向下测试。这一原则使建设者在系统建设整个过程中始终把握全局，致力于总体目标与功能的实现，把以下各级作为实现总体目标和总体功能的保证，这有利于各部分的合理分工、协调与正确配置。这样建立的系统，结构合理，总体与各部分容易协调一致，总体目标和总体功能的实现有保证。“自顶向下”的原则在应用时并不完全排斥“自底向上”的原则。如系统规划阶段在进行“自顶向下”的组织信息需求分析后，将整个拟建系统分成若干开发项目，分期分批进行系统开发，先实现某些子系统，再逐步实现总的目标和功能，这就是“自底向上”逐步实现的系统建设方法。但在具体开发某个子系统时，仍需应用“自顶向下”的原则。在结构化方法中，“自顶向下”原则是主导原则，“自底向上”是辅助原则；即在系统分析与设计时要从整体全局考虑，要自顶向下地工作，而在系统实现时，则要根据设计的要求先编制一个个具体的功能模块，然后自底向上逐步实现整个系统。
4.工作成果描述标准化原则
结构化方法强调各阶段工作成果描述的标准化。每一工作阶段的成果，必须用明确的文字和标准化的图形、图表，完整、准确地进行描述，这不仅作为一个阶段工作完成的标志和管理决策的依据，并且作为系统建设必需的文件进行交流和积累存档，有的文件还是下一阶段工作的主要依据。工作成果描述的标准化，可以防止由于描述的随意性造成建设者之间的误解而贻误工作，便于工作交流和各阶段的交接，便于今后对系统进行检查、修改与扩充。结构化方法重视用标准化图形来表达工作成果。图形表达工具使工作成果一目了然、直观、明确、清晰，避免了许多烦琐的文字，可读性、可修改性好，不容易产生歧义与误解。在描述工作成果时，结构化方法强调与用户对话的重要性，要求描述工具尽可能简易、明了，用户容易掌握，以便有效地和用户进行交流。
在早期经典方法的基础上，应用结构化方法，使信息系统的建设逐渐形成一套比较严格的标准、规范、方法与技术，系统建设的组织管理与实施有章可循，成功率和有效率提高了。一些大型的信息系统成功的开发与应用，也不断充实着这一方法。结构化系统开发方法长期以来一直是信息系统，特别是大型系统的主流方法。现在，信息系统建设方法有了很大发展，新的方法与技术不断涌现，但结构化系统开发方法中的一些重要原则和规范仍然为许多新的方法所继承与发展，继续指导着系统建设的实践活动。
本书的后续章节将详细讨论结构化系统开发方法的原理及过程。
8.3 原型法
8.3.1 结构化系统开发方法存在的问题
结构化系统开发方法的应用，严格的秩序和一套可以实施的标准、规范、方法和技术，使信息系统的建设走上了科学化、规范化的道路。20世纪80年代以来，社会经济和科学技术发展迅速，各类社会组织，特别是企业面临的环境复杂多变、竞争日趋激烈。国际社会的信息化浪潮一浪高过一浪，信息系统建设需求紧迫，已有的信息系统建设方法不能满足日益增长的系统建设的需要。结构化系统开发方法遇到了一系列挑战。
（一）整个系统的开发工作是劳动密集型的
虽然曾经有一些基于结构化系统开发方法的计算机辅助开发工具，但往往只能在系统开发的个别环节上提供有限的支持，各阶段的工作从系统分析、系统设计到系统实施，绝大部分仍然靠人工做出。近五十年来，计算机硬件的运行效率提高了近200倍，而其价格则呈不断下降的趋势，但系统开发的劳动成本（含软件开发）在整个开发成本中的比例却在不断上升。据统计，70年代末期软件成本已超过硬件成本，软件生产率低下已经成为当前信息化的主要障碍之一，这与整个系统开发工作的劳动密集型特点是有关的。
（二）系统开发的整个工作费时过长，难以适应环境的急剧变化
应用结构化系统开发方法，按阶段进行系统的开发，对于一个系统来说，少则一年，多则数年。现代企业面临的环境复杂多变、竞争激烈，不少情况下所建设的系统的功能无法跟踪环境的急剧变化，等到系统建成后，系统建设所依据的原有环境已事过境迁了。
（三）对用户需求的变更不能做出迅速的响应
用户的需求往往在系统开发过程中随着对系统开发工作的进展而逐步明确，甚至系统开发过程本身也在改变用户对信息的需求。因为随着新系统的开发与应用改变了用户的工作环境与条件，信息需求也要发生相应的变化。而以生命周期概念为基础的方法，其各阶段分工明确、费时较长，后一阶段的工作严格地依赖于前一阶段的结果进行，对用户需求的变化难以做出迅速的响应，缺乏灵活性。
（四）难以适应非结构化因素的要求
结构化系统开发方法各阶段的工作是基于这样一种假设：前一阶段的工作为后一阶段的工作任务规定内容与范围，自顶向下的功能分解则是按系统的总体功能或上层模块的功能通过分解、细化来确定子系统或下层模块的功能，前一步工作的正确性与完善性对后一步工作起着决定性作用。这就要求系统开发人员进行工作时，对下一步是否可以实现上一步所规定的内容有很强的预见性，并且这种预见性只有在对系统的有关功能要求十分明确的情况下才有可能。但是，如果系统所处理的问题比较复杂，不确定性因素较多，系统的逻辑方案、物理方案和实施工作需要反复探索，或者说整个系统建设中的非结构化因素较多，那么这种结构化方法就很难适应，因此它适用于组织相对稳定、业务处理过程规范、需求明确的大型信息系统开发。
（五）软件重用程度很低
实际上除了一些接口十分简单的标准数学函数经常重用之外，对一些其他系统的软件开发仍要做大量重复而又繁琐的工作，思维成果的可重用性差。
（六）维护工作繁重，专门人才紧缺
许多建有信息系统的有经验的组织发现，随着系统的发展，系统维护任务日趋繁重，现有信息系统的专门人才50％～75％忙于系统的维护工作，如果这种趋势继续发展，将严重影响新系统的建设。统计数字表明，用结构化方法开发出的软件维护的费用是软件开发费用的几倍。据报道，20世纪80年代美国一年花费的软件维护费用高达300多亿美元。由于计算机硬件价格不断下降和计算机网络与数据通信手段的迅速普及，需要开发信息系统的新用户不断增多，如果都要为他们提供系统开发的专职人员，则现已十分短缺的专门人才将更加供不应求，人才短缺现象已成为信息化进程的一大障碍。
由此可见，由于计算机应用的日益普及和信息系统建设任务急剧增长，传统的开发方法已经无法适应未来发展的需要。
8.3.2 原型法的基本思路
由于结构化开发方法从一开始就锁定系统的实际需求，在开发过程中一般不能修改，缺乏灵活性，人们就开始设想能否有一种可以迅速发现系统的需求错误，或在开发过程中能反复修正需求的方法来降低开发风险。20世纪80年代，随着图形用户界面（Graphical User Interface，GUI）等技术的出现而发展起来的原型法（prototyping Approach），逐渐成为一种流行的系统开发方法。
原型法也称渐进法或迭代法，是在短的时间内先获取一组用户的基本需求，用开发工具迅速构造出一个功能尚不十分完善的、实验性的、简易的管理信息系统模型（也称原型—prototype）。运用这个原型，用户与开发人员结合实际系统，不断地评价和改进，不断扩充和完善系统的结构和功能，提交用户运行。如此反复，直至得到符合用户要求的系统为止。
原型法加速了系统开发中用户需求的获取过程，它并不注重对管理信息系统全面、系统的调查和分析，而是根据对用户信息需求的大致了解，借助强有力的软件环境支持，迅速构造一个新系统的原型。它的提出是为了改进结构化系统开发方法的开发复杂、周期长、修改相对困难等缺点，有助于解决一些规模不大但不确定因素较多的管理决策问题，提高了系统开发效率与有效性。
通常，系统的原型并不是一次建成的，而是由一个初始原型开始，通过逐步细化达到满意为止，原型法与结构化系统开发法相结合，可以解决那些不确定的用户需求，因而加快了系统开发生命周期的进度。
原型法对于那些用户需求较难定义的系统非常有效，而且它也特别适合于那些规模较小的应用系统。通常情况下，原型法有助于开拓系统开发人员的想像力和他们与用户之间的交流。
在大多数情况下，用户所要求的并不是他们想要得到的，而他们想要得到的又往往不一定是他实际上需要的，这是由于他们的专业知识范围的局限性所导致的。原型法就可以较好地解决这一类问题，因为如果用户不满意一个原型，就可以重新建立另一个原型，如此继续，直到双方都达到满意为止。由此可见，采用这种方法，原型法实际上相当于通过不断的学习和发现来建立系统。
原型法是在信息系统开发过程中的一种简单的模拟方法，与最早人们不经分析直接编程的经典方法以及结构化系统开发方法相比，它是人类认识信息系统开发规律道路上的“否定之否定”。它站在前者的基础之上，借助于新一代的软件工具，螺旋式地上升到一个新的更高的起点。它“扬弃”了结构化系统开发方法的某些繁琐细节，继承了其合理的内核，是对结构化开发方法的发展和补充。
8.3.3 建立原型系统的步骤
建立一个信息系统的原型可分四步进行。
（一）明确用户基本信息需求
终端用户与系统开发人员紧密合作，集中力量弄清用户最基本、最主要的需求，如报表格式、屏幕“菜单”设计、主要问题处理程序等，估计建立原型系统的规模和成本。原型系统应尽可能简单，一般无需说明书，但系统规模较大时，应准备一个初步需求文件。
（二）建立初始的原型系统
系统开发人员根据和用户讨论的结果，应用第四代语言工具，尽快建立一个可以运行的、简单的功能模型作为初始原型，这个原型系统只响应用户最基本的需求，并交用户使用。
（三）使用及评价原型系统，进一步明确用户需求
用户在系统开发人员协助下，使用原型系统，取得经验和加深对系统的理解，评价系统的优点和不足，进一步确定对系统的需求，并提出对原型系统的变更与提高的具体意见。
（四）修改和完善原型系统
按照第二步的原则，根据用户的意见修改和完善原型系统，这一步要强调的是尽快完成并交付用户，然后又回到第三步，在建立原型系统时，第三步和第四步是反复进行的，直到用户和系统其他建设人员均满意为止。
8.3.4 原型法的特点
作为一种系统开发方法，原型法从原理到流程都十分简单，所以无论从方法论还是从实际应用的角度看，原型法都备受推崇，在实际应用中也取得了不俗的成绩。其主要特点可归纳如下：
1.原型法的循环往复、螺旋上升的开发模式，相对应结构化方法，更符合人们认识事物的规律，易于被接受和掌握。
2.原型法强调用户的参与。用户的全程参与，使得每次的原型的生成与修改都得到用户的认可，提高了开发成功率，降低了开发风险。用户对系统功能满意的同时也加深对软件结构的理解，从而使最后的评审和验收能顺利完成，也有利于用户日后的运行与使用管理工作。
3.原型法强调开发工具的使用。开发过程采用一系列与原型法适应的模型生成、修改以及目标建立和运行等系统开发环境，使得整个系统的开发过程与传统的工作模式相比，无论在时间上、效率上还是质量上都有大幅提升，系统对内外界的适应能力也得以增强。
4.原型法实际上是将传统的系统调查、系统分析和系统设计合而为一，使用户从一开始就能看到系统开发后的模样。在大多数情况下，原型法可以帮助定义那些在系统分析阶段较难确定的系统需求，而用户与系统开发人员密切的合作关系可以使用户的想法与实际要求更为接近，用户的直接参与使系统的实用性得到了提高。
8.3.5 原型法的优缺点
（一）原型法的优点
由上述特点可知，原型法的主要优点在于：
（1）对系统需求的认识取得突破，能确保用户的需求得到较好的满足。
（2）改进了用户和系统开发人员的交流方式。开发的系统更加贴近实际，提高了用户的满意度。
（3）降低了系统的开发风险，一定程度上减少了开发费用。
（二）原型法的缺点
原型法的不足表现在以下几方面：
（1）采用原型法开发系统是有限制条件的，有些情况就不适用于原型法。
例如，对于比较大而复杂的系统，很难用屏幕或人机界面来简单模拟，而必须经过严密的分析进行分解，就不适用采用原型法了。换句话说，原型法一般适用于小系统的开发。对一些运算复杂、逻辑性强的系统，因其很难构造出供用户评价的原型，也不适合采用原型法。如一些商品实时竞价管理系统、高校的排课系统等。对于那些缺乏管理基础的企业，同样不适合原型法。因为，管理基础薄弱，没有科学合理的方法，系统的开发就容易陷入机械地模拟手工操作方式的陷阱。
（2）文档欠缺，维护困难。与结构化开发方式相比，因为更强调以“原型迭代”的演进方式代替完整的分析与设计，以及为了加快开发进度而取消了软件文档或降低了对软件文档的要求，或者忽略建立完整的开发文档和详细的测试工作。短期而言，尚能满足用户要求，但长期来看，不利于系统运行的维护工作。
（3）开发过程不统一、不标准。由于缺乏对系统运行操作环境的全面考虑，会出现在是运行时系统工作良好，投入实际应用后，在处理大量事物和实际数据甚至海量数据的过程中，系统就不能满足需要或反应时间较慢，影响系统的效率。
（4）原型法对系统开发环境的要求较高。这主要指开发人员和用户的素质、系统开发工具、软/硬件平台等，都会对原型法的开发效果产生重要影响。
此外，对怎样才算是满足用户的需求，即确定用户的满意度，进而控制原型的修复次数，也没有一个明确的标准。
8.4 面向对象的方法
面向对象的系统开发方法（Bbject Oriented，OO）是近年来受到关注的一种系统开发方法。这种方法的基本思想是指把客观世界抽象地看作是由若干相互联系的对象，而后根据对象和方法的特性研制出一套软件工具，使之能够映射为计算机软件系统结构模型和进程，从而实现信息系统的开发。
面向对象开发方法也是从20世纪80年代开始盛行的各种面向对象的程序设计方法（如Smalltalk，C++等）逐步发展而来的。它不像传统的结构化开发方法，需要先把复杂的系统按功能划分为简单子系统。功能分解的方法虽然是一种有效的系统设计方法，但也存在严重的缺陷——过分强调实体的行为特征，而忽视了实体的结构特征，甚至破坏了自然存在的实体结构。其结果对系统的使用、维护和理解都会带来一定困难。
面向对象的系统开发方法是根据实体来阻止信息系统的逻辑结构。信息系统被划分为不同的组成部分，每个组成部分都负责处理一类实体，于是实体的结构特征和行为特征被集中起来。系统设计时产生的模块是类，类模块与功能子系统相比具有更大的独立性和相对性。类模块特征为系统的实现和维护带来一系列好处：系统结构清晰、模块的可重用性好等。同时，面向对象信息管理系统的实现又能有效地组织和管理软件的复杂度，提高软件生产效率和可靠性、可维护性，大大方便了系统编程者和系统维护者，使整个工程便于管理和控制。
8.4.1 基本思想
面向对象方法的基本思想是从现实世界的客观事物（对象）出发来构造信息系统，并在构造中尽可能运用人类的自然思维方式。客观世界是由各种各样的对象所组成的，对象是一个独立存在的实体，从外部可以了解它的功能，但其内部的细节是相对“隐蔽”的，它不受外界干扰。每种对象都有各自的内部状态和运动规律，不同的对象之间相互作用和联系构成了各种不同的系统。开发一套信息系统的目的是为了解决某些问题，而这些问题所涉及的业务范围可以称作该系统的问题域，面向对象方法即强调以问题域（现实世界）中的事物为中心来考虑问题，并根据这些事物的本质特征，把它们抽象地表示为系统中的对象，对这些对象及其相互间的关系进行识别，建立问题域的信息模型，并在此基础上进行系统设计，用对应对象和关系的软件模块构造系统。简单地说，就是使系统的开发过程能像硬件组装那样，由不同的“软件集成块”来构筑。当设计和实现一个信息系统时，如果能在满足一定需求的条件下，把系统设计成由一些不可变动（相对固定的）部分组成的最小集合，这个设计就是最好的。它把握了事物的本质，因而也不会被周围环境（物理环境和管理环境）的变化以及用户没完没了的需求变化所左右。其中那些不可变的部分就是所谓的对象。
在面向对象方法中，既没有过程和程序，也没有数据实体和文件，系统只是由对象所组成的。对象是一个在计算机系统中能对消息做出响应的事物。这种完全不同地看待计算机系统的方法要求使用一种不同的方法来实现系统分析、系统设计和编程。
总体而言，面向对象方法使得系统的结构更加清晰、简单，提高了系统中程序代码的重用性，实现了模块化的开发方式，提高了软件的开发效率，也降低了软件的维护量。
8.4.2 O-O方法中的几个基本概念
（一）对象（Object）
客观世界中的一个实体可称为一个对象。对于计算机软件来说，一个对象是一个拥有数据和作用在这些数据上的一组方法（或称为函数）的实体，它通过一个接口（可被调用的一组方法）对外提供服务。所有的事物，包括物体、人、活动、关系以及由它们组成的混合体都可看成是对象。例如：学籍管理系统中的学生、课程、教师等均是这个系统中的对象。对象由属性和方法组成。
（二）属性（property）
属性就是对象所包含的信息。它是对客观世界中的实体所具有的性质的抽象。
（三）方法（Method）
方法就是对象所能执行的操作。方法描述了对象执行某种操作的算法。这种操作的过程对外是封闭的，即用户只能看到这一方法实施后的结果。相当于事先已经设计好的各种过程，只需要调用就可以了，用户不必去关心这一过程是如何编写的。
（四）消息（Message）
在面向对象的系统中，各个对象之间的协作是通过发送消息来完成的。即：对象之间的联系是通过传递消息来实现的。所以，消息就是用来请求对象执行某一具体操作或回答某些信息的要求。当一个消息发送给某个对象时，包含要求接收对象去执行某些活动的信息。接收到消息的对象经过解释，然后予以响应，这种通信机制也称作消息传递。
（五）类（Class）
从客观对象中抽象出本质特征，这些抽象的本质特征就是这些对象的类。例如：某一个人是具体的对象，将所有人的共同特征抽象出来就是类——人类。类是抽象的概念，不是具体的实体。
每一个对象都属于某个类，类不仅决定了对象的类型，还决定了它的属性（域）和方法。属性和方法在类定义中表达出来。创建一个新对象时，与对象类型相对应的类的定义决定了对象的结构和行为。
类还具有父类、子类之分。父类是高层次的类，表达共性；子类是低层次的类，表达个性。子类通过继承机制获得父类的属性和操作。例如：山地自行车、公路自行车、折叠自行车等都是类，因为只有具体的某部山地自行车，没有抽象的山地自行车。这些类又具有自行车的公共特性，因此自行车就是它们的父类，它们是自行车的子类，子类继承了父类的所有属性和操作，而且子类自己还可扩充定义自己的属性和操作。例如：自行车类具有材质、车速、档位数等属性，山地自行车则继承了这些属性，并扩充了自己的属性，比如减震器。
（六）封装（Encapsulation）
封装就是将事物包起来，使外界不知其实际内容。对象可以看作是数据及作用在这些数据上的方法的封装体，它通过一个接口与外部进行交互，因此封装使得对象的内部实现与外部接口分离开来。这样，改变对象的内部实现并不影响使用这个对象的其他对象或应用。这种封装性也体现了一种抽象和信息隐蔽。封装、抽象和信息隐蔽是用来降低软件复杂性的重要技术。
（七）继承（Inheritance）
继承可以指一种类型的对象继承了另一种类型的对象的特性。在面向对象的程序设计中，继承是指一个子类继承父类的特征。在继承父类时，可以在子类中增加新的属性（数据结构）和方法，也可以重定义从父类中继承下来的方法。父类的特征并不受子类的影响，反之，在理想情况下，父类的内部实现的变化不会影响子类。当然，一个子类可以有多个父类，这种情况称为多继承。继承带来的好处是软件的复用，使用继承可以在已有软件构件的基础上构造新的软件，从而提高软件的生产率并保证软件的质量。
继承具有传递性，继承使得相似的对象可以共享程序代码（方法）和数据结构（属性），从而大大减少了程序中的冗余信息，使对软件的修改变得比过去容易得多了。
（八）多态（polymorphism）
多态的原意是指一个实体多个形态。在收到消息时，对象要予以响应，不同的对象收到同一消息可产生多种不同的结果，即会有多种不同形式，这就是多态。在使用多态时，用户发送一个通用的消息，而实现细节则由接收对象自行决定，这样，同一消息就可以由不同的对象调用不同的方法来响应，从而产生不同的响应结果。
多态的实现受到继承性的支持，利用类层次的继承关系，把具有通用功能的消息存放在高层次，而实现这一功能的不同的行为放在较低层次，则在这些低层次上生成的对象就能给通用消息以不同的响应。
8.4.3 开发过程
应用面向对象方法进行系统开发一般经历3个阶段，即系统分析（面向对象分析，简称为OOA）、系统设计（面向对象设计，简称为OOD）和系统实施（面向对象编程，简称为OOp），看上去与传统的生命周期法相似，但其各阶段所解决的问题和采用的描述方法却有极大区别。
因为面向对象方法把信息系统看做是互相作用的对象集合，因此，OOA意味着定义系统中所有的对象类型，并显示对象之间是如何通过相互作用来完成任务的。OOD意味着定义系统中的人和设备进行通信所必需的其他对象类型，同时，细化每一种类型的对象定义以使用一种具体的语言或环境来实现它。OOp意味着用编程语言书写语句来定义每一类对象的状态和行为。因此，OOA是问题抽象（做什么），OOD是问题求解（怎么做），OOp是问题的解（结果）。下面简要介绍O-O方法所包含的具体内容。
（一）面向对象的分析（OOA）
面向对象分析通常被用于软件项目的初始化阶段，而它的结果被用于系统开发的下一个阶段——面向对象的设计。OOA强调直接针对问题域中客观存在的各种事物来设立OOA模型中的对象。用对象的属性和服务分别描述事物的静态特征和行为。问题域中有哪些值得考虑的事物，OOA模型中就有哪些对象，而且对象及其服务的命名都强调与客观事物的一致性；OOA模型保留了问题域中事物之间关系的原貌。包括把具有相同属性和相同服务的对象归结为类、用一般—特殊结构描述普通类和特殊类之间的静态关系和动态联系，这里的静态联系表示一个对象的属性与另一个对象有关，而动态性则表示一个对象的行为与另一个对象行为无关。
（二）面向对象的设计（OOD）
OOA与OOD的职责划分是OOA针对问题域运用O-O方法，建立一个反映问题域的 OOA模型，不考虑与系统的具体实现有关的因素（比如采用什么编程语言、图形用户界面和数据库等），从而使得OOA模型独立于具体实现。OOD则针对系统的一个具体的实现运用O-O方法，其中包括两方面的工作：一是把OOA模型直接搬到OOD（不经过转换，仅做某些必要的修改和调整），作为OOD的一个部分；二是针对具体实现中的人机界面、数据存储和任务管理等因素补充一些与实现有关的部分，这部分与OOA采用相同的表示法和模型结构。
OOA与OOD采用一致的表示法是面向对象方法优于传统开发方法（例如结构化方法）的主要原因之一。这样可以使得从OOA到OOD的过程不存在转换，只有局部的修改或调整，最多增加几个与实际实现有关的独立部分。因此，OOA与 OOD之间不存在传统开发方法中分析与设计之间的鸿沟，而这能够紧密衔接，大大降低了从OOA到OOD的难度、工作量和出错率。
（三）面向对象的编程（OOp）
这一阶段的任务是将OOD中得到的模型利用程序设计实现，即采用面向对象的程序设计语言将前一步骤整理的范式直接映射为应用软件。理想的O-O开发规范，应要求在OOA和OOD阶段就对相同需要设立的每个对象类，以及内部构成与外部联系都有透彻的认识和清晰的描述，而不是把许多问题留给程序员去重新思考。程序员要做的工作就是用具体的数据结构来定义对象的属性，用具体的语句来实现服务流程图所表示的算法。在程序实现阶段，采用面向对象程序语言产生的程序能够紧密对应OOD模型；OOD模型中的一部分对象类对应OOA模型，其余部分的对象类对应与实现有关的因素；OOA模型中的全部类及对象又都对应问题域中的事物。这样的映射关系不仅提高了开发的效率和质量，对后期的维护也十分有利。
8.4.4 面向对象的系统开发工具——UML*
UML（Unified Modeling Language，统一建模语言）是一套目前被广泛接受作为对象建模标准的符号体系，它使用对象说明或描述软件系统。
（一）产生过程
在面向对象方法的发展过程中，一些专家、学者根据面向对象方法的基本思想，对系统分析，设计的步骤、方法、图形工具等进行了详细研究，提出了多种不同的方案。比较著名的有Coad/Yourdon方法、Grady Booch方法、Jim Rumbaugh等的OMT方法以及Ivar Jacobson的OOSE（面向对象软件工程）方法等。各种不同类型的O-O方法各有特色，在推动这一方法的发展与应用上均有突出的贡献。然而，面向对象方法的概念体系和实施过程比传统方法复杂，由于缺乏统一的建模规范，应用起来多有不便。这是在一个时期内影响这一方法发展的主要原因之一。为了向广大用户提供一个吸取现有各种方法特长的统一建模工具，从1994年开始，Booch与Rumbaugh首先将两者的方法统一起来，命名为统一方法（Unified Method，UM），1995年10月发布了一个公开的版本UM0.8。此后Jacobson 加盟这一工作，通过三人共同努力，将UM重新命名为统一建模语言（Unified Modeling Language，UML），于1996年6月和9月分别发布了两个新版本UML 0.9 和 UML 0.91，UML获得了工业界与学术界的日益广泛的支持。此后经过不断的修订，到2001年，发布了UML 2.0版，目前可视化建模语言已成为事实上的工业标准，代表了面向对象方法的一个重要发展方向。UML模型图有九种，在后面有具体介绍，包括构造系统的框架结构的静态模型：用例图、类图、对象图、组件图、配置图，以及描述系统行为、表示模型执行时的时序状态或交互关系的动态模型：状态图、活动图、顺序图和协作图。下面通过其应用加以简要说明。
（二）UML的具体应用
UML是用来描述模型的，它用模型来描述系统的结构或静态特征、行为或动态特征。
1.面向对象系统分析的过程
像任何其他系统分析方法一样，OOA的目的是更好地理解系统及其需求。换句话说，OOA要求我们辨识支持业务需求的对象、对象的数据属性、相关的行为以及对象之间的关联。我们通过对象建模，记录确定的对象、对象封装的数据和行为以及对象之间的关系。
OOA包括四个活动，具体如下：
（1）建模系统功能
用于系统功能建模的方法称为用例建模。它是按照业务事件、谁发起事件和系统如何响应事件建模系统功能的过程。用例建模从外部用户的角度使用一种被称为用例的工具确定并描述系统功能。用例是一组相关行为的自动的和手工的步骤序列，其目的是为了完成单个业务任务。用例从外部用户的角度以他们所理解的方式和词汇描述系统功能。为了正确而全面地描述用例，要求用户高度参与。
用例是将系统功能范围分解成许多较小的系统功能陈述的结果。用例本身不是一个功能需求，但它讲述的场景收集了一个或多个需求的本质内容。因此，从某种程度上说，用例就是讲述人们（或其他事物）如何使用系统来执行某些任务的故事。通过用例观察系统，能够将系统实现与系统需求分开，这样有助于了解系统最重要的部分。
代表洗衣机用户的直立小人形被称为参与者（Actor），椭圆形代表用例，用例的命名一般以动词开头以强调这是一个过程。值得注意的是，参与者（发起用例的实体）可以是人，也可以是系统。关于用例的具体过程将在用例描述（文字模型）中记载。
需求分析阶段的用例模型是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看做黑匣子，从外部执行者的角度来理解系统；第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统。
（2）发现并确定业务类
在试图确定类时，许多方法学专家建议查找需求文档或者其他相关文档，并划出表示潜在类的名词。这可能是一项复杂的任务！因为名词太多了。用例模型对这个问题提供了一个解决方案，即将整个系统分解成用例。这些相对较小的用例减少了挑选名词的工作量。因而在用例模型中发现和确定类，其目的是为了实现系统分析中的类建模。
（3）组织类并确定其关系
一旦确定了系统的业务类，就要组织这些类，并记录类之间的主要概念关系，如关联、继承和父类/子类等关系。UML的类图可以图形化的方式描述类及其静态关系。其中，矩形方框代表类的图标，它被分成3个区域。最上面的区域中是类名，中间区域是类的属性，最下面区域里列的是类的操作。类图就是由这些类框和表明类之间如何关联的连线所组成。这里，洗衣机类的属性包括品牌、型号、出厂序列号和洗涤容量等；类的操作包括“加衣物”、“加洗涤剂”、“开机”和“取出衣物”等。
类图为开发人员提供了模仿现实世界的表达方式，它允许系统分析员使用客户采用的术语与其交流，促使客户提出所要解决问题的相关细节。
对象（Object）是类的实例，具有具体属性值和行为。例如，某个洗衣机的品牌可能是“海尔”，型号为“XDL500”。UML中，对象图可以看作是类图的一个实例，它建模实际的类实例——显示实例的属性的当前值。对象之间的链（Link）是类之间的关联的实例，对象图为开发人员提供对象在某个时间点上的“快照”。这个模型图不像类图那样经常使用，但使用它能够帮助开发人员更好地理解系统结构。与类的图形表示相似，UML表示对象的图标也是个矩形，只是对象名下面要带下划线。具体实例的名字位于冒号的左边，而该实例所属的类名位于冒号的右边。比如，海尔：洗衣机。
（4）建模对象行为
所有的对象都具有状态——属性在某个时刻的值。当某事发生或者一个属性的值发生变化时，对象就改变状态。一部电梯可以处于上升、停止或下降状态。洗衣机可以处于浸泡、洗涤、漂洗、脱水或关机等状态。UML的状态图建模单个对象的生命周期，它描述了一个对象可以具有的不同状态，包括一系列的状态以及状态之间的转移。
不是所有的对象都需要状态图。一般来说，仅为那些明显地具有可标识状态和复杂行为的对象构造状态图。
2.面向对象系统设计的过程
OOD是OOA的延续，开发角度继续集中于对象建模技术上。从OOA到OOD是一个渐进的模型扩充过程，从OOA到OOD不存在转换问题，而是同一种表示方法在不同范围的运用。OOD包括了问题域部分、人—机交互部分、任务管理部分和数据管理部分等四个部分的设计。OOD不是OOA的细化，它的问题域部分是把OOA模型直接拿来，针对实现的要求进行必要的增补和调整，OOD的问题域部分与OOA并没有严格的划分，实际上可以把OOA理解为OOD的一个部分，这种分析与设计的无缝连接更真实地反映了开发活动的本质。
OOD的其他三个部分是OOA阶段未曾考虑的，全部在OOD阶段建立。
在OOD阶段，要对OOA阶段建立的对象和用例加以精炼，以反映所建议的方案的实际环境。OOD包括以下活动：
（1）对用例模型加以精炼以反映实现环境
在用例建模的这次迭代中，将对用例加以精炼，即每个用例都被高度细化，从而包括参与者（或用户）如何实际地与系统接口以及系统如何响应激发处理业务事件的细节。
在OOA中，重点是确定表示业务领域内的实际数据的对象，这些对象称为实体对象。在OOD中，继续精炼这些实体对象，并确定作为新系统的物理实现而引入的其他类型对象。OOD阶段将引入另外两种类型的对象：一种用来表示用户与系统接口的方式，称为接口对象。例如，ATM机需要一个显示器使参与者或用户和系统通信，用于表现信息。显示器即为接口对象；另一种对象承载应用逻辑或业务规则，称为控制对象。它可以被看做一个“交通警察”，包含了用于管理或指导对象之间交互的应用逻辑或业务规则。
OOD阶段，用户同系统的交互方式——通过菜单、窗口、按钮、打印机——都应该被详细地描述。窗口、报告和查询的内容也应该在用例描述中加以说明。在所有的分析用例都被精炼细化成设计用例后，仍可能会发现新的用例或者参与者，所以应该修改UML的用例图和用例描述。
（2）建模支持用例情境的对象交互和行为
此活动将确定并分类对象，根据设计用例确定对象是实体、接口还是控制对象，而且还要确定对象之间的交互和行为。
一旦确定了对象的行为，即可以创建一个详细模型，这个模型描述了对象之间如何通过交互提供每个设计用例中说明的功能。UML提供了两类图形化的模型来描述这些交互——顺序图和协作图。顺序图详细显示对象如何随着时间的推移进行交互，协作图显示对象如何以消息序列协作的形式满足用例功能。
它存在两个轴：水平轴表示不同的对象，垂直轴表示时间。图中的对象用一个带有垂直虚线的矩形框表示，并标有对象名和类名。垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。图中进水管、洗涤缸和排水管等三个对象用矩形图标表示。整个图反映了各对象随时间变化所经历的交互过程。图中进程是从上到下的，对象之间发送的消息有：注入净水、保持静止、停止注水、旋转洗涤、排污水等。
其中，洗衣机构件类中增加了一个内部计时器。在经过某段时间后，定时器停止注水，然后启动洗涤缸旋转洗涤。图中的序号代表命令消息的发送顺序，计时器对象先向洗涤缸对象发送旋转洗涤的消息，再向进水管对象发送停止进水的消息。
（3）修改类图以反映实现环境
一旦设计了对象/类及其所需的交互，就可以对类图加以精炼，使类包括它所需拥有的行为或者实现方法。
以上OOD阶段活动针对实现的要求对问题域部分进行了必要的增补和调整，增加了人—机交互部分。另外，在OOD还包括新建立的任务管理部分。在设计多任务并行系统时，才有任务管理问题。譬如：多窗口同时接受输入，在多用户系统中存在的用户任务复本，等等。OOD阶段新建立的数据管理部分是连接问题域子系统和外部数据库管理系统的桥梁，为实现对象的物理存取建立通道。目前多选用关系数据库管理系统为面向对象信息系统储存数据，需要在对象存取时进行格式的变换。譬如，设计对象属性的存储时，要将属性一一列举，构成符合关系范式的数据表，再建立对应的关系数据库。
（三）其他UML模型图
1.活动图
活动图类似于流程图，它以图形化方式描述了一个业务过程或者一个用例的活动顺序流。但它不同于流程图，因为它提供了一种描述并行发生的活动的机制。活动图可以灵活地应用于OOA和OOD阶段。圆角矩形表示所需执行的活动或者任务；实心黑棒称为同步条，它可以描述并行发生的活动，如活动“评估需求”和“检查预算”并行发生，它们可以按任何顺序执行，但两个任务都要在活动“同意请求”执行之前执行；菱形表示决策活动；一个空心园套一个实心点表示过程的终止。
2.组件图和配置图
组件图是一种实现类型的模型图，用于以图形化的方式描述软件系统的物理架构。它可以用来显示编程代码如何被划分成模块（或者组件），并描述这些组件之间的依赖关系。配置图也是实现类型的模型图，描述了系统中硬件和软件的物理架构，即描述构成系统架构的计算机和设备，展示其间的连接以及驻留在每台机器中的软件。
8.4.5 O-O法的优缺点和适用范围
面向对象开发方法以对象为基础，利用特点软件工具直接完成从对象客体的描述到软件结构的转换。其主要优点如下：
（1）采用面向对象思想，使得系统的描述及信息模型的表示与客观实体相对应，符合人类的思维习惯，有利于系统开发过程中用户与开发人员的交流和沟通，缩短了开发周期，提高了系统开发的正确性和效率。
（2）面向对象开发方法的应用解决了结构化开发方法中客观世界描述工具和软件结构的不一致性问题，解决了从分析、设计等到软件模块结构之间多次转换映射的繁杂过程。
（3）面向对象技术中的各种概念和特性，如继承、封装、多态性及消息传递机制等，使软件的一致性、模块的独立性和程序的共享性、重用性大大提高，也与分布式处理、多级系统及网络通信等发展趋势相吻合，具有广阔的应用前景。
但是，我们必须看到该方法也存在明显的不足。首先，必须依靠一定的软件技术支持才可得以应用；其次，它是一种自下而上的系统开发方法，在大型管理信息系统开发上具有一定的局限性，若不经自顶向下的整体划分，而是一开始就自底向上采用面向对象方法开发系统，会造成系统结构不合理、各部分关系失调等问题。
由此可知，面向对象开发方法的适用面比较广，基本适用于各类信息系统的开发，但对大型管理信息系统的开发则不太合适。
8.5 组合开发方式及CASE方法
由于上述开发方法均有各自的优缺点，采用一种开发方法进行系统开发往往带有一定的局限性，为此，人们试图综合采用上述方法进行系统的开发，可以弥补各自的缺点。主要组合方式有：
8.5.1 结构化系统开发方法与原型法的组合
当系统规模较大时，往往采用两者结合的形式进行系统开发，在系统规划和系统分析阶段，采用结构化开发思想，自顶向下，从总体到部分，合理划分系统结构，设计数据库模型；在开发具体的模块时，采用原型法，加速开发进程，并让用户较早地参与到系统开发中去。
8.5.2 结构化系统开发方法与面向对象法的组合
对于大型系统开发项目，借助结构化系统开发方法的整体性、系统规划和系统分析的特长，可以把握系统开发中的整体结构和关键因素；而具体开发过程中，采用面向对象法能够实现各开发阶段的平稳过渡，减少中间环节和结果，缩短开发周期。
8.5.3 原型法与面向对象法的组合
原型法和面向对象法的开发方法本来就是相互关联的两种方法，从面向对象思想出发，系统开发以对象表示现实世界的各个实体，由此进行系统的各项开发工作；而各项具体的开发任务可以利用原型法的特点，尽快构造出原型并不断修改完善。因此，原型法必定是采用面向对象的开发方法进行系统开发过程中开发具体模块时的主要方法和手段。
8.5.4 CASE方法
所谓CASE，全称为计算机辅助软件工程（Computer Aided Software Engineering，CASE），是20世纪80年代发展起来的一组计算机工具和方法集合，因为其使用的高效和快捷，也被当作一种系统开发方法普遍使用。但严格地讲，CASE不能算是一种专门的开发方法，只能是一种开发环境，或者是一种辅助性的开发方法。它是从计算机辅助编程工具、第四代语言（4GL）以及绘图工具发展而来的，主要在于帮助开发者产生开发过程中的各类图表、程序和说明性的文档。作为一种自动化或半自动化的方法，能够全面支持除了系统规划以外的每一个开发环节，CASE的关键就是集成，由一系列可协调的软件工具组成，从而形成一整套软件开发的支持环境。其作用就在于能大大提高系统开发的效率和可靠性。
计算机辅助软件工程方法解决系统开发问题的基本思想是：结合系统开发的各种具体方法，在完成对目标系统规划和详细调查后，如果系统开发过程的每一步都相对独立且彼此形成对应关系，则整个系统开发就可以应用专门的软件开发工具和集成开发环境（CASE工具、CASE系统、CASE工具箱、CASE工作台等）来实现。这里所说的对应关系与所采用的具体开发方法有关，大致可以包括结构化方法中的业务流程分析、数据流程分析、功能模块分析、程序实现、业务功能一览表、数据/过程分析以及数据库设计等；也有像面向对象法中的问题抽象，属性、结构和方法定义，对象分类，程序实现等。
用CASE工具进行系统开发，必须结合一种具体的开发方法，毕竟CASE只是为具体的开发方法提供了支持其每一过程的开发环境。如：结构化系统开发方法作为管理信息系统开发的基础方法，可以独立进行系统开发的整个过程。CASE方法的强大环境可为系统开发的各个阶段提供全程的自动化支撑，这种组合开发的优势十分明显；原型法要求快速生成原型的软件工具作为基础，而CASE法首先作为一种强大的软件开发集成环境，提供了对原型构造的支持工具。另外，它还支持对系统分析和设计环节的自动化，因此，两者的结合可以充分发挥快速开发的优势；面向对象法采用CASE方法，可实现整个系统开发过程中各阶段模型生成的自动化和无缝连接，以及模型与代码之间转换的一致性。
【本章小结】
信息系统的构建或开发，是指组织创建一套满足特定管理工作需要的计算机系统，或对现有计算机应用系统进行改进的过程。从软件的角度看，信息系统构建的实质就是开发或拥有一套针对企业生产管理需求的应用软件。在系统的创建过程中，应充分了解并掌握系统开发所涉及的相关问题，分析系统构建的条件，并在此基础上选用合适的构建方式和正确的构建方法。仅从开发一套信息系统本身的角度看，本章将开发方法大致分为结构化系统开发方法、原型法、面向对象开发方法等几类。结构化系统开发方法强调开发人员和用户的紧密结合，开发策略上强调“自上而下”，注重开发过程的整体性和全局性，但它的开发过程复杂繁琐，周期长，系统难以适应环境的变化，因此适合于结构化良好的大型系统的开发。原型法贯彻的是“自下而上”的开发策略，它更易被用户接受，是系统分析阶段获得用户需求的很好方法，但该方法在实施过程中缺乏对管理系统全面、系统的认识，因此它不适合大型系统的开发。它的另一不足是每次反复都要花费人力、物力，如果用户合作不好，盲目纠错，就会拖延开发过程。面向对象开发方法是在面向对象程序设计基础上发展起来的适应人们一般思维方式的描述问题的系统建模与开发方法，基于该方法建立起来的系统具有较强应变能力，系统各部分的可重用性好，但由于它是以数据驱动而非功能驱动的分析法，对于系统的整体行为（功能）缺乏必要的分析，只是通过对象之间的消息传递并不能完整体现出系统的总体功能，因此系统的总体结构性较差，并且它不涉足系统分析以前的开发环节。在实际应用中，应根据每种开发方法的优缺点，综合应用各种开发方法以达到互补的效果。另外，CASE方法是一种除系统调查外全面支持系统开发过程的方法，其本身并非一种开发方法而仅仅是一种开发环境，但能与具体的开发方法相结合，为每一种具体的开发方法提供支持。
【练习与思考】
1.信息系统有哪些开发方式或开发策略？
2.“自下而上”和“自下而上”两种MIS的开发策略各有什么优缺点？
3.试述结构化方法的基本思路、主要原则和特点。
4.结构化开发方法的开发过程包括哪些阶段？
5.什么是原型法？其基本思想是什么？主要解决什么问题？
6.原型法的开发过程是怎样的？它最适合哪类信息系统的开发？
7.面向对象的概念有哪些？各自的含义是什么？
8.什么是面向对象方法？其基本思路是什么？
9.试述面向对象分析和设计阶段的区别与联系。
10.UML共定义了哪几类图？其主要应用领域是什么？
11.CASE方法的基本思想是什么？有什么特点？
12.什么是面向对象方法学？这种方法学有哪些要点？有哪些优点？
13.什么是对象？什么是封装性与继承性？用具体的例子加以说明。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
