Kapitel 3: Statische Analyse mit FUSION

Transkript

1 Die erste Phase Kapitel 3: Statische Analyse mit FUSION SoPra 2008 Kap. 3: Statische Analyse mit FUSION (1/44)

2 Kapitel 3.1: Anforderungsdokument Vorgabe: Informelle Anforderungen (Requirements): Lastenheft (Kundenwünsche) Pflichtenheft (Verhandlungsergebnis, präzisiert Lastenheft) Inhalt: typischerweise umgangssprachlich gegeben fachchinesisch der Anwendung ideal: Beschreibung der Anforderungen (Was ist das Problem, das gelöst werden soll?) oft: Lösungsansätze oder -vorgaben für Teile des Systems manchmal auch: Implementierungsdetails häufig von mehreren Personen erstellt keine völlig einheitlichen Begriffe SoPra 2008 Kap. 3.1: Statische Analyse mit FUSION Anforderungsdokument (2/44)

3 Beispiel: Buchungssystem Allgemeines 1. Buchungssystem soll die Belegung von Räumen in einer Firma (oder der Uni) verwalten. 2. Gegeben ist eine Reihe von Gebäuden mit verschiedenartigen Räumen (Seminarräume, Besprechungsräume, Hörsäle etc.). 3. Räume unterscheiden sich nach Kapazität und Inventar (Beamer/Projektor/Tafel). 4. Belegungsplan der Räume wird verwaltet. (Welcher Raum ist wann von wem für welche Veranstaltung belegt?) SoPra 2008 Kap. 3.1: Statische Analyse mit FUSION Anforderungsdokument (3/44)

4 Beispiel: Buchungssystem Buchungen 1. Benutzer des Systems legt eine Buchung pro Veranstaltung an. 2. Buchungen bestehen aus einem oder mehreren Terminen, die je einen Raum zu einem festen Zeitpunkt für eine gewisse Dauer belegen. 3. Eine Buchung wird angelegt als Einzelbuchung: genau ein Raum wird zu einem Termin belegt periodische Buchung: regelmäßige Termine (jede Woche) Mehrfachbuchung: Mehrere Räume zu einem Termin (für Großveranstaltung, Tutorien) 4. Es soll möglich sein, ganze Buchungen oder auch nur einzelne Termine zu ändern (Zeit/Ort verlegen, streichen, erweitern etc.). 5. Der Benutzer wird über die erfolgten Buchungen informiert. SoPra 2008 Kap. 3.1: Statische Analyse mit FUSION Anforderungsdokument (4/44)

5 Beispiel: Buchungssystem Rechte 1. Das System ist ein Einzelplatzsystem (keine parallelen Clients). 2. Es gibt aber verschiedene Benutzer, die sich mit Passwort anmelden. 3. Benutzer können nur eigene Buchungen anlegen/ändern/löschen. 4. Benutzer können nur zukünftige Termine ändern. 5. Es gibt einen Administrator, der alle Buchungen ändern darf. SoPra 2008 Kap. 3.1: Statische Analyse mit FUSION Anforderungsdokument (5/44)

6 Beispiel: Buchungssystem Anlegen von Buchungen 1. Beim Anlegen (oder auch Ändern) einer Buchung gibt der Benutzer einen Wunsch ein, wie die Buchung aussehen soll: welcher Zeitraum welche Dauer welche Kapazität und Mindestausstattung welcher Raum und welches Gebäude (meist egal) 2. Das System macht Vorschläge, z.b. Raum 1005 ist von 10:00-15:00 Uhr für eine Stunde frei 3. Benutzer wählt dann die konkrete Stunde SoPra 2008 Kap. 3.1: Statische Analyse mit FUSION Anforderungsdokument (6/44)

7 Kapitel 3.2: Analyse mit FUSION Ziel und Ergebnisse Ziel: Präzisierung des Problems und der Lösungsanforderungen Vollständigkeit der Anforderungen Eindeutigkeit der Begriffsbildungen Widerspruchsfreiheit der Anforderungen Festlegung, was als (Software-)System realisiert wird Ergebnis: Semiformale Modelle semiformal = eindeutige Syntax, keine formalisierte Semantik typisch: Diagrammhafte Darstellungen von Objekten, Beziehungen, Abläufen Methoden unterscheiden sich in Art und Reihenfolge der Modelle SoPra 2008 Kap. 3.2: Statische Analyse mit FUSION Analyse mit FUSION (7/44)

