2010-02-23 20 views
10

可能重複:
Is UML practical?UML如何有用?

我做UML在我的大學,我不明白爲什麼我們必須這樣做。它看起來像面向對象數據庫的模型,但我認爲我可以在沒有UML的情況下編寫Java。

我想知道爲什麼UML是在專業領域中使用的技術原因;爲什麼它很重要。不只是學習它,因爲教授這樣說。

+0

你有沒有問教授? – 2010-02-23 12:16:31

回答

12

您可以java寫的非常好,但UML是語言無關。將設計傳達給同事時,您需要共同的「語言」。我認爲,UML是最好的方式。

我現在準備會議與同事討論給出了一些場景,他想出了API設計。一些序列圖明確地顯示了我們如何提出滿足他的需求。他不需要成爲一名Java程序員來理解設計。

+4

我想我明白你的意思。如果你允許比較,它就像程序員的一個幻燈片,對吧? – loriser 2010-02-23 11:38:16

+0

用於該比較的+1 :-) – 2010-02-23 11:51:50

+0

不,這是用於通信的實際語言。我在大學學習了設計模式(和一些Java)。一旦我開始第一份工作(.NET),我發現我有一種可以與同事溝通的共同語言。如果不能描繪UML並談論面向對象的設計抽象(如果沒有UML,那麼你不能真正描述它),我不可能像我那樣快速地開始。這是重要的東西。 – Joe 2010-02-23 11:52:22

14

我們發現,UML是作爲交換媒介有用,勾畫出了其他什麼人設計看起來就像是犯它的代碼之前或可視化什麼現有的代碼看起來像。

我們並不特別關心符合規範的UML,因爲我們都不能完全確定我們應該使用哪些位,並且因爲這些圖通常不會持續很長時間。我想說,我們可能使用鉛筆比使用軟件繪製更多的UML。

實際用途包括試圖敲定一個新類適合現有的層級,工作了,事情是在層次結構重構的接口,開始新功能之前,素描討論潛在的設計。

+0

你能解釋更多嗎? – loriser 2010-02-23 11:34:59

+0

非常感謝所有人,我現在明白了什麼意思。我們不會分組編程,所以我不理解。我喜歡函數說明等其他內容,但是uml似乎毫無用處。 – loriser 2010-02-23 11:47:22

1

給你的項目

2

UML可以用於不同目的的視覺設計:

1)給你寫的代碼(與你的團隊)之前要來有關組件的協議(甚至項目)架構,以避免誤解,這就是爲什麼你可以繪製類圖

2)你想創建用例圖,並把它放在某些你經常會記住的地方,以記住你的應用程序要做哪些主要功能(以及哪些你應該集中更多的任務)

3)類圖可以作爲項目宏架構的文檔。如果您想要邀請新開發人員加入您的項目,那麼擁有這樣的類圖非常重要。

1

作爲一名程序員,您可能會得到一份工作,爲一家小商店構建一個小型網站。這可能很簡單。你可能沒有設計文檔,沒有UML,沒有測試,它可能工作得很好。

但是,您可能會找到一份工作來開展空中交通管制系統,汽車的防抱死制動系統或全球最大銀行之一的交易系統。在這種情況下,你不會自己編寫代碼。你必須說服其他人說你的代碼確實會做正確的事 - 不僅僅是你的同事,還有獨立的審計人員。爲了幫助他們快速理解代碼,他們需要一些圖表。有什麼比標準符號更好的幫助他們獲得你的代碼的圖片? (當然,你也需要你的設計文檔和測試!)

3

編輯這個來添加另一點。 UML用於設計,就像爲您的軟件創建藍圖一樣。一個簡單的比喻就像在實際構建房屋/建築之前設計和審查房屋/建築的體系結構圖。它作爲溝通,思考和挑戰設計的媒介。最終完成後,它將成爲構建軟件的藍圖 - 參考點。


UML不用於OO數據庫設計。它用於模擬軟件的不同設計。例如,您將使用用例來捕獲系統邊界或角色/用戶與系統的交互。這種設計有助於捕捉用戶需求。您可以使用靜態圖來對課程及其關係進行建模。你可以使用序列圖建模交互,這在IMHO中非常有用。

好的,現在回到回答你的具體問題。如果您正在從事小型作業和單人項目,那麼您可以爭辯說UML不會增加太多價值。在現實生活中,您擁有更大的團隊和不同的角色(架構師,設計師,BA,開發人員等),UML用於以一致和標準的方式捕獲和交流架構,需求和設計信息。例如,我可以根據設計師提供的需求信息和用例圖設計一個銀行模型,我將轉化爲類圖的技術設計,並使用序列圖捕獲它們的交互和消息流,然後傳遞給其他4位成員我的團隊去實現這一點。

1

我有超過10年的經驗,在編碼,金融行業的C/C++/C#方面經驗豐富,而且我從未曾經使用過UML。
這可能是我的工作的一個反映哈哈,但我從來沒有見過它在使用。設計文件傾向於基於書面描述和/或故事板。
問題的關鍵似乎是,當你編寫了一個準確而全面的UML圖表並將其轉換爲代碼時,你可能已經編寫了代碼。
有爭論,如果你需要傳達設計給別人也可以是有用的...但我猜你需要知道:

  • 你需要多久做這樣的設計(從頭開始假設)?沒有多少系統是如此綠色環保以至於需要如此全面的設計。
  • 你會告訴它的人如何充分了解它,你已經花時間做出來了嗎?商務人士不太可能。
  • 會流程圖/故事板/說話足夠嗎?通常更直觀並且可以吸引更多的觀衆。
  • 商業人士是否希望您在開始實施之前就可以根據競爭/原型需求正確完成它?如果你已經完成了這項工作,需求變化如此之大,你必須重新制作它,這樣的形式圖會變得很重要嗎?

    我想如果你正在編寫真正的軟件,例如飛機控制系統,它需要是搖滾設計,但我不知道這是否是方法。
0

作爲開發人員,您幾乎不必製作uml架構,但是您必須閱讀其中的很多架構。

圖很酷,但總是過時,所以不是很重要。

在另一方面,沒有用例活性圖說明的是一大堆更難閱讀並轉換成代碼。

1

我發現UML的一個優點是它可以幫助人們以平臺不可知的方式傳達設計和意圖。

讓我們說你正在使用其他團隊提供的API方法編寫代碼。如果您有一個API類的UML圖(類圖),並且遵守了適當的命名約定,那麼您可以輕鬆找出您希望可用於特定類的所有API方法。例如,如果類圖指示要聚合的兩個類之間的關係,並且基數爲1 .. *您可以合理地假定容器類可能提供迭代器以訪問組成元素。 在目前的情況下,使用API​​類的開發人員可以快速獲取API類的高級概覽,而不是通過API文檔並找出他想使用的方法。

3

不要犯思想錯誤UML只是類圖。用例圖是開發者和管理者之間的溝通橋樑,序列圖允許在視覺上所描述的精確算法等

使用這些結合在一起,UML做了兩兩件事:

  1. 正如有人編寫的應用程序它迫使你想出你的軟件如何配合在一起之前你開始撥出代碼
  2. 作爲有人加入團隊,它可以讓你更快速地瀏覽代碼庫,而不是通過所有代碼拖網。
+0

我明白了。我喜歡第2點。 – loriser 2010-02-23 11:57:53