Inhalt 1.Modellierung funktionaler Aspekte in der objektorientierten Analyse 2.Kontrakte/Verantwortlichkeiten 3.Kontrakte im POS Beispiel 4.Vergleich mit Datenflussdiagrammen Lernziele: die objektorientierte Sicht auf die funktionalen Anforderungen insgesamt kennenlernen die Verbindung zwischen Use Cases und Operationen des Systems verstehen die Modellierungstechnik für Kontrakte an Beispielen kennenlernen Abgrenzung zur nicht-objektorientierten Analyse ziehen können Referenzen: Larman, Kapitel 13 B. Meyer: Objektorientierte Softwareentwicklung, Hanser Verlag 1990 Rebecca Wirfs-Brock: Designing Object-Oriented Software Prentice Hall Operationenmodellierung mit Kontrakten

Ausgangspunkt: Arbeitsschritte der detaillierten UseCase Beschreibungen Sicht: System als Blackbox in seinen Interaktionen mit dem Benutzer / externen Akteuren. Jeder Arbeitsschritt des Systems ist eine potentielle Operation Modell: Kontrakt (Vertrag) zwischen System und Umgebung in Form von Vor- und Nachbedingungen auf den Objekten des Domänenmodells, und Operations- signatur Ziel: die funktionale Sicht der UseCases und die Datensicht des Domänenmodells zusammenzubringen methodische Besonderheiten: –keine Zuordnung von Operationen zu Klassen (erst im Design) –deklarative (WAS), nicht prozedurale (WIE) Beschreibung der Funktionalität 6. Operationenmodellierung mit Kontrakten Modellierung funktionaler Aspekte in der OOA

Kontrakte kommen ursprünglich aus dem objektorientierten Entwurf (Bertrand Meyer: Eiffel, Rebecca Wirfs-Brock: Smalltalk) Kontrakte sind "Verträge" Beispiel aus JAVA: Kontrakt (Vertrag) zwischen compare() und equals() zwischen boolean compare() und int equals() soll gelten : o1, o2 Objekte o1.equals(o2) = true AND compare(o1,o2) = 0 Kontrakte werden deklarativ beschrieben, durch logische Bedingungen Ein Kontrakt ist eine abstrakte Beschreibung einer Operation. Er beschreibt die Verantwortlichkeit (Postcondition), die das System übernimmt, wenn die Operation richtig benutzt wird (Precondition). Dazu gehört auch die Angabe ihrer Signatur (Schnittstelle). 6. Operationenmodellierung mit Kontrakten

es wird keine Operation eines bestimmten Objektes modelliert man tut so, als ob alle Daten des Domänenmodells frei zugänglich seien deshalb: die Signatur (Schnittstelle) gibt neben dem Namen der Operation nur die Eingabewerte vom Systemkontext als Parameter an, und Rückgabe nur solcher Werte die in den Systemkontext gehen: Blackbox-Sicht die Signatur muss nicht im Design übernommen werden Begründung: Operationenpositionierung ist ausschliesslich Sache des Entwurfs 6. Operationenmodellierung mit Kontrakten Unterschied zu Kontrakten im Entwurf:

Ausgangspunkt: Arbeitsschritte der UseCase Beschreibungen Sicht: System als Blackbox in seinen Interaktionen mit Benutzer / externen Akteuren. Jeder Arbeitsschritt des Systems ist eine potentielle Operation. 6. Operationenmodellierung mit Kontrakten auf diese Eingabeereignisse antworten mögliche Operationen des Systems: - addLineItem - endSale -... in Anlehnung an die objekt- orientierte Programmierung in der Nachrichten Methoden aktivieren

6. Operationenmodellierung mit Kontrakten Operation: enterItem(in itemID : ItemID, in quantity : Integer, out total : Integer) : ProductSpecification Querverweise:Use Case: Process Sale Vorbedingungen:ein Verkauf ist aktiv (ein Sale Objekt csl wurde erzeugt) Nachbedingungen:- eine Instanz sli von SalesLineItem wurde erzeugt - sli wurde mit dem aktuellen Verkauf csl assoziiert (Beziehung Contained-in wurde zu csl gesetzt) - sli.quantity = quantity - sli wurde mit einer ProductSpecifikation ps assoziiert wobei ps.itemID = itemID gilt Beispiel POS Terminal: Kontrakt CO2: enterItem Sale date time Sales LineItem quantity Contained-in 1.. * 1

