Software Engineering. 10. Entwurfsmuster. Franz-Josef Elmer, Universität Basel, WS 2006/07

Transkript

1 Software Engineering 10. Entwurfsmuster Franz-Josef Elmer, Universität Basel, WS 2006/07

2 Software Engineering: 10. Entwurfsmuster 2 Entwurfsmuster (engl. Design Patterns) Definition: A Bewährte Codevorlagen für Entwurfsprobleme B Rezepte um guten Code zuschreiben C Lösungen von Entwurfsproblemen, welche bei Code- Reviews immer wieder auftreten D Lösungen von Entwurfsproblemen welche Design Prinzipien genügen

3 Software Engineering: 10. Entwurfsmuster 3 Entwurfsmuster Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander 1977 Bilden ein Vokabular, das Entwickler benutzen um über Design zu diskutieren (pattern language). Es gibt verschiedene Kataloge von Entwurfsmuster: Allgemeine für objektorientierte Programmierung (z.b. GoF). Spezielle für bestimmte Fachdomänen. Für Architekturmuster (z.b. POSA). Für Idiome, die spezifisch für eine Programmiersprache sind. Achtung: Falsch eingesetzte Entwurfsmuster schaden!

4 Software Engineering: 10. Entwurfsmuster 4 Architekturmuster Layers Pipes and Filters Model-View-Controller

5 Software Engineering: 10. Entwurfsmuster 5 Architekturmuster: Layers The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. POSA(31) Layer 4 Layer 3 Layer 2 Layer 1 höchste Abstraktion niedrigste Abstraktion

6 Software Engineering: 10. Entwurfsmuster 6 Layers: Regeln 1.Jede Schicht ist unabhängig von den darüber liegenden Schichten. 2. Jede Schicht ist ein Service für die darüberliegende Schicht. 3.Der Zugriffe auf die darunterliegende Schicht erfolgt über eine Schnittstelle. 4.Strict Layering: Eine Schicht darf nur auf die unmittelbar darunterliegende Schicht zugreifen. 5.Layer Bridging: Eine Schicht darf auf alle niederen Schichten zugreifen. Layer 3 Layer 2 Layer Bridging Layer 1

7 Software Engineering: 10. Entwurfsmuster 7 Dreischichtenarchitektur Grundarchitektur für viele Anwendungen: Präsentationsschicht Fachschicht Datenschicht Präsentationsschicht (Benutzeroberfläche) behandelt Benutzereingaben und präsentiert Daten. Aus- und Eingabe via Konsole oder Graphical User Interface (GUI) als fat client (z.b. mit Java Swing) oder als thin client mit HTML Fachschicht (Business Logic) behandelt fachliche Aspekte. Semantische Validierungen Berechnungen Datenschicht (Infrastrukturschicht, Data Access Layer) behandelt das Laden und Speichern der Daten. Integration Nachrichtensystem Sicherheit

8 Software Engineering: 10. Entwurfsmuster 8 Architekturmuster: Pipes and Filters The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems. POSA(53) Filter 1 Filter 2 Filter 3 Input Pipes Output

9 Software Engineering: 10. Entwurfsmuster 9 Pipes and Filters Jeder Filter ist eine Black-Box mit einer definierten Schnittstelle der Datenübertragung und des Datenformats. Filter sind beliebig kombinier- und austauschbar, sofern die Schnittstellen und Datenformate zusammenpassen. Einfache Filter sind besser kombinierbar. Filter kann Daten filtern anreichern umwandeln Filter können die Daten am Stück verarbeiten oder häppchenweise (Streaming). Pull Prinzip: Filter holen die Daten aktiv aus der Pipe. Push Prinzip: Pipe schiebt aktiv die Daten in den Filter. Pipes können synchron oder asynchron arbeiten. Im letzteren Fall sind sie oft Warteschlangen.

10 Software Engineering: 10. Entwurfsmuster 10 Pipes and Filters: Beispiel Unix: Verkettung von Programmen durch das Pipe-Symbol ' '. Was ist das Datenformat und Datenschnittstelle? A Textdatei B Binärdatei C Sequenz von Zeichen D Sequenz von Bytes

11 Software Engineering: 10. Entwurfsmuster 11 Pipes and Filters Sequenzdiagramm mit zwei Filter im Pull-Prinzip: Datenquelle Filter1 Pipe Filter2 Datensenke read() read() Daten write() read() Daten Daten write() write() read()

12 Software Engineering: 10. Entwurfsmuster 12 Architekturmuster: MVC The Model-View-Controller architectural pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A changepropagation mechanism ensures consistency between the user interface and the model. POSA(125) View 1 View 2 Presentation Layer Controller View Model blau = 15 rot = 7 grün = 18 Model

13 Software Engineering: 10. Entwurfsmuster 13 Model View Controller Model: Daten und Business Logik Wichtig: Model ist unabhängig von Controller und View Definiert Schnittstelle für Daten lesen Daten manipulieren und Datenverarbeitung initiieren (synchron oder asynchron) Data Changed Listener an- bzw. abmelden View: Präsentation der Daten (oder eines Teiles davon) als Grafik und/oder Text Datenausgabe Abhängig vom Model: Registriert sich als Data Changed Listener beim Model Liest Daten aus dem Model Spezifisch für ein bestimmtes Model Controller: Steuerung von Model und View durch Benutzerinteraktionen Dateneingabe Abhängig vom Model: Datenmanipulation und -verarbeitung Beeinflusst Zustand der View Oft starke Kopplung zwischen View und Controller

14 Software Engineering: 10. Entwurfsmuster 14 Model View Controller: Klassendiagramm Generisches Klassendiagramm: Controller * * View +datachanged() 1 Model -data: Data +getdata():data +manipulate(d:somedata) 1 * «Interface» DataChangedListener +datachanged()

15 Software Engineering: 10. Entwurfsmuster 15 Model View Controller: Push Prinzip :Controller :Model v1:view v2:view user input analyse input manipulate() do some data processing datachanged() DataChangedListener getdata() repaint datachanged() DataChangedListener repaint data getdata() data

16 Software Engineering: 10. Entwurfsmuster 16 Model View Controller: Variationen Keine Trennung zwischen View und Controller. View kennt Controller nicht, aber umgekehrt. View und Controller sind beide voneinander unabhängig. Client-Server System: Fat Client Thin Client Client Controller View ControllerClient ViewClient Server Model ControllerServer Model ViewServer DataChangedListener: Hat meist einen anderen Namen Übermittelt welche Daten geändert wurden Fehlt bei Web Applikationen, da dort Datenübermittlung nach dem Pull- und nicht nach dem Push-Prinzip erfolgt.

17 Software Engineering: 10. Entwurfsmuster 17 Quiz: Welches Designprinzip steckt hinter allen drei Architekturmuster Layer, Pipes & Filters und MVC? A Design by Contract B DRY (Don't Repeat Yourself) C Open-Closed Prinzip D Geheimnisprinzip