Objektorientierte Programmierung Einführung

Transkript

1 Objektorientierte Programmierung Einführung Prof. Dr. Michael Ryba

2 Lernziele Verstehen, warum Softwareentwicklung benötigt wird Wissen, was unter objektorientierter Softwareentwicklung zu verstehen ist Die Unterschiede zur klassischen Softwareentwicklung verstehen Erklären können, warum Objektorientierung sinnvoll ist Wissen, welche objektorientierten Konzepte es gibt Erklären können, was eine Entwicklungsmethode ist Erklären können, wie sich die Phasen Analyse und Entwurf voneinander unterscheiden Wissen, was die Unified Modeling Language ist 2

3 Was ist Software? (engl., eigtl.»weiche Ware«), Abk. SW, Sammelbezeichnung für Programme, die für den Betrieb von Rechensystemen zur Verfügung stehen, einschl. der zugehörigen Dokumentation. (Brockhaus Enzyklopädie) die zum Betrieb einer Datenverarbeitungsanlage erforderlichen nichtapparativen Funktionsbestandteile. (Fremdwörter-Duden) Computer programs, procedures, rules, and possibly associated documentation and data pertaining to the operation of a computer system. (IEEE Standard Glossary of Software Engineering Terminology) 3

4 Sichten auf Software 4

5 Was ist GUTE Software? Gute Software ist qualitativ hochwertig und wird den Bedürfnissen des Anwenders gerecht. Diskussion Denken Sie an ein Programm, das Sie wirklich gerne anwenden. In welcher Hinsicht halten Sie es für ein qualitativ hochwertiges System? Gibt es Gründe, warum es nach den hier aufgestellten Aussagen kein qualitativ hochwertiges System ist? Welche Punkte beeinflussen Ihre Einstellung dazu am meisten? alternativ Denken Sie an ein Programm, das zwar sehr erfolgreich ist, das Sie selbst aber ungern anwenden. Stellen Sie hierzu die gleichen Fragen. 5

6 Eigenschaften guter Software Funktionalität nützlich und nutzbar: Gute Software erleichtert und verbessert das Leben der Anwender Qualität zuverlässig: Gute Software leistet das Geforderte, hat keine Ausfälle verfügbar: Lauffähigkeit auf verfügbarer Hardware & Betriebssystem sicher: Keine verbotenen Effekte, Verhinderung von Gefahren Wirtschaftlichkeit flexibel: Es ist wichtig, Software später noch verändern zu können (Wartung) kostengünstig: in Anschaffung und Unterhalt ergonomisch: leichte Bedienbarkeit, leichte Erlernbarkeit 6

7 Wozu braucht man Softwareentwicklung? Fundamentales Problem bei der Erstellung von Software: Es gibt eine Grenze, wie viel ein Mensch zu einer gegebenen Zeit verstehen kann. Sehr kleine Systeme können unter Umständen mit der SHIT-Methode bewältigt werden. Software zeichnet sich im Allgemeinen durch Komplexität aus: Technische Komplexität: Abhängigkeiten sind für eine Einzelperson nicht überschaubar. Software ist für die Dauer ihres Lebenszyklus Änderungen unterworfen. Entfernung vom ursprünglichen Konzept Soziale Komplexität: Vielfach Einbettung von SW in soziales Umfeld Entwicklung von Software im Team Expertenwissen vs. Informationsaustausch Methoden & Konzepte für die Entwicklung von Software erforderlich 7

8 Probleme der Softwareentwicklung Die Komplexität von Programmen nimmt ständig zu Umfang und Lebensdauer nehmen zu Neue Anwendungen werden für den Rechnereinsatz erschlossen Die Softwareentwicklung ist integraler Bestandteil der Systementwicklung Immer mehr Entwickler sind mit der Pflege von Altsystemen beschäftigt 8

9 Komplexität Kleine Projekte Beispiel aus dem Alltag: Bau einer Hundehütte Keine formale Vorgehensweise (Projektorganisation) nötig kaum Planung erforderlich Ausführung durch eine einzige Person möglich Einfache Werkzeuge ausreichend Säge, Hammer,... In der Softwareentwicklung: Projekte bis max Codezeilen / 2 Personenjahre 9

