Softwaretechnik. Zusammenfassung der Methodik der Vorlesung im Wintersemester 2010/2011

Transkript

1 Softwaretechnik Zusammenfassung der Methodik der Vorlesung im Wintersemester 2010/2011 INHALT 1 Objektorientierte Analyse Use Case Modell Aktoren bestimmen Anwendungsfälle bestimmen Diagramm erstellen Beschreibungen anfertigen Statisches Modell Klassen identifizieren Assoziationen bestimmen Attribute identifizieren Vererbung einführen Modell überarbeiten Dynamisches Modell Interaktionsdiagramme entwickeln Zustands- und Aktivitätsdiagramme entwickeln Objektorientierter Entwurf Objektentwurf Operationen hinzufügen Assoziationen ausrichten Zugriffsrechte bestimmen Mehrfachvererbung auflösen Wiederverwendung von Klassen Realisierung von Zustandsdiagrammen Prozedurgesteuerte Realisierung Realisierung durch Fallunterscheidung Realisierung durch Zustandsobjekte Realisierung durch eine Zustandsmaschine Systementwurf Grundlagen... 10

2 2.3.2 Fassadenklassen Schichtenarchitekturen Drei-Schichten-Architektur für betriebliche Informationssysteme Kontrollobjekte Beobachter Anmerkung: Der folgende Text versteht sich mit Blick auf die Klausur als Zusammenfassung zur gleichnamigen Vorlesung und fußt dazu natürlich auf die von Prof. Dr. Hennicker erstellten Inhalte. Quelle: Der Autor übernimmt keinerlei Gewährleistung dafür, dass diese Zusammenfassung inhaltlich vollständig oder korrekt ist. Die Benutzung erfolgt also zu eigenem Vergnügen und auf eigene Gefahr. ;) Daniel Buschek

3 3 1 OBJEKTORIENTIERTE ANALYSE Ziel: Die Anforderungen an das Softwaresystem erfassen und präzise und verständlich beschreiben. 1.1 Use Case Modell Input: Informelle, knappe Beschreibung, z.b. aus einem Interview. Ziel: Die (vom Kunden) gewünschte Funktionalität des Systems beschreiben Aktoren bestimmen Zunächst sollen die Aktoren bestimmt werden, die mit dem System interagieren: Wer benützt das System? Wer holt Informationen vom System? Wer liefert dem System Informationen? Anwendungsfälle bestimmen Nun können die Anwendungsfälle bestimmt werden; diese beschreiben die Aufgaben, die das System für einen oder mehrere Aktoren erledigen soll. Hierbei besteht oft die Schwierigkeit, die richtige Granularität zu finden: Welche Alternativen gehören noch zum selben Anwendungsfall, was ist schon ein neuer Anwendungsfall? Diagramm erstellen Nachdem Aktoren und Anwendungsfälle bestimmt wurden, kann ein entsprechendes Anwendungsfall-Diagramm (Use Case Diagramm) erstellt werden. Eventuell kann hier noch eine kurze Beschreibung der Aktoren und Anwendungsfälle angegeben werden Beschreibungen anfertigen In diesem letzten Schritt werden die Anwendungsfälle (iterativ) mit Beschreibungen versehen. Diese haben folgendes Format: Name des Anwendungsfalls Kurzbeschreibung Vorbedingung: Was ist Voraussetzung für eine erfolgreiche Ausführung des Anwendungsfalls? Nachbedingung: Beschreibung des Zustands nach erfolgreicher Ausführung. Primärszenario: Beschreibt den schrittweisen Ablauf im Normalfall. Sekundärszenarien: Beschreiben den schrittweisen Ablauf bei Fehlerfällen oder Optionen.

