Re: Let's put this to rest

On Tue, 20 Jun 2006 16:42:12 +0100, "S Perryman" <a@xxxxx> wrote:

"Robert Martin" <unclebob@xxxxxxxxxxxxxxxx> wrote in message
news:2006062010534584492-unclebob@xxxxxxxxxxxxxxxxxx

On 2006-06-15 11:55:12 -0400, "S Perryman" <a@xxxxx> said:

2. Does anyone on comp.object think that this :

1 R1 <<ordered>> *
[A] ---------------------- [B]

looks like UML specification for any stack entity that they have ever
seen
or used in a software system ??

Is this an appeal to popular opinion? I thought you wanted the
specification of a stack. The above is consistent with a stack; although
it leaves out the FIFO nature of a stack.

1. Then it is not a stack is it, if it cannot express the *LIFO* property.

That's what the 'ordered' means.

Consider in the standard template library for C++, you have the
concept of a container - something that holds something. The contents
are pulled out in random order unless some order is applied. Now look
at the diagram above. It's a container with order applied. Now look
at a stack, it's a container with order applied (LIFO/FIFO).

To me whether the container is a vector, dequeue, list, bit array,
set, map, bag, multi-set, hash-set, string, stack or queue is mostly
irrelevant in analysis and to the basic fact that they are always
containers with or without order.

As I have said in a couple of other posts - analysis is breaking
something down into component pieces - at what level you stop breaking
things down is related to the problem being solved and whether you
need to know if its FIFO or LIFO at analysis or can defer it until
design. Further decomposition can often be delayed until it is
required - often specifically to avoid creating an "implementation
constraint" which is a nasty thing to have when you don't yet have any
idea of what the implementation may be.
An example of where further decomposition can be delayed is a CRM
application processing customer requests. It's likely to be FIFO but
the actual policy can be left to design when that particular business
rule is decided by the customer - it may be they choose a priority
queue for special customers. An example of where it might not be
delayed is perhaps when one is performing analysis of a
telecommunications switch - its nature FIFO/LIFO is often fundamental
to its working.

To me, using a programmer defined term such as 'stack' is not only
creating an implementation constraint, but is likely to massively
harden the architecture because that concept will often flow thru
analysis to design without anyone asking the question 'why was it like
that'.

For myself I will often leave it in its generic state 'ordered
collection' and leave it up to the designers to ask the question -
what type of ordered collection is it to be.

If further decomposition is required because of the special nature of
the problem one might change the stereotype to either <<ordered fifo>>
or <<ordered lifo>> or <<ordered bag>>. But it seems to me doing so
relies on the designers having the smarts to ask whether that
constraint is carried forward to the new system, whereas leaving it
out kind of requires to ask what type it is and why (hopefully). I
would prefer not to use an implementation term like stack, instead I
would just leave it as the analysis pattern <<ordered xx>>

Also, I would suggest that humans use abstractions so that they don't
have to "sweat the detail" to use a well known term. This is one of
the tricks of analysis - knowing when to sweat and knowing when to
pass the buck to someone else - like a designer :

.

Relevant Pages

  • Re: Forth and OO design?
    ... cell circular data stack ... return stack index register ... No, that is not design. ... language which became the bastardized basis of Javascript. ...
    (comp.lang.forth)
  • Re: Zero operand CPUs
    ... the stack in on-chip RAM, ... the oldest part of it to main memory, ... based on how many cells are cached in registers. ... do to simplify the design to reduce cost and power use and increase ...
    (comp.arch.embedded)
  • Re: Simple Adapter Pattern Question
    ... interface Stack. ... Remember that design patterns exist to extract the invariants of solutions to common design issues. ... It is more complicated and one needs some sort of decoupling or dynamic behavior substitution in the collaboration that depends on context within the particular problem domain. ...
    (comp.software.patterns)
  • Re: Tiny CPUs in programmable logic
    ... The B16 is a like my CPU ... My numbers were from a design done in an ACEX 1K. ... mode which was used for the main memory block while sync rams were ... computation, mostly from the return stack pointer arithmetic, IIRC. ...
    (comp.lang.forth)
  • Re: Lets put this to rest
    ... Lahman was asked to produce a CS101 stack in fair time. ... fundamentally different approach to OO software design. ... "producing a stack" is purely a design thing but you refer to doing it ... My suggestion, in that to correctly answer the original question, one ...
    (comp.object)