规避系统用例建模的常见 “陷阱” ！_用例图缺少系统边界-CSDN博客

本文链接：https://blog.csdn.net/SystemEngineeringLab/article/details/146378994

为什么要写这篇文章？

需求分析建模往往是许多团队弱化的环节，但其在整个研发生命中其中又有极为重要。在参与评审的诸多技术方案案例中，团队在表述用例图时依然有很多普遍存在的共性问题。因此，单独写一篇文章跟大家一起探讨交流，希望对大家有所帮助。

这些问题在你的团队出现过吗？

系统用例分析是一种需求分析建模方式，用例图是常见的用例可视化形式，虽然工程实践中被广泛应用，但效果却差强人意。

问题一：用例参与者缺失，或覆盖不全

建模人员在通过用例图表述系统功能时往往弱化对参与者的分析，虽然这是用例建模非常重要的环节。

* 其一，缺失，用例图中不体现参与者

* 其二，忽略了“非人”的参与者，没有把关键的外部的系统参与者考虑在内，使得表述信息不完整

问题二：用例系统边界指定缺失，或不明确

用例图缺少系统边界，没有指明当前上下文的系统。这种现象很常见，问题是对于不太了解的干系人来说，无法从判断当前用例表达的是整体系统还是某个子系统，又或者是哪个端。没有边界所带来的理解成本远大于加上系统边界元素所带来的工作成本

问题三：用例元素过多

一张用例图密密麻麻的罗列满屏的用例元素，干系人需要仔细阅读才能了解用例所表述的知识。有些建模人员“追求全面、力求覆盖”，试图在用例图上事无巨细的表达功能的每个细节，

问题四：乱用关联关系的连线方向

很多用例建模人员试图通过参与者与用例的连线表述某种方向，比如信息流向、依赖方向、调用方向等等。问题并不是出在使用箭头标识方向，而是在于过度使用。

用方向表述某种更明确的信息是允许的，且在某些场景下可能是必要的。但原则上是“无必要不使用”

问题五：用例关系使用混乱

最为常见的关系是包含关系和扩展关系，这两种类型在用例图的表述中非常常见。有些建模人员无法正确的区分包含和扩展关系的本质用途而导致错误使用，或者千篇一律的使用包含关系。这种使用方式，在一定程度上能够表达某种关联的、结构化的联系，但也会丢失原本要表述的业务语义。

问题六：用例抽象层次混乱

见多有四层包含关系的用例图，也见过一张用例图中用例个数超过20个的情况，虽然，“更多的用例可能能够更全面的表达需求”，但，往往会提高干系人的认知成本，严重降低可视化建模带来的有效信息传递效率，使得建模分析的结果大打折扣。

在业务分析过程中，用例建模是分析需求的重要方式，其本质上是对问题域范围的一种抽象，建模过程也是抽象过程。把需求浓缩至简洁的用例表示，有助于干系人间达成共识。既然本质上是抽象，就会涉及抽象的粒度和层次问题。过度抽象则会丢失细节从而失去指导意义，过度详细则信息膨胀从而降低认知效率。通过不同的抽象层次分解问题的复杂度是有效的方式。

问题七：用例命名不合理

命名！命名！命名！这个可能不仅仅是用例建模中存在的问题，在设计和开发等阶段普遍存在。合理的命名事半功倍。在使用用例进行建模分析的上下文中，合理的命名至关重要，见名知意，有利于在干系人间快速达成一致。

举个例子，对于交易系统来说，使用“Create Order” “Add Order” 还是 “Place Order” 呢？又或者使用“Oder Cancel” 还是 “Cancel Order”呢？当然，不同的业务域有自己问题域，但对于用例命名来说，至少要遵循：

* 动宾结构

* 统一语言：使用与业务域一致的概念，不要造新概念

问题八：引入技术概念

用例建模是对问题域的表达，不应该引入“技术”概念，因为技术概念隐形表达了某种解决方案，或者实现。在高层需求分析阶段，应该紧贴业务域，尽量避免引入技术元素。

有哪些建议

* 单个用例图用例元素建议5-10个，如果过多则抽象为不同层次进行表述

* 明确用例要描述的系统边界

* 慎重使用参与者与用例的连线方向，无必要不使用

* 业务域一致，不要引入新概念，或者技术概念