Re: Let's put this to rest

AndyW wrote:
I think what is happening in this discussion is a mis-interpretation
of OOA. I think one person is viewing it as a model for viewing
the problem space and the other is viewing it as a model of the
potential problem solution.

I do see OOA model as "a model for viewing the problem space", but I'm
having hard time seeing an OOA model as *THE* problem solution - it
might be a source of inspiration for a solution, or in some cases even
a *potential* solution, but I would always separate it from the
*solution* model even in the case when they match. For example, in many
systems you'll recognize a "set", which is one of the basic natural and
mathematical structures, and I would include that "set" as a part of
OOA model for that system. My OOD model for the same system might
contain a "set" too that is a part of solution and directly capturing
what the "set" in OOA model is responsible for. Nevertheless, cases
such as this are quite rare in my opinion.


My question to this. How did you initially know that a stack was
required.

Well, lets say you have just designed a new programming language and
you ask me, as a contractor with some experience in building libraries,
to design an OO library of basic data structures for the use with your
new PL... Then I ask you what data structures do you exactlly want? You
say: stack, queue, double queue, etc...

Then I analyze what you are *requiring* me to provide you with and I
come up with the an OOA model which includes: stack, queue, double
queue, etc. (exactly the things you asked me for)...

Then I build an OOD model that consists of the very same entities:
stack, queue, double queue, etc.

So, I do not see what's the problem with this? This is a perfectly
*trivial* example in which if you came with different OOA and OOD
models you'd at best be called an eccentric if not something worse
:-)... and this is I guess where MDA would also work perfectly (since
getting "translational model" right in this case should be trivial)
thus matching how everyone works... at least for the OOA and
"high-level" OOD model... maybe moving to more concrete OOD model & OOP
will be harder for MDA-approach to match the traditional one, but we'll
see... I guess target implementation lang. should be decided on if they
want to follow through with this example...


I think that the only way you would know this is if you either
modelled an existing system that already constained a stack or you
conceptually added a stack to your model. I see this happen quite a
bit where developers are suplimenting their OOA model with their own
personal world view rather than working out what the real world view
is. It can be ok to do this, but I would mark it as an assumption
and append it to the risk management process for validation.

The other way I see it occuring is when people second guess the design
by adding design (OOD) entities to the OOA which I think is what H.S
Lahman is proposing was done above. Stack to me is an abstract term
refering to a specific design componant. If the existing system didnt
contain a stack (one could be analyizing a software entity) one could
recognise the pattern in the analysis model and perform the
substitution, but that I suspect would lead to grief.

.

Relevant Pages

  • Re: Lets put this to rest
    ... So what I have is an OOA model for a stack. ... containing a private reference to an array object. ... implementation language contains also support for dynamic arrays, ...
    (comp.object)
  • Re: Lets put this to rest
    ... So what I have is an OOA model for a stack. ... A stack is almost always an implementation artifact for an ordered collection. ... Whether one needs an ordered collection or not and how that ordering should be done, if needed, depends on what the problem being solved is, which you have not specified. ...
    (comp.object)
  • Re: Lets put this to rest
    ... So what I have is an OOA model for a stack. ... my stack OOA model is ready and waiting. ... I think one person is viewing it as a model for viewing ... The other way I see it occuring is when people second guess the design ...
    (comp.object)
  • Re: Lets put this to rest
    ... The CS101 stack. ... "translation OOA". ... So, an MDA ... developer was asked to demonstrate if his tool can compile a C++ ...
    (comp.object)
  • Re: Lets put this to rest
    ... of OOA. ... I think one person is viewing it as a model for viewing ... the problem space ... characteristc that must be implemented in the final system for it to ...
    (comp.object)