[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] willingness in joint action
Thanks James, The other question I had was whether an Association Class could simultaneously participate in another association where it is on the source or destination end of the relationship rather than acting as the association between two other classes? Cheers, Rex At 3:42 PM -0400 6/28/09, James Odell wrote: >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 >> > > > >--------------------------------------------------------------------- >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]