Re: Closing on NIM requirements

["John Strassner" <jstrassn@cisco.com>]

Dave,

I am rather surprised that you would ask whether methods are
appropriate for an information model, since you have been
part of CIM and DEN, and both use methods as part of their
information model definition. But more to the point, an
object is not merely a grouping of attributes, it is an
encapsulation of behavior. Behavior is, in the most general
form, described by a combination of attributes, methods,
constraints and relationships.

Constraints and relationships are somewhat advanced.
However, methods are commonly accepted as being integral to
the definition of an object. To prove this, here are a set
of definitions, first from a technical book, and then from a
"Manager's Guide":

  "An object class describes a group of objects
   with similar properties (attributes), common
   behavior (operations), common relationships
   to other objects, and common semantics."

  "An operation is a function or transformation
   that may be applied to or by objects in a class."

  "A method is the implementation of an operation
   on a class"

This set of definitions is from:
  "Object-Oriented Modeling and Design", by
   Rumbaugh, Blaha, Premerlani, Eddy, and Lorensen

  "An object is a software 'package' that contains
   a collection of related procedures and data. In
   the object-oriented approach, procedures go by
   a special name; they are called methods."

This definition is from:
  "Object-Oriented Technology: A Manager's Guide"
   by David A. Taylor

It's pretty scary when a very technical textbook and a book
aimed at providing an overview to a subject agree. Not to
mention the scores of books on object-oriented analysis and
design, as well as object-based and object-oriented
languages, that talk about methods as integral to an object.
Not to mention the fact that UML defines methods as integral
to an object.

The inescapable conclusion is that methods are indeed
central to defining an object.

The fact that methods may not be directly represented in
some repositories (actually, ANY repository that is not an
active repository) is irrelevant to the purpose of modeling.
The purpose of modeling is to represent information in a
form that is independent of any particular storage
mechanism, technology or access protocol. It is up to the
developer to map this data into a form that is suitable for
the application. This may be a direct mapping to an active
repository, or it may mean that the information model guides
the developer in defining what data should be stored in a
(passive) repository and what other components, such as
middleware, must be used to manipulate that data. In either
case, methods are a valuable means of describing the
behavior of entities in the information model.

Furthermore, I have no idea why you think that "...methods
as being useful as mechanism for grouping attributes and
expressing the transactional semantics of attributes."
Methods are a definition of an operation that happens on an
object, so the fact that they may (or may not) group
attributes is merely a side-effect. Furthermore, methods in
and of themselves are insufficient to express transactional
semantics, and most methods have nothing to do with
transactions. So you've completely lost me with this
sentence.

Finally, methods (just like attributes) are independent of
"...CORBA/DCOM IDL-like notions...".

regards,
John
----- Original Message -----
From: "Durham, David" <david.durham@intel.com>
To: "'Weiss, Walter'" <WWeiss@lucentctc.com>;
<nim@ops.ietf.org>
Sent: Saturday, April 15, 2000 3:49 PM
Subject: RE: Closing on NIM requirements


> I am still trying to grapple with the idea of methods
within an information
> model. What does it mean to model methods in a declarative
model which I
> generally view as classes, attributes, and associations?
Methods seem to
> break repository models (which do not support them
directly) as well as
> protocol models that strictly set/get or add/remove named
data (eg. SNMP).
>
> I view methods as being useful as mechanism for grouping
attributes and
> expressing the transactional semantics of attributes.
Other than that, if
> they are meant to imply CORBA/DCOM IDL-like notions, then
I don't think they
> belong in an "information model" because they are forcing
it to become
> implementation dependent.
>
> -Dave
>
> > -----Original Message-----
> > From: Weiss, Walter [mailto:WWeiss@lucentctc.com]
> > Sent: Saturday, April 15, 2000 2:52 AM
> > To: 'nim@ops.ietf.org'
> > Subject: Closing on NIM requirements
> >
> >
> > Folks,
> >
> > The next major issue is going to be settling on a
modeling language.
> > Numerous people have offered me there preferences.
However,
> > before this
> > discussion can begin, we need to reach some consensus on
the
> > requirements
> > document. I would like to see some comments submitted to
the
> > list within the
> > next week. If no comments are forthcoming, we will
assume
> > that everybody is
> > happy with the current requirements and we will move on
this
> > next issue.
> >
> > regards,
> >
> > -Walter
> >
> >
>
>
>
>