推荐订阅源

当前，在产品的功能分析中，遇到难题：虽然让大家统一使用UML规范来建模，设计用例图，但是图中的用例老是感觉不到位，不是多了，就是少了。

为了帮助大家更好的找出系统中的用例，特别引入了一组词“生、见、变、灭”。世界万物都是遵循这一规律：生、见、变、灭。

生：事物的产生，由无到有的过程。
见：事物被看到、被其他观察者查询、查看到。是展示于自然界中的形态。
变：事物的变化，有小到大、由弱变强等变化的过程。
灭：事物的消亡，从有到无。

正好，也在InfoQ中看到《理解REST软件架构》一文，也说到了这一点。

REST与CRUD原则

REST软件架构遵循了CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建（Create）、获取（Read）、更新（Update）和销毁（DELETE）就可以完成对其操作和处理了。其实世界万物都是遵循这一规律：生、变、见、灭。所以计算机世界也不例外。这个原则是源自于我们对于数据库表的数据操作：insert（生）、select（见）、update（变）和delete（灭），所以有时候CRUD也写作为 RUDI，其中的I就是insert。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。

在编写用例图的过程中要做到以下几点，就能从很大程度上避免丢失用例的情况：

1、找到一个业务实体（事物），验证其是否有“生、见、变、灭”相关用例。
2、对于“生、见、变、灭”的用例，其是否有相关的扩展。如：‘修改信息’的相关扩展可能为‘推荐’、‘审核’等影响其变化的用例。
3、基于各扩展，其是否又产生了新的实体。如：‘审核’发生时，就会出现‘审核信息’这一实体。那么这一实体的细分又产生了‘申请审核（生）’、‘批准审核（变）’、‘撤回审核（灭）’等。

一句话：即要通过实体的整个生命周期来考虑。

这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。 －－我们正是基于对“CRUD”这一基本操作的重复构造，来完成对用例的完整性检验的。

对于用例图中用例精度（粒度）的思考：
基于对　某一实体的相关用例的扩展而引起的新实体的用例，其可以做细分，也可以概括论之。其把握点在于这“新实体”对“某一实体”的影响有多大，以及怎么样能给读者恰好说清楚。