Inhalt UML KCPM (Klagenfurt Conceptual Predesign Model) Einführung

Präsentation zum Thema: "Inhalt UML KCPM (Klagenfurt Conceptual Predesign Model) Einführung"—  Präsentation transkript:

0 Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann /

1 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

2 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

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

4 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

5 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

6 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

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

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

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

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

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

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

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

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

15 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

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

17 4. UML-Klassendiagramm Problem: Interpretation notwendig

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

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

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

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

22 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

23 4. UML-Klassendiagramm Effizientes Arbeiten

24 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

25 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

26 4. UML-Klassendiagramm Erstellen der Klassen

27 4. UML-Klassendiagramm Einfügen der Beziehungen

28 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

29 4. UML-Klassendiagramm

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

31 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

32 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

33 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

34 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

35 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

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

37 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

38 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

39 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

40 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

41 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

42 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

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

44 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

45 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

46 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 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 [8] stand