Editing OOD (section)

==Modellierungselemente==

===Klassen===
Eine Klasse beschreibt eine Gruppe von Objekten mit gleichen Attributen, gleichem Verhalten (Operationen), gleichen Beziehungen zu anderen Objekten und gleicher Bedeutung . Attribute sind Daten für die jedes Objekt einen Wert besizt. Eine Operation ist ein Service, der von jedem Objekt dieser Klasse angefordert werden kann.

Eine Klasse dient als eine Art Vereinbarung zwischen einer Abstraktion und allen Clienten oder mit Rumbaugh’s Worten: Klassen sind eine Abstraktion von Objekten.

Andere wiederum definieren Klasse als eine Instanzierungsvorschrift fuer Objekte. Der Mengenbegriff kommt daher, dass ein Objekt seine Klassenzugehoerigkeit u.U. zur Laufzeit ändern kann, sodaß es keine statische Beziehung zwischen Klasse und Objekt mehr gibt.

Booch:
Man unterscheidet zwischen dem Interface einer Klasse und seiner Implementation. Das Interface wird in drei Teile aufgeteilt:
#public (alle Klienten haben Zugriff)
#protected (Klasse selbst, alle Subclasses und friends haben Zugriff)
#private (Klasse selbst und friends haben Zugriff)
Friendship bricht jedoch das Prinzip der Kapselung. Die unterschiedlichen Programmiersprachen realisieren verschiedene Konzepte dieser Dreiteilung, dieses ausgefeilte Schema wird nur von C++ unterstützt. Man zählt alle privaten Methoden oder Variablen ebenfalls zum Interface und nicht zu Implementierung, weil ein Compiler bei der Deklaration einer Variablen vom Typ Objekt den benötigten Speicherplatz wissen muß, ohne die Implementation zu kennen. In C++ wird eine Klasse in der Regel in einem Header defininiert, der von den clients eingebunden werden muss. Das dort auch die privaten Daten auftauchen wurde oftmals bemängelt. Die privaten Elemente heißen in den unterschiedlichen Sprachen 'instance variable' (Smalltalk), 'field' (Object Pascal), 'member object' (C++) oder 'slot' (CLOS). 
Friendship sollte man in folgenden Situationen verwenden:
#es existiert eine starke Kopplung und Kommunikation zwischen Klassen und Performance spielt eine entscheidende Rolle (z.B. eine Iterator-Klasse, die sehr schnell sein muß und für Listentraversen gedacht ist, s. Beispiel in [4] S.345)
#wenn der insertion operator, der als non member realisiert wird, Zugriff auf private member haben muß (s.[4] S.352)
#wenn extraction operator Zugriff auf data members haben muß, wird er als friend deklariert, ansonsten als global member function
#wenn eine Klasse als Vermittler zwischen zwei anderen eingesetzt wird, kann sie als friend beider Klasssen realisiert werden

Eine abstrakte Klasse hat keine Instanzen. Im Gegensatz dazu steht eine konkrete Klasse. Ist eine Operation abstrakt steht in der UML {abstract} dahinter. Es ist in diesem Zusammenhang wichtig zwischen interface und abstrakter Klasse zu unterscheiden. In abstrakten Klassen können einige Methoden ausprogrammiert sein in interfaces nicht.

Ob Attribute public oder private sein sollen wird oft diskutiert. Ein Vorteil sie nur über Operationen zugreifen zu können ist das Prinzip der Kapselung. Ein weitere Vorteil ist, dass man nur eine Stelle debuggen muss, wenn sie falsch gesetzt werden, da sie nur über eine Operation gesetzt werden dürfen. Ausserdem kann beim Setzen die Integrität überprüft werden d.h. man kann unsinnige Werte verbieten. Dadurch wird auch der Test erleichtert.

====Notation====
s. [[UML#class|UML Notation]]

====Finding classes====
Since the analysis and design process is iterative the list of classes will change as time moves on. 
The Rational Objectory Process advocates finding classes for a system by looking for boundary, control and entity classes. These three stereotypes conform to the model-view-controller point of view.
An entity class models information and associated behavior that is generally long lived. They are often called domain classes since they usually deal with abstractions of real-world enitities.
Boundary classes handle the communication between the system surroundings and the inside of the system.
Control classes model sequencing behavior specific to one or more use cases. Control classes coordinate the event needed to realize the behavior specified in the use case. Control classes are usually application-dependent classes.