© ELCA - 01 - 2004 BRY

Spezifikation und Entwurfeines grossen verteilten Systems

Bernhard Rytzbernhard.rytz@elca.ch

Fallstudie

http://www.gartenstrasse18.ch

2 © ELCA - 01 - 2004 BRY

Überblick

Ziele

Anhand Fallstudie… Einblick in Besonderheiten

bei der Anforderungs-analyse grosser Projekte

Architektur für ein grosses,verteiltes System

Erfahrungen (positive undverbesserungswürdigePunkte)

Fragen jederzeit !

Inhalt Einstieg Fallstudie

Anforderungsanalyse viele Bedürfnisträger Vorgehen und Mittel Beurteilung

Architektur & Design Was ist Architektur ? Architektur-Varianten Design-Sichten Beurteilung

Zusammenfassung

© ELCA - 01 - 2004 BRY

Einstieg Fallstudie

4 © ELCA - 01 - 2004 BRY

Ausgangslage (1)

Ziele grosser Bankdienstleister will stärker

kundenorientierte Sicht und Verbesserung derAbwicklung in der Kundenberatung

grosse, existierende Systeme müssen dazubesser integriert werden

Besonderes Mehrere 1000 Benutzer arbeiten gleichzeitig In einem zentralen Rechenzentrum wird Betrieb

vieler Banken abgewickelt (Mandantenfähigkeit) Komplexe Topologie, geringe Bandbreite (z.T.

64KBit/s)

Name : .........Vorname: .........Adresse: .........

5 © ELCA - 01 - 2004 BRY

Ausgangslage (2) - Systemkontext

Eine zentrale Aufgabe ist die Integration mit den existierenden("legacy") Systemen.

Oracle Forms

Kunden- &Produkte-

verwaltung

OracleRDBMS

Terminal

Host (Cobol)

BankKerngeschäft

Präsentation

Verarbeitung

Datenhaltung

Neue Applikation

• modernes GUI• neue Geschäfts-

prozesse• schnell erlernbar• einheitliche Sicht

auf Kunden• längerfristig

ausbaubar

Benutzer

Betreiber

© ELCA - 01 - 2004 BRY

Anforderungsanalyse

7 © ELCA - 01 - 2004 BRY

Wer ist betroffen ?

ELCA(= Lieferant)

Dienstleister / RZ A(= Auftraggeber)

Projekt Mgt

Projekt

Betrieb

SW

Bank A1 (=lead)Mgt

Benutzer(2 Klassen)

Betrieb

IT-Dienste

Lieferung

EinflussnahmeDienstleister / RZ B

Mgt

Betrieb

SW

Bank B1-B80

Bank A2-A7

Kein fachlicher Input derübrigen Banken

Zusammenfassung 2 Gremien

BenutzergruppeProjektausschuss

8 © ELCA - 01 - 2004 BRY

Vorgehen/Mittel für Anforderungen

Vereinfachung der komplexen Situation (vorhergehende Grafik) eine "Leadbank" verantwortlich für fachliche Aspekte "Benutzergruppe": Repräsentanten aller Banken prüfen Anforderungen "Projektausschuss" : Repräsentanten des Managements für Entscheide Zweites Rechenzentrum (RZ B) liefert nur betriebliche Anforderungen

Kommunikation mit den Benutzer(-vertretern) Visions-Dokument GUI Prototyping (throw-away), usability tests regelmässige Besprechung der Anforderungs-Dokumente

Anforderungsdokument (Word+Visio, vorgegebene Struktur) Use cases (v.a. detaillierte Abläufe in Textform), natürlichsprachliche Anforderungen, ergänzt mit Tabellen,

Navigationsdiagrammen und (selten) Klassen-, Sequenz- oderZustandsdiagrammen

nicht-funktionale Anforderungen (Mengen und Häufigkeiten, Sicherheit,Integrität, Performance, Verfügbarkeit, Testbarkeit, …)

9 © ELCA - 01 - 2004 BRY

BeispielNavigationsdiagramme

Vorteile Verständlichkeit Benutzer Überprüfung Use cases Verbindung mit Prototyping

Heikel Gefahr Überspezifikation

(Diskussionen über Layoutetc.)

Initialaufwand

PendenzDetail

Pendenzensuchen

Hauptbildschirm

Pe nd enzs uche n

Pendenzen-D

etail Pendenzerledigen

Pendenzmutieren

