Hi again, Sorry for taking so long to reply. Things (a.k.a. "life") have been rather hectic.
Glad you found my post useful. Without reading the official UML specs I'm not sure if: 1) it's strictly a UML syntax error to have a composition/aggregation relationship without navigation 2) navigation should be implied or, 3) the fact that an object A is responsible for another's (B) lifecycle (in composition) or that A can't exist without a B (in aggregation) could also be represented in different ways (I'm thinking you could have, for example, a Map with object references and A would only have the key to the corresponding object in the Map, or something). If 1 or 2 are true, then it's a problem with NetBeans. -m. -- I want to change the world but they won't give me the source code. On Fri, May 1, 2009 at 22:06, Rob Wilson - BabyDuke JUG <[email protected]>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
