Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann / aigner@mathematik.uni-marburg.de

Inhalt UML KCPM (Klagenfurt Conceptual Predesign Model) Einführung Anwendungbeschreibung (Ausschnitt) Bisherige Lösungen – Was ging nicht? UML Klassendiagramm Herangehensweise & Probleme OCL KCPM (Klagenfurt Conceptual Predesign Model) Motivation Glossare KCPM-Entwurfsobjekte & Unsere Lösung Vergleich mit bisherigen Lösungen Resümee & Quellen

1. Einführung Ziel des Projektes: Erstellen einer Ontologie aus einer Anwendungsbeschreibung zum System der Hochschule. Was ist eine Ontologie? Hilfsmittel zum beschreiben eines Wissensbereiches Speichern und Austausch von Wissen In der Softwaretechnik Softwareentstehung nicht nur durch Anforderungen und Modelle, sondern auch durch Ontologien UML für das konzeptionelle Design KCPM für Ontologien im frühen Stadium von Softwareprojekten

2. Anwendungsbeschreibung (Auszug) 1) Jede Hochschule hat einen Namen. 2) Eine Hochschule hat mehrere Fachbereiche und mehrere Räume. 3) Jeder Raum hat eine Nummer. 17) Zu den Vorlesungen werden wöchentlich Übungszettel von den Studenten bearbeitet und von den Tutoren korrigiert 19) Bei erfolgreicher Teilnahme an einer Veranstaltung erhält der Student einen unbenoteten Schein 22) Er [der Professor] bewertet die in dieser Veranstaltung erbrachten Prüfungsleistungen. 26) Innerhalb eines Semesters darf eine Veranstaltung nur einmal angeboten werden. 27) Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.

3. Bisherige Lösungen Was ging nicht? Drei- oder mehrstellige Beziehungen Assoziations-Klassen Komplexere Prädikatenlogische Strukturen Zeitliche Zusammenhänge Was könnte man verbessern? Übersichtlicher (Attribute) Besser verständlich für nicht-Informatiker Automatisierung

Das UML-Klassendiagramm Eines der 13 Diagrammarten der UML Dient der grafischen Darstellung von Klassen, sowie deren Beziehungen untereinander Wichtig bei der modellgetriebenen Softwareentwicklung Besteht aus Klassen (welche wiederum Attribute und Operationen haben können) und deren Beziehungen

4. UML-Klassendiagramm Klassen, Attribute und Operationen Bsp: Fachbereiche haben Name und eine Nummer. Attribute und Operationen können als public (+), geschützt (#), package protected(~) oder private(-) gekennzeichnet werden, sowie einen Typ und einen Wert haben

Abstrakte Klassen 4. UML-Klassendiagramm Klassen, von denen keine Instanzen erzeugt werden sollen Der Klassename wird dabei kursiv geschrieben

4. UML-Klassendiagramm Abstrakte Klassen Bsp: Personen sind Professoren, Studenten und Tutoren.

4. UML-Klassendiagramm Beziehungen Aggregation / schwache Aggregation Bidirektionale Assoziation / Assoziation Abhängigkeit Generalisierung Unidirektionale Assoziation Komposition / starke Aggregation

4. UML-Klassendiagramm Generalisierung Bsp: Tutoren sind Studenten.

4. UML-Klassendiagramm Aggregation Bsp: Eine Hochschule hat mehrere Fachbereiche und mehrere Räume.

4. UML-Klassendiagramm Assoziation „Zu den Vorlesungen werden wöchentlich Übungszettel von den Studenten bearbeitet und von den Tutoren korrigiert.“

4. UML-Klassendiagramm Zusätzliche Charakterisierungen von Assoziationen Rolle Assoziations Bezeichnung / Name Multiplizitäten

4. UML-Klassendiagramm Drei- oder Mehrstellige Beziehungen Bsp: „Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.“

4. UML-Klassendiagramm Assoziationsklassen Ähnlich zu dreistelligen Beziehungen, jedoch ist Assoziationsklasse immer an Assoziation gebunden. Außerdem werden diese i.d.R. neu erzeugt und kommen nicht in der Beschreibung als Nomen vor

4. UML-Klassendiagramm Problem: Interpretation notwendig „Zu einer Arbeitsgruppe gehören Personen.“ Kann eine Person auch in mehreren Arbeitsgruppen sein? Müssen es wirklich Personen sein, oder reicht auch eine einzelne Person / könnte auch eine Arbeitsgruppe mit 0 Personen erlaubt sein?

4. UML-Klassendiagramm Problem: Interpretation notwendig

4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung a) „Zu einer Veranstaltung können ein oder mehrere Tutorien angeboten werden.“ b) „Zu den Vorlesungen gibt es Tutorien die von den Tutoren gehalten und von den Teilnehmern der Vorlesung (den Studenten) besucht werden.“

