Overview

Distribute in Italy by

TABLE OF CONTENTS
Introduction The theoretical problem Traditional Development Methodologies and Related Problems Incremental Methodology GeneXus: An implementation of incremental development Design Transactions Reports Procedures Work Panels Web Panels Themes Menu Data Views GeneXus works with pure knowledge Multiple Platforms / Multitier Architectures Prototype Implementation Maintenance Impact of database changes Impact analysis Generation of conversion programs Execution of conversion programs Impact of program changes 4 5 5 6 7 8 8 9 9 9 9 9 9 10 10 10 10 11 12 12 12 12 12 12

Impact analysis Generation of new programs Documentation Consolidation of several applications and knowledge reusability GeneXus'Unique features GeneXus Users WorldWide

12 12 13 13 14 15

Introduction
GeneXus is an intelligent tool, developed by Artech, whose goal is to assist analysts and users during the whole applications' life cycle. The design and prototype models are developed and tested on a PC either in a Windows, Windows NT/2000/XP environment. Once the prototype has been totally approved by its users, the database and application programs are generated and maintained in a fully automatic way and thus, give rise to the production environment. The basic idea of GeneXus is to automate all that can be made automatic: data normalization and design; database and application programs generation and maintenance. In this way we relieve the analyst from getting involved with tedious and boring tasks, allowing him/her to put all his/her attention on something a programming tool will never be able to do: understanding user problems. A subproduct of the design process is the fact that GeneXus builds the system's documentation selfsufficiently and it permanently updates it. The purpose of this document is to inform the reader about GeneXus features and the problems it solves. It consists of the following sections: The theoretical problem in this section a comparative description of traditional methodologies for system development vs. incremental development is presented. An implementation of incremental development: GeneXus Unique features of GeneXus GeneXus users worldwide

The theoretical problem

Traditional Development Methodologies and Related Problems
The traditional way of application development is based on the following statement: it is possible to build a stable data model of the company. Given this assumption the first task involves a thorough data analysis where an abstract investigation of the companys reality is performed and the final result is a data model of the company. A data model is quite easily reflected by a database once its information is passed on to it. The second task is design the database so as to best absorb the knowledge of the data model. Once a data model has captured the total essence of the reality, the next major step is to analyze the company in its functional aspects. It would be desirable that the study of reality in terms of its functions returns a functional specification of the reality. Most methodologies, however, obtain a functional specification in terms of database files (or more precisely of data model entities that is equivalent on a primary basis). The next and final step after having obtained the database and the functional specification, is to implement the rd th functions where there are traditionally several options to use for this last task (3 or 4 generation languages, generators, interpreters). However, the implementation options mentioned above have a common problem: they are based on a false premise: it is possible to build a stable data model of the company. Actually, it is impossible to draw up a detailed data model of the company in an abstract way, nor is it viewed with the required level of objectivity and detail because nobody on their own right has complete knowledge of the company. So, several workers ranging from employees to employers (let us consider them as users in general) will need to be interviewed and queried on their work in order to achieve a complete view of the companys operations. During the whole application life cycle it is clear that model changes are incorporated as a consequence of user necessities. Even if we consider an ideal situation where the analyst incharge knows exactly what needs to be done and an optimum database is created, the model cannot remain static since it must accompany the evolution of the enterprise. All this would have no importance if functional specifications and database requirements are totally independent. However, functional specifications are based entirely on the databases structure. So, it is inevitable that a change to the latter implies the corresponding (handmade/manual) changes to functional specifications. This frequently spells out very high maintenance costs. It is generally accepted that 80% of the resources theoretically destined to development are actually consumed by the maintenance of implemented applications. Now if big applications are concerned then the situation is even worse: its maintenance begins a lot before the actual implementation of new components, meaning development costs grow exponentially when compared against the actual size of the project. Since it is very difficult to determine and propagate all changes made to the database in such a way that all processes affected by these changes respond accordingly, it is common practice to add redundant files. This solution can only bring along as a consequence, a great fall in system quality and a notorious maintenance cost rise.

Incremental Methodology
An alternative solution to the problem consists of replacing the basic premise seen above with: there is no such thing as a stable data model of the company and really provide a successful solution by taking this one step further by suggesting an incremental philosophy as well. An incremental philosophy seems like a very natural solution as big problems will no longer exist since they are broken down into smaller ones and are resolved as such. What impact does this philosophy have on maintenance costs? If the methodologies reviewed above are used then the impact of changes must be considerable because this approach implies constant changes to the data model and a much greater increase in maintenance costs than initially suggested. However, the following can be noticed: The entire database structure is not known, but every user is completely aware of the data views he/she handles on a daily basis. In other words each user one has his/her own view of reality. Data views take on many formats: screens, listings, etc. perceived as external aspects of the application. In other words, everything that is tangibly perceptible to the user. How can the information from these views help construct a data model? How can we view the above issue as a mathematical problem? If this can be achieved, then a rigorous self standing specification of the problem taking the form of a mathematical representation gives rise to a wide range of resources to help solve it automatically, and thus, simplify the analyst's task. An interesting thought is: a complete knowledge of the database makes possible the designation of required views to all users. In other words, the database must satisfy all user views. It can be demonstrated that given a set of data user views always gives rise to a minimum normalized database, which also happens to be unique. So, once it is clear that the problem does have mathematical characteristics, we need to solve it to determine the database. To do it, Artech has developed, by means of exclusive investigations, an automatic procedure. But how can one implement this theory? By capturing the knowledge that resides in user views and transferring it to a knowledge base. Based on that knowledge it designs and automatically generates the data model, the database and the application programs. The main difference between a knowledge base and traditional data dictionaries is the fact that it has the capacity to infer: the incorporation of certain elements acts as an inference trigger to determine other values. If a knowledge base is achieved then the database and application programs are deterministic, meaning they are: Automatically generated. And since changes in user views is a natural event: The impact of those changes over data and processes is totally measurable and thus determined. Deploying those changes involves the generation of: The necessary Data Conversion Programs. The new versions of the Application Programs affected by those changes.

GeneXus: An implementation of incremental development

GeneXus makes the implementation of this theory possible. GeneXus is a tool that starts from users visions; it captures their knowledge and systematizes them within a knowledge base. From its knowledge base its capable of designing, generating and maintaining 100% automatically the database schema and the application programs (the necessary programs in order that the users operate with their visions). GeneXus is built over a very strong mathematical foundation. Which is the main strength behind GeneXus? A very good automatic administration of the business systems knowledge. GeneXus works with the pure knowledge, which allows performing several things: generating programs (traditional software), understanding that knowledge by human beings (it doesnt need additional documentation which would never be updated), and operating automatically with that knowledge (integrating it with another from other sources, spreading it, licensing it to others so they integrate it in their applications). Therefore, it allows the "knowledge business as a step higher than the software business. Another consequence of working with the pure knowledge is the possibility of generating applications for multiple platforms and multiple architectures and, very specially, certain type of insurance at the technology changes: for example, those GeneXus users who developed applications 8 or 10 years before for iSeries with text screens and rather primitive technologies, now may take advantage of the knowledge about those applications development that GeneXus saved to develop .NET applications easily, although when they were developed nobody could think in something so different from the environment with which they were working. The first step to take into account when developing an application with GeneXus, is to Design the application from the users prospective (from which the system captures and systemize the knowledge). The second step is Prototype the application. GeneXus generates the database and programs for prototype environments. Once generated, the Prototype is executed and tested by analysts and end users. The purpose of a prototype is to provide a way to interact with the user with a live application, so improvements can be suggested and errors detected. The designer, based on this feedback will return to the design phase, perform the corresponding modifications and offer another operational Prototype. This cycle is commonly referred to as the Design/Prototype cycle. Once the Prototype is entirely approved, the following stage is the actual Implementation. This is when GeneXus actually generates the database and programs for the production environment. Summing up, an application is first Designed then Prototyped and finally Implemented. The designer has complete freedom to finetune any of the stages based on constant feedback from the users.

Figure 1: Cycles: DesignPrototype and DesignProduction Each of the above stages are explained in detail:

Design
This phase is performed by both the analyst and the user and it consists of identifying and describing user objects and associating data views. The actual work can be done either on or off the user's site, where a low level of abstraction can be achieved using terms and concepts that are well known by endusers. This type of joint participation has a very important and positive effect on the user; he/she (there can be more than one user involved) becomes an enthusiastic participant in the development. The system results from a joint effort where the user permanently follows its evolution guaranteeing more quality than what is commonly achieved. GeneXus is able to capture knowledge based on the views the user has of the objects from his/her reality. This knowledge is captured via GeneXus objects: Transactions, Reports, Procedures, Work Panels, Themes, Web Panels, Menus, Data Views, and Data Warehousing Transactions. So, the first phase denominated design consists of identifying and describing the mentioned objects. Given these descriptions GeneXus automatically systematizes the captured knowledge and builds, incrementally, the Knowledge Base. This Knowledge Base is a unique repository of all design information from which GeneXus creates the physical data model (tables, attributes, indexes, redundancies, referential integrity rules, etc.) and application programs. Application analysis and design are based on the description of GeneXus objects. Now, we will describe the more important types of GeneXus objects in detail:

Transactions
A transaction is an interactive process used by users to create, modify or delete database data. They are commonly known by users as 'screens' (Win or Web).

Examples: Screen to create, modify or delete Customer entries in a Corporate database. Invoice screen: process where users can create invoices and print them.

A single screen can offer a high level of flexibility to users since they can perform different actions such as insert, update, delete or print information without having to go back to the main menu.

Reports
A report is used to query the database. The output returned by a report can be sent to the screen, printer (conventional listing) or file. This object can return reports that range from very simple (list customer data) to complex listings (several control breaks and multiple database accesses with parameterization). However, a Report cannot update a database (it has not been assigned the properties to do so). We also provide a tool GXquery to make dynamics queries on the database.

Procedures
This object offers all report features plus the ability to update the database. Procedures are commonly used by three types of processes: BatchProcesses: For example, delete all invoices with date prior to a given one and that have already been paid. GeneralPurposeSubroutines: For example, a routine that returns an amount in words, that is, given an amount of money, it returns a text value that represents that quantity using letters instead of numbers (e.g.: 1010 => 'One thousand and ten'). ApplicationServerProcesses: processes (generally written with C/SQL or Java) for a MultiTier Architecture.

Work Panels
A Work Panel is a screen allowing users to perform interactive database queries. The more use users give their computers while working, the more necessary sophisticated dialogs become since they provide users with the elements they need to take decisions. Work panels are used to define complete user dialogs. For example: a Work Panel that displays a customer list and that allows, if desired by the user, the display of a particular clients registered invoices or debts.

Web Panels
Are similar to the set of Work Panels but they require an application browser to run on Internet/Intranet/Extranet environments.

Themes
Themes are created and updated through the Themes Editor. The Themes Editor is the graphic designer that defines all the visual elements of the application, such as fonts, tables, buttons, and so on. Then, this theme is associated to the GeneXus object forms. Since these CSSbased theme values can be changed in runtime, they make Web applications more dynamic and customizable.

Menu
A menu displays a list of fixed items that a user may choose to execute.

Data Views
Are used to establish a map between components or external files and GeneXus tables and treats them as if they were GeneXus objects.

GeneXus works with pure knowledge

The physical data model is designed according to the Theory of Relational Databases applying third normal form (with no redundancy) database normalization criterion, only after all transaction objects have been defined. This normalization is automatically performed and maintained by GeneXus. However, the analyst can define redundancies and can be sure that GeneXus will also automatically manage them. GeneXus' information repository stores design specifications in an abstract form, that is, they do not depend on the environment. This means that a single repository can be generated where functionally equivalent applications for different environments can interact with it.

Multiple Platforms / Multitier Architectures

As a consequence it is possible that, for instance, a centralized iSeries application (100% developed with GeneXus), the user can run his/her application on a Client/Server environment without having to modify the original objects. Quite recently there has been a need to generate multiplatform applications, that is, run the same application in several environments. For example, a banking system application could run on an iSeries at the banks head office and on a PC network in bank branches. However, with the progressive use of Client/Server and Internet/Intranet/Extranet environments, a new need has arisen: the same application must have some of its parts running on a certain platform and others running on other platforms where a correct intercommunication between those parts becomes a necessity. Developing applications with GeneXus gives you the opportunity to divide an application in such a way that each part may be executed on different platforms, and the most appropriate language is used to generate the programs for each one of them, thus giving rise to multitier architectures which in turn improves the use of available resources.

Prototype
In design tasks all the difficulties of human communication are implicit: The user forgets certain details. The analyst doesn't notice some elements. The user conveys wrong approaches. The analyst misinterprets some of the user's explanations.

