Einführung in die Software-Technik

Einführung in die
Software-Technik

1. Motivation
• Wie entwickelt man eigentlich Software
(professionell)?
– alleine, im Team, in einer Firma
•Für wen?
– sich selbst, Bekannte, Kunden
• Ziel von SW-Engineering: Entwicklung
komplexer Software-Produkte von hoher
Qualität

Planung von Software
• Ingenieurmäßiges Vorgehen
– Phasen- und Vorgehensmodelle
– Methoden für die Anforderungsanalyse
– Methoden für den Entwurf
– Programmiersprachen

Qualitätsmerkmale
• Brauchbarkeit
– Benutzungsfreundlichkeit
– Effizienz
– Zuverlässigkeit
– Portabilität
– Korrektheit
• Wartbarkeit
– Änderbarkeit
– Verständlichkeit
– Testbarkeit

2. Phasenmodelle

2.1 Sequentielles Phasenmodell
• Projektinitialisierung
•Analyse
•Entwurf
• Implementierung
• Test
• Installation

2.1.1 Projektinitialisierung
• Idee für ein Software-Produkt
• Vorgänger- bzw. Konkurrenzprodukt
• Durchführbarkeitsstudie
• Projektplan
–Aufwand
–Ablauf
– Grobe Aufgabenstellung

2.1.2 Analysephase
• Anforderungen
– sammeln, sichten, analysieren
– klassifizieren in
• benutzungsorientierte Anforderungen
• Qualitätsanforderungen
• funktionale Anforderungen
– modellieren

Analysephase (2)
• Detaillierte Analyse des Problembereichs
und der Anwendungsfälle
– Struktur der Objekte des Problembereichs
– Verhalten der Objekte und ihre wechselseitige
Interaktion
• Ziel: Vollständiges und widerspruchsfreies
Analysemodell
– Unabhängig von Implementierung

Pflichtenheft
• Detaillierte verbale Beschreibung der
Anforderungen
• Vertragliche Beschreibung des
Lieferumfangs, Grundlage für Abnahme des
fertigen Produkts
• Beschreibt das Was, aber nicht das Wie
• Vorgegebenes, standardisiertes
Gliederungsschema

2.1.3 Entwurfsphase
• Implementierungs-technische
Entscheidungen
• Detailentwurf der Klassen
• Strukturierung des Klassendiagramms

2.1.4 Implementierungsphase
• Ziel: Realisierung der Problemlösung
– Übersetzung des Modells in gewählte
Programmiersprache
– Unabhängige Implementierung der Klassen
– Integration der Klassen
• Ergebnis: ausführbares Programm

2.1.5 Testphase
• Validierung des Software-Produkts
– Separates Testen der Klassen
– Testen des Gesamtsystems
• Beheben der gefundenen Fehler

2.1.6 Installation
• Übertragung des Programms
– von Entwicklungsumgebung
– auf Anwendungsumgebung
• Benutzungshandbuch
– Beschreibung von
• Produktfunktionen
• Produktstruktur
• Arbeitsabläufen

2.2 Kritik
• Merkmale des sequentiellen Phasenmodells
–einfach
– stark idealisierend
– unrealistisch
– keine Rückkopplungen und keine Zyklen
• Was mache ich, wenn Fehler in einer frühen
Phase später bemerkt werden?

Bemerkungen
• Bessere Modelle
– Phasenmodell für jede Komponente einzeln
• SW-Engineering genauer im Hauptstudium
– 3-semestriger Vorlesungs-Zyklus

2.3 Anwendung auf unser Projekt
• Formalisierung so weit wie nötig
• Pflichtenheft ist wichtig
• Meilensteine
• Testfälle für Klassen schreiben
– Während der Entwicklung der Klassen
– Main-Methoden implementieren!

3. UML
• UML = Unified Modelling Language
• Graphische Modellierungssprache
– Unabhängig von Programmiersprache
– Einheitliche Darstellung für SW-Entwurf
• Diagrammarten
– Anwendungsfalldiagramm
– Aktivitätsdiagramm
– Klassendiagramm
– ...