4 4 1.2 Statisches Modell Input: Das Use Case Modell, die ursprüngliche Problembeschreibung, erweitert um Experten- und Allgemeinwissen. Ziel: Ein Klassendiagramm, noch ohne Operationen Klassen identifizieren Es sollen die Klassen für das statische Modell gefunden werden. Kandidaten dafür sind Personen bzw. Rollen, Organisationen, Gegenstände und begriffliche Konzepte (z.b. Bestellung). 1. Kandidaten notieren: Hierzu durchsucht man die Use Case Beschreibungen nach Substantiven. 2. Ungeeignete Klassen streichen: Es sollen Klassenkandidaten gestrichen werden, die redundant, irrelevant oder vage sind. Ebenso eignen sich manche der gefundenen Substantive möglicherweise besser als Attribut einer anderen Klasse oder es handelt sich um eine Tätigkeit. 3. Fehlende relevante Klassen hinzufügen: Hinweise auf fehlende Klassen ergeben sich aus Problembereichswissen und aus Attributen vom vorigen Schritt, zu denen es noch keine Klassen gibt Assoziationen bestimmen Nun sollen Assoziationen zwischen den Klassen gefunden werden. Kandidaten dafür sind physische/logische Verbindungen mit bestimmter Dauer, z.b. konzeptionelle Verbindungen ( arbeitet für ), Besitz ( hat, ist Teil von ) sowie häufige Zusammenarbeit von Objekten zur Lösung einer Aufgabe. 1. Kandidaten notieren: Hierzu durchsucht man die Use Case Beschreibungen nach Verben, Substantiven im Genitiv ( die Karte des Kunden ) oder Possessivpronomen ( seine, ihre, ). Achtung: Verben bezeichnen oft Aktivitäten statt Beziehungen. 2. Ungeeignete Assoziationen streichen: Vor allem auf redundante (abgeleitete) Assoziationen sollte verzichtet werden. 3. Fehlende relevante Assoziationen hinzufügen: Analog zur Vorgehensweise beim Bestimmen der Klassen. 4. Multiplizitäten und ggf. explizite Rollennamen hinzufügen: Im Zweifelsfall kann man die Multiplizitäten aber auch noch weglassen und erst später bestimmen.

5 Attribute identifizieren Bei der Suche nach Attributen gelten folgende Richtlinien: Es sollen nur für die Anwendung relevante Attribute eingeführt werden. Attribute sollen keine Objekttypen haben, dafür werden Assoziationen verwendet. Die genauen Attributtypen können noch weggelassen werden Vererbung einführen In der Analyse geht es hierbei vor allem um Generalisierung: Gemeinsame Merkmale der vorhandenen Klassen (Attribute, Assoziationen) können in einer Oberklasse zusammengefasst werden. Außerdem sollte hier bestimmt werden, welche Klassen abstrakt sind Modell überarbeiten Im Prinzip besteht dieser Schritt aus dem Überdenken der bisherigen Arbeit. Checkliste: Fehlen Klassen oder Assoziationen? Sind alle Klassen und Assoziationen notwendig? Sind alle Attribute und Assoziationen richtig platziert? Gibt es Assoziationen, bei denen ein Qualifizierer sinnvoll wäre? Welche Typen haben/bekommen die Attribute? Fehlen noch Multiplizitäten? 1.3 Dynamisches Modell Input: Use Case Beschreibungen (Szenarien) und statisches Modell. Ziel: Entwurf von Interaktionsdiagrammen für jeden Anwendungsfall, auf deren Basis dann Zustandsund Aktivitätsdiagramme abgeleitet werden Interaktionsdiagramme entwickeln Interaktionsdiagramme beschreiben die Zusammenarbeit und den Nachrichtenaustausch zwischen mehreren Objekten. In UML gibt es Sequenzdiagramme und Kommunikationsdiagramme. Im Rahmen der Vorlesung bzw. Übung wurden nur Sequenzdiagramme auch wirklich verwendet. 1. Identifizieren der Nachrichten, die innerhalb eines Anwendungsfalls ausgetauscht werden und der Objekte, die die Nachrichten senden und empfangen. 2. Konstruktion von Interaktionsdiagrammen für jeden Anwendungsfall bzw. dessen Szenarien.

6 Zustands- und Aktivitätsdiagramme entwickeln Input: Die im vorigen Schritt erstellten Sequenzdiagramme zu den Anwendungsfällen. Ziel: Ein Zustandsdiagramm für jede Klasse mit interessanten Verhalten entwickeln (Klassen deren Objekte einen nicht-trivialen Lebenszyklus haben). Die in den Zustandsdiagrammen auftauchenden Operationen sollen dann mit Aktivitätsdiagrammen beschrieben werden. Zustands- und Aktivitätsdiagramme erfassen also das vollständige Verhalten eines jeden Objekts einer Klasse über viele Szenarien hinweg. Aktivitätsdiagramme können auch weggelassen werden, wenn es bereits ein einziges Interaktionsdiagramm gibt, das schon das vollständige Ablauf-Verhalten der Operation zeigt. Kriterien für interessantes Verhalten : Ein Objekt reagiert auf gleiche Ereignisse in Abhängigkeit seines Zustands unterschiedlich. Mindestens ein Ereignis wird in bestimmten Zuständen ignoriert (bzw. kann dort gar nicht auftreten). Typische zustandsabhängige Objekte sind Kontrollobjekte für Anwendungsfälle und Benutzerschnittstellen, Geräte (z. B. Digitaluhr) sowie Objekte mit beschränktem Fassungsvermögen (voll, leer). Klassifizierung von Zuständen: stabiler/inaktiver Zustand: Ein Zustand, dem keine Aktivität zugeordnet ist. Aktivitätszustand: Ein Zustand, dem eine Aktivität zugeordnet ist und der nur durch ein (evtl. bedingtes) Completion Event verlassen werden kann. Vorgehensweise zur Konstruktion eines Zustandsdiagramms: 1. Wahl eines Sequenzdiagramms, das eine typische Interaktion für ein Objekt der betrachteten Klasse zeigt (normalweise das Sequenzdiagramm für das Primärszenario). 2. Betrachten der Lebenslinie des Objekts. 3. Bilden einer Kette von Zuständen, wobei man der Lebenslinie des Objekts folgt: Inaktive Phasen werden durch stabile Zustände modelliert. Aktive Phasen werden durch Aktivitätszustände umgesetzt, in denen lokale Operationen zur Durchführung der Aktivität aufgerufen werden (dies wird später in den Aktivitätsdiagrammen dargelegt). Eintreffende Ereignisse werden durch entsprechend markierte Transitionen von stabilen Zuständen in Aktivitätszustände modelliert. Das Ende von aktiven Phasen wird durch eine Transition mit einem Completion Event von einem Aktivitätszustand in einen stabilen Zustand umgesetzt. 4. Bilden von Zyklen für Abläufe, die wiederholt werden können. Damit ist dann ein Sequenzdiagramm verarbeitet, freilich noch ohne die Details zu den Aktivitäten. Die angegebenen Schritte wiederholt man für alle Sequenzdiagramme, in denen ein Objekt der

7 7 betrachteten Klasse eine Rolle spielt und erweitert das Zustandsdiagramm entsprechend. Meist führt diese Erweiterung zu Verzweigungen von einem stabilen Zustand aus, der in mehreren Sequenzdiagrammen als Ausgangszustand des Objekts auftauchte. Anschließend folgt die Konstruktion von Aktivitätsdiagrammen für die lokalen Operationen (also die Operationen in den Aktivitätszuständen des erstellten Zustandsdiagramms). Außerdem kann das Zustandsdiagramm evtl. noch durch das Hinzufügen von Bedingungen bei den von Aktivitätszuständen ausgehenden Transitionen verfeinert werden. Dies ist wichtig, damit das Zustandsdiagramm deterministisch ist! Zuletzt müssen evtl. auch noch weitere angegebene Sekundärszenarien integriert werden, für die gar kein Sequenzdiagramm erstellt wurde. 2 OBJEKTORIENTIERTER ENTWURF Input: Das statische und dynamische Modell der objektorientierten Analyse. Ziel: Ein Modell der Systemimplementierung; also wie die einzelnen Aufgaben gelöst werden. 2.1 Objektentwurf Das statische Analysemodell wird nun erweitert und überarbeitet. Dazu verwendet man die Informationen aus dem dynamischen Modell der Analyse. Die beiden Modelle werden also zusammengeführt Operationen hinzufügen Das statische Modell soll um Operationen erweitert werden. 1. Betrachten der Interaktionsdiagramme: Für jede an ein Objekt der Klasse K gesendete Nachricht wird eine entsprechende Operation bei K eingeführt. 2. Betrachten der Zustands- und Aktivitätsdiagramme: Es wird eine Operation eingeführt für jedes Call-Event eines Zustandsdiagramms und für jede in einem Aktivitätszustand aufgerufene (lokale) Operation. Das gilt natürlich auch für Aktionen in den zugehörigen Aktivitätsdiagrammen. 3. Benutzerdefinierte Konstruktoren bei nicht-abstrakten Klassen hinzufügen. 4. Benötigte Zugriffsoperationen für Attribute und Rollen hinzufügen (also Getter- und Setter). 5. Beschreiben der Algorithmen der Operationen (z. B. in Java-Pseudocode).

8 Assoziationen ausrichten Mit diesem Schritt sollen bidirektionale Assoziationen vermieden werden, was die spätere Implementierung erleichtert. Dazu wird betrachtet, in welche Richtung die bestehenden Assoziationen durchlaufen werden (z.b. beim Senden von Nachrichten oder Operationsaufrufen). Wenn sich dabei herausstellt, dass dies nur in eine Richtung geschieht, wird die Assoziation entsprechend ausgerichtet Zugriffsrechte bestimmen Nun werden die Zugriffsrechte für Attribute, Rollennamen und Operationen festgelegt. Attribute und Rollennamen sollten dabei nicht öffentlich zugreifbar sein Mehrfachvererbung auflösen Dieser Schritt ist notwendig, wenn die bei der Implementierung benutzte Sprache keine Mehrfachvererbung unterstützt (z.b. Java). Die Auflösung wird durch die Einführung einer Schnittstelle umgesetzt. Eine der beiden Oberklassen wird durch ein Interface ersetzt, das an ihrer Stelle von der Unterklasse geerbt (bzw. implementiert) wird. Zudem wird eine neue Klasse erstellt, welche die entfernte Oberklasse ersetzen soll (vermutlich gleiche Implementierung). Diese neue Klasse implementiert ebenfalls das eingeführte Interface und wird von der Unterklasse zur Delegation bei Aufrufen der Operationen aus dem Interface benutzt. Beispieldiagramme dazu finden sich im Skript in Kapitel (Folie 11) Wiederverwendung von Klassen Oft bestehen bereits erprobte und hochwertige Klassen, die man im Entwurf wiederverwenden möchte. Braucht man noch mehr Funktionen als die vorhandenen, kann man diese durch Spezialisierung in einer Subklasse hinzufügen. Achtung: Vielleicht bietet die geerbte Klasse mehr Operationen an, als man eigentlich benötigt. Dadurch könnte das Kapselungsprinzip verletzt werden. In einem solchen Fall bietet sich eine Wiederverwendung durch Delegation an. Hierbei bekommt die neue Klasse ein (privates) Objekt der wiederverwendeten Klasse, an das sie bei Bedarf Methodenaufrufe weiterleiten kann. 2.2 Realisierung von Zustandsdiagrammen Input: Das Zustandsdiagramm einer Klasse. Ziel: Ein Objektentwurf mit Algorithmen zur Realisierung des durch das Zustandsdiagramm beschriebenen Verhaltens. Zustandsdiagramme können systematisch realisiert und in den Objektentwurf integriert werden. Dazu gibt es vier Möglichkeiten, die im Folgenden beschrieben werden.

9 Prozedurgesteuerte Realisierung Bei diesem Ansatz werden Ereignisse durch erzwungene Benutzereingaben unterschieden. Das setzt voraus, dass es sich bei den Objekten um Kontrollobjekte zur Dialogsteuerung handelt und sich diese somit an der Systemgrenze befinden. Das gesamte Zustandsdiagramm wird überführt in eine Prozedur mit: modalen Dialogen für die (externen) Ereignisse bedingten Anweisungen für Verzweigungen Wiederholungsanweisungen für Zyklen des Diagramms Anmerkung: Diese Methode ist heutzutage offensichtlich keine allzu gute Idee mehr; flexible Benutzerschnittstellen sind so nur schwer zu realisieren Realisierung durch Fallunterscheidung Hier merkt sich das Objekt seinen Zustand in Form eines Attributs. In den Operationen kann dann anhand dieses Wertes entschieden werden, wie sie sich zu verhalten haben. 1. Ein Enumerationstyp stellt die endlich vielen (stabilen) Zustände dar. 2. Die Klasse bekommt ein explizites Zustandsattribut dieses Typs. 3. Die zustandsabhängigen Operationen werden durch Fallunterscheidung nach dem aktuellen Wert des Zustandsattributs realisiert. Vorteil: Leichte Erweiterbarkeit bezüglich neuer Operationen. Eine neue Operation wird einfach zur Klasse hinzugefügt und nutzt die Fallunterscheidung nach dem Wert des Zustandsattributs. Nachteil: Schlechte Erweiterbarkeit bezüglich neuer Zustände. Ein neuer Zustand bedeutet möglicherweise Veränderungen (nämlich einen neuen Fall) bei den Fallunterscheidungen in allen bisherigen Operationen Realisierung durch Zustandsobjekte Ein spezielles Zustandsobjekt übernimmt hier die Ausführung der zustandsabhängigen Operationen. 1. Jedes Objekt der Klasse bekommt ein Zustandsobjekt, das den aktuellen Zustand repräsentiert. 2. Aufrufe von zustandsabhängigen Operationen werden an das Zustandsobjekt delegiert. 3. Das aktuelle Zustandsobjekt führt die gewünschte Aktivität aus und gibt den (neuen) Zustand zurück, der nun mit dem Basisobjekt verbunden werden soll.

