Aaron之无主题空间

皆主题,此谓无主题。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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

Posted on 2009-05-31 14:35  Aaron  阅读(659)  评论(0编辑  收藏  举报
 

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

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

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

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

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

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

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

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

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