Objektorientierte Softwareentwicklung

Transkript

1 Objektorientierte Softwareentwicklung Analyse, Design und Programmierung Ralf Pichocki 15. Auflage 2002

2

3

4 15. Auflage, by PiSoftware Ralf Pichocki Bahnhofstraße 190 D Marl-Sinsen Tel Fax Bearbeitung: Gestaltung: Druck:

5 Inhaltsverzeichnis EINFÜHRUNG... 9 OBJEKTORIENTIERTE VORGEHENSWEISE... 9 ÜBERBLICK GRUNDLAGEN DER SOFTWAREENTWICKLUNG Software-Entwicklung im Spannungsfeld von Qualität Kosten Zeit Qualitätskriterien Probleme der Software-Entwicklung Prinzip der Wiederverwendbarkeit Vorgehensmodelle OBJEKTORIENTIERTE VORGEHENSWEISE EIGENSCHAFTEN UND ZIELE Eigenschaften Ziele OBJEKTORIENTIERTER LEBENSZYKLUS KONZEPTE DER OBJEKTORIENTIERTEN ENTWICKLUNG OBJEKTE KLASSEN VERERBUNG ASSOZIATION AGGREGATION KOMPOSITION NACHRICHTEN POLYMORPHIE GENERIZITÄT SUBSYSTEME SCHNITTSTELLEN OBJEKTORIENTIERTE ANALYSE ZIELE VORGEHENSWEISE ERGEBNISSE Statische Sicht: Dynamische Sicht: Funktionale Sicht: STATISCHES MODELL Vorgehensweise zur Modellierung Identifizieren von Objekten und Klassen Identifizieren von Attributen und Verantwortlichkeiten Identifizieren von Klassen- und Objektbeziehungen Identifizieren von Strukturen Vererbungstrukturen Mehrfachvererbung Aggregationsstruktur Assoziationsstruktur Identifizieren von Methoden Konzept... 29

6 Arten von Methoden Implizite Methoden Explizite Methoden Spezifikation von Methoden Identifizieren von Nachrichtenverbindungen Klassenspezifikation DYNAMISCHES MODELL DES SYSTEMS Allgemeines Ereignisse Zustände Szenarios Ereignisfolgen Zustandsdiagramme FUNKTIONALES MODELL DES SYSTEMS OBJEKTORIENTIERTES DESIGN VORGEHENSWEISE PRÜFFRAGEN: ERGEBNISSE DER DESIGNPHASE Beschreibung der Architektur Beschreibung der gemeinsamen taktischen Vorgehensweise...36 Entwicklungsplan ELEMENTARE SYSTEMBAUSTEINE Problembereichskomponente Kommunikationskomponente Datenmanagementkomponente Taskmanagementkomponente ABKAPSELUNG VON SYSTEMTEILEN UND DEFINITION VON SCHNITTSTELLEN OBJEKTORIENTIERTE PROGRAMMENTWICKLUNG WARTBARKEIT Formen von Wartung Bessere Wartbarkeit durch Objektorientierung WIEDERVERWENDBARKEIT Formen allgemeiner Wiederverwendbarkeit Formen objektorientierter Wiederverwendbarkeit KOMPONENTEN UND TOOLS FÜR OBJEKTORIENTIERTE ENTWICKLUNG KLASSENBIBLIOTHEKEN ENTWICKLUNGS-TOOLS PROJEKTMANAGEMENT-TOOLS METHODENÜBERBLICK OBJEKTORIENTIERTE ANALYSE UND OBJEKTORIENTIERTES DESIGN PETER COAD, EDWARD YOURDON, Ziele Objektorientierte Analyse Objektorientiertes Design OBJEKTORIENTIERTES MODELLIEREN UND ENTWERFEN RUMBAUGH UND ANDERE, Modelle Objektmodell Dynamisches Modell Funktionalitätsmodell OBJEKTORIENTIERTES SOFTWARE-ENGINEERING JACOBSON UND ANDERE,

7 Modelle Anforderungsmodell Analysemodell OBJEKTORIENTIERTE ANALYSE UND DESIGN GRADY BOOCH, Macro Development Process Micro Development Process Dreidimensionales Modell ANHANG: ANFORDERUNGSANALYSE ANWENDUNGSFALLDIAGRAMME AKTIVITÄTSDIAGRAMME BEISPIEL: VERSICHERUNGSVERTRAG ANWENDUNGSFALLANALYSE AKTIVITÄTENMODELLIERUNG BEISPIEL: GETRÄNKEAUTOMAT SYSTEMBESCHREIBUNG ANWENDUNGSFALLDIAGRAMM KANDIDATEN FÜR OBJEKTE, ERSTER ANSATZ KOLLABORATIONSDIAGRAMM KANDIDATEN FÜR OBJEKTE, ZWEITER ANSATZ ENTWURF DER KLASSE LAGER KLASSENDIAGRAMM DER KLASSE LAGER UND IHRER HILFSKLASSEN KLASSENDIAGRAMM DER ALLGEMEINEN KLASSE LAGER UND IHRER HILFSKLASSEN OBJEKTDIAGRAMM FÜR DAS LAGER DES GETRÄNKEAUTOMATEN SEQUENZDIAGRAMM FÜR DIE NACHRICHT MÖGLICHKAFFEE() AN DEN MIXER ZUSTANDSDIAGRAMM FÜR DEN GETRÄNKEAUTOMATEN UNIFIED MODELLING LANGUAGE LITERATURVERZEICHNIS STICHWORTVERZEICHNIS

8 8

9 Einführung Der Objektorientierte Ansatz nimmt in der Analyse- und Designphase von Software-Projekten rasch an Bedeutung zu. Zur Beschreibung objektorientierter Systeme ist die mittlerweile genormte Unified Modeling Language (UML) geeignet, eine grafische Notationsweise, mit der alle Phasen, nämlich Analyse, Design und Programmierung, abgedeckt werden können. Objektorientierte Vorgehensweise Problembeschreibung Analyse: Objekte des Problembereiches sowie ihre Beziehungen untereinander als konzeptionelles Modell der Anwendung Beispiel: Kraftfahrzeug ist ein Fahrzeug, hat einen Motor und nutzt eine Straße Fahrzeug Motor Kraftfahrzeug Straße Design: DV-technische Umsetzung, insbesondere mit den Zielen Wiederverwendbarkeit und Wartbarkeit Beispiel: : Fahrrad ist ein Fahrzeug und nutzt einen Weg (Straße oder Radweg) Fahrzeug Kraftfahrzeug Fahrrad Motor Weg Straße Radweg 9

