Re: defining quality of OOA and OOD models

Responding to Davor...

Model quality is probably best measured in terms of conformance to the
practices of an established OOA/D methodology.



sigh, might be true, though taking into account theoretical maturity of
OO, we should have hopefully by now measured how well different OOAD
methods fulfill certain quality standards rather than vice versa :-(

There are a couple of books on Amazon devoted specifically with OO metrics, many of which reflect some assessment of quality (dependency analysis, benchmarking "accepted" guidelines, etc.). Essentially those metrics are measuring conformance to accepted methodological practice.

Putting it another way, one uses OOA/D/P because one has specific goals in mind, such as long-term maintainability. (If all we cared about was rapid, intuitive development we would all be doing functional programming.) So my point was that measuring OOA/D quality (as opposed to design or software quality) necessarily reflects the paradigm itself and, consequently, the particular paradigm methodology.

An OOA model is complete when it executes correctly with respect to
functional requirements.  The exit criteria for OOD modeling is fuzzier
because one cannot validate most nonfunctional requirements without an
executable in hand.



might be just conventions but I like to think of OOA as something
tightly linked with RA and problem understanding - RA focusing more on
functional and nonfunctional requirements and OOA focusing more on
structural and conceptual properties of the domain system... OOA that
you are referring to - I like to think of it as OOD with all it's
different levels of abstraction, and what you refer to OOD - I refer to
it as software architecture again with many different levels of
abstraction and different "views"...

RA and OOA are quite different things. RA describes the problem (What must be done) while an OOA model describes the solution (How it should be done).

OOA, OOD, and OOP are just different aspects of solution design. OOA deals with only functional requirements and specifies the solution in a manner that is independent of local computing environment issues. (An acid test of an OOA model is that it could be unambiguously implemented without change as a manual system.) The OOD model augments the OOA solution by resolving nonfunctional requirements at a strategic level. The OOP model augments the OOD solution at a tactical level. Each design approach addresses different issues and employs different techniques (e.g., the problem space abstraction that dominates OOA is supplanted by 3GL dependency management during OOP). IOW, each design approach separates different design concerns (e.g., functional vs. nonfunctional requirements, customer vs. computing space views, strategic vs. tactical, etc.) in order to better manage complexity.


From your answer, I see that you use as a criteria 

1) completeness, and
2) correctness

In the interest of pickiness, I never regard correctness as a quality criteria. Correctness is just an exit criteria for a design activity. If the application doesn't work correctly, then it isn't finished yet. [Measuring things like released defects really monitors process quality rather than software quality. With a perfect development process no defects would be inserted in the software in the first place.]


and you correlate them tightly - presumably through the verification
using some model checker that will benchmark your specification with
respect to certain specified functional criteria. These two are
probably the ultimate criteria to what I perceive as OOD, and should
definitely be method independent.

Alas, you are talking to a translationist. B-) I only construct and validate OOA models. The OOD/P is completely automated by the transformation engine that eats the OOA model in a particular computing environment. So, apropos of the points above, the OOA /must/ be a validatable solution for the functional requirements. And creating such a model is certainly a software design activity. IOW, translation technology could not exist without the above definitions that depend upon the determinism of the computing space for OOD/P.

(BTW, if you respond, my response will take awhile; I am off on vacation for a week or so.)

*************
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: OOA?
    ... Responding to Kret... ... author's methodology are much more likely to view the book in a kindly ... I would look for a book with OOA and/or OOD in the title. ...
    (comp.object)
  • Re: defining quality of OOA and OOD models
    ... > practices of an established OOA/D methodology. ... > An OOA model is complete when it executes correctly with respect to ... The exit criteria for OOD modeling is fuzzier ...
    (comp.object)
  • Re: OOA and OOD
    ... >> I have some troubles to distinguish between OOA and OOD. ... I thought UML is used in design phase only. ... > OOA model is equivalent to a PIM under MDA. ...
    (comp.object)
  • Re: Lets put this to rest
    ... An OOA model is a complete solution specification for functional ... the OOA model does not describe how the application will be implemented in the computing space. ... At the same time, though, that Java program is clearly a concrete implementation of How the OOD specification will be met. ... There is also a useful separation of concerns that supports specialization, which becomes very obvious in translation where the application developer and transformation engine developer essentially belong to different unions. ...
    (comp.object)
  • Re: Lets put this to rest
    ... An OOA model is a complete solution specification for functional requirements. ... In MDA terms an OOA model maps to a Platform Independent Model because it does not depend on the particular computing environment where the application will be implemented. ... OOD is generally regarded as an elaboration of the OOA specification to deal with nonfunctional requirements at a strategic level. ... MDA you are really trying to move from OOA to OOD through "translation" ...
    (comp.object)