a modelling method for consistent physical devices ... · a modelling method for consistent...

A Modelling Method for Consistent Physical

Devices Management: An ADOxx Case Study

Srdjan Zivkovic1,3, Krzysztof Miksa2, and Harald Kuhn3

1 DKE, Faculty of Computer Science, University of ViennaBrunnerstrasse 72, 1210 Vienna, [email protected]

2 Comarch SA Al. Jana Pawla II 39A, Krakow, [email protected]

3 Core Development, BOC Information Systems GmbHWipplingerstrasse 1, Vienna, Austria

{srdjan.zivkovic,harald.kuehn}@boc-eu.com

Abstract. In the domain of network management and operation sup-port systems (OSS), maintainance of thousands of physical network de-vices is a complex, error-prone and time-consuming task. Consistent de-vice configuration and error identification among plethora of networkdevice types is impossible without tool support. Domain-specific mod-elling (DSM) methods promise to deal with system complexity by rais-ing the level of abstraction to models. In this paper, we report aboutconceptualization of a DSM method for physical devices management,that is implemented based on the ADOxx metamodelling platform. Themethod introduces a hybrid modelling approach. A dedicated DSML isused to model the structure of physical devices, whereas the ontologylanguage OWL2 is used to specify configuration-related constraints. Thework resulted in a novel semantic modelling tool prototype that leverageontology reasoning technology to enhance the modelling.

Keywords: Modelling Methods, Domain-specific Modelling, Metamod-elling Platforms, Modelling Tools, Semantic Technology, Case Study.

1 Introduction

One of the challenges faced by OSS [3] is the increasing need for consistentmanagement of physical network equipment. In large companies, maintainance ofthousands of devices is a complex, error-prone and time-consuming task. Properdevice configuration and identification of errors among myriads of network devicetypes cannot be done without tool support. State-of-the-art technologies enablevendor independent equipment type identification and access to the attributes ofthe component types. However, they fail at providing the consistent support tothe user by answering questions that involve sophisticated, configuration relatedconstraints.

Model-based approaches such as MDA [11] and DSM [4] deal with the in-creased system and software complexity by raising the level of abstraction to

C. Salinesi and O. Pastor (Eds.): CAiSE 2011 Workshops, LNBIP 83, pp. 104–118, 2011.c© Springer-Verlag Berlin Heidelberg 2011

A Modelling Method for Consistent Physical Devices Management 105

models. Modelling methods provide necessary concepts to systematically cap-ture relevant domain knowledge in terms of models. A modelling method usu-ally contains 1) a modelling language (ML) used to describe the domain in termsof models, 2) mechanisms and algorithms (M&A) which in general process theknowledge in models and 3) a modelling procedure (MP) defining the steps, re-sults and roles for modelling [9]. Metamodelling platforms provide flexible meansfor the realization of the modelling methods for arbitrary domains, producing amodelling tool tailored to a specific domain.

The system complexity in the domain of network physical devices managementcan be greatly reduced by capturing the semantics of physical devices and theirspecific configurations in models using DSLs and visual modelling tools. Whereasthe adequate definition of a domain-specific ML is important for succesful cap-turing of network equipment information structures, it is equally important todefine domain-specific M&As to check and ensure consistency of models, con-sidering the specific semantics of the domain. In addition, a MP should guidethe users through the network management configuration process by pointingout possible and allowed next steps by considering the given specifics of ML andM&A.

In this paper, we report on the conceptualization of such modelling method,and its implementation using the ADOxx metamodelling platform. The methodhas been constructed within the MOST project1 in order to build a novel mod-elling tool that leverage ontology technology to enhance the modelling.

Following this introduction, Sect. 2 provides an overview of the case study.Sect. 3 explains the main concepts of the PDDSL method. Sect. 4 shows how theconceptualized method is implemented using the ADOxx metamodelling plat-form. In Sect. 5, we discuss the lessons learned, both from the conceptualizationas well as from the implementaiton viewpoint. This is followed by a brief overviewof the related work in Sect. 6. Finally, Sect. 7 concludes this paper and offers anoutlook on future work.

