FACHHOCHSCHULE MANNHEIM

Transkript

1 Objektorientierte Programmierung 8. Vorlesung Prof. Dr. Peter Knauber FACHHOCHSCHULE MANNHEIM Hochschule für Technik und Gestaltung e Die 1. lgruppe von KobrA: Realization le der Realization: Kurze Structural e Neu: e Folie 1

2 1. lgruppe: Die Realization e Die Realization repräsentiert die Umgebung des Systems: Man kann sie sich als Component Realization ohne Spezifikation vorstellen, das heißt als eine Komponente ohne oberes Ende Ihre Entwicklung benötigt Techniken des Requirements Engineering (der Anforderungsanalyse) Interaction (UML collaboration diagrams) Structural (UML class/object diagrams) (UML activity diagrams) Realization Folie 2 Die KobrA-le für die (und Component) Realization e Structural Beschreibt die Daten und die Komponenten, welche der Kontext benötigt Ein oder mehrere Klassendiagramme Null oder mehrere Objektdiagramme Beschreibt die Algorithmen, die benutzt werden, um die Operationen für den Kontext zu realisieren Null oder mehrere Diagrams Null oder mehrere Use Case Diagrams (beschreiben die en, die mit der Komponente assoziiert sind) Interaction Beschreibt, wie Operationen für den Kontext in Form von Interaktionen realisiert werden Null oder mehrere Sequence oder Collaboration Diagrams (pro Operation) Folie 3

3 Unsere Vorgehensweise für ein e Bank Realization Bank Component Specification Bank Component Realization Folie 4 Begleitendes : Beschreibung und Spezifikation von Linearen Listen e Lineare Listen eignen sich gut als Spielzeug-... Sie sind aber auch nützlich! Mathematische Definition von Listen: Eine Liste ist entweder die leere Liste oder sie ist durch Einfügen neuer Elemente (vorne, in der Mitte oder am Ende) in eine existierende Liste entstanden. Visualisierung: Liste Liste... Wert Wert Wert Wert Folie 5

4 Aufgabe von letzter Vorlesung e Entwickeln Sie eine geeignete objektorientierte Form der Operationen für die Linearen Listen! Wo sehen Sie die Unterschiede zu den angegebenen mathematischen / funktionalen Definitionen? Folie 6 Objektorientierte Form der Operationen auf Linearen Listen 1/3 e createlist() : List wird durch den Konstruktor ersetzt insert( element : ElementType; position : Integer; list : List ) : List List wird aus der Parameterliste und dem Ergebnis entfernt: insert( element : ElementType; position : Integer) Pre: list = <a 1,..., a n > 1 <= pos <= n+1 Post: result = <a 1,..., a pos-1, element, a pos,..., a n > remove( position : Integer; list : List ) : List List wird aus der Parameterliste und dem Ergebnis entfernt: remove( position : Integer ) Pre: list = <a 1,..., a pos,...a n > 1 <= pos <= n Post: result = <a 1,..., a pos-1,a pos+1,..., a n > Folie 7

5 Objektorientierte Form der Operationen auf Linearen Listen 2/3 e search( element : ElementType; list : List ) : Integer List wird aus der Parameterliste entfernt: search( element : ElementType ) : Integer Pre: list = <a 1,..., a pos,..., a n > element = element(a pos ) Post: result = pos get( position : Integer; list : List ) : ElementType List wird aus der Parameterliste entfernt: get( position : Integer ) : ElementType Pre: list = <a 1, a 2,..., a n > 1 <= pos <= n Post: result = element(a pos ) Folie 8 Objektorientierte Form der Operationen auf Linearen Listen 3/3 e length( list : List ) : Integer List wird aus der Parameterliste entfernt: length() : Integer Pre: list = <a 1, a 2,..., a n > Post: result = n isempty( list : List ) : Boolean List wird aus der Parameterliste entfernt: isempty() : Boolean Pre: list = <a 1, a 2,..., a n > Post: result = (n = 0) isfull( list : List ) : Boolean List wird aus der Parameterliste entfernt: isfull() : Boolean Pre: list = <a 1, a 2,..., a n > Post: result = (n = MaxN), falls MaxN ex. Folie 9

