GeneXus Overview Latest Update: 2009 Overview of GeneXus Copyright Artech Consultores S. R. L. 1988-2009. All rights reserved. Reproduction by any means is prohibited without the express authorization of Artech Consultores S.R.L. The information contained in this document is for personal use only. Trade Marks Artech and GeneXus are brands or trade marks of Artech Consultores S.R.L. All other brands mentioned in this document are the property of their respective owners. Page 1 Overview of GeneXus Introduction .............................................................................................................. 3 The Theoretical Question ............................................................................................. 4 Traditional Development Methodologies and Associated Problems .................................. 4 Knowledge-based Development and Incremental Methodology ...................................... 5 GeneXus: Incremental Development Made True ............................................................. 7 Design ................................................................................................................... 9 Knowledge-based Development ............................................................................ 12 Multiple Platforms / Multi Tier Architecture ............................................................. 12 Prototyping ........................................................................................................... 12 Implementation ..................................................................................................... 14 Maintenance ......................................................................................................... 15 Impact of Changes on the Database ...................................................................... 16 Impact of Changes on Programs ........................................................................... 16 Documentation ...................................................................................................... 16 Consolidation of Several Applications and Re-utilization of Knowledge .......................... 17 Unique Features of GENE XUS ....................................................................................... 18 Who Are the Users of GENE XUS? .................................................................................. 19 Page 2 Overview of GeneXus Introduction GeneXus is an intelligent tool developed by Artech aimed at assisting analysts and users throughout the lifecycle of applications. The design and prototype are done and tested on a Windows NT/2000/XP environment. Once the prototype is fully approved by users, the database and the application programs for the production environment are generated and/or maintained in a fully automatic way. The core idea underlying GeneXus is the automation of everything that may be automated: data and design normalization, the generation and maintenance of the database and the application programs. This prevents analysts from spending time in routine and tedious tasks, leaving them free to fully concentrate on the one thing programs will never be able to do: understand the issues faced by the user . As a byproduct, GeneXus offers rigorous, self-sufficient and constantly updated documentation. The aim of this document is to provide readers with information on GeneXus and the problems that it solves. Contents of the sections below: • The theoretical question: this chapter presents a description comparing traditional system development methods and incremental development. • An incremental development implementation: GeneXus. • Unique features of GeneXus. • Who the users of GeneXus? Page 3 Overview of GeneXus The Theoretical Question Traditional Development Methodologies and Associated Problems The traditional method for developing applications is based on a core principle: it is possible to build a stable data model of the business . Based on this principle, the first task performed is the analysis of data, where reality is studied in an abstract way to obtain a product data model of the business. The second task is the design of the database. It is very simple to design a database starting from a known data model. Once reality has been studied from the point of view of data, the same is done from the point of view of functions (functional analysis). It would be desirable that the study of reality resulted in a functional specification that depended solely on this reality. However, in the most used methodologies, a functional specification referred to the database files (or to the data model entities, which is essentially equivalent) is obtained. Once the database and the functional specification have been obtained, the next step is the implementation of functions, for which there are traditionally several options (3 rd or 4 th generation languages, generators, and interpreters). However, all these forms of implementation have a common problem: they are based on the principle stated above: it is possible to build a stable data model of the business , and this principle is false . It is actually impossible to build, in an abstract way, a fully detailed and objective data model of the business, because nobody knows the business as a whole. For this reason it is necessary to resort to multiple interlocutors, with each one of them projecting their own subjectivity on the model. A consequence of this is that during the lifecycle of the application, the model undergoes changes. But even in an ideal situation, where all needs are fully accounted for, and where it would be therefore be possible to define an optimum database, the model would have to change to encompass the evolution of the business. Page 4 Overview of GeneXus All this would be of little importance if the functional specification and the database were independent. However, since the functional specification refers to the database, the inevitable modifications in the latter determine the need for (manual) modifications in the former. The most important consequence of this is that maintenance costs are extremely high: most companies working with the conventional methods agree that 80% of the resources theoretically allocated to development are actually used to maintain already implemented applications. In the case of large applications the situation is even worse: maintenance starts much before implementation, which creates a hyperlineal increase of development costs against the size of the project. Due to the difficulties in determining and propagating the consequences of changes made to the database to the processes in this context, instead of making the necessary changes, the option is frequently to introduce redundant files, with the consequent degrading of system quality and the increase of maintenance costs. Knowledge-based Development and Incremental Methodology In the last few years there has been a lot of talk about Knowledge Management in the industry and many things have been included under this label, which are very different from Knowledge-based Development as we describe it here. The industry has usually used the term to refer to ways of organizing and/or accessing knowledge to be used in a traditional way by human beings. This is an updated version, using currently available technology, of books (and one that is enormously useful for humanity): by reading a book we access certain knowledge and, in our minds, we reason on this knowledge, which ultimately results in actions. Intelligent text searchers, which have become available in the last few years, make this knowledge increasingly accessible to more human beings. As a general rule, this knowledge is not “understandable” for a machine and is, therefore, not operable. Additionally, as human beings are able to reasonably (up to a certain extent) deal with ambiguity and even with inconsistency, this knowledge is not always rigorous. Page 5 Overview of GeneXus It is then important to define the concept of knowledge that we will use in our Knowledge- based Development. This knowledge meets the following conditions: • It is rigorous • It may be represented objectively • It is operable Finding a new way to solve the problem of system development requires replacing the basic principle stated above: assuming that it is not possible to build a stable data model of the business and, using instead an incremental philosophy and creating a Knowledge-based Development . An incremental approach seems natural: not dealing with large issues, but rather solving small problems as they appear. What is the impact of this type of scheme on maintenance costs? If the previously described methodologies were to be used with this approach, the impact on cost would be very high: the data model would be constantly modified and maintenance costs would be even higher than the ones described above. The following is clear though: the database is not known, but each user, knows very well the data views they use everyday. These data views may be of various types: screens, dialogs, process flows, lists, etc., which form the external appearance of the application: what is tangible for the user. How can the knowledge of these views help in creating a data model? Can the issue be turned into a logical/mathematical problem? If this were possible, logic and mathematics would provide a wide range of resources to help solve it automatically and, as a consequence, the analyst’s job would be highly simplified. It is interesting to point out