Softwaretechnik (Allgemeine Informatik) Überblick

Transkript

1 Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6 Objektorientiertes Design 7 Test 8 Dokumentation und Wartung 9 Projektmanagement und -organisation Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 62 Softwaretechnik (Allgemeine Informatik) Überblick: 3.1 Eigenschaften 3.3 Agile Softwareentwicklung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 63

2 3.1 Eigenschaften Anwendungsfallgetrieben Architektur- und komponentenzentriert Iterativ Inkrementell Anwendungsfallgetrieben Funktionale Anforderungen an das zu entwickelnde System werden in Anwendungsfälle zerlegen Aus Sicht der Anwender Bilden Grundlage und Checks für alle weiteren Schritte Anwendungsfälle können priorisiert werden bzgl. der Reihenfolge der Umsetzung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) Eigenschaften Architekturzentriert Eigenschaften und Besonderheiten einer vorhandenen Anwendungsarchitektur müssen berücksichtigt werden Die Anwendungsarchitektur bestimmt, welche Artefakte überhaupt zu entwickeln sind Beispiel einer Anwendungsarchitektur ist die Verwendung eines Anwendungs-Frameworks z.b. Document-View Systeme können in Komponenten und Subsysteme gegliedert sein. Auch das ist zu berücksichtigen Die Vorgehensweise sollte also die Erarbeitung der durch die Architektur vorgegebenen Artefakte optimal unterstützen Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 65

3 3.1 Eigenschaften Iterativ und inkrementell Entwicklung innerhalb bestimmter Phasen in mehreren nach- und ggf. auch nebeneinander ablaufenden Iterationen Anders als bei dem klassischen Wasserfallmodell Zunächst Anwendungsfälle: Grobe Anforderungsbeschreibung. Dann ggf. Bildung von Subsystemen Subsysteme können von separaten Teams realisiert werden Teilergebnisse der Teams müssen regelmäßig synchronisiert werden Zwischenergebnisse werden in Reviews validiert und verifiziert Jedes Team legt zu festgelegten Zeiten Ergebnisse vor: Gliederung des Entwicklungsprozesses jedes Teams in Iterationen Jede Iteration liefert ein Teilergebnis Inkrementell: Gesamtfunktionalität wächst mit jedem Schritt Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 66 Softwaretechnik (Allgemeine Informatik) Überblick: 3.1 Eigenschaften 3.3 Agile Softwareentwicklung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 67

4 Überblick UML enthält keine Prozessbeschreibung, die wichtigen Teil einer Methode ausmacht UML ist unabhängig von dem verwendeten Prozess Lösung der 3 Amigos: Unified Process (UP) Eher ein Prozessrahmenwerk (Process Framework) mit Spielräumen zur Anpassung Produkt Rational Unified Process (RUP) von Rational Iterativer und inkrementeller Entwicklungsprozess Software wird in Teilen entwickelt und freigegeben Insbesondere die Konstruktionsphase besteht aus vielen Iterationen, wobei bei jeder Iteration real nutzbare Software erstellt, getestet und integriert wird (Teilmenge der Anforderungen des Projektes) Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 68 Überblick Entwicklungszyklus Iteration Phase Einstieg (Inception) Ausarbeitung (Elaboration) Konstruktion (Construction) Überleitung (Transition) Jede Iteration der Konstruktion Analyse, Entwurf, Implementierung und Test Meilenstein (milestone) Ende einer Phase oder Iteration; signifikante Entscheidung oder Evaluation Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 69

5 Überblick (fortgesetzt) Entwicklungszyklus Iteration Phase Einstieg (Inception) Ausarbeitung (Elaboration) Konstruktion (Construction) Überleitung (Transition) Release Stabiler Teil des endgültigen Produktes; Teilfunktionalität Increment Differenz (delta) zwischen den Releases zweier aufeinander folgender Iterationen Final Production Release Am Ende der Überleitung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 70 Zwei Vorphasen 1. Einstieg (Inception) Begründung der geschäftlichen Absichten des Projektes (Kosten/Nutzen) Anwendungsdomäne kennen lernen Abgrenzung O.K. des Managements weiterzumachen Machbarkeitsstudie Etwa Systemidee und Zielsetzung entwickeln nach Oestereich. Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 71

