UML系統(tǒng)建模及系統(tǒng)分析與設計課件第1章 面向?qū)ο筌浖_發(fā)方法_第1頁
UML系統(tǒng)建模及系統(tǒng)分析與設計課件第1章 面向?qū)ο筌浖_發(fā)方法_第2頁
UML系統(tǒng)建模及系統(tǒng)分析與設計課件第1章 面向?qū)ο筌浖_發(fā)方法_第3頁
UML系統(tǒng)建模及系統(tǒng)分析與設計課件第1章 面向?qū)ο筌浖_發(fā)方法_第4頁
UML系統(tǒng)建模及系統(tǒng)分析與設計課件第1章 面向?qū)ο筌浖_發(fā)方法_第5頁
已閱讀5頁,還剩126頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

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

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

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

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論