Inhalt Modellierung funktionaler Aspekte in der objektorientierten Analyse
description
Transcript of Inhalt Modellierung funktionaler Aspekte in der objektorientierten Analyse
Inhalt1. Modellierung funktionaler Aspekte in der objektorientierten Analyse2. Kontrakte/Verantwortlichkeiten3. Kontrakte im POS Beispiel4. 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
6. 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
: Cashier:System
addLineItem(itemID, quantity)
endSale()
makePayment(amount)
description, total
total with taxes
change due, receipt
* [more items]
makeNewSale()
auf diese Eingabeereignisseantworten mögliche Operationen des Systems:
- addLineItem - endSale - . . .in Anlehnung an die objekt-orientierte Programmierungin der Nachrichten Methodenaktivieren
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
datetime
SalesLineItem
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
holeLohndate
n
Personal-Lohndaten
Arbeitszeiten +Besoldungsdaten
berechne Bruttolohn
für Angestellte
berechne Bruttolohn
für Stundenkräft
e
Arbeitszeiten +Besoldungsdaten
für Angestellte
fürStundenkräfte
GehaltssätzePeriode
berechne Abzüge
Bruttolohn
Personal-Lohndaten
Steuersätze
Steuerdaten
berechne Nettolohn
Bruttolohn Abzüge
erstelle Lohnabrechnun
g
Nettolohn
Personal-daten
Mitarbeiter-Lohn-abrechnung
SBLohnabrechnung
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 op2dat1
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.