Software–Projekt 2009/10VAK 03-901.01

ArchitekturbeschreibungVersion 1.0

xxxxxx xxxxxxx xxxxxxxx@tzi.dexxxx xxxxxxxx xxxx@tzi.dexxxx xxxxx xxxxxx@tzi.dexxxxxxxx xxxxxxxxxx xxx@tzi.dexxxxxx xxx xxxxxxxx@tzi.de

Abgabe: 1. April 2010

Inhaltsverzeichnis

0 Version und Änderungsgeschichte 3

1 Einführung 31.1 Zweck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Definitionen, Akronyme und Abkürzungen . . . . . . . . . . . . 31.4 Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Übersicht über das Dokument . . . . . . . . . . . . . . . . . . . . 4

2 Globale Analyse 52.1 Einflussfaktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Probleme und Strategien . . . . . . . . . . . . . . . . . . . . . . . 6

3 Konzeptionelle Sicht 73.1 BiBi-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 BiBi-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Modulsicht 114.1 Konkretisierung Common . . . . . . . . . . . . . . . . . . . . . . 134.2 Konkretisierung Server . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2.1 Konkretisierung Persistence . . . . . . . . . . . . . . . . . 144.2.2 Konkretisierung BusinessLogic . . . . . . . . . . . . . . . 164.2.3 Konkretisierung Communication . . . . . . . . . . . . . . 17

4.3 Konkretisierung Client . . . . . . . . . . . . . . . . . . . . . . . . 19

5 Datensicht 195.1 Konkretisiertes Datenmodell . . . . . . . . . . . . . . . . . . . . 205.2 Transportmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Ausführungssicht 24

7 Zusammenhänge zwischen Anwendungsfällen und Architektur 257.1 Anwendungsfall Buch hinzufügen . . . . . . . . . . . . . . . . . 257.2 Anwendungsfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

8 Evolution 28

2

0 Version und Änderungsgeschichte

. . .

1 Einführung

1.1 Zweck

Dieses Dokument dient als Vorlage für die Gliederung Eurer Architekturbeschrei-bung. Gleichzeitig dient es als Beispiel für eine Architekturbeschreibung. Hierzu sindexemplarisch einige Architekturelemente näher beschrieben. Dieses Beispiel soll Eucheine Idee vermitteln, wie wir uns die Beschreibung vorstellen.

Um den Text des Beispiels von den Meta-Kommentaren zur Architekturbeschreibungunterscheiden zu können, sind letztere kursiv gesetzt.

Dieses Dokument beschreibt die Architektur der Bibliothekssoftware BiBi. DieArchitektur beschreibt, wie die Anforderungen, die in der Anforderungsspe-zifikation von BiBi [3] angegeben sind, realisiert werden.

Dieses Dokument dient den Entwicklern als Vorgabe für die Implementierung,den Testern für die Vorbereitung der Black-Box-Tests und den Wartungsinge-nieuren für die Beurteilung der Änderbarkeit des Systems für mögliche zu-künftige Anforderungen, wie sie in der Anforderungsspezifikation beschrie-ben sind.

. . .

1.2 Status

Dieses Dokument beschreibt den ersten Entwurf. Es wurde noch nicht durchein Architektur-Review freigegeben.

. . .

1.3 Definitionen, Akronyme und Abkürzungen

GUI Graphical User Interface

. . .

3

1.4 Referenzen

Literatur

[1] IEEE Recommended Practice for Architectural Description of Software-intensiveSystems—Std. 1471-2000. ISBN 0-7381-2518-0, IEEE, New York, NY, USA,2000.

[2] Christine Hofmeister, Robert Nord, Dilip Soni. Applied Software Architec-ture. Addison Wesley, Object Technology Series, 2000.

[3] Bauhaus Software Technologies. Anforderungspezifikation BiBi. Version 1.1vom 11. November 2009. http://www.informatik.uni-bremen.de/st/Lehre/swp/beispiele/anforderungsspezifikation.pdf

[4] Rainer Koschke. Skript zur Vorlesung Software-Projekt. 2009

1.5 Übersicht über das Dokument

Die Architekturbeschreibung genügt dem IEEE-Standard [1] und folgt den Ar-chitekturblickwinkeln von Hofmeister et al. [2].

Zunächst werden in Kapitel 2 die Einflussfaktoren für den Entwurf, Proble-me sowie mögliche Lösungsstrategien dargestellt. Dann werden in den Kapi-teln 3, 4 und 6 drei der vier Sichten nach [2] beschrieben (auf die Code-Sichtwird in diesem Projekt verzichtet). In Kapitel 5 werden die Architektursichtennoch ergänzt durch die Beschreibung des Datenmodells für die Implementie-rung. Es handelt sich dabei um die Verfeinerung des logischen Datenmodellsder Anforderungsspezifikation [3] so wie es implementiert werden soll. An-schließend wird in Abschnitt 7 das Zusammenspiel der verschiedenen Moduleaus Kapitel 4 anhand von ausgewählten Anwendungsfällen erläutert. Im Ab-schnitt 8 wird dann abschließend dargelegt, wie das System geändert werdenmuss, wenn sich Rahmenbedingungen oder Anforderungen ändern.

4

2 Globale Analyse

Hier werden Einflussfaktoren aufgezählt und bewertet sowie Strategien zumUmgang mit interferierenden Einflussfaktoren entwickelt.

2.1 Einflussfaktoren

Hier sind Einflussfaktoren gefragt, die sich auf die Architektur beziehen und nicht z.B.auf das Projektmanagement. Fragt Euch also bei jedem Faktor: Beeinflusst er wirklichdie Architektur? Es geht hier um Einflussfaktoren, die

1. sich über die Zeit ändern,

2. viele Komponenten betreffen,

3. schwer zu erfüllen sind oder

4. mit denen man wenig Erfahrung hat.

Daher werden in der 2. Spalte die Flexibilität (könnt Ihr den Faktor zum jetzigen Zeit-punkt beeinflussen?) und Veränderlichkeit (ändert der Faktor sich später durch äußereEinflüsse?) charakterisiert. Unter Auswirkungen sollte dann beschrieben werden, wieder Faktor was beeinflusst. Das können sein:

• andere Faktoren

• Komponenten

• Operationsmodi

• Designentscheidungen (Strategien)

Verwendet eine eindeutige Nummerierung der Faktoren, um sie auf den Problemkar-ten einfach referenzieren zu können.

Faktor Flexibilität und Veränder-lichkeit

Auswirkung

O1 : EntwicklungsplanO1.1 : Time-To-MarketAuslieferungJuli 2010

Keine Flexibilität Wird der Auslieferungster-min vorgezogen, könnennicht alle Funktionen imple-mentiert werden.

. . . . . . . . .

5

2.2 Probleme und Strategien

Aus einer Menge von Faktoren ergeben sich Probleme, die nun in Form von Problem-karten beschrieben werden. Diese resultieren z.B. aus

• Grenzen oder Einschränkungen durch Faktoren

• der Notwendigkeit, die Auswirkung eines Faktors zu begrenzen

• der Schwierigkeit, einen Produktfaktor zu erfüllen, oder

• der Notwendigkeit einer allgemeinen Lösung zu globalen Anforderungen.

Dazu entwickelt Ihr Strategien, um mit den identifizierten Problemen umzugehen.

Achtet auch hier darauf, dass die Probleme und Strategien wirklich die Architekturbetreffen und nicht etwa das Projektmanagement. Die Strategien stellen im Prinzip dieDesignentscheidungen dar. Sie sollten also die Erklärung für den konkreten Aufbauder verschiedenen Sichten liefern.

Anpassungen an Netzwerk und ClientWeiterentwicklung des Netzwerks und Wechsel auf neue Frontend-Technologie(z.B. Web-Frontend) machen Anpassungen an kommunikationsspezifischen Kom-ponenten notwendig. Für die Wartung steht nur ein Entwickler zur Verfügung.Die Anpassungen müssen schnell vorgenommen werden.EinflussfaktorenO1.1: Time-To-Market02.1: Anzahl EntwicklerP2.1: InteraktionsmodellP6.3: Softwareinstallation und -aktualisierungLösungStrategie S1: Kapselung der kommunikationsabhängigen Anteile Kom-munikationsabhängige Anteile werden in Komponenten isoliert. Diese bil-den eine virtuelle Maschine für alle anderen Komponenten.Strategie S2: . . .

. . .

Beschreibt möglichst mehrere Alternativen und gebt an, für welche Ihr Euch letztlichaus welchem Grunde entschieden habt. Natürlich müssen die genannten Strategien inden folgenden Sichten auch tatsächlich umgesetzt werden!

6

3 Konzeptionelle Sicht

Diese Sicht beschreibt das System auf einer hohen Abstraktionsebene, d.h. mit sehrstarkem Bezug zur Anwendungsdomäne und den geforderten Produktfunktionen und-attributen. Sie legt die Grobstruktur fest, ohne gleich in die Details von spezifi-schen Technologien abzugleiten. Sie wird in den nachfolgenden Sichten konkretisiertund verfeinert. Es folgen Beispiele für die Beschreibung der Komponenten des BiBi-Systems. Einzelne Komponenten müssen evtl. hierarchisch weiter verfeinert werden,wenn sie noch zu umfangreich sind.

<<component>>BiBiClient

<<component>>BiBiServer

requestmessage

Abbildung 1: Aufbau von BiBi

In diesem Kapitel wird das zu entwerfende System aus konzeptioneller Sichtbetrachtet. Hierzu wird der konzeptionelle Blickwinkel nach Hofmeister et al.(vgl. [2]) in der Notation aus der Vorlesung [4] verwendet. Den Anforderungenentsprechend soll das System als Client-Server-Anwendung entwickelt wer-den. Dazu teilen wir das System in zwei große Komponenten auf: den Clientund den Server (siehe Abbildung 1). Diese beiden Teile kommunizieren überein Netzwerk. Diese Aufteilung ergibt sich direkt aus den Anforderungen.

• Client: interagiert mit dem Benutzer

• Server: führt die Geschäftsprozesse aus, verwaltet den Datenbestand undorganisiert dessen Speicherung

In den folgenden Diagrammen werden konkrete Konnektoren verwendet, diejeweils Spezialisierungen von einem Basistyp sind. Die Basis-Konnektoren sind:

• asynchroner, nachrichtenbasierter Konnektorstellt eine asynchrone Kommunikation dar, d.h. einen Funktionsaufruf,bei dem eine Nachricht mit Daten von der rufenden Komponente (Sen-der) an die aufgerufene Komponente (Receiver) übergeben wird. Die Kon-trolle verbleibt im Sender, der Receiver arbeitet die Nachricht im Hinter-grund ab und es werden folglich keine Daten vom Receiver zum Senderübertragen. Das Protokoll des Konnektors wird dabei über den zu über-tragenden Nachrichtentyp festgelegt.

7

• methodenbasierter Konnektorstellt eine synchrone Kommunikation dar, d.h. einen Funktionsaufruf,bei dem Daten von der rufenden Komponente (Caller) an die aufgerufe-nen Komponente (Callee) übermittelt, dort verarbeitet und dann an denCaller zurück gegeben werden. Dabei wird die Kontrolle explizit an denCallee übergeben, d.h. der Aufruf blockiert den Caller. Hier bestimmtdas Interface des Callees das Protokoll des Konnektors.

Die Kommunikation zwischen Client und Server erfolgt dabei über zwei asyn-chrone, nachrichtenbasierte Konnektoren:

• message: der Server informiert den Client über Änderungen im Daten-bestand und übermittelt die zugehörigen Daten. Die übertragenen Nach-richten sind vom Typ Message und können sowohl Steuerungsinforma-tionen als auch Daten enthalten.

• request: der Client übermittelt Anfragen und zugehörige Daten an denServer. Die übertragenen Nachrichten sind vom Typ Request. Sie legenfest welche Aktion im Server ausgeführt wird und übertragen unter Um-ständen benötigte Daten.

Im nächsten Abschnitt 3.1 folgt eine detaillierte Beschreibung des Clients, imnachfolgenden Abschnitt 3.2 eine detaillierte Beschreibung des Servers.

8

3.1 BiBi-Client

<<component>>BiBiClient

<<component>>Model

<<component>>Communication

<<component>>User Interface

to Server

datacontrol

update send

Abbildung 2: Aufbau des BiBiClient

Der BiBiClient besteht aus den folgenden Komponenten (vgl. Abbildung 2):

• User Interface: die grafische Benutzeroberfläche, mit der der Benutzerinteragiert. Die Realisierung als eigenständige Komponente ergibt sichaus Strategie S5: Kapselung des Benutzerinterfaces.

• Model: die Datenhaltung für Bücher, Benutzer und Ausleihen sowie Vor-merkungen. Diese Komponente stellt auch das zentrale Steuerungsglieddes Clients dar, indem es das User Interface über Aktualisierungen desDatenbestands informiert und gewünschte Anwenderaktionen vom UserInterface entgegennimmt und an die Komponente Communication weiter-leitet. Diese Komponente ergibt sich aus den Strategien S5: Kapselung desBenutzerinterfaces (da alternative Benutzeroberflächen eine einheitlicheSchnittstelle zum Auslösen von Aktionen benötigen) und S4: Kapselungder Datenhaltung.

• Communication: ist die Kommunikationsschnittstelle zum Server. DieKomponente baut eine Verbindung zum Server auf und ermöglicht dasÜbertragen von Daten an den Server sowie das Empfangen von Datenvom Server. Empfangene Daten werden an die Komponente Model zurWeiterverarbeitung geleitet. Die Realisierung als eigenständige Kompo-

9

nente ergibt sich aus der Anwendung der Strategie S1: Kapselung der kom-munikationsabhängigen Anteile.

Die verwendeten Konnektoren sind alle Spezialisierungen des methodenba-sierten Konnektors, die sich in der Schnittstelle unterscheiden:

• control: . . .

Anmerkung: Da die Komponente Model wie oben beschrieben offensichtlich weitereTeilkomponenten enthält, muss diese Komponente in einem weiteren Verfeinerungs-schritt detaillierter beschrieben werden.

. . .

3.2 BiBi-Server

<<component>>BiBiServer

<<component>>BusinessLogic

<<component>>Persistence

<<component>>Communicationto Client

query

DBControl

response

Abbildung 3: Aufbau des BiBiServers

Die Komponente Server realisiert die konkreten Geschäftsprozesse, die in derKomponente Client ausgelöst werden, und hält den aktuellen Datenbestandzentral vor. Der Server organisiert die persistente Speicherung des Datenbe-stands.

Der BiBiServer besteht aus den folgenden Komponenten (vergleiche Abbil-dung 3):

10

• Persistence: Diese Teilkomponente realisiert die persistente Speicherungdes Datenbestands und erlaubt Zugriff auf die persistenten Daten. DieseKomponente ergibt sich aus den Strategien S4:Kapselung der Datenhaltungund S9: Verwendung von Fremdbibliotheken.

• BusinessLogic: Hier wird die Funktionalität der Geschäftsprozesse be-reitgestellt, z.B. das Ausleihen oder Vormerken eines Buches. Die Kom-ponente ergibt sich als Konsequenz aus Anwendung der Strategie S12:Trennung von Verarbeitungslogik und Daten.

• Communication: Diese Teilkomponente realisert die Kommunikations-schnittstelle zum Client. Sie nimmt Anfragen vom Client entgegen undleitet diese zur Verarbeitung an die BusinessLogic weiter. Zudem übermit-telt die Komponente die ihr übergebenen Daten an den entsprechendenClient. Diese Komponente ergibt sich wie schon im Fall des Clients ausStrategie S1: Kapselung der kommunikationsabhängigen Anteile.

Auch hier sind die verwendeten Konnektoren alle Spezialisierungen des me-thodenbasierten Konnektors. Sie unterscheiden sich lediglich in der benutztenSchnittstelle:

• DBControl: der Caller übermittelt Änderungen im Datenbestand an denCallee und übergibt diesem die Kontrolle. Der Callee aktualisiert darauf-hin die persistenten Daten und gibt die Kontrolle zurück.

• query: Das Modul Communication stellt als Caller eine Anfrage an dieBusinessLogic (Callee) oder übermittelt diesem durchzuführende Ände-rungen des Datenbestandes. Der Callee übernimmt die Kontrolle undführt die gewünschten Änderungen durch.

• response: Die BusinessLogic übermittelt durchgeführte Änderungen imDatenbestand an das Modul Communication und übergibt diesem dieKontrolle. Der Datenaustausch verläuft synchron.

4 Modulsicht

Diese Sicht beschreibt den statischen Aufbau des Systems mit Hilfe von Modulen,Subsystemen, Schichten und Schnittstellen. Diese Sicht ist hierarchisch, d.h. Modulewerden in Teilmodule zerlegt. Die Zerlegung endet bei Modulen, die ein klar umris-senes Arbeitspaket für eine Person darstellen und in einer Zeitwoche implementiertwerden können. Die Modulbeschreibung der Blätter dieser Hierarchie muss genau ge-nug und ausreichend sein, um das Modul zu implementieren.

Die Module werden durch ihre Schnittstellen beschrieben. Konkrete Implementierun-gen dieser Schnittstellen sind das Geheimnis des Moduls und können vom Program-mierer festgelegt werden. Sie sollen hier nicht beschrieben werden.

11

Die Schnittstelle eines Moduls M ist die Menge aller Annahmen, die andere Moduleüber M machen dürfen, bzw. jene Annahmen, die M über seine verwendeten Mo-dule macht (bzw. seine Umgebung, wozu auch Speicher, Laufzeit etc. gehören). JederSchnittstelle liegt ein Protokoll zugrunde. Das Protokoll beschreibt die Vor- und Nach-bedingungen der Schnittstellenelemente. Dazu gehören die erlaubten Reihenfolgen, indenen Methoden der Schnittstelle aufgerufen werden dürfen, sowie Annahmen überEingabeparameter und Zusicherungen über Ausgabeparameter.

Das Protokoll von Modulen soll einmal in der Modulsicht beschrieben werden. DieAusführungssicht verwendet das Protokoll, es soll aber die Protokollbeschreibung nichtnoch einmal wiederholen. Das Protokoll kann z.B. mit Hilfe von Zustands- oder Se-quenzdiagrammen spezifiziert werden.

Der Bezug zur konzeptionellen Sicht muss klar ersichtlich sein. Im Zweifel sollte erexplizit erklärt werden. Auch für diese Sicht muss die Entstehung anhand der Strate-gien erläutert werden.

In diesem Abschnitt werden nun die einzelnen Module der Anwendung be-schrieben. Dazu werden die in Kapitel 3 beschriebenen Komponenten des Ser-vers und des Clients mit Hilfe von UML-Diagrammen und Tabellen visuali-siert. Allgemein werden die Komponenten aus Kapitel 3 auf Pakete abgebildet,die den gleichen Namen haben wie die Komponenten.

Communication

BusinessLogic

Server

Communication

Client

Model

UserInterface

Common

DataNetwork

Persistence

Abbildung 4: Modulsicht BiBi

12

Abbildung 4 zeigt eine grobe Übersicht über die Module des Systems. DieseSicht wird in den folgenden Abschnitten konkretisiert und verfeinert.

4.1 Konkretisierung Common

. . .

4.2 Konkretisierung Server

Server

Comunication

Persistence BusinessLogic

+getThreadPoolExecutor() : ThreadPoolExecutor

NetworkServer

+disconnect()+getConnectionID() : long+getMember() : Member+send(ProtocolObject protocolObject)+setMember(Member member)

ClientConnection

+commit(Object o)+persist(Object o)+find(Class T, Object p) : T<T+findByQuery(String q) : List<T+refresh(Object o)+remove(Object o)+rollback(Object o)

EntityManager

+updateBookAndMember(Book b, Member m)+updateBooklist(List n)

UpdateHandler

+handleRequest(ProtocolObject r, ClientConnection c)

RequestHandler

+addBook(Book b, Integer n, Boolean r, Member m) : List<Book>+checkLogin(String l, String p, String s) : Member+checkoutBook(Integer b, String l, Member r) : Pair<Book, Member>+getAllBooks() : List<Book>+getAllMembers() : List<Member>+returnBook(Integer bookId, Member requester) : Pair<Book, Member>

BusinessHandler

Abbildung 5: Verfeinerter Aufbau des BiBiServers

Generell wird zur Protokollierung von Informationen und Fehlermeldungenin allen Modulen des Servers Apache Commons Logging verwendet. Diesresultiert aus der Anwendung der Strategien S16: Fehlerdiagnose ermöglichenund S9: Verwendung von Fremdbibliotheken. Die Granularität und damit die An-zahl an Informationen, die tatsächlich protokolliert werden, ist konfigurier-bar. Wenn die Informations- und Fehlermeldungen aussagekräftig protokol-liert werden, sind die Meldungen erkenntnisreich für Wartungsentwickler undrealisieren damit die Strategie S17: Fehlerdiagnose vereinfachen.

13

4.2.1 Konkretisierung Persistence

Das Modul Persistence (vgl. Abbildung 5) umfasst eine Fremdbibliothek zurpersistenten Speicherung des Datenbestands in einer unterliegenden Daten-bank. Dieses Modul ergibt sich als Konsequenz aus den Strategien S4: Kapse-lung der Datenhaltung, S9: Verwendung von Fremdbibliotheken und S10: Persistenzund Datenmodell entkoppeln. In diesem Modul muss eine Klasse EntityManagerenthalten sein, die die im Folgenden angegebenen Methoden bereitstellt:

• commit(Object o) throws Exception:Speichert das Object o dauerhaft ab. Löst eine Exception aus, falls dasObjekt nicht gespeichert werden kann.

• persist(Object o) throws Exception:Fügt das Objekt o dem dauerhaft zu speichernden Datenbestand hinzu.Löst eine Exception aus, falls das Objekt nicht hinzugefügt werden kann.

• T<T> find(Class<T> c, Object p) throws Exception:Findet ein Objekt des Typs T anhand des übergebenen Primärschlüsselsp und gibt es zurück. Löst eine Exception aus, falls mindestens ein Para-meter einen falschen Typ hat.

• List<T> findByQuery(String q):Gibt anhand der Anfrage q eine Liste von dauerhaft gespeicherten Ob-jekten zurück.

• refresh(Object o) throws Exception:Aktualisiert den Zustand eines Objektes aus dem dauerhaft gespeicher-ten Datenbestand. Dabei werden mögliche Änderungen im Objekt über-schrieben. Löst eine Exception aus, falls das Objekt nicht im Datenbe-stand existiert oder einen ungültigen Zustand hat.

• remove(Object o) throws Exception:Entfernt das Objekt aus dem dauerhaft zu speichernden Datenbestand.Löst eine Exception aus, falls das Objekt nicht im Datenbestand existiertoder einen ungültigen Zustand hat.

• rollback(Object o) throws Exception:Überführt das Objekt o in den Zustand den es vor dem aktuellen Zu-stand hatte. Löst eine Exception aus, falls dies nicht möglich ist oder dasObjekt einen ungültigen Zustand hat.

Abhängigkeiten im EntityManager Da die Schnittstelle dieser Klasse zu-standsbehaftet ist, d.h. von dem Zustand des jeweils betrachteten Objektesabhängt, wird das Protokoll für die Nutzung im Folgenden erläutert. Abbil-dung 6 stellt das Protokoll als Zustandsautomat dar.

14

removed

detached

managed

new/transient

persist

commit

remove

merge commit

refresh

persist

Abbildung 6: Protokoll des EntityManagers als Zustandsautomat

Ein Objekt, das außerhalb des EntityManagers erzeugt wird, befindet sich imZustand new/transient. Es hat keinerlei Verbindung zur Datenbank. Ein sol-ches Objekt wird mittels der Funktion persist unter die Kontrolle des Entity-Managers gebracht und wechselt dadurch in den Zustand managed. In diesemZustand werden Änderungen in Attributen mitprotokolliert um beim nächs-ten commit direkt in die Datenbank geschrieben zu werden. Bis dahin bleibtder korrespondierende Datenbankeintrag unverändert. Erst auf commit wer-den die Änderungen tatsächlich in die Datenbank übertragen. Änderungengegenüber dem entsprechenden Datenbankeintrag können in diesem Zustandjederzeit mittels refresh rückgängig gemacht werden. Da ein solches Objekt un-ter der Kontrolle des EntityManagers ist, darf es nicht aus dessen Reichweiteverschwinden, also insbesondere nicht serialisiert werden. Dazu muss es zu-vor mittels commit der Kontrolle des EntityManagers entzogen werden.

Ein Objekt im Zustand detached kann beliebig manipuliert werden, es hat keineVerbindung zu dem ursprünglichen Datenbankeintrag. Der Zustand detachedzeigt allerdings an, dass das Objekt eine Entsprechung in der Datenbank be-sitzt. Um Änderungen an so einem Objekt in die Datenbank zu übertragen,muss das Objekt mittels merge erst wieder angekoppelt werden.

