用UML建模和有時和座在一大堆事物面前很相似，開始吃之前就有不能吃完盤子里面的所有食物的想法可能毀了你的食欲。同樣的現象可能發生在UML建模過程中。用完全詳細的動態模型描述系統的每一個用例，而不得不創建一系列完整的時序圖、協作圖、狀態圖、部署圖，用例和類圖的想法可能會讓一個團隊完全脫離面向對象分析和設計。
在一個給定的建模方法中決定使用哪一個組件簡單同樣是要考慮的。舉例來說，在一個用例圖上同時使用USES 和EXTENDS真的有必要嗎？或者我們只需要使用USES？我的經驗是流程化的東西越多，建模成功的可能性越大。
Write the User Manual Before You Design the Classes設計類之前寫使用手冊
寫程序的一條老的規矩是在寫代碼之前寫使用手冊。在我學習的時候我認為這是一條好的建議，并且到今天為止我仍然認為是好的建議。在面向過程的年代和面向對象方法的早期，這條規矩很少被遵從。在用例驅動建模方法中，Jacobson把這個規律編寫成一系列的步驟，通過這些步驟可以為對象服務并且能用UML描述。每一個步驟建立在上一個步驟的基礎之上，形成一個可以跟蹤的方法，直道最后，管理能加強這個方法把它作為一個設計范例并且確認在分析和設計的過程中能被遵守。
基礎層次的人理解Objectory和用例驅動對象建模的本質的簡單方法是：在設計類之前寫使用手冊。大腦里一直有這個想法將會幫助你在UML的迷宮里穿越靜態和動態的建模符號。每一個用例代表著用戶手冊的一部分，并且應該按著“用例分析的目的是產生對象模型”的方式寫。
Organize Use Cases into Packages用例打包
一旦你準備為你的系統的每一個用例書寫使用手冊的時候，你將很快會意識到需要更高層次的把用例組裝起來。UML允許你把用例打包。這些可以用文件標簽代表。每一個包至少應該包括一個用例圖，這個圖可以作為一個上下文圖，它可能把設計階段每個用例的動態視圖和用例描述聯系起來。有一些項目從高層次的包分割開始。這些分割并不總是代表最終的分割，有時是很好的開始起點。
Use the Objectory Stereotypes使用Objectory模板
整個設計過程從用例中分離出來，表明注重描述它們是“正確“的方法。同時在需求分析和業務過程建模中用例作為一種備選方案正越來越受到歡迎。不同形式的用例建模有一些不同的向導，我遇到的大部分項目仍把用例作為得到對象模型的方法。
Jacobson的早期的OOSE/Objectory包括這樣一個我們稱之為健壯性分析的階段。在健壯性分析中，用例描述被解釋為粗略地分割一系列協作對象。在分析的過程中，Jacobson提出將對象進行分類，把它們分為接口對象，控制對象，和實體對象。
這個小又快的建模步驟產生令人驚訝的收益。它幫助人們寫出正確的用例，較早地確認客戶端/服務器端和MVC設計信息，很可能最重要的是快速的瀏覽所有用例能確認可重用的對象。同時也填補了需求分析和詳細設計之間的空白。
不幸的是，由于某些原因，健壯性分析的一些符號（三個容易畫的符號），在轉變的過程中只有部分保留在UML中。符號仍然存在，但被分離到一個稱為對象過程擴展的文檔當中，并且工具支持也缺少。我把健壯性分析作為一個整體部分描述用例（圖變成了文本的完全檢查）時，發現學生已經很快適應了這個對象。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
