Gipa started as "Generator of Integrity Preserving Associations". Our 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.

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.


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.