Softwarearchitektur - Technische Universität Braunschweig

Software- und Systementwurf
- Softwarearchitektur Software Engineering 1
WS 2011/2011
Dr. Ina Schaefer
Software Systems Engineering
Technische Universität Braunschweig
(Folien von Prof. B. Rumpe)
Überblick
 Softwareentwurf
• Ziele
• Entwurfsprinzipien
 Architekturentwurf
 Architekturmuster
 Unified Modeling Language (UML) - Überblick
Dr. Ina Schaefer
Software Engineering 1
Seite 2
Software-Entwurf
 Ausgangspunkt:
• Systemspezifikation (Pflichtenheft)
 Ziel:
• Vom “WAS" zum “WIE": Vorgabe für Implementierung
 Zentrale Begriffe:
• Subsystem
• in sich geschlossen
• eigenständig funktionsfähig mit definierten Schnittstellen
• besteht aus Komponenten
• Komponente
•
•
•
•
Dr. Ina Schaefer
Baustein für ein Softwaresystem (z.B. Modul, Klasse, Paket)
benutzt andere Komponenten
wird von anderen Komponenten benutzt
kann auch aus Unterkomponenten bestehen
Software Engineering 1
Seite 3
Von der Analyse zum Entwurf
Analyse
AnforderungsErmittlung
AnforderungsSpezifikation
(Lastenheft)
SystemSpezifikation
(Pflichtenheft)
SystemModellierung
Entwurf
Dr. Ina Schaefer
Software Engineering 1
Seite 4
Gliederung des Entwurfsprozesses
 Architekturentwurf
 Subsystem-Spezifikation
 Schnittstellen-Spezifikation
Gesamtstruktur
des Systems
(Grobentwurf)
 Komponentenentwurf
 Datenstrukturentwurf
 Algorithmenentwurf
Detailstruktur
des Systems
(Feinentwurf)
 Grobentwurf:
• weitgehend unabhängig von Implementierungssprache
 Feinentwurf
• angepasst an die Implementierungssprache und Plattform
Dr. Ina Schaefer
Software Engineering 1
Seite 5
Arbeitsteilung beim Entwurf
Architekturentwurf
Entwurf
Subsystem 1
Entwurf
Entwurf
Schnittstelle
Schnittstelle
2 ...
1 2
Entwurf
Subsystem 2
Entwurf
Subsystem ...
Entwurf der Komponenten
Dr. Ina Schaefer
Software Engineering 1
Seite 6
Kriterien für "guten" Entwurf
 Korrektheit
• Erfüllung der Anforderungen
• Wiedergabe aller Funktionen des Systemmodells
• Sicherstellung der nichtfunktionalen Anforderungen
 Verständlichkeit & Präzision
• Gute Dokumentation
 Anpassbarkeit
 Hohe Kohäsion innerhalb der Komponenten
 Schwache Kopplung zwischen den Komponenten
 Wiederverwendung
 Diese Kriterien gelten auf allen Ebenen des Entwurfs (Architektur,
Subsysteme, Komponenten).
Dr. Ina Schaefer
Software Engineering 1
Seite 7
Kohäsion
 Kohäsion ist ein Maß für die Zusammengehörigkeit der Bestandteile
einer Komponente.
 Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung
und Anpassung.
 Frühere Ansätze zur Kohäsion wie:
• ähnliche Funktionalitäten zusammenfassen
• führten nicht unbedingt zu stabiler Systemstruktur
 Bessere Kohäsion wird erreicht durch:
• Prinzipien der Objektorientierung (Datenkapselung)
• Einhaltung von Regeln zur Paketbildung
• Verwendung geeigneter Muster zu Kopplung und Entkopplung
• "Kohärente" Klasse:
• Es gibt keine Partitionierung in Untergruppen von
zusammengehörigen Operationen und Attributen
Dr. Ina Schaefer
Software Engineering 1
Seite 8
Kopplung
 Kopplung ist ein Maß für die Abhängigkeiten zwischen Komponenten.
 Geringe Kopplung erleichtert die Wartbarkeit und macht Systeme
stabiler.
 Arten der Kopplung:
• Datenkopplung (gemeinsame Daten)
• Schnittstellenkopplung (gegenseitiger Aufruf)
• Strukturkopplung (gemeinsame Strukturelemente)
 Reduktion der Kopplung:
• Kopplung kann nie auf Null reduziert werden!
• Schnittstellenkopplung ist akzeptabel, da höhere Flexibilität
• Datenkopplung vermeiden!
• aber durch Objektorientierung meist gegeben
• Strukturkopplung vermeiden!
• z.B. keine Vererbung über Paketgrenzen hinweg
 Entkopplungsbeispiel: getter/setter-Methoden statt direkter Attributzugriff
Dr. Ina Schaefer
Software Engineering 1
Seite 9
Interne Wiederverwendung
 Interne Wiederverwendung (reuse) ist ein Maß für die Ausnutzung
von Gemeinsamkeiten zwischen Komponenten
 Reduktion der Redundanz
 Erhöhung der Stabilität und Ergonomie
 Hilfsmittel für Wiederverwendung:
• im objektorientierten Entwurf: Vererbung, Parametrisierung
• im modularen und objektorientierten Entwurf:
Module/Objekte mit allgemeinen Schnittstellen (Interfaces)
 Aber: Wiederverwendung kann die Kopplung erhöhen:
• Schnittstellenkopplung und Strukturkopplung
Dr. Ina Schaefer
Software Engineering 1
Seite 10
Entwurfsschritte
Analyse
AnforderungsSpezifikation
(Lastenheft)
AnforderungsErmittlung
SystemSpezifikation
(Pflichtenheft)
SystemModellierung
ArchitekturSpezifikation
ArchitekturEntwurf
Entwurf
DetailEntwurf
Klassen- bzw. ModulSpezifikationen
Dr. Ina Schaefer
Software Engineering 1
Seite 11
Architekturentwurf im Kontext der SW-Entwicklung
Anforderungsanalyse,
Domänenanalyse
Entwurf der
Softwarearchitektur
Entwurf der
Systemarchitektur,
Auswahl der
Hardware
Feindesign,
Programmierung,
Integration, Testen,
Auslieferung
Dr. Ina Schaefer
Software Engineering 1
Seite 12
Softwarearchitektur in der Praxis
 Architekturspezifikation wird zu oft nicht als separates Dokument
gefordert.
 Häufig wird funktionale Spezifikation und Architekturspezifikation in
einem Dokument realisiert.
• denn „WAS“ zu spezifizieren, ohne auf grobe Strukturen des „WIE“
einzugehen ist oft nicht möglich.
• Dennoch: die grobe Systemarchitektur wird der Entwurfs-Aktivität
zugeordnet
 Ist Hardware involviert (Steuergeräte im Auto, TelekommunikationsAnlagen etc.), so wird oft bereits dadurch eine physische Architektur
vorgegeben. (Sinnvoll: Architekturskizzen bereits in der Anforderungsbeschreibung.)
 Logische Systemarchitektur und physische Architektur sind nicht
notwendig identisch.
Dr. Ina Schaefer
Software Engineering 1
Seite 13
Beispielarchitektur
Dr. Ina Schaefer
Software Engineering 1
Seite 14
„4+1 Sichten“-Modell der Softwarearchitektur
Logische Sicht
Struktursicht
Szenarien
Ablaufsicht
Physikalische Sicht
Philippe Kruchten, The 4+1 view model of architecture, IEEE Software, November
1995, 12(6), pp. 42-50 (Verwendung im Rational Unified Process - RUP)
Dr. Ina Schaefer
Software Engineering 1
Seite 15
Bestandteile der 4+1 Sichten
Logische Sicht
Struktursicht
• Klassenmodell
• Verfeinerung des
Analysemodells
• Subsysteme
• Schnittstellen
Szenarien
• Use-Cases
Ablaufsicht
Grobentwurf
Physikalische Sicht
• Komponenten
• Hardwaresysteme
• Netze
• Prozesse
• Koordination
Feinentwurf
Dr. Ina Schaefer
Software Engineering 1
Seite 16
Primäre Zielgruppe und Aufgabe der Sichten
Logische Sicht
Struktursicht
• Endanwender
• Programmierung
• Wartung
Grobentwurf
Ablaufsicht
Physikalische Sicht
• System-Integratoren
(Performanz,
Durchsatz ...)
• Kommunikation
• Verteilung
• Auslieferung, Installation
Feinentwurf
Dr. Ina Schaefer
Software Engineering 1
Seite 17
Blockdiagramme
 Blockdiagramme sind kein Bestandteil von UML!
(Gleichwertige Notation in UML: Implementierungsdiagramm)
 Blockdiagramme sind ein verbreitetes Hilfsmittel zur Skizzierung der
