[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] willingness in joint action
Rex, Yes, an association class (by definition) is a class, and therefore has all the features that classes can have. Is that what you were asking? -Jim On 6/28/09 8:32 PM, "Rex Brooks" indited: > 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 > > --------------------------------------------------------------------- > 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]