Last published: March 30, 2009 by 'reiniero'
Gipa started as "Generator of Integrity Preserving Associations".
Keywords: referential integrity, conceptual modeling, uml class diagram, code generation.
Claim: Use of Gipa boosts productivity of domain modeling by a factor between 4 and 5.
For years normalization has been advocated in the relational world as a modeling tool. Normalization certainly is an important set of rules to ensure referential integrity. As a tool to represent real world concepts in a data system, however, it is disputable. The mapping of the analyzed real world entities and relational tuples is lost due to normalization. Nowadays we see active rules and triggers at least partially solve the alienation of entity model and data model.
Object oriented systems do have the same problems with data integrity. This results in the infamous dangling pointer or dangling object problem. Therefore object oriented systems as well need rules to ensure data integrity. Relational normalization could be a solution here as well. But the strength of the object-oriented paradigm is the one to one mapping of the conceptual model to the object model. This can completely be realized with methods. For years we have used a simple set of rules. These rules state how objects can be protected against integrity violating modifications. As a result we can describe patterns for sets of methods that guarantee object model integrity
Longtime experience has shown that there exist a small number of association types that are used frequently, like one to many associations, one to one associations, many to many associations and hierarchical structures. Given specific applications other recurring association types could be defined.
In order to both advance the development of complex data object structures and to build them more reliably, a set of association generating classes have been developed. The simplest generator, ToOneGenerator, adds a variable to the target class and generates the set, get and clear methods. This is alike the generated set and get methods in VisualWorks. Other generators are ToManyGenerator, OneToOneGenerator, OneToManyGenerator, ManyToManyGenerator and TreeGenerator. Other generators can easily be developed and added to the association-generating tool. This tool is currently under development. As far as we can see now it looks like the description effort is about 10% of the equivalent programming effort, is much less error prone, and can be understood by non-Smalltalk programmers.
Gipa as development support
Gipa is actually a framework to support simple cross class modeling and development. It is a coding counterpart of patterns.
The organization and development of object oriented systems is focused on class development. For years patterns have been used to describe cross class functionality. The metaphor of biology is striking. We can describe biological species. This is very much like describing classes. Another approach is describing ecologies. How do various specious interact and which ecologies are successful. This task has been picked up by the concept of design patterns.
Gipa is an attempt to simplify the bridge between (some) design patterns and class coding. Gipa is highly extensible and should be part of the (Smalltalk) community.
With Gipa a developer can specify a model, the GipaModel. This specification may be stored or may be generated in an XML document. This document describes the classes either to generate or to change. The model specifies the namespace and the main package to be used. The model specifies associations, roles within these associations and classes that implement these roles.
Organization of Gipa 1.0
Gipa is organized in a bundle with a couple of packages. All basic functionality is in the package Gipa-Base. Yhis can be divided in some groups of functionality:
- Gipa Meta.
o Gipa_Manager, the container of a complete model,
o Gipa_Class, a reference and/or specification for a Smalltalk classs,
o Gipa_Role, the description of a role,
o Gipa_Abstract_Association, the mother of all associations.
- Gipa Association Code Generation
o A number of actual code generators. They are named: Gipa__Association
- Gipa Marshalling
o An XML marshaller for Gipa XML structures. Typically this will be used for importing a specification document. It descends from an older form of marshalling that supports the requirements I had for it.
Beside the package Gipa Tests defines the tests.
The package Gipa Support contains a number of more or less useful extensions used in the development.
Working with Gipa
Typically a developer will define a GipaModel first. Later on the GipaModel can simply be changed and expanded by changing the specification document and than regenerated. Personally I prefer not to edit anything in generated classes. For actual usage I subclass my generated classes and store specific, non-generated code in subclasses.
The basic result of code generation is an import file in XML format. This can be stored in a file or filed in immediately.
To illustrate the usage you can look at the tests. But there is also a somewhat larger example as some class methods in Gipa_Manager. These contain:
- A very small part of the domain of the application that inspired me to start with defining Gipa. It is a document with 6 associations and 12 class specifications. It is 150 lines long. I edited this in Oxygen. This generated a Smalltalk sourcefile of 1760 lines, totaling 167 methods.
- The XML Schema definition of the GipaModel XML format.
- A convenience method to generate the source file.
- A convenience method to generate and file in the source file.
Work to do
There are lots of things to do. This is only version 1.0. But let me try to name just a couple of projects:
- Defining a IDE application to specify a model. This should be accessible from the RBBrowser.
- Connecting Gipa with XMLObjectBindingWizard to simplify the mapping of domain objects, an XML Schema of a resulting XML document and mapping of a realization of a model to an XML document.
- Connecting Gipa with Magritte
- Organizing a library of Gipa associations.
- A true ACID transaction processing within a Smalltalk image.
- Connecting Gipa with XMI in order to generate a Gipa model from an UNL class diagram.
- Mapping Gipa domain models to relational databases
- Mapping of Gipa domain models to XML databases.
There are probably many many more things to do.
Gipa is an attempt on a conceptual level to enhance the modeling possibilities in Smalltalk. It is simple to use. In its current form it is defining a UML class model in terms of an XML document.
The fun is that it not only is helping modeling on a conceptual level, but that it also boosts productivity very substantially.