Legacy Issue Number: 15421
Source: Simula Research Laboratory ( Bran Selic)
In section 14.4 that describes Interaction diagrams, there are statements describing interaction overview diagrams that is highly misleading and which, in my consulting experience with numerous UML users, have been the source of much misunderstanding:
"Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions"
as well as:
"Interaction Overview Diagrams define Interactions through a variant of Activity Diagrams"
While there is indeed syntactic similarity between the two forms (e.g, with fork and join nodes), the underlying semantics between the two diagrams are quite different. For instance, activities, by definition, fully complete their execution before passing control/data tokens to their successors (as defined by the token passing rules), whereas this does not hold in general for interaction uses (the blocks in an overview diagram). In fact, while one object/lifeline could still be completing its business in one interaction use block (so to speak), its collaborating peer could already have entered a successor block. That is, in general, there is no implicit synchronization between lifelines when entering and exiting the blocks in an overview diagram. (Far too many users assume this type of synchronization, resulting in erroneous or unimplementable model specifications.)
There are numerous other semantic differences between Interactions and Activities (e.g., the latter include the notion of pins, control and data flow tokens, etc., while the former do not have any such notions), which further invalidate the claim that one is a special variant of the other. Finally, the metamodels underlying the two diagrams are completely different To summarize: Interaction Overview diagrams are NOT a specialization or variant of Activity Diagrams.
The solution to this problem is not just to remove the two misleading statements, but to also add an explanation that explicitly points out the differences between the two, so that readers are not misled by the similarity in notations.
Reported: UML 2.5 — Thu, 19 Aug 2010 04:00 GMT
Updated: Wed, 28 Jun 2017 17:20 GMT