即使對可用工具分類的簡短總結，也會帶來數量巨大的選擇。Rational軟件架構師？Visio？PowerPoint？OmniGraffle？WebSequenceDiagrams.com？你選擇哪一個?!
然而關鍵在於，架構和設計軟件並不需要UML工具。在過去幾年的大會演講中，我做了一些非正式的調查，只有10%~20%的聽眾說他們在日常工作中經常使用UML。一張白紙、掛圖或白板，以及一套便利貼或索引卡，你需要的通常就是這些，特別是當你有一組人想要以協作的方式承擔設計過程。你有沒有試過三四個人擠在筆記本電腦屏幕前協作？
敏捷方法將這種技術含量不高的方法用於捕捉用戶故事、故事牆和看板已經有一陣子了。在許多情況下，這是能夠奏效的最簡單的方法，但什麼都抵不過辦公室中間人人都能看到的、貼滿了東西的白板。跟微軟項目計劃不同，沒人能忍住不走過去瞧瞧那些仍在「待辦」一欄的便利貼。
從軟件設計的角度來看，使用技術含量不高的方法，可以把你從對使用工具的複雜性的擔憂和對正式標記法的屈從中解放出來，從而能集中精力在軟件設計的創造性工作上。就以勾畫出大局 為起點，加工必要的底層細節。記住，如果你不使用工具，就需要明確地思考各個抽像層次之間的可追溯性、規約和一致性。比如，UML的箭頭是有意義的，缺了線索，你隨手畫的箭頭到底是指向依賴還是指示數據的流向，可能就不明顯。如果過後需要的話，你總是可以用UML工具以更加正式的方式記錄你的設計。