第一章，軟件工程導論：
軟件危機：計算機軟件開發維護過程中所遇到得一系列嚴重的問題。
軟件危機的典型表現：
- 對軟件開發成本和進度的估計常常很不準確。
- 用戶對以完成的軟件系統不滿意的現象經常發生。
- 軟件產品質量靠不住
- 軟件常常是不可維護的
- 軟件常常沒有適當的文檔資料。
- 軟件成本在計算機系統總成本所佔比例逐年上升。
- 軟件開發生產率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢。
軟件工程導論
軟件=程序+數據+相關文檔
軟件生存週期（Software Life Cycle）：一個軟件 產品從定義、開發、維護到廢棄的時間總和稱爲軟 件的生存週期。
1.軟件定義階段： 該階段必須要回答的問題是“需要軟件解決的問題 是什麼”，
(1) 問題定義： 通過對客戶的訪問調查，系統分析員扼 要地寫出關於問題性質、工程目標和工程規模的書 面報告，經過討論和必要的修改之後這份報告應該得到客戶的確認。
（2）可行性研究： 提交“可行性研究報告”，要回答“對於上 一個階段所確定的問題有行得通的解決方法 嗎？”
（3）軟件需求分析： 主要確定目標系統必須具備哪些功能，提交 “需求規格說明書”，描述軟件的功能和性 能，確定軟件設計的限制和軟件與其他系統 元素的接口，定義軟件的其他有效性需求。
2.軟件開發階段： 該階段的任務是設計實現已定義的並經過需 求分析的軟件系統。
（4）總體設計 （概要設計）： 需要解決的問題是“應該如何宏觀地解決問 題”確定軟件德模塊功能，得出意義明確的 功能模塊，確定每個模塊的輸入、輸出以及相互聯繫。
（5）詳細設計（模塊設計）： 給出具體實現這個系統的步驟，但還不是編 寫程序,而是設計出程序的詳細規格說明（類 似於工程師的工程藍圖），它們包含必要的 細節，程序員可以根據它們寫出實際的程序 代碼。
（6）編碼和單元測試 ：寫出正確的容易理解、容易維護的程序模塊。程序員應該根據目標系統的性質和實際環境 選取一種適當的高級程序設計語言把詳細設 計的結果翻譯成用選定的語言書寫的程序， 並仔細測試編寫出的每一個模塊。
（7）綜合測試 ：關鍵任務是通過各種類型的測試及相應的調 試使軟件大道預定的要求。 此階段最重要的測試是：集成測試、驗收測 試。（1）集成測試：是根據設計的軟件結構，把經過單 元測試的模塊按照某種選定的策略裝配起來。 （2）驗收測試：按照規格說明書的規定，由用戶（或在用戶積極參加下）對目標系統進行驗收。
（8）軟件維護： 運行階段的任務是保障軟件的正常運行以及對軟件 進行維護。爲了排除軟件系統中可能隱含的錯誤， 適應用戶需求及系統操作環境的變化，需要繼續對 系統進行修改或擴充。
把軟件生存週期中各項開發活動的流程用一 個合理的框架-開發模型來規範描述，這就是 軟件過程模型，或稱爲軟件生存週期模型。
瀑布模型 ：
瀑布模型的優缺點
1、瀑布模型有以下優點： 1）爲項目提供了按階段劃分的檢查點。 2）當前一階段完成後，您只需要去關注後續階段。 3）可在迭代模型中應用瀑布模型。
2、瀑布模型有以下缺點： 1）在項目各個階段之間極少有反饋。 2）只有在項目生命週期的後期才能看到結果。 3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。
快速原型模型 ：(簡答題)是快速建立起來的可以在計算機上運行的程序，它 所能完成的功能往往是最終產品能完成的功能的一 個子集。 快速原型模型又稱原型模型，它是增量模型的另一 種形式；它是在開發真實系統之前，構造一個原 型，在該原型的基礎上，逐漸完成整個系統的開發 工作。
增量模型：
螺旋模型：每個階段之前都增加了風險分析過程。
噴泉模型：面向對象的軟件過程模型之一。
第二章，可行性研究
可行性研究本質：
實質上要進行一次大大壓縮簡化了的系統分析和設計的過程。也就是在較高的層次上以較抽象的方式進行系統分析和設計階段的過程， 從經濟可行性、技術可行性、法律可行性和用戶操作可行性等方面評價系統是否值得做，是否能做。
結構化開發方法(Structured Developing Method)：
數據流圖描述了系統的邏輯結構，一個數據流圖中的四個基本圖形元素（數據源、數據流、數據存儲和數據處理）
數據流圖的基本成分
數據流圖的基本圖形元素
數據流圖中的擴充符號
數據流圖繪製方法
繪製步驟： （1）找出系統的輸入輸出 （2）畫系統的內部 （3）畫加工的內部
在頂層圖中沒有文件。
考試題：
訂貨單=配件號+配件名+規格+數量+顧客名+地址
提貨單=訂貨單+金額
採貨單=配件號+配件名+規格+數量+供貨商名+地址
送貨單=配件號+配件名+規格+數量+金額
1.畫系統的頂層圖（輸入輸出）
2.畫系統的0層圖
3.畫加工的內部
數據字典（DD）
數據字典是關於數據信息的集合，是數據流 圖中所有元素嚴格定義的集合
數據字典有以下四類條目：數據項(數據流分量)、數據流、文件(數據存儲)、基本加工(處理)。
1.數據流 ：要定義數據流圖中的數據流就要用數據流條目。數據流條目給出了某個數據流的定義，通常是列出該數據流的各個組成數據項。
訂貨單(數據流條目)=配件號(數據項)+配件名+規格+數量+顧客名+地址；
數據元素組成數據的方式：順序，選擇，重複，可選。
數據流條目的描述內容：
（1）名稱：數據流名。
（2）別名：數據流的另一個名字。
（3）簡述：對數據流的簡單描述和說明。
（4）組成：描述數據流由哪些數據項組成，使用如表3-1所示的描述符號來表示數據流的組成
2.數據項條目 ：
數據流的組成成員是數據項，數據項條目是不可再分解的數據單位，是組成數據流和數據存儲的最小元素。數據項條目的描述內容如下：
（1）名稱：數據項名。
（2）別名：數據項的另一個名字
（3）簡述：對數據項的簡單描述
（9）註解：對數據項的其它補充說明。
第三章，需求分析
需求分析是軟件定義時期的最後一個階段，基本任務是準確回答系統具體做什麼，確定系統必須完成那些工作，對目標系統提出完整，準確，清晰，具體的要求。
需求分析的任務：
- 確定對系統的綜合要求，
- 分析系統的數據要求，
- 導出系統的邏輯模型
- 修正系統開發計劃
分析過程建立的三種模型：
定義系統模型要區分邏輯模型和物理模型。 常用模型有數據建模、功能建模和行爲建模。
概念模型：E-R圖；
2.3 結構化分析方法
結構化分析方法最初只是着眼於數據流，自頂向下，逐層分解，建立系統的處理流程，以數據流圖和數據字典爲主要工具，建立系統的邏輯模型。 擴充後，將建模技術擴展到數據建模、功能建模和行爲建模，以實體-關係圖、數據流圖和控制流圖、狀態-遷移圖爲工具，數據字典爲核心，從不同視點建立系統的分析模型。
數據建模：E-R圖；功能建模：DFD(數據流圖)；行爲建模：狀態轉換圖。
1. 數據建模
數據模型包括三種互相關聯的信息：數據對象，描述對象的屬性，描述對象間相互連接的關係。
在需求分析階段描述數據對象和它們之間的關係，使用了E-R 圖。
2，功能建模：DFD圖
3. 行爲建模
狀態轉換圖
狀態：狀態是任何可以被觀察到的系統的行爲模式，一個狀態代表了一種行爲方式。初態（實心圓），終態（同心圓），中態(同心圓)。一張狀態圖中只能有一個初態，終態可以有0到多個。中間狀態用圓角矩形表示，上面部分爲狀態的名稱，必須有，中間部分爲狀態變量的名字和值，可選，下面部分是活動表，
事件：事件是某個特定時刻發生的事情，它是對引起系統做動作或重一個狀態轉換到另一個狀態的的外界事件的抽象。事件就是引起系統做動作的或轉換狀體的控制信息。
符號：
其他圖型工具：
1.層次方框圖
層次圖也叫H圖，它是一個表示信息系統 結構的有效工具。同模塊結構圖類似，但 比較簡單。層次圖一個方框表示一個模塊， 方框內寫模塊名稱。用方框間的連線表示 模塊間的層次關係。
2.Warnier圖
法國計算機科學家Warnier提出了表示信息層 次結構的另外一種圖形工具。 Warnier圖可以表明信息的邏輯組織，它可以 指出一類信息或一個信息元素是重複出現的， 也可以表示特定信息在某一類信息中是有條件 地出現的。
圈加==異或符號，表明一類信息不能同時出現，px==表示重複的次數。
IPO圖
是輸入—輸出—處理圖的簡稱。它也是美 國IBM公司發展並完善起來的一種圖形工具。它 具有簡單、易用、描述清晰的特點，用來表示一 個加工比較直觀，對設計很有幫助。一個完整的 IPO圖由三個大方框組成。左邊的方框內寫有關 的輸入數據，稱輸入框；中間的方框列出對輸入 數據的處理，稱處理框；右邊的方框寫處理所產 生的輸出數據，稱輸出框。處理框中從上至下的 順序表明系統操作的次序。
第四章 形式化說明技術
按照形式化的程度，可以把軟件工程使用的 方法劃分爲非形式化、半形式化、形式化3類
【注】
（1）用自然語言描述需求規格說明是典型 的非形式化方法.
（2）用數據流圖或E-R圖建立的模型是典型 的半形式化方法。
（3）形式化方法是描述系統性質的基於數學 的技術，即如果一種方法有堅實的數學基礎，那麼它就是形式化的。
4.2有窮狀態機
Petri網：
Z語言：
第五章，總體設計
總體設計包括：系統設計階段，(確定系統的具體實施方案)和結構設計階段（確定軟件結構）。
從工程管理角度來看，軟件設計分兩步完成：概要設計和詳細設計。、
概要設計 將軟件需求轉化爲軟件體系結構 ，確定系統級接口， 全局數據結構或數據庫模式。
詳細設計 確立每個模塊的實現算法和局部數據結構 ，用適當方法表示算法和數據結構的細節
設計原理(簡答)：
模塊化，
抽象(自頂向下由抽象到具體的方式分配控制)，
逐步求精，
信息隱藏和局部化，
模塊獨立(低耦合，高內聚)，
軟件設計的主要手段
1) 設計應遵循抽象化的原則，包含數據抽象和過程抽象。
過程抽象
是指在軟件設計中將處理過程的實現細節隱藏在數據抽象中，可以直接通過模塊接口使用這些處理操作。
數據抽象
是指採用抽象數據類型表示數據，實現數據封裝，使得使用者可通過接口使用數據而不必關心數據結構的實現。
設計應遵循
自頂向下、逐步細化的原則，建立一個層次的結構。 將軟件體系結構自頂向下，對過程細節和數據細節從抽象到具體，逐層細化，直到用編程語言的語句能夠實現爲止。
設計應當遵循模塊化的原則。
設計應遵循信息隱蔽的原則。
5.2 功能獨立性
耦合性: 耦合是模塊間互相連接的緊密程度的度量，它取決於各個模塊之間接口的複雜度、調用方式以及哪些信息通過接口。
高內聚，低耦合。
模塊之間耦合性越強，功能獨立性越差，這樣形成的模塊結構界面不好。
非直接耦合(Nondirect Coupling)：
兩個模塊之間沒有直接關係，它們之間的聯繫完全是通過主模塊的控制和調用來實現的。 非直接耦合的模塊獨立性最強。
內容耦合 (Content Coupling)
如果發生下列情形，模塊之間就是內容耦合:
一個模塊直接訪問另一個模塊的內部數據;
一個模塊不通過正常入口轉到另一模塊內部;
兩個模塊有一部分程序代碼重迭(只可能出現在彙編語言中);
一個模塊有多個入口。
內聚性：內聚是一個模塊內部各個元素彼此結合的緊密程度的度量。
模塊內聚性越強，功能獨立性越好，對於形成的模塊結構有比較好的作用。 要求模塊結構達到高內聚，低耦合。
功能內聚 (Functional Cohesion)
一個模塊中各個部分都是完成某一具體功能必不可少的組成部分，或者說該模塊中所有部分都是爲了完成一項具體功能而協同工作，緊密聯繫，不可分割的。則稱該模塊爲功能內聚模塊。 功能內聚模塊的功能獨立性最強。
巧合內聚（Coincidental Cohesion）
當幾個模塊內正好有一段代碼是相同的，將它們抽取出來形成單獨的模塊，即巧合內聚模塊。這種模塊沒有獨立功能，各部分之間沒有聯繫，或聯繫很鬆散。
啓發式規則:
3．深度(軟件結構中控制的層數)、寬度(軟件結構中同一層次的模總數的最大值)、扇出(一個模塊直接控制或調用的模塊的數目，一般3-4，上限5-9)和扇入(有多少個上級模塊調用它。)都應適當
描繪軟件結構的圖形工具：描述軟件結構在常用工具是結構圖和層次圖。
層次圖和HIPO圖:
層次圖用來描繪軟件的層次結構。在圖5．2 中已經非正式地使用了層次圖。雖然層次圖 的形式和第3．7節中介紹的描繪數據結構的 層次方框圖相同，但是表現的內容卻完全不 同。
方框間的連線表示調用關係而不像層次方框 圖那樣表示組成關係。層次圖中的一個矩形框代表一個模塊,最頂層的方 框代表正文加工系統的主控模塊，它調用下 層模塊完成正文加工的全部功能；第二層的 每個模塊控制完成正文加工的一個主要功能.
HIPO圖HIPO圖具有可追蹤性，在H圖(層次圖)裏除了 最頂層的方框之外，每個方 框都加了編號。 編。
結構圖
結構圖和層次圖類似，也 是描繪軟件結構的圖形工具，圖中一個方框 代表一個模塊，框內註明模塊的名字或主要 功能；方框之間的箭頭(或直線)表示模塊的 調用關係。尾部是空心圓表示傳遞的是數 據，實心圓表示傳遞的是控制信息。
面向數據流的設計方法：把信息流映射爲軟件結構，信息流的類型決定了映射方法。
面向數據流的設計方法的目標是給出設計軟 件結構的一個系統化的途徑。
（1）在軟件工程的需求分析階段，信息流是 一個關鍵考慮，通常用數據流圖描繪信息在 系統中加工和流動的情況。
（2）面向數據流的設計方法定義了一些不同 的“映射”，利用這些映射可以把數據流圖 變換成軟件結構。
通常所說的結構化設計方法(簡稱SD法 )，也就是基於數據流的設計方法。
數據處理的類型
在需求分析階段，面向數據流的SA方法產生數據流圖DFD。
在軟件設計階段，面向數據流的SD方法將DFD轉換成程序結構圖。
數據處理即爲在DFD中從系統的輸入數據流到系統的輸出數據流所經歷的一連串連續變換。
數據處理的類型分爲變換流型與事務流型。
變換流:
數據沿着輸入通路進入系統，經過一系列數據變換，將數據的外部形式轉換成對應的內部表示，然後通過變換中心（也稱主加工）處理，再沿着輸出通路轉換成外部形式離開系統。具有這種特性的數據流稱爲變換流。
變換流型DFD可以分成： 輸入＋變換中心（主加工）＋輸出
相應於取得數據、變換數據、給出數據，變換流型系統結構圖由輸入、變換中心和輸出等三部分組成。
變換分析
變換分析從變換流型的數據流圖導出系統結構圖.
重畫數據流圖；
區分有效（邏輯）輸入、有效（邏輯）輸出和變換中心部分；
進行一級分解，設計模塊結構的頂層和第一層模塊；
頂層模塊：其功能就是整個系統的功能；
輸入控制模塊：接收所有的輸入數據；
變換控制模塊：實現輸入到輸出的變換；
輸出控制模塊：產生所有的輸出數據。
進行二級分解，設計輸入、輸出和中心變換部分的中、下層模塊。
輸入控制模塊的分解：從變換中心的邊界開始，沿着各輸入通路，把輸入通路上的每個加工映射成輸入控制模塊的一個低層模塊。
輸出控制模塊的分解：從變換中心的邊界開始，沿着各輸出通路，把輸出通路上的每個加工映射成輸出控制模塊的一個低層模塊。
變換控制模塊的分解：變換控制模塊通常沒有通用的分解方法，應根據數據流圖中變換部分的實際情況進行設計。
考試題：
層次圖和結構圖是描述軟件的常用工具
第六章 詳細設計
詳細設計的任務：
- 爲每個模塊確定採用的算法，選擇某種合適的工具表達算法的過程，寫出模塊的詳細過程性描述，
- 確定每一模塊使用的數據結構。
- 確定模塊接口的細節，包括對系統外部的接口和用戶界面，對系統內部其他模塊的接口以及模塊輸入數據。
- 爲每一個模塊設計出一組測試用例。
人機界面設計：系統的響應時間：有兩個重要的屬性，長度和易變度。
6.3過程設計的 工具
描述程序處理過程的工具 稱爲過程設計的工具，它們可以分爲圖形 、表格和語言3類。
程序流程圖：又稱爲程序框圖，它是歷史最悠 久、使用最廣泛的描述過程設計的方法，然 而它也是用得最混亂的一種方法。
程序流程圖中用箭頭代表控制流，程序流程圖不易表示數據結構。
盒圖：N-S圖
出於要有一種不允許違背結構程序設計精神 的圖形工具的考慮，Nassi和Shneiderman 提出了盒圖，又稱爲N-S圖。
特點：
(1)功能域(一個特定控制結構的作用域 )明確，可以從盒圖上一眼就看出來。
(2)不可能任意轉移控制。
(3)很容易確定局部和全程數據的作用域。
(4)很容易表現嵌套關係，也可以表示模塊 的層次結構。
PAD圖
它用二維樹形結構 的圖來表示程序的控制流，將這種圖翻譯 成程序代碼比較容易。
(1)使用表示結構化控制結構的PAD符號所設 計出來的程序必然是結構化程序。
(2)PAD圖所描繪的程序結構十分清晰。圈表語句標號，等號表定義
(3)用PAD圖表現程序邏輯，易讀、易懂、易 記。
(4)容易將PAD圖轉換成高級語言源程序， 這種轉換可用軟件工具自動完成，從而可省 去人工編碼的工作，有利於提高軟件可靠性 和軟件生產率。
(5)即可用於表示程序邏輯，也可用於描繪數 據結構。
(6)PAD圖的符號支持.自頂向下、逐步求精方 法的使用。
6.3.4判定表
當算法中包含多重嵌套的條件選擇時，判定表卻能夠清晰地表示覆雜的條件組 合與應做的動作之間的對應關係。
【判定表的組成】 一張判定表由4部分組成，左上部列出 所有條件，左下部是所有可能做的動作，右 上部是表示各種條件組合的一個矩陣，右下 部是和每種條件組合相對應的動作。判定表 右半部的每一列實質上是一條規則，規定了 與特定的條件組合相對應的動作。
6.5．3判定樹
【判定樹】 判定樹是判定表的變種，也能清晰地表示覆 雜的條件組合與應做的動作之間的對應關係
【判定樹的優點】
（1）它的形式簡單到不需任何說明，一眼就 可以看出其含義，因此易於掌握和使用。
（2）多年來判定樹一直受到人們的重視，是 一種比較常用的系統分析和設計的工具。
過程設計語言(PDL)
也稱爲僞碼，它是用正文 形式表示數據和處理過程的設計工具。 PDL具有嚴格的關鍵字外部語法，用於定義控 制結構和數據結構；另一方面，PDL表示實 際操作和條件的內部語法通常又是靈活自由 的，可以適應各種工程項目的需要。因此， 一般說來，PDL是一種“混雜”語言。
考試題
某物流公司運費計算標準如下：若省內運輸，快遞服務每千克5元，平郵普通包裹資費每千克3元；若省外運輸，重量不超過5千克的快遞服務每千克12元，超重部分按每千克5元計算，重量不超過5千克的平郵普通包裹資費每千克8元，超重部分按每千克3元計算。請用結構化語言（PDL）表示
畫判定樹，判定圖。
面向結構的的設計方法：
.1Jackson方法和Warnier方法是最著名的兩個面向數據結構的設計方法，層次圖表現的是調用關係，而Jackson圖表現的是組成關係。
程序複雜程度的定量度量：McCabe方法，Halstead方法，
第七章 實現
實現：通常把編碼和測試統稱爲實現：
軟件測試在軟件生命週期中橫跨兩個階段。
軟件測試的目標(簡答)：
- 測試是爲了發現程序中的錯誤而執行程序的過程。
- 好的測試方案是極有可能發現迄今爲止尚未發現的錯誤的測試方案，
- 成功的測試是發現了至今爲止尚未發現的錯誤的測試。
測試方法
黑盒測試：功能測試，如果已經知道了產品應該具有 的功能，可以通過測試來檢驗是否每個功能 都能正常使用；
- 等價劃分
- 邊界值分析
- 錯誤推測
白盒測試：結構測試，如果知道產品的內部工作過程 ，可以通過測試來檢驗產品內部動作是否按 照規格說明書的規定正常進行。
- 邏輯覆蓋：是以程序內部的邏輯結構爲基礎的設計測試用例的技術。是對一系列測試過程的總稱， 這組測試過程逐漸進行越來越完整的通路測 試。它屬白盒測試。 語句覆蓋 判定覆蓋 條件覆蓋 判定－條件覆蓋 條件組合覆蓋 路徑覆蓋 點覆蓋 邊覆蓋。
- 控制結構測試：基本路徑測試，調減測試，循環測試，
測試步驟：
-
模塊測試，
-
子系統測試，
-
系統測試，
-
驗收測試，(把軟件系統作爲單一的實體進行測試，測試內容與系統測試基本類似，但是在用戶積極參與下進行的。也稱確認測試)
-
平行運行。
軟件 可靠性：
軟件可靠性的基本定義：軟件可靠性是程序 在給定的時間間隔內，按照規格說明書的規定成功地執行地運行的概率，
軟件的可用性：
程序在給定的時間點，按照規格說明書的規定，成功的運行的概率。
7.4集成測試
集成測試是測試和組裝軟件的系統化技術。
一種方法是先分別測試每個模塊，再把所 有模塊按設計要求放在一起結合成所要的程 序，這種方法稱爲非漸增式測試方法；
另一種方法是把下一個要測試的模塊同已經 測試好的那些模塊結合起來進行測試，測試 完以後再把下一個應該測試的模塊結合進來 測試。這種每次增加一個模塊的方法稱爲漸增式 測試，這種方法實際上同時完成單元測試 和集成測試。
目前在進行集成測試時普遍採用漸增 式測試方法
自頂向下集成：
自頂向下集成方式是一個遞增的組裝軟件結 構的方法。從主控模塊（主程序）開始沿控 制層向下移動，把模塊一一組合起來。分兩 種方法： 第一：先深度：按照結構，用一條 主控制路徑將所有模塊組合起來；第二：先 寬度：逐層組合所有下屬模塊，在每一層水 平地 集成測試 沿着移動。
自底向上集成測試 ：
自底向上的集成方式是最常使用的方法。其 他集成方法都或多或少地繼承、吸收了這種 集成方式的思想。 【集成思想】自底向上集成方式從程序模塊 結構中最底層的模塊開始組裝和測試。因爲 模塊是自底向上進行組裝的，對於一個給定 層次的模塊，它的子模塊（包括子模塊的所 有下屬模塊）事前已經完成組裝並經過測試，所以不再需要編制樁模塊（一種能模擬真實 模塊，給待測模塊提供調用接口或數據的測 試用軟件模塊）。
Alpha和Beta測試：
【Alpha測試】由用戶在開發者的場所進行， 並且在開發者對用戶的“指導”下進行測試。開發者負責記錄發現的錯誤和使用中遇到的問題。總之，Alpha測試是在受控的環境中進行的。
【Beta測試】由軟件的最終用戶們在一個或多個客戶場所進行。與Alpha測試不同，開發者通常不在Beta測試的現場，因此，Beta 測試是軟件在開發者不能控制的環境中的“真實”應用。
軟件維護的基本概念
軟件維護：就是在軟件產品投入使用之後，爲了改正軟件產品中的錯誤或爲了滿足用戶對軟件的新需求而修改軟件的過程。
軟件維護的種類
1.改正性維護：20%
2.適應性維護：25%
3.完善性維護：50%
4.預防性維護：5%
軟件維護的特點：
- 結構化維護與非結構化維護差別巨大；
- 維護的代價高昂
- 維護的問題很多
第九章 面向對象方法學導論
OO = object + class + inheritance + communication with messages
面向對象 = 對象 + 分類 + 繼承 + 消息通信
面向對象即使用對象又使用類和繼承等機制，而且對象直接僅能通過傳遞消息實現彼此通信，
面向對象方法學的優點：
- 與人類習慣的思維方法一致。
- 穩定性好。
- 可重用性好。
- 較易開發軟件產品。
- 可維護性好。
面向對象的概念：
對象：對問題域中某個實體的抽象，設立某個對象就表示系統具有保存有關它的信息與它進行的交互能力。特點：以數據爲中心，對象是主動的，實現了數據的封裝，本質上有並行性，模塊獨立性好。
其他概念：
類：具有相同數據和數據操作的一組相似對象的定義。
實例：由某個實例的類所描述的一個具體的對象。
消息：要求某個對象執行在定義它的那個類中所定義的某個操作的規格說明，接收消息的對象，消息選擇符，零個或多個變元。
方法：對象所能執行的所有操作，就是類中所定義的服務。
屬性：類中所定義的數據，即對客觀世界所具有的性質的抽象。
封裝：有清晰的邊界，有確定的接口(協議)，受保護的內部實現，
繼承：直接獲得已有的性質和特性。
多態性：在類等級的不同層次中可以共享一個行爲的名字。
重載：函數重載，在同一作用域內的若干個參數特徵不同的函數可以使用相同的函數名字，運算符重載，同一運算符可以施加於不同類型的操作數上。
面向對象建模：
3種 形式的模型，、
第一是描述系統數據結構 的對象模型(UML類圖)，
第二是描述系統控制結構的動 態模型(狀態轉化圖)；
第三是描述系統功能的功能模型(用例圖)。
對象模型：：表示靜態的、結構化的系統的“數 據”性質。 它是對模擬客觀世界實體的對象以及對象彼 此間的關係的映射，描述了系統的靜態結構。
類與類之間通常有關聯、泛化(繼承)、依賴和 細化等4種關係。