A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und Modellierung von Softwaresystemen
0. Gliederung 1. Einleitung 2. ADL Classification & Comparison Framework 1. Was ist keine ADL? - Statecharts 2. Vergleich der Komponenten 3. Vergleich der Konnektoren 4. Vergleich der Konfigurationen 3. Fazit 2/30
1. Einleitung Softwarearchitektur Jede Software besitzt eine Softwarearchitektur Softwarearchitektur beschreibt die grundlegenden Elemente und die Struktur eines Softwaresystems Softwareeigenschaften, wie Modifizierbarkeit, Wartbarkeit, Sicherheit oder Performance sind von der Architektur abhängig Deshalb: kritischer und wichtiger Punkt im Software- Entwicklungsprozess 3/30
1. Einleitung Definition: Softwarearchitektur Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. (M. Shaw, D. Garlan. Software Architecture: Perspectives on an Emerging Discipline.) 4/30
1. Einleitung Softwarearchitektur im Entwicklungsprozess Systemdesign Architektur Programmierung Modultest Anforderungsanalyse Integrations- System-Test Auslieferung, Wartung frühe Phasen späte Phasen 5/30
1. Einleitung Architekturbeschreibungssprachen (ADLs) beschreiben die Softwarearchitektur hohes Abstraktionsniveau keine Implementierungsdetails Ziel: Verständlichkeit und High-Level Analysen Es existiert große Anzahl unterschiedlicher ADLs Forschungsgemeinschaft ist sich uneinig, was Gegenstand einer Softwarearchitektur ist 6/30
1. Einleitung Elementare Bestandteile von ADLs Komponenten sind physische, austauschbare Teile eines Systems, die über Schnittstellen mit ihrer Umgebung interagieren. (Klassenbibliotheken, Datenspeicher und Binärprogramme) Konnektoren modellieren die Interaktion zwischen Komponenten und bieten Möglichkeiten die Interaktion zu regulieren. Konfigurationen (Topologien) sind verbundene Graphen aus Komponenten und Konnektoren, die die Struktur der Architektur beschreiben 7/30
1. Einleitung Unterschiedliche ADLs (1/3) ACME stellt den kleinsten gemeinsamen Nenner aktueller ADLs dar und wurde entwickelt um ein Austausch-Format zur Verfügung zu stellen. Mit AcmeStudio existiert eine grafische Benutzeroberfläche. Komponente client rpc server Konnektor System 8/30
1. Einleitung Unterschiedliche ADLs (2/3) Darwin beschreibt reguläre Strukturen von Parallelprogrammen, in degenerierter Form ist auch die Beschreibung von Netzwerk- Topologien möglich. Komponenten verbergen ihr Verhalten hinter hinter wohldefinierten Schnittstellen. Rapide ist eine Simulationssprache, um Softwarearchitekturen zu definieren und ihr dynamisches Verhalten zu simulieren. Das Ergebnis der Simulation ist ein Ablaufplan. 9/30
1. Einleitung Unterschiedliche ADLs (3/3) SADL (Structural ADL) wird eingesetzt um Softwarearchitektur- Hierarchien zu spezifizieren. Sowohl Struktur als auch Semantik der Architektur wird beschrieben. Es sind explizite Abbildungen zwischen unterschiedlichen Abstraktionsebenen möglich. Wright ist eine sehr formale Sprache. Dies ermöglicht Tests auf Deadlock-Freiheit auf verschiedenen Ebenen. 10/30
2. ADL Classification & Comparison Framework ADL Architecture Modeling Features Components (Interface, Types, Semantics, Constraints, Evolution, Non-functional properties) Connectors (Interface, Types, Semantics, Constraints, Evolution, Non-functional properties) Architectural Configurations (Understandability, Compositionality, Refinement, Heterogeneity, Scalability, Evolution, Dynamism, Constraints, Non-functional properties) Tool Support (Active Specification, Multiple Views, Analysis, Refinement, Implementation, Dynamism) 11/30
2.1 Was ist keine ADL? Statecharts basieren auf endlichen Automaten Um Statecharts mit ADLs zu vergleichen, betrachten wir: states = Komponenten transitions = Konnektoren interconnections = Konfiguration Statecharts modellieren Konfigurationen nicht explizit d.h. eine Statechart Architektur kann nur durch Betrachten der einzelnen Komponenten bestimmt werden. Es ist nicht möglich die Details der Komponenten und Konnektoren zu abstrahieren 12/30
2.2 Vergleich Komponenten - Interfaces Interfaces Menge von Schnittstellen zw. Komponenten und deren Umwelt Spezifizieren die Dienste einer Komponente Umsetzung Alle ADLs unterstützen die Spezifizierung von Komponenten Interfaces Bezeichnung variiert (interface point SADL, port Wright, ) ADLs unterscheiden zwischen Schnittstellen die Dienste anbieten und Dienste erfordern. MetaH & Rapide unterscheiden zusätzlich synchrone und asynchrone Interfaces 13/30
2.2 Vergleich Komponenten - Types Types Komponenten Typen sind Abstraktionen, die Funktionalität in wieder verwendbare Blöcke kapseln OO Prinzip: Klasse und Instanz unterstützt die Verständlichkeit und Analysierbarkeit Umsetzung Bis auf MetaH und UniCon unterstützen alle ADLs erweiterbare Komponenten Typen MetaH und UniCon unterstützen nur vordefinierte Typen ACME, Darwin, Rapide, SADL und Wright können Interfacetypen parametrisiert werden 14/30
2.2 Vergleich Komponenten - Semantics Semantics Modell des Verhaltens der Komponente, das die Funktionalität auf der Anwendungsebene beschreibt Benötigt für Analysen und um architektonische Beschränkungen sicherzustellen Umsetzung Alle ADLs unterstützen die Definition von Komponenten Verhalten zu unterschiedlichen Graden UniCon: semantische Informationen in Listen (property lists) Rapide: dynamisches Komponenten Verhalten type Application is interface extern action Request(p : params); public action Results(p : params); behavior (?M in String) Receive(?M) => Results(?M); end Application; 15/30
2.2 Vergleich Komponenten - Constraints Constraints Beschränkung als Eigenschaft der Komponente Verletzung führt zu fehlerhaften bzw. unerwünschtem Verhalten der Komponente Umsetzung Alle ADLs ermöglichen die Beschränkung der Benutzbarkeit von Komponenten über deren Interfaces (Typen) Bei einigen ADLs kann über die Semantik der Komponente Beziehungen und Abhängigkeiten innerhalb der Komponente spezifiziert werden. (C2, Darwin, Rapide, UniCon, ) 16/30
2.2 Vergleich Komponenten - Evolution Evolution Komponenten als architektonische Einheiten entwickeln sich stetig, z.b. durch Modifikation von Interfaces, Verhalten oder der Implementierung Durch den Einsatz von Subtypen können ADLs die Entwicklung von Komponenten systematisieren Umsetzung MetaH, Darwin, Weaves & UniCon unterstützen keine Subtypen Rapide erstellt Komponenten über OO-Vererbung SADL erlaubt die Definition von Eigenschaften, die Subtypen erfüllen müssen 17/30
2.2 Vergleich Komponenten Non-Functional Properties Non-Functional Properties Sicherheit, Performanz, Erweiterbarkeit, nicht direkt vom Verhalten ableitbar Aber: Spezifizieren der Eigenschaften wird benötigt für Simulationen und Analysen Umsetzung sehr dürftig umgesetzt Aesop, ACME & Weaves erlauben die Spezifikation von einigen Komponenten Eigenschaften machen aber keinen Gebrauch davon UniCon & MetaH unterstützen nicht funktionale Eigenschaften etwas mehr 18/30
Halbzeit Es ist Halbzeit! 19/30
2.3 Vergleich Konnektoren - Interfaces Interfaces Menge von Schnittstellen zwischen den Konnektoren und den Komponenten Interfaces stellen sicher, dass Komponenten richtig angebunden sind und interagieren können Umsetzung Nur ADLs die Konnektoren als First-Class Entities modellieren, erlauben die Spezifikation von Interfaces unterschiedliche Bezeichnungen: roles (ACME, Aesop, UniCon, Weaves), port (C2) C2 und Weaves Konnektoren sind generisch 20/30
2.3 Vergleich Konnektoren Types Types Konnektoren Typen sind Abstraktionen, die die Kommunikation, Koordination und Interaktion der Komponenten kapseln Damit Konnektoren wieder verwendbar sind, müssen ADLs diese als Typen modellieren Umsetzung Nur ADLs die Konnektoren als First-Class Entities modellieren, unterscheiden zwischen Typen und Instanzen Konnektoren in ACME, Aesop, C2, SADL und Wright basieren auf Interaktions-Protokollen UniCon hat einige vordefinierte Typen von Konnektoren 21/30
2.3 Vergleich Konnektoren Semantics Semantics Semantik ist definiert als Modell des Konnektoren Verhaltens, das Interaktionsabläufe beschreibt (Protokolle) ADLs die Semantik spezifizieren, ermöglichen Interaktions Analysen Umsetzung Einige ADLs benutzen für Konnektoren und Komponenten den gleichen Mechanismus um semantische Infos zu spezifizieren (Rapide, Wright und UniCon) SADL, C2 und Weaves benutzen ein anderes Model 22/30
2.4 Vergleich Konfigurationen - Understandability Understandability unterschiedliche Abstraktionsniveaus einfache und verständliche Syntax grafische Darstellung der Architektur, die auch genügend Eigenschaften der textuellen Form enthält Umsetzung ADLs mit expliziter Konfiguration sind tendenziell leichter verständlich als die mit in-line Konfiguration. C2, Darwin und UniCon haben eine gute, grafische Darstellung SADL und Wright nicht 23/30
2.4 Vergleich Konfigurationen - Compositionality Compositionality Können Subsysteme, die aus Komponenten und Konnektoren bestehen, zusammengefasst werden und auf höheren Hierarchieebenen eingesetzt werden? Umsetzung Wird von allen ADLs unterstützt Bsp: (Darwin) Komponente Composite besteht aus den beiden Komponenten C1 und C2, die wiederum zusammengesetzt sein können 24/30
2.4 Vergleich Konfigurationen - Heterogeneity Heterogeneity ADLs sollen die Entwicklung von großen Systemen vereinfachen, die aus unterschiedlichen Komponenten und Konnektoren bestehen können ADLs müssen offen sein und Möglichkeiten bieten mit heterogenen Infrastrukturen umzugehen Umsetzung keine ADL unterstützt mehrere formale Spezifikationssprachen ADLs die Architekturen implementieren können sind meist auch auf die Wirts Sprache beschränkt Ausnahmen: C2 und Weaves 25/30
2.4 Vergleich Konfigurationen - Scalability Scalability ADLs müssen die Vergrößerung des Systems unterstützen (am Rand oder im Inneren) Erweiterbarkeit Unterstützung von Änderungen im Entwicklungsverlauf der Architektur Umgang mit unvollständigen Architekturbeschreibung 26/30
2.4 Vergleich Konfigurationen Dynamism Dynamism Möglichkeit laufenden Systeme zu modifizieren Konfigurationen sind dynamisch, wenn sie das Einfügen, Entfernen und Umstrukturieren von einzelnen Elementen bis hin zu ganzen Architekturen erlauben Umsetzung Bis auf C2, Darwin, Rapide und Weaves betrachten ADLs Konfigurationen als statisch C2 stellt Operationen bereit, die zur Laufzeit das Einfügen, Entfernen und neu Verbinden ermöglichen 27/30
2.4 Vergleich Konfigurationen Constraints Constraints Werden auf drei Ebenen eingesetzt: Komponenten, Konnektoren und Konfigurationen Spezifizieren Anforderungen an das System Wichtig für die Analyse Non-Functional Properties Anforderungen an das System werden damit in die Architektur eingefügt Eigenschaften werden benötigt um Analysen durchzuführen und Constraints einzuhalten. 28/30
3. Fazit Medvidovic und Tayler haben erstmals für bestehende ADLs eine Definitions- und Klassifikations-Framework geliefert Es wurde gezeigt, wie mit Hilfe des Frameworks, bestimmt werden kann, was eine ADL ist. Der Vergleich offenbarte Stärken von existierende ADLs: starke formale Notationen, Architektur Visualisierung und Analyse aber auch Schwächen: mangelnde Spezifikationsmöglichkeiten für nicht-funktionale Eigenschaften 29/30
4. Ende Vielen Dank! Fragen? 30/30