10 Programmierung: Umsetzung der Ergebnisse von Analyse und Design mit Hilfe objektorientierter oder objektbasierter Programmiersprachen, -tools und systeme Quellcodebeispiel in Programmiersprache JAVA public class Radweg extends Weg { //... } public class Fahrrad extends Fahrzeug { Weg fahrtstrecke = null; //... } Verschiedene Methoden: Peter Coad/Edward Yourdon, Grady Booch und andere Überblick Objektorientierte Vorgehensweise in Analyse und Design, Methodenüberblick Prinzipien der objektorientierten Analyse L Identifikation von Objekten und Klassen L Identifikation ihrer Beziehungen untereinander (Vererbung, Assoziation, Aggregation) L Finden und Festlegen dynamischer und kommunikativer Objektbeziehungen L Beschreibung von Funktionen und Attributen der Objekte und Klassen Prinzipien des objektorientierten Designs L Modellierung elementarer Systembausteine L Abkapselung von Systemteilen, Definition von Schnittstellen L Wartbarkeit und Wiederverwendbarkeit Beispiele und Übungen 10

11 Grundlagen der Softwareentwicklung Software-Entwicklung im Spannungsfeld von Qualität Kosten Zeit Qualität Software Kosten Zeit Qualitätskriterien L Funktionserfüllung L Zuverlässigkeit L Robustheit L Erweiterbarkeit L Wiederverwendbarkeit L Kompatibilität L Portabilität L Benutzerfreundlichkeit L Effizienz L Wartbarkeit Probleme der Software-Entwicklung L Ende der 60er Jahre: GOTO-Krise, Lösung: strukturierte Programmierung L Ende der 80er Jahre: Wiederverwendbarkeits-Krise, Lösung: Objektorientierung Prinzip der Wiederverwendbarkeit L Prozedurale Pogrammierung: Standarfunktionen und Module L Objektorientierte Pogrammierung: Klassen und Klassenbibliotheken 11

12 Vorgehensmodelle L Wasserfallmodell Analyse Design Implementation Test Wartung L Baseballmodell OOA OOP OOD L 4-Phasen-Modell Anforderungsphase (Analyse) Festlegungsphase (Design) Erstellungsphase (Programmierung) Übergabephase (Abschluß) L Spiral-Modell Analys Analys Desig Analys Desig Desig Program Program Program L Anwendungsfallgetriebene architekturzentrierte iterativ-inkrementelle Entwicklung 12

13 Objektorientierte Vorgehensweise L Neue Art Probleme zu verstehen und Lösungen zu finden L Blick auf Objekte als Einheit von Funktionen und Daten Beispiel Auto.heizen() und Haus.heizen() sind verschieden L Softwaresysteme als Menge miteinander kommunizierender Objekte, wobei auch Klassen Objekte sein können L Betonung auf Datenabstraktion, Informationskapselung und Wiederverwendbarkeit L Neue Methoden für Analyse, Design und Programmierung Eigenschaften und Ziele Eigenschaften L Bessere Abbildung der realen Welt L Wiederverwendbarkeit bereits entwickelter Module L Einfache Modifikation und Wartung (Kapselung, Schnittstellen) L Schnell verfügbare Prototypen, Entwicklung inkrementell und iterativ L Besonders geeignet für offene Client/Server-Lösungen Ziele L Reduktion des Aufwandes bei Entwicklung und Wartung L Wiederverwendbare Software-Bausteine und -Bibliotheken Objektorientierter Lebenszyklus L Analyse: Objekte im Problembereich L Design: Objekte im Lösungsbereich L Programmierung: Objekte im Programmcode Objektorientierte Analyse Objekte im Problembereich Objektorientiertes Design Objekte im Lösungsbereich Objektorientierte Programmierung Objekte im Programmcode L Beschreibung aller Phasen mit Hilfe der UML ist möglich 13

14 Konzepte der objektorientierten Entwicklung Objekte L Funktionen L Eigenschaften L Eigenschaftswerte L Identität Klassen Objekte Klassen L Gemeinsamkeiten L Baupläne L Datenabstraktion und Kapselung L Klassifizierungsproblematik Kraftfahrzeug momentgeschw : float innentemp : float beschleunige(zielgesch : float) heize(zieltemp : float) Haus innentemp : float heize(zieltemp : float) 14

15 L Darstellung in der der UML mit Hilfe von Rational Rose 98 Klassenname Attribute Methoden Vererbung L spezielle Klassen Kraftfahrzeug momentgeschw : float = 0 innentemp : float getgeschw() : float beschleunige(speed:float): float Initialwert Typ Rückgabewert Parameter und Typ L erweiterte Funktionalität Konto kontonummer kontostand eroeffnen() aufloesen() Girokonto sollzins kreditlimit einzahlen() auszahlen() aufloesen() Festgeldkonto habenzins restlaufzeit verlaengern() aufloesen() L abstrakte Klassen überschriebene Methode Assoziation L Nutzt -Eigenschaft L Kardinalität L Rolle Firma 2..* Auftrag 0..* FreierMitarbeiter 15

16 Aggregation L Hat -Eigenschaft L Kardinalität L Kann- oder Muß-Beziehung L Komponenten auch allein existenzfähig Firma 0..1 Anstellung 0..* Arbeiter Komposition L Form der Aggregation L Besteht aus -Eigenschaft L Kardinalität L Muß-Beziehung L Komponenten allein nicht existenzfähig Gebäude besteht aus 1 1..* Etage Nachrichten L Senden entspricht Methodenaufruf L Kommunikationspfad (Link) ist notwendig L Sender kennt und sieht den Empfänger L Entspricht Einschreiben mit Rückantwort aber ohne Absender :BankKraft :BankKunde :Sparkonto auszahlen(float) true/false auszahlen(float) true/false 16

17 Polymorphie L Statische Polymorphie L Dynamische Polymorphie BankKunde name : String adresse : String 1 hat 0..* KontoPaket inhaber alleaufloesen() 1 0..* <<Abstract>> Konto kontonummer kontostand eroeffnen() aufloesen() Girokonto sollzins kreditlimit einzahlen() auszahlen() aufloesen() Festgeldkonto habenzins restlaufzeit verlaengern() aufloesen() Sparkonto habenzins einzahlen() auszahlen() aufloesen() L Senden derselben Nachricht an Objekte verschiedener Klassen derselben Basisklasse L trotzdem Aufruf der richtigen Methode Generizität L anderer Weg zur Wiederverwendbarkeit kundekalli : BankKunde kalliskonten : KontoPaket kalliskonto_1 : Konto kalliskonto_2 : Konto alleaufloesen( ) aufloesen( ) ttrue aufloesen( ) ttrue ttrue 17

18 L hauptsächlich Collection-Klassen Liste anhaengen() loeschen() sortieren() groesserals() Liste<Konto> groesserals() Liste<Auto> groesserals() L aber auch andere Klassen, die Objekte als Ganzes bearbeiten Subsysteme L benannte, logische Zusammenfassungen zu Bibliotheken oder Modulen Verkehr Firmen Bankenwelt Schnittstellen L Bereitstellung von Verhaltensmustern, die erst später implementiert werden L Beispiel: Schnittstelle, für einheitlichen Zugriff auf Objekte verschiedener Klassen Kraftfahrzeug momentangeschw : float momentantemp : float Konto kontonummer : int kontostand : float <<Interface>> Anzeigbar benutzt AusgabeDialog beschleunige() heize() anzeigen() eroeffnen() aufloesen() anzeigen() anzeigen() 18

19 L Beispiel: Schnittstelle zum eingeschränkten Zugriff auf Objekte einer Klasse Kraftfahrzeug <<Interface>> Einsteigbar <<Interface>> Lenkbar <<Interface>> Reparierbar <<Interface>> Versteuerbar einsteigen() aussteigen() wobinich() links() rechts() beschleunigen() anhalten() wobinich() klappeauf() reparieren() klappezu() kassieren() Fahrgast Busfahrer Mechaniker Finanzbeamter L Beispiel: Dieselbe Schnittstelle bietet einheitlichen Zugriff auf verschiedene Klassen Kraftfahrzeug A rbeitsvertrag Umsatz <<Interface>> Versteuerbar kassieren() Finanzbeamter 19

20 L Beispiel: Schnittstelle Sortierbar statt Verwendung einer generischen Klasse Kraftfahrzeug Konto <<Interface>> Sortierbar getgroesse() SortierListe einfuegenelement() loeschenelement() sortieren() L Beispiel: Schnittstelle zur Simulation von Mehrfachvererbung Vertrag Kaufvertrag Ratenkauf summe zins <<Interface>> IKredit setsumme() getsumme() setzins() getzins() setsumme() getsumme() setzins() getzins() opname() L Beispiel: Dieselbe Schnittstelle bietet einheitlichen Zugriff auf verschiedene Klassen Ratenkauf summe zins setsumme() getsumme() setzins() getzins() opname() Hypothek leihwert nominalzins setsumme() getsumme() setzins() getzins() <<Interface>> IKredit setsumme() getsumme() setzins() getzins() Bankangestellter summiereallekredite() 20

21 Objektorientierte Analyse Ziele L Probleme verstehen, Organisation aufdecken L Komplexität auflösen, Dekomposition einer Anwendung L Anforderungen beschreiben Vorgehensweise L Vollständig dokumentiertes logisches Modell des relevanten Realweltausschnittes L Darstellung des Anforderungsverhaltens in verschiedenen Modellen und Diagrammen L Ermittlung der Abstraktionen, die den Anforderungen zugrunde liegen L Objekte und Objektverhalten finden und beschreiben L Statische Zusammenhänge zwischen Objekten finden (Beispiel: Bus Motor) L Dynamische Zusammenhänge zwischen Objekten finden (Beispiel: Bus Fahrgast) Ergebnisse Statische Sicht: L Objekte L Klassen L Strukturen L Nachrichtenvebrindungen L Darstellungsmittel: Anwendungsfalldiagramme führt durch Linienfahrt Kraftfahrer <<include>> Fahrgast teilt ein Fahrkartenverkauf Schichtleiter 21

22 L Darstellungsmittel: Objektdiagramme L Darstellungsmittel: Klassendiagramme L Darstellungsmittel: Kollaborationsdiagramme fahrerfritz : Kraftfahrer türenschließen() losfahren() L Darstellungsmittel: Moduldiagramme derbus : Kraftfahrzeug beschleunigen(50) diesel_200_ps : Motor Dynamische Sicht: L Objektverhalten L Kommunikation L Folgen von Methodenaufrufen L Kontrollfluß L Darstellungsmittel: Sequenzdiagramme fahrerfritz : Kraftfahrer derbus : Kraftfahrzeug diesel_200_ps : Motor tuerenschliessen() true losfahren(50) drehzahlerhoehen() Warten bis 50 km/h ASYNCHRON! geschwkonstanthalten() drehzahlkonstanthalten() 22

23 L Darstellungsmittel: Zustandsdiagramme Funktionale Sicht: L Algorithmen Algorithmus Bushaltestelle anfahren : Erreiche Haltebucht der Haltestelle, dabei verringere Geschwindigkeit auf Null, gib alle Türen frei, warte bis niemand mehr ein- oder aussteigt, schließe die Türen. L Realisierung der Methoden L Darstellungsmittel: Ablaufdiagramme Geschw verringern Geschw = 0 UND Ort = Haltpkt? nein ja ja Steigt noch jemand aus oder ein? Türen freigeben nein Türen schließen L Darstellungsmittel: Struktogramme L Darstellungsmittel: Pseudocode Pseudocode Bushaltestelle anfahren : WHILE ( Geschw > 0 ) AND ( NOT ishaltestelleerreicht() ) DO Geschw = MAX( Geschw 10, 0 ) gibfreitueren() WHILE ( jemandsteigtein() OR jemandsteigtaus() ) DO warte( 1 ) schliessetüren() 23

24 Statisches Modell Vorgehensweise zur Modellierung L Identifizieren von Objekten und Klassen L Identifizieren von Verantwortlichkeiten und Attributen L Identifizieren von Klassen- und Objektbeziehungen L Identifizieren von Strukturen L Identifizieren von Methoden und Nachrichtenverbindungen L Zerlegen in Teilsysteme Identifizieren von Objekten und Klassen L Personen, Rollen, Orte, Dinge, Geräte, Einrichtungen L Beschreibungen, Konzepte L Ereignisse, Interaktionen L Organisationen, Einheiten, Systemstrukturen L Relevanz für das zu modellierende System (Realweltausschnitt!) L Klassen stellen Dienste bereit, die für die Gesamtfunktionalität benötigt werden L Klassen enthalten Infomationen, deren Speicherung innerhalb des Systems erforderlich ist L Klassen werden durch mehr als ein Attribut beschrieben L Klassen bilden zunächst nur den Problembereich ab L Klassen enthalten zunächst keine Design- oder Implementierungskonstrukte Identifizieren von Attributen und Verantwortlichkeiten L Objekte einer Klasse haben gemeinsames Verhalten und Menge von Zuständen L Objektverhalten definiert durch Methoden, die für Objekte aufgerufen werden können L Zustand ist bestimmt durch die Werte seiner Eigenschaften L Eigenschaften sind Attribute, aber auch Beziehungen zu anderen Objekten 24

25 L Prüffrage: Wie wird das Objekt allgemein und wie im Problembereich beschrieben? L Prüffrage: Wie ist die Systemverantwortlichkeit des Objektes? L Prüffrage: Welche Informationen werden von den Methoden innerhalb des Objektes benötigt? L Attributspezifikation: Name, Datentyp und Wertebereich, Kurzbeschreibung Identifizieren von Klassen- und Objektbeziehungen L Spezifikation: Name der Klasse, beteiligte Klassen, Kardinalitäten. Kurzbeschreibung L Objekte sind zur Erfüllung ihrer Aufgaben auf die Kommunikation mit anderen Objekten angewiesen L Kommunikationspfad ist Verbindung (Link) zwischen zwei Objekten L Kardinalität der Beziehungen L Beispiele für Klassenbeziehungen: Dozent - Gehaltskonto Dozent name : String anschrift : String 1 1 Gehaltskonto kontonummer : int Kurstyp - Kurs Kurstyp bezeichnung : String dauer : int 1 0..* Kurs kursnummer : int datum : Date Kurs - Teilnehmer Kurs kursnummer : int datum : Date 1..* 0..* Teilnehmer name : String anschrift : String alter : int 25

26 L Beispiele für Objektbeziehungen: dozentdieter dieterskonto, dozentpaul paulskonto dozentdieter : Dozent dieterskonto : Gehaltskonto dozentpaul : Dozent paulskonto : Gehaltskonto typookurs montagoo, dienstagoo, typjava dienstagjava typoo : Kurstyp dienstagoo : Kurs montagoo : Kurs typjava : Kurstyp dienstagjava : Kurs Teilnehmer Kurse tinateilnehmer : Teilnehmer thomasteilnehmer : Teilnehmer mitwochjava : Kurs montagoo : Kurs dienstagjava : Kurs paulparticipant : Teilnehmer dienstagoo : Kurs 26

27 Identifizieren von Strukturen Vererbungstrukturen L Objekte der abgeleiteten Klasse erben alle Attribute, Objektverbindungen und Methoden der Basisklasse L Überall kann statt eines Objektes der Basisklasse auch eines der abgeleiteten Klasse verwendet werden. (Die Umkehrung gilt nicht!) L Alle Nachrichten an Basisklassenobjekte können auch von Objekten einer abgeleiteten Klasse bearbeitet werden: da jedes Konto die Nachricht gibstand() verarbeiten kann, kann auch ein davon abgeleitetes Sparkonto diese Nachricht verarbeiten. L Ein abgeleitetes Objekt kann die Objektverbindungen der Basisklasse nutzen, um selbst Nachrichten zu versenden: da jeder Bus einen Link zu seinem Motor hat, kann auch ein davon abgeleiteter Linienbus diesem die Nachricht beschleunige() senden. L Beispiel: kundekalli : BankKunde kalliskonto : Sparkonto aufloesen( ) true 27

28 Mehrfachvererbung L Eine abgeleitete Klasse erbt von mehreren direkten Basisklassen L Problem: Verschiedene Basisklassen haben gemeinsame Basisklasse, Doppelerbschaft L Beispiel: Vertrag partner : String datum : Date Kaufvertrag produkt : String preis : float Kreditvertrag betrag : float zins : float laufzeit : int Ratenkauf anzahlung : float rate : float Aggregationsstruktur L Ein Objekt enthält ein anderes Objekt oder mehrere andere Objekte L Typen: Gesamtheit-Teil, Container-Inhalt, Gruppe-Mitglied, Verwendung L Beispiele: Gesamtheit-Teil Fuhrpark 1 1..* Bus Container-Inhalt Bus * Fahrgast Gruppe-Mitglied Rezeptur Chemikalie 0..* 1..* 28

29 Assoziationsstruktur L Prüffrage: In welche Teile kann die Klasse im Problembereich zerlegt werden? L Prüffrage: Werden die Komponenten innerhalb der Systemveatwortlichkeit benötigt? L Prüffrage: Erfüllen diese die Kriterien an Klassen, die in das Modell gehören? L Prüffrage: Haben die Teile keine ihrer Aufgaben an die Gesamtheit abgetreten? L Beispiel: steuert Bus Kraftfahrer Identifizieren von Methoden Konzept L Sämtliche Aktivitäten eines objektorientierten Systems basieren auf der Kommunikation zwischen Objekten L Ein Objekt fordert als Client die Dienste eines anderen Objektes als Server mittels Aussenden einer Nachricht an. L Details über Methoden, Nachrichtenverbindungen und Reihenfolgen werden erst später festgelegt. L Eine Nachricht kann auch als Broadcast an alle Objekte einer Klasse gesendet werden L Notwendig für Kommunikation: Objektbeziehung oder Gesamtheit-Teil-Verhältnis L Allgemein kennt der Sender den Empfänger, nicht aber der Empfänger den Sender L Nachrichtenversendung an sich selbst ist möglich und üblich: der Bus, der die Nachricht anhalten() empfängt, wird sich selbst die Nachricht bremsen(0) senden Arten von Methoden L Unterscheide implizite und explizite Methoden L Implizite Methoden in der Analysephase nicht dargestellt, damit überschaubar L Explizite Methoden stellen die echte Funktionalität dar, berechnen Werte 29

30 L In Klassen die Realwelt-Schnittstellen darstellen werden Methoden definiert die auf Eingaben oder Nachrichten externer Systeme warten Konto kontonummer : int kontostand : float Konto() finalize() getkontonummer() setkontonummer() getkontostand() eroeffnen() aufloesen() berechnezins() Kraftfahrzeug momentangeschw : float inntntemp : float Kraftfahrzeug() finalize() getmomentangesch() getinnentemp() beschleunige() heize() Implizite Methoden L Konstruktoren: Erzeugung von Objekten L Destruktoren: Zerstörung von Objekten L Zugriffsfunktionen: setattribut(), getattribut, isattribut(), hasattribut() L Verbindungsfunktionen Explizite Methoden L Beschreiben spezifische Verantwortlichkeiten einer Klasse L Dienste, die ein Objekt dieser Klasse anbietet und zur Verfügung stellt L Prüffragen: Welche Berechnungen sollen die Objekte bereitstellen? Gibt es Überwachungsaufgaben, die wahrgenommen werden müssen? PreisListe preisprotonne : float liest Fracht gewicht : float Rechnung getpreisprotonne() berechnepreis() berechnegesamtpreis() Spezifikation von Methoden L Spezifikation einer Methode wird beim Empfänger bzw. Server vorgenommen L Spezifikation: Name der Methode Typen und Namen der Argumente 30

31 Typ des Wertes Beschreibung L Beispiel: Methoden der Klasse Fracht Methode berechnepreis() Argumente: keine Rückgabewert: Fließkommazahl (float) Beschreibung: Sendet die Nachricht getpreisprotonne() an das Objekt vom Typ PreisListe. Berechnet den Preis als Produkt von gewicht und dem erhaltenen PreisProTonne und gibt diesen Wert zurück. Methode... Identifizieren von Nachrichtenverbindungen L Nachrichtenverbindung setzt einen Kommunikationspfad (Link) voraus L Jede Verbindung (Pfeil vom Sender zum Empfänger) repräsentiert: angeforderte Methode, Argumente (Werte oder Referenzen), Resultat (Rückgabepfeil) L Für einen Link können mehrere verschiedene Nachrichten angegeben werden L Sequenzen von Nachrichten werden durch Nummern geordnet L Spezifikation wird in der Klasse des Senders bzw. Clients vorgenommen L Spezifikation: Name benötigte Methode Typen und Namen der Argumente Typ des Wertes Beschreibung L Beispiel: Nachrichtenenverbindungen der Klasse Fracht Verbindung zur Klasse PreisListe Benötigte Methode getpreisprotonne() Argumente: keine Rückgabewert: Fließkommazahl (float) Beschreibung: Die Anforderung eines Fracht-Objektes an das PreisListe Objekt fordert den Tonnagepreis an, um daraus den Preis für dieses Fracht-Objekt zu berechnen. Verbindung zur Klasse... 31

32 Klassenspezifikation L Klasse: Name, Spezialisierungen, Generalisierungen, Beschreibung L Teile: Namen, Kardinalitäten, Strukturtypen, Beschreibungen L Attribute: Namen, Datentypen, Beschreibungen L Objektverbindungen: Beteiligte Objekte, Kardinalitäten, Beschreibungen L Methoden: Name, Argumente (Namen/Typen), Werte, Beschreibungen L Nachrichtenverbindungen: Beteiligte Objekte, Methoden, Argumente (Namen/Typen), Werte, Beschreibungen Dynamisches Modell des Systems Allgemeines L Modelliert das Verhalten der Objekte L Veränderungen der Attributwerte und Beziehungen im Zeitablauf L Zustandsdiagramme modellieren Lebenszyklen von Objekten L Zustandsübergänge sind immer Reaktionen auf Nachrichten Ereignisse L Ereignis ist Vorfall, der Attributwerte verändert und Zustandsänderung bewirken kann L Ereignis ist immer mit einem Methodenaufruf verknüpft L Externe Ereignisse treten auf bei Schnittstellenobjekt oder von externem System z.b. Taste wurde gedrückt, Timer-Objekt hat externes Ereignis erzeugt L Interne Ereignisse treten auf bei Nachrichtenaustausch innerhalb des Systems z.b. Erzeugen und Löschen von Objekten Zustände L Zustand eines Objektes wird bestimmt durch seine Attributwerte L Zustände, die ein Objekt annehmen kann, werden in Zustandsspezifikation beschrieben L Objekte ändern meistens ihren Zustand, um ihre Aufgaben erfüllen zu können 32

33 Szenarios L Hypothetische Aufeinanderfolge von Ereignissen zur Darstellung der kausalen Zusammenhänge L Jedes vorstellbare Ereignis, das eintreten kann, in mindestens einem Szenario erfasst L Szenarios können als Skript formuliert werden. Ereignisfolgen L Formalere und detailliertere Darstellung der Objektinteraktionen aus den Szenarios L Erleichtern die Validierung der modellierten Struktur- und Verhaltensaspekte L Pro Szenario ein Ereignisfolgediagramm L Objekte durch vertikale Linien, Nachrichten durch Pfeile vom Sender zum Empfänger L Beispiel: Vollständiges Sequenzdiagramm für die Methode berechnegesamtpreis() der Klasse Rechnung diebuchhaltung dierechnung : fracht_1 : Rechnung Fracht fracht_n : Fracht diepreise : Prei sliste berechnegesamtpreis( ) berechnepreis( ) Gewicht g * p getpreisprotonne( ) Preis p summiere alle Einzelpreise in w für alle Frachten 1 bis N Gesamtpreis w berechnepreis( ) Gewicht g * p getpreisprotonne( ) Preis p 33

34 Zustandsdiagramme L Darstellung von Ereignissen, Zuständen, Aktivitäten und ihre Aufeinanderfolge für eine Klasse, für ein Teilsystem oder das ganze System L Jeder Weg durch das Diagramm beschreibt ein Verhaltensmuster für ein Objekt L Dem Verhalten in einem Szenario oder Ereignisfolgediagramm entspricht genau ein Weg durch das Zustandsdiagramm L Zustandsdiagramme entstehen aufbauend auf die Ereignisfolgediagramme L Beispiel Zustandsdiagramm auszahlung/einzahlung einzahlung / auszahlung+limit Haben oder Null auszahlung + limit einzahlung Soll einrichten ausgleichen + aufloesen Funktionales Modell des Systems L Algorithmische Beschreibung der identifizierten Methoden und Aktivitäten L Entwurf erfolgt auf Klassenebene L Hilfsmittel zur Spezifikation: Strukturierte Sprachen, Entscheidungsbäume und tabellen, Ablaufpläne, Struktogramme, Pseudocode, mathematische Gleichungen 34

35 Objektorientiertes Design L Nahtloser Übergang L OOA: Modell zur Beschreibung der Systemverantwortlichkeiten L OOD: Architekturmodell des zu implementierenden Systems L Allgemeine taktische Vorgehensweise Vorgehensweise L Modellierung spezifischer Implementierung unter Berücksichtigung von Hard- und Softwareumgebung L Statisches Modell wird erweitert um lösungsspezifische Attribute, Objektverbindungen, Methoden oder Klassen L Iteration zwischen Problembereich (OOA) und Lösungsbereich (OOD) Prüffragen: L Welche Attribute sind nötig um Objektverbindungen zu implementieren? L Welche Attribute sind nötig um Gesamtheit-Teil-Beziehungen zu implementieren? L Sollen zur Effizienzsteigerung ableitbare Attribute modelliert werden? L Welche zusätzlichen Klassen sind notwendig: Hilfsklassen, Benutzerschnittstelle? L Sind persistente Objekte gefordert? Wenn ja, für welche Klassen? L Findet Kommunikation nur synchron oder auch asynchron statt? L Ist das System zentral oder verteilt zu realisieren? Wie werden im verteilten Fall Nachrichten weitergeleitet? Welche Architektur ist geeignet? Plattformunabhängigkeit: RMI, Beans Sprachenunabhängigkeit: COM, DCOM, ActiveX Plattform- und Sprachenunabhängigkeit: RPC, DCE, CORBA L Fehlermöglichkeiten, Ausnahmebehandlungen insbesondere bei verteilten Systemen L Datenschutz: Authentisierung, Authorisierung, Verschlüsselung L Datensicherheit: Redundanz, Transaktionsverfahren 35

36 Ergebnisse der Designphase Beschreibung der Architektur L Klassen und Objektdiagramme der logischen Architektur L Moduldiagramme der physikalischen Architektur L Einteilung der Klassen in Klassenkategorien L Einteilung der Module in Subsysteme Beschreibung der gemeinsamen taktischen Vorgehensweise L Fehlerbehandlung L Speicherverwaltung L Datenspeicherung L Taskmanagement L Transaktionskonzept L Sicherheitskonzept Entwicklungsplan L Versionsplanung L Einordnung der Szenarios und Funktionspunkte in Versionsfolge L Aufgabenverteilung L Risikoeinschätzung und Terminplanung L Verifizierung der Architektur mit Hilfe von Prototypen Elementare Systembausteine Problembereichskomponente L Klassen und Strukturen gemäß der Analysephase L Fortgeschrieben und ergänzt in der Designphase Vertrag partner : String datum : Date String FTDatum isfeiertg() 36

37 Kommunikationskomponente L Bedienung des Systems durch den Benutzer L Präsentation von Resultaten und Informationen L Klassen und Objekte auf der Systemgrenze, stark werkzeug- und bibliotheksabhängig Component Container Panel Applet paint() L eigenständiges, klar abgegrenztes Subsystem L Beispiel: Vertrag partner : String datum : Date Kaufvertrag produkt : String preis : float <interface> Anzeigbar Panel (from JAVA) Container (from JAVA) Component (from JAVA) anzeige() paint() Anzvertrag 0..* 1 VertragsDialog anzeige() 37

38 Datenmanagementkomponente L Datenaspekte, Voraussetzung für Speicherung und Wiederauffinden von Objekten L Einfluß haben Integrität und Konsistenz, aber auch Zugriffsgeschwindigkeit L Ebenfalls isoliert zu betrachtendes Subsystem L Technik Textdatei: unstrukturiertes Speichern in Datei in der Regel proprietäres Format zusätzliche abstrakte Basisklasse oder Schnittstelle (JAVA) für persistente Objekte PersistentesObjekt (from Datenmanagement) bereitespeicherungvor() schreibeobjekt() liesobjekt() Vertrag (from Banken) partner : String datum : Date Fracht (from Verkehr) gewicht : float berechnepreis() PersistenterVertrag (from Banken) schreibeobjekt() liesobjekt() PersistenteFracht (from Verkehr) schreibeobjekt() liesobjekt() 38

39 L Technik Relationale Datenbank: Speicherung in einer oder mehreren Tabellen Schutzmechanismen werden genutzt generische Klasse für Datenbankcollection Abbildung in die Relationen eines Datenbankschemas Verschiedene Verfahren: für jede Klasse eine Tabelle (ObjID, Attribut,...) für jedes Attribut jeder Klasse eine Tabelle (ObjID, Attribut) insgesamt nur eine Tabelle (Klasse, ObjID, Attributname, Attribut) L Technik Objektorientierte Datenbank: Nutzung der entsprechenden Erweiterung einer objektorientierten Programmiersprache Persistente Objekte unterscheiden sich nicht mehr von transienten Objekten Taskmanagementkomponente L Koordination der Problembereichsobjekte und ihrer Methoden L Modellierung des nebenläufigen Verhaltens verschiedener Objekte sowie der asynchronen Objektkommunikation L Klassen zum Starten und Beenden von Tasks und Prozessen L Aktivitäten und Aktionen, Interprozesskommunikation und Prioritäten Abkapselung von Systemteilen und Definition von Schnittstellen L Modularisierung hat als Ziel kohäsive und lose gekoppelte Module L Komplexität durch Modularisierung wesentlich verringert L Module als Klassengruppen unter dem Aspekt der Wiederverwendbarkeit 39

40 Objektorientierte Programmentwicklung Wartbarkeit Formen von Wartung L Fehlerbehebung und Mängelbeseitigung L Weiterentwicklung und Erweiterung der Funktionalität Bessere Wartbarkeit durch Objektorientierung L Robustheit L Erweiterbarkeit L Wiederverwendbarkeit L Abbildung ähnlich der realen Welt L Verflechtung von Analyse und Design L Kompatibilität Wiederverwendbarkeit Formen allgemeiner Wiederverwendbarkeit L Code L Komponenten aus Bibliothek L Design-Muster L Anforderungsspezifikationen Formen objektorientierter Wiederverwendbarkeit L Basisklassen L Spezialisierte Klassen L Mechanismen, sog. Design-Patterns L Application-Frameworks L Business-Objekte L Dokumentkomponenten 40

41 Komponenten und Tools für objektorientierte Entwicklung Klassenbibliotheken L Problembezogen wiederverwendbare Klassen, z.b. Business-Objekte L Anwendungsbezogen wiederverwendbare Klassen, z.b. Framework-Objekte L Erweiterte Basisklassen, z.b. Grafikklassen, Bedienelemente L Basisklassen, z.b. Datenstrukturen Entwicklungs-Tools L Standardisierte Notation, z.b. Unified Modelling Language (UML) L Unterstützung des gesamten Entwicklungsprozesses (OOA OOD OOP) L Grafisches Entwicklungssystem, textueller Editor mit Sprachenunterstützung L Browser für Klassen- und Modulhierarchien L Quellcodegenerator für die Zielsprache L Reverse Engineering für Round-Trip-Entwicklung L GUI-Builder, Compiler, Debugger L Klassenbibliothekar für Verwaltung eigener und vorgefertigter Bibliotheken Projektmanagement-Tools L Konfigurationsmanagement mit Quelltext- und Versionskontrolle L Projektübergreifende Informationen L Projektplanung und steuerung 41

42 Methodenüberblick L Objektorientierte Analyse und objektorientiertes Design Peter Coad, Edward Yourdon, 1991 L Objektorientiertes Modellieren und Entwerfen Rumbaugh und andere, 1991 L Objektorientiertes Software-Engineering Jacobson und andere, 1992 L Objektorientierte Analyse und Design Grady Booch, 1994 Objektorientierte Analyse und objektorientiertes Design Peter Coad, Edward Yourdon, 1991 Ziele L Objektorientierte Analyse L Objektorientiertes Design L Top-down-Ansatz L Integrierte Vorgehensweise durch objektorientierten Systementwurf L Schließen der Lücke zwischen Analyse und Design Objektorientierte Analyse L Identifikation von Klassen und Objekten des abzubildenden Realweltausschnittes L Identifikation von Strukturen Generalisierung Spezialisierung Vererbungsprinzip L Definition von Subjekten als Zusammenfassung von Objekten L Attribute und Instanzenverbindungen definieren Beachtung von Generalisierung und Spezialisierung Attribute nur in der kleinsten gemeinsamen Oberklasse notieren Instanzenverbindungen bedeuten, dass ein Objekt ein anders benötigt, um seine Aufgabe erfüllen zu können 42

43 L Definition von Methoden und Nachrichtenverbindungen Erzeugen und Löschen eines Objektes Lesen und Schreiben der Daten eines Objektes Berechnungen Objektorientiertes Design L Problembereichskomponente Verfeinerung der Ergebnisse der Analyse, z.b. im Hinblick auf Speicherverwaltung und Wiederverwendbarkeit L Kommunikationskomponente Schnittstelle zwischen DV-System und Anwender erarbeiten L Taskmanagement-Komponente Berücksichtigung zeitkritischer Vorgänge Hardwareeinsatz L Datenmanagement-Komponente Zugriff auf und Manipulation von Daten datenbankunabhängiger Entwurf 43

44 Objektorientiertes Modellieren und Entwerfen Rumbaugh und andere, 1991 Modelle L Objektmodell L Dynamisches Modell L Funktionalitätsmodell Objektmodell L Identifizieren von Klassen und Objekten L Anfertigen eines Data Dictionary L Identifizieren von Beziehungen und Aggregationen L Identifizieren der Attribute von Objekten und Beziehungen L Einführung von Vererbungshierarchien zur Vereinfachung L Sicherstellung von Zugriffpfaden für gewöhnliche Anfragen L Wiederholung der bisherigen Schritte und Verfeinerung des Modells L Gruppierung von Klassen in Modulen Dynamisches Modell L Entwerfen von Szenarien typischer Interaktionsfolgen L Identifizieren von Ereignissen L Entwurf einer Ereignisfolge für jedes Szenario L Erstellen von Zustandsdiagrammen für jede Objektklasse L Zuordnen von Ereignissen, Zuständen und Zustandsübergängen Funktionalitätsmodell L Identifikation der Ein- und Ausgabedaten L Entwerfen von Datenflußdiagrammen L Spezifikation der benötigten Funktionen L Identifizieren von Beschränkungen L Spezifizieren von Optimierungskriterien 44

45 Objektorientiertes Software-Engineering Jacobson und andere, 1992 Modelle L Anforderungsmodell L Analysemodell Anforderungsmodell L Funktionale Anforderungen Statische Struktur und statisches Verhalten Dynamisches Verhalten L Darstellungsform Anwendungsfälle Schnittstellenbeschreibungen Problemdomäne L Inhalte Akteure Anwendungsfälle Systemabgrenzungen Domänen-Objekte und Beziehungen Analysemodell L Fachliche Systemstruktur Statische Struktur und statisches Verhalten L Darstellungsform Anwendungsfälle Schnittstellenbeschreibungen Problemdomäne L Inhalte Entity-Objekte Interface-Objekte 45

46 Control-Objekte Beziehungen zwsichen diesen Objekten Objektorientierte Analyse und Design Grady Booch, 1994 Macro Development Process L Konzeptualisierung: Festlegen der Kernanforderungen L Analyse: Entwicklung eines Modells für das gewünschte Sytemverhalten L Design: Erzeugung einer Architektur für die Implementierung L Evolution: Implementierung mit schrittweiser Verfeinerung L Wartung: Verwalten der Entwicklung nach der Auslieferung Micro Development Process L Identifizieren von Klassen und Objekten einer bestimmten Abstraktionsebene L Festlegen der Semantik dieser Klassen und Objekte L Festlegen der Beziehungen zwischen diesen Klassen und Objekten L Spezifizieren der Schnittstellen und Implementierung dieser Klassen und Objekte Dreidimensionales Modell Dynamisches Modell Statisches Modell Logisches Modell Klassenstruktur Objektstruktur Physikalisches Modell Modul-Architektur Prozeß-Architektur 46

47 Anhang: Anforderungsanalyse Anwendungsfalldiagramme L Beschreibung einer typischen Interaktion eines Anwenders mit dem System L Anwendungsfall entspricht etwa einem Geschäftsvorfall L Keine Beschreibung des internen Verhaltens, keine funktionale Zerlegung L Kein Designhilfsmittel sondern nur für die Anforderungsanalyse L Textuelle Beschreibung zusätzlich zum Anwendungsfalldiagramm Nummer und Name des Anwendungsfalles sowie eine Kurzbeschreibung Auslöser sowie Vorbedingungen: Erwarteter Systemzustand vor dem Eintreten Ergebnisse und Nachbedingungen: Erwarteter Systemzustand nach dem Durchlaufen Nicht-funktionale Anforderungen: Design, Plattformfragen, Entwicklungsprioritäten Ablaufbeschreibung, gegliedert in Einzelschritte, jeder davon separat beschrieben Ausnahmen und Varianten: Abweichungen vom Normalfall, alternatives Verhalten Offene Punkte, Fragen, Dokumente, Referenzen L Daumenregel: Pro Aufwandsjahr etwa fünf Anwendungsfälle L Anwendungsfälle beschreiben, was das System leisten soll, nicht wie es das macht L Prinzipiell auch nicht-softwareunterstützte Aktivitäten möglich 47

48 Aktivitätsdiagramme L Verfeinerung der Anforderungen durch Modellierung von Einzelaktivitäten L Einzelschritte der Anwendungsfälle sind Kandidaten für Einzelaktivitäten L Zusätzliche Zuweisung der Verantwortlichkeiten L Aufteilung in verschiedene Swim Lanes 48

49 Beispiel: Versicherungsvertrag Anwendungsfallanalyse L Anwendungsfalldiagramm L Beschreibung des Anwendungsfalles Vertrag schließen Beschreibung 1. Beginn der Vertragslaufzeit eingeben 2. Produkt auswählen Der Anwender wählt ein Produkt aus, um es dem Vertrag zuzuordnen. Zur Auswahl werden ihm alle Produkte angeboten, die zum eingegebenen Vertragsbeginn gültig sind. 3. Vertrags-Nr. wird erzeugt Die Vertragsnummer wird automatisch erzeugt und eingeblendet. 4. include Anwendungsfall Versicherungsnehmer zuordnen 5. Beitragszahler, Postempfänger und Leistungsempfänger festlegen [...] 6. [...] 7. include Anwendungsfall Deckungen anlegen 8. Vollständigkeit und Plausibilität prüfen sowie berechnen 9. Freigeben Variationen 4. Statt einen vorhandenen Versicherungsnehmer zu suchen und auszuwählen, wird ein neuer Versicherungsnehmer angelegt. 8. Ist die berechnete Prämie >500, muß der Vertrag speziell geprüft und autorisiert werden. extend Anwendungsfall Vertrag autorisieren 49

50 Aktivitätenmodellierung L Aktivitätsdiagramm L Transitionen L Synchronisation L Darstellung von Objektzuständen 50

51 Beispiel: Getränkeautomat Systembeschreibung Das System beschreibt die Funktionsweise eines Getränkeautomaten für Warmgetränke (Kaffee und Kakao) einschließlich seiner Wartung (Nachfüllen von Zutaten) L Münzeinwurf und rückgabe L Getränkeauswahl und zubereitung L Getränkeausgabe L Leeren der Kasse und Auffüllen von Zutaten Anwendungsfalldiagramm Durstige Kehle <<include>> Getränk zubereiten und ausgeben Geld nehmen und wechseln <<include>> Zutaten überprüfen Automatenwart Kasse leeren <<include>> Zutaten nachfüllen 51

52 Kandidaten für Objekte, erster Ansatz L Durstige Kehle, Automatenwart L Rohstoffe, Becher, Wasser, Milch, Kaffepulver, Kakaopulver L Geld, Groschen, Fuffziger, Markstücke L Preisliste L Automat, Kasse, Getränk L Auswahlknöpfe L Mixer, Lager, Geldzähler Kollaborationsdiagramm :Mixer mixegetränk( ) :Auswahlpanel gibpreis( ) genugrohstoffe( ) :Preisliste gibeinwurf( ) :Lager genuggeld( ) :Geldzähler Kandidaten für Objekte, zweiter Ansatz L Rohstofflager Attribute: Becher, Wasser, Milch, Kaffepulver, Kakaopulver L Geldzähler Attribute: Groschen, Fuffziger, Markstücke L Preisliste L Auswahlknöpfe L Mixer 52

53 Entwurf der Klasse Lager L Attribut: Becher, Ganzzahl, Zahl der vorhandenen Becher L Attribut: Wasser, Fließkommazahl, Menge des vorhandenen Wassers L Attribut: Milch, Fließkommazahl, Menge der vorhandenen Milch L Attribut: Kaffepulver, Fließkommazahl, Menge des vorhandenen Kaffepulvers L Attribut: Kakaopulver, Fließkommazahl, Menge des vorhandenen Kakaopulvers L Methode: gibmengezahl, Parameter: Typ, Rückgabe: Ganzzahl, liefert die Zahl der vorhandenen Becher L Methode: gibmengegramm, Parameter: Tyü, Rückgabe: Fließkommazahl, liefert die vorhandene Menge der als Typ gewählten Zutat Klassendiagramm der Klasse Lager und ihrer Hilfsklassen Flüssigkeitsbestand flüssigkeitstyp : String menge : float 4 Lager 1 genugrohstoffe() genuggeld() Becherbestand anzahl : int Geldeinwurf münztyp : {10er,50er,100er} anzahl : int L Strenggenommen unterscheiden sich Becherbestand und Geldeinwurf nur sehr wenig L Führe daher für beide eine gemeinsame Basisklasse ein L Modelliere diese sofort so, daß sie später auch für andere Anwendungen nutzbar ist L Modelliere enstprechend eine Basisklasse für den Flüssigkeitsbestand 53

54 Klassendiagramm der allgemeinen Klasse Lager und ihrer Hilfsklassen AllgemeinesLager entnehmestück(was : String) : boolean einfügestück(was : String) entnehmemenge(was : String, wieviel : float) : boolean einfügemenge(was : String, wieviel : float) * Stückbestand typ : String menge : int entnehme() : boolean einfüge() gibbestand() : int 0..* Mengenbestand typ : String menge : float entnehme(wieviel : float) : boolean einfüge(wieviel : float) gibbestand() : float Objektdiagramm für das Lager des Getränkeautomaten 54

55 Sequenzdiagramm für die Nachricht möglichkaffee() an den Mixer durstiger : Mixer : Allgemeines Lager möglichkaffee( ) gibbestandstück("becher") false false false [z==0] [z<90] [z<10] z gibbestandmenge("wasser") z gibbestandmenge("kaffepulver") z true 55

56 Zustandsdiagramm für den Getränkeautomaten zubereitung & bechertest!ok bechertest!ok einschalten & bechertest ok aktiv genauere Erklärung siehe weiter unten zubereitung & bechertest!ok aktiv - genauer defekt/wartung Geldeinwurf wartend auf Geld Geldeinwurf wartend auf Auswahl Zubereitung beendet Auswahl bei der Zubereitung 56

57 Unified Modelling Language Notationsübersicht Unified Modelling Language (UML), entnommen aus [13] 57

58 58

59 59

60 60

61 Literaturverzeichnis [1] Ken Barclay et al., Objektorientiertes Design mit C++, Prentice Hall, 1997 [2] Daniel J. Berg et al., Advanced Techniques for Java Developers, Wiley & Sons, 1999 [3] Grady Booch, Object-oriented Design, Benjamin/Cummings, 1991 [4] Rainer Burkhardt, UML Unified Modeling Language, Addison-Wesley, 1998 [5] Peter Coad, Edward Yourdon, Object-orientied Design, Yourdon-Press, 1991 [6] Mark Coats et al., Using the CMOSpecification, Dr. Dobb s Journal, June 99 [7] Klaus-Peter Eckert, Objekt-Orientiertheit in offenen Systemen, Thomson, 1995 [8] Igor T. Hawryszkiewycz, Systemanalyse und Design, Prentice Hall, 1995 [9] Gerti Kappel, Michael Schrefl, Objektorientierte Informationssysteme, Springer, 1996 [10] Robert C. Martin. Objektorientierte C++-Anwendungen, Prentice Hall, 1996 [11] Bertrand Meyer, Objektorientierte Softwareentwicklung, Hanser, 1988 [12] Udo Müller, C++-Implementierungstechniken, Thomson, 1997 [13] Bernd Oesterreich, Objektorientierte Softwareentwicklung, Oldenbourg, 1998 [14] Bernd Oesterreich, Erfolgreich mit Objektorientierung, Oldenbourg, 1999 [15] Objektorientierte Analyse und Design, Siemens Nixdorf Trainings Center, 1996 [16] Objektorientierte Programmierung, Siemens Nixdorf Trainings Center, 1996 [17] Dirk Riehle, Entwurfsmuster für Softwarewerkzeuge, Addison-Wesley, 1997 [18] Jeremy Rosenberger, CORBA, SAMS/Markt&Technik, 1998 [19] Günther Wahl, UML kompakt, OBJEKTspektrum 2/1998 [20] Rebecca Wirfs-Brock et al., Objektorientiertes Software-Design, Hanser,

62 62

63 Stichwortverzeichnis 4 4-Phasen-Modell A Aggregation... 17, 29 Analyse... 9, 22 Assoziation... 16, 30 B Baseballmodell D Design... 9 E Eigenschaft Eigenschaftswert F Funktion G Generizität I Identität K Klasse Komposition L Lebenszyklus M Methoden Arten explizite implizite Spezifikation N Nachricht Nachrichten O Objekt P Polymorphie Programmierung Q Qualitätskriterien S Schnittstelle Sicht Dynamische Funktionale Statische Spiral-Modell Subsystem V Vererbung... 16, 28 mehrfache Vorgehensweise... 9, 13 W Wasserfallmodell

64

65

66