Modeling Dependency Injection

[jeshaw2]

Dependency Injection is becoming popular.  How are UML modelers diagramming composite classes having a dependency that is injected lets say with a setter method call?

For example, I tried reverse engineering this code:

Code: [Select]


// In Manager.java

public class Manager {

   public static void main() {

       Wheel aWheel = new Wheel();

       Car myCar = new Car(aWheel);  // Note the injection of a Wheel during construction of myCar
   }
}

// In Car.java

public class Car {

   Wheel myWheel;

   public Car(Wheel aWheel) {myWheel = aWheel;}

   private void rotate () {};
}

// In Wheel.java

public class Wheel {

   private int diameter;
   
   public void setDiameter (int dia) {diameter = dia;}
}

What I got was


I don't know why the Manager's associations were not modeled...

Anyway, this is a simple example of what I mean by dependency injection.  Car is a composite structure having an internal structure consisting of aWheel.  I don't get that sense from the diagram.  But I don't know how to diagram that better.  Yes, I can draw a Composit Structure diagram, but how do I show the dynamics of the dependency injection?  Is an Activity diagram the only way to show the dynamics of the injection?

[thomaskilian]

I'm not really a Java expert, but obviously there is no dependency from Manager to somewhere else. It only has a single method.

[Paolo F Cantoni]

Folks,

We have to be very careful with our language here...

There ARE Dependencies between Manager and the other classes, there are NO (binary) Associations...

That's why the process is called dependency injection!

The reason why the dependencies Jim was expecting aren't modelled is that EA doesn't reverse engineer dependencies within the body of an operation.  That doesn't mean, as we have seen, that they aren't there; it's just that EA doesn't see them.

Another reason why round-trip-engineering from model to code only and back CAN'T work.  Technically, there is insufficient metadata to allow EA to make the right decision, even if it was inclined to.

HTH,
Paolo

[jeshaw2]

For those not familiar with Java, Consider the following code:

private Wheel myWheel = new(Wheel);
private Car myCar = new Car(myWheel);

The first line declares a reference variable myWheel to be of type Wheel.  It then initalizes that variable with the expression 'new(Wheel)' by calling the Wheel constructor.  This won't work if the Wheel class is not available.  I think this to be a dependency.

The second line of code does a similar thing for myCar, however the Car constructor is passed the reference to myWheel; this injects a Wheel depenceny into myCar (ref: above code) and adds a second dependency (Car) to Manager.

Paolo;
OK, let's start with these definitions from the UML Infrastructure spec.:

association
A relationship that may occur between instances of classifiers.
link
A semantic connection among a tuple of objects. An instance of an association. See: association.
dependency
A relationship between two modeling elements, in which a change to one modeling element (the independent
element) will affect the other modeling element (the dependent element).
message
A specification of the conveyance of information from one instance to another, with the expectation that activity will ensue. A message may specify the raising of a signal or the call of an operation.
relationship
An abstract concept that specifies some kind of connection between elements. Examples of relationships include associations and generalizations.

Now help me out here... Are you saying that a message from Manager to Car establishes a relationship between them without that relationship being an association?

PS:  I'm not really conserned about EA's round-trip issues,  I just tried that to see if that would shed any light on this issue of UML diagramming techniques for dependency injection.

[Paolo F Cantoni]

[

[size=13][SNIP][/size]
Now help me out here... Are you saying that a message from Manager to Car establishes a relationship between them without that relationship being an association?

To paraphrase Dr McCoy from from Star Trek, "Yes Jim, it's an Association, but not as we know it!"

UML states explicitly that a named navigable association end IS an attribute.  Therefore, a (binary)  Association is about static structure.  Thus, in your initial example, Car has an explicit attribute member, MyWheel which establishes the Association shown in the diagram, for the reasons above.

So what ARE the relationships when Manager uses other classes to do it's job?  Well, what is an Injector?  "I direct a second party to be aware of (associated with) a third party..." How does that sound?

If you like that, then you have a ternary - not binary relationship between three Classifiers.  I'd model it as such...
I'd stereotype the Association "lozenge" as "setter injection", stereotype the AssociationEnd between the lozenge and Manager as "injector", the AssociationEnd between the lozenge and Wheel as "injection" and the AssociationEnd between the lozenge and Car as "injectee".
You can thus read the Association narratively as: "Manager is the injector that injects Wheel into Car".  

From a "compilable model" point of view, it would be a constraint that when you create a ternary Association with such stereotyping, there must also exist a binary Association (attributive) from the injectee to injection.

I have a similar problem when I'm creating code artifacts for source components using my interface:  I have to follow a ternary Association from the component to the Artifact and Class ("For this Component I require the following Class to be in that Artifact.")

BTW: Yesterday (now) I emitted my first operation body, having got around a problem with CodeDOM not understanding the difference between a string and an symbolic literal.. :-)

HTH,
Paolo

BTW, in the absence of the ternary Association, you can do it with a LOT of cross-dependencies...  That's why I made the first statement in the original post...

[Paolo F Cantoni]

[size=13][SNIP][/size]
From a "compilable model" point of view, it would be a constraint that when you create a ternary Association with such stereotyping, there must also exist a binary Association (attributive) from the injectee to injection.
[size=13][SNIP][/size]

A further simplification is possible, but Jim, if you'll humour me, I'll leave it as an exercise for the reader...  

You'll have gathered by now that Dependency Injection may not be the best term for what's going on here...  Attribute Injection may be a better term...

Paolo

[jeshaw2]

Paolo;
Your approach is interesting; I may comment on it later.

I posted this same question on the Spring Forum and got a reply you might find  interesting:

I encounter similar problem recently. As far as I know, there is no some standard DI modeling techniques. Stil, there is one article on DevX which talks a little about this.

Anyway, I introduce my own solution. If you look at what is really important regarding DI when you look at some class diagram, you will quickly realize that all you really need to know is that some directed association is satisfied (injected) by external entity (lightweight container). In that respect, all you need to do is marking an association with appropriate custom stereotype i.e. <<injected>>. Anybody who knows meaning of this stereotype will immediately realize that this association is injected in object and that object in question doesn't need to implement code for dependency instantiation or lookup.

Hope this help.

Damir Murat

The article referenced is : http://www.devx.com/Java/Article/27583/0/page/1
If you can't see the figures in the article clearly, click on them to open the figure in a larger window.

Both approaches seems to make sense to me.  The mentioned Service Configurator is in a separate package containing the IoC framework (E.g.; Spring).  What do you think of this UML notation?



The Spring package takes the place of the Manager class in my earlier post.

Perhaps this diagram should be done as an object diagram instead of a class diagram?

[Paolo F Cantoni]

Paolo;
Your approach is interesting; I may comment on it later.
[size=13][SNIP][/size]

You can if you like, but you already have...
Elsewhere in the Forums I have asserted that in my view the UML Association "Lozenge: IS the AssociationClass.
Given that is the case (I don't make such assertions lightly...  ) Then the AssociationClass you show (ServiceConfigurator) is my lozenge.  
NOTE: the simplification I mentioned as an exercise for the reader was to reduce the number of Associations to only one... (Which you've now done!)

My preference would be to change the stereotype for the (binary) Association to «injected».  Also, I would remove the "Constructor" name of the Association and make it a TargetEnd Constraint {OnConstruction}.  If you intended the injection to ONLY occur on construction, then I'd set the Changeability of the TargetEnd to {addOnly}.

Once you do that, the only thing to add to your solution is to stereotype ServiceConfigurator as «XXXInjector».  This tells you to write the code for ServiceConfigurator as the appropriate Injector Type (a Setter, Constructor or Interface Injector). In your example, this is still a Setter right?

Paolo

[jeshaw2]

I'm on my way to work, so quickly...

I'm not familiar with your term lozenge. In my dictionary it is a medicated piece of candy or a rhombus.

I didn't mean to give the association a name.  That was a text element I added to the <<injected>> label to indicate 'by Construction'.  I slid them both into an ambiguous location on the diagram to avoid having them overlaying a line and thus being obscured.

Cheers

[Paolo F Cantoni]

[size=13][SNIP][/size]
I'm not familiar with your term lozenge. In my dictionary it is a medicated piece of candy or a rhombus.
[size=13][SNIP][/size]

OK...    Formally, the Association "lozenge" is the Chen-style rhombus located beneath the Table Element on the Structure Tool Set.  It is the mechanism to model a generalized n-ary Association.

It is my contention that this "thing" is also the AssociationClass.  It's just a different rendering...

Cheerz,
Paolo

[jeshaw2]

Elsewhere in the Forums I have asserted that in my view the UML Association "Lozenge: IS the AssociationClass.

 Is there a search keyword that would bring me to those threads?  I'd like to review your comments before I voice my thoughts on the minor differences that I see between them.

My preference would be to change the stereotype for the (binary) Association to «injected».  Also, I would remove the "Constructor" name of the Association and make it a TargetEnd Constraint {OnConstruction}.  If you intended the injection to ONLY occur on construction, then I'd set the Changeability of the TargetEnd to {addOnly}.
 
Once you do that, the only thing to add to your solution is to stereotype ServiceConfigurator as «XXXInjector».  This tells you to write the code for ServiceConfigurator as the appropriate Injector Type (a Setter, Constructor or Interface Injector). In your example, this is still a Setter right?

I agree with all of this, except in my example the setting was done during a call to the constructor method rather than a call to a setter method.  Just a minor difference.  And since the association is a depencency (albeit injected), I'd like to consider using a dashed line rather than the solid line that appears between car and wheel.

My next step is to replace the Wheel Class with a Wheel Interface and model the ability of the ServiceConfigurator to supply a specific type of wheel as needed by the business environment Du Jour.  

Then, onto modeling dynamic dependency update operations.  That is, Car is programmed to a CarEngine interface.  Now, accelerating from a green light in the city requires use of a FamilyCarEngine, but accelerating from the green light at the Saturday night drag strip requires use of my RaceCarEngine, then a quick switch back to the FamilyCarEngine to drive my wife back home again.    Both the FamilyCarEngine and the RaceCarEngine implement a CarEngine interface.

[Paolo F Cantoni]

 Is there a search keyword that would bring me to those threads?  I'd like to review your comments before I voice my thoughts on the minor differences that I see between them.[size=13][SNIP][/size]
.

Lozenge works really well...  

Paolo

[SF_lt]

let's stray a bit:

Paolo, could you post here any class diagram with the N-ary association notation (lozenge :-D) car, wheel and container example would be fine and follow idea

I had difficulties to use this element with it in the past...

[Paolo F Cantoni]

SF,
Is this what you mean?

I have duplicated Jim's diagram and showed the equivalent using the Association "lozenge".

NOTE: the two associations shown are stereotyped «end» to show they are the AssociationEnds shown in the other rendering.  In a sense, they correspond to the dotted line with the AssociationClass.

The Association and AssociationClass may have additional Associations they participate in and I feel it is important to differentiate those from these ones.

HTH,
Paolo

[SF_lt]

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).