5、面向接口_业务模型分析实例3
2013-11-21 00:17
225 查看
前面已经分析了6个接口,接下来我要拿其中的2个来说明。说下想法,对于业务的分析,我所列举的接口的分析只是其中的一部分,还有相当的一部分需要有actor的,也就是说需要去画时序图,需要详细描述清楚对象是如何去干一件有意义的事的,那么我的文章是主要描述接口的应用,所以省略掉了一部分uml的分析(省略掉了并不代表没有)。另外,业务接口因为不需要执行者,所以它更像是一个场景而已,而对付场景的分析,那么活动图就可以大显身手了,对于我下面的分析,是想做实现无关和对象无关(将来的实现类),所以对于下面的尝试,更多的意义在于订立业务接口的输入项和输出项,说的更明白些就是边界。物料的分离(人和物),边界的分离(事),有利于我们去把规则也分离出来,究竟将来是让哪个物料通过边界,如何去通过边界就变得有秩序和有规则,而究竟让谁去执行或者指挥运作也变得更加灵活(谁都可以去做事),目标如下:
第一,通过画时序图将某人做某事详细记录下来,这部分就是面向对象的分析(省略)
第二,通过画活动图将业务接口详细记录下来,这部分就是面向接口甚至有可能包括面向过程的分析了
第三,不清晰的通过业务接口预留好以后分析,遗忘了的,或是其它完全不知道如何分析的无所谓了(后面我会就业务修改了、业务增加了、业务去除了、更新了等分析)
好了下面开始
![](https://img-blog.csdn.net/20131120231459343?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2VuZGlk/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
这是其中一个接口活动图,需要说明一下,在描述这个活动的时候发现,输出项中 生成一段html代码代表什么呢?好像作为业务人员自己都不知道是什么,所以发明了一个网页碎片这个东西。这个网页碎片就是画活动图的所得之一,另外发现录入者身份不需要输入吧(身份这个是自动带的),走完发现了2个必填,这些都是不少的收获,也就是最主要的目的是又精华了一下业务接口的输入项和输出项,另外捎带着把业务也记录了一下,留着吧,这个也有用
另外一个
![](https://img-blog.csdn.net/20131120233944156?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2VuZGlk/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
看到了吧,活动图也可以玩玩对象,当然描述业务接口并记录它的一个实现是主要的,通过上面这个图就可以清晰的看到,也许游客增加博文接口也许包含2个或是更多的业务接口,这就是话活地图的目的啊,当然点到为止,不往下继续分析了,但如果实际项目就需要再继续分析了,所以这个接口其实是一个大的包含N个小的业务接口,那么大致的边界也有了
最后说明一下,为什么要用活动图呢?时序、状态、协作的那些不需要吗?那就看你什么需求了,如果真正需要业务和系统设计分离,也就是业务和程序员老死不相往来,那么就需要更多层次的描述来说明相同的业务,那么就根据需要添加吧,描述清楚为准。对于上面我的说明是最少配置吧,现在回头看一下您就能明白,这些图也许我们经常碰到,它其实不就是业务人员说的流程图吗?对于业务人员画流程图应该是最少成本,我这么说应该就可以理解的吧。
好了 ,接下来就是最关键的地方了,概念层的分析了,如果说,业务层分析是决定项目的目标(我们的目标是罗马),那么概念层则是决定要如何要选路(为什么选这条路),也就是概念就是大脑或是大桥,那为什么我们经常又不用呢,因为可以把概念分散在业务和系统设计上去,举个例子说:业务清楚了(业务)-----〉哈哈,用这个设计模式最合适(程序员),理由充分:设计模式好改,业务变化也没关系,这不就可以了吗?那我要问了,万一改的不符合设计模式了呢?那就改呗。。。。我要不想改呢?我要不让你用适配器模式呢?下一章我们一起来讨论下概念,谈一下分析类,边界类,控制类,实现类,最主要再谈下接口
第一,通过画时序图将某人做某事详细记录下来,这部分就是面向对象的分析(省略)
第二,通过画活动图将业务接口详细记录下来,这部分就是面向接口甚至有可能包括面向过程的分析了
第三,不清晰的通过业务接口预留好以后分析,遗忘了的,或是其它完全不知道如何分析的无所谓了(后面我会就业务修改了、业务增加了、业务去除了、更新了等分析)
好了下面开始
这是其中一个接口活动图,需要说明一下,在描述这个活动的时候发现,输出项中 生成一段html代码代表什么呢?好像作为业务人员自己都不知道是什么,所以发明了一个网页碎片这个东西。这个网页碎片就是画活动图的所得之一,另外发现录入者身份不需要输入吧(身份这个是自动带的),走完发现了2个必填,这些都是不少的收获,也就是最主要的目的是又精华了一下业务接口的输入项和输出项,另外捎带着把业务也记录了一下,留着吧,这个也有用
另外一个
看到了吧,活动图也可以玩玩对象,当然描述业务接口并记录它的一个实现是主要的,通过上面这个图就可以清晰的看到,也许游客增加博文接口也许包含2个或是更多的业务接口,这就是话活地图的目的啊,当然点到为止,不往下继续分析了,但如果实际项目就需要再继续分析了,所以这个接口其实是一个大的包含N个小的业务接口,那么大致的边界也有了
最后说明一下,为什么要用活动图呢?时序、状态、协作的那些不需要吗?那就看你什么需求了,如果真正需要业务和系统设计分离,也就是业务和程序员老死不相往来,那么就需要更多层次的描述来说明相同的业务,那么就根据需要添加吧,描述清楚为准。对于上面我的说明是最少配置吧,现在回头看一下您就能明白,这些图也许我们经常碰到,它其实不就是业务人员说的流程图吗?对于业务人员画流程图应该是最少成本,我这么说应该就可以理解的吧。
好了 ,接下来就是最关键的地方了,概念层的分析了,如果说,业务层分析是决定项目的目标(我们的目标是罗马),那么概念层则是决定要如何要选路(为什么选这条路),也就是概念就是大脑或是大桥,那为什么我们经常又不用呢,因为可以把概念分散在业务和系统设计上去,举个例子说:业务清楚了(业务)-----〉哈哈,用这个设计模式最合适(程序员),理由充分:设计模式好改,业务变化也没关系,这不就可以了吗?那我要问了,万一改的不符合设计模式了呢?那就改呗。。。。我要不想改呢?我要不让你用适配器模式呢?下一章我们一起来讨论下概念,谈一下分析类,边界类,控制类,实现类,最主要再谈下接口
相关文章推荐
- 4、面向接口_业务模型分析实例2
- 3、面向接口_业务模型分析实例1
- 6、面向接口_概念模型分析实例1
- 《火球——UML大战需求分析》(第3章 分析业务模型-类图)——3.1 面向过程与面向对象
- [全程建模]设计模型和UML应用中的实例分析
- 分析用例分析图、找业务对象、画面向对象设计用例描述
- 对Spring中接口注入的理解实例分析
- java 实例分析 接口与类的应用
- 深入DAO业务设计-设计分析实例
- C#中IEnumerable接口用法实例分析
- linux设备驱动模型之 device(设备)原理与实例分析
- CI(CodeIgniter)模型用法实例分析
- PHP面向对象程序设计实例分析
- Java使用Statement接口执行SQL语句操作实例分析
- Javascript文档对象模型(DOM)实例分析
- 分析业务模型—UML类图
- 分析业务模型 - 类图 新书《火球 UML大战需求分析》试读 第3章
- MyBatis 源码分析——生成Statement接口实例
- Asp.net 面向接口可扩展框架之业务规则引擎扩展组件
- java学习,关于接口理解,实例分析