Re: Association vs Dependency
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/03/04
- Next message: Topmind: "Re: Unix and OO Avoidance"
- Previous message: ShriKant Vashishtha: "Re: Collection vs well defined transfer objects"
- In reply to: Robert C. Martin: "Re: Association vs Dependency"
- Next in thread: Michael G: "Re: Association vs Dependency"
- Reply: Michael G: "Re: Association vs Dependency"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 03 Jan 2004 19:33:50 GMT
Responding to Martin...
>>Basically I see the following division of concerns:
>>
>>OOA -- the implementation-independent solution of functional
>>requirements. This is the customer's view of the solution if it were
>>implemented as a manual system (i.e., w/o computers).
>
>
> How do you justify the OO prefix here. The definition you have
> provided is one of the more common definitions of "analysis". What
> does OO have to do with it?
One uses the kernel OO practices: abstraction, encapsulation, separation
of message and method, etc., etc. The OOA model is the purest form of
OO expression.
>
> Also, a small quibble, there are many systems in which the use of a
> computer completely changes the work flow. In those systems you
> should *not* analyze how you would implement it as a manual system.
Such changes are an accommodation to a better solution than the manual
one _for a given problem_. That's a trade-off that the customer makes
in accepting the software solution rather than a manual solution to the
problem.
Problem: get from Boston to Miami.
Manual solution: walk
Automated solution: fly on a commercial airline
Taking a plane requires a whole lot of peripheral practices that aren't
required for walking. But since my days as a field geophysicist are
long gone, odds are I'll take the plane anyhow.
>
>
>>OOD -- the strategic solution of nonfunctional requirements. This is
>>all the high level strategy stuff around caching, distributed
>>boundaries, stateless server objects, and the like.
>
>
> This is the one of the most bizarre aspects of the SM method. Design
> has been relegated to "the other side of the tracks". Design is only
> about the stuff that's not part of the problem domain. Persistence,
> IPC, caching, etc. That's just strange. IMHO the design of a system
> is the shape of that system, and it is inextricably bound to the
> problem being solved.
No. Design is about (a) resolving nonfunctional requirements and (b)
converting an OOA solution specification into a computing environment
solution specification.
Functional Nonfunctional
Requirements Requirements
| |
V |
OOA Model |
| |
V |
OOD Model <--------------+
|
V
3GL Code
|
V
Object Binary
|
V
Loaded Executable
Every work product (concrete or mental image) above Loaded Executable is
a specification for some specialized activity below it. Every work
product below Requirements is a solution for the specification
immediately above. Every "->" is an activity that requires a
specialized domain knowledge.
The unique thing about the computing space is that it is highly
deterministic because it is a bottom-up representation of the
computational model so it reflects the same mathematical rigor as the
computer hardware. As a result we have already automated some of the
specialized skill sets with loaders, linkers, and 3GL compilers. In
quite a few specialized arenas we have automated building 3GL Code with
things like GUI builders and RAD IDEs. Translation provides the
technology to automate generation of both the OOD and 3GL Code.
That sort of automation is enabled by the rigor of the computational
model. But it is also enabled by the relatively narrow definition of
the problem space for each activity. Applications are routinely
partitioned based upon subject matter. Why not subdivide the computing
space in the same manner?
Building a 3GL compiler is a unique problem domain. One creates a 3GL
and/or Assembly program to do so, but that is incidental. It requires a
completely different domain expertise than, say, building an inventory
control application. Yet the paradigms of compiler building are largely
common across languages and platforms. So why shouldn't one separate
the problem space of 3GL compiler building from the problem space of OOD
specification?
Is not designing for performance in database access a specialized
problem space that requires a unique domain expertise? Doesn't the
selection and design around a network architecture require special
domain knowledge for a distributed system? Aren't those things
substitutable across different applications (i.e., independent of
particular functional solutions)?
You are on record for agreeing that things like persistence access
within an application should be decoupled through encapsulation. How do
you reconcile that view with the view that the unique OOA/D/P problem
spaces should not be decoupled?
>
> Again, what justifies your use of the "OO" prefix in your definition
> of design. It seems to me that definition, though bizarre, could
> stand on its own without the help of OO.
Like everything else in OO development, there is nothing really new
here. Long before OO development we had SA, SD, and SP. The notion
that there were multiple subject matters and levels of abstraction in
the computing space is hardly a new concept.
The main thing OO development brings to the table is a package that ties
things together better. For example, OO employs abstraction as a tool
for seamless scaling. Instead of a suite of independent diagrams with
no direct links in SA/SD we have basically the same notation carried
through OOA/D and that notation is, for the most part, almost trivially
mappable into OOPL constructs. More important, it is mappable at every
level of construct, not just large scale (procedure/file/task) modularity.
>
>
>>OOP -- the tactical solution of nonfunctional requirements. This is
>>where one deals with CORBA vs. .NET infrastructures, SQL, state
>>expressed as XML, exception handlers, what sorts of collection classes
>>one employs to implement relationships with multiple participants, and
>>whatnot. In particular one deals with the vagaries of particular languages.
>
>
> This is an even more bizarre definition IMHO. How can programming be
> about NON-functional requirements. Programming is all about FUNCTION.
Nonfunctional requirements are those that do not affect the correctness
of the application. The Big Two are performance and size. However, one
can have nonfunctional requirements that dictate things like distributed
system boundaries. Design, OO or otherwise, has /always/ been about
addressing nonfunctional requirements at a strategic (architectural) level.
Similarly, programming, OO or otherwise, has /always/ been about
tactical solutions for nonfunctional requirements. I can even remember
coding "x = a + a + a" in FORTRAN because the compiler was too dumb to
know that two additions was faster than one multiplication by 3. Tell
me how that doesn't require special domain expertise to do programming
compared to analyzing or designing the overall solution.
>
> I understand the SM scheme, but think that the choice of definitions
> is very strange. IMHO what you call OOA is really programming in a
> higher level language that has nothing to do with OO. What you call
> OOD is really just the creation of a suite of utilities that the high
> level program uses.
>
> I'm not trying to slam the SM approach. I find that approach
> interesting in many ways. However I don't like the way the approach
> tries to hijack the OO prefix. I don't see any OO in the approach.
> What I see is an attempt to create a high level graphical programming
> language based upon data structures and finite state machines. And a
> very laudable attempt to separate high level problem domain concerns
> from low level computation domain concerns.
You've been reading my missives for nearly two decades now on various
forums. We may disagree about stuff like using dynamic_downcast, but do
you really think that my arguments are based on something other than
basic OOA/D principles? When I put up models for newbies, do you really
suggest that they aren't OO models?
If not, then where do you think I am getting this stuff?!? B-) The
only methodology I've used for over a decade is S-M or the MBSE variant.
Aside for a brief foray using Booch in the '80s, I don't know anything
about other OOA/D methodologies other than from Executive Summaries. If
I am getting this stuff from S-M, then how could S-M be "hijacking" the
OO prefix?
More specifically, as far as data structures are concerned, I know of no
other OOA/D methodology that is further from traditional Data Modeling
than S-M. For one thing, S-M /requires/ the attributes be defined as
ADTs and the methodology makes a big deal about consistency in level of
abstraction of ADTs within a subject matter. I also know of no other
methodology that emphasizes using relationships to encode rules and
policies. (How many other people on this forum advocate eliminating
conditionality on relationship ends rather than leaving the rules to be
encoded in methods?)
As far as state machines are concerned, S-M uses them because they
/enforce/ good class and behavior encapsulation. You simply can't get
object state machines to interact correctly unless classes are cohesive
and behaviors are properly encapsulated. (Lurker Corollary: once one
gets the class abstractions right, state machines become pretty trivial
to construct.)
Speaking of that, I know of no other OO methodology that takes the
distinction between knowledge and behavior responsibilities as seriously
as S-M does. While that is driven by the need to be rigorous about data
and referential integrity in the specification for a code generator, it
still enforces classic OO ideas.
Bottom line: it seems to me that S-M is pretty much a parade leader
insofar as putting together a consistent package of fundamentals that
distinguish OO development from other approaches.
*************
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: Topmind: "Re: Unix and OO Avoidance"
- Previous message: ShriKant Vashishtha: "Re: Collection vs well defined transfer objects"
- In reply to: Robert C. Martin: "Re: Association vs Dependency"
- Next in thread: Michael G: "Re: Association vs Dependency"
- Reply: Michael G: "Re: Association vs Dependency"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