10 Komplexität Große Projekte Beispiel aus dem Alltag: Bau eines Einfamilienhauses Wohldefinierte Vorgehensweise: erst Plan, dann Rohbau, Installation, Innenausbau,... Genaue Planung erforderlich Ausführung durch ein Team Mächtige Werkzeuge nötig: Kran, Bagger,... In der Softwareentwicklung: Projekte bis etliche Mio. Codezeilen / 200 Personenjahre 10

11 Beispiel: Zunehmende Qualitätsanforderungen 50% der Ausfälle im industriellen Sektor auf Grund von Software- Fehlern Entwicklung der gefundenen Defekte pro 1000 Zeilen Quellcode 11

12 Beispiel: Zunehmende Entwicklungsdauer 12

13 Was ist Softwaretechnik? Definition Softwaretechnik ist der Einsatz qualifizierter Methoden, Werkzeuge und Entwicklungsprozesse zum Erstellen und Betreiben von Software mit dem Ziel, einerseits die Softwarekosten bei der Entwicklung, Wartung und Erweiterung von Programmsystemen zu senken, andererseits zum Erreichen einer höheren Systemqualität Systematische Entwicklung von Software erfolgt in der Regel nach einem vorgegebenen Ablauf Festlegung von: Arbeitsschritten Zu erstellenden Dokumenten Zusammenarbeit zwischen unterschiedlichen Entwicklern Reihenfolge der Bearbeitung 13

14 Wasserfallmodell 14

15 Wie unterstützt Softwaretechnik die Erstellung guter Software? Durch Prozesse für eine strukturierte Vorgehensweise bei der Entwicklung Zuerst Was und dann Wie Durch Methoden und Konzepte zur Abstraktion der Problemstellung Modell ist Abbild der Wirklichkeit Aufteilung in überschaubare Teilprobleme Durch Werkzeuge zur Entwicklerunterstützung Beherrschung der Komplexität aber Systematische Softwareentwicklung ergibt nicht automatisch gute Software Es werden lediglich Methoden und Abläufe vorgegeben, die die Erstellung von guter Software unterstützen 15

16 Methoden der Softwareentwicklung Aufgabe: Komplexität des Gesamtsystems beherrschen Prinzip: Zerlegung (Dekomposition) Zerlegung des Problems in kleinere, handhabbare Teilbereiche, die relativ isoliert voneinander behandelt werden können Verschiedene Ansätze - Zerlegung nach unterschiedlichen Gesichtspunkten funktionsorientierte Zerlegung datenorientierte Zerlegung objektorientierte Zerlegung 16

17 Beispiel: Warenautomat 17

18 Warenautomat Anforderungen Kunde wählt Waren Der Kunde wählt über ein Eingabefeld einzelne Waren und die gewünschte Menge aus. Auf einer Anzeige wird ihm der Preis für die gewählte Menge der Ware und die Gesamtsumme angezeigt. Kunde kann Auswahl korrigieren Kunde signalisiert, dass er mit der Auswahl zu Ende ist Betätigt der Kunde den Auswahl-bestätigen-Knopf, zeigt ihm der Automat den zu zahlenden Betrag an und aktiviert die Geldeingabe. Kunde gibt Geld ein und erhält Waren Der Kunde gibt das Geld in Form von Münzen oder Scheinen ein. Wenn der notwendige Betrag erreicht oder überschritten ist, sperrt der Automat die Geldeingabe und gibt die Waren in der Warenausgabe aus. Anschließend gibt der Automat, falls erforderlich, das Wechselgeld aus. 18

19 Warenautomat Anforderungen Betreiber definiert die Preise der Waren Der Betreiber gibt über eine Tastatur die Warenart und den Verkaufspreis ein. Existiert die Warenart schon, so wird der Preis geändert, sonst wird die neue Warenart mit Preis aufgenommen. Betreiber füllt Waren auf Nachdem der Betreiber den Automaten mit Waren neu bestückt hat, gibt er über die Tastatur Warenart und Menge der hinzugefügten Waren ein. Automat erzeugt Tagesbericht Um Mitternacht erzeugt der Automat auf einem internen Drucker einen Bericht mit Zeitpunkt und Gesamtpreis jedes Verkaufs. Dazu für jede Ware des Verkaufs Warenart, Menge und Preis für die verkaufte Menge. 19

