RE: Methods in the NIM requirements

["Weiss, Walter" <WWeiss@lucentctc.com>]

Lakshmi,

I find myself agreeing personally with your opinion. However, more often
than not, a practical example of what you mean does more to develop
concensus than abstract discussions. If we have all been talking past
eachother, I would certainly feel more comfortable. If I understand your
comments below, you would describe attributes as any element that is
persistent for the life of the object. Attributes can be read or written
(things like statistics are presumably not writable). Methods deal with
cross-object interactions. From the example:

You would say that the attribute BandwidthAllocation can be read to
determine the current bandwidth level assigned to a queue and written to
change the bandwidth currently assigned to a queue. In contrast, this class
also has an attribute, CanShare, that affects the allocation of excess
resources. Since excess resource management is provided for in the model
with an association to a seperate scheduler, this class would need to be
managed using a method to manipulate the attribute, second scheduler and the
association between the two (cross-object interaction).

Out of curiosity, would you also use a method for BurstsAllowed and
BurstAllocation within the same instance since it is really a tuple?

regards,

-Walter

> -----Original Message-----
> From: Lakshmi Raman [mailto:lraman@telcordia.com]
> Sent: Monday, May 01, 2000 4:53 PM
> To: Weiss, Walter
> Cc: 'Jon Saperia'; Joel M. Halpern; David Harrington; nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
> 
> 
> 
> 
> Walter,
> I am not sure why you believe we have no consensus on when to 
> use what.
> At the requirements level one can give examples. But there is 
> no way you can
> apriori make a statement
> what can be modeled as an attribute or what should be done 
> with methods.
> As a requirements document and in order to select a language 
> we need to use
> a language that restricts you to one or the other. To repeat 
> again, you usually
> model as
> attribute data item that are in the object for its life time.
> The complex interactions between different objects have been modeled
> as behaviour.
> Lakshmi
> 
> 
> 
> 
> "Weiss, Walter" <WWeiss@lucentctc.com> on 05/01/2000 04:13:49 PM
> 
> To:   "'Jon Saperia'" <saperia@mediaone.net>, "Joel M. Halpern"
>       <joel@ivyplan.com>, David Harrington <dbh@cabletron.com>
> cc:   nim@ops.ietf.org (bcc: Lakshmi Raman/Telcordia)
> Subject:  RE: Methods in the NIM requirements
> 
> 
> 
> 
> Jon,
> 
> I believe you, Joel and David have summed up my concerns nicely.
> 
> 1. I wanted to get a sense of how pervasive methods were to 
> understand the
> implications of the modeling language.
> 
> 2. If it were pervasive, or at least of immediate necessity, 
> I feel we would
> want to beef up the requirements for methods to the same 
> degree we have
> fleshed out the requirements for attributes in the requirements spec.
> 
> 3. It has not been clear to me, nor do I see concensus on, 
> when methods
> should be used and when attributes should be used. This is what I was
> originally concerned with when this thread started (what I 
> interpreted as
> differing opinions on when to use each). This is still a 
> significant issue
> for me. From the example I posted yesterday, I have read and 
> heard many
> different opinions:
> 
> a: BandwidthAllocated is read/write
> b: SetBandwidthAllocated ()
> c: A generic container containing the value to be assigned 
> and an Apply()
> method.
> 
> 4. Finally, I am concerned about how consistently the 
> approach in (3) is
> used. If there is concensus in principle on (3). There should be some
> guidelines on when each should be used. This is specifically 
> not part of the
> requirements doc. However, early concensus will help 
> determine how close we
> all are and whether Juergen's prediction about a single model 
> or yet another
> model comes true. I for one certainly don't want to do yet 
> another model. If
> we can't or are unwilling to converge on these questions, we 
> are almost
> certainly doomed to failure.
> 
> regards,
> 
> -Walter
> 
> > -----Original Message-----
> > From: Jon Saperia [mailto:saperia@mediaone.net]
> > Sent: Monday, May 01, 2000 3:34 PM
> > To: Joel M. Halpern; David Harrington
> > Cc: nim@ops.ietf.org
> > Subject: Re: Methods in the NIM requirements
> >
> >
> > on 05/01/2000 2:38 PM, Joel M. Halpern at joel@ivyplan.com wrote:
> >
> > > While I can not construct a strong example of what methods
> > the information
> > > model requires, I am very much of the opinion that the
> > modeling tool must
> > > include support for methods.  For most attributes, read /
> > write attribute
> > > semantics will suffice, but for some cases methods with
> > signatures and
> > > semantics will be necessary.  I rather hope and expect that
> > that is one of
> > > the place where the power of inheritance will come into play as
> > > well.  Otherwise it is purely a textual convention.
> >
> > I think this is well said. In the end much of what is needed
> > may not require
> > methods. The important point is to be very careful if they are to be
> > defined.
> >
> > The Qos Device Model was brought up by John recently. I have
> > worked with the
> > people developing the Differentiated Services Policy MIB
> > Module and mapped
> > the Qos Device Model to that. It works pretty well though
> > there are some
> > places we have some 'tuning' to do. An interesting
> > observation I would make
> > however is that the UML diagram I see by John S., Walter and
> > David D. has
> > only ClassNames and Attributes. There is not a single method
> > on the whole
> > diagram. That does not mean methods are not good or that a
> > language should
> > not support them - I think it should. The point is that we
> > should use them
> > only when required.
> >
> > /jon
> >
> >
> 
> 
> 
> 
>