OO Analyse und Entwurf für Anwender V. Systemarchitektur Dr. Michael Löwe

OO Analyse und Entwurf für Anwender

V. Systemarchitektur

Dr. Michael Löwe

Systemarchitektur Prof. Dr. Michael Löwe, FHDW, Hannover

2

Objektorientierte Analyse und Entwurf

Inhalt der Ausbildung

• Kennzeichen objektorientierter Softwareentwicklung (1)

• Projektorganisation (2)

• Architektur (2)

• Objektorientierte Analyse (4)

• Objektorientierter Entwurf (5)

• Realisierung und Test (2)


3


Lernziele

• Kenntnisse über allgemeine Rahmenbedingungen einer Software-Entwicklung

• Kennenlernen des Unterschieds zwischen – technischen Rahmenbedingungen (Systemarchitektur) und

– fachlichen Rahmenbedingungen (Anwendungsarchitektur)

• Inhalte und Form einer Anwendungsarchitektur• Inhalte und Form einer Systemarchitektur• Unterschied zw. OO-im-Großen und OO-im-Kleinen


4


Inhalt

• Anwendungsarchitektur vs. Systemarchitektur• Komponentenmodelle vs. Modelle für Komponenten• Stilrichtungen von Komponentenmodellen• Client-Server-Architektur

– Softwaretechnisch– Hardwaretechnisch– „Unsere“ Client/Server-Architektur

• WWW, (Dynamic) HTML, Browser und Java• Architektur der Datenhaltung• Zentrale Dienste einer Systemarchitektur


5


Anwendungs- vs. Systemarchitektur

Anwendungsarchitektur gehört zur Analyse wie Systemarchitektur zum Entwurf

Anwendungsarchitektur:Aufbau einer DV-Anwendungslandschaft aus fachlichen Komponenten und Schnittstellen

Systemarchitektur:Aufbau einer DV-Anwendungslandschaft aus technischen Komponenten und Schnittstellen


6


Darstellung: Systemarchitektur

BS2-ServerBS2-Server

FeuerFeuer

Unix-ServerUnix-Server

TransportTransport


RV-SystemRV-System


RVFRVFDaten-Daten-haltunghaltung

MFTMFT

RVF-FunktionenRVF-Funktionen

DBServerDBServer

RVF-OberflächeRVF-Oberfläche MFTMFT

RVF-EingangRVF-Eingang RVF-AusgangRVF-Ausgang

DBServerDBServer


7


Die zwei Dimensionen dieser Darstellung

BS2-ServerBS2-Server

FeuerFeuer


TransportTransport


RV-SystemRV-System


RVFRVFDaten-Daten-haltunghaltung

MFTMFT

RVF-FunktionenRVF-Funktionen

DBServerDBServer

RVF-OberflächeRVF-Oberfläche MFTMFT

RVF-EingangRVF-Eingang RVF-AusgangRVF-Ausgang

DBServerDBServer

DVS/FBDVS/FB DVS/TRDVS/TR

EingangEingang

RVFRVF

AusgangAusgang

RVARVA

Daten-haltung

Daten-haltung

Daten-haltung

Daten-haltung

OberflächeOberfläche

AnwendungslogikAnwendungslogik

GeschäftsobjekteGeschäftsobjekte

Arb

eits

plat

zrec

hner

Zentralrechner

Zerlegung inKomponenten

Zerlegung derKomponenten NetzNetz


8


Zwei Dimensionen der Systemarchitektur

Komponentenmodelle

• Technische Realisierung der Anwendungsarchitektur

• Aufbau eines Systems aus uniformen Teilen

• Zusammenspiel von unterschiedlich realisierten Komponenten

• Austauschbarkeit von Systemteilen

Modelle für Komponenten

• Technische Realisierung einer jeden Komponente

• Aufbau einer Komponente aus heterogenen Teilen

• Zusammenspiel und Realisierung von Oberfläche, Logik und Datenhaltung

• Austauschbarkeit von Komponententeilen


9


K 1

K 5

K 3K 4

K 2

Zwei Dimensionen der Systemarchitektur

– Austauschbarkeit –

K 2‘ DBMS 1

DBMS 1

DBMS 1

DBMS 1

DBMS 1

DBMS 2

DBMS 2

DBMS 2

DBMS 2

DBMS 2


10


Stilrichtungen für Systemarchitekturen

• Daten-basierte Architekturen

• Verteilte DiensteRemote Procedure Call (RPC)

• Verteilte ObjekteCommon Object Request Broker Architekture (CORBA)

• „Unsere“ Komponentenarchitektur


11


Daten-basierte Anwendungsarchitektur

Unternehmensweites DatenmodellUnternehmensweites Datenmodell

Anw

endu

ng I

Anw

endu

ng I

Anw

endu

ng I

IA

nwen

dung

II

Anw

endu

ng I

IIA

nwen

dung

III

Anw

endu

ng I

VA

nwen

dung

IV

Anw

endu

ng n

Anw

endu

ng n

• • • • • • •

Ablauf der AnwendungenAblauf der Anwendungen


12


Daten-basierte Architekturen

