Software- und Systementwurf - TU Braunschweig · Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung und Anpassung. Frühere Ansätze zur Kohäsion wie: •ähnliche

Prof. Dr. Ina Schaefer

Institut für Softwaretechnik und Fahrzeuginformatik

Technische Universität Braunschweig

(mit Folien von Prof. B. Rumpe)

Software- und Systementwurf

- Softwarearchitektur -

Software Engineering 1

WS 2012/2013

Prof. Dr. Ina Schaefer Software Engineering 1 Seite 2

Überblick

Softwareentwurf

• Ziele

• Entwurfsprinzipien

Architekturentwurf

Architekturmuster

Service-orientierte Architekturen


Entwurf

Von der Analyse zum Entwurf

Analyse

Anforderungs- Ermittlung

Anforderungs- Spezifikation (Lastenheft)

System- Spezifikation (Pflichtenheft)

System- Modellierung


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

• Baustein für ein Softwaresystem (z.B. Modul, Klasse, Paket)

• benutzt andere Komponenten

• wird von anderen Komponenten benutzt

• kann auch aus Unterkomponenten bestehen


Gliederung des Entwurfsprozesses

Architekturentwurf

Subsystem-Spezifikation

Schnittstellen-Spezifikation

Komponentenentwurf

Datenstrukturentwurf

Algorithmenentwurf

Grobentwurf:

• weitgehend unabhängig von Implementierungssprache

Feinentwurf

• angepasst an die Implementierungssprache und Plattform

Gesamtstruktur des Systems (Grobentwurf)

Detailstruktur des Systems (Feinentwurf)


Arbeitsteilung beim Entwurf

Architekturentwurf

Entwurf Subsystem 1

Entwurf Subsystem 2

Entwurf Subsystem ...

Entwurf der Komponenten

Entwurf Schnittstelle 1 2

Entwurf Schnittstelle 2 ...


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).


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


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


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


Entwurf

Entwurfsschritte

Analyse

Anforderungs- Ermittlung

Anforderungs- Spezifikation (Lastenheft)

System- Spezifikation (Pflichtenheft)

System- Modellierung Architektur-

Spezifikation

Architektur- Entwurf

Klassen- bzw. Modul- Spezifikationen

Detail- Entwurf


Anforderungs-

analyse,

Domänenanalyse

Entwurf der

Softwarearchitektur

Entwurf der

Systemarchitektur,

Auswahl der

Hardware

Feindesign,

Programmierung,

Integration, Testen,

Auslieferung

Architekturentwurf im Kontext der SW-Entwicklung


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, Telekommunikations-

Anlagen etc.), so wird oft bereits dadurch eine physische Architektur

vorgegeben. (Sinnvoll: Architekturskizzen bereits in der Anforderungs-

beschreibung.)

Logische Systemarchitektur und physische Architektur sind nicht

notwendig identisch.


Beispielarchitektur


„4+1 Sichten“-Modell der Softwarearchitektur

Philippe Kruchten, The 4+1 view model of architecture, IEEE Software, November

1995, 12(6), pp. 42-50 (Verwendung im Rational Unified Process - RUP)

Logische Sicht Entwurfssicht

Ablaufsicht Physikalische Sicht

Szenarien


Bestandteile der 4+1 Sichten



Grobentwurf

Feinentwurf

Szenarien • Use-Cases

• Klassenmodell • Verfeinerung des Analysemodells

• Prozesse • Koordination

• Subsysteme • Schnittstellen

• Komponenten • Hardwaresysteme • Netze


Primäre Zielgruppe und Aufgabe der Sichten



• Endanwender • Programmierung • Wartung

• System-Integratoren (Performanz, Durchsatz ...)

• Kommunikation • Verteilung • Auslieferung, Installation

Grobentwurf

Feinentwurf


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)

Umfassendes Subsystem

Schnittstelle

Subsystem


UML Komponentendiagramme

Das Komponenten-Diagramm stellt die (logischen) Komponenten

des Systems und deren Schnittstellen (Ports) dar.

Architektur: UI Anwendung

Bank

UI = User Interface = Benutzerschnittstelle/ Benutzeroberfläche GUI = Graphical User Interface = grafische Benutzerschnittstelle


Komponenten

optionaler grafischer Stereotyp Name der

Komponente

bereitgestellte Schnittstelle

benötigte Schnittstelle

«component»

WebInterface

Database

Webservice

HTTP


Komposition von Komponenten

Komponente

bereitgestellte Schnittstelle

Zusammengesetzte Komponente

C B

A

D Port

benötigte Schnittstelle

A

C B

D

analoges Blockdiagramm


Konfigurationsdiagramme

Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML!

Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur

Beschreibung der physikalischen Verteilung von System-

Komponenten.

Speicherndes System

Lokales Kommunikationsnetz

Datenkommunikations- Netz

Rechner, Knoten


UML: Verteilungsdiagramm

engl.: deployment diagram

zeigt die physische Verteilung von Systemen

<<network>> local network

<<processor>> Client

<<processor>> Server 1

<<processor>> Server 2

A B

Stereotypen kennzeichnen die Arten von Knoten

Komponenten können zugeordnet werden

Node (Knoten)


Physikalische Konfiguration

Blockdiagramm

PC1 ... PCn PDA1 PDAm

Termin- Server

Anzeigetafel- Steuerung

PC Client PDA Client

PDA Sync

Termin-Manager Daten- Export

Termin-Datenbank

Beispiel Terminverwaltung


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


Hohe Kohäsion und Niedrige Kopplung

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.

Subsystem A (z.B. Benutzungs- oberfläche)

Subsystem B (z.B. fachlicher Kern)


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


Architekturmuster für die Entwurfssicht

Struktursicht der Architektur:

• Zerlegung in Subsysteme eigenständiger Funktionalität

• Keine Aussage über physikalische Verteilung

• Darstellung meist durch Blockdiagramme:

Muster (Architekturmuster, Architekturstile):

• Kette (Chain)

• Schichten

• Interpreter

• Model-View-Controller (MVC)

Subsystem Datenfluss-Schnittstelle

Aufrufschnittstelle


Phase 1

Phase 2.1

Phase 3

Architekturmuster „Pipes & Filters“

Deutsch auch „Kette“

Inkrementelle oder phasenweise Verarbeitung

Beispiele:

• UNIX pipes

• Batch-sequentielle Systeme

• Compiler-Grundstruktur

Zwischen- produkt 1.1

Phase 2.2





Beispiel: Compiler-Architektur

Instanz von „Pipes & Filters“: Kombination von Ketten

Scanner Parser Code- Generator

Fehler- Ausgabe

Quell- Programm Tokens Syntaxbaum

Ziel- Programm

Fehler- meldungen

Symbol- tabelle

Fehler- meldungen


Architekturmuster "Schichten"

Jede Schicht bietet Dienste (nach oben) und nutzt Dienste (von unten)

Beispiele:

• Kommunikationsprotokolle

• Datenbanksysteme, Betriebssysteme

Systemkern

Schicht 1

Schicht 2

„Benutzer“


Beispiel: 3-Schichten-Referenzarchitektur

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

Persistenzschicht

Fachlicher Kern

Benutzungsschnittstelle


Variante: 3-Schichten-Referenzarchitektur

Beispiele für Systemfunktionen:

• Verkapselung von plattformspezifischen Funktionen

• Schnittstellen zu Fremdsystemen

Persistenzschicht

Fachlicher Kern

Benutzungsschnittstelle

System- funktionen


Architekturmuster "Interpreter"

Schichtenarchitektur mit Parametrisierung

Beispiele:

• Portable Sprachimplementierung (z.B. Java Virtual Machine)

• Emulation von Systemarchitekturen (z.B. Soft Windows)

Basissystem

Abstrakte Maschine Programm

„Benutzer“


Model-View-Controller

Model (Datenhaltung)

• Benachrichtigt über Änderungen

View (Darstellung der Daten)

• Fordert Update des Models an

• Sendet Nutzereingaben an Controller

Controller (Programmsteuerung)

• Wählt View aus

• Bildet Nutzereingaben auf Modelupdates ab


Architekturmuster für die physikalische Sicht

Physikalische Sicht der Architektur:

• Aufteilung der Funktionalität auf Knoten (Rechner) eines Netzes

• Darstellung meist durch Konfigurationsdiagramme:

Muster (Verteilungsmuster):

• Zentrales System

• Client/Server:

• Two-Tier (Thin-Client, Fat-Client)

• Three-Tier (GUI; Applikationskern, Datenhaltung)

• Föderation

• Cloud Computing

Knoten Kommunikation


Verteilungsmuster "Zentrales System"

Beispiele:

• Klassische Großrechner-("Mainframe"-)Anwendungen

• Noch einfachere Variante: Lokale PC-Anwendungen (identifizieren Zentrale und Terminal)

Zentrales System

"Unintelligentes" Terminal


Verteilungsmuster "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

Server "Intelligenter" Client


"Thin-Client" und "Fat-Client"

Thin-Client:

• Nur die Benutzungsschnittstelle auf dem Client-System

• Ähnlich zu Zentralem System, aber oft Download-Mechanismen

• Anwendungen:

• "Screen-Scraping" (Umsetzung traditioneller Benutzungsschnittstellen in moderne Technologie)

Fat-Client:

• Teile der Fachlogik (oder gesamte Fachlogik) auf dem Client-System

• Hauptfunktion des Servers: Datenhaltung

• Entlastung des Servers

• Zusätzliche Anforderungen an Clients (z.B. Installation von Software)


Verteilungsmuster "Three-Tier Client/Server"

Client:

• Benutzungsschnittstelle

• evtl. Fachlogik

Anwendungsserver:

• evtl. Fachlogik

• Verteilung von Anfragen auf verschiedene Server

Server:

• Datenhaltung, Rechenleistung etc.

Kommunikation unter Servern meist breitbandig.

Anwendungs- Server

"Intelligenter" Client

Server


Verteilungsmuster "Föderation"

Gleichberechtigte Partner (peer-to-peer)

Unabhängigkeit von der Lokation und Plattform von Funktionen

Verteilte kommunizierende Objekte

Knoten 1 Knoten 2

Knoten 5

Knoten 4

Knoten 3


Cloud Computing

Abstraktion von konkreten IT-Resourcen (z. B. Rechenkapazität,

Datenspeicher, Netzwerkkapazitäten oder auch fertige Software)

Resourcen werden dynamisch nach Bedarf zur Verfügung gestellt.

Client Client

Client Client

Dienst Dienst

Dienst


Cloud Computing (2)

Üblicherweise Unterscheidung von 3 Ebenen der Cloud-Dienste:

• Infrastructure as a Service (IaaS):

• Zugang zu virtualisierten Hardware-Ressourcen, wie Rechnern,

Netzwerken und Speicher.

• Platform as a Service (PaaS):

• Zugang zu Programmierungs- oder Laufzeitumgebungen mit

flexiblen, dynamisch anpassbaren Rechen- und

Datenkapazitäten.

• Entwicklung eigener Software-Anwendungen innerhalb einer

Softwareumgebung, die vom Dienstanbieter (Service Provider)

bereitgestellt und unterhalten wird.

• Software as a Service (SaaS) oder Software on demand:

• Zugang zu Software-Bibliotheken und

Anwendungsprogrammen.


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


Steuerungsmuster "Call-Return"

Haupt- programm

Unter- programm 1

Unter- programm 1.1

Unter- programm 1.2


Steuerungsmuster "Master-Slave"

Manager Sensor Benutz.- oberfläche

Aktuator


Steuerungsmuster "Selective Broadcast"

Event Handler

Subsystem 2

Subsystem 1

Subsystem 3

Ereignis e

e e

e

e' e'

Ereignis e'

e'


Steuerungsmuster "Interrupt"

Interrupt Dispatcher

Handler 2

e

Handler 1

