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

RE: Methods in the NIM requirements



Timo,

I would certainly be interested in this approach. Given that all of our
network related models have been very attribute-centric, I would be
interested in seeing how some of the existing models could be converted to
be  method-centric objects.

regards,

-Walter

> -----Original Message-----
> From: Timo Hotti [mailto:timo.hotti@solidtech.com]
> Sent: Tuesday, April 18, 2000 5:11 PM
> To: Weiss, Walter
> Cc: nim@ops.ietf.org
> Subject: Re: Methods in the NIM requirements
> 
> 
> 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
> 
> 
>