Softwaretechnik SS 2006

Softwaretechnik SS 2006 6. Vorlesungseinheit Prof. Dr. Urs Andelfinger Darmstadt, 15. Mai 2006 Softwaretechnik (SWT) Vorlesung und Praktikum SS 2006 Inhaltsübersicht SW-Management SW-Entwicklung SW-Qualitätsmgmt. Vorgehensmodelle (insbes. RUP) Best-Practices Projektmanagement (?) OO-Grundbegriffe (UML) (Geschäftsprozeßmodellierung) Analyse / OOA Entwurf / OOD Entwurfsmuster Implementierung QM-Grundlagen Produktqualität (Testen, Reviews) Prozeßqualität (CMMI, ISO) Exemplarische Umsetzung ausgewählter Aspekte im Praktikum 2006 Prof. Dr. Urs Andelfinger. All rights reserved. 2 SWT-Vorlesung SS 2006 - VE 6-15.05.2006

Softwaretechnik (SWT) Vorlesung und Praktikum SS 2006 Lernziele der 6. Vorlesungseinheit Die Zielsetzung von OOA kennen und verstehen Die Zielsetzung von OOD kennen und verstehen Wichtige Unterschiede zwischen OOA und OOD kennen und verstehen Die wichtigsten Schritte auf dem Weg vom Klassendiagramm-Analysesicht über das Klassendiagramm-Designsicht bis hin zum Quellcode kennen ( Forward-Engineering ) 2006 Prof. Dr. Urs Andelfinger. All rights reserved. 3 SWT-Vorlesung SS 2006 - VE 6-15.05.2006

1 Von der OO-Analyse zur fertig eingeführten Software Quellenhinweis: Diese Präsentation enthält teilweise Inhalte und Grafiken des Lehrbuchs der Software-Technik (Band 1), 2. Auflage von H. Balzert, Spektrum Akademischer Verlag, Heidelberg 2001 2 Gliederungsübersicht Von der OOA zum OOD Vorgehensweise zur OO-Implementierung Abnahme und Einführung Wartung und Pflege

3 OOD-Konzepte und -Muster Zur Historie Grady Booch 27.2.1955 in Texas Chief Scientist Rational Software Corporation Pionier auf dem Gebiet des modularen und objektorientierten Softwareentwurfs 1983: Buch Software Engineering with Ada 1987: Buch Software Components with Ada 1991/94: Buch Object Oriented Design with Applications Pionier wiederverwendbarer Bibliotheken 1987: Komponentenbibliothek in Ada 1991: Klassenbibliothek in C++ 4 Ziel der OOA objektorientierte Analyse Produkt-Definition erstellen, die das Fachkonzept der gewünschten Anwendung in Struktur und Semantik aus Anwendersicht vollständig, konsistent und eindeutig beschreibt Für ein OOA-Modell bedeutet dies: Es beschreibt die fachliche Lösung, nicht die technische Lösung Es enthält keine Optimierungen Es enthält keine Objektverwaltung Alle Assoziationen, Aggregationen und Kompositionen sind in der Regel bidirektional.

5 Ziel des OOD objektorientierter Entwurf Softwaretechnischen Produkt-Entwurf erstellen, der die funktionalen und nichtfunktionalen Produktanforderungen sowie allgemeine und produktspezifische Qualitätsanforderungen erfüllt und die Schnittstellen zur Umgebung versorgt Einbettung des Produktentwurfs in die Anwendungs- und Plattformumgebung Kein Strukturbruch Da sowohl in OOA als auch in OOD die objektorientierten Konzepte verwendet werden, gibt es keinen»strukturbruch«von OOA nach OOD. 6 Vom Fachkonzept zur fertigen Anwendung Def inition Soft ware- Produkt modell Entwurf Soft ware- Archit ektur Dienstleist ungen Netzvert eilung Imp lementierung GUI Hilfe Anwendung Datenhalt ung Ex pertensystem Soft ware- Produkt Syst emsoft ware Software-Produkt = Im plem entierung des Fachkonzepts + Im plem entierung zusätzlicher Dienstleistungen + Anbindung vorhandener»hilfssystem e«+ Einbindung in die System um gebung

7 OOD-Konzepte Grundlage für den objektorientierten Entwurf In der Regel das OOA-Modell Das entstehende OOD-Modell wiederum bildet die Grundlage für die Implementierung Die Implementierung erfolgt in einer oder mehreren konkreten Programmiersprachen Bezeichner-Syntax Alle Namen des OOD-Modells müssen der Syntax der Ziel-Programmiersprache entsprechen Bezeichnungen aus dem OOA-Modell, die dieser Syntax nicht entsprechen, müssen daher manuell oder automatisch umgewandelt werden. 8 Vorgehensweise zur OO-Implementierung 1 Modifikation der Klassenstruktur Objektverwaltung durch Container-Klassen Analyseklassen 1:1 in die Implementierung Funktionale Komplexität einer Klasse zu hoch Teilaufgaben an detailliertere Klassen delegieren Erreichen der Performance Klassen mit starker Interaktion d.h. mit einer hohen Kopplung zusammenfassen. Hinzufügen weiterer Klassen Z.B. um Zwischenergebnisse zu modellieren, d.h. mehrere abgeleitete Attribute in einer neuen Klasse zu»bündeln«. Assoziative Klassen in»normale«klassen auflösen

