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;
...
};
(b) To introduce new keywords association and participants. Keyword association would declare an association, retrieve its
pieces from the library and insert them transparently into the association classes:
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.
