Dokumentation von Software Architekturen unter Berücksichtigung von IEEE 1471 Vortrag an der FH Regensburg © Dr. Ulrich Margull, 2004 Dr. Ulrich Margull

Übersicht Einführung IEEE 1471: Recommended Practice for Architectural Description of Software-Intensive Systems Beispiel: Architekturbeschreibungen bei Echtzeitsystemen (Automotive Bereich) Zusammenfassung Bibliographie

Was ist Software Architektur? Eine mögliche Definition ist: – Design im großen Maßstab, ohne Details – Das Big Picture eines Software-Systems – Viele weitere Definitionen unter Eine Architekturbeschreibung (AB) ist eine Sammlung von Produkten, die eine Architektur beschreiben Die grundlegende Organisation eines Systems aus seinen Teilen, deren Beziehungen untereinander sowie zur Umgebung und die Entwurfs- und Entwicklungsprinzipien (aus [1],[3]-[5])

Sichten (Views) Eine Architekturbeschreibung enthält verschiedene Sichten (Views) auf ein System Jede Sicht beschreibt einen Aspekt des Systems Jede Sicht entspricht einer bestimmten Sichtweise – Eine Sicht ist eine konkrete Beschreibung eines Aspektes von einem bestimmten System (Beispiel: Dekomposition von Microsoft Word) – Eine Sichtweise ist ein Blickwinkel, unter dem die Architektur eines beliebigen Systems betrachtet werden kann (z.B. in Form eines UML Klassendiagrams) Beispiel: Wolkenkratzer

Software Beispiel: 4+1 Sichten (nach Kruchten, [3]) Logische Sichtweise: Struktur, Behavior – Klassen, (logische) Komponenten, Packages, Module, usw. Prozesse – Prozesse, Threads, Synchronisierungen, usw. Entwicklung (Implementation bzw. Development View) – Entwicklungsprozess, Abbildung der logischen Elemente auf ausführbare Einheiten Verteilung (Deployment bzw. Physical View) – Verteilung der (ausführbare) Komponenten auf Rechnerknoten,usw. Anwendungsfälle (Use Cases)

Übersicht Einführung IEEE 1471: Recommended Practice for Architectural Description of Software-Intensive Systems – Empfohlene Praxis für Architekturbeschreibungen von Software-intensiven Systemen Beispiel: Architekturbeschreibungen bei Echtzeitsystemen (automotive Bereich) Zusammenfassung Bibliographie

IEEE 1471 Recommended Practice ist eine bestimmte Art von IEEE Standard 1471 gilt für Architekturbeschreibungen – Ist keine Standard-Architektur, kein Architektur- Prozess oder –Methode – Definiert einen kontextueller Rahmen Folie – Gibt Richtlinien vor, die von 1471-konformen ABs eingehalten werden müssen

Anforderungen IEEE 1471 Eine konforme muss Architekturbeschreibung alle Interessengruppen (Stakeholders) enthalten – Interessengruppen können sein: Sichtweisen befriedigen die Anliegen von Interessengruppen – Eine Sichtweise, die niemand interessiert, ist überflüssig und sollte weggelassen werden Kunde / Käufer Benutzer Operator Software Architekt Software Projekt Leiter Software Entwickler Designer Integrator Wartungspersonal... und viele andere

Sichten Verschiedene Sichten (Views) sind möglich – Eine Architekturbeschreibung besteht aus ein oder mehreren Sichten – Eine Sicht ist eine Darstellung des Gesamtsystems aus einem bestimmten Blickwinkel Sichten können modular aufgebaut sein Konsistenz alle Sichten – Eine AB muss alle Inkonsistenzen zwischen Sichten nachweisen

Was nützt IEEE 1471 ? GUT: formaler&kontextueller Rahmen für ABs – Übersicht – Interessengruppen & Anliegen – Verwendete Sichtweisen & deren Motivation – Die eigentlichen Sichten auf die Software – Eventuelle Inkonsistenzen zwischen den Sichten – Grundprinzipien der Architektur ABER: 1471 enthält keine Sichtweisen – Es müssen geeignete Sichtweisen ausgewählt & definiert werden

Übersicht Einführung IEEE 1471: Recommended Practice for Architectural Description of Software-Intensive Systems Beispiel: Architekturbeschreibungen bei Echtzeitsystemen (automotive Bereich) Zusammenfassung Bibliographie

Domäne Weiche Echtzeitanforderungen – Teilweise jedoch sicherheitsrelevant Strukturierte Programmierung in C / Assembler Formaler Prozess nach Wasserfall Modell – Mehrere V-Zyklen zur Validierung und Verifikation Produktlinien – Wiederverwendbare Module

Prinzipien IEEE 1471 konform Definition von Sichtweisen im Architecture Documentation Handbook – Dort werden Interessengruppen und ihre Anliegen beschrieben Verwendung von UML zur visuellen Beschreibung – Use Cases (eingeschränkt) – Class Diagrams, Module als Packages – State Charts, Sequence Diagrams – Component Diagrams,

Vorlage zur Architekturbeschreibung Einführung, Bibliographie, Abkürzungen Context: Umgebung des Systems Logische Sicht: Struktur, Verhalten – Dekomposition, Layered Structure, Schnittstellen – Globale Zustandsdiagramme Task & Interrupt View: – Aufteilung der Module auf Tasks und Interrupts – Scheduling, Synchronisierung, Initialisierung, etc. Deployment: Verteilung der Software auf Knoten Development: Entwicklungsprozesse Size & Performance

Zusammenfassung Eine Architekturbeschreibung besteht aus ein oder mehreren Sichten (Views) Jede Sicht entspricht einer bestimmten Sichtweise (Viewpoint) IEEE 1471 stellt Anforderungen an eine Architekturbeschreibung: – Definition der Sichtweisen – Beschreibung der Interessengruppen und deren Anliegen – Sichtweisen müssen dadurch motiviert sein Sichtweisen müssen selbst definiert werden Wichtige Sichten sind z.B. die 4+1 Sichten (Kruchten)

Bibliographie [1]IEEE Standard 1471, verabschiedet in 2000; siehe dazu Vortrag von Chairman Rich Hilliard, architecture.info/Images/Documents/, Datei IEEE Beyond.pdfwww.enterprise- architecture.info/Images/Documents/ [2]Architectural Blueprints – The 4+1 View Model of Software Architecture, Philippe Kruchten, IEEE Software 12 (6), 1995 [3]Software Architecture in Practice, Bass L, et.al, Addison- Wesley, 1998 [4]Documenting Software Architectures: Views and Beyond, Paul Clement et.al., Addison-Wesley, 1st edition, 2002 [5]Software Engineering, Ian Sommerville, Addison-Wesley, 6th edition, 2000; deutsch bei Pearson Studium, 2001;