Hochschule Darmstadt Fachbereich Informatik. Softwaretechnik II. 4.1 Darstellung der Architektur

Transkript

1 Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.1 Darstellung der Architektur

2 Darstellung der Architektur Was macht ein Architekt? Viele Pläne! Endkunde Elektro Bauarbeiter Sanitär Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 96

3 Sichten der Software-Architektur Beim Hausbau gibt es viele verschieden Pläne ("Sichten") Raumaufteilung (Grund- und Seitenriss) Elektroinstallation und Datennetz Sanitäre Installation Bei der Software gibt es ebenfalls verschiedene Sichten Logische Zerlegung Verteilung auf Zielsysteme Quelldateien Prozesse / Threads komplexe Systeme werden in mehreren Sichten ("Views") dargestellt Im konkreten Fall wählt man die "passenden" Sichten Das Wesentliche der Architektur lässt sich in der Regel nicht in einer einzigen Sicht darstellen Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 97

4 Sichten einer SW Architektur (nach Kruchten) Es gibt verschiedene Methoden, eine Softwarearchitektur darzustellen: z.b. das 4+1-Sichten-Modell (Kruchten 1995, verwendet u.a. im Rational Unified Process) Designer: Funktionalität Logische Sicht Implementierungs-Sicht Entwickler: Systemteile Quellcode Anwender/Tester Verhalten Anwendungs-Sicht Prozess-Sicht Physische Sicht Designer: Performanz Skalierbarkeit System Technik: Systemtopologie Verteilung Auslieferung Installation Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 98

5 Logische Sicht Elemente: Komponenten (Klassen), Verantwortlichkeiten, Kollaborationen Beziehungen: Assoziation, Abhängigkeit, Vererbung, Inhalt: Aufteilung der Domäne, Zuständigkeiten, Funktionalität Stakeholder: Anwender, Analytiker, Designer, Domänenexperte Umsetzung: Komponenten-, Klassen-, Sequenzdiagramme u.ä. Die Architektur wird oft auf die logische Sicht beschränkt......dann fehlen viele wichtige Aspekte! Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 99

6 Implementierungs-Sicht Elemente: Dateien, Repositories Beziehungen: Enthaltensein, Abhängigkeit Inhalt: Systembestandteile, Konfiguration Stakeholder: Designer, Entwickler, Konfigurationsmanager Umsetzung: Komponentendiagramme «use» Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 100

7 3 return (HTMLPage) 2: PHP Parse(HTML_Code) 4.1 Darstellung der Architektur Prozess-Sicht Elemente: Prozesse, Threads Beziehungen: Aktivierungssteuerung, (gemeinsame) Ressourcen Inhalt: Performanz, Skalierbarkeit, Verfügbarkeit Stakeholder: Designer, Tester, Deployer Umsetzung: Kommunikations-, Timing-, Sequenzdiagramme u.ä. Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 101

8 Physische Sicht Elemente: Hardwareressourcen Beziehungen: Kommunikationskanäle, Abhängigkeit Inhalt: Hardwaretopologie Stakeholder: Hardwareingenieur, Logistik Umsetzung: Kompositionsstruktur-, Verteilungs-, Komponentendiagr. u.ä. Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 102

9 Anwendungs-Sicht ("+1") Komponenten: Akteure, Anwendungsfälle Beziehungen: Interaktion, Verwendung Inhalt: Verhalten des Systems Stakeholder: Anwender, Analytiker, Tester Umsetzung: Sequenz-, Kommunikationsdiagramme u.ä. Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 103

10 Dokumentation und Tools Die UML bietet diverse Möglichkeiten um Architektursichten darzustellen. Zum Beispiel: Logische Sicht: Komponentendiagramm, Klassendiagramm Implementierungs-Sicht: Komponentendiagramm, Zustandsdiagramm Prozess-Sicht: Timing Diagramm, Kommunikationsdiagramm Physische Sicht: Verteilungs-Diagr., Kompositionsstruktur-Diagramm Anwendungssicht: Sequenzdiagramm, Kommunikationsdiagramm Welche Diagramme verwendet werden (dürfen), legt der Architekturprozess fest! Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 104

