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.