Modeling Dependency Injection

[jeshaw2]

Paolo;
I've read you views as evidenced by a search on Lozenge and if the following statements are true, I'm in full agreement with you.

• A simple binary association is just a tuple of ends; ( I think I said that correctly )  This is diagrammed with a straight line with perhaps navigation or aggregation symbols at the ends.
  

• All other associations are classes with attributes and, optionally, methods.  This may be diagrammed with either a class or lozenge icon and the lines radiating from the icon are the association ends.
  

If this is not correct, or close to it, I'm confused and need enlightment.

[Paolo F Cantoni]

Paolo, thanks for the diagram.

Also, I always wondered, why I can't find any example, where "lozenge" is connecting more than 2 classes (and another diagram, which doesn't use "lozenge", but depicts same thing using associations/dependencies).

SF,
Here's an example using more than two classes (or Classifiers)


I use this ternary in my Code Emitter.  I select the Component to emit, follow the first «end» down to the «manifestation» lozenge.  I then follow the «end» to the «sourceFile».  If I don't already have one, I create a CodeDOM CodeCompileUnit.
I then follow the «end» to the Class and add it (as a CodeTypeDeclaration)  to the CodeCompileUnit I have just identified.
When finished, press Generate and out pops the written code!

HTH,
Paolo

BTW, the notation is my special notation...  I put composition diamonds at the end to make these stand out as «end»s (and also the 0 on the source end of the end...) and also because, to my mind, the Association(Class) acts like a DB intersector table and should have CASCADE DELETE set from all its intersections.

[Paolo F Cantoni]

Paolo;
I've read you views as evidenced by a search on Lozenge and if the following statements are true, I'm in full agreement with you.

• A simple binary association is just a tuple of ends; ( I think I said that correctly )  This MAY diagrammed with a straight line with perhaps navigation or aggregation symbols at the ends.
  

• All other associations are classes with attributes and, optionally, methods.  This may be diagrammed with either a class or lozenge icon and the lines radiating from the icon are the association ends.

If this is not correct, or close to it, I'm confused and need enlightenment.

Just a slight modification.  ALL associations can be shown using the lozenge and the requisite number of «end»s.   The straight line (with optional attached AssociationClass) is a special rendering for binary Associations only...

Finally, there are some associations between the AssociationClass and other classes that aren't part of the Association that is embodied by the lozenge (for example those «attributive» associations belonging to additional attributes in the AssociationClass).  These are shown normally.

Does that clarify things?

HTH,
Paolo

[jeshaw2]

Paolo;
Yep, I'm a happy camper!
Thanks

[SF_lt]

Paolo, if don't use lozenge, then there would be 3 associations: logical-sourcefile, sourcefile-xmlemitter, xmlemitter-logical ?
in this way, lozenge would represent each participating classifier's connection with left classifiers (N*(N-1)/2)

Here's an example using more than two classes (or Classifiers)

[Paolo F Cantoni]

Paolo, if don't use lozenge, then there would be 3 associations: logical-sourcefile, sourcefile-xmlemitter, xmlemitter-logical ?
in this way, lozenge would represent each participating classifier's connection with left classifiers (N*(N-1)/2)

Yes and No...

Actually, since I posted this diagram, I've realised the actual example is wrong!  The wrongness has to do with Components and Artifacts as Classifiers and NOT instances.  But the incorrectness doesn't affect the explanation below if you consider the 3 boxes as normal classes.

Those of us from the Data Management arena recognize this as fourth and fifth normal forms.

Yes, there are three such associations, but their semantics are not what you may be expecting.  The three associations describe the rules:  Which Components can be associated with which Artifacts and which Artifacts can be associated with which Classes and which Classes can be associated with which Components.

But NONE of them express the ternary tuple: This Class is associated with this Artifact for this Component.  In other words, the lozenge is an intersector.

Naturally, the instance of the ternary tuple has to be in agreement with the rules (the three associations).

HTH,
Paolo

[jeshaw2]

Re: Your preference for the term Attribute Injection and more reciently Slot Injection [Ref: Properties, Attributes and Slots thread]. I've just had an Ah Ha! moment.  

Up till know I thought that (being 'Up side Down' from me   ), you were taking the name from the injection target (the attribute) instead of from the name of the injected object (a dependency)...

Now I comprehend that you are viewing the process at a higher abstraction level.  Attribute Injection allows anything to be injected, not just a dependency!  Further, Slot injection (a reference to an instantiated object) infers dynamic behavior rather than static structure.

What a concept!  What a lesson to learn in abstract reasoning!  

It seems reasonable now to support this static diagram with some type of behavioral diagram to model the injection process.  I'm also thinking that this modeling issue, which is so close to implementation level thinking, might be better diagrammed in an Object Diagram.  What do you think?

Now I'm interested in dealing with the need to model the XML artifact that supports the Declarative Dependency concept within the Spring Framework.  :-/

[Paolo F Cantoni]

Don't applaud... Just throw money!

Seriously though, now you see why I'm hooked on this abstraction lark...

The Ah Ha! moment you had, I have frequently...

When you find the right name for something, a lot of things "fall into place".

[size=13]“Names are the heart of programming.  In the past people believed knowing someone's true name gave them magical power over that person.  If you can think up the true name for something, you give yourself, and the people coming after, power over the code.  Don't laugh!
A name is the result of a long deep thought process about the ecology it lives in.  Only a programmer who understands the system as a whole can create a name that "fits" with the system. If the name is appropriate, everything fits together naturally, relationships are clear, meaning is derivable, and reasoning from common human expectations works as expected.”[/size] – Todd Hoff ([email protected], http://www.possibility.com/Tmh)

Paolo