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 ]
