物件导向的软体发展.doc

物件導向的軟體發展 針對日趨複雜之軟體需求的挑戰，軟體業界發展出了物件導向(OO)的軟體發展模式。目前作爲針對軟體危機的最佳對策，OO技術已經引起人們的普遍關注。最初被多數人看作只是一種不切實際的方法，和滿足一時好奇心的研究，現在得到了人們近乎狂熱的歡迎。許多程式語言都推出了支援物件導向的新版本。大量的物件導向的開發方法被提出來。關於OO的會議、學術研討班和課程極受歡迎，無數專業的學術期刊都爲這一話題開闢了專門的版面。一些軟體發展合同甚至也指明了必須使用OO的技術和語言。物件導向的軟體發展對於90年代，就像是結構化的軟體發展對於70年代那樣讓人著迷，而且OO的發展勢必還在日益加速。諸如物件和物件的屬性這樣的概念，可以一直追溯到 1950 年代初，首先出現在人工智慧的早期著作中。然而，OO 的實際發展卻是始於 1966 年。 當時 Kisten Nygaard 和 Ole-Johan Dahl 開發了具有更高層級抽象機制的 Simula 語言。Simula 提供了較副程式更高一級的抽象和封裝；爲了模仿一個實際問題，引入了資料抽象和類別的概念。 大約在同一時期，Alan Kay 正在尤他大學的一台個人電腦上努力工作，他希望能在這上面實現圖形化和虛擬實境。儘管由於軟硬體的限制，Kay 的嘗試沒有成功，但他的這些想法並沒有丟失。70 年代初期，他加入了 Palo Alto 研究中心(PARC)，再次將這些想法付諸實施。在PARC，他所在的研究小組堅信電腦技術是改善人與人、人與機器之間通訊渠道的關鍵。在這信念的支援下，並吸取了Simula 類別的概念，他們開發出Smalltalk語言；1972年PARC發佈了Smalltalk的第一個版本。大約在此時，物件導向這一術語正式確定，Smalltalk被認爲是第一個真正物件導向的語言。 Smalltalk 的目標是爲了使軟體設計能夠盡可能以自動化的單元來進行。在 Smalltalk 中運作的一切都是物件-即是某個類別的實例。最初在Smalltalk的世界中，物件與名詞緊緊相連。Smalltalk還支援一個高度互動式的開發環境和原型方法。這一原創性的工作開始並未被發表，只是被視爲帶有濃厚試驗性質的學術興趣而已。Smalltalk-80 是 PARC 一系列 Smalltalk 版本的總結，發佈於1981年。1981年8月的雜誌公佈了Smalltalk開發小組的重要結果。在這期雜誌的封面圖上，一個熱氣球正從一個孤島上冉冉升起來，標誌著 PARC 的物件導向思想的啓航。該是向軟體發展界公開發表的時候了，起初，影響只是漸進式的，但很快就躍升到火爆的程度。熱氣球確實啓航了，而且影響深遠。早期Smalltalk關於開發環境的研究導致了後來的一系列進展：視窗（window），圖示（icon）,滑鼠(mouse)和下拉式window環境。Smalltalk語言還影響了 80 年代早期和中期的物件導向的語言，如：Object-C(1986)、 C+(1986)、 Self(1987)、Eiffl(1987)、Flavors(1986)，物件導向的應用領域也被進一步拓寬。物件不再僅僅與名詞相聯繫，還包括事件和程序。1980 Grady Booch首先提出物件導向設計（OOD）的概念，然後其他人緊隨其後，物件導向分析的技術開始公開發表。1985年，第一個商用物件導向資料庫問世。1990年代以來，物件導向的分析、測試、度量和管理等研究都得到長足發展。目前物件技術的先進課題包括設計模式(design patterns)、分散式物件系統和以網路為基礎的物件應用等。2 動機爲什麽物件導向運動發展到了現在這樣火爆的程度？部分是源于人們長久以來的一個希望：人們希望它像以前其他軟體發展的技術一樣，能夠滿足軟體發展對於生産效率、可靠性、易維護性、易管理等方面，具有更高、更快、更強的迫切需求，除此之外，還有許多原因都促使了它的流行。物件導向的開發強調從問題領域的概念到軟體程式和介面的直接映射；心理學的研究也表明，把客觀世界看成是許多物件，將更接近人類的自然思維方式。物件比函數更爲穩定；軟體需求的變動往往是功能相關的變動，而其功能的執行者-物件-通常不會有大的變動。另外，物件導向的開發也支援、鼓勵軟體工程實踐中的資訊隱藏、資料抽象化和封裝。在一個物件內部所進行任何的修改是被隔離在局部，因此物件導向開發的軟體就易於修改、擴充和維護。物件導向也被擴充應用於軟體生命周期的各個階段-從分析到編寫程式碼。而且，物件導向的方法自然而然地支援快速原型開發方法和RAD(Rapid Application Development)。物件導向的開發鼓勵重覆使用，不僅軟體的重覆使用，還包括分析、設計的模型的重覆使用。更進一步，OO技術還方便了軟體的互換性，即是網路中一個節點上的應用，能夠利用另一個節點上的資源。物件導向的開發還支援並行、層次和複雜等一些在目前的軟體系統中常見的現象。今天我們常常會需要建造一些軟體系統-不止是黑箱應用。這些複雜系統通常包含由多個子系統組成的層次結構。物件導向的開發支援開放系統的建設；利用不同的應用來進行軟體集成具有更大的柔性。最後，物件導向開發的使用可以減少開發複雜系統所面臨的危險，主要是因爲系統集成遍佈軟體生命周期的各個階段。3 物件導向的塑模物件導向塑模不僅僅是新的程式語言的匯總，它也是一種新的思維方式，一種關於計算和資訊結構化的新思維。物件導向的塑模，把系統看做是相互協作的物件，這些物件是結構和行爲的封裝，都屬於某個類別，那些類別具有某種層次化的結構，系統的所有功能透過物件之間相互發送訊息來獲取。物件導向的塑模可以視爲是一個包含以下元素的概念框架：抽象化、封裝、模組化、層次、分類、並行、穩定、可重覆使用和可擴展性。物件導向塑模的出現並不能算是一場計算革命，更恰當地講，它是程序導向和嚴格資料驅動的軟體發展方法，所漸進式演變的結果。軟體發展的新方法受到來自兩個方面的推動：程式語言的發展和日趨複雜的問題領域的需求驅動。儘管實際上分析和設計是在程式編寫階段之前進行，但從發展歷史看，卻是程式語言的革新帶來設計和分析技術的改變。同樣，語言的演變也是對電腦體系的增強，和因日益複雜的需求而自然的一種回應。影響OO産生的諸多因素中，最重要的可能要算是程式編寫方法的進步。在過去的幾十年中，程式語言中對抽象機制的支援已經發展到了一個較高的水平。這種抽象的進化從地址（機器語言）到名字（組合語言），到運算式（第一代高階語言，如 Fortran），到控制（第二代高階語言，如 Cobol），到程序和函數（第二代和早期第三代高階語言，如 Pascal），乃至模組和資料(晚期第三代高階語言，如 modula )，最後是到物件（基於物件和物件導向的語言）。 Smalltalk 和其他物件導向語言的發展，使得新的分析和設計技術的實現成爲可能。這些新的 OO 的技術實際上是結構化和資料庫方法的融合，OO 的方法中，在小範圍內對資料流程導向的關注，如耦合和聚合，也是很重要的。同樣，物件內部的行爲最終也需要程序導向的設計方法。資料庫技術中的實體-關係（ER圖）的資料建模思想也在 OO的方法中得以體現。電腦硬體體系結構的進步，性能價格比的提高和硬體設計中物件概念的導入都對OO的發展産生了一定的影響。OO的程式通常要更加頻繁地存取記憶體，需要更高的處理速度，他們需要並且也正在利用強大的電腦硬體功能。哲學和認知科學的層次和分類理論也促進了OO的産生和發展。最後，電腦系統不斷增長的規模、複雜度和分佈性都對OO技術起了或多或少的推動作用。因爲影響OO發展的因素很多，OO技術本身還未成熟，所以在思想和術語上有很多不同的說法。所有的OO語言並非生而平等，他們在術語、概念的運用上也各不相同。儘管也存在統一的趨勢，但就如何進行物件導向的分析、設計而言還沒有完全達成共識，更沒有統一的符號來描述這些活動（編輯註：UML正在朝這方向努力）。但是，OO的開發已經在以下領域被證明是成功的：空中交通管理、動畫設計、銀行、商業資料處理、命令和控制系統、CAD、CIM、資料庫、專家系統、圖像識別、數學分析、音樂合成、作業系統、程序控制、空間站軟體、機器人、遠端通訊、介面設計和VLSI設計。毫無疑問，OO技術的應用已經成爲軟體工業發展的主流。4 物件導向程式編輯 概念 在物件導向編程中，程式被看作是相互協作的物件集合，每個物件都是某個類別的實例，所有的類別構成一個透過繼承關係相聯繫的層次結構。物件導向的語言常常具有以下特徵：物件建構的功能、訊息傳遞機制、類別和繼承的機制。這些概念當然可以單獨出現，並且也已經應用於其他程式語言的實作。但是只有在物件導向語言中，他們才會共同出現，以一種獨特的合作方式互相協作、互相補充。程序化的程式編輯模式乃： 參數輸入- | 程式碼 | -結果輸出爲實現某個功能，參數被傳入某個處理程序內，最後傳回計算結果。物件導向程式編輯模式：| 物件- 資料結構| 介面 | 物件- 和 | | 物件- 操作 |OOP中，功能是透過與物件的通訊獲得的。物件可以被定義爲一個封裝了狀態和行爲的實體；或者說是資料結構（或屬性）和操作。狀態實際上是爲執行行爲而必須存於物件之中的資料、資訊。物件的介面，也可稱之爲協定，是一組物件能夠回應訊息的集合。訊息是物件通訊的方式，因而也是獲得功能的方式。物件收到發送給他的訊息後，或者執行一個內部操作（有時稱爲方法或程序），或者再去呼叫其他物件的操作。所有物件都是類別的實例，類別是具有相同特點的物件的集合，或者也可以說，類別是可用於産生物件的一個模版。物件回應一個訊息而呼叫其方法，此由接收該訊息的物件自己決定。類別可以用一種樹狀階層式結構來安排，在這個階層式結構中，子類別可以從比他高的超類別中繼承狀態和方法。當物件接收到一個訊息後，尋找相應方法的程序，將從該物件的類別開始，並在該類別所處的階層式結構中展開，最後，直到找著該方法為止，或者什麽也沒找到（將會產生錯誤訊息）。在某些語言中，一個既定的類別可以從不止一個超類別中繼承下來，此稱之爲多重繼承。如果採用動態鏈結，繼承就導致了多型。多型描述的是如下現象，即若幾個子類別都重新定義了超類別的某個函數（都用相同的函數名），當訊息被發送到一個子類別物件時，在執行時該訊息時，會因子類別的不同而被解釋爲不同的操作方式。方法也可以被包括在超類別的介面中被子類別所繼承，而實際上並不去真正定義它。這樣的超類別也稱為抽象類別。抽象類別不能被實例化，因此也就只能被用於産生子類別。 語言 物件導向的語言包含4個基本的分支：1. 基於Smalltalk語言的；包括Smalltalk的5個版本，以Smalltalk-80爲代表。2. 基於C語言的；包括 objective-C、 C+、 Java。(編輯註：及 Microsoft 近來所提出的 C#)。3. 基於LISP語言的；包括 Flavors、 XLISP、 LOOPS、 CLOS。4. 基於PASCAL語言的；包括 Object Pascal、 Turbo Pascal、 Eiffel、 Ada 95。Simula實際上是所有這些語言的老祖宗。在這些OO語言中，術語的命名和支援OO的能力都有不同程度的差別。 儘管Smalltalk-80不支援多重繼承，它仍被認爲是最物件導向的語言(the truest OO language)。在基於C的OO語言中，Object-C 是Brad Cox開發的，它帶有一個豐富的類別程式庫，已經被成功用於大型系統的開發。C+是由貝爾實驗室的Bjarne Stroustrup所創的，它將C語言中的STRUCT 擴展爲具有資料隱藏功能的CLASS，多型乃透過虛擬函數(virtual functions)來實現。C+ 2.0 支援多重繼承，在多數軟體領域中，尤其是Unix平臺上，C+都是首選的物件導向程式語言。同C和C+相類似的新一代乃基於Internet的物件導向語言Java是由Sun microsystems研製的，它於1995年伴隨著Internet的崛起而風靡一時。用Java寫的applets可以嵌入HTML中被解譯執行，這使它具備了跨平臺特性。Java和Ada一樣支援多執行緒和並行機制，又如C一般的簡單、便於攜帶。基於LISP的語言，多被用於知識表達和推理的應用中。其中CLOS(Common LISP Object System)是物件導向LISP的標準版。在基於Pascal的語言中，Object Pascal是由Apple和Niklaus Wirth爲Macintosh開發的，它的類別程式庫是MacApp。Turbo Pascal是Borland公司以Object Pascal爲範本開發的。(編輯註：Object Pascal 目前也用於 Borland 公司的 Delphi 產品中，而且 Borland 的 Object Pascal 已經做了許多語法上的改良，以便於支援新一代的技術。)Eiffel由交互軟體工程公司的Bertrand Meyer於1987年發佈的。它的語法類似Ada，運行於Unix環境。Ada在1983年剛出來時並不支援繼承和多型，因而不是物件導向式的。直到1995年，一個物件導向的Ada終於問世，這就是Ada 95。除了上述的物件導向的語言之外，還有一些語言被認爲是以物件為基礎(Object-based)的。它們是：Alphard、 CLU、 Euclid、 Gypsy、 Mesa、 Modula。5 物件導向的軟體工程生命周期 儘管物件導向的語言正在取得令人激動的進展，但我們都知道，編輯程式碼並非是軟體發展中主要的問題來源。相比之下，需求和分析的問題就更加普遍，而且它們的除錯代價更加昂貴。因此，對OO開發技術的關注，就不能僅僅集中在編碼上面，更應集中在關心軟體工程各方面的議題。OO方法在處理複雜系統的分析和設計及其重覆使用方面，應用前景也是相當可觀。如果我們承認OO的軟體發展不僅僅局限於編碼活動，那麽就必須採用一種全新的開發模式，包括新的軟體生命周期。目前最常見的生命周期是瀑布模型（結構化）。它是在60年代末軟體危機後出現的第一個生命周期模型。如下所示。分析 - 設計 - 編碼 - 測試 - 維護如圖所示，瀑布式生命周期的開發程序是順序行進的；活動流向基本是單向的。它假設開發者在開發初期對系統的瞭解有充分的瞭解，不幸的是，任何軟體發展活動都不可避免地要涉及大量反覆式的程序，無論你事先是否已經安排妥當。因此好的設計人員指的就是那些能夠同時/span後期的變化、反覆式、變更困難， 不支援重覆使用， 沒有一個連繫各個階段的統一模型。物件導向的方法從問題模型開始，然後就是識別物件、不斷細緻化的過程，本質上它就是反覆式和漸進式的，在這裏，快速原型開發和反饋迴路是必需的標準結構。開發程序就是一次次的反覆遞增程序。隨著反覆式的進行，系統的功能不斷完善。這裏，傳統的開發模式中在分析、設計和編碼等各個階段之間的明顯界限變得模糊起來。其原因是因爲物件的概念彌漫了整個開發過程。物件和它們之間的關係成爲分析、設計和編碼等各個階段的共同表達媒介。開發的重心從編碼往分析偏移，從功能爲中心向資料爲中心轉移。而且，物件導向開發的反覆式和無接縫特性使得重覆使用變得更加自然。近來，爲改善物件導向開發的可管理性，玻姆(Boehm,1988)提出了一個結合了宏觀和微觀觀點(macro & microview)的螺旋式開發模型。宏觀包括3個階段：1分析-發現和識別物件；2 設計-發明和設計物件；3 實施-創造和實現物件。每個宏觀階段都包含一些微觀反覆式的活動。6 OOA和OOD由於物件導向的技術還比較新，目前存在許多種物件導向的分析和設計方法。物件導向的分析(OOA)建立於以前的資訊塑模技術的基礎之上，可以定義成是一種從問題領域辭彙中，以發現類別和物件的概念，來考察需求的分析方法。OOA的結果是一系列從問題領域導出的黑箱物件，OOA通常使用劇情(scenarios)來幫助確定基本的物件行爲。一個劇情是發生在問題領域中一連串的活動序列。在對一個既定的問題領域進行 OOA時，框架(Frameworks)的概念就非常有用。框架是應用或應用子系統的骨架，包含一些具體或者抽象的類別。或者說，框架是一種特定的階層式結構，包含描述某一問題領域的抽象父類別。當下所有流行的OOA方法，其缺點就是他們都缺乏一種固定的模式(formality)。在物件導向的設計(OOD)階段，注意的焦點將從問題空間轉移到理解空間。OOD是一種包含對所設計系統中邏輯的和實體的過程描述，以及系統的靜態和動態模型的設計方法(Booch,1994)。在OOA和OOD中，都存在對於重覆使用特性的關注。目前，OO技術的研究人員們正在嘗試定義設計樣式(design patterns)這一概念。它是一種可以實現重覆使用的財富，可以應用在不同的問題領域中。通常，設計樣式指的是一種多次出現的設計結構或解決方案。如果對他們進行系統的歸類，即可被重覆使用，以構成不同設計之間通信的基礎。OOD技術實際上早於OOA技術而出現，目前在OOA和OOD之間已經很難畫出一條清晰的界限。因此下面的描述，點出一些常用的OOA/OOD（聯合）技術的概要全貌。Meyer 用語言作爲表達設計的工具。(1988)Booch的OOD技術擴展了他以前在Ada方面的工作經驗。他採用一種往返綜合(round-trip gestalt)的方法，包括以下過程：識別物件，識別物件的語義，識別物件之間的關係，同時包含一系列反覆式的開發程序來進行實作。Booch也是最先使用類別圖，類別分類圖，類別模板和物件圖來描述OOD的人(1991)。Wrifs-Brocks的OOD技術是由職責代理來驅動的，類別職責卡(Class Responsibilities Cards簡稱 CRC)就是用來記錄類別所負責的特定功能。在確定了類別及其職責之後，再進行更詳細的關係分析和子系統的實作。(1990)Rumbaugh使用3種模型來描述一個系統：1 物件模型，描述系統中物件的靜態結構；2 動態模型，描述系統狀態隨時間變化的情況；3 功能模型，描述系統中各個資料值的轉變。物件圖、狀態轉換圖和資料流程圖分別被用於描述這3種模型。(1991)Coad和Yourdon採用以下的OOA步驟來確定一個多層次OO模型（5個層次）：找出類別和物件、識別結構和關係、確定主題、定義屬性及定義服務。5個步驟分別對應模型的5個層次，即類別和物件層、主題層、結構層、屬性層和服務層。他們的OOD方法既是多層次的，也是多方面的(multicomponent)，階層式架構也與OOA是一樣的。多方面包括：問題領域、人與人的交互作用、任務管理和資料管理。Ivar Jacobson 提出了Objectory方法(或Jacbson法)，是一種他在瑞典Objective系統中開發的物件導向軟體工程方法。Jacbson的方法特別強調了Use Case的使用。 Use Case成爲分析模型的基礎，用互動圖(Interaction Diagram)進一步描述後就形成設計的模型。Use Cases同時也驅動測試階段的測試工作。到目前爲止，Jacbson法是最爲完整的工業方法。 （1992）以上所述的方法還有許多的變種，無法一一列出。近年來，隨著各種方法的演變，它們之間也互相融合。1995年，Booch、Rumbaugh和Jacbson聯手合作，提出了第一版的UML(Unified Modelling Language)，統一化塑模語言。(目前已經成爲OO塑模語言的事實標準)7 管理問題當組織向物件導向的開發技術轉向時，支援軟體發展的管理活動也必然要有所改變。承諾使用OO技術即意味要改變開發程序、資源和組織結構。(Goldberg 1995) OO開發的反覆式、原型以及無接縫特性消除了傳統開發模式不同階段之間的界限，新的界限必須被重新確定，同時，一些軟體測度的方法也不在適用了。程式碼行數LOC(Lines of Code)評量方式絕對是過時了，重覆使用類別的數目、繼承層次的深度、類別與類別之間關係的數目、物件之間的耦合度、類別的個數以及大小顯得更具有意義。在OO的軟體測量方面的工作還是相當新的，但也已經存有一些參考文獻。(Lorenz 1993)資源分配和人員配置都需要重新考慮。開發小組的規模逐步變小，擅長重覆使用的專家開始吃香，重點應該放在重覆使用而非LOC上。重覆使用的真正實現需要一套全新的準則，在執行軟體契約的同時，類別程式庫和應用框架也必須建立起來。長期的投資策略，以及對維護這些可重覆使用財富的承諾和過程，變