FW: Figures 13/14 (now figs 16 and 17)

My diagrams for the service description diagrams….

From: Peter F Brown
Sent: Friday, 24 February, 2012 11:56
To: 'Mike Poulin'
Cc: Ken Laskey; Rex Brooks (rexb@starbourne.com)
Subject: RE: Figures 13/14 (now figs 16 and 17)

Michael,

I had one insight this morning. I think we can break the deadlock with the following changes and draft suitable accompanying text. I think this keeps in line with Rex’s requirement that we don’t mess around with the core elements of the figures

Firstly, in (new) fig 16, I propose the following changes:

- For accuracy:

o In “Service Description” class, replace <<artefact>> with <<work product>> or leave blank;

o Change “Service Interface” class to “Interface Model”

- For clarity:

o Change other class names to simply read “Reachability” (which is how it is named already in fig 28) and “Functionality”

o Drop sub-sub-classes (Action Model, Process Model, Semantics and Structure) from this diagram – they are fully (and more accurately) explained in the next diagram – and add to fig 17, the notes on Action Model and Process Model, that would be dropped from fig 16;

o Drop sub-classes from Service Reachability and Service Functionality classes –the detailed Reachability diagram is in any case referenced in section 4.2.2.3 and fig 28. Section 4.1.1.3.3 already has detailed Functionality diagram

- For completeness, maybe show “<<work product>> Service Description” with a “realizes” arrow to a new element, “<<interface>> Service” (or “<<interface>> Service Interface” if people are uncomfortable with the former)

Secondly, further revise the accompanying text to underline:

- That “Service Description” as a term actually masks two intents – the actual description and the ‘work product’ that ensures that all ‘description’ is available, whether the source be in text files, database tables, queries, etc;

- That the Interface Model (describing the service interface) is not the same as the interface itself.

I attach a sketch and text of how this would look, with other figures updated accordingly… In .doc with all edits, and as a pdf, stripped of track changes and comments, to show how it might look…

Hope this helps,

Peter

From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Friday, 24 February, 2012 07:39
To: Peter F Brown
Subject: Figures 13/14

Hi Peter,

following the RAF meeting assignment, let me start our work on Figures 13/14 with a question: what UML diagram do you think is appropriate for documenting (Figure 13) and defining (Figure 14, and , may be, 26=29 new) Service Interface (SI)? Do we have a freedom to use other UML diagrams in the RAF?

Dominant majority of other diagrams are Class Diagrams. Since Class owns its data and references, the relationship between description of SI, on one hand, and Behavior and Information Models, on another hand, may be expressed in two ways:
a) SI description Class references to the description Classes of Behavior and Information Models by owing the references. If we assume that SI description Class stands for ALL service interfaces of particular service, there may be more than one description references for each Behavior and Information Model descriptions (one per each interface). This means, that the dark romb (composition) may be replaced by a light romb (aggregation). However, I tihnk, that we have to outline in the diagram that we deal with Description Classes, not with definition Classes.

b) SI description Class explicitly describes behavior and information elements of each specified service interface. These description are contributed by the Behavior Model and Information Model description Classes. In this case, the dark romb (composition) should be replaced by an arrow pointing from the Behavior Model and Information Model description Classes to the SI description Class. IMO, this model easy to comprehand because it corresponds with the Defition Class diagram for SI, Behavior Model and Information Model. We still need to articulate in the text that Figure 13 ia bout _descriptions_ rahter than definition and modify Figure 14/26=29 approprietally.

What do you think?

Cheers,
- Michael Poulin

soa-rm-ra message