KP, could you post diagram? ;)
I have read this superstructure sentence, but without example and explanation it doesn't help a lot
BTW, if you choose other ends, you can get not classA with the left classes, but classC with the rest (classC-classA, classC-classB & etc)
Hi SF_lt (can we have a more human moniker for you? :) ),
If you are familiar with ERD or DB design, the best way to think about the Lozenge (in my view) is as an Intersector Table, with a mandatory, singular, foreign key to each of the associated Classes (as Tables). Therefore the UML statement KP (another non-human? :) ) quoted merely states that if you run a query over the lozenge where you supply values for each of the foreign keys but one, you'll get the set of rows where the value of the remaining foreign key varies. The quote goes on to say that if the end is ordered or unique, this will apply the same constraints on the set of values returned by the query. Does that help?
Also, one little specification on constraints: what I miss, I miss feature to add constraint for the dotted line from association class to association line - there is no way to attach constraint or smth else to this part of association. Maybe UML2 metamodel prohibits it...
The dotted line is not a real connector. It is merely trying to reinforce the idea that the Association Class IS the Association line. It is a rendering artifact, not a real UML element. Therefore you can't attach any metadata to it. That's why Thomas said use the Constraints tab on the AssociationClass or Lozenge.
FWIW, I can't reinforce enough that Sparx needs to understand that the lozenge shape is merely a rendering of the AssociationClass (like say the Boundary, Control and Entity shapes from the Analysis toolkit). Also, that the AssociationClass defined by UML is merely binary example of the N-ary Association. So a binary Association may be depicted by an Association line by itself, an Association line with associated AssociationClass or an Association lozenge with two AssociationEnds - they are all the same thing!
Accordingly, you should be able to do everything you can do to a Class to the Lozenge!
jeshaw, I agree, that road doesn't need to know, what cars use it (what about women? :-D )
in my example, channel passes signals from sender to receivers, also signals travel through the channel to reach their's destination. Also not all signals use one or other channel - there may be many channels.
But still, thanks for your point
By Signal here, do you mean Signal Type? If you mean Signal, what is the domain identifier that allows you to specify which signal instance you are associating. From my intersector table example above, you'll see you need to provide the foreign key to identify each AssociationEnd. IF you can't find one, then it's an indication the model is wrong.
It strikes me that this would be a good example to work through for AssociationClasses and lozenges etc. Like Jim, I'm not so sure there is an N-ary relationship here.
To determine how to model the rules, we need to know the rules. Could you give us a short definition of each of the Classes involved: Sender, Receiver, Channel and Signal? Without them, we can't really provide the direction you are seeking. Nothing fancy (as they say in the competitions - 25 words or less ;D)
If you've been following some of my postings, you'll see I strongly favour a technique called "Verbalisation" - where you "speak out" the model. If the words sound wrong, the model is wrong!
HTH,
Paolo
[size=0]©2005 Paolo Cantoni, -Semantica-[/size]
[size=13][SNIP][/size]
EDIT: On thinking things through, you are free to model all associations as AssociationClass if you wish - it is, after all, adding extra information to the model not subtracting, and if you need the extra info then why not? So to answer your original point, Sparx don't "need to understand that the lozenge shape is merely a rendering of the AssociationClass" but we need to allow you to understand that. I think.
Neil
PS "KP" is pronounced the same as my surname and is easier to type. I've always used it on message boards. In the UK it's also a brand of nut :-/
Hi Neil,
Thanks for the edit. There's hope for you yet. ;D
You're half way there... The problem with the Association Class is that as manifest (on OMG Diagrams etc) it appears to apply only to a binary relation. This can't possibly be the case! We have a continuum of (outbound, N-ary) AssociationEnds for an AssociationClass from 2 upward. Similarly, we have a continuum of AssociationClass Features from N (one attribute for each (N-ary) AssociationEnd) upward.
Accordingly, If I can represent a binary Association as either:- a single Association line (which is composed of the two AssociationEnds) between the two Associated Classes
- or a line with the (rendered) attached AssociationClass
- or the Association lozenge and the two AssociationEnds
then it is obvious (at least to me on a few minutes thought) that the lozenge IS the AssociationClass!
If this is so, the we have an elegant proof that is then extensible to the N-ary case! In short, it works!
Now all we need is for Sparx to provide the additional context menu item on the AssociationClass (which IS the Lozenge) ("Use Lozenge Notation") (similar to the "Use Circle Notation" for an Interface) to allow us to switch between renderings and we're sweet!).
BTW: I don't know how many of you have been bothered by the question "What makes an AssociationClass different from an ordinary Class?"
Do you (the reader - not just Neil!) know? Have you thought about it? Will it come up as a question on the OMG Certification Exam?
An AssociationClass is a Class that represents an Association and thus has one required attribute referencing the associated Class for each arity of the N-ary Association it represents. Add/Remove an AssociationEnd and the attribute is accordingly added/removed.
It all works!
So, Neil, when do we get the "Use Lozenge Notation" context menu Item? Or at a minimum, the ability to change the Type of the Lozenge from Association to Class and back; as I think has been requested before in the forum?
Pleadingly,
Paolo
BTW: The UML specifications are either somewhat compressed and potentially confusing or, in at least one place, downright incorrect on the subject of the N-ary Association. In particular, Figure 74 of the the UML 2 [size=13]Infrastructure[/size] (http://www.omg.org/cgi-bin/doc?ptc/2003-09-15) Specification showing Binary and ternary Association is incorrect in the placement of the multiplicities. The multiplicity of the each AssociationEnd with respect to the associated Class is one! The N-ary Association is defined as a Tuple and therefore the multiplicity MUST be one! As far as I can tell, constraints on the number of Tuples for a given associated Class can only be handled by Class level constraints on the AssociationClass. For example, "a Player can only be a goalie on no more than two team in a season".
[size=0]©2005 Paolo Cantoni, -Semantica-[/size]