Visual C# 2008 Grundlagen und Profiwissen

Transkript

1 Walter Doberenz, Thomas Gewinnus Visual C# 2008 Grundlagen und Profiwissen ISBN-10: ISBN-13: Leseprobe Weitere Informationen oder Bestellungen unter sowie im Buchhandel.

2 9 OOP-Spezial Kapitel 9 OOP-Spezial Dieses Kapitel behandelt drei wichtige OOP-Konzepte: eine praktische Einführung in die UML, der Klassen Designer von Visual Studio 2008, das Microsoft.NET-Ereignismodell. Die Beiträge, die relativ lose nebeneinander stehen, sollen dem fortgeschrittenen Programmierer helfen, sich neue Techniken und Tools zu erschließen, die die UML im Zusammenspiel mit Visual Studio 2008 für die objektorientierte Programmentwicklung bietet. 9.1 Eine kleine Einführung in die UML Ohne tiefergreifende Kenntnisse der UML (Unified Modelling Language) sehen die Zukunftschancen eines Programmierers (egal welcher Sprache) nicht gerade rosig aus. Dieser Abschnitt kann zwar keinen ausgewachsenen UML-Kurs ersetzen, zeigt aber am durchgängigen Beispiel einer Alarmanlage den Umgang mit den wichtigsten UML-Diagrammen. Folgendes Problem soll modelliert werden: Die Zentralverriegelung eines Autos wird mit Hilfe eines Infrarot-Schlüssels betätigt. Beim Versuch, den Motor zu starten ohne vorher das Auto mit dem Schlüssel geöffnet zu haben, soll Alarm ausgelöst werden. Ein Abschalten des Alarms ist nur mit dem Schlüssel möglich. Wir wollen zunächst, in gebotener Kürze, auf die wichtigsten Grundlagen der UML (Unified Modelling Language) eingehen Use Case-Diagramm Für den Einstieg in die UML-gestützte Programmentwicklung wählen wir das Use Case Modell, welches uns hilft, die clientseitigen (d.h. benutzerseitigen) Anforderungen an das zu entwickelnde

