Diagram guidelines needed!

[Tibor Hegyi]

Hi,
I have read through a couple of hudreds of threads in this forum to gain consistent understanding on
approaches to creating diagrams for Part II.
Unfortunately, I could not resolve the ambiguties I found.
So my questions are:
1. What exactly should be drawn in the class diagram? I have drawn my extended, slightly changed BDM with some controller classes
a'la Cade.
2. What about classes not directly related to the business case but rather to the implementation details? I mean classes like
Command or Factory? Shall these go into the Component Diagram? If so, in form of classes or of components?
3. Which diagram is the sequence diagram built on? Some on this forum said it should be built on the Class Diagram showing
messages sent between classes. Some said (along with Cade) it should be built on Components showing interaction of components.
4. If the sequence diagram is based on the class diagram, do we have to specify all the classes in the Class Diagram that will become a
technology specific component/class in the Component Diagram? E.g. I have a Business Controller (EJB) component that does not
manage business objects directly but rather interacts with Facades. Shall I add a corresponding class to the Class Diagram in order to use it
the sequence diagram? I'm not talking about Home/remote etc interfaces...
To put it short, does each component have to have a corresponding class in the Class Diagram?
I tend to think this is not true and the sequence diagram should be based on the Component Diagram because this way it can direct
developers on the interaction of the components matching the use cases.
As you see, I'm a bit confused but I think these questions occur to many of us preparing Part II, so any help is very much appreciated!
Thanks,
Tibor

[Thomas Taeger]

Hi Tibor,

Originally posted by Tibor Hegyi:
I have read through a couple of hudreds of threads in this forum to gain consistent understanding on approaches to creating diagrams for Part II.
Unfortunately, I could not resolve the ambiguties I found.

... you ar not the only one feeling that way. You will not be able to find "the one" stile because OOA/OOD/UML does not propose "the one".

1. What exactly should be drawn in the class diagram? I have drawn my extended, slightly changed BDM with some controller classes
a'la Cade.
2. What about classes not directly related to the business case but rather to the implementation details? I mean classes like
Command or Factory? Shall these go into the Component Diagram? If so, in form of classes or of components?

I decided to follow the practical AND well argued guidlines in
CT Arrington: "Enterprise Java with UML", OMG Press, ISBN: 0-471-38680-4.
In my assignment (like in praxi) I first give a raw class diagram (business related plus Service Locator ...) a la Cade. It is also the way some project leaders prefere. But because I know that on real projects this will never be sufficient for the next crew that has to design in detail and to implement, I also include a refined class diagram showing the technical classes like your "Command or Factory" too. And i show the (preferably few!) dependencies between them, because this enables a good component diagram.

3. Which diagram is the sequence diagram built on? Some on this forum said it should be built on the Class Diagram showing
messages sent between classes. Some said (along with Cade) it should be built on Components showing interaction of components.

I decided to draw
- different raw deployment diagrams
. for getting an overview of the system and
. to understand the spec
- a refining Business Domain Model
. fixing all the gaps and bugs in the given one,
. well documenting my assumptions made
- a raw class diagram a la Cade
. (not important in my opinion, but
. testers might disagree and
. I do not want to loose points for that)
- then the interaction diagrams
. (not sure yet wether sequence or activity)
. because they could affect my detailed class diagram,
- the detailed class diagram
. including all classes of the
. interaction diagrams and
. all technical classes too
- the component diagram
- the final deployment diagram that
. also verifies the component diagram
This is a lot of work, but for me this way is even faster than allways being unsure about the "deliverables" / "results that MUST be delivered". And it is the honest, team oriented way.

I tend to think ... the sequence diagram should be based on the Component Diagram

As far as I know a Sequence Diagram should not be correlated to the Component Diagram nor to the Class Diagram nor to one Usecase but it should be related to one of the possible scenarios (main flow or alternatives) of a Usecase.

4. ... does each component have to have a corresponding class in the Class Diagram?

