语源科技BlogJava-架构师之家http://Architects.blogjava.net/专注于软件设计，特别是架构设计，交流架构设计经验。 <script src="http://www.google-analytics.com/urchin.js" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-424529-2"; urchinTracker(); </script> zh-cnSat, 06 Jun 2026 08:32:57 GMTSat, 06 Jun 2026 08:32:57 GMT60从面向对象到面向切面http://www.blogjava.net/canonical/archive/2011/05/08/349771.htmlcanonicalcanonicalSun, 08 May 2011 04:07:00 GMThttp://www.blogjava.net/canonical/archive/2011/05/08/349771.html
2. 面向对象(OOP)指出，在这一领域上可以建立分组(group)结构：一组相关的变量和函数构成一个集合，我们称之为对象(Object)。同时在分组结构上可以定义一个运算(推理)关系:  D > B, 派生类D从基类B继承（inheritance)，相应的派生对象符合基类对象所满足的所有约束。推理是有价值的，因为根据 D > B, B > A 可以自动推导出 D > A，所有针对A的断言在理论上对D都成立(这也就是我们常说的“派生对象 is a 基类对象”)。编译器也能有点智能了。
   一个有趣的地方是，D > B意味着在D和B之间存在着某种差异，但是我们却无法把它显式的表达出来！也就是说在代码层面上我们无法明确表达 D - B是什么。为了把更多的信息不断的导入到原有系统中，面向对象内置提供的方法是建立不断扩展的类型树，类型树每增长一层，就可以多容纳一些新的信息。这是一种金字塔式的结构，只不过是一种倒立的金字塔，最终基点会被不断增长的结构压力所压垮。

3. 组件技术(Component)本质上是在提倡面向接口(interface)，然后通过接口之间的组合(Composition)而不是对象之间的继承(inheritance)来构造系统。基于组合的观念相当于是定义了运算关系：D = B + C。终于，我们勉强可以在概念层面上做加法了。
   组件允许我们随意的组合，按照由简单到复杂的方向构造系统，但是组件构成的成品之间仍然无法自由的建立关系。这意味着组件组装得到的成品只是某种孤立的，偶然的产物。
   F = A + B + C  ? G = A + D + C。

4. 在数学上，配备了加法运算的集合构成半群，如果要成为群(Group)，则必须定义相应的逆运算：减法。 群结构使得大粒度的结构变换成为可能。
   F = A + B + C = A + D - D + B + C = (A + D + C) - D + B = G - D + B
   在不破坏原有代码的情况下，对原有系统功能进行增删，这就是面向切面(AOP)技术的全部价值。




canonical 2011-05-08 12:07 发表评论
]]>业务架构平台的自举问题http://www.blogjava.net/canonical/archive/2011/02/11/344053.htmlcanonicalcanonicalFri, 11 Feb 2011 06:02:00 GMThttp://www.blogjava.net/canonical/archive/2011/02/11/344053.html    采用业务架构平台来开发业务系统，即使看似开发工作量小，最终产生的各类配置代码量也可能会大大超过普通手工编程产生的代码量，这意味着平台封装了业务内在的复杂性，还是意味着平台引入了不必要的复杂性？很多业务架构平台的卖点都是零代码的应用开发，低水平的开发人员也可以主导的开发，但是为什么高水平的程序员不能借助于这些开发平台极大的提高生产率？
   一般的业务架构平台无法回答以下问题：
1) 业务系统可以通过使用设计工具来重用业务架构平台已经实现的功能，但是业务系统内部大量相似的模型配置如何才能够被重用？
2) 特定的业务领域中存在着大量特殊的业务规则，例如“审批串行进行，每一步都允许回退到上一步，而且允许选择跳转到任意后一步”。这些规则如何才能够被引入设计工具，简化配置过程？
3) 已经开发好的业务系统作为产品来销售的时候，如何应对具体客户的定制化？如果按照客户要求修改配置，则以后业务系统自身是否还能够实现版本升级？
  
   Witrix平台提供的基本开发模型为
          App = Biz aop-extends Generator<DSL>
在这一图景下，我们就可以回答以上三个问题：
1) 业务模型通过领域特定语言(DSL)来表达，因此可以使用语言中通用的继承或者组件抽象机制来实现模型重用。
2) 推理机对于所有推理规则一视同仁，特殊的业务规则与通用的业务规则一样都可以参与推理过程，并且一般情况下特殊的业务规则更能够大幅简化系统实现结构。
3) 相对于原始模型的修改被独立出来，然后应用面向切面(AOP)技术将这些特定代码织入到原始模型中。原始模型与差异修改相互分离，因此原始模型可以随时升级。

  Witrix平台所强调的不是强大的功能，而是一切表象之后的数学规律。Witrix平台通过少数基本原理的反复应用来构造软件系统，它本身就是采用平台技术构造的产物。我们用复杂度为A的工具制造复杂度为A+的产品，然后进一步以这个复杂度为A+的产品为工具来构造复杂度为A++的产品。