6 Aufgabe e Entwickeln Sie ein Realization Structural für die Linearen Listen! Wie sieht es aus? Was lernen Sie daraus? Heben Sie Ihre le auf und bringen Sie sie regelmäßig mit! Folie 10 KobrA Realization e Beschreibt die Algorithmen, die benutzt werden, um die Operationen der Komponente zu realisieren s werden realisiert durch UML Diagrams oder UML Use Cases Diagrams werden etwas ausführlicher behandelt, auf Use Cases gehen wir nur sehr kurz ein Folie 11

7 Realization : UML Diagram e Diagrams beschreiben Folgen von en inklusive bedingtem und parallelem Verhalten Diagrams sind immer assoziiert mit einer Klasse, einer Operation oder einem Use Case (s. später) Diagrams unterstützen traditionelle Kontroll- und Datenfluss- Diagramme Bemerkungen: Diagrams sind zur Beschreibung von en mit relativ wenig Interaktion zu anderen Komponenten und zur Umwelt geeignet Diagrams sind eigentlich Zustandsdiagramme (Knoten sind szustände und Kanten sind Übergänge) Folie 12 für ein UML Diagram 1/2 e en Start der en Fülle Auftragsformular aus Bedingungen [Schnelllieferung] [sonst] Verzweigung (branch) Lieferung über Nacht Normale Lieferung Zusammenführung (merge) Ende der en Schließe Auftrag ab Folie 13

8 für ein UML Diagram 2/2 e Berechne Kosten [Kosten <= 50] [Kosten > 50] Autorisierung erteilen lassen Alternative (nach einer Verzweigung) ohne Konto belasten Folie 14 Diagrams with Swim Lanes ( Schwimmbahnen ) e Ein Bereich eines Diagrams, der mit einer bestimmten Klasse (in einer besonderen Rolle) assoziiert ist Die en innerhalb des jeweiligen Bereiches fallen unter die Verantwortung dieser Klasse Die Bereiche werden durch senkrechte Linien getrennt Durch solche Bereichskennungen ist es möglich, die Logik von Diagrams mit den Verantwortungsbereichen von Interaction Diagrams (s. später) zu kombinieren Folie 15

9 : UML Diagram with Swim Lanes :Rolle 1 :Rolle 2 e [Bedingung] Benennung der zuständigen Klassen (in ihrer Rolle) Bereichs-Trenner [Bedingung] Swim Lane 1 Swim Lane 2 Folie 16 Parallelität in Diagrams e Parallelitäts-Verzweigungen (fork) haben einen einzelnen Eingang und mehr als einen Ausgang Parallelitäts-Zusammenführungen (join) bringen parallele Abläufe wieder zusammen Die Ablaufreihenfolge zwischen fork und join ist irrelevant Der Ablauf nach einem join wird erst fortgesetzt, wenn alle eingehenden Abläufe beendet sind fork join Folie 17

10 für ein Diagram mit Parallelität e Folie 18 e Start der en Realization for SIB: UML Diagram createnewaccount() :Customer :Clerk :Bank decidestarting Balance checkstarting Balance Die beteiligten Akteure: Objekte in UML Verfeinerung im nächsten Schritt Balance < 50 Balance 50 Entscheidung mit den jeweiligen Bedingungen openaccount Bank Kontext deposit Folie 19

11 Realization : UML Use Case Diagram e Use Cases beschreiben die Aktoren, die mit einer Komponente interagieren, die Systemgrenzen und die Beziehungen zwischen Aktoren und Use Cases Use Case-Diagramme können in KobrA als Teil der s verwendet werden Konkret bezeichnen Use Cases die en und ihre Zuordnung zu Aktoren, für die Diagrams entwickelt werden können Folie 20 Allgemein: UML Use Cases e Beziehung zu en System / Komponente Beziehung zwischen en Externer Aktor Folie 21

12 Realization for SIB: UML Use Case Wurzel-Komponente e Interaktion des Systems mit seiner Umgebung Bank deposit «uses» createnewaccount Eine benutzt eine andere Clerk closeaccount withdraw en, sofern sie von Außen (d.h. im Kontext des Systems) sichtbar sind Aktoren der Umgebung Bank Customer setrate getbalance convert Diagrams können einzelne Use Cases genauer beschreiben; createnewaccount: haben wir gerade gesehen Folie 22 Aufgabe e Entwickeln Sie ein Realization für die Linearen Listen! Wie sieht es aus? Was lernen Sie daraus? Heben Sie Ihre le auf und bringen Sie sie regelmäßig mit! Folie 23

13 e Folie 24 Ausblick e Die 1. lgruppe von KobrA: Realization le der Realization: Kurze Structural Neu: Interaction e Folie 25