Beschreibung und Kommunikation. von Software-Architekturen

Transkript

1 Beschreibung und Kommunikation von Software-Architekturen ITech Progress GmbH 2013

2 Über uns Mahbouba Gharbi Geschäftsführerin der ITech Progress GmbH Trainerin, Beraterin und jahrzehntelange Projekterfahrung als Softwarearchitektin Vorstandsvorsitzende isaqb e.v. Prof. Arne Koschel Professor an der FH Hannover Langjährige Erfahrung als Senior-Berater, Projektleiter, Produkt-Manager und Dozent in Forschung und Industrie mit dem Fokus Architektur und Konzeption Middlewarebasierter, heterogener, verteilter Informationssysteme.

3 Agenda Motivation Sichten auf die Software-Architektur Software-Architekturdokumentation Frameworks und Werkzeuge für Dokumentation

4 Einordnung in der Software-Architekturentwicklung Anforderungen klären Software- Architektur bewerten Software- Architektur entwerfen kommunizieren 4

5 Typische Fragen in Softwareprojekten Typische Fragen Wie arbeiten verschiedene Softwarekomponenten zusammen? Ist es irgendwo aufgezeichnet? Wie sieht das Schichtenmodell aus? Welche Design Patterns wurden verwendet? Welches Framework wird verwendet? Welche externen Web Services werden verwendet? Warum benutzen wir Java 1.4? Wieso habt Ihr das so gemacht? Ist das nicht zu kompliziert? Typische Antworten Es ist in Wiki dokumentiert. Es gibt keine Dokumentation, weil wir agil vorgehen. Das war vor meiner Zeit so, bevor ich ins Projekt kam. Es ist historisch gewachsen. Es wurde in einem Meeting entschieden. 5

6 Nutzen von Software-Architekturdokumentation Macht Architekturentscheidungen nachvollziehbar und bewertbar Hilft Fehler und Probleme zu lokalisieren Liefert Systemüberblick Software- Architektur- Dokumentation Ermöglicht bessere Antworten auf Fragen Ist gute Grundlage für Softwareumsetzung Hilft auf Änderungen im technischen und betrieblichen Umfeld schneller zu reagieren Hilft Auswirkungen von neuen und geänderten Anforderungen abzuschätzen 6

7 Qualitätsmerkmale für Architekturdokumentation Verständlichkeit Angemessenheit Korrektheit Effizienz Einfachheit Kürze 7

8 Praxis der Architekturdokumentation??? Bildquelle: 8

9 Agenda Motivation Sichten auf die Software-Architektur Software-Architekturdokumentation Frameworks und Werkzeuge für Dokumentation

10 Sichtenkonzept Modelliert (abstrahiert) die Realität Betrachtung des Systems aus einer bestimmten Perspektive Unwichtige Details für die entsprechende Perspektive weglassen Einzelne Sicht kann nicht die gesamte Komplexität des Systems darstellen Können gezielt an Bedürfnisse der Stakeholder ausgerichtet werden 10

11 Vier bewährte Sichtarten nach isaqb Bildquelle: Basiswissen für Software-Architekten, dpunkt 11

12 Wechselwirkungen Entwurf einer Sicht einer bestimmten Art hat starke Wechselbeziehungen mit Sichten anderer Sichtarten Iterativer Entwicklungsprozess für die Software-Architektur Aktualisiert nach jeder Änderung alle abhängigen Sichten Spezielle Wechselwirkungen sollten dokumentiert werden Entwurfsentscheidungen werden nachvollziehbar (tracability) Auswirkungen von Änderungen werden leichter erkennbar (impact analysis) Zusammenhänge zwischen Systemteilen werden leichter verständlich 12

13 Sollte ich so Architekturen visualisieren? Bildquelle: 13

14 Beispielsystem Kassensystem CoCoME Bildquelle: Basiswissen für Software-Architekten, dpunkt 14

15 Beispiel: Kontextabgrenzung Bildquelle: Basiswissen für Software-Architekten, dpunkt 15

16 Beispiel: Bausteinsicht Bildquelle: Basiswissen für Software-Architekten, dpunkt 16

17 Hierarchische Verfeinerung Schrittweise Verfeinerung des Systems Blackboxes Zeigen externe Schnittstellen Beschreiben Funktionalität nach dem Geheimnisprinzip Whiteboxes information hiding Zeigen innere Struktur, Abhängigkeiten und Arbeitsweisen Die inneren Bausteine sind wiederum Blackboxes Bildquelle: Basiswissen für Software-Architekten, dpunkt 17

18 Beschreibung von Blackboxes Überschrift Zweck / Verantwortlichkeit Ein- und Ausgabeschnittstelle(n) Erfüllte Anforderungen Variabilität Leistungsmerkmale Ablageort / Datei Sonstige Verwaltungsinformation Offene Punkte Inhalt Um welchen (Blackbox-)Baustein geht es? Was ist seine Verantwortlichkeit in knappen Worten Was liefert der Baustein anderen? Semantik: call-return, synchron-asynchron, push/pull, events Verweise auf die Anforderungen Veränderungen oder Flexibilität die der Baustein haben soll/kann Qualities-of-Service (QoS) Wo befindet sich der Source-Code zu diesem Baustein? Autor, Version, Datum, Änderungshistorie Alles was noch geklärt werden muss 18

