[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)

[John Buehler]

Ola Fosheim Grostad writes:

> John Buehler wrote:

>> The stability of a domain is absolutely an important part of
>> creating quality software.  This is true whether you're using
>> components or not.  Stability implies time, and time permits
>> understanding.  Lack of comprehension is the number one reason that
>> we have bugs (my own assertion).  Precise contracts are a claim
>> that both sides of a contractual interaction can know very specific
>> things about what's going to happen during that interaction.

> One may question if a zillion contracts written in OCL, and which
> most likely contain "bugs" themselves, are going to be very helpful
> in a system that should evolve to meet changing requirements.  Maybe
> it is better to have a good abstract model which supports the
> intuitive understanding the designers have of the domain. (OO) I
> believe that light methods like extremeprogramming is one step in
> the right direction for evolutionary projects. Now you even get
> editors that will abstract your source code into visual
> models. Better tools and extreme programming could become practical.

Note that producing a zillion contracts will certainly result in bugs.
Just as cranking out a zillion lines of code will.  Software takes
time so that the folks involved can understand what they're doing.  XP
is assuredly a step in the right direction because it addresses this
fundamental problem: domains must be understood.

But you see that I see XP as a step in the direction of solid
component-centric development.  XP may be the feasible next step in
that direction.  I'd just as soon save another 30 years of development
and hop right into components.

>> problem solving.  If standards had never evolved, we'd still be
>> writing assembly code and building applications no more complex
>> than a clock.

> This is another issue/level, which does not model the domain.

All I heard was a whooshing sound as this went over my head...

>> And this echoes the sentiments of the vast majority of the software
>> development community.  Taking the time to come up with precise
>> contracts takes too long, so we crank out code at a furious rate.
>> And that code is buggy.  But not buggy enough to annoy consumers.

> You don't need component-thinking to do separate testing of modules
> (units). Or to use invariants etc.

But if you do separate testing of units, you are doing a poor-man's
equivalent of what components offer.  What I'm trying to communicate
is the point that components are a distillation of what we already do
in a half-assed way.  To me, components are a bit like the physics of
software engineering.  At least, components permit us to establish
what one type of atom can be, and then a set of physics of software
engineering can be inferred from there.  It is only *a* set of
physics.  There may be other ways of tackling it, but I haven't seen
anything better than (or indeed fundamentally different from) the way
components were handled in that Microsoft research team.

>> There is nothing inherent in components that produces a performance
>> penalty.  Further, the inflexibility that you're referring to is
>> the same inflexibility that comes from having to use standardized
>> parts in any construction process.  Note that you're using standard
>> network protocols, standard schedulers, standard file systems, etc.

> Again this is irrelevant, and does not concern how you model the
> domain.  You are avoiding the problem which is indeed about
> dependencies within the model.

Domain modeling is the process of viable contract discovery.  Whether
you choose to embody those contracts in components or in some other
stucturing is orthogonal.  I argue that the component methodology
permits careful tracking of the contracts as they change so as to
avoid many/most design reconfiguration problems.

>> and our compilers help us to sort that out.  But changing the
>> behavior of a piece of software without informing the software that
>> uses it is not something that current tools support - yet such
>> things can be lethal on a non-trivial project.

> This is a tools discussion and not about wrapping up modules in a
> facade with a minimum of interdependencies and designing by
> specification.  It is quite possible that you have better tools for
> componentbased designs.

I apologize.  I must have completely misunderstood the crux of your
post.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev