Softwarepraktikum SS 2008 Vorlesung 02 – 23. 04. 08 Prof. Dr Softwarepraktikum SS 2008 Vorlesung 02 – 23.04.08 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Institut für Informatik Christian-Albrechts-Universität zu Kiel

Vorlesung 02 Entwurfsmuster, MVC Einführung in UML

Entwurfsmuster Model View Controller Dieses Tutorial basiert auf Folien der AG Rechnerunterstützte Ingenieursysteme (Prof. Dr.-Ing. habil Georg Paul) der Universität Magdeburg http://wwwiti.cs.uni-magdeburg.de/iti_ti/ETISUebung/uePattern.ppt

Motivation Entwurfsmuster Entwurf wiederverwendbarer objektorientierter Software schwer gute Entwürfe entstehen durch Wiederverwendung erfolgreicher Lösungen (Entwurfsmuster) somit in OO Systemen oft wiederkehrende Muster von Klassen und kommunizierenden Objekten Entwickler kann Muster auf vorliegende Probleme anwenden, ohne Lösung erneut zu suchen Muster lösen spezifische Entwurfsprobleme Muster machen Entwürfe flexibler, eleganter, wiederverwendbar

Entwurfsmuster Entwurfserfahrungen als Entwurfsmuster aufgezeichnet (Musterkatalog) durch verständliche Darstellung gut nutzbar erleichtern Wahl von Entwurfsalternativen können Dokumentation + Wartung existierender Systeme erleichtern ermöglichen Entwurf schneller „richtig“ zu machen Entwurfsmuster (C. Alexander): beschreibt beständig wiederkehrendes Problem erläutert Kern der Lösung für Problem somit: Lösung beliebig oft, aber nicht jedesmal gleich, ausführbar

Entwurfsmuster Entwurfmuster sind Muster bestimmter Abstraktionsebene Zusammenarbeit Objekte + Klassen zur Lösung von Entwurfsproblemen in bestimmtem Kontext Benennen, Abstrahieren, Identifizieren relevanter Aspekte einer allgemeinen Entwurfsstruktur Klassen, Objekte, ihre Rollen + Aufgaben + Interaktionen zwischen Rollen identifiziert Entwurfsmuster für je ein bestimmtes Entwurfsproblem: wann einsetzbar + Konsequenzen

Beschreibung von Mustern (I) (Musterbeschreibung nach Gamma) Mustername kurzes Stichwort, um Problem + Lösung zu erläutern hilft bei Kommunikation im Team + Dokumentation Problemabschnitt beschreibt, wann Muster anzuwenden ist (Zweck, Motivation, Anwendbarkeit)

Beschreibung von Mustern (II) Lösungsabschnitt Elemente des Entwurfs, Beziehungen, Zuständigkeiten + Interaktionen (Struktur, Teilnehmer, Interaktionen) kein bestimmter Entwurf, keine konkrete Implementierung, sondern auf viele Situationen anwendbare Schablone (Elemente z.B. Klassen + Objekte) Konsequenzabschnitt Konsequenzen der Musteranwendung (Vor- und Nachteile) + bekannte Verwendungen

MVC (Name, Problem) Name Motivation MVC: Model View Controller Erleichtert Entwurf und Wartung grafischer Benutzerschnittstellen durch Modularisierung Model: Daten + Kernfunktionalität View: Präsentation Model Controller: Kontrollfluss (welche Aktion, welche Logik, welche View)

MVC (Problem) Anwendbarkeit Views nicht zu verändern bei verändertem Controller Model unabhängig von Veränderungen in View und Controller Anwendbarkeit für große Anwendungen wenn klare Rollenverteilung nötig (Designer, Programmierer) wenn starke Wiederverwendung angestrebt

MVC (Lösung I) Struktur: View Controller Model Benutzeraktionen View-Auswahl Änderungen Status erfragen Status ändern Methodenaufrufe Ereignisse

MVC (Lösung II) Teilnehmer Model, View, Controller Interaktionen Views leiten Benutzeraktionen an Controller Controller legt fest, wie Eingaben zu verarbeiten (Befehle an Model schicken und View selektieren) Views können geänderte Werte des Models abfragen

MVC (Konsequenzen I) Konsequenzen Gute Wiederverwendbarkeit Mehrere Ansichten des selben Models möglich Sichten und Controller sind austauschbar Bessere Lesbarkeit  gute Rollenverteilung Designer, Programmierer Gute Skalierbarkeit und Erweiterbarkeit Erhöhte Komplexität Längere Planung Mehr Aufwand bei Implementierung

MVC (Konsequenzen II) Bekannte Verwendungen Smalltalk mit Benutzerschnittstellen-Framework MFC - Microsoft Foundation Classes Swing Web-Frameworks (Struts, Velocity, Tapestry)

Beispiel (JavaServer Pages) M C Bitte ausfüllen! Instanziieren der Bean Status ändern prüfeEingabe() Login Benutzeraktion: OK Instanziieren + Status ändern (setLogin(...)...) muster Passwort ****** OK View1.jsp Controller.java View-Wahl Eingabe NOK View-Wahl Eingabe OK Passwort falsch! Comicanwendung login passwort setLogin(...) ... Login muster Passwort OK View1.jsp View2.jsp Bean.java Status abfragen (getLogin())

Example: The Bouncing Ball Applet Each click of the Step button advances the ball a small amount The step number and ball position are displayed in the status line This example is courtesy of David Matuszek, University of Pennsylvania, www.cis.upenn.edu/~matuszek/cit591-2002/Lectures/mvc.ppt

The Ball Applet: Model The Ball Applet shows a ball bouncing in a window The Model controls the motion of the ball In this example, the Model must know the size of the window so it knows when the ball should be made to bounce The Model doesn’t need to know anything else about the GUI

Class-Responsibility-Collaboration Cards CRC cards are one brainstorming tool in OO design Class Name Responsibilities . . . . . . . . . Collaborators . . . . . . . . .

Model Model Set initial position Move one step No collaborators... ....but provide access methods to allow view to see what is going on

Model I import java.util.Observable; class Model extends Observable { final int BALL_SIZE = 20; int xPosition = 0; int yPosition = 0; int xLimit, yLimit; int xDelta = 6; int yDelta = 4; // more...

Model II void makeOneStep ( ) { // more... xPosition += xDelta; if (xPosition < 0) { xPosition = 0; xDelta = -xDelta; } // more...

if (xPosition >= xLimit) { Model III if (xPosition >= xLimit) { xPosition = xLimit; xDelta = -xDelta; } // still more...

Model IV yPosition += yDelta; if (yPosition < 0 || yPosition >= yLimit) { yDelta = -yDelta; } setChanged(); notifyObservers(); } // end of makeOneStep method } // end of Model class

Model (repeated) Model Set initial position Move one step No collaborators... ....but provide access methods to allow view to see what is going on

The Ball Applet: View The View needs access to the ball’s state (in this case, its x-y location) For a static drawing, the View doesn’t need to know anything else

View View Paint the ball Get necessary info from Model

View I // more... import java.awt.*; import java.util.*; class View extends Canvas implements Observer{ Controller controller; Model model; int stepNumber = 0; // more...

View II public void paint (Graphics g) { g.setColor (Color.red); g.fillOval (model.xPosition, model.yPosition, model.BALL_SIZE, model.BALL_SIZE); controller.showStatus ("Step " + (stepNumber++) + ", x = " + model.xPosition + ", y = " + model.yPosition); } // end paint method

View III public void update(Observable obs, Object arg) { repaint(); } } // end class

View (repeated) View Paint the ball Get necessary info from Model

The Ball Applet: Controller The Controller tells the Model what to do The Controller tells the View when it needs to refresh the display The Controller doesn’t need to know the inner workings of the Model The Controller doesn’t need to know the inner workings of the View

Controller Controller Model View Create Model Create View Give View access to Model Tell Model to advance Tell View to repaint Model View

Controller I import java.applet.*; import java.awt.*; import java.awt.event.*; import java.util.*; public class Controller extends Applet { Panel buttonPanel = new Panel (); Button stepButton = new Button ("Step"); Model model = new Model (); View view = new View (); // more...

Controller II public void init ( ) { // Lay out components setLayout (new BorderLayout ( )); buttonPanel.add (stepButton); this.add (BorderLayout.SOUTH, buttonPanel); this.add (BorderLayout.CENTER, view); // more...

Controller III // Attach actions to components stepButton.addActionListener( new ActionListener ( ) { public void actionPerformed (ActionEvent event) { model.makeOneStep (); } } ); // more...

Controller IV // Tell the View about myself (Controller) // and about the Model model.addObserver(view); view.controller = this; } // end init method // more...

Controller V public void start ( ) { model.xLimit = view.getSize( ).width - model.BALL_SIZE; model.yLimit = view.getSize( ).height - model.BALL_SIZE; repaint ( ); } // end of start method } // end of Controller class

Controller (repeated) Create Model Create View GiveView access to Model Tell Model to advance Tell View to repaint Model View

Quellen Wille, S., Go To Java Server Pages, Addison-Wesley, München, 2001 Gamma, E., Helm, R., Jonson, R., Vlissides, J., Entwurfsmuster, Addison-Wesley, Bonn, 1996 („Gang of Four“) Siemers, S.: MVC meets XML, Javamagazin, 03/2002, S.24 Turau, V. Saleck, K., Schmidt, M.: Java Server Pages und J2EE: Unternehmensweite Web-Basierte Anwendungen, dpunkt.verlag, Heidelberg 2001 http://wwwiti.cs.uni-magdeburg.de/iti_ti/ETISUebung/uePattern.ppt (Basis dieser Folien) http://www.fh-wedel.de/~si/seminare/ws97/Ausarbeitung/3.Krutscher/archmu3.htm (Weiterführende Informationen zu MVC)

UML-Tutorial Unified Modelling Language Dieses Tutorial basiert auf Folien von Prof. Dr. Thomas Wilke, CAU Kiel, sowie auf einem Foliensatz von Dipl.-Inform. Christian Fuß, RWTH Aachen, dieser basiert wiederum auf einem Internet-Tutorial von Prof. Dr.-Ing. R. Dumke, Universität Magdeburg http://www-ivs.cs.uni-magdeburg.de/~dumke/UML

Einführung Object-Orientation Defining abstractions of real-world entities known as objects, which contain both data and procedures. Key characteristics of object-oriented systems are encapsulation, inheritance and polymorphism. UML ist eine Sammlung von Diagrammsprachen für den objektorientierten Entwurf Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme OMG Standard seit 1998, derzeit aktuell UML 2 Entwickelt von Grady Booch, Ivar Jacobsen und Jim Rumbaugh

Überblick

Klassendiagramm – Klassen Klasse ist Konstruktionsbeschreibung für Objekte Attribute Operationen (Methode=Implementierung der Operation) Abstrakte Klassen Grundlage für Unterklassen nicht instanzierbar Parametrisierbare Klassen Schablone zur Erzeugung von Klassen Erzeugte Klasse muss mit <<bind>>-Assoziation mit Schablone verbunden werden

Klassen I bilden eigenen, abgeschlossenen Verantwortlichkeitsbereich beschreiben Objekte der realen Welt schematisch fassen mehrfach und gemeinsam auftretende Daten zusammen können andere erweitern oder generalisieren (Vererbung) stehen miteinander in Beziehung (Assoziationen)

Klassen II Wichtig: suggestive Bezeichnungen eine feste natürliche Sprache (hier: durchgängig deutsch) Namenskonventionen einhalten: Klassennamen beginnen mit Großbuchstaben, Wortgliederung durch Großbuchstaben Checkliste: Werden mehrere Objekte einer Klasse erzeugt? Fassen Objekte Daten und Operationen zusammen? Gibt es sinnvolle Beziehungen zwischen den Klassen?

Methoden Operationen auf Objekten Wichtig: geeignete Abstraktionen bilden get- und set-Methoden kritisch durchsehen Namenskonventionen: Imperativ, beginnend mit Kleinbuchstaben, Wortgliederung durch Großbuchstaben (z. B. tuDiesUndJenes())

Klassendiagramm – Attribute, Operationen attribut : Klasse = Initialwert {Merkmal}{Zusicherung} Datenelement jedes Objekts einer Klasse /abgeleitetes Attribut (nach Berechnungsvorschrift) klassenattribut +publicAttribut #protectedAttribut -privateAttribut Klasse beschreibt Typ des Attributs Merkmal beschreibt weitere Eigenschaften, z.B. read-only Zusicherung schränkt Inhalte, Zustände oder Semantik eines Modellelements ein operation(argument:Argumenttyp=Standardwert,...) : Rückgabetyp {Merkmal} {Zusicherung} vergleichbar den Attributen Operationen sind Dienstleistungen, die aufgerufen werden können

Klassendiagramm – Pakete Ansammlungen von Modellelementen Gesamtmodell in kleine überschaubare Einheiten untergliedern definieren keine Modellsemantik jedes Modellelement gehört zu genau einem Paket können hierarchisch gegliedert werden

Klassendiagramm – Vererbung Programmiersprachenkonzept für Relation zwischen Ober- und Unterklasse Attribute und Operationen der Oberklasse sind auch Unterklassen zugänglich Abstraktionsprinzip zur hierarchischen Gliederung der Semantik eines Modells Unterscheidung eines Diskriminators: z.B. Antriebsart für PKWs

Use-Case-Diagramm stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar Anwendungsfall beschreibt äußerlich sichtbares Systemverhalten, kann hierarchisch geschachtelt werden Akteur befindet sich außerhalb der Systemgrenze Systemgrenze wird durch Rahmen symbolisiert

Sequenzdiagramm beschreibt zeitliche Abfolge von Interaktionen zwischen Objekten Zeitlinie senkrecht von oben nach unten Objekte durch senkrechte Lebenslinien beschrieben gesendete Nachrichten waagerecht entsprechend zeitlichen Auftretens

UML – Weiterführende Links http://www-ivs.cs.uni-magdeburg.de/~dumke/UML (Basis dieses Tutorials) http://uml.org (Seite der OMG) http://www.highscore.de/uml/ (Online-Buch zur UML) http://de.wikipedia.org/wiki/UML

UML-Tutorial Appendix

Klassendiagramm – Schnittstellen Schnittstellen spezifizieren Teil des äußerlich sichtbaren Verhaltens von Modellelementen beinhalten eine Menge von Signaturen für Operationen symbolisiert durch nicht ausgefüllten Kreis, der durch Linie mit anbietender Klasse verbunden ist Name der Schnittstelle entspricht dem Namen der Schnittstellenklasse Nutzung durch Abhängigkeitsbeziehung

Klassendiagramm – Objekte interessierende Objekte und Beziehungen in einer Art Momentaufnahme z.B. Datensatz für den Test zu definieren Systemablauf während des Debugging erwünschte oder unerwünschte Zustände Objektdiagramm bildet konkrete Instanz des abstrakt beschriebenen Modells

Klassendiagramm – Assoziation Assoziationen beschreiben Verbindungen zwischen Klassen Objekte können nur dann miteinander kommunizieren konkrete Beziehung (Instanz einer Assoziation) wird Objektverbindung (Link) genannt an den Enden kann Multiplizität angegeben werden (als einzelne Zahl oder Wertebereich) eine abgeleitete Assoziation wird nicht gespeichert, sondern bei Bedarf berechnet

Klassendiagramm – Aggregation, Komposition Aggregation ist Zusammensetzung eines Objektes aus einer Menge von Einzelteilen Aggregat nimmt stellvertretend für Teile Aufgaben wahr Aggregat kann Nachrichten an seine Teile weiterleiten die beteiligten Klassen führen keine gleichberechtigte Beziehung Teil kann zu mehreren Aggregationen gehören Komposition ist existenzabhängige Aggregatbeziehung

Klassendiagramm – Abhängigkeit Beziehung zwischen Modellelementen, die zeigt, dass Änderung des einen (unabhängigen) Elements Änderung im anderen (abhängigen) Element bewirkt bezieht sich dabei auf Modellelemente selbst, nicht auf Instanzen

Klassendiagramm – Verfeinerung Verfeinerungen sind Beziehungen zwischen gleichartigen Elementen unterschiedlichen Detaillierungsgrades Beispiele Beziehung von Analyse- und Designversion Beziehung von sauberer und optimierter Variante Beziehung zwischen zwei unterschiedlich granulierten Elementen Beziehung zwischen Schnittstellenklasse und umsetzender Klasse

Klassendiagramm – Stereotypen erweitern vorhandene Modellelemente des UML-Metamodells Element wird direkt durch definierte Semantik beeinflusst besitzen keine Typsemantik sollten projekt-, unternehmens- oder methodenspezifisch vergeben werden

Komponentendiagramm Komponente stellt physisches Stück Programmcode dar Komponente kann Elemente (Objekte, Komponenten, Knoten) enthalten und Schnittstellen besitzen Komponentendiagramm zeigt Abhängigkeiten zwischen Komponenten

Einsatzdiagramm Knoten stellen Laufzeitumgebungen dar Knoten werden als Quader visualisiert In den Knoten werden dort installierte Komponenten und Objekte dargestellt Knoten die miteinander kommunizieren werden durch Linien miteinander verbunden

Kompositionsstrukturdiagramm UML2 dient der internen hierarchischen Strukturierung von Komponenten (Klassen) Interne Strukturierung geschieht auf Instanzebene (Zusammenfassung zur Laufzeit) Externe Struktur kann durch Ports verfeinert werden Ports bündeln geforderte und gelieferte Schnittstellen mit logischen Interaktionen

State-Chart-Diagramm Zustandsmaschine ein Anfangszustand endliche Menge Zustände Unterzustände mit Anfangszustand möglich endliche Menge Transitionen durch Ereignisse ereignis(argumente) [bedingung] / operation(argumente) ^zielobjekte.gesendetesEreignis(argumente) endliche Menge Endzustände

Aktivitätsdiagramm Sonderform des State-Chart-Diagramms ähnelt prozeduralem Flussdiagramm beschreibt Aktivitäten von Objekten Aktivität ist Zustand mit interner Aktion

Kommunikationsdiagramm Kollaborationsdiagramm in UML 1 Interaktionen für begrenzten Kontext, unter besonderer Beachtung der Beziehungen der Objekte und ihrer Topographie Objekte durch Assoziationslinien verbunden Nachrichten (zeitliche Nummerierung, Namen, Antwort und Argumenten) entlang der Assoziationslinien Startnachricht erhält noch keine Nummer Aussagekraft wie Sequenzdiagramm

Interaktionsübersichtsdiagramm UML2 Vermischung aus Aktivitäts- und Sequenzdiagramm Aktivitätsbeschreibung in Form von Sequenzdiagrammen

Timing-Diagramm UML2 dienen Darstellung von Zeitbeschränkungen für Zustandswechsel von ein oder mehreren Objekten