Hi Mario, Many thanks for a great first-time post, and a great one at that. I have actually been on a course, probably about 8 years ago for UML OOA/ D at Rational, but, like most courses, I haven't used it since. Your reply therefore has been a great, compressed version of a rather dull course ;-)
There are a couple of pointers that I'd like to make about your reply, first is that I 'think' I'm reasonably comfortable with the various associations but using a rather different analogy hanging back to my C+ + days with pass-by-reference v pass-by-value. My understanding within that context was something along the lines of Association - Class A might include a 'import' to class B Aggregation - Class A has a 'reference' to class 'B', meaning that class B could have a life of it's own outside of class A Composition - Class A has a 'copy' / pass-by-value of Class 'B' and when class A dies, class B dies with it. So in theory, the differences are how long class B lives with the lifecycle of class A... but this is rather a mute point when it comes to Java, so your explanation bridges a gap in my transition for what I was taught 8 years ago to what I _think_ I remember from C++ and how it translates to Java. My biggest problem however, was not so much the different association types, but why they didn't affect the code generated until I added navigatability... this bit confused the hell out of me! For example, with navigatability from A <>------> B, class A ended up with an attribute of B. Without navigatability A<>------B neither classes had attributes. Perhaps I can create a short 5 minute video and post it on youtube to explain if my reply leaves you scratching your head, like I've been scratching mine! Thanks again Mario, your time in replying is very much appreciated. Kind regards, Rob. On May 1, 7:13 am, Mario Camou <[email protected]> wrote: > Hi Rob, and all, > First-time group participant, long time podcast listener. > > Let's get these in order: > > 1. One-way navigability from A to B (A ---> B) means you can get from class > A to class B. That means that if you have an object of class A, from it you > can get to the associated object of class B directly. Since the navigability > is one-way, you cannot get directly from B to A. In code this is reflected > as an attribute. If there is no navigability from B to A it means that B > doesn't have an attribute of type A. > > 2. Ah, the eternal confusion between association/aggregation/composition. > Reminds me of when I used to teach Object-Oriented Programming with UML as a > Sun instructor. First of all, you have to remember that UML diagrams are > used for more than just code generation. They are also part of the project's > documentation and thus will usually have information that is not necessarily > reflected directly in the code. > > The distinction between association, aggregation and composition is > sometimes vague and some sources even contradict each other (so if anyone > disagrees with what I am about to say...go ahead and post). > > The idea is that any relationship between classes is an association. > Aggregation is a "stronger" type of relationship than association, and > composition is even stronger. > > An aggregation relationship between two classes means that it's "whole-part" > relationship. The usual meaning is that you cannot have a "whole" object > (that's the class where the aggregation marker is) without it having a > "part" object associated with it. For example, if you have Car <>---> Engine > it means that a Car must have an Engine but there can be an Engine without > an associated Car (which usually translates into code as a constructor > parameter, an attribute and perhaps a getter). You could also change a Car's > Engine (by means of a setter). An example in code would be: > > public class Engine { > private int cylinders; > public Engine(int _cylinders) { > cylinders = _cylinders > } > public void start() { ... } > public void stop() { ... } > // ... the rest of the Engine class > > } > > public class Car { > private Engine engine; > public Car (Engine _engine) { > _engine = engine; > } > public void setEngine (Engine _engine) { > if (_engine == null) { > throw new IllegalArgumentException ("Engine cannot be null!"); > } > engine = _engine; > } > public Engine getEngine() { > return engine; > } > //... The rest of the Car class > > } > > Composition means additionally that the "whole" is fully responsible for > managing the "part" and that the "part" cannot exist without being > associated with a "whole". If you have Car <#>---> Engine, the Car class is > responsible for creating and managing the Engine object and the Engine > object is completely encapsulated within the Car object (you will usually > have a private Engine attribute and getters for the Engine properties in the > Car class. You might or might not have a public getter for the Engine > itself. The constructor for the Car class would receive the parameters > necessary to create an Engine). For example: > > public class Car { > private Engine engine; > public Car (int cylinders) { > engine = new Engine(cylinders); > } > public void startEngine() { > engine.start(); > } > public void stopEngine() { > engine.stop(); > } > // ... The rest of the Car class > > } > > The distinction between aggregation and composition is is not usually > reflected in tool-generated code tools because, while there is usually > one way of representing navigability that is correct in 90+% of cases (i.e., > by an attribute), there is no standard way of representing either > aggregation or composition (i.e., you could use constructor injection, or > setter injection, or calling the constructor from inside your class, etc.) > > 3 and 4. I have absolutely NO idea... > > Hope this helps, > -m. > > -- > I want to change the world but they won't give me the source code. > > On Fri, May 1, 2009 at 00:18, Rob Wilson <[email protected]> wrote: > > > Hi guys, > > > I have recently tried to use the Netbeans UML editor again, after not > > having much success before. I am having better success than last > > time, but I think I am suffering with a fundamental knowledge problem > > that is causing me to scratch my head a bit! > > > Within the UML editor I have dragged + dropped multiple classes and > > then tried to create relationships between them with combinations of > > non-navigatable, navigatable and association, aggregation and > > composition. When I do code-gen, only the navigatable ones end up > > creating code that I would expect, i.e. class A is navigatable to > > class B with an attribute, so class A has a line in it with 'Class A > > { B myClassB; }", whereas non-navigatable I get something like "Class > > A { }". > > > Here's an ascii view of what's going on ;-) where ----- indicates an > > association, <> indicates aggregation, <#> indicates composition, ----- > > > indicates navigatable. I show the results after generating code > > based on the UML... > > > A --------- B results in neither a or b referencing each other > > > A <>------- B ditto > > > A <#>------ B ditto > > > A --------> B result in A having a reference to B > > > A <>------> B ditto > > > A <#>-----> B ditto > > > My questions are > > > * Why do you need navigatability before attributes are created in the > > class? > > * What's the point in being able to choose association, aggregation or > > composition if the code gen does the same thing? > > * If I write class D in code that references class E, then create the > > UML diagram from the code, the diagram does not show the association / > > aggregations, why not? > > * Is it right that I've had to create two projects, one for the java > > code and one for the UML, syncing from the model to the code > > initially, then reverse engineering back to the model perioically and > > vice-versa. > > > Any help with these n00b questions would be very much appreciated. > > > Many thanks, > > Rob. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
