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: Re: [soa-rm] RE: [soa-rm-ra] Service & Interface Description modelling


let's forget about classes and objects and operate at teh level of modeling entities or entity descriptions. I am not sure I understand what 'removed stereotypes' you mention. I just replaced one 'stereotype' (=aggregation) by another 'stereotype' of referencial association. The latest version of the diagrams states that Service Interface references to (or even depends on) Behavior/Information Models (before it aggregated these Models and this was the mistake).

- Michael

P.S. As I said, Figure 16 as is (+Event Model) is OK with me but may be improved if we want.


----- Original Message -----

From: rexbroo

Sent: 05/10/12 12:13 AM

To: Ken Laskey

Subject: Re: [soa-rm] RE: [soa-rm-ra] Service & Interface Description modelling

I couldn't make heads or tails out of the red ovals. I see no reason to change Figure 16.

Figure 17 I am still thinking about, but removing the stereotype makes is more of a class diagram than an object diagram, though to be honest, I never mention modeling objects in these models. Objects, for me, are strictly actual instances of classes in purely operational diagrams from which specific code can be generated. We are not doing any of that here.


On 5/9/2012 1:19 PM, Ken Laskey wrote:

Are slides 4 and 5 inconsistent with 1, 2, and 3?









Dr. Kenneth Laskey



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



7515 Colshire Drive                                    fax:        703-983-1379



McLean VA 22102-7508






From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Wednesday, May 09, 2012 4:01 PM
To: soa-rm-ra@lists.oasis-open.org
Cc: soa-rm@lists.oasis-open.org
Subject: [soa-rm-ra] Service & Interface Description modelling







attached is the presentation with my proposals for Figures 16, 17 and 29.

Difference between F16 and F17 is tha same as between meta-data and data.

- Michael







----- Original Message -----



From: Ken Laskey



Sent: 05/09/12 01:36 PM



To: 'Mike Poulin', 'Peter F Brown', soa-rm-ra@lists.oasis-open.org



Subject: RE: [soa-rm-ra] New Working Draft 07; Update of Issues List; Update of Minor edits
























See attached for revisions to Figures 16 and 17.  Service Interface as related to Description will be changed to Service Interface Description and the <<interface>> stereotype is being removed.  There was a general agreement that these changes were necessary and useful.  All explanatory text emphasizes description of the interface and not the interface itself.


















Please look at things in this context and I think it will address many of your concerns.













































Dr. Kenneth Laskey









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









7515 Colshire Drive                                    fax:        703-983-1379









McLean VA 22102-7508


















From: soa-rm-ra@lists.oasis-open.org [mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Wednesday, May 09, 2012 7:57 AM
To: Peter F Brown; soa-rm-ra@lists.oasis-open.org
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm-ra] New Working Draft 07; Update of Issues List; Update of Minor edits



















I'd like to comment on Figures 16, 17, 18  - issue 203 (yes, this seems as an obsession of mine but, please, try to understand that I am in difficult situation: I am writing everywhere that service interface is a “path-point” and does not have any behavior, and do not have serious objections from architects, while RAF, which I promote, shows right opposite).









Frankly, it looks to me next to absurd that Figure 18 (Service Functionality) does not even mention neither Behavior nor Information Model (how a service works in this case) while both models are owned/reacheable/included by a dummy service interface in Figure 17.









I can coop with Figure 16 due to a reference to “description” though I am still not 100% happy with it, but Figure 17! It is too much to me. It is Service Description that can/may/should explicitly point to Behavior and Information Model, not an interface: a door into a house can represent neither soft nor hard floor set in the bedroom, IMO.

- Michael



























----- Original Message -----









From: Peter F Brown









Sent: 05/09/12 08:59 AM









To: soa-rm-ra@lists.oasis-open.org









Subject: [soa-rm-ra] New Working Draft 07; Update of Issues List; Update of Minor edits













































Three new documents for your attention regarding the SOA-RAF






















































Firstly, a new draft – WD07 dated 8 May - this incorporates:



























-          all the minor edits (which are considered accepted and are no longer tracked – but see note 3 below);



























-          all the more substantial edits, with sidebar comments indicating the respective Issue number(s) addressed;



























-          several new figures;



























-          indications (in sidebar comments) of other changes still required – often minor updates of figures to align with text already agreed in the SC.



























Note: We will continue to note issue resolution against the July 2011 Public Review document – but any discussion in the SC from hereon in should use the structures, section numbers and line numbers of this new WD07 – this will ensure that we remain – literally – on the same page in further discussions. Please use the pdf version of WD07 when making further comments in meetings or on the list. (We will load the Word version to Kavi asap).






















































Secondly, a fully updated Issues List. This has grown over the last months, inevitably, as a working tool for the editors. Ken and I have restructured this and worked through the whole thing on several passes and present what we hope is a simplified view of what is done, what is recommended, and what remains open. Three new columns appear in the spreadsheet:



























Column B indicates the status of the respective issue:



























-          Green indicates that the issue is closed – this covers many minor edits, typos, alignment of terms etc. Many of these minor edits are no longer tracked in the document (see note 3 below)



























-          Yellow indicates our recommendations for issues that should now be closed, either because they are the result of exhaustive consensus, are also minor edits, or are redundant (OBE) – we propose: if no objections are given in the next (week?), that these issues are closed



























-          Red indicates an issues which has been dealt with in our discussions but which still requires some further work – such as updating a figure. We consider the issue to be “dealt with” but we all need just to be sure that the remaining edits are forthcoming



























-          Blue indicates an open issue that requires further discussion and/or a decision from the SC.



























Columns O and P have been added to provide further information on that small number of issues that are not closed (red or blue in col B)






















































For each issue, all details of the original comment, suggested edits, discussion, etc have been kept. A green cell – in column I or further to the right - will indicate the end/resolution of the consideration of that issue.






















































Thirdly, we have updated the short table circulated two weeks ago, indicating the list of issues that are closed and no longer tracked within the working document – this provides a “due diligence” check for minor edits.






















































I think we can see the finish line….






















































All the best – and enjoy. Talk to you on the call later







































































































































Peter F Brown



























Independent Consultant



























Using Information Technologies to Empower and Transform

















































































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



























Tel: +1.310.694.2278



























Member of:









































































































Follow me:































































































































































































































Rex Brooks 
Starbourne Communications Design 
Email: rexb@starbourne.com 
1361 Addison St. Apt. A 
Berkeley, CA 94702 
Phone: 510-898-0670 


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