• Grundlage: einheitliches Datenmodell• Analysefokus: Unternehmensdaten• Trennung von Daten und Funktion• Alle Anwendungen gleichberechtigt

– kein fachliches Client/Server• Keine Funktionsschnittstellen • Ausschließlich Daten- und

Dialogschnittstellen• Kommunikation über das Datenmodell


13


Klassische Ho(r)st-Systemarchitektur

DatenbankmanagementsystemDatenbankmanagementsystem

Pro

gram

m I

Pro

gram

m I

Pro

gram

m I

IP

rogr

amm

II

Pro

gram

m I

IIP

rogr

amm

III

Pro

gram

m I

VP

rogr

amm

IV

Pro

gram

m n

Pro

gram

m n

• • • • • • •

TransaktionsmonitorTransaktionsmonitor


14


Architektur als Verteilte Dienste

Dienst VIDienst VI

Dienst IDienst I

Dienst IIIDienst III

Dienst IVDienst IV

Dienst IIDienst II

Dienst VIIDienst VII

Dienst VDienst V


15


Verteilte Dienste

• Grundlage: einheitliches Funktionsmodell• Analysefokus: Funktionszerlegung• Kaum erkennbare Anwendungen• Trennung von Funktion und Prozeß• Ausschließlich Funktionsschnittstellen• Keine Datenschnittstellen• Kommunikation über synchronen

Funktionsaufruf


16


Remote Procedure Call

Dienst I(Client)

Dienst I(Client)

Dienst II(Server)

Dienst II(Server)

Funktionspezifikationz.B. IDL in DCE

Server Stub

Client Stub

Transport-Infrastruktur

generiert

generiert

Client Program

Server Program

benutzt

benutzt

Ruft lokal auf

Ruft lokal auf Ergebnisrückgabe

Ergebnisrückgabe


17


Remote Procedure Call

• Realisiert diensteorientierte Anwendungsarchitektur• Systemweit einheitliche Funktionsspezifikation• Unterstützt heterogene Diensterealisierungen• Unterstützt unterschiedliche Plattformen• Dynamische Bindung von Servern möglich• Erhöhter Realisierungsaufwand• Performanzverluste durch Transportdienst


18


Verteilte Objekte

Dienst VIDienst VDienst VI

Daten II

Dienst VIIDienst IXDienst X

Daten III

Dienst IDienst IIDienst III

Daten I

Dienst XIDienst XIIDienst XIII

Daten IV


19


Verteilte Objekte

• Grundlage: einheitliches Objektmodell

• Analysefokus: Zusammenfassung von Daten und zugehörigen Diensten

• Anwendungen = Objekte-im-Großen

• Keine Datenschnittstellen

• Kommunikation über synchronen Nachrichtenaustausch


20


Komponenten in einer Architektur

Komponentenschnittstelle:Angebot (synchr.) DiensteVerarbeitbare asynchrone

Nachrichten

Gekapselte Funktionen:Inneres VerhaltenVerantwortlichkeiten

Gekapselte Daten:Innere ZuständeTeil am Gesamtdatenmodell

GekapseltDaten

GekapselteFunktionen

Schnittstelle


21


Schnittstellen in einer Architektur

Eigenständiger Vermittler zwischen Komponenten

Realisiert durch Diensteerbringer

Genutzt durch Dienstenachfrager

Vertrag zwischen fach-lichem Client und Server

Syn-chron

Asyn-chron

benutzt

realisiert


22


Object Request Broker (ORB)

Syn-chron

Asyn-chron

benutzt

realisiert

ORB (Transportdienst)IDLClient Stub

Server Stub

Language Mapping

Language Mapping


23


Object Request Broker (ORB)

• Realisiert objektorientierte Anwendungsarchitektur• Systemweit einheitliche Objektspezifikation

(OO-im-Großen)• Unterstützt heterogene Objektrealisierungen• Unterstützt unterschiedliche Plattformen• Dynamische Bindung von Servern möglich• Erhöhter Realisierungsaufwand• Performanzverluste durch Transportdienst• Standard und doch kein Standard (Inter-ORB-Protokoll)

• Derzeit die Systemarchitektur mit größter Flexibilität


24


OO-im-Großen vs. OO-im-Kleinen

OO-im-Kleinen• Realisierung von

Einzelobjekte• Material u. Werkzeug• Datenobjekte• Beispiele:

– Adresse– Auftrag– Verteilplan

OO-im-Großen• Zusammenfassung

gleichartiger Objekte• Management• Managerobjekte• Beispiele:

– Adressverwaltung– Auftragsverwaltung– F+B-Management


25


Beispiel: Workflow „unter“ ORB

Arbeitsflüsse: Ereignisse, Vorgänge, Prozesse etc.Arbeitsflüsse: Ereignisse, Vorgänge, Prozesse etc.

Fun

ktio

n I

Fun

ktio

n I

Fun

ktio

n II

Fun

ktio

n II

Fun

ktio

n II

IF

unkt

ion

III

Fun

ktio

n IV

Fun

ktio

n IV

Fun

ktio

n V

Fun

ktio

n V

Fun

ktio

n V

IF

unkt

ion

