The popularity cycle of graphical tools, UML, and libraries of associations

(the official site of the OOPSLA workshop planned for October 22, 2007)

WARNING:This site will continuously evolve until the day of the workshop. If you are interested in this workshop, please check this site periodially in order to see additional technical details and information about new participants and the program.You can also go to the printable version.

1. Technical problems to be discussed
2. Time and place
3. Organizers
4. Participants
5. Registration
6. OOPSLA conference

1. Technical problems to be discussed.

The workshop will attempt to take a unified view of UML-related ideas which span from high level software design (UML and MDD) to technical details of implementing reusable associations.The new ideas should not be language specific -- they must apply to at least C++ and Java. The following diagram shows how these seemingly different ideas relate to each other. Blue boxes are basic observations, the red box connects the high level issues (top part) with the low level, implementation issues (bottom part).

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;

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

2. Time and place.

This workshop will be held as a part of OOPSLA 2007, either on October 22, 2007. The OOPSLA conference will run October 23-25.

This will be a full day workshop.
In the morning, we will discuss the high level problems such as the popularity cycle of graphical tools, potential impact on UML and MDD.
The afternoon will be dedicated to low-level issues such as the implementation of reusable associations, use of code generators, expansion of existing class libraries, and additional features needed in OO languages.

The conference will be in Montreal, Canada. For details and other related information, monitor OOPSLA 2007 website.

3. Organizers.

We are actively looking for people who would like to join the workshop organizers. If you are interested, drop us email. At the moment, the organizers are:

Martin Soukup
Until recently, Martin was a lead security architect at Nortel Networks and represented his company on security and modeling at the United Nations Telecommunications Agency. He is currently a Design Manager and is interested in security, distributed software development, service oriented architecture, and model driven design. He received a MSc in information technology from the University of Liverpool and is a member of the IEEE.

Jiri Soukup
Former manager of the Bell Labs M.H. team which developed the automatic design of silicon chips as we know them today. One of the seven founding members of Cadence Design Systems, San Jose, CA– the largest VLSI CAD company today. Currently president of Code Farms Inc. (Ottawa), company dedicated to better ways of designing software. Author of over 50 papers, book “Taming C++: Pattern Classes and Persistence for Large Projects”, published by Addison-Wesley 1994. Jiri studied both engineering and mathematics, and has a PhD degree in Technical Cybernetics (Prague, 1967).

4. Participants.

OOPSLA workshops provide a creative and collaborative environment where attendees meet to surface, discuss, and solve challenging problems related to a variety of research topics. The prime purpose of this workshop will be to share ideas on a hot new emerging technology, and possibly looking for collaborators on a book. Potential attendees must submit either a short position paper and/or a short bio explaining how their experience and expertise could contribute to the discussion. We'll also consider position papers from people who cannot come to the workshop but have a strong opinion on the subject.

Please, register early!. The number of participants will be limited. Also, the number and background of the participants will influence the program of the workshop -- the time for individual presentations, potential panels, emphasis on certain subjects -- organizers need to know early.

Please read the material on this site, browse through the position statements of pre-registered participants type your position statement as *.doc or in the plain *.txt format, and email it to the organizers even before you register for the conference itself. At the workshop, the emphasis will be on active collaboration and not on organizers presenting their own opinion or work.

5. OOPSLA Conference.

For all questions related to the OOPSLA conference in general including registration, please go to the OOPSLA 2007 website