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


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


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


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.


: 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


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


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


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)


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


Regeln für Kontrakte:

Operation: enterItem(in itemID : ItemID, in quantity : Integer, out total : Integer) : ProductSpecification


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()


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


Kontrakt:

Co1

Co2

Operation: makePayment( amount : Money ) : Money (Rückgabewert: ChangeDue)


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()


Vorbedingungen: ein Verkauf ist aktiv (ein Sale Objekt csl wurde erzeugt)

Nachbedingungen: - csl.isComplete wurde auf TRUE gesetzt- csl.total wurde gesetzt


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


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


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



zu a) und c): ob das ein Nachteil von Kontrakten ist, hängt vom Systemtyp ab



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.

Documents

Inhalt Modellierung funktionaler Aspekte in der objektorientierten Analyse