5、面向接口_业务模型分析实例3

前面已经分析了6个接口，接下来我要拿其中的2个来说明。说下想法，对于业务的分析，我所列举的接口的分析只是其中的一部分，还有相当的一部分需要有actor的，也就是说需要去画时序图，需要详细描述清楚对象是如何去干一件有意义的事的，那么我的文章是主要描述接口的应用，所以省略掉了一部分uml的分析（省略掉了并不代表没有）。另外，业务接口因为不需要执行者，所以它更像是一个场景而已，而对付场景的分析，那么活动图就可以大显身手了，对于我下面的分析，是想做实现无关和对象无关（将来的实现类），所以对于下面的尝试，更多的意义在于订立业务接口的输入项和输出项，说的更明白些就是边界。物料的分离（人和物），边界的分离（事），有利于我们去把规则也分离出来，究竟将来是让哪个物料通过边界，如何去通过边界就变得有秩序和有规则，而究竟让谁去执行或者指挥运作也变得更加灵活（谁都可以去做事），目标如下：

第一，通过画时序图将某人做某事详细记录下来，这部分就是面向对象的分析（省略）

第二，通过画活动图将业务接口详细记录下来，这部分就是面向接口甚至有可能包括面向过程的分析了

第三，不清晰的通过业务接口预留好以后分析，遗忘了的，或是其它完全不知道如何分析的无所谓了（后面我会就业务修改了、业务增加了、业务去除了、更新了等分析）

好了下面开始

这是其中一个接口活动图，需要说明一下，在描述这个活动的时候发现，输出项中  生成一段html代码代表什么呢？好像作为业务人员自己都不知道是什么，所以发明了一个网页碎片这个东西。这个网页碎片就是画活动图的所得之一，另外发现录入者身份不需要输入吧（身份这个是自动带的），走完发现了2个必填，这些都是不少的收获，也就是最主要的目的是又精华了一下业务接口的输入项和输出项，另外捎带着把业务也记录了一下，留着吧，这个也有用

另外一个看到了吧，活动图也可以玩玩对象，当然描述业务接口并记录它的一个实现是主要的，通过上面这个图就可以清晰的看到，也许游客增加博文接口也许包含2个或是更多的业务接口，这就是话活地图的目的啊，当然点到为止，不往下继续分析了，但如果实际项目就需要再继续分析了，所以这个接口其实是一个大的包含N个小的业务接口，那么大致的边界也有了

最后说明一下，为什么要用活动图呢？时序、状态、协作的那些不需要吗？那就看你什么需求了，如果真正需要业务和系统设计分离，也就是业务和程序员老死不相往来，那么就需要更多层次的描述来说明相同的业务，那么就根据需要添加吧，描述清楚为准。对于上面我的说明是最少配置吧，现在回头看一下您就能明白，这些图也许我们经常碰到，它其实不就是业务人员说的流程图吗？对于业务人员画流程图应该是最少成本，我这么说应该就可以理解的吧。

好了 ，接下来就是最关键的地方了，概念层的分析了，如果说，业务层分析是决定项目的目标（我们的目标是罗马），那么概念层则是决定要如何要选路（为什么选这条路），也就是概念就是大脑或是大桥，那为什么我们经常又不用呢，因为可以把概念分散在业务和系统设计上去，举个例子说：业务清楚了（业务）-----〉哈哈，用这个设计模式最合适（程序员），理由充分：设计模式好改，业务变化也没关系，这不就可以了吗？那我要问了，万一改的不符合设计模式了呢？那就改呗。。。。我要不想改呢？我要不让你用适配器模式呢？下一章我们一起来讨论下概念，谈一下分析类，边界类，控制类，实现类，最主要再谈下接口