• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sangmin Lee look at . Harish Ramchandani's resent topic ,he passed 99%. He says something about his diagrams.
 
Sangmin Lee
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot
 
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 344
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
if the class diagram is plainly conceptual then how do you show connection between component diagram & class diagram?
reply
    Bookmark Topic Watch Topic
  • New Topic