Prof. Dr.-Ing. Dagmar Meyer Software Engineering 3 ARCHITEKTURENTWURF

Transkript

1 3 ARCHITEKTURENTWURF

2 Hausbau - so? 2

3 oder so? 3

4 ... oder doch lieber so? 4

5 Dumme Frage! Wenn es um das Bauen von Häusern geht, besteht überhaupt kein Zweifel: ein guter Architekt muss her ohne Baupläne (Architektur) fängt kein Bauarbeiter mit seiner Arbeit an wie sollte er auch? nur gut durchdachte Baupläne garantieren ein ansprechendes Ergebnis Fehler bei der Erstellung der Pläne und der Statik, die nicht bemerkt werden, können im schlimmsten Fall zum Einsturz des Gebäudes führen Und wie sieht es mit dem Entwickeln von Software aus? 5

6 Eigentlich nichts Neues I am more convinced than ever. Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity... After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager, and a separate architect. oder doch? Brooks, Frederick: The Mythical Man-Month (20th Anniversary Edition, 1995) Softwarearchitektur spielt eine zentrale Rolle für die erfolgreiche Erstellung, die Pflege und Wartbarkeit der Software. Die Möglichkeit der Wiederverwendung und der Wissensaufbau bzgl. Software im Unternehmen hängt davon ab. Die Softwarearchitektur ist Ihre Garantie für den Schutz Ihrer Investitionen in Softwareentwicklung. M. Broy et al: Manifest. Strategische Bedeutung des in Deutschland. In: Informatik Spektrum. Springer Verlag. Band 29, Heft 3, Juni

7 Klassische Architektur Die Architektur von Gebäuden wird beschrieben durch mehrere Sichten: Außenansicht, Grundrisse, Leitungspläne,... Architekturstile: romanisch, gotisch,... Stil und Engineering: Wie beeinflusst die Wahl des Baustils die Konstruktion des Gebäudes? Stil und Baumaterialien: Wie beeinflusst die Wahl des Baustils die verwendeten Baumaterialien? Diese Konzepte finden sich auch in SW-Systemen: es gibt Sichten: Kontrollfluss, Datenfluss, Modulstruktur, Verhaltensanforderungen,... Stile: Streams und Filter, objektorientiert, prozedural,... Engineering: Module, Filter, Nachrichten, Ereignisse,... Materialien: Kontrollstrukturen, Datenstrukturen,... 7

8 SW-Architektur oder Big Ball of Mud? Statt eine saubere Softwarearchitektur umzusetzen enden viele Softwaresysteme in einem Big Ball of Mud Mögliche Ursachen: Unterschätzung der Komplexität des Systems Fehlende Methodenkenntnis Mangelndes Durchsetzungsvermögen des Architekten Viele Köche verderben den Brei Abhilfe: Rolle des Architekten im Projekt fest verankern Methodenkenntnis + Erfahrung + Persönlichkeit sind der Schlüssel zum Erfolg 8

9 Warum Softwarearchitektur? Abhängigkeit der Gesellschaft von Software Software als Schlüssel für die Funktionsfähigkeit von Produkten Software wird zum marktunterscheidenden Element Wettbewerbsfähigkeit In vielen Branchen liegt ein Großteil der Wertschöpfung in den elektronischen und durch Software bestimmten Systemen Auch in Unternehmen des klassischen Maschinenbaus (Automobil, Werkzeugmaschinen, Anlagenbau, ) Softwaresysteme werden zunehmend komplexer Fehler können weitreichende Auswirkungen haben Online-Bank, deren Webportal ausfällt, hat plötzlich alle Filialen geschlossen Fehler im Flugsicherungssystem kann viele Menschenleben kosten Ausfall des Warenwirtschaftssystems kann ein Unternehmen Milliarden kosten (keine Bestellungen, kein Verkauf, ) 9

10 Architektur = Bauplan 10

