即使对可用工具分类的简短总结，也会带来数量巨大的选择。Rational软件架构师？Visio？PowerPoint？OmniGraffle？WebSequenceDiagrams.com？你选择哪一个?!
然而关键在于，架构和设计软件并不需要UML工具。在过去几年的大会演讲中，我做了一些非正式的调查，只有10%~20%的听众说他们在日常工作中经常使用UML。一张白纸、挂图或白板，以及一套便利贴或索引卡，你需要的通常就是这些，特别是当你有一组人想要以协作的方式承担设计过程。你有没有试过三四个人挤在笔记本电脑屏幕前协作？
敏捷方法将这种技术含量不高的方法用于捕捉用户故事、故事墙和看板已经有一阵子了。在许多情况下，这是能够奏效的最简单的方法，但什么都抵不过办公室中间人人都能看到的、贴满了东西的白板。跟微软项目计划不同，没人能忍住不走过去瞧瞧那些仍在“待办”一栏的便利贴。
从软件设计的角度来看，使用技术含量不高的方法，可以把你从对使用工具的复杂性的担忧和对正式标记法的屈从中解放出来，从而能集中精力在软件设计的创造性工作上。就以勾画出大局 为起点，加工必要的底层细节。记住，如果你不使用工具，就需要明确地思考各个抽象层次之间的可追溯性、规约和一致性。比如，UML的箭头是有意义的，缺了线索，你随手画的箭头到底是指向依赖还是指示数据的流向，可能就不明显。如果过后需要的话，你总是可以用UML工具以更加正式的方式记录你的设计。