2 UML难以从宏观把控业务流程的完整与准确
图4是用全程建模方法顺序图描述的业务协作流程——“采购”，它将业务事件序列与业务活动有机地集成在一个图形中，用户可以直观地判断软件开发人员描述的业务流程是否正确、完整。
图 4 采用全程建模方法的顺序图描述业务协作流程
图5与图6分别用UML顺序图和活动图描述的业务协作流程——“采购”，问题其一是用户需要左一眼、右一眼、上一眼、下一眼地对照两张图，费时费力，检查两种图时在所难免地会出现遗漏、不一致；问题其二是UML顺序图缺少条件分支的表达方法，表达内容不完整；问题其三是UML顺序图和活动图从形式上到内容上不存在等价关系。
使用UML描述业务流程很难让人放心，因为描述业务流程时产生的遗漏、不一致、不完整，同样会给项目带来灾难。这是纠缠不清的胡子工程问题点之二。
3 UML无法从微观把控业务信息的操作过程
图7从微观上用全程建模方法PAD图描述了职责细化流程——库管员如何“入库”，它不仅描述了岗位职责展开的具体逻辑步骤，同时也描述了如何对业务信息进行操作，如对“入库单”的 “实际入库数量、入库日期”等栏目进行填写操作，对“入库单”的 “商品规格、采购数量”等栏目及“采购计划”的等“商品规格、计划采购数量”等栏目进行读取操作。
图 7 采用全程建模方法的PAD图描述的职责细化流程
UML根本无法从微观上描述业务信息的操作过程，只能等到编程时再由有经验、责任心强的程序员去了解，这无疑于边盖楼边考虑在哪里开窗户，最后各种问题盘根错节，摁倒葫芦起了瓢。软件公司练就了不少救火高手，但不容否认的是充满了救火队员项目常常意味着灭顶之灾。这是纠缠不清的胡子工程问题点之三。
4 UML无法彻底全面描述用户的需求
图8是采用全程建模方法组成结构树进行功能定义，它可以细致到原子工作步骤级，比如“签字入库”仍然需要手工进行。
图 8 采用全程建模方法组成结构树进行功能定义
采用UML无法对这种功能需求直观地定位，结果是开发人员好心好意地实现了电子签名，而客户却毫不领情，应为中国用户不相信计算机的签名，去掉这个功能也是一件麻烦事。
