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