Softwarepraktikum SS 2008 Vorlesung 02 – Prof. Dr

Präsentation zum Thema: "Softwarepraktikum SS 2008 Vorlesung 02 – Prof. Dr"—  Präsentation transkript:

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

2 Vorlesung 02 Entwurfsmuster, MVC Einführung in UML

3 Entwurfsmuster Model View Controller Dieses Tutorial basiert auf Folien der AG Rechnerunterstützte Ingenieursysteme (Prof. Dr.-Ing. habil Georg Paul) der Universität Magdeburg

4 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

5 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

6 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

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

8 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

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

10 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

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

12 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

13 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

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

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

16 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,

17 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

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

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

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

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

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

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

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

25 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

26 View View Paint the ball Get necessary info from Model

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

28 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

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

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

31 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

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

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

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

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

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

37 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

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

39 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 (Basis dieser Folien) (Weiterführende Informationen zu MVC)

40 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

41 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

42 Überblick

43 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

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

45 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?

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

47 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

48 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

49 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

50 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

51 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

52 UML – Weiterführende Links
(Basis dieses Tutorials) (Seite der OMG) (Online-Buch zur UML)

53 UML-Tutorial Appendix

54 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

55 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

56 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

57 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

58 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

59 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

60 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

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

62 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

63 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

64 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

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

66 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

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

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