Design of Information Systems (Entwurf von Informationssystemen) (SoSe 2016, VAK 03-MB-703.02, 6 SWS / 8 ECTS)

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

Hinweise:

Allgemein:

  • Vorstellung der Veranstaltung EIS am Montag, den 04.04.2016 um 13:00 Uhr (pdf-file)
  • Diese Seiten werden während der Veranstaltung ständig ergänzt und aktualisiert.

Mündliche Prüfungen:

  • Mögliche Prüfungsbereiche (txt-file)
Termine:

Mündlichen Prüfungen am 13.7.2016 und 28.09.2016 nachmittags ab 13 Uhr.

Bitte eintragen und Termin reservieren bis 8.7.2016. Die genauen Uhrzeiten werden rechtzeitig per E-Mail (ca. 3 Tage vorher) mitgeteilt.

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 07.04.2016), Vorlesung, Ort: MZH 5210
  • Donnerstag: 14:15 - 15:45, wöchentlich (ab 07.04.2016), Vorlesung, Ort: MZH 1450

Behandelte Themen:

Tutorium (geleitet von Matthias Sedlmeier, E-Mail: ms at tzi.de)

  • Mittwoch: 10:15 - 11:45, wöchentlich (ab 13.04.2015), Übung, Ort: MZH 1450
Literatur:

James Rumbaugh and Ivar Jacobson and Grady Booch The Unified Modeling Language Reference Manual, 2nd Edition Addison-Wesley, Reading, Massachusetts, USA 2005

Material zur Vorlesung:

Folien und ergänzendes Material:

Material aus dem Tutorium:
  • Folgt
Material zur Hausarbeit:

Struktur einer UML/OCL-Hausarbeit bzw. einer Fallstudie: ENGLISH VERSION SEE BELOW

  1. informelle Beschreibung des modellierten Weltausschnitts; Vorstellung im Tutorium; Abstimmung mit den Betreuern
  2. 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)
  3. 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
  4. 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'
  5. 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
  6. 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
  7. Ä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

General structure of a UML/OCL homework resp. case study:

  1. Informal description of the modeled domain; Presentation in the tutorial; Coordination with tutor
  2. Class structure / UML class diagram(s)
    1. Fundamentals: Always choose meaningful but short and pronounceable names / identifier for all model elements like classes (e.g. Person / Company), attributes (e.g. name / salary), operations (e.g. hire, raiseSalary, fire), parameters (e.g. aSalary, anEmployer), associations / association classes (e.g. WorksFor, Marriage, Authorship), roles (e.g. employer, employee), invariants (e.g. nameUnique, agePositive, ageGreaterEqual0 or shorter, but coherent: age_GE_0), preconditions (e.g. salaryRaisePositive, aPercentBetween0and10, isFemale) and postconditions (e.g. salaryAssigned, nameModified, worksForLinkEstablished). All names / identifiers have to be consistent, i.e. in same language and textural style (upper and lower case, usage of underscore etc.).
    2. At least one class diagram, more if necessary
    3. If reasonable, hide details like attribute, operation, association and association names as well as multiplicities
    4. Verbal descriptions of classes, attributes, associations, roles, multiplicities and generalisation
    5. Discussion about diverse modeling alternatives (e.g. via ternary relationships, association classes vs. class + association)
  3. Invariants
    1. Verbal descriptions
    2. The OCL representation (expression)
    3. Discussion about consistence, integrity, completeness and independence of all invariants
    4. All constraints, i.e. invariants, pre- and postconditions, should be preferably minimal. That is, you should rather think about decomposing complex conditions, which cover multiple aspects or independent issues, into several individual conditions (e.g. [ 11 <= numberPlayers and numberPlayers <= 13 ] is split into two invariants (A) [ 11 <= numberPlayers ] as well as (B) [ numberPlayers <= 13 ]).
  4. Operations (incl. parameters and potential return values)
    1. Verbal explanation of all operations as well as pre- and postconditions
    2. The OCL representation or pre- and postconditions (expressions) as well as the operation signature
    3. Verbal description of the SOIL operation source code
    4. Command sequence, generator procedure or SOIL definitions incl. comments
    5. Please note: operations should be generic, i.e. their control flow is solely influenced by parameters and they never contain names of concrete objects like 'bob:Person' or 'ibm:Company'
  5. Scenarios (Test Cases)
    1. Verbal explanation and rationale of scenario / test case selection
    2. Your test cases should cover all interesting properties of your modeled systems
    3. Your scenarios have to cover all classes, associations, attributes, operations, etc.
    4. Please construct positive and negative scenarios
      1. positive: Invariants and pre- resp. postconditions are fulfilled
      2. negative: At least one condition (invariant, pre- or postcondition) fails
    5. Verbal description of all single test cases
    6. Documentation of your test executions: command sequence, command sequence result protocol (e.g. failing conditions), sequence diagrams, object diagrams with illegal states, etc.
    7. Explanation of failure / success of conditions (invariants, pre- and postconditions)
    8. Please note: Your test cases contain concrete objects like 'ada:Person' or 'samsung:Company' as well as concrete procedures like 'samsung hires ada; sun fires bob'. This way, they call command sequences, generator procedures or SOIL definitions with concrete objects or attribute values.
  6. Queries (OCL terms / queries)
    1. Verbal explanation of query
    2. Where necessary, describe details or particularities of the used OCL language features
    3. Evaluation of your queries represented via multiple object diagrams, which illustrate your queries
    4. Please also give the query results
  7. IMPORTANT: Form and Layout of your housework
    1. PDF document, DIN A4, 11pt (also in figure / diagrams), we recommend LaTeX, no unnecessary white spaces in diagrams, no black background color, no screen shots of the USE command shell, command sequences and protocols in textual form via mark and copy from the command shell, no confusing line breaks or word wraps, simplification of paths, clear and consistent layout
    2. Always remember: others want/must read your homework (at least Martin and me)
Beispiel-Hausarbeiten:

Home|People|Teaching|Publications
Letzte Änderung: 17.03.2015 von Matthias Sedlmeier, E-Mail: ms@tzi.de