Re: Polymorphic UML sequence diagrams



Re: Polymorphic UML sequence diagrams

From: Vladimir Mencl <mencl_at_nenya.ms.mff.cuni.cz>
Date: Thu, 19 Oct 2006 12:08:38 +1300
Message-ID: <4536B3F6.8040500@nenya.ms.mff.cuni.cz>
On 10/19/2006 05:09 AM, Andrea Baruzzo wrote:
> 
> On 10/18/06, Robert France <france@cs.colostate.edu> wrote:
>> Not sure what you mean by a "polymorphic ... scenario". Can you give a
>> more descriptive example? Do you want the lifelines to be roles that can
>> be played by different instances (not necessarily of the same class)?
>>
>> Or are you trying to model program-level polymorphic calls?
> This one. I try to describe a general scenario in which an indefinite
> number of instances of derived classes execute the same method
> (without mention explicity all of them in a sequence diagram as single
> instances).  Consider the classical example concerning a list of 25
> geometrical objects. I want to show a scenario in which, *for each of
> them*, I play the method draw().

Hi,

I think this is possible with UML2.0(+) Interactions.

The situation you are describing consists of two issues: calling 
delivering a single call to multiple objects, and having a polymorphic 
collection of descendants receiving the calls.

For the first part, UML allows you to have a Lifeline representing a 
_multivalued_ structural feature of the classifier (e.g., a collection 
association).  Here, UML says that "arbitrary representative of the 
multivalued ConnectableElement is chosen." (pg 511 of ptc/06-04-02), but 
you can also provide a _selector_ expression to choose the correct element.

This, combined with a _loop_ CombinedFragment, allows you to iterate over 
the whole collection association.

As for polymorphism - there are no restrictions explicitly mentioned, and 
an instance of a subclass should be usable in a collection typed by its 
ancestor.  Hence, the problem you described should be solvable this way.


Cheers,
Vladimir




> 
> My hidden goal is to reason about the compliance of a such scenario
> with respect to the Liskov substituibility principle, provided the OCL
> specifications for the Shape hierarchy classes. (Shape is only an
> example). It is possible to reason about this issue even only at
> textual level, considering the class diagram for class definitions,
> and the OCL specifications as class contracts. But considering that
> LSP describes (indirectly) a dynamic scenario, I would expect to see
> also some sort of sequence diagrams to describe this situation, so I
> am reasoning about the sequence diagram's expressive power.
> 
> 
> Andrea
> 
Received on Thu 19 Oct 2006 - 00:09:03 BST