Projection diagram FAQs



Date view Thread view Subject view Author view

Amit Bhagwat (amit_bhagwat@yahoo.com)
Sun, 28 May 2000 01:51:52 -0700 (PDT)


Dear pUMLites, I don't know why my earlier mail came to me twice. Believe me, I sent it only once. Let's hope we do not have recurrence of this. Coming to my last mail, I informed you all that the Projection Diagram FAQs will be released soon. This has been done and I have updated the Projection Diagrams resource page: http://www.geocities.com/amit_uml/ to include the FAQs. You may revisit the same or go straight to: http://www.geocities.com/amit_uml/PROJECTIONDiagramFAQs.htm For those few of us who are not fortunate enough to browse the web, I am giving the plain text version with this mail. There are two things however, One: The htm version is much more readable compared to the plain text version. Two: It is desirable that the pUMLites go through my ideas first before diving into the FAQs, since as our earlier correspondence highlights, the Projection Diagrams do not appear in UML 1.3. Towards this end I am making my work available to all those pUMLites who have contacted me, in the form that is compatible with software available at their end. Please feel free to send any such request to me, preferably within the next week. Unless there are too many requests of the same type, I'll respond to them individually, rather than loading the cs.york.ac.uk mail server with attachment heavy mails. Those who wish to go through the Plain Text version of the Projection Diagrams FAQs, please read on. Warm regards, Amit Projection Diagram FAQ Q1. I seem to have heard about Projection Diagrams. Can you tell me more about what they are? As far as UML is concerned, you are more likely to have heard 'projection' as a stand-alone word rather than the phrase 'Projection Diagram', unless of course that my work has received good publicity quickly or (as a very remote possibility) there are parallel contributors to the yet to appear UML 1.4 who have used this phrase in a similar or an altogether different context. If the RTF may be able to bring such a case to my notice, I'll be happy to collaborate with my parallel if the work is similar. I am also open to use of a different nomenclature if that is necessary or if that appeals most of us. Now let's turn our attention to how the word 'Projection' appears in OMG Unified Modeling Language Specification version 1.3 (June'99). The glossary has the following definition: Projection: A mapping from a set to a subset of it. The word has been used consistently in this sense in defining other terminology in the glossary as also in describing collaboration. Elsewhere, if used otherwise, description as 'projection means that the presentation element represents a human readable notation for the corresponding model elements' is also provided. The phrase or a very explicit concept of Projection Diagram does not appear in UML 1.3. Q2. So you mean, Projection Diagram is, with due derivational help, a 'top to toe' original idea? Yes, unless there should always be a Joseph Henry for a Michael Faraday (or someone much less luminous like me.) Q3. Let's know then, what is projection is your case? A view of the model is an effort much along the OMG definition of mapping from a set to a subset. In our case, a first look may make us say that it is mapping among subsets of a set. If we go a bit deep to note that the Projection Diagrams tend to visually bind together various views of the model, we may better say that projection in our case has a more comprehensive definition as: A mapping from a set to a subset of it, as also from a subset to another. The reason for this nomenclature chosen is however much simpler as explained in the coming answers. Q4. But why hold on to a word already used by OMG? Reason one: The word really deserves a bit broader definition than the present one. Reason two: This happens to be the reason that actually triggered the nomenclature and is much more apparent to a graduate of mathematics, engineering, technology or any area that exposes a good deal to Projective Geometry in general and Orthography in particular. The Projection Diagrams are UML equivalent to projections in Orthography (which are also mapped to one another) and serve much the same purpose in viewing and understanding the model as projections in Orthography do in viewing and understanding a solid. Of course, we all are open to a better name, better definition and better ideas. Q5. What are underlying assumptions for the Projection Diagrams? The underlying assumptions are simple and generally accepted in the UML: Real world systems comprise of objects. Objects may (and for a real world system do) have static relations and communication though sequence of messages. Classes provide template for objects. In other words objects instantiate classes. Classes (including parameterized) and interfaces need to be made instantiable for their use in real world systems. Classes may group into packages and may share resources. Classes may group to work as a unit (component) with no independent existence for external world. Physical resources may be identified by the services they render through classes / components /packages harboring on them. Q6. Which views are you essentially projecting in the Projection Diagrams? We are essentially projecting the class view on the sequence view amalgamated with the object view. Q7. So why are you volunteering to cram components, packages and even nodes in the Projection Diagrams? The answer lies in the assumptions given above. The first four among them form basis for the Projection Diagrams whereas the next three with a distinctive MAY in them show a likelihood of existence. These, if present and definable, are best put on the canvas for clarity and definition. The views presenting them are thus allowed in the projection. Q8. Where do the lifebands fit in the whole picture? Lifebands form a useful but not essential adornment to the sequence view. Sequence view gives us a definite time axis and it makes ample sense in putting down lifeline and parameter passing of methods, as also states of objects with respect to time, if they are well defined, rather than restricting ourselves to lifelines and messaging of the objects. This is essentially Projection of method lifelines and object states onto the time axis. Q9. List the benefits of the Projection Diagrams. (This is one of those 'within 100 words please' questions) In their simplest form, the Projection Diagrams integrate logical and process view. More comprehensive form gives insight into development and physical view. They thus present the 4+1 View Model well, thereby painting a clearer and more comprehensive picture of the system at hand. They force a good deal of system study, conceptualization and even work with other views. This saves from the bad and disastrous habit of leaving important decisions to never materializing future: the tendency of putting head in the sand. The projections check inconsistencies or even worse somehow stage-managed consistency that so often thrive in keeping the views separate altogether (which is not recommended but done all the same in the industry). Q10. It all sounds rather simple. Draw a Projection Diagram and let a CASE tool be developed to do all the rest. Can Software Engineering be ever so easy? Easy all right. But 'so easy' depends on the complexity of the system. Indeed Projection Diagrams are not to make the complexity vanish but to tackle it efficiently. One thing is certain however: Unless the system is a cakewalk, it is not expected that we start with a single all encompassing Projection Diagram. Read on to follow the methodology guidelines. Q11. So what methodology do you recommend to blueprint the system? Let's break this up into five sub-questions: SQ1. Given a system to be modeled do we jump straight (head first) into the Projection Diagrams? Are you used to following the system through extensive help of Use case diagrams, Statecharts, Activity diagrams, etc. etc.? Do you do a lot of homework before you can get down to the Class diagrams? If you are following this practice successfully, (and most of us do that) please continue to clear your concepts and vision of the system under design by following this methodology. Projection Diagrams do have scope for iterative evolution and yet doing well-established groundwork certainly helps. SQ2.Do we make any special effort to wind up the whole affair through one Projection Diagram? Get back to what a most basic Projection Diagram is. It encompasses class, object and sequence diagrams. Would you under present methodology venture into a model with only one class diagram and sequence diagram? If the system is so simple that indeed one class diagram and a sequence diagram suffice, then so will one Projection Diagram do. Otherwise, and as a general rule always, it won't. SQ3. If not, how do we build a multitude of them to make the system clear? If it were asked, what a brick wall is built with; the meaningful answer will be bricks, and not clay particles, or for that matter molecules or atoms or quarks. Though the rest are also valid answers, they are totally out of context. It is true that certain properties of clay particles, which may well be traced down to subatomic level, are responsible for the making and usefulness of bricks. It still remains however that the wall is built out of a few thousand bricks rather than a few billion clay particles, because the clay particles have not built the wall through a direct union, and a sub-union into bricks has been necessary. Here we are essentially talking about the well-tested and proven method of Leveling and Layering. A top down approach will be helpful in our case. Thus, we define objects at highest level of abstraction and build a consistency between the static and dynamic views through Projection Diagram. We then drill each of the objects down to capture respective constituents and their interaction through another Projection Diagram and so on. The total number of Projection Diagrams will depend on level of detail attained in the modeling and also on the number of steps (layers) encountered in the whole exercise. In fact if it has occurred to you, we have followed this methodology in proceeding along various sub-questions in this question. Quite rightly said that OO is not confined to Software Engineering, it is a way of life. SQ4. How to go about building a Projection Diagram? Broad hints and even road maps for this problem are available right from Jacobson's OOSE/Objectory process. The message is quite clear. The whole system exists for performing some operation, i.e. to behave. Thus, how to get the requisite behavior out of interaction between a group of objects is the foremost modeling consideration. Then comes the issue of what these objects shall be like and further how they may be classified. This clearly means that we start from the Sequence diagram, build object relations based on it, build instantiable classifiers for these objects, and lastly workout further possibility of parameterization and reusable interfacing among these classes. SQ5. Having briefed about the construction of the Projection Diagrams in general, when do you visualize the defining of the lifebands? Continuing on our earlier discussion, we first define inter-object messaging with an aim of attempting the desired system behavior. Here it becomes evident to us how states of the participating objects may change or what job each of them will perform. Thus the lifebands materialize before the classes do and they provide signature (methods and attributes) to the classes. Q12. Have you or anyone else applied the Projection Diagrams to design a 'really complicated system'? No. To check that what I propose makes sense, I've gone as far as designing a few simple systems as proof of concept. We must note however, that the Projection Diagrams are today mainly conceptual. A lot of brainstorming is to occur on them leading to their standardization and precision. Only then can they be a candidate for inclusion is say UML 1.5. Towards this end I look forward to collaboration with all of you. Once this is done to a fair degree of completeness, the option of it being picked up by case tools arises. This will lead to enhanced practical use and will give important feedback for conceptual development. __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/


Date view Thread view Subject view Author view