Author Topic: About association (Read 26700 times)

SF_lt · « **on:** August 28, 2005, 07:19:21 am »

11.3.1 Superstructure:

11.3.1 Association
An association describes a set of tuples whose values refers to typed instances. An instance of an association is called a
link.
Description
An association specifies a semantic relationship that can occur between typed instances. It has at least two ends
represented by properties, each of which is connected to the type of the end. More than one end of an association may
have the same type.
When a property is owned by an association it represents a non-navigable end of the association. In this case the property
does not appear in the namespace of any of the associated classifiers.repuS

don't understand statement about non-navigable properties - what does it mean in the model? and for what purpose do we need such case?

thomaskilian · « **Reply #1 on:** August 29, 2005, 01:40:10 am »

Navigable: The class has a property that associates another class.

Non-navigable: the association is "outside" the class. In databases you can associate 2 classes by creating a table with their primaries associated in a row.

jeshaw2 · « **Reply #2 on:** August 29, 2005, 02:09:14 pm »

I'm still confused by that and this statement:

Quote

An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.

Perhaps I don't understand the concept of owned. How can an association own anything? its a tuple referencing the end classifiers...

AND, how does an end class own an end property of an association?

AND, except for classes with internal structures, most associations are between classes, not within them? How are they ever inside of a class?

I'm reminded of the Klein bottle.

Can you elaborate a bit more?

Paolo F Cantoni · « **Reply #3 on:** August 29, 2005, 06:59:00 pm »

Jim,

Get a hold of: the UML 2 Superstructure Specification. This is the latest and greatest.

On page 29 (47 of the PDF) you find: Figure 12 - The Classes diagram of the Kernel package

This helps explain what's going on...

7.3.3 Association (from Kernel)

[size=13][SNIP][/size]

Description
An association specifies a semantic relationship that can occur between typed instances.

Figure 12 shows that the Association is both a Relationship AND a Classifier.

It has at least two ends represented by properties, each of which is connected to the type of the end.

In UML, Properties are what Attributes are made of. They are also what member ends of an Association are made of. This is why UML can say, a "A navigable, named association end IS an attribute." Thus the list of members is the list of columns in the tuple.

More than one end of the association may have the same type.

This just says you can have Associations between instances of the same Class.

An end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.

If, when you delete the association, you also delete the nominated attribute then you have an ownedEnd. The end is owned by the owningAssociation. The equivalent ownedAttribute is owned by the Class, but it disappears none the less.
Some of these Attributes are navigable (essentially By Reference) others aren't (By Value).

Does that help?

Paolo

SF_lt · « **Reply #4 on:** August 30, 2005, 04:16:19 am »

Quote

Non-navigable: the association is "outside" the class. In databases you can associate 2 classes by creating a table with their primaries associated in a row.

I think, that "association is "outside" the class" doesn't provide more clear view about non-navigable associations IMO.

if association ends don't have property in the associated class, then this is non-navigable association, is what you want to say, Paolo?

Paolo F Cantoni · « **Reply #5 on:** August 30, 2005, 04:51:03 am »

Quote

[size=13][SNIP][/size]
if association ends don't have property in the associated class, then this is non-navigable association, is what you want to say, Paolo?

Yes,
just remember, the property is in the class at the client end (opposite the arrow!).

BTW, In order to ensure that the model correctly understands this, you need to "DRAW" (not render) the association from the client to supplier. There was quite some discussion in the forums about 4-6 months back regarding differences in drawing philosophy amongst various tools, and users!

HTH,
Paolo

jeshaw2 · « **Reply #6 on:** August 30, 2005, 06:07:13 am »

Thanks Paolo. Your comments help, but I'm not there yet... I'm (1) zeroing in on ownership; and, (2) wishing I could understand Figure 12, as well as the other metaclass diagrams, better.

It is becoming clear to me that containment of an element does not imply ownership of it, nor does access to it. So ownership of an element simply provides rights to exert control over its accessability by others, and the element's creation and destruction?

Can you help me to read Figure 12 better?

In Figure 12, considering the link between Property and Association, the ownedEnd of the link is attached to that which is owned (Property), and the owningAssociation end is attached to that which has ownership rights (Association). But the question is "What is being owned here?", for when the Association is destroyed, something else is destroyed too. Does the Association own the link between itself and Property, or is the link notation saying that Association owns a Property? I guess the circular definition is confusing for a link is an association.