UML (2)
• Werkzeuge zum Erfassen und Bearbeiten
der Diagramme (Rational Rose, ObjektiF,
TogetherJ, ...)

3.1 Anwendungsfalldiagramm
Grundidee:
• Gliederung der Funktionalität des
Anwendungssystems in logisch
zusammengehörige und handliche funktionale
Einheiten
– „Anwendungs“- oder „Nutzungsfälle“
• Beschreibung in standardisierter Form

Akteur
• Ist etwas, das außerhalb des Systems steht
und auf dieses Wirkungen ausübt
• Repräsentiert die Rolle eines Menschens
oder externen Systems
– Z.B. Administrator, „normaler Benutzer“

Anwendungsfall
• Stellt eine Folge von Ereignissen dar, die durch
einen Akteur ausgelöst werden
• Definiert eine Interaktion zwischen Akteur und
System
• Ist Teil einer Sammlung von Anwendungsfällen,
die zusammen alle Möglichkeiten der
Systembenutzung beschreiben

Beispiel
Scheinverwaltungssystem
• Anwendungsfälle
– Student anlegen
– Veranstaltung bearbeiten
– Teilnehmer Veranstaltung
zuordnen
– Schein freigeben
– Zuordnung Mitarbeiter
beantragen
– Termin anlegen/zuordnen
– ....
• Akteure
– Sekretärin
– Mitarbeiter

Mitarbeiter
Veranstaltung bearbeiten
Zuordnung Teilnehmer
Teilnehmer löschen
«include»
Veranstaltung anlegen
Veranstaltung löschen
Student anlegen
Schein freigeben
«include»
Zuordnung Mitarbeiter beantragen
Teilnehmerliste anzeigen
Zuordnung Mitarbeiter freigeben
Termin anlegen/Zuordnen
Sekretärin

Beschreibung von
Anwendungsfällen (1)
• Titel und Kurzbezeichnung
• Kurzgefasste Darstellung des Zwecks
• Aufzählung der involvierten Akteure
• Ereignisse, die einen konkreten
Anwendungsfall auslösen, ggf. mit den
dazu notwendigen Bedingungen

Beschreibung von
Anwendungsfällen (2)
• Beschreibung der Daten, die bei der
Auslösung benötigt werden
• Behandlung von Ausnahme- und
Fehlersituationen
• Teilschritte, Aktionen und Reaktionen,
die den Ablauf des Anwendungsfalls
bestimmen
• Ergebnisse und Nachbedingungen

Anwendungsfall: Veranstaltung bearbeiten
Involvierte Akteure: Sekretärin
Zweck: Die Daten einer in der Kurzübersicht vorhandenen
Veranstaltung sollten verändert werden.
Für die Auslösung benötigte Daten:
1. Eine Kurzübersicht muss existieren.
2. Ein Belegungsplan für Hörsaal III muss existieren.
Ausnahme- und Fehlersituationen:
1. Es existiert noch keine Kurzübersicht
Fehlermeldung: Der Benutzer wird aufgefordert, eine
Kurzübersicht zu erstellen.
2. Durch die Änderung von Termin oder Raumdaten entsteht ein
Konflikt bei der Belegung von Hörsaal III
Fehlermeldung: Der Benutzer wird auf den Konflikt
hingewiesen und erhält die Möglichkeit, die Daten der
Veranstaltung zu ändern, oder die eingegebenen Änderungen
rückgängig zu machen.

Teilschritte:
1. Eine Liste der in der Kurzübersicht gespeicherten
Veranstaltungen wird ausgegeben, die Sekretärin wählt eine der
Veranstaltungen aus.
2. Eine Eingabemaske mit den gespeicherten Daten wird
angezeigt.
3. Die Sekretärin ändert die gewünschten Datenfelder oder fügt
zusätzliche Informationen für das kommentierte
Vorlesungsverzeichnis ein.
4. Die Änderungen werden in der Kurzübersicht gespeichert, wobei
auch eine Aktualisierung des Belegungsplanes für Hörsaal III
stattfindet und die Belegung des Hörsaales auf
Überschneidungen überprüft wird.
Ergebnisse: Die Kurzübersicht wird geändert. Der Belegungsplan
für Hörsaal III wird geändert.

3.2 Aktivitätsdiagramm
• Verfeinerung eines Anwendungsfalls
• Modellierung eines Ablaufs
• Jeder Aktivitätsschritt wird spezifiziert
• Reihenfolge der Schritte
• Verzweigungen
• Synchronisationspunkte
• Start- und Endpunkte

Beispiel Scheinverwaltungssystem
Kurzübersicht
Veranstaltung
auswählen
Daten
ändern
Kurzübersicht
ändern
Raumplan
ändern

3.3 Klassendiagramm
• Zeigt die logische, statische Struktur eines
Systems
• Enthält
– Klassen und Objekte
• Attribute und Operationen
– Beziehungen zwischen den Klassen
• Vererbungsbeziehungen
• Assoziationen

3.3.1 Klassen in UML
Klassenbezeichner
Attribute
Veranstaltung
Veranstaltungsnr: int
Titel: String
Semester: String
Dozent: String
Betreuer: Account
Termin: Termin
Methoden
löschen()

Objekte in UML
:Veranstaltung
Veranstaltungsnr = 12082
Titel=Informatik-Praktikum im Grundstudium
Semester=SS 03
Dozent=Sommer
Betreuer=Schneider, Heinz
Termin=Mo, 14 – 16, HG 5

3.3.2 Beziehungen zwischen Klassen

Generalisierung/Vererbung
• Subklassen erben alle Attribute,
Operationen und Assoziationen von der
Oberklasse
• Ein Objekt einer Subklasse ist gleichzeitig
auch Exemplar der Superklasse
Superklasse
Veranstaltung
Subklassen
Seminar Vorlesung Praktikum

Bemerkungen
• Vorsicht beim Einsatz von Vererbung
– Wird häufiger genutzt, als sinnvoll!
– Beispiel:
Person
Student Mitarbeiter Professor

Assoziation
• Modelliert Verbindung zwischen Objekten
einer oder mehrerer Klassen
• Kardinalitäten: wie viele Objekte der
anderen Klasse kann ein bestimmtes Objekt
kennen?
• Definition von Rollen
Student
1…*
1…*
Vorlesung
hört

Aggregation
• Zwischen den Objekten der beteiligten
Klassen besteht eine Rangordnung
• Lässt sich beschreiben durch „besteht aus“
oder „ist Teil von“
Auto (PKW)
1
1...5
Reifen
besteht aus

Komposition
– Starke Form der Aggregation
– Lebenszeit von Ganzem und Teil ist identisch
• Wird das Ganze gelöscht, werden automatisch seine
Teile gelöscht.
– Beispiel: Raum „ist in“ Gebäude
Gebäude
1
1...*
Raum
hat

Für unsere Zwecke
• Anwendungsfalldiagramm
• Vereinzelt Beschreibung von
Anwendungsfällen
• Klassendiagramme
• Weitere Diagramme wenn für nötig
befunden

4. Objektorientierte Analyse
(OOA)
• Ziel: Verständnis des zu realisierenden Problems
und dessen Beschreibung in einem OOA-Modell
• Zu erstellenden Produkte:
– Pflichtenheft: textuelle Beschreibung dessen, was das
System leisten soll
– OOA-Modell, bestehend aus statischem Modell und
dynamischen Modell
– Prototyp der Benutzungsoberfläche

