JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Software Engineering  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友    訂閱主題
reply to topicthreaded modego to previous topicgo to next topic
本主題所含的標籤
無標籤
作者 UML到底對於SA/SD要做的事有多大的幫助? [精華]
singlelog

換回來



發文: 416
積分: 6
於 2005-04-04 19:13 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
最近一直在想這個問題。

特別是過了一年沒有寫什麼formal analysis / design document的日子之後,最近接了一個案子,時間超趕,東西也不容易寫,幾個人密集溝通後,根本沒在寫文件。

然後看到還是有很多人在討論UML。

我一直在想,如果我現在拿時間去畫任何UML的diagram,對我們有什麼好處?或者說,當我去畫這些diagram時,把它畫完,把use case寫完,SA/SD就真的做完了嗎?

對我來說,很多最重要的東西,都不會表現在圖上。就如同一個人去用提款機領錢這種case,最需要catch的,不是人機有什麼介面啦,付完錢後要扣餘額啦。這樣的scenario,也就是通常我們在教科書上看到的scenario。

對我來說,要花最多時間跟心力的,是要去定義說,每一個不同的error,要怎麼樣去handle他。光把所有可能要做的check寫出來,整個系統80%以上的code就知道要做什麼了。比如說,鈔票可能不夠,可能沒有百元鈔,可能要跨行金資斷線,可能同時在好幾台同時領錢...

可是這種東西用圖形來表示,並不是那麼容易列舉呀。

我自己在做SA或者半吊子的SD時,花最多時間要去想跟討論的,都是演算法,data flow,table design,SQL怎麼兜...這類的問題。這跟UML,實在扯不上關係呀。

這或許是因為我的眼界太小,經驗也不夠多。所以我想問問大家,就實務經驗上,如果你採用UML來幫你開發,到底對於SA/SD要做的事有多大的幫助?

to me,幫助可能不到20%吧。而圖還是挑著畫勒。

我並沒有質疑UML as a modeling language,可以提供大家統一的標準這件事。我只是對於實務上他可以發揮的作用比較好奇。

因為我在做SA時,最需要完成的事情,是去跟user把scope敲下來,並且對於系統要提供什麼樣的feature要有很清楚的共識。可以的話,就順便幫他想想有沒有什麼潛在的問題,就先問一問。

當我在做半吊子的SD時,其實有很多事情是跟UML無關的。或者我應該說,我會去做table schema design(這種東西跟UML應該算是無關的吧。)我也會去做algorithm的討論以及產出相關的spec。(大多是psuedo code,這應該也是跟UML無關吧。)我會去討論class應該要有的interface與data element。

這些跟UML無關的東西,花去我大多數的時間,然後我挑我喜歡的工具,把必要的圖畫一畫。真要有關,大概就只有在這個phase才會有UML diagram的產出。

我不知道大家的狀況是怎麼樣,看到很多人都在講,沒有UML,沒有use case(族繁不及備載)...就不知道怎麼做SA/SD...想了很久,實在是感到很好奇呀。


singlelog edited on 2005-04-04 19:23
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
ianhong





發文: 2
積分: 0
於 2005-04-04 21:13 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:10
reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
kenming





發文: 194
積分: 10
於 2005-04-04 21:42 user profilesend a private message to usersend email to kenmingreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Hi singlelog:

看了您寫這麼長的文章,又其內的內容看來也與我個人所丟一些關於 uml 討論的文章多少有些關聯,所以..還是做一些回覆。

您提到了一個重點,開發專案的時間超趕,根本沒時間寫 "文件"。畫 use case 這類圖看來也沒多大的幫助。

我個人認為,您說對了!!
本來就不該寫文件的。當然,也不可能僅畫哪些什麼 ATM 存款這類簡單的小 case 的 normal 圖就算完成 sa/sd 了。

如您所述,有需要時才會去畫 uml 一些 "設計" 圖。
個人也認為,說得很好!!
"Code Complete" 一書也提及,不要花時間與精力在 "文件" 上。

所以,結論是,若 UML 甚至是 Java 對您的系統開發沒有 "用",也沒也必要寫文件,那麼,就不要去花時間。
而若,能協助您在設計上的表達,且能簡化程式碼的溝通,那麼,利用 uml 來表達也無妨。

視專案的規模與人員,較大型的專案,可能利用 uml 來溝通比較理想;而若2,3個人的小團隊,尤其是如大陸一些 coding 高手(個人認識蠻多這種怪才),直接用程式碼溝通即可,甚至,需求文件,哪有人在寫...

個人從來就不是要推銷 UML,這點看來是包括如您對我的誤解吧。
我只是利用 uml 來表達我的 "設計" 想法。
只是相對於 Java,我可能 "利用" UML 來表達比較方便罷了。

所以,我個人真正想討論的,是設計的思維,而非 UML or Java 等語法問題。
而我個人想推銷的,也是 "軟體設計" 。或者這麼說,是否軟體開發者能藉由腦力激盪的方式把 "自己" 心中真正的體會表達出來,無論好壞,無論使用 Java or UML。

至於,如您所提,在現實專案上必須煩惱很多現實上的問題,那是理當如此。
在建築施工的過程中,有太多的細節要去考慮以及克服的,那是必然的。

只不過,重點是,您如此辛苦的代價,又必須在如此趕的專案時程內完工,是否,有取得相對的回饋與代價,以及,是否內心有相當的成就與滿足感。
我到覺得,這些比較重要。至於 uml or java,手段手段, Who Care?

P.S. 我常附註說明,利用文字的表達很容易造成溝通上的誤解。所以,我個人並不是很喜歡在討論區上 "筆戰";而若是,您也對軟體設計這個範疇很有興趣,非常非常地歡迎,我們在咖啡廳上聊天討論,我個人就非常喜歡面對面 "舌戰" 了。 Smile


reply to postreply to post
=$∼寸心千里∼$=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
singlelog

換回來



發文: 416
積分: 6
於 2005-04-04 23:45 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我應該這樣說,我在做專案時,花最多時間去討論的,就是data structure以及相衍生的algorithm。在討論data structure時,如果跟database有關,我們會畫ER model,或是直接把table schema 討論一下。跟database無關,我們會討論file layout(例如xml)這類的東西。

在討論algorithm 時,常常會利用psuedo code來表示。我提到提款機的case,是因為先前在跟人討論時,覺得這種東西最困難的地方,根本就不在於normal flow,而是在於有太多可能的狀況可能發生,不管是在做分析,或是設計,很難把它全部考慮進去。也就是說domain knowledge dominates all.

你花很多時間,把normal flow 畫得很漂亮,也把各個class之間的interaction畫得很清楚,可是這大概只完成可能整個提款機所需意具備的function的可能不到1/10。大多數的精力,都會在於,發生了這種問題,要怎麼反應,發生了那種狀況,要怎麼反應。而這種問題的排列組合,可能列出來有幾十種。以提款機這樣的系統來說,每種組合都要測試。當你的狀況有幾十種,甚至上百種時,你還是覺得應該要畫圖嗎?

kenming,我沒有對你有什麼誤解。只是說我真的很想知道,如果你不斷地在相同領域做事,或是說team size大概也不超過10個人,UML也好,OOAD也好,到底會在你們開發系統時,發揮多大的作用呢?


singlelog edited on 2005-04-04 23:57
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:ianhong]
leonz





發文: 11
積分: 0
於 2005-04-05 00:46 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

leonz edited on 2016-04-17 02:15
reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:leonz]
cphsu





發文: 3
積分: 0
於 2005-04-05 01:43 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
個人覺得還是看情況而定囉, 就像是有時要用斧頭砍木頭, 有時要用小刀削鉛筆一樣...有大致的規範, 沒有一定的準則. Tongue

分享自己的經驗是在做SA時, 以人事物時地及5W1H去引發使用單位對各項業務相關的描述; 在SD時則以ADFIP(架構, 資料, 功能, 介面及流程)來當做構面, 分別建立相關資料後(以功能為出發, 介面及流程協同使用者確認業務行為, 架構與資料為基礎), 就可以開始開發了.

原則上文件就是寫到相關的人員看懂為止(所以開發文件的質跟量就要跟你的開發人員相依了, 使用文件則是另一個話題), 我自己寫程式的流程, 有許多都會直接放到程式碼, 因為是先寫虛擬碼再根據它去寫程式, 所以那些流程會在程式中的某一整個區域, 並不分散, 因為我覺得若分散在一行行的程式之間很難一次看清楚, 而且後續維護(包括程式及文件)都要一併考量, 最怕是最後只有程式而找不到對應的文件.

UML的使用...個人的經驗不夠...無法給什麼想法....但我想軟體的開發就像瞎子摸象, 一開始很難盡觀全貌, 但自己心中要有所知, 不能以偏概全, 必須保持一個足夠彈性的開發方式以應付許多不可知的"天下掉下來的禮物" Wink

>>> singlelog said:
>>> 我在做專案時,花最多時間去討論的,就是data structure以及相衍生的algorithm

ps. 我很贊同...一個好的資料結構設計...勝過許多程式碼

Best Regards,
Kent Hsu


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
joeyli





發文: 105
積分: 5
於 2005-04-05 08:33 user profilesend a private message to usersend email to joeylireply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
小弟拙見:

1. 用或不用UML是每個人的思考模式與習慣問題. 有人會說沒有aaa就不能bbb(aaa, bbb就請各位看官自填), 是思考模式所致, 看個人習慣就好. 但重點在於偶而了解一下別人的思考模式, 也有助於突破自己習慣的行為模式中的弱點(避免思維僵化).

2. UML本來就是選用來輔助思考, 但沒辦法把所有的分析/設計甚至實作細節完全寫在裡面, 故傳統的分析/設計文件仍有必要.

3. UML不用畫得很漂亮, 或巨細靡遺, 因為只是輔助思考或協助溝通, 達到上述目的就好, 若自認為不能達到上述目的, 不畫!!

4. UML只是tool, 和OO不OO沒有直接的關係.

5. UML用在軟體架構的結構描述上很好用, 而且已成標準, 例如: class diagram, component diagram, sequence diagram. 架構設計光用文字很難表達得讓別人看得懂, 但用圖片輔以文字會好很多. 例如附圖這樣的東西光用文字描述其scope與邏輯, 恐怕會是天書. 當然圖也會是天圖, 還是要輔以文字說明(附圖中的每個component在原paper都還有個別的圖和文字說明).
架構設計的UML圖一樣不需要巨細靡遺, 只要依據溝通的層級需求, 將重要元件與行為描述出來即可.

6. 是否使用UML與專案/團隊大小沒有直接關係, 與思考模式和產出的軟體性質會比較有關係.


joeyli edited on 2005-04-05 08:49
reply to postreply to post
跨平台是個夢!
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:cphsu]
DraculaCwg





發文: 235
積分: 4
於 2005-04-05 09:29 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
通常我們是拿uml來做溝通用途,而不是當sa sd文件
如果真的有需要用uml當sa sd文件時,也都是拿極簡化的圖示來描繒我自們的設計
了不起劃到像上一層樓那樣子,就算是很詳儘了
曾經也試過要做到圖 == code,code == 圖,雖然有reverse engine,但還是會搞死人滴

在agile methodological,強調溝通、白板、原始碼的價值是遠比任何的sa sd文件來的重要,而且可以適應反覆無常的客戶需求,如果花了大半的時間在sa sd的文件,那當客戶需求異動時,那麼sa sd文件可以又變廢紙一張

所以,我們大多能簡單的圖(可能是,也可能不是uml的圖)在紙上或白版上溝通,然後,有任何問題就去看該設計的test case(unit test)....that all

當然,一開始還是會透過crc 或簡單的use case來分析系統的大致的輪廓


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
jd001982





發文: 366
積分: 6
於 2005-04-05 10:14 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
UML 只是個溝通的工具. 你在溝通上面對的問題越大就越需要多畫 diagram 來幫助.

舉個例, 今天要是只有你自己做這案子, 說不定你根本不會畫超過一兩個, 因為大部分的東西你心裡都有數. 相對的, 你若必須和其他部門合作, 讓他人 review, 或設計給外包商的100個 developer 去寫, 能沒畫上幾十個 diagram 才怪. 可是如果這100個 developer 都是老手 (when does that happen? Big Smile), 而且你也用滿多 pattern 的, 那你需要畫的數量又會減少許多因為大家都知道怎麼做.

所以我個人認為是 It all depends on how much you need to communicate and to whom.


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
kenming





發文: 194
積分: 10
於 2005-04-05 11:53 user profilesend a private message to usersend email to kenmingreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
hi singlelog:

其他的議題,我想就此打住,太多的環節,並不容易在討論區以片段的文字來說明及敘述。您所說的許多問題,我個人是有一些想法,若您有興趣,不妨到咖啡廳大家喝杯咖啡聊聊,彼此交換心得。

不過,對您底下提這個問題個人到蠻感興趣的。
是否,比較偏是 real-time 系統呢?

我想,若是相當注重這種 real-time event 的反應及狀態變化。
那麼,我會利用 state-machine 來表達當事件(您也可以把 exception 視為 event 的 trigger)發生時,狀態的變化情形。

P.S. state-machine 可不是因為 UML 才有的,早於 1960 代,已有此技術的理論及實務,非常地完整。
在描述 UI and real-time 的狀態變化,state-machine 佔有相當重要的角色。不過,坊間 UML 書籍對此著墨非常貧乏。
有本:「constructing user interface with state-chart」,是我看到描述 state-machine 實務上最佳的參考書籍。

singlelog wrote:

大多數的精力,都會在於,發生了這種問題,要怎麼反應,發生了那種狀況,要怎麼反應。而這種問題的排列組合,可能列出來有幾十種。以提款機這樣的系統來說,每種組合都要測試。當你的狀況有幾十種,甚至上百種時,你還是覺得應該要畫圖嗎?



reply to postreply to post
=$∼寸心千里∼$=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
singlelog

換回來



發文: 416
積分: 6
於 2005-04-05 15:24 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我跟user討論時,如果是很複雜的東西,最常拿到的是一個word 或是excel 做的表格。他會列清楚situation A, 你要做什麼,situation B, 你要做什麼。等到要驗收的時候,就是針對這些排列組合去驗證,是不是每一種狀況都可以正確地處理。

我舉提款機,單純只是因為我剛好在這個版上,前前後後的幾篇文章裡面,看到有人舉這個例子。因為我記得好像在大師的書上,看到的不是提款機、就是學生資訊、書店管理系統。可是在real case裡面,我自己知道的是,像是提款機這樣的東西,他最複雜的部份大概你只要把他應該要丟出來的message整理出來,可以做出一張表,根據每一種狀況,你得要去implement相對應的狀況,每個case都完成,大概整個案子就差不多做完了。在這中間,當然可以用OO的方式去思考,也可以用各種UML的notation去畫圖。

以視覺化的方式架構model,當然有他的好處。我自己做系統有很多喜歡畫的圖,一張好的圖可以幫我思考整個系統的來龍去脈,也可以讓溝通變得很容易,特別是當你的team很大,或是大家都不清楚系統應該要做什麼的時候。用一張好的圖來表示,會有很大的幫助。

不過我會比較深入的去想這個問題,主要的原因在於,UML的興起,似乎讓很多新加入這個行業的小朋友,或是沒有接觸過實際專案開發的學生們,花很多時間去學習,每種不同的圖,應該用在什麼地方,應該畫成什麼樣子,應該要怎麼樣,才是正確的畫法。反倒是忽略了真正系統設計與分析最應該要完成的事情。當你花太多時間畫圖,就沒有時間去想想演算法,想想資料結構。

我在想,或許是因為我並不是純粹採用OOAD開發的人,也或許,我對於UML的了解還不夠深入。我才會想要知道,那對於每個現在正在做SA/SD的人來說,到底這幾個常常看見的名詞,在你開發的過程裡面,到底有多重要。

這就單純只是想觀摩一下每個人的實務經驗。因為或許可以從這樣的討論,找出我自己開發系統的盲點,以及可能可以大家可以彼此分享的心得。

分享,就從我自己開始好了。Big Smile

我最近做的一個案子,是個做異質資料庫整合的工具。這個工具,牽涉到要從各式各樣的data source中萃取資料,做點運算後,寫到資料庫去。客戶要求我們要可以讓所有這些動作可以很彈性地彼此湊在一起。比如說要可以動態地去設運算公式啦,如果格式改變了,可以很容易就做點修正啦...諸如此類的事情。

我們自己在開發的時候,大概就是簡單地把所有的scenario整理一下,畫出DFD,identify要做的功能有多少,系統要儲存的data store 到底有多少之後,接下來就去討論各種程式要用到的設定檔應該長成什麼樣子,演算法是什麼,input/output到底是什麼。因為team很小,又已經一起開發了很長的一段時間,要用什麼樣以前用過的library,或是要去那邊抄open source的library,很快就討論出結論來了。好像沒有產出什麼formal document。剩下的問題就不斷地從test case去verify了。 Tongue

至於以前我所做過的系統,則大多是那種把資料寫入,讀出資料庫,給user做做新增修改刪除查詢的商用系統。

我自己以往比較偏好的作法,大概是這樣。我會用到activity diagram來跟user確定business的flow。然後會畫ER-diagram,有必要的話,會畫第一階的Data Flow Diagram,有必要時,大概會很簡單的畫一下sequence diagram(通常也只在一開始討論的時候,畫出第一版,然後就不去管它了。有力氣,或是要結案前,才會想辦法再gen一個版本。)

大部份時間,都會花在思考database的table design,以及相對應的algorithm會是什麼,然後把spec寫清楚。有必要時還會畫畫state chart。對於那種state不算太多,state transition不算太複雜的狀況下,畫畫state chart還蠻有用的。如果我覺得系統的behavior特別囉嗦,那可能會挑著寫一些use case。

我不排斥UML,只是說覺得它沒那麼重要。個人覺得,真正的重點,還是落在怎麼設計data structure跟algorithm上。等這些都想好了,就看你要用什麼樣的model去把它展現出來。

應該有些人沒看過DFD,我附一張圖好了。剛剛看了一下,應該沒有什麼太多的機密。這是把好幾塊湊在一起後的結果。差不多就是我們所接的project可以畫出DFD的部份,都畫進去了。

dfd.wmf (50.84k)


singlelog edited on 2005-04-05 15:33
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
Michael





發文: 9
積分: 1
於 2005-04-08 15:23 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
個人是從Coding and debugging那種模式過來的人,所謂規格,所謂設計,不過是一張紙,三言兩語,剩下的,可以美其名為Code as design.
兩年前開始走到一個完全陌生的領域,這才發軟體領域多出了好些名堂,UML是其中之一.我相信UML對系統分析設計是有幫助的,所以在公司內力推,兩年下來,實做人員應該是有落實UML做為溝通及記錄的工具.但是在系統分析設計這邊,我幾乎可以說是推不起來.
我現在用的大概就是Feature定一定,ER model跟流程圖畫一畫,Prototype拉一拉,重點邏輯寫一寫,在實際運作上,好像還OK.過去逼出來的Use case啊,Diagram啊,大概就是束之高閣,有必要的話,再拿出來顯示”我們是用過UML的”.
我認為在實做層面上,拿UML來描述軟體架構是非常合適的,但是拿來做系統分析與設計,也許我們這一票老頭子腦筋轉不過來,總覺得有點適應不良.本來討論的主體應該是系統需求本身,但是搞到最後卻變成UML該如何表示.這就好像指月一般,月亮應該是主體,結果大家的注意力卻搞到手指上去.我有個專案要Run,如此為文件而文件實非上策,於是改弦易轍,改用Prototyping的方式,終於進展得比較順利.

現在軟體界有些”政治正確”的東西,搞得大家好像不那麼做就不對了.這個現象從我面試年輕人就可以看出來.
--你們用不用UML?不用UML就跟不上潮流,我就不太想來了.
--你們是不是用網頁開發系統?不是網頁就跟不上潮流,我就不太想來了.
CMMI也是一項,不過還沒遇到過就是了,但是CMMI一直推廣下去,難保有一天,我們這種不想搞CMMI的公司會招不到年輕人.

我絕對認同UML做為溝通及記錄的價值,但做系統不是只有一種方法,所有的需求也不會都是ATM這樣的例子.
有一位Jack W. Reeves先生寫了一篇文章認為Coding才是設計.在這樣的定義之下,Coding之前的動作大概就是團隊成員對問題的認知跟解決方案的探索與討論,如果是這樣,那只要能達到互相溝通與記錄,UML,不UML感覺就不是那麼重要了.不然,在UML之前的時代,是不是大家都做不出好系統?
UML一直往嚴謹的方向發展,所能描述的範圍越來越大,做為一門學問,這樣的發展是必然的.但做為一項溝通工具(或者說是語言),它給我的感覺是文法越來越多,要搞清楚似乎越來越不容易.也許它就跟語言一樣,如果從小就學著講,使用起來就會得心應手,所以如果現在的學校一直推UML,也許以後就會很普及.而對我們這種半途出家的,就跟學俄文寫紅樓夢一樣,還是轉用中文比較拿手.
UML讓我感覺有朝程式語言化發展的趨勢,以後不用寫Java , C#了,我們寫UML就可以了.這種只要Design不用Coding的夢,我們想了很久,但這種銀子彈好像還沒見過.
UML會不會就是那顆銀子彈?

Jack W. Reeves先生的文章
http://www.developerdotstar.com/mag/articles/reeves_design_main.html


reply to postreply to post
Words from the dark side
http://wwtblog.blogspot.com/
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:Michael]
singlelog

換回來



