Inhalt Modellierung funktionaler Aspekte in der objektorientierten Analyse

1. 6. Operationenmodellierung mit Kontrakten • Inhalt • Modellierung funktionaler Aspekte in der objektorientierten Analyse • Kontrakte/Verantwortlichkeiten • Kontrakte im POS Beispiel • 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 1990

2. 6. Operationenmodellierung mit Kontrakten Modellierung funktionaler Aspekte in der OOA • 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

3. 6. Operationenmodellierung mit Kontrakten 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). • 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() zwischenboolean compare() und int equals()soll gelten: o1, o2 Objekte o1.equals(o2)=true ANDcompare(o1,o2)=0 • Kontrakte werden deklarativ beschrieben, durch logische Bedingungen

4. 6. Operationenmodellierung mit Kontrakten Unterschied zu Kontrakten im Entwurf: • 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

5. :System : Cashier makeNewSale() addLineItem(itemID, quantity) description, total * [more items] endSale() total with taxes makePayment(amount) change due, receipt 6. Operationenmodellierung mit Kontrakten • Ausgangspunkt: Arbeitsschritte der UseCase Beschreibungen • Sicht: System als Blackbox in seinen Interaktionen mit Benutzer / externen Akteuren. Jeder Arbeitsschritt des Systems ist eine potentielle Operation. • auf diese Eingabeereignisse • antworten mögliche Operationen des Systems: • - addLineItem • - endSale • - . . . • in Anlehnung an die objekt- • orientierte Programmierung • in der Nachrichten Methoden • aktivieren

6. 6. Operationenmodellierung mit Kontrakten Beispiel POS Terminal: Kontrakt CO2: enterItem 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 Sales LineItem quantity * 1.. Contained-in 1 Sale date time

7. 6. Operationenmodellierung mit Kontrakten die Teile einer Kontrakt-Beschreibung 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 Parameter geben nur die Daten aus und in den Kontext, nicht aber die Daten aus dem Domänenmodell an !

8. 6. Operationenmodellierung mit Kontrakten Vor- und Nachbedingungen 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

9. 6. Operationenmodellierung mit Kontrakten Problem bei Nachbedingungsmodellierung: welche Sicht wird im Domänenmodell eingenommen? Sicht auf Objektmodell Sicht auf DB-Modell • 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)

10. 6. Operationenmodellierung mit Kontrakten Regeln für Kontrakte: • 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

11. 6. Operationenmodellierung mit Kontrakten Kontrakt: Co1 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 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 Co2

12. 6. Operationenmodellierung mit Kontrakten Kontrakt: Co3 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 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 Co4

13. 6. Operationenmodellierung mit Kontrakten 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

14. Datenflussdiagramme Methoden der Definitionsphase SB Lohnabrechnung Personal-Lohndaten Steuersätze Gehaltssätze Periode berechne Bruttolohnfür Angestellte Steuerdaten hole Lohndaten Arbeitszeiten + Besoldungsdaten Bruttolohn für Angestellte berechne Abzüge Arbeitszeiten + Besoldungsdaten für Stundenkräfte Abzüge Bruttolohn berechne Bruttolohn für Stundenkräfte Personal-Lohndaten berechne Nettolohn Nettolohn erstelle Lohnabrechnung Personal-daten Mitarbeiter-Lohn-abrechnung

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

16. 6. Operationenmodellierung mit Kontrakten Unterschied zu Datenfluss-Diagrammen zu a) und c): ob das ein Nachteil von Kontrakten ist, hängt vom Systemtyp ab 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

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