RE: (ROSE) Re: How To write in the Sequence Diagram

[Angay, Huseyin (Huseyin)** CTR **]

> ----------
> From:         Peter Lindgren[SMTP:[EMAIL PROTECTED]]
> Reply To:     Peter Lindgren
> Sent:         15 November 2000 16:10
> To:   '[EMAIL PROTECTED]'
> Subject:      Re: (ROSE) Re: How To write in the Sequence Diagram
> 
> 
> "Angay, Huseyin (Huseyin)** CTR **" wrote:
> > 
> > > From:         Peter Lindgren[SMTP:[EMAIL PROTECTED]]
> > >
> > > krishna srinivasa wrote:
> > > >
> > > > I would like to know how to depict this in rose 98 -
> > > > sequence diagram.
> > > >
> > > > i work in vb
> > > > i have an interface class.
> > > > i have the implementing class.
> > > > the implementing class has private functions
> > > > implementing the interface.
> > > > the implementing class is a public class.
> > > > should i show (the implementing class)?
> > >
> > > Yes you show only the implementing class and
> > > not the interface class, since a sequence
> > > diagram shows instances (objects), not classes.
> > > The fact that your implementing class
> > > implements an interface is showed in a class
> > > diagram.
> > >
> > Actually, it is valid to show interfaces in Sequence Diagrams, but you
> have
> > to have a reason for doing it.
> > 
> > (1) The calling class is the focus:
> > Show the calling class, the interface. The calls are between caller and
> the
> > interface. Also put a note on the diagram to say that the interface
> > implementer does something in the background.
> 
> If you mean that the calling class makes calls to an interface,
> without caring what implementation it is, I accept your point.
> 
THat was exactly the point.


> But then you are not showing a real scenario in your diagram,
> you are modelling some kind of "general scenario" -- a pattern
> maybe.
> 
Scenarios, too, have their level of abstraction. Your diagram will stop
illustrating the sequence at one point below which we do not care what
happens.
For instance, when we illustrate component-level interaction, we avoid
showing the calls between classes inside the component. In the same spirit,
when we do not care who implements the interface, we still have a scenario
the focus of which is how the caller obtains the information that it needs,
ignoring how the called gets that information.


> Suggestion:
> Create an object called <<yourpatternname>> Implementor that
> implements the interface, and put this object in the sequence
> diagram.
> 
The intention, in fact, is not to show a pattern. It is to show why the
instance under focus is doing some things.
The pattern comes later.


> N.B. "Implementor" isn't the best name,
> "HumHumInterfaceImplementor" tells the reader that is has
> something to do with the "HumHum" things. Discussion is
> welcome.
> 
> > (2) The implementing class is the focus:
> > Show the implementing class's instance and the instances/interfaces that
> it
> > calls. The caller is probably some faceless (i.e. classless) instance so
> > that we can have an originating class for the message.
> 
> In VB, an Interface is in its nature a little like an abstract
> class -- it cannot be instantiated.
> But since the implementing class is in the focus, place an
> instance of the implementing class and send the messages to
> it. It's a scenario, so we know what instances it will be.
> 
> > (3) You are illustrating a pattern:
> > That's the hard bit. You need to show both the interface and its
> > implementation. I got round this until now by showing the implementing
> > class's instance and a note saying that it implements an interface. I
> > welcome a better suggestion.
> 
> What about my suggestion above?
> 
It's fine for showing who does what, but will not illustrate why things are
happening that way.
One of the most important elements of a design pattern is the clever use of
polymorphism and interfaces. When you strip those out, you end up showing
the implementation but you don't capture why that implementation really
works well.
The solution that I apply uses the same principle as yours. You rely on the
name, I rely on a note. Both solutions get close, but I don't think they
illustrate the point well enough.
As an example, try illustrating the Template pattern (parent class dictates
the sequencing of operations that produce the overall result; the subclasses
implement the specific variations for the operations): if you know the
pattern, the diagram's pretty straightforward to follow and understand; if
you don't know it, you are not any more enlightened than before.
Things get even hairier with patterns like Strategy that rely purely on
polymorphism. THere is no code in the parent class (so you can't even show
the parent).

Anyway, that last point's probably more theoretical than real. Most patterns
need further explanation in text somehow.

Regards,
Huseyin


> /Peter
> -- 
> Peter Lindgren                             Bachelor of Computer
> Engineering
> ERIEYE C2 Software Design
> http://www.ericsson.com/erisoft
> Get your own AWACS:
> http://www.ericsson.se/microwave/2-Products/erieye.asp
> --- Opinions above, expressed or implicit, are my personal opinons only
> ---
> ************************************************************************
> * Rose Forum is a public venue for ideas and discussions.
> * For technical support, visit http://www.rational.com/support
> *
> * Admin.Subscription Requests: [EMAIL PROTECTED]
> * Archive of messages:
> http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
> * Other Requests: [EMAIL PROTECTED]
> *
> * To unsubscribe from the list, please send email
> *
> * To: [EMAIL PROTECTED]
> * Subject:<BLANK>
> * Body: unsubscribe rose_forum
> *
> *************************************************************************
> 
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages: 
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************