Grundlagen und Prinzipien des Software-Entwurfs ALLG. METHODEN DES SOFTWAREEINGINEERING
Ziele der Veranstaltung (I) Grundlagen und Begrifflichkeiten Prinzipien des Architekturentwurfs Modulare Dekomposition Objektorientierte vs. Funktionsorientierte Zerlegung 2
Ziele der Veranstaltung (II) Einführung in die Objektorientierte Modellierung Klassen und Objekte Assoziation, Aggregation, Komposition, Vererbung Modellierung von Klassendiagrammen mit UML Empfehlungen beim Arbeiten mit UML Ermittlung von Klassen und Attributen Ermittlung von Assoziationen und Spezialisierungen 3
Entwurf Übersicht Entwurf basiert auf dem Pflichtenheft/Spezifikation und ist eine Arbeitsvorlage für den Entwicklungsprozess Entwurf berücksichtigt die technischen Gegebenheiten und beschreibt das grobe WIE Entwurf wird schon mit Blick auf die nachher bei der Implementierung verfügbaren Möglichkeiten durchgeführt werden Entwurf legt die Architektur, Komponenten, Schnittstellen und anderer Merkmale der Zielsoftware fest 4
Entwurf Ziele des Entwurfs Gliederung des Systems in überschaubare Einheiten Komplexität verringern Definition der Systemkomponenten Festlegung der Lösungsarchitektur Erarbeitung einer geeigneten Architektur Festlegung der Schnittstellen/Abhängigkeiten Hierarchische Gliederung Arbeitsteiliges Entwickeln vorbereiten 5
Ein guter Entwurf braucht Klare, strukturierte und iterative Vorgehensweise Wissen über die fachlichen Anforderungen Wissen über die Gegebenheiten (Technik, Menschen, Prozesse) Skills Fähigkeiten zur Abstraktion und Dekomposition Wissen über die Einsatztechnologie, min. Imperative Programmierung Beherrschen von Entwurfmustern (Patterns) Beherrschung von Notationen wie UML, ER, PAP, 6
Entwurf Systematische und iterative Vorgehensweise Bildung dynamischer und statischer Komponenten Festlegung der Hierarchie Und der Kommunikation/ Interaktion Zerlegung Revision Änderung Des Vorschlags Verfeinerung der Zerlegung Überprüfung Anhand von aktuellen Anforderungen 7
Bedienoberfläche Begrifflichkeiten im Entwurf Die Entwicklungsrichtung Aufgabe, Problem top-down outside-in bottom-up inside-out System-Software, -Hardware 8
Die Entwicklungsrichtung Top-down: vom Abstrakten zum Konkreten Bottom-up: vom Konkretem zum Abstrakten Outside-in: Modellierung der Umwelt > Modellierung der Systeminterna Inside-out: Modellierung der Systeminterna > Modellierung der Schnittstellen zur Umwelt 9
Die Entwicklungsrichtung Vor- und Nachteile Top-down + Konzentration auf das Wesentliche möglich + Strukturierte Zusammenhänge werden leichter erkannt - Es wird hohes Abstraktionsvermögen benötigt - Vage Entscheidungen werden an tiefere Ebenen weitergereicht Bottom-up + Es ist eine konkrete Ausgangsbasis vorhanden + Eine Begrenzung auf konkrete Teilgebiete ist möglich - Es muss eine breite Basis gelegt werden, um das Ziel sicher zu erreichen 10
Die Entwicklungsrichtung Vor- und Nachteile Outside-In + Konzentration auf die Umwelt + Beziehungen zur Außenwelt werden nicht übersehen - Die Außenwelt lenkt von internen Problem ab - Die Wiederverwendbarkeit wird erschwert Inside-out + Strukturierungen stehen im Mittelpunkt - Gefahr, dass Anforderungen der Umwelt übersehen oder zu spät erkannt werden 11
Begrifflichkeiten im Entwurf System und Systemelemente Ein System ist ein Ausschnitt aus der realen gedanklichen Welt, bestehend aus Systemkomponenten bzw.. Subsystemen, die untereinander in verschiedenen Beziehungen stehen Balzert, H. (2009) Systemteile bzw.. Bausteine, die nicht zerlegbar sind oder zerlegt werden sollten, werden als Systemelemente bezeichnet 12
Begrifflichkeiten im Entwurf Software-Architektur Softwarearchitektur wird als eigenständige Ebene betrachtet, die verschiedene Sichten auf ein Programmsystem beschreibt die äußere Ausgestaltung den inneren Aufbau Äußere Architektur Verbindung mit Komponenten des Basissystems Bindung an Bibliotheken und Rahmenwerke Innere Architektur Die statische Sicht als Zerlegung in Entwurfseinheiten Die dynamische Sicht als Interaktion von Komponenten 13
Software-Architektur Architektur hängt von Gegebenheiten ab Gibt es eine allgemeine Anwendungsarchitektur die als Schablone dienen kann? Welcher architektonischer Typ oder welche Typen sind für das System geeignet? Wie lautet der grundlegende Ansatz zur Strukturierung des Systems? Wie werden die strukturellen Einheiten im System in Module zerlegt? Wie soll die Systemarchitektur dokumentiert werden? und natürlich die Anforderungen an das System 14
Software-Architektur wird durch mehrere Modelle beschrieben (Auszug) Ein statisches Strukturmodell Ein dynamischen Prozessmodell Ein Schichtenmodell Diverse Beziehungsmodelle Ein Verteilungsmodell 15
Begrifflichkeiten im Entwurf Architekturmuster Dokumentation und Wiederverwendung von bewährten Mustern auf einer sehr hohen Abstraktionsebene Programmiersprachen- und Technologie-neutral Abhängig von den Gegebenheiten und vorhanden Werkzeugen Beispiele: Drei-Schichten-Architektur, Model-View-Controller- Architektur 16
Begrifflichkeiten im Entwurf Entwurfsmuster Lösungen für gängige Entwurfsprobleme Werden auf der Ebene des Feinentwurfs von Komponenten eingesetzt Unabhängig von einer Programmiersprache Meistens objektorientierte Konzepte als Grundlage Beispiel: Beobachter, Singleton (Implementierung später) 17
Prinzipien des Architekturentwurfs Prinzip der Abstraktion Abstraktion /Abstrahieren Verallgemeinerung und Loslösen vom Dinglichen Absehen vom Konkreten, Besonderen und Einzelnen Herausgeben des Wesentlichen aus dem Zufälligen Erkennen gleicher Merkmale Erstellen eines Modells der realen Welt Beispiel: Klaus Mustermann besitzt ein Giro-Konto 123456 und ein Sparbuch-Konto 45945 18
Prinzipien des Architekturentwurfs Prinzip der modularen Dekomposition Modulare Dekomposition beschreibt die Zerlegung des System in logische / physikalische Einzelteile (~7) Klassifikation in Funktionale Module Bsp.: Funktionsbibliotheken wie Math > math.pow() Datenobjektmodule Bsp.: Datenbanken Datentypmodule Bsp.: Datentypen wie Kunde, Artikel 19
Modulare Dekomposition Generelle Vor- und Nachteile Vorteile Kapselung des Subsystems (Sichtbarkeit) Keine Schwierigkeiten bei internen Änderungen Nachteile Erhöhte Rechenzeit Hohe Anforderungen an die Doku/ Konfiguration durch hohe Modularisierung 20
Modulare Dekomposition Objektorientierte Zerlegung Aufteilung des Systems in Module mit eigenem Zustand und Operationen System besteht aus lose gekoppelten Objekten mit genau definierten Schnittstellen Objekte repräsentieren real existierende Gegenstände Objekte benutzen die Dienste anderer Objekte 21
Modulare Dekomposition Funktionsorientierte Zerlegung Funktionale Transformationen von Daten: Eingangsdaten > Transformation > Ausgangsdaten Mehrere Funktionen/Prozesse verarbeiten sequentiell oder parallel Informationen 22
Modulare Dekomposition Vorteile Objektorientierte Zerlegung Teile und Herrsche -Prinzip Kapselung von Daten bzw.. Wissen Funktionsorientierte Zerlegung Intuitiv, da Reihenfolge von Verarbeitungen Transformationen können hinzugefügt bzw. entfernt werden 23
Modulare Dekomposition Nachteile Objektorientierte Zerlegung Funktionsorientierte Zerlegung Abstrakt, da keine Reihenfolge Anforderungen an die Schnittstellen (Doku) Verteilung des Objektwissens auf mehrere Funktionen Kann sehr unüberschaubar werden Überlappende Teilfunktionen 24
Prinzipien des Architekturentwurfs Kopplung Kopplung beschreibt die Abhängigkeit zwischen Modulen, z.b. durch Ablaufsteuerung oder gemeinsam benutzte Daten Ziel beim Entwurf: die Kopplung zwischen Modulen möglichst gering zu gestalten -> lose Kopplung Die Kopplung zwischen den Modulen soll über die parametrisierte Operation erfolgen zustandsändernde Prozeduren wertliefernde Operationen 25
Prinzipien des Architekturentwurfs Geheimnisprinzip - Information hiding Eine Technik zur Modularisierung von Software-Systemen Verfolgt den Need-to-know-Prinzip, Informationen, die nicht verwendet werden dürfen, werden nicht zugänglich gemacht Zugriff auf die Informationen über Operationen Das Modul entscheidet selbst wer auf seine Attribute lesend und schreibend zugreifen darf wie lesend und schreibend zugegriffen werden darf. 26
Information Hiding Beispiel: Klasse Konto in Java class Konto { private int kontonr; private double kontostand; public Konto(int nr) { kontonr = nr; } public void abheben(double betrag) {... } } public double kontostandabfragen() {... } 27
Prinzipien des Architekturentwurfs Trennung von Zuständigkeiten Konzentration von Komponenten auf bestimmte Aufgabenbereiche Ziel: keine Komponenten, die in mehreren Bereichen agieren Kriterien zur Trennung bzw. Zusammenlegung von Modulen Zusammengehörende Daten und Operationen (Klassen) Funktionale Aspekte (Features) Trennung von Funktionalität und Interaktionen (MVC) 28
Prinzipien des Architekturentwurfs Trennung von Funktion und Interaktion GUI-intensiven Programmteile können Interaktions- und funktionalen Anweisungen beinhalten Schlechte Lesbarkeit des Programmcodes Sehr hoher Wartungsaufwand bei kleinen Änderungen Keine direkte Wiederverwendung von Geschäftslogiken in anderen Darstellungskonzepten Ziel: Trennung der Darstellung inkl. der Interaktion von der Anwendungs-/Geschäftslogik Werkzeug: Model-View-Controller-Pattern 29
Entwurf Wo fange ich an? 30
31
Was ist Objektorientierung? Objektorientierung ist ein Paradigma, eine Sichtweise auf komplexe Systeme (nicht neu, seit 60er Jahren) Ziel: Verringerung der Komplexität, bessere Handhabung folgende Merkmale aufweist Unterstützung von Vererbungsmechanismen Unterstützung von Datenkapselung Unterstützung von Polymorphie Objektorientierten Sprachen (Auszug): Java, C#, Smalltalk 32
Objektorientierung Vorteile Realitätsnahe Modellierung und Modellbasierte Entwicklung Konzepte und Notation der Analyse gelten auch in Entwurf und Implementierung Kapsellung des Wissens in der Klassen bzw. im Objekt Steigerung der Wartbarkeit und Wiederverwendbarkeit des Codes 33
Objektorientierung Nachteile Die Nachteile sind vorhanden, spielen aber heute keine bedeutende Rollen mehr Großer Speicherbedarf und Verarbeitungsaufwand Speicherverwaltung erforderlich (dynamische Bindung) Anwendung / Portierung des Paradigma auf andere Problembereiche 34
Elemente objektorientierter Architektur Übersicht Statik Klasse und Objekt Beziehungen zwischen Klassen bzw. Objekten Merkmale Verhalten Zustand Lebenszyklus 35
Elemente objektorientierter Architektur Klassen Eine Klasse = eine abstrakte Beschreibung bzw. Schablone von Gegenständen und Sachverhalten Klassen sind Baupläne für Objekte / reale Gegenstände Klassen definieren Eigenschaften und Methoden von Objekten Zu einer Klasse können beliebig viele Objekte erzeugt werden 36
Elemente objektorientierter Architektur Objekte Ein Objekt ist eine konkrete Ausprägung einer Klasse (Instanz der Klasse), ein Objekt wird instanziiert Objekte enthalten Eigenschaften und Methoden von Klassen Ein Objekt besitzt eine Identität! Ein Objekt besitzt Zustände und einen Lebenszyklus Beispiel: Bauplan > Haus (hier kann man wohnen) 37
Elemente objektorientierter Architektur Zustände und Verhalten Der Zustände eines Objekt wird über die Attribute ausgedrückt Das Verhalten eines Objekts wird über seine Operationen beschrieben 38
Fragen bei der objektorientierten Modellierung Welche Objekte benötigen wir? Welche Merkmale besitzen diese Objekte? Wie lassen sich diese Objekte klassifizieren? Welche Assoziationen bestehen zwischen den Klassen? Wie wirken die Objekte global zusammen? In welchen Zuständen befinden sich die Objekte? 39
Unified Modeling Language (UML) hilft beim Beantworten der Fragen Standard der Object Management Group UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen Konzipiert für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung 40
UML Ein Produkt der Evolution M. Jeckle: UML 2.0. Modellierung 2004, Marburg 41
Objektorientierte Modellierung mit UML Diagrammtypen (Auszug) Anforderungen an das System Use-Case-Diagramm Logischer Aufbau des Systems (Statische Sicht) Klassendiagramm Kollaborationsdiagramm Interaktionen und Abläufe (Dynamische Sicht) Aktivitätsdiagramm Sequenzdiagramm Zustandsdiagramm 42
Objektorientierte Modellierung mit UML Werkzeugunterstützung http://www.jeckle.de/umltools.html 43
Klassendiagramm Übersicht Grafische Darstellung / Modellierung von Klassen, Schnittstellen und deren Beziehungen Zusammenstellung deklarativ-statischer Modellelemente (Klassen, Typen, ihre Inhalte und Beziehungen) Zwei wesentliche Elemente: Klasse und Objekt Ersetzt oftmals das klassische Datenmodell (Entity Relationship) 44
Klassendiagramm Aufbau Klassenname Attribute/ Eigenschaften Parameter Operationen/ Methoden Rückgabewert 45
Klassendiagramm Aufbau Rolle bzw. Eigenschaft Beziehungsname Operationen-Bereich Multiziplität Attributen-Bereich 46
Klassendiagramm Beispiel 47
Aufbau Klassendiagramm Sichtbarkeit von Attributen und Operationen Der Sichtbarkeitsbereich für Attribute und Dienste + public sichtbar für alle Systemteilnehmer - private sichtbar nur innerhalb der Klasse # protected sichtbar nur innerhalb der Klasse und für alle Unterklassen ~ package sichtbar nur innerhalb des Packet. Grundsätzlich sollten Variablen immer auf private gesetzt werden > Zugriff soll über Methoden erfolgen 48
Konkrete Implementierung Beispiel: Klasse Konto in Java class Konto { private int kontonr; private double kontostand; public Konto(int nr) { kontonr = nr; } public void abheben(double betrag) {... } } public double kontostandabfragen() {... } 49
Konkrete Implementierung Beispiel: Instanziieren der Objekte in Java public static void main(string[] args) { Konto konto1 = new Konto(123456); konto1.abheben(1000.0); } Konto konto2 = new Konto(234567); konto2.abheben(2000.0); 50
Beziehungen Assoziation Assoziation = semantische Beziehung zweier Klassen Zwei Klassen/Objekte sind assoziiert, wenn das eine Methoden von dem anderen aufruft. Eine Klasse/Objekt nutzt die Dienste einer anderen Klasse/Objekt Beziehung von zwei unabhängigen Objekten, um ein gemeinsames Ziel zu erreichen Objekte bestehen weiterhin unabhängig voneinander fort auch nach dem Erreichen des Ziels Beschreibbar über: "benutzt ein/e", "ist zugeordnet zu" und "hat eine Beziehung zu 51
Assoziationen Beispiel: Eine Person benutzt ein Computer Assoziationsname Assoziation 52
Assoziationen Beispiel: Kunde und Auto stehen im Mietverhältnis 53
Assoziationen Navigierbarkeit Assoziationen können nicht gerichtet und gerichtet sein Keine Aussage zur Navigierbarkeit zwischen der Klasse Person und Konto Person Konto Navigieren von Person nach Konto verboten Person Konto Navigieren von Person nach Konto erlaubt Person Konto In der Praxis wird typischerweise unidirektionale Navigierbarkeit unterstützt 54
Assoziationen Multiplizität Ausdruck wie viele Objekte ein Objekt halten kann Intervall von nicht-negativen, ganzen Zahlen Untergrenze >= anzahl <= Obergrenze * ^= unendlich Multiplizität 55
Assoziationen Mini-Übung 56
Beziehungen Vererbung, Generalisierung und Spezialisierung Modellierung der realen Welt in ihren Strukturen Vorteile Hierarchische Begriffsklassifizierung Wiederverwendung von bereits vorhandenem Wissen Wiederverwendung von existierendem Code Einfachere Wartung Beschreibbar über: "ist ein/e" 57
Vererbung Beispiel Kraftfahrzeug PKW Van LKW Coupé Cabrio Kombi 58
Vererbung Generalisierung und Spezialisierung Basisklasse Superklasse Person erbt von = Spezialisierung Kunde Mitarbeiter Diskriminator Vertragsverhältnis Privat Kunde Praktikant Angestellter Subklasse Leitender Angestellter 59
Vererbung Weitere Beispiele 60
Vererbung Weitere Beispiele 61
Vererbung Beispiel: Java-Programm ohne Vererbung class Angestellter { private String name; private double gehalt; private Date geburtsdatum; } public String liefereangaben() {... } class Abteilungsleiter { private String name; private double gehalt; private Date geburtsdatum; private String abteilung; public String liefereangaben() {... } public void befördern(angestellter a){... }; } 62
Vererbung Beispiel: Java-Programm mit Vererbung 63
Vererbung Beispiel: Java-Programm mit Vererbung class Angestellter { private String name; private double gehalt; private Date geburtsdatum; public String liefereangaben() {... } } class Abteilungsleiter extends Angestellter { } private String abteilung; public void befördern { }... (Angestellter a) 64
Beziehungen Aggregation Aggregation beschriebt eine Abhängigkeit Physische Aggregation: Das Analyseobjekt besteht aus Teilen. Der Motor ist Teil eines Autos (Komposition) Logische Aggregation: Begriffliche Objekte werden als ein Teil angesehen. Die Adresse gehört zu einer Person. 65
Aggregation Beispiel: Der Motor ist Teil eines Autos 66
Aggregation Beispiel Ein Bus befördert Fahrgäste 67
Beziehungen Komposition Eine Komposition stellt eine strengere Beziehung als eine Assoziation dar Bei einer Komposition enthält ein Ganzes-Objekt ein Teil-Objekt. Bei einer Komposition enthält ein Objekt ein anderes. Für das enthaltene Objekt macht eine selbständige Existenz keinen Sinn. Beschreibbar über: "hat ein/e" bzw. "besteht aus" Beispiel: Ein Beispiel für eine Komposition wäre ein Bleistift und seine Mine 68
Komposition Beispiele 69
Aggregation und Komposition Mini-Übung 70
Modellierung von Klassendiagrammen Methodik Finde Klassen Identifiziere Klassen über die Substantivmethode Identifiziere Substantive Identifiziere Synonyme, Akronyme und Fachbegriffe Identifiziere Homonyme Kategorisiere und filtriere die Substantive Wähle aussagefähige und verbindliche Klassennamen Dokumentiere jede Klasse in einem Satz 71
Modellierung von Klassendiagrammen Methodik Finde Attribute Identifiziere Attribute im Anschluss an die Substantivmethode Fasse Adjektive zu Attributen zusammen Überprüfe den Attributnamen (Substantiv, konkret, kein Homonym) Definiere den Typ der Attribute (int, double, Konto,..) Überprüfe die Attribute auf fachliche bzw. technische Lücken Füge Informationen hinzu, die vom System ermittelt werden können Füge Informationen hinzu, die für spätere Verarbeitung verwendet werden können 72
Modellierung von Klassendiagrammen Methodik Finde Assoziationen Identifiziere mögliche Assoziationen zwischen Objekten (Verben und prozessbeschreibende Substantive) Ermittle die Abhängigkeit zwischen den Klassen nur Assoziation? Aggregation? Komposition? Bestimme die Kardinalität jeder Rolle jeder Assoziation Muss-Beziehung -> 1.. Kann-Beziehung -> 0... Ober/Untergrenzen -> n...m 73
Literaturquellen Ludewig, J., Lichter, H.: Software Engineering. Grundlagen, Menschen, Prozesse, Techniken Balzert, H.: Lehrbuch der Software-Technik: Basiskonzepte und requirements engineering Pomberger, G., Blasckek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung Sommerville, I.: Software Engineering 74
Übung 75