Re: defining quality of OOA and OOD models

H. S. Lahman,

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

Yes... Many of these UML case tools also include some metrics, but I'm
looking for something that people actually use in their day-to-day work
to evaluate their models "just by looking at them"...

> 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).

Might be, but I see them as complementary techniques (though not with
definition of OOA that you are using) since RA has also evolved quite a
bit from just functional requirements. For example, use cases capture
and correlate functionality, behavior, and some of concepts that exist
in the problem domain. The very same way conceptual diagrams help us
understand and correlate some of functional requirements...

> 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

I really like much more that other term that you used before for what
you are referring to (Platform-Independent Model (PIM) or something).
Using the term "analysis" to mean "design" should, if nothing else, not
be used at least to avoid confusion. OOA that I'm referring to is
something that should be used to understand and communicate the problem
domain, and as such *might* be used as a solid starting point for
specifying PIM...

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

I was always having problems with "augmentation" in the sense you are
referring to - I have never been able to just augment at any level of
analysis or design - some things get cut out, some completely changed,
some stay as they are... I don't know much about MDA, and the things
might have changed, but I still have to stick with non-MDA
development...

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

So an extremely simple example: Have to make a small simulation that
among other things has a "customer queue".

In my OOA model, I would probably have a "customer queue" concept
linked to a "customer" concept. In my high-level OOD (which seems to
correspond to your OOA model), I would probably realize that I can just
use generic software design concept "queue" instead of "customer queue"
and link it to a "customer" class. Then I might realize that I don't
need a "customer" class at all but rather just some "time units" to
simulate time differences between customer arrivals... So more detailed
OOD model might have "queue" and "time interval" concept... Then when
programming, let's say in Python, this design model concepts "queue"
becomes a Python's list and "time interval" just an integer... Then if
there is a need to optimize, Python's list might become a C array and
Python's Integer might become C byte and both imported in the rest of
Python program... and so on...

So, as you can see, I do not expect OOA to translate to OOD and OOD to
OOP, but I still find that it is useful to model each concept at the
appropriate abstraction level and with a certain purpose. "Customer
queue" from the OOA model completely disappears later on, but its value
for the understanding of the problem in unquestionable... So, I am
curious, how would this simple problem be specified in MDA through
augmentation and translation?


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

Agree. Same could be said about completeness too if we define
completeness in terms of correctness, which you just did.

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

OK, thanks for feedback!

Davor

.

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
    ... What names would call the design activities ... It's not me who coined the terms to distinguish OOA and OOD activities. ... I can easily cite plenty of examples from classic OOA/D ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... >> My problem is not that there aren't defined techniques called OOA. ... >it is independent of any particular computing environment. ... >> define either OO or A) is about the customers problem, and OOD was ... it is no less a customer concern than any of the others. ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... >>levels of design: OOA, OOD, and OOP, each with its own concerns. ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... >>levels of design: OOA, OOD, and OOP, each with its own concerns. ...
    (comp.object)