[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Methods in the NIM requirements
Andrea,
> Walter,
> First - a question to you: "Why put any data/method design
> decisions into an
> info model requirements document?" I see the need to say
> that data and
> methods exist - these are the requirements of the model.
> But, describing
> "how network data is modeled" USING the info model is a
> different beast
> altogether.
You are absolutely correct. However, a discussion of when methods should be
used will determine whether methods are a requirement for the modeling
language or just a desirable feature (corner case).
>
> Now, to answer your questions ....
> As rules of thumb:
> - Class properties represent "data" (Status, CurrentQueues,
> Counters, etc.).
> - Class methods represent "behavior" (Reconfigure, Save/RestoreState,
> Initialize, etc.).
> However, it is up to the NIM WG (if one forms) to decide if
> these rules of
> thumb should be overridden in specific scenarios.
>
> Why separate data and methods?
> This allows a clear modeling separation between:
> - State information and operational constraints (data)
> - Configuration information (more data, since it is different
> than state
> until the configuration is applied, since even after config
> application -
> state can be different, and since different configurations
> can be defined),
> and
> - The activities of configuring/resetting/... with known
> required/input
> data, known output data, return codes, etc.
>
Folks sometimes complain that modelers are too abstract. I think this is the
case here. The goal was to make it easy for laypeople to understand what to
use and when. This is why I provided the example. From the example below, if
I want to change the bandwidth of a queue, must I use a method or must I use
an attribute or can I use both? I don't care about the specific format of
the signature although that would be helpful for some.
regards,
-Walter
> > -----Original Message-----
> > From: owner-nim@ops.ietf.org
> [mailto:owner-nim@ops.ietf.org]On Behalf Of
> > Weiss, Walter
> > Sent: Friday, April 28, 2000 2:22 PM
> > To: nim@ops.ietf.org
> > Subject: RE: Methods in the NIM requirements
> >
> >
> > Andrea and Lakshmi,
> >
> > Seeing that you believe both methods and attributes should
> be available, I
> > am concerned that the choice of when methods should be used and when
> > attributes should be used appears to be a matter of
> opinion. This suggests
> > that clear guidelines for the applicability of methods and
> > attributes should
> > be included in the requirements document. Could you provide your
> > position on
> > when each should be used and why.
> >
> > To make sure we all understand eachother, I would like to
> use the existing
> > BandwidthScheduler class that has already been proposed for
> the QoS Device
> > Model. This class represents a bandwidth scheduler, which is a
> > process that
> > reserves a portion of the bandwidth of a link for each
> selected traffic
> > type. Could you use this example and describe where you believe
> > methods are
> > appropriate and where attributes are appropriate? It would
> also be helpful
> > if you actually included the signatures. We will no doubt
> need to agree on
> > the requirements for method specification as well.
> >
> > BandwidthScheduler
> > BandwidthAllocation: uint32
> > Defines the number of bytes that can be delivered from
> > a queue each cycle
> > BurstsAllowed:boolean
> > This is a boolean attribute which, if TRUE, signifies
> > that a temporary or short-term allocation of additional
> > bandwidth in addition to the amount of bandwidth
> > allocated through the BandwidthAllocation attribute
> > is allowed.
> > BurstAllocation: uint32
> > Specifies the amount of temporary or short-term
> > bandwidth that can be allocated beyond the amount of
> > bandwidth allocated through the BandwidthAllocation
> > attribute. If the maximum actual bandwidth allocation
> > were to be measured, it would be the sum of the
> > BurstAllocation and the Bandwidth allocation attributes.
> > CanShare: Boolean
> > This is a boolean attribute that, if TRUE, enables
> > unused bandwidth from the associated queue to be
> > allocated to queues that need additional resources.
> > WorkConserving: Boolean
> > This is a boolean attribute that, if TRUE, prevents
> > the scheduler from bursting traffic from the queue to
> > which this instance of the scheduler is associated. When
> > TRUE, this attribute also prevents bandwidth from other
> > idle queues to be consumed by the current queue, thereby
> > preventing resource allocations above the assigned
> > bandwidth.
> >
> > regards,
> >
> > -Walter
> >
> > > -----Original Message-----
> > > From: Andrea Westerinen [mailto:andreawest@mindspring.com]
> > > Sent: Tuesday, April 25, 2000 1:41 PM
> > > To: Lakshmi Raman; Weiss, Walter
> > > Cc: Joel M. Halpern; nim@ops.ietf.org
> > > Subject: RE: Methods in the NIM requirements
> > >
> > >
> > > I totally agree with Lakshmi. Attributes represent
> state/data (ie,
> > > DeviceIsLocked boolean, CurrentNumberOfQueues guage, etc.).
> > > This should be
> > > defined as properties in the info model. It is very
> > > reasonable to have
> > > public data in an OO design. Methods represent behavior and
> > > change state
> > > (ie, InitializeDevice, Reconfigure, etc.).
> > >
> > > To mix the concepts of data and methods ends up with data
> > > acting as a method
> > > (ie, write property x, hope that it takes, come back later to
> > > verify, if the
> > > value changed was it because of the write or something else),
> > > or (OTOH)
> > > methods that are very numerous and/or cumbersome.
> > >
> > > A word of caution - Don't mix different implementation views
> > > (all data, all
> > > methods, or various mixes of data/method combinations) into
> > > the info model
> > > view. An info model is (by definition) repository and
> implementation
> > > independent. That indicates that we should define the
> right level of
> > > "public" data and the right methods to reflect behavior and
> > > change state.
> > > Then, the various implementations should map these to what
> > > they understand
> > > and require.
> > >
> > > Andrea
> > >
> > > > -----Original Message-----
> > > > From: owner-nim@ops.ietf.org
> > > [mailto:owner-nim@ops.ietf.org]On Behalf Of
> > > > Lakshmi Raman
> > > > Sent: Saturday, April 22, 2000 2:28 PM
> > > > To: Weiss, Walter
> > > > Cc: Joel M. Halpern; nim@ops.ietf.org
> > > > Subject: RE: Methods in the NIM requirements
> > > >
> > > >
> > > >
> > > >
> > > > Walter
> > > > I do not think it is correct to say that we do not need
> > > > attributes if we have
> > > > methods.
> > > > They are both needed. Often attributes represent states that an
> > > > object goes
> > > > through
> > > > when different methods are invoked and these are properties
> > > that should
> > > > be readable.
> > > > Lakshmi
> > > >
> > > >
> > > >
> > > >
> > > > "Weiss, Walter" <WWeiss@lucentctc.com> on 04/19/2000 04:22:15 AM
> > > >
> > > > To: "Joel M. Halpern" <joel@ivyplan.com>, nim@ops.ietf.org
> > > > cc: (bcc: Lakshmi Raman/Telcordia)
> > > > Subject: RE: Methods in the NIM requirements
> > > >
> > > >
> > > >
> > > >
> > > > > When I build actual objects, I almost always hide the
> attributes
> > > > > completely, and use specific accessor operations. But that
> > > > > is not because
> > > > > I want to hide the existence of the attribute. It is because
> > > > > the languages
> > > > > all end up exposing more than just the attribute when
> I expose an
> > > > > attribute. To retain my flexibility of implementation, I
> > > > > hide that under
> > > > > an accessor. But in the kind of information model we are
> > > > > talking about, we
> > > > > do not have this drawback. So we can use the power of both
> > > > > the attriubte
> > > > > semantics and the operational (method) semantics where each
> > > > > is appropriate.
> > > >
> > > > Joel,
> > > >
> > > > It would seem then that attribute constraints are
> > > unnecessary because the
> > > > the method definitions provide those constraints as
> part of their
> > > > definition. Why bother defining attributes at all if
> you have method
> > > > definitions to specify the behavioural boundaries of the object?
> > > > As you say,
> > > > the attribute definitions within an object define a specific
> > > > implementation
> > > > of the object that is immaterial to the interface definition.
> > > >
> > > > regards,
> > > >
> > > > -Walter
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
>