Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann /"—  Präsentation transkript:

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

2 1 Inhalt 1.Einführung 2.Anwendungbeschreibung (Ausschnitt) 3.Bisherige Lösungen – Was ging nicht? 4.UML a.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

3 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

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

5 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

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

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

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

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

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

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

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

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

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

16 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

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

18 17 4. UML-Klassendiagramm Problem: Interpretation notwendig

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

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

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

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

23 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

24 23 4. UML-Klassendiagramm Effizientes Arbeiten

25 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

26 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

27 26 4. UML-Klassendiagramm Erstellen der Klassen

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

29 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

30 29 4. UML-Klassendiagramm

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

32 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

33 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

34 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

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

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

38 37 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) id#nameclassi- fication quan- tity examplesvalue domain syno- nyms textual description requi- rement sources D 01 Hochschulething- type 120Unis/FHs in Deutsc. Satz 01, 02 D 02 Namething- type Uni Marburg StringSatz 01, 04, 08, 12

39 38 5. KCPM-Entwurfsobjekte: Thing-Type id#nameclassi- fication quan- tity examplesvalue domai n syno- nyms textual descrip tion requi- rement sources D 07 personthing- type Alle die mit der Uni zu tun haben. Satz 6, 7, 8 D 08 professorthing- type 200Satz 7, 21, 22 D 09 studentthing- type D18Satz 7, 8, 9, 10, 16.. … D 18 teilnehmer_d er_vl thing- type D09Satz 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

40 39 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. c- id# namec-type deter- miner perspectiverequi- rement sources p-id#involved thing- type namemin/ max perspective determiner C 01 has-aP01-1D01 Hochschulehas_a1..1Satz 01, 02, 03, … P01-2D02 Namebelogn s_to 1..1 C 02 is-aP02-1D07 Professoris_a1..1Satz 02 P02-2D06 Personcan_be1..1

41 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 # namec-type deter- miner perspectiverequi- rement sources p-id#involved thing-type namemin/ max persp- ective deter- miner C3 5 veranstalt ung/raum /zeit P35-1D12 veranstaltung findet_ statt_in 1..nSatz 27 P35-2D04 raumbelegt_ von 1..1 P35-3D28 zeitzur_zei t 1..1

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

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

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

45 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

46 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

47 46 7. Quellen [1] Fliedl, Kop, Mayr, Mayerthaler, Winkler, Linguistically based requirements engineering - The NIBA-project, [2] Fliedl, Kop, Mayr, Salbrechter, Vöhringer, Weber, Winkler, Deriving static and dynamic concepts from software requirements using sophisticated tagging, [3] Bachmann, Hesse, Russ, Kop, Mmayr, Vöhringer, OBSE – an approach to Ontology-based Software Engeneering in the practice, [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, [7] de.wikipedia.com, stand [8] stand


Herunterladen ppt "Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann /"

Ähnliche Präsentationen


Google-Anzeigen