[Modeling] Feedback on the latest draft interaction diagram spec.

[Stephen Cranefield]

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
  document.

* 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
  with UML.

* 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
  "agent-identifier" terms:

  (inform
          :sender (agent-identifier :name agent1)
          :receiver (set (agent-identifier :name agent2))
          :content "((price good 100))"
          :language fipa-sl
          :ontology auction
  )

* 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.)

Regards,
Stephen

----------------------------------------------------------------------
Stephen Cranefield                       
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: scranefield@infoscience.otago.ac.nz
----------------------------------------------------------------------