Oo analyse und entwurf f r anwender
This presentation is the property of its rightful owner.
Sponsored Links
1 / 41

OO Analyse und Entwurf für Anwender PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

OO Analyse und Entwurf für Anwender. V. Systemarchitektur Dr. Michael Löwe. Inhalt der Ausbildung. Kennzeichen objektorientierter Softwareentwicklung (1) Projektorganisation (2) Architektur (2) Objektorientierte Analyse (4) Objektorientierter Entwurf (5) Realisierung und Test (2).

Download Presentation

OO Analyse und Entwurf für Anwender

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Oo analyse und entwurf f r anwender

OO Analyse und Entwurf für Anwender

V. Systemarchitektur

Dr. Michael Löwe


Inhalt der ausbildung

Inhalt der Ausbildung

  • Kennzeichen objektorientierter Softwareentwicklung (1)

  • Projektorganisation (2)

  • Architektur (2)

  • Objektorientierte Analyse (4)

  • Objektorientierter Entwurf (5)

  • Realisierung und Test (2)

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


Lernziele

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

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


Inhalt

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

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


Anwendungs vs systemarchitektur

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

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


Darstellung systemarchitektur

RVF-Oberfläche

RVF-Eingang

RVF-Ausgang

RVF-Funktionen

DBServer

Darstellung: Systemarchitektur

MFT

MFT

DBServer

Transport

Feuer

RV-System

RVF

Daten-

haltung

Unix-Server

BS2-Server

Unix-Server

Unix-Server

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


Die zwei dimensionen dieser darstellung

RVF-Oberfläche

MFT

MFT

RVF-Eingang

RVF-Ausgang

RVF-Funktionen

DBServer

Transport

DBServer

Feuer

RV-System

RVF

Daten-

haltung

Unix-Server

BS2-Server

Unix-Server

Unix-Server

Die zwei Dimensionen dieser Darstellung

DVS/FB

DVS/TR

Oberfläche

Anwendungslogik

Arbeitsplatzrechner

Eingang

Geschäftsobjekte

RVF

Zerlegung in

Komponenten

Zerlegung der

Komponenten

Netz

Daten-

haltung

Daten-

haltung

Ausgang

RVA

Zentralrechner

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


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

Zwei Dimensionen der Systemarchitektur

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


Zwei dimensionen der systemarchitektur1

DBMS 2

K 1

DBMS 1

DBMS 2

DBMS 1

DBMS 2

DBMS 2

K 4

K 3

DBMS 1

DBMS 1

DBMS 2

K 5

DBMS 1

Zwei Dimensionen der Systemarchitektur

– Austauschbarkeit –

K 2‘

K 2

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


Stilrichtungen f r systemarchitekturen

Stilrichtungen für Systemarchitekturen

  • Daten-basierte Architekturen

  • Verteilte Dienste

    Remote Procedure Call (RPC)

  • Verteilte Objekte

    Common Object Request Broker Architekture (CORBA)

  • „Unsere“ Komponentenarchitektur

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


Daten basierte anwendungsarchitektur

Daten-basierte Anwendungsarchitektur

Ablauf der Anwendungen

Anwendung I

Anwendung II

Anwendung III

Anwendung IV

Anwendung n

• • • • • • •

Unternehmensweites Datenmodell

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


Daten basierte architekturen

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

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


Klassische ho r st systemarchitektur

Klassische Ho(r)st-Systemarchitektur

Transaktionsmonitor

Programm I

Programm II

Programm III

Programm IV

Programm n

• • • • • • •

Datenbankmanagementsystem

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


Architektur als verteilte dienste

Architektur als Verteilte Dienste

Dienst I

Dienst II

Dienst V

Dienst III

Dienst IV

Dienst VII

Dienst VI

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


Verteilte dienste

Verteilte Dienste

  • Grundlage: einheitliches Funktionsmodell

  • Analysefokus: Funktionszerlegung

  • Kaum erkennbare Anwendungen

  • Trennung von Funktion und Prozeß

  • Ausschließlich Funktionsschnittstellen

  • Keine Datenschnittstellen

  • Kommunikation über synchronen Funktionsaufruf

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


Remote procedure call

Remote Procedure Call

Dienst I

(Client)

Client Program

Ruft lokal auf

Ergebnisrückgabe

Client Stub

generiert

benutzt

Funktionspezifikation

z.B. IDL in DCE

Transport-

Infrastruktur

benutzt

generiert

Server Stub

Ruft lokal auf

Ergebnisrückgabe

Dienst II

(Server)

Server Program

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


Remote procedure call1

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

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


Verteilte objekte

Dienst VI

Dienst V

Dienst VI

Dienst VII

Dienst IX

Dienst X

Dienst I

Dienst II

Dienst III

Dienst XI

Dienst XII

Dienst XIII

Daten II

Daten III

Daten I

Daten IV

Verteilte Objekte

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


Verteilte objekte1

Verteilte Objekte

  • Grundlage: einheitliches Objektmodell

  • Analysefokus: Zusammenfassung von Daten und zugehörigen Diensten

  • Anwendungen = Objekte-im-Großen

  • Keine Datenschnittstellen

  • Kommunikation über synchronen Nachrichtenaustausch

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


Komponenten in einer architektur

