[vwnc] Publication of GIPA (Generator of Integrity Preserving Associations)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] Publication of GIPA (Generator of Integrity Preserving Associations)

reinier van oosten-2
Dear Smalltalkers

I'm pleased to announce that I just published in the public repository  
the bundle GIPA. It can be loaded in any recent clean image in which  
StoreForProgres is loaded (needed to access the public repository).

To give you an impression of its functionality I include the comment  
on the bundle.

I welcome all comments on this bundle.

-----------------------------------------------------------------------------------------------------------------
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.

Background:

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_<Type of  
association>_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.
More advanced:
- 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.

Conclusion

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.

-----------------------------------------------------------------------------------------------------------------

Reinier van Oosten
email: [hidden email]



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc