(architektur: = anfang, ursprung + = haus, dach) · 2008-11-10 · vorlesungwintersemester2008 /...
Post on 01-Jun-2020
3 Views
Preview:
TRANSCRIPT
Vorlesung Wintersemester 2008 / 2009
Technische Universität MünchenInstitut für InformatikLehrstuhl von Prof. Dr. Manfred Broy
Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling
Softwarearchitektur(Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach)
4. Sichten bei der Softwarearchitektur – Teil 1
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.2
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.3
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.4
Warum Sichten?
� Komplexe Systeme lassen sich nicht übersichtlich mit einer einzigen Beschreibung erfassen.
� Unterschiedliche Rollen im Bezug auf das System arbeiten mit unterschiedlichen Informationen.
� Nötig sind geeignete Architekturbeschreibungen als
� Kommunikations- und Diskussionsplattform
� Plan für Entwurf und Implementierung
für unterschiedliche Zielgruppen und Aufgaben.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.5
Was sind Sichten?
� Ein System wird aus mehreren Blickwinkeln betrachtet, die jeweils unterschiedliche Schwerpunkte haben.
aus [AC98]
� Je nach Blickwinkel treten bestimmte Eigenschaften in den Vordergrund, andere werden nur grob oder gar nicht dargestellt.
� Eine Beschreibung für einen definierten Blickwinkel heißt Sicht.
� IEEE STD 1471-2000: A view is a representation of a whole system from the perspective of a relatedset of concerns.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.6
Beispiel: Baupläne
� Bei einem Gebäude sind viele unterschiedliche Sichten zu berücksichtigen:� Grundriss
� Aufrisse
� Traglasten
� Elektroinstallationsplan
� Installationsplan
� Fluchtwegeplan
� etc.
� Jede ist für bestimmte Aufgaben und Rollen zugeschnitten.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.7
Eigenschaften von Sichten
� Eine Sicht stellt jeweils bestimmte Eigenschaften eines Systems dar.
� Sichten sind typischerweise nicht völlig unabhängig voneinander – bestimmte Informationen aus einer Sicht können sich in anderen Sichten wiederfinden.
� Widersprechen sich zwei Sichten nicht (und beschreiben damit ein mögliches System), so heißen sie konsistent miteinander.
� Für die einzelnen Sichten können jeweils geeignete Beschreibungstechniken verwendet werden.
� Eine Beschreibungstechnik kann aber auch für unterschiedliche Sichten verwendet werden.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.9
Arten von Sichten auf die Architektur eines Systems
� Wir unterscheiden in der Folge folgende Sichten:
� Spezifikationssichten� Fachliche Sicht
� Technische Sicht
� Verteilungssicht
� Erstellungssichten� Entwicklungssicht
� Testsicht
� Bereitstellungssicht
Thema der heutigen Doppelstunde
Thema der nächsten Doppelstunde
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.10
Fachliche Sicht - Überblick
� Zweck� Darstellung der Konzepte des Anwendungsgebiets möglichst
unabhängig von einer softwaretechnischen oder plattform-spezifischen Lösung
� Inhalte� Fachliche Komponenten inklusive Schnittstellen und Verhalten
� Beziehungen zwischen fachlichen Komponenten
� Systemgrenze und Anbindung existierender fachlicher Komponenten
� Beschreibung� Überblick möglich durch CRC-Karten, Box-and-Line-Diagramme
� objektorientierte Modellierungstechniken (UML + Erweiterungen)
� in Spezialfällen formale Techniken (OCL, ADLs, DSLs etc.)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.11
Technische Sicht - Überblick
� Zweck� Darstellung der softwaretechnischen Lösung für das System
inklusive der Umsetzung der fachlichen Sicht
� Inhalte� Technische Komponenten des Systems und deren Schnittstellen� Beziehungen zwischen den Komponenten, inklusive der
Abbildung der fachlichen Komponenten in die technische Sicht� Beziehung zu Basissoftware und Abbildung auf die Hardware
� Beschreibung� Überblick möglich durch Box-and-Line-Diagramme� objektorientierte Modellierungstechniken (UML + Erweiterungen)� Interface Definition Languages (IDLs)� Quellcode-Fragmente für Details von Mechanismen� in Spezialfällen formale Techniken (OCL, ADLs, DSLs etc.)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.12
Wiederverwendung
Fachliche und Technische Sicht
top-down
botto
m-up
fachlich technisch
Applikationsserver,Datenbanken,
Transaktionsmonitore
existierende Komponenten &
Systeme
fachlicheAnforderungen
Systemarchitektur, Hardware
Architekturanalyse
File
- FileName : String
P
- X : int
- Y : int
Fo
- Name : String
- Style : int- Size : int
D i
- Height : int
- Width : int
Line
+$ STRAIGHT : LineStyle
+$ SNAPPED : LineStyle+$ SLANTED : LineStyle
+$ LOOP : LineStyle
<<Enum>>
Automa
+$ IMPLEMENTATION : AutomatonKind
+$ CLASSSPEC : AutomatonKind+$ TYPESPEC : AutomatonKind
<<Enum>>
Dire
+$ IN : Dir ection
+$ OUT : Direction
<<Enum>>
Tran
- Name : String
- Input : String
- Output : String- PreCondition : String
- PostCondition : String
- Action : String
- IsOuter : boolean
- ControlPointOne : Point
- ControlPointTwo : Point
Par
- Name : String
Rep
S
Inte
- Name : String
- Condition : String
- Direction : int
- Location : Point
*
1
+OutSegment
*
+SourcePoint1
*
1
+InSegment
*
+DestinationPoint1
Com
- Name : String
- OEFStream : String
- OEFAnnotation : String
*
1
*
1
Re
- Name : String
1 11 1
Proj
Chan
- Name : String
- Type : String
- DisplayFont : Font
- DrawType : int
- TextBoxSize : Dimension- TextBoxLocation : Point
Stat
- Name : String
- Predicate : Str ing
- EntryAction : String
- ExitAction : String
- IsHistory : boolean- IsInitial : boolean
- Location : Point
- Size : Dimension
- Border : int0..1* 0..1*
1
*
1
*
Proj
- Name : String
- OEFStream : String
*
1
*
1
1
*
1
*
0..1
*
+SuperProject
0..1
+SubProject
*
1 11 1
S
Attr
- Name : String
- Type : String
Port
- Name : String
- D irection : Direction = -1
- Type : String- Location : Point
# DisplayFont : Font
- ShowName : boolean
0..1
1
+OutChannel
0..1
+SourcePort
1
0..1
1
+InChannel
0..1
+DestinationPort
1
Co
- Name : String
1
*
1
*
Auto
- Name : String- Kind : int
- ClassName : String
0..1
*
0..1
*
1
*
1
*
Com
- Name : String
- Location : Point- Size : Dimension
- Border : int
- DisplayFont : Font
- TextBoxLocation : Point
- TextBoxSize : Dimension0..1 *0..1 *
1
*
+SuperComponent
1
+SubComponent
*
1
*
1
*
1
*
1
*
0..1
1
0..1
1
0..1
0..1
0..1
0..1
Te
- Line : String11..*11..*FachlicheSicht
File
- FileName : String
P
- X : int- Y : int
Fo
- Name : Str ing- Style : int
- Size : int
Di
- Height : int
- Width : int
Line
+$ STRAIGHT : LineStyle
+$ SNAPPED : LineStyle+$ SLANTED : LineStyle
+$ LOOP : LineStyle
<<Enum>>
Automa
+$ IMPLEMENTATION : AutomatonKind+$ CLASSSPEC : AutomatonKind+$ TYPESPEC : AutomatonKind
<<Enum>>
Dire
+$ IN : Direction+$ OUT : Direction
<<Enum>>
Tran
- Name : String- Input : String
- Output : Str ing- PreCondition : String
- PostCondition : Str ing- Action : Str ing- IsOuter : boolean
- ControlPointOne : Point- ControlPointTwo : Point
Par
- Name : Str ing
Rep
S
Inte
- Name : Str ing- Condition : String- Direction : int
- Location : Point
*
1
+OutSegment*
+SourcePoint1
*
1
+InSegment
*
+DestinationPoint1
Com
- Name : String- OEFStream : String
- OEFAnnotation : Str ing
*
1
*
1
Re
- Name : String
1 11 1
Proj
Chan
- Name : String- Type : String- DisplayFont : Font
- DrawType : int- TextBoxSize : Dimension
- TextBoxLocation : Point
Stat
- Name : String- Predicate : String
- EntryAction : String- ExitAction : String
- IsHistory : boolean- IsInitial : boolean- Location : Point
- Size : Dimension- Border : int
0..1* 0..1*
1
*
1
*
Proj
- Name : String
- OEFStream : String
*
1
*
1
1
*
1
*
0..1
*
+SuperProject
0..1
+SubProject
*
1 11 1
S
Attr
- Name : String- Type : Str ing
Por t
- Name : String- Direction : Direction = -1
- Type : Str ing- Location : Point
# DisplayFont : Font- ShowName : boolean
0..1
1
+OutChannel
0..1
+SourcePort
1
0..1
1
+InChannel
0..1
+DestinationPor t
1
Co
- Name : String
1
*
1
*
Auto
- Name : String
- Kind : int- ClassName : Str ing
0..1
*
0..1
*
1
*
1
*
Com
- Name : String- Location : Point
- Size : Dimension- Border : int
- DisplayFont : Font- TextBoxLocation : Point- TextBoxSize : Dimension 0..1 *0..1 *
1
*
+SuperComponent
1
+SubComponent
*
1
*
1
*
1
*
1
*
0..1
1
0..1
1
0..1
0..1
0..1
0..1
Te
- Line : String11..*11..*Technische Sicht
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.13
Trennung von fachlicher und technischer Sicht: Vorteile
� Entwurf, Realisierung und Validierung der Fachlichkeit werden vereinfacht� technische Details müssen nicht betrachtet werden� wesentliche Reduzierung der Komplexität� Einbeziehung der Anwender wird möglich
� Möglichkeit, die fachliche Sicht auf unterschiedliche technische Architekturen abzubilden� fachliches Verhalten bleibt bei allen Realisierungen gleich� Evolution und Optimierungen der technischen Architektur
unabhängig von der Fachlichkeit möglich� langlebige, wertvolle Geschäftslogik kann unabhängig von
speziellen Techniken leben und weiterentwickelt werden� Integration unterschiedlicher Systeme vereinfacht
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.14
MDA – Model-Driven Architecture
� Ansatz der Object Management Group (OMG) zur Modellierung bei der Software-Entwicklung
� Unterscheidet drei aufeinander aufbauende Sichten� Computation-Independent Model (CIM) = Analysemodell
- Anforderungen und Umgebung eines Systems- Abstrahiert von Struktur und Informationsverarbeitung
� Platform-Independent Model (PIM) = Fachliche Architektur- Spezifiziert Struktur und Informationsverarbeitung- Enthält nur die Anteile, die für alle Plattformen gleich sind
� Platform-Dependent Model (PSM) = Technische Architektur- Spezifiziert konkrete Mechanismen für spezielle Plattform
� Entwicklung erfolgt mittels Modelltransformationen� Teile von MDA sind standardisiert: MOF, XMI, UML, QVT
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.15
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.16
Fragestellungen in der fachlichen Sicht
1. Wie wird die fachliche Funktionalität repräsentiert?� Welche Operationen gibt es und wo hängen sie?
� Wie sind die fachlichen Abläufe?
2. Wie sind die Schnittstellen der fachlichen Komponenten?� Welche Operationen sind nach außen zugänglich?
3. Wie lassen sich fachliche Komponenten bilden?� Wann werden Komponenten gebildet?
� Wie erfolgen Zugriff auf und Verwaltung von Komponenten?
� Welche Beziehungen haben die Komponenten untereinander?
� Wie lassen sich Komponenten voneinander entkoppeln?
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.17
Vom Analysemodell zum fachlichen Entwurf
� Die genannten Fragestellungen werden in einem iterativen Prozessbeantwortet:� Start mit erstem fachlichen Analyse-Modell basierend auf den
Anforderungen (meist in Form eines Klassendiagramms mit den Daten des Systems und zusätzlicher Anwendungsfälle und Aktivitäten).
� Schrittweise Verfeinerung des Modells durch- Hinzufügen von Operationen
- Schnittstellenbildung
- Komponentenbildung
� Das entstehende Modell ist plattformunabhängig, zielt aber typischerweise bereits auf einen bestimmten Architekturstil ab.
� Dazu enthält es bereits Konzepte, die seine Abbildung auf die Technik erleichtern.
� OMG-Terminologie: CIM-to-PIM-Mapping.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.18
Anwendungsbeispiel: eSteuer 2008
� Neues Informationssystem „eSteuer 2008“ für die Berechnung neuer Steuern in Finanzämtern
� Steuern� Grundsteuer� Hundesteuer� leicht erweiterbar für beliebige neue Steuerarten� Wegfall von Steuerarten soll grundsätzlich ebenfalls möglich sein
� Funktionalität und Anwendungsfälle von eSteuer 2008� Steuerzahler verwalten� Grundsteuerinformationen verwalten, Grundsteuer berechnen� Hundesteuerinformationen verwalten, Hundesteuer berechnen� Steuerermäßigungen für Wachhunde auf Fremdgrundstücken
beachten!
� Anwender des Systems sind Finanzbeamte
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.19
Ergebnis der Anforderungsanalyse - Funktionalität
� Anwendungsfälle und Ablaufspezifikationen
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.20
Ergebnis der Anforderungsanalyse - Daten
� Fachliches Datenmodell in Form eines UML-Klassendiagramms
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.21
Zuordnung der Funktionalität
� In der fachlichen Sicht wird die Funktionalität in Form von Operationen der modellierten Klassen dargestellt.
� Hier gibt es im Wesentlichen zwei Möglichkeiten:1. Operationen können direkt an den Daten-Objekten (Entity-
Klassen) hängen.
2. Es können eigene Control-Klassen für Operationen gebildet werden.
� Beobachtung: Daten sind meist stabiler als Funktionalität.� Als Strategie ist deshalb sinnvoll, instabile Funktionalität eher
auszulagern und nur stabile Basisfunktionalität bei den Entity-Klassen zu belassen.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.22
Zuordnung der Funktionalität im Beispiel
berechneAnzahlBewachungen
ist eine stabile Operation und wird deshalb der bestehenden Entity-Klasse Hundesteuerzahlerzugeordnet
berechneHundesteuer ist eine instabile Operation (das Berechnungsschema kann sich ändern) und wird deshalb einer neuen Control-Klasse Steuerrechner zugeordnet
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.23
Navigations- und Verwaltungsoperationen
� Neben den Operationen für die Aktionen der Anwen-dungsfälle gibt es auch Operationen, die sich aus der Umsetzung des Klassendiagramms ergeben.
� Zugriff auf die Daten� typischerweise über die Einführung von get- und set-
Operationen für die Attribute� Beispiel: Operationen getGewicht():int und setGewicht(int):void der Klasse Hund
� Verwaltung der Beziehungen zwischen Klassen� typischerweise über die Einführung von Navigations- und
Verwaltungsmethoden� Beispiel: Operationen getHunde():Collection, addHund(Hund):void und removeHund(Hund):voidder Klasse Hundesteuerzahler
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.24
Zugriffs- und Verwaltungsoperationen
� Verwaltung der Instanzen� typischerweise über die Einführung von Verwaltungsklassen� Beispiele: Verwaltungsklasse HundesteuerManager mit
Operationen zum Erzeugen, Löschen und Suchen von Hundesteuerzahlern und Hunden
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.25
Zwischenstand der fachlichen Sicht
Ergebnis: erstes objektorientiertes Entwurfs-Modell, zeigt reine Entwurfskonzepte, keine Implementierungsklassen
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.26
Validierung durch Beispiele
� Für die Operationen im Klassen-diagramm werden nun fachliche Abläufe durchgespielt und beispielhafte Objektstrukturen gebildet.
Klassen zur Modellierung Beispiel-Instanzen zur Validierung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.27
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.28
Schnittstellenbildung
� Zur Vorbereitung der Komponentenbildung werden (möglichst schmale) Schnittstellen definiert und mit geeigneten Beschreibungstechniken beschrieben.
� Die Schnittstellen enthalten nur die Operationen, die später von der Komponente nach außen angeboten werden.
� Gegebenenfalls kann es unterschiedliche Sätze von Schnittstellen geben (z.B. Schnittstellen mit extern zugänglichen Operationen, Schnittstellen mit nur komponentenintern zugänglichen Operationen).
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.29
Bildung fachlicher Komponenten
� Die Bildung übergreifender fachlicher Komponenten erfolgt nach folgenden Gesichtspunkten:� Lose Kopplung – starke Bindung� Wiederverwendbarkeit für andere Systeme� Einfache Austauschbarkeit der Komponente� Konfigurierbarkeit des Systems und der Komponente
� In einem ersten Schritt wird dazu das Klassendiagramm partitioniert.� Person und Rolle stellen Basisfunktionalität für viele
Anwendungen zur Verfügung � eigene Komponente.� Für die unterschiedlichen Steuerarten werden jeweils eigene
Komponenten erstellt, um flexibel auf Änderungen reagieren zu können. Außerdem kann dann jede derartige Komponente von den betreffenden Fachleuten realisiert und getestet werden.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.30
Partitionierung am Beispiel
KomponentePersonen-verwaltung
KomponenteHundesteuerverwaltung
Komponente Grundsteuerverwaltung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.31
Abhängigkeiten zwischen Komponenten definieren
� Der Entwurf der Abhängigkeitsstruktur erfolgt nach folgenden Gesichtspunkten:� Komponenten mit Basisfunktionalität sollten von möglichst
wenig anderen Komponenten abhängig sein. Umgekehrt: Je instabiler eine Komponente ist, desto weniger Komponenten sollten von ihr abhängig sein.- Fehlerfreiheit
- Minimierung des Aufwands bei Änderungen
- Auslieferung unterschiedlicher Systemkonfigurationen
� Zyklen in der Abhängigkeitsstruktur sollten möglichst vermieden werden- leichtere Austauschbarkeit von Komponenten
- Weglassen von Komponenten möglich
- einfachere Abstimmung der Teams während der Entwicklung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.32
Abhängigkeitsstruktur im Anwendungsbeispiel
� Im Beispiel gibt es drei Komponenten:� Personenverwaltung als Basiskomponente
� Grundsteuerverwaltung als relativ stabile Komponente
� Hundesteuerverwaltung als relativ instabile Komponente
� Die Ahängigkeitsstruktur wird im Beispiel wie folgt entworfen:
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.33
Bidirektionale Abhängigkeiten
� Bidirektional navigierbare Assoziationen resultieren normalerweise in zyklischen Abhängigkeiten zwischen den betreffenden Komponenten.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.34
Aufbrechen von bidirektionalen Abhängigkeiten
� Diese Abhängigkeiten lassen sich beispielsweise über die Einführung einer neuen finde-Operation in dem Manager der Komponente aufbrechen.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.35
Kommunikation von Basis- zu abhängigen Komponenten
� Basiskomponenten können abhängige Komponenten nicht über deren eigene Schnittstellen rufen, da sich sonst eine zyklische Abhängigkeit ergäbe.
� Möglich ist jedoch beispielsweise eine Kommunikation über das Observer-Pattern durch Ableiten von der Schnittstelle Rolle.
addRolle entspricht register-Operation
setVermoegen löst update-Aufrufe aus
beim updateerfolgt Zugriff auf geänderte Daten in Person
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.36
Resultierende Komponenten
Mögliche Verbindungsstruktur der Komponenten
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.38
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.39
Fragestellungen in der technischen Sicht
1. Wie wird die technische Funktionalität repräsentiert?� Wie werden die nicht-funktionalen Anforderungen erfüllt?� Welche Komponenten und Schnittstellen gibt es?� Welche Querschnittsmechanismen und Basistechniken gibt es?� Wie arbeiten sie zusammen?
Vorgehen und Beschreibung wie bei Fachlicher SichtBeispiele in später folgenden Vorlesungen
2. Wie ist der Zusammenhang zur fachlichen Sicht?� Was ist die Schnittmenge zwischen den beiden Sichten?� Wie finden sich die fachlichen Konzepte in der technischen
Sicht wieder?� Beispiele in später folgenden Vorlesungen
Möglichkeiten auf den folgenden Folien
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.40
Entkopplung der technischen Funktionalität
� Damit die fachlichen Komponenten arbeiten können, stützen sie sich auf Dienste der technischen Komponenten ab.
� Problem: Bei explizit verwendeten technischen Diensten keine Entkopplung und damit eine enge Bindung von fachlichen und technischen Komponenten!
� Frage: Wie schafft man die Entkopplung?
Fachlichkeit Technik
+
?
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.41
Strategie: Templates für schematische Kopplung
� Programmierrichtlinien oder Templates geben vor, wie die Technik im Programm angesprochen werden kann bzw. muss.
� Probleme� Einhaltung der Richtlinien schwierig zu überwachen
� Templates können Code sehr unübersichtlich machen
� Keine echte Trennung von fachlichem und technischem Code: Wechsel auf neue technische Infrastruktur kann ggf. sehr aufwändig sein
� Beispiel� Methoden-Template zum Tracing von Methoden und zum Überprüfen
von Pre- und Postconditions
Fachliche und technischeTeile gemäß Template
FachlicheAnteile
TechnischeAnteile
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.42
Methodentemplate (Preconditions & Trace Entry) (1)
public void doSomeThing(String arg1, int arg2) {
if (CheckManager.CHECK_PRECONDITION) {
CheckManager.assertPreCondition(this, new
NotNullAssertion(arg1));
CheckManager.assertPreCondition(this,
arg2 > 0, "arg2 <= 0");
}
boolean exceptionThrown = false;
TraceManager.traceCallEntry(this,
new java.lang.Object[] { s });
try {
… fachlicher Code …
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.43
Methodentemplate (Trace Exceptions) (2)
} // try
catch (RuntimeException ex) {
exceptionThrown = true;
TraceManager.traceExceptionThrown(this, ex);
throw ex;
}
catch (Error err) {
exceptionThrown = true;
TraceManager.traceExceptionThrown(this, ex);
throw err;
}
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.44
Methodentemplate (Postconditions & Trace Exit) (3)
finally {
if (!exceptionThrown) {
TraceManager.traceCallExit(this);
if (CheckManager.CHECK_POSTCONDITION) {
CheckManager.assertPostCondition(this, new
NotNullAssertion(arg1));
}
}
}
} // doSomeThing
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.45
� Adapter und Wrapper dienen dazu� komplexe und/oder proprietäre technische Schnittstellen und
Mechanismen vor der fachlichen Sicht zu verstecken und
� stattdessen einfache, möglichst standardisierte Schnittstellen für Anwendungsdienste bereitzustellen.
� Mögliche Probleme:� Technik scheint immer noch durch
� Komponenten sind von Schnittstellen der Adapter/Wrapper abhängig
Strategie: Technik hinter Schnittstellen kapseln
Wrapper
A
B’
C’
D
B
C
Adapter
A
B
C
AA
B’
C’
D
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.46
Interface aus der ODMG-Schnittstelle
Beispiel: Standardschnittstellen für Persistenz
� Der Zugriff auf die Verwaltungsfunktionalität geschieht über einfache, möglichst standardisierte Schnittstellen.
DatenbankOODBMS relationaleRDBMS
OODBMS-Adapter
OODBMS-API JDBC-API
O/R-Mapping Tool
O/R-Mapping-Adapter
O/R-Tool API
ODMG API ODMG API
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.47
� Fachlichkeit wird möglichst ganz ohne Bezug auf technische Basisfunktionalität realisiert (Plain Old Java Objects, POJOs).� Ein Container versorgt die fachlichen Komponenten mit allem, was sie
brauchen und regelt die Technik im Hintergrund.� Der Container benötigt dazu Wissen über die Komponente, das er z.B.
über eine Konfigurationsdatei oder über reflexive Introspektion erhält.
� Mögliche Probleme� Nur möglich, wenn Verwaltung der technischen Funktionalität
konfigurationsgesteuert (ohne Programmierung) möglich ist� Konfigurationsdateien können sehr komplex werden
Strategie: Verantwortung auf Container abwälzen
Konfiguration
Container
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.48
Beispiel: Deklaratives Transaktionsmanagement
� Transaktionssteuerung bei einem Anwendungsserver� Component-Managed Transactions: Die fachliche Komponente erzeugt
Transaktionen und ruft begin, commit und abort auf ihnen auf.� Container-Managed Transactions: Der Application Server
bestimmt, wann eine Transaktion geöffnet und beendet wird.
� Beispiel: Ausschnitt aus Konfigurationsdatei für deklarativeTransaktionsverwaltung im Spring Application Framework<bean id=„trx_hundesteuermanager"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="txManager"/>
<property name="target" ref=„hundesteuermanager"/>
<property name="transactionAttributes"><props>
<prop key="create*">PROPAGATION_REQUIRED</prop>
<prop key=„finde*">PROPAGATION_REQUIRED,readOnly</prop>
</props></property>
</bean>
Verwaltete Komponente
Spring-Mechanismus
Transaktionsattribute für Operationen
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.49
� Die Fachlichkeit wird möglichst ohne Bezug auf die Technik spezifiziert.
� Ein Generator erzeugt mit Hilfe einer Konfiguration die Implementierung.
� Probleme:� Änderungen am generierten
Ergebnis müssen definiert behandelt werden
� Konfiguration kann sehr komplex und schwer verständlich werden
� Schlechte Generatoren erzeugen schlechten Code
� Bau von Generatoren ist nicht einfach; Erfahrung mit manueller Abbildung ist hilfreich
Strategie: Entkopplung durch Generierung
Konfiguration
Trans-formation
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.50
Beispiel: PIM-to-PSM-Mappings bei MDA
Fachliche Sicht(PIM)
Technische Sicht(PSM)
Bereitstellungs-Sicht(PSM)
Entwicklungssicht(PSM)
aus [SI01]
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.51
Beispiel: EJB3 Annotations
@Entity@Table(name=„HUND")@NamedQueries( { @NamedQuery(name =
"findHundById", query = "from HUND i where i.id = ?")})public class Hund implements IdentifiableObject {
@Id @GeneratedValue private long id ;...
}
� Fachlicher Quellcode und technische Konfiguration stehen beisammen, sind leichter konsistent zu halten.
� Nachteil: Technische Aspekte vermischt mit Fachlichkeit; Wechsel auf andere technische Plattform erschwert.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.52
Beispiel: Aspect-Oriented Programming (AOP)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.53
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.54
Verteilungssicht - Überblick
� Zweck� Darstellung der Verteilung der Komponenten zur Ausführungszeit
auf die Prozessoren und Rechner
� Inhalte� Abbildung der Komponenten des Systems auf die Elemente der
Systemarchitektur zur Laufzeit
� Darstellung des Client-/Server-Schnitts
� Darstellung der ausführungsnahen Qualitätseigenschaften, wie zum Beispiel Performance
� Beschreibungen� Textuelle Beschreibung und informelle Box-and-Line-Diagramme
� Kompositionsstrukturdiagramme von UML
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.55
Kern-Entwurfsaufgabe: der Client-Server-Schnitt
1 k2
1 k2
1 k2
1 k2
Präsentation
Anwendung
Präsentation Präsentation Präsentation
Datenhaltung
Anwendung
Anwendung Anwendung
Datenhaltung
Datenhaltung Datenhaltung
Anwendung
Datenhaltung
Verteilte PS Verteilte AS Verteilte DSEntfernte DS Entfernte AS
Präsentation
1 k2
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.56
Beschreibung der Verteilungssicht
� Die Verteilungssicht zeigt die Verteilung von fachlichen und technischen Komponenteninstanzen auf die Elemente der Systemarchitektur.
� Beispiel eSteuer 2008:
db2 : Database
pv : Personen-verwaltung
s2 : Servers1 : Server
db1 : Database
hv : Hundesteuer-verwaltung
gv : Grundsteuer-verwaltung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.57
Inhalt
� Motivation und Eigenschaften� Was sind Sichten?� Überblick über die Sichten
� Fachliche Sicht� Vom Analysemodell zum fachlichen Entwurf� Bildung fachlicher Komponenten
� Technische Sicht� Technische Komponenten und Schnittstellen� Umsetzung der Fachlichkeit
� Verteilungssicht� Verteilung der Komponenten
� Zusammenfassung
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.58
Zusammenfassung
� Eine Sicht stellt jeweils bestimmte, zusammengehörige Eigenschaften eines Systems dar.
� Es gibt zwei Hauptarten von Sichten: Spezifikationssichten zur Beschreibung des Systems und Entwurfssichten zur Beschreibung seiner Entwicklung.
� Bei den Spezifikationssichten sollte die fachliche Sicht vor dertechnischen Sicht bearbeitet und ausmodelliert werden.
� Sowohl in der fachlichen als auch in der technischen Sicht ist die Bildung von Komponenten mit klar definierten Schnittstellen und Abhängigkeitsbeziehungen wichtig.
� Zur Entkopplung von fachlicher und technischer Sicht gibt es eine Reihe von Standard-Techniken. Dazu gehören insbesondere die Kapselung der Technik hinter Schnittstellen, Container-Architekturen sowie Generierung.
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.59
Literaturhinweise
� [BRS97] Klaus Bergner, Andreas Rausch, Marc Sihling: Using UML forModeling a Distributed Java Application, Technischer Bericht der Universität München, TUM-I9735, http://wwwbib.informatik.tu-muenchen.de/infberichte/1997/TUM-I9735.ps.gz, 1997.
� [CBB02] Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord, Judith Stafford: Documenting Software Architectures – Views and Beyond, Addison-Wesley, 2002.
� [HNS99] Christine Hofmeister, Robert Nord, Dilip Soni: Applied Software Architecture, Addison Wesley – Object Technology Series, 1999.
� [HS99] Peter Herzum, Oliver Sims. Business Component Factory: A Comprehensive Overview of Component-Based Development for theEnterprise, John Wiley & Sons, 1999.
� [Kr94] Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara ZenglerStefanQueins: UML2 glasklar, Carl Hanser Verlag, 2004.
� [OM01] Object Management Group: Model Driven Architecture (MDA) Website, www.omg.org/mda, OMG 2005.
� [SI01] J. Siegel, OMG Staff Strategy Group: Developing in OMG´sModel-Driven Architecture, OMG White Paper, November 2001.
� [Sp05] Spring Framework Website, www.springframework.org, 2005.
top related