軟件工程的定義及分類(填空選擇)
軟件工程:
①將系統性的、規范化的、可定量的方法應用于軟件的開發、運行和維護，即工程化應用到軟件上；
②對①中所述方法的研究。

軟件=程序+數據+文檔
分類:系統軟件、支撐軟件、應用軟件

軟件工程產生的原因(選擇)
1968 年北大西洋公約組織在前聯邦德國開會提出軟件工程的概念，要用工程化的思想解決軟件危機。
軟件危機是指在計算機軟件的開發和維護過程中遇到的一系列嚴重問題。

[單選] 軟件工程學科出現的主要原因是（）。
A . 計算機的發展
B . 其他工程學科影響
C . 軟件危機的出現
D . 程序設計方法學的影響

軟件工程方法學三要素(填空選擇)
過程：支持軟件生命周期的所有活動,整個一系列的動作如何組織，動作之間的關系
方法：為軟件開發過程提供“如何做”的技術
工具：為軟件開發方法提供自動的或半自動的軟件支撐環境,計算機輔助軟件工程

軟件工程方法學的三要素是（）。
①方法
②項目管理
③過程
④開發語言
⑤工具

A．①②③
B．①②⑤
C．②③④
D．①③⑤

軟件生命周期劃分及各階段的主要任務(填空選擇重點)
(1)軟件生命周期軟件定義、軟件開發、和運行維護3個階段組成
具體劃分:問題的定義、可行性研究、軟件需求分析、系統總體設計、詳細設計、編碼、測試和運行、維護


軟件開發的瀑布模型，一般都將開發過程劃分為：分析、設計、編碼和測試等階段，一般認為可能占用人員最多的階段是( )
A.分析階段 B.設計階段
C.編碼階段 D.測試階段

正確答案：C

問題定義：
（1）確定要開發軟件系統的總目標和規模。
（2）從技術、經濟和社會因素等方面的要求來論證完成該軟件任務的可行性。
（3）估計可利用的資源(計算機硬件，軟件，人力等)、成本、效益、開發進度。
（4）制定出完成開發任務的實施計劃,連同可行性研究報告，提交管理部門審查。
需求開發：
（1）調查、分析、整理用戶需求；
（2）建立需求分析模型；
（3）編寫軟件需求規格說明書，提交管理部門審查
軟件設計：
（1）根據需求規格說明書，確定軟件的體系結構；
（2）設計每個系統部件的實現算法、數據結構及接口等；
（3）編寫軟件設計說明書，并提交管理部門審查。
軟件構造（編碼）：
（1）根據軟件設計說明書，進行程序設計；
（2）編寫功能實現代碼；
（3）編寫測試代碼。
軟件測試：檢測和驗證所開發的系統是否滿足需求，包括：
（1）單元測試；
（2）集成測試；
（3）確認測試；
（4）系統測試
軟件維護：
對系統進行改進，以適應不斷變化的需求

軟件過程模型及特點(選擇填空)


瀑布模型：特點：嚴格按照步驟，文檔驅動型，從上到下
快速原型模型：思想：和客戶交流能很快構造模型，通過模型討論，完善功能
做UI界面，做一些簡單的模擬展示
螺旋模型：有風險評估，每次迭代，都要風險評估，適合大型項目，投入大風險高

模塊的獨立性指標(填空選擇)
內聚和耦合
內聚:模塊里面的關系
耦合:模塊之間聯系的指標
內聚最高:功能內聚
內聚最低:巧合內聚
耦合最高:內容耦合
耦合最低:非直接耦合

內聚和耦合是主要描述模塊內外聯系的，所以我們了解內聚和耦合之前，我們先了解一下模塊
模塊：就是為了完成某一功能所需的一段程序或是子程序；或是能夠編譯程序、裝配程序等處理的獨立程序單位；或是指大型軟件系統的一部分
模塊化：能夠把一個大而復雜的軟件系統劃分成易于理解的比較簡單的模塊結構。（按功能域劃分
基本屬性
?? 1. 功能：描述該模塊實現什么功能
?? 2. 邏輯：描述模塊內部
?? 3. 狀態：該模塊使用時的環境和條件
??模塊的獨立性：軟件在系統中每個模塊設計軟件要求的具體的子功能
??它的獨立性的度量準則：模塊間的耦合和內聚
??好的模塊：高內聚，低耦合（主要是面向對象的設計，看類的內聚度是否高，耦合度是否低)
??高內聚，低耦合的好處：在系統的持續發展中，它會使系統有很好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務發展！

內聚
內聚主要描述的是模塊內功能的聯系，高內聚就是模塊內功能聯系比較緊密，代碼的相關性特別的強，程序設計的比較嚴謹！
內聚的分類
1 功能內聚（最理想的內聚）
??一個模塊中各個部分都是完成某一具體功能必不可少的組成部分，是不可分割的
??功能內聚是最強的內聚，其最大的優點是它的功能明確。判斷一個模塊是否功能內聚，一般從模塊名稱就能看出。如果模塊名稱只有一個動詞和一個特定的目標（單數名詞），一般來說就是功能內聚，如：“計算水費”、“計算產值”等模塊。功能內聚一般出現在軟件結構圖的較低層次上
??功能內聚模塊的一個重要特點是：他是一個“暗盒”，對于該模塊的調用者來說，只需要知道這個模塊能做什么，而不需要知道這個模塊是如何做的
2 信息內聚
??這個模塊完成多個功能，各個功能都在同一數據結構上操作，每一項功能有一個唯一的入口點
3 通信內聚
??如果一個模塊內各功能部分都使用了相同的輸入數據，或產生了相同的輸出數據，則稱之為通信內聚模型
4 過程內聚
??使用流程作為工具設計程序時，把流程圖中的某一個部分劃分出組成模塊，就得到過程內聚模塊
5 時間內聚
??時間內聚模塊的各個功能的執行與時間有關，通常要求所有功能必須在同一時間段內執行
6 邏輯內聚
??這種模塊把幾種相關功能組合在一起
7 巧合內聚
??各部分之間沒有聯系，或者即使有聯系，這種聯系也很松散。

耦合可以分為以下幾種，它們之間的耦合度由高到低排列如下
（1） 內容耦合：如果發生下列情形，兩個模塊之間就發生了內容耦合
一個模塊直接訪問另一個模塊的內部數據;
一個模塊不通過正常入口轉到另一模塊內部;
兩個模塊有一部分程序代碼重迭(只可能出現在匯編語言中);
一個模塊有多個入口。
（2） 公共耦合：若一組模塊都訪問同一個公共數據環境，則它們之間的耦合就稱為公共耦合。公共的數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。
（3） 外部耦合： 一組模塊都訪問同一全局簡單變量而不是同一全局數據結構，而且不是通過參數表傳遞該全局變量的信息，則稱之為外部耦合。
（4） 控制耦合：如果一個模塊通過傳送開關、標志、名字等控制信息，明顯地控制選擇另一模塊的功能，就是控制耦合。
（5） 標記耦合：一組模塊通過參數表傳遞記錄信息，就是標記耦合。這個記錄是某一數據結構的子結構，而不是簡單變量。
（6） 數據耦合：一個模塊訪問另一個模塊時，彼此之間是通過簡單數據參數 (不是控制參數、公共數據結構或外部變量) 來交換輸入、輸出信息的。
（7） 非直接耦合：兩個模塊之間沒有直接關系，它們之間的聯系完全是通過主模塊的控制和調用來實現的
（8）順序耦合：是靜態耦合性的一種，為了保持正確性，兩個元素(一般是函數或API)必須以特定的順序出現。

軟件結構的深度、寬度、扇入、扇出的定義？(填空選擇)
結構圖的深度指模塊的層數
寬度指一層中最大的模塊數
扇出指一個模塊直接調用下屬模塊的個數
扇入指一個模塊直接上屬模塊的個

下面軟件結構圖的深度、第二層的寬度、A模塊的扇出和B模塊的扇入分別為（A）
A．4、3、3、1
B．4、2、3、1
C．4、3、1、3
D．4、2、1、3．

數據流圖的基本要素及畫法(填空題)
數據流圖（Data Flow Diagram,簡稱DFD）描繪系統的邏輯模型，是結構化系統分析的主要工具。數據流圖(DFD)是描述軟件系統中數據處理過程的一種有力的圖形工具。
數據流圖描述輸入數據流到輸出數據流的變換（加工），用于對系統的功能建模。
采用自頂向下逐層分解，描繪滿足用戶要求的軟件模型。
基本要素
數據源點：產生數據的地方
數據終點：數據的最終消費者
數據處理：數據的加工過程
數據流：在系統中進行流動的數據。
數據存儲：存儲數據的地方


