Re: Let's put this to rest

On Wed, 14 Jun 2006 16:30:15 +0100, "S Perryman" <a@xxxxx> wrote:

"H. S. Lahman" <h.lahman@xxxxxxxxxxx> wrote in message
news:DCVjg.15224$OQ2.708@xxxxxxxxxxx

Responding to Perryman...

That is all there is to it. Do what you must in order to define the above
using "translation OOA" ...

You are asking for an OOP class definition, not an OOA model. Stick to
the original challenge and find an example in either book that you can
demonstrate would be done differently by "most people" because of some
fundamental difference in design methodology.

1. Already done. In a few seconds. No problem whatsoever.
So what I have is an OOA model for a stack.
Free of implementation info. Implementable in any way a developer sees fit.

2. I have chosen a trivial, well-known example.
But an example that IMHO will be done differently by people who use a
fundamentally different method.

Once we have gone beyond the trivial, I have what IMHO is a more
stimulating book example to play with.

But until then, my stack OOA model is ready and waiting. When yours is
ready,
inform me and we can post to comp.object to compare/contrast.


Regards,
Steven Perryman

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.

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

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
    ... 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
    ... I think one person is viewing it as a model for viewing ... I do see OOA model as "a model for viewing the problem space", ... stack, queue, double queue, etc... ... come up with the an OOA model which includes: stack, queue, double ...
    (comp.object)
  • 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)