Ontologien:Ontologien: UML & KCPM UML & KCPM
Jan Borgmann & Daniel Aignerborgmann / [email protected]
2Inhalt
1. Einführung
2. Anwendungbeschreibung (Ausschnitt)
3. Bisherige Lösungen – Was ging nicht?
4. UMLa. Klassendiagramm
b. Herangehensweise & Probleme
c. OCL
5. KCPM (Klagenfurt Conceptual Predesign Model)
a. Motivation
b. Glossare
c. KCPM-Entwurfsobjekte & Unsere Lösung
6. Vergleich mit bisherigen Lösungen
7. Resümee & Quellen
31. 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
42. 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.
53. 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
64. 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
74. 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
84. UML-Klassendiagramm
Abstrakte Klassen
Klassen, von denen keine Instanzen erzeugt werden sollen
Der Klassename wird dabei kursiv geschrieben
94. UML-Klassendiagramm
Abstrakte Klassen
Bsp: Personen sind Professoren, Studenten und Tutoren.
104. UML-Klassendiagramm
Beziehungen
Aggregation / schwache Aggregation
Bidirektionale Assoziation / Assoziation
Abhängigkeit Generalisierung Unidirektionale
Assoziation Komposition / starke
Aggregation
114. UML-Klassendiagramm
Generalisierung
Bsp: Tutoren sind Studenten.
124. UML-Klassendiagramm
Aggregation
Bsp: Eine Hochschule hat mehrere Fachbereiche und mehrere Räume.
134. UML-Klassendiagramm
Assoziation „Zu den Vorlesungen werden wöchentlich Übungszettel
von den Studenten bearbeitet und von den Tutoren korrigiert.“
144. UML-Klassendiagramm
Zusätzliche Charakterisierungen von Assoziationen
Rolle
Assoziations
Bezeichnung / Name
Multiplizitäten
154. UML-Klassendiagramm
Drei- oder Mehrstellige Beziehungen
Bsp: „Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.“
164. 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
174. 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?
184. UML-Klassendiagramm
Problem: Interpretation notwendig
194. 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.“
204. 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)
214. UML-Klassendiagramm
Problem: Unklarheiten in der Beschreibung Verschiedene Lösungen:
224. UML-Klassendiagramm
Erkennung von Drei-&Mehrstelligen Beziehungen „In einem Raum finden zu einer Zeit stets nur eine
Veranstaltung oder ein Tutorium statt.“
234. 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
244. UML-Klassendiagramm
Effizientes Arbeiten
254. 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
264. 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
274. UML-Klassendiagramm
Erstellen der Klassen
284. UML-Klassendiagramm
Einfügen der Beziehungen
294. 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
304. UML-Klassendiagramm
314. UML-Klassendiagramm
Unterstützung durch Tools (hier MagicDraw UML):
324. 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
334. 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
344. 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
355. KCPM
Motivation: Konzeptuelles Schema (UML) nicht leicht verständlich
→ Zwischenstufe:Klagenfurt Conceptual Predesign Method/ModelBasiert auf GlossarenAnforderungen sammeln, analysieren und validieren
365. 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
375. KCPM-Entwurfsobjekte
KCPM-Entwurfsobjekte:– Statisch: Thing-Type, Connection-Type– Dynamisch: Operation-Type, Connection-Type
KCPM-Metamodell (statischer Teil) aus [3]
385. KCPM-Entwurfsobjekte: Thing-Type
Thing-TypeKlassen und Attribute1) „Jede Hochschule hat einen Namen.“
Entscheidung ob Thing-Typ Klasse oder Attribut nicht wichtig, erst späterMeta-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
D
02
Name thing-type
„Uni Marburg“
String Satz 01, 04, 08, 12
395. KCPM-Entwurfsobjekte: Thing-Type
id# name classi-fication
quan-tity
examples value domain
syno-nyms
textual description
requi-rement sources
D07
person thing-type
40.000
Alle die mit der Uni zu tun haben.
Satz 6, 7, 8
D08
professor thing-type
200 Satz 7, 21, 22
D09
student thing-type
40.000
D18 Satz 7, 8, 9, 10, 16..
…
D18
teilnehmer_der_vl
thing-type
D09 Satz 16
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“
405. KCPM-Entwurfsobjekte: Connection-Type
Connection-TypeAssoziationen / Beziehungen / GeneralisierungenZwei (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
name 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
1..1
C
02
is-a P02-1 D07 Professor is_a 1..1 Satz 02
P02-2 D06 Person can_be 1..1
415. KCPM-Entwurfsobjekte: Connection-Type
Mehrstellige Beziehungen1) „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
name 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
1..1
425. KCPM-Entwurfsobjekte: Operation-Type
Operation-Type
Generalisierung von Use-Case, Aktivität, Aktion, Methode, Service ect.Aktoren (thing-types), acting & callingService-Parameter
o-id# name actor calling-actorservice-
parameter
O01klausur-
nachberichtigungD08
professorD09 student
D24 schriftliche_prüfu
ng, „Fehler in Aufgabe 3“
O02 ändern der scheinoteD03
fachbereichD09 student D22 note
435. KCPM-Entwurfsobjekte: Cooperation-Type
Cooperation-Type
Aktoren, die unter bestimmten Bedingungen (pre-condition) Operationen ausführen und Nachbedingungen (post-condition) schaffen
coop-id# name pre-conditioninvolved
operationspost-condition
Co01Noten-
berichtigungStudent bemerkt
Fehler in KorrekturO01, O02
Note für die Vorlesung
wurde korrigiert
445. 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.
456. 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
467. 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
477. 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