OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Return of Gold Copy - version 20111227


Ken,

Attached is the Gold Copy returned incorporating my suggested dispositions for sections 1 thru 3 (in practice, section 3 only) and issues spreadsheet updated.

 

In the word document, I’ve called out all changes as comments indicating issue number addressed.

In the Excel spreadsheet, I have included the rows from the sheets that cover the issues that I have addressed and have changed, no others, for clarity.

 

Some comments:

I’ve tried to limit my changes to those strictly necessary to respond to the issues raised. However, in order to achieve that coherently, I have had to eliminate any phraseology that could lead to modelling problems (such as circular “x is a y”…”y is an x” definitions). This was particularly true around the use of “participant”.

Secondly, I try to recognise and reconcile that in some parts of the text a concept may appear as a class and elsewhere as a role in an association. Rather than trying to model the whole thing (potentially with nested association classes), I’ve tried to keep it simple and describe our concerns more tightly.

In 3.1., in line with Zoran’s comments, I have removed most references to “participant” as a concept but talk only of person/people and use the verb “participate” when necessary and only introduce “participant” later on as a distinct entity class. I think that RM-ODP (particularly in ISO 15414, rather than the more general ISO 10746) does a first class job of modelling and that we could have used more of earlier <sigh/>. However, I am not convinced that RM-ODP goes beyond modelling systems and it tends to model everything ultimately (including a community) as a system – which I think is a bit reductionist.

In 3.1.1., I introduce more succinctly the concepts of stakeholder, participant, actor and delegate.

We already describe “Participant” as a “hybrid role” rather than as an object class – I struggled with this a lot and my conclusion is indeed that “participation” is inextricably bound to the specific role being played by a person at a particular time – in our models we imply that a participant is both a stakeholder and an actor, which leads to modelling problems. Seen as a behaviour rather than an intrinsic property of a person, I think it is easier to sustain the idea of “participant”/”participation” being temporally bound and thus not having the required characteristic of an object class. How we model it, is another problem…and I’m not 100% I’ve captured it right – in the new fig 4, I do not model “Participant” explicitly as a class but introduce it as an “overlay” or pseudo-class – I don’t know if this will stand up to formal modelling scrutiny but I think it gets closer to what we need to represent.

My edition of Enterprise Architect is still playing up so I haven’t been able to transcribe my informal sketches to formal models – someone with the same tool as we used for the other figures will need to pick these up once we agree the dispositions. Further, I am convinced that we need to use fewer class diagrams and make more use of object, behaviour and activity diagrams. Figure 8 is a case in point. I will see if I find some extra time to do at least some sketches of where we could be clearer and avoid over-modelling by classes…

 

 

Peter F Brown

Independent Consultant

www.peterfbrown.com

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

Tel: +1.310.694.2278

 

From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Wednesday, 21 December, 2011 10:26
To: Peter F Brown
Cc: soa-rm-ra@lists.oasis-open.org
Subject: transfer of Gold Copy

 

Peter,

 

The Gold Copy is passed to you for incorporation of changes per the 20111221a issues spreadsheet.  Please inform the group if anything significant needs to be altered in adjudications as captured in that spreadsheet. 

 

Let propose the following as the process for making updates:

1.       Get the latest Gold Copy from the chair (me) along with identification of the issues spreadsheet on which you should be basing changes.

2.       When you finish making changes, change the date on the title page to the date when you finished and rename the file as soa-ra-v1.0-yyyymmdd, where yyyymmdd is that date. 

a.       The first update is made to the file dated 06 July 2011 and constituting the draft used for the public review. 

b.      After the first update, the person making the next set of changes should ensure the date in the title page and file name is the same as the last time the Gold Copy was passed back to the chair or the last date the chair documented new updates.

3.       Transfer the updated Gold Copy back to the chair via email.  In that email, list the issue numbers you propose your changes to close and relevant comments if any are needed.

4.       The group will have an opportunity to review the changes and we will vote on officially closing them.

 

Did I miss anything?

 

Ken

 

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

Dr. Kenneth Laskey

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

7515 Colshire Drive                                    fax:        703-983-1379

McLean VA 22102-7508

 

Attachment: soa-ra-v1 0-20111227.doc
Description: soa-ra-v1 0-20111227.doc

Attachment: PR3 issues-20111227-Peter's proposed dispositions for section3.xlsx
Description: PR3 issues-20111227-Peter's proposed dispositions for section3.xlsx



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]