3 444 9 OOP-Spezial Programm zu bestimmen, um schließlich die an dem zu modellierenden Szenario beteiligten Objekte grob zu identifizieren. Unter einem Use Case (auch als Anwendungsfall bzw. Geschäftsvorfall bezeichnet) verstehen wir eine typische Handlung, die der Akteur mit dem Programm ausführt. Die einzelnen Use Cases können auch von verschiedenen Akteuren initiiert werden und bestehen aus einzelnen Aktivitäten (Aktionen). HINWEIS: Das Use Case-Diagramm kann nicht mehr als einen ersten Überblick über die Geschäftsvorfälle geben, da die Abläufe innerhalb eines Prozesses im Einzelnen noch nicht erkennbar sind. Für unser Beispiel erhalten wir ein sehr einfaches Diagramm: AutoAlarm Besitzer Vorschriftsmäßige Inbetriebnahme Einbruch Dieb Um zu obigem Use Case-Diagramm zu kommen, sind folgende Fragen zu beantworten: 1. Welche Akteure gibt es? 2. Welche typischen Handlungen nehmen sie vor? Zu 1.: Wir haben es in unserem Modell offensichtlich mit den Akteuren "Besitzer" und "Dieb" zu tun. Hierbei handelt es sich keinesfalls um Personen, sondern um so genannte Rollen. Der rechtmäßige Besitzer des Autos kann durchaus die Rolle eines Diebes spielen, nämlich dann, wenn er probeweise versucht, den Motor zu starten, ohne vorher die Alarmanlage entschärft zu haben. Umgekehrt kann ein Dieb dann in die Rolle des Besitzers schlüpfen, wenn er den Fahrzeugschlüssel gestohlen hat. Zu 2.: Die typischen Handlungen sind "Inbetriebnahme des Autos" (vorgenommen durch den Akteur "Besitzer" und "Versuchter Diebstahl des Autos" (initiiert durch den Akteur "Dieb"). Verlieren Sie sich dabei nicht in einzelne Aktionen, sondern versuchen Sie sich auf die wesentlichen Bedienfunktionen zu konzentrieren. Falls mehrere Use Cases einen ähnlichen Aufbau haben (d.h. ihr Aktionsablauf müsste durch Kopieren wiederholt dargestellt werden) lohnt es sich mitunter, das gemeinsame Verhalten in einen separaten Use Case auszulagern. Man verwendet dazu Include-Beziehungen (<<uses>>), die den Zugriff eines Use Case auf einen anderen bezeichnen.

4 9.1 Eine kleine Einführung in die UML 445 Für unser Beispiel könnte ein Use Case "Motor starten" rein theoretisch in Erwägung gezogen werden. AutoAlarm Besitzer Vorschriftsmäßige Inbetriebnahme <<uses>> Motor starten <<uses>> Einbruch Dieb Allerdings ergäbe in unserem Beispiel der Use Case "Motor starten" wenig Sinn, da es sich hier eher um eine einzelne Aktion handelt (siehe folgender Abschnitt). HINWEIS: Vermeiden Sie es, Geschäftsvorfälle so weit zu splitten, dass daraus schließlich einzelne Aktionen werden! Use Case-Dokumentation Die schriftliche Dokumentation der Use Cases ist erforderlich, um den Ablauf der Aktionen zu spezifizieren: USE CASE: Inbetriebnahme des Autos Akteur: Besitzer Überblick: Zweck ist es, dem Akteur den Start des Motors zu ermöglichen. Bedingung: Der Akteur verfügt über den Schlüssel. Ablauf der Aktionen: Akteur richtet den Schlüssel auf das Auto, um dessen Schloss mit seinem Schlüssel zu verbinden. Anschließend betätigt der Akteur die Öffnungstaste des Schlüssels. Autoschloss wechselt vom gesperrten in den geöffneten Zustand, falls die Verbindung zustande gekommen ist. Wenn Autoschloss geöffnet ist, kann Akteur den Motor starten. Akteur schaltet Motor ab. Akteur betätigt Öffnungstaste des Schlüssels, um Autoschloss wieder zu sperren.

5 446 9 OOP-Spezial USE CASE: Versuchter Diebstahl des Autos Akteur: Dieb Überblick: Zweck ist es, dem Akteur den Start des Motors zu verwehren und stattdessen Alarm auszulösen. Bedingung: Das Auto befindet sich im verschlossenen Zustand. Ablauf der Aktionen: Der Akteur versucht den Motor zu starten. Es wird Alarm ausgelöst Objekte identifizieren Use Cases identifizieren im Wesentlichen nur die clientseitigen Objekte, also jene, mit denen der Benutzer interagiert. Hier die wichtigsten Regeln: Objekte sind Dinge (gewöhnlich Substantive), manchmal aber können sie auch als Verben ausgedrückt werden. Objekte kapseln Daten (gewöhnlich Attribute bzw. Eigenschaften), d.h., sie haben einen Zustand. Objekte kapseln Verhalten (gewöhnlich Aktionen bzw. Verben), das sind Methoden, die irgendetwas tun. Jede Komponente, die bereits identifizierte Objekte enthält, ist ebenfalls ein Objekt. HINWEIS: Akteure sind nicht Teil des Systems, werden also nicht als Objekte modelliert! Hilfreich ist es, wenn Sie sich nacheinander alle Use Cases notieren, um die relevanten Ausdrücke gemäß der oben aufgeführten Regeln zunächst einmal zu markieren. Dabei können Sie ohne Rücksichtnahme auf die Orthografie die Satzelemente nach Belieben umgruppieren, um die Identifikation als Objekt, Methode, Zustand oder Eigenschaft deutlicher hervortreten zu lassen: Besitzer peilt an mit Schlüssel das Auto, um Schloss mit Schlüssel zu verbinden. Besitzer betätigt die Öffnungstaste des Schlüssels. Schloss wechselt vom gesperrten in den geöffneten Schließzustand, falls die Verbindung zustande gekommen ist. Wenn Schloss geöffnet ist, kann Besitzer den Motor starten. Besitzer schaltet ab den Motor. Besitzer drückt Öffnungstaste des Schlüssels, um Schloss wieder zu sperren.

6 9.1 Eine kleine Einführung in die UML 447 Dieb versucht, den Motor zu starten. Es wird Alarm ausgelöst. Obwohl obiges Ergebnis jedem Deutschlehrer die Haare zu Berge stehen lässt, kann es in einer nützlichen Tabelle zusammengefasst werden, die wie folgt aussieht: Objekt Methoden Zustände Objekte/Eigenschaften Schlüssel Auto anpeilen mit Schloss verbunden Schloss Öffnungstaste drücken (ja/nein) Schloss Schließzustand wechseln geöffnet/gesperrt Auto Schloss Motor Alarm Motor Motor starten ein/aus Motor anhalten Alarm Alarm auslösen Alarm abschalten ein/aus HINWEIS: Denken Sie immer daran, dass jeder Zustand durch Methodenaufrufe erreichbar sein muss und auch wieder verlassen werden kann! Statisches Modell Die folgende Abbildung zeigt die Umsetzung der in den Use Cases identifizierten Objekte in ein Klassendiagramm, das sich aus den Klassen CAuto, CSchlüssel und CSchloss zusammensetzt: CSchlüssel - verbunden: Boolean + AutoAnpeilen(a: CAuto) + TasteDrücken() 1 schloss 1 CAuto - alarmein: Boolean - motorein: Boolean + <<get>> Schloss: CSchloss + MotorStarten() + MotorAbschalten() 1 1 schloss CSchloss - auf: Boolean + Wechseln() Es handelt sich dabei nur um eine von vielen verschiedenen Möglichkeiten.

7 448 9 OOP-Spezial HINWEIS: Jedes Objektmodell ist eine persönliche Sicht des Entwicklers auf das Problem! Wie Sie dem Klassendiagramm entnehmen, wurde auf das Anlegen der Klassen CMotor und CAlarm verzichtet, stattdessen wurde deren Funktionalität komplett in CAuto verlagert. Eine solche Vorgehensweise empfiehlt sich dann, wenn die identifizierten Objekte mit nicht mehr als nur einem anderen Objekt assoziiert sind und eine relativ geringe Komplexität besitzen Beziehungen zwischen den Klassen Die Klassen CSchlüssel und CSchloss sind durch eine binäre Assoziation miteinander verbunden, die auf beiden Seiten die Kardinalität 1 hat. Der Zugriff ist nur in Pfeilrichtung möglich (der Schlüssel macht etwas mit dem Schloss und nicht umgekehrt!). Damit referenziert (nicht instanziiert!) ein Objekt vom Typ CSchlüssel das bereits vorhandene Objekt schloss vom Typ CSchloss. Bei CAuto und CSchloss handelt es sich um eine typische Aggregation, die wie Sie wissen sollten eine besondere Form der Assoziation darstellt. Das Objekt schloss ist integraler Bestandteil eines Objekts der Aggregat-Klasse CAuto, wird also in diesem erzeugt bzw. instanziiert (new) Dynamisches Modell Als Ergebnis des statischen Modells liegen die identifizierten Klassen mit ihren Zustandsvariablen, Eigenschaften und Methoden vor. Weiterhin wurden dort bereits die Beziehungen zwischen den Klassen (Vererbungsstrukturen, Assoziationen) analysiert. Aufgrund dieser Informationen kann nun das dynamische Verhalten näher spezifiziert werden, wozu sich das Zustandsüberführungsdiagramm (StateChart) hervorragend eignet. Relevante Zustände identifizieren Die im statischen Modell enthaltenen Klassen (CSchlüssel, CAuto, CSchloss) besitzen insgesamt drei Zustandsvariablen vom Typ Boolean (auf, motorein, alarmein). Rein theoretisch ergäben die damit möglichen Kombinationen genau acht verschiedene Zustände. Davon sind allerdings nur vier Zustände von Bedeutung, die übrigen können ausgeschlossen werden (z.b. dürfen alarmein und motorein nicht gleichzeitig True sein). Nr. Zustand auf motorein alarmein 1 Verschlossen False False False 2 Geöffnet True False False 3 MotorAn True True False 4 Alarm False False True