8 Analyse mit FUSION Generelles Vorgehen in 5 Schritten (1) Statische Analyse 1. Entwicklung des Objektmodells (object model): Was sind die relevanten Begriffe für das Problem? In welchen Beziehungen stehen sie? Was liegt innerhalb/außerhalb des Systems? Dynamische Analyse 2. Entwicklung des Interaktionsmodells (interaction model): Wie wird mit dem System kommuniziert? Was sind typische Abläufe (Szenarios)? Was sind die Systemoperationen? SoPra 2008 Kap. 3.2: Statische Analyse mit FUSION Analyse mit FUSION (8/44)

9 Analyse mit FUSION Generelles Vorgehen in 5 Schritten (2) 3. Entwicklung des Operationsmodells (operation model) Deklarative Beschreibung des Verhaltens der Systemoperationen. 4. Entwicklung der Lebenszyklen (life cycle model) Was für Abläufe sind möglich? In welcher Reihenfolge werden Systemoperationen verwendet? In FUSION werden interaction model, operation model und life cycle model zusammen als interface model bezeichnet. 5. Abgleich der 4 Modelle Parallel dazu: Anlegen eines Glossars (data dictionary). SoPra 2008 Kap. 3.2: Statische Analyse mit FUSION Analyse mit FUSION (9/44)

10 Kapitel 3.3: Das Objektmodell Objektmodell besteht aus Klassen (classes) mit Attributen (attributes) und Assoziationen (associations) zwischen den Klassen Klassen (Name oben) werden als Rechtecke notiert, Attribute in der unteren Hälfte Assoziationen werden als Kanten notiert, Angaben zur Kardinalität an den Kanten Gebäude Name enthält 1 * Raum Sitzplätze hatbeamer SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (10/44)

11 Analyse mit FUSION Das Objektmodell: UML Klassendiagramme Vorgehen 1. Bestimmung der Klassen 2. Bestimmung der Assoziationen 3. Bestimmung der Attribute Im Folgenden: Begriffe und Vorgehen am Beispiel Buchungssystem SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (11/44)

12 Entwicklung des Objektmodells 1. Bestimmung relevanter Begriffe relevante Begriffe werden zu (Fach-)Klassen (und später: Attributen) zunächst alles als Klassen ( Objekttyp, Menge von gleichartigen Objekten) betrachten Heuristik: Substantiv Klasse physikalische Objekte Personen/Organisationen abstrakte Begriffe sowohl Klassen mit genau einer Instanz als auch solche mit vielen kommen vor SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (12/44)

13 Beispiel: Buchungssystem Allgemeines 1. Das Buchungssystem soll die Belegung von Räumen in einer Firma (oder der Uni) verwalten. 2. Gegeben ist eine Reihe von Gebäuden mit verschiedenartigen Räumen (Seminarräume, Besprechungsräume, Hörsäle etc.). Raumtyp 3. Die Räume unterscheiden sich nach Kapazität und Inventar (Beamer/Projektor/Tafel etc.). 4. Es wird ein Belegungsplan der Räume verwaltet. (Welcher Raum ist wann von wem für welche Veranstaltung belegt?) SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (13/44)

14 Beispiel: Buchungssystem Buchungen 1. Benutzer des Systems legt eine Buchung pro Veranstaltung an. 2. Buchungen bestehen aus einem oder mehreren Terminen, die einen Raum zu einem festen Zeitpunkt für eine gewisse Dauer belegen. 3. Eine Buchung wird angelegt als Einzelbuchung: genau ein Raum wird zu einem Termin belegt periodische Buchung: regelmäßige Termine (jede Woche) Mehrfachbuchung: Mehrere Räume zu einem Termin (für Großveranstaltung, Tutorien) 4. Es soll möglich sein, ganze Buchungen oder auch nur einzelne Termine zu ändern (Zeit/Ort verlegen, streichen, erweitern etc.). SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (14/44)

15 Beispiel: Buchungssystem Rechte 1. Das System ist ein Einzelplatzsystem (keine parallelen Clients). 2. Es gibt aber verschiedene Benutzer, die sich mit Passwort anmelden. 3. Benutzer können nur eigene Buchungen anlegen/ändern/löschen. 4. Benutzer können nur zukünftige Termine ändern. 5. Es gibt einen Administrator, der alle Buchungen ändern darf. SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (15/44)

16 Beispiel: Buchungssystem Anlegen von Buchungen 1. Beim Anlegen (oder auch Ändern) einer Buchung gibt der Benutzer einen Buchungswunsch ein, wie die Buchung aussehen soll: welcher Zeitraum welche Dauer welche Kapazität und Mindestausstattung welcher Raum und welches Gebäude (meist egal) Raumwunsch als Teil des Wunsches 2. Das System macht Vorschläge, z.b. Raum 1005 ist von 10:00-15:00 Uhr für eine Stunde frei. 3. Benutzer wählt dann die konkrete Stunde. SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (16/44)

