Re: UML: Associations between classes and packages

H. S. Lahman wrote: 
Responding to Kaeppler...

I don't use Java, so I can't comment specifically. However, since JFrame seems to be a realize infrastructure I would guess the best way to represent it would be as an architectural subsystem using the <<subsystem>> stereotype. That effectively encapsulates it as a single Component with an interface and attributes that the other classes can access. (In UML the <<subsystem>> is defined as a stereotype of Component, which, in turn, is derived from Class.)


That means I would have to introduce JFrame as a class?


No, it would be a subsystem. One view of a subsystem is that it is a class on steroids. All the same notions of encapsulation and implementation hiding apply as one accesses it through a single interface. The implementation of a subsystem is just so complicated that it is, itself, implemented with multiple classes. But those classes are hidden from the clients of the infrastructure.

The problem is, that someone could argue I would then also have to introduce Object (in Java it's the implicit base class of all classes) for the sake of completeness and I will soon find myself remodelling half of the Java platform.
That's why I asked, whether it's a good idea in general to model classes of the platform or not.


That depends one where you are standing in the modeling. Since an OOA model is, by definition, independent of the platform one would never see platform classes in an OOA model. Any interactions with platform entities would be abstracted as messages to external entities or by the OOA elements themselves. As an example of the latter, an OOA model knows nothing about distributed deployment so any infrastructure to support collaborations across distributed boundaries would not appear; one would just model simple messages.

One tends to do the same thing during OOD modeling because one is only dealing with a strategic view of the platform, which doesn't need a lot of detail. So much of the infrastructure would still be transparent in the abstractions. Depending on what services the infrastructure provides one might have specific manifestations of it, such as message data packets being expressed in terms of DAO objects for persistence access. But the overall abstraction would still be high (e.g., one can still view most of the infrastructure as realized implementation in a "black box" subsystem with which the rest of the application exchanges messages).


*************
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




I appreciate your detailed answers, but I'm not very proficient with all the terminology: What does OOA mean? I guess Object Oriented Architecture? And what would OOD and DAO mean?

--
Matthias Kaeppler
.

Relevant Pages