10 10 Vorteil: Leichte Erweiterbarkeit bezüglich neuer Zustände. Ein neuer Zustand kann einfach als neue Unterklasse der abstrakten Zustandsklasse umgesetzt werden. Nachteil: Schlechte Erweiterbarkeit bezüglich neuer Operationen. Eine neue Operation muss zumindest in die Klasse und den abstrakten Zustand aufgenommen werden; möglicherweise aber leider auch in alle bisherigen Zustands-Unterklassen Realisierung durch eine Zustandsmaschine Dieser Ansatz realisiert das Zustandsdiagramm, in dem dieses komplett mit verbundenen Objekten nachgebaut wird. Idee: Alle in einem Zustandsdiagramm vorkommenden Größen (stabile Zustände, Transitionen, Aktivitäten, Ereignisse) werden durch Objekte dargestellt. Ereignisse werden von einer speziellen Event-Handle -Operation interpretiert. Das gesamte Zustandsdiagramm wird durch eine verzeigerte Objektstruktur repräsentiert. 2.3 Systementwurf Ziel: Der Objektentwurf soll in die Systemumgebung eingebettet werden. Außerdem wird die Systemarchitektur festgelegt Grundlagen Die Systemarchitektur beschreibt die Gesamtstruktur des Software-Systems durch Angabe von Subsystemen und Beziehungen zwischen diesen. Eine grobe Systemarchitektur wird meist schon zu Beginn der Systementwicklung angegeben. Subsysteme werden durch Pakete oder durch Komponenten (mit Schnittstellen) dargestellt. Grundregeln: hohe Kohärenz (high cohesion): Systemteile die (logisch) zusammen gehören sollen in einem Subsystem zusammengefasst werden. geringe Kopplung (low coupling): Zwischen den Subsystemen sollen möglichst wenige Abhängigkeiten bestehen. Vorteil: Änderung und Austauschen von einzelnen Teilen wird vereinfacht Fassadenklassen Mit Hilfe von Fasadenklassen kann eine geringe Kopplung erreicht werden. Sie vereinen die Dienste verschiedener Klassen eines Subsystems durch Delegation der Aufrufe an die zuständigen Objekte. Ein Beispiel dazu findet sich im Skript in Kapitel (Folie 50).

11 Schichtenarchitekturen In einer Schichtenarchitektur stellt jede Schicht Dienste für die darüber liegende(n) Schicht(en) bereit. Ein bekanntes Beispiel ist das OSI-Modell. Bei geschlossenen Architekturen darf eine Schicht nur auf die direkt darunterliegende Schicht zugreifen, andernfalls spricht man von einer offenen Architektur. Als Client/Server-System bezeichnet man eine Verteilung der Schichten auf verschiedene Rechner. Eine Schicht kann selbst aus verschiedenen Subsystemen bestehen Drei-Schichten-Architektur für betriebliche Informationssysteme Für viele Anwendungen wird eine Drei-Schichten-Architektur gewählt. Diese besteht aus einer Benutzerschnittstelle, dem Anwendungskern und einer Datenbankschnittstelle. Benutzerschnittstelle: Behandelt Nutzereingaben (Mausklicks, Tasten) Ein-/Ausgabe von Daten Dialogkontrolle Anwendungskern: Zuständig für die Anwendungslogik, also die eigentlichen Aufgaben des Problembereichs Ergibt sich aus dem Objektentwurf Datenbankschnittstelle: Sorgt für Speicherung persistenter Daten der Anwendung und den Zugriff darauf Daneben gibt es noch Subsysteme für allgemeine Dienste, wie etwa Kommunikationsdienste, Dateiverwaltung oder Bibliotheken (APIs, GUI, ) Kontrollobjekte Für die Dialogsteuerung (z.b. Verwaltung mehrerer Fenster) oder zur Steuerung der Aufgaben des Anwendungskerns werden häufig eigene Objekte verwendet. Solche Kontrollobjekte sorgen für geringe Kopplung und haben meist ein interessantes Verhalten, das durch Zustandsdiagramme beschrieben werden kann Beobachter Es gilt die Sichtbarkeitsregel zu beachten: Der Anwendungskern darf die Benutzerschnittstelle nicht kennen. Das hat den Vorteil, dass Änderungen an der GUI keine Auswirkungen auf den Code des Anwendungskerns haben. Um die berechneten Daten dennoch anzeigen zu können, kann man mit Beobachtern arbeiten.

12 12 Indirekte Kommunikation durch Beobachter: GUI-Objekte melden sich als Beobachter (Observer) beim Anwendungskern an (addobserver). Falls der Anwendungskern ein Ereignis publizieren will, benachrichtigt er alle seine Beobachter (notifyobservers), die entsprechend reagieren (update). Jeder konkrete Beobachter implementiert das Interface Observer. Der Anwendungskern kennt (zur Programmierzeit) nur das Observer-Interface. Konkrete Observer werden zur Laufzeit dynamisch eingebunden.