11 Aussage von Bauplänen? Die Architektur beschreibt, Was gebaut werden soll Wie die Konstruktion im Groben aussieht Welche Materialien verwendet werden Wofür Fertigteile verwendet werden Die Architektur beschreibt nicht Wie der Maurer die Steine aufeinander schichten und miteinander verbinden soll In welcher Reihenfolge z. B. die Fenster eingesetzt werden müssen Von welchem Hersteller die Badewanne bezogen wird. Softwarearchitektur lässt dem Entwickler beim Design "seiner" Komponenten Freiräume Softwarearchitektur ist keine "Verfahrensanweisung" 11

12 Definition nach ANSI/IEE-Standard ANSI/IEE-Standard Recommended Practice for Architectural Description of Software-Intensive Systems Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. 12

13 Eine Definition in Kurzform Die Softwarearchitektur eines Programms oder Softwaresystems ist die Struktur oder sind die Strukturen des Systems, die Software-Komponenten die nach außen sichtbaren Eigenschaften dieser Komponenten und deren Beziehungen untereinander umfassen. Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice. Addison-Wesley, Boston,

14 Komponenten: Beispiel Hafenrichter, B.: Die Struktursicht der Architektur. Vorlesungsskript, Hochschule Regensburg. Mögliche Komponenten einer Web-Anwendung 14

15 Bewertung einer Architektur? Die vorgestellte Definition lässt offen, ob eine Architektur gut oder schlecht ist. "Trial and Error" ist kein gangbarer Weg zur Auswahl einer geeigneten Architektur für ein System. Beliebige Architektur auswählen? System aufbauend auf dieser Architektur entwickeln? Hoffen, dass die Anforderungen erfüllt werden? Notwendigkeit der Entwicklung einer Architektur (Designprozess: Softwarearchitekturdesign) setzt Methodenwissen und Erfahrung(!) voraus 15

16 Eine gute Softwarearchitektur Ermöglicht dem System die Erfüllung seiner Qualitäts-, Lebenszyklus- und Verhaltensanforderungen Qualitätsmodell ISO

17 Detaillierungsgrad und Risiko Existieren kritische, anspruchsvolle Qualitätsanforderungen, muss Softwarearchitekturdesign in eine beachtliche Detailtiefe gehen, um kritische Teile des Systems zu betrachten. Der Detaillierungsgrad muss nicht für die gesamte Architektur gleich sein, sondern kann je nach Risiko für einzelne Bereiche variieren. Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

18 Zeitliche Einordnung in den Entwicklungsprozess Anforderungen Implementierung Strukturen und Beziehungen Definition der Anforderungen Software- Architektur Feindesign Implementierung Integration Test Reale SW-Entwicklung ist ein inkrementeller Prozess mit mehreren Iterationen 18

19 Zusammenfassung Softwarearchitektur ist die Zerlegung des Systems in seine Hauptbestandteile auf der obersten Ebene. Sie definiert die Architekturbausteine, deren Verantwortlichkeiten, Instanzen, Schnittstellen und wie diese miteinander interagieren. Softwarearchitekturdesign ist der zugehörige Designprozess. Softwarearchitektur manifestiert somit die frühesten und wichtigsten Designentscheidungen für das Softwaresystem. Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

20 Komponenten im Sinne der UML Komponente im Sinne der UML Bausteine, die eine bestimmte Funktionalität zum Beispiel die Kapselung der Zugriffe auf eine Datenbank bereitstellen Kommunikation mit anderen Bausteinen über eine definierte Schnittstelle Schnittstellenspezifikation bezieht sich auf statische Informationen (Signatur der erlaubten Operationen) und auf dynamische Informationen (Sequenz der erlaubten Aufrufe). Schnittstellenspezifikation legt fest: nach außen bereitgestellten Funktionalitäten bereitgestellte (engl. provided) Schnittstellen von der Umgebung geforderte Funktionalitäten benötigte (engl. required) Schnittstellen. 20

21 Komponentendiagramm Komponentendiagramm als Kontextsicht für eine Wetterstation Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

22 Elemente des Komponentendiagramms Komponente Port repräsentiert ein komplettes System bzw. einzelne Architekturbausteine. Bei der Betrachtung des Systemkontexts werden Komponenten sowohl zur Darstellung für das zu erstellende System als auch für die Nachbarsysteme verwendet. definiert einen namentlichen Interaktionspunkt einer Komponente, dem bereitgestellte und benötigte Schnittstellen zugeordnet werden können. Eine Komponente kann mehrere Ports mit gleichen Schnittstellen besitzen, d. h., die gleiche Operation kann über verschiedene Ports aufgerufen werden und wird somit intern von der Komponente unterschiedlich behandelt. Schnittstelle beschreibt die möglichen Typisierungen von Ports und damit die erlaubten Eingangs- und Ausgangsnachrichten. Schnittstellen werden benannt und in bereitgestellte und benötigte Schnittstellen unterschieden. Konnektor (engl. connector) Kommunikationskanal zwischen Komponenten. 22

23 Ausführliche Schnittstellenbeschreibung Beschreibung der Schnittstelle "Temperatur" Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

24 Verteilungsdiagramm Beschreibung eines über Kommunikationskanäle verbundenen Systems aus verteilt angeordneten Bausteinen Beschreibung der Infrastruktur für Softwaresysteme Knoten (nodes) und Verbindungen Ausführungseinheiten (z. B. Prozessoren) Geräte (devices) wie z. B. Sensoren oder Aktuatoren Softwarekomponenten können innerhalb der Knoten dargestellt werden Zusammenhang zwischen Infrastruktur und Software verdeutlichen Artefakte spezifizieren physikalische Realisierungen der Komponenten DLLs Quelldateien 24

25 Verteilungsdiagramm: Beispiel Posch, T. et al: Basiswissen Softwarearchitektur. Verstehen, entwerfen, wiederverwenden. dpunkt.verlag, Heidelberg,

26 Elemente des Verteilungsdiagramms Knoten physikalische Verteilungseinheit mit anderen Einheiten über Kommunikationsbeziehungen verbunden Kommunikationsbeziehung Kommunikationskanal zwischen zwei Knoten, beispielsweise eine serielle Leitung, einen CAN-Bus oder TCP/IP Verteilungsbeziehung Zuordnungsbeziehung zwischen einem Knoten und einem auf diesem Knoten ablaufenden Artefakt. Artefakt physikalische Realisierung eines Bausteins 26

27 "The amateur software engineer is always in search of magic, some sensational method or tools whose application promises to render software development trivial." Grady Booch, 1994 "The process of object-oriented analysis and design cannot be described in a cookbook." Grady Booch,

28 Fundamentale Entwurfsprinzipien Fähigkeit des Menschen im Umgang mit Komplexität ist begrenzt Gleichzeitige Verarbeitung auf max. 7 ± 2 Informationen eingeschränkt 5 s für die Aufnahme einer neuen Informationseinheit Bewältigung komplexer Systeme nur durch Erhöhung des semantischen 1 Gehaltes jeder Information möglich Übernahme wichtiger Prinzipien aus dem objektorientierten Entwurf, der genau diese Ziele verfolgt 1 bedeutungsmäßig 28

29 Grundprinzipien: Abstraktion Abstraktion = idealisiertes, vereinfachtes Modell eines realen Objekts Abstraktion hilft, Gemeinsamkeiten zu erkennen Abstraktion in der Softwarearchitektur Beurteilung von Bausteinen grob nach Schnittstellen und Verantwortlichkeiten Hilfsmittel zur Bewältigung der Komplexität der Aufgabe Hilfsmittel für Abstraktion und Generalisierung sind Modelle und Sichten Elemente einer Modellierungssprache stellen Abstraktionen dar Abstraktion geschieht bei ihrer Verwendung bereits implizit Eine Abstraktion ist abhängig von der Sicht des Betrachters Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

30 Grundprinzipien: Kapselung Ursprung: Geheimnisprinzip (information hiding) Verstecken von Daten und ihren Zusammenhängen im Inneren eines Bausteins Objektorientierung kapselt zusätzlich das Verhalten des Objekts Kapselung in der Architektur Fundamentales Grundprinzip für die Einteilung eines Systems in Komponenten mit definierten Verantwortlichkeiten und Schnittstellen Grundlage für viele Architekturstile Beispiel Schichtenarchitektur Grundlegende Funktionalität zur Implementierung eines Bausteins wird in der darunter liegenden Schicht gekapselt z. B. Socket-Funktionalität beim TCP/IP- Protokoll Kapselung versteckt die Details der Implementierung eines Objektes Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

31 Grundprinzipien: Modularität Modularität = Eigenschaft eines Systems, das in eine Menge von in sich geschlossenen und lose gekoppelten Modulen zerlegt wurde Elemente innerhalb eines Moduls sollten eng, Module untereinander lose gekoppelt sein Modularität ermöglicht Arbeitsteilung während des gesamten Entwicklungsprozesses Softwarearchitekt muss modulare Strukturen definieren und manipulieren Modulare Operatoren Aufteilung eines Entwurfs in Module Ersetzen eines modularen Entwurfs durch einen Alternativentwurf Hinzufügen eines neuen Moduls zu einem bestehenden System Entfernen eines Moduls aus einem System Invertieren der Hierarchie eines modularen Systems Portierung eines Moduls Modularität fasst Abstraktionen zu diskreten Einheiten zusammen Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

32 Grundprinzipien: Hierarchiebildung Arten von Hierarchien Enthalten-in- bzw. Besteht-aus-Hierarchien (Struktur) Ist-ein-Hierarchien (Generalisierung, z. B. Vererbung) Substitutionsprinzip bei Vererbungshierarchien Ein abstraktes Element sollte jederzeit durch eine seiner Spezialisierungen ersetzt werden können! Hierarchie in der Architektur Komponentenzentrierter Ansatz Strukturelle Hierarchie verschachtelter Komponenten Generalisierung und Spezialisierung ist vielseitig anwendbar auf Anforderungen, Architekturen, Verantwortlichkeiten von Bausteinen, Schnittstellen Abstraktionen bilden eine Hierarchie Grady Booch: Object-oriented Analysis and Desgin with Applications, Addison-Wesley Longman, Menlo Park,

33 Grundprinzipien: Konzeptuelle Integrität "I will contend that conceptual integrity is the most important consideration in system design." Konzeptuelle Integrität bedeutet Frederick Brooks die durchgängige Anwendung von Entwurfsentscheidungen im gesamten System und damit die Vermeidung von Speziallösungen bzw. Verwässerung der originalen Konzepte. Voraussetzung Trennung von Architekturdesign und Implementierung Ein Architekt bzw. kleines Architekturteam Folge: Erhöhung des semantischen Gehalts von Informationen Entwurfsentscheidungen (z. B. interne Kommunikationsmechanismen) gelten für das gesamte System Übergreifender Informationsgehalt System wird leichter verständlich 33

34 Kopplung Kopplung: Beziehungen unter den Bausteinen einer Softwarearchitektur Kopplung charakterisiert die Interaktionen der Bausteine Einfache Metrik: Anzahl der Beziehungen eines Bausteins zu anderen Bausteinen Arten der Kopplung am Beispiel zweier Klassen mit Zugriff auf gemeinsame Daten Gegenseitiger Zugriff auf die gemeinsamen Daten keine der Klassen kann ohne Betrachtung der anderen geändert werden Kommunikation über eine globale Datenstruktur weniger starke Kopplung, aber Änderungen der globalen Datenstruktur betreffen alle Klassen, die damit arbeiten Kommunikation über Methodenaufrufe und entsprechende Parameter Geringere Kopplung, meist nur lokale Änderungen notwendig Metrik zur Laufzeit Objekt hat hohe Kopplung zu einem anderen, wenn es dessen Methoden häufig aufruft Begriff kann auf alle Arten von Architekturbausteinen abgebildet werden 34

35 Prinzip der losen Kopplung Ziel: Komplexität von Strukturen gering halten Geringe Kopplung zwischen Bausteinen ermöglicht Verständnis eines Bausteins ohne viele andere Bausteine verstehen zu müssen Erhöhung der Änderbarkeit der Architektur lose Kopplung ermöglicht Änderungen oder Austausch eines Bausteins ohne nennenswerte Rückwirkungen auf die übrigen Bausteine Gesetz von Demeter Ein Systembaustein sollte nur eng verwandte Bausteine benutzen ("Sprich nicht mit Fremden") 35