To my imperfect mind, of the three links between Property and association, the first is navigatable in both directions, the second is also (but adds aggregation to the mix) and the third is only navigatible from Association to Property. These three links seem both redundant and contradictory to me.

And, looking below the Association, why is the type classifier not associated with the end property? or, is that what the association element is doing, or is that what "+/endType {ordered}" means?

I have more to ask, but I must deal with an unowned element called work.

Later.....

Paolo F Cantoni · « **Reply #7 on:** August 30, 2005, 05:00:29 pm »

Quote

Thanks Paolo. Your comments help, but I'm not there yet... I'm (1) zeroing in on ownership; and, (2) wishing I could understand Figure 12, as well as the other metaclass diagrams, better.

It is becoming clear to me that containment of an element does not imply ownership of it, nor does access to it. So ownership of an element simply provides rights to exert control over its accessibility by others, and the element's creation and destruction?

Yes Jim, essentially I believe you're right.
In various discussions on meronymy associate connectors when reverse engineering I believe we need to clearly distinguish between:
1) Ownership: I control you (including who can access you and who create and destroy you)
2) Nesting: You cannot be accessed, except through me
3) Containment: I hold you within me - but you are not of me
4) Collection: You are in a group

Quote

Can you help me to read Figure 12 better?

In Figure 12, considering the link between Property and Association, the ownedEnd of the link is attached to that which is owned (Property), and the owningAssociation end is attached to that which has ownership rights (Association). But the question is "What is being owned here?", for when the Association is destroyed, something else is destroyed too. Does the Association own the link between itself and Property, or is the link notation saying that Association owns a Property? I guess the circular definition is confusing for a link is an association.

The associationEnd (the Property) is what is being owned (by the owningAssociation). The link is automatically destroyed (by a sort of garbage collection) when either end is destroyed.

Quote

To my imperfect mind, of the three links between Property and association, the first is navigable in both directions, the second is also (but adds aggregation to the mix) and the third is only navigable from Association to Property. These three links seem both redundant and contradictory to me.

Ah, now you've touched on what I believe is a deficiency in the UML specification with regard to rendering. There is no visible difference between the rendering of "navigable in both directions" and "navigable in neither direction". I'll leave it as a exercise for the reader to determine what navigable in neither direction could mean...

However, since the Association has both ends named, in this instance it is navigable in both directions as you suggest. Similarly, for the second one. I have written elsewhere, that in my view, the "composition" indicator in a UML model actually merely describes whether the end with the indicator (the whole) can destroy the other end (the part). The third is navigable only from the Association to the Property.

Now to the meat of your question. You are right to suspect redundancy, but it is at the instance level. The way to "read" the relationships between the Association and the Property is (in my view):
An Association is both a Relationship and a Classifier.
An Association has at least two members (which are Properties)
Some (possibly none) of those members can be owned by the Association
Some (possibly none) of these owned members are navigable.

So you see, the semantics of each of the Associations becomes progressively more restrictive, although any given link could participate in more then one Association.

Quote

And, looking below the Association, why is the type classifier not associated with the end property? or, is that what the association element is doing, or is that what "+/endType {ordered}" means?

Each Association has a manifold, derived, Attribute called endType. It's not connected to the property because it isn't the type of the Property, it's the type of the Classifier at the end of the assocationEnd (I think).

Quote

I have more to ask, but I must deal with an unowned element called work. Later.....

There's no such thing as a stupid question...

HTH,
Paolo

jeshaw2 · « **Reply #8 on:** August 31, 2005, 06:18:21 am »

Paolo;

Quote

1) Ownership: I control you (including who can access you and who create and destroy you)
2) Nesting: You cannot be accessed, except through me
3) Containment: I hold you within me - but you are not of me
4) Collection: You are in a group

I love your allegories here.

So, in an association between two classes, the black diamond identifies the class which owns the association (including the end properties), but says nothing about who owns the associated class? If true, I think this is good. I'm thinking that Ownership, Nesting, Containment, and Collection are Structural issues then, not associative issues.