20 Funktionsorientierte Zerlegung Historisch älteste Zerlegungsmethode Beschreibung der Funktionen und Aktionen innerhalb der Anwendung Abstraktion (Modellbildung) durch Betrachtung der zu erfüllenden Aufgabe Ergebnis ist Top-Down-Zerlegung der Funktionen des geplanten Systems Beispiel: Warenautomat (Teilausschnitt) 20

21 Datenorientierte Zerlegung Betrachtung der Datenstrukturen und -transformationen der Anwendung System wird nach Daten zerlegt, die in dem System gespeichert und verarbeitet werden müssen. Bsp.: Entity-Relationship-Modell Beispiel: Warenautomat (Teilausschnitt) 21

22 Funktions-/Datenorientierte Zerlegung Analyse der Aufgabenstellung nach zwei gegensätzlichen Gesichtspunkten Ergänzen sich gegenseitig Funktions- und Datenorientierte Zerlegung gehören zu den so genannten Strukturierten Methoden Strukturierte Analyse (SA) Datenflussdiagramme (funktionsorientiert) Entity-Relationship-Diagramme (datenorientiert) Strukturierter Entwurf (SD) Strukturdiagramme für Funktionsaufruf Module im Sinne von Datenabstraktion 22

23 Nachteile der Strukturierten Entwicklung Entspricht nicht der menschlichen Denkweise Geringe Abstraktionstiefe Strukturbruch zwischen Entwicklungsphasen durch unterschiedliche Darstellungen Umfangreiche Modelle sind schwierig zu lesen und zu ändern Produkte (Dokumentation, Modelle, Programme) sind weniger flexibel bei Änderungen und Erweiterungen Rein funktionaler Entwurf führt zu schlecht wartbaren Programmen Keine Unterstützung der Wiederverwendung 23

24 Objektorientierte Entwicklung Definition: Bei der objektorientierten Softwareentwicklung werden die in der realen Welt vorkommenden Gegenstände und Begriffe als Objekte betrachtet. 24

25 Objektorientierte Entwicklung Merkmale Nicht nur Daten und Funktionen werden beschrieben, sondern auch ihr Zusammenhang sowie Beziehungen zu ihrer Umwelt (andere Objekte) Ergebnisse der Phasen Analyse, Entwurf und Implementierung werden objektorientiert in derselben Notation erstellt Verwendung derselben Konzepte in den Entwicklungsphasen: Analyse - Object-Oriented Analysis (OOA) Entwurf - Object-Oriented Design (OOD) Implementierung - Object-Oriented Programming (OOP) 25

26 Beispiel: Warenautomat Funktionen und Daten werden zusammengefasst Objekt Objektname: Ware Attribute des Objekts Ware: Warenname Preis Anzahl verfügbare Einheiten Methoden des Objekts Ware: Was ist Dein Preis Berechne neue Anzahl (aufgrund Anzahl verkaufte Einheiten) 26

27 Objekte Warenautomat 27

28 Vorteile objektorientierte Softwareentwicklung Strukturen, Zusammenhänge und Abhängigkeiten der realen Welt werden besser erfasst Visuelle Modellierung Objekte, Klassen und Pakete Bessere Durchgängigkeit, evolutionäre Entwicklung wird unterstützt Dieselben Konzepte und Notationen in allen Phasen Kein Strukturbruch zwischen Analyse und Entwurf Vergleichsweise einfache Integration von Änderungen Verkapselung in Klassen und Geheimnisprinzip unterstützen die Wartbarkeit Vererbungskonzept unterstützt Erweiterbarkeit Bessere Wiederverwendbarkeit der Arbeitsergebnisse 28

29 Was ist eine Methode? Definition: Eine Methode beschreibt die systematische Vorgehensweise zur Erreichung eines bestimmten Ziels (griech.: methodos). [H. Balzert] Eine Methode besteht aus: 29

30 Konzepte Grundkonzepte In allen Phasen vorhanden (Analyse, Entwurf, Implementierung) Objekt Klasse Attribut Operation Botschaft Vererbung OO- Programmiersprache unterstützt alle Grundkonzepte Weitere Konzepte für Analyse und Entwurf Modellierung zusätzlicher Aspekte eines Systems Assoziation Anwendungsfall Szenario Zustandsautomat Paket 30

31 Notation Text Beispiel: Pflichtenheft Graphik Beispiel: Klassendiagramm Beispiel: Zustandsautomat Dokumentationsstandards Festlegung, wie Text- und Grafikelemente verwendet werden 31

32 Methodische Vorgehensweise Methodische Schritte Vorgegebene Reihenfolge von Tätigkeiten bei Analyse und Entwurf Unterschiedliche Anzahl vorgegebener Schritte für unterschiedliche Anwendungsbereiche Methodische Regeln Große Anzahl vorhanden (implizit oder explizit) Anwendung erfolgt situationsspezifisch Keine feste Reihenfolge festgelegt Beispiele Helfen auf vorhandenes Wissen zurückzugreifen Konkrete Beispiele Abstrakte Muster (Pattern) 32

33 Frage Wodurch wird bei der objektorientierten Softwareentwicklung die gute Durchgängigkeit von der Analyse bis zur Implementierung erreicht? Verwendung derselben Grundkonzepte in allen Entwicklungsphasen Verwendung grafischer Notation Weil zuerst ein Pflichtenheft erstellt wird Verwendung der gleichen Notation in Analyse und Entwurf Durch vorgegebene Reihenfolge der Tätigkeiten bei Analyse und Entwurf 33

34 Was versteht man unter Analyse? Definition Das Ziel der Analyse ist es, die Wünsche und Anforderungen eines Auftraggebers an ein neues Softwaresystem zu ermitteln und zu beschreiben. [H. Balzert] Erstellen eines Modells der Problemstellung Modell soll konsistent, vollständig, eindeutig und realisierbar sein Aspekte der Implementierung werden bewusst ausgeklammert (Annahme über perfekte Technologie ) Festlegen was das System tun soll, aber noch nicht wie es realisiert werden soll 34

35 Probleme bei der Analyse Anforderungen des Auftraggebers sind in der Regel unklar widersprüchlich fallorientiert Auftraggeber hat keine vollständige Vorstellung des zukünftigen Systems hilfreich: Prototyp Der Systemanalytiker muss sich dem Auftraggeber verständlich machen, nicht umgekehrt! Ziel: Verstehen des Problems und Beschreibung in einem OOA-Modell 35

36 Objektorientierte Analyse Ausgangspunkt der OOA sind Objekte, die in der realen Welt existieren Dinge Personen Begriffe Ereignisse... Darstellung der Objekte und ihrer Beziehungen untereinander OOA - Modell beschreibt Struktur und Semantik des Problems Produkte der Analysephase Pflichtenheft Beschreibung des Leistungsumfanges OOA-Modell Beschreibung der fachlichen Lösung (Fachkonzept) Prototyp der Benutzungsoberfläche Visualisierung des Fachkonzepts 36

37 Pflichtenheft Einstiegsdokument in das Projekt Textuelle Beschreibung dessen, was das zu realisierende System leisten soll Beschreibt das System aus Sicht des Auftraggebers Weniger detailliert als OOA-Modell 37

38 OOA-Modell Fachliche Lösung des zu realisierenden Systems Umsetzung der Anforderungen aus dem Pflichtenheft Modellierung mit grafischer Notation besteht aus statischem Modell Benötigte Klassen und ihre Eigenschaften Beziehungen zwischen Klassen des Modells Vererbungsstruktur Beschreibt die Struktur des Systems dynamischem Modell Aufgaben und Funktionsabläufe Kommunikation zwischen Objekten Beschreibt das Verhalten des Systems 38

39 Beispiel: Diplomarbeitsverwaltung 39

40 Prototyp Benutzeroberfläche Ablauffähiges Programm Besteht aus Fenstern, Dialogen, Menüs usw. Enthält keine Daten oder Funktionalität Bildet Attribute des OOA-Modells auf Programmoberfläche ab Dient zur Kommunikation und Diskussion mit Fachexperten und Benutzern 40

41 Erstellung OOA-Modell Systemanalytiker hat die Aufgabe, den Auftraggeber zu verstehen sowie die Anforderungen zu präzisieren und zu überprüfen Diskussion in einem Team aus Systemanalytiker, Fachexperten und zukünftigen Benutzern (ca. 2-5 Personen) OOA-Modell erstellen Prototyp wird aus OOA-Modell abgeleitet 41

42 Frage Warum ist es wichtig, in der Analyse von allen Implementierungsdetails zu abstrahieren? Weil Implementierungsdetails im Prototyp beschrieben werden Gefahr, dass OOA-Modell auf eine spezielle Umgebung abgestimmt ist Implementierungsdetails können mit objektorientierten Konzepten nicht dargestellt werden Lösung wird zu stark von der verwendeten Technologie eingeschränkt Weil dadurch das Verständnis des Problems gefördert wird 42

43 Was versteht man unter Entwurf? Definition Die Aufgabe des Entwurfs ist es, die in der Analysephase spezifizierte Anwendung auf einer Plattform unter den geforderten technischen Randbedingungen zu realisieren. [H. Balzert] Beschreibung des Systems auf höherer Abstraktionsebene als der Programmcode Erstellung des OOD-Modells Stark mit der Implementierung verknüpft Festlegen wie das System realisiert werden soll 43

44 OOD-Modell OOD-Modell entsteht aus OOA-Modell durch Verfeinerung und Ergänzung OOD-Modell soll ein Abbild des späteren Programms sein Jede Klasse des OOD-Modells kann direkt in einer OO Programmiersprache implementiert werden besteht aus statischem Modell beschreibt die Architektur des Systems enthält alle Klassen des Programms Pakete zur Modellierung von Teilsystemen dynamischem Modell Beschreibung der Kommunikation zwischen den Objekten 44

45 Entwurfsziele objektorientierter Entwurf Berücksichtigung bestimmter Entwurfsziele bei der Erstellung des OOD-Modells Beispiel: Entwurfsziel: Trennung von Fachkonzept, Benutzungsoberfläche und Datenhaltung Realisierung durch: Drei-Schichten-Architektur Einfluss durch: verwendetes GUI (Graphical User Interface) verwendete Form der Datenhaltung 45

46 Zusammenhang OOA OOD Ausgangspunkt des OOD-Modells ist OOA-Modell Verfeinerung und Erweiterung, so dass Abbildung in Programm möglich ist Gleiche Konzepte, gleiche Notation OOD-Modell besteht auch aus statischem und dynamischem Modell Dynamisches OOD-Modell besonders wichtig, da es komplexe Kommunikationsbeziehungen übersichtlich darstellt, die anhand des Programmcodes nur schwer nachvollziehbar sind 46

47 Abgrenzung Analyse und Entwurf 47

48 Frage Warum ist es sinnvoll, die fachliche Funktionalität einer Anwendung, deren Benutzungsschnittstelle und die Datenhaltung strikt zu trennen? 48

49 Unified Modeling Language (UML) The Unified Modeling Language is a visual language for specifying, constructing, and documenting the artifacts of systems. It is a generalpurpose modeling language [...] that can be applied to all application domains (e.g., health, finance, telecom, aerospace) and implementation platforms. [ Die Unified Modeling Language (UML) ist eine von der Object Management Group (OMG) entwickelte und standardisierte Sprache für die Modellierung von Software und anderen Systemen. [de.wikipedia.org] aktuelle Version:

50 UML wurde entscheidend geprägt durch Grady Booch Ivar Jacobson James Rumbaugh hat die vor 1996 existierenden verschiedenen Modellierungsmethoden (der genannten drei, sowie anderer) abgelöst wird zur Prozessmodellierung, Analyse, Spezifikation und zum Systementwurf verwendet es sind sehr viele gute Werkzeuge zur UML auf dem Markt bietet sehr konkreten Übergang zur Implementierung Code-Generierung ist aus den Modellen heraus in vielen Teilen möglich in Zukunft: MDA, MDD und Executable UML? 50

51 Die drei Amigos Ivar Jacobson Grady Booch James Rumbaugh 51

52 Geschichte der UML 52

53 Geschichte der UML 53

54 Entstehung der UML 54

55 Diagramm Übersicht 55

56 Diagramm Übersicht (engl.) 56

57 Strukturdiagramme Klassendiagramm (class diagram) Modellierung der Klassen mit Methoden, Attributen und Beziehungen Paketdiagramm (paket diagram) Modellierung der logische Struktur der Modellelemente mit deren (z.t. abstrakten) Abhängigkeiten Objektdiagramm (object diagram) Modellierung von Momentaufnahmen konkreter Objekte mit Werten und Beziehungsausprägungen Kompositionsstrukturdiagramm (composite structure diagram) Modellierung der internen Struktur eines Modellelements (Classifiers) sowie dessen Möglichkeiten zur Interaktion mit anderen Systemkomponenten Komponentendiagramm (component diagram) Modellierung der Komponenten (=Module) und deren Abhängigkeiten Verteilungsdiagramm (deployment diagram) zeigt die (physischen) Geräte des Systems im Betrieb 57

58 Verhaltensdiagramme Use-Case Diagramm (use case diagram) Modellierung der Anwendungsfunktionalität aus der Sicht der Anwender Aktivitätsdiagramm (activity diagram) Modellierung des dynamischen Ablaufs (i.d.r. eines Use Case) Zustandsdiagramm (state transition diagram) modelliert die Zustände und Zustandswechsel (i.d.r. zu einer Klasse) Sequenzdiagramm (sequence diagram) Modelliert ein Szenario: den Botschaftsfluss zwischen Objekten Kommunikationsdiagramm (comunication diagram) Dynamik wie Sequenzdiagramm; zusätzlich Objekteigenschaften Timing-Diagramm Präziser zeitlicher Verlauf Interaktionsübersichtsdiagramm Modellierung des Zusammenspiels einzelner Interaktionsdiagramme 58

59 Frage Was ist durch die UML definiert? Notation und Symbole für Elemente objektorientierter Modelle Entwicklungsprozess und Vorgehensweise Welche Klassen für ein System benötigt werden Bedeutung der grafischen Symbole Aufbau und Struktur objektorientierter Diagramme 59

60 Zusammenfassung Die Erstellung von Software unterscheidet sich von der Herstellung anderer industrieller Güter Systematische Softwareentwicklung ist notwendig, um die Komplexität moderner Software beherrschbar zu machen Die Softwareentwicklung erfolgt nach einem vorgegebenen Ablauf, einem Entwicklungsprozess, der in unterschiedliche Phasen gegliedert ist. Eine (objektorientierte) Methode setzt sich aus Konzepten, einer Notation und einer methodischen Vorgehensweise zusammen. In der Analyse wird ein Fachkonzept des zu realisierenden Systems erstellt. Das OOA-Modell beschreibt die wesentlichen Merkmale des Problems, aber noch keine technische Lösung. Aufgabe des Entwurfs ist es, das Fachkonzept auf einer Plattform unter den geforderten technischen Randbedingungen zu realisieren. Das OOD-Modell ist ein Abbild des späteren objektorientierten Programms. Als Notation für Analyse und Entwurf dient die Unified Modeling Language UML. 60

61 Frage Weshalb wird in der Analysephase ein Prototyp der Benutzungsoberfläche erstellt? 61

62 Frage Welche der folgenden Aussagen über UML treffen zu? UML ist ein Software-Entwicklungsprozess. UML beschreibt Diagramme und Notationen. UML ist als Modellierungssprache für Menschen gedacht. UML ist eine Entwurfsarchitektur. UML ist abhängig von der verwendeten Programmiersprache. 62