Re: UML Question (Object <-> ObjectFinder?)

On Tue, 21 Jun 2005 20:01:47 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:

>Responding to Martin...
>
>>>>Since I consider OO to be a lower level concept related more to the
>>>>genus, than to the phylum, I have difficulty considering Mellor's
>>>>method as an OO technique. That's not a slur on it's utility; simply
>>>>a quibble about it's classification.
>>>
>>>We've been down this road before and I don't see that big a difference.
>>> All of the translation approaches tend to be more rigorous because
>>>they all talk to literal-minded code generators.
>>
>>
>> If seems to me that a compiler is also a literal minded code
>> generator. It also seems to me that the formality of one's language
>> is little evidence of the discipline of those who write it.
>
>I was referring the the context of doing OOA/D at the UML level in an
>elaboration process. Usually that is not done with the same
>methodological rigor as in a translation process. That's because one
>can fix things up when one gets to the OOP level where the compiler /is/
>literal-minded.

That's also why I don't do much of that. I completely agree that
slinging a bunch of UML around without getting feedback from an
executable is much less disciplined than actually having to make
something work.

>However, I can't buy your point here. When one abstracts an FSM from
>the problem space one is defining constraints on behavior sequencing
>that the software /must/ honor; IOW, those constraints are requirements.
> So one can't define them inefficiently; they are either correct or not.

I disagree. An FSM is a description of an algorithm. Indeed, it is
the definitive description of an algorithm (e.g. Turing machine). I
can, for example, create an FSM that describes a bubble sort, even
though it's a very inefficient algorithm.

It doesn't matter how high up you abstract this. In the end, an FSM
is an algorithm, not a requirement; a statement of how, not what.
Given the same requirement two people could come up with two
completely different FSMs to solve that problem; one could be simple
and efficient, and the other could be an inefficient mess.

>>
>> I would say that the SMOOA model is much more akin to the SASD genus,
>> than to OO of the Simula/Smalltalk/C++ genus.
>
>I don't know where you get this, though I suspect it is based comments
>you made years ago about SMOOA being based on data modeling.

I get this from the fact that the method is derived from the work that
Ward and Mellor did on SASD in the 80s.
>
>Bottom line: the distinguishing characteristic of the OO paradigm is
>problem space abstraction and SMOOA provides the richest view of
>abstraction around.

You aren't the only one to disagree with me on what OO is. Lots of
folks like to say that OO is about modeling the problem domain, or
modeling the real world, or modeling X, or modeling Y. I disagree.
IMHO OO is a set of low level tools for managing interdependencies
between source code entities. No more, no less.

I'm not saying that abstracting the problem space is not a good idea,
it is. I'm not saying that you cannot abstract the problem space
using OO languages, you can. But you can't really do it any better in
an OO language than you can in a procedural language. In the end it's
all just data structures and functions.

I'm also not saying that OO is insignificant, it is not. OO is a
great boon to software developer who need to keep their dependencies
under control (which is nearly everyone, and the rest will eventually
discover that they need it to).
>
>>>The acid test for an OOA model is that one could implement it
>>>unambiguously and without change as a manual system.
>>
>>
>> I could certainly do this with any C++ or Java program. People can
>> emulate the computing environment of those languages. And before you
>> laugh too loudly, consider:
>>
>> void Payroll::payCycle() {
>> foreach Employee e in EmployeeDataBase {
>> if (e.TodayIsPayday()) {
>> Money pay = e.CalculatePay();
>> e.DeliverPay(pay);
>> }
>> }
>> }
>>
>> This is legal syntax for C#, is executable by a C# compiler, and a
>> human could easily execute it manually. Moreover, given the right OO
>> structure for the Employee and EmployeeDatabase type, it is utterly
>> decoupled from all the lower level implementation details.
>
>You're right, it is nice computational specification for the world of
>Turing and von Neumann. But how to you get from here to, say, a
>one-write manual system? There is stuff that is ambiguous here for a
>manual context, such has who does this and when they do it. More to the
>point, this is just a detailed algorithmic computation; it would be
>specified pretty much the same way in any context. So it is a straw man.

No, this is not a strawman. I didn't set it up to knock it down. The
algorithm above is a very simple statement of a method for solving a
particular problem. It is abstract, isolated from implementation, and
could even be executed manually. Indeed, creating systems with this
much separation between the high level policies and the low level
details is what OO is *really* all about.

>The real problem solution lies in overall flow of control, which is all
>predicated here on 3GL block structuring, scope rules, procedural
>message passing, and a flock of other implementation details.

Any language that can execute has some underlying assumptions about
flow of control, including an SMOOA. The execution engine of an SMOOA
may assume that FSM events are asynchronous, but that's just another
kind of implementation detail. In any case, I can just as easily
create a high level description of a parallel process, or a process
based on asynchronous events, in C++, or Java.

>The flow
>of control for a manual system would have to be drastically modified to
>solve the same overall problem as the 3GL payroll /application/. Not to
>mention all that mickey mouse stuff around persistence, UIs, and
>solutions to nonfunctional requirements like concurrency and caching.

All that mickey mouse stuff is implementation detail that has nothing
to do with the high level business rules. Keeping those separate is
simply good design.

>3GLs are specific computing environment choices.

Any language that can execute must make certain specific assumptions
about the computing environment choices.

>Part of optimizing for
>the computing environment is selecting the best 3GL for the application.

The choice of language has much more to do with the programmers than
anything else. IMHO most business systems nowadays ought to be
written in Ruby or Python. It would take a third the time to write
them, and they'd be a lot easier to maintain. The that choice is
politically impossible at the moment.

A few systems are constrained to use a smaller subset of languages;
but even then the choice has more to do with what the programmers are
comfortable then anything else.

> The computing environment includes hardware platforms, OSes, 3GL
>languages, technologies (e.g., EJB, XML, XMI, SOAP, et al), practices
>(e.g., dependency management for 3GL maintainability), protocols (e.g.,
>TCP/IP), models (e.g., layered CRUD/USER models), paradigms (e.g.,
>transaction processing, client-server, RDM), etc. that are related to
>implementing software for execution on a computer.

I can run Java in my cell phone. I can run it in my PDA. I can run
it in little embedded real time devices. I'd be willing to bet that I
could find C++ compilers for most of the microprocessors and even some
of the DSPs out there. These languages run on a *lot* of different
platforms. So they are already very strongly decoupled from specific
platforms.

>> However, when you have a code generator the *point* is that you don't
>> have to pay any attention to the generated code. All the attention
>> goes into the source. And so the source becomes your "code", and is
>> the thing that must be maintained. And (this is the crux) the
>> problems of maintenance, structure, dependencies, etc, are not
>> automatically solved by the source syntax. There are rules and
>> principle, and design considerations for this new source code.
>
>The code part I agree with. I also agree models have to be maintained.
> But the rules, principles, and design considerations for doing so are
>just basic OOA methodology. There is no need for special rules and
>principles to deal with 3GL dependency management because there is no
>problem equivalent to 3GL physical coupling in an OOA model.

SO if you change one part of an OOA model (like the name of an event,
or the name of a field) you don't have to modify any other parts of
the model? Or if you change the protocol that some object expects to
communicate with, you don't have to change all the communicating
objects?
>
>> In short, you've moved the problem, not solved it.
>
>It may have moved, but it has also gotten a whole lot easier to deal
>with when the model is an order of magnitude more compact than 3GL code
>and one has full design reuse for nonfunctional requirements. B-))

IF (and I think it's a big IF) the OOA models are really much simpler
than the corresponding portions of a Java or Ruby system, then we'd be
getting somewhere. But I remain unconvinced that there is a
significant simplification.

>>
>> IID (Iterative and Incremental Development) *starts* by incrementally
>> and iteratively discovering the problem space. It was Fred Brooks who
>> said that the "specify-then-build" approach was at the heart of so
>> many software problems.
>
>So your position is that the only way to discover the problem space is
>by doing IID? You're being whimsical again.

No, I'm not. The most accurate way to discover the problem space is
to define and solve a sequence of very tiny pieces. To quote Fred
Brooks: "...it is the [] specify-then-build approach that lies at the
heart of so many [] software problems."

-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.

Relevant Pages

  • Re: UML Question (Object <-> ObjectFinder?)
    ... all language syntax that compiles without error enforces ... emulate the computing environment of those languages. ... and design considerations for this new source code. ... >> By defining the problem space in small increments, ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... all language syntax that compiles without error enforces ... the problem space one is defining constraints on behavior sequencing ... action language is at a sufficiently high level of abstraction so that ... emulate the computing environment of those languages. ...
    (comp.object)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... That's what problem space abstraction provides. ... customer: the one who specifies the requirements for the software ... my planned alterations to the compiler core should be able to ... one configured it with an external BNF description of the language to be ...
    (comp.object)
  • Re: UML Question (Object <-> ObjectFinder?)
    ... the problem space one is defining constraints on behavior sequencing that the software /must/ honor; ... An FSM is a description of an algorithm. ... abstraction around. ... an OO language than you can in a procedural language. ...
    (comp.object)
  • Re: OS Threads behavior
    ... > might run at higher priorities than your threads. ... >>I care about it, since I need it, "This answer is so famelies in Microsoft ... >> heavy tools in this language, the language does not support Hardware ... it's the OS the one who decide which thread to execute. ...
    (microsoft.public.dotnet.languages.csharp)