Re: UML Question (Object <-> ObjectFinder?)

Responding to Martin...

Two good rules of thumb when looking for an OOA/D book are: (1) ignore any book with 'UML' in the title and (2) ignore any book with a specific language in the title. 


Hmmm.  You mean like:  "UML for Java Programmers", Robert C. Martin,
Addison Wesley, 2003?

Exactly. It's on the other side of UML (implementation of UML -> Java) rather than the OOA/D side (problem space -> UML). It's a fine book for dependency management but that isn't very relevant for OOA/D. 


Which gets to the heart of the disagreement that you and I have had
for several years; which is:

Since we are both presenting papers at the Boston SD:BP this year, shall we resolve this by selecting seconds and having a duel? Might liven up the conference a bit.


1. You believe that there is a well-defined technique called OOA, and
I think that nobody agrees on what OOA is, and I doubt whether it even
exists as a discipline.  In our discussions, what you have called OOA,
to me is simply design.

You keep saying this despite the published definitions. There are several profiles for translation OOA in book form by several different authors (Mellor, Selic, Douglass, Wilkie, etc.). All of them share the same view that is quite specific about an OOA model (a) resolving all functional requirements (i.e., it is a complete solution for functional requirements), (b) the resolution can be validated by the same test suite as the final program (i.e., the model itself is executable), and (c) the solution being independent of any particular computing environment (e.g., a specific OOPL like Java).

As far as it being a discipline is concerned, code generators do what one says, not what one meant. Therefore producing a translation-quality OOA model that will unambiguously result in correct code generation for any computing environment requires a highly disciplined methodology. I'll take that even further: the translation methodologies require more discipline than any other form of OO development.


2. You believe that OOD and OOP are separate, and I think they are
inseparable.

For me, the "UML for Java Programmers" book *is* a book about OOD.
Indeed, the book expounds the 11 principles of OOD that I write about
so often. It talks about design patterns, and how to use them. It
presents a number of case studies that show how the design of
applications evolves through iterative implementation.

I never said that OOP does not involve design. However, there are three levels of design: OOA, OOD, and OOP, each with its own concerns. What you provide is primarily OOP level design. I'll give you design patterns as a valid reification of the problem space for both OOA and OOD. (Even then some patterns, like Visitor, would never appear in OOA/D and others, like Observer, would be very rare because they represent tactical implementation solutions.) But the book is mainly about your 11 principles for dependency management, which are mostly only relevant at the 3GL level. They solve the developer's problem of 3GL maintainability rather than the customer's problem, which is what OOA/D are exclusively about.

For example, the UML dependency relationship is not even included in the subset of UML defined by the MDA profiles for OOA translation models. (IMO, it should not be in UML at all because it leads to overspecification of the solution by usurping the prerogatives of OOP level design.)

I would also point out that IID has nothing to do with problem space abstraction, which is the core of OOA/D.


*************
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
(888)OOA-PATH



.

Relevant Pages

  • 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: Lets put this to rest
    ... say they are "design activities"). ... Note that since OMG is a standards organization, that indirectly gives substantial credence to the notion that an OOA and OOD are distinguished on the basis of problem space vs. computing space and functional vs. nonfunctional requirements. ... The original Booch notation was aka Graphical C++ in the early '80s, yet Booch was also involved in the development of UML in the '90s, which is used for both OOA and OOD. ... The construction of a transformation engine is nontrivial and requires a whole lot of solid software design. ...
    (comp.object)
  • Re: OOA and OOD
    ... OOA helps me determine if I have ... increasing numbers of hardware companies are adopting OOD/UML ... as a first phase of design but I really don;t care. ... And here we must be careful to avoid confusing UML and its ...
    (comp.object)
  • Re: OOA and OOD
    ... I think we have very different views of what a proper OOA model is. ... building an OOA model is a software design activity. ... >>least since UML added an abstract action language specification ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... >Responding to Martin... ... It's on the other side of UML ... I think that nobody agrees on what OOA is, and I doubt whether it even ... It talks about design patterns, ...
    (comp.object)