Ein Objekt kann nur im Zustand managed aus der Datenbank gelöscht werden.Durch remove wird ein Objekt entkoppelt und in den Zustand removed über-führt. Der entsprechende Datenbankeintrag ist in diesem Fall jedoch noch vor-handen, das Objekt wird tatsächlich nur mit einer Löschmarkierung versehen.Erst auf commit wird der Datenbankeintrag tatsächlich entfernt und das Objektwird aus Sicht des EntityManagers wie ein neues, unbekanntes Objekt behan-delt. Ein Objekt im Zustand removed kann mittels persist wieder angekoppeltwerden. In diesem Fall wird die Löschmarkierung entfernt.

15

Die Aktion rollback ist in jedem Zustand außer new/transient möglich und über-führt das Objekt wieder in den Zustand, den es vor dem aktuellen Zustandhatte.

Wenn über die Methoden find bzw. findByQuery Objekte aus der Datenbankangefordert werden, so befinden sich diese im Zustand managed.

4.2.2 Konkretisierung BusinessLogic

Das Modul BusinessLogic besteht aus dem Teilmodul BusinessHandler. Der Busi-nessHandler bietet als Konsequenz aus Straegie S12: Trennung von Verarbeitungs-logik und Daten Dienste für das Durchführen der Geschäftsprozesse an undstellt die im Folgenden beschriebene Schnittstelle zur Verfügung. Sie ist zu-standslos, d.h. ein Methodenaufruf dieser Schnittstelle ist jederzeit unabhän-gig von vorbereitenden Methodenaufrufen durchführbar.

• List<Book> addBook(Book b, Integer n, Boolean r, Member m) throwsRequestException:Fügt auf Initiative des Benutzers m n Kopien des Buches b zum Datenbe-stand hinzu und gibt eine Liste mit diesen neuen Büchern zurück. Fallsr false ist, wird geprüft, ob es ein ähnliches Buch im Datenbestand gibt.Die Ähnlichkeitsprüfung selbst ist ein Geheimnis dieser Methode. Fallses ein ähnliches Buch gibt, wird eine RequestException ausgelöst. Sollte rtrue sein, werden die neuen Bücher dem Datenbestand sofort ohne Ähn-lichkeitsprüfung hinzugefügt. Der Parameter m wird bei der Protokollie-rung des Vorgangs verwendet.

– Vorbedingung: Hier die Vorbedingungen angeben. . .– Abhängigkeiten: -

(Hinweis: Da es sich um eine zustandslose Schnittstelle handelt (s.o.), wirdhier explizit angegeben, dass keine Abhängigkeiten existieren.)

– Nachbedingung: Hier die Nachbedingungen angeben. . .

• Member checkLogin(String l, String p) throws RequestException:Prüft, ob es einen Benutzer mit dem Benutzernamen l und dem Pass-wort p gibt. Wenn das so ist, wird der entsprechende Benutzer zurück-gegeben. Der Parameter s gibt die Quelle des Login-Vorgangs an undwird für die Protokollierung des Vorgangs verwendet. Falls kein passen-der Benutzer gefunden wird, wird eine RequestException ausgelöst.

– . . .

• Pair<Book,Member> checkoutBook(Integer i, String l, Member r)throws RequestException:Realisiert (auf Initiative des Benutzers r) die Ausleihe des Buches mit

16

der id i an den Benutzer mit dem Benutzernamen l. Die Liste mit aus-geliehenen Büchern dieses Benutzers wird um das entsprechende Bucherweitert und dessen Ausleih-Referenz wird auf diesen Benutzer gesetzt.Das aktualisierte Buch und der aktualisierte Benutzer werden zurückge-geben. Sollte das Buch nicht verliehen werden können (weil es z.B. be-reits verliehen ist) wird eine RequestException ausgelöst.

– . . .

• List<Book> getAllBooks():Liefert eine Liste aller Bücher.

– . . .

• List<Member> getAllMembers():Liefert eine Liste aller persistenten Benutzer.

– . . .

• Pair<Book, Member> returnBook(Integer i, Member r) throwsRequestException:Realisiert (auf Initiative des Benutzers r) die Rückgabe des Buches mitder gegebenen Id i. Die Ausleih-Referenz des Buches wird gelöscht unddas Buch aus der Liste der ausgeliehenen Bücher des entsprechendenBenutzers entfernt. Das aktualisierte Buch und der aktualisierte Benut-zer werden zurückgegeben. Falls das Buch nicht zurückgegeben werdenkann (weil es z.B. gar nicht verliehen ist) wird eine RequestExceptionausgelöst.

– . . .

4.2.3 Konkretisierung Communication

Im Folgenden werden die Teilmodule des Moduls Communication und derenSchnittstellen beschrieben.

NetworkServer Das Modul NetworkServer bietet grundlegende Netzwerk-kommunikation. Es horcht an einem konfigurierbaren Port und Interface aufeingehende Verbindungen und erzeugt pro Verbindung eine ClientConnection,die den Verbindungsversuch behandelt. Der NetworkServer verwaltet dieseClientConnectons und nimmt Nachrichten vom UpdateHandler und Request-Handler zum Versand an. Diese Nachrichten werden an die entsprechendenClientConnections weitergeleitet. Dieses Modul ergibt sich aus Strategie S13:Kapselung der Low-Level-Kommunikation über TCP. Das Modul hat nur eine Me-thode in seiner Schnittstelle:

• . . .

17

ClientConnection Das Modul ClientConnection repräsentiert die Netzwerk-verbindung zu genau einem Client. Es entscheidet initial über die Gültigkeiteines Verbindungsversuchs und erledigt im weiteren Verlauf das Senden undEmpfangen von Nachrichten. Hierbei wird ebenfalls die Gültigkeit von einge-henden Nachrichten geprüft und im Falle einer zu hohen Fehlerrate die Ver-bindung beendet. Gültige empfangene Nachrichten werden zur Weiterverar-beitung an den RequestHandler geleitet. Das Modul ergibt sich aus der Anwen-dung der Strategien S13: Kapselung der Low-Level-Kommunikation über TCP undS14: Zentrale Prüfung der Validierung eingehender Verbindungen und Nachrichten.

Die Schnittstelle der ClientConnection umfasst die folgenden Methoden:

• . . .

RequestHandler Das Modul RequestHandler verbindet die ClientConnectionmit der BusinessLogic. Hier werden die relevanten Daten aus Client-Anfragenextrahiert und zur Bearbeitung eines Geschäftsprozesses an das Modul Busi-nessLogic weitergeleitet. Das Resultat dieser Bearbeitung wird in ein entspre-chendes Antwort-Objekt verpackt und an den NetworkServer geleitet, um dieAntwort an den Client zu senden. Sollte die Bearbeitung eines Geschäftspro-zesses eine Aktualisierung des Datenbestands ergeben, so wird der Update-Handler angewiesen, die Übermittlung dieser Aktualisierungen an alle Clientszu durchzuführen. Dieses Modul ergibt sich aus Anwendung der StrategieS12: Trennung von Verarbeitungslogik und Daten.

Die Schnittstelle des Moduls RequestHandler enthält nur die folgende Methode:

• handleRequest(ProtocolObject o, ClientConnection c): Behandelt dieAnfrage eines Clients bzw. einer dem Client zugeordneten ClientConnec-tion c. Die Methode extrahiert zunächst den konkreten Anfragetyp ausdem ProtocolObject o und ruft dann die der Anfrage entsprechende Me-thode des Moduls BusinessHandler auf. Wenn die Anfrage erfolgreich be-arbeitet wurde, wird über die ClientConnection c eine SuccessResponsean den anfragenden Client gesendet. Sollte die Anfrage nicht erfolgreichbearbeitet werden können, wird die durch den BusinessHandler entspre-chend ausgelöste Ausnahme gefangen und über die ClientConnection ceine Fehlermeldung an den Client gesendet.

– . . .

UpdateHandler Das Modul UpdateHandler dient dazu, auf Anweisung durchden RequestHandler alle Clients über Änderungen im Datenbestand zu infor-mieren. Dies geschieht durch Erzeugung entsprechender Protokoll-Objekte,die dann durch Nutzung der jeweiligen ClientConnection an alle Clients gesen-det werden. Dieses Modul ergibt sich aus Strategie S15: Protokoll-unabhängige

18

Schnittstelle zur Benachrichtigung von Clients.

Die folgenden Methoden bilden die Schnittstelle des Moduls UpdateHandler:

• updateBooklist(List n): Diese Methode informiert alle aktuell mit demServer verbundenen Clients über eine Aktualisierung der Bücherliste.Diese Methode wird aufgerufen, wenn Bücher hinzugefügt wurden odervorhandene Bücher bearbeitet wurden. Die Liste mit geänderten Büchernfindet sich im Parameter n. Diese Liste wird einem neu erzeugten Upda-teResponse Protokoll-Objekt hinzugefügt und den verbundenen Clientsüber den jeweiligen Aufruf der Methode send() der entsprechenden Cli-entConnection mitgeteilt. Die Liste der ClientConnections wird durch eineentsprechenden Methode des NetworkServers bereitgestellt.

– . . .

• updateBookAndMember(Book b, Member m): Diese Methode infor-miert alle aktuell mit dem Server verbundenen Clients über eine Aktua-lisierung des Buches b und des Benutzers m. Diese Methode wird z.B.dann aufgerufen, wenn ein Buch ausgeliehen wird, denn dann ändertsich sowohl die Ausleiher-Referenz des Buches als auch die Liste derausgeliehenen Bücher des Benutzers. Die Benachrichtigung der Clientsgeschieht dabei genauso wie in der obigen Methode updateBooklist.

– . . .

4.3 Konkretisierung Client

Hier müssen natürlich noch die Modulsichten für den Client angegeben werden

. . .

5 Datensicht

In diesem Kapitel wird das Datenmodell aus der Anforderungsspezifikationkonkretisiert indem im ersten Abschnitt die Strukturierung der Daten nachKlassen und deren Schnittstellen beschrieben wird. Hier werden zunächst nurdie Klassen und deren Beziehungen beschrieben und nicht die ebenfalls not-wendige Abbildung dieser Zusammenhänge auf die Datenbank. Diese Abbil-dung kann zum jetzigen Zeitpunkt nicht angegeben werden, da der Einsatzeines Persistenz-Frameworks zur Datenspeicherung geplant ist. Die konkreteAbbildung ist dabei frameworkspezifisch und wird automatisch vorgenom-men. Sollte dieser Plan nicht umgesetzt werden, so wird dieser Abschnitt ent-sprechend ergänzt.

19

Im zweiten Abschnitt wird die Struktur der Transportobjekte für die Netz-werkkommunikation zwischen Client und Server beschrieben.

5.1 Konkretisiertes Datenmodell

-login : string-password : string-givenName : string-surName : string-email : string-active : boolean-deleted : boolean

Member

-authors : string-bookId : int-checkOutHidden : boolean-edition : string-hiddenReservations : boolean-isbn : string-location : string-owner : string-publisher : string-series : string-theYear : int-title : string-volume : string

Book

<<Constant>> -STUDENT<<Constant>> -EMPLOYEE<<Constant>> -ADMIN

<<Enum>>UserGroup

java.util.Date

Reservation

1

book

reservations 0..*

date1

1

0..*

member

reservations

0..1

checkOutDate

1

0..1

0..*

checkedOutBy

checkedOut

userGroup

Abbildung 7: Konkretisiertes Datenmodell

Abbildung 7 zeigt das konkretisierte Datenmodell des Systems. Die KlasseMember repräsentiert einen Benutzer des Systems. Benutzer haben Vor- undNachnamen (givenName, SurName), einen Benutzernamen (login) und ein Pass-wort (password), mit dem sie sich am System anmelden können. Der Benut-zername muss systemweit eindeutig sein, da es sich hierbei um den Primär-schlüssel für die Abbildung auf die Datenbank handelt und dieser natürlichauch bei Verwendung eines Persistenz-Frameworks definiert werden muss.Die Email-Adresse (email) wird in späteren Versionen für das Mahnwesen ver-wendet. Das Attribut active zeigt an, ob ein Benutzer aktiv oder inaktiv ist. Eininaktiver Benutzer kann sich nicht am System anmelden. Das Attribut deletedzeigt an, ob ein Benutzer gelöscht ist. Wenn ein Benutzer gelöscht wird, ver-bleiben seine Daten im System (da sie z.B. für eine Ausleih-Historie benötigtwerden könnten) aber er ist als gelöscht markiert. Gelöschte Benutzer kön-

20

nen sich ebenfalls nicht am System anmelden. Ein Benutzer hat genau eineBenutzerrolle (userGroup). Benutzerrollen sind im Aufzählungstyp UserGroupfestgelegt und können Student (STUDENT), Mitarbeiter (EMPLOYEE) oderAdministrator (ADMINISTRATOR) sein.