canonical 2011-02-11 14:02 发表评论
]]>模型驱动的数学原理http://www.blogjava.net/canonical/archive/2011/02/07/343919.htmlcanonicalcanonicalSun, 06 Feb 2011 18:56:00 GMThttp://www.blogjava.net/canonical/archive/2011/02/07/343919.html    一种技术思想如果确实能够简化编程，有效降低系统构造的复杂性，那么它必然具有某种内在的数学解释。反之，无论一种技术机制显得如何华丽高深，如果它没有 清晰的数学图象，那么就很难证明自身存在的价值。对于模型驱动架构(MDA)，我长期以来一直都持有一种批判态度。（Physical Model Driven http://canonical.javaeye.com/blog/29412 ）。原因就在于“由工具自动实现从平台无关模型(PIM)向平台相关模型(PSM)的转换”这一图景似乎只是想把系统从实现的泥沼中拯救出来，遮蔽特定语 言，特定平台中的偶然的限制条件，并没有触及到系统复杂性这一核心问题。而所谓的可视化建模充其量不过是说明人类超强的视觉模式识别能力使得我们可以迅速 识别系统全景图中隐含的整体结构，更快的实现对系统结构的理解，并没有证明系统复杂性有任何本质性的降低。不过如果我们换一个视角, 不把模型局限为某种可视化的结构图,而将它定义为某种高度浓缩的领域描述, 则模型驱动基本上等价于根据领域描述自动推导得到最终的应用程序。沿着这一思路，Witrix平台中的很多设计实际上可以被解释为模型定义，模型推导以及 模型嵌入等方面的探索。这些具体技术的背后需要的是比一般MDA思想更加精致的设计原理作为支撑。我们可以进行如下抽象分析。（Witrix架构分析 http://canonical.javaeye.com/blog/126467 ）

1. 问题复杂？线性切分是削减问题规模（从而降低问题复杂性）的通用手段，例如模块(Module)。（软件中的分析学 http://canonical.javaeye.com/blog/33885 ）

App = M1 + M2 + M3 +    


2. 分块过多？同态映射是系统约化的一般化策略，例如多态（polymorphism）。（同构与同态：认识同一性 http://canonical.javaeye.com/admin/blogs/340704 ）

(abc,abb,ade,) -> [a],   (bbb, bcd,bab,) -> [b]


3. 递归使用以上两种方法，将分分合合的游戏进行到底，推向极致。

4. 以少控多的终极形态？如果存在，则构成输入与输出之间的非线性变换（输入中局部微小变化将导致输出中大范围明显的变化）。

App = F(M)


5. 变换函数F可以被诠释为解释器(Interpreter)或者翻译机，例如工作流引擎将工作流描述信息翻译为一步步的具体操作，工作流描述可以看作是由底 层引擎支撑的，在更高的抽象层面上运行的领域模型。但是在这种观点下，变换函数F似乎是针对某种特定模型构造的，引擎内部信息传导的途径是确定的，关注的 重点始终在模型上，那么解释器自身应该如何被构造出来呢？

App ~ M


6. 另外一种更加开放的观点是将变换函数F看作是生成器(Generator)或者推理机。F将根据输入的信息，结合其他知识，推理生成一系列新的命题和断 言。模型的力量源于推导。变换函数F本身在系统构造过程中处于核心地位，M仅仅是触发其推理过程的信息源而已。F将榨干M的最后一点剩余价值，所有根据M 能够确定的事实将被自动实现，而大量单靠M自身的信息无法判定的命题也可以结合F内在的知识作出判断。生成器自身的构造过程非常简单--只要不断向推理系 统中增加新的推理规则即可。语言内置的模板机制(template)及元编程技术(meta programming)，或者跨越语言边界的代码生成工具都可以看作是生成器的具体实例。（关于代码生成和DSL http://canonical.javaeye.com/blog/275015 )

App = G<M>


7. 生成器G之所以可以被独立实现，是因为我们可以实现相对知识与绝对知识的分离, 这也正是面向对象技术的本质所在。（面向对象之形式系统 http://canonical.javaeye.com/blog/37064 ）