Prozess 2

e’

Prozess 1

Verwendet Interrupt-Vektor


Zusammenfassung Architekturmuster

Architekturmuster beschreiben erprobte Strukturierungsformen für

die Architektur eines Systems

Architekturmuster beschreiben:

• Entwurfsstruktur

• physikalische Verteilung

• Kommunikationsformen und –protokolle

Schichtenbildung ist ein mächtiges Strukturierungsmittel


Service-orientierte Architektur

Erleichterung der Entwicklung von großen

Unternehmenssystemen

Orientierung an Geschäftsprozessen

Integration von heterogenen Anwendungen

Bessere Anpassbarkeit, Erweiterbarkeit und Skalierbarkeit

Bessere Weiterentwickelbarkeit und Wartbarkeit

Die Service-orientierte Architektur (SOA) ist ein Architekturparadigma

mit folgenden Zielen:


Begriffsklärung

• “A service oriented architecture is a form of

distributed system architecture. It consists of a set

of components (services) which can be invoked,

and whose interface descriptions can be published

and discovered.”

• “A service is an abstract resource that represents a

capability of performing tasks that form a coherent

functionality from the point of view of provider and

requester entities.”

[nach W3C, 2004]


Services

Ein Service kapselt Zugriff auf die Funktionen und Daten einer

oder mehrerer Applikationen und erbringt bestimmte Leistung

gemäß der Service-Spezifikation.

Service-Spezifikation:

• Servicename und Operationsnamen

• Ein- und Ausgabedaten mit Typen

• Beschreibung der Funktionalität (meist textuell)

• Randbedingungen (Vor- und Nachbedingungen, Invarianten)

• Nicht-funktionale Eigenschaften (z.B. Performance)

• ggf. weitere Informationen (z.B. Release, Herkunft, ...)


Verwendung von Services

Service Provider (Anbieter):

• Bietet die Möglichkeit, Funktionen gemäß Spezifikation zu

nutzen

• Implementierung des Services unter Einhaltung der

Spezifikation austauschbar

Service User (Nutzer):

• Dem Service Provider ggf. unbekannt

• Kann Service auch anders nutzen, als vom Provider

vorgesehen

• Kann Funktion auch im Auftrag weiterer Nutzer ausführen


Service Directory

Aufgaben des Service Directory (Verzeichnis):

• Zentrale Verwaltung von Services

• Publikation von Service-Spezifikationen

• Kategorisierung von Services

• Schnittstellen für Suche nach Services


Referenzarchitektur

Service

Provider Service User

Service

Directory

➊ Spezifikation

publizieren

➋ Service suchen

➌ Spezifikation liefern

➍ Spezifikation abfragen

➎ Service nutzen ➎

“SOA-Dreieck”

Prof. Dr. Ina Schaefer Software Engineering 1 Seite 56 5

6

Web Services

Service

Provider

(WDSL)

Service

User

Service

Directory

(UDDI)

SOAP (über HTTP/SMTP)

SOAP = Simple Object Access Protocol

WDSL = Web Service Description Language

UDDI = Universal Description Discovery and Integration

Prof. Dr. Ina Schaefer Software Engineering 1 Seite 57 5

7

Designprinzipien

Schnittstellenorientierung:

Spezifikation abstrahiert von Implementierung.

Interoperabilität:

Einheitliche Kommunikationsstandards

Modularität:

Hohe Kohäsion im Service

Niedrige Kopplung zwischen Services

Bedarfsorientierung:

Leistungsumfang entspricht Prozessaktivitäten.


Zusammenfassung

Softwareentwurf – Ziele und Tätigkeiten

Architekturentwurf

• Prinzipien und Ziele

• 4-Sichten-Modell der Softwarearchitektur

• Architekturmuster für

• Entwurfssicht

• Verteilungssicht

• Ablaufsicht

• Grundbegriffe der Service-orientierten Architekturen

Software- und Systementwurf - TU Braunschweig · Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung und Anpassung. Frühere Ansätze zur Kohäsion wie: •ähnliche

Documents