反思,然后进步-再论系统件开发模式

“系统件开发模式不应该是一个产品或者一个工具,而应该是人们的工作模式和在此工作模式下使用的多种工具”

目录

1 系统件
(1) 定义
(2) 特征
A 一个系统件可能是一组代码,一组应用程序或一组文本模板
B 一个系统件封装了一类框架(FrameWork),一类解决方案或一类设计思想
2 系统件开发模式
(1) 什么是系统件开发模式
(2) 系统件开发模式应该是一种工作模式
(3) 有许多基于这种模式发展起来的工具可供使用,在这些工具中,这种模式 的具体实现方法也有许多种

正文

1 系统件
(1) 定义
是一类已经做好的成熟的特殊的系统,说它特殊,是因为这类系统模版并不 具有任何具体的数据特性,不具有任何个性化的信息,但具有固定的系统结 构和布局。当我们使用这些系统模版来作系统实现的时候,我们只需要予它 具体的属性值,比如说具体的数据库信息,具体的显示信息等。更直观一点 ,其实一个系统模版就和一个类,一个组件,控件差不多,只是它是系统级 别的,已经上升到了系统的高度
(2) 特征
A 一个系统件可能是一组代码,一组应用程序或一组文本模板
B 一个系统件封装了一类框架(FrameWork),一类解决方案或一类设计思想
2 系统件开发模式
(1) 什么是系统件开发模式
系统件开发模式指的是围绕系统件这一核心,根据软件工程的思想而提出的 一种软件开发过程

其大致思路为:从需求分析结果开始进入系统设计,设计围绕系统件来进行 ,即选择什么样的系统件,选择什么样的数据库,该怎样来设计数据库以正 确配置系统件等。根据系统设计的结果,选择合适的基于系统件开发模式的 集成工具来完成系统的实现以得到最后的系统的过程!

和一般的软件开发过程相比,最主要的不同就在于在在设计的时候是以系统件作为主要的考虑因素,实现则是以于系统件开发模式的集成工具来完成!根据所选择的系统件开发模式类别,可能涉及代码,也可能完全不涉及代码!

(2) 系统件开发模式应该是一种工作模式
就象现在的许多软件工程师用三层结构模式或分布式体系结构模式,组件开发模式思维来建构产品一样,系统件开发模式应该发展成一种软件工程师在开发产品时,去考虑,选择的一种产品构建方法,过程!

(3) 有许多基于这种模式发展起来的工具可供使用,在这些工具中,这种模式 的具体实现方法也有许多种

正如现在的PB,VC++/VB,DELPHI/C++BUILDER/KYLIX,J2EE/EJB等工具都不约而同的荣融入了组件/控件/构件开发模式的思想,也会有许多融入了系统件开发模式思想的工具。而正如这些工具对组件/控件/构件开发模式的实现方法也不相同一样,这些融入了系统件开发模式思想的工具的系统件开发模式的具体实现方法也不一而足。但大体上来说,可以有以下两大类:代码重用,二进制/文本模板重用(系统级重用)。
现在大家的思维大多都是集中在代码重用这一层面,这就我个人观点而言,可能和以下原因有关系:
1) 现在迅猛发展的面向对象方法
由于现在面向对象方法的迅猛发展,使得重用性问题得到了人们充分的认识-因为面向对象的核心思想之一就是复用.也因为复用的好处是如此的明显,因此也反过来促进了面向对象方法在人们心目中的极度扩张.而面向对象方法现在用的最多的又主要是在OOP(真正用了OOA,OOD来做出合格产品的CASE还比较鲜见)上,,因此提到复用问题的时候,都不约而同的想到了代码复用!
2) 现在的软件开发还处于语言级的水平
综观软件开发的发展历程,研究一下机器语言,汇编,中级语言,高级语言,商业语言,非语言这一发展线路,我们所处的时代正是中高级语言大行其道,汇编,商业语言用的相对较少,机器语言,非语言几乎不用的时代,既中间大,两头小.机器语言,汇编几乎不用,那是因为思维,水平的发展都已经超越了这个层次.而商业语言用的较少,是因为思维虽然达到了这个层次,但水平还没普遍达到这个层次;非语言几乎不用,则是因为人们的思维很少有人达到这个层次,当然,更不用说水平了.
因此,当人们谈到软件开发的时候,一般都首先想到的是语言,代码!
这里解释一下,曾经有人提到第几六代语言的问题,我想这重提法就和我在这里所说的非语言差不多!照N-G(第N代)的划分方法,商业语言该属于第5代,而现在则正处于第3,4代语言的时期.就我所理解的非语言,应该是是一种系统级的设计语言,诸如业务流程设计,建模等! 其实和具体的语言,代码已经挂不上边了!
因为上面的原因,大家在谈到重用的时候,几乎都朝代码层次上来想了!

当然,从一般的思维模式来说,这是极其正常而自然的事情,并且作为系统件开发模式的一类实现方法,这也是可行的.
所以,在以前基于系统件开发模式的诸多讨论中,不乏极其有建设性的想法.典型的如第六代语言等.也有许多从现在的成熟产品或思想来着手思考的,如通用程序设计方法(GP),STL,泛型编程,设计模式,MFC,并深入到了基于这些思想或产品的体系结构如三层(外观,逻辑,数据),分布式等深层次的东西!
我可以肯定的说,基于以上这些深刻的技术而思考着努力着的人们,若方法得当,路线正确,肯定都能做出漂亮的基于系统件开发模式的工具,相信不久的将来,这样的工具必将如今日之基于面向对象方法的的开发工具般普遍!虽然现在有这样那样的时间,效率,质量等的诸多质疑,但那只是成功路上的一些小插曲,在充分重视到的同时,不应是不可逾越的障碍.
当然,就象痛往康庄大道的路不止一条一样,在如何使系统件开发模式成为一种能为人们提高效益的看的见摸的着的工具的一部分上,还有不同的实现方法,那就是我所说的二进制重用.
二进制重用这个称谓,更确切一点来说,应该叫系统级重用.二进制重用的说法只是为了从狭义上和代码重用相区别,但就更科学的说法来讲,叫系统件重用更贴切些.因为这类重用不但不限于二进制的重用,更重要的,它也不限于程序上的重用.
系统级重用说它不限于二进制的重用,是因为除了而进制应用程序的重用外,还可以是文本上的重用.比如,一个典型的WINDOWS应用程序可以设计成系统件然后供重用,然而,一个典型的网页模板(只是文本而已)也可以设计成系统件供重用.
系统级重用更重要的一点,应该是设计思想,解决方案,经验层次上的重用.只有在这些层次上,才能说我们的重用是在系统级的,具有了系统件开发模式的典型特征!
当然,说到这里,你肯定马上会想到代码重用也大量的存在这些思想啊,如设计模式!
这个疑惑正好体现了代码重用和系统级重用的最显著的差别:代码重用后,你必须得再依赖于编译器或解释器生成最终的应用系统,而系统级重用则不依赖于任何编译器或解释器,直接可以得到最终系统!
所以叫它系统级重用更合适一些!
说到以系统级重用来实现系统件开发模式,可能和大家所熟悉的代码重用相比起来,感觉会有些陌生.这正如我前面提到的那样,现在正处于面向对象迅猛发展的阶段,并且现在的软件开发水平处于语言期,因此当提到重用的时候,都会从代码的层面来思考.
其实,代码重用实在只是重用的很小很小的一个实例.在任何行业,任何地方,任何时候,重用都在发生着.典型的,制造业中的流水线生产工艺就是一个极好的重用的例子-产品的生产工艺被重用来生成不同规格的产品.
我不得不说的是,因为软件产业的特殊性,重用在软件的生产过程中体现得最为突出-甚至使得其他行业中的重用看起来都不象重用了!
但是,对于软件开发来说,当这么一个非常好的优势被仅仅利用在代码层面时,那就显得有些可惜了.为什么我们不能扩展到其他地方呢,不能让它更上一层楼呢?
答案是:可以!
因此便有了设计模式这样经典的重用.它不止在代码层面上重用了,还在设计思想上也重用了!
那为什么不可以扩展到系统级重用呢?
答案是:可以!
因此,基于系统级重用的系统件开发模式也是可以的!
说到这里,我又想起了非语言的-第六代语言的问题.当定义系统件开发模式的规时,如果要从代码重用中吸取精华的话,可以借鉴面向对象中的定义-当然,这属于具体实现的问题了!
说了这么多,其实就是想把系统件开发模式中的一些问题描述清楚,最后在总结一下吧,还是这句话:
“系统件开发模式不应该是一个产品或者一个工具,而应该是人们的工作模式和在此工作模式下使用的多种工具”

相关连接:
系统件开发模式专业网站:http://systemer.51.net
本文来源:http://systemer.51.net/SystemerPattern.htm
发表评论:http://systemer.51.net/cgi-bin/forums.cgi?forum=2

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值