Re: UML inner/nested class associations

Responding to VisionSet...

Caveat. My response below is controversial because I do not like the direction that OMG is taking UML. There is a camp within OMG that is trying to make UML a tactical design tool so that one can express things like ActiveX implementations. I belong to the camp that believes UML is an OOA/D tool that should live at a higher level of abstraction (e.g., ActiveX is only one mechanism for implementing the OOA/D design logic so that should be left as a prerogative of OOP).

If you have an inner class that creates stateless objects then you can do
this in a number of ways.

1/ A nested class, Objects of the class can be composed attributes of outer
object.
2/ A nested class, Objects of the class are just instantiated in method
scope.
3/ An inner class declared in a method. Objects are just instantiated in
method scope.

In UML only 1/ can be shown as a composisition (?) association although the
designed effect is the same.

How can I legally show relationships in the other cases? At the moment I'm
using notes & note anchors. I was using the dotted instantiates/dependency
relationship, but I now realise that is misuse.
Can you show relationships for method local objects at all?

I expect the answer might be, 'this is what sequence diagrams are for'.

My short answer is: You don't need to.

Your three examples are all closely tied to 3GL context. At the OOA/D level in UML one doesn't really care which solution is used in the 3GL implementation. The fundamental logic of the solution will be the same regardless of which implementation is chosen. Choosing a specific implementation will depend upon things like language syntax, referential integrity context, programmer convenience, dependency management, and a bunch of other pure OOP issues.

So my answer is: solve the problem abstractly at the OOA/D level using natural problem space abstractions and don't worry about how it will be implemented at the 3GL level. So...


Also when naming associations, does the naming direction go in the direction
of a one way association by default? I believe you can have it in either
direction, but there is no visual way to indicate direction? How can you
read direction in 2 way associations? Also my names seem a bit over-long eg
'connects to database via'.

example here:
http://img126.imageshack.us/img126/5078/dao4bv.gif

Nested class is RowHandler, a locally used object is DAOException.

You have identified a suite of classes necessary to communicate with an RDB. Those classes will have natural collaborations as peers to convert the application view (presumably a game of some sort) into an RDB view. You can express those collaborations without worrying about how the objects will be implemented. The fundamental collaborations to convert views will be the same (and probably quite reusable across applications!)

The only reason you might want to use a composition association here is to specify a referential integrity constraint where one object's life cycle is tied to another's. For example, you might not want a DAOException object to exist beyond the life of a specific UserDao or GameDAO. (I have no idea whether that is true for your problem; the point is the problem context will dictate the composition constraint.) If there is such a life cycle constraint, then it will have to be honored at OOP time by implementing one of the three strategies above. Then (1) will probably require the least effort, but any of them could be made to enforce it.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: need your help!
    ... Relationships like Association, aggregation and composition. ... clients of A know that A uses B or they don't. ... so in this respect at least, UML is useless. ... Do Car objects send messages to Engine ...
    (comp.object)
  • Re: Aggregation vs composition
    ... >> with the concepts of aggregation and composition. ... >a uses relationship and an aggregation just by looking at the code. ... Before UML there was OMT with its uses, aggregation, & ... level concept that mapped down to cbv and cbr. ...
    (comp.object)
  • Re: Once again I am confused! [class diagram associations)
    ... and the wheels on a particular car are pretty well married for the long ... so you need to consider Composition. ... In the UML subsets used for OOA modeling neither aggregation nor ... Composition places restrictions on referential integrity in the OOP ...
    (comp.object)
  • Re: Aggregation vs composition
    ... aggregation and composition in UML are flawed concepts. ... > responsibility is shared because the object is shared. ... > may destroy the part. ...
    (comp.object)