第二章信息系统工程体系

第2章

信息系统工程体系如果你根本不知道自己在讨论什么，那么对其强求精确是毫无意义的。软件工程的基本内容和目标软件工程体系:SOFTWAREENGINEERINGARCHITECTURE软件开发过程:IDENTIFYCOREACTIVITIESINSYSTEMSDEVELOPMENTLIFECYCLE&PROTOTYPING软件开发方法:EVALUATESTRUCTUREDANALYSISANDDESIGNMETHDOLOGY&OBJECT-ORIENTEDDEVELOPMENT软件开发环境和工具:COMPUTERAIDEDSYSTEMENGINEERING(CASE)*LEARNINGOBJECTIVES学习完本章后，你应该具备以下能力：理解信息系统工程的基本问题解释信息系统工程体系中的质量焦点理解过程、建模语言、方法学和工具在信息系统工程体系中的作用及其之间的关系掌握几种典型的系统开发生命周期模型，如瀑布模型、迭代模型、螺旋模型和喷泉模型，包括特点、适用范围等掌握典型的信息系统开发方法（结构化方法、面向对象方法）的基本概念和原理了解计算机辅助系统工程（CASE）的概念、意义学习目标目前软件开发中存在的问题：速度：软件的发展水平远远滞后于硬件的发展水平，生产率低下，软件制造仍然是一种人工集约生产方式质量：软件的质量低下，不能满足用户的需求、适应性差成本：软件开发成本居高不下软件开发的速度、软件制品的质量、软件开发成本是软件工程的三个核心问题。1.软件工程概述高质量：如何衡量软件的质量？产品操作（可用性、正确性、可靠性、效率、完备性等）产品修改（可维护性、适应性）产品适应（可移植性、可复用性、互操作性）高效率：计算机软件的生产率及其性能将大大落后于硬件的发展速度，计算机软件已成为计算机技术和应用发展的主要“瓶颈”。低成本：目前的软件生产仍是人工集约生产方式1.软件工程概述软件质量度量软件质量可直接测量Measurement，测量得到定义属性值。如吞吐量、响应时间等性能指标。间接度量Metrics。度量一般是某一个相对尺度，发现问题。如可维护性、适应性等。 McCall质量因素 直接测量 间接度量 定型的准则可用打分（1..10）方法度量适变能力适应能力运作性能正确性可靠性易用性集成性效率可维护柔性可测试可移植可重用互操作性思考：你认为通过哪些途径或技术可以实现上述目标？不同的方法或技术在上述三个基本问题上的效果有何不同？Softwareengineering(1968,NATO)Popularduringthe1970sItnowreferstoacollectionofmanagementprocesses,softwaretooling,anddesignactivitiesforsoftwaredevelopment.1.软件工程概述AccordingtotheIEEE[2]StandardComputerDictionary(1990),softwareengineeringistheapplicationofasystematic,disciplined,quantifiableapproachtodevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.Theaimofsoftwareengineeringistheproductionofqualitysoftware,deliveredontime,withinbudget,andsatisfyingusers'needs

1.软件工程概述软件工程——是指把系统的、规范化的、可以度量的方法运用于软件的开发、运行和维护的过程；简言之，工程化在软件开发方面的应用。以工程的方法制作软件项目project或产品product的全过程（从立项到交付）工程方法：人们利用技术（或工具）、技能通过有组织活动完成契约规定的目标，即按预定完工期交付合格成品。工程要素：人力、资金、技术工程目标：在给定的资金、限制的时间内，完成符合相应标准的产品。（成本、进度、质量三要素）1.软件工程概述软件工程知识主体指南主要内容软件需求(SoftwareRequirement)软件设计(SoftwareDesign)软件构造(SoftwareConstruction)软件测试(SoftwareTesting)软件维护(SoftwareMaintenance)软件配置管理(SoftwareConfigurationManagement)软件工程管理(SoftwareEngineeringManagement)软件工程过程(SoftwareEngineeringProcess)软件工程工具和方法(SoftwareEngineeringToolsandMethods)软件质量(SoftwareQuantity)2.信息系统工程体系

信息系统工程是指以计算机、网络、数据库、软件等信息技术与产品为构件的系统工程（罗晓沛、侯炳辉，2003）。信息系统工程的内容包括硬件工程、软件工程、网络工程、数据工程、人机工程。其中数据工程是信息系统工程的基础工程。2.信息系统工程体系信息系统危机效益问题。对企业来说，信息系统的建设是一项巨大的投资。用户在硬件、软件、开发和维护等方面投入了大量的资金，却很少能产生明显的经济效益和社会效益，甚至导致企业破产。从而使很多企业对信息系统的建设持有观望、甚至抵制的心理。有些企业过分强调了硬件的档次和质量，而忽视了其它一些更为重要的因素。2.信息系统工程体系信息系统危机需求问题。信息系统是一个社会技术系统，其中的不稳定因素很多，导致用户的需求更具有不确定性和易变性。如何适应用户需求的变化是信息系统工程研究的一个核心问题，目前的信息系统开发技术并不能很好地解决这一问题。2.信息系统工程体系队伍建设问题。企业是否要建立自己的开发队伍？这一直是困扰企业领导层的一个问题。系统分析员的奇缺，技术人员的频繁流动，导致企业没有自己的信息系统建设队伍。

2.信息系统工程体系规划问题。与软件不同的是，信息系统总是处于企业的业务环境之中的，是企业管理系统的一个子系统。传统的信息系统建设往往是从某个局部应用开始的，只注重于某个业务子系统，而忽略了整个企业对信息系统的全局要求。没有统一的信息系统规划的指导，就会出现数据不一致，已有的系统很难集成等问题。规划工作必须由领导直接参与，而领导重视程度不够，不能直接参与规划工作是普遍的现象。2.

信息系统工程体系信息系统工程包含四个部分：第一部分是：方法——提供了构造信息系统的技术第二部分：建模语言——用以支持信息系统的分析、设计和实现第三部分：工具——为方法和语言提供自动化或半自动化的支持第四部分是：信息系统开发过程——是粘结剂（Glue）把方法、语言和工具结合在一起。过程定义了方法的使用顺序、可交付产品（文档、报告、格式）的要求，确保质量和修改的控制，并使信息系统管理人员能对它们的进展进行评价。2.信息系统工程体系2.信息系统工程体系信息系统工程是一种层次化的技术任何工程方法（包括软件工程、信息系统工程）必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激了不断的过程改进，正是这种改进导致了更加成熟的软件工程和信息系统工程方法的不断出现。支持信息系统工程的根基就在于对质量的关注。2.信息系统工程体系信息系统工程的基层是过程层信息系统工程过程是将技术层结合在一起的凝聚力，使得信息系统能够被合理地和及时地开发出来。过程定义了一组关键过程区域的框架，这对于信息系统工程技术的有效应用是必须的。关键过程区域构成了信息系统项目管理控制的基础，并且确定了上下各区域之间的关系，规定了技术方法的采用、工程产品（模型、文档、数据、报告、表格等）的产生、里程碑的建立、质量的保证及变化的适当管理。2.信息系统工程体系信息系统工程的方法层提供了为开发信息系统在技术上需要“如何做”。方法涵盖了一系列的任务：需求分析、设计、编程、测试和维护。2.信息系统工程体系信息系统工程的建模语言层模型是用某种工具对同类或其他工具的表达方式。模型从某一个建模观点出发，抓住事物最重要的方面而简化或忽略其他方面。工程、建筑和其他许多需要具有创造性的领域中都使用模型。

2.信息系统工程体系信息系统工程的建模语言层软件系统的模型用建模语言来表达，如UML。模型包含语义信息和表示法，可以采取图形和文字等多种不同形式。建立模型的目的是因为在某些用途中模型使用起来比操纵实物更容易和方便。

2.信息系统工程体系信息系统工程的工具层对过程和方法提供了自动的或半自动的支持。当这些工具被集成起来使得一个工具产生的信息可以被另外一个工具使用时，一个支持信息系统开发的系统就建立了，称为计算机辅助软件工程（CASE）。CASE集成了软件、硬件和一个软件工程数据库（包含了关于分析、设计、编程和测试的重要信息），从而形成了一个软件工程环境。3.信息系统工程过程模型“计划本身什么都不是，而编制计划的过程就是一切。”——美国第34任总统艾森豪威尔上将。产品什么也不是，而开发产品的过程就是一切。文档什么也不是，而编制文档的过程就是一切。3.信息系统工程过程模型过程（Process）：为实现一个给定目标而进行的一系列运作步骤。过程具有一系列的性质：时间性、并发性、嵌套性和度量性等。软件过程：软件开发过程是一个将用户需求转化为软件系统所需要的活动的集合。即开发和维护软件及其相关产品所涉及的一系列活动。过程是活动的集合；活动是任务的集合；任务是把输入转换为输出的操作。3.信息系统工程过程模型软件过程模型也称为系统开发生命周期（SDLC：SystemDevelopmentLifeCycle）模型，是软件开发的指导思想和全局性框架，软件过程模型的提出和发展反映了人们对软件过程的某种认识观，体现了人们对软件过程认识的提高和飞跃。3.信息系统工程过程模型SDLC包括：任务分解结构WBS(WorkBreakdownStructure)。如传统的系统开发阶段包括可行性研究、初始调研、系统分析、总体设计和详细设计等，现代的系统开发阶段包括系统规划、系统分析、系统设计、系统实施和系统支持。WBS优先级结构。即系统开发所遵循的基本模式，如瀑布模型(Waterfall)、阶梯模型(Stairstep)、螺旋模型(Spiral)、迭代模型(Iterative)等。软件开发过程(模式)的演化:——瀑布模型:适合于科学数值计算,嵌入式软件和实时控制系统——原型开发模型:(抛弃式,演化式,增量式):适合于商业数据处理系统的开发——螺旋开发模型:综合了瀑布模型和原型开发模型的优点.四个主要步骤:计划,风险分析,工程,用户评价.适合于大型软件的开发——4GL技术:限于事务信息系统中的中\小型应用程序的开发3.信息系统工程过程模型——过程开发模型(混合模型hybridmodel或元模型metamodel):最初只是用来代表美国DoD调查各软件机构开发过程的成熟程度.1991年DodSEI公布的CMM.——面向对象生存期模型:喷泉模型.具有更多的增量和迭代性质,生存期的各个阶段可以相互重叠和多次反复,而且在项目的整个生存期中还可以嵌入子生存期.——基于构件的软件开发(CBD:Component-BasedDevelopment):是在软件重用和OO技术基础上发展起来的,是一个面向产品结构的软件开发模式.3.信息系统工程过程模型——统一的软件开发过程(TheUnitedSoftwareDevelopmentProcess):基于UML,有三个关键思想,使用用例驱动(Use-CaseDriven);以体系结构为中心(Architecture-Centric);迭代与增量式开发(IterativeandIncremental)3.信息系统工程过程模型3.1瀑布模型（WaterfallModel）系统规划系统分析系统设计系统实施系统维护什么是信息系统规划（InformationSystemPlanning,ISP）？在充分、深入研究企业发展远景、业务策略和管理的基础上，形成信息系统的远景、信息系统的组成架构、信息系统各部分的逻辑关系，以支撑企业战略规划（BusinessStrategicPlanning,BSP）目标的达成。

PHASE1：SYSTEMSPLANNINGPHASE1：SYSTEMSPLANNING理解关键的企业目标企业如何达到目标？IS如何支撑这些目标？需要哪些IT支撑IS？信息化建设具体项目的实施企业战略规划（BSP）信息系统战略规划（ISSP）信息技术战略规划（ITSP）ISP的主要目标：根据组织的目标与战略制定出组织中业务流程改革与创新和信息系统建设的长期发展方案，决定信息系统在整个生命周期内的发展方向、规模和发展进程。主要任务:(1)根据组织的发展目标与战略制定业务流程改革与创新的目标和信息系统的发展战略。(2)制定组织的业务流程规划，确定业务流程改革与创新的方案(3)根据组织目标和业务流程规划确定信息系统的总体结构规划方案；(4)安排项目实施方案，制定信息系统建设的资源分配方案。PHASE1：SYSTEMSPLANNING系统分析的主要任务是对现行系统进行详细调查，以充分掌握现行系统全面和真实的情况，分析用户信息需求，在此基础上提出新系统的逻辑模型，并编写系统分析报告。PHASE2：SYSTEMSANALYSISANALYSISOFPROBLEMTOBESOLVEDWITHANINFORMATIONSYSTEMFEASIBILITYSTUDY:Canproblembesolvedwithin constraints?REQUIREMENTSDEFINITIONPHASE2：SYSTEMSANALYSISFEASIBILITYTECHNICAL:

Assesshardware,software,technicalresourcesECONOMIC:Willbenefitsoutweighcosts?OPERATIONAL:

Issolutiondesirablewithinexistingconditions?*REQUIREMENTSDEFINITIONINFORMATIONREQUIREMENTS:

Detailedstatementofnewsystemneeds*需求定义框架——PIECESPIECES-ausefulframeworkforclassifyingproblems,opportunities,anddirectives.ItiscalledPIECESbecauseeachofthelettersrepresentoneofsixcategories.P

