KNOWLEDGE MODULE

Abstract: An object, known as a KnowledgeModule, 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. The knowledge module is part data driven and part code driven.

Description: KNOWLEDGE MODULE This invention relates to the field of object-oriented programming, and in particular to a new kind of class object. Modern communications networks are managed using object models, which represent the physical objects in the network. As the network develops, new objects must be created in the network model. In the prior art, this involved manually changing portions of code for each change, which was time-consuming and costly. There are two traditional approaches to software development: code driven and data driven. Code driven software is very flexible, but has the disadvantage of being labor intensive, cloned rather than shared, and requiring long development and testing cycles. Data Driven software on the other hand offers fast development, improved reliability, shorter testing cycle, allows many tasks to be automated, but has limited flexibility, and demands that every possible requirement in framework design must be anticipated. In an object model, a Managed Object definition, as specified in a Management Information Base (MIB), contains naming, containment, attribute, and structure information needed for Network Management Systems (NMS's) to communicate about a particular type of network component, 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-oriented "Class" can contain provisioning rales and behavior but it is limited in what mechanisms are provided for describing naming, containment, attribute, and structure information. Certain parameters of network components are not inherited. 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 familiar with the particular type of network component, for example, an LGS (Loop/Ground start Subscriber) card for a Newbridge Networks Corporation 3600 Bandwidth Manager. An object of the invention is to alleviate this problem. According to the present invention there is provided 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, and at least some of the behavior of said object being data driven. The invention is typically applied to a digital communications network. The object encapsulates all the required information about a type of network component into a single unit. Such objects are known as generally known KnowledgeModules and are arranged in an object-oriented hierarchy and fully support inheritance and polymorphism. KnowledgeModules may be imported and exported to and from text files. A KnowledgeModule builds on the concepts of "Managed Object" (see ITU/CCITT standard M.3010) and the object-oriented "Class" from the Smalltalk programming language (see Goldberg, A. and Robson, D., "Smalltalk-80: The Language and its Implementation", Reading, Mass.: Addison- Wesley, 1983). Knowledge modules are class with extra properties, such as the ability to specify certain things about objects. 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. Knowledge Modules combine the data driven and code driven approaches to provide a very efficient, flexible, quick development of Network Element objects within an Element Management environment. Knowledge Modules provide data driven development of the most common parts of the network element objects, generating code for the object classes and accessors, and code for recreating the Knowledge Module data on system initialization. However, due to the varied requirements of the different network element equipment that cannot be anticipated in advance through a data driven approach, Knowledge Modules provide the user with the ability to customize the class by writing code in it. This provides the ultimate in flexibility and efficiency of development. KnowledgeModules differ from the traditional object oriented subclass paradigm in that some of the behavior of the KnowledgeModules is data driven, not code driven. For example, when determining the equipment that can be contained within another piece of equipment, the KnowledgeModule looks to its data to determine this information. It is not done through logic within the class, as would be the case in a traditional code based environment. On the other hand, it differs from the traditional data driven environment in that some behavior is generated from the data into class/instance methods, but other behavior is custom, and is written by the developer. Any language which fully supports inheritance andpolymorphism may be used to implement Knowledge Modules. The implementation consists of an (object-oriented) "Class" which is a subclass of "Modeled Object" and an instance 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 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 or source code management system. After importing, a Modeled Object subclass can create its Modeled Object Template, thereby bootstrapping the system. KnowledgeModules can be implemented in the Smalltalk programming language as implemented by ObjectShare Inc.. Persistent multi-user access to the Modeled Object instances in provided by the GemStone object-oriented database of GemStone Systems. The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings, in which:- 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. A KnowledgeModule encapsulates 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 information • containment rules • communication protocol information • provisioning rales • inter-object relationship information • intra-object inter-attribute relationship information • customizable provisioning screens • database storage and retrieval information KnowledgeModules are arranged in an 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 KnowledgeModule to obtain information to guide the behavior of applications including Provisioning and Management Information Base navigation. Any language which fully supports inheritance and polymorphism may be used to implement Knowledge Modules. The implementation consists of a (object-oriented) "Class" in which is a subclass of "Modeled Object" and an instance 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 importing, a Modeled Object subclass can create its Modeled Object Template, thereby bootstrapping the system. Example Object Model Class Hierarchy The class hierarchy and structure of the relevant classes is shown below Object Modeled Object Instance variables: container - reference to the containing object dependents addressKey inventory - collection of contained objects connectionRegistry registries objectState compoundState myName CreationDate CreationTime CreatedBy LastModifiedDate LastModifiedTime LastModifiedBy Generallnformation 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 islndexable - indexing directive for database schema generation myNameBlock creationRule dependentAttributes uniqueldBlock extensions maxNumOfSubParts - maximum number of Modeled Objects which can be contained by the Modeled Object instance myBitmapBlock superclassTemplate - name of the Modeled Object Template which is the superclass allAttributeNames attributeDictionary attributeGroupSpecs subPartClassSpecs - specifies the containment rules subPartKeySpecs menu relationships allVisibleGroups isCopyable Figure 1 shows the relationships between a particular sampled model object (a WENode9600Typel) and the Modeled object which contain it (a WEDomain) and are contained by it (a collection of Modeled Objects of typeWEShelf9600). Figure 2 shows the relationship between a sample Modeled Object, a WENode9600Type 1, and its Modeled Object template.

Claims: Claims: 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, and at least some of the behavior of said object being data driven. 2. An object as claimed in claim 1, which is a subclass of a modeled object class and an instance of a modeled object template class. 3. An object as claimed in claim 2, wherein said object is arranged in an object-oriented hierarchy and supports inheritance and polymorphism. 4. An object as claimed in claim 1, wherein said object-oriented programming environment represents a model of a communications network. 5. A method of updating an object model, comprising the steps of creating a modeled object class that implements the behavior of modeled objects, and creating a model object template class that has the ability to generate the source code of an associated modeled object class. 6. A method of managing an object model in an object-oriented programming environment, comprising the step of creating 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, and wherein at least some of the behavior of said object being data driven. 7. A method as claimed in claim 6, wherein said object is a subclass of a modeled object class and an instance of a modeled object template class. 8. A method as claimed in claim 7, wherein said object is arranged in an object-oriented hierarchy and supports inheritance and polymorphism. 9. A method as claimed in claim 6, wherein said object model represents a communications network.

Inventors: BARRY KATHERINE, DRIEDGER KEVIN, MCCLOSKEY MICHAEL J, MUNN GWEN, SUKHU FRANK, BARRY, KATHERINE, DRIEDGER, KEVIN, MCCLOSKEY, MICHAEL, J., MUNN, GWEN, SUKHU, FRANK
Applicants: BARRY KATHERINE, CROSSKEYS SYSTEMS CORP, DRIEDGER KEVIN, MCCLOSKEY MICHAEL J, MUNN GWEN, SUKHU FRANK, BARRY, KATHERINE, CROSSKEYS SYSTEMS CORPORATION, DRIEDGER, KEVIN, MCCLOSKEY, MICHAEL, J., MUNN, GWEN, SUKHU, FRANK
Application year: 1998
Main classification: G06F9
IPC codes: G06F9