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
