Software- und Systementwurf - Technische Universität Braunschweig

Dr. Ina Schaefer. Software Engineering 1. Seite 33. Variante: 3-Schichten- Referenzarchitektur. ▫ Beispiele für Systemfunktionen: • Verkapselung von p...

24 downloads 191 Views 550KB Size
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 •  •  •  • 

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! Anforderungs-" Ermittlung"

Anforderungs-" Spezifikation" (Lastenheft)"

System-" Spezifikation" (Pflichtenheft)"

System-" Modellierung"

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! Anforderungs-" Ermittlung"

Anforderungs-" Spezifikation" (Lastenheft)"

System-" Spezifikation" (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

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

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

Entwurfssicht

•  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  =  Benutzerschni7stelle/  Benutzeroberfläche   GUI  =  Graphical  User  Interface  =  grafische  Benutzerschni7stelle   Dr. Ina Schaefer

Software Engineering 1

Seite 19

Komponenten optionaler grafischer Stereotyp

Name der Komponente

«component» HTTP

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

<>" Client"

<> local network"

<>" Server 1"

<>" Server 2"

A"

Dr. Ina Schaefer

Komponenten können zugeordnet werden

B"

Software Engineering 1

Seite 23

Beispiel Terminverwaltung PC1"

..." PCn"

Termin-" Server"

PDA1"

PDAm"

Physikalische! Konfiguration"

Anzeigetafel-" Steuerung"

PC Client" PDA Client" PDA Sync"

Blockdiagramm"

Termin-Manager"

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

Subsystem A! " (z.B. Benutzungs-" oberflä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.

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: Subsystem

Datenfluss-Schnittstelle 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

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

QuellProgramm

Tokens Scanner

Symboltabelle

Syntaxbaum Parser

Fehlermeldungen

ZielProgramm

CodeGenerator

FehlerAusgabe Fehlermeldungen

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 Systemfunktionen 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) •  Fordert Update des Models an •  Sendet Nutzereingaben an Controller Dr. Ina Schaefer

Model (Datenhaltung) •  Benachrichtigt über Änderungen

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

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.

Dr. Ina Schaefer

Software Engineering 1

Seite 40

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

Dr. Ina Schaefer

Client

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

Dr. Ina Schaefer

Unterprogramm 1

Unterprogramm 1.1

Software Engineering 1

Unterprogramm 1.2

Seite 45

Steuerungsmuster "Master-Slave" Manager

Dr. Ina Schaefer

Benutz.oberfläche

Sensor

Software Engineering 1

Aktuator

Seite 46

Steuerungsmuster "Selective Broadcast" Event Handler

Subsystem 1

Ereignis e e

Subsystem 2

e

Subsystem 3

e

Ereignis e' e'

Dr. Ina Schaefer

e'

Software Engineering 1

e'

Seite 47

Steuerungsmuster "Interrupt" Interrupt Dispatcher

Handler 1

Handler 2

e 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 User

➎ Service nutzen ➎

Service Provider

➋ Service suchen ➊ Spezifikation publizieren ➌ Spezifikation liefern Service Directory

Dr. Ina Schaefer

Software Engineering 1

“SOA-Dreieck”

Seite 55

Web Services

Service User

SOAP (über HTTP/SMTP)

Service Provider (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