4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung a) -> Veranstaltung hat 0..* Tutorien (können angeboten werden) b) -> Vorlesungen haben 1..* Tutorien (es gibt zu Vorlesungen Tutorien)

4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung Verschiedene Lösungen:

4. UML-Klassendiagramm Erkennung von Drei-&Mehrstelligen Beziehungen „In einem Raum finden zu einer Zeit stets nur eine Veranstaltung oder ein Tutorium statt.“

4. UML-Klassendiagramm Effizientes Arbeiten „Eine Veranstaltung hat außerdem eine Prüfungsform.“ Mögliche Lösung: Prüfungsform als Attribut von Veranstaltung speichern, vom Typ String. Problem: Mehrfaches abspeichern von 4 Strings ist uneffizient

4. UML-Klassendiagramm Effizientes Arbeiten

4. UML-Klassendiagramm Mögliche Herangehensweise bei der Modellierung des UML-Klassendiagramms Zuerst die Beschreibung des Anwendungsbereichs nach irrelevanten Aussagen durchsuchen Bsp: „In den Tutorien werden vom Tutor Fragen zur Vorlesung beantwortet, Hinweise und Hilfestellungen zur Lösung der Übungszettel gegeben und bereits korrigierte Übungszettel besprochen.“ Eine Methode „besprecheUebungszettel()“ für Tutoren ist nur zur Darstellung des Ablaufs relevant, in Hinsicht auf eine spätere Programmierung jedoch nicht

4. UML-Klassendiagramm Mögliche Herangehensweise Die Beschreibung des Anwendungsbereichs nach Nomen durchsuchen, welche als Klasse Sinn machen Bsp: „Jede Hochschule hat einen Namen.“ Hochschule wird Klasse Name deren Attribut

4. UML-Klassendiagramm Erstellen der Klassen

4. UML-Klassendiagramm Einfügen der Beziehungen

4. UML-Klassendiagramm Problem: „Jeder Student ist an mindestens einem Fachbereich eingeschrieben.“ „Zu einer Arbeitsgruppe gehören Personen.“ Zwischen Fachbereich und Studenten besteht eine Aggregation. Eine Aggregation zwischen Professoren und Arbeitsgruppe ist jedoch nicht unbedingt sinnvoll, eher eine normale Assoziation. Eigentlich sollten aber auch Professoren und die Hochschule über Umwege mit einer Aggregation verbunden sein Diese ist ebenfalls über den Fachbereich am Sinnvollsten

4. UML-Klassendiagramm

4. UML-Klassendiagramm Unterstützung durch Tools (hier MagicDraw UML):

4. UML-Klassendiagramm OCL = Object Constraint Language Bestandteil der UML, ist als Ergänzung gedacht Dient der textuellen Spezifikation Soll zu einer präziseren Modellierung der Software führen Ist widerspruchsfrei, jedoch rein textuell

4. UML-Klassendiagramm OCL = Object Constraint Language Beispiele: Context Student inv: self.Matrikelnummer > 0 Context Zeit inv: self.Anfangszeit < self.Endzeit Context Person inv: Alter<18 implies autos->size()=0

4. UML-Klassendiagramm Vor- und Nachteile bei UML Mit UML ließ sich alles darstellen, das ganze steht und fällt jedoch mit der Beschreibung des Anwendungsbereichs Diese ist in den seltensten Fällen eindeutig und perfekt, es kann also nicht automatisch modelliert werden, sondern der Modellierer muss häufig interpretieren und sich auf seine Erfahrung verlassen

5. KCPM Klagenfurt Conceptual Predesign Method/Model Motivation: Konzeptuelles Schema (UML) nicht leicht verständlich → Zwischenstufe: Klagenfurt Conceptual Predesign Method/Model Basiert auf Glossaren Anforderungen sammeln, analysieren und validieren

5. KCPM: Was sind Glossare? Wiki: „Ein Glossar […] ist eine Liste von Wörtern mit Erklärungen.“ „Sammlungen erklärungsbedürftiger Wörter“ „listet die Terminologie […] eines technischen Sachgebietes mit begrifflich-sachlichen Definitionen, die den richtigen Gebrauch dieser Fachausdrücke und deren eindeutiges Verständnis sichern sollen.“ Tabellen mit Informationen Glossare als zentrale Wissensdatenbank zum Zusammentragen, Speichern und Austauschen von Wissen über das Anwendungsgebiet während der frühen Software-Entwicklungsphase Semi-Formale Ontologie

5. KCPM-Entwurfsobjekte Statisch: Thing-Type, Connection-Type Dynamisch: Operation-Type, Connection-Type KCPM-Metamodell (statischer Teil) aus [3]