Pflichtenheft (1)
Gliederungsschema (Muster) eines Pflichtenhefts
1 Zielbestimmung
1.1 Musskriterien
1.2 Wunschkriterien
1.3 Abgrenzungskriterien
2 Produkteinsatz
2.1 Anwendungsbereiche
2.2 Zielgruppen
2.3 Betriebsbedingungen
3 Produktübersicht
4 Produktfunktionen
5 Produktdaten
6 Produktleistungen
7 Qualitätsanforderungen
8 Benutzungsoberfläche
9 Nichtfunktionale
Anforderungen

Pflichtenheft (2)
10 Technische Produktumgebung
10.1 Software
10.2 Hardware
10.3 Orgware
10.4 Produkt-Schnittstellen
11 Spezielle Anforderungen an die Entwicklungsumgebung
12 Gliederung in Teilprodukte
13 Ergänzungen (nach H. Balzert: Lehrbuch der Software-Technik)

OOA-Modell
• Statisches Modell beschreibt
– Klassen des Systems
– Assoziationen
– Attribute (Daten des Systems)
– Pakete zur Bildung von Teilsystemen
• Dynamisches Modell zeigt
– Funktionsabläufe, Verhalten des Systems
• Prototyp der Benutzungsoberfläche
– dient zur Kommunikation mit dem Auftraggeber

5. Objektorientierter Entwurf
• Aufgaben des Entwurfs
– Ermitteln und Festlegen der Umgebungs- und
Randbedingungen
– Treffen grundlegender Entwurfsentscheidungen
– Entwerfen einer Software-Architektur
– Zerlegung des Systems in Komponenten
– Spezifikation des Funktions- und Leistungsumfang der
Komponenten
– Festlegung der Schnittstellen, über die die
Systemkomponenten miteinander kommunizieren

Drei-Schichten Architektur
Benutzungsoberfläche
Anwendungsschicht
Datenhaltung
• Beispiel Buch:
– Klasse für die Anzeige
– Klasse mit Verwaltungsoperationen
– Klasse zur Speicherung eines Buchs

OOD-Modell
• Technische Lösung des zu realisierenden
Systems
• Abbild des späteren Programms
• Enthält alle Klassen, Attribute und
Operationen des späteren Programms
• Gleiche Attribut- und Methodennamen wie
im Programm

6. Implementierung
• Tätigkeiten bei der Implementierung
– Konzeption von Datenstrukturen und Algorithmen
– Strukturierung des Programms durch geeignete
Verfeinerungsebenen
– Umsetzung der Konzepte in die Konstrukte der
verwendeten Programmiersprache
– Dokumentation und Kommentierung der
Implementierungsentscheidungen
• Ergebnisse
– Quellcode einschließlich integrierter Dokumentation
– Testplanung und Testprotokoll

Prinzip der Verbalisierung
• Aussagekräftige Namensgebung (bitte in
der Sprache einheitlich: entweder nur
Deutsch oder nur Englisch)
• Geeignete Kommentare
• Verwendung benannter Konstanten
! Programmierrichtlinien für Java-
Programme

Weitere Prinzipien der
Implementierung
• Prinzip der problemadäquaten Datentypen
– Verwendung von vordefinierten Datentypen der
verwendeten Programmiersprache
• Prinzip der Verfeinerung
• Prinzip der integrierten Dokumentation
– Kurzbeschreibung des Programms
– Verwaltungsinformationen
– Kommentierung des Quellcodes

Integrierte Dokumentation
• Reduziert den Aufwand zur
Dokumentenerstellung
• Stellt sicher, dass keine Informationen verloren
gehen
• Garantiert die rechtzeitige Verfügbarkeit
• Entwicklungsbegleitende Dokumentation
• Gute Dokumentation bildet die Voraussetzung für
– Leichte Einarbeitung bei Personalwechsel
– Gute Wartbarkeit des Produkts

Javadoc
• Dokumentationskommentar: /**Kommentar*/
• Dort können verwendet werden:
– spezielle Befehle: @author, @version,....
– Zur Kommentierung von Operationen:
• @param: Name und Bezeichnung von Parametern
• @return: Beschreibung eines Rückgabeparameters
• @exception: Name und Beschreibung von Ausnahmen
• @see: Verweis auf andere Klassen
– HTML-Befehle wie , ...
– Hyperlinks auf andere relevante Dokumente mit dem
HTML-Befehl

