Re: Let's put this to rest

Responding to Davor...

As I indicated, that is the classic requirements analysis or SA/D/P
view. It is not the OO view. Do I really need to quote a bunch of
classic OOA/D books to demonstrate this?


I thought it's just a "common sense" view that:

problem != solution
problem analyzing != problem solving
analyzing != designing
analysis != design

But you are mapping a dictionary definition od SA/D/P view and ignoring the OO in OOA and OOD.

Let me turn it around. What names would call the design activities involved in (A) developing an abstract resolution of functional requirements in pure customer terms and (B) developing an abstract resolution of nonfunctional requirements in computing space terms? Both are high level design activities but it is crucial to the OO paradigm's step stone model that they be distinguished. So one needs different names for them. What would you call them?

So, yes again, I can follow what you are talking about, but I'm again
encouraging you not to use term "analysis" for what *you* semantically
equate with *design*...

It's not me who coined the terms to distinguish OOA and OOD activities. Brown's book is titled "Object-Oriented Analysis" and Rumbaugh's chapter heading where he presented the ATM solution is titled "Analysis". I can easily cite plenty of examples from classic OOA/D authors who provide a similar mapping of OOA to <abstract> solutions -- those were literally just the first two books I pulled out of my bookcase.

The only place where one sees the problem analysis view in OO literature is from the '70s and early '80s when authors were still migrating from the then-dominant SA/D/P view and getting their act together. In fact, the name OOA was chosen in no small part to provide a mapping between SA and OOA because both dealt with a problem space view. But OOA was still not the same thing as SA. The OO paradigm, particularly OOA/D has evolved a lot since then. (Note that Rumbaugh's book was published in '91 and Brown's in '95.)

Don't you find it so disturbing how many people cannot understand and
accept this basic idea of OO and apply it in their work? And, all that
is needed is to

1. underline nouns and produce OOA model
2. make 1-to-1 mapping of OOA model to OOD model to produce a good OOD
model (actually no need even to redraw it just claim OOA model is
really a design model since in OO world, according to some, analysis ==
design)

and underlining nouns and making 1-to-1 mappings are the part of
skill-set that most 1st or 2nd graders have ;-). So the only required
thing to produce good OOAD models is to provide your kids or grand-kids
with a problem description and you'll get back a perfect OOAD model!
:-)

Yes, I do find that simplistic view of OOA/D disturbing. To paraphrase G. B. Shaw on Christianity, the only trouble with OOA/D is that it hasn't been tried.

I suspect part of the disconnect lies in the roles of specification and
abstraction in the OO development continuum. Recall from the previous
message...

Requirements -> OOA Model -> OOD Model -> OOP Model -> Executable

^ ^
^ ^
^ ^
HARD AND "NON-OPTIMALY-TRANSLATABLE", IMHO!

Unfortunately I was around when BAL programmers used exactly that argument versus 3GLs in the early '60s. B-) We have two decades of commercial translation technology to demonstrate that it can be done. It's not easy and transformation engines are pricey because of that. But it is certainly routine today.

For OOD model and later stages, I'm much more optimistic about
"translation".
Of course, even in the first OOD paper, we had an algorithm for
straightforward "translation", but I simply do not accept it as *the*
way it should be done.

So, by any means, "translation" is always feasible, but "how well" can
we automate design experience and creativity in a problem domain
independent way is the question?

Another common translation is, n analysis objects - to - 1 design
object ;-)

Actually it is usually the other way around. Typically there are multiple ways to implement a given OOA artifact. One view of the mechanics of transformation is that it is a two-step process. One applies a mapping function to the semantic meta-models to determine a set of target representation artifacts that are viable and then applies some selection criteria to select the optimal target artifact from among that set. The former is rigidly deterministic once the semantic meta-models are defined. The selection criteria is the tricky part but it is still deterministic.

The creativity that you are concerned with then boils down to recognizing what the selection criteria is. To take a simple example, a 1:* relationship is typically implemented with a collection object at OOP time. But what sort of collect object? The answer to that depends on a large number of factors, such as: how big the collection may be; whether the number of elements is known and fixed; whether and how often elements are added or removed; whether the collection must be ordered; whether it will be accessed sequentially, by element identity, or by some attribute criteria -- to name just a few. (Some tool vendors provide dozens of model tags for 1:* relationships just to characterize the run-time context.)

The creativity lies in the transformation engine designer doing two things. The first is identifying all of the factors that influence the selection of a collection class. Those need to be represented in some abstract fashion as nonfunctional requirements. So, in effect, the engine designer needs to provide a UI that allows the user (an application developer) to express the nonfunctional requirements unambiguously in problem space terms. That, in itself, is a nontrivial design problem and there has been substantial evolution since the early '80s in that area.

The second is to provide a suite of rules for analyzing those characteristics that will optimize the selection for the computing environment in hand. That is a matter of nontrivial pattern recognition in the computing space and analysis skills. It also requires rather extensive knowledge of the available implementation mechanisms. Thus the engine designer usually needs to know exactly how library collection classes work internally to identify switch points between strategies.


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



.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... One also has to be careful about books with 'UML' or a specific OOPL in the title; they are good at describing how to express your design in the UML or OOPL syntax but they tend to be short on advice about coming up with a good design in the first place. ... The author has made clear in an early chapter that the book is about OOA, and what UML is introduced will serve that purpose. ... When we talked about things like hardware propagation delays before you didn't seem to think they were relevant (i.e., all the controller processing could be completed in a base clock tick interval (100 ms) in the real controller). ... But speaking of maintainability, if it were to be used in a real-time system with Timer reading the system clock rather than incrementing a counter, could it easily accomodate that? ...
    (comp.object)
  • Re: defining quality of OOA and OOD models
    ... must be done) while an OOA model describes the solution (How it should ... Using the term "analysis" to mean "design" should, if nothing else, not ... bridge the chasm between customer problem spaces and the computing ... the problem space abstraction that dominates OOA is ...
    (comp.object)
  • Re: Where to make tradeoffs in OOA/D
    ... point in design you would take a look at the technological ... However, in the OO paradigm, the OOA solution is pretty well-defined. ... So -- assuming that by 'technical requirements' you mean nonfunctional requirements on performance, size, security, etc. -- the answer to your question is that OOA does not address them at all, OOD provides a strategic resolution, and OOP provides a tactical resolution. ... For example lets take maintainabilty. ...
    (comp.object)
  • Re: Database Design & Normalization Question
    ... understand the logic behind the books, videos, software, ... didn't have to change the database design to store new ...
    (microsoft.public.sqlserver.server)
  • Re: OOA and OOD
    ... > I'm using OOA to analyze my requirements most folks I speak to ... Requirements analysis. ... >>reconciled with the notion that OOA is not a software design activity? ... like Rhapsody that use an augmented 3GL as an abstract action language ...
    (comp.object)