Architekturbeschreibung PSA/BikeShop Version 1.0

Transkript

1 Architekturbeschreibung PSA/BikeShop Version 1.0 Rainer Koschke Universität Bremen 4. Februar Einführung 1.1 Zweck Dieses Dokument dient als Vorlage für die Gliederung Ihrer Architekturbeschreibung. Gleichzeitig dient es als Beispiel für Ihre Architekturbeschreibung. Hierzu sind exemplarisch einige Architekturelemente näher beschrieben. Dieses Beispiel soll Ihnen eine Idee vermitteln, wie wir uns die Beschreibung vorstellen. Um den Text des Beispiels von den Meta-Kommentaren zur Architekturbeschreibung unterscheiden zu können, sind letztere kursiv gesetzt. Dieses Dokument beschreibt die Architektur von PSA/Bikeshop. Die Architektur soll zeigen, wie die Anforderungen, die in der Anforderungsspezifikation PSA/Bikeshop [Anforderungsspezifikation Version 1.0] angegeben sind, realisiert werden können. Dieses Dokument dient den Entwicklern als Vorgabe für die Implementierung, den Testern für die Vorbereitung der Black-Box-Tests und den Wartungsingenieuren für die Beurteilung der Änderbarkeit des Systems für mögliche zukünftige Anforderungen, wie sie in der Anforderungsspezifikation beschrieben sind. 1.2 Status Diese Dokument beschreibt den ersten Entwurf. Es wurde noch nicht durch ein Architektur-Review freigegeben. 1.3 Definitionen, Akronyme und Abkürzung GUI Graphical User Interface PDA Personal Digital Assistant PSA Personal Shopping Assistant 1.4 Referenzen Literatur [IEEE P1471] IEEE Recommended Practice for Architectural Description of Softwareintensive Systems Std ISBN , IEEE, New York, NY, USA,

2 [Hofmeister et al., 2000] Christine Hofmeister, Robert Nord, Dilip Soni. Applied Software Architecture. Addison Wesley, Object Technology Series, [Anforderungsspezifikation Version 1.0] DreamBikers. Anforderungspezifikation PSA/Bikeshop. Version 1.2 vom 18. Januar intranet.dreambikers.com/nowhere 1.5 Übersicht über das Dokument Die Architekturbeschreibung genügt dem IEEE-Standard [IEEE P1471] und folgt den Architekturblickwinkeln von Hofmeister et al. [Hofmeister et al., 2000]. Zunächst werden in Kapitel 2 die Einflussfaktoren für den Entwurf, Probleme sowie mögliche Lösungsstrategien dargestellt. Dann werden in den Kapiteln 3, 4 und 5 drei der vier Sichten nach [Hofmeister et al., 2000] beschrieben (auf die Code-Sicht wird in diesem Projekt verzichtet). Im Abschnitt 6 wird dargelegt, wie das System geändert werden muss, wenn sich Rahmenbedingungen oder Anforderungen ändern. 2 Globale Analyse Hier werden Einflussfaktoren aufgezählt und bewertet sowie Strategien zum Umgang mit interferierenden Einflussfaktoren entwickelt. 2.1 Einflussfaktoren Faktor Flexibilität und Änderbarkeit Auswirkung P2 : Funktionale Eigenschaften P2.1 : Zugrundeliegendes Datenmodell Fahrraddomäne Neue Domänen sollen zukünftig erschlossen werden. Betrifft Datenrepräsentation und -haltung, Constraint- Auflösung sowie Benutzerschnittstelle (mit anderen Worten: alles) 2

3 <<component>> : PDA Client <<component>> : Main caller <<connector>> :Control callee <<component>> : GUI caller <<connector>> :Data pull <<connector>> :Control callee <<component>> : Article Base <<connector>> :Data pull <<component>> : Constraint Solver Abbildung 1: Aufbau des PSA 2.2 Probleme und Strategien Neue Domänen Neue typen können zu einer Domäne hinzukommen. Ganz neue Domänen sollen erschlossen werden. Die Änderungen sollen mit möglichst geringem Aufwand realisiert werden können. Eine Neuübersetzung und -installation ist akzeptabel. Einflussfaktoren O1.1: Time-To-Market 02.1: Anzahl Entwickler P2.1: Zugrundeliegendes Datenmodell P6.3: Softwareinstallation und -aktualisierung Lösung Strategie: S1: Gekapseltes Datenmodell Das Datenmodell wird in einer Komponente gekapselt. Das Schema kann statisch (d.h. zur Übersetzungszeit) konfiguriert werden. Das Schema selbst ist durch ein Meta-Schema beschrieben, das als Konzepte, Eigenschaften und Abhängigkeiten umfasst. Andere Komponenten, insbesondere die graphische Benutzeroberfläche beziehen sich nur auf diese Meta-Konzepte, d.h. nicht direkt auf die konkreten Konzepte der Fahrraddomäne (z.b. Sattel). Beschreiben Sie möglichst mehrere Alternativen und geben Sie an, für welche Sie sich letztlich aus welchem Grunde entschieden haben. 3 Konzeptionelle Sicht Diese Sicht beschreibt das System auf einer hohen Abstraktionsebene, d.h. mit sehr starkem Bezug zur Anwendungsdomäne und den geforderten Produktfunktionen und -attributen. Sie legt die Grobstruktur fest, ohne gleich in die Details von spezifischen Technologien abzugleiten. Sie wird in den nachfolgenden Sichten konkretisiert und verfeinert. 3

