UML系統(tǒng)建模及系統(tǒng)分析與設(shè)計(jì)課件第1章 面向?qū)ο筌浖_發(fā)方法

第1章面向?qū)ο筌浖_發(fā)方法教學(xué)目的⑴了解軟件的發(fā)展和軟件工程的概念。⑵了解軟件開發(fā)的常用方法。⑶重點(diǎn)掌握面向?qū)ο蠹夹g(shù)的基本概念和開發(fā)過程。⑷了解幾種典型的面向?qū)ο箝_發(fā)方法。⑸了解可行性研究方法。⑹掌握可行性分析報(bào)告的書寫格式。1.1軟件發(fā)展與軟件工程軟件是一種特別的產(chǎn)品，隨著其規(guī)模和復(fù)雜性的進(jìn)步及應(yīng)用領(lǐng)域的擴(kuò)大，逐漸形成了工程。軟件（software）是計(jì)算機(jī)系統(tǒng)中與硬件（hardware）相互依存的另一部分，它包括程序（program）、相關(guān)數(shù)據(jù)（data）及其說明文檔（document）。1.1軟件發(fā)展與軟件工程軟件工程（SoftwareEngineering，簡稱為SE）是針對軟件這一具有特殊性質(zhì)的產(chǎn)品的工程化方法。軟件工程涵蓋了軟件生存周期的所有階段，并提供了一整套工程化的方法來指導(dǎo)軟件人員的開發(fā)工作。1.1.1軟件的發(fā)展與特征1.軟件的發(fā)展階段軟件發(fā)展的歷史可以大致分為如下的四個(gè)階段：第一個(gè)階段（20世紀(jì)50年代到60年代）是程序設(shè)計(jì)階段，基本是個(gè)體手工勞動的生產(chǎn)方式。20世紀(jì)50年代，軟件伴隨著第一臺電子計(jì)算機(jī)的問世誕生了。以寫軟件為職業(yè)的人也開始出現(xiàn)，他們多是經(jīng)過訓(xùn)練的數(shù)學(xué)家和電子工程師。20世紀(jì)60年代美國大學(xué)開始有計(jì)算機(jī)專業(yè)，專門教人們寫軟件。早期的軟件開發(fā)也沒有什么系統(tǒng)的方法可以遵循，軟件設(shè)計(jì)是在某個(gè)人的頭腦中完成的一個(gè)隱藏的過程。1.1.1軟件的發(fā)展與特征1.軟件的發(fā)展階段第一個(gè)階段嚴(yán)格來說這個(gè)時(shí)期尚無軟件的概念，基本上只有程序、程序設(shè)計(jì)概念，不重視程序設(shè)計(jì)方法。軟件主要是用于科學(xué)計(jì)算，規(guī)模很小，采用簡單的工具（基本上采用低級語言），硬件的存儲容量小，運(yùn)行可靠性差。20世紀(jì)中期，盤算機(jī)從軍用領(lǐng)域轉(zhuǎn)向民用領(lǐng)域應(yīng)用，那時(shí)編寫程序的工作被視為藝術(shù)家的創(chuàng)作。第一階段的主要特征是：⑴程序設(shè)計(jì)只是一個(gè)隱含在開發(fā)者頭腦中的過程，程序設(shè)計(jì)的結(jié)果，除了程序流程圖和源程序清單可以留下來之外沒有任何其他形式的文檔資料保留下來。⑵此時(shí)只有程序的概念，沒有軟件的概念。⑶主要采用匯編語言，甚至是機(jī)器語言，以解決計(jì)算機(jī)內(nèi)存容量不夠和運(yùn)算速度太低的矛盾。由于過分追求編程技巧，程序設(shè)計(jì)被視為某個(gè)人的神秘技巧，程序除作者本人外，其他人很難讀懂。1.軟件的發(fā)展階段第二階段（20世紀(jì)60年代到70年代）是軟件設(shè)計(jì)階段，采取小組合作生產(chǎn)方式。這一時(shí)期盤算機(jī)的利用領(lǐng)域得到進(jìn)一步擴(kuò)大，對軟件系統(tǒng)的需求和軟件自身的復(fù)雜度急劇上升，傳統(tǒng)的開發(fā)方法無法適應(yīng)用戶在質(zhì)量、效率等方面對軟件的需求。人們?yōu)閿[脫匯編語言和機(jī)器語言編程的困難，相繼研制出了一批高級程序設(shè)計(jì)語言，大大加速了計(jì)算機(jī)應(yīng)用普及的步伐，各種類型的應(yīng)用程序相繼出現(xiàn)。1.軟件的發(fā)展階段第二階段軟件開始作為一種產(chǎn)品被廣泛使用，出現(xiàn)了“軟件作坊”?！斑@個(gè)階段的開發(fā)成本令人吃驚地高，而失敗的軟件開發(fā)項(xiàng)目卻屢見不鮮。最為突出的例子是美國IBM公司于1963年～1966年開發(fā)的IBM360系列機(jī)的操作系統(tǒng)。IBM360操作系統(tǒng)的歷史教訓(xùn)已成為軟件開發(fā)項(xiàng)目中的典型事例被記入歷史史冊。“軟件危機(jī)”就這樣開始了?！败浖C(jī)”“軟件危機(jī)”使得人們開始對軟件及其特性進(jìn)行更深一步的研究，人們改變了早期對軟件的不正確看法。早期那些被認(rèn)為是優(yōu)秀的程序常常很難被別人看懂，通篇充滿了程序技巧。為解決這個(gè)問題，1968年秋季NATO（北大西洋公約組織）的科技委員會召集了近50名一流的編程人員、計(jì)算機(jī)科學(xué)家和工業(yè)界巨頭討論并制定擺脫“軟件危機(jī)”的對策。在聯(lián)邦德國召開的這次國際學(xué)術(shù)會議上第一次提出了“軟件危機(jī)”（softwarecrisis）。“軟件危機(jī)”軟件危機(jī)指的是在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。概括來說，軟件危機(jī)包含兩方面問題：一是如何開發(fā)軟件，以滿足日益增長，日趨復(fù)雜的需求；二是如何維護(hù)數(shù)量不斷膨脹的軟件產(chǎn)品。第二階段階段的主要特征⑴由于程序的規(guī)模增大，程序設(shè)計(jì)已不可能由個(gè)人獨(dú)立完成，而需要多人分工協(xié)作。軟件的開發(fā)方式由“個(gè)體生產(chǎn)”發(fā)展到“小組軟件作坊”。⑵程序的運(yùn)行、維護(hù)也不再由一個(gè)人來承擔(dān)，而是由開發(fā)小組承擔(dān)。⑶程序已不再是計(jì)算機(jī)硬件的附屬成份，而是計(jì)算機(jī)系統(tǒng)中與硬件相互依存、共同發(fā)揮作用的不可缺少的部分。在計(jì)算機(jī)系統(tǒng)的開發(fā)過程中，起主導(dǎo)作用的已經(jīng)不僅僅是硬件工程師，同時(shí)也包括軟件工程師。1.軟件的發(fā)展階段第三個(gè)階段（20世紀(jì)70年代到90年代）采用工程化的生產(chǎn)方式，是傳統(tǒng)軟件工程階段。微處理器的出現(xiàn)與應(yīng)用使個(gè)人計(jì)算機(jī)發(fā)展迅速，這個(gè)階段的硬件向超高速、大容量、微型化以及網(wǎng)絡(luò)化方向發(fā)展。軟件系統(tǒng)的規(guī)模、復(fù)雜性增強(qiáng)，促進(jìn)了軟件開發(fā)過程管理及工程化。這個(gè)時(shí)期還包括開發(fā)、使用和維護(hù)過程所需的文檔。軟件開發(fā)范圍從需求定義、分析、設(shè)計(jì)、編碼、測試、使用到維護(hù)等整個(gè)軟件生命周期。第三階段的主要特征⑴軟件產(chǎn)業(yè)已經(jīng)興起，“軟件作坊”已經(jīng)發(fā)展為軟件公司，甚至是跨國公司。⑵軟件開發(fā)的成功率大大提高，軟件的質(zhì)量也有了很大的保證。軟件已經(jīng)產(chǎn)品化、系列化、標(biāo)準(zhǔn)化、工程化。⑶軟件工程并發(fā)環(huán)境及其相應(yīng)的集成工具大量涌現(xiàn)，軟件開發(fā)技術(shù)中的度量問題受到重視1.軟件的發(fā)展階段第四階段（20世紀(jì)90年代至今）是現(xiàn)代軟件工程階段。數(shù)據(jù)庫、開發(fā)工具、開發(fā)環(huán)境、網(wǎng)絡(luò)、分布式、面向?qū)ο蠹夹g(shù)等工具方法都得到應(yīng)用。Internet技術(shù)的迅速發(fā)展使得軟件系統(tǒng)從封閉走向開放，Web應(yīng)用成為人們在Internet上最主要的應(yīng)用模式，異構(gòu)環(huán)境下分布式軟件的開發(fā)成為一種主流需求，軟件復(fù)用和構(gòu)件技術(shù)成為技術(shù)熱點(diǎn)。第四階段的主要特征：⑴面向?qū)ο蠹夹g(shù)廣泛使用。⑵軟件開發(fā)技術(shù)逐漸成熟。這個(gè)時(shí)代的主流應(yīng)用技術(shù)采用面向?qū)ο蠹夹g(shù)、軟件復(fù)用技術(shù)（設(shè)計(jì)模式、軟件框架、軟件體系結(jié)構(gòu)等）、構(gòu)件設(shè)計(jì)技術(shù)、分布式計(jì)算技術(shù)、軟件過程管理技術(shù)等。2.軟件的特征軟件同傳統(tǒng)的工業(yè)產(chǎn)品相比，有其獨(dú)特的特性。⑴軟件是一種邏輯實(shí)體，具有抽象性。⑵軟件沒有明顯的制造過程。⑶軟件在使用過程中，沒有磨損、老化的問題。當(dāng)修改的成本變得難以接受時(shí)，軟件就被拋棄。⑷軟件對硬件和環(huán)境有著不同程度的依賴性，這就導(dǎo)致了軟件移植的問題。2.軟件的特征⑸軟件的開發(fā)至今尚未完全擺脫手工作坊式的開發(fā)方式，生產(chǎn)效率低。⑹軟件是復(fù)雜的，而且以后會更加復(fù)雜。⑺軟件的成本相當(dāng)昂貴。軟件開發(fā)需要投入大量的、高強(qiáng)度的腦力勞動，成本非常高，風(fēng)險(xiǎn)也大?，F(xiàn)在軟件的開銷已大大超過了硬件的開銷。⑻軟件工作牽涉到很多社會因素。人的因素，常常成為軟件開發(fā)的困難所在，直接影響到項(xiàng)目的成敗。1.1.2軟件工程軟件工程的方法就是基于軟件危機(jī)的問題提出來的。大型的、復(fù)雜的軟件系統(tǒng)開發(fā)是一項(xiàng)工程，必須按工程學(xué)的方法組織軟件的生產(chǎn)和管理，必須經(jīng)過系統(tǒng)的分析、設(shè)計(jì)、實(shí)現(xiàn)、測試和維護(hù)等一系列的軟件生命周期階段。這一認(rèn)識促使了軟件工程學(xué)的誕生。1.軟件工程的概念與知識體系軟件工程是一門研究如何用系統(tǒng)化、規(guī)范化、數(shù)量化等工程原則和方法去進(jìn)行軟件的開發(fā)和維護(hù)的學(xué)科。軟件工程包括兩方面內(nèi)容：軟件開發(fā)技術(shù)和軟件項(xiàng)目管理。軟件開發(fā)技術(shù)包括軟件開發(fā)方法學(xué)、軟件工具和軟件工程環(huán)境。軟件項(xiàng)目管理包括軟件度量、項(xiàng)目估算、進(jìn)度控制、人員組織、配置管理、項(xiàng)目計(jì)劃等。軟件工程的三要素是方法、工具和過程。軟件工程應(yīng)該包括的知識IEEE的軟件工程實(shí)施體系指南SEWBOK（GuidetotheSoftwareEngineeringBodyofKnowledge2004Version）界定了軟件工程的10個(gè)知識領(lǐng)域（KAs：KnowledgeAreas），即軟件需求、軟件設(shè)計(jì)、軟件構(gòu)建、軟件測試、軟件維護(hù)、軟件配置管理、軟件工程管理、軟件工程過程、軟件工程工具和方法及軟件質(zhì)量。軟件工程知識體系指南（2004）知識域內(nèi)容軟件需求軟件需求基礎(chǔ)、需求過程、需求獲取、需求分析、需求規(guī)格說明、需求確認(rèn)和實(shí)踐考慮軟件設(shè)計(jì)軟件設(shè)計(jì)基礎(chǔ)、軟件設(shè)計(jì)關(guān)鍵問題、軟件結(jié)構(gòu)與體系結(jié)構(gòu)、軟件設(shè)計(jì)質(zhì)量的分析與評價(jià)、軟件設(shè)計(jì)符號、軟件設(shè)計(jì)的策略與方法軟件構(gòu)造軟件構(gòu)造基礎(chǔ)、管理構(gòu)造、實(shí)際考慮軟件測試軟件測試基礎(chǔ)和測試級別、測試技術(shù)、與測試相關(guān)的度量、測試過程軟件工程知識體系指南（2004）知識域內(nèi)容軟件維護(hù)軟件維護(hù)基礎(chǔ)、軟件維護(hù)的關(guān)鍵問題、維護(hù)過程、維護(hù)技術(shù)軟件配置管理軟件配置管理過程管理、軟件配置標(biāo)志、軟件配置控制、軟件配置狀態(tài)統(tǒng)計(jì)、軟件配置審核、軟件發(fā)行管理和交付軟件工程管理啟動和范圍定義、軟件項(xiàng)目計(jì)劃、軟件項(xiàng)目實(shí)施、評審與評價(jià)、關(guān)閉、軟件工程度量軟件工程過程過程實(shí)施與改變、過程定義、過程評定、過程和產(chǎn)品度量軟件工程工具和方法軟件工程工具、軟件工程方法軟件質(zhì)量軟件質(zhì)量基礎(chǔ)、軟件質(zhì)量過程、實(shí)踐考慮相關(guān)學(xué)科計(jì)算機(jī)工程、計(jì)算機(jī)科學(xué)、管理、數(shù)學(xué)、項(xiàng)目管理、質(zhì)量管理、軟件人類工程學(xué)和系統(tǒng)工程

