對這文章發表回應
發表限制: 非會員 可以發表
發表者: 冷日 發表時間: 2008/3/18 4:22:53
爪哇教室 >> 我幹麻要畫這些圈圈、框框?(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對於筆者來說跟英文字母一樣,這是最基本應該要會的,如果連這字母都不
會怎麼跟別人溝通,您說是嗎?
--------------------------------------------------------
筆名: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對於筆者來說跟英文字母一樣,這是最基本應該要會的,如果連這字母都不
會怎麼跟別人溝通,您說是嗎?