2 Case Study: Consistent Physical Devices Management

The consistent management of the repository of physical network equipment isimportant prerequisite for efficient network management. Let us take an exam-ple of a usual situation in the telecommunication companies when one of thephysical device cards is broken and requires replacement. Fig. 1a represents aparticular configuration of the Cisco 7603. It contains two cards. The card inslot 1 is a supervisor2 of type Supervisor Engine 2, required by the deviceto work properly. In slot 2, two additional cards hotswap and supervisor720are inserted.

Let’s suppose that the main supervisor card is broken and requires replace-ment. The person responsible for this device receives a notification about theproblem and begins to resolve it. The process of finding a valid replacement re-quires deep knowledge about every sub-component of the physical device (what1 http://www.most-project.eu

106 S. Zivkovic, K. Miksa, and H. Kuhn

(a) A particular configuration ofCisco 7603

(b) Alowed configurations ofCisco 7603

Fig. 1. Configuration of Cisco 7603

kind of cards can be used as a replacement for a broken card, what kind of con-straints a particular card has, etc.). As shown in Fig. 1b, the device type Cisco7603 requires at least one card in Slot 1 either of type Supervisor Engine2 or Supervisor Engine 720. Furthermore, Slot 2 allows three types of cardsto be inserted: Catalyst6500, Hot Swappable OSM or Supervisor Engine 720.However, there is an additional restriction that if a card of type Hot SwappableOSM is inserted, a Supervisor Engine 720 card is needed as well.

As shown, there is clearly a need for tools that provide not only the modellingcapabilities to capture the knowledge about various device configurations, butalso an advanced set of mechnanisms that should identify inconsistencies inconfigurations, pin-point invalid cards and, in general, help users to make correctdecisions. The problems to address can be summarized as follows:

1. Network planning - what components can I use with a given configurationof a device to build my service?

2. Consistency checks - is my configuration valid?3. Data quality - what is the exact type of device, given it’s configuration?4. Explanations and guidance: Why is my configuration invalid? How can I

fix it?

Such tools, guiding and supporting users through tedious tasks by answering thequestions mentioned, would generate substantial profit, and reduce the number ofpotential errors in the device configurations. It would also improve productivity,and mitigate the time consumed studying the technical details of a device’sdocumentation.

3 Method Design

The modelling method for physical devices management (PDDSL method) hasbeen conceptualized within the MOST project as a result of the case study ofComarch2, with the goal to investigate the possibilities of semantic technolo-2 http://www.comarch.com


gies in model-based software engineering approaches. MOST offers, to our bestknowledge, the first systematic approach of bridging the model and ontologytechnical spaces [18]. In the case study the approach is instantiated in the do-main of physical devices management. Formal ontology languages bring moremodelling power for defining precise constraints on models through formal se-mantics. Models translated to ontologies and integrated with constraints enablethe usage of reasoning mechanisms such as consistency and subsumption check-ing, classification, explanation and justification. In the following, we explicatethe design of each of the method elements: the PDDSL modelling language, ahybrid language for semantically rich modelling of physical devices (Sect. 3.1),the PDDSL mechanisms needed for checking consistency of physical device mod-els (Sect. 3.2) and the PDDSL modelling procedure to guide users through thenetwork configuration process (Sect. 3.3).

3.1 PDDSL: A Hybrid Modelling Language

The modelling of physical devices as introduced in case study (Sect. 2) posestwo major requirements on the underlying modelling language 1) support forboth linguistic and ontological instantation 2) support for semantically-rich con-straints definition. On the one side, the pure PDDSL needs to support modellingof both network device types (Fig. 1b) and concrete device instances (Fig. 1a) atthe same modelling level. Therefore, PDDSL is designed according to the two-dimensional metamodelling architecture [2], with both linguistic and ontologicalinstantiation. On the other side, the language has to be expressive enough, toenable definition of additional constraints on device type structure, that shouldhold for all device instances. To approach this challenge, PDDSL is integratedwith the formal knowledge representation language OWL2 [14], thus providinga hybrid language for modelling both structure and semantics of the domain.

