Re: Alternatives to Association Classes?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 03/05/04 

Date: Fri, 05 Mar 2004 16:50:49 GMT

Responding to Jackson...

>>The most common use of an association class is to qualify a *:*
>>relationship. In that context the association class captures the fact
>>that referential integrity cannot be unambiguously resolved as a scalar
>>attribute with a simple data domain in either participating class. IOW,
>>it is a place holder for another class that will reify the *:*
>>relationship into multiple 1:1 and/or 1:* relationships. (Note that
>>there are many ways to do such reifications, so one employs the
>>association class on a *:* when one wants to defer the reification
>>decision.) This is what Martin was talking about.
>
>
> Reification *decision*? Is that just a fancy way of saying you choose
> an association class to be the embodiment of the relationship, as
> opposed to the (more direct, class to class) alternative?

OK, that's one way to put it. It is common (in fact required in OOA
modeling) to defer the choice of which particular reification
implementation to use. Often it is deferred until OOP because the
decision may be based in part on tactical issues like what sorts of
library collection classes are available.

>
>
>>[What the forum debaters are dismissing is the notion that one needs the
>>*:* view rather than going directly to the reified view.
>
>
> Sorry, I've read this sentence > 20x now, and I still can't sort it
> out.

In OOA modeling one would /always/ leave the *:* association class as-is
because the reification choice is a design decision, not a problem space
decision. IOW, it will usually be dictated by nonfunctional
requirements like performance. If a shop values keeping the OOA models
even after the executable is produced, then replacing the *:* with a
reified version loses that implementation-independent context. The
debaters are effectively arguing that one should always go directly to
OOD modeling.

I would argue that there are situations where describing the reification
even in OOD represents design paralysis because one is usurping the
prerogatives of OOP to handle tactical decisions when the reification
decision is tactical in nature. So the debaters are also arguing that
one should over-design in the OOD in at least some cases.

[BTW, the debaters' position is very consistent with using round-trip
tools for OO development. The problem is that the only model such tools
can provide after the initial development is a low level OOD model that
overspecifies the OOP solution That's because such a model is the only
way to achieve 1:1 correspondence between the models and the code for
doing things like creating header files. This complete loss of
distinction between OOA/D/P is the Achilles Heel of round-trip
development when maintaining such systems in the long term. One cannot
distinguish functional requirements (OOA) from nonfunctional
requirements and computing space strategy (OOD) or tactical programming
(OOP).]

>
>
>>That might be
>>true if all one built were OOD models. However, Eclipse provides code
>>generation facilities so one would expect that the OOA view would be not
>>only desired but necessary.]
>
>
> You mean the UML representation of an association class. :-?

Right. You said your were using UML.

>
>
>>However, association classes have another use that can be applied to
>>associations with any multiplicity. In this case there are additional
>>properties of the relationship itself that cannot be captured in static
>>conditionality, multiplicity, roles, and OCL constraints. Typically
>>such association classes capture a behavioral responsibility needed in
>>the relationship context. Such properties can't go in either
>>participating class because it is intrinsic to the relationship rather
>>than the entities abstracted by the relationship classes. Those
>>properties need to be captured in a separate class accessible to anyone
>>navigating the relationship via a collaboration. This is what Ben was
>>talking about.
>>
>>Note that this second view exists regardless of what level of UML
>>modeling one is doing, so the argument that one should go directly to
>>the reification does not wash.
>
>
> Attempting to condense the above:
> <paraphrasing>
> |A|----->|C|------>|B| is not necessarily a good substitute for an association class.
> </paraphrasing>?

Not quite. It is always a good substitution for an association class at
the OOP level because the divide-and-conquer approach of reification to
complexity management will <almost> always make the code simpler and
more efficient. At worst the reification will be equivalent in those
respects.

So the issue is where (i.e., at what level of abstraction of the
solution) one wants to do the reification. Replacement is definitely a
no-no at the OOA level. It may or may not be a no-no at the OOD level.

>
> I hope I'm not being too naive in trying to make these abstract
> concepts concrete, but say:
> 1. I want to give a date and "registrationMedium" attribute to each
> "Registration" (which is, perhaps, the association class between
> Registrant and Event)?
> 2. I also want to restrict the Registrant to just one registration per
> Event.
>
> With these requirements in mind, doesn't "Registration" beg to be an
> association class? (Though an intermediate class might be what I have
> to settle for, given the limitation of the tool.)

There is insufficient problem context, here and in your original post,
to comment. What does the application do? What's being registered?
Why? What does an Event represent? What's a registrationMedium?

>
>
>>>One more question: I'm curious if anyone has any good references on
>>>approaches to persisting data with a RDB, as I'm stull fuzzy on how
>>>the DB interactivity ought to work with Objects.
>>
>>This is a very complex subject and it depends a lot on what sort of
>>support the Eclipse environment provides. I don't know much about
>>Eclipse specifically, but typically such tools depend on a specific
>>layered model along the lines of
>>
>>Presentation
>>-------------
>>Business
>>-------------
>>Persistence
>>
>>usually with a couple of other layers. The tool then provides a good
>>deal of automated infrastructure code to hide the mechanics of
>>presentation and persistence access.
>
>
> Whoa, it's news to me that a single tool can integrate and handle both
> the business and persistence layers. In fact I was even suprised to
> see Eclipse(UML) spitting out Java as I diagrammed. I'll have to check
> into Eclipse's functionality in that regard (persistence). If it
> provides anything, I'll be shocked.

Prepare for even greater shocks. B-) The entire RAD tool industry is
about doing exactly that for CRUD/USER pipeline applications (which are
quite common in IT). In addition, the translation-based approaches
provide 100% code generation from UML OOA models; the developer never
produces an OOD model or OOPL code. (I've been a translationist for
pushing two decades and I doubt I wrote 10 KLOC of OOPL code in the
entire decade before I retired.) However,...

>
> I was expecting references on how to (manually) code the business
> layer to interact with a RDB. I had no idea that folks would assume
> that I meant that I wondered how a specific *tool* handled it. If I'm
> interpreting the replies correctly, the tools are way more evolved
> than I thought. (Not that I could afford them, though.)

The degree of automation and number of tools isn't the issue. [BTW, one
thing OMG's MDA initiative is providing a standardization that will
allow tool specialization (e.g., drawing tool vs. code generator) and
full plug & play. Typically today's RAD environments like Delphi tend
to be monolithic with a single tool (actually several seamlessly
integrated in a single IDE, but all vendor proprietary.]

Layered model infrastructures like MVC, .NET, and J2EE support manual
development of applications. But in doing so they provide high-level
abstract representations of the layers and layer interfaces that the
developers access through APIs, name spaces, callbacks, and whatnot.
Those abstract representations hide the detailed processing and save the
developers from writing a lot of tedious detailed code.

Tools like Access, Delphi, and Eclipse raise the level of abstraction
abstraction even further. In Access the developer provides some
fragments of VB code for event callbacks but everything else is handled
without traditional coding. The downside is that Access is only useful
for relatively simple USER/CRUD applications. Delphi is more general so
a broader range of problems may be attacked and the developer does more
traditional programming. But most of the details are still pretty well
hidden.

My <quite limited> understanding of Eclipse is that it is intended to be
truly general purpose in the IT arena. So it also includes support for
modern round-trip development and even some translation-like code
generation beyond header files and body stubs. That would require that
the developer have access to both the high- and low-level
infrastructures. The expectation is that in most cases the easy
CRUD/USER stuff can be handled by Access-like high-level, abstract
facilities while one might have to get down-and-dirty in the low-level
infrastructure for more exotic processing.

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

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