畫分層DFD的指導原則:
父圖-子圖平衡:模型分解時必須保持父圖的輸入輸出數據流和子圖輸入輸出數據流相同。
局部數據存儲:出現在加工之間的界面時，才畫出來
編號:子圖圖號為分解的父圖中的加工號，同級子圖在最后數字以序號區別。
分解的程度:按功能情況定，一般設深度為3-5；同一層次超過5個加工，最好分解畫，否則容易出錯。

數據流圖的分析步驟:
找出數據流圖的四種組成要素。
源點和終點、數據處理、數據存儲、數據流。
畫出基本系統模型。
把軟件系統看作一個整體單元，描述它與外部環境的數據交互關系。
畫出功能模型。
把系統劃分出幾個主要的數據處理步驟，描述系統內部之間的數據流動關系。
數據流圖細化。
對數據處理進行進一步細化，形成詳細的數據流圖。

ER圖的基本要素及畫(分析題)
實體：矩形
屬性：橢圓
屬性-實體 線條
實體-實體有關系 用菱形
映射基數 多對多

數據庫邏輯設計內容及做法(同第九題一起出)
邏輯設計就是將ER圖轉為關系模式
考試第一步畫ER圖，第二部轉換他的關系模
每一個實體他是可以轉為一個關系模式，每一個關系也可以轉為一個關系模式
關系里面根據映射的多少轉換的方式也不一
還要注意：映射完后，主關鍵字能標注出來，畫下劃線

題目:

向數據流的設計方法(非分析題)
數據流->結構圖就是面向數據流的設計方法
兩種數據流 變換型，事物型
變換型：映射為哪三個部分：傳入路徑 變換中心 傳出路徑
變換型分析的設計步驟:

