Software Engineering Grundlagen von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der jeweils angegebenen Literatur erstellt. Darüber hinaus finden sich ausgewählte Beispiele zur Softwareentwicklung aus dem Bereich der Telekommunikation. 08.10.2013 Prof. Dr. Andreas Schmietendorf 1
Inhaltsübersicht Definitionen zur Softwarearchitektur Architekturmerkmale Qualitätsattribute einer Architektur Entwurfsprinzipien einer Architektur 08.10.2013 Prof. Dr. Andreas Schmietendorf 2
Definitionen zur Softwarearchitektur 08.10.2013 Prof. Dr. Andreas Schmietendorf 3
Definition 1 Grundlage kann eine Definition der IEEE sein, die Architektur als Komponenten und deren Interaktion definiert, sowie Entwurfsregeln und Veränderungen beinhaltet: Architecture is defined by the remommended 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. Quelle: [ANSI/IEEE Std 1471-2000] 08.10.2013 Prof. Dr. Andreas Schmietendorf 4
Definition 2 Eine andere Definition einer relevanten Publikation nennt Abstraktion und verschiedene Sichten als wichtige Konzepte: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Quelle: [Bass, Klements, Kazman, Software Architecture in Practice, 2nd ed., Addison Wesley, 2003] Das Software Engineering Institute verwaltet eine Liste von Definitionen für Software-Architektur (http://www.sei.cmu.edu/architecture/definitions.html). 08.10.2013 Prof. Dr. Andreas Schmietendorf 5
Architekturmerkmale 08.10.2013 Prof. Dr. Andreas Schmietendorf 6
Architektur definiert Struktur Software-Architekt unterteilt ein System in Teile - Komponenten bzw. Module, - Objekte bzw. Dienste/Services, Diese Unterteilung muss bestimmten Anforderungen genügen. Beispiele für solche Anforderungen sind: - Funktions- und Datenverteilung - Internetbasierte Zugriffskanäle Komponenten des Systems erhalten Verantwortlichkeiten Ziel: Verringerung der Abhängigkeiten zwischen Komponenten. 08.10.2013 Prof. Dr. Andreas Schmietendorf 7
Architektur beschreibt Kommunikation Komponenten kommunizieren miteinander, sie tauschen Daten und Kontrollinformationen aus. Vielfältige Möglichkeiten zur Kommunikation wie z.b.: - Gleicher Adressraum via Methodenaufrufe - Middleware (CORBA, RMI, SOAP/WSDL, JSON, ) - REST basierter Architekturstil Design- und Architekturmuster (engl. Pattern) beschreiben erfolgreiche Strukturen, die verschiedene Arten der Komponentenkommunikation unterstützen. Beispiele sind das Proxy- und das Publisher-Subscriber-Muster. 08.10.2013 Prof. Dr. Andreas Schmietendorf 8
Proxy- & Publisher-Subscriber-Muster Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 9
Architektur adressiert NFA Nichtfunktionale Anforderungen sind durch UC nicht abgedeckt Bereiche nichtfunktionaler Eigenschaften: - Technische Bedingungen, z.b. Programmiersprache, Datenbank, OS - Geschäftsbedingungen, z.b. Schnittstellen zu Business-Systemen, - Qualitätsattribute, z.b. Skalierbarkeit, Verfügbarkeit. Während die ersten beiden Bereiche in den meisten Fällen durch die Kundenwünsche feststehen, werden Qualitätsattribute durch viele Beteiligte festgelegt (z.b. Nutzer, Projektteam, Geldgeber). Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 10
Architektur ist Abstraktion Hierarchische Dekomposition ist ein hilfreicher Mechanismus zur Beschreibung von SW-Architekturen. So können z.b. Komponenten auf verschiedenen Abstraktionsebenen beschrieben werden. Verfeinerungen entstehen durch Anforderungen, z.b. ein vorhandener Server muss eingesetzt werden. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 11
Architektursichten nach Kruchten Kruchten schlägt vier Perspektiven vor: - Logische Sicht der Architektur z.b. durch Klassendiagramme. - Prozesssicht beschreibt Kommunikationsmechanismen. - Physische Sicht beschreibt die Verteilung der Komponenten. - Entwicklungssicht beschreibt die interne Organisation der Komponenten z.b. in Pakete. Quelle: P. Kruchten: Architectural Blueprints, IEEE Software, 12(6) Nov. 1995 08.10.2013 Prof. Dr. Andreas Schmietendorf 12
Architektursichten nach SEI Das Software Engineering Institute (SEI) schlägt in seinem Views and Beyond -Ansatz drei Sichten auf SW-Architektur vor: - Module: Strukturelle Sicht, für Klassen, Pakete und Subsysteme - Komponenten und Konnektoren: Diese Sicht beschreibt den Verhaltensaspekt. Komponenten können Objekte sein, die z.b. über Sockets als Konnektoren kommunizieren. - Allokation: Diese Sicht beschreibt die Abbildung auf Hardware und die Kommunikation über Netzwerke/ DBS. Quelle: Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.: Documenting Software Architectures: Views and Beyond, SEI Series in Software Engineering 08.10.2013 Prof. Dr. Andreas Schmietendorf 13
Übung 11-1 1. Versuchen Sie die Ihnen jetzt bekannten Perspektiven auf eine SW- Architektur in eine umfassende Definition zu bringen. 2. Wie könnte man die erwähnten Sichten auf eine SW-Architektur mit Ihnen bekannten Mitteln beschreiben? 3. Nennen Sie Beispiele für nichtfunktionale Anforderungen. Das SEI bietet unter http://www.sei.cmu.edu/architecture/definitions.html die Möglichkeit, eigene Definitionen für SW-Architektur anzugeben. 08.10.2013 Prof. Dr. Andreas Schmietendorf 14
Qualitätsattribute einer Architektur 08.10.2013 Prof. Dr. Andreas Schmietendorf 15
Qualitätsattribute Qualitätsattribute einer SW-Anwendung sind Teil ihrer NFA Sie müssen exakt formuliert sein ( muss schnell sein ) Für viele Attribute gibt es verschiedene Perspektiven wie z.b.: - Anzahl der simultanen Nutzerverbindungen, - steigendes Datenvolumen, - Eine größere Nutzerbasis. Meist sind Anforderungen nichtfunktionaler Art schwer testbar Es existieren sehr viele allgemeine Qualitätsattribute. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 16
Qualitätsattribute Zeit- und ressourcenbezogene Effizienz (Performance) Skalierbarkeit Änderbarkeit Sicherheit Verfügbarkeit Möglichkeiten zur Daten- und Funktionsintegration Portabilität Test- und Wartbarkeit Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 17
Übung 11-2 In welcher Weise sollten die dargestellten Qualitätsattribute (vorherige Folie) während der Analysephase eines neuen Softwaresystems berücksichtigt werden. Identifizieren Sie entsprechende Spezifikationsansätze. Auswahl von jeweils 2 Qualitätsattribute je Laborgruppe Überlegen Sie sich methodische und werkzeugbezogene Ansätze zum Erreichen der vorgestellten Qualitätsattribute. 08.10.2013 Prof. Dr. Andreas Schmietendorf 18
Entwurfsprinzipien einer Architektur 08.10.2013 Prof. Dr. Andreas Schmietendorf 19
Übersicht - Entwurfsprinzipien SW-Architekturen erfüllen Anforderungen mehr oder weniger gut. Jedoch existieren allgemeine Prinzipien, die beim Entwurf einer Architektur beachtet werden sollten. Eine erkennbare Missachtung dieser Prinzipien kann als Warnsignal bei der Beurteilung einer Architektur gesehen werden. Die Hauptansätze der Prinzipien sind: - Reduktion der Komplexität und - Erhöhung der Flexibilität/ Änderbarkeit Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 20
Lose Kopplung Kopplung ist die Beziehung von Bausteinen in einer Architektur. Betrachtet man z.b. Klassen in OO-Systemen, so kann die Anzahl der Verbindungen gezählt und deren Stärke beurteilt werden. Die Kopplung in einer Architektur sollte möglichst gering gehalten werden. (Lesbarkeit und Änderbarkeit) Teilprinzipien der losen Kopplung sind: - Law of Demeter: Ein Systembaustein sollte nur eng verwandte Bausteine benutzen ( Sprich nicht mit Fremden! ). - Vermeidung zirkulärer Abhängigkeiten: Ursache vieler Probleme (Deadlocks, schwierige Änderbarkeit) arbeitsteilige Entwicklung nahezu ausgeschlossen. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 21
Hohe Kohäsion/ Bindung Kohäsion Abhängigkeiten innerhalb eines Systembausteins. Kopplung und Kohäsion stehen in einer Wechselbeziehung: Je höher die Kopplung, desto geringer die Kohäsion. So sollten z.b. ähnliche Anforderungen Teil desselben Systembausteins sein, da sie sonst zu hohem Kommunikationsbedarf tendieren. Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 22
Entwurf für Veränderung Architektonisches Vorausplanen vorhersehbarer Änderungen - Berücksichtigung weitergehender Anforderungen, - Unklarheiten in Anforderungsspezifikationen, - spätere Weiterentwicklungen (z.b. aus Kostengründen), - häufige Änderungen/Anpassungen dieses Systemtyps Probleme: - Zusätzliche Zeit für den weitergehenden Entwurf notwendig - Ggfs. höherer Ressourcenverbrauch Beispiele für Instrumente: - Aufrufschnittstellen in Middleware-Systemen - Verwendung von Konfigurationsdateien Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 23
Separation of Concerns Prinzip: Aspekte eines Problems voneinander trennen und jedes Teilproblem für sich behandeln ( Teile und herrsche ) Reduktion der Komplexität und arbeitsteilige Bearbeitung Möglichkeiten sind die Zerlegung - des Systems in Systembausteine ( Modularisierung ), - der Anforderungen, - in Sichten, - in organisatorische Verantwortlichkeiten, - der Erstellungsprozess in Teilprozesse. Grundsätzlich erfolgt Trennung in fachliche und technische Teile Weiter geht ein multidimensionales Separation of Concerns Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 24
Information Hiding Nur der für eine Aufgabe notwendige Teil von Informationen wird nach außen gezeigt. Von hoher Bedeutung für die Verständlichkeit einer Architektur. Öffentliche Schnittstellen verbergen Implementierungen und verwendete Daten innerhalb eines Systembausteins. Information Hiding ist auch Strukturierungsprinzip für größere Systemstrukturen: Facade-Entwurfsmuster Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 25
Abstraktion Wichtige Aspekte identifizieren und unwichtige Details vernachlässigen Beispiele zur Schnittstellenabstraktion: - Trennung von Schnittstelle und Implementierung - Design-by-Contract (Vor- und Nachbedingungen) - Explizite Schnittstellen Bekanntgabe eigener und verwendeter SSt. - Schnittstellenunterstützung im Entwurf und in der Implementierung - Schnittstellen-Segregationsprinzip (nur benötigte SSt. Integrieren) - Liskov-Substitutionsprinzip (Syntaktische und semantische korrekte Weitergabe von Schnittstellen an abgeleitete Klassen Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 26
Modularität Klare Abgrenzung der funktionalen Verantwortlichkeit von Systembausteinen. Kombination der Prinzipien Abstraktion, Separation of Concerns und Information Hiding. Meyer fordert die Kriterien: - Modulare Dekomposition des Problems: Zerlegung in Teilprobleme - Modulare Komposition: Freies Zusammensetzen der Teillösungen - Modulare Verstehbarkeit: Jeder Baustein für sich ist verstehbar - Modulare Kontinuität: Kleine Änderungen betreffen nur einen Baustein - Modulare Protektion: Fehler bleiben auf einen Baustein begrenzt Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II 08.10.2013 Prof. Dr. Andreas Schmietendorf 27
Übung 11-3 Beschreiben Sie, welche der dargestellten Abstraktionsprinzipien von der Programmiersprache Java direkt oder indirekt unterstützt werden. Gehen Sie dabei auf folgende Sichten ein: - Notationssicht - Architektursicht Wählen Sie jeweils ein Struktur-, Verhaltens-und Erzeugungsmuster (siehe umseitige Beispiele) und gehen Sie dabei auf folgende Aspekte (Name, Problem, Lösung UML/Java, Bewertung, Einsatzgebiete) ein. 08.10.2013 Prof. Dr. Andreas Schmietendorf 28
Entwurfsmuster Beispiele Strukturmuster statische Struktur von Klassen und Objekten - Adapter - Fassade Verhaltensmuster Zusammenwirken von Objekten - Beobachter - Vermittler Erzeugungsmuster Erzeugen von Objekten - Fabrikmethode - Singleton 08.10.2013 Prof. Dr. Andreas Schmietendorf 29