Software- und Systementwurf

- Softwarearchitektur -
Software Engineering 1
WS 2011/2012

Dr. Ina Schaefer

Software Systems Engineering
Technische Universität Braunschweig

(mit Folien von Prof. B. Rumpe)

 Überblick

§  Softwareentwurf
•  Ziele
•  Entwurfsprinzipien

§  Architekturentwurf

§  Architekturmuster

§  Service-orientierte Architekturen

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
•  Baustein für ein Softwaresystem (z.B. Modul, Klasse, Paket)
•  benutzt andere Komponenten
•  wird von anderen Komponenten benutzt
•  kann auch aus Unterkomponenten bestehen

Dr. Ina Schaefer Software Engineering 1 Seite 3

 Von der Analyse zum Entwurf
Analyse!
Anforderungs-" System-"
Anforderungs-" Spezifikation" Spezifikation"
Ermittlung" (Lastenheft)" (Pflichtenheft)"

System-"
Modellierung"

Entwurf!

Dr. Ina Schaefer Software Engineering 1 Seite 4

 Gliederung des Entwurfsprozesses

§  Architekturentwurf Gesamtstruktur

§  Subsystem-Spezifikation des Systems
(Grobentwurf)
§  Schnittstellen-Spezifikation

§  Komponentenentwurf Detailstruktur

§  Datenstrukturentwurf des Systems
(Feinentwurf)
§  Algorithmenentwurf

§  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 Entwurf
Schnittstelle Schnittstelle
1↔2 2↔...
Entwurf Entwurf Entwurf
Subsystem 1 Subsystem 2 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!
Anforderungs-" System-"
Anforderungs-" Spezifikation" Spezifikation"
Ermittlung" (Lastenheft)" (Pflichtenheft)"

System-"
Modellierung" Architektur-"
Spezifikation"

Architektur-"
Entwurf"

Entwurf! Detail-"
Entwurf"
Klassen- bzw. Modul-"
Spezifikationen"
Dr. Ina Schaefer Software Engineering 1 Seite 11
 Architekturentwurf im Kontext der SW-Entwicklung

Entwurf der
Anforderungs-
Entwurf der 
 Systemarchitektur,

analyse, 

Softwarearchitektur" Auswahl der
Domänenanalyse"
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, 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.
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 Entwurfssicht

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 Entwurfssicht

•  Klassenmodell •  Subsysteme
•  Verfeinerung des •  Schnittstellen
Analysemodells
Szenarien
•  Use-Cases Grobentwurf

Ablaufsicht Physikalische Sicht

•  Prozesse •  Komponenten
•  Koordination •  Hardwaresysteme
•  Netze

Feinentwurf

Dr. Ina Schaefer Software Engineering 1 Seite 16

 Primäre Zielgruppe und Aufgabe der Sichten

Logische Sicht Entwurfssicht

•  Endanwender •  Programmierung
•  Wartung

Grobentwurf

Ablaufsicht Physikalische Sicht

•  System-Integratoren •  Kommunikation
(Performanz, •  Verteilung
Durchsatz ...) •  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 Umfassendes
Subsystem

Dr. Ina Schaefer 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  =  Benutzerschni7stelle/  Benutzeroberfläche  

GUI  =  Graphical  User  Interface  =  grafische  Benutzerschni7stelle  

Dr. Ina Schaefer Software Engineering 1 Seite 19

 Komponenten

optionaler
grafischer
Name der Stereotyp
Komponente
«component»
WebInterface
HTTP

Database

Webservice

bereitgestellte benötigte
Schnittstelle Schnittstelle

Dr. Ina Schaefer Software Engineering 1 Seite 20

 Komposition von Komponenten
Zusammengesetzte!
Komponente! Komponente!
Port! D"

A"
benötigte!
Schnittstelle! bereitgestellte!
Schnittstelle!

B" C"
D"
A"

analoges
Blockdiagramm B" C"

Dr. Ina Schaefer Software Engineering 1 Seite 21

 Konfigurationsdiagramme
§  Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML!
§  Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur
Beschreibung der physikalischen Verteilung von System-
Komponenten.

Rechner, Knoten

Datenkommunikations-
Speicherndes Netz
Lokales
Kommunikationsnetz System

Dr. Ina Schaefer Software Engineering 1 Seite 22

 UML: Verteilungsdiagramm
§  engl.: deployment diagram
§  zeigt die physische Verteilung von Systemen

Stereotypen kennzeichnen
Node die Arten von Knoten
(Knoten) <<processor>>"
Client"

<<network>> local network"

<<processor>>" <<processor>>"
Server 1" Server 2" Komponenten können
zugeordnet werden
A" B"

Dr. Ina Schaefer Software Engineering 1 Seite 23

 Beispiel Terminverwaltung

PDA1" PDAm" Physikalische!

PC1" ..." PCn" Konfiguration"

Termin-" Anzeigetafel-"
Server" Steuerung"

PC Client" PDA Client"

Blockdiagramm" PDA Sync"

Daten-"
Termin-Manager" Export"

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

§  Hohe Kohäsion:

Subsystem A! Subsystem B darf keine Information
" und Funktionalität enthalten, die zum
(z.B. Benutzungs-" Zuständigkeitsbereich von A gehört
oberfläche)" und umgekehrt.

§  Niedrige Kopplung:

Es muss möglich sein, Subsystem A
weitgehend auszutauschen oder zu
Subsystem B! verändern, ohne Subsystem B zu
!
(z.B. fachlicher Kern)"
verändern.
Änderungen von Subsystem B sollten
nur möglichst einfache Änderungen
in Subsystem A nach sich ziehen.

Dr. Ina Schaefer 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 Entwurfssicht
§  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
•  Model-View-Controller (MVC)

