Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 3
Entwurf
Von der Analyse zum Entwurf
Analyse
Anforderungs- Ermittlung
Anforderungs- Spezifikation (Lastenheft)
System- Spezifikation (Pflichtenheft)
System- Modellierung
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 4
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 5
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 6
Arbeitsteilung beim Entwurf
Architekturentwurf
Entwurf Subsystem 1
Entwurf Subsystem 2
Entwurf Subsystem ...
Entwurf der Komponenten
Entwurf Schnittstelle 1 2
Entwurf Schnittstelle 2 ...
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 7
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).
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 8
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 9
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 10
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 11
Entwurf
Entwurfsschritte
Analyse
Anforderungs- Ermittlung
Anforderungs- Spezifikation (Lastenheft)
System- Spezifikation (Pflichtenheft)
System- Modellierung Architektur-
Spezifikation
Architektur- Entwurf
Klassen- bzw. Modul- Spezifikationen
Detail- Entwurf
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 12
Anforderungs-
analyse,
Domänenanalyse
Entwurf der
Softwarearchitektur
Entwurf der
Systemarchitektur,
Auswahl der
Hardware
Feindesign,
Programmierung,
Integration, Testen,
Auslieferung
Architekturentwurf im Kontext der SW-Entwicklung
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 13
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 15
„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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 16
Bestandteile der 4+1 Sichten
Logische Sicht Entwurfssicht
Ablaufsicht Physikalische Sicht
Grobentwurf
Feinentwurf
Szenarien • Use-Cases
• Klassenmodell • Verfeinerung des Analysemodells
• Prozesse • Koordination
• Subsysteme • Schnittstellen
• Komponenten • Hardwaresysteme • Netze
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 17
Primäre Zielgruppe und Aufgabe der Sichten
Logische Sicht Entwurfssicht
Ablaufsicht Physikalische Sicht
• Endanwender • Programmierung • Wartung
• System-Integratoren (Performanz, Durchsatz ...)
• Kommunikation • Verteilung • Auslieferung, Installation
Grobentwurf
Feinentwurf
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 18
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 19
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 20
Komponenten
optionaler grafischer Stereotyp Name der
Komponente
bereitgestellte Schnittstelle
benötigte Schnittstelle
«component»
WebInterface
Database
Webservice
HTTP
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 21
Komposition von Komponenten
Komponente
bereitgestellte Schnittstelle
Zusammengesetzte Komponente
C B
A
D Port
benötigte Schnittstelle
A
C B
D
analoges Blockdiagramm
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 22
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 23
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 24
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 25
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 26
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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 27
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 28
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 29
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
Zwischen- produkt 1.2
Zwischen- produkt 2.1
Zwischen- produkt 2.2
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 30
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 31
Architekturmuster "Schichten"
Jede Schicht bietet Dienste (nach oben) und nutzt Dienste (von unten)
Beispiele:
• Kommunikationsprotokolle
• Datenbanksysteme, Betriebssysteme
Systemkern
Schicht 1
Schicht 2
„Benutzer“
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 32
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 33
Variante: 3-Schichten-Referenzarchitektur
Beispiele für Systemfunktionen:
• Verkapselung von plattformspezifischen Funktionen
• Schnittstellen zu Fremdsystemen
Persistenzschicht
Fachlicher Kern
Benutzungsschnittstelle
System- funktionen
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 34
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“
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 35
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 36
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 37
Verteilungsmuster "Zentrales System"
Beispiele:
• Klassische Großrechner-("Mainframe"-)Anwendungen
• Noch einfachere Variante: Lokale PC-Anwendungen (identifizieren Zentrale und Terminal)
Zentrales System
"Unintelligentes" Terminal
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 38
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 39
"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)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 40
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 41
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 42
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 43
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 44
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 45
Steuerungsmuster "Call-Return"
Haupt- programm
Unter- programm 1
Unter- programm 1.1
Unter- programm 1.2
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 46
Steuerungsmuster "Master-Slave"
Manager Sensor Benutz.- oberfläche
Aktuator
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 47
Steuerungsmuster "Selective Broadcast"
Event Handler
Subsystem 2
Subsystem 1
Subsystem 3
Ereignis e
e e
e
e' e'
Ereignis e'
e'
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 48
Steuerungsmuster "Interrupt"
Interrupt Dispatcher
Handler 2
e
Handler 1
Prozess 2
e’
Prozess 1
Verwendet Interrupt-Vektor
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 49
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 50
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:
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 51
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]
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 52
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, ...)
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 53
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
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 54
Service Directory
Aufgaben des Service Directory (Verzeichnis):
• Zentrale Verwaltung von Services
• Publikation von Service-Spezifikationen
• Kategorisierung von Services
• Schnittstellen für Suche nach Services
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 55
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.
Prof. Dr. Ina Schaefer Software Engineering 1 Seite 58
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