aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes class diagram and sequence diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "class diagram and sequence diagram" Watch "class diagram and sequence diagram" New topic
Author

class diagram and sequence diagram

suekar meredilko
Ranch Hand

Joined: Mar 27, 2006
Posts: 153
Hello All,

I have a doubt, I have been reading through the assignment and also gone through some earlier posts in this forum provided by successful candidates and have the below 2 doubts.

There seem to be mixed answers. Pls. contribute what your thoughts are.

1) Class diagram
Most folks agreed to have a simple class diagram avoiding EJB related, Framework related information rather expanding on the BDM provided by Sun and documenting any specific assumptions one might have made.

Is it a good idea to provide more than 1 class diagrams to be on a safer side like expanded BDM class diagram (conceptual/specification in nature) and then supplement it with more detailed and implementation specific diagram covering all the gamut of J2EE like controller, filters, validators, deligators and patterns, ejb etc.

What are your thoughts ?

2) I see that sun provided 4 usecases and mentioned ... to create a sequence diagram or a Collaboration diagram for each use case provided.

Now my question is a usecase may involve multiple sequences, are we suppose to add all the sequences. A single usecase will involve multiple steps. Each step involves a sequence so should be make that sequence diagram for each step ?

Hope asking this question is fine in the forum. Otehrwise I will treat this as my own assumption and go ahead.

thanks for the help.

Suekar
Thomas Taeger
Ranch Hand

Joined: Dec 16, 2002
Posts: 311
Originally posted by suekar meredilko:
2) I see that sun provided 4 usecases and mentioned ... to create a sequence diagram or a Collaboration diagram for each use case provided.
Now my question is a usecase may involve multiple sequences, are we suppose to add all the sequences. A single usecase will involve multiple steps. Each step involves a sequence so should be make that sequence diagram for each step ?

There is a formal reason for being free to provide at least this count of interaction diagrams or even more : In UML 1 we preferably provide one sequence per scenario, in UML 2 a Sequence diagram can show all controll flow including branches and loops of a whole usecase.

I think there is an additional reason to be free in deciding the number of sequence diagrams - deriving from the different roles: Business analysts providing the Usecase diagrams have another (business...) and a more coarse grained scope than the architects designing with Sequence diagrams.
In my assignment (still pending) I have split one Usecase into more than one Sequence diagrams and
on the other hand for one of the Usecases I decided to not provide a Sequence diagram at all - with a written reasoning of cause.


Originally posted by suekar meredilko:
1) Class diagram
Most folks agreed to have a simple class diagram avoiding EJB related, Framework related information rather expanding on the BDM provided by Sun and documenting any specific assumptions one might have made.
Is it a good idea to provide more than 1 class diagrams to be on a safer side like expanded BDM class diagram (conceptual/specification in nature) and then supplement it with more detailed and implementation specific diagram covering all the gamut of J2EE like controller, filters, validators, deligators and patterns, ejb etc.

I know that nobody likes Component diagrams, some even do not like interfaces. But I found that Component diagrams along with its interfaces often are the missing clamp.

Instead of thinking in one or more class diagrams I tend to think in

- Sequence diagrams constructing and showing
- - UML(!)-Interfaces promising behaviour by providing method signatures to be realized later.

- Component diagrams showing
- - these interfaces and
- - components planned to realize these interfaes (this way component diagrams no longer are just implementation diagrams)

- Class diagrams showing
- - classes realizing
- - - one big or
- - - several somehow related components
- - the set of interfaces provided by these components

The order of constructing these diagrams is not fixed. Maybe we start with a raw Class diagram (similar to the BDM), use its classes in Sequence Diagrams (hopefully the tool is good enough to reflect changes back to the Class diagrams too). As soon as it becomes more complex (or from the beginning ...) we add all the found interfaces to a Component diagram, re-think which component and which class in which component should realize which interface, and so on, iteratively.

If working this way the number of Class diagrams does not matter nor wether they belong to Sun's BDM or to a more technical view of the system to be designed.
We should design as we would in real life.

Thomas
[ June 08, 2006: Message edited by: Thomas Taeger ]

www.classic-and-class.com - www.evalulearn.com
Interfaces are the glue of OO.
suekar meredilko
Ranch Hand

Joined: Mar 27, 2006
Posts: 153
thanks. Got your point !!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: class diagram and sequence diagram