VI

Fun

ktio

n n-

1F

unkt

ion

n-1

Fun

ktio

n n

Fun

ktio

n n

Datenbestände


26


Beispiel: Workflow „unter“ ORB

Objekt Request Broker

Workflow

Funktion n Funktion II IV, VI, n-1Funktion V I und III

Server 1 Server 2 Server 3 Server 4 Server 5

Client 1 Client 2 Client 3 Client 4 Client 5


27


„Unsere“ Komponentenarchitektur

Rahmenanwendung (in SmallTalk): Navigieren, Suchen und Beziehungsaufbau

Anwendung I Anwendung II

Objektwelt IIObjektwelt IEntfernte Beziehung

Anwendung III

Objektwelt III

registrieren

Dienste I Dienste II Dienste III


28


Client/Server-ArchitekturSoftwaretechnisch

Syn-chron

Asyn-chron

benutzt

realisiert

Hardwaretechnisch

Netz


29


C/S – hardwaretechnisch –

• Abgrenzung zu „Alles passiert auf einem Rechner“• Trennung „Single-User“ von „Multi-User“• Hardware-Struktur soll orthogonal zu Software-

Struktur sein• Wer Client und Server ist, entscheidet die Software• Client/Server in Hardware behindert die Architektur

– Mainframe ist Datenserver für PC– PC ist Textserver für Mainframe

• Client/Server versus Distributed Computing


30


Unsere Client/Server-Struktur

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Oberfläche, Anwendungslogik und Persistenzschicht in SmallTalk (VA)


DBServer (SQL + TM)DBServer (SQL + TM)DDEDDE

TCP/IP-Netz

PC


31


Unsere Client/Server-Struktur

• Fat Client• Kapselung der DBMS-Klienten

Server: Informix, Oracle, Sybase, Upic/UTMClient: VA, VSE, ISA-DM, C, Word

• BetriebssystemeServer: Unix oder NT oder BS2000 oder ....Client: NT (Desktop oder Winframe-Server)

• Batchverarbeitung in derselben (Hardware-) Architektur(Z. B. Textformatierung oder Auftragskommunikator)


32


Architektur mit Anwendungsserver

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Oberfläche, Anwendungs-logik und Persistenzschicht

in SmallTalk (VA)

Oberfläche, Anwendungs-logik und Persistenzschicht

in SmallTalk (VA)

DBServer (SQL + TM)DBServer (SQL + TM)

DDEDDE

TCP/IP-Netz

PC

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

TCP/IP-Netz

PC

Oberfläche

PC

Oberfläche

TCP/IP-Netz

AnwendungslogikAnwendungslogik

GeschäftsobjekteGeschäftsobjekte


33


Architektur mit Anwendungsserver

Vorteile+ Softwareverteilung+ Datensicherheit+ Verfügbarkeit+ Skalierbarkeit+ Netzwerkfähigkeit+ Ressourcen-Sharing+ Administration+ Operating+ Schnelle Netzte

Nachteile– Multi-User– Konkurrenz


34


Beispiel: Winframe

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server

Datenbank-Server



DBServer (SQL + TM)DBServer (SQL + TM)DDEDDE

TCP/IP-Netz

Anw

endu

ngs-

serv

er

TCP/IP-Netz, WAN

NT-OberflächenemulationNT-Oberflächenemulation


35


WWW, HTML, Browser und Java

Verteilte Klassen versus verteilte Objekte


36


Architektur der Datenhaltung

• DBMS-Clustering

• DB Verteilung– DB Fragmentierung

• horizontal

• vertikal

– DB Replikation• asymmetrisch

• symmetrisch


37


FragmentierungHorizontal Vertikal

GesamtbestandTeilbestand

Teilbestand

TeilbestandG

esam

tinf

orm

atio

n

Tei

linf

orm

atio

n

Tei

linf

orm

atio

n


38


ReplikationAsymmetrisch

Original-bestand

Kopie vomOriginal-bestand

Symmetrisch

Original-bestand I

Original-bestand II

¿ Konflikte ?


39


Architektur der Datenhaltung

Empfehlungen:– Zentraler Bestand– Jedes Datum möglichst nur einmal– Keine selbstverwalteten Spiegelbestände– Replikation nur asymmetrisch zum Lesen

• Datenkaufhaus

• WWW

– Clustering und Fragmentierung zum Tuning


40


Zentrale Dienste einer Systemarchitektur

• Global Directory aller Principals– Nutzer und – Rechner

• Time-Service• Security Services• Transaktionsdienste• Suchdienste


41


Zusammenfassung

Systemarchitekturen haben zwei Dimensionen– Technische Realisierung der Anwendungsarchitektur– Verfeinerte technische Strukturierung der einzelnen

Komponenten einer Anwendungsarchitektur

Systemarchitekturen beschreiben– den Aufbau eines Systems aus Softwarekomponenten– die Hardware-Architektur– die Abbildung der Software- auf die Hardware-Architektur

Systemarchitekturen beschreiben insbesondere Mangement der Daten

Documents

OO Analyse und Entwurf für Anwender V. Systemarchitektur Dr. Michael Löwe