36 Prinzip der hohen Kohäsion Kohäsion 1 : Abhängigkeiten innerhalb eines Systembausteins Köhäsion innerhalb eines Bausteins soll möglichst hoch sein Beispiel: Anzahl der Methodenaufrufe innerhalb einer Klasse Anzahl der Methodenaufrufe zwischen Klassen, die zusammen einen Baustein bilden lokale Änderbarkeit einzelner Systembausteine wird verbessert Wechselbeziehung zwischen Kopplung und Kohäsion Je höher die Kohäsion individueller Bausteine ist, desto geringer ist die Kopplung zwischen den Bausteinen Elemente mit hohem Kommunikationsbedarf (z. B. Datenaustausch) sollten daher in einem Architekturbaustein zusammengefasst werden Geringe Kohäsion führt zu starker Kopplung 1 lat. cohaerere zusammenhängen Hohe Kohäsion führt zu loser Kopplung 36

37 Prinzip des Entwurfs für Veränderung Idee: Architektonische Vorausplanung vorhersehbarer Änderungen Wahrscheinliche Änderungen Erhebung und Beachtung weiter gehender Anforderungen Unklarheiten in der Anforderungsspezifikation können auf weiter gehene Funktionalitätsanforderungen hindeuten Geplante Weiterentwicklungen Erfahrungen aus dem Entwurf ähnlicher Architekturen Umgang mit diesen Änderungen setzt Erfahrung des Architekten voraus! Unerwartete Änderungen Vorsicht! Generelle Vorausplanung ist problematisch, weiter gehender Entwurf kann Zeit und erhöhten Implementierungsaufwand bedeuten Nachteile hoch flexibler Architekturen: höherer Ressourcenverbrauch Lose Kopplung Entwurf für Veränderung Einsatz vorzugsweise an "Hot Spots" Stellen, wo schon oft Änderungen aufgetreten sind Stellen, wo viele verschiedene Aspekte einer Architektur zusammenkommen 37

38 Separation-of-Concerns-Prinzip Trennung verschiedener Aspekte eines Problems und separate Behandlung jedes dieser Teilprobleme Zerlegung eines Softwaresystems in eine Struktur von Systembausteinen Separation-of-Concerns-Prinzip unterstützt die Modularisierung Dekompositionskriterien Funktionalität oder Wiederverwendung Trennung von fachlichen und technischen Teilen Trennung der fachlichen Abstraktion von ihrer konkreten technischen Umsetzung Negativbeispiel: Steuerung für CNC-Maschinen Monolithische Software Keine Trennung zwischen Algorithmen für die Bewegungsführung, Kommunikation mit dem GUI, Bearbeitung der CNC-Programme,... Portierung auf geänderte Systemplattform nahezu unmöglich Arbeitsteilung bei der Portierung nicht möglich keine Wiederverwendung von Systemteilen möglich 38

39 Geheimnisprinzip (Information-Hiding-Prinzip) Fundamentales Prinzip zum Verstehen komplexer Systeme Zeige einem Klienten nur das, was er für seine Aufgabe benötigt Anwendung des Prinzips z. B. in der Modularisierung Kapselung von Entwurfsentscheidungen in einem Systembaustein Bekanntgabe durch wohl definierte Schnittstellen Konzept der Sichtbarkeit in Objekt- und Komponentenkonzepten (public vs. private) Data Hiding Umsetzung durch Objektorientierung, Datenbankschnittstellen und Abfragesprachen Konzepte / Beispiele zur Umsetzung Information Hiding mittels Facade (Fassade) Information Hiding durch Schichtenbildung 39

40 Information Hiding Beispiele Information Hiding mittels Facade Information Hiding durch Schichtenbildung Software-Architektur. Grundlagen - Konzepte - Praxis. Spektrum Akademischer Verlag, Heidelberg,

41 Abstraktionsprinzipien für Schnittstellen Explizite Schnittstellen Anhand eines Systembausteins soll direkt erkennbar sein, mit welchen anderen er kommuniziert Explizite Bekanntgabe von Schnittstellen Entwurf der Softwarearchitektur soll auf Basis der Schnittstellen erfolgen Trennung von Schnittstelle und Implementierung Beschreibung der Schnittstellen separat von der Implementierung Klient kann sich ohne Kenntnis der Implementierungsdetails auf die Schnittstelle verlassen Ermöglicht z. B. parallele Verwendung unterschiedlicher Versionen eines Systembausteins ohne Änderung des Klienten Liskov-Substitutions-Prinzip Bei Vererbungsabstraktionen sollen erbende Klassen von Klienten durch die Schnittstelle der vererbenden Klasse aufrufbar sein. Klient kann sich darauf verlassen, dass alle Objekte eines Typs (also auch ererbte) die gleiche Schnittstelle unterstützen Schnittstellen-Segregations-Prinzip Ein Klient sollte nie auf einer Schnittstelle basieren, die er nicht benutzt Aufteilen (segregieren) komplexer Schnittstellen, auf denen mehrere Klienttypen basieren, in mehrere einzelne Schnittstellen 41

42 Rückverfolgbarkeits- und Selbstdokumentationsprinzip Rückverfolgbarkeit (traceability) Zuordnung von Anforderungen zu Systembausteinen Zuordnung von Umsetzung architektonischer Strukturen im Code zu Entwurfsmodell, Architekturbeschreibung etc. Abbildbarkeit verschiedener Entwurfssichten aufeinander Annotationen im Code konsequente Verwendung der gleichen Bezeichnungen Selbstdokumentationsprinzip Jede Information über einen Systembaustein sollte Teil des Bausteins sein Generierung von API-Beschreibungen möglich (z. B. JavaDoc, Doxygen) Erleichtert die Rückverfolgbarkeit 42

43 Weitere Architekturprinzipien Bezug zu Anwendungsfällen Architektur soll sich im Entwurf an relevanten Anwendungsfällen orientieren Architektur schießt nicht über das angestrebte und gewünschte Ziel des Systems hinaus Vermeidung überflüssiger Komplexität Unnötig komplexe Architekturen sind meist fehleranfällig und werden nur unzureichend verstanden. Konsistenz Durchgängiger, einheitlicher Satz von Regeln bezüglich Namensgebung, Kommunikation der Systembausteine, Struktur der Schnittstellen, Aufbau der Dokumentation Konventionen statt Konfigurationen Sinnvolle Standardannahmen treffen Nur notwenige Anpassungen müssen konfiguriert werden 43

44 Architekturstile Architekturarten, die häufig angewendet werden Globale Strukturierungs- bzw. Organisationsprinzipien für Softwarearchitekten Vermischung von Architekturstilen auf einer Abstraktionsebene sollte vermieden werden Verwendung unterschiedlicher Stile auf unterschiedlichen Abstraktionsebenen ist unproblematisch, verletzt aber das Prinzip der konzeptionellen Integrität des Entwurfs Wichtige Architekturstile Schichten (Layers ) Verbindungen und Filter (Pipes and Filters) Objektorientierung Impliziter Aufruf (Implicit Invocation) 44

45 Schichten (Layers) Horizontale Schichten Jede Schicht repräsentiert eine bestimmte Abstraktionsebene Verwendung von Operationen der darunter liegenden Schicht Bietet der darüber liegenden Schicht komplexere Operationen an Strikte Schichtenarchitekturen Vorteile Jede Schicht greift nur auf Operationen der darunter liegenden Schicht zu Verschiedene Abstraktionsebenen Portierung beschränkt sich auf Portierung der untersten Schicht Betriebssicherheit und Schutz von Einbrüchen in das System, weil Überwachungsschichten leicht eingezogen werden können Nachteile Mehrbedarf an Rechenzeit Risiko bezüglich der Performance Bei strikter Schichtenarchitektur viele Indirektionen layer bridging 45

46 Verbindungen und Filter (Pipes and Filters) Beschreibung Zusammenarbeit von Bausteinen in Form eines Datenflussgraphen Jeder Baustein hat Ein- und Ausgänge, über die ein Datenstrom durch den Baustein fließt und verarbeitet wird Pipes Verbindungen zwischen den Bausteinen Einsatz und Vorteile Sinnvoll bei Verarbeitung von kontinuierlichen Datenströmen Filterbausteine arbeiten asynchron und voneinander unabhängig Einfache Verteilung auf mehrere Entwickler Umkonfigurierung und Wiederverwendung der Bausteine leicht möglich Nachteile Leistung durch Umkopieren und Transport aller Daten Wartbarkeit, weil geänderte Anforderungen mehrere Bausteine beeinflussen Zuverlässigkeit : gesamte Kette ist genauso schwach wie ihr schwächstes Glied 46

