Software- und Systementwurf - Technische Universität Braunschweig

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


Seite 3

Von der Analyse zum Entwurf Analyse! Anforderungs-" Ermittlung"

Anforderungs-" Spezifikation" (Lastenheft)"

System-" Spezifikation" (Pflichtenheft)"

System-" Modellierung"

Entwurf!

Dr. Ina Schaefer


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


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


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


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


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


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


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


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


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


Seite 13

Beispielarchitektur

Dr. Ina Schaefer


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


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


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


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/ Benutzeroberﬂäche GUI = Graphical User Interface = graﬁsche Benutzerschni7stelle Dr. Ina Schaefer


Seite 19

Komponenten optionaler grafischer Stereotyp

Name der Komponente

«component» HTTP

WebInterface Database

Webservice

benötigte Schnittstelle

bereitgestellte Schnittstelle

Dr. Ina Schaefer


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


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


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"


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


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Seite 44

Steuerungsmuster "Call-Return" Hauptprogramm

Dr. Ina Schaefer

Unterprogramm 1

Unterprogramm 1.1


Unterprogramm 1.2

Seite 45

Steuerungsmuster "Master-Slave" Manager

Dr. Ina Schaefer

Benutz.oberfläche

Sensor


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'


e'

Seite 47

Steuerungsmuster "Interrupt" Interrupt Dispatcher

Handler 1

Handler 2

e Prozess 2 e’ Prozess 1

Verwendet Interrupt-Vektor

Dr. Ina Schaefer


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


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


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


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


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


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


Seite 54

Referenzarchitektur ➍ Spezifikation abfragen Service User

➎ Service nutzen ➎

Service Provider

➋ Service suchen ➊ Spezifikation publizieren ➌ Spezifikation liefern Service Directory

Dr. Ina Schaefer


“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


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


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


Seite 58

Software- und Systementwurf - Technische Universität Braunschweig

Recommend Documents