Technische Universität München
Institut für Informatik
FORSOFT Teilprojekt ZEN
Technische Universität München
|
|
|
|
ADL-Workshop - Aufgabenbeschreibung
Ziele
Ziel des Workshops ist es, die Konzepte bestehender Architekturbeschreibungssprachen
(„Architectural Description Languages“ bzw. ADLs) zu identifizieren und
zu vergleichen. Von besonderem Interesse ist es hierbei, einerseits die
Mächtigkeit einzelner ADLs zu untersu-chen und andererseits ihre Eignung
für den praktischen Einsatz zu prüfen.
Im folgenden werden eine Reihe von Fragestellungen zu ADLs vorgestellt,
welche eine Klas-sifikation ggf. erleichtern können. Diese sollten
jedoch lediglich als Anregungen zur Ausei-nandersetzung mit ADLs verstanden
werden.
Um die Ausdrucksmächtigkeit, und somit das potentielle Anwendungsfeld
einer ADL besser abschätzen zu können, bietet sich eine Untersuchung
folgender Fragestellungen an:
Vorgehen
Jeder Teilnehmer bzw. jede Teilnehmergruppe wählt sich eine spezifische
ADL aus (vgl. Lis-te am Ende der Workshop-Beschreibung). Die Teilnehmer
machen sich in einem Zeitraum von ca. einer Woche mit dieser ADL vertraut.
Anschließend versucht jeder Teilnehmer das im folgenden Abschnitt
beschriebene System mit Hilfe dieser Beschreibungssprache zu mo-dellieren.
Auf die Modellierung der GUI des Systems kann hierbei verzichtet werden.
Im Anschluss stellen die Teilnehmer im Rahmen eines gemeinsamen Workshops
jeweils „ihre“ ADL und die fertige Modellierung des Systems vor. In der
gemeinsamen Diskussion sollen die im vorigen Abschnitt angeführten
Fragen zur Mächtigkeit und Verwendbarkeit von ADLs für die einzelnen
Beschreibungssprachen erörtert werden.
Das zu modellierende System
Modelliert werden soll das von sd&m-Research zur Verfügung gestellte Telecom-Billing-System (TBS) zur Erstellung von Telefonrechnungen. Hierzu kann auf die vorhandene Do-kumentation zugegriffen werden. Als „letzte Instanz“ bei Unklarheiten in der Spezifikation des Systems dient der Quellcode. Hierdurch soll sichergestellt werden, dass alle Beteiligten das selbe System modellieren und keinen Design-Contest veranstalten. Das TBS wurde um eine zusätzliche Komponente Billing erweitert, die mit Fremdsystemen der Kunden kommuniziert. Abbildung 1 zeigt den groben Aufbau des Systems, wobei die Komponenten für die kein Quellcode existiert gestrichelt eingezeichnet sind.
Abbildung 1: Wesentliche Komponenten des TBS
Abbildung 3: Erfolgloser Zahlungsvorgang
Die Komponente für den Versand von Rechungen lässt jeden Monat
automatisch eine neue Rechnung erstellen und versendet die darin enthaltenen
Daten mittels HTTP in einem SO-AP-Aufruf „Invoice“ an den jeweiligen Kunden.
Als Antwort sendet das Finanzsystem des Kunden eine Zahlungsankündigung
(Avis), in dem es den Betrag, die Kontonummer und das Datum der Überweisung
ankündigt. Der zu überweisende Betrag kann unter dem Rech-nungsbetrag
liegen, wenn der Kunde zusätzlich „Phone-Miles“ einlöst.
Das TBS prüft die Daten durch einen Aufruf an eine weitere Prüf-Komponente
die ggf. auch Anwender involviert. Im Erfolgsfall sendet das TBS eine SOAP-Nachricht
„Payment Ac-cepted“ an das Kundensystem und zieht die Phone-Miles vom Konto
des Kunden ab. Diese Komponente soll jedoch nicht mehr Teil der Beispielapplikation
sein, für das hier zu modellie-rende System liefert sie lediglich
nichtdeterministisch entweder den Wert „true“ oder „false“. Schlägt
die Überprüfung des Avis fehl (z.B. durch eine ungültige
Nachricht vom Kundensys-tem oder weil der Kunde nicht mehr genügend
Phone-Miles hat), so wird eine Nachricht „Reminder“ an das Kundensystem,
das alle Daten der Rechnung beinhaltet, geschickt. Das System des Kunden
muss daraufhin erneut einen Zahlungsavis an das TBS senden.
Schlägt die Überprüfung dieses Avis ebenfalls fehl,
so sendet das TBS eine Nachricht „Pay-ment Not Accepted“ an das Kundensystem,
um diesem zu signalisieren, dass die automati-sche Überweisung nicht
erfolgen soll. Gleichzeitig wird das Problem per Email an einen Sachbearbeiter
eskaliert, der nun die weitere Bearbeitung des Zahlungsvorgangs manuell
abschließt. Das TBS verhält sich genauso, wenn es nach der Versendung
einer Erinnerung nicht innerhalb von 48 Stunden eine gültige Antwort
des Kundensystems erhält. Antwortet das Kundensystem innerhalb von
48 Stunden nicht auf eine „Invoice“-Nachricht, so wird eine Erinnerung
verschickt; ein Kunde bekommt jedoch nie mehr als eine Erinnerung.
Die von der Billing-Komponente empfangenen und gesendeten SOAP-Nachrichten
sind im einzelnen:
Gesendete Nachrichten:
| Name | Parameter |
| Invoice | int invoiceID
int amount date startDate date endDate |
| Reminder | int invoiceID
int amount date startDate date endDate string comment |
| Payment Accepted | |
| Payment Not Accepted | string comment |
Empfangene Nachrichten:
| Name | Parameter |
| Avis | int invoiceID
int amount int amountOfPhoneMiles string bankAccountInfo date dateOfTransfer string comment |
Im Gegensatz zum Rest der Anwendung existiert für die Billing-Komponente
kein Code. Die Signaturen der einzelnen SOAP-Nachrichten werden hier nicht
explizit festgehalten, da sie für die Modellierung der Architektur
eher unerheblich sind und als Black-Box-Komponenten angesehen werden können.
Auch die von der Billing-Komponente verwendeten Technolo-gien (SOAP-fähiger
http-Server, XML-Parser, Datenbank etc.) werden hier nicht explizit be-schrieben.
Sie können als Black-Box-Komponenten angesehen werden, welche Methoden-aufrufe
in SOAP-Nachrichten umwandeln, bzw. beim Eingang einer SOAP-Nachricht ent-sprechende
Methoden in der Billing-Komponente aufrufen.