Softwarearchitektur - Software and Systems Engineering

Transcription

Softwarearchitektur
(Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach)
4. Sichten bei der Softwarearchitektur – Teil 1
Vorlesung Wintersemester 2010 / 2011
Technische Universität München
Institut für Informatik
Lehrstuhl von Prof. Dr. Manfred Broy
Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling
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 – 4. Sichten bei der Softwarearchitektur I
3.2
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.3
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.
3.4
Was sind Sichten?
Ein System wird aus mehreren Blickwinkeln betrachtet, die jeweils
unterschiedliche Schwerpunkte haben.
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 related
set of concerns.
aus [AC98]
3.5
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.
3.6
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.
3.7
Arten von Sichten auf die Architektur eines Systems
Wir unterscheiden in der Folge folgende Sichten:
Spezifikationssichten
Fachliche Sicht
Technische Sicht
Verteilungssicht
Thema der heutigen
Doppelstunde
Erstellungssichten
Entwicklungssicht
Testsicht
Bereitstellungssicht
Thema der nächsten
Doppelstunde
3.9
Fachliche Sicht - Überblick
Zweck
Inhalte
Darstellung der Konzepte des Anwendungsgebiets möglichst
unabhängig von einer softwaretechnischen oder plattformspezifischen Lösung
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.)
3.10
Technische Sicht - Überblick
Zweck
Inhalte
Darstellung der softwaretechnischen Lösung für das System
inklusive der Umsetzung der fachlichen Sicht
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.)
3.11
Fachliche und Technische Sicht
top-down
fachliche
Anforderungen
Architekturanalyse
Re
1
1
Systemarchitektur,
Hardware
Re
- N ame : String
Rep
- Name : String
*
1
0..1
Proj
*
- Name : String
- OEFStream : String
*
1
1
+SubProj ect
*
Co
*
Com
- Name : String
- Kind : int
- ClassName : String
Fachliche
Sicht
C om
1
*
+SubComponent
1
*
Attr
- Name : String
- Type : String
Te
- Name : String
- Line : String
1..*
1
0..1
*
File
S
S
*
0..1
-
+Super Component
1
*
+ SubC omponent
<< Enum>>
Automa
1
+SourcePort
+OutChannel
1
+ DestinationPort
0..1
Fo
- Name : String
- Style : int
- Size : int
P
- X : int
- Y : int
0..1
Chan
- Name : String
- Type : String
- DisplayFont : Font
- DrawType : int
- TextBoxSize : Dimension
- TextBoxLocation : Point
< <Enum> >
Line
+$ STRAIG HT : LineStyle
+$ SNAPPED : LineStyle
+$ SLANTED : LineStyle
+$ LOOP : LineStyle
bottom-up
existierende
Komponenten &
Systeme
< < Enum> >
Dire
+ $ IN : Dir ection
+ $ OUT : Direction
Auto
- N ame : Stri ng
- Kind : int
- C lassName : Str ing
*
0..1
0..1
*
Par
- N ame : Str ing
Te
- Line : String
1..*
1
0..1
*
Fil e
S
S
*
0..1
Stat
- Name : String
- Pr edicate : Stri ng
- EntryAction : String
- ExitActi on : Stri ng
- IsH istory : bool ean
- IsInitial : boolean
- Location : Point
- Si ze : D imension
- Border : int
- FileName : String
1
1
*
*
*
Inte
Attr
- N ame : String
- Type : Str ing
1
*
Inte
- Name : String
- Condition : String
- Direction : int
- Location : Point
1
+SourcePoint
Di
- Heig ht : int
- Width : int
+ InChannel
Proj
*
Com
- N ame : String
- Location : Point
- Size : D imensi on
- Border : i nt
- D isplayFont : Font
- TextBoxSize : D imensi on
1
- FileName : String
1
+ $ IMPLEMENTATION : AutomatonKind
+ $ CLASSSPEC : AutomatonKind
+ $ TYPESPEC : AutomatonKind
1
0..1
*
Stat
Name : String
Predicate : Str ing
EntryAction : String
ExitAction : String
IsHistory : boolean
IsInitial : boolean
Location : Point
Size : Dimension
Border : int
*
Port
- N ame : String
- D irection : Direction = -1
- Type : String
- Location : Point
# DisplayFont : Font
- ShowName : boolean
R ep
1
1
Technische
Sicht
0..1
0..1
*
Par
- Name : String
- Location : Point
- Size : Dimension
- Border : int
- DisplayFont : Font
- TextBoxSize : Dimension
1
Com
- Name : String
- OEFStr eam : String
- OEFAnnotati on : Str ing
1
0..1
1
0..1
+SuperComponent
1
*
*
Co
- N ame : Stri ng
Auto
- Name : String
- OEFStream : String
- OEFAnnotation : String
0..1
1
Proj
- Name : String
- OEFStr eam : String
1
1
*
- N ame : String
1
*
+Super Project
1
Proj
0..1
1
1
1
+ SuperProject
+SubProject
+ OutSeg ment
*
Por t
- N ame : String
- D irecti on : D ir ection = -1
- Type : Str ing
- Location : Point
# D isplayFont : Font
- ShowN ame : bool ean
1
+ Sour cePort
+OutC hannel
1
+DestinationPoint
+ InSeg ment
1
+ DestinationPor t
0..1
- N ame : String
- Input : String
- O utput : String
- PreCondition : String
- PostCondition : String
- Action : String
- IsOuter : boolean
- C ontrolPointOne : Point
- C ontrolPointTwo : Point
Di
- H ei ght : int
- Width : int
P
- X : int
- Y : int
<< Enum> >
Line
+$ STR AIGH T : LineStyle
+$ SN APPED : Li neStyle
+$ SLANTED : Li neStyle
+$ LOOP : LineStyle
Wiederverwendung
fachlich
Fo
- N ame : Str ing
- Style : int
- Size : int
0..1
C han
- N ame : Stri ng
- Type : String
- D isplayFont : Font
- D rawType : int
- TextBoxSize : Di mension
- TextBoxLocati on : Point
*
Tran
< <Enum>>
Automa
+ $ IM PLEM ENTATION : AutomatonKind
+ $ CLASSSPEC : AutomatonKi nd
+ $ TYPESPEC : AutomatonKind
+InC hannel
<< Enum> >
D ire
+ $ IN : D irecti on
+ $ OU T : D irection
- N ame : Str ing
- C ondition : String
- D ir ection : int
- Location : Poi nt
1
+ Sour cePoint
1
+ D estinationPoi nt
+OutSegment
*
*
+InSeg ment
Tr an
- N ame : Stri ng
- Input : String
- Output : Str ing
- PreCondition : String
- PostC ondition : Str ing
- Acti on : Str ing
- IsOuter : boolean
- C ontrolPointOne : Poi nt
- C ontrolPointTwo : Poi nt
Applikationsserver,
Datenbanken,
Transaktionsmonitore
technisch
3.12
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
3.13
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
3.14
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.15
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?
3.16
Die genannten Fragestellungen werden in einem iterativen Prozess
beantwortet:
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.
3.17
Anwendungsbeispiel: eSteuer 2010
Neues Informationssystem „eSteuer 2010“ 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 2010
Steuerzahler verwalten
Grundsteuerinformationen verwalten, Grundsteuer berechnen
Hundesteuerinformationen verwalten, Hundesteuer berechnen
Steuerermäßigungen für Wachhunde auf Fremdgrundstücken
beachten!
Anwender des Systems sind Finanzbeamte
3.18
Ergebnis der Anforderungsanalyse - Funktionalität
Anwendungsfälle und Ablaufspezifikationen
3.19
Ergebnis der Anforderungsanalyse - Daten
Fachliches Datenmodell in Form eines UML-Klassendiagramms
3.20
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 (EntityKlassen) 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 EntityKlassen zu belassen.
3.21
Zuordnung der Funktionalität im Beispiel
berechneHundesteuer ist eine instabile
Operation (das Berechnungsschema kann sich
ändern) und wird deshalb einer neuen
Control-Klasse Steuerrechner zugeordnet
berechneAnzahlBewachungen
ist eine stabile Operation und wird
deshalb der bestehenden EntityKlasse Hundesteuerzahler
zugeordnet
3.22
Navigations- und Verwaltungsoperationen
Neben den Operationen für die Aktionen der Anwendungsfä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 setOperationen 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):void
der Klasse Hundesteuerzahler
3.23
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
3.24
Zwischenstand der fachlichen Sicht
Ergebnis: erstes objektorientiertes EntwurfsModell, zeigt reine Entwurfskonzepte, keine
Implementierungsklassen
3.25
Validierung durch Beispiele
Für die Operationen im Klassendiagramm werden nun fachliche
Abläufe durchgespielt und
beispielhafte Objektstrukturen
gebildet.
Klassen zur Modellierung
Beispiel-Instanzen zur Validierung
3.26
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.27
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).
3.28
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.
3.29
Partitionierung am Beispiel
Komponente
Personenverwaltung
Komponente
Hundesteuerverwaltung
Komponente Grundsteuerverwaltung
3.30
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
3.31
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:
3.32
Bidirektionale Abhängigkeiten
Bidirektional navigierbare Assoziationen resultieren normalerweise in
zyklischen Abhängigkeiten zwischen den betreffenden Komponenten.
3.33
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.
3.34
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
beim update
erfolgt Zugriff
auf geänderte
Daten in
Person
setVermoegen löst
update-Aufrufe aus
3.35
Resultierende Komponenten
3.36
Mögliche Verbindungsstruktur der Komponenten
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.38
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 Sicht
Beispiele 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
3.39
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
+
?
3.40
Strategie: Templates für schematische Kopplung
Programmierrichtlinien oder Templates geben vor, wie die Technik
im Programm angesprochen werden kann bzw. muss.
Fachliche
Anteile
Fachliche und technische
Teile gemäß Template
Technische
Anteile
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
3.41
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 …
3.42
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;
}
3.43
Methodentemplate (Postconditions & Trace Exit) (3)
finally {
if (!exceptionThrown) {
TraceManager.traceCallExit(this);
if (CheckManager.CHECK_POSTCONDITION) {
CheckManager.assertPostCondition(this, new
NotNullAssertion(arg1));
}
}
}
} // doSomeThing
3.44
Strategie: Technik hinter Schnittstellen kapseln
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.
A
B’
A
A
A
B
B’
Adapter
C’
D
C’
C
B
C
D
Wrapper
Mögliche Probleme:
Technik scheint immer noch durch
Komponenten sind von Schnittstellen der Adapter/Wrapper abhängig
3.45
Beispiel: Standardschnittstellen für Persistenz
Der Zugriff auf die Verwaltungsfunktionalität geschieht über
einfache, möglichst standardisierte Schnittstellen.
Interface aus der ODMG-Schnittstelle
ODMG API
OODBMSAdapter
ODMG API
O/R-MappingAdapter
O/R-Tool API
O/R-Mapping
Tool
OODBMS-API
OODBMS
Datenbank
JDBC-API
relationale
RDBMS
3.46
Strategie: Verantwortung auf Container abwälzen
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.
Container
Konfiguration
Mögliche Probleme
Nur möglich, wenn Verwaltung der technischen Funktionalität
konfigurationsgesteuert (ohne Programmierung) möglich ist
Konfigurationsdateien können sehr komplex werden
3.47
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 deklarative
Transaktionsverwaltung im Spring Application Framework
<bean id=„trx_hundesteuermanager"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="txManager"/>
Spring-Mechanismus
Verwaltete Komponente
<property name="target" ref=„hundesteuermanager"/>
<property name="transactionAttributes"><props>
<prop key="create*">PROPAGATION_REQUIRED</prop>
<prop key=„finde*">PROPAGATION_REQUIRED,readOnly</prop>
</props></property>
Transaktionsattribute für Operationen
</bean>
3.48
Strategie: Entkopplung durch Generierung
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
Konfiguration
Transformation
3.49
Beispiel: PIM-to-PSM-Mappings bei MDA
Fachliche Sicht
(PIM)
aus [SI01]
Technische Sicht
(PSM)
Entwicklungssicht
(PSM)
Bereitstellungs-Sicht
(PSM)
3.50
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.
3.51
Beispiel: Aspect-Oriented Programming (AOP)
3.52
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.53
Verteilungssicht - Überblick
Zweck
Inhalte
Darstellung der Verteilung der Komponenten zur Ausführungszeit
auf die Prozessoren und Rechner
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
3.54
Kern-Entwurfsaufgabe: der Client-Server-Schnitt
Entfernte DS
Entfernte AS
Verteilte PS
1
Präsentation
2
Präsentation
Verteilte AS
Verteilte DS
Präsentation
Präsentation
k
Präsentation
1
2
Anwendung
k
1
2
Anwendung
k
Anwendung
Anwendung
1
2
k
1
Anwendung
Datenhaltung
Datenhaltung
Datenhaltung
2
k
Datenhaltung
Datenhaltung
3.55
Beschreibung der Verteilungssicht
Die Verteilungssicht zeigt die Verteilung von fachlichen und
technischen Komponenteninstanzen auf die Elemente der
Systemarchitektur.
Beispiel eSteuer 2010:
s1 : Server
s2 : Server
hv : Hundesteuerverwaltung
pv : Personenverwaltung
gv : Grundsteuerverwaltung
db1 : Database
db2 : Database
3.56
Inhalt
Was sind Sichten?
Fachliche Sicht
Technische Sicht
Verteilungssicht
Zusammenfassung
3.57
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 der
technischen 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, ContainerArchitekturen sowie Generierung.
3.58
Literaturhinweise
[BRS97]
Klaus Bergner, Andreas Rausch, Marc Sihling: Using UML for
Modeling a Distributed Java Application, Technischer Bericht der Universität
München, TUM-I9735, http://wwwbib.informatik.tumuenchen.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 the
Enterprise, John Wiley & Sons, 1999.
[Kr94]
Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara ZenglerStefan
Queins: 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´s
Model-Driven Architecture, OMG White Paper, November 2001.
[Sp05]
Spring Framework Website, www.springframework.org, 2005.
3.59

Softwarearchitektur - Software and Systems Engineering

Transcription

Documents pareils

Softwarearchitektur - Software and Systems Engineering

Übung 7

Unbenannte Seite - Der Schallplattenladen

Camille Top Hand made Crochet top . Short sleeves

Reguläre Ausdrücke in Perl

Was ist C++ Good to know Was kann mir helfen?

9. Strings

EXCEL 2013 VBA: Zeichenkette/String in Bestandteile zerlegen