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