發文: 416
積分: 6
於 2005-04-08 16:35 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Michael wrote:
現在軟體界有些”政治正確”的東西,搞得大家好像不那麼做就不對了.這個現象從我面試年輕人就可以看出來.
--你們用不用UML?不用UML就跟不上潮流,我就不太想來了.
--你們是不是用網頁開發系統?不是網頁就跟不上潮流,我就不太想來了.
CMMI也是一項,不過還沒遇到過就是了,但是CMMI一直推廣下去,難保有一天,我們這種不想搞CMMI的公司會招不到年輕人.

看了以後,真是心有戚戚焉呀。Big Smile

可是,我一點也不老呀!Cry
Michael wrote:
我絕對認同UML做為溝通及記錄的價值,但做系統不是只有一種方法,所有的需求也不會都是ATM這樣的例子.
...恕刪...
不然,在UML之前的時代,是不是大家都做不出好系統?

我自己也講過跟Michael幾乎一模一樣的話。看來是遇到知音了。Big Smile

整個業界的趨勢不會被我們這樣幾篇文章所影響,只是說心裡面有話不說,憋得可難過啦。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:Michael]
LinusTseng





發文: 58
積分: 0
於 2005-04-10 21:28 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
martin fowler也有類似的文章

http://martinfowler.com/bliki/CodeAsDocumentation.html

可以參考看看..


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:LinusTseng]
Tomm

葛瑞菲



發文: 39
積分: 2
於 2005-04-13 17:13 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
LinusTseng wrote:
martin fowler也有類似的文章

http://martinfowler.com/bliki/CodeAsDocumentation.html

可以參考看看..


Martin Flowler 在 Agile 陣營算是對 UML 頗友善的, Martin Flowler 在其書中曾提到 Kent Beck 每次都是隨手繪出設計圖而無固定之 Notation. 我一直很喜歡看 singlelog 的 Post , 每次都是一針見血 Big Smile 且務實 , UML Distilled 中提到:

Activity diagrams are one of most unexpected parts of the UML.

Unlike most other techniques in the UML, the activity diagram doesn't have clear origins in the previous works of the three amigos.

沒有 Activity diagrams 我真不知道 three amigos 原本打算怎表達 singlelog 提到 Error Handling 與 Work flow 這些 algorithm 設計


Tomm edited on 2005-04-13 17:18
reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
gameboy





發文: 6
積分: 0
於 2005-04-29 13:42 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
有些想法
請問您的團對每個一人大概都是幾乎從SA,SD,coding,testing從頭包到底吧?
這樣來說我覺得或許傾向XP或者Agile的開發方式或許會比較適合
至於內部溝通用不用UML來溝通,應該也是其次,RUP之類的不大合適

不過我個人認為這樣的case應該把use case寫好吧,這是我認為最重要的事情
use case應該不用rose這樣龐大的東西來寫,就像你個人用的word跟excel
就可以了。
把use case寫好應該就會知道,動了一個例外處理,會影響到系統多大,對於
後續開發的人員也有很大的好處,diagram如果太趕,能少就少吧
Matrin Folwer提示use case來說文字的重要性遠大於圖形,處理客戶需求
use case diagram是use case抽出來的,隱藏了許多細節方便檢視跟溝通

對於客戶來說我想你用啥演算法跟table design對他們應該沒有太大影響,
他們要的是功能,剩下應該不是他們關心的範圍;這些應該也是介於SD到
coding的範疇吧。

題外話,今天如果拿UML來Model整個系統,重點應該是如何表現出系統
跟每個系統之間的一致性吧;至於實做的細節就不是那麼重要了。

以上是我個人的淺見。


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:gameboy]
singlelog

換回來



發文: 416
積分: 6
於 2005-04-30 02:49 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
gameboy wrote:
有些想法
請問您的團對每個一人大概都是幾乎從SA,SD,coding,testing從頭包到底吧?
這樣來說我覺得或許傾向XP或者Agile的開發方式或許會比較適合
至於內部溝通用不用UML來溝通,應該也是其次,RUP之類的不大合適
不過我個人認為這樣的case應該把use case寫好吧,這是我認為最重要的事情
use case應該不用rose這樣龐大的東西來寫,就像你個人用的word跟excel
就可以了。

其實不然。我以前待過很多team都是 SA / SD / Coding /Testing 截然分開。只是現在因為人少,所以只有我們只有我一個人當SA/ 半個SD / 半個tester。coding的人還要兼SD + architect。我們現在開發確實蠻接近XP的若干精神,不過跟我本人越來越懶得寫文件也有關。Big Smile

這世上並不是只有UML / use case...這樣的東西。OOAD在紅,也是這十幾年的事情。Structured Analysis雖然是從70年代就有了的老東西,還是建造出很多系統來。在那個年代,一樣有老字號的SA/SD呀。

gameboy wrote:
把use case寫好應該就會知道,動了一個例外處理,會影響到系統多大,對於
後續開發的人員也有很大的好處,diagram如果太趕,能少就少吧
Matrin Folwer提示use case來說文字的重要性遠大於圖形,處理客戶需求
use case diagram是use case抽出來的,隱藏了許多細節方便檢視跟溝通


Matrin Folwer提示use case來說文字的重要性遠大於圖形。那為什麼UML要強調它是個圖形化的modeling language?不就是說文字長篇大論大家不喜歡看,用圖比較好溝通嗎?為什麼跟user confirm requirement反倒是要用use case勒?user會比programmer聰明嗎?這就是我最不解的地方。

我個人不是說UML不好,也不是說use case不好,不過說他很好的人,真的用過傳統的structure analysis來分析設計過系統,然後進行過比較嗎?我只能說,UML+use case在我自己做過的為數不算多的案子裡面,只有在做那種跟資料庫比較無關的系統上,會發揮的比較好。如果你做的是商用資訊系統,運用structure analysis來開發,會比use case driven OOAD來得管用多了。這也是純個人感覺。所以我比較好奇,UML到底對於SA/SD要做的事有多大的幫助?當然,這個命題並不好,因為很多人可能都還是20出頭,可能根本就沒有用過structure analysis,就沒得比較了。

gameboy wrote:
對於客戶來說我想你用啥演算法跟table design對他們應該沒有太大影響,
他們要的是功能,剩下應該不是他們關心的範圍;這些應該也是介於SD到
coding的範疇吧。


對於客戶來說,如果你寫的是把東西丟到資料庫去的程式的話,table design對他們的DBA很重要,對他們的IT部門很重要。對end user來說,他們care的是資料可以正確地進系統,也可以快速地進行彈性化的查詢。演算法跟table design的不好,就是沒有彈性,或是效率很差,導致回應速度很慢。除此之外,我用啥演算法跟table design對他們應該沒有太大影響。


singlelog edited on 2005-04-30 02:52
reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
gameboy





發文: 6
積分: 0
於 2005-04-30 06:36 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
其實不然。我以前待過很多team都是 SA / SD / Coding /Testing 截然分開。只是現在因為人少,所以只有我們只有我一個人當SA/ 半個SD / 半個tester。coding的人還要兼SD + architect。我們現在開發確實蠻接近XP的若干精神,不過跟我本人越來越懶得寫文件也有關。Big Smile

這世上並不是只有UML / use case...這樣的東西。OOAD在紅,也是這十幾年的事情。Structured Analysis雖然是從70年代就有了的老東西,還是建造出很多系統來。在那個年代,一樣有老字號的SA/SD呀。

是的,Structured Analysis是可以work,但是相信有一些問題,教科書上也很多;
如今大家"相信"(信仰?)OOAD也是有他的原因不是嗎?

Matrin Folwer提示use case來說文字的重要性遠大於圖形。那為什麼UML要強調它是個圖形化的modeling language?不就是說文字長篇大論大家不喜歡看,用圖比較好溝通嗎?為什麼跟user confirm requirement反倒是要用use case勒?user會比programmer聰明嗎?這就是我最不解的地方。

我講的不大好,對於use case跟use case diagram來說,的確文字比圖形重要,其他
就不是這樣;一個programmer真的可以看use case diagram把程式寫出來?應該是
不可以吧?因為太多細節省略掉了,圖形某種程度上是為了溝通方便。
另外user並不一定比programmer聰明,反之亦然。大家需要溝通XP不是很重視
feedback,有時候文字的確比圖形嚴謹。
但是今天如有選擇程式碼跟流程圖,你要看哪一個?
另外use case並不強調一定要用OO來做,structure analysis應該也可以
這樣看來我對於比較趕的project,比較重視use case requirement,認為其他
可以先省略,主要是因為時間的考量;可是我的偷懶相信以後要付出代價Dead

我個人不是說UML不好,也不是說use case不好,不過說他很好的人,真的用過傳統的structure analysis來分析設計過系統,然後進行過比較嗎?我只能說,UML+use case在我自己做過的為數不算多的案子裡面,只有在做那種跟資料庫比較無關的系統上,會發揮的比較好。如果你做的是商用資訊系統,運用structure analysis來開發,會比use case driven OOAD來得管用多了。這也是純個人感覺。所以我比較好奇,UML到底對於SA/SD要做的事有多大的幫助?當然,這個命題並不好,因為很多人可能都還是20出頭,可能根本就沒有用過structure analysis,就沒得比較了。
對於客戶來說,如果你寫的是把東西丟到資料庫去的程式的話,table design對他們的DBA很重要,對他們的IT部門很重要。對end user來說,他們care的是資料可以正確地進系統,也可以快速地進行彈性化的查詢。演算法跟table design的不好,就是沒有彈性,或是效率很差,導致回應速度很慢。除此之外,我用啥演算法跟table design對他們應該沒有太大影響。

UML應該是溝通上方便,對於寫作上來說,除非有錢買好工具,有熟悉那套工具
不然還真的很花時間;UML對於OOAD我覺得是有幫助的,但不否認他有相當的成
本存在;我個人的經驗是跟某些programmer講Design Pattern他們不曉得,這應該
是我跟他們說的是"不同的語言",這樣我要多花一些時間來溝通。
另外本人不熟悉Structrue Analysis,可以請教用他每個人寫的文件下一個接手
的公司可以得到多精確,多少程度的資訊呢?相信你們應該有類似的經驗吧?

我的確想說UML的圖形對於做Analysis不是很大的幫助,應該說他本身目的是為了
建立一個標準的平台, 分析是靠OO或者structure analysis的;只是UML比較傾向
OO的一種"語言";所以說UML對於OOAD的幫助應該是在溝通吧Smile
不知道我這樣說對不對,請多指教


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
singlelog

換回來



發文: 416
積分: 6
於 2005-05-01 01:59 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我個人看法大概是這樣:

1.DFD可以幫助SA去進行系統分析,做單純把資料寫到db的案子的話,會幫你節省與user溝通的時間。他們也會很清楚到底系統的scope在那邊,有多少function是要做的。你要他們去理解object oriented的概念比較難。而use case的話,主要的問題在於裡面的scenario可能很多,不過都是文字,所以對於requirement的coverage是否充足就比較沒有像DFD這樣子,可以從圖上看得到。

我比較question的是用use case來做requirement analysis,在做pure 商用資訊系統時,真的沒有像是requirement document + DFD清楚。

2.我因為沒有唸比較新的教科書。所以我不知道structured analysis有什麼問題。Big Smile我個人認為,structured analysis適用的範圍是比較受限的。你如果要做個rational rose,structured analysis是沒幫助的。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
ianhong





發文: 2
積分: 0
於 2005-05-01 11:34 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
Post is deleted

ianhong edited on 2007-04-26 15:11
reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
ec_yeh





發文: 72
積分: 0
於 2005-05-04 10:19 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
好精采的討論串呀!不過我總是覺得有好幾個概念被放在一起講。試著將它分開一下,謬誤之處再請各位幫忙指正。

1. UML是一種表達方式,和OOAD沒有必然的關係。看過不少人很會用Rational Rose畫出洋洋灑灑的圖,但是沒有OO的概念。反過來也有OO概念很強的人卻不習慣用UML表達。JUnit也是很好的設計方法,卻不用畫圖。
2. 使用UML方法很多。並不是專案開始就開Rose或Visio畫各種圖來當作SA、SD才是用UML。兩個人在白板上塗鴉,在計算紙上亂畫也可以用UML。就如前面各位大大所說,UML只是一個溝通工具。
3. use case和UML以及OO應該沒有直接的關係。use case常用來描述functional requirement,但是不需要UML的use case diagram也可以整理出很好的use case。實作use case描述的功能也不一定要物件技術。

如果上述的分析沒有錯的話,我猜想獨孤木前輩要討論的是,OOAD方法比傳統的 structured analysis 和 data modeling 高明在哪裡吧。是這樣嗎?


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:ec_yeh]
singlelog

換回來



發文: 416
積分: 6
於 2005-05-04 10:50 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ec_yeh wrote:
好精采的討論串呀!不過我總是覺得有好幾個概念被放在一起講。試著將它分開一下,謬誤之處再請各位幫忙指正。

1. UML是一種表達方式,和OOAD沒有必然的關係。看過不少人很會用Rational Rose畫出洋洋灑灑的圖,但是沒有OO的概念。反過來也有OO概念很強的人卻不習慣用UML表達。JUnit也是很好的設計方法,卻不用畫圖。
2. 使用UML方法很多。並不是專案開始就開Rose或Visio畫各種圖來當作SA、SD才是用UML。兩個人在白板上塗鴉,在計算紙上亂畫也可以用UML。就如前面各位大大所說,UML只是一個溝通工具。
3. use case和UML以及OO應該沒有直接的關係。use case常用來描述functional requirement,但是不需要UML的use case diagram也可以整理出很好的use case。實作use case描述的功能也不一定要物件技術。

如果上述的分析沒有錯的話,我猜想獨孤木前輩要討論的是,OOAD方法比傳統的 structured analysis 和 data modeling 高明在哪裡吧。是這樣嗎?

不是也。

因為我感覺大多數人寫的系統(這個是純個人感覺),是開發跟資料庫相關的商用程式。我自己在開發這類型的系統時,覺得SA也好,SD也好,大多數時間都在分析data,以及定義對於data的加工。你會花很多時間去規劃最後的database schema是什麼,也會去看看系統裡面對於data的加工應該做那些。而user想跟你討論的也就是這些。

所以我覺得,如果你需要做這樣的project,UML當然有幫助。不過傳統的 structured analysis 和 data modeling 可能會對你把整個案子做完,有更大的幫助。最少我以前看過不少人,就把table schema開一開,DFD大致上畫一畫,寫寫 program spec,就開始動手去做了。

當然,這是純粹個人的臆測與觀察,所以我比較想知道,目前所謂的use case driven OOAD + UML,到底在現在每個人的開發工作中,扮演什麼樣的角色。我內心潛在的疑問是,當我們的教育也往這方面傾斜,就像很多小朋友根本就不畫過DFD,那會不會花很多時間去學習,花很多時間去做SA/SD,卻沒有抓到整個系統要capture的重點呢?

當然,如果你做的根本不是這種類型的系統,那UML+OOAD可能就會相當吃重。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
ec_yeh





發文: 72
積分: 0
於 2005-05-04 12:26 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
說一下個人的淺見。

首先,個人認為只要是好的SA或SD,無論讓他用哪種方法,只要有一些時間學習都不是問題,一法通,萬法通。Object Model和Data Model很多概念是共通的。反過來Rose用得滾瓜爛熟也不能幫助一個人成為一個好的SD。年輕人如果堅持用新潮的方法入手,第一個問題是在於它能不能得到資深同儕的協助和指導?一個老經驗的SA,即使不會UML,也是一個寶庫。獨孤木大大說的典範轉移的問題,我覺得主要來自於經驗傳承。UML好學,SASD的精髓很難學。

BOOCH的書開宗明義就說,物件技術處理的是complexity。一個軟體資訊系統裡面的複雜度一旦高到超越人力認知能力所能理解的極限,我們就會開發出新的技術來應付更高的複雜度。結構化設計、模組化設計、元件技術、物件技術應該都是這樣的產物。

至於業界真正的專案,複雜度有高到那麼離譜嗎?老實說,我自己沒有遇到過。我所遇到過的專案,都是理論上table schema、DFD這些就可以解決的。