G<M> ==> G = {m => m.x(a,b,c);m.y();  }


8. 现实世界的不完美，就在于现实决不按照我们为其指定的理想路线前进。具体场景中总是存在着大量我们无法预知的“噪声”，它们使得任何在“过去”确立的方程 都无法在“未来”保持持久的平衡。传统模型驱动架构的困境就在于此。我们可以选择将模型M和生成器G不断复杂化，容纳越来越多的偶然性，直至失去对模型整 体结构的控制力。另外一种选择是模型在不断膨胀，不断提高覆盖能力的过程中，不断的空洞化，产生大量可插入(plugin)的接入点，最终丧失模型的推理 能力，退化成为一种编码规范。Witrix平台中采用的是第三种选择：模型嵌入--模型中的多余信息被不断清洗掉，模型通过精炼化来突出自身存在的合理 性，成为更广泛的运行环境中的支撑骨架。（结构的自足性 http://canonical.javaeye.com/blog/482620 ）

App != G0<M0>  ， App != G0<M1>， App = G1<M1>


9. 现在的问题是：如何基于一个已经被完美解决的重大问题，来更有效率的搞定不断出现但又不是重复出现的小问题。现在我们所需要的不是沿着某个维度进行均匀的 切分，而必须是某种有效的降维手段。如果我们可以定义一种投影算子P, 将待解决的问题投射到已经被解决的问题域中，则剩下的补集往往可以被简化。（主从分解而不是正交分解 http://canonical.javaeye.com/blog/196826 ）

dA = App - P[App]  = App - G0<M0>


10. 要实现以上微扰分析策略，前提条件是可以定义逆元，并且需要定义一种精细的粘结操作，可以将分散的扰动量极为精确的应用到基础系统的各处。Witrix平台的具体实现类似于某种AOP（面向切面编程）技术。（逆元：不存在的真实存在 http://canonical.javaeye.com/blog/325051 ）

App = A + D + B = (A + B + C) - C + D = App0 + (-C + D) = G0<M0> + dA


11. 模型驱动并不意味着一个应用只能由唯一的一个模型来驱动，但是如果引入多个不同形式的模型，则必须为如下推理提供具体的技术路径：
  A. 将多个模型变换到共同的描述域
  B. 实现多个模型的加和
  C. 处理模型之间的冲突并填补模型之间的空白
在Witrix平台中模型嵌入/组合主要依赖于文本化及编译期运行等机制。（文本化 http://canonical.javaeye.com/blog/309395 ）

App = Ga<Ma> + Gb<Mb> + dA


12. 系统的开发时刻t0和实施时刻t1一般是明确分离的，因此如果我们要建立一个包含开发与实施时刻信息的模型，则这一模型必须是含时的，多阶段的。关于时 间，我们所知道的最重要的事实之一是“未来是不可预知的”。在t0时刻建立的模型如果要涵盖t1时刻的所有变化，则必须做出大量猜测，而且t1时刻距离 t0时刻越远，猜测的量越大，“猜测有效”这一集合的测度越小，直至为0。延迟选择是实现含时系统控制的不二法门。
   在Witrix平台中，所有功能特性的实现都包含某种元数据描述或者定制模板，因此结合配置机制以及动态编译技术既可实现多阶段模型。例如对于一个在未来 才能确定的常量数组，我们可以定义一个Excel文件来允许实施人员录入具体的值，然后通过动态编译技术在编译期解析Excel文件，并完成一系列数值映 射运算，最终将其转化为编译期存在的一个常量。这一过程不会引入任何额外的运行成本，也不要求任何特定的缓存机制，最终的运行结构与在未来当所有信息都在 位之后再手写代码没有任何区别。（D语言与tpl之编译期动作 http://canonical.javaeye.com/blog/57244 ）

App(t1) = G(t0,t1)<M(t0,t1)> + dA(t0,t1)


13. 级列理论提供了一个演化框架，它指出孤立的模型必须被放在模型级列中被定义，被解释。（关于级列设计理论 http://canonical.javaeye.com/blog/33824 ）

M[n] = G<M[n-1]> + dMn


14. 推理的链条会因为任何局部反例的出现而中断。在任意时空点上，我们能够断言的事实有哪些？信息越少，我们能够确定的事实越少，能够做出的推论也就越少。现 在流行的很多设计实质上是在破坏系统的对称性，破坏系统大范围的结构。比如明明ORM容器已经实现所有数据对象的统一管理，非要将其拆分为每个业务表一个 的DAO接口。很多对灵活性的追求完全没有搞清楚信息是对不确定性的消除，而不确定性的减少意味着限制的增加，约束的增加。（From Local To Global http://canonical.javaeye.com/blog/42874 ）

   组件/构件技术的宣言是生产即组装，但是组装有成本，有后遗症（例如需要额外的胶水或者螺钉）。软件的本质并不是物质，而是信息，而信息的本质是抽象的规 律。在抽象世界中最有效的生产方式是抽象的运算，运算即生产。组件式开发意味着服从现有规律，熟练应用，而原理性生产则意味着不断创造新的规律。功能模 块越多，维护的成本越高，是负担，而推理机制越多，生产的成本越低，是财富。只有恢复软件的抽象性，明确把握软件构造过程内在的数学原理，才能真正释放软 件研发的生产力。（从编写代码到制造代码 http://canonical.javaeye.com/blog/333167 ）


注解1：很多设计原则其实是在强调软件由人构造由人理解，软件开发本质上是人类工程学，需要关注人类的理解力与协作能力。例如共同的建模语言减少交互成本，基于模型减少设计与实现的分离，易读的代码比高性能的代码更重要，做一件事只有唯一的一种方式等。

注解2：生成系统的演绎远比我们想象的要深刻与复杂得多。例如生命的成长可以被看作是在外界反馈下不断调整的生成过程。

注解3：领域描述是更紧致但却未必是更本质的表达。人类的DNA如果表达为ATGC序列完全可以拷贝到U盘中带走，只要对DNA做少量增删，就可以实现老 鼠到人类的变换（人类和老鼠都有大约30000条基因，其中约有80%的基因是“完全一样的”，大约共享有99%的类似基因），但是很难认为人类所有智慧 的本质都体现在DNA中，DNA看起来更像是某种序列化保存形式而已。

注解4：模型转换这一提法似乎是在强调模型之间的同构对应，转换似乎总是可以双向进行的，仅仅是实现难度限制了反向转换而已。但是大量有用的模型变换却是单向的，变换过程要求不断补充新的信息。

注解5：模型驱动在很多人看来就是数据库模型或者对象模型驱动系统界面运行，但实际上模型可以意指任意抽象知识。虽然在目前业内广泛流行的对象范式下，所 有知识都可以表达为对象之间的关联，但是对象关系（名词之间的关联关系）对运算结构的揭示是远远不够充分的。很多时候所谓的领域模型仅仅是表明概念之间具 有相关性，但是如果不补充一大段文字说明，我们对于系统如何运作仍然一知半解。数学分析其实是将领域内在的意义抽空，仅余下通用的形式化符号。



canonical 2011-02-07 02:56 发表评论
]]>软件架构设计参考文件http://www.blogjava.net/Jack2007/archive/2009/10/21/299238.htmlJack.WangJack.WangWed, 21 Oct 2009 12:04:00 GMThttp://www.blogjava.net/Jack2007/archive/2009/10/21/299238.html阅读全文

Jack.Wang 2009-10-21 20:04 发表评论
]]>J2ME移动应用开发及部署http://www.blogjava.net/raozhh/archive/2009/10/15/lbom.htmllbomlbomThu, 15 Oct 2009 09:50:00 GMThttp://www.blogjava.net/raozhh/archive/2009/10/15/lbom.html一、项目建立及应用实现

1、建立J2ME项目

clip_image001

2、在完成开发后，进入Application Descriptor编辑界面

clip_image002

3、因默认情况下，Application Descriptor文件中未定义MIDlet启动对象，因此需使用EditPlus或记事本等文本编辑器，编辑Application Descriptor文件（位于项目根目录下），并添加以下项目，如：

clip_image003

4、运行Application Descriptor编辑界面中的Lanuch as enumlated Java ME JAD，进行测试

clip_image004

5、在步骤4之后，会在项目根目录下的.mtj.tmp中生成LaunchFromJAD子目录，其中的worm.jad和worm.jar即是手机程序的安装文件

clip_image005

6、将worm.jad和worm.jar复制至手机中，运行worm.jad进行安装后，即可使用

二、问题分析：

1、如报【文件不完整】错误，则检查worm.jad中的项目是否完整。在Eclipse中使用Lanuch as enumlated Java ME JAD测试通过，并自动生成的此文件，一般都是完整的，不需作任何修改。

2、如报【版本错误】，则检查您在Eclipse中使用的的模拟器版本是否是您手机所支持的，出现此错误后，将模拟器版本调低试试。其位置如下

clip_image006

