RE: Closing on NIM requirements

[Randy Bush <randy@psg.com>]

> 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