-theneedtoimproveperformance.I-theneedtoimproveinformation(anddata).E-theneedtoimproveeconomics,controlcosts,orincreaseprofits.C-theneedtoimprovecontrolorsecurity.E-theneedtoimproveefficiencyofpeopleandprocessesS-theneedtoimproveservicetocustomers,suppliers,partners,employees,etc.ThePIECESProblem-SolvingFrameworkThePIECESProblem-SolvingFrameworkThefollowingchecklistforproblem,opportunity,anddirectiveidentificationusesWetherbe'sPIECESframework.NotethatthecategoriesofPIECESarenotmutuallyexclusive;somepossibleproblemsshowupinmultiplelists.Also,thelistofpossibleproblemsisnotexhaustive.ThePIECESframeworkisequallysuitedtoanalyzingbothmanualandcomputerizedsystemsandapplications.PERFORMANCEProblems,Opportunities,andDirectivesA. Throughput–theamountofworkperformedoversomeperiodoftime.B. Responsetime–theaveragedelaybetweenatransactionorrequestandaresponsetothattransactionorrequestINFORMATION(andData)Problems,Opportunities,andDirectivesA. Outputs1. Lackofanyinformation2. Lackofnecessaryinformation3. Lackofrelevantinformation4. Toomuchinformation–``informationoverload''5. Informationthatisnotinausefulformat6. Informationthatisnotaccurate7. Informationthatisdifficulttoproduce8. InformationisnottimelytoitssubsequentuseFAST–ASystemDevelopmentMethodologyThePIECESProblem-SolvingFrameworkINFORMATION(andData)Problems,Opportunities,andDirectivesB. Inputs1. Dataisnotcaptured2. Dataisnotcapturedintimetobeuseful3. Dataisnotaccuratelycaptured--containserrors4. Dataisdifficulttocapture5. Dataiscapturedredundantly--samedatacapturedmorethanonce6. Toomuchdataiscaptured7. IllegaldataiscapturedC. StoredData1. Dataisstoredredundantlyinmultiplefilesand/ordatabases2. Storeddataisnotaccurate(mayberelatedto#1)3. Dataisnotsecuretoaccidentorvandalism（故意破坏）4. Dataisnotwellorganized5. Dataisnotflexible–noteasytomeetnewinformationneedsfromstoreddata6. DataisnotaccessibleFAST–ASystemDevelopmentMethodologyThePIECESProblem-SolvingFrameworkECONOMICSProblems,Opportunities,andDirectivesA. Costs1. Costsareunknown2. Costsareuntraceabletosource3. CostsaretoohighB. Profits1. Newmarketscanbeexplored2. Currentmarketingcanbeimproved3. OrderscanbeincreasedCONTROL(andSecurity)Problems,Opportunities,andDirectivesA. Toolittlesecurityorcontrol1. Inputdataisnotadequatelyedited2. Crimesare(orcanbe)committedagainstdata a. Fraud（欺诈） b. Embezzlement（盗用）3. Ethicsarebreachedondataorinformation–referstodataorinformationlettingtounauthorizedpeople4. RedundantlystoreddataisinconsistentindifferentfilesordatabasesFAST–ASystemDevelopmentMethodologyThePIECESProblem-SolvingFrameworkCONTROL(andSecurity)Problems,Opportunities,andDirectivesA. Toolittlesecurityorcontrol(continued)5. Dataprivacyregulationsorguidelinesarebeing(orcanbe)violated6. Processingerrorsareoccurring(eitherbypeople,machines,orsoftware)7. Decision-makingerrorsareoccurringB. Toomuchsecurityorcontrol1. Bureaucraticredtape（官僚）slowsthesystem2. Controlsinconveniencecustomersoremployees3. ExcessivecontrolscauseprocessingdelaysEFFICIENCYProblems,Opportunities,andDirectivesA. People,machines,orcomputerswastetime1. Dataisredundantlyinputorcopied2. Dataisredundantlyprocessed3. InformationisredundantlygeneratedB. People,machines,orcomputerswastematerialsandsuppliesC. EffortrequiredfortasksisexcessiveD. MaterialsrequiredfortasksisexcessiveFAST–ASystemDevelopmentMethodologyThePIECESProblem-SolvingFrameworkSERVICEProblems,Opportunities,andDirectivesA. ThesystemproducesinaccurateresultsB. ThesystemproducesinconsistentresultsC. ThesystemproducesunreliableresultsD. ThesystemisnoteasytolearnE. ThesystemisnoteasytouseF. ThesystemisawkwardtouseG. ThesystemisinflexibletoneworexceptionalsituationsH. ThesystemisinflexibletochangeI. ThesystemisincompatiblewithothersystemsJ. ThesystemisnotcoordinatedwithothersystemsPHASE3：SYSTEMDESIGN任务：赋予系统分析阶段所确定的新系统的功能一种具体的实现方法和技术。因此，系统设计的主要任务是依据系统分析报告，全面地确定系统应具有的功能和性能要求。系统设计主要包括总体设计和详细设计两个活动。总体设计的主要任务是构造软件的总体结构、数据库设计、计算机硬件软件和网络配置方案设计；详细设计包括代码设计、输入/输出设计、控制设计、程序设计。PHASE3：SYSTEMDESIGN

DETAILSHOWSYSTEMWILLMEETNEEDS:LOGICALDESIGN:

Components,dataasneededbyapplicationsPHYSICALDESIGN:

Physicallocationofcomponentsanddata*PHASE4：SYSTEMIMPLEMENTATION任务：根据系统设计所提供的控制结构图、数据库设计、系统配置方案及详细设计资料，编制和调试程序、调试系统、进行系统切换等工作，将技术设计转化为物理实际系统。系统实施阶段包括的活动有：编程：根据每一个模块的基本结构，用某种计算机语言编写其程序代码。测试：测试是程序执行的过程，其目的是尽可能多地发现软件中存在的错误。测试包括模块测试、集成测试、系统测试等。用户培训：编写用户操作手册。新旧系统之间的切换PHASE4：SYSTEMIMPLEMENTATIONPROGRAMMING:

TranslatingneedstoprogramcodeTESTING:

Doessystemproducedesiredresults?CONVERSION:Changingfromtheoldtothenew*PHASE5：SYSTEMMAINTENANCE系统维护(SystemsMaintenance)的任务：系统的日常运行管理，评价系统的运行效率，使之能正常地运作。输入是产品信息系统以及在使用该系统中所产生的各种问题。系统维护是一个再造软件工程的过程(包括逆向软件工程和正向软件工程)。系统支持包括校正性维护、适应性维护、完善性维护和预防性维护。瀑布模型的特点：结构简单明了；历史较长、应用面广泛、为广大软件工作者所熟悉；已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的；反馈信息慢。强调阶段的划分及其顺序性各阶段工作及其文档的完备性是一种严格线性的、按阶段顺序的、逐步细化的开发模式。3.1瀑布模型（WaterfallModel）2.瀑布模型的基本原则：原则1：用户积极参与用户的作用是什么？用户(User)能否积极参与信息系统的开发,是信息系统开发能否成功的一个关键的、绝对必要的因素。作为系统开发人员必须准确而有恰当地理解用户的需求,并将他(她)所理解的需求通过计算机来实现。要做到这一点,必须经常与用户沟通，将他所理解的用户需求用特定的语言描述出来,并反馈给用户,用户再提出进一步的修改意见,……经过几个反复，最终形成一个明确的用户需求。因此,在系统开发过程中,用户与系统开发人员之间的沟通是很关键的。语言上的沟通困难,理解上的不一致,一直是信息系统开发专家们多年来寻求能够很好地解决的一个问题。3.1瀑布模型（WaterfallModel）原则2：自顶向下，分而治之：阶段活动作业，严格按划分的阶段进行系统开发结构化方法对项目进行控制的一个基本原则就是运用系统处理方法,将系统开发的全过程采取“分而治之”的策略。其具体的办法就是将整个系统的开发过程分为一系列“阶段”,每一个阶段都规定了明确的任务和应该完成的文档。每一个阶段结束后均应从功能、预算、进度、质量等方面重新评估所开发系统的可行性，避免由于系统开发的失败造成更大的损失。结构化方法以瀑布模型为基础，按工程学的原理管理和组织信息系统开发。结构化方法的各阶段之间基本上是一种线性的顺序依赖关系，即前一个阶段的结果是后一阶段的工作依据。3.1瀑布模型（WaterfallModel）原则3：强调系统的观点从理论上讲，任何一个系统都是某一个大系统的一部分（即子系统）；同样，任何一个系统都是由一系列更小的子系统组成的。因此，为了更好地理解一个大型的系统，通常采用“分而治之(divideandconquer)”的办法，即将大系统分解为一系列子系统，将子系统分解为更小的、更易于理解的子系统，……直至所有的子系统更容易理解为止。3.1瀑布模型（WaterfallModel）原则4：文档标准化定义：文档(Document)是一种数据媒体和媒体上所记录的信息。在信息系统开发中,文档被用来描述或表示对开发活动、需求、过程或结果进行描述、定义、规定、报告或认证的任何书面或图示的信息为什么要文档标准化（文档的作用）1.文档是现代软件产品的一个重要组成部分。从几十年来人们对软件产品的认识不难看出，文档已成为软件产品必不可少的组成部分。2.文档是通讯和交流的手段。3.文档对信息系统的开发过程有重要的控制作用。4.文档是进行系统维护的依据。3.1瀑布模型（WaterfallModel）高质量的文档应当体现在以下一些方面：

1.针对性；文档编制以前应分清读者对象，按不同的类型、不同层次的读者，决定怎样适应他们的需要。例如，管理文档主要是面向管理人员的，用户文档主要是面向用户的，这两类文档不应像开发文档(面向软件开发人员)那样过多地使用软件的专业术语。

2.精确性：文档的行文应当十分确切，不能出现多义性的描述。同一课题若干文档内容应该协调一致，应是没矛盾的。

3.清晰性：文档编写应力求简明，如有可能，配以适当的图表，以增强其清晰性。

3.1瀑布模型（WaterfallModel）

4.完整性：任何一个文档都应当是完整的、独立的，它应自成体系。例如，前言部分应作一般性介绍，正文给出中心内容，必要时还有附录，列出参考资料等。同一课题的几个文档之间可能有些部分相同，这些重复是必要的。例如，同一项目的用户手册和操作手册中关于本项目功能、性能、实现环境等方面的描述是没有差别的。特别要避免在文档中出现转引其它文档内容的情况。比如，一些段落并未具体描述，而用“见××文档××节”的方式，这将给读者带来许多不便。

3.1瀑布模型（WaterfallModel）

5.灵活性：各个不同的软件项目，其规模和复杂程度有着许多实际差别，不能一律看待。对于较小的或比较简单的项目，可做适当调整或合并。比如，可将用户手册和操作手册合并成用户操作手册；软件需求说明书可包括对数据的要求，从而去掉数据要求说明书；概要设计说明书与详细设计说明书合并成软件设计说明书等。

6.可追溯性；由于各开发阶段编制的文档与各阶段完成的工作有着紧密的关系，前后两个阶段生成的文档，随着开发工作的逐步扩展，具有一定的继承关系。在一个项目各开发阶段之间提供的文档必定存在着可追溯的关系。例如，某一项软件需求，必定在设计说明书，测试计划以至用户手册中有所体现。必要时应能做到跟踪追查。3.1瀑布模型（WaterfallModel）可行性研究报告；

项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。计算机软件产品开发文件编制指南（GB8567-88）表1软件生存周期各阶段中的文件编制

原则5：推迟实现的观点（逻辑独立性原则）对于有一定规模的软件，编码越早，完成的时间反而会更长，甚至导致不可挽回的失败。这是为无数事例所证实了的。结构化生命周期法的一个主要的特点就是逻辑设计与物理设计分开，从而大大提高了系统的正确性、可靠性和可维护性。逻辑设计和物理设计分开进行是结构化方法学的一个基本原则。逻辑设计与物理设计分开进行，有利于开发人员更准确地抽象出系统的本质特征和功能，另外逻辑设计所产生的逻辑模型相对比较稳定，按照这种模型所开发的系统具有较好的灵活性和适应性。逻辑模型相对比较稳定物理实现手段具有多样性、多变性

3.1瀑布模型（WaterfallModel）FrederickP.BrooksJr.在《人月神话》中深刻地批评了瀑布模型的错误，他认为：瀑布模型的基本谬误是它假设项目只经历一次过程，而且体系结构出色并且易于使用，设计是合理可靠的。换言之，瀑布模型假设所有的错误发生在编码实现阶段。瀑布模型的第二个谬误是它假设整个系统一次性地被构建，在所有的设计、大部分编码、部分单元测试完成之后，才为闭环的系统测试合并各个部分。

3.1瀑布模型（WaterfallModel）（1）优点阶段的顺序性和依赖性。前一个阶段的完成是后一个阶段工作的前提和依据，而后一阶段的完成往往又使前一阶段的成果在实现过程中具体了一个层次。逐步求精的结构化思路。整个系统的开发乃至每一阶段的工作，体现出“自顶向下、逐步求精”的结构化技术特点。推迟实现的观点。质量保证措施。文档是通讯的手段，是开发工作的依据，也是维护阶段的重要支持信息。每一个阶段对文档的复审，就是对本阶段工作成果的评定，使错误较难传递到下一阶段。错误纠正得越早，所造成的损失就越少。3.1瀑布模型（WaterfallModel）（2）缺点结构化SDLC是一种预先定义需求的方法，也就是说，采用该方法的基本前提是必须能够在早期就冻结用户的需求。因此，该方法只适应于可以在早期阶段就完全确定用户需求的项目。然后在实际中要做到这一点往往是不现实的，用户很难准确地陈述其需求。该方法存在的另一个缺陷是未能很好地解决系统分析到系统设计之间的鸿沟(gap)。通讯是一个主要的问题。该方法文档的编写工作量极大，随着开发工作的进行，这些文档需要及时更新，从而会延长系统的开发周期。虽然目前已有很多CASE工具可以支持这一工作，但仍需要很大程度的人工参与。3.1瀑布模型（WaterfallModel）（3）适用范围结构化SDLC以瀑布模型为基础，按工程学的原理组织和管理信息系统开发。由于结构化SDLC的各阶段之间基本上是一种线性的顺序关系，即前一个阶段的结果是后一阶段的工作基础，因此，结构化SDLC不允许有返工的情况发生。运用瀑布模型的前提是能够早期冻结用户的需求。其适用范围包括：开发早期能够冻结用户需求；组织结构稳定，业务处理过程相对比较规范、成熟、定型的企业信息系统，需求比较明确、稳定；系统规模大、功能与数据关系复杂的大型系统。

3.1瀑布模型（WaterfallModel）2.3.4原型模型（Prototyping）1.快速原型法产生的背景和原因基于瀑布模型的结构化SDLC有很多缺陷，其中最大的一个缺点是运用该方法的前提是需要早期冻结用户的需求，事实上，对于很多应用系统(如商业信息系统)来讲，用户要想在项目开发初期就非常清楚地陈述其需求几乎是不可能的；错误形成的越早，对整个系统的影响越严重等等。而且大量事实表明：用户需求定义方面的错误是信息系统开发中出现的后果最严重的错误，这意味着传统的SDLC方法不允许失败(尤其是早期的！)。那么，为什么要使用原型法呢？原因有以下几方面：为了构造一个工作演示模型以便从用户取得反馈意见。为了得到一个更直观、更形象的东西。为了能及早发现系统开发的难点。2.3.4原型模型

（Prototyping）2.3.4原型模型（Prototyping）2、什么是原型？原型(prototype)即样品、模型的意思。原型分为三类：抛弃式，目的达到即被抛弃，原型不作为最终产品；原型作为标识软件需求的一种机制，原型被建造仅是为了定义需求，之后就该被抛弃（或至少部分抛弃）2.3.4原型模型（Prototyping）演化式，系统的形成和发展是逐步完成的，它是高度动态迭代和高度动态的，每次迭代都要对系统重新进行规格说明、重新设计、重新实现和重新评价，所以是对付变化最为有效的方法，这也是与瀑布开发的主要不同点；增量式，系统是一次一段地增量构造，与演化式原型的最大区别在于增量式开发是在软件总体设计基础上进行的。很显然，其对付变化比演化式差。2.3.4原型模型（Prototyping）做原型的好处：

原型是动态的。

原型有助于开发与用户友好的人机界面。

原型有助于发现需求方面的误解。

原型有助于检验侯选的设计方案。

原型有助于早些提供使用。4原型模型（Prototyping）3.什么是原型法？

快速原型法(RapidPrototyping)是用于开发某种产品或其组成部件的一个小规模工作模型(即原型)所使用的一种非常流行的工程技术。对于信息系统开发而言,快速原型法是指用户的需求被提取、表示，并快速地构造一个最终系统的、具有进化能力的工作模型，并逐步发展和完善该模型。2.3.4原型模型

（Prototyping）Process

ofBuildingExperimentalSystemtoDemonstrate,EvaluateApproach;UsersRefineNeeds.PROTOTYPE:

Preliminaryworkingversionofinformationsystemfordemonstration,evaluationpurposesITERATIVEPROCESS*4、STEPSINPROTOTYPING（1）IDENTIFYUSER’SREQUIREMENTS（2）DEVELOPPROTOTYPE（3）USEPROTOTYPE（4）REVISE&ENHANCEROTOTYPE

2.3.4原型模型

（Prototyping）需求分析

快速设计建立原型

用户评价原型

修改原型

生成产品

BernardBoar于1984年提出的原型法系统开发生命周期

2.3.4原型模型

（Prototyping）原型模型听取用户意见建造/修改原型用户测试运行原型2.3.4原型模型

（Prototyping）5.快速原型法的优缺点快速原型法的优点是：减少了开发时间，大大提高了系统开发效率。这主要是由于最终用户更加积极地参与系统的开发，尤其是信息系统需求的确定。由于用户在看到原型以前往往很难理解和详细陈述其需求，而且用户所看到的是实际的工作模型而不是用单调的语言或图来描述的需求，因此，通过快速原型法使信息需求的定义工作更为直观、简单。通过一系列对原型的修改和完善，大大增加了用户对设计的满意程度,进而提高了信息系统的质量。减少了系统开发费用。2.3.4原型模型（Prototyping）快速原型法的缺点是：分析和设计上的深度不够,从而可能造成在未能很好地理解用户需求的情况下就着手程序代码的编写。快速原型法中的第一个工作原型可能并不是一个最优方案。通过快速原型法所开发的系统不具备灵活性,以适应用户需求的变化。工作原型不见得容易修改。2.3.4原型模型（Prototyping）6.应用快速原型法的前提系统需求在系统开发以前不能准确地加以陈述和说明，用户需求变化较快，无需早期冻结用户需求。有快速的系统建造工具。应用生成器(AG)、第四代生成语言(4GL)、计算机辅助软件工程CASE等，都是原型化方法的有力支持工具。2.3.4原型模型（Prototyping）需要实际的、可供用户参与的系统模型。文字和静态图形是一种比较好的通讯工具，然而其最大缺点是缺乏直观的、感性的特征，因而往往不易理解对象的全部含义。交互式系统能够提供生动活泼的规格说明，用户见到的是一个“活”的、运行着的系统。理解纸面上的系统，操作在机器上运行的系统，其差别是十分显著的。用户能够积极地参与系统的开发。需要有一个原型工作环境。具有一批具有丰富的问题域知识和开发经验的开发人员。2.3.4原型模型（Prototyping）在实际工作中，可以将这两种方法有机地结合在一起使用。运用快速原型法提取用户需求，一旦需求确定后，可以运用结构化SDLC的方法按部就班地开展以后几个阶段的开发工作。2.3小结2.4信息系统开发方法学内容概要：信息系统开发方法学概论结构化方法的基本原理面向对象方法的基本概念和原理结构化方法与面向对象方法的比较方法学：方法学(Methodology)是一组思路、规范、过程、技术、环境及工具的集成，是认识和描述系统的一套完整的思路。软件工程方法为软件开发供了“如何做”的技术，是完成软件工程项目的技术手段.结构化方法学：自顶向下、逐步求精信息工程方法学：面向对象方法学：归纳→演绎[注意]上述方法学既可以按照结构化SDLC的思路来组织软件的开发，也可以按照快速原型法的思路来进行，或者按照其它的软件开发模式进行。2.4信息系统开发方法学不同方法的不同之处主要体现在以下两个方面：⑴对问题空间和求解空间的结构描述方法不同。这种结构主要体现在以下两个方面：构成系统的基本要素不同。例如，结构化方法认为组成系统的基本要素是“过程”（模块）；信息工程方法认为组成系统的基本要素是“数据”；面向对象方法认为组成系统的基本要素为“对象”。系统要素之间的联系方式不同。例如，结构化方法是按“自顶向下、逐步求精”的方法来描述问题空间和求解空间的，；而面向对象方法则是一种“归纳演绎”的过程，即由特殊(通过抽象)一般，一般(通过继承)特殊。因此，面向对象方法一般说通过自底向上的方法来归纳描述问题空间的。2.4信息系统开发方法学⑵分析与设计阶段的过渡方式不同。一种好的、生命力强的信息系统开发方法学的根本就在于所建立的映射是一个“同构关系(Isomorphism)”，通过该同构关系，使问题空间与求解空间之间保持结构上的一致。同构关系的实质是尽可能接近人类的思维方式。映射增量2.4信息系统开发方法学结构化方法学亦称之为面向过程的方法或以过程为驱动的方法(Process-driven)，或数据流建模方法。该方法产生于70七十年代中期，包括三个方面的内容：结构化程序设计SP(StructuredProgramming)、结构化分析SA(StructuredAnalysis)和结构化设计SD(StructuredDesign)。结构化方法(StructuredMethodology)又称为数据流建模方法(DataFlowModelingMethodology)。“结构化”的含义是指“严格的、可重复的、可度量的”。结构化方法是从数据流的角度将业务问题分解为可管理的、相互关联的子问题，然后再将这些子问题的解综合成为整个业务问题解的一系列技术的总称。2.4信息系统开发方法学结构化方法学的原理和思想概括起来就是：自顶向下、逐步求精。模块自顶向下的结构是根据一定的设计原则获得的。模块化设计。所谓模块化设计，即将软件分解为一组尽可能功能独立的模块。模块化原理使得软件结构更加清晰，易理解，易测试，易修改，从而提高了软件的可靠性。另外，模块化也有助于程序从个体化开发方式向集体化开发方式的转化，有助于软件开发工程的组织和管理。信息隐藏。2.4信息系统开发方法学信息工程方法又称面向数据(data-orient方法，是一种根据系统数据的组织和存取来建立系统模型的一种技术。该方法也称之为以数据为驱动的方法(Data-driven)。数据建模技术和信息工程就是该方法的典型代表。该方法的代表性技术和工具有实体关系图(Entity-RelationshipDiagram)，业务域分析(BusinessAreaAnalysis)，信息模型(InformationModel)等。数据建模技术：数据建模技术是在八十年代初期，由于数据库管理系统在企业管理中的作用日益突出的背景下出现的。该技术是从信息(数据)的角度而不是功能(过程)来开发信息系统的。在该技术中，现实世界被描述为是由数据、数据属性及其之间的关系组成的。

2.4信息系统开发方法学信息工程：信息工程IE(InformationEngineering)的倡导者JamesMartin对信息工程的定义是：在一个企业或企业的主要部门中，关于信息系统规划、分析、设计和构成的一套相互关联的、环环紧扣的正规化、自动化技术集合的应用，称为IE。使用这套技术，使用这套技术，使得企业模型、数据模型和业务过程模型在一个综合的知识库中建立起来，用于创建和维护数据处理系统。IE是一种数据驱动的、但同时也强调过程的技术。它首先建立数据模型，然后再建立过程模型。除了将过程建模和数据建模有机地结合起来以外，信息工程更强调系统规划(SystemPlanning)的重要性。

2.4信息系统开发方法学JamesMartin指出，应用信息工程方法的首要前提是：在现代数据处理中，要以数据为中心，数据的存储和管理是通过各种数据系统软件来支持的。数据处理包括：数据的创建、数据的更新、文件的生成、各种综合、分析图表和报表的生成、“What-if”分析和决策、信息检索以及审查。2.4信息系统开发方法学面向对象的分析和设计方法出现于八十年代中期和后期，由于一批面向对象的程序设计语言如SmallTalk、C++、ObjectC以及Eiffel越来越多地被人们用于系统开发中。面向对象方法在解决问题的风范(Paradigm)上是与传统的结构化方法迥然不同。传统的结构化方法遵循结构化、确定性、顺序的风格，而面向对象方法则运用了对象（类）、属性、消息、封装、继承以及多态等概念和机制来描述系统。面向对象方法是一种运用对象、类、继承、封装、聚集、消息传递、多态性等概念来构造系统的软件开发方法。我们认识一个系统是一个渐进的过程，是在继承了以往的有关知识的基础上，多次迭代往复而逐步深化的。在这种认识的深化过程中，即包括了从一般到特殊的演绎，也包括了从特殊到一般的归纳。2.4信息系统开发方法学注意：方法学的产生与发展与计算模式的发展有密不可分的关系。2.4信息系统开发方法学结构化技术的发展历史结构化技术的基本原理结构化技术的组成结构化技术中存在的问题2.4.1结构化方法学1.软件危机（SoftwareCrisis）特征：程序可读性很差、程序的可维护性极差、软件生产率低下原因：程序的结构差、采用自底向上的开发方法、软件越来越复杂2.结构化程序设计SP的产生1966年，Bohn和Jacopini提出了结构化程序设计的理论，其基本思想是：每一个程序都应按照一定的基本结构来组织，这些基本结构包括顺序结构、选择结构和循环结构。结构化程序设计很快成为一种标准。结构化方法的发展历史2.结构化程序设计SP的产生（续）问题：结构化程序设计思路忽略了整个软件的总体结构。未能从全局的角度去考虑软件中各个模块之间的关系，使得用这种方法设计出来的系统缺乏灵活性和可维护性，并且可靠性和效率极差，从而影响了软件系统的质量。结构化方法的发展历史软件工程（SoftwareEngineering）1968年，北大西洋公约组织，FritzBauer提出基本思想：将系统工程的原理运用到软件开发中去，目的是要解决“如何以低成本、按计划、高效率地生产出高质量的软件”，实现软件开发由手工作坊向工程化方向发展。运用系统的、规范的、可定量的方法来开发、运行和维护软件。结构化方法的发展历史3.结构化设计SD（StructuredDesign）结构化设计(StructuredDesign，简称SD)的概念和理论源于结构化程序设计SP。结构化设计最早是在七十年代中期，LarryConstantine在IBMSystemJournal上所发表的一篇奠基性的文章“结构化设计”中提出的。此后，由GlenfordMeyers,EdwardYourdon,MichaelJackson,MeilierJones等人在此基础上进一步发展了这一理论。此后逐步成为一种颇为流行的信息系统开发方法。结构化方法的发展历史4.结构化分析SA（StructuredAnalysis）结构化分析(StructuredAnalysis，简称SA)产生于1975年。结构化分析的提倡者有TomDemarco,ChrisGane,TrishSarson以及EDYourdon等人。所谓结构化分析SA是以过程为中心的、建立系统用户需求模型的技术。结构化分析将系统分解为过程、输入、输出和文件，它为业务问题建立了一种面向输入-处理过程-输出的模型。结构化方法的发展历史结构化技术的成果：将软件开发视之为一项工程，而不仅仅是程序的设计以结构化技术作为软件工程的主要技术。结构化方法的发展历史思路:自顶向下，逐步求精；先整体，再局部结构化方法应遵循以下原则：抽象原则形式化原则分解原则层次组织原则信息隐藏原则模块化原则逻辑独立性原则结构化方法的基本原理原则1——抽象原则抽象(Abstract)是一种忽略与系统目标无关的问题域，从而集中于与当前系统目标有关的问题域的机制。在系统分析与设计中，抽象是为了更好地识别本质的信息系统需求。结构化方法学的三个组成部分；结构化分析、结构化设计、结构化程序设计实际上都是在不同层次上对问题的一种抽象。参见图3.1结构化方法的基本原理结构化系统分析结构化系统设计结构化程序设计结构化方法学发展过程系统开发过程最高级的抽象：问题空间的描述中间级抽象：过程性抽象最低级的抽象：求解方法的实现结构化方法的基本原理原则2——形式化原则形式化原则是指按照某种严格的方法和过程来解决问题。结构化方法的基本原理原则3——分解原则：分而治之(DivideandConquer)原则分解原则是指在求解问题的过程中，将复杂问题分解为一些较小的、比较容易理解的、相对独立的部分来求解，然后再将这些部分问题的解综合成复杂问题的解。例如，在结构化SDLC中，对系统开发过程的管理是采用分解的原则，将整个系统开发过程分解为一系列阶段，每一个阶段还可以进一步分解为一系列活动。在结构化分析中，信息系统过程模型(DFD)的构造采用的方法就是自顶向下、层次分解的方法。在结构化设计中，对软件结构的构造也是采用自顶向下分解的方法，而且这种分解是按层次进行的。结构化方法的基本原理原则4——层次组织原则层次组织原则是指将问题的解用树状的层次结构组织起来。层次组织原则与分解原则是两个相关的原则。结构化方法的基本原理原则5——信息隐藏原则(InformationHiding)该原则是结构化方法的主要成果之一。结构化方法学和面向对象方法学都支持信息屏蔽的原则，只不过支持的方式和名称不同而已。在面向对象方法学中，这一原则被称为“封装”。在结构化方法学中，信息屏蔽是将模块视为一个“黑箱(BlackBox)”，包含在模块内部的信息对于无需这些信息的其它模块来说是不可存取的，即不需要的信息都屏蔽起来，只允许模块知道它本身所需要的信息。结构化方法的基本原理原则5——信息隐藏原则(InformationHiding)——续优点：通过信息屏蔽，可以将问题和错误局部化，因此即使某个模块出现错误，该错误也不会影响其它的模块，即避免了错误的传播性，从而进一步提高了软件的可维护性。结构化方法的基本原理原则6——模块化原则模块化是分解原则在结构化设计中应用的结果。模块化就是将程序分解成若干个模块，每一个模块完成一个子功能，把这些模块集成起来组成一个整体，就可以完成程序指定的功能。因此，模块化原则实际上是分而治之、逐步求精思想的具体应用。结构化方法的基本原理模块化原则的优点：采用模块化原则设计的软件结构清晰，容易设计。由于每一个模块都对应单一独立的程序功能，每个模块都可独立测试，因此，按模块化原则设计的软件也容易测试和调试，从而有助于提高软件的可靠性和可维护性。另外，模块化也有助于软件开发工程的组织管理，一个复杂的程序可以分解为许多模块，而这些模块又具有一定的独立性，所以，可以由许多程序员分工编写不同的模块。结构化方法的基本原理原则7——逻辑独立性原则逻辑设计和物理设计分开进行是结构化方法学的一个基本原则。逻辑设计与物理设计分开进行，有利于开发人员更准确地抽象出系统的本质特征和功能。逻辑设计所产生的逻辑模型相对比较稳定，按照这种模型所开发的系统具有较好的灵活性和适应性。物理实现的手段具有多样性，遵循该原则，也可以使软件的实现具有充分的选择余地。结构化方法的基本原理结构化分析，简称SA结构化设计，简称SD结构化程序设计，简称SP

结构化方法的组成结构化分析，简称SA结构化分析认为系统模型是由一系列数据流程图(DFD)组成的。这些数据流程图只显示了数据、数据的存贮以及进行数据变化的过程。由于数据流程图描述了过程之间的数据流，因此，结构化分析也称之为数据流方法(DataFlowApproach)。另一方面，许多专家都认为DFD是一种过程模型(ProcessModel)，因此，结构化分析实际上是一种面向过程的方法。

结构化方法的组成结构化分析，简称SA（续）结构化分析成为八十年代广泛流行的系统开发技术。其工具—数据流程图具有容易构造、容易理解的优点。但另一方面，数据流程图和结构化分析本身不能保证“业务和用户需求定义”的完整性、一致性和准确性；而且数据流程图的构造大大延缓了系统分析的过程，尤其在强调生产率的今天，这一问题更为突出。

结构化方法的组成结构化设计，简称SD所谓结构化设计是对于一个清楚陈述的问题(well-statedproblem)，选择和组织模块和模块接口，从而求得所述问题的“最优”解(EdwardYourdon)。也就是说，结构化设计是运用一组标准的准则和工具帮助系统设计员确定软件系统是由哪些模块组成的，这些模块用什么方法联结在一起，才能构成一个最优的软件系统结构。结构化设计更强调软件总体结构的设计，是一种自顶向下的设计策略。

结构化方法的组成结构化程序设计，简称SP

结构化方法的组成结构化分析数据流程图DFD数据字典过程描述：结构化英语、判定树/判定表数据存取图结构化设计

结构图伪码系统流程图结构化程序设计

程序流程图N-S图(又称盒图)PAD图结构化方法的工具两种典型的结构化方法：①面向数据流（过程）的方法：Yourdon的结构化设计方法Gane/Sersor结构化分析方法Demarco结构化分析方法②面向数据结构的方法Jackson方法Warnier/Orr方法

典型的结构化方法

对问题域的认识和描述不是以问题域中固有的事物作为基本单位，而是打破了事物之间的界限，在全局范围内以功能、数据或数据流为中心进行分析。因此，该方法容易隐蔽一些对问题理解的偏差，与后续开发阶段的衔接也比较困难。分析文档（数据流程图）与设计文档（软件结构图）是两种不同的表示体系，从而造成分析与设计之间的鸿沟——致命的缺陷 在软件维护、软件重用方面效果并不理想适用范围：并不是所有的系统都是以过程为中心的！开发周期长，导致系统寿命短。

结构化方法的不足面向对象技术的发展历史面向对象技术的基本概念2.4.2面向对象方法什么是面向对象？Objectmodelingisatechniqueforidentifyingobjectswithinthesystemsenvironment,andtherelationshipsbetweenthoseobjects.面向对象建模是一种识别系统内对象及其之间相互关系的技术。什么是面向对象？“面向对象是一种风范（Paradigm），是观察和分析问题的一种方法论（Methodology）。对象技术是一种软件系统组织和结构设计的工程技术，它将对象作为软件系统结构的基本组成单元，以主体数据为中心，将数据及其上作用的操作加以封装，以标准的接口规范对外提供服务。基于这样的方法论，人们可以用自然的方式认识和模拟现实世界，并由此带来软件制造方式的根本变化。人工集约生产方式向资源集约生产方式的转变。

——《对象技术导论》什么是面向对象？“面向对象是一种运用对象、类、继承、封装、聚合、消息传递、多态性等概念来构造系统的软件开发方法。

——《面向对象的系统分析》面向对象方法的特点出发点：问题域中的对象作为系统的基本构成单元对象具有静态特征（属性）和动态特征（服务）对象的属性与服务被封装为一个独立的实体，对外屏蔽其内部细节。对事物进行分类（分类结构）继承机制消息通信机制：对象之间的动态联系是通过消息的传递实现的。什么是面向对象？总而言之：面向对象是认识和描述系统（问题域、实现域即软件系统）的一种方法学。该方法认为，系统是由一系列相互联系、相互作用的对象组成的。因此，所谓用面向对象方法认识和描述系统，就是分析系统（问题域、实现域即软件系统）中是由哪些对象组成的？这些对象之间的联系是什么。为什么要面向对象？面向对象方法学产生的根本原因还在于解决“软件危机”。有学者在研究、分析软件危机产生的原因时曾指出(汪成为[1])：“用冯诺依曼机所求解的问题的问题空间结构与冯诺依曼机所用的求解问题方法的方法空间结构不一致”，这是导致软件危机产生的主要原因。这种不一致主要表现在以下几个方面：为什么要面向对象？⒈问题空间与求解空间不一致⑴语言的鸿沟这是指用来解决问题的求解语言即计算机语言与人类自然语言之间的距离较远。客观世界是由实体组成的，客观实体之间的多种多样的联系构成了五彩缤纷的客观世界，因此人类认识客观世界首先是从概念以及概念之间的联系出发的，概念反映了客观存在的实体，联系反映了实体之间的以来关系，是实体赖以生存的方式。语言反映了人们解决问题的方式。传统的面向过程的语言是由一组数据和一组能动的过程即进程组成的，它所用的概念显然与人类认识客观世界所用的概念相去甚远，是一种难以理解的语言。而面向对象方法学由于在问题空间和求解空间上所采用的概念是完全一致的，因而面向对象方法学所采用的语言更接近于自然语言。为什么要面向对象？⒈问题空间与求解空间不一致⑵冯诺依曼机与问题域(用户)之间的鸿沟汪成为等曾指出：传统的计算机虽然也有各种各样的体系结构，但从根本上改变冯.诺依曼机的基本特征，即顺序地执行指令，按地址访问线形的存储空间，数据和指令在机器内部采用统一的表示形式，以及数字计算。对于用户来讲，这种机器(裸机)的功能是很有限和很不直观的。为了满足用户的需求，就在裸机上利用软件来构造不同层次的虚拟机，每一层虚拟机都可以看作是一种语言的翻译器或解释器，用这种方法来填补用户和裸机之间的鸿沟。但虚拟机的层次越多，软件的开销就越大，可靠性和可维护性就越低。为什么要面向对象？各层虚拟机鸿沟冯.诺依曼机用户

冯.诺依曼机和用户之间的鸿沟

为什么要面向对象？⒉系统分析到系统设计的过渡困难系统分析向系统设计的过渡困难是传统的结构化方法的另一困难。传统的结构化方法中，系统分析模型是为了解决系统分析员与用户之间的通讯问题，而系统设计模型是为了解决系统分析员与程序员之间的通讯问题，由分析向设计的过渡是一件非常困难的事情。关于系统分析向系统设计过渡的问题，文献中都作过详细的讨论。很多研究者都认为，在面向对象方法中，不存在分析与设计的过渡问题。其主要原因是系统分析向系统设计过渡是一个渐进的、逐步细化的过程，因此系统分析师、用户、程序员从系统分析到系统设计、编码、测试和实施过程中自始自终讨论的是一个模型。所生成的信息系统可以逆向推导出系统的原模型。但是也有学者提出相反的观点，例如有人认为：很多面向对象方法的支持者将从面向对象的需求到面向对象的设计的过渡描述为简明的过渡。事实上面向对象的分析与面向对象的设计之间存在难以置信的差别，二者之间的过渡不是也不应是简单的。为什么要面向对象？⒊过程模型和数据模型分别建立，并且忽视了信息系统的行为特征传统的结构化方法学存在的第三个问题是在建立系统模型时，是从功能和数据两个不同的角度分别来构造的，这样产生的一个突出的问题是所建立的过程模型和数据模型可能存在不一致性，并且忽视了信息系统的第三个重要特征，即行为。但是在现代的信息系统中，信息系统的第三个特征—行为(behavior)日显重要，也同样需要建立关于行为的模型。另外，在传统方法中，信息系统的功能模型和数据模型是分别建立的，无论是系统分析师还是最优秀的CASE软件均无法完整地检查和纠正两个模型集成后所存在的不一致性和不准确