Software Engineering. Grundlagen von Softwarearchitekturen

Transkript

1 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 Prof. Dr. Andreas Schmietendorf 1

2 Inhaltsübersicht Definitionen zur Softwarearchitektur Architekturmerkmale Qualitätsattribute einer Architektur Entwurfsprinzipien einer Architektur Prof. Dr. Andreas Schmietendorf 2

3 Definitionen zur Softwarearchitektur Prof. Dr. Andreas Schmietendorf 3

4 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 ] Prof. Dr. Andreas Schmietendorf 4

5 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 ( Prof. Dr. Andreas Schmietendorf 5

6 Architekturmerkmale Prof. Dr. Andreas Schmietendorf 6

7 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 Prof. Dr. Andreas Schmietendorf 7

8 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 Prof. Dr. Andreas Schmietendorf 8

9 Proxy- & Publisher-Subscriber-Muster Unter Verwendung von: Faustmann, G.: Vorlesung Software Engineering, FHW Berlin Fachbereich II Prof. Dr. Andreas Schmietendorf 9

10 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 Prof. Dr. Andreas Schmietendorf 10

11 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 Prof. Dr. Andreas Schmietendorf 11

12 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 Prof. Dr. Andreas Schmietendorf 12

13 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 Prof. Dr. Andreas Schmietendorf 13

14 Übung 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 die Möglichkeit, eigene Definitionen für SW-Architektur anzugeben Prof. Dr. Andreas Schmietendorf 14

15 Qualitätsattribute einer Architektur Prof. Dr. Andreas Schmietendorf 15

16 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 Prof. Dr. Andreas Schmietendorf 16

17 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 Prof. Dr. Andreas Schmietendorf 17

18 Ü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 Prof. Dr. Andreas Schmietendorf 18

19 Entwurfsprinzipien einer Architektur Prof. Dr. Andreas Schmietendorf 19

20 Ü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 Prof. Dr. Andreas Schmietendorf 20

21 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 Prof. Dr. Andreas Schmietendorf 21

22 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 Prof. Dr. Andreas Schmietendorf 22

23 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 Prof. Dr. Andreas Schmietendorf 23

24 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 Prof. Dr. Andreas Schmietendorf 24

25 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 Prof. Dr. Andreas Schmietendorf 25

26 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 Prof. Dr. Andreas Schmietendorf 26

27 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 Prof. Dr. Andreas Schmietendorf 27

28 Ü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 Prof. Dr. Andreas Schmietendorf 28

29 Entwurfsmuster Beispiele Strukturmuster statische Struktur von Klassen und Objekten - Adapter - Fassade Verhaltensmuster Zusammenwirken von Objekten - Beobachter - Vermittler Erzeugungsmuster Erzeugen von Objekten - Fabrikmethode - Singleton Prof. Dr. Andreas Schmietendorf 29