加载....

GeneXus目标的演进-朝向第四维

2019-02-21T21:32:24+00:00

从GeneXus 诞生到今天的十五年后,我们对GeneXus 的目标能说些什么,目标是如何演进 改变的,这些目标实现到何种程度?

GeneXus 的目标一直在向更满足不断出现的新需求方向演进,目标的改变是基于我们的研究 成果,总体技术的发展和我们对现实的更好的理解而发生的。

事实表明,我们不断的实现了更高层次的目标。

四个维度 

通过以下的四个维度,我们可以明确我们的目标,并评价我们的实现程度:

1. 完整性(数据库和应用程序100%的完全由GeneXus  自动生成)

2 . 生产率(通过使用GeneXus,与一个使用一般开发语言,如  过去的COBOL 和RPG 或者现在的Java 和C#,    的好的程序员相比,生产率可获得显著的提高)

3 . 通用性(对于涉及到的任何平台,应用可以100%的完全由GeneXus 开发完成)

4 . 易用性(这定性的表明GeneXus 的易用程度,用户不需要特殊的培训就可以使用GeneXus )

 

让我们回顾从1989 年底GeneXus 第一版推出到今天GeneXus 目标的演变和目标的实现过程。 完全用文字来表现四维总是很困难的,以下是一种合理的表述方式(尽管不是严格的)。下图中,我们用一个箭头表示每一维,对每维我们都通过GeneXus 作出了贡献。

GeneXus 第一个版本发布时的目标

当GeneXus 第一个版本发布时,我们已经在完整性、生产率,和易用性方面达到很高的程度。

完整性:

第一版的目标是70%的应用程序由GeneXus 生成,而在由GeneXus 生成的每个程序中,100% 的代码完全由GeneXus 生成,这样可以避免手工修改生成的程序。

这个特点总是非常的重要,由于系统具有生成数据库和程序的全部知识,它也有自动维护所有生成的内容(数据库结构和数据,程序)的知识。

很明显,理想的状况是100%的应用程序全部自动生成,如果我们能这样做,GeneXus 将能 自动维护整个系统,带来成本的极大的降低(金钱和时间成本),但当时的技术实现不了这种理想的情况。

生产率 

由于开发者不再需要花大量时间从事传统的开发任务:如数据分析、数据库设计,程序设计和编码等,生成率获得显著的提升。

使用用户友好并及时的原型开发方式,系统的测试工作也显著的改善。

最初的目标是在当时所用的语言(RPG 和COBOL )下,与传统的编程开发方式相比较,生

产率提高500% 。

易用性 

与手工编程方式相比,易用性有很大的提高(第一版是用于 IBM  OS/400                操作系统,使用 AS/400 的数据库管理系统,命令语言和程序语言是RPG 或COBOL ).  为什么易用性增加呢?   由于开发者不需要语言和数据库方面的细节知识,使开发者从那些 底层技术中解放出来,能集中精力来理解和解决用户的问题而不是受限于所采用的技术。

很难定量的表达易用性的增加,重要的是,GeneXus 能使熟悉过去开发技术的老的开发者和 新的没有开发知识和经验的开发者都能马上使用GeneXus 这一新技术开发。

我们的目标实现了,但用户如何反映?他们为什么要采用 GeneXus ?什么特点是最有价值的?

用户使用GeneXus 的最主要原因是:

。 对于新的IBM AS/400,GeneXus 使不了解AS/400 和其内部技术的技术人员马上开始可 视化的程序开发工作。

。 GeneXus 使开发人员的生产率水平获得极大的提升

。 特别的是,当时客户并没有意思到自动的维护所有所生成的程序是GeneXus  的一个最主要的优势,因为当时人们并没有认识到自动维护是完全可能的。

在使用GeneXus 后的一个短时期内,客户更确定了他们初始时的判断,不具有AS/400 知识 的技术人员可以极高生成率来开发AS/400 的应用。

然而,更重要的改变是,用户开始意识到,自动维护所生成的应用程序是 GeneXus  的一个关键优势。

在当时,尽管GeneXus 只能生成所有需要的程序的70%,但用户仍然要采用GeneXus,这是因为GeneXus 的优点已经明显显露:

。 与手工编程相比,生产率获得显著的提升

。 自动维护相比与手工维护的巨大优势

。 自动维护只能在自动生成的程序上实现

这时,用户期望避免余下的 30%的手工编程工作,他们更期望避免永远不再做对手工编的 程序的手工维护工作。

上述情况产生了两个非常重要的结果:

。 每个人都非常清楚的了解到,不要去手工修改自动生成的程序以免妨碍程序的自动维护性。

。 客户强烈要求ArTech 公司用GeneXus 实现100%程序自动生成。

从多种原因出发,100%的自动生成所有应用程序都是个很好的目标。一些原因是很明显的:

。 100%的自动维护应用,可极大的提高生产率

。 其他几年后明显表现出来的原因

。 应用系统在不同平台的兼容性

。 知识库的市场  等等/

但是,自动的生成和维护全部应用是一个非常难于实现的目标(在当时,直到现在,还没有 任何一个其他的工具实现了这个目标),我们能够实现吗?

为100%的生成所有应用程序,首先需要完全并精确的表达全部需求,在当时,GeneXus 不 具备满足这个需要的足够的表达能力。

GeneXus 如何快速的增加表达能力?GeneXus 是100%的声明型的,如果加入一种第四代的 编程语言,它可以获得表达能力,但在当时,这将会失掉自动维护所有生成的程序的能力。 这是因为对于当时所知的各种过程型语言,当数据库改变时,原程序不再有效。

我们需要一种具有原程序的过程型语言,当数据库经历改变时,原程序依然有效。现成的解 决办法没有找到,但这个事项被列如我们研究的最优先目标。

1992 的目标:100%的完整性 

经过考虑并研究了多种可选的方案,我们找到了解决问题的方法。

应用数据库管理系统的解决方法。  最合理的可选方法(独立于 GeneXus )是由ANSI Sparc  完成的 3 模型设计建议(外部模型、逻辑模型、和内部模型),所有的应用与外部模

型交互,改变数据库并不引起外部模型的改变。

当时的趋势使这种可能看起来很不现实。在数据库管理系统的市场上,多个公司用不同的产 品竞争,采用SQL 作为新版本的标准而不是采用最新的创新技术是当时竞争的手段。

这个标准隐含了几乎全部的功能性的停滞,竞争的结果是只要很少的几个数据库厂商生存下 来。

结论是:那种方法并不能解决问题。

稳定的数据库 。 许多理论家建议“稳定的,预先很好的设计的数据库“。(很明显,如 果数据库是稳定的,我们想要解决的问题就不会存在,由于没有对数据库结构的改变,也就 没有对程序的影响)

然而,那些概念与实际并不相符,只有在那些失掉所有创新能力的快要消亡的企业或机构中 才会有稳定的数据结构。

结论是:那些方法与实际情况没有联系。

独立于数据库结构的带有程序的过程型语言。  第三种可能是设计并开发一种过程型 语言,程序的有效性将不受数据库改变的影响。

 

我们决定采用这个方案,一个如果是处于孤立状态,看起来非常困难并且四几乎不可能的方 案,但在象 GeneXus  知识库这样的环境下又是完全现实的方案。为什么我们要手工的加入一些对象(表,文件名等)在程序中,而这些对象完全的可以被自动引用(在生成程序时)。

GeneXus  的过程语言仅作用于外部模型(其元素不受数据库改变的影响),并且不使用类似表,文件等底层的物理元素,并且,其原程序不被数据库结构的改变而影响。

这个高层次的过程语言的加入使我们能解决GeneXus 的100%的生成应用的问题。

这时,GeneXus 能自动的生成并维护数据库(结构和数据)并100%的生成和维护应用程序。

这样,100%的完整性目标已经实现,我们也将致力于在将来保持这个目标,这极大的增加了使用GeneXus 的优势,我们的用户理解这种优势。

当时,GeneXus 是一个仅能用于IBM AS/400 平台的工具,然而,在其他平台上的应用并没 有理论上的限制。

1995 年的目标:对C/S 架构的支持

1995 年,一个被长久期盼的事情发生了,C/S 架构的开始获得广泛的应用。

Artech 发布了支持哪个时代主要相关数据库管理系统,IBM DB2, IBM DB2 for AS/400,  Informix, Microsoft SQL Server and Oracle.这些新的能力受到欢迎,C/S 架构开始快速的成长。

同时,突然并且未料到的商业用途的Internet 发布表现出巨大的成功,整个计算机业开始快速的改变。

直到那时,系统还是可预知并是结构化的,系统的目标用户是整个世界的成千上万的用户,用户使用这些系统没有任何的自由度,并且只要在培训后才能使用。

开发者—一个在整个世界相对很小的群体,难道要为所有的用户决定自由度。

在现实的迷雾中,Internet 出现并在一开始就为全世界的更大量的人所接触,这些人没有被培训过,并且具有很大的自由度要求.。GeneXus 很快的发布了第一个Web 生成器。

1995 年的状况是怎样的呢?

GeneXus 保持了它的完整性—100%程序的自动生成和维护。

生产率  仍然非常高(较人工编程高500% )

通用性  通过支持C/S 架构和Web 被显著的提升。

易用性保持在原先的水平。

2001 年目标:通用性的显著提升

90 年代后半期,面向Web 平台的多层架构应用开始出现,用户需要将应用自动的从PC 客户端转移到Web.

两个重要平台,Java 和.net 很快的瓜分了大部分市场份额,Web 架构快速发展,主机系统衰落。

GeneXus 及时的发布了Java 和.Net 生成器,同时强力的优化了它的Web  架构的生成器。

基于这些,GeneXus 保持了很高水平的完整性,生产率、和易用性,同时显著的提升了通用性:现在,GeneXus 能对所有的平台生成业务应用。

2004 的目标:显著的提升生产率 

随着 InterNet  的发展,计算机发生了很大的变化。有更多的计算机用户,一般情况下,不

可能对这些用户进行很好的培训。

数据库也不再是安装在公司内部,而是一个扩展的,包含客户,供应商、公用或私人的Web 服务,同时,公司内部的数据库也需要被其他人访问,这些人将被以完全不同的方式双重授 权。

用做终端的设备也各种各样,手持设备,Palms, Pocket PCs  蜂窝电话等。

网络已被扩展,现在已包含更高速率的无线长距离连接(WI Fi )无线中距离的连接(Wi Max ), 高速电话连接(GPRS,EDGE ).

然而,关键之处在于:我们的应用必须服务于成千上万的潜在用户,他们具有很高的自由度,而不可能被培训。结果是,应用变的越来越复杂,需要被很好的设计并开发使复杂性被隐藏,以提供简单的容易的使用。

面对这种新现实,Artech 意识到,500%的生产率的提高在将来是不够的,  Artech 要用2000%来 代替500%,这将通过两个生产率的100%的提升来达到,每个新版本的生产率将较前一个版本 提升100%,第一个100%的提升在2005 年中发布,而第而个100%的提升版本将在2007 年中发布,

 

同时其他维度也会被严密的控制,特别是通用性,增加了对市场上新出现的平台和技术的支持, 比如PostgreSQL, MySQL and AJAX.

未来:易用性的显著增强 

现在,下一步的创新应该是什么?我们能期望将来GeneXus 给我们提供什么?

GeneXus 已经在前三个维度具有巨大的能力,完整性和通用性维度已经达到了顶峰,并我们将继续努力在将来新的创新技术出现时保持这种能力。

生产率:GeneXus  的生产率已经提高到如此的程度,它可以在未来的几年内,及时并低成 本的开发出用户要求的,复杂性不断加大的应用系统。由于不再手工编写通常的象 Java 和.Net 程序语言程序.。这成为  GeneXus 最重要的特点。

那么第四个维度(易用性)的状态是怎么样呢?

易用性目前已经做的较好,但我们还不能将其与其它几个维度相比。GeneXus  是一个供开 发者使用的,具有完整算法基础的开发工具。比如由于其过程组件仍然很重要,通过提升易 用性其使用将会更用户友好。这样,任何具有一般基础的人员都可以用其完成通常的开发任 务,而不需进行昂贵的特殊培训。

目前的状态如何呢?从一开始,GeneXus 的易用性就非常重要,基于以下情况,这种易用性在今天依然非常重要。

当我们开始开发工作时,我们不再必须知道运行平台(硬件,操作系统,数据库系统,架构 和所用的程序语言)是什么。

开发者不需要具备运行平台的细节知识,这对于熟悉过时技术的老的开发人员和没有经验的 新开发人员都有巨大的帮助。

用户将获得更大的自由度,这是由于他们可以在任何时候更换系统的运行平台,使用 GeneXus 完成应用的转换。

新技术可在大项目的开发中后期被应用,在项目的进行过程中随时决定采用新技术而不会带 来任何问题。

GeneXus  自动集成应用系统中的不同部分,确保其永久的一致,并保持信息的有效和最新。

系统的正确性通过完整及时的原形测试获得验证。

所有这些都非常重要,而且,大多这些特点都是 GeneXus  所独有的。那么,问题究竟在那里呢?实际上,不存在问题而只存在限制,这就是—GeneXus 总是需要专业的开发人员来使用。

在一定时期内认为所有的应用都需要被专业的开发人员来开发是否合理呢?

我们并不这样认为,使用专业开发人员来开发系统仅仅是技术限制带来的结果。

突破这个限制后,我们可以期望信息系统的用户将为信息系统的开发作出非常大的贡献。今 天,用户最了解业务,但他们不了解(也不能期望他们了解)建造系统必须的底层技术细节。

了解要解决的问题将会比了解解决问题需要的技术更重要,系统将变的更多样化,在不久的 将来,基于会计,采购,销售,库存,或者 ERP,  CRM  等的系统将只是用户需要的系统中的很小的部分。何处存在建造新系统所必要的知识呢?我们认为,在用户那里的这种知识要比在专业开发人员中存在的知识多很多。

因此,GeneXus 将继续改进以变得更易用,更容易的被需要解决问题(他们最了解问题)的用户使用,但他们不是专业的开发人员。

特别的是:GeneXus  需要更用户友好化,它需要降低使用它的抽象程度,隐藏它的复杂性, 特别的是需要增加其声明性组件,加入直观的容易使用的图形组件,减少使用其过程组件的 需要。

这是我们未来几年内的最大的任务。