Achilles’s Cabin

工作了，每天变得比学校的时候更加简单。难道生活就是这样的吗？

七月份的时候这个床一直不好用，以为挂了呢，今天同学在群里公布blog，我就抱着试试看的态度回这里看了一下，surprisingly,这里又打开了。做个记号，从今天开始继续搏我的老哥。

来自http://xjcxp.mblogger.cn/posts/11271.aspx
管理软件的生产模式
重温ERP的生产计划部分，通常把生产流程划分为连续型生产、重复性生产、基于库存的生产、基于订单的装配和基于订单的设计，尽管不是很严格的定义，却也不失为一种好的归类。

联想起管理软件的生产问题，较之IT技术的飞速发展，其生产率并没有显著的提升。企业对信息化的渴求与管理软件实施与服务成本的居高不下，是目前这个市场最为突出的矛盾。也许也可以对管理软件的生产问题先归归类，以便更好地分析问题的症结所在。

一、标准产品模式

搞一个产品到处买，是最为理想的方式。数据库、Office等软件就是这样成就了Oracle、Microsoft。在企业应用领域，CAD、办公OA等也可以在一定程度上做到标准化。但最突出的是财务软件，用友、金蝶已成为一个经典范例。

当然，管理领域是如此复杂，差异化是如此丰富，这种标准产品模式已经是可遇不可求了。

二、完全项目模式

国内很多中小软件公司都是靠这种方式生存的。没有什么产品积累，搞一大帮开发人员，从零开始为用户定制开发企业应用。对用户而言，这个可是最彻底的量体裁衣。

但这并非说明用户的业务就真的这么特殊，软件开发商也并非自觉地地专注于一个细分的市场。就国内而言，这种情况是管理软件的起步阶段，低水平建设的标志。实际上，考虑到IT人员的高流动频率，此类软件开发商大多处于低水平重复的恶性循环，也不大可能为客户提供高质量的产品和服务。

以上二种方式实际上是二个极端，一个完全标准化，一个完全定制化。在管理软件市场的起步阶段，这二种方式占据主流的位置。随着市场的逐步成熟，这二种方式也逐步被边缘化了。预计今后只有在特定的细分市场，这二种方式才会被继续采用。

三、二次开发模式

一个完全项目模式的开发商，在多个案例中可以归纳出项目的许多共性，于是一种产品原型便提炼了出来。在这个基础上，再给客户作定制开发，开发效率无疑会大幅提升。这种二次开发模式于是便成为管理软件的主流开发模式。

过去搞标准产品的开发商，如用友、金蝶，在向ERP进军的过程中，也纷纷采用这种通用模式。往往是先通过完全项目模式搞点积累，然后采用二次开发模式迅速打开市场。

四、参数配置模式

如果每个客户项目都需要派大批软件工程师进行二次开发，对于一个管理软件供应商而言，这种人力成本依然很高。具有丰富业务积累的供应商便需要考虑，如果事先把各种业务需求都预制在产品中，通过参数开关，实现对客户的个性化配置，这样便可以大大节省二次开发的成本。

当然，做到这一点，需要很大的投入。首先是，需要以丰富的业务积累为前提；其次，产品研发的难度很大，需要强有力的研发力量。

所以，目前也只有SAP在这方面做得较好。Oracle虽然也可以进行大量配置来个性化，但许多时候，还是要进行二次开发。用友和金蝶就更逊一些了。

二次开发和参数配置是目前的主流模式。管理软件商大都同时采用这二种方式来提供解决方案。而且，一个趋势是，随着产品研发的不断深入，大多强化业务积累和配置，减少二次开发的工作量。

但就SAP而言，虽然把参数配置模式发挥到及至，但其产品的复杂性和高昂的实施和维护成本，已经令客户不堪重负。解决方案的敏捷性便成了一个突出的问题。

五、构件装配模式

构件装配的思想显然是受制造业的启迪。这个思想已经提出很久了，构件技术也有了很大的发展。现有的管理软件产品，无疑也大量使用了构件技术。但是，很难说，时下的那种管理软件采用了构件装配模式。

以Delphi这种工具为代表的事件驱动开发，把构件技术首先用在表示层，大大提升了桌面应用的开发效率。EJB把构件技术成功地推广到中间服务层，充分体现了构件技术的威力。但这些技术型构件的积累，主要是对软件开发的效率有很大提升，关管理软件什么事？管理软件更关注业务的敏捷性。

于是，构件平台出现了。不仅是积累各种技术性构件，更主要的是积累丰富的业务构件，以实现对管理软件的快速装配。这种平台，目前在一些行业应用中得到了初步的展示。但是，它似乎更多地是同二次开发模式竞争。

实际上，正如我在以前的随笔里倡导的商业对象的去对象化，业务构件的积累则是典型的商业对象的对象化，其困难我以前的随笔已有说明。

六、模型驱动模式

这个思想也很早就出现了。只是那时多用一个技术术语：代码生成器。也就是说，通过图示表达自动生成程序应用。如今的技术有了很大发展，这个思路也就有了大展身手的舞台。OMG搞的受到IBM等大企业推崇的MDA，就是如今正热门的模型驱动模式。

模型驱动的基本思想是，把复杂的业务描述为一个平台无关的模型，再自动转换为软件代码，生成应用。这个思路可以说直指参数配置模式。无需研发成本高昂、复杂庞大、包罗万象的可以进行强大配置的erp产品，完全可以根据业务变化随时快速生成一个新的应用，能更好地适应业务的敏捷性。

以上，大致列出了6种管理软件的生产模式。如果非要给出一个演化序列，大致可以说，标准产品模式和完全项目模式为第一代，二次开发模式和参数配置模式为第二代，构件装配和模型驱动为第三代。目前的管理软件生产模式以第二代为主，但已经开始逐步向第三代演化了。

我个人的看法是，第三代模式将会以模型驱动为主导，构件装配将会隐退致幕后。这并不是说，构件技术被淘汰了。而是说，构件始终是技术构件。所谓业务构件，也仍然是程序代码段，积累再多，也不能有效应对业务敏捷变化。不如直接从业务模型自动生成应用来得快捷。

AcmeStudio is an architectural design environment that has been developed at Carnegie Mellon University. It provides a graphical interface that allows you to draw architectures in various styles, and to manipulate and analyze those designs. The terminology used in AcmeStudio is the same as the Acme architecture description language, and in fact AcmeStudio can read and write Acme descriptions.

C.A.R. Hoare’s Communicating Sequential Processes (CSP) is a model-language
hybrid for describing concurrent and distributed computation. A CSP program is
a static set of explicit processes. Pairs of processes communicate by naming each
other in input and output statements. Communication is synchronous with uni-
directional information
ow. A process that executes a communication primitive
(input or output) blocks until the process with which it is trying to communicate
executes the corresponding primitive. Guarded commands are used to introduce
indeterminacy.
CSP is a language fragment; it extends an imperative kernel with guarded
and parallel commands. Hoare’s primary concerns in the design of CSP have been
with issues of program correctness and operating systems description. CSP shows
its strong operating systems orientation by prohibiting dynamic process creation,
determining the interprocess communication structure at system creation, and
excluding recursion

操作语义的基本思想是建立一个抽象机器以模拟程序在执行过程中如何进行数据处理。
指称语义的思想是使语言的每一成分对应于一个数学对象，该对象称为该语言成分的指称，程序看作输入域到输出域的映射，输入域和输出域统称为论域。因此论域与映射是指称语义的基本研究对象。
公理语义实在程序正确性验证的基础上发展起来的，它给出一种方法，使人们在给定的前提下，验证某种特性是否成立。
代数语义的基本思想是把描述语义的逻辑体系和满足这个逻辑系统的各种模型统一在一起，同时把模型的集合看成是以代数机构，研究这些模型之间的关系

上个月乱七八糟的事情比较多，没有心情上来更新，先说说上个月都作了些什么吧。
五月第一周放假，充分的休息了一周，第二周就看了一周的软件设计师的考试，第三周填了个IBM的实习计划，没有报太大的希望，结果让我去笔试了 大老远跑到哈尔滨 考了一下，考试基本上是那种能力测试，内容很简单，只要能看懂E文就行了，过了不到一周又让我去面试，面就面吧，这时候都是第四周了，又跑了一趟哈尔滨，这个是我生平第一次面试啊，紧张倒是不紧张，可是本人不擅长表达自己，好几个问题回头想想可以展开谈谈的，可能表现太差了，估计也不会给我二面机会了，让我触动最大的可能就是那个英文交流了，口语好事多么重要啊 唉，从今天开始强化英语听说能力。
总的来说这次ibm的事给我的收获也算不小，希望下半年找工作自己能够好运气。