17 Entwicklung des Objektmodells 2. Bestimmung relevanter Beziehungen relevante Beziehungen zwischen Objekten werden zu Assoziationen zwischen Klassen Assoziationen beschreiben Mengen von Objektpaaren verschiedene typische Fälle: 1. physikalische Beziehungen: Gebäude enthält Raum 2. Elementbeziehung: Termin ist Element von Buchung 3. Spezialisierung/Generalisierung 4. Wissen Beziehungen dauern an, sind zu speichern reine Aktionen, dynamisches Verhalten, Kommunikation mit dem System wird nicht als Assoziation modelliert: Benutzer gibt Raumwunsch ein SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (17/44)

18 2. Bestimmung relevanter Beziehungen Physikalische Beziehungen benachbart_zu Nachbar * Gebäude * Bezug Termin * findet_statt_in 1 Raum mögliche Kardinalitäten: 1, 0..3, * geben an, wie viele Objekte zu einem Objekt in Relation stehen können * : beliebig viele, + als Abkürzung für 1..* SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (18/44)

19 2. Bestimmung relevanter Beziehungen Elementbeziehung ist (physikalisch oder logisch) enthalten in, ist Bestandteil von Komposition und Aggregation Buchung * Termin Gebäude * Raum * Inventar SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (19/44)

20 2. Bestimmung relevanter Beziehungen Spezialisierung Spezialisierung/Generalisierung:... ist ein... Buchungswunsch Mehrfachwunsch periodischer Wunsch Einzelwunsch Zusätzliche Angaben: {disjoint}, {overlapping}, {complete}, {incomplete} SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (20/44)

21 2. Bestimmung relevanter Beziehungen Wissen A muss B kennen, damit Vorgänge sinnvoll durchgeführt werden können ( needs to know ). Raumwunsch 1 zulässige Räume 1..* Raum Der Raumwunsch muss die zulässigen Räume kennen sonst können keine Vorschläge berechnet werden. Termin muss den Raum kennen, den er belegt (1:1). Benutzer muss die Buchungen kennen, die ihm gehören. SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (21/44)

22 Entwicklung des Objektmodells 3. Festlegung der Attribute Attribute sind charakteristische Merkmale der Objekte eines Konzepts. Ob ein Merkmal eher ein Attribut oder ein Konzept (Klasse) ist, ist nicht immer eindeutig. Im Zweifel zunächst eher eine Klasse. Klassen sollten in Attribute gewandelt werden, wenn die Objekte der Klasse keine eigene Identität haben (zweimal das selbe Datum sollte nicht unterschieden werden). typisch für Attribute sind primitive Datentypen wie: boolean, int, String, Aufzählungstypen (Farbe, Wochentag, etc.) Attribute für zusammengesetzte Datentypen nur, wenn nicht weiter analysiert: Datum, Adresse, etc. Mindestanforderung für die Umwandlung einer Klasse in ein Attribut: Klasse kommt nur in 1:*-Beziehungen vor SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (22/44)

23 Objektmodell für Buchungssystem SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (23/44)

24 Bestimmung der Systemschnittstelle Festlegung, welche Konzepte (Klassen) zum System gehören, und welche außerhalb liegen. (System object model) Einzeichnen durch geschlossene, gestrichelte Kurve. Festlegung hängt von der intendierten Funktionalität ab. Beispiel Buchungssystem: alle Konzepte liegen innerhalb der Systemgrenze. SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (24/44)

25 Analyse Weitere Hinweise Die GUI, also wie die Daten präsentiert werden, ist unerheblich für die statische Analyse. also: keine Klassen für Oberfläche wie Mitarbeiterfenster erst Szenarien, Abläufe, Lebenszyklen bestimmen (ohne genaues Aussehen der Fenster), danach GUI-Design Eine Datenbank spielt ebenfalls keine Rolle in der Analyse (Abbildung Objekte auf Datenbank durch Persistenzschicht) SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (25/44)

26 Data Dictionary (1) Das Data Dictionary dient zur Dokumentation aller bei der Entwicklung des Systems verwendeten (eindeutigen) Begriffe. ohne Glossar sind die Diagramme kaum zu verstehen zentrale Stelle zum Nachschlagen vermeidet Inkonsistenzen bei großen Entwicklerteams, die Teile unabhängig voneinander entwickeln wichtig, um die Begriffe der Modelle zu erklären für später hinzu kommende Entwicker für spätere Wartung erleichtert die Erstellung der Dokumentation SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (26/44)

27 Data Dictionary (2) Das Data Dictionary ist zentrale Ablage und ein Nachschlagewerk von Begriffsdefinitionen und Konzepten. Sämtliche relevante Informationen, die in den Diagrammen keinen Platz finden, werden hier gesammelt. Es enthält u. a. Definitionen für Agenten, Klassen, Attribute, Assoziationen, Invarianten, Systemoperationen, Prädikate, Events. SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (27/44)

28 Data Dictionary (3) Form der Einträge 3 Spalten: Name Typ (Klasse, Assoziation,... ) Beschreibung Hinweise intuitive Namen verwenden Beschreibung sollte nicht den Inhalt des Objektmodells wiederholen Einheitliche Sprache (Deutsch oder Englisch, wie vom Kunden gefordert) SoPra 2008 Kap. 3.3: Statische Analyse mit FUSION Das Objektmodell (28/44)

29 Kapitel 3.4: Beispiel: Data Dictionary für das Buchungssystem (1) Name Typ Beschreibung Raum Klasse Beschreibt einen buchbaren Ort Gebäude BW Mehrfachbuchung BW Einzelbuchung BW periodische Buchung Klasse Klasse Klasse Klasse übergreifendes Strukturierungsmerkmal für Räume Hält die für eine Mehrfachbuchung nötigen Merkmale eines BW fest. Hält die für eine Einzelbuchung nötigen Merkmale eines BW fest. Hält die für eine periodische Buchung nötigen Merkmale eines BW fest. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (29/44)

30 Buchungssystem: Analyse, data dictionary (2) Name Typ Beschreibung Buchung Termin Benutzer Klasse Klasse Klasse Im System gespeicherte Reservierung von Räumen für eine Veranstaltung mit einem oder mehreren definierten Terminen. Ein Termin steht für einen gebuchten oder einen buchbaren Zeitraum an einem bestimmten Tag. Benutzer des Systems. Authentisiert sich gegenüber dem System. Veranlasst Buchungen. Wird über erfolgreiche Buchungen informiert. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (30/44)

31 Buchungssystem: Analyse, data dictionary (3) Name Typ Beschreibung Administrator Klasse Ein Benutzer des Systems mit speziellen Rechten zur Benutzer- und Rechteverwaltung. Gesamtbelegungsplan Klasse Gesamtverzeichnis der Buchungen aller Benutzer. Diese Buchungen sind konsistent. Konsistent Invariante Buchungen sind konsistent, wenn sie untereinander terminlich konfliktfrei sind und die Wünsche der Benutzer erfüllen. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (31/44)

32 Buchungssystem: Analyse, data dictionary (4) Name Typ Beschreibung Buchungswunsch Klasse Wunsch des Benutzers bzgl. Zeit, Dauer, Raum und Inventar für eine bestimmte Veranstaltung. Anforderungen können eng oder weit formulierbar sein. Je weiter sie sind, desto höher sind die Erfolgschancen. Ein Buchungswunsch ist entweder ein Wunsch über eine Einzelbuchung, eine periodische Buchung oder eine Mehrfachbuchung (Aufteilung vollständig und disjunkt). SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (32/44)

33 Buchungssystem: Analyse, data dictionary (5) Name Typ Beschreibung BW Mehrfachbuchung Klasse Ein Mehrfachbuchungswunsch bezieht sich auf eine Veranstaltung, die einmal, aber aufgeteilt in mehreren Räumen stattfindet. BW Einzelbuchung Klasse Ein Einzelbuchungswunsch bezieht sich auf eine Veranstaltung mit einem Termin. BW periodische Buchung Klasse Ein periodischer Buchungswunsch bezieht sich auf eine Veranstaltung, die regelmäßig zu bestimmten Termin stattfinden soll. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (33/44)

34 Buchungssystem: Analyse, data dictionary (6) Name Typ Beschreibung Raumwunsch Klasse Anforderungen an einen Raum bzgl. Kapazität, Typ, Gebäude und Inventar. Inventar Klasse Speichert, welche Ausrüstungsgegenstände sich in einem buchbaren Raum befinden (z.b.: Beamer, Projektor, Tafel) Gebäude Klasse Nennt Lage und Räume. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (34/44)