Also, on the other hand, system implementation is commonly a task that takes a lot of time, meaning: Many of these problems are only detected at the end of system testing and the cost (time and money) of solving them is very large; Reality changes, so it is not reasonable to think that specifications can be frozen while the system is being implemented; The consequence of freezing specifications is that the design team ends up implementing a relatively unsatisfactory solution.

The impact of these problems would decrease a lot if every specification could be tested immediately. Different systems have taken a step forward to achieve this by offering the possibility of viewing user screen formats, reports, etc., animated by menus. This helps the user to have a better idea of what the system will consist of but afterwards surprises are always unavoidable. A very different situation is where a user can test an application that is functionally equivalent to what was desired even to the finest detail and that can actually be executed. However, GeneXus has taken this initiative even further since the user can execute the application that is functionally equivalent to the final one. A GeneXus prototype is a "readytorun" application, functionally equivalent to the final production application. The difference between the prototype and the production model, is that generally the first one is intended to run on a PC, but the second model is generated to run on the user's target environment (iSeries, LANs, Client/Server, etc.). Therefore, a GeneXus prototype given the characteristics above can be totally tested before entering the final production phase. The enduser can work with real data during the test phase, meaning he/she will be able to execute tests that represent real activities that occur on a daily and not just test screen formats, reports, and so on, but also formulas, business rules, data structures, etc. GeneXus philosophy is centered around the concept known as incremental development. It is very common for traditional working environments to consider all project changes required during the actual implementation phase and particularly those essential system changes that arise after the implementation has taken place as being really very expensive. GeneXus develops an application respecting a methodology that overcomes this problem because it realizes that all development must be done in an incremental and successive fashion, this means that the designer, after a need for change has been detected, can quickly come up with the successive prototype in a ready test state for the enduser without any additional costs.

Implementation
GeneXus automatically generates the necessary code to: Create and maintain the database schema; Generate and maintain programs to handle the objects described by users.

The generation process can be viewed as two stages: SPECIFICATION and GENERATION. Specification is totally independent of the target environment but the generation is not. This means that the same model can run off the different execution platforms it has been generated for and each one of those different generated versions can be optimized according to the environment it will run on. The environments and languages currently supported are (see the date in the firs page): Platforms Execution Platforms JAVA, Microsoft .NET, and Microsoft .NET Compact Framework Operating Systems IBM OS/400, LINUX, UNIX, Windows NT/2000/2003 Servers, Windows NT/2000/XP/CE Internet JAVA, ASP.NET, Visual Basic (ASP), C/SQL, HTML, WebServices

Database Management Systems IBM DB2 UDB, Informix, Microsoft SQL Server, MySQL, Oracle, and PostgreSQL Languages .Net, .Net Mobile, JAVA, C#, C/SQL, COBOL, RPG, Visual Basic and Visual FoxPro Web Servers Microsoft IIS, Apache, WebSphere, etc. Multiple architectures Multitier architecture, Web based, Client/Server, Centralized (iSeries)

Maintenance
This may be the single most important feature GeneXus has and that puts it ahead of all its competitors: totally automatic maintenance of both the database (structure and contents) and programs. Below, we explain how the maintenance process works once the description of any GeneXus object changes (user view):

Impact of database changes

Impact analysis GeneXus automatically analyses the impact of any changes on the database and produces a report where it explains how the conversion of data must be done, and if it corresponds what potential problems that conversion may have (inconsistencies produced by old data given new rules, etc.). You can decide if you want to go ahead or not with the database update. Generation of conversion programs Once possible problems have been solved or the decision to go along with the conversion has been accepted, then the programs that convert the old database to the new one are automatically generated, this term is called refactoring. Execution of conversion programs The following step is to move to the corresponding execution environment (prototype, iSeries production, client/server production, etc.) and execute conversion programs.

Impact of program changes

Impact analysis GeneXus analyses the impact of any change on the programs, and provides a diagnosis reporting which programs must be generated or regenerated. It also produces, for each new program, a database navigation diagram where you can choose between two optional levels of detail. Generation of new programs GeneXus automatically generates the necessary programs.

