Objektorientierte Programmierung OOP

Ein Anwendungsfall (engl. use case) bezeichnet eine typische Interaktion zwischen einem Anwender und einem System aus der Sicht des Anwenders. Ein Anwendungsfall umfasst Folgen von Aktionen, die reguläre, aber auch vom normalen Verhalten abweichende Abläufe beschreiben.   Anwendungsfälle erfassen genau die Systemaktionen, die für das Zusammenwirken zwischen dem System und seiner Benutzerin erforderlich sind und dazu beitragen, bestimmte Ziele der Benutzerin zu erreichen. Anwendungsfälle werden durch Anwender oder durch Zeitereignisse angestoßen.

Mögliche Anwendungsfälle in unserer Fallstudie sind zum Beispiel die Bestellung bei einem Großlieferanten, die Erfassung einer neuen Premiumkundin oder der Verkauf beliebig vieler Artikel. Diese Anwendungsfälle werden durch die zuständige Mitarbeiterin oder eine Kundin angestoßen.

Anwender und externe Systeme, die an Anwendungsfällen teilnehmen, aber selbst nicht Teil des zu realisierenden Systems sind, werden als Akteure (engl. actor) bezeichnet.

Mögliche Akteure in unserer Fallstudie sind Großlieferanten, die Chefin, Verkäufer, Kunden und Premiumkundinnen sowie der Kurier

Die Teilnahme eines Akteurs an einem Anwendungsfall wird durch eine Assoziation zwischen beiden ausgedrückt. Andere Beziehungen zwischen Akteuren und Anwendungsfällen gibt es nicht.

Ein UML-Anwendungsfalldiagramm beschreibt grafisch die Zusammenhänge zwischen einer Menge von Akteuren und Anwendungsfällen. Ein solches Diagramm besteht aus: • dem System, dargestellt als Rechteck, wobei der Name des Systems im Rechteck steht; • Anwendungsfällen, die als Ellipsen innerhalb des Systems erscheinen und die Bezeichung des Anwendungsfalls enthalten; • Akteure, die als Strichmännchen außerhalb des Systems dargestellt werden, wobei der Name des Akteurs unter das Symbol geschrieben wird; • Assoziationen zwischen Akteuren und Anwendungsfällen, die durch Linien dargestellt werden; • Beziehungen zwischen Akteuren und Anwendungsfällen untereinander.

Die Abbildung zeigt das System, einige Anwendungsfälle, Akteure und ihre Assoziationen untereinander. Die Assoziationen geben an, welche Akteure an welchen Anwendungsfällen beteiligt sind.

Wie die Abbildung veranschaulicht, kann eine Premiumkundin genauso wie ein Kunde direkt im Laden etwas kaufen, sie kann aber darüber hinaus auch etwas telefonisch bestellen und umsonst nach Hause liefern lassen. Eine Premiumkundin ist somit eine Spezialisierung eines Kunden und ein Kunde eine Generalisierung einer Premiumkundin. Ebenso kann eine Chefin die gleichen Aufgaben wie eine Verkäuferin übernehmen, aber eben auch die Bestellungen beim Lieferanten erledigen. Somit handelt es sich bei einer Chefin um eine Spezialisierung von Verkäuferin.

Der Anwendungsfall „Artikelverkauf“ enthält beispielsweise den Anwendungsfall „Bezahlung“.

Eine solche Beschriftung in spitzen Klammern (<<...>>) bezeichnet man in der UML als Stereotyp. Solche Stereotypen kommen bei verschiedenen Elementen zum  Einsatz

Fällt während des Verkaufs eines Artikels auf, dass er gar nicht oder nicht in ausreichender Menge vorhanden ist, so muss eine Nachbestellung erfolgen. Die Bestellung eines Artikels erweitert somit den Verkauf eines Artikels.

Bisher hatten wir nur den allgemeinen Anwendungsfall Bezahlung. Es sollen jedoch laut Fallstudie Barbezahlung, Bezahlung mit Kreditkarte oder per Rechnung möglich sein. Diese Anwendungsfälle können wir als Spezialisierung von Bezahlung modellieren.

So kann ein Anwendungsfall jedes Bezahlverfahren zulassen. Dieser hat dann eine Enthält-Beziehung zum Anwendungsfall Bezahlung, ein anderer wiederum lässt zum Beispiel nur Barbezahlung zu und besitzt deswegen nur eine Enthält-Beziehung zum Anwendungsfall Barbezahlung. Da der Anwendungsfall Bezahlung eine Assoziation zum Akteur Kunde hat, besitzen diese Beziehung auch implizit alle spezielleren Anwendungsfälle.

Wir nennen eine einzelne Abfolge von Aktionen, d. h. einen Ablaufpfad in einem Anwendungsfall, ein Szenario. Ein Szenario, das die Sicht der Anwender wiedergibt, fasst das zu entwickelnde System als Blackbox auf. Die innere Arbeitsweise des Systems bleibt den Anwendern verborgen, von Interesse ist allein das externe Verhalten. Das Augenmerk liegt bei dieser Perspektive auf typischen Interaktionen zwischen Benutzern und dem Anwendungssystem.

Für die Beschreibung der in Anwendungsfällen auftretenden Interaktionen werden Beschreibungsschema wir das in Tabelle angegebene Schema verwenden.

