个人在系统开发过程中多次被客户骂成猪头后得到的个人观点：
很多人人UML语言能过完成系统所有从分析到设计，编码的过程，但是我还是要说说自己的观点：
对于技术人员来说，UML语言使用use case ，顺序图，流程图等都是从系统描述，内部结构，系统（开发人员）使用到的内部对象交互，发布构建组合等方面来展开整个系统的全貌的。但是对于客户来说，他并不关心你内部的对象是怎么交互的，你的数据结构是怎么保存的，他们更关心的是你的系统是否能够完成这样的功能，你的系统的界面表现方式，你做的东西能否处理这样那样的业务流程。
在工作中我发现UML有的弱点，就是对业务流程的描述的不明确性。对于说是自己没有描述好，用户看不懂这样的观点，我觉得还是有些问题，为什么我用其他方法的流程图（如IDEF1）能够很快地让用户了解，但是用UML的图不能很快地让用户看懂？这是我描述不好的原因还是我使用的工具不好的原因，这都有点难说。所以不建议使用UML来描述系统的业务流程。
就举个例子来说，帐务报销的审核，用use case 图可以看到报销单的填写，审核等功能，从状态图可以看到单子的状态的转换过程，但是我看不到单子的状态的转换是由哪一个actor来审批这样的场景在一个图上全部展现出来（当然这可以用场景描述来弥补），但这是不是UML的一个弱点呢？我做的时候不得不使用IDEF1x来描述业务流程，用UML来展现系统结构。不知道大家是否有什么好的建议？
