Box 1.Historical cycle: textual programming vs. graphical tools.

The following cycle has been observed. Programmers create software which keeps growing both in complexity and size, until it is hard to manage. At that point programmers reach for various graphical tools to keep the complexity under control. It does not take long though and a new paradigm is invented which eliminate the source of complexity. Graphical tools are abondoned, programmers return to textual programming, and a new cycle begins.

An article about this is scheduled for the August 2007 issue of the IEEE Computer (Soukup J., Soukup M.: The Inevitable Cycle - Graphical Tools and Programming Paradigms). Until this article is published, you can view an earlier document on the same subject. Both documents describe three such cycles: Flow charts which were eliminated by the introduction of structural programming, table diagrams which were eliminated by the introduction of structures and pointers, and once popular pointer diagrams which are not needed since the introduction of class libraries (STL and Java Collections).

Box 2. UML class diagrams are popular today.

There is no question about this -- any properly designed software project today uses UML, at least the UML class diagrams. If you work in a MDD environment, UML drives the entire design and the first skeleton of the code is generated automatically.

Box 3. Why are UML class diagrams so popular?

It is important to understand the underlying reasons: (a) In the current style of the object-oriented programming, classes are highly visible but their relations (associations, data structures, design patterns) are burried inside class definitions and not easy to find. UML gives us one unified view where classes and their relations have the same importance. (b) When you program with existing libraries you think in collections (containers) and pointers (references). UML forces you to think in higher level concepts -- the associations. Note that collections are only a subset of associations: Associations include bi-directional relations among 2 or more classes, while collections (uni-directional relations between just 2 classes) are only a special case of associations.

Box 4. What will be the next paradigm?

If the observation about the popularity cycle of graphical tools is correct, the widespread use of UML today indicates that a new programming paradigm is imminent. We don't know what this paradigm is going to be, but if this paradigm will superseed UML class diagrams, it should allow us to program with associations, in a style which would resemble how we program with collections today. This new paradigm should also make relations among classes (associations) first class objects, in other words these relations should be clearly visible without wading through the code.

Box 5. We need libraries of associations

Very likely, the new paradigm will employ libraries of generic associations, however the existing features of the OO languages (in particular C++ templates and Java generics) do not support such libraries. Generic associations must not only depend on parametric types (just like reusable collections do), but they also require special members to be inserted into the classes that participate in those associations. Intrinsically, associations are intrusive data structures -- an important category of data structures which have been neglected in recent years due to the widespread use of collections. One of the attempts to provide this missing feature is the Aspect Oriented Programming (AOP).

When using the existing features of the commonly used OO languages, the insertion of additional members can be done either through multiple inheritance or using a code generator. Since Java and C# do not have multiple inheritance, the first method is unlikely to become popular. Technical details including an unsuccessful attempt of applying the AOP to this problem are described in Soukup J., Soukup M.: Reusable Associations . This paper has been submiteed for publication, but has not been accepted yet.

Box 6. Structural design patterns combine associations with inheritance.

This was described in Implementing Patterns (Soukup J., The first conference on Pattern Languages of Program Design, proceedings edited by J.O.Coplien and D.C.Schmidt, Addison-Wesley 1995, pp.395-415). If we plan to build libraries of associations, we may right away build them in a way which includes structural design patterns.

Box 7. Expanding existing collection libraries to include associations.

As a feasibility study, we designed a library of associations based on a simple code generator which works both in C++ and in Java. We do not claim this to be the best solution, perhaps you have a better idea which you can present at the workshop.

This software, called IN_CODE MODELLING is Open Source -- it does not require a license unless you plan to use it for commercial purposes. It's main three parts can be downloaded independently: The C++ library including its code generator written in C++, the Java library including its code generator written in Java, and the Layout program which generates high quality UML class diagrams from a simple textual declaration of associations.

Each part includes documentation and a suite of test programs.The software has been tested under Windows XP, but it is coded in a general way which should run with a minimum conversion (if any is really needed) under Unix or Linux. The Layout program applies advanced VLSI CAD algorithms to make the UML diagram logical, easy to read and esthetically pleasing. Note that the code generators are coded using themselves and each its own library -- a good example of how these libraries can be used.

Box 8. Support of reusable associations in the existing OO languages.

The important question is what features we would have to add to the existing OO languages in order to support reusable associations. This is one of the issues also discussed in document Soukup J., Soukup M.: Reusable Associations . It seems to us that the following features would be required:

(a) In addition to types or integers, to allow templates (or generics) to parametrize member names. For example:

       template<class A, name abc> class MyClass {
            A abc;
           ...
        };

        class Student;  
        class Course;
        class Takes {
            int mark;
            int attendance;
        };
        association ManyToMany<Student,Takes,Course> studentCourse; 

Keyword participants would describe the role of classes which implement the association inside the library.

The obvious way to implement part (b) would be to add our code generator to an existing C++ or Java compiler, but there may be some better way. We have been contemplating about this, but have not done any work and are looking for people interested in this part of the project.

Box 9. Impact on MDA and existing UML tools.

Since there would be a one-to-one correspondence between associations in the UML diagram and their declarations in the code, the currently used code and UML generators would be reduced to trivial programs matching the two sets.

The declarations of associations, especially if placed together as a block of of code, could be used as a textual form of the UML diagram, eliminating altogether the need for using the UML class diagram, at least on small and medium sized projects. Jiri has been comfortably working in this mode for over a decade.

Using the database terminology, you can think about this block of declarations as being a schema of the data organization. This schema would control the implementation and, at the same time, would give us a compact information about it, in a form we can easily find and read. For those who still want to see a graphical representation, with every compilation, we can easily generate the UML class diagram from this schema as it is done in the IN_CODE libraries.

This is really turning the existing MDA inside out. Instead of controlling the data structure by the UML diagram, the data structure is controlled from within the code -- by the schema. The UML diagram is automatically generated and is only an auxilliary entity, a help for the programmer. It is never edited in the graphical environment -- the only way you can change is is to add, remove, or modify the declarations of the associations (or the inheritance among classes). This is not only faster and safer, but may lead to a superior graphical representation.

As explained in the postion paper for the ATEM workshop 2007 Soukup M., Soukup J.: Graphical Tools and Language Evolution, model driven design isn't really about pictures but about using models in programming.

All these ideas may appear rather strange to those who are used to the existing MDD -- it is indeed a change of paradigm, and we anticipate a lively discussion on this topic.

Box 10. Will we go back to textual programming?

This is the main subject of this workshop, and the answer will depend on our discussion of boxes 4,8,9, and 13.

Box 11. Does this apply to distributed computing?

This is another important area which we would like to explore.

Box 12. UML isn't just class diagrams.

Beside the most commonly used static view (class diagram), UML provides many other views of the design: Use Case View, State Machine View, Activity View, Interaction View, Physical View, and Model Management View. Even if the new paradigm would eliminate the need for class diagrams, the management of other views could be a sufficient reason for using the UML in its present style. Or is it?

Box 13. Can you imagine textual representation for other UML diagrams?

We should discuss, specifically for each of the UML views
(1) what would be the impact (or improvement) if associations become first class entities and are available in a reusable form
(2) what additional members and/or methods representing the associations would have to include in order to substitute for (or replace) that particular UML view.