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

Download Ontologien: UML & KCPM Jan Borgmann & Daniel Aigner borgmann / aigner@mathematik.uni-marburg.de

Post on 05-Apr-2015

103 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li> Folie 1 </li> <li> Ontologien: UML &amp; KCPM Jan Borgmann &amp; Daniel Aigner borgmann / aigner@mathematik.uni-marburg.de </li> <li> Folie 2 </li> <li> 1 Inhalt 1.Einfhrung 2.Anwendungbeschreibung (Ausschnitt) 3.Bisherige Lsungen Was ging nicht? 4.UML a.Klassendiagramm b.Herangehensweise &amp; Probleme c.OCL 5.KCPM (Klagenfurt Conceptual Predesign Model) a.Motivation b.Glossare c.KCPM-Entwurfsobjekte &amp; Unsere Lsung 6.Vergleich mit bisherigen Lsungen 7.Resmee &amp; Quellen </li> <li> Folie 3 </li> <li> 2 1. Einfhrung 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 fr das konzeptionelle Design KCPM fr Ontologien im frhen Stadium von Softwareprojekten </li> <li> Folie 4 </li> <li> 3 2. Anwendungsbeschreibung (Auszug) 1) Jede Hochschule hat einen Namen. 2) Eine Hochschule hat mehrere Fachbereiche und mehrere Rume. 3) Jeder Raum hat eine Nummer. 17) Zu den Vorlesungen werden wchentlich bungszettel von den Studenten bearbeitet und von den Tutoren korrigiert 19) Bei erfolgreicher Teilnahme an einer Veranstaltung erhlt der Student einen unbenoteten Schein 22) Er [der Professor] bewertet die in dieser Veranstaltung erbrachten Prfungsleistungen. 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. </li> <li> Folie 5 </li> <li> 4 3. Bisherige Lsungen Was ging nicht? Drei- oder mehrstellige Beziehungen Assoziations-Klassen Komplexere Prdikatenlogische Strukturen Zeitliche Zusammenhnge Was knnte man verbessern? bersichtlicher (Attribute) Besser verstndlich fr nicht-Informatiker Automatisierung </li> <li> Folie 6 </li> <li> 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 knnen) und deren Beziehungen </li> <li> Folie 7 </li> <li> 6 4. UML-Klassendiagramm Klassen, Attribute und Operationen Bsp: Fachbereiche haben Name und eine Nummer. Attribute und Operationen knnen als public (+), geschtzt (#), package protected(~) oder private(-) gekennzeichnet werden, sowie einen Typ und einen Wert haben </li> <li> Folie 8 </li> <li> 7 4. UML-Klassendiagramm Abstrakte Klassen Klassen, von denen keine Instanzen erzeugt werden sollen Der Klassename wird dabei kursiv geschrieben </li> <li> Folie 9 </li> <li> 8 4. UML-Klassendiagramm Abstrakte Klassen Bsp: Personen sind Professoren, Studenten und Tutoren. </li> <li> Folie 10 </li> <li> 9 4. UML-Klassendiagramm Beziehungen Aggregation / schwache Aggregation Bidirektionale Assoziation / Assoziation Abhngigkeit Generalisierung Unidirektionale Assoziation Komposition / starke Aggregation </li> <li> Folie 11 </li> <li> 10 4. UML-Klassendiagramm Generalisierung Bsp: Tutoren sind Studenten. </li> <li> Folie 12 </li> <li> 11 4. UML-Klassendiagramm Aggregation Bsp: Eine Hochschule hat mehrere Fachbereiche und mehrere Rume. </li> <li> Folie 13 </li> <li> 12 4. UML-Klassendiagramm Assoziation Zu den Vorlesungen werden wchentlich bungszettel von den Studenten bearbeitet und von den Tutoren korrigiert. </li> <li> Folie 14 </li> <li> 13 4. UML-Klassendiagramm Zustzliche Charakterisierungen von Assoziationen Rolle Assoziations Bezeichnung / Name Multiplizitten </li> <li> Folie 15 </li> <li> 14 4. UML-Klassendiagramm Drei- oder Mehrstellige Beziehungen Bsp: Jede Veranstaltung und jedes Tutorium findet zu bestimmten Zeiten in einem bestimmten Raum statt. </li> <li> Folie 16 </li> <li> 15 4. UML-Klassendiagramm Assoziationsklassen hnlich zu dreistelligen Beziehungen, jedoch ist Assoziationsklasse immer an Assoziation gebunden. Auerdem werden diese i.d.R. neu erzeugt und kommen nicht in der Beschreibung als Nomen vor </li> <li> Folie 17 </li> <li> 16 4. UML-Klassendiagramm Problem: Interpretation notwendig Zu einer Arbeitsgruppe gehren Personen. Kann eine Person auch in mehreren Arbeitsgruppen sein? Mssen es wirklich Personen sein, oder reicht auch eine einzelne Person / knnte auch eine Arbeitsgruppe mit 0 Personen erlaubt sein? </li> <li> Folie 18 </li> <li> 17 4. UML-Klassendiagramm Problem: Interpretation notwendig </li> <li> Folie 19 </li> <li> 18 4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung a) Zu einer Veranstaltung knnen 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. </li> <li> Folie 20 </li> <li> 19 4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung a) -&gt; Veranstaltung hat 0..* Tutorien (knnen angeboten werden) b) -&gt; Vorlesungen haben 1..* Tutorien (es gibt zu Vorlesungen Tutorien) </li> <li> Folie 21 </li> <li> 20 4. UML-Klassendiagramm Problem: Unklarheiten in der Beschreibung Verschiedene Lsungen: </li> <li> Folie 22 </li> <li> 21 4. UML-Klassendiagramm Erkennung von Drei-&amp;Mehrstelligen Beziehungen In einem Raum finden zu einer Zeit stets nur eine Veranstaltung oder ein Tutorium statt. </li> <li> Folie 23 </li> <li> 22 4. UML-Klassendiagramm Effizientes Arbeiten Eine Veranstaltung hat auerdem eine Prfungsform. Mgliche Lsung: Prfungsform als Attribut von Veranstaltung speichern, vom Typ String. Problem: Mehrfaches abspeichern von 4 Strings ist uneffizient </li> <li> Folie 24 </li> <li> 23 4. UML-Klassendiagramm Effizientes Arbeiten </li> <li> Folie 25 </li> <li> 24 4. UML-Klassendiagramm Mgliche 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 Lsung der bungszettel gegeben und bereits korrigierte bungszettel besprochen. Eine Methode besprecheUebungszettel() fr Tutoren ist nur zur Darstellung des Ablaufs relevant, in Hinsicht auf eine sptere Programmierung jedoch nicht </li> <li> Folie 26 </li> <li> 25 4. UML-Klassendiagramm Mgliche 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 </li> <li> Folie 27 </li> <li> 26 4. UML-Klassendiagramm Erstellen der Klassen </li> <li> Folie 28 </li> <li> 27 4. UML-Klassendiagramm Einfgen der Beziehungen </li> <li> Folie 29 </li> <li> 28 4. UML-Klassendiagramm Problem: Jeder Student ist an mindestens einem Fachbereich eingeschrieben. Zu einer Arbeitsgruppe gehren 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 </li> <li> Folie 30 </li> <li> 29 4. UML-Klassendiagramm </li> <li> Folie 31 </li> <li> 30 4. UML-Klassendiagramm Untersttzung durch Tools (hier MagicDraw UML): </li> <li> Folie 32 </li> <li> 31 4. UML-Klassendiagramm OCL = Object Constraint Language Bestandteil der UML, ist als Ergnzung gedacht Dient der textuellen Spezifikation Soll zu einer prziseren Modellierung der Software fhren Ist widerspruchsfrei, jedoch rein textuell </li> <li> Folie 33 </li> <li> 32 4. UML-Klassendiagramm OCL = Object Constraint Language Beispiele: Context Student inv: self.Matrikelnummer &gt; 0 Context Zeit inv: self.Anfangszeit &lt; self.Endzeit Context Person inv: Altersize()=0 </li> <li> Folie 34 </li> <li> 33 4. UML-Klassendiagramm Vor- und Nachteile bei UML Mit UML lie sich alles darstellen, das ganze steht und fllt jedoch mit der Beschreibung des Anwendungsbereichs Diese ist in den seltensten Fllen eindeutig und perfekt, es kann also nicht automatisch modelliert werden, sondern der Modellierer muss hufig interpretieren und sich auf seine Erfahrung verlassen </li> <li> Folie 35 </li> <li> 34 5. KCPM Motivation: Konzeptuelles Schema (UML) nicht leicht verstndlich Zwischenstufe: Klagenfurt Conceptual Predesign Method/Model Basiert auf Glossaren Anforderungen sammeln, analysieren und validieren </li> <li> Folie 36 </li> <li> 35 5. KCPM: Was sind Glossare? Wiki: Ein Glossar [] ist eine Liste von Wrtern mit Erklrungen. Sammlungen erklrungsbedrftiger Wrter listet die Terminologie [] eines technischen Sachgebietes mit begrifflich-sachlichen Definitionen, die den richtigen Gebrauch dieser Fachausdrcke und deren eindeutiges Verstndnis sichern sollen. Tabellen mit Informationen Glossare als zentrale Wissensdatenbank zum Zusammentragen, Speichern und Austauschen von Wissen ber das Anwendungsgebiet whrend der frhen Software-Entwicklungsphase Semi-Formale Ontologie </li> <li> Folie 37 </li> <li> 36 5. KCPM-Entwurfsobjekte KCPM-Entwurfsobjekte: Statisch: Thing-Type, Connection-Type Dynamisch: Operation-Type, Connection-Type KCPM-Metamodell (statischer Teil) aus [3] </li> <li> Folie 38 </li> <li> 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 spter Meta-Informationen knnen 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 </li> <li> Folie 39 </li> <li> 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 40.00 0 Alle die mit der Uni zu tun haben. Satz 6, 7, 8 D 08 professorthing- type 200Satz 7, 21, 22 D 09 studentthing- type 40.0 00 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 </li> <li> Folie 40 </li> <li> 39 5. KCPM-Entwurfsobjekte: Connection-Type Connection-Type Assoziationen / Beziehungen / Generalisierungen Zwei (oder mehr) Perspektiven -&gt; 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 </li> <li> Folie 41 </li> <li> 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 </li> <li> Folie 42 </li> <li> 41 5. KCPM-Entwurfsobjekte: Operation-Type Operation-Type Generalisierung von Use-Case, Aktivitt, Aktion, Methode, Service ect. Aktoren (thing-types), acting &amp; calling Service-Parameter o-id#nameactorcalling-actor service- parameter O01 klausur- nachberichtigung D08 professor D09 student D24 schriftliche_prfu ng, Fehler in Aufgabe 3 O02ndern der scheinote D03 fachbereich D09 studentD22 note </li> <li> Folie 43 </li> <li> 42 5. KCPM-Entwurfsobjekte: Cooperation-Type Cooperation-Type Aktoren, die unter bestimmten Bedingungen (pre-condition) Operationen ausfhren und Nachbedingungen (post-condition) schaffen coop-id#namepre-condition involved operations post-condition Co01 Noten- berichtigung Student bemerkt Fehler in Korrektur O01, O02 Note fr die Vorlesung wurde korrigiert </li> <li> Folie 44 </li> <li> 43 5. KCPM: Vorteile / Nachteile + Leicht verstndlich + Keine neuen Strukturen zu lernen + Flexibel, modular, einfach zu handhaben fr Benutzer, Anwendungsgebiet- und Software-Experten - Aufwndig zu erstellen und umzuwandeln + Semi-Automatisierung mglich (Projekt NIBA) - Unbersichtlich - Schwer zu berblicken ob evtl. Verbindungen fehlen ect. </li> <li> Folie 45 </li> <li> 44 6. Vergleich mit bisherigen Lsungen Was ging nicht? Drei- oder mehrstellige Beziehungen Assoziations-Klassen Komplexere Prdikatenlogische Strukturen Zeitliche Zusammenhnge Was knnte man verbessern? bersichtlicher (Attribute) Besser verstndlich fr nicht-Informatiker Automatisierung </li> <li> Folie 46 </li> <li> 45 7. Resmee UML gut und bersichtlich fr Experten Eher in der spteren Projektphase Evtl. schwer verstndlich KCPM fr alle leicht verstndlich Zwischen Anwendungsbeschreibung und Modell Unbersichtlich Semi-automatisierung mglich </li> <li> Folie 47 </li> <li> 46 7. Quellen [1] Fliedl, Kop, Mayr, Mayerthaler, Winkler, Linguistically based requirements engineering - The NIBA-project, 2000. [2] Fliedl, Kop, Mayr, Salbrechter, Vhringer, Weber, Winkler, Deriving static and dynamic concepts from software requirements using sophisticated tagging, 2006. [3] Bachmann, Hesse, Russ, Kop, Mmayr, Vhringer, 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 &amp; Wissensreprsentation, SS2008. [6] Hesse, Skript: Einfhrung 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 </li> </ul>