许多数学工具都是以集合为基础的，而lambda 演算与众不同，它是以函数演算为基础的．它允许任意高阶的
函数运算，也就是说，一个函数的输人和输出都可以是函数．这个特点使它特别适于用作语义描述的表示方
法，尤其是在指称语义描述中更需要用到它．
Lambda演算是一个形式系统，它被设计出来用来研究函数定义，函数应用和递归。它是在二十世纪三十年代由Alonzo Church 和 Stephen Cole Kleene发明的。Church在1936年使用lambda演算来证明了判定问题是没有答案的。Lambda演算可以用来清晰的定义什么是一个可计算的函数。两个lambda演算表达式是否相等的问题不能够被一个通用的算法解决，这是第一个问题，它甚至排在停机问题之前。为了证明停机问题是没有答案的，不可判定性能够被证明。Lambda演算对于函数式编程语言（例如lisp）有重大的影响。

λ-演算可以说是最简单、最小的一个形式系统。它是在二十世纪三十年代由Alonzo Church 和 Stephen Cole Kleene发明的。至今，在欧洲得到了广泛的发展。可以说，欧洲的计算机科学是从λ-演算开始的，而现在仍然是欧洲计算机科学的基础，首先它是函数式程序理论的基础，而后，在λ-演算的基础上，发展起来的π-演算、χ-演算，成为近年来的并发程序的理论工具之一，许多经典的并发程序模型就是以π-演算为框架的。

低级的任务首先就绪（由凸沿表示），那以后很快就获得互斥体。现在当高级
任务就绪，它必须被阻塞（用阴影区表示）直到低优先级的任务处理定它们
共享的资源。问题在于中级任务，由于它不需要对那个资源访问，所以抢先
于低优先级的任务执行，于是它就会耽误高优先级任务对于处理器的使用。
对于这个问题人们已经提出了很多解决方案。其中最普遍的方案叫作“优先
级的继承”。这个解决方案在高优先级任务等待互斥体的时候，就把低优先级
的任务的优先级升到那个高优先级任务的优先级。一些操作系统在它们的互
斥体实现中加入了这个修正，但是大部分都没有。

2005年时本人一生中比较重要的一年，因为马上就要找工作了，对于一个学生身份晃荡了近二十的人，马上就要步入江湖，心里总是有一点点迷茫。想来这应该是我人生中的一次转折吧。
马上就到五月一了，记得去年的这个时候，研究生的课程还没有结束，那时还有课可以上真是滋润啊。从去年五月一开始就进入了实验室，由一个博士师兄，一个博士师姐，带领大家做一个电信领域的网络管理软件。这个应该是本人的第一个“正规“ 的项目吧，由于我加入项目组比较晚，接替一个师兄的工作，对整个项目一点都不了解，刚一开始就拿到了一大堆java代码，每天看这些代码，分析每个类的作用，还好本人学过一点java，进度还算不慢。以前学软件工程说新人加入项目组要有短期的培训，我发现这个规矩到了实验室就没用了，唉，悲哀。
先来说说我所负责的工作吧，整个软件是分三大部分，我负责最上层的数据呈现，这个呈现就是对网络的拓扑结构进行呈现，要监视设备的运行状况 设备故障要以告警的形式添加到界面上，说来其实就是这么简单，其他就是些辅助的功能了，但是却让我在上面花费了一年时间。
说说具体用到的技术吧，整个系统采用jbuilder+weblogic+oracle的开发框架，多层体系结构，使用java语言开发，对象持久化使用jdbc，业务逻辑层使用statless session bean 上层界面图形化使用jviews+swing，大概也就涉及这么多的技术吧 。
至于收获吗，应该说是不小的 但是也浪费了不少时间，通过这个项目，让我对企业级软件开发有了全面的认识，对j2ee体系结构有了全面深入的理解，可以熟练的使用java语言，没有参与数据库的设计让我感到非常遗憾