Partner suchen

Partner-Ü

bersicht

Pendenzen suchen

Partnersuchen

Partner-Detail

Login Fällige Pendenzen

logout

Fällige Pendenzen

10 © ELCA - 01 - 2004 BRY

Risikomanagement Gewichtung Anforderungsanalyse im Projekteffort

Vorgehen muss auf Projektzugeschnitten sein Risikotoleranz Fachliche Vorkenntnisse Entwickler Technische Vorkenntnisse Kunde Komplexität der Materie Änderungshäufigkeit erwartete Lebensdauer Applikation

Anforderungen sind Mittel zumZweck: weder über- nochunterspezifizieren

die objektiv perfektenAnforderungen gibt es nicht

Für gegebenes Budget undErfahrung muss maninsbesondere zwischenPräzision undVerständlichkeitKompromisse machen

(fachliche) Verständlichkeit(tech

nisch

e)Pr

äzisi

on Wo wollenwir sein ?

optimiertesVorgehen

11 © ELCA - 01 - 2004 BRY

Beurteilung Anforderungsprozess (1)

Was hat gut funktioniert ?Fachliche Bedürfnisse genügend richtig und vollständig

erkanntNeues GUI wird als grosser Fortschritt empfundenEffizienzsteigerung erreicht

Wo gab es Probleme ?Wenig Verständnis der Benutzer für OO FormalismenPerformance-Anforderungen nicht genügend erhobenAnforderungen spezifiziert ohne Machbarkeit zu

berücksichtigen (Performance)Schnittstellen externer Systeme nicht präzis genug

spezifiziert Probleme bei Datenqualität, Performanceund Integrität

12 © ELCA - 01 - 2004 BRY

Beurteilung Anforderungsprozess (2)

Dauernde HerausforderungAnforderungsspezifikation genug verständlich für

Auftraggeber und genug präzise für Entwickler ?Gedankliche Trennung Anforderungen und Design

Lehrenmehr Disziplin zur Beschreibung nicht-funktionaler

AnforderungenDiagramme mit Beschreibungen kombinierenUmsysteme noch besser kennenlernen (z.B.

Stichproben Datenqualität)

© ELCA - 01 - 2004 BRY

Vorgehen Architektur & Design

14 © ELCA - 01 - 2004 BRY

Überblick Ablauf

Benutzer

Betreiber

Umsystem

1

1

1

Architektur2

2

2

2

3

3

3

Anforderungen1

44

4

4 4

4

class Xyzi = j+1 ;

4 Klassendesign/Code

2 Architektur & Systemdesign

3 Komponentendesign

tech

nisc

hfa

chlic

h

15 © ELCA - 01 - 2004 BRY

Inkrementelles Vorgehen

Prozess inkrementell mitInbetriebnahme neuerFunktionsblöcke alle 3Monate

EntwicklungsaufwandFunktionsblock 3-20Personenmonate

Parallel dazu Nachführungund Korrektur bestehenderBlöcke

Kleinere Inkremente hiernicht sinnvoll, wegen Koordinationsaufwand Testaufwand Schulungsaufwand

Inkrementelles Vorgeheneinfacher mit inkrementellerDokumentation

AnforderungenSystem

AnforderungBlock A

Design/ArchitekturSystem

DesignBlock A

AnforderungBlock B

DesignBlock B

...

...

16 © ELCA - 01 - 2004 BRY

Was ist Architektur ?

Architektur = Dokumentation für Strukturierungs- und Kommunikationsprinzipien konkrete Grobstruktur des Systems (logisch und physisch) Behandlung transversaler nicht-funktionaler Aspekte wie

Sicherheit, Performance, Datenintegrität, …

Was sollte in derArchitektur sein ?

Designpunkte, fürwelche eine falscheoder fehlendesystemweite Regelungbesonders weh tut

projekt-spezifisch....

Bus ines s Modeling

Requirements

Des ign

Implementation

Test

inc. elaborationelaboration construction transition

17 © ELCA - 01 - 2004 BRY

Architektur-Alternativen

Es gibt immer mehr als eine Möglichkeit….

?

Benutzer

Betreiber

ExtExt

Benutzer

Betreiber

ExtExt

Browser

WebServerJSP EngineJSP Seiten

Java Code

JDBCAdapt.

Benutzer

Betreiber

ExtExt

KommerziellesCRM

(customerrelationship

management)Werkzeug