Abstract Syntax. As pivotal element in the language definition, we define theabstract syntax using metamodels. The hybrid language consists of metamodelsof PDDSL and OWL2, both integrated using well-defined integration points.

PDDSL Metamodel. Fig. 2 illustrates the excerpt of the PDDSL metamodelenabled for the ontological instantiation. It consists of constructs for the mod-elling of device types (LHS) and device instances (RHS). The fundamental ele-ment of the PDDSL metamodel is the relationship hasType between Artefactand ArtefactType, which enables instantiation of all concrete artefact instancesbased on their artefact types on the same modelling level. (e.g. the supervisor2is a particular inventory instance of card type Supervisor Engine 2).

OWL2 Metamodel. The OWL2 metamodel is based on the abstract syntaxmetamodel of theOWL2 Manchester Syntax [7]. The syntax is object-centeredand frame-based, unlike other OWL2 syntaxes which are axiom-based. Fig. 3illustrates a small, but relevant subset of rather complex OWL2 metamodel.


Fig. 2. Excerpt of the PDDSL metamodel

Fig. 3. Excerpt of the OWL2 metamodel (based on Manchester Syntax)

Entities such as Class and Individual can be defined as Frame. A classcan contain Descriptions, which in turn may form simple or complex classexpressions using logical operators such as Conjuction and Disjunction orexistential and universal quantification operators. For example, throughequivalentClassesDescriptions it is possible to define equivalent classes.Similarly, an individual can be related to the class description representing itstype, through types reference.

Metamodel Integration. The metamodels of PDDSL and OWL2 have been inte-grated according to the well-defined integration points for bridging the structurallanguages with ontology languages [18] and following the basic metamodel inte-gration rules [22]. The integration is fairly simple, but powerful, considering theoutcome (see Fig. 4). The PDDSL metamodel element ArtefactType becomesthe subclass of OWL2 Class, thus inheriting the rich OWL2 class expressive-ness. Similar is done between Artefact and Individual. The integration isinvasive from the viewpoint of PDDSL, since PDDSL classes are extended bythe inherited attributes of the OWL2 super classes.


Fig. 4. Metamodel Integration of PDDSL and OWL2

Semantics. Semantics of the language assigns meaning to the abstract syn-tax constructs and it may be specified by a natural language specification orformalized (partially) by logics. The semantics of our language contains severalaspects such as PDDSL semantics, OWL2 semantics, integration semantics andoperational semantics of the integrated language. PDDSL semantics and the in-tegration with OWL2 is formalized in Description Logics (DL). The semanticsof OWL2 is formally defined using DL, too [13]. The operational semanticsdefines how hybrid PDDSL-OWL2 models should be interpreted/transformedinto pure OWL2 ontology, considering the open-world (OWA) and close-worldassumptions (CWA) [12].

Concrete Syntax (Notation). A language can have one or more concrete(graphical, textual) syntaxes. We defined a graphical notation both for PDDSLand OWL2 by mapping the abstract syntax elements to concrete syntax symbols.Table 1 provides an extract of the graphical syntax specification.

Table 1. Example of graphical syntax specification for PDSL and OWL2

PDDSL

Symbol

Element Device Config. Slot slots

OWL2

Symbol

Element Class Obj.Property Nested Descr Conjuction

3.2 PDDSL Mechanisms: Services for Consistency Guidance

PDDSL method introduces a set of metamodel-specific M&As as services forconsistent modelling of physical devices. Considering domain-specific semanticsof PDDSL, these services check both device type models and device instancemodels for validity. We specify some of the consistency services using a high-level specification pattern, that considers the following characteristics of M&As:Name, Signature, Description, Trigger, Input, Output (see Table 2).


