© ELCA - 01 - 2002 BRY
6SH]LILNDWLRQ�XQG�(QWZXUIHLQHV�YHUWHLOWHQ�6\VWHPV
Bernhard Rytz
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