Re: Specifying physical dependencies in a MDA model
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/13/04
- Next message: Calum: "Re: Using iterators and efficiency."
- Previous message: Universe: "Re: OOA?"
- In reply to: Francois Tanguay: "Specifying physical dependencies in a MDA model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 13 Jan 2004 20:51:10 GMT
Responding to Tanguay...
> I just finished reading Executable UML: How to build Class Models and am
> ready to conquer the world, which is a really nice book btw.
Wouldn't it be great if it was just that easy. B-)
>
> I was wondering if we should be able to specify depedencies in a model. I
> mean since every association is binary, every class depends on every class
> on an analysis point of view.
The main problem with Starr's book is that it assumes a translation
approach, which is can be a problem for elaborationists. The MDA
profile for Starr's book is a subset of UML that doesn't not include OOD
elements. Since dependencies are almost exclusively an issue for OOP,
there is no need to specify them in a translation OOA model. (IMO,
there is no need to express them even in an OOD model.)
Another difficulty for elaborationists is that Starr does not include
behavior interface information in the Class Diagram. This doesn't
matter for translationists because all behaviors are invoked via events
so one has the Statecharts and Interaction Diagrams to define the
behavior interface.
[That's something I do not personally agree with because the existence
of the behavior is still static in nature (i.e., it always has an
interface) even though the behavior itself is dynamic. In addition,
since the interface is static it should be fully defined in the Class
Diagram, even if it is redundant information. However, adding the
behavior interface to the diagram by enumerating the events a class
accepts is hardly a taxing activity.]
>
> I'm curious as how the Model compiler will decide which physical depedencies
> should be created and which depedencies should be left out for the sake of
> reusability ?
The problem here is that the Class Diagram only represents the static
structure of the application. The actual navigation of the
relationships is described in the dynamic portion of the model. To
resolve the dependency issue one needs Interaction Diagrams or a
combination of state machines and abstract action language.
As far as leaving things out, that really isn't an issue. As you note,
the subset of notation is very spartan. The same is true for the
dynamic description. As a result there is nothing in the model that
isn't critical to the resolution of the functional requirements. So in
that sense, the model compiler can't leave anything out.
>
> Is it done by coloring the model in order to indicate which parts need to be
> reusable separatly and which aren't ?
>
> +-------+1 0..* +-------+
> | Client |------------------------------- | Loan |
> +-------+ is Contracted By Contracts +-------+
You might want to make sure you are drawing diagrams in a fixed font and
your mailer does not automatically convert to HTML format (usually
variable font default). B-)
>
> Since Loan class represents a class that contains calculations for the loan
> fees, amount, .... I'd like to make sure Loan can be reused without Client
> since it would make sense in a financial calculator which does not represent
> a client with a name, address, ....
As Chui points out, translation effectively does not do class level
reuse. Reuse is handled on the scale of subsystems. The application is
partitioned into subject matters and each subject matter is implemented
with classes that are tailored specifically to that subject matter. If
two subject matters abstract the same underlying entity the class
abstractions will represent unique views (e.g., the behaviors will be
different because the subject matters will deal with different
requirements).
However, that is a methodological issue for what one abstracts in a
class. There is nothing in the modeling techniques for a Class Diagram
that precludes modeling classes in a one-size-fits-all manner.
Essentially that just means bundling all the possible responsibilities
into one class. The interface to the class (synchronous knowledge
services and events) should be independent of particular client.
Note that a relationship in a Class Diagram doesn't describe individual
collaborations. That's because individual collaborations are inherently
dynamic while the Class Diagram is a static description. The Class
Diagram just describes the /structure/ that collaborations employ for
communication. There is nothing about reuse that could not be
explicitly provided by enumerating the interface events (Signals in UML)
in the Class box.
-----
Nonetheless, there is a reason why class level reuse never lived up to
the hubris of the '70s and early '80s. One abstracts a semantics for a
class in the form of responsibilities. For semantics of even modest
complexity one can access that semantics with multiple syntaxes. This
is analogous to writing the same program in two different 3GLs; the
solution semantics is the same but it is expressed with different syntax.
This leads to a problem because in a reuse situation the new client may
wish to access the service with a different syntax that the service
provides. If so, they can't communicate even though they both share
identical views of the semantics of what the service provides.
There are basically four solutions. One is to modify the client. That
simply won't work in a dynamic swapping situation and it would be highly
undesirable anyway -- clients shouldn't be affected by implementation
substitution. The second solution is to modify the service interface
for the new client. That can be rejected out of hand because it defeats
reuse. The third solution is to add a new interface to the service to
accommodate the new client. With a lot of reuse that will lead to more
interfaces that functionality quickly. In addition, one has problems
with consistency across multiple responsibilities. Finally, those
interfaces bloat the services for /all/ reuse contexts.
The fourth solution is a variation on the third. One provides a Facade
wrapper for the class that is tailored to the particular reuse
situation. This ensures consistency of access and eliminates bloat.
But it introduces a level of indirection that is usually prohibitive at
the class level in an OO application where classes are usually simple.
However, the performance hit for the Facade solution is usually not a
problem for large scale reuse at the subsystem level. So the
translation methodologies tended to embrace subsystem reuse long before
the notion of component engineering became PC. They have even developed
formal models for such subsystem Facades.
[Truth in advertising... Subsystem reuse in translation was more about
its origins in R-T/E than a conscious objective of large scale reuse.
R-T/E pioneered ideas like modularity and layering because they made
that unforgiving environment more survivable.]
*************
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
- Next message: Calum: "Re: Using iterators and efficiency."
- Previous message: Universe: "Re: OOA?"
- In reply to: Francois Tanguay: "Specifying physical dependencies in a MDA model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
