4、面向接口_业务模型分析实例2

       我们继续，除了上面的还有哪些可以做业务接口呢？最明显的还有‘定制提交表单’，就是这个图里面的，为什么定制提交表单是一个接口呢？因为它是一个模糊的概念，很有可能包含这2个用例，也有可能是3个。目前先按2个来看

从这个图来看的话有2个已经分析，1个没有分析，日后再说吧，然后说下为什么这么做

1. 这2个接口是我快速订立的，它一定正确吗？（不一定）万一输入项确少或是多了怎么办？（很有可能啊）这就是我用接口来解决模糊问题的办法，充分利用接口的解耦功能，把已经总结或是明确的业务先规划出来，它绝对不是完美的，但它已经可以去单独分析了，也就是说让接口去细化业务，如果有新的业务或是不同的问题，那么我们要不就从新订立，要不就改接口（这个改不建议！！如果必须要改那么前提是此接口从来没有被用过），这也就是前面所说，你所做的每一步工作都有意义
2. 其实它的意义就在于要先剥离人、物、事，然后通过接口来去建立关系 ，接口只是门，它只知道放谁进去，放谁出来，它并不知道究竟发生了什么，这就最大程度的保证了实现的灵活性，换句话说就是谁都可以做这个，所以对于很多复杂的关系，我们只能通过接口来互通有无，这样就最大程度的保证了耦合事件的发生
3. 为什么不用类图直接定义出interface而用usercase来表示接口呢，因为这个是业务接口，而usercase中并无接口的定义，只能如此啦，其实我是想最大程度的不去改变什么，而只去观察和分析，让业务人员也能看懂是我的终极目标
4. 事实上我建议大家把每一个usercase都做为接口来去分析，当然这样有点偏执，过度使用就是滥用啊，但是别忘了，业务为项目的根本啊，项目的失败往往和业务分析不够彻底有关，所以见仁见智的事大家自行处理就好，不要固守成规。

到这里用例分析结束，接下来我将会把这些业务接口变成活动图来去进一步分析，进而去验证接口的输入和输出项的准确性，并且试着去分析这些接口间的关系，为概念层的过度打下基础，另外谈一下我对概念层的理解，今天就到此结束了