9 Objekt / Klasse Container-Klasse Verwaltet Menge von Objekten einer Klasse Stellt Operationen bereit, um auf die verwalteten Objekte zuzugreifen Ein Objekt der Container-Klasse wird als Container bezeichnet Typische Container: Felder (arrays) und Mengen (sets) Namenskonvention Plural des Klassennamen, u.u. gefolgt von dem Namen Container bestehen Fachkonzept-Klasse Kunde Zugehörige Container-Klasse Kunden oder KundenContainer. 10 Objekt / Klasse Container für die Verwaltung von Dozenten Dozent Dozent encont ainer Name Biografie OOA OOD erstelleliste() er stelleliste() 1 :Dozent :Dozent :Doz entencontainer Name Biogr afie Doz ent

11 Vorgehensweise zur OO-Implementierung 2 Verfeinern der Attribute Für»abgeleitet«Attribute prüfen, ob die Werte zu speichern sind oder ob sie jeweils aktuell berechnet werden sollen Handelt es sich um viele Attribute, so ist es sinnvoll, eine neue Klasse dafür in das Modell einzufügen. 12 Attribut Sichtbarkeit (visibility) in OOD public: sichtbar für alle anderen Klassen protected: sichtbar innerhalb der Klasse und in deren Unterklassen private: sichtbar nur innerhalb der Klasse friendly: sichtbar nur innerhalb des jeweiligen Paketes (nur in Java) Class + publicatt ribute # protectedattribute privateatt ribute friendlyattribut e

13 Vorgehensweise zur OO-Implementierung 3 Verfeinern der Operationen Spezifizierte Operationen sind aus Entwurfssicht detaillierter zu beschreiben Komplexe Operationen sind in Teiloperationen zu gliedern Besitzt die Klasse einen Lebenszyklus, so ist eine auszuführende Operation von dem jeweiligen Objektzustand abhängig Dann muss der Algorithmus entsprechende Abfragen enthalten oder es ist das Zustandsmuster anzuwenden. 14 Operation Sichtbarkeiten (analog wie Attribute) Private Operation (private): Kann nur von Operationen derselben Klasse aus aufgerufen werden Für alle anderen Klassen bzw. deren Objekte unsichtbar Geschützte Operation (protected) Kann von Operationen der eigenen Klasse und ihren Unterklassen aus aufgerufen werden Öffentliche Operation (public) Class + publicoperation() # protectedoperation() privat eoperation() friendlyoperation() Kann von Operationen aller Klassen bzw. deren Objekten aufgerufen werden

15 Operationen in C++ Konstruktoren und Destruktoren Konstruktoren sind eine elegante Möglichkeit, Objekte zu initialisieren Fehlt der Konstruktor, dann ruft C++ einen impliziten Konstruktor auf Variablen können in C++ auch direkt bei der Deklaration initialisiert werden Eine Klasse kann mehrere Konstruktoren mit unterschiedlichen Parametern enthalten (overloading) Pro Klasse gibt es immer nur einen Destruktor Explizite Freigabe von Speicherplatz 16 Vorgehensweise zur OO-Implementierung 4 Verfeinern von Assoziationen Prüfen, ob eine Navigationsrichtung ausreicht Richtung im Klassendiagramm durch einen Pfeil kennzeichnen Assoziationen unter dem Gesichtspunkt des optimalen Zugriffs auf Objekte modellieren Für jede Operation prüfen, welche Assoziationen sie»durchlaufen«muss, um an die benötigten Informationen zu gelangen Beispiel Assoziation zwischen Klassen A & B wird nur von A nach B als Zeiger in A implementiert Bei einem Zugriff in der Gegenrichtung müssen alle Objekte von A betrachtet und gefiltert werden.

17 Assoziation Navigation Im Entwurf wird festgelegt, ob Assoziationen unioder bidirektional implementiert werden Man spricht von der Navigation der Assoziation ReifenTyp Typnam e Höh en klasse 1 OOA Reifen Barcodenummer Einlagerdatum OOD ReifenTyp 1 Reifen - Typname - Höhenklasse - Barcodenum mer - Einlagerdatum 18 Assoziation Realisierung mittels Zeigern Jede Richtung einer Assoziation kann mittels Zeigern zwischen Objekten realisiert werden Dann kennt jedes Objekt seine assoziierten Objekte Durch die Operationen muss sichergestellt werden, dass alle Verbindungen konsistent auf- und abgebaut werden Eine Kardinalität von 0..1 oder 1 wird dabei durch einen einzelnen Zeiger realisiert Liegt eine Kardinalität größer 1 vor, dann muss eine Menge von Zeigern gespeichert werden Wenn keine Ordnung der Assoziation definiert ist, dann können Container-Klassen wie Set, Bag etc. verwendet werden.

19 Assoziation Beispiel Realisierung einer bidirektionalen Assoziation mittels Zeigern Reif entyp 1 Reifen :Reifentyp :Reif en :Reifentyp :Reif en :Reifentyp :Reif en 20 Assoziative Klassen Für die Implementierung sind assoziative Klassen aufzulösen A 0..1 B A B 1 1 C C 0..1 A B A B 1 1 C C

Literaturhinweise zur 6. Vorlesungseinheit Helmut Balzert: Lehrbuch der Software-Technik Bd. 1, Spektrum Verlag, Heidelberg 2001, LE 27, 33, 34 2006 Prof. Dr. Urs Andelfinger. All rights reserved. 4 SWT-Vorlesung SS 2006 - VE 6-15.05.2006 Fragen? 2006 Prof. Dr. Urs Andelfinger. All rights reserved. 5 SWT-Vorlesung SS 2006 - VE 6-15.05.2006