Table 2. Services for consistency guidance

Service: Device types consistency checking

Name Consistency checking of device types

Signature bool check (in PDDSL.DeviceType deviceType, out

List<CheckResult> results))

Trigger System Event: pddsl.device.type.before.save, User Event: validationservice invoked.

Description Given a device type and a set of constraints defined for device type, theconsistency of the definition is checked.

Input deviceType - a device type definition.

Output boolean - device type consistency state. results - a list of result messagesof type: error, warning, information.

Service: Device instances consistency checking

Name Consistency checking of device instances

Signature bool check (in PDDSL.Device device, in PDDSL.DeviceType

deviceType, out List<CheckResult> results)

Trigger System Event: pddsl.device.instance.before.save, User Event: valida-tion service invoked.

Description Given a device instance and its corresponding device type (incl. constraints),the consistency of the device configuration is checked.

Input device - a device istance. deviceType a device type, against which thedevice istance is checked.

Output boolean - device consistency state. results - a set of result messages oftype: error, warning, information.

3.3 PDDSL Modelling Procedure

The PDDSL method introduces a modelling procedure to guide users throughconsistent network configuration process. PDDSL MP considers two roles: Do-main Expert which specifies possible device type structures, and Domain Userwhich configures devices according to device types. Activities in the MP pre-scribe modelling tasks, that can be performed towards consistent network de-vices modelling. For example, the activity Fix Device must be performed foreach device that has been found to be invalid (see Table 3). For the specification,we consider the following activity characteristics: Role, Modelling Language(ML)Element, and Pre- and Postconditions.

4 Method Implementation based on ADOxx

The PDDSL modelling prototype has been implemented based on the ADOxxmetamodelling platform and by integrating the set of ontology-based compo-nents developed within the MOST project. It represents one of the two proof-of-concept demostrators developed using a feature-based product-line developmentapproach [21]. The prototype features hybrid visual modelling of physical devicesand OWL2 constraints, semantic validation of models and modelling guidance


Table 3. Activity: Fix device

Name Fix Device

Description An activity that should be performed if the validation service detects aninvalid device.

Role Domain User

ML Element PDDSL.Device

Precondition An instance of device which is marked invalid.

Postcondition A valid instance of device.

(cf. Fig.7)3. In the following, we first introduce the ADOxx metamodelling plat-form as a basis for the implementation of the PDDSL method. Then, we providean overview of the prototype architecture, followed by the implementation detailsfor each of the PDDSL method elements.

4.1 ADOxx: A Platform for Developing Modelling Environments

ADOxx is an extensible, repository-based metamodelling platform developed bythe BOC Group4. ADOxx can be customized using metamodelling techniquesand extended with custom components to build a modelling environment for aparticular application domain. ADONIS [8] is a modelling tool based on ADOxxfor the domain of business process management. The ADOxx platform kernelprovides basic modules for managing models and metamodels. In addition, theADOxx generic components for graphical and tabular model editing, for modelanalysis, for simulation, or for model comparison can be reused and customisedin all products derived from ADOxx. Each ADOxx-based product contains aproduct-specific modelling language and may have additional set of product-specific components.

4.2 PDDSL Prototype Architecture

The PDSSL modelling tool has been developed as a product instance of ADOxx,according to the architecural blueprint for ontology-based modelling environ-ments [21]. Fig. 5 illustrates the instantation of the architecture for the PDDSLtool. The uppermost layer contributes various Editors to create and edit mod-els and metamodels. Views provide modellers information about the currentdevelopment status. Further below, we find various components that contributeOntology-based Services for modelling process guidance, consistency guid-ance and querying. These services are enabled by the subjacent IntegrationInfrastructure that provide bridges between the Modelling Infrastruc-ture and the Ontology Infrastructure. In addition, the generic architecturecontains Vertical Services like user and rights management or import/ex-port and Persistency Services. Note that components in grey colour rely on3 The prototype is available at Open Models Initiative: http://www.openmethods.at4 http://www.boc-group.com/


