Objektorientierte Softwareentwicklung Analyse- und Designmethoden Analyse- & Designmethoden Strukturierte, traditionelle Methoden Objektorientierte Methoden Funktionsorientierte Methoden Datenorientierte Methoden 2 1
Zuordnung Methoden Phasen Requirements Engineering Fachlicher Entwurf Softwareentwurf Programmierung EPK Datenflussplan Datenflussdiagramm Entscheidungstabelle Data Dictionary Datenflussplan Datenflussdiagramm ERM Struktogramm PAP Pseudocode UML UML UML UML 3 Objektorientierung Auffassung der Software als eine Sammlung diskreter Objekte, die sowohl eine Datenstruktur als auch Methoden zur Handhabung der Datenstrukturen in sich vereinigen. 4 2
Prinzipien der Objektorientierung Objekte und Klassen Datenkapselung und Information hiding Vererbung Polymorphismus Definition: Objekt ein Objekt ist eine Einkapselung von Eigenschaften (Attributen) und von Funktionalitäten (Methoden, Operationen, Services), die auf diese Eigenschaften anwendbar sind. ein Objekt stellt einen abstrakten Datentyp dar 3
Definition: Klasse Objekte mit gleicher Struktur (Attributen) lassen sich zu Klassen zusammenfassen. jedes konkrete Objekt einer Klasse wird als Instanz bezeichnet Klassen besitzen Mengencharakter, d.h. Klassen können von daher auch im Sinne von Teilmengen in sog. Unterklassen aufgeteilt werden Definition: Vererbung hierarchisch untergeordnete Klassen erben alle Eigenschaften (Attribute) und alle Operationen der übergeordneten Klassen die untergeordneten Klassen können aber zusätzlich noch spezifische Attribute und Operationen besitzen 4
Gründe für Objektorientierung Wiederverwendbarkeit Klassen können in verschiedenen Systemen wiederverwandt werden. Kapselung unterstützt die Wiederverwendbarkeit. Über Vererbungsstrukturen und Polymorphie können Attribute und Operationen mehrfach genutzt werden Stabilität Durch die Wiederverwendbarkeit entstehen fehlerärmere und stabilere Softwaresysteme. Da Daten in ihrer Struktur weniger Änderungen unterworfen sind als Funktionalitäten, erhöht die Konzentration auf das Objektmodell die Stabilität der Systeme Gründe für Objektorientierung Fehlerreduktion Durch die Zusammensetzung eines Softwaresystems aus stabilen - einzeln testbaren Klassen - ist ein objektorientiertes System i.d.r. fehlerärmer als konventionell entwickelte Software. Zudem unterstützt die Wiederverwendbarkeit die Fehlerreduktion Realistischere Modelle Durch die Betrachtung von Objekten, die in der realen Welt existieren, entspricht die konzipierte Software stärker den Anforderungen der Benutzer. 5
Weitere Gründe Steigerung der Produktzuverlässigkeit (+) Sinkende Produkteffizienz (-) Steigerung der Entwicklerproduktivität (+) Änderung der Entwicklungsdauer, Aufwand verlagert sich hin zu Analyse und Design Steigerung der Mitarbeiterzufriedenheit (+) Entwicklung objektorientierter Programmiersprachen 12 6
Entwicklung objektorientierter Entwurfsmethoden Programmiersprachen Ada OOP Smalltalk traditionelle Analyse- & Designmethoden Composite/ Structured Design SA ERM SA/RT SERM objektbasierte Analyse- & Designmethoden HOOD GOOD Object System Oriented Design Development MOOD OMT OOSystems Analysis OOModelling and Design objektorientierte Analyse- & Designmethoden OOD OOSD Design Method OOA OOSE SOM for OOP schwache Beeinflußung starke Beeinlußung 13 Phasenmodell der objekt-orientierten Softwareentwicklung Objekt-Orientierte Analyse (OOA) Objekt-Orientiertes Design (OOD) Objekt-Orientierte Programmierung (OOP) 14 7
Bespiel Objekt-Modell für OMT nach Rumbaugh et al. Projekt Sprache Person Programmierer Analytiker 15 Beispiel für OOSA nach Slaer/Mellor Sprache Projekt * Projekt-ID Projekt-Name arbeitet an wird bearbeitet von Person * Personal-ID Name Programmierer Analytiker 16 8
Klassen-Notation bei Coad/Yourdon Klassen-Name Attribute Atribute Layer Methoden Service Layer 17 Beispiel für OOA nach COAD/Yourdon 18 9
Beispiel für OOSD nach Wasserman/Pircher/Muller value location point ok display move new-position min max move location bounded point history point bounds history history point location bh point bounded point move 19 OOD-Modell nach Booch 20 10
Beispiel für OOD nach Booch Projekt Person Programmierer Analytiker Projekt Person 21 SOM-V-Modell nach Sinz 22 11
Die drei Amigos Grady Booch James Rumbaugh Ivar Jacobsen 23 Entwicklung der UML 24 12
Komponenten der UML v1.x Stereotype Pakete Notizen Klassendiagramm Einsatzdiagramm Komponentendiagramm Kollaborationsdiagramm Komponenten der UML 29.10.2004 - v1 Objektdiagramm Anwendungsfalldiagramm Zustandsdiagramm Aktivitätsdiagramm Sequenzdiagramm 25 Komponenten der UML v2.x Strukturdiagramme Klassendiagramm Kompositionsstrukturdiagramm bzw. Montagediagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Paketdiagramm Verhaltensdiagramme Anwendungsfalldiagramm bzw. Use-Case-Diagramm Aktivitätsdiagramm Sequenzdiagramm Kommunikationsdiagramm Interaktionsübersichtsdiagramm Zeitverlaufsdiagramm Zustandsdiagramm 13
27 28 14
29 30 15
31 16