2.軟件工程的框架軟件工程的框架由軟件工程目標(biāo)、軟件工程活動和軟件工程原則三個(gè)方面的內(nèi)容構(gòu)成。開發(fā)范型設(shè)計(jì)方法支持過程管理過程需求設(shè)計(jì)實(shí)現(xiàn)確認(rèn)支持可用性正確性合算性軟件工程活動維軟件工程目標(biāo)維軟件工程原則維圖1.軟件工程框架軟件工程的目標(biāo)是開發(fā)與生產(chǎn)出具有良好的軟件質(zhì)量和費(fèi)用合算的產(chǎn)品，即生產(chǎn)具有正確性、可用性以及合算的軟件產(chǎn)品。正確性是指軟件產(chǎn)品達(dá)到預(yù)期功能的程度?？捎眯允侵杠浖窘Y(jié)構(gòu)、實(shí)現(xiàn)及文檔為用戶可用的程度。費(fèi)用合算是指軟件開發(fā)運(yùn)行的整個(gè)開銷能滿足用戶要求的程度。軟件質(zhì)量是指該軟件能滿足明確的和隱含的需求能力有關(guān)特征和特性的總和。軟件工程活動包括需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)和支持。需求包括問題分析和需求分析。問題分析包括需求獲取和定義，又稱軟件需求規(guī)約。需求分析包括生成軟件功能規(guī)約。設(shè)計(jì)包括概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)。實(shí)現(xiàn)就是把設(shè)計(jì)結(jié)果轉(zhuǎn)換為可執(zhí)行的程序代碼。確認(rèn)貫穿整個(gè)開發(fā)過程，對完成的結(jié)果進(jìn)行確認(rèn)，保證產(chǎn)品滿足用戶的要求。支持是修改和完善活動。軟件工程的原則⑴選取適宜開發(fā)范型。該原則與系統(tǒng)設(shè)計(jì)有關(guān)，在系統(tǒng)設(shè)計(jì)中，軟件需求、硬件需求以及其他因素之間是相互制約、相互影響的，經(jīng)常需要權(quán)衡。因此，必須認(rèn)識需求定義的易變性，采用適宜的開發(fā)范型予以控制，以保證軟件產(chǎn)品滿足用戶的要求。⑵采用合適的設(shè)計(jì)方法。在軟件設(shè)計(jì)中，通常要考慮軟件的模塊化、抽象與信息隱蔽、局部化、一致性以及適應(yīng)性等特征。合適的設(shè)計(jì)方法有助于這些特征的實(shí)現(xiàn)，以達(dá)到軟件工程的目標(biāo)。軟件工程的原則⑶提供高質(zhì)量的工程支持?！肮び破涫拢叵壤淦鳌?。在軟件工程中，軟件工具與環(huán)境對軟件過程的支持頗為重要。軟件工程項(xiàng)目的質(zhì)量與開銷直接取決于對軟件工程所提供的支撐質(zhì)量和效用。⑷重視開發(fā)過程的管理。軟件工程的管理，直接影響可用資源的有效利用、生產(chǎn)滿足目標(biāo)的軟件產(chǎn)品和提高軟件組織的生產(chǎn)能力等問題。因此，僅當(dāng)軟件過程得以有效管理時(shí)，才能實(shí)現(xiàn)有效的軟件工程。軟件工程的框架軟件工程的目標(biāo)是可用性、正確性和合算性軟件工程活動主要包括需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)和支持等活動，每一活動可根據(jù)特定的軟件工程，采用合適的開發(fā)范型、設(shè)計(jì)方法、支持過程以及過程管理。3.軟件工程的基本原理⑴用分階段的生命周期計(jì)劃嚴(yán)格管理⑵堅(jiān)持進(jìn)行階段評審。⑶實(shí)行嚴(yán)格的產(chǎn)品控制。⑸結(jié)果應(yīng)能清楚地審查。⑹開發(fā)小組的人員應(yīng)該少而精。1.2軟件過程和開發(fā)方法1.2.1軟件過程軟件過程是為了獲得高質(zhì)量的軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。軟件過程描述了為了開發(fā)出客戶滿意的軟件，什么人（who）、在什么時(shí)候（when）、做什么事（what）以及怎么做（how）這些事以實(shí)現(xiàn)某一個(gè)特定的具體目標(biāo)。通常用生命周期模型簡潔地描述軟件過程。1.2軟件過程和開發(fā)方法1.2.1軟件過程生命周期模型規(guī)定了把生命周期劃分成哪些階段及各階段的執(zhí)行順序，因此，稱為軟件過程模型，又稱為軟件開發(fā)模型。軟件開發(fā)模型是指軟件開發(fā)中的所有過程、活動和任務(wù)的結(jié)構(gòu)框架，它能清晰、明確地表達(dá)軟件開發(fā)的全過程軟件開發(fā)通常包括需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)和支持等階段。常見的軟件過程模型有瀑布模型快速原型模型增量模型螺旋模型噴泉模型此外還有迭代模型、V模型和智能模型等。1.瀑布模型1970年溫斯頓·羅伊斯（WinstonRoyce）提出了著名的“瀑布模型（WaterfallModel）”，它有時(shí)也稱為傳統(tǒng)生存周期模型或線性順序過程模型。20世紀(jì)80年代之前，它一直是唯一被廣泛采用的軟件開發(fā)模型，現(xiàn)在它仍然是軟件工程中應(yīng)用最廣泛的過程模型之一。傳統(tǒng)軟件工程方法學(xué)的軟件過程，基本上可以用瀑布模型來描述。瀑布模型將軟件生命周期劃分為軟件計(jì)劃、需求分析、系統(tǒng)設(shè)計(jì)、軟件編寫、軟件測試和運(yùn)行維護(hù)等六個(gè)基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。瀑布模型制定計(jì)劃驗(yàn)證系統(tǒng)設(shè)計(jì)驗(yàn)證程序編碼測試綜合測試需求分析驗(yàn)證系統(tǒng)維護(hù)傳統(tǒng)的瀑布模型瀑布模型的主要特點(diǎn)：⑴階段間具有順序性和依賴性。⑵推遲實(shí)現(xiàn)的觀點(diǎn)。⑶質(zhì)量保證的觀點(diǎn)。瀑布模型在實(shí)現(xiàn)之前無法了解項(xiàng)目的實(shí)際情況，只有實(shí)現(xiàn)了才知道項(xiàng)目的情況。及時(shí)驗(yàn)證是保證軟件質(zhì)量、降低軟件成本的重要措施。實(shí)際的瀑布模型——帶反饋環(huán)制定計(jì)劃驗(yàn)證系統(tǒng)設(shè)計(jì)驗(yàn)證程序編碼測試綜合測試需求分析驗(yàn)證系統(tǒng)維護(hù)變化的需求驗(yàn)證瀑布模型的優(yōu)點(diǎn)⑴嚴(yán)格地規(guī)定了每項(xiàng)活動必須提交的文檔?？梢詮?qiáng)迫開發(fā)人員采用規(guī)范的開發(fā)方法。⑵為項(xiàng)目提供了按活動劃分的檢查點(diǎn)。每項(xiàng)活動交出的產(chǎn)品必須經(jīng)過質(zhì)量保證小組的仔細(xì)驗(yàn)證，這樣可以保證軟件的開發(fā)質(zhì)量。⑶當(dāng)前一階段完成后，您只需要去關(guān)注后續(xù)階段。瀑布模型的缺點(diǎn)：⑴各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。⑵由于開發(fā)模型是線性的，用戶只有等到整個(gè)過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風(fēng)險(xiǎn)。⑶早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進(jìn)而帶來嚴(yán)重的后果。瀑布模型是線性的，“線性”是人們最容易掌握并能熟練應(yīng)用的思想方法。當(dāng)人們碰到一個(gè)復(fù)雜的“非線性”問題時(shí)，總是千方百計(jì)地將其分解或轉(zhuǎn)化為一系列簡單的線性問題，然后逐個(gè)解決。2.快速原型模型快速原型模型（RapidPrototypeModel）的第一步就是根據(jù)用戶提出的需求，由用戶與開發(fā)者共同確定系統(tǒng)的基本要求和主要功能，并在較短時(shí)間內(nèi)建立一個(gè)實(shí)驗(yàn)性的、簡單的小型系統(tǒng)，稱作“快速原型”。第二步就是將原型交給用戶使用，用戶在使用原型的過程中會產(chǎn)生新的需求，開發(fā)人員依據(jù)用戶提出的評價(jià)意見對快速原型進(jìn)行不斷的修改、補(bǔ)充和完善。如此不斷地迭代，直至開發(fā)出客戶滿意的軟件產(chǎn)品。2.快速原型模型原型快速分析構(gòu)造運(yùn)行評價(jià)3.增量模型增量模型（IncrementalModel）又稱為演化模型。這種模型融合了瀑布模型的基本成份和快速原型的迭代特征。分析設(shè)計(jì)編碼測試增量1分析設(shè)計(jì)編碼測試增量2分析設(shè)計(jì)編碼測試增量3分析設(shè)計(jì)編碼測試增量4增量模型3.增量模型增量模型也存在以下缺陷：⑴由于各個(gè)構(gòu)件是逐漸并入已有的軟件體系結(jié)構(gòu)中的，要求加入構(gòu)件必須不破壞已構(gòu)造好的系統(tǒng)部分，這需要軟件具備開放式的體系結(jié)構(gòu)。⑵在開發(fā)過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應(yīng)這種變化的能力大大優(yōu)于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。4.螺旋模型1988年BarryBoehm正式提出了軟件系統(tǒng)開發(fā)的“螺旋模型（SpiralModel）”，“螺旋模型”將瀑布模型和快速原型模型結(jié)合起來，它強(qiáng)調(diào)了其它模型所忽視的風(fēng)險(xiǎn)分析，特別適合于大型復(fù)雜的系統(tǒng)。4.螺旋模型5.噴泉模型噴泉模型（fountainmodel）也稱面向?qū)ο蟮纳嫫谀Ｐ?，OO模型。噴泉模型與傳統(tǒng)的結(jié)構(gòu)化生存期模型比較，具有更多的增量和迭代性質(zhì)，生存期的各個(gè)階段可以相互重疊和多次反復(fù)，而且在項(xiàng)目的整個(gè)生存期中還可以嵌入子生存期。就像水噴上去又可以落下來，可以落在中間，也可以落在最底部。5.噴泉模型分析設(shè)計(jì)實(shí)現(xiàn)維護(hù)演化噴泉模型6.智能模型智能模型也稱為“基于知識的軟件開發(fā)模型”，它把瀑布模型和專家系統(tǒng)結(jié)合在一起，利用專家系統(tǒng)來幫助軟件開發(fā)人員工作。該模型應(yīng)用基于規(guī)則的系統(tǒng)，采用歸納和推理機(jī)制，幫助軟件人員完成開發(fā)工作，并使維護(hù)在系統(tǒng)規(guī)格說明一級進(jìn)行。智能模型以知識作為處理對象，這些知識既有理論知識，也有特定領(lǐng)域的經(jīng)驗(yàn)。6.智能模型空間、屬性數(shù)據(jù)GIS系統(tǒng)數(shù)據(jù)黑板狀態(tài)黑板結(jié)論黑板推理機(jī)數(shù)據(jù)轉(zhuǎn)換器模型運(yùn)行體智能模型運(yùn)行池決策請求人機(jī)交互信息分析結(jié)果GIS數(shù)據(jù)庫模型庫知識庫接口統(tǒng)一的模型知識模型數(shù)據(jù)圖1.智能模型樣圖6.智能模型需求分析知識獲取和表示推理機(jī)制體系結(jié)構(gòu)設(shè)計(jì)軟件原型系統(tǒng)軟件實(shí)現(xiàn)知識庫/專家系統(tǒng)智能模型智能模型特點(diǎn)智能模型擁有一組工具（如數(shù)據(jù)查詢、報(bào)表生成、數(shù)據(jù)處理、屏幕定義、代碼生成、高層圖形功能及電子表格等這種方法需要四代語言（4GL）的支持。它以瀑布模型為基本框架，在不同開發(fā)階段引入了原型實(shí)現(xiàn)方法和面向?qū)ο蠹夹g(shù)以克服瀑布模型的缺點(diǎn)，適應(yīng)于特定領(lǐng)域的軟件和專家決策系統(tǒng)的開發(fā)。7.V模型V模型是軟件開發(fā)瀑布模型的變種，主要反映測試活動與分析和設(shè)計(jì)的關(guān)系。圖1.V模型用戶需求概要設(shè)計(jì)需求分析詳細(xì)設(shè)計(jì)驗(yàn)收測試集成測試功能測試單元測試編碼8.各種模型的比較模型描述優(yōu)點(diǎn)缺點(diǎn)應(yīng)用場景瀑布模型過程劃分為計(jì)劃、需求、設(shè)計(jì)、編碼、測試和維護(hù)階段；各階段自上而下，相互銜接固定次序，如同瀑布流水；各階段評審確認(rèn)通過，前階段輸出是后階段輸入；文檔驅(qū)動（DocumentDriven）。嚴(yán)格規(guī)定應(yīng)提交的文檔，為項(xiàng)目提供檢查點(diǎn)；利于大型軟件項(xiàng)目中人員的組織與管理；利于開發(fā)方法工具的研究和使用；提高大型項(xiàng)目中的開發(fā)效率與質(zhì)量。文檔驅(qū)動，可能不能完全滿足用戶需求；呈線性，成果未經(jīng)測試時(shí)，用戶看不到結(jié)果，增加了風(fēng)險(xiǎn)；前階段未發(fā)現(xiàn)的錯誤傳到后階段甚至擴(kuò)散，可導(dǎo)致項(xiàng)目失??；需求階段，完全確定需求比較困難。大型軟件項(xiàng)目；需求明確；需求很少變更。8.各種模型的比較模型描述優(yōu)點(diǎn)缺點(diǎn)應(yīng)用場景快速原型模型快速建造初步、非完整軟件原型，實(shí)現(xiàn)客戶與系統(tǒng)交互；客戶對原型評價(jià)，細(xì)化需求；逐步調(diào)整原型滿足要求，原型內(nèi)部結(jié)構(gòu)不重要；原型驅(qū)動（PrototypeDriven）。確定客戶真正需求，減少需求不確定性；更好和客戶溝通，提高客戶對軟件的滿意度；減少技術(shù)，應(yīng)用風(fēng)險(xiǎn)，縮小成本，提高產(chǎn)品質(zhì)量。需要盡可能盡快建造軟件原型，可能會限制開發(fā)人員創(chuàng)新；所選技術(shù)工具不一定是主流，效率低；原型快速建立的內(nèi)部結(jié)構(gòu)及連續(xù)修改可能導(dǎo)致產(chǎn)品設(shè)計(jì)差；客戶確定真正需求，原型可能被棄?？蛻艋蝾I(lǐng)域?qū)＜也皇煜る娔X/軟件，軟件人員不熟悉領(lǐng)域，溝通理解困難。8.各種模型的比較模型描述優(yōu)點(diǎn)缺點(diǎn)應(yīng)用場景增量模型分階段實(shí)現(xiàn)，軟件增量設(shè)計(jì)，實(shí)現(xiàn)，集成，測試；整個(gè)產(chǎn)品拆成多個(gè)構(gòu)件，分次逐個(gè)構(gòu)件，交付可運(yùn)行產(chǎn)品；功能驅(qū)動（FunctionDriven）。反饋及時(shí)，較好適應(yīng)變化；客戶看到不斷變化的軟件，降低開發(fā)風(fēng)險(xiǎn)；鼓舞團(tuán)隊(duì)的士氣。容易退化成邊做邊改，失去對軟件過程的整體控制，效率低；不破壞現(xiàn)有架構(gòu)；產(chǎn)品、架構(gòu)不是開放的，維護(hù)難度加大。需求比較明確；架構(gòu)比較穩(wěn)定，每次增量不影響架構(gòu)。8.各種模型的比較模型描述優(yōu)點(diǎn)缺點(diǎn)應(yīng)用場景螺旋模型分成計(jì)劃、評估、設(shè)計(jì)實(shí)施、用戶反饋四個(gè)象限；沿著螺線進(jìn)行若干次迭代；關(guān)注風(fēng)險(xiǎn)，風(fēng)險(xiǎn)分析之后決策項(xiàng)目是否繼續(xù)；風(fēng)險(xiǎn)驅(qū)動（強(qiáng)調(diào)可選方案及約束條件支持軟件重用；有助于提升軟件質(zhì)量。要求客戶接受相信其風(fēng)險(xiǎn)分析，并作出反應(yīng)不容易；風(fēng)險(xiǎn)分析成本>項(xiàng)目利潤，項(xiàng)目風(fēng)險(xiǎn)分析無意義；要善于識別風(fēng)險(xiǎn)，且準(zhǔn)確，否則將帶來更大風(fēng)險(xiǎn)。8.各種模型的比較模型描述優(yōu)點(diǎn)缺點(diǎn)應(yīng)用場景噴泉模型以需求為動力，以對象為驅(qū)動，支持面向?qū)ο箝_發(fā)；開發(fā)過程自下而上各階段是相互迭代和無間隙；對象驅(qū)動（ObjectDriven）。各階段無明顯界限，開發(fā)人員可同步開發(fā)；提高開發(fā)效率，節(jié)省開發(fā)時(shí)間。各階段重疊，需大量開發(fā)人員；不利于項(xiàng)目管理；需嚴(yán)格管理文檔及文檔變更。適合面向?qū)ο箝_發(fā)。V模型，智能模型是上述模型的演化或者組合，這里就不再單獨(dú)列出。1.2.2軟件開發(fā)方法1．結(jié)構(gòu)化方法結(jié)構(gòu)化開發(fā)方法是由E.Yourdon和L.L.Constantine于1978年提出的，即所謂的SASD方法，也可稱為面向功能的軟件開發(fā)方法或面向數(shù)據(jù)流的軟件開發(fā)方法，又稱為結(jié)構(gòu)化生命周期法。此方法是系統(tǒng)分析員、軟件工程師、程序員以及最終用戶按照用戶至上的原則，自頂向下分析與設(shè)計(jì)和自底向上逐步實(shí)施的建立計(jì)算機(jī)信息系統(tǒng)的一個(gè)過程，是組織、管理和控制信息系統(tǒng)開發(fā)過程的一種基本框架。SASD方法是80年代使用最廣泛的軟件開發(fā)方法。1．結(jié)構(gòu)化方法結(jié)構(gòu)化分析以數(shù)據(jù)流圖為工具，實(shí)現(xiàn)對問題空間即需求的描述。它主要以數(shù)據(jù)流、數(shù)據(jù)變換為考慮對象，從這個(gè)角度來描述整個(gè)系統(tǒng)的狀況。結(jié)構(gòu)化設(shè)計(jì)以數(shù)據(jù)流圖為藍(lán)本，提出其數(shù)據(jù)變換部分，加以功能分解，一直到最小的功能元素單位。開發(fā)人員據(jù)此進(jìn)行程序設(shè)計(jì)。2．面向數(shù)據(jù)結(jié)構(gòu)的軟件開發(fā)方法⑴Jackson方法。1975年，M.A.Jackson提出了面向數(shù)據(jù)結(jié)構(gòu)的軟件開發(fā)方法，簡稱為JSP方法。這一方法從目標(biāo)系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)入手，導(dǎo)出程序框架結(jié)構(gòu)，再補(bǔ)充其它細(xì)節(jié)，就可得到完整的程序結(jié)構(gòu)圖。Jackson指出，無論數(shù)據(jù)結(jié)構(gòu)還是程序結(jié)構(gòu)，都限于三種基本結(jié)構(gòu)及它們的組合，因此，他給出了三種基本結(jié)構(gòu)的表示。三種基本的結(jié)構(gòu)形式就是順序、選擇和重復(fù)。2．面向數(shù)據(jù)結(jié)構(gòu)的軟件開發(fā)方法(1)Jackson方法,基本上由下述五個(gè)步驟組成。①分析并確定輸入數(shù)據(jù)和輸出數(shù)據(jù)的邏輯結(jié)構(gòu)，并用Jackson圖描繪這些數(shù)據(jù)結(jié)構(gòu)。②找出輸入數(shù)據(jù)結(jié)構(gòu)和輸出數(shù)據(jù)結(jié)構(gòu)中有對應(yīng)關(guān)系的數(shù)據(jù)單元。③按一定的規(guī)則由輸入、輸出的數(shù)據(jù)結(jié)構(gòu)導(dǎo)出程序結(jié)構(gòu)。④列出所有操作和條件,并且把它們分配到程序結(jié)構(gòu)圖的適當(dāng)位置。⑤用偽碼表示程序。⑵Warnier方法1974年，J.D.Warnier提出了另一種面向數(shù)據(jù)結(jié)構(gòu)的程序設(shè)計(jì)方法，又稱為邏輯構(gòu)造程序方法（簡稱LCP）方法。這種方法由如下五個(gè)步驟組成：①分析和確定輸入數(shù)據(jù)和輸出數(shù)據(jù)的邏輯結(jié)構(gòu)，并用Warnier圖描繪這些數(shù)據(jù)結(jié)構(gòu)。②主要依據(jù)輸入數(shù)據(jù)結(jié)構(gòu)導(dǎo)出程序結(jié)構(gòu)，并用Warnier圖描繪程序的處理層次。③畫出程序流程圖并自上而下依次給每個(gè)處理框編序號。④分類寫出偽碼指令。⑤把前一步中分類寫出的指令按序號排序，從而得出描述處理過程的偽碼。3．面向問題的分析方法PAM（ProblemAnalysisMethod）是80年代末由日立公司提出的一種軟件開發(fā)方法。它的基本思想是考慮到輸入、輸出數(shù)據(jù)結(jié)構(gòu)，指導(dǎo)系統(tǒng)的分解，在系統(tǒng)分析指導(dǎo)下逐步綜合。這一方法的具體步驟是：從輸入、輸出數(shù)據(jù)結(jié)構(gòu)中導(dǎo)出基本處理框；分析這些處理框之間的先后關(guān)系；按先后關(guān)系逐步綜合處理框，直到畫出整個(gè)系統(tǒng)的PAD圖。3．面向問題的分析方法這一方法本質(zhì)上是綜合的自底向上的方法，但在逐步綜合之前已進(jìn)行了有目的地分解，這個(gè)目的就是充分考慮系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)。PAM方法的另一個(gè)優(yōu)點(diǎn)是使用PAD圖。這是一種二維樹形結(jié)構(gòu)圖，是到目前為止最好的詳細(xì)設(shè)計(jì)表示方法之一。由于在輸入、輸出數(shù)據(jù)結(jié)構(gòu)與整個(gè)系統(tǒng)之間同樣存在著鴻溝，這一方法仍只適用于中小型問題。4．原型化開發(fā)方法產(chǎn)生原型化方法的原因很多，主要是并非所有的需求都能夠預(yù)先定義，而反復(fù)修改是不可避免的。開發(fā)工具的快速發(fā)展為原型化方法奠定了基礎(chǔ)。如用VB，Delphi等工具可以迅速的開發(fā)出一個(gè)可以讓用戶看得見、摸得著的系統(tǒng)框架。有了這個(gè)框架，對于計(jì)算機(jī)不是很熟悉的用戶就可以根據(jù)這個(gè)樣板提出自己的明確需求。4．原型化開發(fā)方法開發(fā)原型化系統(tǒng)一般由以下幾個(gè)階段組成：⑴確定用戶需求。⑵開發(fā)原始模型。⑶讓用戶使用原型，征求用戶對初始原型的改進(jìn)意見。⑷修改原型。⑸判定原型完成情況，完成后就提交文檔并交付使用。5．面向?qū)ο蟮能浖_發(fā)方法面向?qū)ο笫钱?dāng)前計(jì)算機(jī)界關(guān)心的重點(diǎn)，它是90年代軟件開發(fā)方法的主流。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計(jì)和軟件開發(fā)，擴(kuò)展到很寬的范圍。如數(shù)據(jù)庫系統(tǒng)、交互式界面、應(yīng)用結(jié)構(gòu)、應(yīng)用平臺、分布式系統(tǒng)、網(wǎng)絡(luò)管理結(jié)構(gòu)、CAD技術(shù)、人工智能等領(lǐng)域。面向?qū)ο蠹夹g(shù)是軟件技術(shù)的一次革命，在軟件開發(fā)史上具有里程碑的意義。隨著OOP（面向?qū)ο缶幊蹋┫騉OD（面向?qū)ο笤O(shè)計(jì)）和OOA（面向?qū)ο蠓治觯┑陌l(fā)展，最終形成面向?qū)ο蟮能浖_發(fā)方法。5．面向?qū)ο蟮能浖_發(fā)方法面向?qū)ο笙到y(tǒng)采用了自底向上的歸納、自頂向下分解的方法，它通過建立對象模型，能夠真正反映用戶的需求，而且系統(tǒng)的可維護(hù)性大大改善。面向?qū)ο蠓椒ǖ幕舅枷胧菑默F(xiàn)實(shí)世界中客觀存在的事物出發(fā)來構(gòu)造軟件系統(tǒng)，并在系統(tǒng)構(gòu)造中盡可能運(yùn)用人類的自然思維方式。目前，面向?qū)ο箝_發(fā)方法的研究已日趨成熟，國際上已有不少面向?qū)ο螽a(chǎn)品出現(xiàn)。當(dāng)前業(yè)界關(guān)于面向?qū)ο蠼５臉?biāo)準(zhǔn)是UML（UnifiedModelingLanguage）。6．可視化開發(fā)方法可視化開發(fā)并不能單獨(dú)的作為一種開發(fā)方法，更加貼切的說可以認(rèn)為它是一種輔助工具。可視化開發(fā)就是在可視開發(fā)工具提供的圖形用戶界面上，通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、復(fù)選框、列表框和滾動條等，由可視開發(fā)工具自動生成應(yīng)用軟件。目前主要是在編程這個(gè)環(huán)節(jié)上使用可視化，而不是在系統(tǒng)分析和設(shè)計(jì)上用可視化方法。6．可視化開發(fā)方法可視化編程語言的特點(diǎn)主要表現(xiàn)在兩個(gè)方面：一是基于面向?qū)ο蟮乃枷?，引入了控件的概念和事件?qū)動；二是程序開發(fā)過程一般遵循以下步驟，即先進(jìn)行界面的繪制工作，再基于事件編寫程序代碼，以響應(yīng)鼠標(biāo)、鍵盤的各種動作。國外有些公司正在進(jìn)行這方面的研究，如BusinessObject就是一個(gè)非常好的數(shù)據(jù)庫可視化分析工具。可視化開發(fā)使我們把注意力集中在業(yè)務(wù)邏輯和業(yè)務(wù)流程上，用戶界面可以用可視化工具表示。1.3面向?qū)ο箝_發(fā)方法概述 1.3.1面向?qū)ο箝_發(fā)方法的由來面向?qū)ο螅∣bjectOriented，OO）的概念起源于挪威的K.Nyguard等開發(fā)的模擬離散事件的程序設(shè)計(jì)語言Simula67。真正的面向?qū)ο蟪绦蛟O(shè)計(jì)是由AlanKeyz主持設(shè)計(jì)的Smalltalk語言，“面向?qū)ο蟆边@個(gè)詞也是Smalltalk最先提出的。面向?qū)ο蟾拍畹某霈F(xiàn)是程序設(shè)計(jì)方法學(xué)和軟件工程方法學(xué)的里程碑。面向?qū)ο蟮姆椒ㄆ鹪从诿嫦驅(qū)ο蟮某绦蛟O(shè)計(jì)語言。20世紀(jì)80年代，隨著大批面向?qū)ο缶幊陶Z言的問世，面向?qū)ο蠓椒ㄩ_始向面向?qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計(jì)等階段延伸，并試圖在系統(tǒng)開發(fā)的整個(gè)生命周期中使用面向?qū)ο蟮姆椒ā?.3.2面向?qū)ο蠓椒ǖ幕舅枷?客觀世界是由各種各樣的對象組成的，每種對象都有各自的內(nèi)部狀態(tài)和運(yùn)動規(guī)律，不同對象之間的相互作用和聯(lián)系構(gòu)成了各種不同的系統(tǒng)。面向?qū)ο笫菑默F(xiàn)實(shí)世界客觀存在的事物（即對象）出發(fā)來構(gòu)造軟件系統(tǒng)，并且在系統(tǒng)構(gòu)造中盡可能運(yùn)用人類的自然思維方式。面向?qū)ο蠓椒ǖ囊c(diǎn)：⑴客觀世界是由各種對象組成的。任何事物都是對象，復(fù)雜的對象可以由比較簡單的對象以某種方式組合而成。⑵所有對象劃分為類。把所有對象都劃分成各種對象類（簡稱為類（Class）），每個(gè)對象類都定義了一組數(shù)據(jù)和一組方法，數(shù)據(jù)用于表示對象的靜態(tài)屬性，是對象的狀態(tài)信息。⑶類具有等級。⑷對象之間通過消息進(jìn)行交互。對象彼此之間僅能通過傳遞消息互相聯(lián)系。1.3.3面向?qū)ο蟮幕靖拍?在面向?qū)ο蟮姆治龊驮O(shè)計(jì)中，對象和類是核心概念。。1.3.3面向?qū)ο蟮幕靖拍?面向?qū)ο蠓椒ㄓ腥笾匾卣鳎悍庋b性、繼承性和多態(tài)性。面向?qū)ο笊婕暗幕靖拍钣校簩ο?、類、封裝、信息隱蔽、繼承、多態(tài)、消息、關(guān)聯(lián)和復(fù)用等。在面向?qū)ο蟮姆治龊驮O(shè)計(jì)中，對象和類是核心概念。1．類把眾多的事物歸納、劃分成一些類（class）。JamesRumbaugh對類的定義：類是具有相似結(jié)構(gòu)、行為和關(guān)系的一組對象的描述符，類包括屬性和操作。類的屬性是對象的狀態(tài)的抽象，用數(shù)據(jù)結(jié)構(gòu)來描述類的屬性。類的操作是對象的行為的抽象，用操作名和實(shí)現(xiàn)該操作的方法來描述。類歸納是人類在認(rèn)識客觀世界時(shí)經(jīng)常采用的思維方法，分類的原則是抽象。類是具有相同屬性和服務(wù)的一組對象的集合，它為屬于該類的所有對象提供了統(tǒng)一的抽象描述，其內(nèi)部包括屬性和服務(wù)兩個(gè)主要部分，，一個(gè)方法有方法名、返回值、參數(shù)、方法體等。2.對象對象（object）是現(xiàn)實(shí)世界中一個(gè)實(shí)際存在的事物，它可以是有形的，如房屋，桌子等；也可以是無形的，如國家，生產(chǎn)計(jì)劃等。對象是構(gòu)成世界的一個(gè)獨(dú)立單位，它具有自己的靜態(tài)特征和動態(tài)特征。面向?qū)ο蠓椒ㄖ械膶ο螅窍到y(tǒng)中用來描述客觀事物的一個(gè)實(shí)體，它是用來構(gòu)成系統(tǒng)的一個(gè)基本單位，由一組屬性和一組行為構(gòu)成。對象可分為主動對象和被動對象。4．繼承繼承（inheritance）是指一個(gè)對象直接使用另一對象的屬性和方法，是表示相似性質(zhì)的機(jī)制。繼承是指類之間有繼承關(guān)系，子類有條件地繼承父類的特征。繼承意味著自動地?fù)碛?，或隱含地復(fù)制，正如你同時(shí)繼承父母的外貌特點(diǎn)一樣，信息系統(tǒng)組成成分也從有關(guān)部件繼承某些特點(diǎn)。繼承是一種聯(lián)結(jié)類的層次模型，并且允許和鼓勵類的重用，它提供了一種明確描述共性的方法。4．繼承一個(gè)類的上層可以有超類，下層可以有子類，形成一種層次結(jié)構(gòu)。這種層次結(jié)構(gòu)的一個(gè)重要特點(diǎn)是繼承性，一個(gè)類繼承其超類的全部描述。對象的一個(gè)新類可以從現(xiàn)有的類中派生出來，這個(gè)過程稱為類繼承。新類繼承了原始類的特性，新類稱為原始類的派生類（子類），而原始類稱為新類的基類（父類）。派生類可以從它的基類繼承方法和實(shí)例變量，并且類可以修改或增加新的方法使之更適合特殊的需要。5．多態(tài)多態(tài)（polymorphism）一般指具有多種形態(tài)的能力。如水有3態(tài)，即固態(tài)、液態(tài)和氣態(tài)。打印程序可以打印字符、數(shù)字、圖形和圖像。對象的多態(tài)性是指在一般類中定義的屬性或服務(wù)被特殊類繼承之后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。不同的對象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象稱為多態(tài)性。多態(tài)性包括參數(shù)化多態(tài)性和包含多態(tài)性。5．多態(tài)多態(tài)性允許每個(gè)對象以適合自身的方式去響應(yīng)共同的消息。多態(tài)性能夠利用同一類（基類）類型的指針來引用不同類的對象，能夠根據(jù)所引用對象的不同以不同的方式執(zhí)行相同的操作。多態(tài)性增強(qiáng)了軟件的靈活性和重用性。6．消息消息（message）是面向?qū)ο蠓椒ㄖ袑ο笾g相互聯(lián)系的方法，是對傳送信息的對象之間所進(jìn)行的通信的規(guī)約，其中帶有將要發(fā)生的活動的期望。對象之間進(jìn)行通信的結(jié)構(gòu)叫做消息。在對象的操作中，當(dāng)一個(gè)消息發(fā)送給某個(gè)對象時(shí)，消息包含接收對象去執(zhí)行某種操作的信息。發(fā)送一條消息至少要包括說明接受消息的對象名，發(fā)送給該對象的消息名（即對象名、方法名）。一般還要對參數(shù)加以說明，6．消息t:AirTrafficPlannerp:FightPlan1:getPositionAtTime(t)1.1:getLastCheckpoint()消息消息7．關(guān)聯(lián)關(guān)聯(lián)（relationship）是對象之間的一種引用關(guān)系，如客戶類與訂單類之間的關(guān)系，關(guān)聯(lián)關(guān)系所涉及的兩個(gè)類是處于同一層次上的，而在聚合和組合關(guān)系中，兩個(gè)類處在不平等的層次，一個(gè)代表整體，一個(gè)代表部分關(guān)聯(lián)是一種結(jié)構(gòu)關(guān)系，說明一個(gè)事物的對象與另一個(gè)事物的對象相聯(lián)系。給定一個(gè)連接兩個(gè)類的關(guān)聯(lián)，可以從一個(gè)類的對象導(dǎo)航到另一個(gè)類的對象。關(guān)聯(lián)可以有方向，即導(dǎo)航。一般不作說明的時(shí)候，導(dǎo)航是雙向的，不需要在線上標(biāo)出箭頭。8．復(fù)用復(fù)用（reuse）就是重復(fù)使用。復(fù)用可以采用3種形式，即共享、復(fù)制和改造。共享和復(fù)制是大家非常熟悉的。改造也是常用的，例如程序員在可復(fù)用部件庫內(nèi)找到一段子程序、模塊或段落等，該子程序、模塊或段落成為程序員編制新的子程序的出發(fā)點(diǎn)，新的子程序與庫中子程序存在某種程度的相似。于是程序員開始對庫中的子程序進(jìn)行改造，刪除某些代碼，改變某些代碼，或加入某些新的代碼。1.4面向?qū)ο笾饕_發(fā)方法 面對對象開發(fā)方法起源于面向?qū)ο缶幊陶Z言，它包括面向?qū)ο蠓治?、面向?qū)ο笤O(shè)計(jì)、面向?qū)ο髮?shí)現(xiàn)、面向?qū)ο鬁y試和面向?qū)ο缶S護(hù)等。20世紀(jì)80年代后期到90年代初期，隨著面向?qū)ο蠹夹g(shù)成為研究的熱點(diǎn)，出現(xiàn)了幾十種支持軟件開發(fā)的面向?qū)ο蠓椒ā?0世紀(jì)90年代中期，面向?qū)ο蠓椒ㄒ呀?jīng)成為軟件分析與設(shè)計(jì)方法的主流。1.4.1CoadYourdon方法CoadYourdon方法是由PeterCoad和EdwardYourdon在1991年提出的，這是一種逐步進(jìn)階的面向?qū)ο蠼７椒āoad和Yourdon1991年合寫了《面向?qū)ο蟮姆治觥芬粫?。該書詳?xì)地闡述了面向?qū)ο笙到y(tǒng)分析的一套使用方法和具體步驟，用實(shí)例進(jìn)行詳細(xì)的說明。后來他們又合寫了《面向?qū)ο蟮南到y(tǒng)設(shè)計(jì)》一書，詳細(xì)地闡明了面向?qū)ο笤O(shè)計(jì)的一套使用方法和步驟。1.4.1CoadYourdon方法CoadYourdon方法的開發(fā)步驟也是由面向?qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計(jì)和面向?qū)ο髮?shí)現(xiàn)所組成。這種方法嚴(yán)格區(qū)分了面向?qū)ο蠓治龊兔嫦驅(qū)ο笤O(shè)計(jì)。OOA完成系統(tǒng)分析，包括以下五個(gè)步驟：確定類與對象、標(biāo)識結(jié)構(gòu)、定義主題、定義屬性和定義服務(wù)。在面向?qū)ο蠓治鲭A段，經(jīng)過5個(gè)層次活動分析得到一個(gè)分成5個(gè)層次的問題域模型，包括主題、類及對象、結(jié)構(gòu)、屬性和服務(wù)5個(gè)層次。1.4.1CoadYourdon方法OOD負(fù)責(zé)系統(tǒng)設(shè)計(jì)，包括以下四個(gè)步驟：⑴設(shè)計(jì)問題域部分（PDC）。細(xì)化分析結(jié)果，面向?qū)ο蠓治龅慕Y(jié)果直接放入該部分。⑵設(shè)計(jì)人機(jī)交互部分（HIC）。⑶設(shè)計(jì)任務(wù)管理部分（TMC）。⑷設(shè)計(jì)數(shù)據(jù)管理部分（DMC）。確定持久對象的存儲，這一部分依賴于存儲技術(shù)。數(shù)據(jù)管理采用文件系統(tǒng)，關(guān)系數(shù)據(jù)庫管理系統(tǒng)，還是面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)。1.4.2Booch方法 GradyBooch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一，他提出了面向?qū)ο筌浖こ痰母拍?。Booch方法是GradyBooch從1983年開始研究，1991年后走向成熟的一種方法。1993年，Booch對其之前的方法做了一些改進(jìn)，使之適合系統(tǒng)的設(shè)計(jì)和構(gòu)造。Booch在其OOAda中提出了面向?qū)ο蟮?個(gè)模型：邏輯視圖，物理視圖及其相應(yīng)的靜態(tài)和動態(tài)語義。1.4.2Booch方法Booch方法的開發(fā)步驟：⑴在給定的抽象層次上識別類和對象。⑵識別這些對象和類的語義。⑶識別這些類和對象之間的關(guān)系。該階段利用狀態(tài)轉(zhuǎn)移圖描述對象的狀態(tài)模型，利用時(shí)態(tài)圖（系統(tǒng)中的時(shí)態(tài)約束）和對象圖（對象之間的相互作用）描述行為模型。⑷實(shí)現(xiàn)類和對象。1.4.2Booch方法Booch方法與UML的關(guān)系Booch方法是UML的主要來源，其包含的概念豐富，如類、對象、繼承、元類、消息、域、操作、機(jī)制、模塊、子系統(tǒng)和進(jìn)程等。其模型主要包括：邏輯靜態(tài)視圖（類圖和對象圖）、邏輯動態(tài)視圖（順序圖、狀態(tài)圖）、物理靜態(tài)視圖（模塊圖、進(jìn)程圖）和物理動態(tài)視圖。1.4.3OMT方法 OMT（ObjectModelingTechnique）最早是由Loomis，Shan和Rumbaugh在1987年提出的，曾擴(kuò)展應(yīng)用于關(guān)系數(shù)據(jù)庫設(shè)計(jì)。OMT方法是1991年由JamesRumbaugh等5人提出來的，其經(jīng)典著作為“面向?qū)ο蟮慕Ｅc設(shè)計(jì)”。在OMT方法中，系統(tǒng)是通過對象模型、動態(tài)模型和功能模型來描述的。OMT方法包含系統(tǒng)分析、系統(tǒng)設(shè)計(jì)、對象設(shè)計(jì)和實(shí)現(xiàn)四個(gè)步驟，它定義了三種模型。這些模型貫穿于每個(gè)步驟，在每個(gè)步驟中被不斷地精化和擴(kuò)充。1.4.3OMT方法 OMT方法開發(fā)步驟：⑴OMT方法的系統(tǒng)分析。用OMT方法進(jìn)行系統(tǒng)分析需要建立對象模型、動態(tài)模型和功能模型。⑵OMT方法的系統(tǒng)設(shè)計(jì)。把系統(tǒng)分解成子系統(tǒng)；識別問題中固有的并發(fā)性；把子系統(tǒng)分配給處理器和任務(wù)；選擇數(shù)據(jù)存儲管理的方法；處理訪問全局資源；選擇軟件中的控制實(shí)現(xiàn)；處理邊界條件及設(shè)置綜合優(yōu)先權(quán)。1.4.3OMT方法 OMT方法開發(fā)步驟：⑶OMT方法的對象設(shè)計(jì)。用OMT方法進(jìn)行對象設(shè)計(jì)的開發(fā)步驟是組合3種模型——獲得類上的操作；實(shí)現(xiàn)操作的算法設(shè)計(jì)；優(yōu)化數(shù)據(jù)的訪問路徑；實(shí)現(xiàn)外部交互式的控制；調(diào)整類結(jié)構(gòu)，提高繼承性；設(shè)計(jì)關(guān)聯(lián)；確定對象表示；把類和關(guān)聯(lián)封裝成模塊。⑷OMT方法的實(shí)現(xiàn)?？梢允褂妹嫦?qū)ο蟮恼Z言、非面向?qū)ο笳Z言等程序設(shè)計(jì)語言，也可以使用數(shù)據(jù)庫管理系統(tǒng)實(shí)現(xiàn)。1.4.4OOSE方法 OOSE（Object-OrientedSoftwareEngineering）方法是IvarJacobson在1992年提出的一種使用事例驅(qū)動的面向?qū)ο箝_發(fā)方法。最大特點(diǎn)是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。OOSE是由用案模型、域?qū)ο竽Ｐ汀⒎治瞿Ｐ?、設(shè)計(jì)模型、實(shí)現(xiàn)模型和測試模型組成的。在需求分析階段識別領(lǐng)域?qū)ο蠛完P(guān)系，開發(fā)人員識別類、屬性和關(guān)系。在該方法中的一個(gè)關(guān)鍵概念就是use-case。1.4.4OOSE方法 use-case模型與其它5種系統(tǒng)模型關(guān)聯(lián)：⑴

