引子：
编程也有许多年，只是执着的喜爱，时常加班熬夜的编码，也时常迷陷进新技术的泥淖，回头看看想想，这一行实在是很辛苦的。
经常看到电视新闻里，很多工厂的自动化流水线，只需三、四个人便可完成庞大的生产任务，其生产效率和自动化程度之高令我艳羡不已。
软件工业总自命高科技产业，我这般搞软件的人也总自诩IT新贵，可一些事实总让我觉得：高科技、新贵云云，是有些名不副实的。
《程序员》杂志曾对程序员们做过一些有趣的调查[1]，其中有一项很值得人们思考。
调查的题目是“我的黑夜比白天多”，主要调查程序员的加班情况结果是：“有高达71%的程序员熬夜的天数超过了150天，这个加班的天数是否太高了？……在现实中，最大比例的程序员把属于自己的夜晚用来好好睡一觉……”。
这样一个高科技产业却满是员工们夜以继日的辛苦劳作，由此看来，软件产业是一个劳动密集型产业而不是人们向往的那个摩登的IT业[2]。
也许仍有人自欺的辩白，软件产业的科技含量决不是那些劳务产业能比拟的，软件员工的知识水平、综合素质也不是劳务工人所能比拟的。
还是看看我们的现实状况吧：太多的项目不能按时完成，为了完成只有持续的无底洞式的投入资金，盲目的也是无奈的盼望人月的堆积能拯救举步维艰的项目，可谁又不明白这也许只是饮鸩止渴呢？项目的成败往往取决于运气！
软件产业也仅仅是一个现代的劳动密集型产业！
这样的结论多么的悲哀，没有谁会怀疑我们整个产业的高科技含量，也没有谁会否认我们整个产业对其他产业自动化的巨大贡献，可是为什么我们自己却还徘徊于“手工劳作”的尴尬境地呢？
我常常幻想，有朝一日，软件生产也能有自己的自动化流水线，进入一个真正的自动化时代，但随着对这个行业了解的加深，越发感叹这个美好时代何其遥远，但我仍固执的幻想这一切终会实现！
本文就从这个观点出发，为这个时代的提早到来抛一块引玉之砖。
普通工业自动化的类比[3]
常在自动化流水线上看到一些灵活的机器将一件物品拿到另一个地方，或是拿着焊枪之类的工具加工器件，我们形象的称之为机械手，因为这些机械模拟了人的手，发挥了人手的功能。
由此可见，普通工业自动化本质上是人的行为的延伸甚至替代，它实现了人的动作的自动化。
常听人将计算机称为电脑，因为它模拟了人的大脑，发挥了人脑的功能，那么软件就好比这个“电动大脑”的思维，我们安装一套软件就好比灌输一种思想。
类比的，软件工业自动化本质上是人的思维的延伸甚至替代，它实现了人的思考的自动化。
软件工业自动化的定义和特点
软件工业自动化当属软件工程的研究范畴，软件工程对这方面的研究已经迈出了若干步（后文会详细说明），这里为了文章完整给出一个容易理解、定性的定义：
软件工业自动化指人工参与程度低、开发效率高的软件生产方式。
软件工程领域研究的问题很多，但主旨都是为了降低成本提升开发效率，DeMarco和Lister通过《人件》一书，向业界发表了他们的观点后，人们才清楚的认识到影响开发效率，阻碍项目进度的竟是开发者自己。
后来，项目管理学科加大了对人的管理的研究，幻想开发人员能像精确、稳定、永不疲惫的机器那样任劳任怨的为管理者所用。
人是项目的核心，而人是最不可预测的元素，其他的人和物对人的影响使得其更加不可预测。提升开发效率的关键是提高人的效率，人的不可预测使得提升开发效率也成了不可预测的，开发者本身已经成为项目开发的瓶颈问题。
我所谓的软件工业自动化的最大特点就是人工参与程度低，这里不是研究如何管理人而是更彻底的——抛弃人[4]。
另外，可以预见，软件工业自动化必定是一种庞大的系统，出于成本的考虑，对于小型软件开发可能并没有其用武之地。敏捷系列的理论会是一种好的方案。
软件工业自动化实现的探讨
前文已然提到软件工业自动化实现了人思考的自动化，也即是模拟了人的开发活动、开发过程，所以软件工业自动化实现的研究，我认为，必将是围绕开发过程展开的，重点是研究人们是如何进行开发过程的，要对开发过程的每一步骤都有精确的把握。
存在于软件工业自动化“流水线”上的软件产品，从“原料”到“成品”的变化过程中的每个阶段，都必须作为一种可归档的抽象描述形式存在，以备“流水线”进行自动化控制，所以对软件产品，各个阶段的归档描述技术是必须解决的问题。
现代软件工程注重软件过程的研究，为的是给开发过程提供一种标准，告诉开发者自己所做的事情中，哪些是对的，哪些是错的。
这里隐含着一个结论，即：只要完全的、精确的依照正确的软件过程实施，就一定能得到正确的产品。
这一结论也是软件工业自动化有望成为现实的理论依据。
“正确的软件过程”和“完全的精确的依照”是软件工业自动化需要解决的两大问题，后面会对这些做出一些简单的分析。
现今软件工程领域产生了多项技术，有些与软件工业自动化的理念非常接近，它们可能会成为软件工业自动化的基石，深化这些技术的研究可以把握自动化的未来趋势，后文会简单列举其中比较知名的几项技术，并做出一些相关评论。
3．1开发过程本质的认识
回顾软件开发的历史，噩梦般的布尔代码只在寥寥几位前辈的眼中灵动万分；汇编语言作为布尔代码的铭牌，让更多的人打消疑虑，主动的接近它；后来的C、Pascal、Basic等组成的高级语言家族，成为了软件和程序员之间的亲善大使，此时我们终于长舒口气——计算机终于有可能被大多数人认知了。
从机器语言到高级语言，人们为什么要不遗余力的逼迫计算机咿呀学语？因为，计算机与我们有天然的隔阂。
在解决问题时，我们站在问题域，它处在解答域[5]。这些语言以及与之配备的开发套件，出现的目的就是用接近题域的解域语言来描述题域。它们就像是两个领域之间的桥梁。但是，时至今日，依然遗憾的是：两个领域的距离总是比这座桥还要长很多，以至于当我们站在桥的一端时，不得不再奋力一跳，才有可能踏入另一个领域。
开发过程的本质即是从题域走向解域的过程，而软件工程自动化则是尽量减小这一过程中，需要跳跃的那段距离。
3．2开发过程的选择
如何为软件工业自动化选择或构造一个正确的软件过程，或者说什么样的软件过程是软件工业自动化所需要的，是软件工业自动化实现过程中必须解决的问题之一。
由于历史的局限，我们很难正确的判断出，现在的软件过程中，哪个能够适应未来的软件工业自动化，也许那个真正适合的软件过程，直至今日还尚未出现，又或者这样的软件过程并不唯一。
但技术的发展总是渐变，总结发展的规律可以为我们找到寻觅的方向。
前文已经提出，开发过程的本质是从题域走向解域的过程，而能够切实拉近题域与解域距离的思想，以及体现这种思想的软件过程可能就是一个较好的选择。从目今来看，日臻成熟的面向对象思想和统一过程[6]可能孕育着这方面的突破。
对于软件工业自动化，现今所使用的软件过程必须朝精确化方向改造，这是一个先决条件，必须等到软件过程变得足够精确时，软件工业自动化才能有质的发展。因为，软件过程的精确化说明了人们自身对软件过程的深入理解和控制，是人们对软件开发活动精确认知的标志，只有人们先足够深刻的认知了开发过程，认知了开发手动化的本质规律，才有可能使得开发过程自动化。
所以，要想“完全的精确的依照”就必须创造出极端精确的软件过程标准，以现在看来要做到这一点还要走一段路。
3．3软件工业自动化相关的局部技术
RAD技术
RAD（Rapid Application Development）——“快速应用程序开发”是指一种辅助性的编程系统，它可以帮助程序员快速的编制程序。
RAD技术主要体现在一些应用程序开发工具上，比较著名的有微软的VisualBasic系列和宝兰的Delphi系列，这些工具依托组件重用思想，简化常见的编程活动，在用户界面、数据库应用等方面有一定作用，这些主要体现在代码的自动、智能生成上。
时至今日，RAD工具已经颇为成熟，但相对于整个软件工业自动化战略，它还尚为稚嫩，这些工具一般只能胜任小型项目，而对大型项目则力不从心，境地十分尴尬。
我认为造成这种情况的原因是由于RAD工具将自己定位过高，RAD工具不应成为一个全能选手，应在其优势项目——代码生成上再下苦功，如此一来，则有望为软件工业自动化的实现解决一个棘手的问题。
UML技术
UML（Unified Modeling Language）——“统一建模语言”是三位面向对象方法学巨擘James Rumbaugh、Ivar Jacobson和Grady Booch成功合作的结晶，是原先三种主流软件工程方法取长补短、互相融合的标志，再加之OMG的采纳，UML已成为响当当的工业标准。
在我看来，UML并不是什么新鲜的技术，它的主要功用是以图表方式描述软件系统，在它之前有很多的图形化表示法，稍夸张的说，也许每一个软件工程师都有自己一套独特的描述软件的图形符号系统，所以UML的出现只是统一了这些图形符号，让人们可以无碍的交流，也正因如此UML标准才只可能由这三位重量级的专家缔造，别人是没有如许的影响力的。
UML在一定程度上解决了软件系统的抽象描述问题，使得软件系统可以脱离它本身而被统一归档表示，软件工业自动化本身就需要解决软件系统的抽象描述问题，所以UML标准应是一项有潜力的方案。
但是，UML技术只在软件系统的框架，运行时序、流程等方面具备表达能力，却无法表达更为抽象的业务逻辑，不过，据我所知，现今业界也没有那项技术能对复杂多变的业务逻辑，进行统一化归档描述，甚至形成一个像UML那样的图形、符号系统。
UseCase技术
UseCase——用例分析技术最早由I.Jacobson在他的OOSE方法中提出，这一技术也可算是一种“描述”——是对用户需求的描述，但在我看来它过于简单，还远未达到抽象描述的高度，对其进行统一化归档还有相当大的困难，但也许用例分析技术是软件工业自动化中需求描述的一种雏形。
几种技术的小结
前面谈到的几项技术是按照现阶段人们研发程度从深到浅依次排列的，也可以体现出我所认为的软件工业自动化需要的几项局部技术：代码生成技术，软件框架流程描述，业务逻辑描述和需求描述技术。
在代码生成技术的研究上，人们已经有了相当的水准，软件框架流程描述上也算初具规模，但对业务逻辑描述和需求描述两方面的认知还比较浅薄，也许这就是今后软件工程领域研究的方向。
另外，我还想简单谈一下设计模式。
研究设计模式的主旨在于建立一个灵活的软件框架，它可能无助于软件工业自动化的实现，但很可能成为判别同类软件工业自动化技术优劣的条件，不过要将它引入软件工业自动化恐怕还要等更长的时间。
结语：
回顾前文，我觉得软件工业自动化需要一个软件过程，一套表示法和一套转换技术。
一个软件过程用来战略的指导和控制整个软件开发过程，一套表示法用来精确的描述软件过程中的各种“半成品”和“成品”，转换技术则将这些描述对应转换成真正的软件产品。
以现在的眼光看，软件过程和转换技术都是相对容易解决的问题，只是表示法方面很是棘手，需要对业务逻辑和用户需求做出更进一步的研究和分析，找出其中的共性，创造出一套完备的图形符号系统（或者其它的形式）对这些做出抽象的描述，要做到这一点可能很不容易，因为业务逻辑和用户需求已经很抽象了，再进行一层抽象就难于做到了。
软件工业自动化也许会是这样一幅图景：软件工程师针对用户做具体的需求调研，将调研结果制作成符合标准的需求规范，由自动化工具产生框架和核心代码，软件工程师根据实际情况做出调整，并最终制作出符合规范的软件来，再交由专业人员或客户进行测试。
关于软件工业自动化的“砖头”，我就零零碎碎的抛这几块，确没指望能引来碧玉、美玉，但我想人总是懒惰的，程序员更是“懒惰”非常，能自动开发出软件的黄粱美梦，不少程序员应都是做过的，只要人们还有梦想，总是会实现的。
参考和注释：
【1】《程序员2003合订本（上）》 《程序员》杂志社编 电子工业出版社
这份调查是《关心程序员》系列调查的一篇，主要是依托国内著名的csdn.net网站进行的，权威性不言而喻，其它几篇（爱情篇、学习篇）也是很令人玩味的。
【2】《积极发展劳动密集型产业》
http://www.cass.net.cn/webnew/file/2004061114728.html
该网站为中国社会科学院的官方网站，原文出自《中国社会科学院院报》，IT产业属于劳动密集型产业是公认的，但实在感觉与“身份”不合，所以更需要我们研究软件工业自动化技术。
【3】这里的“普通”是相对于软件工业自动化而言的，普通工业自动化是那些在计算机软件帮助下实现的自动化，是所谓的用软件造机器，软件工业自动化可以类似的理解为用软件造软件。
【4】这里并不是完全的抛弃人，这是在一些环节抛弃人，为了尽量减少不确定因素。
【5】我关于题域和解域概念的形成最早得惠于Bruce Ercel 的《C＋＋编程思想》一书，该书在前几个章节，讲解有关面向对象概念时，曾提到过题域和解域。
邵维忠、杨芙清著的《面向对象的系统设计》一书也谈到过题域与解域的划分，他们称作“问题空间”和“解空间”，这里有稍多些的讨论。
【6】UP（Unified Process）统一过程，这里主要指Rational UP 即RUP，业内批评RUP过于繁杂，在我看来作为一个精确的软件过程，繁杂是不可避免的，简单又能完全描述问题的方法是不存在的——除非问题本身就足够简单。
本文地址：http://com.8s8s.com/it/it33218.htm