19 Blackbox-Sicht einer Komponente Bereitgestellte Schnittstelle Betrieb überwachen empfangen Management Port abholen versenden Genutzte Schnittstelle 19

20 Beschreibung von Whitebox-Sichten Überschrift Inhalt Übersichtsdiagramm Ein Diagramm, das die innere Struktur dieser Whitebox zeigt. Lokale Bausteine Tabelle oder Liste der lokalen Blackbox-Bausteine. Deren interne Struktur kann in einer weiteren Verfeinerungsebene dargestellt werden. Lokale Beziehungen Tabelle oder Liste der Abhängigkeiten und Beziehungen zwischen den lokalen Bausteinen Entwurfsentscheidungen Gründe, die zu dieser Struktur geführt haben oder zur Ablehnung von Alternativen. Auswirkungen dieser Entscheidungen. 20

21 Notation der Laufzeitsicht Kommunikationsdiagramm Bildquelle: Basiswissen für Software-Architekten, dpunkt 21

22 Beispiel Sequenz-Laufzeitsicht Sequenzdiagramm InputProcess Controller VSAM DataReader Migration Database Import Fehlerpool Akteur Start() [while not EOF] getnextrecord() convert EBCDIC/ASCII() getpaketnr() Konvertierbarkeit des aktuellen Records ermitteln und merken [if{isconvertable()&isvalidpaketnr()}] insert() [if{!isconvertable()}] insert() LEGENDE: UML 22

23 Beispiel: Verteilungssicht 23

24 Querschnittskonzepte und Themen Persistenz Benutzeroberfläche & Ergonomie Fehlerbehandlung Sicherheit Ablaufsteuerung Geschäftsregeln Verteilung Integration mit externen Systemen Internationalisierung 24

25 Agenda Motivation Sichten auf die Software-Architektur Software-Architekturdokumentation Frameworks und Werkzeuge für Dokumentation

26 Grobe Beispielschablone zur Architekturdokumentation angelehnt an 1. Kurzbeschreibung Worum geht es? 2. Diagramme Grafische Darstellungen der Sichten 3. Elementkatalog Elementkatalog mit textueller oder tabellarische Aufstellung der Elemente oder Bausteine pro Sicht, z.b.: Elemente und ihre Eigenschaften; Beziehungen; Schnittstellen u.a.m. 4. Variabilitäten: Variabilitäten in Anforderungen, Architektur, Design, beteiligten Fremdsystemen oder Infrastruktur. 5. Hintergrundinformationen Begründungen, Ergebnisse von Analysen oder Voruntersuchungen, Annahmen, Bezüge u.ä. 26

27 Schnittstellenbeschreibung Identifikation Bezeichnung und Version Bereitgestellte Ressourcen Syntax, Semantik, Auswirkungen beim Aufruf Fehlerszenarien Fehlersituationen und deren Behandlung Variabilität und Konfigurierbarkeit Verhalten veränder- oder konfigurierbar (Parameter)? Qualitätseigenschaften Aussagen über Qualitätsmerkmale Entwurfsentscheidungen Hinweise Fragen, Einflüsse, Annahmen, Alternativen, Begründungen Hinweise oder Beispiele zur Benutzung 27

28 Übliche Dokumenttypen Zentrale Architekturbeschreibung Architekturüberblick Dokumentübersicht Übersichtspräsentation Architekturtapete Handbuch zur Dokumentation Technische Informationen 28

29 Regeln für Dokumentation Aus der Sicht des Lesers schreiben Unnötige Wiederholung vermeiden Mehrdeutigkeit vermeiden Eine standardisierte Organisationstruktur einsetzen Begründungen schriftlich festhalten Regelmäßig Aktualisierungen durchführen Überprüfung auf Gebrauchstauglichkeit 29

30 Agenda Motivation Sichten auf die Software-Architektur Software-Architekturdokumentation Frameworks und Werkzeuge für Dokumentation

31 TOGAF The Open Group Architecture Framework (TOGAF) H Architecture Change Management A Architecture vision B Business Architecture Entwickelt von der Open Group Architecture Development Method (ADM) G Implementation Governance Requirements C Information System Architectures Definiert acht Phasen F Migration Planning D Technology Architecture E Opportunities and Solutions 31

32 RM-ODP Reference Model of Open Distributed Processing Unternehmenssicht ISO-Norm seit 1996 Metamodell zur Beschreibung von Informationssystemen Technologiesicht System Informationssicht Zugeschnitten auf objektbasierte Systeme Konstruktionssicht Systemsicht 32

33 Referenzen Basiswissen für Software-Architekten M. Gharbi, A. Koschel, A. Rausch, G. Starke Documenting Software Architectures Clements et al. Handbuch der Software-Architektur Ralf Reussner, Wilhelm Hasselbring TOGAF RM-ODP

34 Fragen? Fragen! Mahbouba Gharbi Geschäftsführerin ITech Progress GmbH Arne Koschel Prof. für Verteilte Systeme (& freier Berater) HS Hannover, Fakultät IV, Abt. Informatik f4.hs-hannover.de, akoschel acm.org