Unified Modeling Language

5. KLASSENDIAGRAMM

5.1. Notation Klasse und Objekt

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.


















Metaklasse: Klassen für die Klassenobjekte werden Metaklassen genannt und ähnlich wie eine normale Klasse mit dem Stereotyp <> 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.

5.2. Elemente eines Klassendiagramms (Beziehungselemente)

• 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, dass das Objekt auf seine Klasse zeigt.

<>


• 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, dass 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, dass 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, dass 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:

5.3. Beispiel

Die zu diesem Klassendiagramm in Java programmierten ausprogrammierten Klassen sind im Anhang zu finden.

6. ZUSTANDSDIAGRAMM

6.1. Beschreibung

6.2. Notation und Beispiel

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

7. AKTIVITäTSDIAGRAMM

7.1. Beschreibung

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.

7.2. Notation und Beispiel

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, dass die Bereiche, die sie abgrenzen, einzelnen Klassen zugeordnet werden können.


Beispiel: Geldbehebung via Bankomat.

8. VERHALTENS OD. INTERAKTIONSDIAGRAMME

Sequenzdiagramme und Kollaborationsdiagramme

8.1. Sequenzdiagramm

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.

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

8.2. Kollaborationsdiagramm

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:

9. KOMPONENTEN - UND VERTEILUNGSDIAGRAMM

9.1. Komponentendiagramm

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

9.2. Verteilungs od. Deployment - Diagramm

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

Literaturverzeichnis

[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

Anhang A: CRC - Karten

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, dass man die Karte nicht mit Verantwortlichkeiten "überlädt". Man würde zu sehr in die Tiefe gehen, und verliert die Übersicht.

Anhang B: Java Klassen

GameServer.java

// Network game example, (C) Bernd Wender, 1998

import java.rmi.*;

public interface GameServer extends Remote {
public GameServer connect() throws RemoteException;
public void movePlayer(int dx, int dy) throws RemoteException;
public Position getPosition() throws RemoteException;
}

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 {

// the grid on which players are moving around (for future use)
static int grid[][];

// represents a player
private Player player;

// constructor
public GameServerImplementation() throws RemoteException {
player = new Player();
}

// main method
public static void main(String args[]) {

try {
GameServerImplementation gameServer =
new GameServerImplementation();
gameServer.bindService("Game");
}
catch (Exception x) { x.printStackTrace(); }
}

// binds the "Game" service to the RMI registry
private void bindService(String service) {

try {
Registry registry = LocateRegistry.getRegistry();
registry.bind(service, this);
}
catch (Exception e) { e.printStackTrace(); }
}

// creates new instance of itself (GameServerImplementation) and returns
// its remote interface to the client
public GameServer connect() throws RemoteException {
return new GameServerImplementation();
}

// moves its player by [dx, dy]
public void movePlayer(int dx, int dy) throws RemoteException {
player.move(dx, dy);
}

// gets the position of its player
public Position getPosition() throws RemoteException {
Position p = player.getPosition();
return(p);
}
}


Player.java

// Network game example, (C) Bernd Wender, 1998

import java.io.*;

// represents a player (at the server side)
public class Player implements Serializable{

// the player's position
Position position;

// constructor
public Player() {
position = new Position();
}

// move the player by [dx, dy]
public void move(int dx, int dy) {
position.moveX(dx);
position.moveY(dy);
}

// get the player's position
public Position getPosition() {
return position;
}

public String toString() {
return new String("I am the player");
}
}

Position.java

// Network game example, (C) Bernd Wender, 1998

import java.io.*;

// represents a player (at the server side)
public class Player implements Serializable{

// the player's position
Position position;

// constructor
public Player() {
position = new Position();
}

// move the player by [dx, dy]
public void move(int dx, int dy) {
position.moveX(dx);
position.moveY(dy);
}

// get the player's position
public Position getPosition() {
return position;
}

public String toString() {
return new String("I am the player");
}
}




GameClient.java

import java.rmi.*;

// This class represents a player on the client side.
public class GameClient {

// this is the connection to the GameServer interface.
private GameServer gameServer;

// constructor: connects the GameClient to the GameServer
GameClient(String url) {
try {
// look up the GameServer interface
gameServer = (GameServer) Naming.lookup(url);

// now connect your client. This is, let the server construct
// a new game server thread for your client exclusively.
gameServer = gameServer.connect();
}
// Oops, something went wrong.
catch (Exception x) { x.printStackTrace(); }
}

// displays the position of a player.
public void displayPlayer(Position p) {
System.out.println("Position is " + 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[]) {
String machine, url;
try { machine = new String(args[0]); }
catch (Exception x) { machine = new String("esther"); }
url = new String("//" + machine + "/Game");
GameClient gameClient = new GameClient(url);

try {
gameClient.displayPlayer(gameClient.gameServer.getPosition());
gameClient.gameServer.movePlayer(2, 3);
gameClient.displayPlayer(gameClient.gameServer.getPosition());
}
catch(RemoteException rx) { rx.printStackTrace(); }}}

3781 Worte in "deutsch"  als "hilfreich"  bewertet