SOA服务治理需求分析中遇到的困惑及解决过程

     最近在做一个SOA服务治理平台方面的需求分析，和以往做过的项目不同之处在于这个系统并不是业务主导型的，所以在使用UML进行面向对象分析时候遇到一个困惑。

   

     由于我采用的是用例驱动开发的RUP软件开发过程，而用例即代表参与者的目标，一个用例就是一个功能性需求，当我们把系统的功能性需求全都找出来，那么这个系统的问题领域我们就清楚了。在过去的企业级应用开发或者人机交互密集型（如业务主导型）项目中，使用这套方法论进行需求分析、UML建模是没有什么概念上的困惑，但是这次面对 非人机交互密集型的系统，我刚开始有点转变不过来。

 

    比如说这个系统需要对所有的SOA服务进行权限控制、流量控制和服务的监控，一开始我觉得几个好像不是功能性需求吧，如果不是功能性需求，那么如何用例驱动？参与者怎么识别？边界又在哪里？

 

   因为诸如 用户查看商品信息、用户支付订单等是很明显的功能性需求，参与者很明显是用户，边界可以很明显划分为交易，如图：

    

 
   但是权限控制、流量控制、服务监控呢？  我可以认为这三者是涉众中 运维人员的期望和目标，但是实际的业务流程中，它们由是运维人员发起的吗？ 明显不是，用例都要有一个启动者啊，那我用例图怎么画？活动图又怎么描述？还是说它们根本就不是功能性需求，不是用例，而属于非功能性需求的范围？

 

 

   在与网友的交流过程中，我确定了它们是功能性需求的观点。因为我现在面对的不是一个纯业务型项目，而是一个接近于底层产品的系统，对于普通的业务型项目来说，流量控制、服务监控这类确实是非功能性需求，但是对于我这个底层产品来说，它就是功能性需求，因为这就是涉中们直接对系统提出来的期望和目标啊，不是用例那是什么？ 另外一个参考的观点就是CSDN软件工程版主 “青润” 的解释：

 

    一些非功能性需求在一定阶段会转化为功能性需求，比如说，安全本身是非功能性需求，但是当某个安全模块成为一个标准件的时候，用户要求必须采用某个安全标准使得该模块达到这个安全模块可以做到的诸如文件必须经过安全检查，这时候，一个非功能性需求就变成了功能性需求。

 

    综合这些观点我豁然开朗，之前对于是否为功能性需求的纠结一下子不在困惑了。那么参与者呢？即用例的启动者呢？

 

   在我的知识体系中曾经存在一个知识点：不存在没有参与者的用例，用例不会自行启动。这说明没有人参与的需求一定有别的事物在发出启动的动作，应该找到这个事物，这个事物就是一个参与者，它可能是一个计算机系统、一个计时器或者一个 JMS 消息等。

 

   回到我的SOA服务治理平台中来，很明显，这个参与者非人，那是什么呢？经分析，我可以明确， 权限控制、流量控制、服务监控这些用例的启动者，参与者就是 服务的消费方（Consumer），它就是一个SOA消费方应用或者是其中的一个服务发起的，这是参与者非人的用例。

 

   

 

     明白了这些之后，接下去的事情就好办多了，照搬我的知识体系，SOA服务治理平台的需求分析：用例模型和领域模型也就随之完成了。