[Modeling] interaction diagrams
Fri, 21 Mar 2003 11:14:57 -0500
Radovan, I think you missed the point. That document, as I understood, is
not suposed to be the final but rather the start stone for our
modifications, this is probably why it looks like so much to UML 2.0.
Jim, correct me if I'm wrong!
>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.
>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
>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
>* 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.
>* 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
>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
>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
>Radovan Cervenka | firstname.lastname@example.org
>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.
>Modeling mailing list
Intelligent Automation, Inc.
7519 Standish Place, ste 200
Rockville, MD 20855