Professional Documents
Culture Documents
Distribute in Italy by
Distribute in Italy by
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
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.
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.
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):
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).
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.
Copyright
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.