杂话用例建模【3】：Use Case Modeling是百家争鸣的小学科

 

基本上，关于Use Case Modeling讨论我有两个基本原则：1）不会说一个分析模型是否正确（因为Modeling没有正确和错误）；2）不轻易卷入关于什么颗粒度、用例间关系、描述格式等方面的争论。

因为Use Case Modeling实在是个百家争鸣的小学科，以至于很多大师、顶级人物都很难在某些问题上达成一致意见。这些问题包括，Actor和Use Case 之间的关联是否要用箭头；Use Case描述的每一步“颗粒度”如何把握；用例的大小（用例的颗粒度）；用例间的关系；等等。

不过不用担心，这并不妨碍我们使用Use Case。因为首先，UML是一个重在实践的方法论，能对问题进行建模并实现作为沟通的功能是第一要素；其次，关于Use Case的很多争论，只要放到具体环境中即可有结论。争论往往起于凭空而谈，一旦失去现实因素，那些空洞的理论就会变得飘忽不定、不得其所。

所以解决这些大师们也很难和解的问题，可以有以下几个大原则：

1.       保持Use Case Model的简单性。Use Case Model是为了捕获并描述需求，那么就不要弄些东西来把问题搞得更复杂，这些东西可能包括复杂的用例图、用例间关系等。

2.       坚持实用为首要原则，具体情况具体对待。特定情况下，违反了一些常见规则又如何？比如CRUD，在大部分情况下我们都建议将之写成一个Use Case，可是当你的项目需求中Create、Retrieve、Update和Delete逻辑都很复杂的时候，为什么不可以分开来描述？

3.       根据自己的喜好选择。比如用例描述格式，会有数十种之多，选择一个自己喜欢的就可以；哪怕觉得不好下次可以换其他的。如果自己所在组织有统一规范，则可以以此为准。因为这样会更有利于你的工作。

4.       形成组织的共识。对于争议的东西，暂且搁置，在自己的组织、团队形成共识即可。就像“Good good study，day day up！”很多人也能理解一样，J！

另外，还有个小建议：在研究Use Case时，坚持“严”原则，使用Use Case时，采用“松”原则。我们在实际工作中可以“灵活的用”，而在一些关于建模的学习讨论中还是应力求深入，这样会帮助更加灵活的使用。