I can see then, that when a class which owns an association is immolated, it has an option to destroy the association link, but then again, it may not. This seems to set up some referential integrity issues for me in that the objects being referenced no longer exist, but the link between them does? Or worse yet, one object still remains with the association, but the other end is unconnected? In Figure 12, the cardinallity of the association between Class and Property seem to allow this, or am I reading this incorrectly?

In Figure 12 again, I'm also bemused by the fact that both the association and the associated class may own a given End Property (as well ad the association itself) as both of them have black diamond ends on their links to Property.

All of this is making me wonder just what a Property Class represents? The model says it is a specalized StructuralFeature, but does it exist in code somewhere or is it simply a concept that controls the generation of the code? Are the terms End Property and Association End synonymous?

Who would have thought that a simple line on a diagram could be so complex?

Try explaining all of this to a first year college student!

I'm beginning to think we need to fork this thread into several sub-threads...

Here's hoping my questions are worthy of your attention.

Paolo F Cantoni · « **Reply #9 on:** August 31, 2005, 07:26:04 am »

Quote

Paolo;
I love your allegories here.

Thanks Jim, I try to figure out simple rules that allows me to make better models. Making "industrial strength" models is not trivial (but it 's also not rocket science).

Quote

So, in an association between two classes, the black diamond identifies the class which owns the association (including the end properties), but says nothing about who owns the associated class? If true, I think this is good. I'm thinking that Ownership, Nesting, Containment, and Collection are Structural issues then, not associative issues.

I can see then, that when a class which owns an association is immolated, it has an option to destroy the association link, but then again, it may not. This seems to set up some referential integrity issues for me in that the objects being referenced no longer exist, but the link between them does? Or worse yet, one object still remains with the association, but the other end is unconnected? In Figure 12, the cardinality of the association between Class and Property seem to allow this, or am I reading this incorrectly?

No, I haven't made myself clear enough. Both Classes determine the existence of the Association (as a concept). If either is removed from the model, then the Association must be removed. The filled in diamond DOES determine whether the instance of the Class at the diamond end CAN destroy the instance(s) of the Class at the other end.

Quote

In Figure 12 again, I'm also bemused by the fact that both the association and the associated class may own a given End Property (as well ad the association itself) as both of them have black diamond ends on their links to Property.

Alles ist in ordnung here... (apologies Thomas

. Remember, the Property is both the AssociationEnd and the Attribute. If I delete the Attribute, I'm deleting the Property and thus I'm deleting the AssociationEnd and therefore the Association. On the other hand, if I delete the Association, I delete the AssociationEnd which deletes the Property which deletes the Attribute! This is in line with my assertion (elsewhere in the forum) that an AssociationEnd and an Attribute are just different renderings of the same Property. I said it in words, Figure 12 says it graphically.

Quote

All of this is making me wonder just what a Property Class represents? The model says it is a specialized StructuralFeature, but does it exist in code somewhere or is it simply a concept that controls the generation of the code? Are the terms End Property and Association End synonymous?

See preceding...

Quote

Who would have thought that a simple line on a diagram could be so complex? Try explaining all of this to a first year college student!

That's the power of modelling. With apparently simple symbols and rules we are able to construct models of suitable complexity to take a meaningful stab at describing the world. What's known in MDA terms as the CIM - Computationally Independent Model.

Quote

I'm beginning to think we need to fork this thread into several sub-threads...

I'll leave it up to you to create the forks...

Quote

Here's hoping my questions are worthy of your attention.

As I said before... Besides, for me, having to explain it means I'm forced to make sure I have a decent stab at having Consistency, Consistency, Consistency! ^TM in my understanding...

HTH,
Paolo

jeshaw2 · « **Reply #10 on:** August 31, 2005, 11:43:36 am »

Paolo:

I thought a light bulb went on in my head as you explained that the three associations between Association and Property might not be redundant as they expressed different kinds of constraints on the relationship. So, my discovery is that "more than one association line can be used to define a complex relationship"! What a concept! None of the UML books ever told me that. Its kinda like association decomposition...

In another thread, you mentioned that you have multiple class drawings, each articulating a different aspect of the class. Again, wow! The books never mentioned that either! This is good stuff!

So I developed a model with two classes "A" and "B" such that A owned B. Then I tried to add another association between them, but EA would not put it on the drawing! It disappeared right after I released the 'clickndrag' button on my rodent???

How come??

Paolo F Cantoni · « **Reply #11 on:** August 31, 2005, 03:59:00 pm »

Quote

Paolo:

I thought a light bulb went on in my head as you explained that the three associations between Association and Property might not be redundant as they expressed different kinds of constraints on the relationship. So, my discovery is that "more than one association line can be used to define a complex relationship"! What a concept! None of the UML books ever told me that. Its kinda like association decomposition...(

At last, in UML 2, you can actually use Generalization between Associations, and set management also! Now if EA would just support this...

Quote

In another thread, you mentioned that you have multiple class drawings, each articulating a different aspect of the class. Again, wow! The books never mentioned that either! This is good stuff!

In courses I've given (in Data Modelling), that has often been the feedback- they never taught any of this at University! Gratifying certainly, and thank you for your feedback... Like bruce, I've been threatening to write that book...

Quote

So I developed a model with two classes "A" and "B" such that A owned B. Then I tried to add another association between them, but EA would not put it on the drawing! It disappeared right after I released the 'clickndrag' button on my rodent???

How come??

Ah, grasshopper, consider this experience an exercise in how not to defined a unique user interface! EA's strikes again...

Point 1: You , as a user, have no direct access to connectors - so you can't tell if you actually created it or not. That is, they don't appear on the browser (like in many/most other products)
Point 2: If you don't move the first Association, the second will be created right on top of it. So (visually), you "lose" the newly created Association.

If you can, re-layout the diagram. EA will show you the two Associations. If you can't layout the diagram (for aesthetic or other reasons), create a new diagram, drag both classes onto that and layout that diagram.

They should both be there! If not, then you didn't actually create the second Association. On the diagram, move the original Association first, then create the other.

HTH,
Paolo

jeshaw2 · « **Reply #12 on:** August 31, 2005, 07:32:02 pm »

Paolo;
That did it. I just needed to move the association lines.

Now, I'm exploring the mysteries of the code generator's reactions to all this stuff I've just learned. I'm getting a few surprises, but as I dwell upon them, I see a machine working logically behind the scenes. I'm always surprised at the creativity of logic machines.

Now, I'm going to see if I can reconcile the machine's logic to the UML 2.0 spec.

Might even get into the code generation templates too. Wish me luck.

Cheers

Paolo F Cantoni · « **Reply #13 on:** August 31, 2005, 08:46:10 pm »

Quote

Paolo;
That did it. I just needed to move the association lines.

Now, I'm exploring the mysteries of the code generator's reactions to all this stuff I've just learnt. I'm getting a few surprises, but as I dwell upon them, I see a machine working logically behind the scenes. I'm always surprised at the creativity of logic machines.

Now, I'm going to see if I can reconcile the machine's logic to the UML 2.0 spec. Might even get into the code generation templates too. Wish me luck.

Cheers

Luck doesn't enter into it. It won't work...

You may make some local gains, but eventually it will break.

I went through the same processes as you. Fortunately I tested the CGT to destruction before I invested too much in its functionality. The CGT is not sufficiently functional to emit code of sufficient richness. AND it's NOT even used in reverse engineering!

NOTE: This problem is NOT unique to EA. I believe it to be a general fallacy that round-trip-engineering from a model to pure code is possible.

I've taken the route of generation only, BUT through a decoupling interface. So far so good... Watch this space...

Paolo

jeshaw2 · « **Reply #14 on:** August 31, 2005, 09:48:05 pm »

I have evaluated many, many CASE tools over the years and have already come to that conclusion. However, if a tool is given sufficient information (as we are able to do in EA), I do expect a reasonably robust forward generation of stubs and attributes. (Having access to that feature is the primary reason I upgraded to my currentl level of EA.) I'm not getting that yet out of EA, but I want to make sure the problem is not due to my understandings and is an opportunity for EA Enhancement.

Actually, I want to be able to render a rather complex OO design in UML and to teach my students to properly decode the model so they can realize the design in effective code. (Obviously, textual design information will also be provided.)

From my perspective, it really does not matter if the code is machine generated or hand written, as the processes I teach are upstream of the coding process.

Sparx Systems Forum

News: