© ELCA - 01 - 2002 BRY

6SH]LILNDWLRQ�XQG�(QWZXUIHLQHV�YHUWHLOWHQ�6\VWHPV

Bernhard Rytz

bry@elca.ch

2 © ELCA - 01 - 2002 BRY

hEHUEOLFN�3UlVHQWDWLRQ

� Einstieg Fallstudie

� Anforderungsprozess� komplexe Ausgangslage� Vorgehen und Mittel� Beurteilung

� Designprozess� Nicht-funktionale Aspekte� Design-Varianten� gewählte Design� Beurteilung

� Zusammenfassung

© ELCA - 01 - 2002 BRY

(LQVWLHJ�)DOOVWXGLH

4 © ELCA - 01 - 2002 BRY

$XVJDQJVODJH

Ziel� grosser Bankdienstleister will stärker kundenorientierte Sicht und

Verbesserung der Abwicklung in der Kundenberatung� grosse, existierende Systeme müssen dazu besser integriert werden

Existierende Systeme� Host-basierendes Bankeninformationssystem� Oracle-basierendes Kundeninformationssystem� Zahlreiche kleinere Systeme

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)

1DPH��������������

9RUQDPH�����������

$GUHVVH�����������

5 © ELCA - 01 - 2002 BRY

6\VWHPNRQWH[W

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

Oracle Forms

Kunden- &Produkte-verwaltung

OracleRDBMS

Terminal

Host (Cobol)

BankKerngeschäft

Präsentation

Verarbeitung

Datenhaltung

1HXH�$SSOLNDWLRQ

• modernes GUI• schnell erlernbar• einheitliche Sicht

auf Kunden• längerfristig

ausbaubar

%HQXW]HU

%HWUHLEHU

© ELCA - 01 - 2002 BRY

$QIRUGHUXQJVSUR]HVV

7 © ELCA - 01 - 2002 BRY

:HU�LVW�EHWURIIHQ�"

ELCA� /LHIHUDQW�

Dienstleister / RZ A� $XIWUDJJHEHU�

Projekt Mgt

Projekt

Betrieb

SW

Bank A1 � OHDG�

Mgt

Benutzer(2 Klassen)

Betrieb

SW +Betrieb

Lieferung

Einflussnahme

Dienstleister / RZ B

Mgt

Betrieb

SW

Bank B1-B80

Bank A2-A7

.HLQ�IDFKOLFKHU ,QSXW GHU

�EULJHQ�%DQNHQ

=XVDPPHQIDVVXQJ � *UHPLHQ

Benutzergruppe

Projektausschuss

8 © ELCA - 01 - 2002 BRY

9RUJHKHQ�0LWWHO�I�U�$QIRUGHUXQJHQ

� Vereinfachung der komplexen Situation� eine "Leadbank" verantwortlich für fachliche Aspekte� "Benutzergruppe": Repräsentanten aller Banken prüfen Anforderungen� "Projektausschuss" : Repräsentanten des Managements für Entscheide� Zweite 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

� Anforderungsspezifikation (Word+Visio, vorgegebene Struktur)� Use cases (v.a. detaillierte Szenarien),� 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, …)

10 © ELCA - 01 - 2002 BRY

5HVXOWDWH�DXV�$QIRUGHUXQJV��'HVLJQSUR]HVV

Vision- Grobziele aus Geschäfts-Sicht- 20-30 Seiten

Anforderung Applikation- funktionale Aspekte- nicht-funktionale "- ungf. 150 Seiten

Schnittstellen zuexistierenden Systemen

GUI Prototyp

Applikationsarchitektur- Aufteilung in Komponenten- allgemeine Prinzipien/Regeln

Design Komponente X- internes Design der Komponente

Anforderungen Komponente X- detaillierte Anforderungen je Komponente

Code (inklusive Kommentierung)

Fachlich

-T

echnisch

High-Level/G

esamtsystem

-D

etails/Kom

ponenten

Techn. Vorabklärungen

11 © ELCA - 01 - 2002 BRY

%HXUWHLOXQJ�$QIRUGHUXQJVSUR]HVV

� Was hat gut funktioniert ?� Fachliche Bedürfnisse genügend richtig und vollständig erkannt� Neues GUI wird als grosser Fortschritt empfunden

� Wo gab es Probleme ?� Wenig Verständnis der Benutzer für OO Formalismen� Performance - Anforderungen nicht genügend erhoben� Anforderungen spezifiziert ohne Machbarkeit zu berücksichtigen

(Performance)� Schnittstellen externe Systeme nicht präzis genug spezifiziert =>

gewisse Probleme bei Datenqualität, Performance und Integrität

� Dauernde Herausforderung� Anforderungsspezifikation genug verständlich für Auftraggeber und

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

© ELCA - 01 - 2002 BRY

'HVLJQSUR]HVV

13 © ELCA - 01 - 2002 BRY

$EVWUDNWLRQ GXUFK 0LGGOHZDUH KDW *UHQ]HQ

.RPPXQLNDWLRQ1HW]ZHUN�EUDXFKW

�YLHO��PHKU�=HLW,GHDOHU�)DOO

�YROO�]HQWUDOLVLHUW�

��6HUYHU��&OLHQW ��6HUYHU��&OLHQW

6LFKHUKHLW��ZLH�HUNHQQH�LFKOHJLWLPH�.XQGHQ�"

*U|VVHUHV�5LVLNR.RPPXQLNDWLRQVSUREOHPH

��6HUYHU��&OLHQW

8QDEKlQJLJH�3DQQHQ

��6HUYHU��&OLHQW

��6HUYHUQLFH�&OLHQWEDG�&OLHQW

RURU

3DUDOOHOOH�=XJULIIH

��6HUYHUD�&OLHQWE�&OLHQW

14 © ELCA - 01 - 2002 BRY

'HVLJQ�$OWHUQDWLYHQ

Es gibt immer mehr als eine Möglichkeit….

"

%HQXW]HU

%HWUHLEHU

([W([W

%HQXW]HU

%HWUHLEHU

([W([W

Browser

WebServer

JSP Engine

JSP Seiten

Java Code

JDBCConn.

%HQXW]HU

%HWUHLEHU

([W([W

KommerziellesCRM

(customerrelationship

management)Werkzeug

AdapterAdapter

15 © ELCA - 01 - 2002 BRY

*HZlKOWHV�'HVLJQ

� Komplexes GUI Java/Swing� Aufteilung der fachlichen

Funktionalität inwiederverwendbare Komponenten

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

� Kommunikation mit Host überspeziellen "Connector"

� Kommunikation mit Oracle-Applikation mit JDBC

� eigene Datenhaltung zur"Synchronisation" der beidenexternen Systeme

%HQXW]HU

%HWUHLEHU

([W([W

Java/Swing

Tuxedo

JDBCConn.

Java Code GUI

Kommunikations-Bus

Eigene Daten

fachl.Kompo.

fachl.Kompo.

16 © ELCA - 01 - 2002 BRY

'HVLJQ�*UXQGSULQ]LSLHQ ��$UFKLWHNWXU��

� Komponenten� explizite Schnittstelle, versionierbar� grob-granular, service-orientiert, stateless� wiederverwendbar� location-transparency, Kommunikation über Tuxedo� selbstverantwortlich für Sicherheit, 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

17 © ELCA - 01 - 2002 BRYStateful Services/Beans

'HVLJQ�)UDJH��6WDWHOHVV YV� 6WDWHIXO

� Stateless Service verzichten auf eigenes Caching, benützen dafürCaching der DB

� Skalierbarkeit vs. Einbussen bei der Antwortzeit ?� Beste Lösung hängt stark von Mengen und Häufigkeiten ab

Bean

RDBMS

Client Client Client

Bean Bean

���

���

Filesystem

datadata

data

���

Cache

datadata

data

���

Stateless Services/Beans

Bean

RDBMS

Client Client Client���

Filesystem

datadata

data

���

Cache

datadata

data

���

.RQWH[W�EHL

MHGHP�$XIUXI

YRQ &OLHQW

PLWJHJHEHQ

18 © ELCA - 01 - 2002 BRY

(LQJHVHW]WH�0LWWHO�I�U 'HVLJQ

� 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.� Code (abstrakte Klassen/Interfaces) wird von Anfang eingesetzt

� 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

19 © ELCA - 01 - 2002 BRY

6LFKWHQ�DXI�GDV�6\VWHP

Verschiedene Sichten erlauben bessere Strukturierung der Überlegungenund helfen als "Checkliste"

Gesamtsicht

Benutzer-sicht

Betreiber-sicht

Entwickler-sicht

KonzeptionelleArchitektur Sicht

LaufzeitArchitektur Sicht

CodeArchitektur Sicht

ImplementierungsArchitektur Sicht

20 © ELCA - 01 - 2002 BRY

Technische Komponenten

'HVLJQ��.RQ]HSWLRQHOOH�6LFKW

Kanal Java Swing Kanal Browser Kanal Gui-Tool (4GL)A BA

Facades Facade A Facade B

FachlicheKomponenten

KontoVerwaltung

~ 30 weitere KomponentenKarten

DataAccess(lokale Komponenten)

...

RDBMS Data Security

JDB

C

ResourceAccess KomponentenKunden...

Rep

lik.

Hostzugriff

SecurityConfiguration

KundeÜbersicht KundenStamm

Kunden

JDB

C

HostT

erm

Pendenzen

21 © ELCA - 01 - 2002 BRY

Rechen-zentrum

Notstand

Bank

'HVLJQ���/DXI]HLW�6LFKW

Filiale Filiale

Hauptsitz

> 1000 clients

Rechen-zentrum

GUI GUI

GUI GUI

GUI GUI

App-ServerTuxedo

App-ServerTuxedo

Service XApp-Server

Tuxedo

Service YApp-Server

TuxedoTuxedoAgents

Bank

DBDBHostHost DB

Host-Programm

Bank

22 © ELCA - 01 - 2002 BRY

%HXUWHLOXQJ�'HVLJQ

� Was hat gut funktioniert ?� Komponentenmodell� Wiederverwendung in neuen Projekten schon Tatsache� Skalierbarkeit gut

� Wo gab es Probleme ?� Konfigurationsmanagement (neue Abhängigkeiten)� Antwortzeit (Performance-Bugs, zu "naives" Design)� Betriebsaufnahme (ein verteiltes System wird anders betrieben als

ein zentraler Host)

� Dauernde Herausforderung� Keep it simple

© ELCA - 01 - 2002 BRY

$EVFKOXVV

24 © ELCA - 01 - 2002 BRY

=XVDPPHQIDVVXQJ

� 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 100% transparent. Verteilungdarf nie Selbstzweck sein

� Nach Einfachheit und Eleganz streben

Verständlichkeit

Präz

ision Wo wollen

wir sein ?

© ELCA - 01 - 2002 BRY

'DQNH�I�U�,KUH�$XIPHUNVDPNHLW

LQWHUHVVLHUW�"

ZZZ�HOFD�FK

26 © ELCA - 01 - 2002 BRY

/LWHUDWXU

� *Applied Software Architecture, C. Hofmeister et al., 2000� *Component Software, C. Szyperski,1998� Das objekt-orientierte Konstruktionshandbuch: Werkzeug und

Material-Ansatz, H. Züllighofen, 1998� Object-Oriented Software Construction, Bertrand Meyer, 1997� *Pattern-orientierte Software-Architektur, F. Buschmann et al., 2000� Software Architecture, D. Garlan et al.,1996� Software Architecture in Practice, L. Bass et al., 1998� Software Project Survival Guide, McConnell,1998� Software Requirements, Karl Wiegers,1999� The art of systems architecting, E. Rechtin, 1997� www.theserverside.com� www.ibm.com/developerworks und .../redbooks� www.javasoft.com� www.eaijournal.com