Documentation
All information provided by the analyst or inferred by GeneXus is stored in an active repository that constitutes a very complete online documentation that is kept permanently up to date. Documentation includes the description of specified objects, information on the resulting knowledge base and of the designed database. GeneXus' knowledge base not only lets you access the knowledge it stores whenever desired but it also lets you access all logically inferred information that it stores (a referential integrity rule, a database navigation map, an impact analysis of changes, cross references, ER diagrams inferred from the stored knowledge).

Consolidation of several applications and knowledge reusability

Several applications can be designed and prototyped simultaneously by different teams when GeneXus is used. These teams can exchange design specifications by means of a module called the KNOWLEDGE MANAGER. This module lets you automatically: Start the design of a new application based on Business Objects, Software Patterns, Domains, Attributes and/or Styles of a public domain. Distribute knowledge from the corporate knowledge base to any other application's knowledge base. Verify the consistency between an application's knowledge base and the corporate one. Consolidate two applications (it is particularly useful to consolidate the knowledge from a given application to the corporate one).

This offers ideal flexibility: the analyst works with entire freedom in a prototyping environment interacting with a small knowledge base, and only when his/her application is ready from the users point of view will he/she start to consider integrating the small knowledge base to the corporate one.. Powerful automatic tools are available for use when the decision comes to integrate two knowledge bases. The impacting a new application or modifying one will have on the corporate model is analyzed and if appropriate, changes are made to assure consistency. This schema lets you reuse, for example, knowledge bases licensed from third parties. In the beginning it is necessary to make use of a common nomenclature between different knowledge bases involved in the consolidation. However, the new characteristic Adapt From lets you define a mapping for names conversion so as to adapt to the target. It is also important to point out that it is now possible for the software house that licenses the GeneXus knowledge base to maintain private parts of it, in order to allow the automatic use of it but without exposing the sources. Additionally, now an object can be declared as public or private. All can be automatically used by GeneXus but in the case of private objects only the owner can view and/or modify GeneXus highlevel source.

GeneXus' Unique features

GeneXus has several characteristics of its own that distinguish it from its competitors. Here are a few of them that really make the difference: The design starts after end users have provided sufficient knowledge of the objects they interact with each day (TRANSACTIONS, REPORTS, etc.); because of their daily activities they are the ones who know how things work or should work. Each objects description is totally independent of other object descriptions. This means that if an object needs to be modified it will not require the manual modification of other objects. This exclusive GeneXus feature enables full automatic applications maintenance. The learning curve is short. The database is automatically designed, created and maintained. The application (database and programs) is of the best quality regardless of the changes it has been put through: - The database is always at its optimum. -- Programs are not modified: when they are no longer appropriate others are generated to substitute those that are considered obsolete. There is a simple and efficient use of files or external databases to GeneXus. Powerful and very high level languages are supplied to define PROCEDURES, WORK PANELS and WEB OBJECTS. None of these objects require any specific reference of files since they are automatically inferred when object processes are generated. This fact achieves total data independence when the object is defined. As a consequence, GeneXus' high level object specifications will not need to experience changes when modifications are made to database structures. 100% automatic maintenance: This means that GeneXus generates and maintains automatically 100% of its programs. All sectors of the economy can benefit from this (commercial, administrative, financial or industrial, etc.). GeneXus runs on PCs, freeing the production computer from design load. Easy distribution of corporate knowledge facilitates the easy development of new applications. Simple and powerful Reporting and Data Warehousing solutions. Automatic verification of consistency and consolidation between applications developed as separate modules. Platform and architecture independence. Design made simple: GeneXus uses the most advanced resources of artificial intelligence allowing system analysts and users to use it with great ease.

GeneXus Users World-Wide

More than 4.500 customers worldwide use GeneXus products to create and integrate mission critical applications that adapt easily to relentless business change. The GeneXus technology enables our customers to use their unique knowhow on the leading technology platforms. Our corporate customers range from middle to very large corporations in a wide variety of industries and today account for 70% of the company revenues. Our ISV (Independent Software Vendors) customers are small, medium, and large software companies that build their products and solutions using GeneXus. This segment accounts for 30% of the company revenues but is growing rapidly.

Copyright

ARTech Consultores S. R. L. 19882005.

All rights reserved. This document may not be reproduced in any form without the express permission of ARTech Consultores S.R.L. The information contained herein is intended for personal use only. TRADEMARKS ARTech GeneXus are trademarks or registered trademarks of ARTech Consultores S.R.L. All other trademarks mentioned herein are property of their respective owners.