发展中国软件产业的未来之路
发信人: dych (lao), 信区: FreeDevelop
标 题: 攒软件：发展中国软件产业的未来之路
发信站: BBS 水木清华站 (Sat Dec 4 21:57:36 1999)
攒软件：发展中国软件产业的未来之路
近闻有北大方正等参加的中关村的一个代表团去印度“取经”，考察学习印度软件发展。
印度软件工业号称世界第二，仅次于老美。据说以色列的软件也很强，而中国这个泱泱大
国在软件方面却默默无闻，着实令人汗颜。中国人聪明又勤劳，为什么在软件这个既需要
智慧有需要汗水的行业
落后于人呢？确实需要好好总结一下。
中国目前的软件行业的现状是盗版，仿制和手工作坊式的个体户开发。拿来主义固然一时
管用，但是造成了现在微软的产品一统天下。手工作坊式的个体户开发只能凭借开发者的
聪明生产一些小的程序，不可能产生大的软件，更谈不上服务了。笔者认为中国的最大优
势是人多力量大，劳动
力价格便宜，看一看我们的VCD,服装，玩具，不是世界第一吗？只有象攒机器那样攒软件
，中国的软件产业才大有希望。可软件产业恰恰不是人多力量大，而是人越多，效率越低
，人多的优势和效率低的劣势抵消了。如何才能扬长避短呢？以下是笔者的一些思考，抛
砖引玉，仅供参考。
软件开发是一项智力与体力相结合的劳动，主要是脑力劳动。它既象作家创作文学作品，
又象数学定理的构造性证明。它需要创造性，但更多的是相关知识，逻辑及驾驭语言的能
力。可以把软件开发分成几个部分，由不同的人来实施。
1。分析/设计部分：由熟悉问题领域的专家与熟悉软件工程的专家来做。这些人要少而精
，有丰富的经验及丰富的专业知识。
2。编程部分：由熟练的程序员来做。这些人要熟练掌握一门或几门编程语言，熟练使用
开发工具，有丰富的开发经验。他们与第一部分人数之比是10：1。
3。测试/调试部分：这些人要测试和调试第二部分的程序，指出错误和修改建议。他们要
掌握一门编程语言，熟练使用测试工具，有丰富的测试经验。他们与第二部分人数之比是
1：1。
4。技术支持部分：他们要辅助第一二部分人员工作，并编写文档及帮助文件。还将负责
培训第五部分的人员。其人数与第二部分人数之比是2：1。
5。售后服务部分：他们将面向客户，负责产品的售后服务工作。这些人事先需要经过一
定时间的培训，以熟悉项目。对他们的要求是最低的，但他们的人数是最多的，与与第一
部分人数之比是10：1。
按照这一比例，所需人员将达到 400人，足以完成中等以上软件项目的开发服务。这样一
来，软件工业将成为继纺织服装，玩具等行业之后又一项劳动密集型行业，可以解决大量
劳动力的就业问题，最适合中国国情。
问题在于如何解决开发人员之间的协作以提高单位人员的劳动生产率？我们知道在软件行
业是人越多，效率越低。效率低的原因是每个开发人员的工作之间耦合严重。要尽可能减
少这种耦合，耦合的对立面是独立，如果能做到开发人员的工作之间相互独立，然后象攒
机器那样攒软件，岂不
是大大提高了软件开发效率？那么如何才能实现这一理想？笔者认为组件技术是最有希望
的选择。以下是笔者的一些思考，借用了数据库中对象关系模型，CORBA 以及面向对象软
件工程的一些概念，姑且称之为小型组件结构（small component architecture）。
1。面向对象。
与传统的面向对象相同，对象具有属性和方法。所不同的是对象对外部的声明要使用XML
格式，这种声明称为接口，要在接口数据库中登记，接受查询。这种思想来自CORBA
。另一点不同是对象接口中声明的属性没有复合结构属性，都是如整型，实型，字符型或
其数组，不含结构类型。这样就给外界一个简单的接口形象。当然对象内部可以使用结构
类型，但当对外输出时在接口中必须展开。
2。关系框架。
孤立的对象只有连成整体才能完成有意义的工作。对象通过关系框架联合起来，成为组件
。其实关系就是一种特殊的对象，用来连接一组对象。关系如同普通对象一样有ID，有属
性有方法，它们提供关系这一层次的功能。关系并不直接与对象相连，而是通过一种称作
角色的特殊对象来连接
普通对象。角色只能存在于某个关系对象之中，关系属性中保存着角色的ID。每个对象在
一个关系中只能充当一种角色，一个对象在不同的关系中可以充当不同的角色。角色就象
嵌在关系之中的空位，对象可以与角色相连从而占据那些空位。关系，角色，对象共同构
成一个局部环境（cont
ext）。容器及其中的内容，客户与服务器都是关系，角色，对象的典型例子。这种思想
来自CORBA ，关系数据库，对象链接和嵌入。
3。事件传递。
组件之间以及对象之间通过事件传递进行通讯来提供服务。服务有两种：一种是请求及提
供值，这里的值是计算或查询的结果；另一种是提供托管服务，这是迁移计算，类似java
的applet。第一种服务又有三种形式：公共消息型，谁愿意看谁看，不指定接收对象，类
似BBS
；mail型，发送给指定的对象，发送后立即返回，不等待应答；对话型：一问一答，保持
状态和连接。这其实就是传统的客户服务器模型的RPC
调用及消息通讯，连接或不连接，有无状态，是否阻塞，有否目的对象等形式的组合。当
然要进行改造，使之变得更容易使用。至于第二种迁移计算，可使用关系框架模式，用角
色将提供服务的对象与使用服务的对象连接在一起来实现。
4。代理机制。
通过代理机制可以使对象间的事件传递变得容易，至少从使用者的角度来看。代理是预先
编写好的对象，属于公共设施的一部分，内部集成了用于事件传递的方法。对象只需连接
上合适的代理，就将具有事件传递功能，无须编写事件通讯的代码。还有一件事情，对象
是独立开发的，事先并
不知道对方的接口格式，事后要使用事件通讯，需要做数据格式转换，这件事由对象适配
器（adapter）来做。适配器是专门套在对象上做接口转换工作的特殊对象。当然对象如
果事先知道对方的接口，可以不用接口转换，也就不需要适配器。
5。接口查询。
对象所声明登记的接口都保存在接口数据库中，可以通过接口数据库查询对象ID及对象所
提供的公开的服务。对象可以随时向接口数据库增加，删除，修改接口项，当然需具有一
定的权限。
6。XML 格式。
这是最有前途的通用文档格式，对象的接口声明将使用XML格式。它由标记和内容组成，
内容由标记括起来。
7。安全机制。
安全机制用来保证对象在一个可信赖的环境中通讯与协作，防止对象的未经授权的修改，
使用及冒名顶替。刚开始对象之间是互不信任的，要建立信用机制并保证对象间通讯可以
顺利进行。这需要深入的研究和单独的讨论。
8。可视界面。
使用可视化工具可以使业余爱好者开发出专业水平的界面，即使还不是专业水平的程序，
但至少可算作一个demo。每个对象都用不同的图标表示，图标就是对象的替身。开发者象
玩游戏时造坦克一样制造对象，连接对象，攒软件，岂不美妙？
归纳一下，中国软件开发的出路在于象攒机器那样攒软件，这要靠组件化的软件结构，辅
助工具及一批开发人员来实现。笔者将一些不成熟的想法抛出来，目的是引起大家的注意
，共同为中国软件产业的发展献技献策。
--
一万年太久，只争朝夕。
小虾
[36m※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 202.112.180.28]
标 题: 攒软件：发展中国软件产业的未来之路
发信站: BBS 水木清华站 (Sat Dec 4 21:57:36 1999)
攒软件：发展中国软件产业的未来之路
近闻有北大方正等参加的中关村的一个代表团去印度“取经”，考察学习印度软件发展。
印度软件工业号称世界第二，仅次于老美。据说以色列的软件也很强，而中国这个泱泱大
国在软件方面却默默无闻，着实令人汗颜。中国人聪明又勤劳，为什么在软件这个既需要
智慧有需要汗水的行业
落后于人呢？确实需要好好总结一下。
中国目前的软件行业的现状是盗版，仿制和手工作坊式的个体户开发。拿来主义固然一时
管用，但是造成了现在微软的产品一统天下。手工作坊式的个体户开发只能凭借开发者的
聪明生产一些小的程序，不可能产生大的软件，更谈不上服务了。笔者认为中国的最大优
势是人多力量大，劳动
力价格便宜，看一看我们的VCD,服装，玩具，不是世界第一吗？只有象攒机器那样攒软件
，中国的软件产业才大有希望。可软件产业恰恰不是人多力量大，而是人越多，效率越低
，人多的优势和效率低的劣势抵消了。如何才能扬长避短呢？以下是笔者的一些思考，抛
砖引玉，仅供参考。
软件开发是一项智力与体力相结合的劳动，主要是脑力劳动。它既象作家创作文学作品，
又象数学定理的构造性证明。它需要创造性，但更多的是相关知识，逻辑及驾驭语言的能
力。可以把软件开发分成几个部分，由不同的人来实施。
1。分析/设计部分：由熟悉问题领域的专家与熟悉软件工程的专家来做。这些人要少而精
，有丰富的经验及丰富的专业知识。
2。编程部分：由熟练的程序员来做。这些人要熟练掌握一门或几门编程语言，熟练使用
开发工具，有丰富的开发经验。他们与第一部分人数之比是10：1。
3。测试/调试部分：这些人要测试和调试第二部分的程序，指出错误和修改建议。他们要
掌握一门编程语言，熟练使用测试工具，有丰富的测试经验。他们与第二部分人数之比是
1：1。
4。技术支持部分：他们要辅助第一二部分人员工作，并编写文档及帮助文件。还将负责
培训第五部分的人员。其人数与第二部分人数之比是2：1。
5。售后服务部分：他们将面向客户，负责产品的售后服务工作。这些人事先需要经过一
定时间的培训，以熟悉项目。对他们的要求是最低的，但他们的人数是最多的，与与第一
部分人数之比是10：1。
按照这一比例，所需人员将达到 400人，足以完成中等以上软件项目的开发服务。这样一
来，软件工业将成为继纺织服装，玩具等行业之后又一项劳动密集型行业，可以解决大量
劳动力的就业问题，最适合中国国情。
问题在于如何解决开发人员之间的协作以提高单位人员的劳动生产率？我们知道在软件行
业是人越多，效率越低。效率低的原因是每个开发人员的工作之间耦合严重。要尽可能减
少这种耦合，耦合的对立面是独立，如果能做到开发人员的工作之间相互独立，然后象攒
机器那样攒软件，岂不
是大大提高了软件开发效率？那么如何才能实现这一理想？笔者认为组件技术是最有希望
的选择。以下是笔者的一些思考，借用了数据库中对象关系模型，CORBA 以及面向对象软
件工程的一些概念，姑且称之为小型组件结构（small component architecture）。
1。面向对象。
与传统的面向对象相同，对象具有属性和方法。所不同的是对象对外部的声明要使用XML
格式，这种声明称为接口，要在接口数据库中登记，接受查询。这种思想来自CORBA
。另一点不同是对象接口中声明的属性没有复合结构属性，都是如整型，实型，字符型或
其数组，不含结构类型。这样就给外界一个简单的接口形象。当然对象内部可以使用结构
类型，但当对外输出时在接口中必须展开。
2。关系框架。
孤立的对象只有连成整体才能完成有意义的工作。对象通过关系框架联合起来，成为组件
。其实关系就是一种特殊的对象，用来连接一组对象。关系如同普通对象一样有ID，有属
性有方法，它们提供关系这一层次的功能。关系并不直接与对象相连，而是通过一种称作
角色的特殊对象来连接
普通对象。角色只能存在于某个关系对象之中，关系属性中保存着角色的ID。每个对象在
一个关系中只能充当一种角色，一个对象在不同的关系中可以充当不同的角色。角色就象
嵌在关系之中的空位，对象可以与角色相连从而占据那些空位。关系，角色，对象共同构
成一个局部环境（cont
ext）。容器及其中的内容，客户与服务器都是关系，角色，对象的典型例子。这种思想
来自CORBA ，关系数据库，对象链接和嵌入。
3。事件传递。
组件之间以及对象之间通过事件传递进行通讯来提供服务。服务有两种：一种是请求及提
供值，这里的值是计算或查询的结果；另一种是提供托管服务，这是迁移计算，类似java
的applet。第一种服务又有三种形式：公共消息型，谁愿意看谁看，不指定接收对象，类
似BBS
；mail型，发送给指定的对象，发送后立即返回，不等待应答；对话型：一问一答，保持
状态和连接。这其实就是传统的客户服务器模型的RPC
调用及消息通讯，连接或不连接，有无状态，是否阻塞，有否目的对象等形式的组合。当
然要进行改造，使之变得更容易使用。至于第二种迁移计算，可使用关系框架模式，用角
色将提供服务的对象与使用服务的对象连接在一起来实现。
4。代理机制。
通过代理机制可以使对象间的事件传递变得容易，至少从使用者的角度来看。代理是预先
编写好的对象，属于公共设施的一部分，内部集成了用于事件传递的方法。对象只需连接
上合适的代理，就将具有事件传递功能，无须编写事件通讯的代码。还有一件事情，对象
是独立开发的，事先并
不知道对方的接口格式，事后要使用事件通讯，需要做数据格式转换，这件事由对象适配
器（adapter）来做。适配器是专门套在对象上做接口转换工作的特殊对象。当然对象如
果事先知道对方的接口，可以不用接口转换，也就不需要适配器。
5。接口查询。
对象所声明登记的接口都保存在接口数据库中，可以通过接口数据库查询对象ID及对象所
提供的公开的服务。对象可以随时向接口数据库增加，删除，修改接口项，当然需具有一
定的权限。
6。XML 格式。
这是最有前途的通用文档格式，对象的接口声明将使用XML格式。它由标记和内容组成，
内容由标记括起来。
7。安全机制。
安全机制用来保证对象在一个可信赖的环境中通讯与协作，防止对象的未经授权的修改，
使用及冒名顶替。刚开始对象之间是互不信任的，要建立信用机制并保证对象间通讯可以
顺利进行。这需要深入的研究和单独的讨论。
8。可视界面。
使用可视化工具可以使业余爱好者开发出专业水平的界面，即使还不是专业水平的程序，
但至少可算作一个demo。每个对象都用不同的图标表示，图标就是对象的替身。开发者象
玩游戏时造坦克一样制造对象，连接对象，攒软件，岂不美妙？
归纳一下，中国软件开发的出路在于象攒机器那样攒软件，这要靠组件化的软件结构，辅
助工具及一批开发人员来实现。笔者将一些不成熟的想法抛出来，目的是引起大家的注意
，共同为中国软件产业的发展献技献策。
--
一万年太久，只争朝夕。
小虾
[36m※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 202.112.180.28]
枫到红极枫飘落 , 情到浓时情转薄 . 昨日共看花盛荣 , 今朝独对落花风 . 神龟虽寿有竟时 , 情能绵绵无绝期 ? 风来风去风匆匆 , 断续情随断续风 . 缘起缘灭缘可求 ? 花自飘零水自流 .