Komponenten in einer Architektur

Komponentenschnittstelle:

Angebot (synchr.) Dienste

Verarbeitbare asynchrone Nachrichten

Gekapselte Funktionen:

Inneres Verhalten

Verantwortlichkeiten

Gekapselte Daten:

Innere Zustände

Teil am Gesamtdatenmodell

Schnittstelle

Gekapselte

Funktionen

Gekapselt

Daten

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


Schnittstellen in einer architektur

benutzt

Syn-

chron

Asyn-

chron

realisiert

Schnittstellen in einer Architektur

Eigenständiger Vermittler zwischen Komponenten

Realisiert durch Diensteerbringer

Genutzt durch Dienstenachfrager

Vertrag zwischen fach-lichem Client und Server

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


Object request broker orb

Object Request Broker (ORB)

Language Mapping

benutzt

Client Stub

Syn-

chron

Asyn-

chron

IDL

ORB (Transportdienst)

Server Stub

realisiert

Language Mapping

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


Object request broker orb1

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

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


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

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

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


Beispiel workflow unter orb

Beispiel: Workflow „unter“ ORB

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

Funktion I

Funktion II

Funktion III

Funktion IV

Funktion V

Funktion VI

Funktion n-1

Funktion n

Datenbestände

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


Beispiel workflow unter orb1

Workflow

Objekt Request Broker

Server 1

Client 1

Client 2

Server 2

Client 3

Server 3

Client 4

Server 4

Server 5

Client 5

Funktion n

Funktion V

IV, VI, n-1

I und III

Funktion II

Beispiel: Workflow „unter“ ORB

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


Unsere komponentenarchitektur

„Unsere“ Komponentenarchitektur

Rahmenanwendung (in SmallTalk):

Navigieren, Suchen und Beziehungsaufbau

registrieren

Anwendung I

Anwendung II

Anwendung III

Dienste I

Dienste II

Dienste III

Objektwelt I

Objektwelt II

Objektwelt III

Entfernte

Beziehung

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


Client server architektur

Client/Server-Architektur

Softwaretechnisch

Hardwaretechnisch

benutzt

Netz

Syn-

chron

Asyn-

chron

realisiert

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


C s hardwaretechnisch

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

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


Unsere client server struktur

Oberfläche, Anwendungslogik und

Persistenzschicht in SmallTalk (VA)

DDE

DBServer (SQL + TM)

Unsere Client/Server-Struktur

PC

TCP/IP-Netz

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

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


Unsere client server struktur1

Unsere Client/Server-Struktur

  • Fat Client

  • Kapselung der DBMS-Klienten

    Server: Informix, Oracle, Sybase, Upic/UTM

    Client: VA, VSE, ISA-DM, C, Word

  • Betriebssysteme

    Server: Unix oder NT oder BS2000 oder ....

    Client: NT (Desktop oder Winframe-Server)

  • Batchverarbeitung in derselben (Hardware-) Architektur

    (Z. B. Textformatierung oder Auftragskommunikator)

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


Architektur mit anwendungsserver

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Architektur mit Anwendungsserver

PC

PC

Oberfläche, Anwendungs-

logik und Persistenzschicht

in SmallTalk (VA)

PC

Oberfläche

Oberfläche

DDE

TCP/IP-Netz

DBServer (SQL + TM)

Anwendungslogik

Geschäftsobjekte

TCP/IP-Netz

TCP/IP-Netz

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


Architektur mit anwendungsserver1

Vorteile

Softwareverteilung

Datensicherheit

Verfügbarkeit

Skalierbarkeit

Netzwerkfähigkeit

Ressourcen-Sharing

Administration

Operating

Schnelle Netzte

Nachteile

Multi-User

Konkurrenz

Architektur mit Anwendungsserver

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


Beispiel winframe

Oberfläche, Anwendungslogik und

Persistenzschicht in SmallTalk (VA)

DDE

DBServer (SQL + TM)

Beispiel: Winframe

NT-Oberflächenemulation

TCP/IP-Netz, WAN

Anwendungs-

server

TCP/IP-Netz

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

Datenbank-

Server

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


Www html browser und java

WWW, HTML, Browser und Java

Verteilte Klassen versus verteilte Objekte

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


Architektur der datenhaltung

Architektur der Datenhaltung

  • DBMS-Clustering

  • DB Verteilung

    • DB Fragmentierung

      • horizontal

      • vertikal

    • DB Replikation

      • asymmetrisch

      • symmetrisch

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


Fragmentierung

Fragmentierung

Horizontal

Vertikal

Teilbestand

Gesamtbestand

Teilinformation

Teilinformation

Gesamtinformation

Teilbestand

Teilbestand

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


Replikation

Replikation

Asymmetrisch

Symmetrisch

Kopie vom

Original-

bestand

Original-

bestand I

Original-

bestand II

Original-

bestand

¿ Konflikte ?

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


Architektur der datenhaltung1

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

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


Zentrale dienste einer systemarchitektur

Zentrale Dienste einer Systemarchitektur

  • Global Directory aller Principals

    • Nutzer und

    • Rechner

  • Time-Service

  • Security Services

  • Transaktionsdienste

  • Suchdienste

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


Zusammenfassung

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

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


  • Login