Towards Semantic Modeling of Network Physical Devices

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

Objectives
Scenario
Roles
Requirements
Languages
Physical Device DSL
Phyiscal Device Instance DSL
Transformation of languages to ontology
Conclusion
1 of 8

Scenario (Roles) Guidance and services Constraints DSL User DSL Designer DSL Metamodel uses specifies Domain Model builds requires based on defined in

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

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

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

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

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

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

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

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”

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

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

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

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)))

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

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

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

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

Finally
Thanks for your attention
supported by
www.most-project.eu

Towards Semantic Modeling of Network Physical Devices

by Tobias Walter on Feb 06, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Towards Semantic Modeling of Network Physical Devices — Presentation Transcript