Fig. 5. Ontology-based Modelling Tool Architecture based on ADOxx

ADOxx generic platform components, whereas other components are product-specific, i.e. implemented and/or integrated specific for the PDDSL tool.

4.3 PDDSL Modelling Language Implementation

Abstract Syntax ADOxx supports three-layered metamodelling architecture.The abstract syntax of our hybrid language has been implemented on the M2level using the constructs of the ADOxx Meta2–Model positioned at M3 level.ADOxx Meta2–Model (see Fig. 6a) organizes metamodel elements such asClasses and Relation Classes into Model Types i.e. diagram types. A modeltype may have different modes, that filter a model type only for a specific subsetof contained elements. In our language, we defined three model types: Devicetypes, Devices and OWL2. OWL2 was splitted in two modes: OWL2 Frames andOWL2 Descriptions (see Fig. 6b). Further, ADOxx features a special kind of re-lation class called Interref that enables to connect elements crossing the modelborder. This feature helped us to implement the ontological-instantiation re-lation between model types by defining interref-relationship hasType betweenArtefact and ArtefactType. Similarly, the metamodel integration with OWL2has been achieved by specifying the generalization relationships between bothArtefactType and Class, and Artefact and Individual.

Semantics. ADOxx doesn’t provide a declarative formalism to define meta-model semantics. However, operational metamodel semantics in ADOxx can bedefined in a imperative way using a scripting language or by integrating externalcomponents. For our hybrid language, the semantics is implemented by a Co-march PDDSL-OWL Transformation Bridge. The component considers both theontological instantation and the metamodel integration semantics of the languageand translates the models into a set of description logic axioms. The transforma-tion was implemented using QVT Operational [15] and Java. For example, the


(a) M3: Simplified ADOxx Meta2–Model (b) M2: Extract of PDDSL+OWL2

Fig. 6. Integrated metamodel based on ADOxx Meta2–Model

semantics of the ontological instantiation relationship hasType can be definedby transforming each occurence of it to an appropriate class assertion axiom inOWL2. On the other side, the direct semantics of OWL2 is directly implementedin the semantic reasoner (in our case the TrOWL5 Reasoner).

Concrete Syntax (Notation). ADOxx supports the definition of the graph-ical concrete syntax. To define the graphical representation (GraphRep) of ametamodel element, the platform provides a set of dedicated APIs that can beaccessed via JavaScript. This allows to define not only statical elements of theGraphRep (curves, lines etc.), but also to add dynamical aspects by consideringthe changes in element property values. For example, the GraphRep of the Slotmay change the color to red if the slot property required is true (see List. 1.1).

if (graphRep.getAttr ("cardRequired"))

{

graphRep.fillColor.setColorByName (graphRep.fillColor.red);

}

graphRep.fillRoundRect (...);

Listing 1.1. A code snippet for the graphical represention of Slot

4.4 PDDSL M&As: Ontology-Based Consistency Services

PDDSL M&As (cf. Sect. 3.2) are implemented based on ontology reasoning ser-vices and additional post-processing. The service Consistency checking ofdevice instances relies on pure satisfiability checking to compute unsatisfi-able set of classes. On the other side, the service Consistency checking ofdevice instances uses consistency checking in combination with explanationservices (known as justifications for inconsistency [6]). Reasoning explanationsare additionally post-processed and interpreted in the domain specific manner.We rely on OWL2 annotations to report users inconsistency reasons. Each axiom5 http://trowl.eu


meaningful to the user is annotated with user-friendly error description. Con-sistency guidance services are part of the product-specific component ComarchConsistency Guidance (cf. Fig. 5) [12].

4.5 PDDSL MP: Ontology-Based Process Guidance Engine