但是complexity會發生再另一個地方:如果我們不是用waterfall,而是採用agile的方式。Agile方法會需要大量的架構重整,包含DB schema的改變。Agile的設計不在於從無到有如何想出一個架構,而常常是在於從一個舊架構要過渡到一個新架構。因為我們不做預先設計,只針對眼前的需求做最簡單的設計,所以明天的refactoring是必然的。我自己的看法是,這種複雜度就需要大量的物件技術才能應付。不然變動的成本會太高。


reply to postreply to post
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:ec_yeh]
singlelog

換回來



發文: 416
積分: 6
於 2005-05-04 20:50 user profilesend a private message to usersend email to singlelogreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
ec_yeh wrote:
但是complexity會發生再另一個地方:如果我們不是用waterfall,而是採用agile的方式。Agile方法會需要大量的架構重整,包含DB schema的改變。Agile的設計不在於從無到有如何想出一個架構,而常常是在於從一個舊架構要過渡到一個新架構。因為我們不做預先設計,只針對眼前的需求做最簡單的設計,所以明天的refactoring是必然的。我自己的看法是,這種複雜度就需要大量的物件技術才能應付。不然變動的成本會太高。

同意這樣的看法。不過這就要看我們做的軟體到底是什麼樣的東西了。如果你做的是一次性的project,那麼用waterfall是比較適合的。如果你是持續地改版,那不斷地演化會是重點。

不過商用系統即使是這樣,本質上可能採用跟data modeling相關的方法會比較好。最少就商業邏輯的這一段是如此。當然如果今天是以要架構一個不斷演化的framework當做是目標的話,那可能慢慢演化會比較適合。

或許另外一個可以考量的點在於requirement的清晰程度。如果requirement還不是很明確,可能不斷地做prototyping,然後不斷地去refactoring會比較洽當。

一開始在起這個話題的時候,其實內心想的是,很多跟SA/SD相關的工作,跟UML其實沒什麼關係。不過好像很多小朋友都把這幾件事畫上等號。所以覺得有點納悶。


reply to postreply to post
我的書:專案管理Happy書!

我的網站:diggirl.net

my blog http://tinyurl.com/36gcye
作者 Re:UML到底對於SA/SD要做的事有多大的幫助? [Re:singlelog]
joeyli





發文: 105
積分: 5
於 2005-05-05 10:51 user profilesend a private message to usersend email to joeylireply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
singlelog wrote:
同意這樣的看法。不過這就要看我們做的軟體到底是什麼樣的東西了。如果你做的是一次性的project,那麼用waterfall是比較適合的。如果你是持續地改版,那不斷地演化會是重點。

不過商用系統即使是這樣,本質上可能採用跟data modeling相關的方法會比較好。最少就商業邏輯的這一段是如此。當然如果今天是以要架構一個不斷演化的framework當做是目標的話,那可能慢慢演化會比較適合。


基本上小弟與獨孤大您的看法相同, 使用哪一種類型的process應該要視產品的特性來決定.
但是, 小弟認為iterate這樣的模式應該是至少適用於所有product開發案, 而不只是侷限在framework的開發. 因為大部分的product都有演化的需求, 產品的開發況日費時, 且在上市後又必須面對眾多不同的客戶來做調整, 產品在架構上沒有妥善的分層, 沒有component-based, 沒有粹取出核心framework, 在後來都會不太容易應付變動.
況且, product常常被切分成為module, 或再細分到component, 若能利用interface做妥善分割的話, 是能夠做到每個module或每個component獨立演化的, 而我們目前也是這樣做.
事實上, 所謂framework可以出現在system中的任何一層, 只要公司策略覺得必要的話, 就可以抽framework出來. 假設我們公司要做一套可以用來開發data mining的framework也是可以的, 就看市場的需要.

重點在於是不是保留一點有彈性的空間, 而不是"立刻"就要抽framework, data modeling它比較容易讓人最後聚焦在database schema的設計上面, 反而忽略了實作business logic的"code"是否保留變動的彈性, 這樣的系統特色就是(以三層式架構為例):
database schema開得非常漂亮, 但中間層連一個符合domain concept的object都沒有, 只有一堆邏輯四處糾結, 只為了把資料"兜"出來的code.

這時候可以適時搭配一下UML的class diagram, 來引導我們"稍微"想一下中間的邏輯code怎麼寫比較好一些.

至於演化則是軟體的本質, 只要認為軟體有演化的可能, 就有必要要考慮iterate的做法, 而不僅限於是否是framework.
也常看到原本僅是一個project所產出的system, 因為市場需要而轉成product來賣, 那它會不會演化呢?


或許另外一個可以考量的點在於requirement的清晰程度。如果requirement還不是很明確,可能不斷地做prototyping,然後不斷地去refactoring會比較洽當。

一開始在起這個話題的時候,其實內心想的是,很多跟SA/SD相關的工作,跟UML其實沒什麼關係。不過好像很多小朋友都把這幾件事畫上等號。所以覺得有點納悶。

其實無論哪一類型的專案, 所有的view都不能偏廢, business logic, data model都是需要的. UML或DFD事實上都只是工具, 差別只是這些工具想引導我們做什麼面向的思考.
UML與SA/SD確實不能畫上等號, 而且SA/SD概念的重要性一定高過UML或DFD這些工具.
就這點來說, 小弟一直覺得獨孤大與kenming是很相像的, 只是獨孤大您比較質疑的是在當前這種氛圍是否data model, 流程這類的就被忽視掉了; 而kenming也是想強調SA/SD的重要, 只是他擅用UML的手法來表達.


joeyli edited on 2005-05-05 11:20
reply to postreply to post
跨平台是個夢!
go to first page go to previous page  1   2  go to next page go to last page
» JWorld@TW »  Software Engineering

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8