关于BPM/SOA/MDA的随想 - Powered by Jdon

总共有 1 回复／ 1 页

mentat

悄悄话
发表文章: 17
注册时间: 2008年03月07日 14:16

关于BPM/SOA/MDA的随想	2008年06月30日 13:36
标签列表 ddd(126) 中间件(33) mda(11) soa(24)

软件开发不外是：需求->设计->组件->编码，在软件开发中，为提高效率，一般要求这四层尽量解耦，即各自变化，互不影响。
其实，现实中很难做到，一般变化的层次越高，引起的变化越大，组件可能只引起编码的变化，而需求一旦变了，则可能会全盘皆变；
所以软件开发的突破重点是如何隔离需求的变动；
当然应用人工智能是一个很不错的场景，只要业务人员与AI多对对话，什么都能搞定；但本世纪可能不会实现吧！
现实中，强大而灵活的组件及组件的组装架构也是一种很不错方法，BPM/SOA这么流行，也就是能灵活的粘合不同的组件！组件就象天地人中的人，BPM/SOA就是巫了，能通天达地。
积累的组件越多，做起什么应用系统、管理咨询也就越轻松，所以现在中间件厂商都被做咨询的、做数据库的、做操作系统的招安了嘛！
组件在设计及以下层之间做了很好的隔离。当然，要组装起组件，还是要做一些编码！当然是BPEL、SCA级次的编码。
这两天看了下MDA，觉得可能不会有什么前途吧！ MDA的目的，在于解耦设计与实现。基于这样一种认识：设计的变化自动引起实现的变化。
源代码的自动生成是其主要方式吧！使“编码”一层尽可能的“薄”，当然这个“薄”不是指数量少，而是指开发人员关心的少、做得少。
UML作为一种需求分析工具很强大，但它能否象BPEL/SCA一样起作用呢？或者作为BPEL/SCA的前端图形化工具？
需求的变动是软件开发公司不好控制的，重点只能在组件及组件组装架构上了。组件设计得好、组装方式灵活，就能以不变应万变。
客户需求只管来，反正敌有铁浮图，我有麻扎刀。但万一客户提出组件及协作不能达到功能，那只能敌有狼牙棒，我只有天灵盖了，开动脑筋去开发、维护组件了。
但强大的组件（很难理解），灵活的组装方式（很难掌握），实际上把开发的复杂性转移了。
MDA能否减少这种复杂性？就要看它所能表达的语义能否囊括这种复杂性了。首先要能表达组件所有的行为，然后还要能表达组件协作所能产生的行为。
在嵌入式系统中，以上行为可能不是太多，MDA能胜任愉快。但在企业应用中业务可能太复杂了，以至于要么MDA表达不了，要么MDA不断扩展，以至于太复杂了，导致其产生的问题，大于了其能解决的问题！
我看它可能只会起到设计工具的作用，想成为一种开发语言或者模式，还有很长的路要走！

banq

悄悄话
发表文章: 9482
注册时间: 2002年08月03日 17:08

回复:关于BPM/SOA/MDA的随想

2008年09月17日 08:40

很好的思考和观点

MDA是一个努力方向，MDD/DDD也是，其实我们的软件系统如果计算机身份越明显，就越不能快速跟随需求变化，如果我们把需求知识和计算机概念看成矛盾两个方面。

所以，站在需求只是和计算机概念分界线中间才能协同这两个一起发展，做好他们两个之间变动的沟通，而显然DDD/oo方法是目前最适合的，相反数据库等计算机概念很强的则不能。

这个主题有 1 回复／ 1 页