[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Closing on NIM requirements




----- Original Message -----
From: "Durham, David" <david.durham@intel.com>
To: "'Jon Saperia'" <saperia@mediaone.net>; "Harald Tveit
Alvestrand" <Harald@alvestrand.no>; "'Weiss, Walter'"
<WWeiss@lucentctc.com>; <nim@ops.ietf.org>
Sent: Sunday, April 16, 2000 2:57 PM
Subject: RE: Closing on NIM requirements


> Actually, I think you can almost always find a mapping
convention from some
> high-level modeling concept to any low-level
implementation (Ie. Multiple
> inheritance to Single inheritance with associations
simulating multiple
> inheritance).

ACK! This is NOT a good example. Multiple inheritance in
general does not correspond to single inheritance with
associations! First, that assumes that associations are
implemented as classes. Second, it completely misses the
fact that a Class C, multiply inheriting from Classes A and
B, now has as part of its definition the attributes,
methods, relationships and constraints of classes A and B.
This is NOT the same as having two classes, E and F (where E
subclasses from A and F subclasses from B) and an
association G linking them together.

> The point of the high-level model is that it should be
easy to
> model your information with it... It is for the modeler
who knows what the
> data needs to be but not how specific implementations work
(or what their
> particular quirks may be). Using the conventions of the
high-level model,
> standard mappings can be developed for specific
implementations (ie. a
> high-level two-way association maps to an SNMP table entry
with a successor
> + predecessor row pointer). Standard mappings will
hopefully make the
> translation automatic.

This is a compelling argument as to why you do want to
include methods in the definition. First, for
interoperability. Second, to provide a consistent interface
that encapsulates the behavior of an entity.

> Besides being most convenient to the modeler, the
high-level model must be
> maximally expressive, allow the modeler to specify
constraints, etc. such
> that the resulting model is unambiguous (and, thus, so are
the mappings).
>
> Basically, we need a simple way to get the information out
of the expert's
> heads and into a high-level model (once), then derive the
low-level models
> from that root model.
>
> -Dave
>
> > -----Original Message-----
> > From: Jon Saperia [mailto:saperia@mediaone.net]
> > Sent: Sunday, April 16, 2000 2:43 PM
> > To: Harald Tveit Alvestrand; Durham, David; 'Weiss,
Walter';
> > 'nim@ops.ietf.org'
> > Subject: Re: Closing on NIM requirements
> >
> > > I have a stated a preference for UML in the past. The
> > interesting question
> > that this discussion begs is: if people believe LDAP and
SNMP
> > (and others)
> > are not able to effectively represent what is in the
> > 'higher-level' models,
> > what should be done? I have mentioned a number of times
that
> > the technology
> > specific details, whether they be LDAP, SNMP, or
anything
> > else will always
> > tend to impinge on the higher layer modeling. Even in
what
> > are generally
> > considered to be OO languages, there are important
> > differences. For example,
> > how do I do multiple inheritance in Java?  The point is
not
> > to pick on Java
> > or any other technology. My point is that either the
modeling
> > language be
> > reduced to the least common denominator - which probably
> > nobody wants, or a
> > plan be put in place to bring up the infrastructure
elements
> > to the point
> > where they have what people feel is needed. In that case
a
> > fairly protracted
> > but appropriate discussion of tradeoffs would probably
have
> > to take place.
> >
> > /jon
> >
> >
>
>
>
>