Upload
ngohanh
View
216
Download
0
Embed Size (px)
Citation preview
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
Dr. Ina Schaefer Software Engineering 1 Seite 3
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 4
Entwurf!
Von der Analyse zum Entwurf
Analyse!
Anforderungs-"Ermittlung"
Anforderungs-"Spezifikation"(Lastenheft)"
System-"Spezifikation"(Pflichtenheft)"
System-"Modellierung"
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)
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↔...
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).
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
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
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
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"
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
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.
Dr. Ina Schaefer Software Engineering 1 Seite 14
Beispielarchitektur
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
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
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
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 klardefiniert.(z.B. Aufrufschnittstelle,Kommunikationsprotokoll)"
Umfassendes Subsystem
Schnittstelle
Subsystem
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 = Benutzerschni7stelle/ Benutzeroberfläche GUI = Graphical User Interface = grafische Benutzerschni7stelle
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
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
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
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)
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
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
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)"
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
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
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
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
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“
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
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
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“
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
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
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
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
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)
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
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
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
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.
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
Dr. Ina Schaefer Software Engineering 1 Seite 45
Steuerungsmuster "Call-Return"
Haupt- programm
Unter- programm 1
Unter- programm 1.1
Unter- programm 1.2
Dr. Ina Schaefer Software Engineering 1 Seite 46
Steuerungsmuster "Master-Slave"
Manager Sensor Benutz.- oberfläche Aktuator
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'
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
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
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:
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]
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, ...)
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
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
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”
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.
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