[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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] 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 P.O. Box 49719, Los Angeles, CA 90049, USA Tel: +1.310.694.2278 From: Rex Brooks [mailto:rex.brooks@ncoic.org] 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. 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 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 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 unhappiness. Take a look and start the discussion. I’d like nothing better than to have this resolved before Wednesday’s call. Ken --------------------------------------------------------------------------- Dr. Kenneth Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508 ---------------------------------------------------------------------To unsubscribe, e-mail: soa-rm-ra-unsubscribe@lists.oasis-open.orgFor additional commands, e-mail: soa-rm-ra-help@lists.oasis-open.org |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]