[Modeling] RE: Comments on interaction diagram modeling

[Marian Nodine]

This is a multi-part message in MIME format.
--------------539FDB847B1F6B655EFBE6FF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well, I think actually we have several issues here. The first is the
communication issue. In this case I think there are three roles -- (1) the
security council entity, (2) the proposer, and (3) the responder. In this
interaction:
a. The proposers submit the proposal to the security council.
b. The security council forwards the proposal to the responders, setting the
deadline.
c. The responders respond to the security council with a vote.
d. Optionally, the result of the vote is communicated to the proposers and
responders.

The second issue has to do with who can fill the roles in the interaction. Note
that many forms of voting can follow the above interaction, and the distinction
between them is in constraints such as who can fill the role. In the described
protocol, the role constraints are as follows:
Security council -- There is one of these. It must be the legal entity
designated as the security council. It must be able to set the deadline and
tally the votes according to the approved procedure -- if the majority of the
members voted FOR, and no permanent member voted AGAINST, then the proposal
becomes a resolution; otherwise, it does not. It must know who the members are,
and whether they are permanent or not.
Proposer -- There may be one or more of these. All of them must be members of
the UN security council. They must be able to submit the proposal according to
the required procedures.
Responder -- All members of the UN security council must be responders. This
includes the proposers. They must be able to respond according to the required
procedures.

To my mind, the first issue is defined at a more abstract level than the second
issue. I am not sure how this fits in with interaction protocols -- I would be
inclined to say that interaction protocols cover the first issue. The issue of
role assignment should be covered at more of an implementation level.

-- Misty


"Dr. Hong Zhu" wrote:

> Hi,
>
> Sorry for joining the discussion so late. Reading the emails passed around,
> I feel that there are a lot of issues involved in the discussion. However,
> the most important thing is what are the 'requirements' of such an
> interaction diagram and whether the current version meets the requirements.
>
> Let's have a more concrete example and see how interaction diagram to
> represent a protocol. Consider the procedure that UN security council passes
> a resolution. It seems the protocol consists of the following steps:
>
> (1) At least one member of the security council submit a proposal;
> (2) By a given date that the council members all agreed, a vote from the
> members must be made;
> (3) Each member of the security council can vote either FOR or AGAINST or
> SUSTAIN;
> (4) The proposal becomes a resolution of UN security council's resolution,
> if the majority of the members voted FOR, and no permanent member voted
> AGAINST.
>
> Here, we have two castes (i.e. agent types): One for security council
> members and one for permanent members. Agents of these two castes are
> autonomous, but they together form another agent - UN security council.
>
> Can we represent this protocol in the interaction diagram?
>
> Best regards,
> Hong
>
> ----- Original Message -----
> From: "Wagner, G.R." <G.R.Wagner@tm.tue.nl>
> To: "'Renato Levy'" <rlevy@i-a-i.com>; <modeling@fipa.org>
> Sent: Thursday, March 20, 2003 9:44 AM
> Subject: RE: [Fwd: [Modeling] Comments on interaction diagram modeling doc]
>
> > >> protocols are both a design specification tool, but also a
> > >> standardisation mechanism. We may need to address these 2 uses
> > >> separately?
> >
> > > This is precisely the point for the definition of level of
> > > abstraction of the design document.
> >
> > It's not really about the "level of abstraction" but rather
> > about the purpose of the model: standard interaction protocols
> > correspond to domain models which you may transform into
> > design models (by enriching/refining them). The OMG also
> > calls these two different types of models "Computation-
> > Independent Model (CIM)" and "Platform-Independent Model
> > (PIM)" in their Model-Driven Architecture approach.
> >
> > -Gerd
> > _______________________________________________
> > Modeling mailing list
> > Modeling@www.fipa.org
> > http://fipa.org/mailman/listinfo/modeling
>
> _______________________________________________
> Modeling mailing list
> Modeling@www.fipa.org
> http://fipa.org/mailman/listinfo/modeling

--------------539FDB847B1F6B655EFBE6FF
Content-Type: text/x-vcard; charset=us-ascii;
 name="nodine.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Marian Nodine
Content-Disposition: attachment;
 filename="nodine.vcf"

begin:vcard 
n:Nodine;Marian
tel;work:512-478-8923
x-mozilla-html:FALSE
org:Telcordia Austin Research Center
adr:;;;;;;
version:2.1
email;internet:nodine@research.telcordia.com
title:Senior Research Scientist
x-mozilla-cpt:;23928
fn:Marian Nodine
end:vcard

--------------539FDB847B1F6B655EFBE6FF--