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-ra] willingness in joint action


Rex,

Sorry: I overlooked your email.

In UML, a dependency is a relationship that signifies that a single or a set
of model elements requires other model elements for their specification or
implementation. This means that the complete semantics of the depending
elements is either semantically or structurally dependent on the definition
of the supplier element(s).

Semantics
A dependency signifies a supplier/client relationship between model elements
where the modification of the supplier may impact the client model elements.
A dependency implies the semantics of the client is not complete without the
supplier.  The presence of dependency relationships in a model does not have
any runtime semantics implications, it is all given in terms of the
model-elements that participate in the relationship, not in terms of their
instances.

Notation
A dependency is shown as a dashed arrow between two model elements. The
model element at the tail of the arrow (the client) depends on the model
element at the arrowhead (the supplier). The arrow may be labeled with an
optional stereotype and an *optional* name.  So, a name is not required.
However, for indication of meaning, it would -- IMO -- be helpful.  I notice
that Ken used the term "requires" in his 6/25 6:57pm EDT email.  That works
for me.

-Jim 



On 6/25/09 11:32 AM, "Rex Brooks" indited:

> Thanks James,
> 
> My question to James is: do you have a
> recommended name? For the pre-specified names, I
> reviewed the UML 2.2 superstructure spec for
> classes and it seems to me that realization is
> the more accurate.
> 
> The description for realization is
> 
> "Realization is a specialized abstraction
> relationship between two sets of model elements,
> one representing a specification (the supplier)
> and the other represents an implementation of the
> latter (the client). ...."
> 
> My initial thought was that it was more accurate
> because the action is the implementation of
> willingness or ability to act (and it is also the
> implementation of "intent" to act toward the
> fulfillment of some desired real world
> effect--goal). Unfortunately a closer reading of
> the description leads to a tautology since Action
> is the latter (client) class, making Action an
> implementation of Action. So, I appeal to James
> or Jeff to enlighten me here.
> 
> However, if I were to choose a term on my own as
> an extension of Dependency for explanatory
> purposes, whether UML Tools can operate on it or
> not, I would use <<enable>>. Of course, for my
> purposes, I want the tools to be able to use
> this, but that should not stand in the way of
> completing the explanatory purpose of this
> specification.
> 
> My last question is: if realization is more
> accurate, should we then, use a Realization
> Dependency (a dashed line ending in a triangle)?
> Willingness and Ability Dependency connectors
> could be joined and share the triangle to make
> clear that both must be satisfied.
> 
> Cheers,
> Rex
> 
> At 9:41 AM -0400 6/25/09, James Odell wrote:
>> Dependencies typically have names.  A choice of names are pre-specified by
>> UML (e.g., <<instantiate>>, <<realization>>).  However, you may extend this
>> set of names, but they will not be understood by conventional UML tools.
>> 
>> -Jim
>> 
>> 
>> On 6/24/09 8:29 PM, "Francis McCabe" indited:
>> 
>>>  I dont think that dependencies are usually named. What would you
>>>  suggest for the names?
>>>  On Jun 24, 2009, at 5:14 PM, Rex Brooks wrote:
>>> 
>>>>  Works better for me. Will the association between Willingness and
>>>>  Actor  and between Ability and Actor be named?
>>>> 
>>>>  Cheers,
>>>>  Rex
>>>> 
>>>>  At 4:33 PM -0700 6/24/09, Francis McCabe wrote:
>>>>>  I have a new diagram...
>>>>> 
>>>>> 
>>>>>  Attachment converted: Macintosh HD:Joint Actions 4.png (PNGf/«IC»)
>>>>>  (01789292)
>>>>> 
>>>>> 
>>>>>  This focuses on the fact that an actor has ability (or not) and
>>>>>  willingness (or not) and that joint action depend on both.
>>>>>  I redrew the named association between joint actions and actions as
>>>>>  a regular aggregation.
>>>>> 
>>>>>  Frank
>>>>>  On Jun 24, 2009, at 3:05 PM, Rex Brooks wrote:
>>>>> 
>>>>>>  The dependency of Joint (or any kind of) Action on Willingness is
>>>>>>  not clear in the diagram. That's why I modeled it as a Dependency
>>>>>>  relationship of Willingness-Determination (as the supplier) and
>>>>>>  Joint (or any kind of) Action (as the client) and not an
>>>>>>  Association Class. However, as an Association Class it can be
>>>>>>  applied to the relationship between an actor and any kind of
>>>>>>  action. I like that.
>>>>>> 
>>>>>>  If there is a way to make the Association Class show dependency,
>>>>>>  I'd be happier.
>>>>>> 
>>>>>>  Cheers,
>>>>>>  Rex
>>>>>> 
>>>>>>>  Sooo, while I agree that willingness is a kind of association
>>>>>>>  class, I am uncomfortable with this diagram:
>>>>>>> 
>>>>>>>  Attachment converted: Macintosh HD:Joint Actions 3.png
>>>>>>>  (PNGf/«IC») (01788EEC)
>>>>>>> 
>>>>>>>  for two reasons: Willingness is a noun and associations are
>>>>>>>  predicates, and there are other important associations that could
>>>>>>>  be drawn here, such as ability, authority, all kinds of stuff.
>>>>>>> 
>>>>>>>  Thoughts?
>>>>>>> 
>>>>>>>  Frank
>>>>>>> 
>>>>>>>  Attachment converted: Macintosh HD:smime 1092.p7s (    /    )
>>>>>>>  (01788EED)
>>>>>> 
>>>>>> 
>>>>>>  --
>>>>>>  Rex Brooks
>>>>>>  President, CEO
>>>>>>  Starbourne Communications Design
>>>>>>  GeoAddress: 1361-A Addison
>>>>>> Berkeley, CA 94702
>>>>>>  Tel: 510-898-0670
>>>>> 
>>>>> 
>>>>> 
>>>>>  Attachment converted: Macintosh HD:smime 1094.p7s (    /    )
>>>>>  (01789293)
>>>> 
>>>> 
>>>>  --
>>>>  Rex Brooks
>>>>  President, CEO
>>>>  Starbourne Communications Design
>>>>  GeoAddress: 1361-A Addison
>>>>  Berkeley, CA 94702
>>>>  Tel: 510-898-0670
>>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 




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