AdapterAdapter

18 © ELCA - 01 - 2004 BRY

Gewählte technische Architektur

Multi-Channel Frontend Swing GUI Browser (als Versuch)

Aufteilung fachliche Funktionalität inwiederverwendbare Komponenten

Kommunikation der Komponentenuntereinander und mit Frontend überKommunikations-Bus (Tuxedo-basierend)

Kommunikation mit Host überspeziellen "Connector"

Kommunikation mit Oracle-Applikationüber JDBC

eigene Datenhaltung zur"Synchronisation" der beiden externenSysteme

Benutzer

Betreiber

ExtExt

Java/Swing

Tuxedo

JDBCAdapter

Java Code GUI

Kommunikations-Bus

Eigene Daten

fachl.Kompo.

fachl.Kompo.

Techn. K.

Browser

WebSrvJSP

19 © ELCA - 01 - 2004 BRY

Weitere Architektur-Prinzipien

Komponenten wiederverwendbar, explizite Schnittstellen, versionierbar grob-granular, service-orientiert, stateless location-transparency, Kommunikation über Tuxedo eigenverantwortlich für Sicherheit, Daten-Integrität, Konfiguration

Multi-Channel konsequente Trennung Präsentation, Verarbeitung, Datenhaltung Explizite Schnittstellen (Façades) für die Präsentation

gemeinsame "Infrastruktur" Querschnittsfunktionen als gemeinsame technische Komponenten

(Sicherheit, Fehlerbehandlung, Konfiguration, Überwachung, etc.) Middleware Transaktionsmonitor Tuxedo

voll skalierbar und pannentolerant

möglichst durchgängig Java; starke Typisierung

Grundlage für konkretes Systemdesign

20 © ELCA - 01 - 2004 BRY

Eingesetzte Mittel für Design

Design "machen" kreative Aufgabe, aus der Erfahrung gespiesen viele Köche… Prüfung/Optimierung durch Walkthroughs und/oder Reviews

Kommunikation eines Designs UML v.a. Klassen-, Sequenz- und Zustandsdiagramme Natürliche Sprache (gerade für Regeln und Begründungen) Ziel: Redundanz zum (kommentierten) Code möglichst gering zu halten.

Alles was möglich ist, wird im Code beschrieben.

Werkzeuge Design-Dokument für Gesamt-Applikation Kurzes Design-Dokument je Komponente Umfangreiche Kommentierung und sorgfältige Gestaltung des Codes

(Javadoc) Tool Together erlaubt wahlweises Arbeiten via Code oder Diagramm-Sicht

(round-trip engineering)

21 © ELCA - 01 - 2004 BRY

Strukturierungshilfe Schichten-Modelle("layering")

Präsentation

Verarbeitungs-steuerung

Verarbeitungs-dienste

Datenhaltung

technischeKomponenten

fachlichewiederverw. K.

fachliche,nicht-wiederv. K.

Einfach +wirkungsvoll !

GUIFramework GUI

No!

22 © ELCA - 01 - 2004 BRY

Strukturierungshilfe: Sichten auf das System

Verschiedene Sichten (“views”) Strukturierung der Überlegungen bessere Abstraktion Konsistenz durch Quervergleiche

Gesamtsicht

Benutzer-sichtBetreiber-sichtEntwickler-sicht

KonzeptionelleSicht

Laufzeit Sicht

Code Sicht

Implementie-rungs Sicht

Komponenten, Schnittstellen,Abhängigkeiten undInteraktionen ohne techn. Detailswie Kommunikationsverfahren

Das klassische Systemdesignmit "allen" Klassen, Beziehungenund Interaktionen

Executables, Prozesse,Maschinen, Netzwerke

Organisation Source-Code,Build-Prozess, Libraries

23 © ELCA - 01 - 2004 BRY

Design: Konzeptionelle Sicht(nur fachliche Komponenten)

Datenhaltung

ext 1owndata

Frontend/Präsentation

Verarbeitungssteuerung

Verarbeitungsdienste

account customer

cplsv card acc. part. dau formnum. vm

output

GUI

host ext 2

Web-Server

24 © ELCA - 01 - 2004 BRY

Rechen-zentrum

Notstand

Bank

Design : Laufzeit-Sicht

Filiale Filiale

Hauptsitz

> 1000 clients

Rechen-zentrum

GUI GUI

GUI GUI

GUI GUI

Bank

DBDBHostHost DB

Host-Programm

Bank

Unix Server<<process>>Kompo. X

App-ServerTuxedo

<<process>>Kompo. X

App-ServerTuxedo

<<process>>TuxedoAgents

<<process>>Kompo. X

App-ServerTuxedo

<<process>>Kompo. Y

App-ServerTuxedo

<<process>>TuxedoAgents

Tuxedo Tuxedo

25 © ELCA - 01 - 2004 BRY

Beurteilung Design

Was hat gut funktioniert ?KomponentenmodellWiederverwendung in neuen Projekten schon TatsacheSkalierbarkeit gut

Wo gab es anfänglich Probleme ?Konfigurationsmanagement (neue Abhängigkeiten mit

Umsystemen)Antwortzeit (Performance-Bugs, zu "naives" Design)Betriebsaufnahme (ein verteiltes System wird anders

betrieben als ein zentraler Host)

Dauernde Herausforderung “so einfach wie möglich, so kompliziert wie nötig”

© ELCA - 01 - 2004 BRY

Abschluss

27 © ELCA - 01 - 2004 BRY

Zusammenfassung

Ohne "genügende" Anforderungen sind Enttäuschungenvorprogrammiert

Alle potentiellen Interessenten (stakeholder) kennen,dazu gehören auch die Betreiber

Richtiger Kompromiss zwischen Präzision undVerständlichkeit (und Aufwand) für Anforderungen -Stakeholder und Entwickler müssen sich treffen

Die globale Architektur eines verteilten Systems muss(vor allem) die nicht-funktionalen Aspekteberücksichtigen!

Verteilung ist nie wirklich völlig transparent. Verteilungdarf nie Selbstzweck sein

Nach Einfachheit und Eleganz streben

Verständlichkeit

Präz

ision

Wo wollenwir sein ?

28 © ELCA - 01 - 2004 BRY

P.S.: 3 Jahre danach

Neues Bedürfnis 3 Jahre nach Betriebsaufnahme Bedürfnis, von Tuxedo auf J2EE

(BEA WLS) umzustellen. Gründe: Standardisierung, Web-Service-Unterstützung, …

Umsetzung Dank einer Architektur, welche Kommunikationsbus mit gewisser

Middleware-Unabhängigkeit postuliert hatte, Umstellung machbar. Nach Vorbereitungsarbeiten von einigen Montaten, wurde alle

Banken innerhalb 2 Wochen umgestellt.

Kommentar Architektur-Investition (Abstraktion Transportschicht) hat gelohnt Das wissen wir allerdings erst im Nachhinein

© ELCA - 01 - 2004 BRY

Danke für Ihre Aufmerksamkeit

30 © ELCA - 01 - 2004 BRY

Literatur + URLs

*Applied Software Architecture, C. Hofmeister et al., 2000 *Applying UML and Patterns, C. Larman, 2002 *Component Software, C. Szyperski,1998 Das objekt-orientierte Konstruktionshandbuch: Werkzeug und Material-Ansatz, H.

Züllighofen, 1998 Object-Oriented Software Construction, B. Meyer, 1997 *Pattern-orientierte Software-Architektur, F. Buschmann et al., 2000 Patterns of Entreprise Application Architecture, Martin Fowler, 2003 Software Architecture, D. Garlan et al.,1996 Software Architecture in Practice, L. Bass et al., 1998 Software Project Survival Guide, McConnell,1998 Software Requirements, K. Wiegers,1999 The art of systems architecting, E. Rechtin, 1997 UML Components, J. Cheeseman et al., 2001 http://www.systemsguild.com/GuildSite/Robs/Template.html www.theserverside.com www.ibm.com/developerworks und .../redbooks

31 © ELCA - 01 - 2004 BRY

ELCA www.elca.chELCA - eine starke Präsenz

gegründet 1968 über 300 hochqualifizierte

Ingenieure ISO 9001 Zertifizierung 1993 Umsatz 2002: 52 Mio SFr. Standorte Lausanne, Zürich,

Bern, Genf, Vietnam, London,Paris

Produkte und Frameworks

Dienstleistungen

Software-Entwicklung über alle Phasen System-Integration Business-Consulting Projekt- und Qualitätsmanagement

Besondere Kompetenzbereiche

CRM & Business Intelligence Content Management Internet Technologies & Web Factory Resource Planning Project Support & Supervision Business Consulting Architecture and Distributed Systems