[Modeling] Feedback on the latest draft interaction diagram spec.
Tue, 03 Jun 2003 23:07:17 +1200
Here is some more feedback on the latest version of the interaction
diagram specification. Sorry for not sending these comments earlier.
* "Protocol frame" seems to be too specific a name for the box around
a sequence diagram. A sequence diagram is useful things other than
defining interaction protocols, e.g. illustrating snapshots of agent
interactions, and it would be odd to have to use the term "protocol
frame" for a diagram that doesn't define a protocol.
* It would be good to clarify the syntax used for parameters. It is
stated in Section 2.1.3 that parameters can be prefixed by the names
of the corresponding template parameters, but it doesn't say clearly
that the format is "name value" rather than (say) "name:value" or
"name=value". Also, the parameter names to be used for specifying
the ontology, ACL and content language should be defined in this
* The FIPA abstract architecture allows a message to reference
multiple ontologies, and FIPA ACL does too (the value of the
ontology field is an expression not a constant - see
http://www.fipa.org/specs/fipa00070/SC00070I.html - but the use of
this to specify multiple ontologies is not defined yet). The
Agentcities community have discussed the use of SL set or list terms
in the ACL ontology field together with the use of XML namespaces to
allow terms from multiple ontologies to be used in a message. In
the light of all this, I think AUML should allow multiple ontologies
to be associated with a sequence diagram. In the absence of any
standards for this yet, we could just say that the ontology
parameter is a text field that may be the name of an ontology or an
expression that represents a set of ontologies together with other
information such as namespace prefix definitions.
* UML 2.0 allows an interaction to define local attributes (see Figure
8-148, page 380 in the UML 2.0 superstructure spec.). This would be
useful for AUML as interaction protocols might have local state,
e.g. who the current chair is in the UN Security Council example, or
whether the state of a contract is agreed or not agreed.
* Section 2.2.1 mentions groups several times, but the concept of
group has not been defined or introduced before it is used.
* I am uncomfortable with the use of the term "dynamic classification"
to describe the operation of changing state. I would use this term
to mean the possibility of objects changing state dynamically, but
not the changing action itself (the word "classification" seems to
need another party that is doing the classification).
* The end of the second paragraph in Section 2.2.1 says that role
dynamics are not addressed in the sequence diagram, but this is not
true - a notation for state changes is discussed later.
* Why do role names need to be underlined? This doesn't seem to add
anything to the notation. Instead of requiring underlining, instead
it could be compulsory to include an initial ":" if using a role
name alone as the label on a lifeline. This would be in accordance
* It might be clearer to use a different sort of line for role
changing, e.g. a dashed line. This would make them look more
visually distinct from messages.
* There are stereotypes for changing and adding roles. Why isn't
there one for deleting a role too?
* The syntax for the FIPA ACL message in Section 2.3.1 is incorrect.
The content is a tuple, so even if there's only one expression, you
need an extra set of parentheses. To be consistent with the
examples in the FIPA Communicative Act Library you there should also
be double quotes around the content. The language parameter should
use the official value for FIPA SL: fipa-sl. Finally, the receiver
parameter should be a singleton set, and for consistency with the CA
library spec, the agents should be referred to using
:sender (agent-identifier :name agent1)
:receiver (set (agent-identifier :name agent2))
:content "((price good 100))"
* Section 2.6.1: For the Consider and assertion operations it is not
clear to me what it means for an agent to "consider" a message or to
"not accept" one. In the latter case should it send an error
message in response?
* UML 2 allows an abbreviation in the use of combined fragments: more
than one operator can be shown in the corner pentagon of a frame,
e.g. "sd strict" (see page 389 in the UML 2 spec.). This is useful
because if an interaction has multiple interaction fragments
(representing message ends and nested combined fragments) then the
semantics declare that the weak sequencing operation is used to
combine the sets of traces of the fragments to form the traces of
the overall interaction. Writing "sd strict" provides a compact way
of getting strict rather than weak sequencing - otherwise the frame
must contain an intermediate combined fragment that uses the
"strict" operator to combine the required message ends, etc.
* Representing actions: I don't see the need to introduce a new symbol
for actions (a rectangle with double vertical lines). UML 2 already
has two notations for associating actions with message ends (using
the ExecutionOccurrence metaclass - see page 376). You can either
use thin rectangles on the lifeline (like activitions in UML 1) or
the action symbol from activity diagrams (rounded-corner rectangles)
with associations linking it to start (and possibly) finish events
on the lifeline. In the former case, the UML 2 spec. doesn't seem
to say if you are allowed to name the action on the diagram.
In fact, the notation for writing "t = now" beside a message end is
a special example of including an action in a sequence diagram
(although the rounded-corner box isn't used). In UML 2 an
expression of this form is an instance of the metaclass
TimeObservationAction (see Figure 7-135 in the UML 2 spec.)
Department of Information Science
University of Otago Phone: 64 3 479 8083
PO Box 56, Dunedin Fax: 64 3 479 8311
New Zealand E-mail: email@example.com