CA2311328A1 - Knowledge module - Google Patents
Knowledge module Download PDFInfo
- Publication number
- CA2311328A1 CA2311328A1 CA002311328A CA2311328A CA2311328A1 CA 2311328 A1 CA2311328 A1 CA 2311328A1 CA 002311328 A CA002311328 A CA 002311328A CA 2311328 A CA2311328 A CA 2311328A CA 2311328 A1 CA2311328 A1 CA 2311328A1
- Authority
- CA
- Canada
- Prior art keywords
- information
- class
- attribute
- modeled
- oriented
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000004891 communication Methods 0.000 claims abstract description 7
- 238000013519 translation Methods 0.000 claims abstract description 5
- 238000000034 method Methods 0.000 claims description 3
- 238000011161 development Methods 0.000 description 5
- 238000013459 approach Methods 0.000 description 3
- 230000003466 anti-cipated effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 239000010437 gem Substances 0.000 description 2
- 229910001751 gemstone Inorganic materials 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
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 abject 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 rules 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.
EP 631, 232 discloses a systems management subsystem wherein state information about managed components is encapsulated into objects that are visible in the global name space, but it does not envision objects that are both code driven and data driven.
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 comprising: 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, infra-object inter-attribute relationship information, customizable provisioning screens, and database storage and retrieval information, wherein said object is a subclass of a modeled object class and an instance of a modeled object template class, and some of the behavior of said object is data driven at some of the behaviour of said object is code driven.
The invention encapsulates all the required information about a type of network component into a single unit. Such objects are known as KnowledgeModules and are arranged in a 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.
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 abject 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 rules 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.
EP 631, 232 discloses a systems management subsystem wherein state information about managed components is encapsulated into objects that are visible in the global name space, but it does not envision objects that are both code driven and data driven.
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 comprising: 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, infra-object inter-attribute relationship information, customizable provisioning screens, and database storage and retrieval information, wherein said object is a subclass of a modeled object class and an instance of a modeled object template class, and some of the behavior of said object is data driven at some of the behaviour of said object is code driven.
The invention encapsulates all the required information about a type of network component into a single unit. Such objects are known as KnowledgeModules and are arranged in a 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.
AP~E~~iDED SHEET
', , CA 02311328 2000-OS-23 _ . ; - , . . . , < ~ , ' - , 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 Ai~~t~t~E~ ~!-!r~=~
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.
KnowledgeModuies 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.
', , CA 02311328 2000-OS-23 _ . ; - , . . . , < ~ , ' - , 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 Ai~~t~t~E~ ~!-!r~=~
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.
KnowledgeModuies 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 WENode9600Type1) and the Modeled Object which contain it (a WEDomain) and are contained by it (a collection of Modeled Objects of type WEShelf~600); 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 rules ~ inter-object relationship information infra-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.
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 rules ~ inter-object relationship information infra-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.
xam le 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 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 database schema generation myNameBlock creationRule dependentAttributes uniqueIdBlock extensions maxNumOtSubParts - 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 WENode9600Type1) and the Modeled object which contain it (a WEDomain) and are contained by it (a collection of Modeled Objects of typeWEShe1~600).
Figure 2 shows the relationship between a sample Modeled Object, a WENode9600Type l, and its Modeled Object template.
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.
xam le 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 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 database schema generation myNameBlock creationRule dependentAttributes uniqueIdBlock extensions maxNumOtSubParts - 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 WENode9600Type1) and the Modeled object which contain it (a WEDomain) and are contained by it (a collection of Modeled Objects of typeWEShe1~600).
Figure 2 shows the relationship between a sample Modeled Object, a WENode9600Type l, and its Modeled Object template.
Claims (4)
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 comprising: 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, infra-object inter-attribute relationship information, customizable provisioning screens, and database storage and retrieval information, wherein said object is a subclass of a modeled object class and an instance of a modeled object template class, and some of the behavior of said object is data driven at some of the behaviour of said object is code driven.
2. An object as claimed in claim 1, wherein said object is arranged in an object-oriented hierarchy and supports inheritance and polymorphism.
3. An object as claimed in claim 1, wherein said object-oriented programming environment represents a model of a communications network.
4. A method of updating an object model in an object oriented programming environment, comprising the steps of creating an object that encapsulates all network management information which is required about a class of network component, said information comprising: 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, infra-object inter-attribute relationship information, customizable provisioning screens, and database storage and retrieval information, wherein said object is a subclass of a modeled object class and an instance of a modeled object template class, and generating some of the behavior of said object from data is data into class/instance methods some of the behaviour of said object in code custom written by a developer.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002311328A CA2311328A1 (en) | 1997-11-20 | 1998-11-20 | Knowledge module |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2221654 CA2221654A1 (en) | 1997-11-20 | 1997-11-20 | Knowledge module |
| CA2,221,654 | 1997-11-20 | ||
| PCT/CA1998/001079 WO1999027447A1 (en) | 1997-11-20 | 1998-11-20 | Knowledge module |
| CA002311328A CA2311328A1 (en) | 1997-11-20 | 1998-11-20 | Knowledge module |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2311328A1 true CA2311328A1 (en) | 1999-06-03 |
Family
ID=25679847
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002311328A Abandoned CA2311328A1 (en) | 1997-11-20 | 1998-11-20 | Knowledge module |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2311328A1 (en) |
-
1998
- 1998-11-20 CA CA002311328A patent/CA2311328A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7139821B1 (en) | Method and apparatus for creating and deploying applications from a server application | |
| US7120896B2 (en) | Integrated business process modeling environment and models created thereby | |
| US6023579A (en) | Computer-implemented method for generating distributed object interfaces from metadata | |
| CN101996078B (en) | Compositional modeling of integrated systems using event-based legacy applications | |
| WO2006099046A2 (en) | Automated interface-specification generation for enterprise architectures | |
| CN112685020A (en) | Method and device for dynamically creating service interface, electronic equipment and storage medium | |
| EP1185927A1 (en) | Management of non-mbeam objects in jmx environment | |
| Henttonen et al. | Integrability and Extensibility Evaluation from Software Architectural Models- A Case Study | |
| Cheong et al. | Frame-based method for customizing generic software architectures | |
| WO1999027447A1 (en) | Knowledge module | |
| CA2311328A1 (en) | Knowledge module | |
| CN106598551B (en) | A kind for the treatment of method and apparatus of smart card, smart card | |
| CN114968224A (en) | Tree component packaging system and method for multiple service scenes | |
| Pavlou | Using distributed object technologies in telecommunications network management | |
| Thompson et al. | Comparisons between corba and dcom: architectures for distributed computing | |
| Fregonese et al. | Architectural framework modeling in telecommunication domain | |
| Lakos | Towards a reflective implementation of object petri nets | |
| Farooqui et al. | Architecture for Open Distributed Software Systems | |
| Fitsilis | Object-oriented development for telecommunication services | |
| Bellissard et al. | Olan: A Language and Runtime Support for Distributed Application Configuration | |
| KR100287065B1 (en) | Method and System for Managing Persistent Object in Object-Oriented Database System | |
| Akehurst et al. | UML specification of distributed system environments | |
| Klimathianakis et al. | DELOS-A repository based environment for developing network centric applications | |
| Unpingco | Object-Oriented Programming | |
| Bright et al. | Service creation in an intelligent network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |