einführung in die softwaretechnik...softwaresysteme und für die lösung komplexer...

Einführung in die Softwaretechnik

Gabriele Taentzer Philipps-Universität Marburg

Wintersemester 2014/15

Taentzer Einführung in die Softwaretechnik 2

Organisation der LV Umfang: 4 SWS, 6 ECTS Punkte Veranstalter: Gabriele Taentzer, Daniel Strüber

und Tutoren Kontakt:

[email protected], Raum D5434, Tel: 21532

[email protected], Raum: D5432, Tel: 21511

Termine: VL: Di 14 – 16h, Seminarraum 04A30 UE: Mi 14 – 16 h + 16 – 18h, Raum 03C52

(nur eine Übung auswählen)


Organisation der LV

LV ab 3. Semester Voraussetzung:

Grundvorlesungen in Praktischer Informatik I + II Scheinkriterien:

Übungsaufgaben Abschlussklausur am 16.02.2013, 12.30 – 16.00h

Homepage der LV: www.uni-marburg.de/fb12/swt/lehre/est1415 Kopien der Folien, Literaturhinweise, Übungen

Anmeldung: Anmeldung über das LSF-System Online


Lehrveranstaltungsstil

Konzeptvermittlung durch Folien und Literatur Folienkopien sind auf der Homepage verfügbar, kleinere

Abweichungen (insb. Korrekturen) sind möglich Beispiele häufig an der Tafel Zwischenfragen und Kommentare während der Vorlesung sind

grundsätzlich erwünscht. Tutorien:

Praktische Übungen, auch am Rechner Übungen speziell für das Tutorium


Lernziele

Überblick über Softwareentwicklungsprozesse Grundverständnis für die wesentlichen Aufgaben während der

Softwareentwicklung Grundkenntnisse im Entwurf von Softwaresystemen mit der Unified

Modeling Language Vertiefung der Kenntnisse in objektorientierter Programmierung in

Java Grundkenntnisse in der Qualitätssicherung, insbesondere Testen, von

Softwaresystemen Grundverständnis für die in der LV vorgestellten Werkzeuge, durch

Übungen vertieft


Inhalt Einführung in die Softwaretechnik:

Probleme, Prozesse und Techniken der Softwareentwicklung Kontinuierliche Softwareentwicklung

Versions- und Konfigurationsmanagement Anforderungsanalyse für Softwaresysteme Softwareentwurf:

Modellierung der wesentlichen Aspekte SW-Architekturen, Entwurfsmuster und Komponenten

OO-Konzepte für Fortgeschrittene Software-Qualitätssicherung:

speziell Testen von Softwaresystemen Software-Evolution Projektmanagement

Einführung in die Softwaretechnik

14. Oktober 2014

Überblick

Bestandsaufnahme Wie haben wir bisher Softwaresysteme entwickelt? Welche Arten von Softwaresystemen gibt es? Welche Probleme können auftreten?

Welche Prozesse/Verfahren zur Softwareentwicklung gibt es? Welche Aufgaben gibt es und wie können diese strukturiert werden? Wie kann die Arbeit einer größeren Gruppe von Entwicklern koordiniert

werden?


Bestandsaufnahme Welche Softwaresysteme haben Sie bisher entwickelt?

Wie groß sind diese? Von welcher Art sind diese?

Wie lange haben Sie entwickelt? Allein oder im Team? Wie haben Sie die Anforderungen herausgefunden? Wie haben Sie die Software entworfen? Wie haben Sie implementiert?

Mit welcher Programmiersprache? Mit einer Entwicklungsumgebung?

Wie haben Sie die Software getestet?



Softwaretechnik (engl.: Software Engineering) ist ein etabliertes Teilgebiet der Informatik.

Der Name Software Engineering wurde Ende der 1960-er Jahre geprägt. Er war als Antwort auf die damals aufkommende Rede von der Software-Krise gemeint.

Innerhalb der Softwaretechnik befasst man sich mit der Konzeption und Herstellung von Softwaresystemen und den dazu

eingesetzten Methoden und Werkzeugen (Softwareentwicklung) mit der Planung, Steuerung und Überwachung von Softwareprojekten

(Softwareprojektmanagement) mit der Herstellung und Prüfung von Softwarequalität

(Softwarequalitätssicherung)

Softwaretechnik: Herkunft und Einordnung

Eine der ersten Erwähnungen der Softwarekrise

„[Die Hauptursache für die Softwarekrise liegt darin begründet,] dass die Maschinen um einige Größenordnungen mächtiger geworden sind! Um es ziemlich einfach auszudrücken: Solange es keine Maschinen gab, war Programmierung kein existierendes Problem; als wir ein paar schwache Computer hatten, wurde Programmierung zu einem geringen Problem, und nun da wir gigantische Computer haben, ist die Programmierung ein ebenso gigantisches Problem.“– Edsger Dijkstra: The Humble Programmer (1972)(http://www.cs.utexas.edu/users/EWD/ewd03xx/EWD340.PDF)Taentzer Einführung in die Softwaretechnik 11


Beispiele von Softwaresystemen

Eingebettete Systeme Robotersteuerungen Echtzeit-Anwendungen (z.B. in Flugzeugen und Autos) mobile Systeme

Daten- und Informationssysteme Systeme im Bank- und Versicherungswesen, im Verkehr, in der Touristik

und in öffentlichen Verwaltungen Webanwendungen

Softwaremanagementsysteme Programmierumgebungen, Versionsverwaltungssysteme

Textsysteme und Office-Anwendungen Wissensbasierte Systeme

Beratungs- und Expertensysteme, Lehr- und Lernsysteme


Spezielle Eigenschaften von Softwaresystemen Komplexität

übertrifft die vieler anderer technischer Systeme Repräsentation von "Realwelt"-Systemen

Software soll "Abbild" realer Strukturen und Abläufe herstellen, adäquate Ergebnisse liefern, simulieren, "reale" Vorgänge steuern

Universalität: fast alles ist programmierbar ( Turingmaschine)

Schnelle Innovationszyklen neue Probleme und neue Technologien in schneller Abfolge

Fehler- und Störungsanfälligkeit besonders hoch wegen der Universalität und hoher Innovation

Übertriebene, unrealistische Anforderungen führen z.T. zu Megaprojekten, mit hohen Risiken und Verlusten,

sowie unnötigen Verkomplizierungen von Lebensvorgängen


Programmieren im Kleinen und im Großen

In der Softwaretechnik geht es um das "Programmieren im Großen", d.h. um Methoden und Werkzeuge für die Entwicklung großer Softwaresysteme und für die Lösung komplexer Programmier-aufgaben.

Im Laufe der 1950/60-er Jahre waren Umfang und Komplexität von Programmieraufgaben dramatisch angewachsen. Man begann, von der "Software-Krise" zu sprechen.

In den 1970-er Jahren stellten DeRemer und Kron die wesentlichen Charakteristika von "kleinen" und "großen" Programmieraufgaben grundsätzlich einander gegenüber und leisteten damit einen Beitrag zum Selbstverständnis der entstehenden Softwaretechnik.


Programmieren im Kleinen/ im Großen: UnterschiedeDie folgende Tabelle zeigt einige charakteristische Unterschiede von Programmierprojekten im Kleinen bzw. im Großen:

Programmieren …

Softwaresysteme

Komponenten/Module

Aufwand

Dauer

Entwickler

Projektmanagement

Qualitätskontrolle

Werkzeuggebrauch

… im Großen

groß (> ca. 10.000 LoC)

viele (> 10)

groß (> 2 BJ)

lang (> 1 Jahr)

viele (> 10)

notwendig: Planung, Syn-chronisation, Kontrolle etc.

systematisch, geplant

unentbehrlich, integriert

… im Kleinen

klein (<= ca. 5.000 LoC)

wenige (<= 3)

klein (<= 0,5 BJ)

kurz (<= 1/2 Jahr)

wenige (<= 3)

kaum benötigt (selbst-organisierend)

spontan, nach Bedarf

vereinzelt, isoliert

LoC: Lines of Code

BJ: Bearbeiterjahr(e)


Softwaretechnik als Ingenieurdisziplin Als Ursachen der Software-Krise wurden seinerzeit u.a. erkannt:

- unsystematisches, "künstlerisches" Programmieren,- fehlende oder unzureichende Zielsetzung, Planung, (Gesamt)Konzeption, - isolierte Arbeitsweise, individualistische Lösungen.

Software Engineering versteht sich ausdrücklich als Ingenieursdisziplin.Damit möchte man u.a. erreichen:- überschaubare Projekt-, System- und Programmstrukturen, - systematisches, geplantes und kontrolliertes Vorgehen,- ökonomischen und effizienten Einsatz der Ressourcen (Menschen und Arbeitsmitteln),- nachvollziehbare und auf Andere übertragbare Dokumentation,- systematische Verfahren und Maßnahmen zur Qualitätssicherung,- flexibles, den Herausforderungen gewachsenes Projektmanagement.

Nach heutigem Verständnis sind jedoch neben dem Ingenieursaspekt auch andere Aspekte maßgeblich, insbes. wirtschaftliche und psychologische.


Welt der Benutzer

Analyse &Definition

Welt der Modelle

Entwurf

Welt der Maschine

Installation,Betrieb &Wartung

Integration, Tests

ImplementierungDer Weg durch die

SW-Entwicklung

Softwareentwicklung: Prinzipielle Schritte

Vorgehensmodelle für die Softwareentwicklung


Überblick

In einem größeren Softwareprojekt ist für einen längeren Zeitraum die Arbeit einer größeren Gruppe von Entwicklern zu koordinieren. Wie strukturiert man ein Softwareprojekt? Welche Arbeiten müssen koordiniert werden? Welche Vorgehensmodelle gibt es für die Software-

entwicklung?

Diskussion anhand von konkreten Softwareprojekten


Auftragsprojekt „Bewertung der Qualität von Lieferanten“

Eine größere Softwarefirma wird von einem Kunden aus der Maschinenbaubranche beauftragt, ein neues Softwaresystem zur Bewertung und kontinuierlichen Beobachtung von Lieferanten zu entwickeln.

Wesentliche Funktionalität: Bewertung der Termin- und Mengentreue der Lieferanten Management von Eskalationsmaßnahmen

mittelgroßes Projekt (ca. 20 – 30 SW-Entwickler/-innen) Die Kundenseite wird durch eine Firma vertreten. Die Auftragsabwicklung ist in der Hand einer SW-Firma. Ein Legacy-System mit Lieferantendaten ist vorhanden. Die Firma hat die Bewertung bisher auf dem Papierweg erledigt.


Auftragsprojekt „eGovernment“ Die Bundesregierung schreibt die Entwicklung eines neuen

Softwaresystems aus, mit dem es möglich werden soll, Behördengänge elektronisch abzuwickeln. Das System soll bundesweit eingesetzt werden.

Wesentliche Funktionalität: vollständig elektronische Abwicklung typischer Behördengänge, wie

sie z.B. im KfZ-Wesen, Rentenwesen, etc. auftreten sehr großes Projekt (20 - 30 Einzelprojekte pro Jahr) Die Kundenseite wird durch die Bundesregierung vertreten. Die Auftragsabwicklung ist zweigeteilt:

Anforderungsspezifikation Ausschreibung für die Realisierung der Software

Die Ämter haben bisher einen kombinierten Arbeitsprozess. Anträge und Benachrichtigungen in Papierform Bearbeitung und Verwaltung in einem älteren System


Open-Source-Entwicklung im Kontext von Eclipse

Die Eclipse Cooperation startet verschiedene Eclipse-Projekte, in denen Entwicklungswerkzeuge für Softwareentwickler/-innen realisiert werden.

Plugin-Entwicklung: stark komponentenorientiert Entwicklung einzelner Plugins: kleine bis mittlere Projekte z.B. Entwicklung der Java Development Tools

kein konkreter Auftrag, sondern Anforderungen und Wünsche von beteiligten SW-Firmen und Benutzern

extrem verteilte SW-Entwicklung Nutzer werden teilweise zu Entwicklern, indem sie

testen kleinere Fehler selbst beseitigen

Entwicklung eines neuen Computerspiels

Eine kleinere Firma entwickelt ein neues Computerspiel, in dem mehrere Spieler auch verteilt spielen können.

Wesentliche Funktionalität wird im Game-Design beschrieben: Konzepte der Spielvision, Spielwelt, Regeln und Charaktere

mittelgroßes Projekt (ca. 20 – 30 SW-Entwickler/-innen) Produktentwicklung: Kein direkter Kunde, sondern viele Käufer. Erstellung eines Prototypen, mit dem sich schon früh ein Eindruck

vom späteren Spiel gewinnen lässt. Eine erste spielbare Version des neuen Computerspiels wird Alpha-

Version genannt. Eine für das erste Release vorgeschlagene Version wird Beta-Version genannt. Diese werden von professionellen Spiele-testern auf Fehler geprüft.


Wie können Softwareprojekte systematisch entwickelt werden?



SystemRequirements

SoftwareRequirements

PreliminaryDesign

DetailedDesign

Code andDebug

Test andPreOperations

Operations +Maintenance

Wasserfallmodell von B. BOEHMValidation

Validation

Validation

Validation

Developm.Test

Validation Test

Revalidation

nach [Boe81]


abstrakt

konkret

Abstraktion(Problem)

konkret

Abstraktion(Masch.)

Beschreibungs-form

formalinformal

Überprüfungs-form

informalformal

Ideen Prosa Pseudo-Code

Code Beweis Stich-probe

Begut-achtung

Glaube

Maschine

reale WeltAusgangs-

punktProblemeerkennen,bewerten

wartenpflegen

Probleme beschreibentesten

(Abn.-Test)Modell(e)entwickeln

Modell(e)beschreiben

installieren

testenmont.

testenmont.

testende-bug.

spez.

konstr.

spez.

konstr.

spez.cod.

Ziel

Software-Lebenszyklus im V-Modell

Modell


• Ein Inkrement ist ein Software-Baustein bzw. eine Menge von Bausteinen, der (die) zu einem existierenden System oder Subsystem hinzugefügt wird, um dessen Funktionalität oder Leistung zu vergrößern oder zu verändern. Ein Inkrement kann – muss aber nicht -- ein Subsystem, d.h. eine für sich allein genommen lauffähige Einheit, sein.

• Inkrementelle Systementwicklung bedeutet, mit einem (i.a. relativ kleinen) Kernsystem zu beginnen und diesen Kern schrittweise zu erweitern, bis die gewünschte Funktionalität erreicht ist.

I1 I1

I2 I2

I1

I3

I2

I1

I3

I4

Inkremente

Inkrementelle Systementwicklung

Vor- und Nachteile der inkrementellen Entwicklung

Vorteile: schneller lauffähige Software Flexibler gegenüber sich ändernden Anforderungen mehr Feedback vom Kunden möglich Risiken können leichter gemanagt werden, da sie früher erkannt

werden.

Nachteile: Die Projekte brauchen mehr Planung und Design, damit sie

erfolgreich abgeschlossen werden können. Voraussetzung ist ein klares und vollständiges Verständnis vom

System, damit es vom Kern her inkrementell aufgebaut werden kann.



Unified Process(Anfang) (Vertiefung ) (Konstruktion) (Inbetriebnahme)

(Geschäfts-prozess-modellierung)

(Software-verteilung)

Kern-Arbeits-schritte

Unter-stützende Arbeits-schritte

Quelle: IBM - Rational


Prozessphasen

1. Anfang (inception): grundlegender Umfang des Projekts ist bekannt, endet mit der Zusage des Auftraggebenden

2. Vertiefung (elaboration): Endet mit• Grundlegender Systemarchitektur• Konstruktionsplan• Identifizierten Risiken

3. Konstruktion (construction): iterativ, die längste Phase, endet mit Beta-Release

4. Inbetriebnahme (transition): Einführung des Systems beim Anwender


Unified Process ( UP ) Iterativ und inkrementell: Die Phasen sind zeitlich geordnet. Die

Iterationen beschreiben verschiedene Abschnitte innerhalb einer Phase. Die Disziplinen beschreiben die Aktivitäten im Prozess. Der Prozess ist

klar strukturiert. Der Prozess ist anwendungsfallgetrieben. Wichtige Anwendungsfälle

werden zuerst behandelt. Der Prozess ist auf die Softwarearchitektur zentriert. Risiko-fokussiert: Risiken sollen frühzeitig identifiziert werden. Während des Projekts werden viele Softwareartefakte erzeugt: z.B.:

Anforderungsspezifikation, Modelle, Projektpläne, Risikoabschätzungen, Code, Tests, Dokumentationen

Parallel zur UML von Ivar Jacobson, Grady Booch und James Rumbaugh entwickelt

Rational UP als Implementierung (aktuell: Ver. 9)


… ist ein relativ neuer Ansatz, mit dem man versucht, nach wie vor bestehende Probleme bei der SW-Entwicklung zu lösen. Diese sieht man vorrangig

• im Spannungsfeld zwischen Qualität, Kosten und Zeit

• in ungenauen Kundenwünschen und instabilen Anforderungen,

• in langen Entwicklungszeiten und überzogenen Terminen,

• in unzureichender Qualität.

Agile Softwareentwicklung


Im "Manifest der agilen SW-Entwicklung" werden u.a. neue Prioritäten gefordert (vgl. [Coc 02]:)

- Menschen und Kooperation -vor Werkzeugen und (automatisierten) Prozessen,

- funktionsfähige Software -vor umfassender Dokumentation

- Zusammenarbeit mit Kunden -vor bürokratischen Vertragsverhandlungen

- dynamische Reaktion auf Veränderungen -vor statischer Planeinhaltung

Manifest der agilen Softwareentwicklung


Wesentliche agile Praktiken testgetriebene Entwicklung

Die wesentliche Testart sind automatisch durchführbare Tests. Diese Tests werden von den Entwicklern geschrieben. „Schreib erst die Tests und dann den Code.“ „Schreib nicht mehr Code als nötig ist, um die Tests zu bestehen.“

ständige Refaktorisierungen „Refactoring ist die strukturelle Verbesserung von Programmcode

unter Beibehaltung des beobachtbaren Programmverhaltens.“ Refactoring soll den Code hinsichtlich Lesbarkeit, Wartbarkeit,

Erweiterbarkeit und Testbarkeit verbessern. Nach einem Refactoring muss das Programm wieder getestet

werden.


Extreme Programming (XP) - Einige Grundsätze (vgl. [Bec 99]):

• Wenig Analyse- und Entwurfstätigkeiten, nur rudimentäre Spezifikationen, selbst-dokumentierender Code ("simple design")

• Frühes Programmieren, prototypisches Umsetzen einzelner "stories" • Testfälle stehen am Anfang und ersetzen Spezifikation ("test first")• Ständige Kommunikation der Entwickler mit Management und Benutzern, kurze

Rückkopplungsschleifen, schnelle Rückmeldungen • Schrittweise Änderungen, schrittweise angepasste Tests ("refactoring"), fortlaufende

Integration ("continuous integration") • Fahrer-/Beifahrer-Prinzip beim Programmieren ("Pair programming")

• Gemeinsame Standards aller Entwickler, gemeinsames Eigentum am Code("collective code ownership")

• leicht lesbarer, gut strukturierter Code (viele Code Reviews)

Beispiele für weitere "agile" Methoden:• Adaptive SW development, SCRUM, Crystal, Feature driven development

Extreme Programming

Vor- und Nachteile der agilen Praktiken

Vorteile: sehr schnell lauffähige Software typischerweise gut getestet gut lesbarer Code

Nachteile: „Der ideale Kunde und die ideale Entwicklerin“ werden vorausgesetzt. Im Laufe der Zeit unklareres Design der Software: Eine Architektur-

änderung kann ggf. teurer als eine Neuimplementierung sein. Schwer testbare Komponenten werden ggf. zu wenig getestet. zu bewegliche Anforderungen beschränkte Team- und Projektgrößen nicht für Festpreisprojekte geeignet



Softwaretechnik (engl.: Software Engineering) gibt es seit ca. 1970 als eigenständiges Fachgebiet der Informatik, wurde unter dem Namen Software Engineering als Antwort aus die

damals konstatierte Software-Krise begründet, beschäftigt sich mit der Erstellung großer Softwaresysteme hat formale, ingenieurmäßige, technische, gestalterische und

ökonomische Aspekte, gliedert sich in die Teilbereiche:

Entwicklung und Anwendung, Projektmanagement und Qualitätssicherung.

Zusammenfassung


Zusammenfassung

kontinuierliche Entwicklung des Softwareentwicklungs-modells vom Wasserfallmodell zu iterativer Entwicklung

Trend zu ...kürzeren Entwicklungszyklen ...systematischeren Entwicklungsschritten ...systematischerer Qualitätssicherung

Die Auswahl eines konkreten Entwicklungsprozesses hängt von der Art des Softwareprojekts ab.


Literatur Ältere Prozessmodelle:

Barry W. Boehm, Software Engineering Economics, Englewood Cliffs, NJ : Prentice-Hall, 1981

Unified Process:Kruchten: Der Rational Unified Process, Addison Wesley, 1999

Zuser, Grechenig, Köhle: Software Engineering mit UML und dem Unified Process, Pearson Studium, München, 2004

Agile Softwareentwicklung: A. Cockburn. Agile Software Development. Addison Wesley 2002

Extremes Programmieren: K. Beck: Extreme Programming explained: Embrace change. Addison-Wesley 1999

einführung in die softwaretechnik...softwaresysteme und für die lösung komplexer...

Documents