姓名 :戴育兵
學號 :g1030510
年級 :大二
班級 : .net(2)班
摘要 傳統的軟體工程方法學曾經給軟體產業帶來巨大進步，部分地緩解了軟體危機，使用這種方法學開發的許多中、小規模軟體專案都獲得了成功。但是，人們也注意到當把這種方法學應用於大型軟體產品的開發時，似乎很少取得成功。
在20世紀60年代後期出現的物件導向程式設計語言simdla_67中首次引入了類和物件的概念，自20世紀80年代中期起，人們開始注重物件導向分析和設計的研究，逐步形成了物件導向方法學。到了20世紀90年代，物件導向方法學已經成為人們在開發軟體時首選的范型。物件導向技術已成為當前最好的軟體開發技術。
軟體工程傳統方法學
1. 傳統方法學概述
隨著計算機應用領域的不斷拓廣，各種各樣的問題也不斷湧現，當問題嚴重到開發人員無法控制的時候便產生了軟體危機。軟體危機的出現，促使了軟體工程學的形成和發展。 隨之整合整套技術的軟體工程方法學廣泛應用，主流之一就是傳統方法學。
傳統方法學在軟體開發過程中佔據相當大的比重，因為其悠久的歷史而為很多軟體工程師青睞。如果說自然語言和程式語言之間有一道難以跨越的鴻溝，傳統方法學就是跨越這道鴻溝的橋梁。
傳統方法學又稱生命週期方法學或結構化范型。乙個軟體從開始計畫起，到廢棄不用止，稱為軟體的生命週期。在傳統的軟體工程方法中，軟體的生存週期分為需求分析、總體設計、詳細設計、程式設計和測試幾個階段。
傳統方法學使用的是結構化分析技術來完成需求分析階段的工作。軟體工程學中的需求分析具有兩方面的意義。在認識事物方面，它具有一整套分析、認識問題域的方法、原則和策略。
這些方法、原則和策略使開發人員對問題域的理解比不遵循軟體工程方法更為全面、深刻和有效。在描述事物方面，它具有一套表示體系和文件規範。但是，傳統的軟體工程方法學中的需求分析在上述兩方面都存在不足．它在全域性範圍內以功能、資料或資料流為中心來進行分析。
這些方法的分析結果不能直接地對映問題域，而是經過了不同程度的轉化和重新組合。因此，傳統的分析方法容易隱蔽一些對問題域的理解偏差，與後續開發階段的銜接也比較困難。
在總體設計階段，以需求分析的結果作為出發點構造出乙個具體的系統設計方案，主要是決定系統的模組結構，以及模組的劃分，模組間的資料傳送及呼叫關係。詳細設計是在總體設計的基礎上考慮每個模組的內部結構及演算法，最終將產生每個模組的程式流程圖。 但是傳統的軟體工程方法中設計文件很難與分析文件對應，原因是二者的表示體系不一致， 所謂從分析到設計的轉換，實際上並不存在可靠的轉換規則，而是帶有人為的隨意性，從而很容易因理解上的錯誤而留下隱患。
程式設計階段是利用一種程式語言產生乙個能夠被機器理解和執行的系統，測試是發現和排除程式中的錯誤，最終產生乙個正確的系統。但是由於分析方法的缺陷很容易產生對問題的錯誤理解，而分析與設計的差距很容易造成設計人員對分析結果的錯誤轉換，以致在程式設計時程式設計師往往需要對分析員和設計人員已經認識過的事物重新進行認識，並產生不同的理解。因此為了使兩個階段之間能夠更好的銜接，測試就變得尤為重要。
軟體維護階段的工作，一是對使用中發生的錯誤進行修改，二是因需求發生了變化而進行修改。前一種情況需要從程式逆向追溯到發生錯誤的開發階段。由於程式不能對映問題以及各個階段的文件不能對應，每一步追溯都存在許多理解障礙。
第二種情況是乙個從
需求到程式的順向過程，它也存在初次開發時的那些困難，並且又增加了理解每個階段原有文件的困難.
2. 傳統方法學的優點
程式在除錯、可讀性和可維護性等方面都有很大的改進。
傳統軟體工程方法面向的是過程，它按照資料變換的過程尋找問題的結點，對問題進行分解。由於不同人對過程的理解不同，故面向過程的功能分割出的模組會因人而異。對於問題世界的抽象結論，結構化方法可以用資料流圖，系統結構圖，資料字典，狀態轉移圖，實體關係圖來進行系統邏輯模型的描述，生產乙個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。
傳統軟體工程方法學強調以模組為中心，採用模組化，自頂向下，逐步求精設計過程， 系統是實現模組功能的函式和過程的集合，結構清晰，可讀性好，是提高軟體開發質量的一種有效手段。結構化設計從系統的功能入手，按照工程標準，嚴格規範地將系統分解為若干功能模組，因為系統是實現模組功能的函式和過程的集合。然而，由於使用者的需要和軟硬體技術的不斷發展變化，作為系統基本組成部分的功能模組很容易受到影響，區域性修改甚至會引起系統的根本性變化。
開發過程前期入手快而後期頻繁改動的現象比較常見。
3. 傳統工程方法學的缺點
傳統的軟體工程方法學也存在很多的缺點，主要表現在生產效率非常底，從而導致不能滿足使用者的需要，復用程度低，軟體很難維護等。
結構化開發方法，注重的是系統功能，自頂向下，從大到小的功能分解，從dfd－＞msd，往往系統需求變化最大就是功能，一段較長的時間內，商業的流程可能已經發生了很大的變化，這樣基於功能和過程的方法顯然難以維護的，**重用率。
**重用性不高：以過程為中心設計新系統，除了一些標準函式，大部分**都必須重新編寫。由於軟、硬體技術的不斷發展和使用者需求的變化，按照功能劃分設計的系統模組容易發生變化，使得開發出來的模組的可維護性欠佳。
開發周期長，系統難以適應環境的變化，開發過程發雜繁瑣。
適用於相對穩定。，業務處理過程規範的，需求明確且在一定時間內不會發生大變化的複雜系統的開發。
軟體重用性差
重用性是指同一事物不經修改或稍加修改就可多次重複使用的性質。軟體重用性是軟體工程追求的目標之一。
軟體可維護性差
軟體工程強調軟體的可維護性，強調文件資料的重要性，規定最終的軟體產品應該由完整、一致的配置成分組成。在軟體開發過程中，始終強調軟體的可讀性、可修改性和可測試性是軟體的重要的質量指標。實踐證明，用傳統方法開發出來的軟體，維護時其費用和成本仍然很高，其原因是可修改性差，維護困難，導致可維護性差。
開發出的軟體不能滿足使用者需要
用傳統的結構化方法開發大型軟體系統涉及各種不同領域的知識，在開發需求模糊或需求動態變化的系統時，所開發出的軟體系統往往不能真正滿足使用者的需要。
用結構化方法開發的軟體，其穩定性、可修改性和可重用性都比較差，這是因為結構化方法的本質是功能分解，從代表目標系統整體功能的單個處理著手，自頂向下不斷把複雜的處理分解為子處理，這樣一層一層的分解下去，直到僅剩下若干個容易實現的子處理功能為止，然後用相應的工具來描述各個最低層的處理。因此， 結構化方法是圍繞實現處理功能的「過程」來構造系統的。然而，使用者需求的變化大部分是針對功能的，因此，這種變化對於基於過程的設計來說是災難性的。
用這種方法設計出來的系統結構常常是不穩定的，使用者需求的變化往往造成系統結構的較大變化，從而需要花費很大代價才能實現這種變化。
物件導向方法學
1.象的基本概念
(1)物件
物件是人們要進行研究的任何事物，從最簡單的整數到複雜的飛機等均可看作物件，它不僅能表示具體的事物，還能表示抽象的規則、計畫或事件。
(2)物件的狀態和行為。
物件具有狀態，乙個物件用資料值來描述它的狀態。
物件還有操作，用於改變物件的狀態，物件及其操作就是物件的行為。
物件實現了資料和操作的結合，使資料和操作封裝於物件的統一體中
(3)類。
具有相同或相似性質的物件的抽象就是類。因此，物件的抽象是類，類的具體化就是物件，也可以說類的例項是物件。
類具有屬性，它是物件的狀態的抽象，用資料結構來描述類的屬性。
類具有操作，它是物件的行為的抽象，用操作名和實現該操作的方法來描述。
(4)類的結構。
在客觀世界中有若干類，這些類之間有一定的結構關係。通常有兩種主要的結構關係，即一般--具體結構關係，整體--部分結構關係。
①一般——具體結構稱為分類結構，也可以說是「或」關係，或者是「is a」關係。
②整體——部分結構稱為組裝結構，它們之間的關係是一種「與」關係，或者是「has a」關係。
(5)訊息和方法。
物件之間進行通訊的結構叫做訊息。在物件的操作中，當乙個訊息傳送給某個物件時，訊息包含接收物件去執行某種操作的資訊。傳送一條訊息至少要包括說明接受訊息的物件名、傳送給該物件的訊息名（即物件名、方法名）。
一般還要對引數加以說明，引數可以是認識該訊息的物件所知道的變數名，或者是所有物件都知道的全域性變數名。
類中操作的實現過程叫做方法，乙個方法有方法名、引數、方法體。
(1)物件唯一性。
每個物件都有自身唯一的標識，通過這種標識，可找到相應的物件。在物件的整個生命期中，它的標識都不改變，不同的物件不能有相同的標識。
(2)抽象性。
分類性是指將具有一致的資料結構(屬性)和行為(操作)的物件抽象成類。乙個類就是這樣一種抽象，它反映了與應用有關的重要性質，而忽略其他一些無關內容。任何類的劃分都是主觀的，但必須與具體的應用有關。
(3)繼承性。
繼承性是子類自動共享父類資料結構和方法的機制，這是類之間的一種關係。在定義和實現乙個類的時候，可以在乙個已經存在的類的基礎之上來進行，把這個已經存在的類所定義的內容作為自己的內容，並加入若干新的內容。
繼承性是物件導向程式設計語言不同於其它語言的最重要的特點，是其他語言所沒有的。
在類層次中，子類只繼承乙個父類的資料結構和方法，則稱為單重繼承。
在類層次中，子類繼承了多個父類的資料結構和方法，則稱為多重繼承。
在軟體開發中，類的繼承性使所建立的軟體具有開放性、可擴充性，這是資訊組織與分類的行之有效的方法，它簡化了物件、類的建立工作量，增加了**的可重性。
採用繼承性，提供了類的規範的等級結構。通過類的繼承關係，使公共的特性能夠共享，提高了軟體的重用性。
(4)多型性(多形性)
多型性是指相同的操作或函式、過程可作用於多種型別的物件上並獲得不同的結果。不同的物件，收到同一訊息可以產生不同的結果，這種現象稱為多型性。
多型性允許每個物件以適合自身的方式去響應共同的訊息。
多型性增強了軟體的靈活性和重用性。
傳統的程式設計技術是面向過程的設計方法，這種方法以演算法為核心，把資料和過程作為相互獨立的部分，資料代表問題空間中的客體，程式**則用於處理這些資料。
把資料和**作為分離的實體，反映了計算機的觀點，因為在計算機內部資料和程式是分開存放的。但是，這樣做的時候總存在使用錯誤的資料呼叫正確的程式模組，或使用正確的資料呼叫錯誤的程式模組的危險。使資料和操作保持一致，是程式設計師的乙個沉重負擔，在多人分工合作開發乙個大型軟體系統的過程中，如果負責設計資料結構的人中途改變了某個資料的結構而又沒有及時通知所有人員，則會發生許多不該發生的錯誤。
傳統的程式設計技術忽略了資料和操作之間的內在聯絡，用這種方法所設計出來的軟體系統其解空間與問題空間並不一致，令人感到難於理解。實際上，用計算機解決的問題都是現實世界中的問題，這些問題無非由一些相互間存在一定聯絡的事物所組成。每個具體的事物都具有行為和屬性兩方面的特徵。
因此，把描述事物靜態屬性的資料結構和表示事物動態行為的操作放在一起構成乙個整體，才能完整、自然地表示客觀世界中的實體。
物件導向的軟體技術以物件(object)為核心，用這種技術開發出的軟體系統由物件組成。物件是對現實世界實體的正確抽象，它是由描述內部狀態表示靜態屬性的資料，以及可以對這些資料施加的操作(表示物件的動態行為)，封裝在一起所構成的統一體。物件之間通過傳遞訊息互相聯絡，以模擬現實世界中不同事物彼此之間的聯絡。
物件導向的設計方法與傳統的面向過程的方法有本質不同，這種方法的基本原理是，使用現實世界的概念抽象地思考問題從而自然地解決問題。它強調模擬現實世界中的概念而強調演算法，它鼓勵開發者在軟體開發的絕大部分過程中都用應用領域的概念去思考。在物件導向的設計方法中，計算機的觀點是不重要的，現實世界的模型才是最重要的。
物件導向的軟體開發過程從始至終都圍繞著建立問題領域的物件模型來進行：對問題領域進行自然的分解，確定需要使用的物件和類，建立適當的類等級，在物件之間傳遞訊息實現必要的聯絡，從而按照人們習慣的思維方式建立起問題領域的模型，模擬客觀世界。
小議傳統方法學與物件導向的區別
小議傳統方法學 與物件導向的區別 姓名 朱威 班級 微軟2班 系別 資訊工程 摘要傳統的軟體工程方法學曾經給軟體產業帶來巨大進步，部分地緩解了軟體危機，使用這種方法學開發的許多中 小規模軟體專案都獲得了成功。但是，人們也注意到當把這種方法學應用於大型軟體產品的開發時，似乎很少取得成功。在 20 世紀...
UML與物件導向方法學
2007 2008學年第2學期 專業班級 姓名學號 開課系室 考試日期 一 填空題 每空1分，共27分 1 uml中關係包括4種，分別是 和2和用於對物件導向系統的物理方面建模進行描述的2種圖形。3是描述在某一時刻，系統中一組物件以及它們之間關係的圖形。4 部署圖中的節點可以分為2種型別和 5 物件...
第三講物件導向方法學
問題 組合語言編寫程式 高階語言的結構化程式設計和物件導向程式設計之間的比較？物件導向方法與面向過程方法的比較分析 物件導向的概念 省略 物件導向軟體過程的一般特性 1 物件導向的軟體過程 軟體過程模型的比較 噴泉模型 噴泉模型的生命週期與面向過程的生命週期是一致的，但噴泉模型的各個階段是迭代和無縫...