5. KCPM-Entwurfsobjekte: Thing-Type Klassen und Attribute 1) „Jede Hochschule hat einen Namen.“ Entscheidung ob Thing-Typ Klasse oder Attribut nicht wichtig, erst später Meta-Informationen können helfen (Beispiele, Synonyme) id# name classi-fication quan-tity examples value domain syno-nyms textual description requi-rement sources D 01 Hochschule thing-type 120 Unis/FHs in Deutsc. Satz 01, 02 02 Name „Uni Marburg“ String Satz 01, 04, 08, 12

5. KCPM-Entwurfsobjekte: Thing-Type 7) „Personen sind Professoren, Studenten und Tutoren.“ 16) „Zu den Vorlesungen gibt es Tutorien die von den Tutoren gehalten und von den Teilnehmern der Vorlesung (den Studenten) besucht werden“ id# name classi-fication quan-tity examples value domain syno-nyms textual description requi-rement sources D 07 person thing-type 40.000 Alle die mit der Uni zu tun haben. Satz 6, 7, 8 D 08 professor 200 Satz 7, 21, 22 D 09 student D18 Satz 7, 8, 9, 10, 16.. … D 18 teilnehmer_der_vl D09 Satz 16

5. KCPM-Entwurfsobjekte: Connection-Type Assoziationen / Beziehungen / Generalisierungen Zwei (oder mehr) Perspektiven -> Eine Verbindung 1) „Jede Hochschule hat einen Namen.“ 7) „Personen sind Professoren, Studenten und Tutoren.“ c-id# name c-type deter-miner perspective requi-rement sources p-id# involved thing-type min/max perspective determiner C 01 has-a P01-1 D01 Hochschule has_a 1..1 Satz 01, 02, 03, … P01-2 D02 Name belogns_to 02 is-a P02-1 D07 Professor is_a Satz 02 P02-2 D06 Person can_be

5. KCPM-Entwurfsobjekte: Connection-Type Mehrstellige Beziehungen 1) „Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.“ c-id# name c-type deter-miner perspective requi-rement sources p-id# involved thing-type min/max persp-ective deter-miner C35 veranstaltung/raum/zeit P35-1 D12 veranstaltung findet_statt_in 1..n Satz 27 P35-2 D04 raum belegt_von 1..1 P35-3 D28 zeit zur_zeit

5. KCPM-Entwurfsobjekte: Operation-Type Generalisierung von Use-Case, Aktivität, Aktion, Methode, Service ect. Aktoren (thing-types), acting & calling Service-Parameter o-id# name actor calling-actor service-parameter O01 klausur-nachberichtigung D08 professor D09 student D24 schriftliche_prüfung, „Fehler in Aufgabe 3“ O02 ändern der scheinote D03 fachbereich D22 note

5. KCPM-Entwurfsobjekte: Cooperation-Type Aktoren, die unter bestimmten Bedingungen (pre-condition) Operationen ausführen und Nachbedingungen (post-condition) schaffen coop-id# name pre-condition involved operations post-condition Co01 Noten-berichtigung Student bemerkt Fehler in Korrektur O01, O02 Note für die Vorlesung wurde korrigiert

5. KCPM: Vorteile / Nachteile Leicht verständlich Keine neuen Strukturen zu lernen Flexibel, modular, einfach zu handhaben für Benutzer, Anwendungsgebiet- und Software-Experten Aufwändig zu erstellen und umzuwandeln Semi-Automatisierung möglich (Projekt NIBA) Unübersichtlich Schwer zu überblicken ob evtl. Verbindungen fehlen ect.

6. Vergleich mit bisherigen Lösungen Was ging nicht? Drei- oder mehrstellige Beziehungen Assoziations-Klassen Komplexere Prädikatenlogische Strukturen Zeitliche Zusammenhänge Was könnte man verbessern? Übersichtlicher (Attribute) Besser verständlich für nicht-Informatiker Automatisierung

7. Resümee UML gut und übersichtlich für Experten Eher in der späteren Projektphase Evtl. schwer verständlich KCPM für alle leicht verständlich Zwischen Anwendungsbeschreibung und Modell Unübersichtlich Semi-automatisierung möglich

7. Quellen [1] Fliedl, Kop, Mayr, Mayerthaler, Winkler, Linguistically based requirements engineering - The NIBA-project, 2000. [2] Fliedl, Kop, Mayr, Salbrechter, Vöhringer, Weber, Winkler, Deriving static and dynamic concepts from software requirements using sophisticated tagging, 2006. [3] Bachmann, Hesse, Russ, Kop, Mmayr, Vöhringer, OBSE – an approach to Ontology-based Software Engeneering in the practice, 2007. [4] Burch/Chewsick, The Internet mapping project www.cheswick.com, Grafik der ISPs. [5] Hesse, Skript Modellierung v. Informationssystemen & Wissensrepräsentation, SS2008. [6] Hesse, Skript: Einführung in die Softwaretechnik, 2008. [7] de.wikipedia.com, stand 10.6.2008 [8] www.omg.org/docs/formal/07-11-04.pdf, stand 12.06.2008