In order to provide a tool support for PDDSL modelling procedure, theontology-based process guidance engine(cf. Fig. 5) developed by BOC isused [23]. The guidance engine relies on the ontology reasoning services suchas classification and query answering to infer availability of the next possibletasks [16]. The activities, its pre- and postconditions, the affected metamodel ele-ments and user roles are part of the modelling procedure definition and are spec-ified in OWL2 as an ontology TBox. List. 1.2 provides a simplified example of FixDevice (cf. Tab. 3) activity definition. First, the artifact IncorrectDevice is de-fined to describe the invalid state of a Device. Then, the activity FixDeviceTaskis said to be performed by the role DomainUser. Finally, the object propertyfixDevice states that IncorrectDevice is a precondition for FixDeviceTaskactivity.

Class: IncorrectDevice

EquivalentTo: Device and Incorrect

Class: FixDeviceTask

SubClassOf: TaskType, performedBy some DomainUser

ObjectProperty: fixDevice

Domain: IncorrectDevice Range: FixDeviceTask

Listing 1.2. Excerpt of the modelling procedure definition using OWL2

5 Lessons Learned

In the following, we discuss the lessons learned during the PDDSL method design(Sec. 5.1) and implementation (Sec. 5.1).

5.1 Experiences from Method Design

Metamodel integration. Metamodel integration of PDDSL and OWL2 is acornerstone of our prototype. However, it solves only part of the issues. Mostnotably, we were unable to simply express the equality of attributes of meta-model elements. For example, after integrating PDDSL.PhysicalElementTypeand OWL2.Class by generalization, it was not possible to define that attributename of PhysicalElementType is the same as attribute iri of Class. Thus, wewere forced to change the PDDSL metamodel and use iri attribute instead ofname. As a consequence, we had to adapt all metamodel-specific mechanismsworking on the PDDSL part of the language. Therefore, we see a need for non-invasive metamodel composition techniques.


Fig. 7. The PDDSL modelling tool prototype based on ADOxx

Language and ontological instantation. We found that language and onto-logical instantation approach perfectly solved the problem of modelling devicetypes and device instances. Futhermore, cases where two-dimensional modellingcould be useful are quite frequent in OSS domain such as service managementor connectivity modelling.

5.2 Experiences from Method Implementation

Reusability of platform components. ADOxx was previously applied in var-ious modelling domains, offering a plethora of ready-to-use generic (metamodel-independent) components such as graphical editor, generic model repository oranalysis component. Thus, we had to develop and integrate comparatively smallnumber of new components for the PDDSL tool prototype, that were neededonly due to the explorative and research-oriented product requirements.

Platform extensibility and interoperability. The extensibility of ADOxxmade it easy to integrate new components into the final product. Using dedicatedbridges, it was possible to integrate Comarch guidance services that are basedon Eclipse EMF technology. Furthermore, the interoperatiblity with ontologyeditors (Protege) and reasoners (TrOWL, Pellet) has been established over theADOxx2OWL Bridge based on OWL API.

Ontology-based validation mechanisms. The reasoning services providedby the semantic reasoner are crucial for the implementation of consistency mech-anisms in our prototype. However, to provide the meaningful answers to the


users of PDDSL method, it is also necessary to translate the results from ontol-ogy technical space back to the domain of PDDSL. For instance, we post-processthe justifications of the inconsistency of the ontology in order to retrieve the setof incorrect model elements. Additionally, it is also necessary to pre-process theontology prior to invoking the reasoning service. For example, before checkingthe consistency of the devices we need to close certain aspect of the ontology,while in order to properly compute the card suggestions for the slots, the sameaspects of the domain have to remain open.

Support for two-dimensional metamodelling. We implemented the seman-tics of ontological-instantiation (hasType) directly in our language on M2 level.We found that this feature could be implemented in metamodelling platformson M3 level, to be used for arbitrary metamodels on M2 level.

6 Related Work

