第一章 面向物件及軟體建模概述
1 軟體與軟體工程
軟體： 程式＋文件＋資料
特點：
（1）軟體規模大。
（2）軟體開發規範並趨於標準化。
（3）軟體開發方法多，有大量的軟體工具支援。
（4）注重軟體開發的管理。
（5）軟體維護相對過去容易得多。
§軟體工程的指導性原則：變動的軟體需求。
穩妥的設計方法。
高效的軟體開發支援技術。
有效的過程管理。
§軟體工程具有里程碑意義的進展：結構化軟體開發方法的工具。
計算機輔助軟體工程（CASE）。
面嚮物件語言和方法成為主流的軟體開發技術。
2 生存週期和開發模型的演變
一、軟體生命週期
二、開發模型：
軟體開發模型是軟體開發全部過程、活動和任務的結構框架。
軟體開發模型能清晰、直觀的表達開發全部過程，明確規定了要完成的主要活動、任務和開發策略，可以作為軟體專案開發工作的基礎。
(1)瀑布模型 (2)原型模型 (3)OO模型
（1）瀑布模型
（1）瀑布模型——特點
§1. 順序性和依賴性1）前結束，後開始；
2）前輸出，為後輸入。
§2. 推遲實現的觀點前階段的工作必須做紮實，方可以開展後續工作。
§3. 質量保證的觀點1）必須完成規定文件；
2）必須對完成的文件進行評審，以便儘早發現問題。
（1）瀑布模型——使用條件
1）慎重使用瀑布模型的情況：
§不能充分理解客戶需求或客戶需求有可能迅速發生化； §系統太大太複雜，不能一次做完所有的事； §事先擬採用的技術迅速發生變化； §提供的資源有限； §無法利用各開發階段的某一中間產品。2）使用瀑布模型的情況：
§系統所有的功能、效能要求客戶可以一次性準確交付時； §必須是首次開發的新系統並且淘汰全部老系統時。（2）增量模型
先完成一個系統子集的開發，再按同樣的開發步驟增加功能(系統子集),如此遞增下去直至滿足全部系統需求。
系統的總體設計在初始子集設計階段就應作出設想。
（2）增量模型——使用條件
1）使用漸增模型的情況：
§需要在盡短時間內得到系統基本功能的演示或使用2）慎重考慮使用漸增模型的情況：
§不能充分理解客戶需求或客戶需求有可能迅速發生變化； §事先擬採用的技術迅速發生變化； §客戶突然提出一些新的功能需求； §長時期內僅有有限的資源保證（人員和資金）（3）原型模型
一般用於最終系統的早期使用者評價,開發工期短，質量有保證。
（3）原型模型——使用條件
§原型模型也是通過系統各個可執行的中間版本以漸增的形式來開發系統的，但是客戶需求可以分步逐漸瞭解，不用在初始時就確定。 §在模型中，可以預先定義一部分客戶需求，然後在每個後繼的中間版本中再逐步增加需求，一點點完善。 §在開發每個中間版本時，開發過程中的活動和任務可以順序地或部分重疊平行地被加入到這些中間版本中。（4）螺旋模型
（5）噴泉模型
3 軟體開發方法概述
一、程式設計方法
1.結構化程式設計方法
其控制結構僅由順序、選擇與重複等有限的基本控制結構表示。
2.模組化程式設計方法
模組之間的介面應儘可能簡明清晰：
單獨模組的修改不影響其它模組的功能；
模組化應具有可修改性、易讀性和可驗證性。
3.面向物件程式設計方法
面向過程Vs.面向物件
二、 結構化軟體開發方法
1）結構化分析（SA）的步驟
構造資料流模型。
構建控制流模型。
生成資料字典（DD）。
生成可選方案，建立需求規約。
2）結構化設計（SD）步驟
首先研究、分析和審查資料流圖。從軟體的需求
規格說明中弄清資料流加工的過程。
然後根據資料流圖決定問題的型別。
由資料流圖推匯出系統的初始結構圖。
優化軟體結構。
描述模組介面。
修改和補充資料詞典。
制定測試計劃。
傳統方法學的缺點
傳統的生命週期方法學的本質，是通過需求分析預定義軟體需求，然後一個階段接著一個階段有條不紊的開發使用者所要求的軟體，實現預定義的軟體需求。
雖然生命週期方法較之傳統的軟體開發方法更為規範化，對實現軟體開發工程化起到了重要的促進作用，部分緩解了軟體危機，引起了軟體開發原理的一次重大變革。
但是，對於那些大的複雜的軟體系統而言，這種方法仍然顯得力不從心。
1）瀑布模型的缺點：僵化
生命週期各階段間存在嚴格的順序性與依賴性，因此其特別強調預先定義需求的重要性。要求預先定義並“凍結”軟體需求。
實踐表明：在系統建立起來很難僅僅依靠分析就能確定一套完整、準確、一致、有效的應用需求，而且該方法不適用與使用者需求不斷變化的情況：
（1）某些型別的系統需求是模糊的。
（2）專案參與者之間存在通訊鴻溝。
（3）預先定義的需求可能是過時的。
2）SA - SD - SP 技術的缺點
本質上是功能分解，以實現功能的過程為中心，而使用者的需求變化主要是針對功能的。這就使基於過程的設計不易被理解；且功能變化往往引起結構變化較大，穩定性不好。
系統有明確的邊界定義，且系統結構依賴
於系統邊界的定義，系統不易擴充和修改。
資料與操作分開處理，可造成軟構件對具
體應用環境的依賴，可重用性(reusability)較差.
三、 面向物件軟體開發方法
1) 面向物件思想的由來
1) 面向物件思想的由來（續）
物件表示現實世界中某個具體的事物。 事物可分為兩大部分 : v物質: 表達具體的事物 v意識: 描述抽象的概念解決問題方法:(OO--Object-Oriented)
現實問題空間 面向物件解空間
物質 物件(客觀存在的)
意識 類 (抽象的概念)
2) 物件、實體與類關係圖
3）面向物件方法(OOM)特點
儘可能模擬人類習慣的思維方式，即問題域與求解域在結構上儘可能一致。與傳統方法相反，OOM以資料或資訊為主線，把資料和處理結合構成統一體—— 物件。這時程式不再是一系列工作在資料上的函式集合，而是相互協作又彼此獨立的物件的集合。
4）面向物件的定義
面向物件=物件+類+繼承+通訊
如果一個軟體系統是使用這樣 4個概念設計和實現的，則我們認為這個軟體系統是面向物件的。
一個面向物件的程式的每一成份應是物件，計算是通過新的物件的建立和物件之間的通訊來執行的。
面向物件四要素：
（1）物件（2）類 （3）繼承（4）訊息
5）面向物件四要素——物件物件(Object)是面向物件的基本成份。
每個物件可用它本身的一組屬性和它可以執行的一組操作來定義。
屬性一般只能通過執行物件的操作來改變。
操作又稱為方法或服務，它描述了物件執行的功能，若通過訊息傳遞，還可以為其它物件使用。
面向物件四要素——類類（Class）是一組具有相同資料結構和相同操作的物件的集合。
類的定義包括一組資料屬性和在資料上的一組合法操作。
類定義可以視為一個具有類似特性與共同行為的物件的模板，可用來產生物件。
在一個類中，每個物件都是類的例項(Instance)，它們都可使用類中提供的函式。
物件的狀態則包含在它的例項變數，即例項的屬性中。
面向物件四要素——訊息訊息（Message）是一個物件與另一個物件的通訊單元，是要求某個物件執行類中定義的某個操作的規格說明。傳送給一個物件的訊息定義了一個方法名和一個引數表（可能是空的），並指定某一個物件。
一個物件接收的訊息則呼叫訊息中指定的方法，並將形式引數與引數表中相應的值結合起來。
OOM舉例：郵局業務管理
class Post_office //定義類
{ private :
loc_type location ;
emp_type employee ;
……
public :
void send (req_type request, money_type payment);
void sell (int goods, money_type payment) ;
……
} ;
main ( )
{ Post_office My_PO ; //宣告類的示例：物件
req_type My_request ;
money_type My_payment ;
……
My_PO.Send ( My_request, My_payment) ; //通訊
……
}繼承(Inheritance)是使用已存在的定義做為基礎建立新定義的技術。
新類的定義可以是既存類所宣告的資料和新類所增加的宣告的組合。新類複用既存的定義，而不要求修改既存類。
既存類可當做基類來引用，則新類相應地可當做派生類來引用。
例如，從一個既存的車輛類派生的四輪驅動車類可能不僅是車輛類子集合定義的特殊化，而且還可能在新類的介面中引入新的能力。
面向物件與傳統方法比較①OOM與人類習慣的思維方法一致
傳統方法：面向過程設計，以計算為核心，資料與操作分離，不易理解。
OOM：以object為核心，強調對現實概念的模擬而不強調演算法。“面向物件方法學的基本原則，是按照人們習慣的思維方式建立問題域的模型，開發出儘可能直觀、自然地表現求解方法的軟體系統”。
¨Class:由特殊到一般的歸納(induction)
¨Inheritance：由一般到特殊的演繹(deduction)
②OOM穩定性好
傳統方法：結構依賴於功能，不穩定。
OOM：以object模擬實體，需求變化不會引起結構的整體變化，因為實體相對穩定，故系統也相應穩定。
③OOM可重用性好
傳統方法：通過建立標準函式庫來重用軟構件。但標準函式缺少必要的“柔性”，難以適應不同場合的不同需要。
OOM：一個class所有的 instances都可重用它的程式碼；由inheritance派生出的新的class可重用其父類的程式碼，並且可以修改、擴充而不影響其父類的使用。
④ 可維護性好
傳統方法：可維護性是最令人頭痛的問題。
OOM：從以下幾方面改善了可維護性—
§穩定性好：軟體功能需求的變化不牽動全域性，只需區域性修改； §面向物件的軟體比較容易修改：只要修改不涉及class的對外介面，則內部修改完全不影響外部呼叫；Inheritance和多型性(polymorphism)使其很容易被修改和擴充； §易於測試和除錯 §面向物件的軟體比較容易理解 ；⑤較易開發大型軟體產品
採用00M，便於一個大型軟體產品分解成一系列本質上相互獨立的小產品來處理，這就不僅降低了開發的技術難度，而且也使得對開發工作的管理變得容易多了。
OOM並不一定減少了開發時間，而是通過提高可重用性、可維護性，進行擴充和修改的容易程度等，從長遠角度改進了軟體的質量。OOM與快速原型法結合使用效果好。
4 模型
（1）建模的意義
建模是對現實系統進行適當的過濾，用適當的表現規則描繪出簡潔的模型
（2）基本概念
n模型是現實系統的簡化，它是抓住現實系統的主要方面而忽略次要方面的一種抽象 n模型既反映現實系統，又不等同於該現實系統 n模型是理解、分析、開發或改造現實系統的一種常用手段作用
n模型可以促進專案有關人員對系統的理解和交流 n模型有助於挑選出代價較小的解決方案 n模型可以縮短系統的開發週期（3） 建模的原則
1）選擇建立什麼樣的模型對如何發現和解決問題具有重要的影響。
正確的模型有助於提高開發者的洞察力。
2）每個模型可以有多種表達方式。
使用者的身份和使用的原因是評判模型好壞的關鍵。
3）最好的模型總是能夠切合實際。
模型是現實的簡化，必須保證簡化過程不會掩蓋任何重要的細節。
4）孤立的模型是不完整的。
（4） 建模三要素
首先抽象出系統的不同檢視，並用精確的表示法來建立模型，最後在模型轉換為實現的過程中逐漸新增進相關細節
（5）通用建模語言（1）自然語言、圖形語言、數學語言
（2）結構化建模與面向物件建模
A、基於功能的分解與基於概念的建模
B、面向物件的建模語言（50種之多）
Rumbaugh :OMT
Jacobson :OOSE
Booch:Booch93
Code/Yourdon:OOA/OOD
（3）統一建模語言UML
5 面向物件的軟體建模
所謂模型，就是為了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。
通常，模型由一組圖示符號和組織這些符號的規則組成，利用它們來定義和描述問題域中的術語和概念。
更進一步講，模型是一種思考工具，利用這種工具可以把知識規範地表示出來。
§OMT（Object Modeling Technique）方法OMT方法是1991年由JamesRumbaugh等5人提出的，經典著作為“面向物件的建模與設計”。
特點是開發工作起始於對真實世界的物件建模上，然後圍繞這這些物件使用這個模型來構造獨立於語言的設計。建立三種模型：
① 描述系統資料結構的物件模型(object model).
② 描述系統控制結構的動態模型(dynamicmodel).
③ 描述系統功能的功能模型(functionmodel).
§OOSE方法Jacobson於1994年提出了OOSE方法,其最大特點是面向用例(Use-Case),並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器,但用例貫穿於整個開發過程,包括對系統的測試和驗證。OOSE比較適合支援商業工程和需求分析
§Booch方法Booch最先描述了面向物件的軟體開發的基礎問題，指出了面向物件開發方法是一種完全不同於傳統的功能分解的設計方法。面向物件的軟體分解方法更接近人對客觀事物的理解，而功能分解只能通過問題空間的轉換獲得。
Booch方法包括各種模型，涉及軟體系統的物件、動態及功能各方面，對類及繼承方面的描述特別值得借鑑。
§OOA/OOD方法1989年Coad與Yourdon提出的面向物件方法，經典著作(OOA、OOD).該方法比較完整而系統介紹了面向物件的分析和設計。
主要優點是在物件、結構、屬性和服務的認定方面，提出了一套系統的原則。該方法完成了從需求角度出發的物件和分類結構的認定工作，面向物件的設計可以在此基礎上，從設計的角度進一步類和類層次結構的認定。
【存在的危機】：
1）面對眾多的建模語言,使用者由於沒有能力區別不同語言之間的差別,因此很難找到一種比較適合其應用特點的語言;
2）眾多的建模語言實際上各有千秋;
3）雖然不同的建模語言大多類同,但仍存在某些細微差別,極大地妨礙了使用者間的交流。
因此在客觀上,極有必要在精心比較不同的建模語言優缺點及總結面向物件技術應用實踐的基礎上,組織聯合設計小組,根據應用需求,取其精華,去其糟粕,統一建模語言。
6 統一建模語言(UML)
UML－UnifiedModeling Language
Unified：
n組合了當前最好的面向物件軟體建模方法 nGradyBooch，JamesRumbaugh，IvarJacobson，UML三位主要貢獻者。1.OMT（JamesRumbaugh）
2.TheBoochMethod（GradyBooch）
3.OOSE（IvarJacobson ）
UML－UnifiedModeling Language
Modeling：
用於表達現實的簡化檢視，以便於面向物件軟體系統的設計與實現。
Language：
UML主要是遵循精確語法的圖形語言。
小知識：物件管理組織 OMG
OMG（物件管理組織，Object Management Group）成立於1989年，作為一個非營利性組織，集中致力於開發在技術上具有先進性、在商業上具有可行性並且獨立於廠商的軟體互聯規範，推廣面向物件模型技術，增強軟體的可移植性、可重用性和互操作性。
該組織成立之初，成員包括Unisys、Sun、Cannon、Hewlett-Packard、Philips等在業界享有聲譽的軟硬體廠商，該組織擁有800多家成員。
CORBA（Common Object Request Broker Architecture, 公共物件請求代理體系結構）是由OMG提出的應用軟體體系結構和物件技術規範，其支援異構分佈應用程式間的互操作性及獨立於平臺和程式語言的物件重用。
特點n統一了各種方法對不同型別的系統、不同的開發階段以及不同內部概念的不同觀點，消除了各建模語言之間的差異 n不僅適合於一般系統的開發，對並行、分散式系統的建模尤為適宜 n一種建模語言，而不是一個開發過程
UML定義了用例圖、類圖、物件圖、狀態圖、活動圖、序列圖、協作圖、構件圖、部署圖等九種圖
目標
UML是用於描繪軟體藍圖的標準語言，不是視覺化的程式設計語言,而是一種視覺化的建模語言，其提出的目標是:
1、易用性：可進行視覺化建模，編制說明和建立軟體文件。
2、無關性：UML與具體的實現無關,與具體的過程無關, 可以用於任何語言任何開發過程。
3、複用性：UML強調在開發中對架構,框架,模式和元件的重用。
4、可擴充套件性：UML本身具有擴充套件機制。
應用領域UML的目標是以面向物件圖的方式來描述任何型別的系統,具有很寬的應用領域。其中最常用的是建立軟體系統的模型,但它同樣可以用於描述非軟體領域的系統,如機械系統、企業機構或業務過程,以及處理複雜資料的資訊系統、具有實時要求的工業系統或工業過程等。
總之,UML是一個通用的標準建模語言,可以對任何具有靜態結構和動態行為的系統進行建模。標準建模語言UML適用於以面向物件技術來描述任何型別的系統,而且適用於系統開發的不同階段,從需求規格描述直至系統完成後的測試和維護。
