File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes  :confused:  How much depth is needed in class diagram and component diagram. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark " :confused:  How much depth is needed in class diagram and component diagram." Watch " :confused:  How much depth is needed in class diagram and component diagram." New topic
Author

:confused: How much depth is needed in class diagram and component diagram.

Sangmin Lee
Greenhorn

Joined: Jul 06, 2004
Posts: 7
Hi all.

I'm preparing Step-2 exam.

First, I'm confusing, how depth in drawing class diagram.

Must I extend offered Business model ?

OR

Must I draw each subsystem's class diagram ?

Second, How I express JSP, and servlet in Component diagram ??

Is all JSP expressed in one JSP Component?


Third, How I express SSL in class diagram ?

So, much question...


Please reply...
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
I am not at all experienced at designing systems, for I am only a humble road sweeper. However, what I have learned from inexperience is, too much detail too early can confuse. My gut feeling is you do not have to show any J2EE components (like JSP) in class diagrams only Sequence and Collaboration diagram.

Therefore, what I would do is create either sequence or collaboration diagram �the choice is yours- then decide what J2EE component cover parts of that diagram.

Mind you, this approach would require good understanding of Design Patterns.
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
Sangmin Lee look at . Harish Ramchandani's resent topic ,he passed 99%. He says something about his diagrams.
Sangmin Lee
Greenhorn

Joined: Jul 06, 2004
Posts: 7
Thanks a lot
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Gerald, good advice. I don't agree you're a roadsweeper.

A few things I'd like to add.

For the class diagram, most people who passed said they only did one diagram (this would cover all sub-systems). Personally, I would look at extending the Business Model, and don't be afraid to make changes (it is your class diagram you are changing, not the Business Model).

You don't need to put SSL in the class diagram.

Ray
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Originally posted by Gerald Davis:
My gut feeling is you do not have to show any J2EE components (like JSP) in class diagrams only Sequence and Collaboration diagram.


I think it's necessary to show JSP and servlets also in component diagrams. The preferred way to model is probably using component stereotypes JSP and servlet. I also decided to show session beans in my class diagram, like our best resource Cade & Roberts SCEA book teaches. Although it is important not to show too much J2EE component details in a class diagram. Many people seem to have failed because of describing EJB details already in the first phase.
[ July 15, 2004: Message edited by: Tomi Tuomainen ]
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Tomi,
I agree with you about the component diagrams.

For class diagrams, I still can't make my mind up about having stereotypes <<sessionbean>>. I know that Cade does this, so it must be acceptable for the exam. However, it doesn't feel right to me. Isn't this an implementation decision? (i.e. the decision to use session beans is later in a project).

Ray
Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
Ramon,

It could be safest do what Harish did (see Passed Part 2/3 - 99% topic): add UML note that a class will be implemented as EJB component. Anyway, I think it's a thin line between this kind of note and a stereotype, shouldn't affect scoring.
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Some of my thoughts on class diagram..
As described my Martin Fowler in UML Distilled, there are essentially 3 views or perspective of class diagram. Namely, conceptual, specification and implementation perspective. Each perspective represent a different level of detail. In the words of Martin Fowler:

--start quote --

If you take the 'Conceptual' perspective, you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them, but there is often no direct mapping. Indeed, a conceptual model should be drawn with little or no regard for the software that might implement it, so it can be considered language-independent.

In the 'Specification' perspective,now we are looking at software, but we are looking at the interfaces of the software, not the implementation.

In the 'Implementation' perspective, we really do have classes and we are laying the implementation bare. This is probably the perspective used most often, but in many ways the specification perspective is often a better one to take.

--End quote---

So, from what I understand, its upto us what level of detail we wish to show in our class diagram. If we document that we are using the Implementation perspective , then we are very well show the <<session bean>> stereotype, etc in the class diagram and get away with it.

Currently, I am undecided between the specification view and the implementation view, as one might show too less and the other might show too much..

Parag
Paul Mukherjee
Greenhorn

Joined: Dec 13, 2002
Posts: 4
Regarding the general issue of whether identification of session beans is an implementation decision or not, I would argue that it is definitely an architectural decision: appropriate identification of EJBs has implications for scalability and performance which are very much architectural concerns.

Paul

Originally posted by Ramon Gill:
Tomi,
I agree with you about the component diagrams.

For class diagrams, I still can't make my mind up about having stereotypes <<sessionbean>>. I know that Cade does this, so it must be acceptable for the exam. However, it doesn't feel right to me. Isn't this an implementation decision? (i.e. the decision to use session beans is later in a project).

Ray
Ramon Gill
Ranch Hand

Joined: May 15, 2003
Posts: 344
Parag,
I agree with you that its up to us as to the level of detail we show in the class diagram. I see that you are thinking about a mixture of specification/implementation. At the moment I am leaning more towards spec.

Paul,
I see your point about architectual decisions, plus if Cade does it, it must be ok.

Sanmin,
hope you don't mind that I hijacked your thread.
Ray
Parag Doshi
Ranch Hand

Joined: Jun 29, 2004
Posts: 317
Ramon,
I might drop the implementation view if the class diagram gets too messy..i am more concerned and giving more attention to my core class diagram (spec view)..If the SUN guy understands that perfectly, he will easily sum up the rest thru the other diagrams.

Parag
Sangmin Lee
Greenhorn

Joined: Jul 06, 2004
Posts: 7
Thanks guys.

I have another question...

How express SSL on exam 2 ?

If we submit Depolyment Diagram, I can express SSL on node.

But I don't know, how express SSL on 3 diagrams...

Tomi Tuomainen
Ranch Hand

Joined: Jun 13, 2004
Posts: 86
My opinion is that we don't need to express ssl in our diagrams. SSL handshaking is a very detailed technical issue, which is usually implemented by browser, application server, jsse.jar etc. We could of course add UML notes to our component and sequence diagrams between gui and server elements. I can't think of any other reasonable way... ?
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
All I know about SSL is that it is a web security protocol. I don�t know nowt about its server or client responsibilities. To help you decide for yourself:

1: If you have designed a system without SSL and later decide to implement it without having to change the design, then you do not need to express SSL in your diagrams.

2: If there is only one obvious way to implement SSL into your design, there is no need express SSL in your design that add unnecessary clutter because the developer will know what to do to implement the system. Some notes on implementation SSL could help the dude.
Gerald Davis
Ranch Hand

Joined: May 15, 2002
Posts: 872
On most occasions I would agree with what Parag Doshi had said about not showing implementation details in class diagram and take the Conceptual perspective.

But isn�t it our job as the Systems Architect to dictate how the system will be implemented that�s what we do in the sequence and Collaboration diagrams, no?

Then again, Systems do change. If we put to much system specific information into the class diagram, it will dictate how the developers design the system. The same could be said about detail of the class diagram relationship between classes. Example if you use a diamond arrow thingy, inheritance relationship or a specific multiplicity relationship then you have it in your mind that this is the only way to implement the system.
Foram San
Greenhorn

Joined: Jul 21, 2004
Posts: 5
if the class diagram is plainly conceptual then how do you show connection between component diagram & class diagram?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: :confused: How much depth is needed in class diagram and component diagram.
 
Similar Threads
Part 2 discussion
Few questions on part-II diagrams
Class Diagram Tips Please?
Wait is over Passed II/III 96%
Two Questions about Component Diagram