三、开发环境：

1、java JDK1.6.0_10；

2、EclipseV3.3.1.1；

3、sun公司J2ME-WTK开发包：sun_java_wireless_toolkit-2_5_2-ml-windows.exe

4、Eclipse移动应用开发包：eclipseme.feature_1.7.9_site.zip

lbom 2009-10-15 17:50 发表评论
]]>结构的自足性http://www.blogjava.net/canonical/archive/2009/10/07/297381.htmlcanonicalcanonicalWed, 07 Oct 2009 09:10:00 GMThttp://www.blogjava.net/canonical/archive/2009/10/07/297381.html    按照结构主义哲学的观点，结构具有三个要素：整体性，具有转换规律或法则（转换性），自身调整性（自律性）。整体性意味着结构不能被简单的切分，其构成要素通过内在的关系运算实现大范围的关联与转换，整体之所以成为整体正是以转换/运算的第一性为保证的。这种转换可以是共时的（同时存在的各元素），也可以是历时的（历史的转换构造过程），这意味着结构总要求一个内在的构造过程，在独立于外部环境的情况下结构具有某种自给自足的特性，不依赖于外部条件即可独立的存在并保持内在的活动。自律性意味着结构内在的转换总是维持着某种封闭性和守恒性，确保新的成分在无限地构成而结构边界却保持稳定。注意到这里对结构的评判并不是来自外在规范和约束，而是基于结构内在的规律性，所强调的不是结构对外部条件的适应性，而是自身概念体系的完备性。实际上，一个无法直接对应于当前实际环境的结构仍然可能具有重要的价值，并在解决问题的过程中扮演不可或缺的角色。在合理性这个视角下，我们所关注的不仅仅是当前的现实世界，而是所有可能的世界。一个“合理”的结构的价值必能在它所适应的世界中凸现出来。
   在信息系统中，我们可能经常会问这个模型是否是对业务的准确描述，是否可以适应需求的变更，是否允许未来的各种扩展等等。但是如果换一个思维方向，我们会发现这些问题都是针对最终确立的模型而发问的，而在模型构建的过程中，那些可被利用的已存在的或者可以存在的模型又是哪些呢。每一个信息模型都对应着某种自动推理机，可以接收信息并做一定的推导综合工作。一个可行的问题是，如何才能更有效的利用已有的信息进行推导，如何消除冗余并减少各种转换成本。我们经常可以观察到，某一信息组织方式更充分的发掘了信息之间的内在关联（一个表象是它对信息的使用不是简单的局域化的，而是在多处呈现为互相纠缠的方式，难以被分解），这种内在关联足够丰富，以至于我们不依赖于外部因素就可以独立的理解。这种纠缠在一起的信息块自然会成为我们建模的对象。
   如果模型的“覆盖能力”不再是我们关注的重点，那么建模的思维图式将会发生如下的转化


最终的模型可以由一系列微模型交织构成。模型的递进构造过程并不同于组件(Component)的实物组装接口，也不是CAD图纸堆叠式的架构概念所能容纳的。在Witrix平台中，模型分解和构造表达为如下形式  http://canonical.javaeye.com/blog/333167
     Biz[n] = Biz[n+1] aop-extends CodeGenerator<DSLx, DSLy>。
   在软件发展的早期，所有的程序都是特殊构造的，其必然的假设是【在此情况下】，重用不在考虑范围之内，开发可以说是一个盲目试错的过程。随着我们逐步积累了一些经验，开始自觉的应用理论分析手段，【在所有情况下】都成立的一些普适的原理被揭示出来，它们成为我们在广阔的未知世界中跋涉时的向导。当我们的足迹渐渐接近领域的边界，对领域的全貌有一个总体的认知之后，一种对自身成熟性的自信很自然的将我们导向更加领域特定的分析。很多时候，我们会发现一个特化假设可以大大提高信息的利用率，推导出众多未被显式设定的知识。我们需要那些【在某些情况下】有效的规则来构成一个完备的模型库。这就如同有大量备选的数学定理，面对不同的物理现象，我们会从一系列的数学工具中选择一个进行使用一样。
  




canonical 2009-10-07 17:10 发表评论
]]>基于WEB服务器导致消息中心各组件之间无法正常工作的问题分析与解决http://www.blogjava.net/raozhh/archive/2009/10/07/297379.htmllbomlbomWed, 07 Oct 2009 09:06:00 GMThttp://www.blogjava.net/raozhh/archive/2009/10/07/297379.html 

消息中心产品简介

产品简介

在XXX