Software- und Systementwurf - tu-braunschweig.de · Software Systems Engineering Technische...

Dr. Ina Schaefer Software Systems Engineering

Technische Universität Braunschweig

(mit Folien von Prof. B. Rumpe)

Software- und Systementwurf - Softwarearchitektur -

Software Engineering 1

WS 2011/2012

Dr. Ina Schaefer Software Engineering 1 Seite 2

Überblick

§  Softwareentwurf •  Ziele •  Entwurfsprinzipien

§  Architekturentwurf

§  Architekturmuster

§  Service-orientierte Architekturen


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


Entwurf!

Von der Analyse zum Entwurf

Analyse!

Anforderungs-"Ermittlung"

Anforderungs-"Spezifikation"(Lastenheft)"

System-"Spezifikation"(Pflichtenheft)"

System-"Modellierung"


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 klardefiniert.(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 = Benutzerschni7stelle/ Benutzeroberfläche GUI = Graphical User Interface = grafische Benutzerschni7stelle


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”

Dr. Ina Schaefer Software Engineering 1 Seite 56 56

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

Dr. Ina Schaefer Software Engineering 1 Seite 57 57

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.de · Software Systems Engineering Technische...

Documents

Transcript of Software- und Systementwurf - tu-braunschweig.de · Software Systems Engineering Technische...