Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann / [email protected]

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


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

Klassen, von denen keine Instanzen erzeugt werden sollen

Der Klassename wird dabei kursiv geschrieben


Abstrakte Klassen

Bsp: Personen sind Professoren, Studenten und Tutoren.


Beziehungen

Aggregation / schwache Aggregation

Bidirektionale Assoziation / Assoziation

Abhängigkeit Generalisierung Unidirektionale

Assoziation Komposition / starke

Aggregation


Generalisierung

Bsp: Tutoren sind Studenten.


Aggregation

Bsp: Eine Hochschule hat mehrere Fachbereiche und mehrere Räume.


Assoziation „Zu den Vorlesungen werden wöchentlich Übungszettel

von den Studenten bearbeitet und von den Tutoren korrigiert.“


Zusätzliche Charakterisierungen von Assoziationen

Rolle

Assoziations

Bezeichnung / Name

Multiplizitäten


Drei- oder Mehrstellige Beziehungen

Bsp: „Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt.“


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


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?


Problem: Interpretation notwendig


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


Problem: Unklarheiten in der Beschreibung a) -> Veranstaltung hat 0..* Tutorien (können

angeboten werden)

b) -> Vorlesungen haben 1..* Tutorien (es gibt zu Vorlesungen Tutorien)


Problem: Unklarheiten in der Beschreibung Verschiedene Lösungen:


Erkennung von Drei-&Mehrstelligen Beziehungen „In einem Raum finden zu einer Zeit stets nur eine

Veranstaltung oder ein Tutorium statt.“


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


Effizientes Arbeiten


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


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


Erstellen der Klassen


Einfügen der Beziehungen


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



Unterstützung durch Tools (hier MagicDraw UML):


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


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


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

Documents

Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann / [email protected]