[MUD-Dev] Re: TECH: reliablity (was: Distributed Muds)
johnbue at msn.com
Thu May 3 13:09:42 New Zealand Standard Time 2001
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
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev