1 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Softwarepraktikum SS 2008...

1

Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme

SoftwarepraktikumSS 2008

Vorlesung 02 – 23.04.08

Prof. Dr. Reinhard v. HanxledenAG Echtzeitsysteme/Eingebettete Systeme

Institut für InformatikChristian-Albrechts-Universität zu Kiel

2


Vorlesung 02

• Entwurfsmuster, MVC• Einführung in UML

3


EntwurfsmusterModel View Controller

Dieses Tutorial basiert auf Foliender 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

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– MVC: Model View Controller

• Motivation– 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)

– 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:

Methodenaufrufe

Ereignisse

View

ControllerModel

Benutzeraktionen View-AuswahlÄnderungen Status erfragen

Status ändern

V

CM

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)

Benutzeraktion: OK Instanziieren + Status ändern(setLogin(...)...)

loginpasswortsetLogin(...)...

View-Wahl Eingabe OK

Comicanwendung

View-Wahl Eingabe NOK

Instanziieren der BeanStatus ändernprüfeEingabe()

musterLogin

Passwort ******

OK

Bitte ausfüllen!

musterLogin

Passwort

OK

Passwort falsch!

Status abfragen (getLogin())

V

CM

View1.jsp

View1.jsp View2.jsp Bean.java

Controller.java

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,www.cis.upenn.edu/~matuszek/cit591-2002/Lectures/mvc.ppt

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

Class Name

Responsibilities. . .. . .. . .

Collaborators. . .. . .. . .

• CRC cards are one brainstorming tool in OO design

19


Model

ModelSet 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 ( ) { xPosition += xDelta; if (xPosition < 0) { xPosition = 0; xDelta = -xDelta; } // more...

22


Model III

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

23


Model IV

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

24


Model (repeated)

ModelSet 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

ViewPaint the ball Get necessary info

from Model

27


View I

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)

ViewPaint 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

ControllerCreate ModelCreate ViewGive View access to ModelTell Model to advanceTell View to repaint

Model

View

33


public class Controller extends Applet { Panel buttonPanel = new Panel (); Button stepButton = new Button ("Step"); Model model = new Model (); View view = new View ();

// more...

import java.applet.*;import java.awt.*;import java.awt.event.*;import java.util.*;

Controller I

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)

ControllerCreate ModelCreate ViewGiveView access to ModelTell Model to advanceTell 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

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

40


UML-TutorialUnified Modelling Language

Dieses Tutorial basiert auf Folienvon Prof. Dr. Thomas Wilke, CAU Kiel,

sowie auf einem Foliensatzvon Dipl.-Inform. Christian Fuß, RWTH Aachen,

dieser basiert wiederum auf einem Internet-Tutorialvon Prof. Dr.-Ing. R. Dumke, Universität Magdeburghttp://www-ivs.cs.uni-magdeburg.de/~dumke/UML

41


Einführung

• 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

Object-OrientationDefining 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.

42


Überblick

UML-Diagramme

Strukturdiagramme

Klassendiagramm Objektdiagramm

Kompositions-strukturdiagramm

Komponenten-diagramm

Paketdiagramm

Einsatzdiagramm

Verhaltensdiagramme

Interaktionsdiagramme

Use-Case-Diagramm

State-Chart-Diagramm

Aktivitätsdiagramm

SequenzdiagrammInteraktionsüber-sichtsdiagramm

Kommunikations-diagramm

Timing-Diagramm

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:

1. geeignete Abstraktionen bilden

2. get- und set-Methoden kritisch durchsehen

3. Namenskonventionen: Imperativ, beginnend mit Kleinbuchstaben, Wortgliederung durch Großbuchstaben (z. B. tuDiesUndJenes())

47


Klassendiagramm – Attribute, Operationen

• 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

attribut : Klasse = Initialwert {Merkmal}{Zusicherung}

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

• 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

53


UML-TutorialAppendix

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 definierenSystemablauf während des Debuggingerwü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• 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

UML2

64


State-Chart-Diagramm

• Zustandsmaschine• ein Anfangszustand• endliche Menge Zustände

Unterzustände mit Anfangszustand möglich

• endliche Menge Transitionen durch Ereignisseereignis(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

• Vermischung aus Aktivitäts- und Sequenzdiagramm• Aktivitätsbeschreibung in Form von

Sequenzdiagrammen

UML2

68


Timing-Diagramm

• dienen Darstellung von Zeitbeschränkungen für Zustandswechsel von ein oder mehreren Objekten

UML2

1 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Softwarepraktikum SS 2008...

Documents

Transcript of 1 Prof. Dr. Reinhard v. Hanxleden AG Echtzeitsysteme/Eingebettete Systeme Softwarepraktikum SS 2008...