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: [email protected] on sabbatical leave at: School of ITEE, University of Queensland Brisbane Qld., Australia [email protected]
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?
Project requirements OBSE stands for Ontology-based Software [NL] Engineering Domain • Software projects are not only driven by knowledge transform base -by requirements and models but also -by an ontology (or by ontologies) forming a Project knowledge base for the application domain knowledge base shared by many projects transform & • Models come after ontologies: develop Instead of building models from scratch they Model are derived from both the requirements and (e.g. [UML]) the ontology . implement
Code (e.g. [Java])
Ont_SE AUS_06 4
Why use ontologies in software projects?
• 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 or 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. 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 Our goals
• 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 ontology transformation and integration.
______* Ontology Definition MetaModel * Model driven Architecture (an initiative of the OMG) Ont_SE AUS_06 7 Ontologies vs. conceptual models
Conceptual models Ontologies
• refer to one specific application • refer to an encompassing project (or a few related ones) application domain (shared by many projects and applications) • address mainly developers of one • address all involved people in one (or maybe few neighbour) project(s) application domain • can be changed according to • rely on ontological commitment of project requirements heterogeneous groups • maintain consistency and data • control and standardise integrity within one particular conceptualisation and terminology implementation for many implementations • should be extensible for related • must be open for extensions by not yet known projects projects • are shared by many domain • are in the responsibility of one (or a experts and developers of many few) modeller(s) projects, incl. forthcoming ones
Ont_SE AUS_06 8 Ontologies and MDA Requirements ? (z.B. use cases)
Ontology analyse & specify (OWL, UML, ??) ? CIM
ODM model ? PIM (UML)
transform & generate
PSM_1 .... PSM_n
CIM: Computation independent model ODM: Ontology Definition metamodel PIM: Platform independent model PSM: Platform specific model Ont_SE AUS_06 9
A glossary-based approach to OBSE
• 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.
Ont_SE AUS_06 10 From requirements to models: traditional approach
Universe of Discourse
Natural Language Traditional approach: Requirements z large conceptual distance Specifications z users are not able to validate conceptual schemas Conceptual Schema
X Z Y
Logical Schema create table x ... create table z ... create table y ....
From: H.C. Mayr et al.: KCPM documentation Ont_SE AUS_06 11 From requirements to models via CP Solution: Universe of z Adding a new intermediate step: Discourse conceptual predesign z Semantic model with only few orthogonal und intuitively understandable modeling concepts: KCPM => “Requirements modeling” X Y KCPM glossaries z Graphical and tabular Z representation by X Z Y ‘glossaries’ -> ‘scratch pad’ for requirements elicitation and analysis create table x ... -> Basis for validation create table z ... ______create table y .... cf. [M-K 02] H.C. Mayr , Ch. Kop: A User Center- ed Approach to Requirements Modeling.
Ont_SE AUS_06 12
KCPM design objects
Design object
thing type condition
connection type cooperation type
operation type 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 Another glossary-based approach: ORM
• 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
Ont_SE AUS_06 16 Transformations in the ontology / project life cycles
Ontology LC Proiect LC Domain Project knowledge requirements [NL] [NL]
extract extract
Ontology import / export Project glossary glossary [KCPM ?] [KCPM]
transform transform & develop exchange (?) Formal Class ontology [OL] diagram [UML]
implement
XML & RDF Code (e.g. [Java]) Ont_SE AUS_06 17
Use of KCPM for managing domain ontologies
- 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
Ont_SE AUS_06 18 The ontology life cycle: approaches
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 our EOS model ([Hes 96], [Hes 03]). Its highlights are: • Component-based, AN OU • Multi-cyclic, Comp • recursive (fractal) process structure, consisting of DS IM • uniform development cycles, synchronised by • revision points. Ont_SE AUS_06 19
The EOS model M02
(for Evolutionary, Object oriented System X 1 S development) K01 X 4
X 2
M21 X 3
Cycles for: S: System development M31 X: component development M: module/class development
Ont_SE AUS_06 20 The ontology life cycle (in terms of the EOS model)
OA OU • Ontological analysis: - analyse and delimit ontology domain, Ont - investigate super-, sub- and adjacent ontologies, OD OI - 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. • 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
SE and Ont-E processes - a comparison
Software Engineering Process Ontology Engineering Process
Duration of process Duration of process - fixed, until project termination - not fixed, unlimited Structure of process Structure of process - Phases, maybe decomposed in - preferably iterations, maybe iterations (e.g. RUP) decomposed in phases - Activities: parts of phases - Activities: mostly extensions, modifi- cations of partial areas Subprocesses concern the development of single Subprocesses components or increments concern the development or revision of partial areas Process paradigms: - Waterfall Process paradigms: - incremental - incremental - component-based - component-based - prototyping, spiral - evolutionary - evolutionary
Ont_SE AUS_06 22
What distinguishes OBSE from the (normal) SE process?
• 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 theearly phases (analysis of and import from existing ontologies) -during thelate phases (selection and export to existing ontologies). Ont_SE AUS_06 23
Ontology and software development cycles combined
• Three development paths . Base ontology path . Domain ontology path . Software development path
import import
B-Ont D-Ont SW-Dev
export export
Ont_SE AUS_06 24
update, incorporate, M02 Ont
derive, adjust X 1 S M01 System X 4 development and ontology life cycles X 2 interconnected M21 X 3
M31 Ont_SE AUS_06 25 Life cycle bridges
• Main goal of the envisaged OBSE tool: to build bridges between the development export (update, paths. OA OU incorporate) SA SO Ont import OD (derive, adjust) SE OI SD SI • 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 ontology AN (revision cycle) or between domain ontology OU and base ontology AN.
Ont_SE AUS_06 26 The OBSE tool
- 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) Ont_SE AUS_06 27 Eclipse Plug-in Architecture • Plug-in = Component - Set of contribution - Smallest unit of Eclipse function Plug-in - Details spelled out in plug-in manifest - Big example: mail client - Small example: action to calculate the number of lines of a mail Plug-in • Extension point - named entity for collecting contributions - Example: extension point to add additional spam filtering tools • Extension RCP - Platform - a contribution Runtime - Example: a specific spam filter tool • RCP (Rich Client Platform) Extension Extension point - set of standard plug-ins • Runtime - controls and manages contributions
Ont_SE AUS_06 28
An architecture for an OBSE tool
Static Editor Dynamic Editor OBSE Actions
GEF Ontology Editor
O/R-Mapping (OJB, Hibernate, …)
RCP - Platform DB Runtime
GEF: Graphical Editing Framework 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 ontologies into their project work.
Ont_SE AUS_06 30 References
[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) Ont_SE AUS_06 31 References (cont'd):
[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
Ont_SE AUS_06 32 Comparison: Analysis phase
Software Engineering Process Ontology Engineering Process
Activities: Activities: - Capture requirements - Identify potential applications - Analyse use cases - View and structure existing - Build object lists terminology - Design (overall) class structure - Build glossary Results: - Collect facts and rules - Requirements - Detect and solve terminolog. conflicts - Use cases + UC diagrams Results: - Object lists - (potential) applications - Class model (preliminary) - Glossaries Techniques & tools: - Facts and rules - UC diagram Techniques & tools: - Class diagram, UML -Natural language - Natural language - Tables - semi-formal - Semantic networks - Target groups: developers and - informal or semi-formal users - Target groups: domain experts and developers Ont_SE AUS_06 33 Comparison: Design phase
Software Engineering Process Ontology Engineering Process
Activities: Activities: - Design (detailed) class structure - Define ontology structure - Design system architecture - Fill and adjust glossaries (component and module structure) - Solve terminological conflicts - Specify building blocks Results: Results: - Ontology structure - Conceptual Model - Filled glossaries - Architectural diagrams - Facts and rules Techniques & tools: - Ontology maps - E/R diagrams Techniques & tools: - Class diagrams, UML - Natural language - semi-formal - Logic languages - Target groups: developers - Semantic networks, topic maps - semi-formal / informal - Target groups: developers and domain experts
Ont_SE AUS_06 34 Comparison: Implementation phase
Software Engineering Process Ontology Engineering Process
Activities: Activities: - Coding: transfer into concrete PL - Formalise: transfer into ontology - Testing, debugging language - Integration, subsystem testing - Check syntax and semantics - Integrate & adjust partial ontologies Results: Results: - tested programs - formally defined set of facts and rules - integrated system Techniques & tools: - Logic languages Techniques & tools: - Semantic networks, topic maps - Programming languages - Frames, DAML+OIL. OWL - formal - Main target: exchange with related systems and programs Ont_SE AUS_06 35 Comparison: Operations & use phase
Software Engineering Process Ontology Engineering Process
Activities: Activities: - Deploy system at users site - Deploy & disseminate ontology - check, evaluate, collect feedback , - check, evaluate, collect feedback - Test, debug, collect requirements - Adjust ontology with neighbour ont., for revision remove inconsistencies - (if needed) trigger revision - collect requirements for revision Results: - (if needed) trigger revision - Evaluation reports Results: - Requirements for revisions - User reports - Requirements for revisions Summary of products
- project-related - domain-related, cross-project - (mostly) not re-used - (deliberately) re-used - (relatively) short-termed - long-termed - isolated, limited to application - "sharable", binding for many domain institutions and projects
Ont_SE AUS_06 36 The ontology life cycle (in terms of the EOS model)
OA OU • Ontological analysis: - analyse and delimit ontology domain, Ont - define super- and sub-ontologies, OD OI - 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 ontologies, - define, visualise and communicate concepts, associations and rules, - adjust definitions wrt adjacent ontologies. Ont_SE AUS_06 37 The ontology life cycle
OA OU • Ontology implementation: - Implement concepts, associations and rules Ont using a given base technology and platform, - integrate with adjacent ontologies, OD OI - publish ontology for potential client applications.
• 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.
Ont_SE AUS_06 38 A hierarchy of ontologies
General world ontology ......
IS DSS Medicine ...... Envir.
Transp. IS IS Finance IS
Teeth Surgery Inner Med.
......
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
Legend:
Building block
Phase / activity