 |
|
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！ |
|
|
恭喜您是本站第 1729378
位訪客!
登入 | 註冊
|
|
|
|
| 發表者 |
討論內容 |
冷日
(冷日) |
發表時間：2008/3/18 4:22 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [分享]我幹麻要畫這些圈圈、框框
- 爪哇教室 >> 我幹麻要畫這些圈圈、框框？(Facade)
--------------------------------------------------------
筆名:Facade Facade.zhao@msa.hinet.net 2005年03月09日
■引言
==============================
多人在一起生活或做事情，溝通協調就會顯的特別重要，例如：親子之間的溝通
協調沒做好，易產生誤會，長官部屬溝通沒做好，易導致執行效果不彰，海峽兩岸溝
通沒做好，就……（這是大人世界的事情，筆者不敢妄加評斷，但期望和平收場），
聰明的您一定可以在舉更多這類的例子。
造成溝通的障礙有很多，其中對於溝通”內容”的解讀錯誤是其中障礙之一，因
此古代人發展語言及文字以便於減少解讀上的錯誤，也使得資訊能傳承不再使用口耳
相傳，例如：蘇美爾的楔形文字，埃及的聖書字，中國的甲骨文等，當然對於軟體團
隊開發中也有定義一些溝通的符號，以降低溝通上的障礙而導致專案上的風險。
■強化溝通
==============================
筆者想問各位下面兩本書，一本是幽遊白書，一本是三民主義，大家會比較想看哪一本？
圖二、幽遊白書 vs三民主義
不會吧！三民主義？太酷了，願意繼承 國父遺教，筆者先向您敬禮
，如果給筆者選的話，筆者會選幽遊白書，為什麼？因為圖比較多，看的比較輕鬆，
內容也比較有趣(有靈彈！有人界、冥界、靈界)，三民主義硬梆梆的字太多，有時讀
完也不知道在讀什麼？有句英文是這樣『a picture is worth a thousand words.』
，意思是說一張圖比幾千個字更有價值，在Modeling，一張Class Diagram 一定比程
式碼說明的更清楚，使用Use Case Diagram來討論也一定勝過幾十場電話會議來討論
事情。
一個有經驗的Developer對於剛接手的已存在的只有程式碼軟體開發專案，要能
了解這個軟體的架構是什麼至少要花數個小時，如果這個軟體專案有Model Diagram
，則這個Developer則很快就可以了解這個軟體架構。
其實從管理及使用者的層面來看，圖可以讓客戶很清楚的了解到，他們想要知道
的部份，大部分的客戶應該可能不會想去了解程式語言或是Interface怎麼呼叫，他
可能比較想知道這個軟體的最重要Component是什麼或是系統架構。
對於在不同軟體開發團隊，溝通就是一個重要的課題，筆者舉一個例子，當一家
小公司被另外一家大公司併購，這時IT部門就必須了解雙方的不同的開發流程及溝通
機制，如果溝通機制都是使用UML，對於IT資源的整合一定有相當大的幫助。
一般而言Diagramming Language都應該提供下列資訊：
‧Overall architecture of the system
‧System dependencies
‧Complexity
‧Flow of information through a system
‧Business requirements
‧Database organization and structure
‧Source code – including almost every aspect of object-oriented development
‧Deployment configurations
■降低風險
==============================
任何軟體專案都有這兩個風險一個是時間，一個是品質，Modeling可以降低這兩
類的風險。
一個軟體專案如果有使用Visual Models，我們就能從比較高的層次去看這個
Project，藉由從較高層次圖去找尋Fine-Grained Diagram。這樣的方法可以幫助
Architect和Engineer直覺地(Intuitively)掌握住問題並解決它，軟體問題容易掌握
，時間自然縮短，品質自然提高。
軟體專案的複雜度很自然就會導致軟體品質議題，藉由Refactoring Diagram最小
化複雜度，這可讓我們很快的了解到整個軟體專案的風險在哪，及軟體專案的組成。
■結語
==============================
看到這裡可能有許多讀者能了解到圖對於溝通的重要性，並開始”花時間”自創
符號(Notation)畫圖，其實早在1990初期各種不同的方法論及OOAD的符號紛紛出籠，
百家爭鳴，這些包括：
‧Peter Coad
‧James Martin
‧Steve Mellor
‧James Odell
‧Sally Schlaer
‧Rebecca Wirfs-Brock
‧Ed Yourdon
‧Others….
最後在”1995”年，由Grady Booch，Jim Rumbaugh，Ivar Jacobson這三位大人
物將之一整合，就是後來的UML。
UML對於筆者來說跟英文字母一樣，這是最基本應該要會的，如果連這字母都不
會怎麼跟別人溝通，您說是嗎？
|
|
|
|
