KNOWLEDGE MODULE

MODULE DE CONNAISSANCES

English Abstract

A object, known as a Knowledge Module encapsulates all network management
information which is required about a class of network component, including the name of the
class, the object-oriented superclass, attribute descriptions which includes the valid values,
type of the attribute, and translation information, containment rules, communication protocol
information, provisioning rules, inter-object relationship information, intra-object
inter-attribute relationship information, customizable provisioning screens, database storage and
retrieval information.

Claims

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY
OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. In an object-oriented programming environment, an object that encapsulates all
network management information which is required about a class of network component,
said information being selected as one or more items from the group consisting of: the name
of the class, the object-oriented superclass, attribute descriptions which includes the valid
values, type of the attribute, and translation information, containment rules, communication
protocol information, provisioning rules, inter-object relationship information, intra-object
inter-attribute relationship information, customizable provisioning screens, database storage
and retrieval information.
-7-

Description

CA 022216~4 1997-11-20
KNOWLEDGE MODULE
This invention relates to the field of object-oriented pro~~ g, and in
particular to a new kind of class object known as a KnowledgeModule.
A KnowledgeModule builds on the concepts of "Managed Object" (see
ITU/CCITT standard M.3010) and the object-oriented "class" from the Sm~llt~lk
pro~,l;..."";l~g language (see Goldberg, A. and Robson, D., "Sm~ lk-80: The Language
and its Impl~m~nt~tion", R~ ing, Mass.: Addison-Wesley, 1983).
A Managed Object definition contains n~min~, colll~ilmlent, attribute, and
structure information needed for Network Management Systems (NMS's) to
communicate about a particular type of network compollent but it does not contain useful
information about how the network management system should behave. Information
which is lacking includes the rules for how the network component should be
provisioned. Also, a Managed Object includes a subset of the object-oriented paradigm.
Conversely, an object-oriente~ "Class" can contain provisioning rules and
behavior but it is limited in what mech~ni~m~ are provided for describing n~min~,
colllaillment, attribute, and structure information.
Both Managed Object and Class definition are typically manipulated by technical
experts in these respective technologies. They are not readily manipulated by "domain
experts" who are those who are f~mili~r with the particular type of network component.
An object of the invention is enc~rs~ te all the required information about a type
of network component into a single unit.
Accor~illg to the present invention there is provided in an object-oriented
pro~,~.,...,il~g eL~vilolllllent, an object that enca~ulates all network management
il~"l,ation which is required about a class of network component, said information
being selected as one or more items from the group con~i~ting of: the name of the class,
the object-oriented superclass, attribute descriptions which includes the valid values, type
ofthe attribute, and tr~ncl~tion information, co.ll;.;lll"ent rules, communication protocol
information, provisioning rules, inter-object relationship il~llllation, intra-object inter-
attribute relationship information, cu~lollli~able provisioning screens, 11~t~b~ce storage
and retrieval information.

CA 022216~4 1997-11-20
Such objects are known as KnowledgeModules and are arranged in a object-
oriented hie.~.;hy and fully support inhf ;~ ce and polymorphism. KnowledgeModules
may be hll~)Gl led and exported to and from text files.
Once a KnowledgeModule has been imported, it behaves as an extended class
object, allowing instances to be created. The instances refer back to the
KnowledgeModule to obtain information to guide the behavior of applications including
Provisioning and Management Information Base navigation.
Any language which fully supports inh~rit~nce, polymorphism, and run-time
compilation may be used to implement Knowledge Modules. The implement~tion
consists of a (object-oriented) "Class" in which is a subclass of "Modeled Object" and an
h~ ce of "Modeled Object Template" class. The network management system creates
instances of t_e Modeled Object subclass at runtime. The Modeled Object class
implements the basic behavior of all Modeled Objects and has facilities to for subclasses
to create their Modeled Object Template object instance.
The Modeled Object Templ~te object instance is a normal Object and so can be
manipulated as such through a user int~ ce. The updated Modeled Object Template has
the ability to regenerate the source code of its Modeled Object class.
Using the services provided by the software development ellvirolllllent, the source
code ofthe Modeled Object subclass may be exported and imported to a text file. After
iln~o~ g, a Modeled Object subclass can create its Modeled Object Template, thereby
boo~ g the system.
Knowledge Modules are a key component of CrossKeys' "OpenKnowledge"
vvolL which is the basis of the West End Astrolabe Net.~,vork Node Manager. In this
system, the KnowledgeModules are used to model the West End network eq lipment in
the resi~çnti~l broaclh~n~l market. OpenKnowledge implements the KnowledgeModules
in the Sm~llt~lk prog~...~ language as implement~l by ParcPlace-Digitalk.
Pe~i~tent multi-user access to the Modeled Object instances in provided by the
GemStone object-oriented ~lat~b~e of GemStone Systems.
The invention will now be described in more detail, by way of example only, withreference to the accol~ hlg drawings, in which:-

CA 022216~4 1997-11-20
Figure 1 shows the relationships between a sample Modeled Object (a
WENode9600Typel) and the Modeled Object which contain it (a WEDomain) and are
contained by it (a collection of Modeled Objects of type WEShelf9600); and
Figure 2 shows the relationship between a sample Modeled Object, a
WENode9600Typel, and its Modeled Object Template.
1. MODELED OBJECT DESIGN OVERVIEW
A KnowledgeModule e~c~rs~ tçs all network management information which is
required about a class of network component. This information includes:
~ the name of the class
~ the object-oriented superclass
~ attribute descriptions which includes the valid values, type of the attribute, and
translation inro~ ation
~ cont~inm~nt rules
~ collllllu"ication protocol inforrnation
~ provisioning rules
~ inter-object relationship information
~ intra-object inter-attribute relationship information
lOll~i~ble provisioning screens
~ ~qt~b~e storage and retrieval information
KnowledgeModules are arranged in a object-oriented hierarchy and fully support
inheritance and polymorphism. KnowledgeModules may be imported and exported to
and from text files.
Once a KnowledgeModule has been imported, it behaves as an extended class
object, allowing instances to be created. The instances refer back to the

CA 022216~4 1997-11-20
KnowledgeModule to obtain information to guide the behavior of applications including
Provisioning and M~n~gen ~nt Information Base navigation.
Any language which fully supports inh~rit~nce, polymorphism, and run-time
compilation may be used to implement Knowledge Modules. The implelnentation
consists of a (object-oriented) "Class" in which is a subclass of "Modeled Object" and an
in.~t~n~.e of "Modeled Object Template" class. The network management system creates
instances of the Modeled Object subclass at runtime. The Modeled Object class
implements the basic behavior of all Modeled Objects and has facilities to for subclasses
to create their Modeled Object Template object instance.
The Modeled Object Template object instance is a normal Object and so can be
manipulated as such through a user interface. The updated Modeled Object Template has
the ability to regenerate the source code of its Modeled Object class.
Using the services provided by the software development environment, the source
code of the Modeled Object subclass may be exported and imported to a text file. After
ollhlg~ a Modeled Object subclass can create its Modeled Object Template, thereby
boul~L,~pillg the system.
1.1 object Model
1.1.1 Class Hierarchy
The class hie,dl~clly and structure of the relevant classes is shown below
Object
Modeled Object
In~ ce variables:
conl~ er - reference to the co~ ,g object
dep~.n~nt.~
addressKey
inventory - collection of contained objects
connectionRegistry
registries
objectState

CA 02221654 1997-11-20
compoundState
myName
CreationDate
CreationTime
CreatedBy
LastModifiedDate
LastModifiedTime
LastModifiedBy
GeneralInformation
alarms
Class variables: -
ObjectRegistry
Modeled Object Template
Instance variables:
dependents
listOfAttributes - a list of the specifications for the
Modeled Object's
attributes
typeOfModeledObject - the name of the Modeled Object
reqAttributesForCreation - required attributes for creation
isIndexable - indexing directive for ~at~b~e schema
generation
myNameBlock
creationRule
dep~.n~l~nt~ttributes
uniqueIdBlock
extensions
maxNumOfSubParts - m;1X;~ number of Modeled
Objects which
can be contained by the Modeled Object instance
myBitmapBlock

CA 02221654 1997-11-20
superclassTemplate - name of the Modeled Object
Template which is
the superclass
allAttributeNames
attributeDictionary
attributeGroupSpecs
subPartClassSpecs - specifies the conlai~ ent rules
subPartKeySpecs
menu
relationships
allVisibleGroups
isCopyable
1.1.2 Object Relationships
Shown below are two diagrams. The first figure shows the relationships between
a sample Modeled Object (a WENode9600Typel) and the Modeled Object which containit (a WEDomain) and are contained by it (a collection of Modeled Objects of typeWEShelf9600).

Representative Drawing