Re: Methods in the NIM requirements

["Timo Hotti" <timo.hotti@solidtech.com>]

Folks,


here's some unstructured thinking from a new kid on the block. So, please
be patient when you proceed...

On 4/17/2000 11:56:36 PM, "Weiss, Walter"  wrote:
>I am really struggling with this thread. Here is my basic problem. In many
>of the models I have seen (including some I have worked on), a class is
>defined with a set of attributes that can be manipulated to affect
>particular changes in the system that the object is meant to model. Hence,
>the set of attributes provide an interface to the system being described.
>In contrast, traditional OO design approaches suggest that an object has a
set
>of attributes that are not directly accessable except with the use of
>methods. Hence, the method is the interface to the object (and therefore
>the system). If we want to incorporate methods in the NIM requirements,
then
>the methods should represent the primary interface, obviating the need for
most
>attributes (except as parameter definitons for the methods).
I'm also struggling with this thread, which probably is a good sign ;-)

Objects by definition have state and behaviour. State = attributes and
behaviour = methods. If either half is missing, it's not an object.
Therefore I warmly recommend that if we do object-oriented modeling, we
actually include the methods into the discussion and actually try to stay
away from the attributes because they are encapsulated (i.e. hidden) and
hence almost always implementation specific.

To make things more complicated... in a real & good OO system, there are
many kinds of objects with entirely different roles. Here's how I've
understood the different roles of objects:

1) "Business objects" that model the business domain (e.g. router, server,
communications port  etc.). The attributes of these objects make the data
model that typically is implementation specific, primarily because
optimizing information model is required to get proper performance out of
the system.

2) "Interface objects" or "service objects" that publish the "external
behaviour" of a component that consists of one or multiple business
objects. One (but not always the only) way to model this is to make one or
multiple objects per service. A service can be understood as a atomic
logical unit of work (LUW) that consists of multiple operations performed
co-operatively by the business objects of the component. This is sort of
analogous to a database transaction.

3) "Framework objects" that specify how different kinds of object of the
overall system work together. The framework provides the glue that keeps
the entire system together.

Out of these three object types, I would be tempted to proceed towards
modeling "service objects". They may well be standardizable because they
hide the implementation behind an interface. However, in order to be
successful with modeling the interfaces, one must have lots of
understanding about the business objects and frameworks as well...

At this point, this is just another idea to think about... I don't have any
concrete Network Management example in mind to make this more concrete. It
might be a good exercise however to table test different modeling
approaches with real life examples such as "Establish a VPN between node A
and node B for next 7 days using keys ABC and XYZ". Usually an abstract,
reusable high-level model shows up from somewhere once you have struggled
long enough with some concrete instances of the problem.

To my knowledge, making reusable, cross-vendor compatible components (which
I guess is the ultimate goal here) is the toughest challenge of software
development. I don't know of any great success stories in this front yet.
However, I believe that such success story is required to make the
tomorrow's or even today's networks manageable. Therefore, it may be worth
exploring multiple different approaches with some concrete application
examples before choosing the right one.


Regards,

Timo Hotti
Principal Consultant
SOLID Information Technology Corp
Tel. (408) 981 5007