6 Zwei Vorphasen 2. Ausarbeitung (Elaboration) Sammeln detaillierter Anforderungen Analyse und Entwurf auf hohem Abstraktionsgrad: Grundlegende Architektur, Plan für die Konstruktion Welche Technologien sollen eingesetzt werden? Welche Risiken sind vorhanden? Mehrere Iterationen möglich Vorgehensweise: Anwendungsfälle entdecken Gerüst eines konzeptionellen Modells des Problembereichs: Grundlage für Klassenmodell Problembereichsmodell Entwurfsmodell: Klassen zur Übernahme der Aufgaben (Fachklassen). Wiederverwendbare Architektur für künftige Erweiterungen. Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 72 Zwei Vorphasen (fortgesetzt) 2. Ausarbeitung (Elaboration) (fortgesetzt) Nicht alle Anwendungsfälle auf einmal Zunächst nur zentrale Anwendungsfälle und zentrale Klassen des Problembereichs Weitere Anwendungsfälle können inkrementell hinzugefügt werden Wichtige UML-Techniken neben Anwendungsfällen hierbei (Problembereichsmodell): Klassendiagramme, Aktivitätsdiagramme (Arbeitsabläufe, workflows), Ggf. Interaktionsdiagramme (später nützlicher) Etwa die weiteren Unterkapitel aus Analyse bei Oestereich Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 73

7 Eine nachgeschaltete Phase Überleitung (Transition) Betatests, Performance-Verbesserungen, Benutzertraining Im Prinzip Iterationen auch in den anderen Phasen (neben Konstruktion). Entwicklungszyklus Iteration Phase Einstieg (Inception) Ausarbeitung (Elaboration) Konstruktion (Construction) Überleitung (Transition) Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 74 Konstruktion Entwicklungszyklus Iteration Phase Einstieg (Inception) Ausarbeitung (Elaboration) Konstruktion (Construction) Überleitung (Transition) Erstellung des Systems in einer Folge von Iterationen Jeweils ein eigenes Miniprojekt Analyse, Entwurf, Programmierung, Test und Integration für jeden Anwendungsfall, der der Iteration zugewiesen ist Ziel: Risikoverminderung Ständiges Testen und Integrieren 2-6 Wochen Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 75

8 Konstruktion (fortgesetzt) Vorgang ist sowohl inkrementell als auch iterativ: Inkrementell bezüglich Funktionalität. Jede Iteration baut auf Anwendungsfällen der vorigen Iteration auf und fügt weitere Funktionalität hinzu z.b. einen weiteren Anwendungsfall Iterativ bezüglich der Codebasis Jede Iteration wird/kann ein Umschreiben eines Teils des existierenden Codes zur Folge haben (Umstrukturierung, refactoring) Ziel: Reduktion der Softwareentropie Refactoring: Gleiche Funktionalität bei geänderter innerer Struktur Umbenennung einer Methode, Verschieben von Attributen in andere Klasse, Zusammenführung gleichartiger Methoden zweier Klassen in Superklasse, Änderung eines internen Algorithmus Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 76 Konstruktion (fortgesetzt) Alle UML-Techniken sind in der Konstruktion wichtig und nützlich: Analyse: Anwendungsfälle (auch Abgrenzung des Arbeitsgebietes) Konzeptionelles Klassenmodell (Vorbereitung einiger Konzepte für den Anwendungsfall) Aktivitätsdiagramm, falls Anwendungsfall bedeutende Arbeitsablaufelemente enthält Dies zusammen mit Experten der Anwendungsdomäne. Übergang zum Entwurf: Detaillierte Ausarbeitung der Klassendiagramme Interaktionsdiagramme (Sequenz- und Kommunikationsdiagramme) zum Zusammenspiel der Klassen zur Implementierung des Anwendungsfalls Klassenkarten (CRC cards): Verantwortlichkeiten der Klassen Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 77

9 Konstruktion (fortgesetzt) Nicht unbedingt detaillierte Diagramme für das ganze Systems. Nur dort, wo es auch etwas bringt Weiterhin: Paketdiagramme als logischer Plan des Systems Für jedes Paket ein spezifikationsorientiertes Klassendiagramm (Assoziationen, nur wichtige Attribute und Methoden) -> Graphisches Inhaltsverzeichnis Zustandsdiagramme, falls Klasse komplexes Verhalten während ihres Lebenszyklus hat. Selten notwendig Eher Interaktionsdiagramme Einsatz von Entwurfsmustern (Design Patterns) Martin Fowler, Kendall Scott: Iterative Entwicklung nur für Projekte einsetzen, von denen man will, dass sie erfolgreich ablaufen Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 78 Software-Entropie Je sorgfältiger ein System zu Anfang geplant, designed und implementiert wurde, um so länger kann es unter ständiger Pflege leben Physik (2 Hauptsatz der Thermodynamik): Die Entropie (Unordnung) eines abgeschlossenen Systems kann nie geringer werden, sondern bleibt bestenfalls konstant, hat aber normalerweise das Bestreben, zuzunehmen Umgesetzt auf die Softwareentwicklung: Ein Programm, das benutzt wird, wird auch verändert Wird ein Programm verändert, so nimmt seine Komplexität zu, falls man nicht aktiv dagegen ankämpft Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 79

10 Software-Entropie (fortgesetzt) Nimmt man an, dass die Software-Entropie um so schneller zunimmt, je größer sie zu Anfang war, so findet man das folgende Bild: System 1 System 2 Grenze der Wartbarkeit Software-Entropie Zeit Lebenszeit System 1 Lebenszeit System 2 Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 80 Nochmals: Objektorientierte Analyse Ziel, wie bei allen Analysemethoden: Verständnis der geforderten Anwendung, nur aufgrund der funktionalen Anforderungen Unterschied zwischen objektorientierter Analyse und anderer funktionsoder datenorientierter Analysemethoden: Verhalten der Anwendung und Daten der Anwendung werden nicht separat betrachtet Stattdessen werden sie in Klassen/Objekten integriert Bei der Analyse iteriert man ständig zwischen dem Verhalten und den Infomationsstrukturen der Anwendung hin und her Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 81

11 Objektorientierte Analyse Geschäfts- oder Fachklassenmodellierung Arbeitsschritte in irgendeiner Reihenfolge: Finde die Objekte Aus der Anwendungsdomäne Substantive in der Beschreibung Essentielle Objekte, die während des gesamten Lebenszyklus essentiell bleiben Evtl. mehrere Objekttypen, z.b. aktiv/passiv Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 82 Objektorientierte Analyse (fortgesetzt) Organisiere die Objekte Objekte und Klassen von Objekten, Ähnlichkeiten, Vererbungshierarchien, abstrakte Klassen Andere Objektbeziehungen: Welches Objekt arbeitet für ein anderes? Ist ein Objekt ein Teil eines anderen Objekts? Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 83

12 Objektorientierte Analyse (fortgesetzt) Organisiere die Objekte... Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 84 Objektorientierte Analyse (fortgesetzt) Beschreibe, wie Objekte wechselwirken Szenarien der Nutzung der Anwendung Z.B: in Form von Use Cases oder Interaktionsdiagrammen Dadurch Beschreibung der Objektumgebung Was erwarten andere Objekte von diesem Objekt Resultat: Schnittstellen des Objekts Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 85

13 Objektorientierte Analyse (fortgesetzt) Definiere die Operationen der Objekte Natürliches Ergebnis, wenn man die Schnittstellen von Objekten definiert Oder von der Anwendung: Was kann mit den Dingen, die wir modellieren, getan werden? Primitiv (add/delete) oder komplex (Zusammenstellung eines Reports über mehrere Objekte) sehr komplexe Operationen neues Objekt Definiere die Objekte intern Welche Informationen muss das Objekt enthalten Müssen die Informationen den Programmablauf überdauern (persistente Objekte/Informationen) Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 86 Objektorientierte Analyse (fortgesetzt) All dies beschäftigt sich zunächst nur mit der Anwendungsdomäne! Daraus resultierende Objektmodelle haben sich als zeitlich sehr stabil herausgestellt Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 87

14 Softwaretechnik (Allgemeine Informatik) Überblick: 3.1 Eigenschaften 3.3 Agile Softwareentwicklung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) Agile Softwareentwicklung Agile Software Development 2001 von der Agile Alliance vorgeschlagen Non-Profit Organisation 2003: Manifesto of Agile Alliance: 4 Empfehlungen Individuen und Interaktion über Prozesse und Werkzeuge Funktionierende Software über ausführliche Dokumentation Zusammenarbeit mit dem Auftraggeber über Vertrags- Verhandlungen Auf Änderungen reagieren über genau einem Plan folgen Software-Entwicklung ist kreative Tätigkeit mehr abhängig von Menschen und Team-Zusammenarbeit als von Prozessen, Werkzeugen, Dokumentation, Planung und anderen Formalitäten Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 89

15 3.3 Agile Softwareentwicklung Agile Software Development Auftraggeber und Entwickler arbeiten während des ganzen Softwareentwicklungs-Prozesses eng zusammen Ständiges Feedback der Auftraggeber Weniger formale Verträge Weniger Dokumentation (!?) Klingt sehr revolutionär In der Praxis werden jedoch, wenn auch unter anderen Namen, bekannte Phasen und Methoden verwendet Analyse, Design, Implementierung, Test, Einführung Analyse ersetzt durch User Stories Features, die die Anwender sehen möchten werden einzeln von dem Entwicklungsteam realisiert Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) Agile Softwareentwicklung Agile Software Development Design, Implementierung und Test ersetzt durch Kombination von Akzeptanz Tests Refactoring Test-driven Development Entwickler programmiert seine Vorstellungen in Form eines Akzeptanz Tests Weitere Praktiken Pair Programming Zwei Programmierer arbeiten zusammen an einem Arbeitsplatz Einer schreibt den Code Der andere beobachtet und stellt Fragen Die Rollen wechseln häufig Die Paare wechseln wenigstens einmal pro Tag Collective Ownership der Software Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 91

16 3.3 Agile Softwareentwicklung Agile Software Development Integration und Einführung ersetzt durch ständige Integration und kurze Entwicklungszyklen sorgfältige Planung dieser Zeitpunkte (z.b. alle 2 Wochen) Jedes Zwischenergebnis wird an Auftraggeber ausgeliefert Alle 6 * 2 Wochen ein major release Entspricht in der Praxis durchaus der iterativen, inkrementellen Vorgehensweise Prominenter Befürworter: Ken Beck: extreme Programming (XP), 1999 Gefahr: Build-and-Fix Model Einfach hack-kodieren, ohne dokumentierte Analyse und Design Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 92 Softwaretechnik (Allgemeine Informatik) Überblick: 3.1 Eigenschaften 3.3 Agile Softwareentwicklung Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 93

17 Bestandteil der iterativen und agilen XP-Methode Schreiben Sie den Test zuerst! Zuerst Testcode schreiben Erst dann die Klasse, die getestet werden soll Ergebnis: Entwickler schreibt Unit Testing Code für fast den gesamten Produktionscode Rhythmus: Ein wenig Testcode Ein wenig Produktionscode Dieser muss Test bestehen Dann kommt der nächste Testcode Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 94 Vorteile Unit Tests werden wirklich geschrieben Zufriedenheit des Programmierers Kann ich den Code so schreiben, dass er diesen Test besteht? Interface und Verhalten werden im Detail geklärt Hauptvorteil Man muss sich Code vorstellen Alle Einzelheiten der öffentlichen Sicht des Codes Name, Parameter, Rückgabewert, Verhalten Beweisbare, wiederholbare, automatisierte Verifizierung Testbasis wächst ständig (10, 50, 500,... Tests) Leichte Verifizierung der Korrektheit Läuft automatisch ab Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 95

18 Vorteile (fortgesetzt) Vertrauen, Dinge ändern zu können Bei Änderungen kann man ganz leicht testen, ob die bisherigen Tests immer noch bestanden werden Unit Testing Frameworks xunit-familie ( JUnit (Kent Beck, Erich Gamma): Java NUnit:.NET (managed code) CppUnit: C++ (Visual C++, MFC) Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 96 Ablauf eines Tests Das Ding, das getestet werden soll, erstellen fixture, etwa: Testobjekt Etwas mit ihm tun also einige seiner Methoden aufrufen, die getestet werden sollen Prüfen, ob die Ergebnisse den Erwartungen entsprechen Testklasse Nachfahre von CppUnit::TestCase Implementiert schon verschiedene Unit Testing Verhaltensweisen Eine oder mehrere Testmethoden pro zu testender public Methode Ausnahmen: Triviale Methoden, z.b. setter und getter Man verwendet hilfreiche, vordefinierte Makros Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 97

19 Beispiel: Adress-Programm Aufsetzen des Projektes: siehe Aufgabenblatt CAdrTestCase.h #pragma once #include <cppunit/testcase.h> #include <cppunit/extensions/helpermacros.h> #include "../Adr/CAdrDoc.h" class CAdrTestCase : public CppUnit::TestCase { CPPUNIT_TEST_SUITE(CAdrTestCase); CPPUNIT_TEST(addTest); CPPUNIT_TEST(changeTest); CPPUNIT_TEST_SUITE_END();... Definition einer Test-Suite Die einzelnen Tests Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 98 Beispiel: Adress-Programm CAdrTestCase.h (fortgesetzt)... public: // Keinen expliziten Konstruktor/Destruktor void setup(); // Initialisierung vor jedem Test void teardown(); // Aufräumen nach jedem Test protected: void addtest(); void changetest(); private: CAdrDoc* fixture; }; Die einzelnen Tests Das Testobjekt Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 99

20 Beispiel: Adress-Programm CAdrTestCase.cpp #include "StdAfx.h" #include "CAdrTestCase.h" CPPUNIT_TEST_SUITE_REGISTRATION(CAdrTestCase); void CAdrTestCase::setUp() { fixture = new CAdrDoc(); } void CAdrTestCase::tearDown() { delete fixture; fixture = NULL; } Erzeuge das Testobjekt Aufräumen nach dem Test... Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 100 Beispiel: Adress-Programm CAdrTestCase.cpp (fortgesetzt)... void CAdrTestCase::addTest() { CAdresse* adr = new CAdresse(CString("Dreher"), CString("Björn"), CString("Teststr. 5"), 65123, CString("Wiesbaden")); CPPUNIT_ASSERT(fixture->NewAdresse(CString("Dreher, Björn"), adr) == TRUE); CPPUNIT_ASSERT(fixture->GetFirstAdresse(&adr)); CPPUNIT_ASSERT(adr->getName() == CString("Dreher")); CPPUNIT_ASSERT(adr->getVorname() == CString("Björn")); CPPUNIT_ASSERT(adr->getOrt() == CString("Wiesbaden")); } void CAdrTestCase::changeTest() { CPPUNIT_ASSERT(1 == 2); // Absichtlich falsch! } Erzeuge neue Adresse Füge sie dem Dokument hinzu Teste! changetest schlägt absichtlich fehl Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 101

21 Beispiel: Adress-Programm CAdrTestApp.cpp: Initialisierung des Application Objektes BOOL CAdrTestApp::InitInstance() {... // Hier geht es jetzt mit der Test Anwendung los: } Das GUI des Test Runners // Declare a test runner, fill it with our registered tests and run them CppUnit::MfcUi::TestRunner runner; runner.addtest(cppunit::testfactoryregistry::getregistry().maketest() ); runner.run(); Die über die Makros definierten Tests hinzufügen // Da das Dialogfeld geschlossen wurde, FALSE zurückliefern, sodass wir // die Anwendung verlassen, anstatt das Nachrichtensystem der Anwendung // zu starten. return FALSE;...und die Tests laufen Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 102 Beispiel: Adress-Programm Ergebnis der Test Suite: Prof. Dr. Björn Dreher Softwaretechnik (Allgemeine Informatik) 103