Operation:die Operationssignatur, in folgender Form (UML): Name[(Parameterliste)] [ : Rückgabetyp ] Parameter: [Richtung] Name [ : Typ ] Richtung: in | out | inout Querverweise:meistens Use Cases Vorbedingungen:was vor Aktivierung der Operation gültig sein muss, damit die Nachbedingung garantiert werden kann Nachbedingungen:Liste von Bedingungen auf Objekten des Domänen- modells, und auf ihren Beziehungen untereinander die Teile einer Kontrakt-Beschreibung 6. Operationenmodellierung mit Kontrakten die Parameter geben nur die Daten aus und in den Kontext, nicht aber die Daten aus dem Domänenmodell an die Parameter geben nur die Daten aus und in den Kontext, nicht aber die Daten aus dem Domänenmodell an

Vor- und Nachbedingungen beschreiben den Kontrakt (Vertrag) zwischen dem Benutzer als Aktivierer einer Operation, und dem die Operation bereit- stellenden System Vorbedingungen: werden von der Operation nicht versucht, zu erfüllen - sie müssen vor Aktivierung sichergestellt sein: Teil eines Vertrages "wenn..., dann..." Nachbedingungen beschreibt die Änderungen im aktuellen Zustand der Objekte des Domänen- modells –Instanzen (Objekte) erzeugen (manchmal auch: löschen) –Setzen und Aufheben von Beziehungen –Attributänderungen 6. Operationenmodellierung mit Kontrakten Vor- und Nachbedingungen

in einem DB-Modell z.B. werden die Daten bei einer Datenerfassung wie im processSale UseCase erst am Ende desselben in die Datenbank geschrieben - was ist also die Nachbedingung des Schrittes addLineItem ? Vorgehensregel: das Domänenmodell soll beide Welten wiedergeben: die Anwendungssicht (Objektmodell) und die Datenbank-Sicht (DB-Modell) beschreibe also die fachlogische Sicht, nicht die physische oder organisa- torische Sicht auf Datenänderungen (letztere erst im Design) 6. Operationenmodellierung mit Kontrakten Problem bei Nachbedingungsmodellierung: welche Sicht wird im Domänenmodell eingenommen? Sicht auf Objektmodell Sicht auf DB-Modell

nicht für alle UseCases oder UseCase Schritte müssen Kontrakte geschrieben werden manche UseCases können als Ganzes einen Kontrakt erhalten, wie im UseCase Template bereits vorgesehen bei Vor- und Nachbedingungen sind nur Zustände von Domänenmodell- objekten wichtig. Daten, die allein die Ablauflogik steuern, werden nicht modelliert die Existenz aller nicht von der Operation erzeugten Objekte, die in der Nachbedingung referenziert werden, wird in der Vorbedingung gefordert Nachbedingungen müssen nicht vollständig sein die Kontraktmodellierung kann zu Veränderungen/Erweiterungen des Domänenmodells führen (funktionale statt Datensicht!) Hauptfehler bei Kontraktmodellierung: Assoziationen zu setzen und zu lösen wird leicht vergessen 6. Operationenmodellierung mit Kontrakten Regeln für Kontrakte:

Operation: enterItem(in itemID : ItemID, in quantity : Integer, out total : Integer) : ProductSpecification Querverweise:Use Case: Process Sale Vorbedingungen:ein Verkauf ist aktiv (ein current Sale Objekt csl wurde erzeugt) Nachbedingungen:- eine Instanz sli von SalesLineItem wurde erzeugt - sli wurde mit dem aktuellen Verkauf csl assoziiert (Beziehung Contained-in wurde zu csl gesetzt) - sli.quantity = quantity - sli wurde mit einer ProductSpecifikation ps assoziiert wobei ps.itemID = itemID gilt Operation: makeNewSale() Querverweise:Use Case: Process Sale Vorbedingungen:Register Objekt reg für diese Kasse existiert Nachbedingungen:- eine Instanz csl von Sale wurde als "current sale" erzeugt - csl wurde mit reg assoziiert (Beziehung Captured-On wurde gesetzt ) - csl.date und csl.time wurden initialisiert 6. Operationenmodellierung mit Kontrakten Kontrakt: Co1 Co2