Consistency checking of UML models may be performed by transforming UMLand OCL to a more formal language such as Alloy [1]. Different works (e.g. [19,5])have explored the usage of logic-based language F-Logic to describe configura-tions of devices or the semantics of MOF models. The mentioned approachesrely on pure transformation of models to languages with more formal semanticsfor consistency checking. Besides the transformation of PDDSL to OWL2, ourapproach provides the possibility to define additional constraints in OWL2 basedon metamodel integration. This basic idea has been applied in [17], to integrateUML and OWL for consistent class-based modelling. An alternative implemen-tation of our approach called OntoDSL [20] combines EMOF and OWL at themetametamodel level to take profit from OWL expressivity and reasoning ser-vices to help DSL engineers and DSL users through the development and usageof DSLs. In [10] a metamodel-based approach is proposed that bridges the busi-ness process and knowledge engineering spaces, to support knowledge-intensivebusiness process modelling actions by semantic technology.

7 Conclusion and Outlook

In this paper, we reported on the design of the DSM method for the consis-tent management of physical network equipment, and its implementation basedon the ADOxx metamodelling platform and the set of ontology-based compo-nents developed within the MOST project. The method conceptualization re-sulted in a prototype featuring a hybrid DSML for semantically rich modellingof physical devices, a set of mechanisms for consistency checking of models, amodelling procedure to guide users through the network configuration process.We discussed lessons learned both in method design and method implemen-tation. Hence, we hope that our paper helps method developers to experiencethe potential and challenges of domain-specific method design and realizationbased on metamodelling platforms and ontology technology. Our future work


will be concentrated on several topics derived from lessons learned. Conceptsand techniques for non-invasive metamodel composition integration could bringbenefits to metamodelling platforms while fostering metamodel reuse and com-patibility of mechanisms. Furthermore, we want to generalize the ontologicalapproach for two-dimensional modelling to be applicable for various methodshaving two-dimensional charactestics. Finally, we will investigate the possibili-ties of integrating the semantic technology on the metamodelling language levelas well. This would allow us to provide better support for metamodelling byrelying on formal, declarative languages for knowledge representation and onreasoning mechanisms.

Acknowledgment

This research has been co-funded by the European Commission and by theSwiss Federal Office for Education and Science within the 7th FP project MOST# 216691.

References

1. Anastasakis, K., Bordbar, B., Georg, G., Ray, I.: UML2Alloy: A challenging modeltransformation. In: Engels, G., Opdyke, B., Schmidt, D.C., Weil, F. (eds.) MOD-ELS 2007. LNCS, vol. 4735, pp. 436–450. Springer, Heidelberg (2007)

2. Atkinson, C., Kuehne, T.: Model-driven development: a metamodeling foundation.IEEE Software 20(5), 36–41 (2003)

3. Fleck, J.: Overview of the Structure of the NGOSS Architecture (2003)

4. France, R., Rumpe, B.: Domain specific modeling. Software and Systems Model-ing 4, 1–3 (2005) 10.1007/s10270-005-0078-1

5. Gerber, A., Lawley, M., Raymond, K., Steel, J., Wood, A.: Transformation: TheMissing Link of MDA. In: Corradini, A., Ehrig, H., Kreowski, H.-J., Rozenberg,G. (eds.) ICGT 2002. LNCS, vol. 2505, pp. 90–105. Springer, Heidelberg (2002)

6. Haase, P., Qi, G.: An analysis of approaches to resolving inconsistencies in dl-basedontologies (2007), http://kmi.open.ac.uk/events/iwod/papers/paper-13.pdf

7. Horridge, M., Patel-Schneider, P.F.: OWL 2 Web Ontology Language ManchesterSyntax (2009), http://www.w3.org/TR/owl2-manchester-syntax/

8. Junginger, S., Kuhn, H., Strobl, R., Karagiannis, D.: EinGeschaftsprozessmanagement-Werkzeug der nachsten Generation. Wirtschaftsin-formatik 42(5), 392–401 (2000)

9. Karagiannis, D., Kuhn, H.: Metamodelling platforms. In: Bauknecht, K., Tjoa,A.M., Quirchmayr, G. (eds.) EC-Web 2002. LNCS, vol. 2455, p. 182. Springer,Heidelberg (2002)

10. Karagiannis, D., Woitsch, R.: Knowledge engineering in business process manage-ment. In: Handbook on Business Process Management. International Handbookson Information Systems, vol. 2, pp. 463–485. Springer, Heidelberg (2010)

11. Kleppe, A., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architec-ture: Practice and Promise. Addison-Wesley, Reading (2003)

http://kmi.open.ac.uk/events/iwod/papers/paper-13.pdf

http://www.w3.org/TR/owl2-manchester-syntax/


12. Miksa, K., Sabina, P., Kasztelnik, M.: Combining ontologies with domain spe-cific languages: A case study from network configuration software. In: Aßmann,U., Bartho, A., Wende, C. (eds.) Reasoning Web. LNCS, vol. 6325, pp. 99–118.Springer, Heidelberg (2010)

13. Motik, B., Patel-Schneider, P.F., Grau, B.C.: OWL 2 Web Ontology LanguageDirect Semantics (2009),http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/

14. Motik, B., Patel-Schneider, P.F., Parcia, B.: OWL 2 Web Ontology LanguageStructural Specification and Functional-Style Syntax (2009),http://www.w3.org/TR/2009/REC-owl2-syntax-20091027//

15. OMG: MOF QVT Final Adopted Specification (2005),http://www.omg.org/docs/ptc/05-11-01.pdf

16. Ren, Y., Lemcke, J., Friesen, A., Rahmani, T., Zivkovic, S., Gregorcic, B., Bartho,A., Zhao, Y., Pan, J.Z.: Task representation and retrieval in an ontology-guidedmodelling system. In: OWLED (2009)

17. Silva Parreiras, F., Staab, S., Winter, A.: TwoUse: Integrating UML Models andOWL Ontologies. Tech. Rep. 16/2007, Universitat Koblenz-Landau (2007)

18. Staab, S., Walter, T., Groner, G., Parreiras, F.S.: Model driven engineering withontology technologies. In: Aßmann, U., Bartho, A., Wende, C. (eds.) ReasoningWeb. LNCS, vol. 6325, pp. 62–98. Springer, Heidelberg (2010)

19. Sure, Y., Angele, J., Staab, S.: OntoEdit: Guiding ontology development bymethodology and inferencing. LNCS, pp. 1205–1222.

20. Walter, T., Silva Parreiras, F., Staab, S.: ontoDSL: An ontology-based frameworkfor domain-specific languages. In: Schurr, A., Selic, B. (eds.) MODELS 2009. LNCS,vol. 5795, pp. 408–422. Springer, Heidelberg (2009)

21. Wende, C., Zivkovic, S., Aßmann, U., Kuhn, H.: Feature-based Customisationof MDSD Tool Environments. Tech. Rep. TUD-FI10-05-Juli 2010, TechnischeUniversitat Dresden (July 2010),http://ftp.inf.tu-dresden.de/berichte/tud10-05.pdf

22. Zivkovic, S., Kuhn, H., Karagiannis, D.: Facilitate modelling using method integra-tion: An approach using mappings and integration rules. In: ECIS 2007, Universityof St. Gallen, Switzerland (2007),http://is2.lse.ac.uk/asp/aspecis/20070196.pdf

23. Zivkovic, S., Wende, C., Bartho, A., Gregorcic, B.: D2.3 - Initial Prototype ofOntology-driven Software Process Guidance System (2009),http://most-project.eu/documents.php

http://www.w3.org/TR/2009/REC-owl2-direct-semantics-20091027/

http://www.w3.org/TR/2009/REC-owl2-syntax-20091027//

http://www.omg.org/docs/ptc/05-11-01.pdf

http://ftp.inf.tu-dresden.de/berichte/tud10-05.pdf

http://is2.lse.ac.uk/asp/aspecis/20070196.pdf

http://most-project.eu/documents.php

a modelling method for consistent physical devices ... · a modelling method for consistent...

Documents