Towards Semantic Modeling of Network Physical Devices
Download as PPT, PDF1 like791 views
The document discusses the development of a semantic modeling framework for physical network devices using domain-specific languages (DSLs) such as pddsl and pdidsl, focusing on the relationships and constraints of various device components. It highlights the need for consistency checking, debugging, and mapping these models to ontologies for better configuration management. The framework aims to enhance the design and functionality of DSLs, integrating them with ontology engineering for improved reasoning and semantic rules.
Towards Semantic Modeling of Network Physical Devices
- 1. Tobias Walter University of Koblenz-Landau, Germany Krzysztof Miksa, Marek Kasztelnik, Pawel Sabina Comarch SA, Poland Towards Semantic Modelling of Network Physical Devices Workshop on Transforming and Weaving Ontologies in Model Driven Engineering (TWOMDE) 04.10.2009, Denver, Colorado
- 2. Objectives Scenario Roles Requirements Languages Physical Device DSL Phyiscal Device Instance DSL Transformation of languages to ontology Conclusion 1 of 8
- 3. Scenario (Roles) Guidance and services Constraints DSL User DSL Designer DSL Metamodel uses specifies Domain Model builds requires based on defined in
- 4. Scenario Modeling physical devices, e.g. Cisco network devices Cisco 7603: Possible and mandatory connections of elements A slot can be occupied by a specific set of cards Card from a specific group is required in a device Other constraints If two supervisor engines are inserted they must be identical A card requires that a specific supervisor engine is in the device Domain Model: supervisor_720 hot_swappable_osm slot_1: Slot slot_2: Slot slot_3: Slot conf: Config dev: Chassis
- 5. Scenario (DSL User) Requirements of DSL User: Consistency Checking Debugging of domain models Domain Model: Error Error Error hot_swappable_osm spa_interface_osm hot_swappable_osm slot_1 slot_2 slot_3 conf7603 dev7603
- 6. Scenario (DSL User) Requirements of DSL User: Consistency Checking Debugging of domain models Suggestions of suitable domain concepts Use of services without any extra effort Domain Model: supervisor_720 hot_swappable_osm slot_1 slot_2 slot_3 conf Configuration7603 dev Cisco7603
- 7. PDDSL PDDSL – Physical Device Domain Specific Language PDDSL models (M1 layer) conform to metamodel (M2 layer) M2 layer M1 layer PDDSL Metamodel PDDSL Model conformsTo conformsTo SupervisorEngine HotSwappableOSM Slot Slot Slot Configuration Cisco conformsTo
- 8. PDDSL model to PDIDSL metamodel PDIDSL – Physical Device Instance Domain Specific Language PDDSL model is mapped to PDIDSL metamodel PDDSL Model M1 layer PDIDSL Metamodel M1 layer SupervisorEngine HotSwappableOSM Slot Slot Slot Configuration Cisco mapped to
- 9. PDIDSL PDIDSL model represents concrete configuration PDIDSL model conforms to PDIDSL metamodel PDIDSL Metamodel M1 layer PDIDSL Model M0 layer supervisor_720 hot_swappable_osm slot_1 slot_2 slot_3 conf7603 dev7603
- 10. Language hierarchy M3 level Ecore metametamodel M2 level PDDSL metamodel: the definition of the language needed to describe possible configurations of devices M1 level PDDSL model: a model describing the possible configurations of a device. PDIDSL metamodel: the definition of the language needed to describe concrete configurations of devices. M0 level PDIDSL model: concrete configurations DSL User DSL Designer
- 11. Main assumptions Language design Two layers: type and instance layer PDDSL (type layer) defines a metalayer for PDIDSL (instance layer) Ontology design Device types and information about possible configurations in TBox Concrete configurations and instances of devices in ABox “ Closed-Domain-Assumption”
- 12. Model-based architecture PDIDSL Model PDIDSL Metamodel PDDSL Model PDDSL Metamodel M1 layer M2 layer M0 layer OWL Reasoner (Pellet) map to instance of instance of Ontology ABox TBox transformed to Ontology Extension imports transformed to
- 13. Generated OWL – basic concepts PDDSL Model TBox: Class: Configuration Class: Slot Class: Card ObjectProperty: hasSlot Domain: Configuration Range: Slot ObjectProperty: hasCard Domain: Slot Range: Card transformed to Ontology ABox TBox
- 14. Generated configuration PDDSL Model Class: Cisco7603Configuration EquivalentTo: Configuration and # cardinality restriction on slots: hasSlot exactly 3 Slot and # required cards restriction: (hasSlot some (hasCard some Supervisors and id value 1)) and #optional card restriction: (hasSlot only (((hasCard some Supervisors and id value 1)) or ((hasCard some Supervisors and id value 2) or (hasCard some Hot_Swappable_OSM and id value 2)) or ((hasCard some Hot_Swappable_OSM and id value 3) or (hasCard some SPA_interface_processors and id value 3)))) TBox: transformed to Ontology ABox TBox
- 15. Additional axioms in OWL Import of additional axioms: Future work: Integrated Approach DSL designer can simultaneously implement additional constraints while designing the PDIDSL metamodel MoDELS talk Namespace: pd <http://www.comarch.com/oss/pd.owl#> Ontology: <http://www.comarch.com/oss/pd-ext.owl> Class: pd:Cisco7603Configuration SubClassOf: ((pd:containsCard some pd:Hot_Swappable_OSM) and (pd:containsCard some pd:Supervisor_engine_720)) or (pd:containsCard only (not (pd:Hot_Swappable_OSM)))
- 16. Generated OWL – individuals PDIDSL Model ABox: Individual: cisco1 Types: Configuration Facts: hasSlot slot_1, hasSlot cslot_2, hasSlot slot_3 Individual: slot_1 Types: Slot Facts: hasCard supervisor_2_1, id 1 Individual: slot_2 Types: Slot Facts: hasCard supervisor_2_3, id 2 Individual: slot_3 Types: Slot Facts: hasCard spa_1, id 3 transformed to Ontology ABox TBox
- 17. Generated OWL – CDA PDIDSL Model TBox: Class: Configuration Class: Slot EquivalentTo: {slot_3, slot_2, slot_1} Class: Card EquivalentTo: {supervisor_2_2, HS_OSM_1, supervisor_720_1, supervisor_720_3, H_OSM_2, supervisor_2_1, supervisor_2_3, spa_1} transformed to Ontology ABox TBox
- 18. Implementation (Meta-) Modelling Framework: EMF Transformation language: QVT Operational Concrete syntax: EMF tree editors / EMFText Ontology metamodel: OWL2 metamodel with Manchester Syntax OWL Reasoner: Pellet
- 19. Conclusions Ontologies improve DSLs Define formal semantics Take profit from reasoning, query answering, semantic rules DSLs enrichment by additional constraints DSLs improve Ontology Engineering DSLs can be regarded as mean to visualize and edit ontologies Bring the idea of metamodeling into ontologies
- 20. Finally Thanks for your attention supported by www.most-project.eu
Editor's Notes
- #4: DSL User Uses domain-specific language to create domain models E.g. Models are financial contracts (bank officer), network device configuration (system engineer) Needs services for productively modeling DSL Designer Creates metamodels to specify the domain specific language Provides concrete syntax to DSL users Supports the DSL user, e.g. by guidance, validation
- #5: The complete box is called a chassis. The chassis consists of different cards, for example: Supervisor Engine 720 card for different IP and security features SPA Interface Card for 1-Gbps broadband connections (OSM Card) Hot Swap Controller for swapping cards at runtime (OSM Card)
- #6: Complete and inconsistent
- #7: Complete and consistent -> dynamic classification (refine the model)
- #8: - Metamodel of BEDSL