Ein Benutzer hat eine Liste von ausgeliehenen Büchern (checkedOut) und ei-ne Liste von vorgemerkten Büchern (reservations). Da zur Vormerkung einesBuches auch das Datum der Vormerkung gespeichert werden soll, wird statteiner Liste von Büchern eine Klasse Reservation benötigt, die zu jeder Vormer-kung das jeweilige Vormerkungs-Datum (Reservation.date) enthält.

Ein Buch hat einen oder mehrere Autoren (authors), Titel (title), Auflage (editi-on), ISBN (isbn), Verlag (publisher), Reihe (series), Jahrgang (theYear) und Band(volume). Darüberhinaus hat ein Buch eine systemweit eindeutige Kennzahl(bookId), die analog zu Member.login als Primärschlüssel dient.

Da die Bücher nicht zentral an einem Ort aufbewahrt werden und auch externeBücher verliehen werden können, hat ein Buch einen Standort (location) undeinen Besitzer (owner), der nicht zwangsläufig ein Benutzer des Systems seinmuss.

Ein Buch kann von mehreren Benutzern reserviert worden sein, daher hat eseine Liste von Vormerkungen (reservations). Da auch hier das Vormerk-Datumrelevant ist, wird wie oben die Klasse Reservation statt einer Liste von Benut-zern eingesetzt. Ein Buch kann von keinem oder genau einem Benutzer ausge-liehen sein (checkedOutBy) und hat daher noch ein Ausleihdatum checkOutDate.

Die Attribute checkOutHidden und hiddenReservations sind für spätere Erweite-rungen vorgesehen.

21

5.2 Transportmodell

ProtocolObjectjava.util.Date

Request Response

<<Constant>> -LOGIN<<Constant>> -GET_BOOK_LIST<<Constant>> -GET_MEMBER_LIST<<Constant>> -ADD_BOOK<<Constant>> -CHECKOUT_BOOK<<Constant>> -RETURN_BOOK

<<Enum>>RequestCode

java.util.Map

InformationMessage

<<Constant>> -SERVER_ERROR<<Constant>> -CONNECTION_LIMIT_REACHED<<Constant>> -TIME_TO_LOGIN_EXCEEDED<<Constant>> -MAXIMUM_OF_BAD_REQUESTS_REACHED

<<Enum>>InformationCode

1 message

1

values

1

values

1 requestCode

1

creationDate

Abbildung 8: Transportmodell für die Netzwerkkommunikation

Abbildung 8 zeigt einen Teil der Klassen, die für den Transport von Daten überdas Netzwerk verwendet werden. Die zentrale Klasse für den Transport istdie abstrakte Basisklasse ProtocolObject. Sie enthält zu Synchronisationszwe-cken ein creationDate, das bei Erzeugung eines Objektes dieser Klasse das ak-tuelle Datum und die Uhrzeit speichert. Die abstrakten Klassen Response undRequest erweitern dieses Protokoll-Objekt und haben zusätzlich jeweils nocheine Map values, die relevante Daten als Schlüssel-Wert-Paare enthält. Ein Ob-jekt vom Typ Request hat darüber hinaus noch einen requestCode, der unterBenutzung der Konstanten aus RequestCode den konkreten Typ der Anfragebestimmt. Die Klasse InformationMessage erweitert ebenfalls ProtocolObject undenthält zusätzlich eine Nachricht message, die als Konstante aus InformationCo-de kodiert wird.

22

Request

AddRequest UpdateRequest

-login : string-password : string

LoginRequest SelectRequest

Abbildung 9: Unterklassen von Request

Abbildung 9 zeigt die Unterklassen von Request. Ein LoginRequest enthält einenBenutzernamem login und ein Passwort password. Die Klassen SelectRequest,AddRequest und UpdateRequest werden verwendet, um über den Klassenna-men die Art der Anfrage zu bestimmen. Hierbei zeigt ein SelectRequest einereine Datenanfrage an. Ein AddRequest wird verwendet wenn Daten hinzuge-fügt werden sollen, während ein UpdateRequest zur Aktualisierung bestehen-der Daten eingesetzt wird.

Response

ErrorResponse

<<Constant>> -LOGIN_UNKNOWN_USER<<Constant>> -LOGIN_ACCOUNT_DEACTIVATED<<Constant>> -LOGIN_WRONG_PASSWORD<<Constant>> -ADD_BOOK_FAILED<<Constant>> -BOOK_EXISTS<<Constant>> -INSUFFICIENT_PERMISSIONS<<Constant>> -INCONSISTENT_BOOK<<Constant>> -NO_SUCH_BOOK<<Constant>> -NO_SUCH_MEMBER<<Constant>> -BOOK_ALREADY_CHECKEDOUT<<Constant>> -BOOK_NOT_CHECKEDOUT

<<Enum>>RequestFailedReason

SuccessResponse UpdateResponse

<<Constant>> -BOOK_LIST<<Constant>> -BOOK_AND_MEMBER

<<Enum>>UpdateCode

updateCode11 requestFailedReason

Abbildung 10: Unterklassen von Response

23

Abbildung 10 zeigt die Unterklassen von Response. Die ErrorResponse wird ver-wendet um einen Fehler als Reaktion auf eine Anfrage zu melden. Dazu be-sitzt ein Objekt dieses Typs eine Konstante requestFailedReason über die mithilfeder Aufzählung RequestFailedReason der Grund für den Fehler bestimmt wird.Ein Objekt des Typs SuccessResponse übermittelt die erfolgreiche Bearbeitungeiner Anfrage. UpdateResponse wird verwendet, um Aktualisierungen im Da-tenbestand zu übermitteln. Die konkret betroffenen Daten werden über dieKonstante updateCode aus der Aufzählung UpdateCode bestimmt.

6 Ausführungssicht

Die Ausführungssicht beschreibt das Laufzeitverhalten. Hier werden die Laufzeitele-mente aufgeführt und beschrieben, welche Module sie zur Ausführung bringen. EinModul kann von mehreren Laufzeitelementen zur Laufzeit verwendet werden. DieAusführungssicht beschreibt darüber hinaus, welche Laufzeitelemente spezifisch mit-einander kommunizieren.

Abbildung 11: Ausführungssicht

Hier wird das Diagram in Abbildung 11 erklärt.

. . .

24

7 Zusammenhänge zwischen Anwendungsfällenund Architektur

In diesem Abschnitt sollen Sequenzdiagramme mit Beschreibung(!) für die vorgegebe-nen Anwendungsfälle erstellt werden. Jedes Sequenzdiagramm beschreibt den Nach-richtenverkehr zwischen allen Modulen, die an der Realisierung des Anwendungsfal-les beteiligt sind.

In diesem Abschnitt werden Sequenzdiagramme für repräsentative Anwen-dungsfälle der Anforderungsspezifikation ([3]) vorgestellt. Die Anwendungs-fälle sind insofern als repräsentativ zu bezeichnen, als sie zusammengenom-men alle Module des Systems einbeziehen.

7.1 Anwendungsfall Buch hinzufügen

Der Anwendungsfall Buch hinzufügen erstreckt sich über Module sowohl imClient als auch im Server, die nicht in unmittelbarem Zusammenhang stehen.Aus diesem Grund werden für diesen Anwendungsfall mehrere Sequenzdia-gramme angegeben und beschrieben.

NetworkHandler

AddRequest

ClientControlUserInterface

1.3: send(AddRequest a)

1.2: addValue(Book b)

1.1: create(RequestCode.ADD_BOOK)

1: performAddBook(Book b)

Abbildung 12: Sequenzdiagramm zu „Buch hinzufügen“ auf dem Client

Abbildung 12 zeigt ein Sequenzdiagramm für den Anwendungsfall Buch hin-zufügen, das den initialen Nachrichtenverkehr der beteiligten Module auf demClient zeigt. . . .

25

EntityManager

SuccessResponse

UpdateResponse

UpdateHandlerBusinessHandlerRequestHandlerClientConnection

1.2.1: commit(Book b)

1.3.3: notifyAllClients(UpdateResponse r)

1.4: create()

1.5: send(SuccessResponse sr)

1.3.2: addValue(newBook)

1.3.1: create(UpdateCode.BOOK_LIST)1.3: updateBooklist(Book newBook)

1.2.2: Book newBook

1.2: addBook(Book b, Member m)

1.1: handleAddRequest(AddRequest a, ClientConnection c)

1: handleRequest(ProtocolObject o, this)

Abbildung 13: Sequenzdiagramm zu „Buch hinzufügen“ auf dem Server

Abbildung 13 zeigt ein Sequenzdiagramm für den Anwendungsfall Buch hin-zufügen, das den Nachrichtenverkehr der beteiligten Module auf dem Servernach Auslösung durch den Client zeigt.

Die ClientConnection empfängt zunächst über das Netzwerk ein ProtocolObjecto. Um den konkreten Inhalt des Protokoll-Objektes zu bestimmen, wird es zu-sammen mit einer Referenz auf die gerade aktive ClientConnection unverän-dert an den RequestHandler weitergeleitet.

Dort wird das Protokoll-Objekt ausgepackt um die Art der Anfrage zu bestim-men. In diesem Fall handelt es sich um einen AddRequest, so dass die loka-le Methode handleAddRequest mit dem AddRequest und der Referenz auf dieClientConnection aufgerufen wird.

Diese Methode entnimmt der ClientConnection den ihr zugeordneten Benut-zer und bestimmt anhand des requestCodes der Anfrage die konkret auszufüh-rende Aktion. In diesem Fall handelt es sich um das Hinzufügen eines Bu-ches, angezeigt durch die Konstante RequestCode.ADD_BOOK. Daher befin-det sich in values des Requests unter dem Schlüssel book das hinzuzufü-gende Buch-Objekt. Dieses wird zusammen mit dem Benutzer an den Busi-nessHandler weitergereicht.

Hier wird das Buch zur Persistierung an den EntityManager weitergereicht

26

und protokolliert, dass der Benutzer m ein Buch hinzugefügt hat. Das neueBuch wird an den RequestHandler zurückgegeben und von dort an den Upda-teHandler weitergeleitet.

Dieser erzeugt ein neues UpdateResponse-Objekt, das mit dem entsprechendenupdateCode UpdateCode.BOOK_LIST versehen wird, um anzuzeigen, dass essich bei dem Update um eine Aktualisierung der Bücherliste handelt. DiesemUpdate-Objekt wird das neue Buch hinzugefügt und dann wird es an alle ak-tuell verbundenen Clients gesendet. Die Liste der Clients wird dabei als Listevon ClientConnections vom NetworkServer erfragt und dann wird das Update-Objekt aus dieser Liste an jede authentifizierte Client-Verbindung gesendet.

Danach erzeugt der RequestHandler eine SuccessResponse und übergibt sie andie ClientConnection, die die ursprüngliche Anfrage entgegennahm. Von dortwird sie über das Netzwerk an den entsprechenden Client gesendet, um die-sen über die erfolgreiche Bearbeitung der Aktion zu informieren.

ClientControlUserInterfaceResponseHandlerMessageHandlerNetworkHandler

1.2.2: clearPendingRequest()

1.2.1: showSuccessDialog(RequestCode r)

1.2: updateSuccess(RequestCode r)

1.1: handleSuccessResponse((SuccessResponse)o)

1: handleMessage(ProtocolObject o)

Abbildung 14: Fortgesetztes Sequenzdiagramm zu „Buch hinzufügen“ aufdem Client

Abbildung 14 zeigt ein Sequenzdiagramm für den fortgesetzten Anwendungs-fall Buch hinzufügen, das den Nachrichtenverkehr der beteiligten Module aufdem Client nach erfolgter Reaktion des Servers zeigt. . . .

27

ClientControl UserInterfaceResponseHandlerMessageHandlerNetworkHandler

1.2.2: bookListUpdated()

1.2.1: addOrUpdateBook(b)

1.2: receivedBookUpdate(Book b)

1.1: handleUpdateResponse((UpdateResponse)o)

1: handleMessage(ProtocolObject o)

Abbildung 15: Sequenzdiagramm zur Reaktion des Clients auf Aktualisierungbei „Buch hinzufügen“

Abbildung 15 zeigt das Sequenzdiagramm für den Nachrichtenverkehr der be-teiligten Module eines Clients wenn eine Update-Benachrichtigung vom Ser-ver eingeht. Diese Update-Benachrichtigung wird wie oben beschrieben (undaus Abbildung 13 ersichtlich) vom Server gesendet wenn ein neues Buch er-folgreich in den Datenbestand integriert wurde. . . .

7.2 Anwendungsfall . . .

. . .

8 Evolution

Beschreibt in diesem Abschnitt, welche Änderungen Ihr vornehmen müsst, wenn sichAnforderungen oder Rahmenbedingungen ändern. Insbesondere sollten hierbei die inder Anforderungsspezifikation unter „Ausblick“ bereits genannten Punkte behandeltwerden.

. . .

28