11 Tipps zur Dokumentation UML als Lingua Franca Es geht nicht darum, die neuesten UML-Features zu verwenden Sie dokumentieren für Ihre Kollegen und die Wartungsphase Wenn Sie etwas Wesentliches nicht im Modell ausdrücken können, verwenden Sie einfach eine Notiz nicht "nur" das Endergebnis dokumentieren! Ebenfalls wertvoll sind Grundsätzliche Ideen und Lösungsansätze (Metaphern) wichtige Zwischenschritte (z.b. "vorläufige Lösung bis Standard X existiert") nicht so leicht ersichtliche Randbedingungen (z.b. "weil Komponente X das so macht") Hinweise (z.b. "Umsetzung erfolgt so wg. Anforderung X ") Begründung bei einer Entscheidung mit Alternativen Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 105

12 Dokumentation der Architektur - Entscheidungen Wichtige Diskussionen und Entwurfsüberlegungen dokumentieren Entscheidungen, Alternativen und Argumente müssen nachvollziehbar sein Vermeidung von wiederkehrenden Diskussionen kein Standard, keine UML aber sehr hilfreich! IBIS method, Tool: Questmap Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 106

13 Hochschule Darmstadt Fachbereich Informatik Softwaretechnik II 4.2 Zusammenfassung SW-Architektur

14 4.2 Zusammenfassung Software-Architektur Nutzen einer SW-Architektur für den Entwicklungsprozess trifft weitreichende, frühe Designentscheidungen weist Machbarkeit von Softwarefunktionalität nach macht Vorgaben für Design und Implementierung strukturiert den Entwicklungsprozess bietet Kommunikationsplattform für die Planbarkeit liefert die Einheiten der Planung für Design, Implementierung, Test und Wartung für die Wettbewerbsfähigkeit reduziert Kosten durch Wiederverwendung im Großen erhöht Flexibilität durch Betrachtung von Varianten ohne Umsetzung Ohne eine SW-Architektur ist die Komplexität eines großen Projekts nicht zu bewältigen! Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 108

15 4.2 Zusammenfassung Software-Architektur Auswirkungen von Fehlern in der SW-Architektur Fehler in Requirements: Unterschätzung der Bedeutung / Übersehen eines wichtigen Requirements - Schwerwiegende Änderungen / keine Wiederverwendung Überschätzung der Bedeutung - Unnötige Arbeit und Kosten Falsche Gewichtung der Requirements gegeneinander - Falsche Ausrichtung der Architektur / Verfehlung des Projektziels Fehler in der Struktur aus Komponenten und deren Beziehungen: Ungeschickte Aufteilung bzw. Festlegung der Verantwortlichkeiten - Kleine Änderungen haben große Auswirkung Zu grobe Struktur - Keine ausreichenden Vorgaben für die Entwicklung / Übersehen von Problemen Zu feine Struktur - Ineffiziente Architektur-Arbeit Architekturentwicklung ist immer eine Gratwanderung! Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 109

16 4.2 Zusammenfassung Software-Architektur Kontrollfragen zur Software-Architektur Warum ist eine Software-Architektur für ein großes Projekt wichtig? Welche Grundprinzipien im Entwurf kennen Sie? Wie hängen Qualitätseigenschaften mit der SW-Architektur zusammen? Was passiert, wenn die Bedeutung einer Anforderung unterschätzt wird? Woher wissen Sie, dass Ihre Architektur optimal ist? Welche Aspekte des Entwurfs drückt man in der SW-Architektur aus? Wie wirkt sich die Verwendung eines Architektur-Stils aus? Hängt die SW-Architektur von der Programmiersprache / dem Betriebssystem ab? Wie dokumentieren Sie eine SW-Architektur? Ahnen Sie jetzt wie man eine SW-Architektur erstellt? Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 110

17 4.2 Zusammenfassung Software-Architektur Literatur Len Bass et.al.: Software Architecture in Practice; Addison-Wesley; 2003 Paul Clements et.al.: Documenting Software Architectures; Addison- Wesley; 2002 Ralf Reussner, Wilhelm Hasselbring: Handbuch der Software-Architektur; dpunkt 2006 Softwaretechnik II, Prof. Dr. Ralf Hahn, WS , h_da, Fachbereich Informatik 111