[Modeling] Interaction diagrams review

[Radovan Cervenka]

Dear all,

I'm sorry for this relatively late reaction to interaction diagrams
proposal, but I have been very busy with my work since the beginning of this
month and I have had no time to think about the problem and to join the
email communication. But now I'm ready to give some input. In this mail I'd
like to discuss just some general observations.

___UML___

1. Remark about UML 2.0 (03-03-03): This version of UML Superstructure
document is little bit inconsistent, incomplete and several mistakes could
be found there. It is relatively difficult to work with the UML 2.0
metamodel and notation definition, if text describing metaclasses is
inconsistent with pictures, text do not use the same names for the same
modeling elements at different places, "TBD" or similar notes appear at
several places, OCL is almost missing in specification of constraints, some
notation is not properly (or not at all) described, notations of some
elements are distributed over the whole document, etc. I do not want to go
into details now, because our job is different... but we will see these
problems when AUML goes into details of specifying metamodel and UML
profile. UML 1.4 was of better quality. I would wonder if OMG approved this
UML 2.0 document. But I hope that people at OMG are working on newer
version(s).

___AUML___

2. After closer look at the FIPA Modeling: Interaction Diagrams document I
observed that it says almost nothing new, comparing to UML 2.0
Behavior::Interactions section. The language defined there, is almost whole
described in the UML Superstructure. The only new things are:

* idea of "multi object" (multi role/agent/...) for Lifeline - I wonder why
UML 2.0 does not use it, if in UML 1.* it worked perfectly e.g. for
multicasting,

* detourment of lifeline and role changing - unfortunately the notation
coincides with concurrent lifeline from UML 1.* and it does not respect the
fact that one agent can play more roles in one interaction at once.
Fortunately, there is an alternative solution available in UML: two
lifelines can have the same name, but different Classifiers. It means: one
agent can play different roles (if a role is represented by Classifier).
Messages can then touch a Lifeline with proper role. By this, it is not
necessary to show role changing. But if needed, a StateInvariant can be
placed at a lifeline to say that an agent changed the role.

* blocking constraint - looking at the UML Metamodel I'd say that blocking
constraint will become a special StateInvariant in AUML profile. I expect
exactly the same using and principal notation of both elements. Just an icon
can be different or blocking constraint will be stereotyped by a label (e.g.
<<block>>).

* triangle near continuation label - I could not find this notation in UML
Superstructure. But it is just a small improvement, that is not really
necessary - UML uses the setting metaattribute and recognizes its different
values by putting the Continuation either at the beginning or at the end of
the CombinedFragment.

New AUML modeling constructs represent just minor improvements to UML
interaction modeling. I see the Interaction Diagrams document just as a
description how to use UML to describe agent-specific interactions. But it
does not define new specialized language for agent-specific interaction. We
could hardly draw its metamodel and UML profile. It is not wrong at all!!!
At least we can say that UML 2.0 is more-or-less sufficient for AUML
purposes.

3. Some terms used in the document do not match UML terms and sometimes are
not used precisely. E.g. interaction protocol is called Interaction in UML,
role is usually used to reference to a collaborationRole (from
Collaborations package; Lifeline does not define a role in Interaction),
protocol template from AUML represents Interaction with formal parameters
(no special name is used), and AUML timing constraint probably represents an
equivalent to TimeConstarint, DurationConstraint and IntervalConstraint
respectively (???). We could think about (at least partial) re-using of
terms from UML, or at least we can define some unambiguous mapping of AUML
and UML terms/modeling elements. I can imagine that OO people, who
understand UML, will wonder why AUML defines new names for already defined
concepts form well-known UML. ...

4. I think about representing of IP by a Collaboration that contains one or
several related Interactions. CollaborationOccurense offers a nice graphical
notation for mapping of collaboration parameters to actual parameters. AUML
could extend the notation and semantics of parameters also to contained
messages, interaction constraints, etc.

5. Question: is it sufficient to represent FIPA communicative act by
"normal" UML Message? Is it sufficient to have a message name and a list of
parameters? How could be parameters mapped to the ACL message elements.
These questions were not addressed by the document.

Now, I'm going to put my detailed comments directly into the Interaction
Diagrams Word document. I'll also try to go through all of your comments and
mails from FIPA Modeling mailing list ... WUFFF!!! more than 60 mails and 12
document responses...

Regards,

Rado1.
--
Radovan Cervenka | rce@whitestein.com
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5443-5502 | Fax +421(2)5443-5512
--
If you are not the intended recipient of this email,
you are not authorized to make any use of it;
please delete it and notify us by return email.
Thank you.