4 Der PSA besteht aus den folgenden Komponenten (vergleiche Abbildung 1): Main: das Hauptprogramm, das die PSA-Komponenten initialisiert und hernach der GUI die Kontrolle übergibt. Will der Benutzer das Programm beendet, übergibt die GUI die Kontrolle wieder zurück an Main. Main fährt dann das Programm herunter. GUI: die grafische Benutzeroberfläche, mit der der Benutzer interagiert. Article Base: die Datenhaltung für die, die der Kunde bereits gekauft hat. Constraint Solver: der Abgleich von Einschränkungen zu n; hier wird geprüft, ob ein zu kaufender zu den bereits gekauften n passt. Folgende Konnektoren werden hierfür verwendet: Control: Der Caller übergibt die Kontrolle an den Callee; beschreibt den Kontrollfluss. Data: Die Rolle pull übermittelt mögliche Eingabeparameter, anhand derer Daten hergeleitet werden sollen, an die andere Rolle, übergibt dieser die Kontrolle und empfängt schließlich von der anderen Rolle die Daten. Anschließend hat die pull-rolle wieder die Kontrolle. Der Datenaustausch verläuft synchron. 4 Modulsicht Diese Sicht beschreibt den statischen Aufbau des System mit Hilfe von Modulen, Subsystemen, Schichten und Schnittstellen. Diese Sicht ist hierarchisch, d.h. Module werden in Teilmodule zerlegt. Die Zerlegung endet bei Modulen, die ein klar umrissenes Arbeitspaket für eine Person darstellen und in einer Zeitwoche implementiert werden können. Die Modulbeschreibung der Blätter dieser Hierarchie ist genau genug und ausreichend, um das Modul zu implementieren. Die Module werden durch ihre Schnittstellen beschrieben. Konkrete Implementierungen dieser Schnittstellen sind das Geheimnis des Moduls und können vom Programmier festgelegt werden. Sie werden sollen hier nicht beschrieben werden. Die Schnittstellen eines Moduls M ist die Menge aller Annahmen, die andere Module über M machen dürfen, bzw. jene Annahmen, die M über seine verwendeten Module macht (bzw. seine Umgebung, wozu auch Speicher, Laufzeit etc. gehören). Jeder Schnittstelle liegt ein Protokoll zugrunde. Das Protokoll beschreibt die Vor- und Nachbedingungen der Schnittstellenelemente. Dazu gehören die erlaubten Reihenfolgen, in denen Methoden der Schnittstelle aufgerufen werden dürfen, sowie Annahmen über Eingabe- und Zusicherungen über Ausgabeparameter. Das Protokoll von Modulen soll einmal in der Modulsicht beschrieben werden. Die Ausführungssicht verwendet das Protokoll, es soll aber die Protokollbeschreibung nicht noch einmal wiederholen. 4.1 Konkretisierung Article Base Verhältnis GUI und Abbildung 2 beschreibt die Modulsicht zum Verhältnis von GUI zur Article Base. Die Zuordnung der Module zur Article Base ist in Tabelle 1 wiedergegeben. 4

