Überblick: |
Der Kurs Entwurf von Informationssystemen setzt den Kurs
Datenbanksysteme fort und beschäftigt sich mit dem Entwurf
und der Modellierung von Datenbanksystemen. Es wird die
graphische Software-Beschreibungssprache Unified Modeling
Language (UML) mit ihren verschiedenen
Diagrammarten (Use case, Class, Object, Sequence,
Collaboration, Statechart, Activity, Component und Deployment
Diagramm) diskutiert. Ausführlich behandelt werden die
formale Semantik von ausgewählten UML-Sprachmitteln und die
Beziehungen der UML-Sprachmittel untereinander. Weitere
Schwerpunkte bilden die Object Constraint
Language OCL (eine textuelle Teilsprache innerhalb von
UML) und das UML-Metamodell. Angewendet wird UML um den
konzeptionellen und logischen Entwurf von Datenbankschemata
vorzunehmen und die Grundlagen von Datenmodellen formal zu
beschreiben.
The course Design of Information Systems continues the course
Database Systems and studies design and modeling of Database
Systems. The course introduces the Unified Modeling
Language UML with its different diagram forms (Use
case, Class, Object, Sequence, Collaboration, Statechart,
Activity, Component, and Deployment diagram). The formal
semantics of selected UML language features and the relationships
between such language features is treated. Further central topics
include the Object Constraint Language OCL (a textual
sublanguage within UML) and the UML metamodel. UML is applied to
carry out the conceptual and logical design of database schemata
and to describe the fundamentals of data models in a formal way.
|
Termine: |
Mündlichen Prüfungen (Termine im 20-Minuten-Takt; keine Termine für Fachgespräche):
- Die Termine werden noch bekannt gegeben.
Die Prüfungen finden im Raum MZH 8150 statt.
Die Anmeldung zur mündlichen Prüfung erfolgt über das
Wiki der Veranstaltung im Stud.IP.
Vorlesung:
- Donnerstag: 10:15 - 11:45, wöchentlich (ab 16.04.2015), Vorlesung, Ort: GW1 C1070
- Donnerstag: 14:15 - 15:45, wöchentlich (ab 16.04.2015), Vorlesung, Ort: SFG 1080
Behandelte Themen:
Tutorium (geleitet von Matthias Sedlmeier, E-Mail: ms at tzi.de)
- Mittwoch: 10:15 - 11:45, wöchentlich (ab 22.04.2015), Übung, Ort: SFG 2080
|
---|
Material zur Hausarbeit: |
Struktur einer UML/OCL-Hausarbeit bzw. einer Fallstudie:
- informelle Beschreibung des modellierten Weltausschnitts;
Vorstellung im Tutorium; Abstimmung mit den Betreuern
Klassenstruktur
- Grundsätzlich: Sinnhafte, aber dennoch
möglichst kurze, und sprechbare Bezeichner
für alle Modellelemente wählen; also
z.B. für Klassen (z.B. Person, Company),
Attribute (z.B. salary), Operationen (z.B. raise,
raiseSal, raiseSalary, hire, fire), Parameter
(z.B. aSalary, anEmployer), Assoziationen (z.B.
WorksFor, Job, Employment, Marriage, Fatherhood,
Authorship), Rollen (z.B. employer, employee),
Invarianten (z.B. nameUnique, agePositive,
ageGreaterEqual0, age_GE_0, maleHasNoHusband),
Vorbedingungen (z.B. salaryRaisePositive,
aPercentBetween0And10, selfIsFemale, isFemale)
und Nachbedingungen (z.B. salaryAssigned,
nameModified, jobLinkEstablished), Bezeichner
entweder einheitlich Deutsch oder einheitlich
Englisch, Bezeichner im Java-Stil, also mit
Klein- und Großbuchstaben, in der Regel ohne
Unterstrich.
- je nach Umfang ein oder mehrere Klassendiagramme
- falls erforderlich Details verbergen, wie z.B.
Attribut-, Operations-, Assoziations-,
Rollennamen, Multiplizitätsangaben
- es müssen aber alle Details in der
Gesamtheit der Diagramme bzw. im Diagramm
dargestellt werden
- verbale Erläuterung der Klassen, Attribute,
Assoziationen, Rollen und
Multiplizitätsangaben, gegebenenfalls auch
der Vererbungsbeziehungen
- Diskussion verschiedener Modellierungsmöglichkeiten
(z.B. ternäre Beziehung vs. Assoziationsklasse vs.
Klasse + Assoziation)
Invarianten
- verbale Erläuterung
- Invariantentext
- Diskussion der Konsistenz, Vollständigkeit
und Unabhängigkeit der Gesamtheit der
Invarianten
- Constraints, also Invarianten und Vor- und Nachbedingungen,
sollten in der Regel möglichst begrenzte
Sachverhalte formulieren, eine Invariante soll
z.B. *nicht* als 'A and B' formuliert werden,
wenn 'A' und 'B' nicht in einem (zwingendem)
Zusammenhang stehen (z.B. 11 <=numPlayers and
numPlayers<=13), besser ist hier die Formulierung
mit zwei unabhängigen Invarianten
-
Operationen (inklusive der Parameter und
möglicher Rückgabewerte)
- verbale Erläuterung der Operation und der
Vor- und Nachbedingungen
- Text der Vor- und Nachbedingungen zusammen mit
Operationssignatur
- verbale Erläuterung der Realisierung der
Operation
- Kommandosequenz, Generator-Prozedur oder SOIL-Definitionen mit Kommentaren
- universell einsetzbar, gesteuert über
Parameter
- enthalten keine konkreten Objekte wie
'ada:Person' oder 'ibm:Company'
Szenarios (Testfälle)
- verbale Erläuterung der Auswahl der Szenarios
- Gesamtheit der Szenarios muss alle interessanten
Eigenschaften des beschriebenen Systems verdeutlichen
- bezogen auf die Gesamtheit aller Szenarios: alle Klassen und
Assoziationen müssen instanziiert werden, alle Attribute
müssen verwendet werden, alle Operationen müssen
aufgerufen werden
- positive und negative Szenarios
- positiv: Invarianten und Vor- und Nachbedingungen sind erfüllt
- negativ: mindestens eine Invariante oder Vor- und Nachbedingung schlägt fehl
- verbale Erläuterung des einzelnen Szenarios
- Dokumentation der Szenarios in angemessener Weise als
Kommandosequenz, Kommandosequenz-Protokoll (z.B. bei Fehlschlagen
von Vor- oder Nachbedingungen), Sequenzdiagramm und
gegebenenfalls mit einem oder mehreren Objektdiagrammen, u.U.
auch für Zwischenschritte
- Erläuterung des Erfülltseins oder des Fehlschlagens
von Invarianten oder Vor- und Nachbedingungen
- enthalten konkrete Objekte wie 'ada:Person' oder
'ibm:Company' und konkrete Abläufe wie 'ibm hires ada; sun
fires bob'
- rufen (die universellen) Kommandosequenzen,
Generator-Prozeduren oder SOIL-Definitionen mit den konkreten Objekten oder Werten
auf
Anfragen (OCL-Terme, Queries)
- verbale Erläuterung der Anfrage
- gegebenenfalls Erklärung von Details oder Besonderheiten
der eingesetzten OCL-Sprachmittel
- Auswertung in der Regel in mehreren Objektdiagrammen
- Gesamtheit der ausgewählten Objektdiagramme muss die
Anfrage verdeutlichen
- jeweils Anfrageergebnis
Äußere Form der eigentlichen Hausarbeit
- PDF-Dokument, Din A4, 11pt, möglichst LaTeX,
Schriftgröße in Diagrammen auch etwa 11pt, keine
unnötigen weißen Flächen in Diagrammen, keine dunklen
Hintergründe, keine Screenshots der Kommando-Shell,
Kommandosequenzen und Kommandosequenz-Protokolle in Textform
(erhalten mittels 'Markieren' und 'Kopieren' aus der
Komando-Shell), anschließend Bereinigung von
unübersichtlichen Umbrüchen, Vereinfachung von Pfaden
und Erstellung eines übersichtlichen, klaren Layouts
|