Eine konkrete Anwendungsfallbeschreibung für den Anwendungsfall „Bestellung eines Premiumkunden“ ist in der Tabelle angegeben. Wir ergänzen dabei den Akteur Kurier, da wir nicht davon ausgehen, dass die Lieferung durch einen Verkäufer erfolgen muss.

• Warum benutzt ein Akteur das System? • Welche Art der Antwort erwartet der Akteur von einer Aktion? • Was muss der Akteur tun, um das System benutzen zu können? • Welche Information muss der Akteur dem System übermitteln? • Welche Information erwartet der Akteur als Antwort vom System?

Ein Datenlexikon ist eine nach festen Regeln aufgebaute präzise Bestimmung aller Datenlexikon Datenelemente, die für das Anwendungsgebiet wichtig sind. Das Datenlexikon trägt dazu bei, Missverständnisse sowie unterschiedliche Interpretationen von Auftraggeberinnen und Entwicklern zu vermeiden. Die Tabelle gibt die in einem Datenlexikon üblichen Symbole und Schreibweisen an. Kommentare können dafür benutzt werden, umgangssprachlich Definitionsbereiche oder Maßeinheiten anzugeben.

Zeichenkette = Buchstabe + {(Buchstabe | -)} GanzeZahl = Ziffer + {Ziffer} Premiumkunde = Vorname + Nachname + Anschrift + Kundennummer Vorname = Zeichenkette Nachname = Zeichenkette Anschrift = Straße + Hausnummer + PLZ Straße = Zeichenkette Hausnummer = GanzeZahl + (Buchstabe) PLZ = 00001 | ... | 99999 Kundennummer = GanzeZahl

In einem professionellen Entwicklungsprojekt wird üblicherweise zwischen Auftraggeberinnen und Softwareentwicklern ein sog. Pflichtenheft aufgestellt. Im Pflichtenheft sind alle wichtigen organisatorischen und technischen Vorgabe zur Erstellung der Software zusammengefasst. Das Pflichtenheft bildet die Grundlage für die technische Realisierung der Software. Das Pflichtenheft dient damit zwei Hauptzwecken: • Es muss so abgefasst sein, dass es vom Auftraggeber und den Spezialisten in den Fachabteilungen, die die Software später einsetzen sollen, verstanden wird. • Die erfasste Information muss ebenso für die Softwareentwickler hilfreich sein. Der angestrebte Sollzustand ist der Hauptbestandteil des Pflichtenheftes. Der Istzustand soll nur dann in das Pflichtenheft mit aufgenommen werden, wenn er zur Verdeutlichung des Sollzustandes beiträgt.

Die objektorientierte Programmierung bezeichnet die Abbilder konkreter individuell unterscheidbarer Gegenstände und Träger individueller Rollen in Entwurfsdokumenten und Programmen als Objekte.

Beispiele für Objekte sind in unserer Fallstudie die Kundin Anna Müller, der Kunde Jens Meier oder die Rechnung mit der Nummer 20022.

Wichtig ist, dass es sich bei Objekten um individuelle, identifizierbare Abbilder handelt.

Eine Klasse beschreibt in der objektorientierten Programmierung einen Bauplan für viele ähnliche, aber individuell unterscheidbare Objekte. Klassen werden durch Substantive bezeichnet

Jedes Objekt ist eine Ausprägung einer bestimmtem Klasse. Wir bezeichnen Objekte auch als Exemplare

Mögliche Klassen sind Kunde, Rechnung oder auch Blume. Dabei wären Anna Müller und Jens Meier Objekte der Klasse Kunde und die Rechnung mit der Nummer 20022 ein Exemplar der Klasse Rechnung

Die Eigenschaften, die alle Exemplare einer Klasse besitzen, werden durch Attribute dargestellt. Attribute werden durch Substantive bezeichnet.

Attribute der Klasse Kunde sind name und adresse. Eine Rechnung besitzt beispielsweise die Attribute rechnungsnummer, betrag und ist Bezahlt.

Ein Attributwert bezeichnet den Wert, den ein Exemplar zu einem bestimmen Attribut besitzt.

Ein Beispiel für einen Attributwert des Attributs name der Klasse Kunde ist Anna Müller. Die Nummer 20022 ist ein möglicher Attributwert für das Attribut rechnungsnummer der Klasse Rechnung.

Durch die Attributwerte eines Objekts wird sein innerer Zustand festgelegt.

Das gemeinsame Verhalten aller Objekte einer Klasse wird durch die Methoden der Klasse bestimmt. Jede Methode beschreibt eine Fähigkeit oder mögliche Form des Umgangs mit einem Objekt der Klasse. Methoden werden durch Verben bezeichnet und in der Regel durch ein nachstehendes Klammerpaar „(“ und „)“ abgeschlossen.

Eine Assoziation zwischen zwei Klassen drückt aus, dass es zwischen Exemplaren dieser Klassen eine Beziehung geben kann. Eine Assoziation besitzt einen Namen. Die konkrete Beziehung zwischen zwei Exemplaren wird Verknüpfung genannt. Zu jeder Verknüpfung zwischen zwei Exemplaren muss es immer eine zugehörige Assoziation zwischen den beiden Klassen geben.

Jede Rechnung wird für einen Kunden ausgestellt. Somit hat ein Exemplar der Klasse Rechnung eine Verknüpfung zu einem Objekt der Klasse Kunde. Zwischen den beiden Klassen Kunde und Rechnung existiert die Assoziation rechnungsempfaenger. Die Rechnung 20022 kann somit eine Verknüpfung zum Kunden Jens Meier besitzen.