It must at least have one corresponding class, but according to M.Hitz "UML@Work" (in German), p.164, a component
1) is a physical, plugable, replacable part like a .java, .rel, .exe, .dll, .class,
2) has been produced within the implemented system,
3) can correspond to one or several classes modeled in the progress of requirements gathering, analysis or design.
4) Or according to P.Allen: "J2EE - SCEA...", p. 106, also "Java deployable components - JAR (Java Archive) files" or .ear.
5) And "you can think of this diagram as a kind of compile, JAR, and deploy description."
I know that this does not answer your question directly. From deploying I know that for deploying a component like an EJB all the .class needed by the EJB eighther must be packaged into the JAR file of the EJB or those common or shared .class files must be packaged in a separate JAR and must be made commonly available to the others. Is this thinking in deployment needs wrong for deciding what a component is? Is the JAR the component, or is the ejb.class?
Significantly in literature i did not find even one realistic component diagrams including a valuable description. In my 8 books directly related to J2EE and/or UML (not Patterns, JMS, EJB, Servlet, ...) only 4 (50%) know the phrase "component diagram" at all, but Sun gives 44% of the points for the component diagram. On the other hand Sun itself does as good as nothing to enlighten this phrase. C.Cade offers a pritty uncommented component diagram I would not dare to include in my assignment, and P.Allen on p.93 + 106 just writes 4 + 11 lines about Component [diagram] and then just shows an example consisting of one TradingApplication component, one J2EEApplicationServer node/component/object?? and one TradingSessionBeans subsystem, wihtout any comments at all. The need of component diagrams just a selling argument for Sun courses?
In C.Larman: "Applying UML and Patterns", p. 605 also "a browser" is a component - in contrary to "has been produced within the implemented system" stated by M.Hitz. And then: "... or a JAR file (such as for an Enterprise Java Bean)". And:
"UML components are usually shown within depoyment diagrams, rather than on their own." No example too.
* * *
Not even one commented, valuable Component Diagram, and 44% ....
I think I will treat as a component each:
- at least one shared JAR of server related classes,
- at least one shared common JAR (for server and client),
- each JAR of each EJB,
- the ServiceLocator,
- the BusinessDelegates (depends on ServiceLocator)
- each Factory
- each WebCommand/Command pair
- each JSP or Servlet,
- the Java-client in total,
most of them having a dependency arrow to at least one shared JAR file.
Thomas.
[ February 27, 2004: Message edited by: Thomas Taeger ]

[Tibor Hegyi]

Hi Thomas,
First I thank you for your detailed reply. All you wrote sounds reasonable
and correct.
Although I don't think I'd submit as many diagrams as you listed, but one question occured to me. I wonder whether your Component Diagram will contain components based on your Detailed Class Diagram or on your Raw Class Diagram. I guess the former is true.
I think all my concerns arise from one point: What to put into the Class Diagram? Only a fixed BDM + several controllers or quasi everything (including Command, Factory as well)?
As simplicity is emphasised overall in this forum, I prefer the first approach, but then the some questions needs to be answered. (see my questions in the original post)
I understand that there might be different levels of abstraction in the diagrams, what I'm not totally sure of is what Sun expects from us in an Architect exam.
Still looking for a consistent approach in the light of the requested deliverables (1 Class Diagram, 1 Component Diagram and several Interaction Diagrams)...
Tibor

[Thomas Taeger]

Hi Tibor,
our postings have crossed each other, I have re-edited mine, see above.
Still longing for a well commented, valuable Component Diagram example ....
Thomas.

[Tibor Hegyi]

Hi Thomas,
Concerning Sequence Diagrams, what I meant was whether the objects, they show to express the interactions fulfilling a use case, correspond to components or to classes.
I also lack a good documented Component Diagram Example espacially from the perspective of an architect. The UML spec is also quite brief on Component Diagrams.

I think I will treat as a component each:
- at least one shared JAR of server related classes,
- at least one shared common JAR (for server and client),
- each JAR of each EJB,
- the ServiceLocator,
- the BusinessDelegates (depends on ServiceLocator)
- each Factory
- each WebCommand/Command pair
- each JSP or Servlet,
- the Java-client in total,

More or less this is the current case with my Component Diagram too. Factory/Command are also in this one as components. For the time being, I have not shown JARs as groups of components but individual components only.
Let's see if anybody else can clarify our doubts.
Thanks again!
Tibor

[Tibor Hegyi]

I pick this thread up, maybe a few SCEAs or UML experts share some thoughts of theirs on the issues mentioned in the first post.
This would be very much appreciated.

[zheng shu]

Here is what I learnt and am following, in regard of sequence
diagram and class diagram:
1) create sequence diagram where you will identify both
object/class and messages (class method).
2) based on the sequence diagram, you define the class diagram.
repeat the above two steps in cycles until you get
both.
The sequence diagram gives you an opprotunity to explore
the dynamic aspect of objects in the runtime. This dynamic
aspect is much more difficult to understand than the
static code that you want to produce. Through working
with sequence diagram first, you will gain clues what
methods you need to define and how data/message are exchanged
between instances.
If you have a complete sequence diagram, you get the
class diagram automatically by summerizing what you
have with sequnce diagram.
As for the component, component is a very abstract
concept that you can use to specify a chunck of packaged
code you want to use, at any levels, large or small.
This is I belive a concept more focusing on packaging,
i.e., a physical package, rather than logical one.
It makes more sense to use it at a large scale, rather
than a small one. I belive you can call a class
a component, but most time, the scale is too small to
make any real sense.

[Tibor Hegyi]

Thank you very much for sharing your thoughts!
I think I got the picture.
Tibor