By: Armando de la Torre Mothelet
Abstract: This article explains how Delphi would benefit from an application dictionary
As programmers we are faced with the challenge of writing and maintaining applications. A number of elements , which here on will be called assets , are required to develop such business application. The list assets includes ( but is not restricted to ) :
An application dictionary is a tool where all these assets are stored and managed. Even more , the dictionary provides a number of services which make developing and changing applications easier. The key services an application dictionary provide are:
Additionally , a data dictionary can provide (given the proper framework) application metadata which can significantly reduce the amount of code needed to build an application and can be the base to create other tools :
The dictionary will normally be a relational database which will store all the development assets mentioned in the previous section. To gain access to these assets the developer must log-in into the dictionary. Every time a developer wishes to make changes to an asset , the dictionary checks it is free or if it is currently being locked by another user. The locked asset can not be edited until it is released and a new version is generated. Once a lock is acquired , the asset is included into a project. A project can only be released ( e.g. into production ) when all of its assets have been individually released.
The key point from the above paragraph are :
A development project has an estimated duration, involves a number of developers and the modification or creation of certain modules during its lifetime. A project can be classified in the following types :
It is particularly important to note the dictionary’s behavior with a localization project. Due to its “local” nature , changes made with such a project do not become the “default” active version unless a new “local” project for the same sector or country is started.
Modules are logical partitions of applications. An accounting system might be divided by modules into accounts receivable , accounts payable, general ledger and fixed assets. Including module information in all the dictionary assets provides the following advantages:
Users are the people who need to access the assets from the dictionary. There are 5 kind of users :
Of course , it is possible that these roles are combined ( e.g there might be a Developer / Tester or a Designer /Developer / Manager) . Having the capacity to restrict a users permit is important , as we probably will not want to have a professional translator messing with the code or diagrams.
Figure 1 Shows the Class diagram for projects, modules and users
Table 1 – Project table
Pneumonic for the project
Date and time in which the project was created
User who created the project
Date and time of the project’s last change
User who last changed the project
Estimated start date
Estimated end date
Date of project Release
User who released the project
IsoCode of county ( localization )
Key of economy sector ( localization )
Although ECO applications are model based , storing the model in a dictionary would bring additional benefits :
One of the most important aspects of a class within an application is its persistence capability. In business applications a persistent class will usually be stored into a database table, hence additional information is required to perform storage and retrieval operations. Because persistence is achieved by the use of a database, it is very important to be able to determine the relation between the application tables. Often a developer is faced with the questions: which tables/classes are needed to retrieve this information? What is the relation between these tables/classes ?
There are several kinds of persistent classes according to their use :
Figure 2 shows the class diagram for Classes, Tables and Asociations.
Messages constitute the simplest form in which an application communicates with the end-user. Messages may be of the following types:
Although simple messages may require no further explanation , in some cases the user may require further information in order to take an adequate decision or to know how to proceed. A message’s help can include :
It is therefore crucial that a message makes part of the dictionary . Among other things , the message should have :
I hope I have made clear just how important it is to have messages controlled and documented. I will also emphasize the fact that documentation can not be just a plain-text description . A comprehensive help system must support hypertext with links to other sections of the documentation as well as links to other parts of the application and even allow the execution of external applications.
Documenting a system can be ( when thoroughly performed ) a daunting task because of the huge amount an variety of documents that can be generated. What follows is a list of the most common kinds of help within a business application.
Within a business application there are several kinds of forms :
From the point of view of the dictionary it is important that the following attributes are stored with the form :
The above information allows to quickly find any form ( think of how difficult it can be a find a form in Delphi when the project has 200 or 400 forms and you are not-very-sure what the form’s name was).Also , with some parsing , it opens the possibility of getting table-form and object-form use lists. Use lists are particularly important when making changes to applications , as they give us some insight in the scope of the changes . A use list would answer a question like : which forms are affected if I remove table XXX ?
In the first part of this article we’ve seen what is an application dictionary and what programming assets are stored within it. Also an overview has been given about the advantages of using a Dictionary to manage some of these assets (projects, modules, Classes, tables, associations, messages, documentation, forms).
In the second part I will continue exploring the advantages of an application dictionary for the rest of the assets. I’d truly appreciate any feedback from the community, particularly from the R&D team.
Some topics I would like to hear about follow:
Does a dictionary seem like a useful tool?
Is it feasible?
Does it overlap with existing functionality?
Would it corrupt the traditional way of building applications with Delphi?
Try Delphi XE4 free for 30 days
New Instant Trial!
Webinars on demand!
More social media choices:
Delphi on Google+
@RADTools on Twitter
Server Response from: ETNASC01