知道UML造成了怎樣的局面大混亂嗎？知道什么樣的功能是UML擁有但JAVA不具備的嗎？知道我們?yōu)槭裁葱枰齁AVA外的另一種電腦語言嗎？UML并不僅僅只是JAVA或者其它什么語言的替代品。UML并不僅僅只是JAVA或者其它什么語言的替代品。UML是面向?qū)ο蟮姆治黾霸O(shè)計的注釋。UML是獨立于那些傳統(tǒng)設(shè)計語言之外的一種語言。因為UML并不依附于某種語言，而且它被用作是聯(lián)系溝通Java、 C++ 、Smalltalk等語言的基礎(chǔ)工具。通過使用UML，可以在開始編碼之前規(guī)劃好整個系統(tǒng)，并且開發(fā)人員清楚自己所負責的模塊在整個系統(tǒng)中所起的作用。
更為重要的是，UML可以幫你記錄下從設(shè)計就開始出現(xiàn)的錯誤，要知道糟糕的設(shè)計會帶來一系列的麻煩。設(shè)想一下，在源代碼編制到一半的時候，你突然發(fā)現(xiàn)你所需要的信息已經(jīng)枯竭了，但你卻沒有辦法重新取得信息，因為你沒有引用OBject，甚至于你引用了object，然而信息確是非public的。顯然的，你將花費數(shù)天時間來找出代碼的變化。
UML可以幫您擺脫如下一些困境：代碼隨著細節(jié)的增多而累積，因此，查找哪些是系統(tǒng)的基本要素，了解objects之間的關(guān)系如何以及它們之間怎么聯(lián)系都會變得困難起來。當大量的代碼產(chǎn)生出來的時候，做一些改變也變得困難。因此決定一個對象的功能被分配到協(xié)作中的設(shè)置是一項主要的工作。甚至有時只是改變一個方法的名稱那樣簡單事情，也很可能導(dǎo)致一個很長的編輯----編譯---錯誤循環(huán)。
在編碼之前高水平的設(shè)計是進行正確的需求分析和精確的定義，UML的自動化工具固然重要，但UML在設(shè)計討論中就顯得更為有用。
OOA, OOD, and OOP
什么是OO分析和設(shè)計？它們與OO編程相比又有什么不同之處？要了解這些，請注意觀察一個程序的循環(huán)過程
第一步，需求收集：首先要規(guī)劃好系統(tǒng)，計劃好系統(tǒng)的實施步驟。通常人們都會通過討論來萃取出需求，并做詳細記錄，然后與關(guān)鍵用戶或是消費者一起探討并使他們同意你們已掌握系統(tǒng)正在解決的問題。
OOA （Object oriented analysis）即是描述系統(tǒng)實施與系統(tǒng)規(guī)劃相結(jié)合一個的進程。解析放大了處于問題中心區(qū)域的目標，分析它們的重要作用是什么，分析何種目標與何種目標相聯(lián)系。另外，解析還決定何種目標從屬于公用類別。
OOA （Object oriented analysis）即是描述系統(tǒng)實施與系統(tǒng)規(guī)劃相吻合的一個過程。分析放大了處于問題中心區(qū)域的目標，分析它們的重要作用是什么，分析何種目標與何種目標相聯(lián)系。另外，解析還決定何種目標從屬于公用類別。
特別地是，解析應(yīng)與現(xiàn)實生活中的問題類似，不需要產(chǎn)生什么新的復(fù)雜的問題。你甚至可以與一個不懂技術(shù)但懂得這些問題的人員來分享這些解析，他們可以指出你在解析中遺漏了什么，忽略了什么或者哪些地方出錯了。
OOD 在設(shè)計階段，你得準備將具體問題放大化以便分析。然后你得決定方法的自變量有哪些，以及它們的return類型。你也許可以發(fā)現(xiàn)新類將會幫您完成設(shè)計 。你可以抽象出公用的功能到接口或基類中。一個單一的分析類可以分解成為幾個合作類。總而言之，你仍停留在規(guī)劃階段，而不是實施階段。。
OOP在您搭建好一個框架后，下一步就是實施代碼了。在合適的設(shè)計后，你可以按以下步驟來實施細節(jié)：
1、是使用哈西表或者是二叉樹
2、是使用RMI還是CORBA來完成客戶/服務(wù)器的通信？
3、用何種語言？
為了更真實的體驗到UML是怎樣在解析及設(shè)計階段起鋪助作用，則需要通過解決一個問題來了解。
一旦你將一切都代碼化并且處于施行中，你就可以將周而復(fù)始的循環(huán)運用。隨著系統(tǒng)交付日期的臨近，更會發(fā)現(xiàn)什么地方不足，以及下一步需要完善哪一部份。通過使用交互式的解析、設(shè)計，完善及運行，你可以很迅速、穩(wěn)定地重復(fù)運行及完善系統(tǒng)，而不需要擔心遺失代碼
源自
IT資源網(wǎng)