領(lǐng)域?qū)ο竽Ｐ汀se-case模型根據(jù)領(lǐng)域來表示。⑵分析模型。use-case模型通過分析來構(gòu)造。⑶設(shè)計(jì)模型。use-case模型通過設(shè)計(jì)來具體化。⑷實(shí)現(xiàn)模型。該模型依據(jù)具體化的設(shè)計(jì)來實(shí)現(xiàn)use-case模型。⑸測試模型。用來測試具體化的Use-Case模型。1.4.5Rational軟件統(tǒng)一開發(fā)過程UML的創(chuàng)始者Booch、Jacobson和Rumbaugh在Rational公司（現(xiàn)在Rational公司被IBM并購）的支持下綜合了多種系統(tǒng)開發(fā)過程的長處，提出新的面向?qū)ο蟮拈_發(fā)過程，稱為Rational統(tǒng)一過程（RationalUnifiedProcess，RUP）。Rational統(tǒng)一過程是軟件工程的過程，它提供了在開發(fā)組織中分派任務(wù)和責(zé)任的紀(jì)律化方法。它的目標(biāo)是在可預(yù)見的日程和預(yù)算前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。統(tǒng)一過程模型是一種“用例驅(qū)動，以體系結(jié)構(gòu)為核心，迭代及增量”的軟件過程框架，由UML方法和工具支持。RUP用二維坐標(biāo)來描述。橫軸通過時(shí)間來組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)?？v軸以內(nèi)容來組織，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)。RUP中有9個(gè)核心工作流，分為6個(gè)核心過程工作流（CoreProcessWorkflows）和3個(gè)核心支持工作流（CoreSupportingWorkflows）。迭代模型圖顯示了過程的二維結(jié)構(gòu)，如所示。盡管6個(gè)核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個(gè)階段，但應(yīng)注意迭代過程中的階段是完全不同的，這些工作流在整個(gè)生命周期中一次又一次地被訪問。9個(gè)核心工作流在項(xiàng)目中輪流被使用，在每一次迭代中以不同的重點(diǎn)和強(qiáng)度重復(fù)。1.4.5Rational軟件統(tǒng)一開發(fā)過程測試內(nèi)容組織時(shí)間組織狀態(tài)核心過程工作流商業(yè)建模需求分析與設(shè)計(jì)實(shí)現(xiàn)部署核心支持工作流配置與變化項(xiàng)目管理環(huán)境初始迭代迭代﹟1迭代﹟1迭代﹟n迭代﹟n+2迭代﹟n+1迭代﹟m迭代﹟m+1迭代圖1.面向?qū)ο蟮能浖y(tǒng)一過程1.4.5Rational軟件統(tǒng)一開發(fā)過程1．商業(yè)建模商業(yè)建模（BusinessModeling）工作流描述了如何為新的目標(biāo)組織開發(fā)一個(gè)構(gòu)想，并基于這個(gè)構(gòu)想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程、角色和責(zé)任。2．需求需求（Requirements）工作流的目標(biāo)是描述系統(tǒng)應(yīng)該做什么，并使開發(fā)人員和用戶就這一描述達(dá)成共識。為了達(dá)到該目標(biāo)，要對需要的功能和約束進(jìn)行提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。1.4.5Rational軟件統(tǒng)一開發(fā)過程3.分析和設(shè)計(jì)分析和設(shè)計(jì)（Analysis&Design）工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計(jì)，為系統(tǒng)開發(fā)一個(gè)健壯的結(jié)構(gòu)并調(diào)整設(shè)計(jì)使其與實(shí)現(xiàn)環(huán)境相匹配，優(yōu)化其性能。4．實(shí)現(xiàn)實(shí)現(xiàn)（Implementation）工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)；以組件的形式（源文件、二進(jìn)制文件、可執(zhí)行文件）實(shí)現(xiàn)類和對象；將開發(fā)出的組件作為單元進(jìn)行測試以及集成由單個(gè)開發(fā)者（或小組）所產(chǎn)生的結(jié)果，使其成為可執(zhí)行的系統(tǒng)。5．測試測試（Test）工作流要驗(yàn)證對象間的交互作用，驗(yàn)證軟件中所有組件的正確集成，檢驗(yàn)所有的需求已被正確的實(shí)現(xiàn)，識別并確認(rèn)缺陷在軟件部署之前被提出并處理。6．部署部署（Deployment）工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。7．配置和變更管理配置和變更管理（Configuration&ChangeManagement）工作流描繪了如何在多個(gè)成員組成的項(xiàng)目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個(gè)變體，跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)，如何自動創(chuàng)建工程。同時(shí)也闡述了對產(chǎn)品修改原因、時(shí)間、人員保持審計(jì)記錄。8．項(xiàng)目管理軟件項(xiàng)目管理（ProjectManagement）平衡各種可能產(chǎn)生沖突的目標(biāo)和管理風(fēng)險(xiǎn)，克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標(biāo)包括：為項(xiàng)目的管理提供框架，為計(jì)劃、人員配備、執(zhí)行和監(jiān)控項(xiàng)目提供實(shí)用的準(zhǔn)則，為管理風(fēng)險(xiǎn)提供框架等。9．環(huán)境環(huán)境（Environment）工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項(xiàng)目過程中所需要的活動，同樣也支持開發(fā)項(xiàng)目規(guī)范的活動，它提供了逐步的指導(dǎo)手冊并介紹了如何在組織中實(shí)現(xiàn)過程。1.4.5Rational軟件統(tǒng)一開發(fā)過程5．測試測試（Test）工作流要驗(yàn)證對象間的交互作用，驗(yàn)證軟件中所有組件的正確集成，檢驗(yàn)所有的需求已被正確的實(shí)現(xiàn)，識別并確認(rèn)缺陷在軟件部署之前被提出并處理。6．部署部署（Deployment）工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。1.4.5Rational軟件統(tǒng)一開發(fā)過程7．配置和變更管理配置和變更管理工作流描繪了如何在多個(gè)成員組成的項(xiàng)目中控制大量的產(chǎn)物。8．項(xiàng)目管理軟件項(xiàng)目管理平衡各種可能產(chǎn)生沖突的目標(biāo)和管理風(fēng)險(xiǎn)，克服各種約束并成功交付使用戶滿意的產(chǎn)品。9．環(huán)境環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。RUP周期RationalUnifiedProcess將周期劃分為四個(gè)連續(xù)的階段，即初始（Inception）、細(xì)化（Elaboration）、構(gòu)造（Construction）和移交（Transition）階段。每個(gè)階段終結(jié)于良好定義的里程碑（某些關(guān)鍵決策必須做出的時(shí)間點(diǎn)），每個(gè)階段關(guān)鍵的目標(biāo)必須被達(dá)到。初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例和確定項(xiàng)目的邊界，主要包括識別所有用例和描述一些重要的用例。細(xì)化階段的目標(biāo)是分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項(xiàng)目計(jì)劃，淘汰項(xiàng)目中最高風(fēng)險(xiǎn)的元素。構(gòu)建階段主要目標(biāo)是通過優(yōu)化資源和避免不必要的返工達(dá)到開發(fā)成本的最小化；根據(jù)實(shí)際需要達(dá)到適當(dāng)?shù)馁|(zhì)量目標(biāo)；據(jù)實(shí)際需要形成各個(gè)版本；對所有必須的功能完成分析、設(shè)計(jì)、開發(fā)和測試工作；發(fā)出一個(gè)可以提交給最終用戶的完整產(chǎn)品；確定軟件站點(diǎn)用戶都為產(chǎn)品的最終部署做好了相關(guān)準(zhǔn)備；锍梢歡ǔ潭壬系牟⑿鋅⒒啤交付階段的目的是將軟件產(chǎn)品交付給用戶群體。統(tǒng)一軟件開發(fā)過程是一個(gè)面向?qū)ο笄一诰W(wǎng)絡(luò)的程序開發(fā)方法論。RUP開發(fā)過程定義“誰”于“何時(shí)”、“如何”做“某事”。開發(fā)過程中有四種建模元素：角色、活動、產(chǎn)物和工作流。根據(jù)Rational（RationalRose和統(tǒng)一建模語言的開發(fā)者）的說法，好像一個(gè)在線的指導(dǎo)者，它可以為所有方面和層次的程序開發(fā)提供指導(dǎo)方針、模版以及事例支持。RUP和類似的產(chǎn)品——例如面向?qū)ο蟮能浖^程（OOSP），以及OPENProcess都是理解性的軟件工程工具——把開發(fā)中面向過程的方面（例如定義的階段，技術(shù)和實(shí)踐）和其他開發(fā)的組件（例如文檔，模型，手冊以及代碼等等）整合在一個(gè)統(tǒng)一的框架內(nèi)。1.4.5Rational軟件統(tǒng)一開發(fā)過程RUP裁剪步驟：⑴確定本項(xiàng)目需要哪些工作流。RUP的9個(gè)核心工作流并不總是需要的，可以取舍。⑵確定每個(gè)工作流需要哪些制品。⑶確定4個(gè)階段之間如何演進(jìn)。確定階段間演進(jìn)要以風(fēng)險(xiǎn)控制為原則，決定每個(gè)階段需要哪些工作流、每個(gè)工作流執(zhí)行到什么程度。制品有哪些，每個(gè)制品完成到什么程度。⑷確定每個(gè)階段內(nèi)的迭代計(jì)劃。規(guī)劃RUP的4個(gè)階段中每次迭代開發(fā)的內(nèi)容。⑸規(guī)劃工作流內(nèi)部結(jié)構(gòu)。工作流涉及角色、活動及制品，它的復(fù)雜程度與項(xiàng)目規(guī)模及角色多少有關(guān)。最后規(guī)劃工作流的內(nèi)部結(jié)構(gòu)，通常用活動圖的形式給出。真正使“統(tǒng)一過程”與眾不同可以用三句話來表達(dá)：它是用例驅(qū)動的；以基本架構(gòu)為中心的；迭代式和增量性的。1.4.5Rational軟件統(tǒng)一開發(fā)過程RUP的特點(diǎn)：⑴RUP是一種迭代式開發(fā)。⑵管理需求。確定系統(tǒng)的需求是一個(gè)連續(xù)的過程，開發(fā)人員在開發(fā)系統(tǒng)之前不可能完全詳細(xì)的說明一個(gè)系統(tǒng)的真正需求。⑶基于組件的體系結(jié)構(gòu)。組件使重用成為可能，系統(tǒng)可以由組件組成。⑷可視化建模。⑸驗(yàn)證軟件質(zhì)量。⑹控制軟件變更。1.4.6幾種方法的比較CoadYourdon方法中，OOA把系統(tǒng)橫向劃分為五個(gè)層次，OOD把系統(tǒng)縱向劃分為四個(gè)部分，從而形成一個(gè)清晰的系統(tǒng)模型。OOAD適用于小型系統(tǒng)的開發(fā)。Booch方法并不是一個(gè)開發(fā)過程，只是規(guī)定在開發(fā)面向?qū)ο笙到y(tǒng)時(shí)應(yīng)遵循的一些技術(shù)和原則。Booch方法是從外部開始，逐步求精每個(gè)類直到系統(tǒng)被實(shí)現(xiàn)。因此，它是一種分治法，支持循環(huán)開發(fā)，它的缺點(diǎn)在于不能有效地找出每個(gè)對象和類的操作。1.4.6幾種方法的比較OMT方法覆蓋了應(yīng)用開發(fā)的全過程，是一種比較成熟的方法，用幾種不同的觀念來適應(yīng)不同的建模場合，它在許多重要觀念上受到關(guān)系數(shù)據(jù)庫設(shè)計(jì)的影響，適合于數(shù)據(jù)密集型的信息系統(tǒng)的開發(fā)，是一種比較完善和有效的分析與設(shè)計(jì)方法。OOSE能夠較好地描述系統(tǒng)的需求，是一種實(shí)用的面向?qū)ο蟮南到y(tǒng)開發(fā)方法，適合于商務(wù)處理方面的應(yīng)用開發(fā)RUP描述了如何有效地利用商業(yè)的可靠的方法開發(fā)和部署軟件，是一種重量級過程（也被稱作厚方法學(xué)），因此特別適用于大型軟件團(tuán)隊(duì)開發(fā)大型項(xiàng)目，“統(tǒng)一過程”使用的是“統(tǒng)一建模語言”。1.5面向?qū)ο筌浖_發(fā) 面向?qū)ο蟮能浖こ虒W(xué)是面向?qū)ο蠓椒ㄔ谲浖こ填I(lǐng)域的全面運(yùn)用。它包括面向?qū)ο蟮姆治觥⒚嫦驅(qū)ο蟮脑O(shè)計(jì)、面向?qū)ο蟮木幊獭⒚嫦驅(qū)ο蟮臏y試和面向?qū)ο蟮能浖S護(hù)等主要內(nèi)容。面向?qū)ο蠓椒ò聪到y(tǒng)開發(fā)的一般過程分為系統(tǒng)調(diào)查與可行性分析、面向?qū)ο蠓治觥⒚嫦驅(qū)ο笤O(shè)計(jì)、面向?qū)ο髮?shí)現(xiàn)、面向?qū)ο鬁y試和面向?qū)ο笙到y(tǒng)維護(hù)等階段?？尚行苑治鍪强蛇x的，對于一些指定的系統(tǒng)，不需要進(jìn)行可行性研究。1.5.1可行性分析1.可行性分析概念可行性分析又稱可行性研究（FeasibilityStudy），是指在當(dāng)前組織內(nèi)外的具體環(huán)境和現(xiàn)有條件下，某個(gè)項(xiàng)目投資的研制工作是否具備必要的資源及其他條件，是對組織將要開發(fā)的項(xiàng)目的價(jià)值和實(shí)用性的度量。1.5.1可行性分析1.可行性分析概念可行性通常從技術(shù)可行性（TechnicalFeasibility）、經(jīng)濟(jì)可行性（EconomicFeasibility）和運(yùn)行可行性（OperationalFeasibility）等3個(gè)方面來考慮。除了上述3個(gè)方面的可行性分析以外，還可從人員可行性（HumanFactorsFeasibility）、進(jìn)程可行性（ScheduleFeasibility）、環(huán)境可行性（EnvironmentFeasibility）和管理可行性（ManagementFeasibility）等方面進(jìn)行論證。2.可行性分析的目的和任務(wù)⑴可行性分析的目的?！队?jì)算機(jī)軟件產(chǎn)品開發(fā)文件編制指南》GB8567--1988中指出，可行性分析的目的是：說明該軟件開發(fā)項(xiàng)目的實(shí)現(xiàn)在技術(shù)上、經(jīng)濟(jì)上和社會條件上的可行性；評述為合理地達(dá)到開發(fā)目標(biāo)可能選擇的各種方案；說明并論證所選定的方案?？尚行苑治龅哪康囊簿褪峭ㄟ^對現(xiàn)行系統(tǒng)的調(diào)查研究，確定用戶提出建立一個(gè)新的計(jì)算機(jī)系統(tǒng)的要求是否合理、是否可行。避免盲目投資，減少不必要的損失。2.可行性分析的目的和任務(wù)⑵可行性分析的任務(wù)。依據(jù)《計(jì)算機(jī)軟件開發(fā)規(guī)范》GB8566--1988所指出的，可行性分析的主要任務(wù)是了解客戶的要求及現(xiàn)實(shí)環(huán)境，提出新系統(tǒng)的開發(fā)方案，從技術(shù)、經(jīng)濟(jì)和社會因素等3個(gè)方面研究并論證本軟件項(xiàng)目開發(fā)的可行性，編寫可行性分析報(bào)告，制定初步的項(xiàng)目開發(fā)計(jì)劃。3.可行性分析的實(shí)施步驟⑴現(xiàn)行系統(tǒng)調(diào)查與分析。系統(tǒng)分析人員對現(xiàn)實(shí)系統(tǒng)進(jìn)行初步調(diào)查，對系統(tǒng)進(jìn)行初步需求分析，了解用戶的需求。⑵提出新系統(tǒng)開發(fā)方案。⑶對待開發(fā)系統(tǒng)進(jìn)行可行性分析。⑷寫出系統(tǒng)可行性分析報(bào)告。⑸評審和審批系統(tǒng)可行性分析報(bào)告。⑹若項(xiàng)目可行，則制定初步的項(xiàng)目開發(fā)計(jì)劃，并簽署合同。4.可行性分析的檢查點(diǎn)對上級指令性的開發(fā)系統(tǒng)，只進(jìn)行系統(tǒng)的規(guī)劃，不需要進(jìn)行論證。系統(tǒng)規(guī)劃后明顯可行的項(xiàng)目由于范圍和復(fù)雜性的變化，可能會變得不可行。應(yīng)在系統(tǒng)生命周期內(nèi)設(shè)立可行性檢查點(diǎn)，4.可行性分析的檢查點(diǎn)問題的提出問題分析，總體規(guī)劃需求分析，邏輯設(shè)計(jì)應(yīng)用架構(gòu)，物理設(shè)計(jì)程序設(shè)計(jì)，系統(tǒng)轉(zhuǎn)換系統(tǒng)運(yùn)行，系統(tǒng)維護(hù)系統(tǒng)開發(fā)的可行性檢查點(diǎn)5.可行性分析報(bào)告的內(nèi)容1引言1.1編寫目的1.2背景1.3定義1.