logischen Struktur einer Systemarchitektur.
• Subsystem umfasst Objekte
bestimmter Klassen.
• Schnittstelle ist klar
definiert.
(z.B. Aufrufschnittstelle,
Kommunikationsprotokoll)
Schnittstelle
Subsystem
Dr. Ina Schaefer
Umfassendes
Subsystem
Software Engineering 1
Seite 18
UML Komponentendiagramme
Das Komponenten-Diagramm stellt die (logischen) Komponenten
des Systems und deren Schnittstellen (Ports) dar.
Architektur:
Anwendung
UI
Bank
UI = User Interface = Benutzerschnittstelle/ Benutzeroberfläche
GUI = Graphical User Interface = grafische Benutzerschnittstelle
Dr. Ina Schaefer
Software Engineering 1
Seite 19
Komponenten
optionaler
grafischer
Stereotyp
Name der
Komponente
«component»
WebInterface
HTTP
Database
Webservice
benötigte
Schnittstelle
bereitgestellte
Schnittstelle
Dr. Ina Schaefer
Software Engineering 1
Seite 20
Komposition von Komponenten
Zusammengesetzte
Komponente
Komponente
D
Port
A
benötigte
Schnittstelle
bereitgestellte
Schnittstelle
B
C
D
A
analoges
Blockdiagramm
Dr. Ina Schaefer
Software Engineering 1
B
C
Seite 21
Konfigurationsdiagramme
 Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML!
 Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur
Beschreibung der physikalischen Verteilung von SystemKomponenten.
Rechner, Knoten
Lokales
Kommunikationsnetz
Dr. Ina Schaefer
Speicherndes
System
Software Engineering 1
DatenkommunikationsNetz
Seite 22
UML: Verteilungsdiagramm
 engl.: deployment diagram
 zeigt die physische Verteilung von Systemen
Stereotypen kennzeichnen
die Arten von Knoten
Node
(Knoten)
<<processor>>
Client
<<network>> local network
<<processor>>
Server 1
<<processor>>
Server 2
A
Dr. Ina Schaefer
Komponenten können
zugeordnet werden
B
Software Engineering 1
Seite 23
Beispiel Terminverwaltung
PC1
... PCn
TerminServer
PDA1
PDAm
Physikalische
Konfiguration
AnzeigetafelSteuerung
PC Client
PDA Client
PDA Sync
Blockdiagramm
Termin-Manager
DatenExport
Termin-Datenbank
Dr. Ina Schaefer
Software Engineering 1
Seite 24
Kriterien für guten Entwurf
 Wie bereits diskutiert ist auf Kohäsion und Kopplung zu achten:
 Hohe Kohäsion:
• Kohäsion = "Zusammenhalt"
• Die Dinge sollen in Struktureinheiten zusammengefasst werden,
die inhaltlich zusammengehören.
Niedrige Kopplung:
• Kopplung = Abhängigkeiten
• Einzelne Struktureinheiten sollen möglichst unabhängig voneinander
sein.
Daneben allgemeine Eigenschaften, z.B.: Korrektheit, Anpassbarkeit,
Verständlichkeit, Ressourcenschonung
Dr. Ina Schaefer
Software Engineering 1
Seite 25
Hohe Kohäsion und Niedrige Kopplung
Subsystem A
(z.B. Benutzungsoberfläche)
Subsystem B
(z.B. fachlicher Kern)
Dr. Ina Schaefer
 Hohe Kohäsion:
Subsystem B darf keine Information
und Funktionalität enthalten, die zum
Zuständigkeitsbereich von A gehört
und umgekehrt.
 Niedrige Kopplung:
Es muss möglich sein, Subsystem A
weitgehend auszutauschen oder zu
verändern, ohne Subsystem B zu
verändern.
Änderungen von Subsystem B
sollten nur möglichst einfache
Änderungen in Subsystem A nach
sich ziehen.
 Beispiele zur konkreten technischen
Realisierung siehe später
(MVC-Architektur, Entwurfsmuster)
Software Engineering 1
Seite 26
Qualitätssicherung mittels Szenarien
 Szenarien (für Anwendungsfälle) sind von zentraler Bedeutung:
• Integration der verschiedenen Sichten
• Kriterium für Architekturbewertung (Auswahl alternativer Muster)
• Qualitätssicherung (Review)
 Bewertung für Softwarearchitekturen:
• Architektur(en) festlegen
• Im Architekturentwurf: Alternativen
• Bei der abschließenden Qualitätssicherung: gewählte Architektur
• Szenarien durchspielen
• „Direkte Szenarien“: Auf der Architektur gut realisierbar
• „Indirekte Szenarien“: Nur nach Architekturerweiterung realisierbar
• Architekturen bewerten nach:
• Anzahl der direkten Szenarien
• Aufwand zur Modifikation für indirekte Szenarien
• Abschätzung der Effizienz
Dr. Ina Schaefer
Software Engineering 1
Seite 27
Architekturmuster für die Struktursicht
 Struktursicht der Architektur:
• Zerlegung in Subsysteme eigenständiger Funktionalität
• Keine Aussage über physikalische Verteilung
• Darstellung meist durch Blockdiagramme:
Datenfluss-Schnittstelle
Subsystem
Aufrufschnittstelle
 Muster (Architekturmuster, Architekturstile):
• Kette (Chain)
• Schichten
• Interpreter
Dr. Ina Schaefer
Software Engineering 1
Seite 28
Architekturmuster „Pipes & Filters“
Phase 2.1
Phase 1
Phase 3
Phase 2.2
Zwischenprodukt 1.1
Zwischenprodukt 1.2
Zwischenprodukt 2.1
Zwischenprodukt 2.2
 Deutsch auch „Kette“
 Inkrementelle oder phasenweise Verarbeitung
 Beispiele:
• UNIX pipes
• Batch-sequentielle Systeme
• Compiler-Grundstruktur
Dr. Ina Schaefer
Software Engineering 1
Seite 29
Beispiel: Compiler-Architektur
QuellProgramm
Tokens
Scanner
Symboltabelle
Syntaxbaum
Parser
Fehlermeldungen
ZielProgramm
CodeGenerator
FehlerAusgabe
Fehlermeldungen
 Kombination von Ketten
Dr. Ina Schaefer
Software Engineering 1
Seite 30
Architekturmuster "Schichten"
„Benutzer“
Schicht 2
Schicht 1
Systemkern
 Jede Schicht
bietet Dienste (nach oben) und
nutzt Dienste (von unten)
 Beispiele:
• Kommunikationsprotokolle
• Datenbanksysteme, Betriebssysteme
Dr. Ina Schaefer
Software Engineering 1
Seite 31
Architekturmuster "Interpreter"
„Benutzer“
Programm
Abstrakte Maschine
Basissystem
 Schichtenarchitektur mit Parametrisierung
 Beispiele:
• Portable Sprachimplementierung (z.B. Java Virtual Machine)
• Emulation von Systemarchitekturen (z.B. Soft Windows)
Dr. Ina Schaefer
Software Engineering 1
Seite 32
Beispiel: 3-Schichten-Referenzarchitektur
Benutzungsschnittstelle
Fachlicher Kern
Persistenzschicht
 Entwurfsregeln:
• Benutzungsschnittstelle greift nie direkt auf Datenhaltung zu.
• Persistenzschicht verkapselt Zugriff auf Datenhaltung, ist aber
nicht identisch mit dem Mechanismus der Datenhaltung (z.B.
Datenbank).
• Fachlicher Kern basiert auf dem Analyse-Modell
 Erlaubt das Aufsetzen von interaktiven, batch, etc.
Benutzerschnittstellen und den Austausch von Datenbanken
Dr. Ina Schaefer
Software Engineering 1
Seite 33
Variante: 3-Schichten-Referenzarchitektur
Benutzungsschnittstelle
Fachlicher Kern
Systemfunktionen
Persistenzschicht
 Beispiele für Systemfunktionen:
• Verkapselung von plattformspezifischen Funktionen
• Schnittstellen zu Fremdsystemen
Dr. Ina Schaefer
Software Engineering 1
Seite 34
Architekturmuster für die physikalische Sicht
 Physikalische Sicht der Architektur:
• Aufteilung der Funktionalität auf Knoten (Rechner) eines Netzes
• Darstellung meist durch Konfigurationsdiagramme:
Knoten
Kommunikation
 Muster (Verteilungsmuster):
• Zentrales System
• Client/Server:
• Two-Tier (Thin-Client, Fat-Client)
• Three-Tier (GUI; Applikationskern, Datenhaltung)
• Föderation
Dr. Ina Schaefer
Software Engineering 1
Seite 35
Verteilungsmuster "Zentrales System"
"Unintelligentes"
Terminal
Zentrales
System
 Beispiele:
• Klassische Großrechner-("Mainframe"-)Anwendungen
• Noch einfachere Variante:
Lokale PC-Anwendungen (identifizieren Zentrale und Terminal)
Dr. Ina Schaefer
Software Engineering 1
Seite 36
Verteilungsmuster "Client/Server"
"Intelligenter"
Client
Server
 Sogenannte "Two-Tier" Client/server-Architektur
 Andere Namen:
• "Front-end" für "Client", "Back-end" für "Server"
 Client:
• Benutzungsschnittstelle
• Einbindung in Geschäftsprozesse
• Entkoppelt von Netztechnologie und Datenhaltung
 Server:
• Datenhaltung, evtl. Fachlogik
Dr. Ina Schaefer
Software Engineering 1
Seite 37
"Thin-Client" und "Fat-Client"
 Thin-Client:
• Nur die Benutzungsschnittstelle auf dem Client-System
• Ähnlich zu Zentralem System, aber oft DownloadMechanismen
• Anwendungen:
• "Screen-Scraping"
(Umsetzung traditioneller Benutzungsschnittstellen in moderne
Technologie)
 Fat-Client:
• Teile der Fachlogik (oder gesamte Fachlogik) auf dem ClientSystem
• Hauptfunktion des Servers: Datenhaltung
• Entlastung des Servers
• Zusätzliche Anforderungen an Clients (z.B. Installation von
Software)
Dr. Ina Schaefer
Software Engineering 1
Seite 38
Verteilungsmuster "Three-Tier Client/Server"
"Intelligenter"
Client
AnwendungsServer
Server
 Client:
• Benutzungsschnittstelle
• evtl. Fachlogik
 Anwendungsserver:
• evtl. Fachlogik
• Verteilung von Anfragen auf verschiedene Server
 Server:
• Datenhaltung, Rechenleistung etc.
 Kommunikation unter Servern meist breitbandig.
 Heute üblich!
Dr. Ina Schaefer
Software Engineering 1
Seite 39
Verteilungsmuster "Föderation"
Knoten 1
Knoten 2
Knoten 3
Knoten 5
Knoten 4
 Gleichberechtigte Partner (peer-to-peer)
 Unabhängigkeit von der Lokation und Plattform von Funktionen
 Verteilte kommunizierende Objekte
Dr. Ina Schaefer
Software Engineering 1
Seite 40
Architekturmuster der Ablaufsicht
 Ablaufsicht der Architektur:
• Definition nebenläufiger Systemeinheiten (z.B. Prozesse)
• Steuerung der Abfolge von Einzelfunktionen
• Synchronisation und Koordination
• Reaktion auf externe Ereignisse
 Darstellung z.B. durch Sequenzdiagramme
 Muster (Steuerungsmuster):
• Zentrale Steuerung
• Call-Return
• Master-Slave
• Ereignis-Steuerung
• Selective Broadcast
• Interrupt
Dr. Ina Schaefer
Software Engineering 1
Seite 41
Steuerungsmuster "Call-Return"
Hauptprogramm
Dr. Ina Schaefer
Unterprogramm 1
Unterprogramm 1.1
Software Engineering 1
Unterprogramm 1.2
Seite 42
Steuerungsmuster "Master-Slave"
Manager
Dr. Ina Schaefer
Benutz.oberfläche
Sensor
Software Engineering 1
Aktuator
Seite 43
Steuerungsmuster "Selective Broadcast"
Event
Handler
Subsystem
1
Subsystem
2
Subsystem
3
Ereignis e
e
e
e
Ereignis e'
e'
e'
e'
Dr. Ina Schaefer
Software Engineering 1
Seite 44
Steuerungsmuster "Interrupt"
Interrupt
Dispatcher
Handler
1
Handler
2
e
Prozess
2
e’
Prozess
1
Verwendet
Interrupt-Vektor
Dr. Ina Schaefer
Software Engineering 1
Seite 45
Zusammenfassung Architekturmuster
 Architekturmuster beschreiben erprobte Strukturierungsformen für
die Architektur eines Systems
 Architekturmuster beschreiben:
• Struktur
• physikalische Verteilung
• Zuordnung von Prozessen auf Prozessoren
• Kommunikationsformen und –protokolle
 Schichtenbildung ist ein mächtiges Strukturierungsmittel
Dr. Ina Schaefer
Software Engineering 1
Seite 46
Unified Modeling Language (UML)
 graphische Modellierungssprache zur Spezifikation, Konstruktion
und Dokumentation von Teilen von Software und anderen Systemen
 Kombiniert die Modellierung von Strukturen (Architektur, Daten, …),
Prozessen, Verhalten und Interaktionen
 von der Object Management Group (OMG) entwickelt und
standardisiert
 ISO standardisiert (ISO/IEC 19501 für UML 2.1.2)
 Aktuelle Version: UML 2.3 (Mai 2010)
Dr. Ina Schaefer
Software Engineering 1
Seite 47
Historische Entwicklung von UML
Dr. Ina Schaefer
Software Engineering 1
Seite 48
Diagrammtypen der UML
Dr. Ina Schaefer
Software Engineering 1
Seite 49