(1）確定DFD的變換中心、邏輯輸入和邏輯輸出
(2）設計軟件結構的頂層和第一層:變換結構
(3）設計中、下層模塊
(4）設計的優化
事物型：事務型結構由至少一條接受路徑、一個事務中心與若干條動作路徑組成。

事務分析的設計步驟：
⑴確定事務中心和加工路徑?
⑵設計頂層（事務機構）和第一層?頂層模塊有兩個功能：接收數據和根據事務類型調動相應處理模塊。?
⑶中下層模塊的設計﹑優化工作與變換結構相同。?
事務型軟件結構包括兩部分：?接收分支?發送分支
通常包括一調度模塊，當事務類型不多時，可與主模塊合并

面向對象思想(分數多,填空選擇問答)
基本觀點：

1）對象：客觀世界由對象組成
2）類：對象可以歸并為一個類
3）對象之間有繼承關系
4）對象直接有聯系，通過通信，成為消息
面向對象三大特征
封裝繼承多態
1）封裝:將客觀事物抽象成類，每個類對自身的數據和方法實行protection (private，protected,public)
2）繼承:廣義的繼承有三種實現形式:實現繼承(指使用基類的屬性和方法而無需額外編碼的能力)、可視繼承(子窗體使用父窗體的外觀和實現代碼)、接口繼承(僅使用屬性和方法，實現滯后到子類實現)。前兩種（類繼承)和后一種（(對象組合=>接口繼承以及純虛函數）構成了功能復用的兩種方式。
3）多態:是將父對象設置成為和一個或更多的與他的子對象相等的技術，賦值之活，父對象就可以根據當前賦值給它的子對象的特性以不同的方式運作。簡單的說，就是一句話:允許將子類類型的指針賦值給父類類型的指針。

面向對象分析中領域建模任務(分析題)
識別出分析類
考大題，給一個業務描述，這里面識別出來幾個類，類圖怎么畫
類的識別方法：分析類，邊界類，控制類，實體類

題目: 汽車和自行車都是交通工具。一輛自行車只能歸一個人擁有，但一輛汽車可歸一個人或者兩個人擁有。一個人可能沒有自行車或汽車.也可能擁有多輛自行車或汽車。人分男人和女人兩類，每個人都具有年齡和名字。在任何時候，一輛汽車上可能載有0個多個乘客。每輛汽車都有自己的顏色和商標。特別地，每輛汽車都只有兩個前燈和一臺發動機。請畫出類圖。

面向對象設計的七大原則(考一兩個原則概念填空題)
開閉原則
里氏代換原則
最少知道原則
單一職責原則
接口隔離原則
依賴倒轉原則
合成復用原則
(1) 單一職責原則(Single Responsibility Principle, SRP)
定義：
??類的職責要單一，一個類只負責一項職責
分析：
??一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作
作用：
??降低代碼復雜度、系統解耦合、提高可讀性
注意：
??通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級違反單職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則。

(2) 接口隔離原則(Interface Segregation Principle, ISP)
定義：
??客戶端不應該依賴那些它不需要的接口。 一旦一個接口太大，則需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可

分析:
接口隔離原則是指使用多個專門的接口，而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色，不多不少，不干不該干的事，該干的事都要干。
一個接口就只代表一個角色，每個角色都有它特定的一個接口，此時這個原則可以叫做“角色隔離原則”。
接口僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的接口，而不要提供大的總接口。
使用接口隔離原則拆分接口時，首先必須滿足單一職責原則，將一組相關的操作定義在一個接口中，且在滿足高內聚的前提下，接口中的方法越少越好。
可以在進行系統設計時采用定制服務的方式，即為不同的客戶端提供寬窄不同的接口，只提供用戶需要的行為，而隱藏用戶不需要的行為。

作用：
?? 避免接口過于臃腫職責不單一。

(3) 依賴倒轉原則(Dependency Inversion Principle, DIP)
定義：
??高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節，細節應該依賴于抽象。

分析：
??簡單來說，依賴倒轉原則就是指：代碼要依賴于抽象的類，而不要依賴于具體的類；要針對接口或抽象類編程，而不是針對具體類編程。
??通過面向接口編程，使用接口或者抽象類制定好規范和契約，而不去涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成。

作用：
??避免需求變化導致過多的維護工作。

注意：
??依賴注入，就是將一個類的對象傳入另一個類，注入式應該盡量注入父類對象，而在程序運行時再通過子類對象來覆蓋父類對象。
??繼承時遵循里氏替換原則。

(4) 里氏代換原則(Liskov Substitution Principle, LSP)
定義：
??所有引用基類（父類）的地方必須能透明地使用其子類的對象。

分析:
子類可以實現父類的抽象方法，但是不能覆蓋父類的非抽象方法；
子類中可以增加自己特有的方法；
當子類覆蓋或實現父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松；
當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。
如果子類不能完整地實現父類的方法，或者父類的一些方法在子類中已經發生畸變，則建議斷開繼承關系，采用依賴，聚合，組合等關系代替繼承。
里氏代換原則是實現開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。

作用：
??避免系統繼承體系被破壞。

(5) 開閉原則(Open-Closed Principle, OCP)
定義：
??一個軟件實體應當對擴展開放(對提供方)，對修改關閉(對使用方)。也就是說在設計一個模塊的時候，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。

分析：
??設計模式前面6大原則以及23種設計模式遵循的好，開閉原則自然遵守的好。對需求的變更保持前瞻性和預見性，就可以使抽象具有更廣泛適用性，設計出的軟件架構就能相對穩定。軟件需求中易變的細節，通過從抽象派生出實現類來擴展。

作用：
??提高擴展性、便于維護。

(6) 迪米特法則(Law of Demeter, LoD)
定義:
又稱為最少知識原則。
不要和“陌生人”說話。
只與你的直接朋友通信。
每一個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位。

分析:
一個對象應該對其他對象保持最少的了解。
類與類關系越密切，耦合度越大。
迪米特法則(DemeterPrinciple)又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外泄露任何信息。
迪米特法則還有個更簡單的定義：只與直接的朋友通信。
直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。
??耦合的方式很多，依賴，關聯，組合，聚合等。其中，我們稱出現成員變量，方法參數，方法返回值中的類為直接的朋友，而出現在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變 量的形式出現在類的內部。

作用：
??降低類與類之間的耦合。

注意：
??迪米特法則的核心是降低類之間的耦合,但是，由于每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間(對象間)耦合關系， 并不是 要求完全沒有依賴關系

(7) 合成復用原則(Composite Reuse Principle, CRP)
定義：
??盡量使用對象組合，而不是繼承來達到復用的目的。

分析:
合成復用原則就是指在一個新的對象里通過關聯關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；
新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關系，少用繼承。
在面向對象設計中，可以通過兩種基本方法在不同的環境中復用已有的設計和實現，即通過組合/聚合關系或通過繼承。
組合/聚合可以使系統更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實現復用；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的復雜度，因此需要慎重使用繼承復用。

目的：
??防止類的體系龐大。

狀態圖的組成組成元素及畫法(分析題)
一個業務里有哪些狀態，初態 終態，狀態（圓角矩形），轉換（狀態之間有外部干擾時會從一種狀態轉換為另一種狀態
狀態圖的概念于1987年由Harel提出，采用狀態、事件等圖形符號來描述系統的行為。

題目:辦公室復印機的工作過程大致如下，請畫出復印機的狀態轉換圖。
未接到復印命令時處于閑置狀態，信息燈呈黃色，屏幕熄滅；
當接到復印命令則進入復印狀態，信息燈呈綠色，屏幕點亮；
完成一個復印命令規定的工作后，10秒內沒有收到復印命令又回到閑置狀態，繼續等待下一個復印命令；
執行復印命令時發現缺紙，則進入缺紙狀態，發出警告聲，等待裝紙，裝滿紙后進入閑置狀態，準備接受復印命令；
如果復印時發生卡紙故障，則進入卡紙狀態，信號燈呈紅色，發出警告聲，等待維修人員排除故障，故障排除后回到閑置狀態。

用例圖組成元素及畫法(分析題)
了解參與者期望什么，期望系統干什么，有意義的目標為用例
參與者用小人，用例用橢圓形表示，系統邊界框起來

用例描述的幾種方法(問答題分析題)
重點是描述用例，參與者是什么，前置條件是什么，操作流程是什么
文本和圖形兩種方式
圖形描述用活動圖，涉及到多個參與者泳道圖

用例圖只是簡單地用圖描述了一下系統，但對于每個用例，我們還需要有詳細的說明，這樣就可以讓別人對這個系統有一個更加詳細的了解，這時我們就需要寫用例描述。

對于用例描述的內容，一般沒有硬性規定的格式，但一些必須或者重要的內容還是必須要寫進用例描述里面的。用例描述一般包括：簡要描述（說明）、前置（前提）條件、基本事件流、其他事件流、異常事件流、后置（事后）條件等等。下面說說各個部分的意思：

簡要描述：對用例的角色、目的的簡要描述；

前置條件：執行用例之前系統必須要處于的狀態，或者要滿足的條件；

基本事件流：描述該用例的基本流程，指每個流程都“正常”運作時所發生的事情，沒有任何備選流和異常流，而只有最有可能發生的事件流；

其他事件流：表示這個行為或流程是可選的或備選的，并不是總要總要執行它們；

異常事件流：表示發生了某些非正常的事情所要執行的流程；

后置條件：用例一旦執行后系統所處的狀態；

題目：家教網站分為前臺客戶系統和后臺管理系統

時序圖的組成及畫(同13類分析出題)
進一步識別類與類之間的交互關系，時序圖描述，強調的是一個時間概念，類與類之間有一個時間的先后順序，一種是橫軸類，縱軸時間，從上之下遞增，虛線是生命線，起始對象開始，從上至下，從左至右畫消息，那個對象和哪個對象會發送消息，消息要編號
消息兩種，正向的消息用實線，反饋的用虛線

構件圖的基本元素及畫法(填空選擇)
組成元素:構件 依賴關系 需求接口 提供接口
1，組件圖又稱為構件圖(Component Dlagram)。組件圖中通常包括組件、接口，以及各種關系。組件圖顯示組件以及它們之間的依賴關系，它可以用來顯示程序代碼如何分解成模塊或組件。一般來說，組件就是一個實際文件，可以有以下幾種類型:
源代碼組件:一個源代碼文件或者與一個包對應的若干個源代碼文件。
二進制組件:—個目標碼文件，一個靜態的或者動態的庫文件。
可執行組件:在一臺處理器上可運行的一個可執行的程序單位，即所謂可執行程序。
2，組件圖可以用來顯示編譯、鏈接或執行時組件之間的依賴關系，以及組件的接口和調用關系。
3，組件間的關系有兩種:泛化關系和依賴關系，如果兩個不同組件中的類存在泛化關系或依賴關系，那么兩個組件之間的關系就表示為泛化關系或依賴關系。
4，對于由多個組件組成的大系統來說，組件圖非常重要。