title: 《軟件工程導論》期末知識點復習
categories: 計算機專業課
tags: "軟件工程"
前言：軟件工程知識點詳解，是在。本書參考《軟件工程導論》第六版，張海藩，紅色的那本。帶*不重要了解一下即可,黑體重點部分,需記憶。
<--more-->
如果有圖片掛了，去這個鏈接，都是本人發的
第一章 軟件工程概論
- *軟件：是計算機程序、方法、規則、相關的文檔以及運行計算機系統時所必需的數據的總和(狹義定義：軟件＝程序+數據+文檔)
- *軟件的特性：軟件是復雜的、軟件是不可見的、軟件是不斷變化的和軟件質量難以穩定。
- *軟件的質量特性：功能性、可靠性、易用性、效率、維護性、可移植性。
- 軟件危機：指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。
- 軟件危機的主要表現：
- 對軟件開發成本和進度估計常常很不準確
- 用戶對"已完成"的系統不滿意的現象經常發生
- 軟件產品的質量往往靠不住
- 軟件常常是不可維護的
- 軟件成本在計算機系統總成本所占的比例逐年上升
- 軟件危機產生的主要原因:
- 軟件日益復雜和龐大
- 軟件開發管理困難和復雜
- 軟件開發技術落后
- 生產方式落后
- 開發工具落后
- 軟件開發費用不斷增加
- 軟件危機如何解決：既要有技術措施（方法和工具），又要有必要的組織管理措施。
- 軟件工程：是指導計算機軟件開發和維護的一門工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它。
- 軟件工程以關注軟件質量為目標，包括方法、過程、工具、范式四個要素。
- 軟件工程方法學：把軟件生命周期全過程中使用的一整套技術方法的集合成為方法學(也稱范型paradigm),包括三個要素:方法,工具和過程.目前使用最廣泛的是傳統方法學和面向對象方法學
- 傳統方法學(也稱生命周期方法學或結構化范型):采用結構化技術(結構化分析,結構化技術,結構化實現)來完成軟件開發的各項任務,并使用適當的軟件工具或軟件環境來支持結構化技術的運用...略太過了
- 面向對象方法學:有4個要點;它是一個多次反復迭代的演化的過程;特有的繼承性和多態性進一步提高了面向對象軟件的可重用性
-
軟件生命周期
軟件生命周期
- 問題定義:確定要解決的問題是什么(通過客戶的訪問調查,系統分析員寫出問題的性質,工程目標和工程規模的書面報告,并得到客戶的確認)
- 可行性研究:不是具體解決問題,而是研究問題的范圍,探索問題是否值得去解,是否有可行的解決方法
- 需求分析:準確確定"為了解決這個問題,目標系統必須做什么",主要是確定目標系統必須具備哪些功能
- 總體設計:設計出目標系統的多種方案;設計程序的體系結構
- 詳細設計:詳細的設計每個模塊,確定要實現模塊功能所需要的算法和數據結構
- 編碼和單元測試:寫出正確的容易理解,容易維護的程序模塊
- 綜合測試:通過各種類型的測試(及相應的的調試)使軟件達到預定的要求
- 軟件維護:通過各種必要的維護活動使系統持久地滿足用戶的需要
- 軟件過程:指為了獲得高質量軟件所需完成一系列任務框架,它規定了完成各項任務的工作步驟;通常使用生命周期模型簡潔地描述軟件過程
- 生命周期模型:也稱過程模型規定了把生命周期劃分成哪些階段及各個階段的執行順序
- 瀑布模型
①瀑布模型特點：
- 階段間具有順序性和依賴性:必須等前一階段的工作完成后之后,才能開始后一段的工作;前一段的輸出文檔就是后一階段的輸入文檔
- 推遲實現的觀點:在編碼之前設置了系統分析和系統設計的各個階段,分析與設計階段的基本任務規定,這兩個階段主要考慮目標系統的邏輯模型,不涉及物理實現
- 質量保證的觀點:每個階段必須完成規定的文檔;每個階段結束前都要對完成的文檔進行評審,以便盡早發現問題
②瀑布模型適用：在開發的早期階段軟件需求被完整確定
③瀑布模型的優點: 可強迫開發人員采用規范的方法;嚴格規定了每個階段必須提交的文檔;要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證
④瀑布模型缺點：瀑布模型是由文檔驅動;最終產品不能真正滿足客戶的需求
- 快速原型模型：首先建立一個反映用戶主要需求的原型系統,讓用戶體驗,之后提出意見,隨之進行修改,再讓用戶體驗...直至用戶完全滿意,據此寫出規格說明文檔
- 增量模型：也稱漸增模型，融合了瀑布模型的基本成分（重復應用）和原型實現的迭代特征，該模型采用隨著日程時間的進展而交錯的線性序列，每一個線性序列產生軟件的一個可發布的“增量”。
- 增量模型優點:人員分配靈活,剛開始不用投入大量人力資源；可先發布部分功能給客戶，對客戶起到鎮靜劑的作用；增量能夠有計劃地管理技術風險。
- 增量模型缺點:需要軟件具備開放式的體系結構；容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性；增加系統內部的耦合復雜性。
- 螺旋模型：把它看作在每個階段之前增加了風險分析的快速原型模型。
- *螺旋模型與增量模型的區別：（1）兩者迭代層級不同：增量模型在活動級迭代；螺旋模型在過程級迭代；（2）兩者需求分析的時間不同：增量模型常常是先做總體需求分析和設計，然后在編碼和測試中逐個增量開發；螺旋模型在開發周期內采用簡化瀑布模型或快速模型；(3)兩者提交軟件的方式不同：增量開發在上次增量的基礎上提交新的一部分軟件；螺旋模型每次迭代都提交一個新的完整的軟件版本；(4)兩者減少風險的方式不同：增量模型使用未成熟技術和經常的客戶反饋等方法減少風險；螺旋模型中直接加進風險識別，風險分析、風險控制，計劃性較強.
- 噴泉模型:典型的具有面向對象軟件開發過程迭代和無縫的特性
-
Rational 統一過程(Rational Unified Process Rational，RUP):
RUP核心：RUP核心是解決可操作性問題，幫助開發人員盡可能少地依賴那些“不可描述的經驗”。RUP特點：用例驅動；以體系結構為中心（高內聚低耦合）；增量和迭代開發。 - RUP最佳實踐
- 迭代式開發:允許每次迭代過程中需求都可以有變化;采用可驗證的方法來減少風險
- 管理需求:RUP采用用例分析來捕獲需求,并由它們驅動設計和實現
- 使用基于構件的體系架構:使用現有的或新開發的構件定義體系結構的系統化方法,從而降低軟件開發的復雜性,提高軟件重用率
- 可視化建模:建立軟件系統的可視化模型,提高管理復雜軟件的能力,如UML
- 驗證軟件質量:軟件質量評估貫穿整個開發過程,由全體成員參與
- 控制軟件的變更:RUP描述了如何控制,跟蹤和監控修改,以確保迭代開發的成功
- RUP軟件開發生命周期
①核心工作流 (縱軸代表核心工作流,橫軸代表時間) 前6個為核心過程工作流, 后3個為核心支持工作流
- 業務建模:深入了解使用目標系統的機構及商務運作評估目標系統對使用它的機構的影響
- 需求:捕獲客戶的需求并且使開發人員和用戶達成對需求描述的共識
- 分析與設計:把需求分析的結果轉化為分析模型和設計模型
- 實現:把設計模型轉化為實現結果
- 測試:檢查各子系統的交互與集成,驗證所有需求是否都被正確實現,識別,確認缺陷并確保在軟件部署之前消除缺陷
- 部署:成功生成目標系統的可運行版本,并將軟件移交給用戶
- 配置與變更管理:跟蹤并維護在軟件過程中產生的所有制品的完整性和一致性
- 項目管理:提供項目管理框架,為軟件開發制定計劃,人員配備,執行和監控等方面的使用準則,并為風險管理提供框架
- 環境:向軟件開發機構提供軟件開發環境,包括過程管理和工具支持
②工作階段
- 初始階段:建立業務模型,定義最終產品視圖,并確定項目的范圍
- 精化階段:設計并確定系統的體系結構,制定項目計劃確定資源需求
- 構建階段:開發出所有構件和應用程序,把它們集成客戶需要的產品,并且詳細地測試所有功能
- 移交階段:把開發出的產品提交給用戶使用
③RUP迭代式開發
第二章 可行性研究
- 可行性研究的目的不是為了解決問題，而是確定問題是否值得去解決
- 可行性：技術可行性、經濟可行性、操作可行性、運行可行性、法律可行性。
- 可行性研究過程：
- 復查系統規模和目標
- 研究正在使用的系統
- 導出新系統的高層邏輯模型
- 進一步定義問題
- 導出和評價供選擇的解法
- 推薦行動方針
- 草擬開發計劃
- 書寫文檔提交審查
- *系統流程圖：是概括地描繪物理系統的傳統工具。用圖形符號以黑盒子形式描繪組成系統的每個部件（程序，文檔，數據庫，人工過程等）。表達的是
數據在系統各部件之間流動的情況
| 符號 | 名稱 | 說明 |
|---|---|---|
| 矩形 | 處理 | 能改變數據值或數據位置的加工或部件。如程序 、處理機、人工加工等都是處理 |
| 平行四邊形 | 輸入輸出 | 表示輸入或輸出，是一個廣義的不指名具體設備的符號 |
| 圓形 | 連接 | 指出轉到圖的另一部分或從圖的另一部分轉來，通常在同一頁上 |
| 矩形下面 加個三角形 | 換頁連接 | 指出轉到另一頁圖上或另一頁圖轉來 |
| 箭頭 | 數據流 | 用來連接其他符號，指明數據流的方向 |
- *數據流圖表示方法：實線表示數據流；虛線表示控制流；圓框代表處理數據的過程；矩形框表示產生與接收數據的對象；平行線表示數據存儲區。
- 數據字典定義組成：數據流；數據流分量（即數據元素）；數據存儲；處理
- 數據字典定義數據的方法（對數據自頂向下分解）：
| 符號 | 含義 |
|---|---|
| = | 等價于或定義為 |
| + | 和(連接兩個分量) |
| [] | 或，多個用|隔開 |
| {} | 重復 |
| () | 可選 |
| 標識符 | 字母字符+字母數字串 |
| 字母數字串 | 0{字母或數字}7 |
| 字母或數字 | [字母字符|數字字符] |
-
成本效益分析的方法及如何運算:
第一步估計開發成本、運行費用和新系統將帶來的經濟效益。需從貨幣時間價值,投資回收期,純收入,投資回收率
方法有三種：
- 代碼行技術：軟件成本=每行代碼的平均成本*估計的源代碼總行數
- 任務分解技術：單本任務成本=任務所需人力估計值*每人每月平均工資；軟件開發項目總成本=每個單獨任務成本估計總和
- 自動估計成本技術：采用自動估計成本的軟件
第三章 需求分析
- 需求分析的任務
- 確定對系統的綜合要求
- 分析系統的數據要求
- 導出系統的邏輯模型
- 修正系統開發計劃
-
分析建模與規格說明
模型: 就是為了理解事物而對事物作出的一種抽象,是對事物的一種無歧義的書面描述。通常，模型由一組圖形符號和組織這些符號的規則組成
需要建立的三種模型：數據模型、功能模型和行為模型
- 實體-聯系圖：描繪數據對象、數據對象的屬性及數據對象之間的關系，用于建立數據模型
- 數據流圖：描繪當數據在軟件系統中流動和被處理的邏輯過程，是建立功能模型的基礎
- 狀態轉換圖：描繪了系統的狀態及引起狀態轉換的事件，是建立行為模型的基礎
- 狀態轉換圖符號含義及怎么畫 P65，P67
- 層次方框圖：是用樹形結構的一系列多層次的矩形框描繪數據的層次結構。最頂層矩形框：代表完整的數據結構；下面各層的矩形框代表數據的子集；最底層的矩形框代表實際數據元素
第四章 形式化說明技術
- 按形式化程度分為三類：
- 非形式化，如用自然語言描述規格說明
- 半形式化，如用數據流圖或實體-聯系圖建立模型
- 形式化，如描述系統性質是基于數學的技術
- 非形式化的缺點
- 矛盾性：在需求規格說明書中對同一問題前后存在不同的描述
- 二義性：讀者可以用不同的方式理解的陳述
- 含糊性：需求規格說明書對某一問題描述不清晰，不可理解
- 不完整性：需求規格說明書對某一問題只說明了局部，沒說明整體
- 抽象層次混亂：指在非常抽象的陳述中混入了關于低層次的細節陳述
- 形式化的優點：
- 能夠簡潔準確的描述物理現象、對象或動作的結果
- 在不同的軟件工程活動之間平滑過渡
- 提供了高層確認的手段
- 應用形式化準則
- 選用適當的表示方法
- 應該形式化，但不要過分形式化
- 應該估算成本
- 應該有形式化顧問隨時提供咨詢
- 不應該放棄傳統的開發方法
- 應該建立詳盡的文檔
- 不應該放棄質量標準
- 應該測試，測試再測試
- 應該重用
第五章 總體設計
-
設計過程：2個階段(
系統設計階段:確定系統的具體實現方案 和結構設計階段:確定軟件結構); 9個步驟：
- 設想供選擇的方案
- 選取合理的方案
- 推薦最佳方案
- 功能分解
- 設計軟件結構
- 設計數據庫
- 制定測試計劃
- 書寫文檔
- 審查和復審
- 設計原理的相關概念
- 模塊化：就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求
- 抽象：抽出事物本質特性而暫時不考慮細節
- 逐步求精：為了能集中精力解決最主要問題而盡量推遲對問題細節的考慮。逐步求精是人類解決復雜問題時采用的基本方法，也是許多軟件工程技術的基礎
- 信息隱藏：應該這樣設計和確定模塊，使得一個模塊內包含的信息對于不需要這些信息的模塊來說是不能訪問的
- 局部化：是指把一些關系密切的軟件元素物理地址放得彼此靠近
- 模塊獨立：是模塊化、抽象、信息隱藏和局部化的概念的直接結果。獨立的程度測量標準：內聚、耦合
- 耦合：是對一個軟件結構內不同模塊之間互連程度的度量。耦合強弱取決于模塊間接口的復雜程度，進入或訪問一個模塊的點，以及通過接口的數據。耦合程度強烈影響著系統的可理解性、可測試性、可靠性、可維護性。設計原則：盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境的耦合的范圍，完全不用內容耦合。
- 數據耦合：如果兩個模塊彼此間通過參數交換信息，而且交換的信息僅僅是數據。數據耦合是低耦合
- 控制耦合：傳遞的信息中有控制信息。中等耦合，增加了系統的復雜性
- 特征耦合：當整個數據結構作為參數傳遞而被調用的模塊只需要使用其中一部分數據元素時
- 公共環境耦合：當兩個或對個模塊通過一個公共數據環境互相作用時。公共環境可以是全程變量、共享通信區、內存的公共覆蓋區、任何存儲介質的文件、物理設備等。
- 內容耦合：如果發生之一就是①一個模塊訪問另一個模塊的內部數據,②一個模塊不通過正常入口而轉到另一個模塊的內部,③兩個模塊有一部分程序代碼重疊,④一個模塊有多個入口
- 內聚：標志著一個模塊內各個元素彼此之間結合的緊密程度，它是信息隱藏和局部化概念的擴展。設計原則：力求高內聚，通過提高模塊間的內聚降低耦合從而使模塊獲得較高的獨立性。高內聚意味著低耦合
- 低內聚
- 偶然內聚：如果一個模塊完成一組任務，這些任務彼此之間有關系，關系也是很松散的。如在一個程序內有一組語句在兩處或多處出現，于是把這些語句作為一個模塊以節省內存
- 邏輯內聚：如果一個模塊完成的任務在邏輯上屬于相同或相似的一類。如一個模塊產生各種類型的全部輸出
- 時間內聚：如果一個模塊包含的任務必須在同一時間內執行。如模塊完成各種初始化工作
- 中內聚
- 過程內聚：如果一個模塊內的處理元素是相關的，且必須以特定次序執行。如流程圖確定模塊的劃分，得到的往往是過程內聚的模塊
- 通信內聚：如果一個模塊中所有元素都是用同一個輸入數據和產生同一個輸出數據
- 高內聚
- 順序內聚：如果一個模塊內的處理元素和同一個功能密切相關，且這些處理必須順序執行。如一個處理元素的輸出數據作為下一個處理元素的輸入數據，根據數據流圖劃分模塊得到往往是順序內聚模塊
- 功能內聚：如果模塊內的所有處理元素屬于一個整體，完成單一的功能
- 7種內聚的優劣評分
| 名稱 | 得分 |
|---|---|
| 功能內聚 | 10 |
| 順序內聚 | 9 |
| 通信內聚 | 7 |
| 過程內聚 | 5 |
| 時間內聚 | 3 |
| 邏輯內聚 | 1 |
| 偶然內聚 | 0 |
- 啟發規則
- 改進軟件結構提高模塊的獨立性
- 模塊規模應該適中
- 深度、寬度、扇出和扇入都應適當
- 模塊的作用域應該在控制域內
- 力爭降低模塊接口的復雜程度
- 設計單入口單出口的模塊
- 模塊的功能應該可預測
- 描繪軟件結構的圖形工具（例子見P102,P103）
- 層次圖：描繪軟件的層次結構。一個矩形框代表一個模塊，方框間的連線表示調用關系
- HIPO圖：“層次圖加輸入/處理/輸出圖”，就是在層次圖的每個方框加編號
- 結構圖：每個方框代表一個模塊，框內注明模塊的名字或主要功能，方框間的箭頭（或直線）代表模塊的調用關系，注釋表示來回傳遞的信息【尾部空心圓表示傳遞數據，實心圓代表傳遞控制信息】
第六章 詳細設計
- 人機界面設計指南：P123,P124
- 一般交互指南
- 信息顯示指南
- 數據輸入指南
- 程序流程圖：
- 優點：對控制流程的描繪直觀，初學者很容易掌握
- 缺點：①程序流程圖不是精益求精的好工具嗎，它誘使程序員過早地考慮程序的控制流程，而不去考慮全局結構②程序流程圖中用箭頭代表控制流 ，因此程序員不受任何約束，可以完全不顧結構程序設計的思想，隨意轉移③程序流程圖不易表示數據結構
- 盒圖（N-S圖）的特點：
- 功能域明確
- 不可能任意轉移控制
- 很容易確定局部和全局數據的作用域
- 很容易表現嵌套關系，也可以表示模塊的層次結構
- 問題分析圖（PAD圖）：使用二維結構的圖來表示程序的控制流。其優點：
- 使用PAD符號設計出來必然是結構化程序
- PAD圖描繪的程序結構十分清楚
- PAD圖表現程序的邏輯，易讀、易懂、易記
- 很容易將PAD圖轉化為高級語言程序
- 即可表示程序邏輯，也可表示數據結構
- PAD符號支持自動向下，逐步求精
- 判定表：當算法中含有多重嵌套的條件選擇時
- 優點：能清晰表示復雜的條件組合與應做的動作之間的關系
- 缺點：①判定表的含義不能一眼看出來②當數據元素多于兩個時，判定表的簡潔程度下降
- 判定樹：判定表變種
- 優點：一眼看出其含義，易于掌握，使用
- 缺點：①簡潔性不如判定表，數據元素需重復寫多遍②判定樹的分支次序對畫出的判定樹的簡潔程度有較大影響
- PDL（過程設計語言）：也稱偽碼，具有嚴格的關鍵字外部語法，用于定義控制結構和數據結構，內部語法靈活自由，適應各種工程項目。
其優點：
- 可作為注釋直接插在源程序中間
- 可使用普通的正文編輯程序或文字處理系統完成PDL的書寫和編輯
- 已有自動處理PDL的程序，可自動生成程序代碼
其缺點：
- 不如圖形工具形象直觀，描述復雜的條件組合與動作間的對應關系時，不如判定表清晰簡單
- McCabe方法：McCabe根據程序控制流的復雜程度度量 程序的復雜程度，這樣度量出的結果稱為程序的環形復雜度
①流圖的表示：
- 結點：用圓表示，一個圓代表一條或多條語句
- 邊：箭頭線稱為邊，代表控制流
- 區域：由邊和結點圍成的面積 稱為區域，當計算區域數時應該包括圖外未被圍起來的區域
- 判定結點：包含條件的結點
②計算環形復雜度的方法:
- 流圖中線性無關的區域數等于環形復雜度
- 流圖G的環形復雜度
V(G)=E-N+2,其中E是流圖中邊的條數，N是結點數 - 流圖G的環形復雜度
V(G)=P+1,其中P是流圖中判定結點的數目
第七章 實現
編碼：把詳細設計結果翻譯成某種程序語言書寫的程序
軟件測試：是保證軟件質量的關鍵步驟，是對軟件規格說明、設計和編碼的最后復審
第七章實現(編碼和測試).png
補充
測試用例：所謂測試用例是為特定的目的而設計的一組測試輸入、執行條件和預期的結果；測試用例是執行測試的最小實體。
白盒測試主要用于對模塊的測試，包括：程序模塊中的所有獨立路徑至少執行一次；對所有邏輯判定的取值（“真”與“假”）都至少測試一次；在上下邊界及可操作范圍內運行所有循環；測試內部數據結構的有效性等。
黑盒測試可用于各種測試，它試圖發現以下類型的錯誤：不正確或遺漏的功能；界面錯誤；數據結構錯誤或外部信息(如外部數據庫)訪問錯誤；性能錯誤；初始化和終止錯誤。
第八章 維護
- 軟件維護的定義：就是在軟件已經交付使用之后，為了改正錯誤或滿足新的需要而修改軟件的過程
- 結構化維護和非結構化維護
①非結構化維護
- 如果軟件配置的唯一成分是程序代碼，那么維護活動從評價代碼開始，而且由于內部文檔不足而使評價更困難
- 非結構化維護需要付出巨大代價，是沒有使用良好定義的方法學開發出來的必然結果
②結構化維護 - 如果有一個完整軟件配置存在，那么維護從評價設計文檔開始就很規范
- 減少精力的浪費，提高維護的總體質量
- 決定軟件可維護的因素：
- 可理解性
- 可測試性
- 可修改性
- 可重用性
第八章 面向對象方法學引論
- 面向對象方法學要點：
①基本原則：盡可能模擬人類習慣的思維方式，是開發軟件的方法和過程盡可能接近人類認識的世界解決問題的方法和過程
②4個要點
- 軟件是由對象組成的，任何元素都是對象，復雜軟件對向由比較簡單的軟件對象組成
- 所有對象都劃分成對象類，類都定義了一組數據和一組方法
- 若干對象類組成一個層次的系統
- 對象間僅能通過傳遞消息互相聯系
③面向對象方法學優點 - 與人類習慣的思維方法一致
- 穩定性好
- 可重用性好
- 較易開發大型軟件產品
- 可維護性好
- 對象：是描述該對象屬性的數據以及對這些數據施加的所有操作封裝在一起構成的統一體
①對象的定義
- 對象是具有相同狀態的一組操作的集合
- 對象是對問題域中某個東西的抽象
- 對象::=<ID,MS,DS,MI>。ID是對象的標識或名字，MS操作集合，DS數據結構，MI對象受理的消息名集合
②對象的特點 - 以數據為中心
- 對象是主動
- 實現了數據的封裝
- 本質上具有并行性
- 模塊獨立性好
- 其它概念
- 類：是一組具有相同屬性和相同操作的對象的集合。
- 實例：由某個特定的類所描述的一個具體的對象。
- 消息：要求某個對象執行在定義它的那個類中所定義的某個操作的規格說明。組成部分：接收消息的對象；消息名；消息變元
- 方法：就是對象所能執行的操作，也就是類中所定義的服務。
- 屬性：屬性就是類中所定義的數據，它是對客觀世界實體所具有的性質的抽象。
- 封裝：對象封裝了對象的數據以及對這些數據的操作。
- 繼承：繼承是子類自動地共享基類中定義的數據和方法的機制。
- 單重繼承：子類僅從一個父類繼承屬性和方法
- 多重繼承：子類可從多個父類繼承屬性和方法
- 多態性：指子類對象可以像父類那樣使用
- 函數重載：指在同一作用域內的若干參數特征不同的函數可以使用相同的函數名
- 運算符重載：指在同一個運算符可以施加于不同類型的操作數上面
第十章 面向對象分析
- 建立對象模型
①三個子模型，按所解決的問題進行劃分
- 靜態結構（對象模型）
- 交互次序（動態模型）
- 數據變換（功能模型）
②5個層次
- 主題層
- 類與對象層
- 結構層
- 屬性層
- 服務層
③對象模型創建的步驟
- 確定類與對象
- 確定關聯
- 劃分主題
- 確定屬性
- 識別繼承關系
- 反復修改
第十一章 面向對象設計
- 面向對象設計準則
- 模塊化
- 抽象
- 信息隱藏
- 弱耦合
- 強內聚
- 可重用
- 類構件的重用方式：
- 實例重用
- 繼承重用
- 多態重用
