Re: Let's put this to rest
- From: "Davor" <davorss@xxxxxxxxx>
- Date: 13 Jun 2006 12:33:28 -0700
I did not have the opportunity to follow the discussions in this group
for quite some time, but I remember that we had a discussion that might
be related to this issue, and that is that you were interpreting
"analysis" as what I, and probably many others, see as some form of
"high-level design". To me they are, and always will be, different
activities. To give an example, let's say I want to reorganize my
workspace. I perform following activities that give me following sets
of data:
OOA = {desk, 6 pens, 3 notebooks, 1 cup, stapler}
So, OOA models is purely what I can observe in terms of
objects/concepts within my workspace that I'm analyzing.
[... skipping all functionality/goal related analysis that has to be
performed ...]
Abstracting OOA model and intersecting with functional/goal model =
{writing device}
OOD (high-level) = {computer, editor}
OOD (more concrete} = {desktop computer, monitor, keyboard, mouse, text
editor}
OOD (even more concrete} = {dell machine, samsung monitor, ibm
keyboard, ms mouse, vi-clone}
OOD (or what would be OOP} = {Dimension 1100, syncmaster 213, IBM Model
M keyboard, intellisense mouse, vim}
As you can see, for me there is a huge difference between OOA and OOD.
OOA models is a view into an "existing" domain system, and by no means
something that I would like to see in a system that I'm building or
even something that is supposed to be "correct" - in fact, it's more
often something that should be changed and something that we are moving
away from than a reliable foundation based on which we should build our
(new) system. This is also why I believe MDA (that I do not know much
about) and "translational ism" might work fine within OOD range of
activities and making models more concrete, but I'm having issues with
it when it comes to moving from OOA to OOD, as to me the main activity
for moving from OOA to OOD is *problem solving*, which I believe very
rarely or probably never can be equated with *translating*. So, if in
MDA you are really trying to move from OOA to OOD through "translation"
rather than "problem solving", maybe that is the problem and the cause
of the differences in the solution models (OOD)? Refering back to the
problem above, the "translation" move from OOA to OOD above would be:
OOD = {(slightly different) desk, (slightly different) 6 pens,
(slightly different) 3 notebooks, (slightly different) 1 cup, (slightly
different) stapler}
which is significantly different from the OOD solution above.
Davor
H. S. Lahman wrote:
Responding to Bob Martin...
In another thread you said:
"Sigh. HS, what you call OOA/D is not what most people call OOA/D.
What you call OOA/D has more to do with the particular religion of
translation (or should we say MDA)."
You haven't responded to my challenge in that thread, but I'm not going
to let you off that easily. You have made similar assertions several
times over the years and I am getting really tired of it because there
is no basis in fact for the assertion. So I want to settle this once
for all.
I want some demonstration of why the OOA/D that MDA-based
translationists practice is not the OOA/D that "most people" practice.
(Aside from the obvious use of translation automation for OOD/P.) We
could start a quote war by pulling quotes out of various OOA/D authors'
books but that is subject to interpretation, context, and other factors.
Fortunately there is a more objective way to resolve the dispute.
If there is some fundamental difference between the MDA/translation view
and "most people's", then that difference should be manifested in the
OOA models we produce. That is, for some problem the model that we
would produce would /always/ be different from the model that "most
people" would produce and that difference would be directly traceable to
some fundamental difference in design approaches.
The book "Executable UML" by Mellor and Balcer defines an MDA profile
for translation OOA modeling that is essentially the one I use. The
book has dozens of examples of real problem solutions. Similarly, Leon
Starr's "Executable UML: How to Build Class Models" has hundreds of
examples of Class Diagrams.
Here's my challenge: Find an example in one of those books where you can
demonstrate that a non-MDA/translation developer would always produce a
different OOA model because that developer has a fundamentally different
approach to OO software design.
*************
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
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- Follow-Ups:
- Re: Let's put this to rest
- From: Davor
- Re: Let's put this to rest
- From: H. S. Lahman
- Re: Let's put this to rest
- References:
- Let's put this to rest
- From: H. S. Lahman
- Let's put this to rest
- Prev by Date: Re: Let's put this to rest
- Next by Date: Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
- Previous by thread: Re: Let's put this to rest
- Next by thread: Re: Let's put this to rest
- Index(es):
Relevant Pages
|
