第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軟件均無法完整地檢查和糾正兩個模型集成后所存在的不一致性和不準確