Realization is not, imo, the correct dependency in this case.
On Jun 25, 2009, at 8:32 AM, Rex Brooks wrote:
> 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
>
