首页 > 代码库 > 基于UML的OOA/00D

基于UML的OOA/00D

现在大家都说框架、架构,就不得不先提分析与设计,谈到了DDD,又不得不谈OOA/OOD。

一套框架,首先是一套方法论,离开理论支持的框架很难长久的发展下去,框架是长期积累的结晶。能够从需求沟通、流程方案、系统设计、快速开发、细调等各个环节,能够无缝的衔接起来,最好能够用同一种声音说话。

BPM,我不知道在国内的项目里面,有多少个公司是真正的在用,当前都用到了什么程度,在作需求的时候是如何处理的。

我在流程引擎选型的时候花了很多的时间,由于没有什么资源,最后是选择了BPMN,因为自己长期以来的分析方法是活动图+状态图的方法,而且通过流 程分析直接能够与框架结合起来,并且映射到服务上去,能够做到流程细化完了,接口、函数基本都可以定下来了,比较能够贴近开发。

流程分析设计,可以直接在系统里画图,画完保存后,大的方面已经定义好;通过UML静态图把数据模型定义好,再把流程的关联对象、脚本、通用服务、界面加入后,就可以直接执行了。而且,后续的脚本、界面,是编码人员应该处理的。这样一样,角色的定义人员分工明确。

最为最为关键的是:BPMN让业务分析、需求分析人员与用户以同一种语言在说话,即使客户从来没有接触过,15分钟后,你所画的图,用户也都能看的 懂,能够提出你画的是否正确,是否把他的意思表达清楚了,你是否把他的想法表达清楚表达全了,与用户之间的不会产生歧义,软件出来后,流程方面与用户的期 望之间通常不会有多大的出入,可能界面方面会有些差异,但如果仅仅是界面的多一个字段少一个字段,对整个项目来说 ,影响通常会相对比较小的,如果再加上快速的界面设计,差异可能会更小。另一方面,与开发人员之间的沟通,也会把用户的意思完整的表达给开发人员,实现意 思的完整传递,使整个项目快速上线。从几个大的客户那边的来看,没有出现过大的返工的现象,整个项目的推进速度应该是非常快的。

这样基本上就可以实现模型驱动开发,这是我的理解,不知道有多少偏差。

举个例子,订单,订单包含明细,明细包含编码。

在流程分析的时候,订单是作为一个整体,明细是因为订单在存在而存在,离开了订单明细没有任何意义。按照封装的原则,服务对外只提供订单,订单内部 归内部处理。订单流转的时候也是作为一个整体,在处理订单详细的时候,用相关子流程处理,从而实现一层层细化。也就是流程+子流程+静态图的抽象。

不知道我说的是否清楚,没有说清的话,请留言,我再解释

下图为我在其中的一个项目里面的与SAP的交互图,是与生产相关的。

流程画完后,与SAP之间的接口也同步定义好了,当场没有定义出加工单的详细字段,在后续细节设计的时候还是应该很容易的设计出来的,至少这一块的 影响不会大。不过,这张图并没有完全按照严谨的流程图去画,重点是为了与用户沟通他们的操作的动作,是一个生产控制系统,业务系统可能会更严谨一些。

这是系统间的,对于系统内部,也是一样的思路与方法。

这张图与业务流程就更吻合一些,当前的这个流程稍加整理就可以通过流程引擎进行流转。

通过静态图可以把结构定下来,这张图可以把几个关键的字段定下来。

这就是我所说的,流程+子流程+静态图+界面,固定的操作可以通过Coding的方式把写进服务,而不是通过流程引擎或脚本去处理,比如增加、减少库存等等。不用流程引擎,则函数接口也定义出来了,差异也不会太大了。

这就是我理解的DDD,这是我用的分析方法, 在实际项目中自己感觉还是比较好用的,在还没有流程引擎和静态图工具的时候,就是通过这种方法把流程 定位到服务,数据库设计通过工具生成代码,然后再手工改代码与静态图一致这种方法实现了,手工映射到框架上去的。我的框架支持层次级联触发的,是树状态结 构,能够实现服务、对象的映射。

至于实际的分析设计,还需要深入的学习和实践的积累。