7. Testen
• Gezieltes Suchen nach Fehlern
• Getestet werden sämtliche Dokumente, die bei der
Softwareentwicklung entstehen
• Testen ist Kontrollfunktion im Software-
Entwicklungsprozess (! Qualität)
• Testen umfasst nicht die Fehlerkorrektur

Funktionstest
• Programm als black-box: Überprüfung der
in der Spezifikation festgelegten
Funktionalität.
• Zwei Stufen:
1. Definitionsbereiche der Eingaben bzw. die
Wertebereiche der Ausgaben in
Äquivalenzklassen zerlegen
2. Aus jeder Äquivalenzklasse nach bestimmter
Strategie Testfälle auswählen

Äquivalenzklassenbildung
• Alle Werte einer Äquivalenzklasse verursachen
identisches, funktionales Verhalten.
• Beispiel: Programm zur Berechnung von Preisen
– Art.-Nr.: 5-stellige Zahl
– Stückzahl: mind. 1, höchstens 10.000
– Rabatt: liegt zwischen 0 und 100%

Äquivalenzklassen
gültig
ungültig
Art.-Nr.
Stückzahl
Rabatt
9999

Testfälle
1.
2.
3.
4.
5.
6.
7.
8.
Art-
Nr.
10000
99999
9999
100000
11111
11111
11111
11111
Stück
1
10000
1
1
0
10001
1
1
Rabatt
0
100
0
0
0
0
-1
101

Testen von Klassen
• Äquivalenzklassenbildung der möglichen
Attributwerte und Parameter ! Testfälle
• Ausführen der Operationen für alle
Testfälle
– Die Werte des Objekts müssen zu Beginn in
den entsprechenden Zustand versetzt werden.
– Abgleich von Ist- und Sollwerten
• Test jeder Folge abhängiger Operationen

Integrationstest
• Überprüfung des fehlerfreien
Zusammenwirkens der Systemkomponenten
• Schrittweises Hinzufügen neuer
Systemkomponenten zu einem bereits
fehlerfrei arbeitenden Subsystem
• Überprüfen der gegenseitigen
Methodenaufrufe

Systemtest
• abschließender Test
• Basis für den Systemtest ist das Pflichtenheft
(Anwendungsfälle) und das OOA-Modell
• Auf Grundlage dieser Vorgaben werden Testfälle
übernommen, ergänzt, und/oder neu erstellt
• Verschiedene Teiltests:
-Funktionstest
-Sicherheitstest
-Leistungstest
-Interoperabilitätstest
-Benutzbarkeitstest

Testplan
• Auf Grundlage der Vorgaben im
Pflichtenheft werden die zu überprüfenden
Funktionen in einem Testplan festgehalten

8. Benutzerhandbuch
• Soll die Handhabung und das Verhalten des
Software-Produkts möglichst vollständig
und fehlerfrei beschreiben
• Adressaten sind die Endbenutzer
• Inhalt
– Produktbestandteile
– Produktfunktionen
– Arbeitsabläufe

Gliederungsschema (1)
• Vorwort
• Inhaltsverzeichnis
• Einführung
• Installation
• Benutzungsoberfläche
– Allgemeine Bedienungshinweise
– Tasten- und Mausbelegung
– Bildschirmaufbau
• Produktstruktur

Gliederungsschema (2)
• Trainingsteil
– Typische Arbeitsabläufe mit Beispielen
• Referenzteil
– Benutzer-Leitfaden, enthält vollständige Beschreibung
aller Objekte und Funktionen
• Literaturverzeichnis
• Abkürzungsverzeichnis
• Glossar
• Stichwortverzeichnis/Index/Register
nach H. Balzert: Lehrbuch der Software-Technik

„Und das sollen wir alles
machen?“