你也可以檢視我的其他同類文章，也會讓你有一定的收貨！

參考：http://blog.sina.com.cn/s/blog_46552dd90100eg5l.html
問題：我在一個新的專案中使用UML中的用例分析和概念模型。但是老闆堅持要用傳統的需求說明書（使用面對過程的方法）。傳統方法使用系統結構圖表達功能間關係，使用資料流圖表達功能與資料間關係，使用ER圖表達資料間關係。老闆說我可以使用UML，但必須能夠清晰的表達這幾種關係。

我不知道應該使用UML中的哪些圖表達這些關係。我覺得Use_Case圖可以部份表達功能間關係（通過用例的Include和Extant關係），概念模型可以替代ER模型。但IPO（資料流）圖的表達如何用UML來替代？？

方案：我決不會教你如何做設個移植手術，因為這樣做的結果只能出來一個驢不象驢，馬不象馬的怪物，也許還沒拉車，就會死掉。

我只能告訴你一些原來結構化模型中表達的資訊，現在在UML的OO方法中都跑到哪裡去了。也就是驢子使出的力氣，馬是如何使的。你解釋給你們老闆聽，希望這樣能讓你們的老闆心裡對你是用OO踏實一些。我猜你是一個碩士生，老闆是你導師，所以你會堅持用馬。如果你不是學生，我這是在害你。

面向物件的主要思想是將資料和處理合理的結合在一起，即類圖和相應的動態圖

通常，

1. 表達需求的系統結構圖會按照業務功能領域逐層分解一個大的組織機構的業務功能到小的組織機構和個人的功能。
2. 為每個分解下來了的業務功能後面加一個“管理”的字尾，就成了“系統功能模組”或“子系統劃分”的需求了。

3. 接下來會為每個模組或子系統進行功能實現的設計，

   • 畫IPO圖，把模組之間的資料介面和內部處理邏輯表達出來。

   • 畫資料流圖，用模組的功能及其對資料的使用關係的鏈來表達對外部請求的響應過程和給外界的反饋資訊。

   • ER圖則把重點放在對持久資料的儲存結構方面，以便用關係型資料庫儲存和查詢資訊，實現功能執行與資料儲存的結構無關性。

面向過程和面向物件表達的資訊對比：

• 在結構化方法中，使用者使用軟體的目的和過程的資訊，都被直接抽象為了輸入資料和得到反饋的資料。你只會看到使用者做出輸入什麼資料然後得到什麼資料輸出的現象，至於使用者在做出一件有什麼業務意義的行為的資訊在結構化模型中基本被拋棄。
  這些資訊在面向物件的方法中得到保留並作為外部封裝的資訊。
  用例是用來描述在系統的邊界上看到的對外服務的視窗，並不是用來直接描述系統功能的分解結構的，使用用例模型代替結構化方法的功能分解是一個頑固的誤用。

• IPO圖表達的功能資料介面資訊則封裝到順序圖或協作圖中物件之間傳遞的訊息中去了。
  
  簡單地說：原來結構化方法中功能結構分解的資訊已經完全封裝在物件方法的協作關係中去了。
  用例是對外的服務，內部靠物件的協作來滿足這些服務。
  原來功能分解的形式已經完全被物件在協作中的職責劃分的方式所取代。不僅這些資訊沒有丟失，而且儲存得更加完整和從使用者角度更加易於理解。

• 資料流圖在OMT方法中是被沿用了的。
  
  在UML中被捨棄的原因大概是因為大師認為：“從結構化方法向面向物件方法的過渡期”已經過去。帶有實現類的活動圖（帶泳道）在表達動態處理過程更有優勢，不僅能表達處理的流程，還能看清物件的職責。

• 關於ER圖和靜態模型的對比問題，我前些時候有過討論。
  
  我認為關於資料儲存的問題在面向物件方法中已經可以從概念層降低到實現層了。在面向物件的概念模型中，只有物件協作，資料關係的資訊也被重新組織和劃分到物件屬性和關聯的資訊之中。

  只有在考慮物件需要持久儲存其某些資訊的時候，由於現有資料儲存的主要機制還是關係型資料庫，所以，才會帶來重新按儲存的要求來組織資料的工作。
  一個明顯的趨勢當然是直接儲存物件的資訊，這樣，ER模型就可以徹底退出歷史舞臺了。

總之，從結構化到面向物件，不僅僅是模型形式上的變化，而且有哲學思想上的變化，試圖從形式上進行嫁接的努力一定得不到好結果。

關注我的公眾號，輕鬆瞭解和學習更多技術