RE: [soa-rm-ra] revised section 4.3

[Peter F Brown <peter@peterfbrown.com>]

Ken,
Only just seen your mail. I had hoped to do a further short note today but to no avail. I'm in a conference all day tomorrow but could call you first thing Tuesday so that we can iron these points out....
Cheers,
Peter

Peter F Brown
Independent Consultant
www.peterfbrown.com
Twitter @PensivePeter

Sent from my phone - Apologies for brevity and typos: it's hard writing on a moving planet

---

From:
Ken Laskey
Sent:
22-Jan-12 17:27
To:
Peter F Brown; 'Rex Brooks'; 'Michael Poulin '
Cc:
jeffrey.a.estefan@jpl.nasa.gov; 'Thornton, Danny R (IS)'; ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject:
RE: [soa-rm-ra] revised section 4.3

Peter,



I still need to read the entirety of your comments below with more care and
in more detail but there are a few things that have a feel of being broken.



-          At one point below you say, "the UML construct 'Actor' would also
apply to other roles played by people wrt the ecosystem and social
structures (notably 'Participant' and 'Stakeholder', " but we also have
Actor as only participating through the SOA-based system.  There now seems
to be a connection between Actor and Stakeholder that we didn't have before.



-          The initial introduction of Person for Participant is reasonable
but the later substitution throughout section 3 gets to be a problem.  Our
guide for using Stakeholder vs. Participant vs. Actor is the two paragraphs
after the definition of delegate just before section 3.1.2: 



o   actor <>  is used when it is not important whether the entity is a
delegate <>  or a participant <> 

o   If the actor <>  is acting on behalf of a stakeholder, then we use
delegate <> 

o   If the actor <>  is also a stakeholder <>  in the ecosystem, then we use
participant <> .

-          As noted, you "avoid modelling 'Participant is-a Stakeholder AND
is-a Actor' (former figure 4)" but the text continues to make significant
use of Participant.  However, Participant no longer appears in any of the
models and seems especially lacking from Figure 5. If we decide "Person
participating" is preferable, there are a lot of changes that need to filter
through. 

-          One existing glitch I noted in this vein is the definition of
Delegate is when "acting on behalf of a participant <> " but the next
paragraph says, "automated agents are always delegates, in that they act on
behalf of a stakeholder." By our previous models, it latter should be
Participant.



To Michael's question about Activity, we introduce the concept with a
paragraph and a diagram but don't seem to make use of it otherwise.  I can
see noting this in the appendix where we talk about coordinating with the
SAIF CD work and possibly even formalizing it in section 4.3. Do we plan to
go further and, if so, how do you propose we proceed?



I need to deal with some things around the house and will study this further
before Wednesday.  But any further clarification would be appreciated.



Ken



P.S. I think Rex's "blue man" reference was the rough orchestration diagram
I put in the revision to section 4.3.  I don't mean that exact diagram to be
included but I put it in as a placeholder to see if we thought it is worth
further consideration.



---------------------------------------------------------------------------

Dr. Kenneth Laskey

MITRE Corporation, M/S H305              phone: 703-983-7934

7515 Colshire Drive                                    fax:
703-983-1379

McLean VA 22102-7508



From: Peter F Brown [mailto:peter@peterfbrown.com] 
Sent: Wednesday, January 18, 2012 2:45 PM
To: Rex Brooks; Michael Poulin (mpoulin@usa.com)
Cc: Ken Laskey; jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS);
ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] revised section 4.3



Rex, Michael

I fully understand both your concerns - let me see if I can address them:



We state in Section 1.3.2 that "Normative UML is used unless otherwise
stated but it should be noted that it can only partially describe the
concepts in each model - it is important to read the text in order to gain a
more complete understanding of the concepts being described in each
section."

Yes, I have used the 'normative' UML construct for 'Actor' while trying to
fit its use, by us, in the 'realm' of the system and not extend it to the
'only-human' world of the social structure and ecosystem, where I stick to
using 'Participant' and 'Person' as appropriate.



I admit there is one potential problem and cause of confusion, if we stick
to the following train of logic:

-          IF the UML construct 'Actor' is used, in canonical UML, to
represent any role that a user can play with regard to a system;

-          And IF our concepts of 'ecosystem' and 'social structure' could
be understood and modelled as UML systems (Zoran Milosevic's comment and
interpretation of RM-ODP);

-          THEN, the UML construct 'Actor' would also apply to other roles
played by people wrt the ecosystem and social structures (notably
'Participant' and 'Stakeholder')

Technically that is correct but I don't think that this interpretation, if
applied, would 'break' our model. In the new diagrams I have been very
careful and explicitly sought to avoid modelling 'Participant is-a
Stakeholder AND is-a Actor' (former figure 4).



I'm not sure I understand the reference to "blue man diagram", so I'm
assuming it refers to the UML Use Case diagram (figure 6) on line 726 of the
20120117 edition. I'd be happy for someone to make this canonical, if it
isn't - I had intended that it was. It contains Actors (understood very
widely), Use Cases and a main flow of events consistent with the text that
follows. In the caption I also state that "each role is represented using
the UML stick figure for an actor"



Michael is right that in my fig 5, "Actor does not contribute (via feedback)
into the social structure" - but, it never did. The relationship previously
was modelled as "a Participant contributes to a Social Structure". I have
that modelled now as "Person contributes to social structure" (Participation
is the role that the Person plays in that relationship). 'Actor' is still
modelled as a class, albeit an 'association class' (although not clear in
the sketch) defining the role played by a Person in any Action - which I
think is correct.



The problem arises because I have used the UML stick-figure in Fig. 6 to
model different 'things' (Analyst, Service Owner, Service Provider, Service
Consumer and Stakeholder), all of which in UML are Actors. The easiest way
to solve this would be to remove <<person>>Stakeholder from the left-hand
side of the diagram - I had only modelled Stakeholder and Consumer
separately to distinguish between the system-level actor (Service Consumer)
and the real-world flesh-and-blood stakeholder (expressing needs and seeing
them fulfilled) but it wouldn't kill the model to remove Stakeholder and use
only Consumer on the left. But we are then left with a 'Consumer' expressing
needs, which is what we did not want. Can we represent Stakeholder in any
other way and this still remain a Use-Case diagram? I don't like the idea of
modelling this as a workflow (if anything, it is probably closer to a Value
Chain or Value Network) but happy to see what you can come up with, Rex.



I also wonder if we should just dump the lines containing the definition of
'Role", particularly as we use it far more extensively than just to model
relationships with Person or Delegate within a social structure.



We could also add an explanatory statement after the definitions of
Stakeholder, Actor, Participant, Non-Participant and Delegate.



In UML, Stakeholder and Participant could both be modelled as Actors if the
whole ecosystem, as defined, were also to be considered as a 'system'.
However, the distinctions between the SOA-based system, the broader
Ecosystem and the roles played in and by Social Structures, are all
important distinctions for this work. 'Actor' is therefore only used in the
context of the System and specific roles played in the wider Ecosystem are
represented by Stakeholder and Participant as appropriate.



In 3.2.3, the figure is explicitly not an activity diagram: in the caption,
I state that Activity is "expressed informally as a graph of Actions, with a
single Start point and alternative End points". I am trying to make the link
between the valid RM-ODP definition of Activity, without having to define it
ourselves. Yes, Michael is right that our concept of Joint Action is a type
of Activity, formally speaking. But I deliberately chose not to open that
can or worms and use the RM-ODP definition for illustrative purposes - the
idea of an activity being an acyclic graph of actions is particularly useful
I think in getting to grips with issues around orchestration, choreography
and composition, as a graph of actions does not assume nor preclude specific
ordering, branching, forking, etc.



Hope this helps,

Peter



Peter F Brown

Independent Consultant

www.peterfbrown.com

P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.310.694.2278



From: Rex Brooks [mailto:rex.brooks@ncoic.org] 
Sent: Wednesday, 18 January, 2012 07:55
To: Peter F Brown
Cc: Ken Laskey; jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS);
ellis@deccs.com; soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] revised section 4.3



Haven't had time and health to review thoroughly, but I thought we had
agreed that we would make it clear in our discussion of UML as a
communication v. modeling tool that our definition of actor is significantly
different from that used for UMLUse-Case diagrams. Hence we should either
reiterate that in the text around the blue man diagram or else make it a
canonical UML use case, which it resembles just enough to cause confusion,
or else use some other diagram, such as as BPMN workflow to show workflow.
However, without a previous use of and explanation of that kind of diagram,
that would actually be worse. So I would use Visio and make it a purely
informational diagram without any reference to UML, nor any possiblity of
confusion over the use of "Actor." If I can find the time, I will actually
do that so that it is clear what I mean. Of course, that's not possible in
the 35 minutes left before the meeting.

Cheers,
Rex

On 1/16/12 6:59 PM, Peter F Brown wrote: 

Hi,

OK, here is the Gold Copy returned, with filename incremented.

The main changes compared with Ken's send out of a few hours earlier are:

Section 3.1.1 - clarification of term "Actor" to make it compatible with the
UML construct of the same name (useful for our purposes and for the
modelling that follows);

Update of fig 5, to include Activity;

Section 3.1.2.1 - moved fig 6 below role definitions: fits better with text
that follows regarding needs, requirements, capability, etc that also appear
in the use case of fig 6;

Section 3.2.3 - introduce 'Activity' (using RM-ODP definition) and new
(informal) diagram and clarification of our use of 'Action' and 'Activity'
(normative reference to RM-ODP has also been added to section 1.6.1)



Cheers,

Peter



Peter F Brown

Independent Consultant

www.peterfbrown.com

P.O. Box 49719, Los Angeles, CA 90049, USA

Tel: +1.310.694.2278



From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org]
On Behalf Of Ken Laskey
Sent: Monday, 16 January, 2012 16:18
To: soa-rm-ra@lists.oasis-open.org
Cc: jeffrey.a.estefan@jpl.nasa.gov; Thornton, Danny R (IS); ellis@deccs.com
Subject: [soa-rm-ra] revised section 4.3



I've incorporated all adjudicated changes to section 4.3 and attempted to
capture consensus in some original material appearing in section 4.3.4 to
the end.  I am hoping for a continuation of the agreeability over the past
few days and everyone will be happy with the changes; at the least, I am
hoping for an acceptable balance among everyone's remaining unhappi

[The entire original message is not included.]