Die Idee der Objektorientierung ist schon 30 Jahre alt und hatte mit objektorientierten Programmiersprachen wie Simula und Smalltalk ihren Anfang.
Anfang der 90er Jahre kam eine Welle von objektorientierten Analyse und Designmethoden auf. Die Methoden von Grady Booch (Booch 91), James Rumbaugh (OMT) und Jacobsen mit OOSE haben sich als die beliebtesten herauskristallisiert. Booch und Rumbaugh begannen ihre Methoden zusammenzufügen und entwickelten eine neue Notation- die UM od. Unified Method. Kurze Zeit später gesellte sich auch Ivar Jacobson dazu und brachte seine Use Cases od. Anwendungsfälle in die UM ein.
Sie nannten sich die drei Amigos und entwickelten mit ihrer Unified Modeling Language UML einen Quasi Standard, der 1997 bei der Object Management Group (OMG) zur Standardisierung eingereicht wurde.
UML 1.1 wurde akzeptiert- die derzeit aktuelle Version ist 1.2 - die jedoch nur wenige Anderungen zur Version 1.1 aufweist. Die Weiterentwicklung von UML wird derzeit durch die OMG betrieben.
"Die Unified Modeling Language (UML) ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme. Die UML berücksichtigt die gestiegenen Anforderungen bezüglich der Komplexität heutiger Systeme, deckt ein breites Spektrum von Anwendungsgebieten ab und eignet sich für konkurrierende, verteilte, zeitkritische, sozial eingebettete Systeme uvm" 1
UML ist in erster Linie die Beschreibung einer einheitlichen Notation zur Modellierung, sie ist jedoch bewußt keine Methode. UML kann Basis für versch. Methoden sein, aber grundsätzlich muß eine Methode die individuellen Rahmenbedingungen und das Umfeld usw. berücksichtigen.
Die Unified Modeling Language ist eine Modellierungssprache und eignet sich deswegen hervorragend zur Übersetzung in eine objektorientierte Programmiersprache.
aus [Oestereich'98]
Wie oben erwähnt ist die UML eine Modellierungssprache, jedoch keine Methode- sie enthält keine Prozeßbeschreibung, die einen wichtigen Teil einer Methode ausmacht.
Ich gehe nur grob auf einen Entwicklungsprozeß ein, und beschreibe kurz die einzelnen Phasen der Entwicklung. In der Vorlesung wurde dieser Punkt als Software Engineering mit dem klassischen Phasenmodell erläutert.
Phase 1 Phase 2 Phase 3 Phase 4
Der wichtigste Teil hierbei ist es, mit den zukünftigen AnwenderInnen zu kommunizieren und damit den Anwendungsbereich aus der Praxis kennenzulernen. Es müssen die genauen Anforderungen an die zu erstellende Software definiert werden. Hier stellt sich hauptsächlich die Frage: Was soll das Produkt können, und nicht wie wird das Ergebnis erreicht. Natürlich fällt in diesen Bereich auch eine Kosten/Nutzen Analyse.
Das Ergebnis der Analyse und Definition ist die Produktdefinition, die den Leistungsumfang des Produkts festlegt.
Die Produktdefinition muß laut Vorlesung aus Software Engineering WS98/99 folgende Festlegungen enthalten:
Funktionsumfang
Benutzeroberfläche
Schnittstellen zur Systemumgebung (Hardware und Software)
Hardware und Softwarebasis
Leistungsverhalten
Dokumentation
Terminplanung
Ein wichtiges Ergebnis beim Entwurf ist eine grundlegende Architektur für das System. Diese Architektur ist die Grundlage für die Entwicklung; sie dient als Bauplan für spätere Phasen. Es soll zur Bewältigung der Komplexität das Gesamtprodukt in kleine, beherrschbare Einheiten zerlegt werden. Das Ergebnis ist hier eine klare Software- Spezifikation.
Bei der Implementierung des Entwurfs erstellt man das System in einer Folge von Iterationen. Jede Iteration ist ein Miniprojekt, das programmiert, getestet und integriert wird. Sie besteht jeweils aus Analyse, Design, Realisierung und Test einer Menge von Teilfunktionalitäten. Das Testen ist hier besonders wichtig, um am Ende ein korrektes System zu erhalten.
Das Ergebnis ist eine Sammlung von Quelltexten die am Schluß zusammengefügt werden.
Hier gibt es kein Hinzufügen von Funktionalität. Es werden nur noch Fehlerkorrekturen vorgenommen. ( von der Beta bis zur Endversion)
Integrationstest, Effizienzstest, Installation und Abnahmetest sind die wichtigsten Punkte bei der letzten Phase eine Entwicklungsprozeßes.
Anwendungsfalldiagramm (Use Case Diagramm): zeigt Akteure, Anwendungsfälle und ihre Beziehungen. Einsatz in Phase: 1, 2, 3 und 4
Klassendiagramm: Zeigt Klassen und ihre Beziehungen untereinander. Einsatz in Phase: 2 und 3. Das Klassendiagramm ist das wichtigste Diagramm der UML.
Verhaltensdiagramme (behavior diagrams): Zeigen den Nachrichtenfluß und damit die Zusammenarbeit der Objekte im zeitlichen Ablauf. Einsatz in Phase: 1, 2, 3 und 4
Aktivitätsdiagramm: zeigt Aktivitäten, Objektzustände, Zustände, Zustandsübergänge und Ereignisse. Einsatz in Phase: 2 und 3
Kollaboratinsdiagramm (collaboration diagram): zeigt Objekte und ihre Beziehungen inklusive ihres räumlich geordneten Nachrichtenaustausches.
Sequenzdiagramm: zeigt Objekte und ihre Beziehungen inklusive ihres zeitlich geordneten Nachrichtenaustausches.
Zustandsdiagramm: zeigt Zustände, Zustandsübergänge und Ereignisse also das dynamische Verhalten. Einsatz in Phase: 1, 2, 3 und 4.
Implementierungsdiagramme: Besonders für die Darstellung von verteilten Anwendungen und Komponenten; allgemein: Darstellung von Implementierungsaspekten (Übersetzungseinheiten, ausführbare Programme, Hardwarestruktur) Einsatz in Phase: 2, 3 und 4
Komponentendiagramm: zeigt Komponenten und ihre Beziehungen also die zusammenhänge der Software.
Verteilungsdiagramm (deployment diagram): zeigt Komponenten, Knoten und ihre Beziehungen. (Hardwareaufbau)
Definition laut [Oestereich'98]: " Ein Anwendungsfall beschreibt eine Menge von Aktivitäten eines Systems aus der Sicht seiner Akteure, die für die Akteure zu einem wahrnehmbaren Ergebnis führen. Ein Anwendungsfall wird stets durch einen Akteur initiiert. Ein Anwendungsfall ist ansonsten eine komplette, unteilbare Beschreibung "
Ein wenig klarer Ausgedrückt ist ein Anwendungsfall eine typische Interaktion zwischen einem Benutzer und einem Computersystem. Es werden Anforderungen wie : was das System leisten muß gestellt; jedoch nicht wie es das System leisten muß.
Daraus folgt, daß ein Anwendungsfall also einen typischen Arbeitsablauf beschreibt.
Akteure sind die vom Anwender - in Bezug auf das System - eingenommenen Rollen (wie z.B. Kunde, Verkäufer ). Meist gibt es viele Kunden, aus der Sicht des Systems haben aber alle Kunden dieselbe Rolle. Wenn nicht, ist ein neuer Akteure nötig.
Akteure können in versch. Weise dargestellt werden: als textuelles Stereotyp, als visuelles Stereotyp od. in einer gemischten Form.
Akteur; am
Anwendungsfall beteiligte Person (visuelles Kunde Stereotyp)
textuelles Stereotyp
Kunde
textuelles und visuelles Stereotyp
Einschub: Was ist ein Stereotyp ?
Stereotypen sind Mechanismen, die es erlauben, die UML zu erweitern. Sie haben in der UML die Bedeutung "so ähnlich wie etwa". Stereotypen können eigene Piktogramme (Icons) haben und werden in eckigen Klammern dargestellt, z.B.: <<uses>>. Sie erlauben eine weitere Einteilung der Klassen, Abhängigkeiten, Assoziationen etc. So ist z.B. eine Einteilung der Klassen in Schnittstellen -, Kontroll- und Entitätenobjekte (irgendwelche Dinge) möglich.
Ein Modellierungselement kann mit beliebig vielen Stereotypen klassifiziert werden. Dadurch werden die Semantik und visuelle Darstellung des Elements beeinflußt.
Beispiele von
Stereotypen:
visuelle Stereotypen: siehe oben
textuelle Stereotypen:
<<präsentation>>, <<vorgang>>,<<fachklasse>> (hier werden die Bedeutungen einer Klasse in der Anwendungsarchitektur angegeben)
<<model>>, <<view>>,<<controller>>,<<exception>>,<<uses>>,<<extends>>
<<interface>> (mit interface wird eine abstrakte Klasse gekennzeichnet, die nur abstrakte Operationen beinhaltet)
<<implements>> deklariert zwischen zwei Klassen eine Verfeinerungsbeziehung
Ein Anwendungsfalldiagramm beschreibt die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren. Es bildet somit den Kontext und eine Gliederung für die Beschreibung, wie mit einem Geschäftsvorfall umgegangen wird.
Anwendungsfälle beschreiben gewöhnlich nur die Aktivitäten, die durch die zu entwickelnde Software unterstützt werden sollen, und deren Berührungspunkte zum Umfeld dieser Software.
Ein Anwendungsfalldiagramm enthält eine Menge von Anwendungsfällen, die durch einzelne Ellipsen dargestellt werden und eine Menge von Akteuren und Ereignissen, die daran beteiligt sind. Sie können außerdem hierarchisch verschachtelt werden (siehe unten)
Wobei der Anwendungsfall " Spielzug durchführen" ein eigenes Anwendungsfalldiagramm darstellt:
Akteur Anwendungsfall od. Use Case
Verbindungstypen:
<<uses>>, << benutzt>> (ab UML 1.3 umbenannt in <<include>>)
wird verwendet, wenn zwei od. mehr Use Cases einen ähnlichen Aufbau haben und Verhalten durch Kopieren wiederholt dargestellt werden muß. Also wenn die gleiche Use Case Beschreibung in verschiedenen Use Cases vorkommt. Um dies zu vermeiden, wird der entsprechende Teil separiert und mit einer <<uses>> Beziehung wieder in die andere Anwendungsfallbeschreibung eingebunden. Dadurch ist es möglich, Verhalten von den Use-Cases in einen seperaten Use-Case zu verlagern.
<<extends>>, <<erweitert>>
Dieser Verbindungstyp klammert auch Verhalten aus, jedoch ist die Zielsetzung eine andere. Bei <<extends>> wird das Verhalten erweitert. (z.B. für spezielle Abweichungen oder Erweiterungen)
Klassendiagramme sind der zentrale Bestandteil der UML und auch zahlreicher objektorientierter Methoden. Wie die Klassen ermittelt werden, darüber gibt die UML keine Auskunft; hierfür gibt es andere Techniken, z.B.: CRC-Karten (Abkürzung für "Class, Responsibilty and Collaboration") auf die ich in Punkt 10 - Anhang - auf Seite 21 später kurz eingehen möchte.
Die UML beschreibt lediglich die Notation und die Semantik:
Klassen werden durch Rechtecke dargestellt, die entweder nur den Namen der Klasse (fett) oder zusätzlich auch Attribute und Operationen tragen. Klassennamen beginnen mit einem Großbuchstaben. Zum besseren Verständnis hier ein kleines Beispiel: Eine Klasse Kreis würde beispielsweise die Attribute radius und position sowie die Operationen anzeigen(), entfernen (), setPosition(pos) und setRadius(neuerRadius) beinhalten. Das darunterliegende Objekt mit dem Namen: einKreis, welches Exemplar der Klasse ist. Objektenamen werden Unterstrichen.
Attributwerte Attributname Exemplarname Klassenname Operationen Zusicherung Attributname Parameter (Name: Typ=Initialwert= Klassenname
Metaklasse: Klassen für die Klassenobjekte werden Metaklassen genannt und ähnlich wie eine normale Klasse mit dem Stereotyp <<metaclass>> notiert. In Smalltalk sind Klassen grundsätzlich Instanzen ihrer Metaklassen. Die Metaklassen sind selbst Instanzen der Klasse MetaClass, die ist allerdings wider Instanz der Klasse MetaClassClass. Klassenoperationen müssen in der UML nicht innerhalb der Metaklasse notiert werden, sie können auch in der Klasse selbst enthalten sein, wobei sie dann unterstrichen werden, um sie von normalen Operationen unterscheiden zu können.
Parametrisiebare Klasse: Bei einer parametrisierbaren Klasse wird keine konkrete Klasse definiert, sondern lediglich eine Schablone (template) zur Erzeugung von Klassen. Bei diesen Schablonen handelt es sich meist um einfache Makros, die hauptsächlich Textersetzung durchführen.
Abstrakte Klasse: Eine abstrakte Klasse ist eine Oberklasse, die selbst keine Objekte instanzieren kann. So kann Vehikel ein abstrakte Klasse sein, von der man selbst kein Objekt haben kann, und Auto, Flugzeug , usw sind konkrete Klassen. Eine abstrakte Klasse ist also eine Verallgemeinerung od. Abstraktion.
Abhängigkeitsbeziehungen: werden dargestellt durch einen gestrichelten Pfeil, wobei der Pfeil von einem abhängigen auf das unabhängige Element zeigt:
Klassen - Objekt Beziehungen werden so dargestellt, daß das Objekt auf seine Klasse zeigt.
<<instance of>>
Verfeinerungsbeziehungen: werden dargestellt als gestrichelter Generalisierungspfeil in Richtung auf das "Hauptelement":
Vererbung: Bei einer
Vererbung werden die Eigenschaften und
Operationen der Oberklasse an die Unterklassen weitervererbt. Notation:
Generalisierung- Spezialisierung: Bei der Generalisierung - Spezialisierung werden Eigenschaften hierarchisch gegliedert, das bedeutet, das allgemeine Eigenschaften Oberklassen zugeordnet werden, und spezielle werden Unterklassenzugeteilt. Somit erben die Unterklassen die allgemeinen Eigenschaften der Oberklasse. Der Pfeil zeigt von der Unterklasse zur Oberklasse:
Assoziation: Werden durch eine Linie zwischen den Beteiligten Klassen dargestellt. Sie stellt eine allgemeine Beziehung zwischen 2 Klassen dar und sind notwendig, damit Objekte miteinander kommunizieren können.
Multiplizität: Die Multiplizität einer Assoziatin gibt an, mit wievielen Objekten der anderen Klasse ein Objekt assoziiert sein kann. Man spricht auch von Kardinalität. Liegt das Minimum bei 0, bedeutet das, daß die Beziehung optional ist. Ein * bedeutet "unbestimmt - od. Joker"- man kann alles dafür einsetzen:
1 0..1 1 n m n 1 *
Es gibt viele weiter Arten der Assoziation wie z.B. Rekursive Assoziation, Attributierte Assoziation, Assoziationszusicherung, Qualifizierte Assoziation, Abgeleitete Assoziation, Mehrgliedrige Assoziation, Gerichtete Assoziation. Im Rahmen dieser Arbeit gehe ich nicht näher auf die einzelnen Arten ein, es würde den Rahmen sprengen. Eine gute Beschreibung gibt es in [Oestereich'98]- ab Seite 259.
Aggregation: Unter einer Aggregation versteht man die Zusammensetzung eines Objektes aus einer Menge von Einzelteilen. Sie gibt an, daß eine Klasse "Teil-Von" in einer Klasse "Gesamtheit" enthalten ist. (IST-TEIL-VON-Beziehung). Eine Aggregation wird durch eine Linie zwischen 2 Klassen dargestellt, bei der zusätzlich auf der Seite des Aggregats, als des Ganzen (mit der Führungsrolle), eine kleine Raute steht:
Komposition: Eine Komposition ist eine stärkere Form der Aggregation, für sie gelten die gleichen Regeln. Das bedeutet, daß die Kardinalität auf der Seite des Aggregats nur 1 sein kann (nicht wie oben 0..1). Der Teil des Aggregats ist existenzabhäng und hat also die gleiche Lebensdauer wie das Ganze selbst. Notation:
Die zu diesem Klassendiagramm in Java programmierten ausprogrammierten Klassen sind im Anhang zu finden.
Aus den Interaktionsdiagrammen können Zustandsdiagramme entwickelt werden. Sie beschreiben das Verhalten eines Systems. Alle Szenarios definieren ein bestimmtes Zustandsdiagramm genauer. Die Szenarios sind so zu wählen, daß das Zustandsdiagramm einer Klasse vollständig definiert wird.
Zustandsdiagramme zeigen einfach eine Folge von Zuständen, die ein Objekt im Laufe seines Bestehens einnehmen kann. Zustandsdiagramme beschreiben endliche Automaten.
Zustände werden durch abgerundete Rechtecke dargestellt. Sie können einen Namen und (durch einen horizontalen Strich getrennt) Zustandsvariablen besitzen.
Am besten wird die Funktion eines Zustandsdiagrammes Anhand eines Beispiels erklärt:
Zustandsdiagramm für einen Getränkeautomaten:
Start
Zustand Transition Aktivität
Durch das Eintreffen von Ereignissen, kann ein anderer Zustand erreicht werden (was durch die Pfeile symbolisiert wird)
Eine genaue Notation siehe unten:
entry, do und exit sind als Wörter reserviert, und können nicht als Bezeichnung für einen Zustand verwendet werden. (entry gibt an was zu tun ist, wenn man in einen Zustand kommt, do ruft die Aktivität auf, und exit kennzeichnet das Verlassen eines Zustandes)
Ein Aktivitätsdiagramm ist eine spezielle Form des Zustandsdiagramms, das überwiegend oder ausschließlich Aktivitäten enthält. Eine Aktivität ist ein einzelner Schritt in einem Ablauf. Sie ist ein Zustand , in der ein Vorgang abläuft.
Aktivitätsdiagramme sind ähnlich den Flussdiagrammen, jedoch sind alle Aktivitäten eindeutig Objekten zugeordnet.
Grundelemente dieser Diagramme sind
Aktivitäten: Zustände in denen Vorgänge ablaufen
Transitionen: erfolgen automatisch am Ende der Aktivitäten; sie werden durch Pfeile dargestellt
Synchronisationslinien: werden durch Striche dargestellt und schalten, wenn alle Engangstransitionen vorhanden sind.
Swimlanes od. Verantwortlichkeitsbereiche: teilen ein Aktivitätsdiagramm so ein, daß die Bereiche, die sie abgrenzen, einzelnen Klassen zugeordnet werden können.
Beispiel: Geldbehebung via Bankomat.
Es gibt 2 Arten von Verhaltensdiagrammen:
Sequenzdiagramme und
Kollaborationsdiagramme
Beide beschreiben die zeitlichen Abläufe, das heißt die Aufrufsequenzen. Im Grunde beschreiben sie exakt das selbe, die Darstellungsart ist jedoch verschieden.
Beim Erstellen dieser Diagramme beschränkt man sich auf die wichtigsten Szenarios (oft werden sie auch Szenariodiagramme genannt)- später dann werden Sonderfälle miteinbezogen.
Die Darstellung der Objekte erfolgt durch gestrichelte senkrechte Linien ("Lebenslinien") . Oben über der Linie steht der Name bzw. das Objektsymbol. Die Nachrichten werden als Pfeile dargestellt, auf denen der Name notiert ist. Nachrichten können auch Bedingungen haben, die dann in eckigen Klammern angegeben wird.
Die Balken, die vertikal über den Lebenslinien liegen, kennzeichnen den Steuerungfokus, d.h. welches Objekt gerade aktiv ist. (Dieser Balken wird auch "Focus of Control" genannt). Das Löschen eines Objektes wird durch ein X am Ende des Steuerungfokus-balkens gekennzeichnet.
Die Zeitachse verläuft von oben nach unten.
Hier ein Beispiel aus der Anmeldesequenz beim Netzwerkspiel: Mensch-ärgere-dich-nicht.
Ein Eröffnungsspieler startet über einen Internetbrowser ein Java-Applet (GUI-Eingabemaske-Clientseitig). Beim nächsten Schritt werden seine Daten in der Klasse Spieler gespeichert sowie die Spielfiguren initialisiert.
Nachdem sich auch andere Spieler angemeldet haben, kann der Eröffnungsspieler das Spiel starten(über die GUI-Eingabemaske). Danach wird die Klasse Spielfeld initialisiert und die grafische Oberfläche für das Spielen aufgebaut
Das Kollaborationsdiagramm und das Sequenzdiagramm beinhalten die gleichen Informationen und unterscheiden sich lediglich in der
Darstellung. Die automatische Umwandlung eines Sequenzdiagramms in ein Kollaborationsdiagramm und umgekehrt ist möglich. Bei vielen
Klassen und wenigen Nachrichten sind Kollaborationsdiagramme übersichtlicher als Sequenzdiagramme. Sind wenige Klassen und viele
Nachrichten vorhanden, so ist das Sequenzdiagramm besser geeignet.
Beim Kollaborationsdiagramm stehen die Objekte und ihre Zusammenarbeit (Kollaboration) untereinander im Vordergrund; zwischen ihnen werden bestimmte Nachrichten dargestellt.
Notation:
Zwischen den Objekten werden Assoziationslinien gezeichnet, auf denen dann die Nachrichten notiert werden.
Beispiel- Mensch-ärgere-dich-nicht:
Ein Eröffnungsspieler kann seine Daten über die GUI_Eröffnungsmaske eingeben. Dazu zur Verfügung hat er ein TextField Eingabefeld und eine List Farbenliste. Nachdem er seine Auswahl getroffen hat, kann er sein Spiel durch Drücken des Button Spiel_eroeffnen eben eröffnen. Durch dieses Drücken wird ein Event-Prozedur ausgelöst, in der die Daten im Remote Object Spieler gespeichert werden. Nach Warten auf die anderen Spieler kann das Spiel durch Drücken des Button Spiel_starten gestartet werden und die Methode paint der Klasse GUI_Spielfeld wird aufgerufen und das Spielfeld aufgebaut
Das Komponentendiagramm zeigt die Abhängigkeiten unter den Softwarekomponenten, genauer die Abhängigkeiten zwischen
Quellcode, Binärcodekomponenten und ausführbaren Programmen. Einige dieser Komponenten existieren nur während des
Übersetzungsvorgangs, einige nur während des Linkens, andere zur Ausführungszeit und wieder andere die ganze Zeit über. Im
Komponentendiagramm haben die Darstellungen nur Typencharakter, im Gegensatz zu den Deployment oder Verteilungsdiagramm, wo sie zu Instanzen werden
(d. h. die Bezeichnungen werden unterstrichen).
Die Komponenten werden als drei ineinander verschachtelte Rechtecke gezeichnet; ihre Schnittstellen sind Striche mit Kreisen am Ende.
Dadurch können die verschiedenen Schnittstellen der Komponenten dargestellt werden. Das Diagramm enthält ferner Abhängigkeiten in Form
von gestrichelten Pfeilen.
Beispiel:
Schnittstelle
1
Schnittstelle 2
Zur Darstellung der Hardware werden Verteilungs-Diagramme verwendet.
Sie zeigen, welche Komponenten und Objekte auf welchen Knoten (die eine Verarbeitungs- oder Hardwareeinheit darstellen) laufen. Knoten werden als Quader gezeichnet. Unter den Knoten existieren Verbindungen: Dabei handelt es sich um die physikalischen Kommunikationspfade, die als Linien eingezeichnet werden
Häufig werden diese Diagramme mit normalen Zeichenprogrammen erstellt und für die Quader werden Clip-Arts verwendet.
Verteilungsdiagramm für Mensch-ärgere-dich-nicht Spiel
[Oestereich'98]. Bernd Oestereich, Objektorientierte Softwareentwicklung- Analyse und Design mit der Unified Modeling Language. 4. aktuell. Auflage. Oldenbourg Verlag 1998. ISBN 3-486-24787-5
[Fowler'97] Martin Fowler, Kendall Scott, UML konzentriert- Die neue Standard- Objektmodellierungssprache anwenden. 1. Auflage. Addison Wesleey Longman Verlag GmbH 1998. ISBN 3-8273-1329-5
CRC- Karten (Class-Responsibility-Collaboration) wurden in den späten achtziger Jahren von Cunningham und Beck entwickelt (eine gute Einführung in CRC- Karten gibt die Website des Erfinders: http://c2.com/doc/oopsla89/paper.html )
Anstatt Diagramme zur Modellentwicklung zu benutzen, verwendet man zu Präsentation der Klassen kleine Karteikarten.
Anstatt Attribute und Methoden schreibt man Verantwortlichkeiten auf. Was sind nun Verantwortlichkeiten: Es handelt sich um eine Beschreibung des Zwecks der Klasse (losgelöst von Bits und Daten). Wichtig: Es ist nicht erlaubt mehr aufzuschreiben, als auf die Karte paßt.
Als zweites schreibt man nun zu jeder Verantwortlichkeit die Zusammenhänge zu den anderen Klassen auf. So erhält man eine Verbindung zu den anderen Klassen.
Besonders von Vorteil sind CRC Karten beim durchgehen eines Anwendungsfalles: Man nimmt sich die Karten, wie die Klassen in dem Anwendungsfall gerade zusammenwirken. Wie sich die Verantwortlichkeiten dabei gerade bilden, kann man sich auf den Karten notieren.
Beispiel:
Klassenname Verantwortlichkeiten Beziehungen
Wichtig ist, daß man die Karte nicht mit Verantwortlichkeiten "überlädt". Man würde zu sehr in die Tiefe gehen, und verliert die Übersicht.
GameServer.java
// Network game example, (C) Bernd Wender, 1998
import java.rmi.*;
public interface GameServer extends Remote
GameServerImplementation.java
// Network game example, (C) Bernd Wender, 1998
import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.*;
import java.security.*;
import java.util.*;
import java.net.*;
// This is the game server. An instance of this class is created for
// each player
public class GameServerImplementation extends UnicastRemoteObject
implements GameServer
// main method
public static void main(String args[])
catch (Exception x)
}
// binds the 'Game' service to the RMI registry
private void bindService(String service)
catch (Exception e)
}
// creates new instance of itself (GameServerImplementation) and returns
// its remote interface to the client
public GameServer connect() throws RemoteException
// moves its player by [dx, dy]
public void movePlayer(int dx, int dy) throws RemoteException
// gets the position of its player
public Position getPosition() throws RemoteException
Player.java
// Network game example, (C) Bernd Wender, 1998
import java.io.*;
// represents a player (at the server side)
public class Player implements Serializable
// move the player by [dx, dy]
public void move(int dx, int dy)
// get the player's position
public Position getPosition()
public String toString()
Position.java
// Network game example, (C) Bernd Wender, 1998
import java.io.*;
// represents a player (at the server side)
public class Player implements Serializable
// move the player by [dx, dy]
public void move(int dx, int dy)
// get the player's position
public Position getPosition()
public String toString()
GameClient.java
import java.rmi.*;
// This class represents a player on the client side.
public class GameClient
// Oops, something went wrong.
catch (Exception x)
}
// displays the position of a player.
public void displayPlayer(Position p)
// create new client and make it connect to the server. Display
// player's position, move the player and display its position again.
public static void main(String args[])
catch (Exception x)
url = new String('//' + machine + '/Game');
GameClient gameClient = new GameClient(url);
try
catch(RemoteException rx) }}
Haupt | Fügen Sie Referat | Kontakt | Impressum | Nutzungsbedingungen