47 Beispiele: Compiler und Unix-Shell B. Anzeletti, W. Keller, R. Lewandowski, K. Messner: Vorlesung für große Informationssysteme, Technische Universität Wien, SS

48 Objektorientierung Zusammensetzung von Architekturen aus kooperierenden Objekten Objekte, die Daten kapseln Objekte, die als Manager und Controller agieren Komponenten verwalten ihre Daten und bündeln Verantwortung für Daten und Funktionalität Vorteile Trennung Implementierung Verwendung erleichtert Austauschbarkeit Wiederverwendbarkeit, etwa Klassenbibliotheken Nachteile Verwender müssen Objektidentität kennen Zerfaserung von Funktionalität auf viele Objekte 48

49 Impliziter Aufruf (Implicit Invocation) Bausteine versenden Ereignisse (events) Empfang und Bearbeitung durch ihnen unbekannte Bausteine Ereignisse sind asynchron, Ausführung empfangenden Baustein blockiert Sender des Ereignisses nicht Vorteile Nachteile Entkopplung von Bausteinen Wartbarkeit, Flexibilität Einsatz in verteiltem System möglich Overhead durch Kommunikationssystem Leistung Zusätzliche Strukturen zum Verständnis nötig (z. B. Protokolle) Beispiele Grafische Benutzeroberflächen (die Kontrollelemente wie Buttons, Slider etc. senden die Ereignisse) Eingebettete Systeme (Empfang interner und externer Ereignisse, Abarbeitung häufig in Echtzeit) 49

50 Architekturmuster Architekturstil = globales Strukturierungsprinzip für eine Softwarearchitektur Darüber hinaus: Querschnittsaspekte Nebenläufigkeit Persistenz Verteilung Betreffen die gesamte Architektur Sind unabhängig von der Wahl des Architekturstils Anwendung von Architekturmustern Architekturmuster betreffen technische Aspekte von Softwaresystemen Infrastrukturthemen Architekturmuster sind prinzipiell sprachneutral und plattformunabhängig. Konkrete Ausprägungen sind an ein bestimmtes OS oder eine Sprache gebunden, z. B. EJB oder.net. 50

51 Beispiel: Model View Controller Bei diesem Architekturmuster werden interaktive Applikationen aus drei Grundbausteinen zusammengesetzt. Die Kernfunktionalität und die Datenbasis werden im Modell (engl. model) zusammengefasst. Ansichten (engl. views) und Steuerungskomponenten (engl. controller) bilden die Benutzerschnittstelle. Dabei werden die Daten durch die Ansichten präsentiert und Eingaben durch die Steuerungskomponenten verarbeitet. Ein Notifikationsmechanismus ermöglicht die Konsistenz von Ansichten und Modell. 51

52 Heuristiken und Tipps für die Praxis (1) Heuristiken aus dem Projektumfeld Hinterfragen Sie Anforderungen! Betrachten Sie Use Cases! Nutzen Sie andere Systeme als Inspiration! Suchen Sie Feedback! Heuristiken für den Entwurf So einfach wie möglich! Bleiben Sie auf der richtigen Detailebene! Modellieren Sie angemessen komplex! Denken Sie in Verantwortlichkeiten! Nicht übergeneralisieren! Konzentrieren Sie sich auf die Schnittstellen! Entwerfen Sie so lokal wie möglich! 52

53 Heuristiken und Tipps für die Praxis (2) Heuristiken zur Beherrschung von Komplexität Teile und herrsche! Verstecken Sie Details! Kapseln Sie Risiken! Trennen Sie Funktionalität und Kontrolle! Trennen Sie Fachlogik und Infrastruktur! Heuristiken zur Arbeitsmethodik Beginnen Sie mit den schwierigsten Teilen! Verwenden Sie Prototypen! Werfen Sie Prototypen weg! Dokumentieren Sie Entscheidungen! 53