35 Buchungssystem: Analyse, data dictionary (7) Name Typ Beschreibung Raum Klasse Beschreibt Kapazität, Nummer, Typ und Inventar. Buchungsvorschlag Klasse Antwort des Systems auf den Buchungswunsch eines Benutzers. Es kann mehrere Vorschläge zur Auswahl geben. Raumbelegungsplan Klasse Gibt für einen Zeitraum die Belegung eines Raumes an. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (35/44)

36 Buchungssystem: Analyse, data dictionary (8) Name Typ Beschreibung Gehört Assoziation Welcher Benutzer für eine Buchung verantwortlich ist. Macht Assoziation Welcher Benutzer einen Buchungswunsch erzeugte. GebuchtMit Assoziation Aus welchem Buchungswunsch eine Buchung hervorging. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (36/44)

37 Buchungssystem: Analyse, data dictionary (9) Name Typ Beschreibung Enthält Assoziation Aus welchen Buchungen der Raumbelegungsplan hervorging. Für Assoziation Zu welchem Raum ein Raumbelegungsplan gehört. FindetStattIn Assoziation Der Raum zu einem Termin. ZulässigeGebäude Assoziation Alle möglichen Gebäude zu einem Raumwunsch. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (37/44)

38 Buchungssystem: Analyse, data dictionary (10) Name Typ Beschreibung ZulässigeRäume Assoziation Alle für einen Raumwunsch möglichen Räume. Benötigt FändeStattIn ErfülltDurch Assoziation Assoziation Assoziation Welches Inventar bei einem Raumwunsch gebraucht wird. In welchem Raum ein Termin (der zu diesem Zeitpunkt noch Teil eines BVs ist) stattfinden könnte, wenn der BV akzeptiert werden würde. Aus welchem Buchungswunsch ein Buchungsvorschlag hervorging. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (38/44)

39 Buchungssystem: Analyse, data dictionary (11) Name Typ Beschreibung Nutzerkennung Attribut Eindeutige systeminterne Identifikation eines Benutzers. Name Attribut Name und Vorname eines Benutzers, mit der Benutzer angesprochen wird. Attribut adresse eines Benutzers, die zur Benachrichtigung verwendet wird. Passwort Attribut Zur Identifikation passende Zugangsbeschränkung. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (39/44)

40 Buchungssystem: Analyse, data dictionary (12) Name Typ Beschreibung Titel Attribut Name einer Buchung oder Veranstaltung. Beschreibung Attribut Enthält zusätzliche Informationen über eine Buchung/ Veranstaltung. Zeitraum(Gebucht/Buchbar) Attribut Festgelegter (Buchung) oder möglicher (Buchungsvorschlag) Zeitraum. ErfassterZeitraum Attribut Zeitraum, für den der Raumbelegungsplan erstellt wird. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (40/44)

41 Buchungssystem: Analyse, data dictionary (13) Name Typ Beschreibung Kapazität Raumnummer Attribut Attribut Die Anzahl an Personen, die in einem Raum Platz finden. Die Identifikation eines Raums innerhalb eines Gebäudes. Raumtyp HatBeamer Attribut Attribut Informationen über den Typ eines Raums (Seminarraum, Hörsaal, Besprechungsraum, Computerraum etc.). Speichert, ob ein Raum mit einem Beamer ausgestattet ist. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (41/44)

42 Buchungssystem: Analyse, data dictionary (14) Name Typ Beschreibung HatProjektor Attribut Ob ein Raum mit einem Projektor ausgestattet ist. HatTafel Attribut Ob ein Raum mit einer Tafel ausgestattet ist. GeeigneterZeitraum Attribut Angabe eines Benutzers, in welchem Zeitraum seine Buchung liegen sollte. BenötigteKapazität Attribut Angabe eines Benutzers, wieviele Personen in dem zu buchenden Raum Platz finden sollen. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (42/44)

43 Buchungssystem: Analyse, data dictionary (15) Name Typ Beschreibung BenötigteDauer Attribut Speichert, wie lange der Raum benötigt wird. GeeigneteRaumtypen Attribut Enthält Informationen über die Art des angeforderten Raumes. Adresse Attribut Die Anschrift eines Gebäudes. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (43/44)

44 Buchungssystem: Analyse, data dictionary (16) Name Typ Beschreibung ZulässigeWochentage Attribut Speichert, welche Wochentage für Buchungsvorschläge überhaupt in Frage kommen. Seriendauer Attribut Über welchen Zeitraum (Wochen, Monate) eine periodische Buchung laufen soll. SoPra 2008 Kap. 3.4: Statische Analyse mit FUSION Beispiel: Data Dictionary (44/44)