Dr. Ina Schaefer Software Engineering 1 Seite 28

 Architekturmuster „Pipes & Filters“

Phase 2.1

Phase 1 Phase 3

Phase 2.2

Zwischen- Zwischen- Zwischen- Zwischen-

produkt 1.1 produkt 1.2 produkt 2.1 produkt 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
§  Instanz von „Pipes & Filters“: Kombination von Ketten

Quell- Ziel-
Programm Tokens Syntaxbaum Programm

Scanner Parser Code-

Generator

Symbol- Fehler- Fehler-

tabelle meldungen Ausgabe

Fehler-
meldungen

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
 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 32
 Variante: 3-Schichten-Referenzarchitektur

Benutzungsschnittstelle

Fachlicher Kern
System-
funktionen
Persistenzschicht

§  Beispiele für Systemfunktionen:

•  Verkapselung von plattformspezifischen Funktionen
•  Schnittstellen zu Fremdsystemen

Dr. Ina Schaefer Software Engineering 1 Seite 33

 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 34

 Model-View-Controller
Controller (Programmsteuerung)
•  Wählt View aus
•  Bildet Nutzereingaben auf Modelupdates ab

View (Darstellung der Daten) Model (Datenhaltung)

•  Fordert Update des Models an •  Benachrichtigt über Änderungen
•  Sendet Nutzereingaben an Controller

Dr. Ina Schaefer Software Engineering 1 Seite 35

 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
•  Cloud Computing

Dr. Ina Schaefer Software Engineering 1 Seite 36

 Verteilungsmuster "Zentrales System"

"Unintelligentes" Zentrales
Terminal System

§  Beispiele:
•  Klassische Großrechner-("Mainframe"-)Anwendungen
•  Noch einfachere Variante:
Lokale PC-Anwendungen (identifizieren Zentrale und Terminal)

Dr. Ina Schaefer Software Engineering 1 Seite 37

 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 38

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

Dr. Ina Schaefer Software Engineering 1 Seite 39

 Verteilungsmuster "Three-Tier Client/Server"

"Intelligenter" Anwendungs- Server

Client Server

§  Client:
•  Benutzungsschnittstelle
•  evtl. Fachlogik
§  Anwendungsserver:
•  evtl. Fachlogik
•  Verteilung von Anfragen auf verschiedene Server
§  Server:
•  Datenhaltung, Rechenleistung etc.
§  Kommunikation unter Servern meist breitbandig.

Dr. Ina Schaefer Software Engineering 1 Seite 40

 Verteilungsmuster "Föderation"

Knoten 1 Knoten 2

Knoten 5 Knoten 3

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 41
 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

Dienst
Dienst

Dienst

Client Client

Dr. Ina Schaefer Software Engineering 1 Seite 42

 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.

Dr. Ina Schaefer Software Engineering 1 Seite 43

 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 44

 Steuerungsmuster "Call-Return"
Haupt- Unter- Unter- Unter-
programm programm 1 programm 1.1 programm 1.2

Dr. Ina Schaefer Software Engineering 1 Seite 45

 Steuerungsmuster "Master-Slave"
Benutz.-
Manager Sensor Aktuator
oberfläche

Dr. Ina Schaefer Software Engineering 1 Seite 46

 Steuerungsmuster "Selective Broadcast"

Event Subsystem Subsystem Subsystem

Handler 1 2 3

Ereignis e
e
e
e

Ereignis e'
e'
e'
e'

Dr. Ina Schaefer Software Engineering 1 Seite 47

 Steuerungsmuster "Interrupt"
Interrupt Handler Handler
Dispatcher 1 2

Prozess
2
e’
Prozess
1

Verwendet
Interrupt-Vektor

Dr. Ina Schaefer Software Engineering 1 Seite 48

 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

Dr. Ina Schaefer Software Engineering 1 Seite 49

 Service-orientierte Architektur

Die Service-orientierte Architektur (SOA) ist ein Architekturparadigma

mit folgenden Zielen:

§  Erleichterung der Entwicklung von großen

Unternehmenssystemen
§  Orientierung an Geschäftsprozessen
§  Integration von heterogenen Anwendungen
§  Bessere Anpassbarkeit, Erweiterbarkeit und Skalierbarkeit
§  Bessere Weiterentwickelbarkeit und Wartbarkeit

Dr. Ina Schaefer Software Engineering 1 Seite 50

 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]

Dr. Ina Schaefer Software Engineering 1 Seite 51

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

Dr. Ina Schaefer Software Engineering 1 Seite 52

 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

Dr. Ina Schaefer Software Engineering 1 Seite 53

 Service Directory

Aufgaben des Service Directory (Verzeichnis):

•  Zentrale Verwaltung von Services

•  Publikation von Service-Spezifikationen

•  Kategorisierung von Services

•  Schnittstellen für Suche nach Services

Dr. Ina Schaefer Software Engineering 1 Seite 54

 Referenzarchitektur

➍ Spezifikation abfragen

Service
Service User ➎ Service nutzen ➎
Provider

➋ Service suchen

➊ Spezifikation
publizieren
➌ Spezifikation liefern

Service
Directory
“SOA-Dreieck”

Dr. Ina Schaefer Software Engineering 1 Seite 55

 Web Services

Service
Service SOAP (über HTTP/SMTP)
Provider
User
(WDSL)

Service
Directory
(UDDI)

SOAP = Simple Object Access Protocol

WDSL = Web Service Description Language
UDDI = Universal Description Discovery and Integration
Dr. Ina Schaefer Software Engineering 1
5
Seite 56
 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.

Dr. Ina Schaefer Software Engineering 1 5

Seite 57
 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

Dr. Ina Schaefer Software Engineering 1 Seite 58