Month Year Issue

June 2000 Issue: 14

Journal of Conceptual Modeling
www.inconcept.com/jcm

Projection Diagram - The Unified Approach at a Glance
By Amit Bhagwat

Preface

The ideas in the article are shared at: 4th Workshop on Defining Precise Semantics for UML at European Conference on Object Oriented Programing (ECOOP'2000), France on June 12,2000. (http://ecoop2000.unice.fr/) A comprehensive presentation (PPS) on the projection diagrams is available at: http//www.geocities.com/amit_uml/.

Introduction

As stated by Sinan Si Alhir [1]:

The UML is intended to be an evolutionary general-purpose, broadly applicable, tool-supported, and industry standardized modeling language for specifying, visualizing, constructing, and documenting the artifacts of a system-intensive process.

Over the years, UML has progressed in leaps and bounds to accomplish by and large its intended objectives that many of earlier software modeling techniques have managed in a rather limited way. It is the constant endeavor at becoming a complete and comprehensive software modeling system that has given UML a definite edge over the others. Of course this has meant the benign practice of combining the best available methodologies and notations from a sea of software modeling techniques. The unified approach here has given analysts power to look at system development from the context and paradigm that bears most relevance and makes the most complex things definable as blocks of an integrated system or steps in an integrated operation. It has also given the analyst an opportunity to be certain of the system model from every relevant perspective. Scott Ambler has well illustrated how the UML Models Fit Together [2] to give a total outlook. Thus provided that the analysis is performed with an eye on relevance with other views (and provided that all the views are not synchronously misleading), the model is more likely to have an ability to materialize into a system.

In this article we shall first summarize the commonest views that are defined by the UML as of now and proceed to bring the process of unification into a lower level of designing.

A way to look at

Modeling a system starts with abstracting it from a particular viewpoint. The analyst may wish to be attentive to the work steps, state transitions, system-user interactions, inter-component relations in terms of association / containment or operational data-transfer, or the physical placement and configuration of the components. It is thus a tendency to sketch a model to suit the perspective of the analysis at hand and suitably iterate till an acceptable version is attained. It is often found convenient to classify these filters through which the system is abstracted as static views and dynamic views. It is generally accepted that the inter-component messaging, data flow, state transitions, interaction with user and lifecycle of the components be followed through the dynamic views, whereas their relative placement and interrelations be covered by static views.

It is common to look at a system as a logical entity with the above interactions and interrelations, thus thinking more generically of it, as also visioning it as a real life entity with every practical constraint and a considerable specialization. This leads to distinct sets of physical and logical views. Whereas the former articulate real-world systems the latter have portability across a variety of these.

It is quite evident however, even before venturing into discussions about any of these views that the system needs to be designed giving respect to and attaining concurrence among these views. Further, whereas some view like use cases and activity flows contribute more to analysis and understanding, some others like class view serve an equal deal or perhaps more in system design. These views have capability to be mapped easily to components of the real world system. It is to these views that we shall confine the following discussions.

The static views

The OO methodology has its roots at its ability to categorize and classify bundles of data and implementation, which provide specific interfaces, through which they perform specific set of tasks. The logical view of classifiers and their instantiations thus serves as the basic static framework for system design. The basis of static view therefore is the way in which such classifiers are related to each other and the way in which they may be abstracted or parameterized.

The dynamic views

The common dynamic views that bear direct relevance to system design are the state transition view and the interaction view. Whereas the former is more to the level of a unit the latter as the name suggests is about interaction in a group of objects.

The physical views

So far we have reviewed the logical designing of system. There are models to view the system as is physically deployed. It is a usual practice to classify them apart from the logical designing mentioned in the above sections. These views bear direct correspondence with the configuration of the system. Among these the most uncontroversial is the deployment view. The package and component views also belong to the real world.

A unification

UML as the name suggests has come this far through the process of unification and thus combines ideas of leading thinkers and gives access to their methodology of modeling in consistency with that of the others. Now we are planning to get down a level further and to represent these modeling methodologies on the same canvas.

To bring these entities under the same frame of reference we need first to look for a commonality that is not far stretched or bolted out of blue sky. Such point of joining between the static logical view and the dynamic interaction view is in terms of objects in the interaction view as also the object view that materialize as instances of classifiers (classes) in the logical view (class diagram).

Whereas classes are templates which can only have constants (which may be parameters in case of a parameterized class) as valid attributes, the objects instantiated from them have state and therefore attributes which are variables for the class. Thus we may be able to project objects in sequence diagram onto classes in the class diagram. We may further define the state of these objects through adornment to the interaction view and effectively present a view which gives static relations among classes as well as state interaction and lifetime of the objects instantiated from them. This is illustrated in figure1.

We still retain the liberty of providing instantiation to a parameterized class. Similarly there is no restriction to giving qualified association or aggregation or realizing an abstract class since we are only projecting an object on an instantiable class and all the state related adornments are made to the original construct of the interaction view.

The states in figure1 can further be qualified to present detailed depiction as in figure2.

Here we have broadened the lifelines (lifebands / lifejackets?) so as to accommodate lifelines (they may better be called lifethreads since they bear striking resemblance to real world threads) for methods (on the left side) and markers for attribute value change (to the right). Here for Yclass this change is a continuous process, whereas for Xclass it occurs discretely thus not showing a line joining these attribute changes.

This is drilled down a bit further to illustrate a good many logical view complications in figure3.

Here parameterized class Xparam is instantiated in Xclass whereas Yclass implements (realizes?) interface Yinter. We also have relation "Xclass has Yclass". This is much better depicted as aggregation at the level of objects instantiated by each of them since it further qualifies that there shall be one instantiation of Xclass for which there my be 0 to 3 instantiations of Yclass contained within it. In case we wish to visibly retain class relations, there is nothing forbidding us from putting the desired relationships in place (may be at the cost of redundancy but without any potential harm).

A bit may now be done about unifying the physical views into our present enterprise. Since physical views have brought us 'back to earth', it is worthwhile considering real world situations. I.e. scenarios where the classifiers are just packed together and are meant to be unpacked and interpreted at runtime as in the case of Java or where they are integrated into components which in themselves behaves like standardized classes (say COM components if that's your trade).

We do not have anything lost if we perform some packaging in either case. We may first bundle up the classes (which are after all templates for discrete clusters of data and operations) into components as may be necessitated by many of the software development paradigms. These components may then be packed, in view of coupling involved in them, to deploy / execute suitably. On the other hand, in a Java type scenario the packages can directly be stuffed with the classes. We of course continue to retain flexibility for putting forth separate logical and physical packages and thus present both software specific as well as generic grouping in the same diagram. We then suitably stuff our nodes (deployment panes) with these physical (component) packages or loose components. This gives a plain and direct line of relation as is represented in figure4.

Let's add another class and its object to our darling system of two objects indulged so long with, to present a "Proof of Concept" as in figure5.

Taking the description where we left it for figure3, we observe that a class Zclass and its instantiation along with its lifeband are added. Next we put Xparam, Yinter and Yclass (looks funny but this is only hypothetical) into component Comp1 (call it a DLL if you can not resist the temptation). Similarly class Zclass is whisked away with Comp2. We are now packing these two components into package pack1. In the present case it is a physical package (like those instant cook jars and kick start cabs) and is ready for deployment. We represent its harboring on the node Server1 by pointing an anchor to this node as indicated.

SWAT

I am reminded of the Amigos' [3] statement on UML:

"In the Unified Modeling Language, clouds disappear. This was the Right and Noble Decision: Rectangles are easier to draw and more space efficient, although they are heavily overloaded. We preserve the concept in object diagrams, which use structured clouds (basically, vertically elongated hexagonal shapes). Jim's pointed out that when clouds crystallize, they form hexagons so we probably made the right choice here."

Used in a rather specific context the statement presents a great moral. Indeed UML is meant to eliminate the cloudy zones in software modeling. Another thing, UML semantic is to be that which is easy to work with and yet which is wholly covering the system at hand. Having chosen to present outline of the unified view christened the Projection Diagram; it is time that we look into the utility and usability aspects. Indeed we perform a SWAT analysis for it.

A better view:

The diagram presents a clearer and more comprehensive picture of the system. The Logical and process view are well integrated in figure3 whereas the insight into development and physical view is coupled to this in figure5. The projection diagram thus makes the 4+1 View Model [4] more apparent.

The level of analysis and understanding needed for putting up the projection view requires a great deal of homework (which may involve use cases, state charts or even drill on the class and sequence views). What Philippe Kruchten phrases as Putting head in the sand [5] - the temptation of postponing "rather difficult" things to the never materializing future is thus discouraged a good deal while attempting to put up this diagram.

Consistency:

To use a metaquote (quoting a quote [6])

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. - Ralph Waldo Emerson, 1873. Stretched a bit to the social situations of that period though, this quote rings a warning bell against a 'some how stage managed' consistency which is fictitious and disastrous (and as Emerson's candid words take it - foolish). It may be out of confusion or inadequate opportunity of mapping one view on to other while building a multitude of them.

The projection view, through forcing the analyst to project the static and dynamic views and further extending them to physical world, helps in controlling such inconsistencies.

Anti-KISS?

To borrow Magnus Penker's thoughts: [7]

The goal of UML is to establish an explicit coupling to conceptual as well as executable artifacts; describe correctly the system to be built; and present model of system (and not just software) which is consistent, easy to communicate to others and easy to change and understand using object-oriented concepts.

We have so far established how the projection view endeavors at most of these. There may be some doubt as to whether this view is easy to change and understand. The KISS (keep it short and simple) advocates will at once raise their fingers. Indeed the diagram may appear puzzling if it is not clear where from to start it, building or viewing. This brings us to:

How to go about it?

It has been amply discussed earlier that the analysts are at liberty to take a good deal of help from use case diagrams and statecharts as also to venture into the sequence and class view separately if that gives them comforts and peace of mind. Once ventured into building the unified view it will help following some discipline. Many methodologies will agree with Doug Rosenberg's thinking of Driving the Static Model from the Dynamic [8] one. Thus it makes ample sense in starting the construction of the projection view from the sequence view. It may be worthwhile adding adornments through the lifebands that contain method lifelines and state information. The next to build upon are the instantiable classes which are materialized into the objects in the sequence. The parameterized classes / interfaces etc. which are related to these appear next.

The diagram gives the analyst liberty to concentrate on the logical view as in figure3 and come down to the physical view a bit (but not a great deal) later. Indeed "to partial fulfillment of the requirements" the projection diagram stands at the level of figure3 itself. We have discussed in earlier sections how to go ahead of this to get to the completeness of figure5 with an eye on the physical world.

There is no need to cram the projection diagram with every detail, for as Jim Rumbaugh recommends it, the projection diagram can well follow Leveling and Layering [9] to analyze and synthesize the system. The analysts will find it suitable to build projection diagrams at different levels of view.

Further work

If the reader has been patient enough to come this far with me let me make a (rather obvious) confession (a bit too late). It is that apart from introducing a few relational notations and the concept of lifebands there's precious little that has been contributed to the semantics. I have attempted here to do more for concepts than for apparition and have introduced with a minimal proof how the concept may potentially stand. It is to bring all useful views together and to ensure consistency among them (that the crusading analyst may elect or happen to sidetrack) that the projection diagram is ever thought of.

Like all newcomers it has a rough road ahead where a lot of semantic standardization is to be brought in. It needs to be practiced by experienced methodologists to add useful features and eliminate any discrepancies. Being aggregated from other views it is not to be regarded as a replacement but rather as a better manifestation of them.
It has been a similarity both in concept and appearance that this diagram has had with various projections in engineering drawing that has suggested its name. Methodologists are welcome however to regard it as a makeshift name along the lines of the centennial X-rays and suggest better ones.

References

Sinan Si Alhir - The Unified Modeling Language (UML) - Two Years After Adoption of the Standard (November 28, 1999) (http://home.earthlink.net/~salhir/theumltwoyearsafteradoptionofthestandard.html)
Scott W. Ambler - How the UML Models Fit Together (Software Development / Focus on UML) (http://www.sdmagazine.com/uml/focus.ambler.htm)
UML - FAQ (Microgold / Provided by Rational Software) (http://microgold.com/Stage/UML_FAQ.html)
Philippe Kruchten - The 4+1 View Model of Architecture (Rational Software Corp. / UML resource / Whitepapers ) (http://www.rational.com/uml/resources/whitepapers/dynamic.jtmpl?doc_key=350&borschtid=00911070010268002672)
Philippe Kruchten - From Waterfall to Iterative Lifecycle: A tough transition for project managers (Rose Architect - Spring 2000) (http://www.rosearchitect.com/mag/current/spring00/f8.shtml)
Michael Moors - Consistency Checking (Rose Architect - Spring 2000) (http://www.rosearchitect.com/mag/current/spring00/f6.shtml)
Magnus Penker -The Unified Modeling Language (Boldsoft news /Guest Column - July 1998) (http://www.boldsoft.com/news/columns/column1998july.htm)
Doug Rosenberg - UML Applied: Nine Tips to Incorporating UML into Your Project (Software Development / Focus on UML) (http://www.sdmagazine.com/uml/focus.rosenberg.htm)
Jim Rumbaugh - Bridging the Gap (Rose Architect / Amigo Page - Winter 1999) (http://www.rosearchitect.com/mag/archives/winter99/amigo.shtml)

Amit Bhagwat is a visual modeling enthusiast who has been in the thick of object oriented software modeling and architectural development for last two years. He is an active member of the precise UML group and happens to be the brain father of the projection diagram. He shares a variety of other interests including photography, poetry, sociological study, etc. and is addicted to writing. Explore some of his work at: http://www.geocities.com/amit_bhagwat/.