Thinking in UML 學習筆記(一)——建立對象模型


一、面向對象的本質

面向對象的本質是抽象,當系統達到了超越其處理能力的程度,我們能夠抽象出我們能夠處理的范圍來提成抽象級別,這樣就能夠構建更大、更復雜的系統。

現實世界和對象世界之間存在着一道溝壑,這道溝壑的名字叫抽象,抽象是面向對象的精髓所在。同一時候也是面向對象的困難所在。要跨越這道溝壑,我們須要解決下面問題:

1、一種把現實世界映射到對象世界的方法。

2、一種從對象世界描寫敘述現實世界的方法。

3、一種驗證對象世界行為是否正確反映了現實世界的方法。

UML正是解決這一問題的分析設計方法。

二、面向對象遇到的問題

1、對象的分析與設計問題。

2、對象結構的含義模糊不清。

當面向對象遇到這些問題的時候。UML統一建模語言出現了。學習UML僅僅是學會了一門語言。而要寫出一篇精彩的文章,卻須要依靠寫作人對生活的感悟和升華,這兩者缺一不可。因此比學會UML建模本身更重要的是要理解UML背后所影藏的最佳實踐。

三、UML統一建模語言要解決的問題

1、UML既然是一門語言,作為語言要解決的首要問題就是溝通問題

2、統一,則是要解決混亂的方言問題。如普通話一樣被大家廣泛認可。

3、可視化,easy被人理解和記憶(超越文字的表達方式)。

四、從現實到模型的抽象過程

建模實際上是一種對現實事物的理解。現實世界中假設我們站在非常高的角度去抽象,就會發現不管這個時間多么復雜,其本質無非是由人、事、物和規則組成。

1、UML採用稱之為參與者(actor)的元模型作為信息來源提供者。代表現實中的“”。

2、UML採用稱之為用例(use case)的一種元模型來表示驅動者的業務目標。也就是參與者想要做什么而且獲得什么。代表現實中的“”。

3、一件事怎么做。根據什么規則。則通過稱之為業務場景(business scenario)和用例場景(use case scenario)的UML視圖來描繪的。代表現實中的規則

4、業務中的對象模型則就相應現實中的“”。

五、從業務模型到概念模型

分析模型:UML通過稱之為概念化的分析過程來建立適合計算機理解和實現的模型。

分析模型介於原始需求和計算機實現之間,是一種過渡模型。

分析模型的元模型:

1、邊界類(boundary):_____事

2、控制類(control)———規則

3、實體類(entity):————物

下圖是業務模型到概念模型的轉換過程示意圖:


六、從概念模型到設計模型

設計模型則是對概念模型的詳細實現,這樣的實現方式不止一種。在設計模型中。概念模型中的邊界類能夠被轉換為操作界面或者系統接口。控制類能夠被轉化為計算機程序或控制程序,比如工作流、算法等;實體類能夠轉化為數據表、XML文檔或者其它持久化類。實際上對於不同的軟件架構和框架以及不同的編程語言。所實現的概念模型有所不同。


面向對象分析設計完整步驟例如以下:



七、RUP介紹

RUP(Rational Unified Process)統一過程。

統一過程歸納和整理了非常多在實踐中總結出來的軟件project的最佳實踐。是一個採用了面向對象思想,使用UML作為軟件分析語言,並結合了項目管理、質量保證等很多軟件project知識綜合而成的一個非常完整和龐大的軟件方法。


統一過程定義了軟件開發過程中最重要的四個階段和九個核心工作流,每一個階段對不同工作流的側重點不同。

軟件項目真正的靈魂是軟件過程。軟件過程的須要才是這些工具和語言誕生的原因。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM