Ontologies in the Software Engineering process Wolfgang Hesse FB - - PDF document

Ont_SE AUS_06 1

Ontologies in the Software Engineering process

Wolfgang Hesse

FB Mathematik und Informatik, Univ. Marburg, Hans Meerwein-Str., D-35032 Marburg email: hesse@informatik.uni-marburg.de

• n sabbatical leave at:

School of ITEE, University of Queensland Brisbane Qld., Australia hesse@itee.uq.edu.au

Ont_SE AUS_06 2

Contents

• What does OBSE mean?
• Why use ontologies in the SE process?
• Goals
• Ontologies vs. conceptual models
• A glossary-based approach to OBSE
• The role of KCPM in the OBSE cycle
• Ontology vs. software development cycles and their combination
• Tool support for OBSE
• Conclusions

Ont_SE AUS_06 3

What does OBSE mean?

OBSE stands for Ontology-based Software Engineering

• Software projects are not only driven by
• by requirements and models but also
• by an ontology (or by ontologies) forming a

knowledge base for the application domain shared by many projects

• Models come after ontologies:

Instead of building models from scratch they are derived from both the requirements and the ontology .

Project requirements [NL] transform

Project knowledge base Model (e.g. [UML]) Code (e.g. [Java])

transform & develop implement

Domain knowledge base

Ont_SE AUS_06 4

• Re-use should be supported - not only by (ready-made) components,

but also including analyses and models.

• Application domains are addressed by many projects. Cross-cutting

dependencies increase, applications coalesce and grow together.

• More efficient work is required: profit from results of other (concluded
• r concurrent) projects (→ ontology evolution).
• Improve exchange of knowledge - between developers and domain

experts, between developers of concurrent projects, between agents, etc.

• Gain quality in domain analysis and conceptual modelling.
• Support standardization of (basic) application domain knowledge and

components.

Why use ontologies in software projects?

Ont_SE AUS_06 5

Our principal questions

• How cold the software process be improved by using ontologies?
• Which language (for using ontologies in SE projects)?

→ Candidates:

• OWL (or another Semantic Web language)
• UML (with extensions / restrictions / ..)
• An ORM-like language
• A glossary-like format
• .. other

→ Which granularity?

• Which process (for OBSE projects)?

→ Software & Ontology life cycles: Similarities and differences → What is the OBSE process like?

Ont_SE AUS_06 6

• To develop a new approach to OBSE
• To use glossaries as knowledge base both for project &

domain knowledge

• To combine the KCPM and EOS approaches
• To build tools supporting OBSE
• To profit from the ongoing ODM* and MDA** efforts for
• ntology transformation and integration.

_______________________________________________ * Ontology Definition MetaModel * Model driven Architecture (an initiative of the OMG)

Our goals

Ont_SE AUS_06 7

Ontologies

• refer to an encompassing

application domain (shared by many projects and applications)

• address all involved people in one

application domain

• rely on ontological commitment of

heterogeneous groups

• control and standardise

conceptualisation and terminology for many implementations

• must be open for extensions by not

yet known projects

• are shared by many domain

experts and developers of many projects, incl. forthcoming ones

• refer to one specific application

project (or a few related ones)

• address mainly developers of one

(or maybe few neighbour) project(s)

• can be changed according to

project requirements

• maintain consistency and data

integrity within one particular implementation

• should be extensible for related

projects

• are in the responsibility of one (or a

few) modeller(s)

Ontologies vs. conceptual models

Conceptual models

Ont_SE AUS_06 8

Ontologies and MDA

Requirements (z.B. use cases) PIM (UML) PSM_1

....

CIM: Computation independent model PIM: Platform independent model PSM: Platform specific model

PSM_n

model transform & generate

Ontology (OWL, UML, ??) CIM

analyse & specify

? ? ODM

ODM: Ontology Definition metamodel

?

Ont_SE AUS_06 9

• Project requirements are typically written (or uttered) in natural

language, in a rather vague, ambiguous, … manner.

• Ontologies should be consulted as early in the project life cycle as

possible.

• Formal definitions are less important in this phase than information

retrieval, exchange, alignment, matching of domain knowledge.

• Glossaries are well suited for knowledge representation on the

requirements analysis level.

• The KCPM method (cf. [Mayr, Kop et al. 2002] follows a glossary-

based approach for requirements analysis and domain modelling.

• Conceptual models (e.g. UML-like ones) may be formally derived from

glossaries using the KCPM rule set.

A glossary-based approach to OBSE

Ont_SE AUS_06 10

Traditional approach:

• large conceptual distance
• users are not able to

validate conceptual schemas

create table x ... create table z ... create table y ....

X Y Z

Universe

• f

Discourse Natural Language Requirements Specifications Conceptual Schema Logical Schema

From requirements to models: traditional approach

From: H.C. Mayr et al.: KCPM documentation

Ont_SE AUS_06 11

Solution:

Adding a new intermediate step:

conceptual predesign

Semantic model with only few

• rthogonal und intuitively

understandable modeling concepts: KCPM => “Requirements modeling”

Graphical and tabular

representation by ‘glossaries’

• > ‘scratch pad’ for requirements

elicitation and analysis

• > Basis for validation

_____________________________

• cf. [M-K 02] H.C. Mayr , Ch. Kop: A User Center-

ed Approach to Requirements Modeling. Universe

• f

Discourse

X Y Z

KCPM glossaries

X Y Z

create table x ... create table z ... create table y ....

From requirements to models via CP

Ont_SE AUS_06 12 condition

• peration type

thing type Design object connection type cooperation type

KCPM design objects

Ont_SE AUS_06 13

KCPM example: part of a thing type glossary

Ont_SE AUS_06 14

KCPM example: part of a connection type glossary

Ont_SE AUS_06 15

• Spyns et al.: [SMJ 02] follow a glossary based approach starting from the

Object-with Roles Model (ORM) [Hal 01]

• They distinguish:
• an ontology base (obligatory for all ontology users) consisting of fact

declarations ("lexons") of the form <Context-Id : Term1, Role, Term2>

• ontological commitments, i.e. packages of domain rules (serving as

mediators between the ontology base and its applications.

• Rules determine which parts of the ontology are visible for the specific

application and contain further constraints, conditions, extensions etc. Rules are given in a semi-formal way and may be further formalised step-by-step through project progress.

Another glossary-based approach: ORM

Ont_SE AUS_06 16

Transformations in the ontology / project life cycles

Project requirements [NL] Ontology LC Proiect LC import / export extract Domain knowledge [NL]

Ontology glossary [KCPM ?]

extract

Project glossary [KCPM] Formal

• ntology [OL]

Class diagram [UML]

exchange (?)

Code (e.g. [Java])

transform & develop transform implement

XML & RDF

Ont_SE AUS_06 17

• Domain ontologies are glossaries.
• They consist of

. thing types, . connection types, . operation / cooperation types, . conditions, . …

• Forms of presentation (interchangeable):

. as table, . graphical (as network) . UML-like

• NL linguistic analysis tools support domain analysis

Use of KCPM for managing domain ontologies

Ont_SE AUS_06 18

Fernandez et al. list possible approaches (acc. to SE life cycle models) [FGJ 97]:

• waterfall,
• incremental,
• evolutionary.

Waterfall approach does not meet the specific requirements for ontology engineering (→ no sequential process): incremental approach only partly (no planned increments) Evolutionary approach: seems to be promising. It is, for example, supported by

• ur EOS model ([Hes 96], [Hes 03]). Its highlights are:
• Component-based,
• Multi-cyclic,
• recursive (fractal) process structure, consisting of
• uniform development cycles, synchronised by
• revision points.

The ontology life cycle: approaches

AN DS IM OU

Comp

Ont_SE AUS_06 19

The EOS model

(for Evolutionary, Object oriented System development)

S

X 1 X 3 X 4 X 2 M21 K01 M31 M02

Cycles for: S: System development X: component development M: module/class development

Ont_SE AUS_06 20

The ontology life cycle (in terms of the EOS model) Ont

• Ontological analysis:
• analyse and delimit ontology domain,
• investigate super-, sub- and adjacent ontologies,
• gather and integrate domain knowledge
• check for completeness, consistency etc.
• Ontology design:
• determine / derive / synthesize concepts, associations and rules,
• define, visualise, communicate and adjust with adjacent ontologies.

OA OD OI OU

• Ontology implementation:
• Implement c/a/r.'s and integrate with adjacent ontologies,
• publish for potential client applications.
• Ontology use and revision:
• Use, test validate, disseminate ontology through pilot projects
• gather requirements and CR's for revision, start new cycle if required.

Ont_SE AUS_06 21

Duration of process

• fixed, until project termination

Structure of process

• Phases, maybe decomposed in

iterations (e.g. RUP)

• Activities: parts of phases

Subprocesses concern the development of single components or increments Process paradigms:

• Waterfall
• incremental
• component-based
• prototyping, spiral
• evolutionary

Ontology Engineering Process

Duration of process

• not fixed, unlimited

Structure of process

• preferably iterations, maybe

decomposed in phases

• Activities: mostly extensions, modifi-

cations of partial areas Subprocesses concern the development or revision

• f partial areas

Process paradigms:

• incremental
• component-based
• evolutionary

Software Engineering Process

SE and Ont-E processes - a comparison

Ont_SE AUS_06 22

• Less Conceptual Modelling from scratch - ontologies are already

there,

• Analysis and modelling are much more based on re-use than on

new development,

• Layered models: Ontology-related vs project-specific parts,
• Much more need for cooperation (with ontology owners and

concurrent projects)

• during the early phases (analysis of and import from existing
• ntologies)
• during the late phases (selection and export to existing
• ntologies).

What distinguishes OBSE from the (normal) SE process?

Ont_SE AUS_06 23

• Three development paths

. Base ontology path . Domain ontology path . Software development path B-Ont D-Ont SW-Dev import export import export

Ontology and software development cycles combined

Ont_SE AUS_06 24

System development and ontology life cycles interconnected

S

X 1 X 3 X 4 X 2 M21 M01 M31 M02 Ont

derive, adjust update, incorporate,

Ont_SE AUS_06 25

• Main goal of the envisaged

OBSE tool: to build bridges between the development paths.

• Main bridges are:
• import bridges, e.g. between domain ontology OU and software

project AN or between base ontology OU and domain ontology AN.

• export bridges, e.g. between software project OU and domain
• ntology AN (revision cycle) or between domain ontology OU and

base ontology AN.

Ont

OA OD OI OU

SE

SA SD SI SO

import (derive, adjust) export (update, incorporate)

Life cycle bridges

Ont_SE AUS_06 26

• supports OBSE work
• mainly for SW developers who work with ontologies
• offers bridges to ontology editors:

Import: from ontology to OBSE (analysis) tool Export: from OBSE tool to otology editor Interface: to schema integration functions

• First prototype:
• includes building an eclipse-based platform
• offers user interface on RCP basis,
• implements bridge functions (Import, Export) between SE- and Ont-cycles
• enables switching between different views (tables / graphics) on MVC

basis

• offers synchronisation mechanisms and transaction handling
• offers uniform interface (e.g.. for static-/dynamic editors, later to be

incorporated)

The OBSE tool

Ont_SE AUS_06 27

Eclipse Plug-in Architecture

• Plug-in = Component
• Set of contribution
• Smallest unit of Eclipse function
• Details spelled out in plug-in manifest
• Big example: mail client
• Small example: action to calculate the number of lines
• f a mail
• Extension point
• named entity for collecting contributions
• Example: extension point to add additional spam

filtering tools

• Extension
• a contribution
• Example: a specific spam filter tool
• RCP (Rich Client Platform)
• set of standard plug-ins
• Runtime
• controls and manages contributions

Plug-in RCP - Platform Plug-in

Extension Extension point

Runtime

Ont_SE AUS_06 28

An architecture for an OBSE tool

RCP - Platform Runtime O/R-Mapping (OJB, Hibernate, …) DB GEF Dynamic Editor Ontology Editor Static Editor

GEF: Graphical Editing Framework

OBSE Actions

Ont_SE AUS_06 29

Conclusions

• Ontologies will play a major role in SE only if their contents can easily

be transferred into the project life cycle (and vice versa).

• Possible transfer points:
• on the glossary level (early analysis phase)
• on the modelling language (ML) level (modelling phase)
• on the implementation language (IL) level (implementation phase)
• For transfers at different project stages different languages are

feasible.

• The glossary / KCPM approach seems promising for early phase

(= requirements level) knowledge transfer.

• KCPM and OBSE tools support developers while incorporating
• ntologies into their project work.

Ont_SE AUS_06 30 [Col 06] B. Colomb et. al.: The Object Management Group Ontology Definition

• Metamodel. To appear in: C. Calero et al.: Ontologies for Software Engineering

and Software Technology, Springer 2006 [C-P 06] St. Cranefield, J. Pan: Bridging the Gap between MDA and Ontology

• Engineering. To appear in: IJHCS, special issue 2006

[Gru 93] T. Gruber: A translation approach to portable ontologies. Knowledge Acquisition, 5(2), pp. 199-220 (1993) [G-L 02] M. Gruninger, J. Lee: Ontology - Applications and Design. CACM 45.2, pp. 39-41 (Feb. 2002) [Gua 98] N. Guarino: Formal Ontology and Information Systems. In: Proc. FOIS '98, Trento (Italy) June 1998, Amsterdam IOS Press pp 3-15 [Hal 01] T. Halpin: Information Modeling and Relational Databases: from conceptual ana-lysis to logical design. Morgan-Kaufmann 2001 [Hes 96] W. Hesse: Theory and practice of the software process - a field study and its im-plications for project management; in: C. Montangero (Ed.): Software Process Technology, 5th European Workshop, EWSPT 96, Springer LNCS 1149,

• pp. 241-256 (1996)

[Hes 02] W. Hesse: Das aktuelle Schlagwort: Ontologie(n). in: Informatik Spektrum, Band 25.6 (Dez. 2002) [Hes 03] W. Hesse: Dinosaur Meets Archaeopteryx? or: Is there an Alternative for Rational's Unified Process? Software and Systems Modeling (SoSyM) Vol. 2. No. 4, pp. 240-247 (2003)

References

Ont_SE AUS_06 31 [Hes 05] W. Hesse: Ontologies in the Software Engineering process. In: R. Lenz et al. (Hrsg.): EAI 2005 - Tagungsband Workshop on Enterprise Application Integration, GITO-Verlag Berlin 2005 and: http://sunsite.informatik.rwth-aachen.de/ Publications/CEUR-WS/Vol-141/ [H-S 02] C. W. Holsapple, K.D. Joshi: A Collaborative Approach to Ontology Design. CACM 45.2, pp. 42-47 (Feb. 2002) [KMZ 04] Kop, Ch.; Mayr, H.C.; Zavinska, T.: Using KCPM for Defining and Integrating Domain Ontologies. Proc. Int. Workshop on Fragmentation versus Integration - Perspectives of the Web Information Systems Discipline, Brisbane Australia, Nov. 2004. LNCS, Springer [M-K 02] H.C. Mayr , Ch. Kop: A User Centered Approach to Requirements Modeling. In: M. Glinz, G. Müller-Luschnat (Hrsg.): Modellierung 2002 - Modellierung in der Praxis - Modellierung für die Praxis, pp. 75-86, Springer LNI P-12 (2003) [SMJ 02] P. Spyns, R. Meersman, M. Jarrar: Data modelling versus Ontology engineering, SIGMOD Record 31 (4), Dec. 2002 [V-M 05] Vöhringer, J.; Mayr, H.C.: Integration of schemas on the pre-conceptual level using the KCPM-approach. Proc. 16th Int. Conference on Information Systems Development ISD2005, August 2005, LNCS Springer-Verlag [Web 97] R. Weber: Ontological Foundations of Information Systems. Monograph, Coopers & Lybrand 1997

References (cont'd):

Ont_SE AUS_06 32

Activities:

• Capture requirements
• Analyse use cases
• Build object lists
• Design (overall) class structure

Results:

• Requirements
• Use cases + UC diagrams
• Object lists
• Class model (preliminary)

Techniques & tools:

• UC diagram
• Class diagram, UML
• Natural language
• semi-formal
• Target groups: developers and

users Activities:

• Identify potential applications
• View and structure existing

terminology

• Build glossary
• Collect facts and rules
• Detect and solve terminolog. conflicts

Results:

• (potential) applications
• Glossaries
• Facts and rules

Techniques & tools:

• Natural language
• Tables
• Semantic networks
• informal or semi-formal
• Target groups: domain experts and

developers

Ontology Engineering Process Software Engineering Process

Comparison: Analysis phase

Ont_SE AUS_06 33

Activities:

• Design (detailed) class structure
• Design system architecture

(component and module structure)

• Specify building blocks

Results:

• Conceptual Model
• Architectural diagrams

Techniques & tools:

• E/R diagrams
• Class diagrams, UML
• semi-formal
• Target groups: developers

Activities:

• Define ontology structure
• Fill and adjust glossaries
• Solve terminological conflicts

Results:

• Ontology structure
• Filled glossaries
• Facts and rules
• Ontology maps

Techniques & tools:

• Natural language
• Logic languages
• Semantic networks, topic maps
• semi-formal / informal
• Target groups: developers and

domain experts

Ontology Engineering Process Software Engineering Process

Comparison: Design phase

Ont_SE AUS_06 34

Activities:

• Coding: transfer into concrete PL
• Testing, debugging
• Integration, subsystem testing

Results:

• tested programs
• integrated system

Techniques & tools:

• Programming languages

Activities:

• Formalise: transfer into ontology

language

• Check syntax and semantics
• Integrate & adjust partial ontologies

Results:

• formally defined set of facts and rules

Techniques & tools:

• Logic languages
• Semantic networks, topic maps
• Frames, DAML+OIL. OWL
• formal
• Main target: exchange with

related systems and programs

Ontology Engineering Process Software Engineering Process

Comparison: Implementation phase

Ont_SE AUS_06 35

Activities:

• Deploy system at users site
• check, evaluate, collect feedback ,
• Test, debug, collect requirements

for revision

• (if needed) trigger revision

Results:

• Evaluation reports
• Requirements for revisions

Activities:

• Deploy & disseminate ontology
• check, evaluate, collect feedback
• Adjust ontology with neighbour ont.,

remove inconsistencies

• collect requirements for revision
• (if needed) trigger revision

Results:

• User reports
• Requirements for revisions

Ontology Engineering Process Software Engineering Process

Comparison: Operations & use phase Summary of products

• project-related
• (mostly) not re-used
• (relatively) short-termed
• isolated, limited to application

domain

• domain-related, cross-project
• (deliberately) re-used
• long-termed
• "sharable", binding for many

institutions and projects

Ont_SE AUS_06 36

The ontology life cycle (in terms of the EOS model) Ont

• Ontological analysis:
• analyse and delimit ontology domain,
• define super- and sub-ontologies,
• investigate adjacent ontologies and their terminology,
• gather and integrate domain knowledge,
• build conceptual framework,
• check candidate definitions for completeness,

consistency etc.

• Ontology design:
• determine general concepts, associations and rules,
• derive concepts from higher level or synthesize from lower level
• ntologies,
• define, visualise and communicate concepts, associations and rules,
• adjust definitions wrt adjacent ontologies.

OA OD OI OU

Ont_SE AUS_06 37

The ontology life cycle Ont

• Ontology use and revision:
• Use, test and validate ontology through pilot and project applications,
• disseminate to potential users,
• aim for ontological commitment,
• gather requirements and change requests for ontology revision,
• start new cycle if required.

OA OD OI OU

• Ontology implementation:
• Implement concepts, associations and rules

using a given base technology and platform,

• integrate with adjacent ontologies,
• publish ontology for potential client applications.

Ont_SE AUS_06 38

A hierarchy of ontologies

...

General world ontology IS Finance IS

• Transp. IS

Envir. IS DSS Medicine Inner Med. Teeth Surgery

... ... ... ... ... ... ... ... ... ...

Hierarchical structure of ontologies:

• Universal (top-level) ontology [Gua 98],
• discipline ontologies,
• domain ontologies.

Ont_SE AUS_06 39

Application Platform

• Application model

– Family of components (Mailing, Organizer, Address-Book, …) – Different sets of components form different applications

• Workbench offers:

– Perspectives: define arrangement of editors and views – Editors: edit or browse a document or input object – Views: navigate a hierarchy of information – Action contributions: add additional action to already existing elements – Management of shared resources like global menu, preference pages, …

• Programming model

– Supports Model - View - Controller paradigm – Components contribute to workbench extension points – Components provide own extension points – Split between XML (plugin.xml) and Java code

Ont_SE AUS_06 40 S X1 X2 X3 M21 M22 Building block Phase / activity Legend: