![Page 1: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/1.jpg)
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
![Page 2: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/2.jpg)
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
![Page 3: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/3.jpg)
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
![Page 4: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/4.jpg)
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.
![Page 5: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/5.jpg)
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.
![Page 6: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/6.jpg)
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.
![Page 7: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/7.jpg)
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.
![Page 8: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/8.jpg)
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
![Page 9: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/9.jpg)
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.)
![Page 10: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/10.jpg)
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.)
![Page 11: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/11.jpg)
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
![Page 12: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/12.jpg)
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
![Page 13: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/13.jpg)
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
![Page 14: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/14.jpg)
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
![Page 15: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/15.jpg)
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?
![Page 16: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/16.jpg)
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.
![Page 17: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/17.jpg)
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
![Page 18: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/18.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.19
Ergebnis der Anforderungsanalyse - Funktionalität
� Anwendungsfälle und Ablaufspezifikationen
![Page 19: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/19.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.20
Ergebnis der Anforderungsanalyse - Daten
� Fachliches Datenmodell in Form eines UML-Klassendiagramms
![Page 20: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/20.jpg)
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.
![Page 21: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/21.jpg)
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
![Page 22: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/22.jpg)
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
![Page 23: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/23.jpg)
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
![Page 24: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/24.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.25
Zwischenstand der fachlichen Sicht
Ergebnis: erstes objektorientiertes Entwurfs-Modell, zeigt reine Entwurfskonzepte, keine Implementierungsklassen
![Page 25: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/25.jpg)
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
![Page 26: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/26.jpg)
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
![Page 27: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/27.jpg)
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).
![Page 28: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/28.jpg)
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.
![Page 29: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/29.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.30
Partitionierung am Beispiel
KomponentePersonen-verwaltung
KomponenteHundesteuerverwaltung
Komponente Grundsteuerverwaltung
![Page 30: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/30.jpg)
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
![Page 31: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/31.jpg)
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:
![Page 32: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/32.jpg)
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.
![Page 33: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/33.jpg)
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.
![Page 34: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/34.jpg)
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
![Page 35: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/35.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.36
Resultierende Komponenten
![Page 36: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/36.jpg)
Mögliche Verbindungsstruktur der Komponenten
![Page 37: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/37.jpg)
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
![Page 38: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/38.jpg)
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
![Page 39: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/39.jpg)
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
+
?
![Page 40: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/40.jpg)
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
![Page 41: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/41.jpg)
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 …
![Page 42: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/42.jpg)
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;
}
![Page 43: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/43.jpg)
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
![Page 44: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/44.jpg)
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
![Page 45: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/45.jpg)
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
![Page 46: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/46.jpg)
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
![Page 47: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/47.jpg)
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
![Page 48: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/48.jpg)
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
![Page 49: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/49.jpg)
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]
![Page 50: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/50.jpg)
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.
![Page 51: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/51.jpg)
Softwarearchitektur verteilter Systeme – 2. Grundlagen der Softwarearchitektur 3.52
Beispiel: Aspect-Oriented Programming (AOP)
![Page 52: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/52.jpg)
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
![Page 53: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/53.jpg)
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
![Page 54: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/54.jpg)
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
![Page 55: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/55.jpg)
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
![Page 56: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/56.jpg)
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
![Page 57: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/57.jpg)
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.
![Page 58: (Architektur: = Anfang, Ursprung + = Haus, Dach) · 2008-11-10 · VorlesungWintersemester2008 / 2009 TechnischeUniversitätMünchen Institut für Informatik Lehrstuhlvon Prof. Dr](https://reader034.vdocuments.net/reader034/viewer/2022042313/5edc3926ad6a402d6666ccf5/html5/thumbnails/58.jpg)
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.