Operation: makePayment( amount : Money ) : Money (Rückgabewert: ChangeDue) Querverweise:Use Case: Process Sale Vorbedingungen:- ein Verkauf ist aktiv (ein Sale Objekt csl wurde erzeugt) - csl.isComplete = TRUE - amount >= csl.total Nachbedingungen:- eine Instanz p von Payment wurde erzeugt - p.amounttendered = amount - p wurde mit dem aktuellen Verkauf csl assoziiert (Beziehung PaidBy) - aktueller Verkauf csl wird mit Store assoziiert ( " Logs-Completed) - Rückgabewert = amount – csl.total Operation: endSale() Querverweise:Use Case: Process Sale Vorbedingungen:ein Verkauf ist aktiv (ein Sale Objekt csl wurde erzeugt) Nachbedingungen:- csl.isComplete wurde auf TRUE gesetzt - csl.total wurde gesetzt 6. Operationenmodellierung mit Kontrakten Kontrakt: Co3 Co4

Vorteil von Kontrakten beschreiben das WAS, nicht das WIE (deklarativ, nicht prozedural) vermeiden, schon in der Analyse die Operationen den Klassen zuzuordnen Nachteil von Kontrakten sind nicht verfeinerbar sind weniger geeignet für komplexe, algorithmische Systeme legen eventuell eine entwurfsmässig schlechte funktionale Modularisierung fest, mit Gefahr, dass sie den Entwurf überlebt 6. Operationenmodellierung mit Kontrakten

hole Lohndate n Personal- Lohndaten Arbeitszeiten + Besoldungsdaten berechne Bruttolohn für Angestellte berechne Bruttolohn für Stundenkräft e Arbeitszeiten + Besoldungsdaten für Angestellte für Stundenkräfte Gehaltssätze Periode berechne Abzüge Bruttolohn Personal- Lohndaten Steuersätze Steuerdaten berechne Nettolohn Bruttolohn Abzüge erstelle Lohnabrechnun g Nettolohn Personal- daten Mitarbeiter -Lohn- abrechnung SB Lohnabrechnung Datenflussdiagramme Methoden der Definitionsphase

a)keine Angabe der benötigten Daten in Kontrakten (d.h. kein Input aus dem Domänenmodell) b)keine Verfeinerung von Kontrakten, in DFDs Verfeinerung durch das "leveling" c)keine Beziehung zwischen Operationen in Kontrakten, während in DFDs die des Produzent-Konsument von Daten zwischen Operationen 6. Operationenmodellierung mit Kontrakten Unterschied zu Datenfluss-Diagrammen op1 op2 dat1 dat2 sp1 Operation: op1(dat1 : Dat1) : Dat2 Precondition:... (dat1)... Postcondition:... (dat2)... (sp1)... Operation: op2(dat2 : Dat2) Precondition:... (dat2)... Postcondition:... (sp1)...

es hängt aber auch von der eingenommenen Sicht ab: in DFDs sind systeminterne Abläufe/Strukturen erfasst: wie werden Daten schrittweise verarbeitet bis zum Resultat? in Kontrakten wird eine reine Blackbox Sicht auf das System eingenommen: in der Systeminteraktionssicht sind die Datentransformationsschritte einer komplexen Funktion weniger wichtig als in der Sicht auf systeminterne Funktionen 6. Operationenmodellierung mit Kontrakten Unterschied zu Datenfluss-Diagrammen zu a) und c): ob das ein Nachteil von Kontrakten ist, hängt vom Systemtyp ab

6. Operationenmodellierung mit Kontrakten Unterschied zu Datenfluss-Diagrammen Fazit: der Hauptunterschied besteht darin, dass Kontrakte UseCase- orientiert sind, DFDs aber nicht. Deshalb stehen Kontrakte beziehungslos zueinander, alles wird durch das Domänenmodell und den UseCase zusammengehalten. Im DFD wird alles durch den Datenfluss zusammengehalten.