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 on 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? 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 knowledge base for the application domain 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 an encompassing • refer to one specific application application domain (shared by project (or a few related ones) 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 conceptualisation and terminology integrity within one particular for many implementations implementation • must be open for extensions by not • should be extensible for related 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 Specifications large conceptual distance � users are not able to � Conceptual validate conceptual schemas Schema Z X 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 � Adding a new intermediate step: Discourse conceptual predesign � Semantic model with only few orthogonal und intuitively understandable modeling concepts: KCPM => “Requirements modeling” X KCPM glossaries Y � Graphical and tabular Z representation by Z X 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 condition thing type 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 <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. Ont_SE AUS_06 16 Transformations in the ontology / project life cycles Ontology LC Proiect LC Domain Project knowledge requirements [NL] [NL] extract extract import / export Ontology 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 M 02 (for E volutionary, O bject oriented S S ystem X 1 development) K 01 X 4 X 2 X 3 M 21 Cycles for: S: System development M 31 X: component development M: module/class development Ont_SE AUS_06 20 The ontology life cycle (in terms of the EOS model) • Ontological analysis: OA OU - analyse and delimit ontology domain, Ont - investigate super-, sub- and adjacent ontologies, OD - gather and integrate domain knowledge OI - 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.