[Modeling] Feedback on the latest draft interaction diagram spec.
Marc-Philippe Huget
M.P.Huget@csc.liv.ac.uk
Wed, 02 Jul 2003 16:41:46 +0100
Hello all,
Thanks for your comments, here are some answers and how I corrected the
specification
Stephen Cranefield wrote:
> 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.
Agreed. Jim told me more or less the same thing, I propose to keep UML 2
name since it is a convenient one, now protocol frames are called
interactions.
> * 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.
Agreed. Now parameters are written as follows: name = value, did the same
for ontologies, ACL and content language
> * 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.
Modified.
> * 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.
That's right, this part is missing, it is now added as proposed in UML2
> * Section 2.2.1 mentions groups several times, but the concept of
> group has not been defined or introduced before it is used.
One small definition is included now
> * 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).
Normally, it is the term used in UML 2 (Jim, correct me if I am wrong),
it is the reason I use it. I think the motivations behind this term is to
represent roles by their class, a taxonomy, explaining why we have the
term 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.
Actually, the role dynamics are not addressed in this specification since
role dynamics cover more elements such as constraints on role addition
and deletion, if some roles are incompatible at the same moment, etc.
These issues will be addressed by a specific diagram
> * 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.
Updated all figures, underlining was a souvenir of AUML 1
> * 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.
Done
> * There are stereotypes for changing and adding roles. Why isn't
> there one for deleting a role too?
Er... let's say I consider that a lifeline that has no more messages is
stopped and as a consequence the role is removed, it is the reason we
have no stereotype <<delete role>>, do you have any counterexample?
> * 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
> )
Oops! Fixed
> * 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?
Actually, I have the same problem but for sake of completeness, I add
them, now if nobody understands them or finds good examples, maybe we can
omit them
> * 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.
I don't understand this point, where do I make an error in the
specification?
> * 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.)
Totally right, I changed for the UML 2 Actions.
The new specification will be uploaded soon to the AUML site
Cheers,
Marc-Philippe
--
Marc-Philippe Huget
Agent Applications, Research and Technology Group
Department of Computer Science
University of Liverpool
Chadwick Building, Peach Street
L69 7ZF Liverpool
United Kingdom
email: mph@csc.liv.ac.uk
http://www.csc.liv.ac.uk/~mph