RE: Closing on NIM requirements

["Andrea Westerinen" <andreawest@mindspring.com>]

I think that we agree.  The caution is to decide whether tire composition is
important and to what level.  If not important, cool - lose it.  If
important, but only to the extent of "rubber", "synthetic", "biological",
"other" - then this is a valid enumeration that can be expanded later, when
absolutely necessary.  If important to understand the exact chemical
composition, then I would not make it an enumeration but a chemical formula.

The data/relationships/methods must be modeled enough, but not too much.
So, I always start with the problems being solved (requirements), and move
to the nouns and verbs.  I never start with a predefined model in mind.

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> Randy Bush
> Sent: Monday, April 17, 2000 11:20 PM
> To: Andrea Westerinen
> Cc: Harald Tveit Alvestrand; Durham, David; 'John Strassner'; 'Weiss,
> Walter'; nim@ops.ietf.org
> Subject: RE: Closing on NIM requirements
>
>
> > Totally agree but we need the right data, relationships AND
> methods.  IMHO,
> > a tire may be modeled with:
> > - an enumeration indicating composition (perhaps to understand
> lifetime and
> > traction)
> > - an integer indicating CurrentPressure (to understand if it is
> flat or not)
> > - a gauge of RotationsPerMinute to guarantee that legal speeds are not
> > exceeded
> > - a relationship to other objects like the hub/axle to which it
> is attached,
> > or if not important the car to which the ticket is issued when
> legal speeds
> > are exceeded
> > - a method like "uint32 Refill([INPUT] AmountOfPressure)" when tires are
> > high availability items that can be refilled based on road
> conditions and
> > policy
> >
> > Perhaps on most objects, there aren't any methods.  However, I
> would caution
> > against throwing out an important modeling tool, under the
> auspices of being
> > "declarative".  In my mind, an object oriented design is just as
> > "declarative" as a list of properties.
>
> i think harald's point was not with what a tire MAY be modeled [*], but
> rather with what a tire MINIMALLY MUST be modeled for this to build this
> very particular petrol/tire stop.
>
> >> modelling is also the art of throwing away information not relevant to
> >> the model's purpose.
>
> this is often a major piece of magic which makes projects actually
> achievable.
>
> randy
>
>
> * - this soon becomes the entire usiverse, as the projections for next
>     year's rubber crop in java may influence the choices in composition
>     of this year's tires
>