Transcript Seminar Pleiten, Pech & Pannen der Informatik

Seminar Pleiten, Pech & Pannen
der Informatik
Software
"
Philipp Stratmann, Softwareentwicklung mit UML
"
Alexander Ott, Qualitätsmetriken für Software
Hardware
"
Matthias Möller, Testbenchmethodik
"
Horst Rechner, Netzwerktest
"
Christian Teufel, Fehlertoleranz
"
Daniel Brintzinger, Selbsttests
Softwareentwicklung mit UML
Gliederung:
"
Probleme beim Design des S/390-Systems
"
Einführung in UML
"
Softwaredesign mit UML
"
Fazit
Entwicklung S/390 Betriebssystem
Entwicklungsleiter Frederick P. Brooks
(aus Brooks, F.P.; the mythical man-month, 1975)
Zeitplanung für Systemarchitektur: 7 Monate
Leiter Designabteilung mit 10 guten Leuten:
„Für ein gutes Design brauchen wir 10 Monate.“
Leiter Implementierung mit 150 Leuten:
„Wir schaffen gleich gutes Design in 7 Monaten.“
Leiter Designabteilung:
„Sie werden auch 10 Monate brauchen und das Design
wird viel schlechter sein.“
Entscheidung und Folgen
Brooks Entscheidung:
Implementierungsabteilung macht Design
Ergebnis:
beide Voraussagen des Designers trafen ein
Folgen, weil kein einheitliches Konzept vorlag:
" System war wesentlich teuerer zu erstellen und zu ändern
" 1 Jahr zusätzlich für Debugging
Erkenntnis
Brooks:
„Es ist eine sehr beschämende Erfahrung, einen multimillionen
Dollar teuren Fehler zu machen, aber man erinnert sich stark
daran.“
Fazit:
Gutes Design ist bares Geld wert
Ein Hilfmittel für ein gutes Design ist UML
Einführung
UML - Unified Modelling Language
eine graphische Sprache zur Spezifikation, Visualisierung,
Konstruktion und Dokumentation von Modellen für
Softwaresysteme, Geschäftsmodelle und andere NichtSoftwaresysteme
Entwickelt von Grady Booch, James Rumbaugh
und Ivar Jacobson
seit 1998 Standard der Open Managment Group (OMG)
aktuell Version 1.4
UML ist keine Methode
UML ist ein Satz von Notationen zur Formung einer
allgemeinen Sprache zur Softwareentwicklung.
Eine Methode beinhaltet Empfehlungen zur Vorgehensweise
bei Entwicklungsprozessen.
Um UML erfolgreich zu nutzen, ist es notwendig eine
passende Methode zu entwickeln, die UML unterstützt.
UML-Diagramme
Gliederung in 8 Diagrammtypen:
1
2
3
4
5
6
7
8
Anwendungsfalldiagramm
Klassendiagramm
Aktivitätsdiagramm
Kollaborationsdiagramm
Sequenzdiagramm
Zustandsdiagramm
Komponentendiagramm
Einsatzdiagramm
Anwendungsfalldiagramm
Menge von Anwendungsfällen, stellt Beziehungen zwischen Akteuren
und Anwendungsfällen dar
Klassendiagramm
Eine Klasse ist eine Menge von Objekten, in der die Eigenschaften
(Attribute), Operationen und die Semantik der Objekte definiert
werden
Klassendiagramm - Vererbung
Vererbung ist ein Programmiersprachenkonzept, d.h. ein Umsetzungsmechanismus für die Relation zwischen Oberklasse und Unterklasse,
wodurch Attribute und Operationen der Oberklasse auch den
Unterklassen zugänglich werden. Generalisierung und Spezialisierung
sind Abstraktionsprinzipien zur hierarchischen Gliederung der
Semantik eines Modells.
KD - Assoziation und Aggregation
Eine Assoziation beschreibt eine Relation zwischen Klassenbezüglich
gemeinsamer Semantik und Struktur von Objektbeziehungen.
Eine Aggregation ist eine Assoziation, deren beteiligte Klassen
eine Ganzes-Teile-Hierarchie darstellen.
Praxis
Die vorgestellten Diagramme dienen aber nur als Hilfmittel.
Nun soll beispielhaft eine Methode der objekorientierten Anwendungsentwicklung vorgestellt werden
Das Vorgehensmodell ist
" anwendungsfallgetrieben
" architektur- und komponentenzentriert
" iterativ
" inkremtell
Anwendungsfallgetrieben
Zur Erhebung der Anforderungen werden Anwendungsfälle eingesetzt
Sie werden am Anfang systematisch erarbeitet und bilden die
Grundlage für weiters Vorgehen
Z.B. Priorisierung, was zuerst umgesetzt werden soll
Typische Fragen:
Welche Gegenstände werden verwendet?
Welche Eigenschaften haben sie?
Wie kommunizieren die Mitarbeiter untereinander?
Architekturzentriert
Wichtig ist, daß die Eigenschaften evtl. vorhandener Anwendunsarchitekturen berücksichtigt werden können.
Die Architektur beschreibt, wie sich das Gesamtsystem in seine Teile
gliedert und wie diese zusammenwirken.
Daraus Ableitung, welche Teile zu entwickeln sind.
Dies heißt vor allem, daß das Vorgehen die Erarbeitung der durch die
Architektur vorgegebenen Teile optimal unerstützt.
Iterativ und inkrementell
Iterativ bedeutet die Zerlegung in mehrere gleichartige Schritte. Jede
Iteration erzeugt ein Teilergebnis.
Inkrementell bedeutet die schrittweise Zunahme der Gesamtfunktionalität
Entwicklung in mehreren nach- und nebeneinanderlaufenden Phasen
Modularisierung, d.h. Aufteilung in Subsysteme und Teams
Regelmäßige Synchronisation durch zentralen Koordinator
Teilergebnisse unterliegen der Revision und werden intern und extern
validiert und verifiziert
Überblick
Vorstudie u.
Anfor
derrunsanalyse
Grobdesign
Iterative
inkrementelle
Entwicklung
Systemtest
Jede Phase gliedert sich dabei in verschiedene Einzelaktivitäten
UML-Tools
Zur Unterstützung gibt es Softwaretools, mit denen UML-Diagramme
gezeichnet werden können.
Diese können aus den Diagrammen Code-Gerüste erzeugen, oder
umgekehrt, aus Code Diagramme.
Vorteile:
Hilft Fehler bei Umsetzung zu vermeiden
Team-Unterstützung
Meist nur ein Werkzeug nötig
Bsp: Rational: Rose, Togethersoft: Together, MS: Visio, etc
Together:
Paketverwaltung
Members werden beim
Generieren automatisch
eingebunden
Bemerkungen
Bernd Oestereich: „Eine funktionierende OO-Entwicklunsmethodik und
-umgebung kann mit 20-50% des Aufwands eines konventionellen
(prozeduralen) Entwicklung auskommen.“
Jedoch: UML und OO sind keine Selbsläufer und führen nicht automatisch zu einem besseren Design.
Eine gute OO-Entwicklunsmethode wird durch UML ideal unterstützt.
UML bietet ein anschauliches und standardisiertes Konzept zur
Visualisierung des gesamten Entwicklungsprozesses
1 Bild = 1 Megawort
Fazit
Jedes Softwareprojekt sollte auf der Basis eines guten Designs stehen.
Denn schlechtes oder fehlendes Design kann, wie in der Einleitung gesehen, viel Zeit und Geld kosten und u.U. dazu führen, daß Projekte
nicht realisiert werden können.
Brooks: „Der schwierigste Teil bei der Entwicklung eines
Softwaresystems ist, genau zu entscheiden, was gebaut werden soll.
[...] Kein anderer Teil ist später schwieriger zu korrigieren.“