5 bestand Attribut Attributwert String Attributwert Integer Attributwert Float Attributwert verwaltet die vollständige Liste aller vom Kunden gekauften ein einzelner ; definiert die Schnittstelle für alle und die Attribute, die alle haben (Preis und Nummer, letztere beschreibt den eindeutig); domänenspezifische Attribute werden durch die Klasse Attribut beschrieben; die konkreten der Domäne werden von Klasse abgeleitet (sie sind in [Anforderungsspezifikation Version 1.0] beschrieben und sollen hier nicht wiederholt werden). domänenspezfisches Attribut eines s abstrakte Klasse für Attributwerte konkretes String-Attribut konkretes Integer-Attribut konkretes Float-Attribut Tabelle 1: Liste der Module zur Article Base. Blatt Behälter ein nicht zusammengesetzter ein, der aus weiteren n besteht Tabelle 2: Fortgesetzte Liste der Module zur Article Base. Hier muss noch die Schnittstelle der Module beschrieben werden. Als Beispiel sei auf Abschnitt verwiesen. Die GUI verwendet nur die Schnittstelle von, nicht jedoch Schnittstellen der konkreten Unterklassen, die domänenspezifisch sind. Umgesetzt wird bei dieser Modularisierung die Strategie S1: Gekapseltes Datenmodell. Die GUI benötigt nur eine Zeichenkettenrepräsentation der werte und verwendet somit nur die Klasse Attributwert, nicht jedoch deren Unterklassen. Auf diese Weise können weitere Attributwerte leicht eingeführt werden. Relevant sind die konkreten Werte für den Leser der daten und den Constraint Solver Realisierung zusammengesetzter bestehen aus Teilartikeln. Um der GUI eine einheitliche Schnittstelle zusammengesetzter Attribute zur Verfügung zu stellen, wird an dieser Stelle das Entwurfsmuster Composite verwendet. Der Zusammenhang ist in Abbildung 3 beschrieben. Die Rolle des Verwenders nimmt hier die GUI ein. Die Schnittstellenelemente sind in den Tabellen 3, 4 und 5 detailliert. Die domänenspezifischen werden entweder von Blatt oder Behälter abgeleitet. entfernen () hinzufügen () alleteile () löscht einen und alle seine Teile fügt einen als Teil ein liefert alle Teile eines s als Liste (im Falle von Blättern wird dies immer die leere Liste sein) Tabelle 3: Schnittstelle 5

6 GUI bestand +Alle(): list of +lies(dateinamen) * +Preis(): float +AlleAttribute(): list of Attribut +Attributnummer(): int * Attribut +Wert(): Attributwert +Name(): string 1 Attributwert +To_String(): string String Attributwert +To_String(): string +Value(): string Integer Attributwert +To_String(): string +Value(): int Float Attributwert +To_String(): string +Value(): float Abbildung 2: Bezug GUI und Verwender +hinzufügen() +alleteile(): list of Teile Blatt +hinzufügen() Behälter for each t in Teile t.entfernen() Mantel Felge Rahmen Laufrad Rad Abbildung 3: Zusammengesetzte entfernen () hinzufügen () löscht den wirft die Ausnahme leaf_has_no_parts Tabelle 4: Schnittstelle Blatt entfernen () löscht einen und alle seine Teile Tabelle 5: Schnittstelle Behälter 6

7 Leser liest von einer Datei und erzeugt sie; die genaue Syntax der Eingabedatei ist das Geheimnis dieses Moduls Tabelle 6: Teilmodule von bestand. GUI Leser +lies(dateinamen) id = datei.liesid() f.fabrikmethode(id) Schöpfer +FabrikMethode(id) +Eintragen(id) artikel = FabrikMethode (id) artikelliste.einfuegen (artikel) Rahmen Blatt Felge Behälter FahrradSchöpfer +FabrikMethode(id) <<create>> <<create>> Laufrad <<create>> if (id=="rahmen") return new Rahmen; if (id=="felge") return new Felge;... Abbildung 4: Entwurfsmuster Factory Method für das Einlesen von n Einlesen von n Das Einlesen von n von Datei wird vom Modul Leser realisiert (siehe Abbildung 6. Hierzu wird das Entwurfsmuster Abstract Factory verwendet (siehe 4). Hier muss noch die Schnittstelle der Module beschrieben werden. Als Beispiel sei auf Abschnitt Ausführungssicht Das Laufzeitverhalten wird in der Ausführungssicht beschrieben. Hier werden die Laufzeitelemente aufgeführt und beschrieben, welche Module sie zur Ausführung bringen. Ein Modul kann von mehreren Laufzeitelementen zur Laufzeit verwendet werden. Die Ausführungssicht beschreibt darüber hinaus, welche Laufzeitelemente spezifisch miteinander kommunizieren.... und hier erklären wir das Diagramm in Abbildung Evolution Beschreiben Sie in diesem Abschnitt, welche Änderungen sie vornehmen müssten, wenn sich das zugrunde liegende Datenmodell für für Ihre Software ändern würde. Untersuchen Sie hierbei zwei Änderungsszenarien: (1) neue typen in ihrer Domäne kommen hinzu und (2) die Software soll auf eine völlig neue Domäne übertragen werden (mit fortgesetzter, paralleler Unterstützung der ursprünglichen Domäne, versteht sich). 7

8 : PDA : Ladenrechner : Datenbankrechner <<process>> * <<process>> n <<process>> 1 Personal Shop Assistant <<module>> PDA client * TCP/IP 1 Shop Server <<module>> Server * TCP/IP 1 Data Base Server <<subsystem>> transaction monitor <<subsystem>> SQL manager <<subsystem>> data base Abbildung 5: Ausführungssicht 8