Ontologien: UML & KCPM

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

2. Inhalt • 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

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

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

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

6. 4. UML-Klassendiagramm 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

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

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

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

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

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

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

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

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

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

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

17. 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?

18. 4. UML-Klassendiagramm Problem: Interpretation notwendig

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

20. 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)

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

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

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

24. 4. UML-Klassendiagramm Effizientes Arbeiten

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

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

27. 4. UML-Klassendiagramm Erstellen der Klassen

28. 4. UML-Klassendiagramm Einfügen der Beziehungen

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

30. 4. UML-Klassendiagramm

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

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

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

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

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

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

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

38. 5. KCPM-Entwurfsobjekte: Thing-Type • 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)

39. 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“

40. 5. KCPM-Entwurfsobjekte: Connection-Type • Connection-Type • Assoziationen / Beziehungen / Generalisierungen • Zwei (oder mehr) Perspektiven -> Eine Verbindung • 1) „Jede Hochschule hat einen Namen.“ • 7) „Personen sind Professoren, Studenten und Tutoren.“

41. 5. KCPM-Entwurfsobjekte: Connection-Type • Mehrstellige Beziehungen • 1) „Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.“

42. 5. KCPM-Entwurfsobjekte: Operation-Type • Operation-Type • Generalisierung von Use-Case, Aktivität, Aktion, Methode, Service ect. • Aktoren (thing-types), acting & calling • Service-Parameter

43. 5. KCPM-Entwurfsobjekte: Cooperation-Type • Cooperation-Type • Aktoren, die unter bestimmten Bedingungen (pre-condition) Operationen ausführen und Nachbedingungen (post-condition) schaffen

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

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

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

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