Post on 29-Aug-2019
transcript
Software-Projekt
Prof. Dr. Rainer Koschke
Fachbereich Mathematik und InformatikArbeitsgruppe Softwaretechnik
Universitat Bremen
Wintersemester 2008/09
Uberblick I
1 Vorbemerkungen
2 Softwaretechnik
3 Planung
4 Anforderungsanalyse
5 Objektorientierte Modellierung
6 Reviews
7 Entwurf von Benutzungsschnittstellen
Uberblick II
8 Software-Architektur
9 Architekturstile und Entwurfsmuster
10 Software-Test
11 Implementierung
12 Benutzerdokumentation
13 Antworten auf gesammelte Fragen im Wiki
14 Das SWP-Lied
Vorbemerkungen
Vorbemerkungen1 Vorbemerkungen
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 4 / 634
Vorbemerkungen
Anmerkungen zu diesem Skriptum
Einige dieser Folien basieren inhaltlich auf Skripten von. . .
Prof. Dr. Jochen Ludewig (2003), Universitat Stuttgart
Prof. Dr. Susanne Maaß (2001), Universitat Bremen
Prof. Dr. Karl-Heinz Rodiger (2004), Universitat Bremen
Dr. Andreas Winter (2003), Universitat Koblenz
Ich danke fur deren freundliche Genehmigung.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 5 / 634
Vorbemerkungen
Ziele der Vorlesung
Primare Ziele:
Rustzeug fur die erfolgreiche Durchfuhrung Ihres Software-Projektsvermitteln
Modell fur zukunftige ahnliche Projekte bieten
→ Praktikum und Vorlesung bilden eine Einheit
Primare Ziele sind nicht:
Vollstandige Darstellung aller Themengebiete der Softwaretechnik1
Vermittlung von spezifischen Kenntnissen fur die Entwicklung desAnwendungssystems X
1Wird im Hauptstudium nachgereicht.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 6 / 634
Vorbemerkungen
Software-Projekt
Szenario:
Erstellung eines großen Softwaresystems
hier: mehrere Mitarbeiter uber einen langen Zeitraumhier nicht: ein
”Freizeit“-Programmierer
fur einen Auftraggeber
hier: Individualsoftwarehier nicht: Standardsoftware
im Rahmen eines Projekts
hier: einmalige Zielverfolgunghier (eher) nicht: Weiterentwicklung existierender Software(aber: die Software wird von uns spater weiterentwickelt; Wartbarkeitist erklartes Ziel)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 7 / 634
Vorbemerkungen
Angestrebte Resultate
Softwaretechnik ist nicht nur Programmieren.
Softwaretechnik ist auch Programmieren.
Software-Entwicklung produziert Dokumente.
Der Quellcode ist ein Dokument unter vielen.
Sie sollen nicht nur ein richtiges System bauen.Sie sollen ein System auch richtig bauen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 8 / 634
Vorbemerkungen
Aktivitaten bei der Softwareentwicklung
managem
ent
Qualitäts−
Konfigurations−management
man
agem
ent
Projekt−
Imple−men−tierung
Inbetrieb−nahme
Analyse
Entwurf
Test
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 9 / 634
Vorbemerkungen
beeinflusst/startet
pruft
Infrastruktur einrichten
Initiale Projektplanung
Ist-Analyse
Soll-Analyse
Usability-Prototyp
Anforderungsspezifikation
Review der Anforderungs-spezifikation
HandbuchschreibenArchitekturentwurf
TechnischesPrototyping
Architekturreview
Testplan u. Unit-Test-Entw.
Implementierung
Code-InspektionUnit-/Integrationstests
Systemtests
Testprotokoll
Akzeptanztest(Prasentation)
Ubergabe
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 10 / 634
beeinflusst/startet
pruft
Infrastruktur einrichten
Initiale Projektplanung
Ist-Analyse
Soll-Analyse
Usability-Prototyp
Anforderungsspezifikation
Review der Anforderungs-spezifikation
HandbuchschreibenArchitekturentwurf
TechnischesPrototyping
Architekturreview
Testplan u. Unit-Test-Entw.
Implementierung
Code-InspektionUnit-/Integrationstests
Systemtests
Testprotokoll
Akzeptanztest(Prasentation)
Ubergabe
20
09
-02
-09
Software-Projekt
Vorbemerkungen
Ablauf
Aktivitaten in schwarzer Schrift sind konstruktiv; Aktivitaten in blauer Schrift dienen der analytischenQualitatssicherung. Das Symbol kennzeichnet abzugebende Dokumente, die Produkt einer Aktivitat sind.
Vorbemerkungen
Zeitplan
24.11.2008 Initialer Projektplan12.1.2009 Anforderungsspezifikation mit Angebot
12.-30.1.2009 Review der Anforderungsspezifikationvorauss. 9-13.2.2009 Vorlesung Datenbankgrundlagenvorauss. 9-20.3.2009 Prufung zur Vorlesung
16.3.2009 Architekturentwurf6.-13.4.2009 Walkthrough des Architekturentwurfs
20.4.2009 Testplan mit Unit-TestsMai/Juni 2009 Code-Inspektion
10.7.2009 Endabgabe2
15-17.7.2009 Abschlussprasentationen
Vorlaufige Teilergebnisse mussen Sie evtl. in den Tutorien vorher abgeben.
2Implementierung (Source+lauffahig), Dokumentation, Whiteboxtests, Testprotokoll,Dokumentation der Abweichungen von Spezifikation und Architektur
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 11 / 634
Vorbemerkungen
Anmeldung
Tutorienwahl ab sofort bis zum bis 30.10., 23.59 Uhr3
(erstes Tutorium am 3.11.)
Web-Seite zur Anmeldung:http://www.informatik.uni-bremen.de/st/mems/courses.php?lng=en
gruppenweise anmelden
Gruppengroße 6 Personen
Gruppennamen sorgfaltig auswahlen
auslandische Studierende integrieren
3Ortszeit BremenRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 12 / 634
Vorbemerkungen
Scheinbedingungen
http://www.informatik.uni-bremen.de/st/Lehre/swp/scheinbedingungen.html
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 13 / 634
Vorbemerkungen
Abgabe des Projektplans
abzugebender initialer Projektplan umfasst Aufgaben, Teilnehmer,Rollen, Verantwortlichkeiten, Pflichten, Risiken und deren Behandlung
danach: inkrementelle Fortfuhrung
kann abgegeben werden fur Feedback vom Tutor, muss aber nichtraten wir aber dringend anVerantwortlicher ist z.B. Phasenleiter fur die zu planende Phaseerste Woche jeder Phase dient Einarbeitung und PlanungGranularitat der Arbeitspakete: Arbeitsumfang von 1-2 Personen mitmax. 1-2 Zeitwochengerade in Krisenzeiten (Implementierungsphase) braucht man einenPlan (was ware die Feuerwehr ohne Plan?)
Fertigstellung (Ist) wird dokumentiert durch individuelle Zeiterfassungaufgeschlusselt in Aktivitaten (Anette).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 14 / 634
Vorbemerkungen
Anette: Aufgaben-Management
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 15 / 634
Vorbemerkungen
Anette: Zeiterfassung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 16 / 634
Vorbemerkungen
Die Aufgabe
Aktuelle Probleme bei der Durchfuhrung von Arbeitssitzungen im SWPund anderswo:
Terminfindung ist ein langwieriger Prozess
keine Moglichkeit zur Vorbereitung, da keine Agenda
schlechte Zeitausnutzung
wichtige Dinge bleiben unbesprochen
die Inhalte der Arbeitssitzungen gehen verloren
Festlegungen in Arbeitssitzungen bleiben unverbindlich
Aufgaben werden nicht erledigt
Aufgabe: Meeting Assistant
Erstellung eines Systems zur Unterstutzung von Arbeitssitzungenz.B. im SWP
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 17 / 634
Vorbemerkungen
Durchfuhrung von Arbeitssitzungen
Rollen: Moderator, Protokollant, sonstige Teilnehmer
Vorbereitung:
1 Terminfindung
2 Aufstellung der Agenda mit Priorisierung und Zeitplan
3 Versenden der Einladung mit Agenda
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 18 / 634
Vorbemerkungen
Durchfuhrung von Arbeitssitzungen
Durchfuhrung:
1 Feststellung der Anwesenheit
2 ggf. Anpassung der Agenda
3 Abfragen der offenen Aufgaben des letzten Treffens4 Abarbeitung der Agenda:
entlang der PriorisierungEinhaltung des ZeitplansProtokollierung aller wesentlichen Punkte
5 Festlegung von Aufgaben mit Verantwortlichen und Erledigungsdatum
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 19 / 634
Vorbemerkungen
Durchfuhrung von Arbeitssitzungen
Nachbearbeitung:
1 Versenden des Protokolls
2 ggf. Anpassung des Protokolls
3 Auswertungen von Statistiken, um Arbeitssitzungen kontinuierlich zuverbessern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 20 / 634
Vorbemerkungen
Erforderliche Funktionalitat
Meeting Assistant soll den gesamten Prozess unterstutzen:
Zeitfindung unter den Teammitglieder
Vorbereitung der Agenda und Verteilung im Vorfeld
Protokollerstellung wahrend der Besprechung und Verteilung imAnschluss
Uberprufen der offenen Punkte vom letzten Protokoll
Integration mit Anette ware vorteilhaft, ist aber nicht verbindlich.Quellcode von Anette kann erweitert werden.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 21 / 634
Vorbemerkungen
Erforderliche Funktionalitat
Randbedingungen:
Implementierung in Java 5 oder hoher
Swing-GUI, keine Webanwendung
Mehrbenutzerbetrieb
hoher Anspruch an Datenschutz und -sicherheit
hoher Anspruch an Benutzbarkeit/Ergonomie
Client/Server Anwendung
Verwendung von MySQL fur den Server
Verwendung von SQL-Abfragen
keine”große“ Datenbank auf dem Clienten (eingebettete sind OK)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 22 / 634
Vorbemerkungen
Vorlesungsbegleitender Technikkurs
Themen:
Swing
Sockets (TCP)
RMI
SSL
Serialisierung
Datenbankanbindung
OR-Mapping
XML Parser
Multithreading
. . .
jeweils Einfuhrung + betreute Ubung
optionales Angebot, Teilnahme freiwillig
etwa 4–5 Termine
Termin: im Januar/Februar?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 23 / 634
Vorbemerkungen
Die Beteiligten
Tel. E-Mail OrtRainer Koschke 9671 koschke OAS 3016Raimar Falke 2576 rfalke OAS 3012Markus Eich 64105 eich DFKI 212Hendrik Iben 2447 hiben TAB 1.91Hui Shi 64260 shi Cartesium 1.053Xin Xing 3035 xing TAB 1.77
. . . und naturlich Sie!
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 24 / 634
Vorbemerkungen
Ressourcen
Web-Seite zur Vorlesung:http://www.informatik.uni-bremen.de/st/Lehre/swp/
Folien mit Kommentaren:http://www.informatik.uni-bremen.de/st/lehredetails.php?id=&lehre_id=46
Folien mit Annotationen aus der Vorlesung bei Stud.IP:http://elearning.uni-bremen.de/
Video-Aufzeichnung vom letzten Jahr:http://mlecture.uni-bremen.de
Newsgroup fb3.lv.swp
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 25 / 634
Vorbemerkungen
Lehrbucher zur Softwaretechnik I
Allgemeine Literatur zur Softwaretechnik:
Balzert (1998): Umfassendes deutsches Lehrbuch vmtl. der Bestsellerin Deutschland; leider nicht mehr im Buchhandel verfugbar, wird neuaufgelegt
Ludewig und Lichter (2006): Umfassendes Lehrbuch, das ausLudewigs Vorlesungen rund um Softwaretechnik entstanden ist. DieseVorlesung basiert in großen Teilen auf dem Skript von LudewigsVorlesung.
Sommerville (2004): Ein Standardlehrbuch, sowohl in deutscher alsauch englischer Sprache verfugbar. Im Umfang vergleichbar mit demBuch von Pressman (2003).
Pressman (2003): Ein umfassendes englisches Lehrbuch, das man fastschon als Enzyklopadie bezeichnen konnte. Behandelt auchnicht-objektorientierte Konzepte.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 26 / 634
Vorbemerkungen
Lehrbucher zur Softwaretechnik II
Brugge und Dutoit (2004): Eine Einfuhrung in Deutsch mitSchwerpunkt Objektorientierung und UML.
Zuser u. a. (2004): Eine Einfuhrung in Deutsch mit SchwerpunktObjektorientierung und dem Rational Unified Process. Wenigerumfassend als das Buch von Brugge und Dutoit (2004).
Spezialthemen:
Storrle (2005): Eine kurze Einfuhrung in die Konzepte der UML 2.0 indeutscher Sprache.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 27 / 634
Allgemeines zur Softwaretechnik
Allgemeines zur Softwaretechnik
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucher
2 SoftwaretechnikEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 28 / 634
Allgemeines zur Softwaretechnik
Was ist Software?
Definition
Software: Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of a computer system.
IEEE Std 610.12-1990 (1990)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 29 / 634
Was ist Software?
Definition
Software: Computer programs, procedures, and possibly associateddocumentation and data pertaining to the operation of a computer system.
IEEE Std 610.12-1990 (1990)
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Was ist Software?
Software umfasst also nach IEEE Std 610.12 Programme, Ablaufe, Regeln, auch Dokumentation und Daten, diemit dem Betrieb eines Rechnersystems zu tun haben.
Allgemeines zur Softwaretechnik
Ein Produkt wie jedes andere?
Software
ist ein technisches Produkt,
weist aber einige einmalige Merkmale auf.
→ Sie sollten beim Umgang mit Software beachtet werden.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 30 / 634
Ein Produkt wie jedes andere?
Software
ist ein technisches Produkt,
weist aber einige einmalige Merkmale auf.
→ Sie sollten beim Umgang mit Software beachtet werden.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Ein Produkt wie jedes andere?
Generell kann und sollte Software als technisches Produkt betrachtet werden, das wie andere Produkte vonIngenieuren systematisch entwickelt werden kann und durch feststellbare Eigenschaften (Funktionalitat, Qualitat)gekennzeichnet ist. Software ist sogar frei von allen Unwagbarkeiten, die anderen technischen Produkten anhaften.Sie ist in diesem Sinne das ideale technische Produkt. Als Software-Leute sollten wir darum keine spezielleNachsicht erwarten. Software weist aber (wie viele andere Produkttypen) einige besondere und wenigstens in dieserKombination einmalige Merkmale auf: Sie mussen beim Umgang mit Software beachtet werden.
Allgemeines zur Softwaretechnik
Eigenschaften von Software
Software ist immateriell:
Software kann nicht ohne Weiteres betrachtet werden.Kopie und Original sind vollig gleich.Software wird nicht gefertigt, sondern nur entwickelt.Software verschleißt nicht.Software
”altert“ in dem Maße, in dem sich ihre Umwelt andert.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 31 / 634
Eigenschaften von Software
Software ist immateriell:
Software kann nicht ohne Weiteres betrachtet werden.Kopie und Original sind vollig gleich.Software wird nicht gefertigt, sondern nur entwickelt.Software verschleißt nicht.Software
”altert“ in dem Maße, in dem sich ihre Umwelt andert.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Eigenschaften von Software
Was wir als naturlich empfinden, ist an materielle Eigenschaften geknupft. An Software ist nichts naturlich.Erfahrungen aus der naturlichen Welt sind nicht ubertragbar (werden dennoch standig ubertragen, siehe z.B.Wartung). Kopie und Original sind vollig gleich. Software wird nicht gefertigt, sondern nur entwickelt. Softwareverschleißt nicht; die Wartung stellt nicht den alten Zustand wieder her, sondern einen neuen. Wiederverwendungist bei Software extrem lukrativ, wenn der Aufwand fur Anpassungen relativ gering ist. Programmiererunterschatzen meist das Problem (. . . oder uberschatzen sich selbst!)
Allgemeines zur Softwaretechnik
Eigenschaften von Software
Software hat keine naturliche Lokalitat.
Ihre Werkstoffe sind amorph und universell.
Strukturen mussen aktiv geschaffen werden.
Ein Programm realisiert keine stetige Funktion.
Korrektheit ist durch Test nicht prufbar.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 32 / 634
Eigenschaften von Software
Software hat keine naturliche Lokalitat.
Ihre Werkstoffe sind amorph und universell.
Strukturen mussen aktiv geschaffen werden.
Ein Programm realisiert keine stetige Funktion.
Korrektheit ist durch Test nicht prufbar.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Eigenschaften von Software
Naturliche Lokalitat gibt es bei Software nicht. Im Speicher eines Rechners gibt es keine schutzende Distanz. DieWerkstoffe der Software sind amorph und universell. Werkstoffe sind die eingesetzten Sprachen, meist nur dienaturliche Sprache und die Programmiersprache, evtl. noch andere, z.B. graphische Notationen.Ein Programm realisiert keine stetige Funktion. Der Zusammenhang zwischen Eingabe und Ausgabe lasst sich nichtdurch eine kontinuierliche Funktion beschreiben.
Allgemeines zur Softwaretechnik
Eigenschaften von Software
Software-Systeme sind sehr komplex:
→ Entwicklungskosten sind unvermeidlich hoch.→ Korrekte Konstruktion ist extrem schwierig.
Software spiegelt (in vielen Fallen) die Realitat wider.
“This complexity is compounded by the necessity to conform toan external environment that is arbitrary, unadaptable, andeverchanging.”
–F.P. Brooks, 1987
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 33 / 634
Eigenschaften von Software
Software-Systeme sind sehr komplex:
→ Entwicklungskosten sind unvermeidlich hoch.→ Korrekte Konstruktion ist extrem schwierig.
Software spiegelt (in vielen Fallen) die Realitat wider.
“This complexity is compounded by the necessity to conform toan external environment that is arbitrary, unadaptable, andeverchanging.”
–F.P. Brooks, 1987
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Eigenschaften von Software
Software-Systeme sind sehr komplex (nach Zahl der relevanten Entscheidungen darin), vergleichbar mit anderensehr komplexen Systemen. Es ist extrem schwer, sie trotzdem so zu konstruieren, dass sie automatisch und korrektarbeiten.
Allgemeines zur Softwaretechnik
Eigenschaften von Software
Software gilt als flexibel (d.h. leicht anderbar) 4:
Sie verbindet Hardware und Umgebung.Details der Aufgabenstellung werden in aller Regel durch Softwarerealisiert.
→ Anderungen schlagen sich entsprechend primar in der Software nieder.
4Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 34 / 634
Eigenschaften von Software
Software gilt als flexibel (d.h. leicht anderbar) 4:
Sie verbindet Hardware und Umgebung.Details der Aufgabenstellung werden in aller Regel durch Softwarerealisiert.
→ Anderungen schlagen sich entsprechend primar in der Software nieder.
4Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Eigenschaften von Software
Eigenschaften von Software
Software ist nur in dem Maße flexibel, in dem die Flexibilitat explizit eingebaut ist: Es ist leicht einen Parameter zuverandern, aber nur wenn dieser Parameter in der Software vorhanden ist.
Allgemeines zur Softwaretechnik
Software-Lebenszyklus
Entwurf
Analyse
Implemen−tierung
Test
Wartung& Evolution
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 35 / 634
Software-Lebenszyklus
Entwurf
Analyse
Implemen−tierung
Test
Wartung& Evolution
20
09
-02
-09
Software-Projekt
Softwaretechnik
Software-Lebenszyklus
Software-Lebenszyklus
Wie jeder komplexe Engineering-Prozess, so verlauft auch die Software-Entwicklung in mehreren Phasen. DieSoftware wird spezifiziert, eine Losung wird entworfen und implementiert und schließlich getestet. Nach derAuslieferung wird sie gewartet. Das heißt, Fehler werden korrigiert sowie Erweiterungen und Anpassungenvorgenommen.Diese Darstellung suggeriert, dass alle Teilphasen mehr oder minder gleich lang sind. Dies stimmt jedoch nicht.
Allgemeines zur Softwaretechnik
Aufwand in den Phasen nach McKee (1984)
Implemen−
tierung
Wartung
& Evolution
Analyse
Entwurf
Test
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 36 / 634
Aufwand in den Phasen nach McKee (1984)
Implemen−
tierung
Wartung
& Evolution
Analyse
Entwurf
Test
20
09
-02
-09
Software-Projekt
Softwaretechnik
Software-Lebenszyklus
Aufwand in den Phasen nach McKee (1984)
Hier sehen Sie eine Darstellung des Entwicklungsprozesses, in der die einzelnen Phasen entsprechend ihrer Dauergezeichnet sind.Empirische Untersuchungen zeigen, dass bis zu 80% der Kosten erst nach der Auslieferung entstehen. Das heißt, inder Wartungs- und Evolutionsphase.Diese Phase unterscheidet sich von den anderen Phasen darin, dass man sich mit einem existierenden Systemauseinander setzen muss.Diese Verteilung sagt ubrigens auch aus, dass unsere Studenten zu 80prozentiger Wahrscheinlichkeit es in ihremspateren Berufsleben mit der Wartung zu tun haben werden. Nur an wenigen Universitaten werden sie hieraufausreichend vorbereitet.
Allgemeines zur Softwaretechnik
Evolutionsphase nach Fjeldstadt und Hamlen (1984)
Änderung und TestVerstehen
Implemen−tierung
Wartung& Evolution
Analyse
Entwurf
Test
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 37 / 634
Evolutionsphase nach Fjeldstadt und Hamlen (1984)
Änderung und TestVerstehen
Implemen−tierung
Wartung& Evolution
Analyse
Entwurf
Test
20
09
-02
-09
Software-Projekt
Softwaretechnik
Software-Lebenszyklus
Evolutionsphase nach Fjeldstadt und Hamlen (1984)
Weitere Studien zeigen, dass Wartungsprogrammierer etwa die Halfte ihrer Zeit allein mit der Analyse der Softwareverbringen, ehe sie ihre Anderungen vornehmen und testen. Bei der Korrektur von Fehlern liegt der Aufwand eherbei 60%.Dieser hohe Aufwand liegt an der unzureichenden Information, die den Wartungsprogrammierern zur Verfugungsteht. Die Programmierer mussen die Informationen muhsam von Hand herleiten, weil ihnen die dazu notwendigenWerkzeuge fehlen.Wer Kosten bei der Software-Entwicklung sparen mochte, muss hier ansetzen.
Allgemeines zur Softwaretechnik
Lehman und Beladys”Gesetze“ (1985)
Gesetz vom fortwahrenden Wandel
Software lost ein Problem der realen Welt,
die reale Welt andert sich,
Software muss sich anpassen,
bis sie abgelost wird.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 38 / 634
Lehman und Beladys”Gesetze“ (1985)
Gesetz vom fortwahrenden Wandel
Software lost ein Problem der realen Welt,
die reale Welt andert sich,
Software muss sich anpassen,
bis sie abgelost wird.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Software-Evolution
Lehman und Beladys”Gesetze“ (1985)
Warum muss Software uberhaupt angepasst werden? Die Begrundung fallt leicht. . . .
Allgemeines zur Softwaretechnik
Lehman und Beladys”Gesetze“ (1985)
Gesetz der zunehmendenKomplexitat
die Komplexitat derSoftware erhoht sichbeim Wandel,
wenn keineGegenmaßnahmenergriffen werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 39 / 634
Lehman und Beladys”Gesetze“ (1985)
Gesetz der zunehmendenKomplexitat
die Komplexitat derSoftware erhoht sichbeim Wandel,
wenn keineGegenmaßnahmenergriffen werden
20
09
-02
-09
Software-Projekt
Softwaretechnik
Software-Evolution
Lehman und Beladys”Gesetze“ (1985)
Leider geht mit dem Zwang zur Anderung der Anstieg der Komplexitat der Software einher. Hier sehen Sie eineGrafik von Many Lehman, der sich als einer der ersten mit dem Phanomen der Software-Evolution empirischauseinander gesetzt hat.Sie sehen hier den Umfang eines Systems, gemessen in der Anzahl seiner Module, uber die Zeit. Die Messpunktesind die verschiedenen Releases der Software.Sie bemerken das Wachstum. Aber auch gleichzeitig die Verlangsamung des Wachstums. Die Dauer zwischenReleases nimmt zu.Um diesem Trend entgegen zu wirken, mussen Sie Maßnahmen ergreifen, um die Komplexitat einzudammen.
Allgemeines zur Softwaretechnik
Software-Evolution
Konsequenzen:
Anderbarkeit ist eine Schlusselqualitat
Anderbarkeit muss fruhzeitig angestrebt werden
sie lasst sich nicht nachtraglich uberstulpen
wer sie vernachlassigt, nimmt einen Kredit auf, den er teuer abzahlenwird
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 40 / 634
Allgemeines zur Softwaretechnik
Wo liegen die Probleme in der Softwaretechnik?
In den spaten 60er Jahren:
Manche Software-Projekte sind selbst mit gigantischem Aufwandnicht zu schaffen.
In vielen anderen Fallen wird der Abschluss nur mit unbefriedigendenResultaten, viel zu spat und/oder mit extremenKostenuberschreitungen erreicht.
Andererseits erzielt die Hardware-Entwicklung atemberaubendeFortschritte.
“The whole trouble comes from the fact that there is so muchtinkering with software. It is not made in a clean fabricationprocess, which it should be. What we need is softwareengineering.”
–F.L. Bauer, 1968
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 41 / 634
Wo liegen die Probleme in der Softwaretechnik?
In den spaten 60er Jahren:
Manche Software-Projekte sind selbst mit gigantischem Aufwandnicht zu schaffen.
In vielen anderen Fallen wird der Abschluss nur mit unbefriedigendenResultaten, viel zu spat und/oder mit extremenKostenuberschreitungen erreicht.
Andererseits erzielt die Hardware-Entwicklung atemberaubendeFortschritte.
“The whole trouble comes from the fact that there is so muchtinkering with software. It is not made in a clean fabricationprocess, which it should be. What we need is softwareengineering.”
–F.L. Bauer, 1968
20
09
-02
-09
Software-Projekt
Softwaretechnik
Entstehung der Softwaretechnik
Wo liegen die Probleme in der Softwaretechnik?
Kurz: Es ist nicht alles machbar, was prinzipiell moglich sein musste. Fur diese Probleme kam das SchlagwortSoftware Crisis in Mode. Die Software-Krise war Anlass fur viele Diskussionen und Tagungen. Auf derNATO-Konferenz in Garmisch (1968) pragte F.L. Bauer das Wort Software Engineering als Provokation (siehe dazuBauer, 1993).
Allgemeines zur Softwaretechnik
Wie viel hat sich bis heute daran geandert?
Beispiel
Fehler:
vollstandiger Batterieausfall in Fahrzeugen eines deutschenAutomobil-Herstellers
Ursache:
Fehler in der software-gesteuerten Innenbeleuchtung
Folge:
Ruckrufaktion mit einem (geschatzten) Schaden von mehrerenMillionen DEM
Partsch (1998)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 42 / 634
Allgemeines zur Softwaretechnik
Wie viel hat sich bis heute daran geandert?
Beispiel
Fehler:
Bei der rechnergestutzten Auswertung der OB-Wahl in Neu-Ulm 1994wurde zunachst eine Wahlbeteiligung von 104% festgestellt.
Ursache:
In der Auswertungssoftware hatte sich ein mysterioser Faktor 2eingeschlichen.
Folge:
Neuauszahlung
Partsch (1998)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 43 / 634
Allgemeines zur Softwaretechnik
Wie viel hat sich bis heute daran geandert?
Beispiel
Fehler:
USS Yorktown treibt wahrend eines Manovers im September 1997manovrierunfahig bei Cape Charles, VA.
Ursache:
Fehler in einer Routine zum Abfangen einer Division durch Null in einerWindows NT Applikation. Die
”Null“ wurde als manuelle Eingabe einer
enormen Datenmenge interpretiert.
Folge:
“Atlantic Fleet officials said the ship was dead in water for about 2hours and 45 minutes.”
Neumann (1999)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 44 / 634
Allgemeines zur Softwaretechnik
Produktgarantie?
Disclaimer of Warranty:
This car is provided under this license on an “as is” basis, withoutwarranty of any kind, either expressed or implied, including,without limitation, warranties that the car is free of defects,merchantable, fit for a particular purpose or non-infringing. Theentire risk as to the quality and performance of the car is with you.Should any car prove defective in any respect, you (not the initialdeveloper or any other contributor) assume the cost of any necessaryservicing, repair or correction.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 45 / 634
Allgemeines zur Softwaretechnik
Garantien uber Software?
Disclaimer of Warranty:
This software is provided under this license on an “as is” basis,without warranty of any kind, either expressed or implied,including, without limitation, warranties that the software is freeof defects, merchantable, fit for a particular purpose ornon-infringing. The entire risk as to the quality and performance ofthe software is with you. Should any software prove defective inany respect, you (not the initial developer or any other contributor)assume the cost of any necessary servicing, repair or correction.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 46 / 634
Garantien uber Software?
Disclaimer of Warranty:
This software is provided under this license on an “as is” basis,without warranty of any kind, either expressed or implied,including, without limitation, warranties that the software is freeof defects, merchantable, fit for a particular purpose ornon-infringing. The entire risk as to the quality and performance ofthe software is with you. Should any software prove defective inany respect, you (not the initial developer or any other contributor)assume the cost of any necessary servicing, repair or correction.
20
09
-02
-09
Software-Projekt
Softwaretechnik
Entstehung der Softwaretechnik
Garantien uber Software?
An solche Disclaimer haben wir uns schon lange gewohnt. Stellen Sie sich vor, sie lesen einen solchen in derBetriebsanleitung Ihres Autos. Sie wurden das Auto sofort zuruckgeben.Ubrigens: Solche Disclaimer sind nach deutschem Recht hinfallig. Stellen Sie jemandem auf dem Netz einProgramm zur Verfugung, sind Sie automatisch in der Haftung. Grobe Fahrlassigkeit und Vorsatz lassen sich inDeutschland nicht ausschließen.Spezifizieren Sie nicht den Zweck Ihres Programms, so wird zu Grunde gelegt, was man ublicherweise von einemProgramm dieser Art erwartet.
Allgemeines zur Softwaretechnik
Ingenieursdisziplin (Shaw und Garlan 1996)
Kunst
Talentierte Amateure
• Herstellung fur die Verwendung,
• verschwenderische Verwendung• gelegentliche Ubermittlung• wahlloser Fortschritt
weniger fur den Verkauf
verfugbaren Materials
• intuitiv und ad hoc
ProduktionHandwerk
• pragmatische Verfeinerungen
• Herstellung fur den Verkauf
• Ausbildung in der Ausfuhrung
• etabliertes Vorgehen
• okonomische Betrachtungder Materialien
Geubte Arbeiter
Wissenschaft
Ingenieursdisziplin
• Analyse und Theorie
• Einfuhrung neuer
• Marktsegmentierung durchProduktvielfalt
Wissenschaft
Anwendungen durch Analyse
Ausgebildete Personen
• Fortschritt basiert auf
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 47 / 634
Allgemeines zur Softwaretechnik
Definition
Softwaretechnik:
Entdeckung und Anwendung solider Ingenieur-Prinzipien mit demZiel, auf wirtschaftliche Art Software zu bekommen, die zuverlassig istund auf realen Rechnern lauft.
–F.L. Bauer
Herstellung und Anwendung einer Software, wobei mehrere Personenbeteiligt sind oder mehrere Versionen entstehen.
–D.L. Parnas
(1) The application of a systematic, disciplined, quantifiable approachto the development, operation, and maintenance of software; that is,the application of engineering to software. (2) The study ofapproaches as in (1). IEEE Std 610.12-1990 (1990)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 48 / 634
Definition
Softwaretechnik:
Entdeckung und Anwendung solider Ingenieur-Prinzipien mit demZiel, auf wirtschaftliche Art Software zu bekommen, die zuverlassig istund auf realen Rechnern lauft.
–F.L. Bauer
Herstellung und Anwendung einer Software, wobei mehrere Personenbeteiligt sind oder mehrere Versionen entstehen.
–D.L. Parnas
(1) The application of a systematic, disciplined, quantifiable approachto the development, operation, and maintenance of software; that is,the application of engineering to software. (2) The study ofapproaches as in (1). IEEE Std 610.12-1990 (1990)2
00
9-0
2-0
9
Software-Projekt
Softwaretechnik
Merkmale der Softwaretechnik
Software Engineering wurde oft definiert. Drei wichtige Definitionen sind hier angegeben.Die IEEE-Definition ist problematisch, wenn nicht falsch, weil sie wertet und fordert, also ein Ideal beschreibt, undeinen anderen undefinierten Begriff zu Grunde legt.
Allgemeines zur Softwaretechnik
Abschrift aus dem Vorwort zum Vorlesungsskript Werkstoffe derElektrotechnik (Prof. Fischer, Uni-Dortmund, 1977)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 50 / 634
Allgemeines zur Softwaretechnik
Merkmale der alten Ingenieurdisziplinen
Kostendenken als Grundlage von Bewertungen
praktischer Erfolg als einziger zulassiger Beweis
Qualitatsbewusstsein als Denkprinzip
Einfuhrung und Beachtung von Normen (Schnittstellen, Verfahren,Begriffe)
Denken in Baugruppen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 51 / 634
Merkmale der alten Ingenieurdisziplinen
Kostendenken als Grundlage von Bewertungen
praktischer Erfolg als einziger zulassiger Beweis
Qualitatsbewusstsein als Denkprinzip
Einfuhrung und Beachtung von Normen (Schnittstellen, Verfahren,Begriffe)
Denken in Baugruppen
20
09
-02
-09
Software-Projekt
Softwaretechnik
Merkmale der Softwaretechnik
Merkmale der alten Ingenieurdisziplinen
Definition und Anwendung von Methoden, Bereitstellung und Verwendung von Werkzeugen sind allgemeinbewahrte Ansatze, also nicht typisch fur Ingenieure. Ingenieur-spezifisch sind dagegen:
• Kostendenken als Grundlage von Bewertungen (Achtung, es geht hier um die Gesamtkosten, nicht nur um Geld!)
• praktischer Erfolg als einziger zulassiger Beweis: nur was gezahlt oder gemessen wurde, ist ein akzeptables Argument;
• Qualitatsbewusstsein: hohe Qualitat ist ein Prinzip der unspezifischen Kostensenkung; kommt aus der handwerklichenTradition, die die Ingenieure ubernommen haben;
• Normen (vgl. Norm fur Passstifte); Merke: Eine Norm wird immer beachtet!
• Baugruppen: Durch Normen entsteht die Moglichkeit, Baugruppen zu verwenden, also die Losung der Teilproblemeauszuklammern.
Allgemeines zur Softwaretechnik
Wiederholungsfragen
Was sind die besonderen Eigenschaften von Software?
Was folgt aus diesen Eigenschaften fur die Softwareentwicklung?
Aus welchen Phasen besteht der Software-Lebenszyklus?
Was ist die Besonderheit der Wartungsphase und was folgt daraus furdie Softwareentwicklung?
Warum muss Software uberhaupt angepasst werden? Welche Folgenkonnen diese Anderungen haben?
Welche Einsichten fuhrten zur Entstehung der Softwaretechnik? Mitwelchen Problemen ist die Softwaretechnik nach wie vor konfrontiert?
Was ist Softwaretechnik? Welche Ziele verfolgt sie?
Was sind die Kennzeichen einer Ingenieursdisziplin und wie entstehtsie?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 52 / 634
Planung eines Software-Projekts
Planung eines Software-Projekts
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der Softwaretechnik
3 PlanungProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 53 / 634
Planung eines Software-Projekts
Projekt
Definition
Projekt: eine fur begrenzte Zeit mit bestimmtem Ziel bestehendeOrganisation mit all ihren Bestandteilen, Beziehungen im Innern und nachaußen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 54 / 634
Planung eines Software-Projekts
Planung
Planung
am Anfang:
Gliederung in Phasen, Aktivitaten, Arbeitspakete,zeitlicher Ablauf (Meilensteine),Arbeitsorganisation,Aufbau der Dokumentation.
wahrend des Projekts:
Controlling (d.h. die Uberwachung des Projektfortschritts),Reaktion auf Abweichung (Anpassung des Plans).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 55 / 634
Planung
Planung
am Anfang:
Gliederung in Phasen, Aktivitaten, Arbeitspakete,zeitlicher Ablauf (Meilensteine),Arbeitsorganisation,Aufbau der Dokumentation.
wahrend des Projekts:
Controlling (d.h. die Uberwachung des Projektfortschritts),Reaktion auf Abweichung (Anpassung des Plans).
20
09
-02
-09
Software-Projekt
Planung
Projekt
Planung
Planung hat im Software-Projekt zwei verschiedene Bedeutungen: Zu Beginn des Projekts mussen Plane aufgestelltwerden fur die Gliederung in Phasen, den fur die Arbeitsorganisation, den fur den Aufbau der Dokumentation, undden fur die Prufungen. Die Existenz und die Qualitat dieser Plane hat zentrale Bedeutung fur den Erfolg desProjekts.Wahrend des Projekts bleibt die Planung eine Daueraufgabe, weil sich die Realitat meist nicht an unsere Planungenhalt. Notwendig ist ein Kompromiss zwischen der starrsinnigen Verteidigung von Planen, die offenkundig nichteinzuhalten sind, und der laufenden Anpassung der Plane an den realen Stand. Eine gewisse Spannung zwischenPlan und Realitat ist normal. Planung und Planverfolgung sind die wichtigsten Aufgaben der Projektleitung. Engdamit verbunden sind Controlling (d.h. die Uberwachung der Ausgaben in einem Projekt) und Qualitatssicherung(d.h. die Prufung aller Teilresultate und Resultate).
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 56 / 634
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
20
09
-02
-09
Software-Projekt
Planung
Projekt
Elemente eines Projekts
Fur das Verstandnis von Projekten sind einige Grundbegriffe notwendig. Keiner dieser Begriffe ist spezifisch fur einSoftware-Projekt. Insgesamt kann angemerkt werden, dass allgemeine Aussagen zu Projekten (jedweder Form) inaller Regel auch fur Software-Projekte gelten. Die Natur der Software, die in einem Software-Projekt entwickeltwerden soll, kommt vielmehr in den Inhalten der Arbeitspakete zum Tragen.
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
Definition
Aktivitat: Arbeitseinheit mitprazisem Anfangs und -enddatum
enthalt Aufgaben
benotigt Ressourcen
produziert Arbeitsprodukt
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 57 / 634
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
Definition
Projektfunktion: Aktivitat, die diegesamte Projektlaufzeit uberspannt.Beispiele:
Projektmanagement
Konfigurationsmanagement
Qualitatssicherung.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 58 / 634
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
AnalysephaseDefinition
Arbeitspaket: Spezifikation fur einezu erledigende Arbeit. Definiert
Arbeitsprodukt,
Personalbedurfnisse,
erwartete Entwicklungsdauer,
verwendete Ressourcen,
Akzeptanzkriterien,
Namen desHauptverantwortlichen
und sonstige relevante Aspekteder Arbeit.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 59 / 634
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
AnalysephaseDefinition
Arbeitsprodukt ein konkretesErgebnis einer Projektfunktion oder-aktivitat. Beispiele:
Anforderungsspezifikation,
Projektplan,
funktionale Spezifikation,
Entwurfsdokumente,
Benutzerhandbuch,
Testplan
oder Protokolle von Reviewsoder Meetings.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 60 / 634
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
Definition
Meilenstein:
Menge von Kriterien
und vorgesehener Zeitpunkt
und erreichter Zeitpunkt
fur die Abnahme eines(Zwischen-)Resultats
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 61 / 634
Planung eines Software-Projekts
Elemente eines Projekts
Abnahmedurch Kunden abgenommene
Anforderungsspezifikation
Anforderungs−spezifikationSpezifikation
der Anforderungen
Prototyp
Soll−Beschreibung
Soll−Analyse
Ist−Analyse
Ist−Beschreibung
Prototyp
erstellen
Analysephase
Definition
Baseline: Arbeitsprodukt,
formal begutachtet undakzeptiert,
nur durch formalenkontrollierten Anderungsprozessanderbar;
bildet Basis fur nachfolgendeArbeitsaktivitaten.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 62 / 634
Planung eines Software-Projekts
Vorgehen zur Planung
1 Auswahl eines geeigneten Prozesses (oder Prozessmodells)
2 Grobe Abschatzung des Gesamtumfangs und des Gesamtaufwands
3 Aufstellen eines Zeitplans
4 Aufstellen eines Dokumentationsplans
5 Aufstellen eines Prufplans
6 Aufstellen eines Organisationsplans
7 Definition der Meilensteine (1-6)
und naturlich: Iteration dieser Schritte, bis die Resultate zusammenpassen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 63 / 634
Planung eines Software-Projekts
Vorgehen zur Planung
Wo es definierte Prozessmodelle gibt, kann (und muss) die Projektleiterindie Vorlagen fur die Plane aus der Schublade (d.h. aus dem Intranet)nehmen.
Der Projektplan sollte sorgfaltig gepruft werden!
Der Projektplan entsteht mit dem Projekt und wird im Verlauf desProjekts fortgeschrieben, aber nicht laufend geandert.
Der Projektplan ist Gegenstand der Anderungskontrolle.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 64 / 634
Planung eines Software-Projekts
Inhalt des Projektplans
Plan macht prinzipiell Aussagen zu den folgenden W-Punkten:
warum
was getan wird,
fur wieviel Geld,
von wem,
wann und
womit, d.h. unter Einsatz welcher Hilfsmittel und Techniken.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 65 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Ubersicht
0. Version und Anderungsgeschichte1. Einleitung2. Projektorganisation3. Managementprozess4. Technischer Prozess5. Arbeitspakete, Zeitplan und Budget6. Zusatzliche Elemente7. Index8. Anhang
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 66 / 634
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Ubersicht
0. Version und Anderungsgeschichte1. Einleitung2. Projektorganisation3. Managementprozess4. Technischer Prozess5. Arbeitspakete, Zeitplan und Budget6. Zusatzliche Elemente7. Index8. Anhang2
00
9-0
2-0
9
Software-Projekt
Planung
Inhalt
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Der Projektplan, wie jedes andere Dokument auch, erhalt eine Versionsnummer. Anderungen des Projektplans sindunausweichlich (er wird schrittweise verfeinert und angepasst). Die Anderungen mussen dokumentiert und
nachvollziehbar sein. Der Abschnitt “Version und Anderungsgeschichte” enthalt diese Information.Die Einleitung gibt einen Uberblick uber das Projekt und das Produkt, die Liste der auszuliefernden Dinge, der Planfur die Entwicklung und die Fortfuhrung des Projektplans, Referenzmaterial sowie Definitionen und Akronyme.Der Abschnitt “Projektorganisation” spezifiziert das Prozessmodell des Projekts, die Organisationsstruktur, dieGrenzen und Schnittstellen der Organisation und die individuellen Verantwortlichkeiten.Der Abschnitt “Managementprozess” spezifiziert die Managementziele und -prioritaten, Annahmen undEinschrankungen, Risiken und deren Behandlung sowie Kontrollmechanismen und den Personalplan.Der Abschnitt “Technischer Prozess” spezifiziert die technischen Methoden, Werkzeuge und Techniken, die imProjekt benutzt werden sollen. Außerdem wird der Dokumentationsplan und die Plane fur die Projektfunktionenspezifiziert, wie etwa die Qualitatssicherung und das Konfigurationsmanagement.Der Abschnitt “Arbeitspakete” spezifiziert die Arbeitspakete, ihre Abhangigkeiten und Beziehungen, die benotigtenRessourcen, Zuteilung des Budgets und Ressourcen auf Arbeitspakete sowie den Zeitplan.Der Abschnitt “Zusatzliche Elemente” enthalt Plane fur zusatzliche Komponenten.
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Einleitung
1.1 Projektubersicht
Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitaten und-produkte, Hauptmeilensteine, benotigte Ressourcen, grober Zeitplanund Budget; Kontaktdaten des Kunden
1.2 Auszuliefernde Produkte
alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatumund -ort sowie deren Anzahl6
1.3 Evolution des Plans
Plan fur vorausgesehene und nicht vorausgesehene Aktualisierung desProjektplans und deren Bekanntmachung
1.4 Referenzen
1.5 Definitionen und Akronyme
6Die Anforderungsspezifikation ist ein separates Dokument!Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 67 / 634
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Einleitung
1.1 Projektubersicht
Zusammenfassung der Ziele, Resultate, Hauptarbeitsaktivitaten und-produkte, Hauptmeilensteine, benotigte Ressourcen, grober Zeitplanund Budget; Kontaktdaten des Kunden
1.2 Auszuliefernde Produkte
alle an den Kunden auszuliefernde Produkte mit Auslieferungsdatumund -ort sowie deren Anzahl6
1.3 Evolution des Plans
Plan fur vorausgesehene und nicht vorausgesehene Aktualisierung desProjektplans und deren Bekanntmachung
1.4 Referenzen
1.5 Definitionen und Akronyme
6Die Anforderungsspezifikation ist ein separates Dokument!
20
09
-02
-09
Software-Projekt
Planung
Inhalt
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Die Referenzen enthalten Verweise auf alle Dokumente und andere Informationsquellen, die im Projektplanreferenziert werden. Hierfur gelten die ublichen Zitierregeln.Der Abschnitt “Definitionen und Akronyme” beschreibt alle Begriffe, die fur das Verstandnis des Projektplansnotwendig sind, auch in Form von Verweisen auf entsprechende Dokumente mit deren Definition.Es handelt sich hier nicht um das Glossar der Anforderungsspezifikation, von dem spater noch die Rede sein wird.Der Projektplan kann aber auf dieses Glossar verweisen.
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Projektorganisation
2.1 Prozessmodell
Beziehungen zwischen den Projektfunktionen und -aktivitaten mitHauptmeilensteinen, Baselines, Reviews, Produkte (interne undauszuliefernde) und Abschlusse
2.2 Organisationsstruktur
interne Managementstruktur (z.B. durch Organigramme):Weisungsbefugnis, Verantwortlichkeit und Kommunikation im Projekt7
2.3 Organisationsgrenzen und -schnittstellen
zwischen ubergeordneter Organisation, Kundenorganisation undUntervertragsnehmer
2.4 Verantwortlichkeiten
Auflistung aller Projektfunktionen und -aktivitaten unter Nennung derVerantwortlichen
7Kontaktdaten aller Beteiligter nicht vergessen!Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 68 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Managementprozess
3.1 Managementziele und -prioritaten
Beispiele: Haufigkeit und Mechanismen der Berichterstattung; relativePrioritaten zwischen Anforderungen, Zeitplan und Budget; Absicht zurWiederverwendung existierender Software
3.2 Annahmen, Abhangigkeiten und Einschrankungen
Annahmen, auf denen das Projekt beruht; externe Ereignisse, vondenen es abhangt; Beschrankungen, unter denen das Projektdurchgefuhrt wird
3.3 Risikomanagement
Identifikation und Bewertung von Risiken; Mechanismen fur Verfolgungder Risikofaktoren; Notfallplane;Beispiele: Risiken mit Vertragen, technologische Risiken, Große undKomplexitat der Aufgabe, Personal, Akzeptanz des Kunden etc.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 69 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Managementprozess (Fortsetzung)
3.4 Projektuberwachung
Berichtswesen, Formate fur Berichte, Informationsflusse, Reviews undAudits; auf der Ebene von Arbeitspaketen; Beziehung zuProjektfunktionen (bspw. Qualitatssicherung,Konfigurationsmanagement)
3.5 Mitarbeiter
Anzahl und Typen der notwendigen Mitarbeiter; erforderlicheFahigkeiten, Beginn und Dauer der Mitarbeit; Methoden zurAnwerbung, Ausbildung, Bindung und Ausgliederung von Mitarbeitern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 70 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Technische Prozesse
4.1 Methoden, Werkzeuge und Techniken
Entwicklungsplattform, Entwicklungsmethode, Programmiersprachesowie andere Notationen, Techniken und Methoden, um das Systemund andere auszuliefernde Produkte zu spezifizieren, entwerfen,konstruieren, testen, integrieren, dokumentieren, modifizieren oderpflegen;technische Standards, Richtlinien, Zertifizierungskriterien
4.2 Dokumentationsplan
Anforderungen an die Dokumentation, Meilensteine, Baselines, Reviewsund Abnahme der Software-Dokumentation;Style-Guide, Namenskonventionen, Dokumentationsformate
4.3 Unterstutzende Projektfunktionen
z.B. Konfigurationsmanagement und Qualitatssicherungmit Verantwortlichkeiten, Ressourcen, Zeitplanen und Budget
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 71 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Arbeitspakete, Zeitplan und Budget
5.1 Arbeitspakete
eindeutig identifizierbar (z.B. mit Nummer);Zerlegung der Arbeitspakete
5.2 Abhangigkeiten
Abhangigkeiten zwischen Arbeitspaketen und zu externen Elementen;Reihenfolge der Abarbeitung
5.3 Ressourcenanforderung
Dauer und Ressourcen;Beispiele: Anzahl und Qualifikation des Personals, Hardware,unterstutzende Software, Buro- und Laborraume, Reisekosten,Wartungskosten
5.4 Zuteilung des Budgets und der Ressourcen auf Projektfunktionen undAktivitaten
5.5 Zeitplan
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 72 / 634
Planung eines Software-Projekts
Aufbau eines Projektplans nach IEEE-Std-1058 (1987)
Beispiele fur zusatzliche Elemente:
Managementplane fur Unterauftragsnehmer
Ausbildungsplane
Beschaffungsplane fur Hardware
Raumplane
Installationsplane
Plane fur die Konvertierung von Daten
Plane fur die Ubergabe des Systems (intern, extern)
Plane fur die Wartung und Evolution
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 73 / 634
Planung eines Software-Projekts
Zeitplan: Aktivitaten und Dauer (Gantt-Diagramme)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 74 / 634
Zeitplan: Aktivitaten und Dauer (Gantt-Diagramme)
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Aktivitaten und Dauer (Gantt-Diagramme)
Die Gantt-Notation ist nach ihrem Erfinder, Henry L. Gantt (1917), benannt. Sie beschreibt kausaleAbhangigkeiten einzelner Aktivitaten sowie deren zeitlichen Verlauf.Das Projekt wird zunachst in einzelne Aktivitaten gegliedert. Deren Aufwand wird geschatzt. Mogliche Aktivitatenbehandeln wir in spateren Kapiteln.Die Granularitat der Aktivitaten muss angemessen sein. Die in diesem Beispiel gewahlte ist es sicher nicht. Jedetaillierter die Angabe desto leichter fallt die Schatzung (und desto aufwandiger die Planung; was sich jedoch inder Regel auszahlt). “Anfangern” ist eine moglichst feingranulare Darstellung zu empfehlen, da ihre Schatzungdadurch zuverlassiger wird.
Planung eines Software-Projekts
Zeitplan: Meilensteine
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 75 / 634
Zeitplan: Meilensteine
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Meilensteine
An verschiedenen Zeitpunkten des Projekts werden Meilensteine gesetzt.Ein Meilenstein ist ein Zeitpunkt, zu dem ein prufbares Ergebnis vorliegen muss.Meilensteine erlauben die Beobachtung des Projektfortschritts. Die Projektverfolgung und die Qualitatssicherungwerden interne Meilensteine setzen, also solche die nur dem Projekt bekannt sind, wie zum Beispiel das Review desEntwurfs. Zumindest bei jeder Ubergabe eines Zwischenprodukts (Entwurfsdokument, Quellcode etc.) sollte ein
Meilenstein definiert werden, der die Ubergebenden und Empfanger des Zwischenprodukts einbezieht. DerMeilenstein legt die Kriterien fur eine erfolgreiche Ubergabe fest.Externe Meilensteine involvieren den Kunden, z.B. die Abnahme der Spezifikation und der Akzeptanztest.
Planung eines Software-Projekts
Zeitplan: Abhangigkeiten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 76 / 634
Zeitplan: Abhangigkeiten
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Abhangigkeiten
Zwischen den Aktivitaten existieren kausale Abhangigkeiten, die festgelegt werden mussen. Beispielsweise kann nurgetestet werden, wenn der Quellcode existiert.Die kausalen Abhangigkeiten fuhren zu einer partiellen Sequenzialisierung der Aktivitaten.
Planung eines Software-Projekts
Zeitplan: Verfeinerung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 77 / 634
Zeitplan: Verfeinerung
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Verfeinerung
Grobgranulare Aktivitaten sollten verfeinert werden (siehe oben). Die Verfeinerung erlaubt auch eine getreuereDarstellung der Abhangigkeiten zwischen den Aktivitaten. So konnen zum Beispiel Testfalle fur den Black-Box-Test(siehe das spatere Kapitel uber Tests) bereits beim Vorliegen der Spezifikation vorbereitet werden.Dadurch kann die Moglichkeit zur Parallelisierung der Aktivitaten erhoht werden.
Planung eines Software-Projekts
Zeitplan: Ressourcen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 78 / 634
Zeitplan: Ressourcen
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Ressourcen
Ressourcen im Software-Projekt sind in der Regel menschliche Wesen. Bei der Entwicklung eingebetteter Systemeist z.B. auch die Zielhardware eine Ressource, die eingeplant werden muss. In vielen Fallen wird sie parallel zurSoftware entwickelt.Der Kunde ist eine wichtige Ressource, die eingeplant werden muss, und selten verfugbar ist.Der Begriff “Ressource” auf Menschen angewandt klingt sehr technokratisch. Das ist hier nicht so gemeint.
Planung eines Software-Projekts
Zeitplan: Einplanung der Ressourcen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 79 / 634
Zeitplan: Einplanung der Ressourcen
20
09
-02
-09
Software-Projekt
Planung
Zeitplan
Zeitplan: Einplanung der Ressourcen
Schließlich werden die Ressourcen den Aktivitaten zugewiesen. Dadurch kann sich die Dauer von Aktivitatenverlangern oder verkurzen. Sie verlangern sich zum Beispiel, weil ein Entwickler auch fur quasi-zeitgleicheAktivitaten eingeplant wurde und selbstverstandlich eine begrenzte wochentliche Arbeitszeit hat. Sie verkurzt sich,wenn mehrere Entwickler einer Aktivitat zugeordnet werden. Aber Achtung! Im Gegensatz zu anderen Projektengilt im Software-Projekt nicht:
Dauer = AufwandAnzahl Personen
Je mehr Personen an einer Aktivitat beteiligt sind desto hoher ist der Aufwand fur Kommunikation undAbstimmung. Statt dessen gilt der Rat: Weniger und bessere Leute nehmen!Ein noch haufiger Irrglaube ist, dass man durch spate Hinzunahme zusatzlicher Leute einen in Schieflage geratenenPlan noch einhalten kann. Der Aufwand erhoht sich dann nicht nur durch erhohte Kommunikation, sondern auchdurch die Einarbeitung der Neuen.
Planung eines Software-Projekts
Kritischer Pfad
Definition
Kritischer Pfad: die von der Dauer her langste Kette von Aktivitaten.
bestimmt die Dauer des Projekts;
Verspatungen in dieser Kette schlagen sich auf die Dauer des Projektsnieder;
muss wahrend des Projektverlaufs stets im Auge behalten werden.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 80 / 634
Planung eines Software-Projekts
Geschriebene Codezeilen im SWP 05/06
0
2500
5000
7500
10000
12500
15000
17500
20000
22500
25000
27500
LOC pro Gruppe
TestCode
lila = Testcode, orange = Produktionscode
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 81 / 634
Planung eines Software-Projekts
Aufwandsverteilung im SWP 05/06
Plan Spez. Arch. Impl. Test Doku Bespr. Sonst.
0
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
Aufwand nach Phasen
Aufw
and/
h
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 82 / 634
Planung eines Software-Projekts
Note versus Aufwand
1 1,5 2 2,5 3 3,5 40
500
1000
1500
2000
2500
3000
3500
Aufwand zu Note
Note
Auf
wan
d/h
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 83 / 634
Planung eines Software-Projekts
Planung: Soll und Ist
0 1000 2000 3000 4000 5000 60000
1000
2000
3000
4000
5000
6000
Plan zu IstStunden
geplante Stunden
tats
ächl
iche
Stu
nden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 84 / 634
Planung eines Software-Projekts
Arbeitsstunden pro Tag
0
100
200
300
400
500
600
700
800
900
1000
1100
Stunden nach Tag
Tag der Projektlaufzeit
Ges
amts
tund
en
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 85 / 634
Planung eines Software-Projekts
Risiken
If you do not actively attack the risks in your project, they willactively attack you.
– Gilb (1988)
Definition
Ein Risiko ist ein Ereignis, dessen Eintreten den Erfolg des Projektsentscheidend behindern kann.Quantifizierte Risikohohe = Eintrittswahrscheinlichkeit × max.Schadenshohe
Risikomanagement kummert sich um Risiken, bevor sie auftreten.Krisenmanagement kummert sich um aufgetretene Risiken.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 86 / 634
Planung eines Software-Projekts
Risiko-Management
Risikoanalyse
Identifizierung der Risiken
Einschatzung der Eintrittswahrscheinlichkeit
Einschatzung des potentiellen Schadens
Risikomaßnahmen: Planung von Gegenmaßnahmen
Vermeidung: Unterlassung der Aktivitat
Verminderung/Begrenzung auf akzeptables Maß, z.B. Streuung oderHaftung bis zu einem Limit
Abwalzung: z.B. Unterauftragnehmer
Akzeptanz, wenn Kosten/Nutzen im Verhaltnis stehen
Risiko-Controlling: Monitoring wahrend des Projekts
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 87 / 634
Planung eines Software-Projekts
Risiken identifizieren
Produktimmanent
Produkt
Technologie
z.B. ungenaue Anforderungen
z.B. instabile Anforderungen
Projektimmanent
Mensch
Vorgehen
Management/Organisation
Infrastruktur
z.B. Ressourcenprobleme
z.B. mangelnde Motivation
Umfeldabhangig
Organisatorische Einbettung
Politik
Recht
Kultur
z.B. Verschiebung vonPrioritaten
z.B. Abhangigkeit zu anderenProjekten
→ Historie: aus abgeschlossenen Projekten lernen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 88 / 634
Risiken identifizieren
Produktimmanent
Produkt
Technologie
z.B. ungenaue Anforderungen
z.B. instabile Anforderungen
Projektimmanent
Mensch
Vorgehen
Management/Organisation
Infrastruktur
z.B. Ressourcenprobleme
z.B. mangelnde Motivation
Umfeldabhangig
Organisatorische Einbettung
Politik
Recht
Kultur
z.B. Verschiebung vonPrioritaten
z.B. Abhangigkeit zu anderenProjekten
→ Historie: aus abgeschlossenen Projekten lernen
20
09
-02
-09
Software-Projekt
Planung
Erfahrungen aus dem SWP 05/06
Risiken im Software-Projekt
Zu Risiken und Nebenwirkungen fragen Sie Ihren
. . . gesunden Menschenverstand, erfahrene Software-Entwickler, die Tageszeitung, die Literatur uber
Softwaretechnik . . .
Planung eines Software-Projekts
Personalausfall
0 1 2 3 4 5 split0%
5%
10%
15%
20%
25%
30%
35%
40%
Personalausfall
Ausfälle
Häu
figke
it
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 90 / 634
Planung eines Software-Projekts
Note versus Personalausfall
0 1 2 3 4 5 split1
1,5
2
2,5
3
3,5
4
Note nach Personalausfall
Ausfälle
Dur
chsc
hnitt
snot
e
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 91 / 634
Planung eines Software-Projekts
Projektabbruch
31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volleFunktionalitat (Standish Group 1994)8
Gilt: Abbruch = Misserfolg wegen mangelhaftem Management?
8Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungenmit unterschiedlichen Ergebnissen Buschermohle u. a. (2006); Sauer und Cuthbertson(2003); Standish Group (2004)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 92 / 634
Projektabbruch
31% aller Software-Projekte werden vor Abschluss abgebrochen; weitere53% sprengen den Zeit- oder Kostenrahmen oder liefern nicht die volleFunktionalitat (Standish Group 1994)8
Gilt: Abbruch = Misserfolg wegen mangelhaftem Management?
8Dieser Bericht ist nicht unumstritten. Es gibt eine Reihe anderer Untersuchungenmit unterschiedlichen Ergebnissen Buschermohle u. a. (2006); Sauer und Cuthbertson(2003); Standish Group (2004)
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Projektabbruch
Die Statistik uber den Abbruch von Projekten legt die Folgerung nahe, dass die Projekte abgebrochen wurden, weilsie schlecht gefuhrt wurden. Diese Implikation ist falsch und gefahrlich. Sie ist falsch, weil viele gut gefuhrteProjekte abgebrochen werden, weil sich ihre ursprunglichen Annahmen geandert haben. Sie werden ausvertretbarem Grund beendet. Dies ist vor allem in Feldern mit schnellem Wandel haufig anzutreffen.Die Implikation ist gefahrlich, weil Projektmanager sich der Verfuhrung konfrontiert sehen, ein eigentlich obsoletesProjekt weiterzufuhren, um nicht als Versager dazustehen. Es gibt oft gute, vertretbare Grunde, ein Projektabzubrechen. Der Abbruch ist dann weiser als die Fortfuhrung.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Unvollstandige Anforderungen (13 %9):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens haufig
Projekt startet ohne klare Idee derBedurfnisse und Prioritaten derStakeholder.
Stakeholder konnen sich nicht aufAnforderungen einigen.
9relativ zu den abgebrochenen ProjektenRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 93 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Unvollstandige Anforderungen (13 %9):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens haufig
Projekt startet ohne klare Idee derBedurfnisse und Prioritaten derStakeholder.
Stakeholder konnen sich nicht aufAnforderungen einigen.
9relativ zu den abgebrochenen Projekten
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Die angegebenen Zahlen hat Barry Boehm anhand von Projekten ermittelt, bei denen er selbst involviert war (5-6Projekte fur digitale Bibliotheken pro Jahr, Begutachtung von ungefahr 20 Berichten uber abgebrocheneIndustrieprojekte, die unter Beteiligung von den 30 Angehorigen des Center for Software Engineering, das er leitet.Andere Autoren berichten von Abbruchraten mit 40% und 50%, insbesondere fur Gebiete, in denen neue Produkteeingefuhrt werden Hayes (1997).Die meisten hier genannten Ursachen fur Abbruche stellen handfeste Risiken fur Ihr Software-Projekt dar, denen Siesich bewusst sein sollten. Die Fehler, die bei schlecht gefuhrten Projekten gemacht werden, sollten Sie meiden.Fur Sie folgt hier: Machen Sie die Anforderungen und Prioritaten Ihres Kunden fest, bevor Sie anfangen zuentwerfen und zu implementieren.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangelhafte Einbeziehung der Benutzer (12 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig
Projekt kommuniziert nicht mitBenutzer.
Benutzer kommuniziert nicht mitProjekt.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 94 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangelhafte Einbeziehung der Benutzer (12 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig
Projekt kommuniziert nicht mitBenutzer.
Benutzer kommuniziert nicht mitProjekt.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Fur Sie folgt hier: Suchen Sie Ihren Kunden auf. Beziehen Sie ihn bei der Anforderungsanalyse ein. Machen Sie eineanstandige und umfassende Ist-Analyse. Lassen Sie den Kunden das Pflichtenheft prufen (verwenden Sie dabei eineihm passende Terminologie; definieren Sie ein Begriffslexikon). Entwickeln Sie Prototypen, die Sie dem Kundenvorfuhren. Halten Sie Kontakt mit dem Kunden auch wahrend der Implementierungsphase. Prufen Sie periodisch,ob sich seine Prioritaten und Anforderungen geandert haben.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangel an Ressourcen (11 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig; schlecht gefuhrte Projekte haben jedoch niedrigerenGeschaftswert und sind tendenziell eher betroffen
Projekt hat wenig Geschaftswert.Budgeteinschnitte, Verkleinerungen, Repriorisierungen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 95 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangel an Ressourcen (11 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig; schlecht gefuhrte Projekte haben jedoch niedrigerenGeschaftswert und sind tendenziell eher betroffen
Projekt hat wenig Geschaftswert.Budgeteinschnitte, Verkleinerungen, Repriorisierungen.2
00
9-0
2-0
9
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Fur Sie folgt hier: Ihre Ressource ist im Wesentlichen die Zeit; insbesondere auch die Zeit Ihrer Mitstreiter imProjekt. Deren Prioritaten sind nicht immer die Ihrigen. Manche Projektteilnehmer werden es an Einsatz vermissenlassen.Weitere potenziell mangelnde Ressourcen sind Rechner, Netzwerke und Software-Werkzeuge, die Sie fur Ihr Projektbenotigen.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Unrealistische Erwartungen (10 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig
Machbarkeit wurde nicht gepruft. Machbarkeitsprufung fiel negativaus.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 96 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Unrealistische Erwartungen (10 %):
Ursache beischlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig
Machbarkeit wurde nicht gepruft. Machbarkeitsprufung fiel negativaus.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Unrealistische Erwartungen des Benutzers liegen in dessen Natur. Er kennt selten technische Randbedingungen undGrenzen der Berechenbarkeit. Software gilt als beliebig flexibel: “Ich dachte, da mussen Sie nur ein Bit umkippen.”.Und selbstverstandlich will er stets noch einmal uber den Preis reden.Die Tutoren werden versuchen, den Benutzer realistisch zu simulieren.Aber auch Sie selbst konnten zu unrealistischen Erwartungen neigen. Sie sind moglicherweise nicht mit demAnwendungsbereich vertraut genug oder unterschatzen den Aufwand an Kommunikation, den einMehrpersonenprojekt mit sich bringt, und den Aufwand fur die Analyse, den Entwurf und den Test.Letztlich steht Ihnen circa ein Tag pro Woche fur das Projekt zur Verfugung, und diese Projekttage sindunterbrochen von vielen anderen Aktivitaten.Fur Sie folgt hier: Klopfen Sie fruhzeitig die Anforderungen des Kunden auf Machbarkeit ab. Erstellen SiePrototypen, um die Machbarkeit kritischer Anforderungen zu uberprufen. Planen Sie realistisch. Geben sie nicht inallen Punkten dem Kunden nach, wenn dieser seine Wunsche außert. Es gilt “quid pro quo”: etwas fur etwas. Willer X, muss er sich bei Y beschranken. Verlangen Sie ihm Prioritaten ab.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangelnde Unterstutzung bei der Ausfuhrung (9 %):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens haufig
Manager machen unverifizierteAnnahmen uber Unterstutzung (z.B.verlassen sich darauf, dass andereInitiativen repriorisiert werden, umProjekt zu unterstutzen).
Unterstutzung wird entzogen(z.B. Verantwortliche werdenausgetauscht; neueVerantwortliche haben anderePrioritaten und Agenda).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 97 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangelnde Unterstutzung bei der Ausfuhrung (9 %):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens haufig
Manager machen unverifizierteAnnahmen uber Unterstutzung (z.B.verlassen sich darauf, dass andereInitiativen repriorisiert werden, umProjekt zu unterstutzen).
Unterstutzung wird entzogen(z.B. Verantwortliche werdenausgetauscht; neueVerantwortliche haben anderePrioritaten und Agenda).
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Sie mussen sich mit Mitgliedern Ihrer Gruppe und auch mit anderen Gruppen auseinander setzen. Der Betreuer/dieBetreuerin betreut mehrere Gruppen und hat noch viele andere Pflichten. Teilnehmer wie Betreuer sindmoglicherweise zeitweise oder auch dauerhaft nicht verfugbar.Fur Sie folgt hier: Seien Sie explizit daruber, was Sie von anderen erwarten und auch bis wann Sie etwas erwarten.Kommunizieren Sie!
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Anforderungen andern sich (9%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens nicht selten
Anderungen werden akzeptiert, ohnedass Budget und Projektplanangepasst werden.
Folgekosten der Anderunguberwiegen den Nutzen desProjekts.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 98 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Anforderungen andern sich (9%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
meistens nicht selten
Anderungen werden akzeptiert, ohnedass Budget und Projektplanangepasst werden.
Folgekosten der Anderunguberwiegen den Nutzen desProjekts.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Die Anforderungen sind am Anfang nicht klar verstanden. Der Kunde selbst wird sich im Laufe des Projekt klarerdaruber, was er eigentlich will. Rahmenbedingungen andern sich.Die Anforderungen sind selten als stabil zu betrachten.Fur Sie folgt hier: Halten Sie vertraglich fest, wie Sie und der Kunde mit Anderungen umgehen wollen. AntizipierenSie mogliche Anderungen. Uberlegen Sie sich gut, welche Anderung Sie akzeptieren. Seien Sie sich uber dieKonsequenzen einer Anderung im Klaren.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangelhafte Planung (8%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
immer —
Projektmanager haben keineAhnung, wo sie sich befinden undwann das Projekt fertig wird.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 99 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangelhafte Planung (8%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
immer —
Projektmanager haben keineAhnung, wo sie sich befinden undwann das Projekt fertig wird.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Sie sind weder mit dem Anwendungsbereich noch mit einem Projekt dieser Art vertraut. Sie werden es besondersschwer haben.Fur Sie folgt: Seien Sie nicht zu optimistisch. Unterschatzen Sie nicht das Problem, insbesondere in seinen Details,und uberschatzen Sie nicht sich selbst.Planen Sie und seien Sie sich zu jedem Zeitpunkt daruber im Klaren, wo sie sich tatsachlich befinden und was IhrPlanziel war. Seien Sie vorsichtig in dem Glauben “Das holen wir spater wieder ein”.Wenn Soll und Ist zu weit auseinander klaffen, reagieren Sie. Sprechen Sie fruhzeitig mit Ihrem Kunden ubermogliche Einschrankungen bei der Leistung. Der Kunde ist sehr wahrscheinlich besser bedient, wenn er wenigstenetwas bekommt, und nicht gar nichts. Das Vertrauensverhaltnis ware auf immer zerruttet, wenn Sie ihm erst amTag der Auslieferung uber den wahren Zustand Ihres Projekts aufklaren.Denken Sie an die Manager von TollCollect, die noch einen Monat vor der geplanten Einfuhrung behauptet haben,sie wurden den Termin halten.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Kein Nutzen (8%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
gleich haufig in Feldern mit schnellem Wandel
Gute Projektmanager verfolgenTrends und erkennennachlassenden Nutzen fruher; siereagieren fruhzeitiger mitAbbruch.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 100 / 634
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangelndes IT-Management (6%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
immer —
Offensichtlich mangelhaftes Manage-ment.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 101 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangelndes IT-Management (6%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
immer —
Offensichtlich mangelhaftes Manage-ment.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Gehen Sie in die Vorlesung. Die Vorlesung mochte Sie genau hiervor bewahren. Kommen Sie nicht allein weiter,holen sich den Rat eines externen Consultants, sprich Ihres Tutors, ein.Sollten Sie nicht selbst der Projektmanager sein, dann sprechen Sie mit ihm offen uber das Problem. EinProjektleiter ist kein General, sondern ein Dienstleister fur die Projektmitglieder. Er soll die Ubersicht wahren unddas Projekt zusammenhalten. Schafft er dies nicht, obwohl Sie mit ihm daruber geredet haben, wechseln Sie Ihn aus.
Planung eines Software-Projekts
Grunde fur Projektabbruch nach Boehm (2000)
Mangelndes Verstandnis der Technologie (4%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
allermeistens —
Fehlende Kenntnisse der Entwicklerund Manager; Projekte, die niemalshatten begonnen werden sollen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 102 / 634
Grunde fur Projektabbruch nach Boehm (2000)
Mangelndes Verstandnis der Technologie (4%):Ursache bei
schlecht gefuhrtem Projekt gut gefuhrtem Projekt
allermeistens —
Fehlende Kenntnisse der Entwicklerund Manager; Projekte, die niemalshatten begonnen werden sollen.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Grunde fur Projektabbruch nach Boehm (2000)
Bilden Sie Experten, die sich mit spezifischen technischen Problemen gezielt auseinander setzen. Bauen SiePrototypen in einer Technologie, die Sie noch nicht beherrschen. Drehen Sie nicht gleichzeitig an zu vielenSchrauben: Nicht allen Technologien gleichzeitig hinterherlaufen, sondern eine nach der anderen inkrementelleinfuhren. Betrachten Sie das Problem unbekannter Technologien fruhzeitig in ihrem Projektplan (raumen Siezusatzliche Zeit hierfur ein). Bedenken Sie, dass es nicht ausreicht, mehrere Technologien isoliert zu beherrschen.Sie konnten Ihr blaues Wunder erleben, wenn Sie versuchen, diese Technologien miteinander zu integrieren.
Planung eines Software-Projekts
Menschliche Wahrnehmung von Risiken
Selbstgewahlte Gefahren erscheinen geringer als aufgezwungene.
Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf diewir scheinbar keinen Einfluss haben.
Naturliche Risiken werden eher hingenommen als von Menschengeschaffene.
Katastrophen alarmieren uns mehr als der alltagliche Wahnsinn.
Risiken, die von schwer fassbaren Techniken ausgehen, werden eherwahrgenommen als die von vertrauten Techniken.
Schlechte Nachrichten werden eher geglaubt als positive.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 103 / 634
Menschliche Wahrnehmung von Risiken
Selbstgewahlte Gefahren erscheinen geringer als aufgezwungene.
Prinzipiell kontrollierbare Risiken sind akzeptabler als solche, auf diewir scheinbar keinen Einfluss haben.
Naturliche Risiken werden eher hingenommen als von Menschengeschaffene.
Katastrophen alarmieren uns mehr als der alltagliche Wahnsinn.
Risiken, die von schwer fassbaren Techniken ausgehen, werden eherwahrgenommen als die von vertrauten Techniken.
Schlechte Nachrichten werden eher geglaubt als positive.
20
09
-02
-09
Software-Projekt
Planung
Allgemeine Risiken in einem Software-Projekt
Menschliche Wahrnehmung von Risiken
Allgemein:
• Die Risiken bestimmter Sportarten wie Skifahren oder Reiten gehen wir bewusst ein. Dagegen wehren wir uns gegenKonservierungsstoffe in der Nahrung.
• Fettes, nahrstoffarmes Essen ist beliebt, wahrend Leitungswasser auch dann gemieden wird, wenn die Trinkqualitatgarantiert ist.
• In der Erde vorkommendes Radon erscheint uns harmlos im Vergleich zur selben Strahlungsintensitat aus kunstlichenQuellen.
• Werden nach einem Schiffsungluck Giftbeutel oder Olklumpen an die Strande geschwemmt, ist die Aufregung groß,wahrend die schleichende Vergiftung der Meere kaum zur Kenntnis genommen wird.
• Eine Mullverbrennungsanlage mit relativ geringen Emissionen wird bekampft, der Autoverkehr hingegen verteidigt.
• Sturme und Uberschwemmungen gelten als Beweis fur den Treibhauseffekt, doch die geringer gewordene Verschmutzungdes Rheins halten viele fur Propaganda der Industrie.
In der Software-Entwicklung:
• Eine vom Kunden gewollte fremde Technologie erscheint uns riskanter als eine selbst gewollte fremde Technologie.
• Wie scheuen uns eine Software-Bibliothek zu verwenden und implementieren unsere Hash-Tabelle lieber selbst.
• Rutschige Straßenverhaltnisse erscheinen uns harmlos im Vergleich zu Fehlern in der Software des Bremssystems imAuto.
• Der Projektabbruch alarmiert uns mehr als die schleichende Verschlechterung der Qualitat, die wir ausliefern.
• Die Einfuhrung der Cleanroom-Development-Methode erscheint uns riskanter als die Code-and-Fix-Methode.
• Das Gerucht, dass das Projekt in Schieflage geraten ist, macht hellhorig; eine Aussage, die Deadline werde eingehalten,glauben wir gerne.
Planung eines Software-Projekts
Wiederholungsfragen I
Erstellen Sie einen Projektplan fur ein Software-Projekt.
Was sind die Elemente eines Projekts? Insbesondere was ist einMeilenstein und eine Baseline?
Wann wird geplant?
Wie geht man beim Planen vor?
Was ist der Inhalt eines Projektplans?
Was ist ein Gantt-Diagramm?
Was ist ein kritischer Pfad? Welche Bedeutung hat er?
Was sind die Ressourcen eines Software-Projekts? Was sind derenBesonderheiten?
Was sind typische Risiken in einem Software-Projekt? Wie geht manmit ihnen um?
Was sind die Besonderheiten eines Software-Projekts?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 104 / 634
Planung eines Software-Projekts
Wiederholungsfragen II
Welche Risiken sind typisch fur Software-Projekte? Wie ist mit ihnenumzugehen?
Erlautern Sie Risiko-Management.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 105 / 634
Anforderungsanalyse
Anforderungsanalyse
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragen
4 AnforderungsanalyseLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 106 / 634
Anforderungsanalyse
Lernziele
Ist- und Soll-Zustand ermitteln konnen
Anforderungsspezifikation schreiben konnen
Anforderungsspezifikation begutachten konnen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 108 / 634
Lernziele
Ist- und Soll-Zustand ermitteln konnen
Anforderungsspezifikation schreiben konnen
Anforderungsspezifikation begutachten konnen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Lernziele
Lernziele
Bevor ein System implementiert werden kann, mussen die Anforderungen an das System erhoben werden. DieserAufgabe widmet sich die Anforderungsanalyse. Ihr Ziel ist es, einen moglichst genauen und vollstandigen Katalogvon Anforderungen an ein System zu erfassen und zu beschreiben. Die Anforderungen beschreiben einSoll-Konzept, das Verbesserung fur ein Problem des Kunden schaffen soll. Damit dieses Konzept auch wirklich hilft,ist es notwendig, zuerst einmal zu verstehen, was das Problem des Kunden ist. Insofern ist die Analyse desIst-Zustands und seiner Probleme Teil einer Anforderungsanalyse.
Das Ergebnis der Anforderungsanalyse ist der Katalog der Anforderungen. In welcher Form dieser Katalogbeschrieben ist, hangt vom Vorgehensmodell ab. Bei dokumentengetriebenen Vorgehensmodellen – wie demWasserfallmodell – werden die Anforderungen in Form einer Anforderungsspezifikation schriftlich festgehalten. Invielen agilen Vorgehensmodellen erfolgt die Anforderungsspezifikation als Zuruf des Kunden.
Wann und wie oft die Anforderungsanalyse durchgefuhrt wird, hangt ebenso stark vom Vorgehensmodell zurSoftwareentwicklung ab. Beim Wasserfallmodell wird die Anforderungsanalyse nur einmal und ganz zu Anfangdurchgefuhrt. Beim inkrementellen Vorgehen, bei dem die Entwicklung in kleinen abgeschlossenen Inkrementen deszu entwickelnden Systems erfolgt, wird sie jedes Mal wieder vor der Entwicklung jedes Inkrements durchgefuhrt.Beim Extreme-Programming hat man durch die Prasenz eines Kundenvertreters vor Ort eine fast kontinuierlichstattfindende Anforderungsanalyse.
In diesem Modul geht es um die Durchfuhrung der Anforderungsanalyse. Wir streben hier die schriftlicheDokumentation der Anforderungen in Form einer Anforderungsspezifikation an, da dies in den meisten Fallen eineReihe von Problemen vermeidet. Der Inhalt dieses Abschnitts ist jedoch auch fur agiles Vorgehen ohne schriftlicheSpezifikation der Anforderungen relevant, weil auch orale Uberlieferung zu allen Aspekten derAnforderungsspezifikation Stellung nehmen muss.
Ubersicht:
Zunachst widmen wir uns der Frage, warum die Anforderungsanalyse so wichtig aber leider auch schwierig ist.Dann lernen wir die grundsatzlichen Schritte der Anforderungsanalyse kennen. Dazu gehoren die Erfassung desIst-Zustands und seiner Probleme durch die Ist-Analyse, die angestrebte Verbesserung durch ein Soll-Konzept durchdie Soll-Analyse und die genaue und vollstandige Beschreibung der Anforderungen in Form einerAnforderungsspezifikation. Wir vertiefen alle Schritte und lernen Techniken fur diese einzelnen Schritte kennen.
Anforderungsanalyse
Wegweiser
Herausforderungen
Warum sind die Anforderungen so kritisch?Warum ist ihre Erhebung so schwer?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 109 / 634
Anforderungsanalyse
Kosten fur Anderungen
1,5 − 6 x
60 − 100 x
1 x
Kosten für Änderung
nach AuslieferungDefinition Entwicklung
Zeit
Pressman (2003)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 110 / 634
Kosten fur Anderungen
1,5 − 6 x
60 − 100 x
1 x
Kosten für Änderung
nach AuslieferungDefinition Entwicklung
Zeit
Pressman (2003)
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Kosten fur Anderungen
Die Anforderunganalyse ist von zentraler Bedeutung fur den Erfolg eines Projektes. Passieren hier Fehler, entstehtein System, was an den Bedurfnissen des Kunden vorbei entwickelt und damit unbrauchbar wird. Fehler in derAnforderungsanalyse konnen zwar oft noch in spateren Phasen entdeckt und dann korrigiert werden, die Korrekturdieser Fehler ist jedoch meist mit einem erheblichen Mehraufwand verbunden. Pressman (2003) berichtet von denrelativen Kosten fur Korrekturen von Fehlern in der Anforderungsanalyse in Abhangigkeit vom Zeitpunkt, zu demdiese Fehler bekannt werden. Findet man einen Fehler der Anforderungsspezifikation in spateren Aktivitaten derEntwicklung, also beim Entwurf, der Implementierung oder dem Test noch vor Auslieferung, dann konnen dieKosten um einen Faktor 1,5 bis 6 hoher sein als die Korrekturkosten, die entstanden waren, hatte man den Fehlernoch wahrend der Anforderungsanalyse gefunden. Wird der Fehler noch spater gefunden, also nach der Auslieferungder Software, kann er gar um einen Faktor 60 bis 100 hoher sein. Es entstehen dann nicht nur zusatzliche Kostenfur die Nachbesserung von Anforderungsspezifikation und Entwurf, Fehlerkorrektur und Restrukturierung derImplementierung sowie Wiederholung des Tests. Es entstehen daruber hinaus auch Kosten fur die Beseitigung vonAuswirkungen des Fehlers. Hat eine eingebettete Software in einem Automobil beispielsweise einen Fehler, somussen alle Fahrzeuge in der Werkstatt uberholt werden. Dadurch entstehen hohe direkte Kosten, aber auch nochindirekte Kosten durch den Imageverlust des Automobilherstellers, wenn sich der Imageverlust auf dieVerkaufszahlen auswirkt.
Anforderungsanalyse
Warum die Anforderungsanalyse so schwer ist
Kunden wissen haufig nicht, was sie genau wollen, bzw. konnen esnicht genau außern
Kunden sprechen ihre Sprache, die von Entwicklern nicht verstandenwird
unterschiedliche Kundengruppen haben unterschiedlicheAnforderungen, die sich mitunter widersprechen
politische Entscheidungen konnen Anforderungen beeinflussen
die Welt andert sich, die Anforderungen an die Software auch; auchwahrend der Entwicklung
– Sommerville (2004)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 111 / 634
Warum die Anforderungsanalyse so schwer ist
Kunden wissen haufig nicht, was sie genau wollen, bzw. konnen esnicht genau außern
Kunden sprechen ihre Sprache, die von Entwicklern nicht verstandenwird
unterschiedliche Kundengruppen haben unterschiedlicheAnforderungen, die sich mitunter widersprechen
politische Entscheidungen konnen Anforderungen beeinflussen
die Welt andert sich, die Anforderungen an die Software auch; auchwahrend der Entwicklung
– Sommerville (2004)20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Warum die Anforderungsanalyse so schwer ist
Die Anforderungsanalyse ist schwierig, so dass die Wahrscheinlichkeit, dass wir Fehler machen, recht hoch ist.Sommerville (2004) nennt hierfur eine Reihe von Grunden:
• Die Kunden wissen haufig nicht genau, was sie genau wollen, beziehungsweise konnen es nicht genau außern.
• Kunden sind Experten in ihrem Anwendungsbereich, haben jedoch in der Regel wenig Kenntnisse in der Informatik. Beiden Informatikern verhalt es sich meist umgekehrt. Es treffen also Menschen aufeinander, die erst zu einer gemeinsamenSprache und einem gemeinsamen Verstandnis finden mussen.
• Es gibt meist nicht den Kunden oder Benutzer, sondern sehr viele mit recht unterschiedlichen Anforderungen, die sichnicht selten widersprechen. Bei der Anforderungsanalyse mussen also Konflikte aufgedeckt und Kompromissegeschlossen werden.
• Die Anforderungen werden nicht selten durch politische Entscheidungen beeinflusst. Das aus organisatorischer undtechnischer Sicht bestmogliche Soll-Konzept kann dann immer noch aus rein politischen Grunden scheitern.Beispielsweise sieht der Abteilungsleiter durch eine Anderung im Arbeitsfluss dank softwaretechnischer Unterstutzungplotzlich seinen Einfluss gefahrdet und boykottiert die angestrebte Losung.
• Die Welt ist einem standigen Wandel unterworfen. Weil sich die Welt andert, andern sich notwendigerweise auch dieAnforderungen an die Software, die einen Arbeitsfluss dieser Welt automatisiert. Das geschieht sicherlich in der Zeitnach Auslieferung der Software in der so genannten Wartungsphase, d.h. wahrend ihres Einsatzes, aber nicht selten auchschon wahrend der Entwicklung. Mit der Anforderungsanalyse ist man also selten fertig. Man sollte deshalb idealerweisewahrscheinliche zukunftige Anderungen vorwegsehen und schon in der initialen Entwicklung berucksichtigen.
Anforderungsanalyse
Bewusstseinsebenen
bewusstes Wissen (20-30%)
Wissen, uber das man sich im Klaren ist oder das in seiner vollenBedeutung klar erkannt wird
unbewusstes Wissen (≤40%)
Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aberdennoch handlungsbestimmend ist, und potenziell aufgerufen werdenkann
unterbewusstes Wissen
unbekannte Wunsche, die erst von außen herangetragen werdenmussen, um als Anforderungen erkannt zu werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 112 / 634
Bewusstseinsebenen
bewusstes Wissen (20-30%)
Wissen, uber das man sich im Klaren ist oder das in seiner vollenBedeutung klar erkannt wird
unbewusstes Wissen (≤40%)
Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aberdennoch handlungsbestimmend ist, und potenziell aufgerufen werdenkann
unterbewusstes Wissen
unbekannte Wunsche, die erst von außen herangetragen werdenmussen, um als Anforderungen erkannt zu werden
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Bewusstseinsebenen
Dass Benutzer oft nicht genau wissen, was sie wollen beziehungsweise es nicht sagen, liegt meist nicht an einemMangel an Kenntnis, Vorstellungsvermogen oder Kooperationsbereitschaft, sondern an der Gestalt menschlichenWissens. Menschliches Wissen lasst sich unterteilen in drei ungefahr gleich große Bereiche.
Das bewusste Wissen ist solches Wissen, uber das man sich im Klaren ist oder das in seiner vollen Bedeutung klarerkannt wird. Fragt man einen Radfahrer danach, wie man mit einem Fahrrad eine Kurve fahrt, so wird er einemsicherlich antworten, dass man hierfur den Lenker einschlagen muss. Das bewusste Wissen ist durch direkte Fragenunmittelbar zuganglich.
Das unbewusste Wissen ist solches Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aber dennochhandlungsbestimmend ist und potenziell aufgerufen werden kann. Wird man denselben Radfahrer daraufaufmerksam machen, dass man beobachtet habe, dass er seinen Korper neigt, bevor er den Lenker zur Kurveeinschlagt, wird er die maßgebende Rolle des Korpergewichtes bestatigen. An das unbewusste Wissen vermag mandurch Beobachtung und Nachfragen zu kommen.
Wahrend sowohl das bewusste als auch das unbewusste Wissen wenigstens indirekt erschlossen werden kann,kommt man an die dritte Gestalt menschlichen Wissens kaum oder nur sehr schwer heran. Ein Drittel desmenschlichen Wissens ist dem Wissenden selbst namlich gar nicht bewusst. Das unterbewusste Wissen besteht ausdem uns nicht bekannten Wissen, das dennoch fur unsere Handlungen maßgebend ist. Oft sind es Angste,unbewusste Wunsche oder Triebe, die fur uns handlungsbestimmend sind. Warum der Radfahrer in bestimmtenSituationen es scheut, eine Kurve schneller zu nehmen, hat vielleicht damit zu tun, dass er sich einmal kraftig durcheinen Sturz blamiert hat, als er einst versuchte, eine Kurve besonders schnittig zu nehmen, um seinen Freunden zuimponieren. Unbewusste Anforderungen mussen erst von außen an uns herangetragen werden, um alsAnforderungen erkannt zu werden.
Bewusstseinsebenen
bewusstes Wissen (20-30%)
Wissen, uber das man sich im Klaren ist oder das in seiner vollenBedeutung klar erkannt wird
unbewusstes Wissen (≤40%)
Wissen, das sich dem Bewusstsein im Moment nicht darbietet, aberdennoch handlungsbestimmend ist, und potenziell aufgerufen werdenkann
unterbewusstes Wissen
unbekannte Wunsche, die erst von außen herangetragen werdenmussen, um als Anforderungen erkannt zu werden
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Bewusstseinsebenen
Folgt fur den Informatiker, der eine Anforderungsanalyse durchfuhrt, nun daraus, dass er besser eine Ausbildung alsPsychoanalytiker absolvieren sollte? Wenngleich das sicherlich helfen konnte, so ist es fur unsere Zwecke meistausreichend, sich uber diese Formen des Wissens im Klaren zu sein und passende Techniken anzuwenden, um anmoglichst viel Wissen und Anforderungen zu kommen. Mit reinen Fragetechniken wird man zum uberwiegenden Teilallein das bewusste Wissen erschließen konnen. Mit Beobachtungen und Nachfragen kann man noch den Bereichdes unbewussten Wissens erfassen. Bei der Einschatzung der Aussagen eines Benutzers sollte man sich aber auchGedanken machen, warum er eine Antwort in einer bestimmten Weise geben konnte oder warum er sich auf einebestimme Art und Weise verhalt. Es konnten zum Beispiel Angste vor der Umstellung durch die softwaretechnischeLosung sein, die einen Menschen unbewusst umtreiben – seien es berechtigte Angste um den moglichen Verlust desArbeitsplatzes oder einfach nur die allgemeine Angst, durch die Neuerungen uberfordert zu werden.
Anforderungsanalyse
Basisfaktoren
Minimalanforderungen
→ Mangel fuhrt zu massiverUnzufriedenheit
→ mehr als Zufriedenheit ist nicht moglich
Leistungsfaktoren
bewusst verlangte Sonderausstattung
→ bei Erfullung: Kundenzufriedenheit
→ sonst: Unzufriedenheit
Begeisternde Faktoren
unbewusste Wunsche,nutzliche/angenehme Uberraschungen
→ steigern Zufriedenheit uberproportional
Kano-Modell
Kunde unzufriedenenttäuscht
Erwartungennicht erfüllt
Kunde sehr zufrieden,begeistert Begeisternde Faktoren
Leistungsfaktoren
Basisfaktoren
Erfüllungsgrad
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 113 / 634
Basisfaktoren
Minimalanforderungen
→ Mangel fuhrt zu massiverUnzufriedenheit
→ mehr als Zufriedenheit ist nicht moglich
Leistungsfaktoren
bewusst verlangte Sonderausstattung
→ bei Erfullung: Kundenzufriedenheit
→ sonst: Unzufriedenheit
Begeisternde Faktoren
unbewusste Wunsche,nutzliche/angenehme Uberraschungen
→ steigern Zufriedenheit uberproportional
Kano-Modell
Kunde unzufriedenenttäuscht
Erwartungennicht erfüllt
Kunde sehr zufrieden,begeistert Begeisternde Faktoren
Leistungsfaktoren
Basisfaktoren
Erfüllungsgrad
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Eine gute Anforderungsanalyse ist der Grundstock fur den Erfolg. Dazu muss es uns gelingen, den Kunden mitunserem Produkt zu begeistern, indem wir auf alle seine Anforderungen eingehen und diese spater auch umsetzen.
Der Zusammenhang zwischen dem Erfullungsgrad der Anforderungen und der Begeisterung, die wir damit beimKunden wecken konnen, wird durch das Kano-Modell (Kano 1984) beschrieben. Generell gilt offensichtlich, dasswir mit einem hoheren Erfullungsgrad der Anforderungen auch eine hohere Zufriedenheit erreichen konnen. Ob eineerfullte Anforderung den Kunden zur Begeisterung treibt oder ob es fur ihn vielmehr eine Selbstverstandlichkeitdarstellt, hangt jedoch ab von der Art der Anforderung.
Die erste Kategorie von Anforderungen sind die Basisfaktoren der Software. Diese Anforderungen stellenMindestanforderungen dar, die die Software erfullen muss, damit sie eingesetzt werden kann, Werden sie nichterfullt, ist die Software unbrauchbar. Dies fuhrt zu massiver Unzufriedenheit. Da es sich um Mindestanforderungenhandelt, werden wir den Kunden selbst mit einer hundertprozentigen Erfullung allenfalls zufrieden, aber nichtbegeistern konnen.
Die Gesamtheit der Leistungsfaktoren ist die bewusst verlangte Sonderausstattung. Werden diese Anforderungenerfullt, konnen wir den Kunden mehr als nur zufrieden stellen. Werden sie nicht erfullt, ist der Kunde enttauscht –er hatte sich diese Leistungsfaktoren ja explizit gewunscht. Es droht dann Unzufriedenheit.
Den Kunden begeistern konnen wir, indem wir ihn uberraschen. Die begeisternde Faktoren erfullen ihm unbewussteWunsche oder stellen nutzliche und angenehme Uberraschungen dar. Mit diesen Faktoren konnen wir dieZufriedenheit uberproportional steigern, aber bei Nichterfullen niemals enttauschen, weil der Kunde dieseAnforderungen nicht explizit verlangt hat.
Basisfaktoren
Minimalanforderungen
→ Mangel fuhrt zu massiverUnzufriedenheit
→ mehr als Zufriedenheit ist nicht moglich
Leistungsfaktoren
bewusst verlangte Sonderausstattung
→ bei Erfullung: Kundenzufriedenheit
→ sonst: Unzufriedenheit
Begeisternde Faktoren
unbewusste Wunsche,nutzliche/angenehme Uberraschungen
→ steigern Zufriedenheit uberproportional
Kano-Modell
Kunde unzufriedenenttäuscht
Erwartungennicht erfüllt
Kunde sehr zufrieden,begeistert Begeisternde Faktoren
Leistungsfaktoren
Basisfaktoren
Erfüllungsgrad
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Herausforderungen
Daraus folgt nun nicht, dass wir eigene Anforderungen hinzu erfinden sollten, von denen wir glauben, dass sie denKunden vom Hocker reißen werden. Schließlich mussen wir die Anforderungen implementieren und wenn sie vomKunden nicht bestellt sind, mussen wir dafur bezahlen. Wenn es uns aber gelingt, solche Anforderungen in derAnforderungsanalyse zu identifizieren und dem Kunden vorzuschlagen, so konnen sie zum Vertragsgegenstandwerden, fur die er gerne Geld ausgibt. Allerdings werden sie so dann schnell zu Leistungsfaktoren, die beiNichterfullung Unzufriedenheit hervor rufen. Aber zumindest kann es fur den Kunden den Ausschlag geben, sich furunsere Dienste und nicht fur die unserer Mitbewerber zu entscheiden.
Anforderungsanalyse
Wegweiser
Erhebung der Anforderungen
Was sind die wesentlichen Schritte zur Erhebung derAnforderungen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 114 / 634
Wegweiser
Erhebung der Anforderungen
Was sind die wesentlichen Schritte zur Erhebung derAnforderungen?
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Aktivitaten
Wegweiser
In diesem Abschnitt wenden wir uns den einzelnen Aktivitaten der Anforderungsanalyse zu. Dazu gehoren dieIst-Analyse, die Soll-Analyse und das Festhalten der Anforderungen in Form einer Anforderungsspezifikation. DieseAktivitaten haben eine naturlichen Abfolge, weil sie voneinander kausal abhangen. Allerdings werden sie in derPraxis meist wiederholt.
Anforderungsanalyse
Schritte der Anforderungsanalyse: Ist-Analyse
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Verstandnis der Welt, fur dieSoftwarelosung angestrebt wird.Haufige Fehler:
Entwickler sieht nicht, dass Kundeprimar keine Veranderung, sondernVerbesserung anstrebt.
Kunde beschreibt selten, was sich nichtandern soll (weil es gut genug ist).
Kunde 6= Endbenutzer; weiß nicht, wasdieser braucht.
Folgen von Mangeln: Eigentliches Problemwird ignoriert.Erforderlich: Beobachtungsgabe,Einfuhlungsvermogen,Kommunikationsfahigkeit.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 115 / 634
Schritte der Anforderungsanalyse: Ist-Analyse
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Verstandnis der Welt, fur dieSoftwarelosung angestrebt wird.Haufige Fehler:
Entwickler sieht nicht, dass Kundeprimar keine Veranderung, sondernVerbesserung anstrebt.
Kunde beschreibt selten, was sich nichtandern soll (weil es gut genug ist).
Kunde 6= Endbenutzer; weiß nicht, wasdieser braucht.
Folgen von Mangeln: Eigentliches Problemwird ignoriert.Erforderlich: Beobachtungsgabe,Einfuhlungsvermogen,Kommunikationsfahigkeit.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Aktivitaten
Schritte der Anforderungsanalyse: Ist-Analyse
Die Aktivitat Ist-Analyse zielt darauf ab, den Ausschnitt der Welt zu verstehen, fur den eine softwaretechnischeLosung angestrebt wird. Das heißt, wir streben an, den Ist-Zustand genau zu verstehen und zu analysieren. Uberdie Beschreibung des Ist-Zustands hinaus, entsteht in dieser Phase ein Glossar (Begriffslexikon), in dem wir dieBegriffe aus der Anwendungsdomane definieren, die der Kunde verwendet. Das Begriffslexikon ist notwendig, umUnklarheiten und Missverstandnisse auszuschließen. In der Regel sind Softwareentwickler mit den Begriffen derAnwendungsdomane nicht vertraut genug oder haben eine etwas falsche Vorstellung. Besonders problematisch sinddie Falle, in denen wir meinen zu wissen, was vermeintlich gemeint ist, aber leider daneben liegen, ohne es zumerken. Dieses Glossar wird vom Kunden gelesen und verifiziert. Es wird uber die Projektdauer gepflegt undangepasst.
Ein haufiger Fehler bei der Ist-Analyse ist es, dass wir uns nicht bewusst werden, dass der Kunde primar keineVeranderung, sondern eine Verbesserung anstrebt. Das bedeutet, dass der Kunde mit vielen Dingen so wie sie sindbereits zufrieden ist und die auch weiterhin so bleiben sollen. Der Kunde beschreibt aber selten, was sich nichtandern soll, weil es gut genug ist. Er konzentriert sich vielmehr darauf, was sich andern soll. Nichtsdestotrotzmussen wir auch die Anforderungen kennen, die ubernommen werden sollen. Wenn es darum geht, ein existierendesSoftwaresystem abzulosen, bietet sich uns eine große Chance vom existierenden System zu lernen. VieleInformatiker machen jedoch den Fehler, das existierende Systeme allerhochstens oberflachlich zu untersuchen.Dabei konnten wir den Kunden gezielt danach fragen, was wir vom existierenden System ubernehmenbeziehungsweise verbessern sollten.
Erfolgt die Ist-Analyse mangelhaft, droht die Gefahr, dass wir das eigentliche Problem ignorieren. Fur eineerfolgreiche Durchfuhrung der Ist-Analyse benotigen wir Beobachtungsgabe, Einfuhlungsvermogen undKommunikationsfahigkeit.
Anforderungsanalyse
Schritte der Anforderungsanalyse: Soll-Analyse
Soll−Analyse
Lastenheft
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Aufdeckung und Verbesserungbisheriger Schwachen durch Softwarelosung.Antizipation von Anderungen.Haufige Fehler:
Entwickler gleiten in technische Detailsab.
Kunde hat keine klare Vorstellung bzw.kann sie nicht vermitteln.
Folgen von Mangeln: falsche Losung wirdspezifiziert.Erforderlich: Analytische Fahigkeitenkombiniert mit Wissen uber Machbarkeit vonSoftwarelosungen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 116 / 634
Schritte der Anforderungsanalyse: Soll-Analyse
Soll−Analyse
Lastenheft
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Aufdeckung und Verbesserungbisheriger Schwachen durch Softwarelosung.Antizipation von Anderungen.Haufige Fehler:
Entwickler gleiten in technische Detailsab.
Kunde hat keine klare Vorstellung bzw.kann sie nicht vermitteln.
Folgen von Mangeln: falsche Losung wirdspezifiziert.Erforderlich: Analytische Fahigkeitenkombiniert mit Wissen uber Machbarkeit vonSoftwarelosungen.2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Aktivitaten
Schritte der Anforderungsanalyse: Soll-Analyse
Auf Basis der Ergebnisse der Ist-Analyse identifiziert die Soll-Analyse die bisherigen Schwachen und erarbeitetVerbesserungsmaßnahmen. Dabei interessieren uns nicht nur die unmittelbar anstehenden Anforderungen sondernauch jene, die in absehbarer Zukunft relevant werden konnen. Wahrscheinliche zusatzliche Anforderungen an dasSystem, die in der Zukunft eintreffen werden, sollen beschrieben werden, damit die Softwarelosung so strukturiertwerden kann, dass diese Anderungen spater einfach zu realisieren sind.
Das Ergebnis der Soll-Analyse ist das Lastenheft, in dem wir aus Sicht des Kunden beschreiben, was die Problemeder bisherigen Situation sind und was die neue Software verbessern soll.
Haufig wird in der Soll-Analyse der Fehler gemacht, dass wir in technische Details der Losung abgleiten, obwohl esdoch zunachst um grobe Konzepte zur Verbesserung geht. Wir stoßen auch auf das oben bereits angefuhrteProblem, dass der Kunde nicht notwendigerweise eine klare Vorstellung von der moglichen softwaretechnischenVerbesserung hat beziehungsweise sie nicht vermitteln kann.
Mangel in der Soll-Analyse fuhren dazu, dass eine falsche Losung spezifiziert wird. Am Ende entsteht einSoftwaresystem, das nicht die relevanten Probleme beseitigt und damit unnutz ist. Um eine gute Soll-Analysemachen zu konnen, brauchen wir neben analytischen Fahigkeiten bei der Problemsuche auch softwaretechnischesWissen, um abzuschatzen ob und mit welchem Aufwand, anvisierte softwaretechnische Losungen machbar sind.
Anforderungsanalyse
Schritte der Anforderungsanalyse: Spezifikation
Abnahmedurch Kunden abgenommene
Anforderungs−
(Pflichtenheft)
spezifikation
Anforderungs−spezifikation
der Anforderungen
Spezifikation
Soll−Analyse
Lastenheft
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Anforderungen genau beschreiben.Haufige Fehler:
Anforderungen bleiben vage
Implementierungsdetails stattAnforderungen
Folgen von Mangeln:
Vertragsstreitigkeiten am Projektende.
Erforderlich: Kommunikationsfahigkeit.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 117 / 634
Schritte der Anforderungsanalyse: Spezifikation
Abnahmedurch Kunden abgenommene
Anforderungs−
(Pflichtenheft)
spezifikation
Anforderungs−spezifikation
der Anforderungen
Spezifikation
Soll−Analyse
Lastenheft
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Anforderungen genau beschreiben.Haufige Fehler:
Anforderungen bleiben vage
Implementierungsdetails stattAnforderungen
Folgen von Mangeln:
Vertragsstreitigkeiten am Projektende.
Erforderlich: Kommunikationsfahigkeit.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Aktivitaten
Schritte der Anforderungsanalyse: Spezifikation
Die Ist-Analyse untersucht die Anwendungsdomane, fur die eine softwaretechnische Losung angestrebt wird. DieseAnalyse ist rein deskriptiv. Die Soll-Analyse untersucht die Schwachen des Ist-Zustands und formuliert darausAnforderungen an eine softwaretechnische Losung, die diese Schwachen ausgleichen sollen. Die Soll-Analyse mussPrioritaten setzen (nicht alle Anforderungen sind gleich wichtig) und mogliche Konflikte auflosen (Anforderungenkonnen sich widersprechen; z.B. Performanz versus Sicherheit). Bei der Soll-Analyse mussen eventuell auch Folgenvon softwaretechnischen Losungen abgeschatzt werden. Diese Abschatzung konnte dazu fuhren, eine anderesoftwaretechnische Losung zu finden beziehungsweise – im Extremfall – eine softwaretechnische Losung ganzauszuschließen.
Mit Losung ist hier nicht die Implementierung gemeint, sondern lediglich der Anforderungskatalog an dieImplementierung. Es geht hier noch nicht darum, sich zu uberlegen, wie die Anforderungen implementiert werden.
Das Lastenheft beschreibt die Wunsche des Kunden aus dessen Sicht. Es ist haufig noch unscharf oder unstimmig.Erst die Anforderungsspezifikation (auch Pflichtenheft) beschreibt genau, was zu implementieren ist.
Obwohl die Anforderungsspezifikation nur beschreiben soll, was implementiert und nicht wie implementiert werdensoll, sind Uberlegungen zu der generellen Machbarkeit notwendig. Eine Anforderungsspezifikation muss auchrealisierbar sein. Dennoch sollten diese Uberlegungen lediglich dazu fuhren, moglicherweise die Anforderungenabzuandern. Mogliche Wege, die Anforderungen zu implementieren, gehoren in ein Entwurfsdokument und nicht indie Anforderungsspezifikation.
Die Anforderungsspezifikation stellt den Vertrag zwischen Kunde und Entwickler dar und muss entsprechend genaugepruft werden. Meist geschieht dies durch ein Review mit dem Kunden.
Schritte der Anforderungsanalyse: Spezifikation
Abnahmedurch Kunden abgenommene
Anforderungs−
(Pflichtenheft)
spezifikation
Anforderungs−spezifikation
der Anforderungen
Spezifikation
Soll−Analyse
Lastenheft
Ist−Analyse
Ist−Zustand
Glossar
Ziel: Anforderungen genau beschreiben.Haufige Fehler:
Anforderungen bleiben vage
Implementierungsdetails stattAnforderungen
Folgen von Mangeln:
Vertragsstreitigkeiten am Projektende.
Erforderlich: Kommunikationsfahigkeit.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Aktivitaten
Schritte der Anforderungsanalyse: Spezifikation
Typische Fehler bei der Anforderungsspezifikation sind vage Anforderungen (z.B. dass die Softwarebenutzerfreundlich sein soll) und dass sie Implementierungsdetails beschreibt statt Anforderungen aus Kundensicht.
Weil die Anforderungsspezikation den Vertragsgegenstand festlegt, fuhren Mangel nicht selten zuVertragsstreitigkeiten am Ende des Projekts. Wenn die Anforderungen nicht genau definiert wurden, ist einegerichtliche Auseinandersetzung sehr muhselig. In jedem Falle ist ein solcher Streit fur alle Parteien zum eigenenSchaden. Der Kunde hat nicht bekommen, was er wollte; wir bekommen moglicherweise unser Geld nicht. Einenttauschter Kunde schadet uns, denn Enttauschung spricht sich schnell herum.
Wir werden uns also große Muhen bei der Anforderungsspezifikation geben. In den folgenden Abschnitten werdenwir hierzu verschiedene Techniken kennen lernen, die uns bei richtiger Ausfuhrung vor Schaden bewahren konnen.Es sei auch hier nochmal darauf hingewiesen, dass die genannten Schritte der Ist- und Soll-Analyse sowie dasFesthalten der Anforderungen hochgradig iterativ sind und keineswegs so sequentiell, wie durch den Datenfluss imDiagramm suggeriert. Das muss bei der Planung beachtet werden.
Anforderungsanalyse
Wegweiser
Ist-Analyse
Was ist das Ziel und der Gegenstand derIst-Analyse?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 118 / 634
Anforderungsanalyse
Soziotechnisches System
Definition
Soziotechnisches System: organisierte Menge von Menschen undTechnologien, die in einer bestimmten Weise strukturiert sind, um eineAufgabe zu erfullen.
Aufgaben
Menschen
Technologien
Rolle/Struktur
AusgabeEingabe
Technisches
Soziales
Umgebung
– Emery, Thorsrud & Trist 1964Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 119 / 634
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
. . . aus allenrelevantenBlickwinkeln.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 120 / 634
Ist-Zustand: Was?
Verstandnis von:Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
. . . aus allenrelevantenBlickwinkeln.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
In diesem Abschnitt lernen wir Analysetechniken fur die Ist-Analyse kennen. Zunachst untersuchen wir, was wir beider Ist-Analyse uberhaupt analysieren sollen.
Durch die Ist-Analyse streben wir ein Verstandnis folgender Aspekte des Ist-Zustands aus allen relevantenBlickwinkeln an:
• Struktur: das organisatorische Gefuge des Systems, fur das die Softwarelosung angestrebt wird.
• Aufgaben: der Umfang und die Art der anfallenden Aufgaben (Operationen) und Besonderheiten im Ablauf
• Kommunikation: die Vorrichtungen und Gelegenheiten zur Kommunikation und ihr Ablauf
• Dokumenten: schriftliche oder elektronische Dokumente, die verwendet und produziert werden
• Daten: Umfang und Art der verarbeiteten Daten in den Dokumenten und uber sie hinaus
• Schwachstellen: die bestehenden Mangel, Unvollstandigkeiten und Redundanzen des Ist-Zustands
Wie werden diese Aspekte nun vertiefen und benutzen als illustrierendes Beispiel eine Verkaufssituation in einemFahrradladen, fur die wir eine softwaretechnische Unterstutzung entwickeln sollen.
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
organisatorisches Gefuge des Systems, fur dasSoftwarelosung angestrebt wird
relevante Akteure
Systemgrenzen
Art und Umfang der Verbindungen innerhalbund nach außen
Kunde 1Verkäufer 1
Kunde 2
Verkäufer 2
Ladenbesitzer
Großhändler
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 121 / 634
Ist-Zustand: Was?
Verstandnis von:Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
organisatorisches Gefuge des Systems, fur dasSoftwarelosung angestrebt wird
relevante Akteure
Systemgrenzen
Art und Umfang der Verbindungen innerhalbund nach außen
Kunde 1Verkäufer 1
Kunde 2
Verkäufer 2
Ladenbesitzer
Großhändler
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Bei der Analyse der Struktur identifizieren wir zunachst alle relevanten Akteure (Benutzer und andereSoftwaresysteme, die miteinander interagieren. Im Fahrradladen sind das Kunden und Verkaufer sowie derLadenbesitzer und seine Lieferanten.
Dann legen wir die Systemgrenzen fest. Mit System ist hier weder das Softwaresystem gemeint, das wirimplementieren sollen (wir kennen ja die Anforderungen dafur noch gar nicht) noch etwa ein moglicherweise bereitsexistierendes Softwaresystem, das wir ablosen sollen. Vielmehr meinen wir damit den Ausschnitt der Welt, fur denwir die softwaretechnische Verbesserung anstreben sollen. Diesen Ausschnitt fassen wir als ein System miteinanderagierender Akteure auf.
Wenn wir die Systemgrenzen festlegen, bestimmen wir also, was alles zu dem Ausschnitt der Welt gehort, der furuns relevant ist. Bsp.: Nehmen wir an, wir sind beauftragt, das Verkaufsgesprach zwischen Kaufer und Verkaufer zuoptimieren, dann gehoren diese beiden Personengruppen zu unserem untersuchten System. Ihr Zusammenspielsollen wir optimieren. Ladenbesitzer und Lieferanten hingegen sind außerhalb unseres Systems, aber dennochrelevant fur unsere Aufgabenstellung, weil der Verkaufer den Ladenbesitzer bei bestimmten Entscheidungen zu Rateziehen und Lieferanten zu Lieferzeiten befragen muss. �
Haben wir die Systemgrenzen gezogen, untersuchen wir die Art und den Umfang der Verbindungen innerhalb desSystems und nach außen. Wir bestimmen, wer innerhalb des System miteinander und welche unserer innerenAkteure mit welchen externen Akteuren interagiert. Die Interaktion zwischen externen Akteuren konnen wir in derRegel vernachlassigen.
Das Ergebnis lasst sich als Graph reprasentieren, dessen Knoten die Akteure und dessen Kanten die Interaktionendarstellen.
Anforderungsanalyse
Ist-Zustand: relevante Akteure
Grundsatz: Kenne deinen Benutzer!
Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sindindividuelle Menschen, um die es geht.
Andererseits: Wir konnen nicht jeden betrachten und mussenzusammenfassen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 122 / 634
Ist-Zustand: relevante Akteure
Grundsatz: Kenne deinen Benutzer!
Aber: Der Benutzer bzw. die Benutzerin ist eine Illusion. Es sindindividuelle Menschen, um die es geht.
Andererseits: Wir konnen nicht jeden betrachten und mussenzusammenfassen.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: relevante Akteure
Nachdem wir alle Akteure bestimmt haben, untersuchen wir die menschlichen Akteure weiter im Detail. Dies sinddie potentiellen Benutzer unseres zukunftigen Softwaresystems. Zum Teil erscheinen sie uns bisher noch rechtabstrakt, etwa der Verkaufer und der Kaufer. Diese Rollen definieren bestimmte Klassen von Benutzern mitunterschiedlichen Aufgaben und Zielen in unserem Systemgefuge. Diese Rollen abstrahieren aber von denEigenschaften konkreter Benutzer. So konnen wir sicherlich ganz unterschiedliche Kaufer in unserem Fahrradladenausmachen, die sich in Erfahrungen, Vorlieben, Wunschen, Alter, Geschlecht und Finanzkraft unterscheiden. Allewollen ein Fahrrad oder ein Fahrradbestandteil kaufen, aber ihre Auswahl und ihre Interaktion mit dem Kaufer wirdwesentlich durch ihre personlichen Eigenschaften bestimmt. Es reicht also nicht aus, nur funktionale Rollen zuidentifizieren. Da das Softwaresystem von konkreten Menschen benutzt werden wird, mussen wir deren Eigenheitengenau kennen, damit wir ein nutzliches Softwaresystem fur sie entwickeln konnen.
Andererseits konnen wir auch nicht jedes mogliche Individium einzeln betrachten, da die Anzahl der Benutzer meistsehr hoch ist und uns nicht alle Benutzer bekannt sind. Aus okonomischen Grunden mussen wir also mehrereIndividuen mit ahnlichen Eigenschaften zu Klassen zusammenfassen.
Anforderungsanalyse
Ist-Zustand: relevante Akteure
Persona
(in archetypischer Psychologie) die Maske oder Erscheinung, die man derWelt prasentiert.
(in der Softwareergonomie) erzahlerische Beschreibung charakterischerEigenschaften und Verhalten eines Benutzers oder Kunden, die spezifischeDetails nennt, statt Verallgemeinerungen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 123 / 634
Ist-Zustand: relevante Akteure
Persona
(in archetypischer Psychologie) die Maske oder Erscheinung, die man derWelt prasentiert.
(in der Softwareergonomie) erzahlerische Beschreibung charakterischerEigenschaften und Verhalten eines Benutzers oder Kunden, die spezifischeDetails nennt, statt Verallgemeinerungen.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: relevante Akteure
Es ist die Aufgabe des Analysten, eine angemessene Menge von Benutzerklassen zu finden, die die richtige Balancezwischen abstrakten Rollen und individuellen Benutzern wahrt. Zur Beschreibung dieser Benutzerklassen kann mansich der so genannten Personas bedienen. Die Persona ist ursprunglich eine im griechischen Theater von denSchauspielern verwendete Maske, die die Rolle typisierte und als Schallverstarker benutzt wurde. In derarchetypischen Psychologie ist es die Maske oder Erscheinung, die man der Welt prasentiert.
In der Anforderungsanalyse der Softwaretechnik steht eine Persona fur eine Benutzerklasse. Sie beschreibt derengemeinsamen Eigenschaften, gibt ihnen aber ein konkretes Bild. Sie ist in der Softwareergonomie eine erzahlerischeBeschreibung charakterischer Eigenschaften und Verhalten eines Benutzers oder Kunden, die spezifische Detailsnennt, statt nur Verallgemeinerungen.
Neben der Konkretisierung statt Verallgemeinerung geben uns die Personas etwas Spielerisches imEntwicklungsprozess, das unsere Kreativitat stimulieren kann. Wir konnen große Poster unserer Personas aufhangenund sie betrachten, wahrend wir an der Anforderungsspezfikation schreiben. Wir leben damit die Idee, fur und mitdem Benutzer zu entwickeln.
Anforderungsanalyse
Persona-Poster:
Bild (fiktiv)
Name (fiktiv),Beruf, Motto
Rolle, Ziele,Aufgaben, Ideen,Wunsche,Vorlieben,personlicheDetails
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 124 / 634
Persona-Poster:
Bild (fiktiv)
Name (fiktiv),Beruf, Motto
Rolle, Ziele,Aufgaben, Ideen,Wunsche,Vorlieben,personlicheDetails
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Die ursprungliche Idee der Personas fur die Anforderungsaanalyse stammt von Cooper. Zur Beschreibung einerPersona gehoren ein fiktives Bild und ein fiktiver Name sowie weitere personliche Eigenschaften, wie den Beruf oderein charakterisierendes Motto. Statt von der abstrakten Benutzerklasse Verkaufer sprechen wir also von HerrnSchmidt, dem Verkaufer. Dann werden die gemeinsamen Eigenschaften der Benutzer, die sich hinter der Personaverbergen, aufgefuhrt. Dazu gehoren die Rolle, die Herr Schmidt ausfullt, die Ziele, die Herr Schmidt verfolgt, seineIdeen, Wunsche, Vorlieben und weitere personliche Details, soweit sie von Relevanz fur die Analyse sind.
Quelle fur das Bild:http://www.research.microsoft.com/research/coet/Grudin/Personas/Pruitt-Grudin.doc. Der Artikelerlautert auch wesentliche Ideen.
Anforderungsanalyse
Bedeutung von Personas
archetypische Benutzerbeschreibungen
typisch fur Zielgruppen
decken deren Anforderungen, Bedurfnisse und Ziele ab
stehen im Designprozess stellvertretend fur die realen Benutzer (stattder relativ anonymen und pauschalen Große “Benutzer”)
konnen bei Design und beim Usability-Test der Benutzerinteraktionverwendet werden
konnen beim Handbuchschreiben und -prufen sowie Akzeptanztestverwendet werden
– Astrid Beck, FHT Esslingen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 125 / 634
Bedeutung von Personas
archetypische Benutzerbeschreibungen
typisch fur Zielgruppen
decken deren Anforderungen, Bedurfnisse und Ziele ab
stehen im Designprozess stellvertretend fur die realen Benutzer (stattder relativ anonymen und pauschalen Große “Benutzer”)
konnen bei Design und beim Usability-Test der Benutzerinteraktionverwendet werden
konnen beim Handbuchschreiben und -prufen sowie Akzeptanztestverwendet werden
– Astrid Beck, FHT Esslingen20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Bedeutung von Personas
Astrid Beck, von der Fachhochschule fur Technik in Esslingen, fasst die Bedeutung von Personas in derSoftwaretechnik wie folgt zusammen. Personas sind archetypische Benutzerbeschreibungen und beschreibentypische Zielgruppen durch deren gemeinsame Eigenschaften. Die Gesamtheit der Anforderungen aller Personasdeckt die Anforderungen, Bedurfnisse und Ziele aller Benutzer ab. Wie viele Personas man benotigt, hangt starkvom Projekt ab. In der Regel wird man mit zwischen 5 und 15 verschiedene Personas auskommen.
Die Personas stehen im Designprozess stellvertretend fur die realen Benutzer und bilden eine kreative und konkreteAlternative zu der relativ anonymen und pauschalen Große
”Benutzer“. Die Anforderungsspezifikation muss die
Anforderungen fur jede Persona beinhalten. Sie konnen aber nicht nur wahrend der Anforderungsanalyse derfunktionalen Anforderungen an die Software verwendet werden. Die Personas helfen uns auch beim Design derMensch-Maschine-Kommunikation und beim Usability-Test der Benutzerinteraktion. Hier muss dieBenutzerinteraktion so gestaltet sein, dass alle Personas ihr Anwendungsproblem mit dem Softwaresystem effektivund effizient losen konnen. Aus den Personas lassen sich fur den Usability-Test, der dies uberprufen soll,unmittelbar entsprechende Test-Benutzer ableiten, die das Profil der Personas erfullen. Schließlich konnen diePersonas beim Handbuchschreiben und -prufen sowie beim Akzeptanztest verwendet werden. Auch hier helfen sie,sicher zu stellen, dass die Anforderungen zutreffend und vollstandig sind, indem das Handbuch und System ausallen relevanten Blickwinkeln der Benutzersicht untersucht wird.
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Umfang und Art der anfallenden Aufgaben(Operationen) und Besonderheiten im Ablauf.
Was wird gemacht?→ Kundenberatung
Wer oder was fuhrt Operation aus?→ Kunde + Verkaufer
Wann und wie haufig?→ werktags: 50 Mal/Tag; samstags: 80Mal/Tag
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 126 / 634
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Forts.)
Zu welchem Zweck?→ Kauf eines Artikels
Nach welchen Regeln wirken Operationenzusammen?→ Beratung vor Kauf-Operation, aber optional
Was benutzt/produziert Operation?→ Zeit und Wissen des Verkaufers/Auswahldes Kaufers
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 127 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Forts.)
Zu welchem Zweck?→ Kauf eines Artikels
Nach welchen Regeln wirken Operationenzusammen?→ Beratung vor Kauf-Operation, aber optional
Was benutzt/produziert Operation?→ Zeit und Wissen des Verkaufers/Auswahldes Kaufers
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Nachdem wir uns durch die Personas einen Uberblick verschafft haben, welche Benutzerklassen zu beachten sind,untersuchen wir als nachstes die Aufgaben der einzelnen Akteure, die im untersuchten System vorkommen. DieAufgaben konnen wir als Operationen der Akteure auffassen. Hier interessiert uns, was eine Operation macht, wersie ausfuhrt, wann und wie haufig die Operation ausgefuhrt wird, zu welchem Zweck sie durchgefuhrt wird, welcheRegeln der Ausfuhrung der Operation selbst und welche dem Zusammenwirken der Operationen zu Grunde liegensowie was eine Operation benutzt und produziert.
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Forts.)
Zu welchem Zweck?→ Kauf eines Artikels
Nach welchen Regeln wirken Operationenzusammen?→ Beratung vor Kauf-Operation, aber optional
Was benutzt/produziert Operation?→ Zeit und Wissen des Verkaufers/Auswahldes Kaufers
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Betrachten wir diese Fragen zu den Aufgaben an unserem Beispiel des Fahrradladens. Wir untersuchen hier diebesondere Aufgabe des Einkaufes. Dies ist eine Operation unter vielen in einem Fahrradladen. Die Reparatur oderder Umtausch sind weitere Beispiele fur Operationen in einem Fahrradladen.
Bsp.: Der Einkauf folgt im Wesentlichen dem folgenden Ablauf:
1. Der Kunde betritt den Laden und außert seinen Wunsch gegenuber dem Verkaufer.
2. Der Verkaufer fragt nach den Details und berat den Kunden.
3. Der Kunde wahlt aus dem Angebot aus, kauft und bezahlt, wenn er etwas Passendes gefunden hat.
4. Der Verkaufer ubergibt den Artikel und den Kassenzettel, sobald der Betrag durch den Kunden beglichen wurde.
• Wer oder was fuhrt Operation aus?
→ Die Ausfuhrenden sind Kunde und Verkaufer in den oben beschriebenen Rollen.
• Wann und wie haufig?
→ Werktags findet diese Operation ca. 50 Mal am Tag statt; samstags ca. 80 Mal/Tag. Abends findet sie tendenziellhaufiger statt als morgens.
• Zu welchem Zweck?
→ Der Kaufer benotigt einen Fahrradartikel. Der Verkaufer mochte Umsatz erzielen.
• Nach welchen Regeln wirken Operationen zusammen?
→ Wenn der Kunde nichts Passendes findet oder der Verkaufer ihn unzureichend berat, geht der Kunde ohne zu kaufen.Wenn der Kunde nicht komplett bezahlen kann, schreibt der Verkaufer an, wenn er den Kunden gut genug kennt.Ansonsten ubergibt ihm der Verkaufer den Artikel nicht. Ein Umtausch ist nur moglich, wenn ein Artikel vorher gekauftwurde. Kaufer und Verkaufer verhalten sich kooperativ, das heißt, der Verkaufer berat nach bestem Wissen undGewissen und der Kunde liefert ihm hierfur notwendige Hintergrundinformationen zu seinen bereits gekauften Artikelnund seinen Wunschen.
• Was benutzt/produziert Operation?
→ Die Operation uberfuhrt den Artikel aus dem Besitz des Ladens in den Besitz des Kaufers. Sie uberfuhrt den Geldbetrag,der zu entrichten ist, vom Kunden in die Kasse des Verkaufers.
�
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Welche Vorrichtungen und Gelegenheiten zurKommunikation gibt es (im Rahmen welcherAufgaben)?→ Laden, Telefon
Wie lauft Kommunikation ab?→ initiiert vom Kunden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 128 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Welche Vorrichtungen und Gelegenheiten zurKommunikation gibt es (im Rahmen welcherAufgaben)?→ Laden, Telefon
Wie lauft Kommunikation ab?→ initiiert vom Kunden
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Wenn wir die Kommunikation untersuchen, interessieren wir uns fur die Vorrichtungen fur die Kommunikation, dieGelegenheit, zu der die Kommunikation stattfindet, sowie den Ablauf der Kommunikation.
Bsp.: Beim Verkaufsgesprach, wie oben dargestellt, verwenden die Akteure im Laden schlicht die menschlicheStimme, wenn das Gesprach im Laden stattfindet. Alternativ kann der Kunde sich aber auch uber das Telefon vomVerkaufer beraten lassen und erst spater den Laden betreten, um den passenden Artikel zu besorgen.
Die Kommunikation findet wahrend der Ladenoffnungszeiten statt und wird vom Kunden initiiert. Wenn derVerkaufer frei ist, spricht er jedoch auch Kunden an, wenn er den Eindruck hat, dass sie seine Hilfe benotigen. �
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
klara: Kundin
volker : Verkäufer
gib−artikel()
gib−detail()
Detail
Auswahl
wähle−aus()
gib−geld()
Geld
Artikel
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 129 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
klara: Kundin
volker : Verkäufer
gib−artikel()
gib−detail()
Detail
Auswahl
wähle−aus()
gib−geld()
Geld
Artikel20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Den Ablauf der Kommunikation kann man verbal beschreiben oder zu etwas formaleren Notationen greifen. Hierfureignen sich insbesondere die UML-Sequenzdiagramme, die fur solche Zwecke entworfen wurden.
Wichtig ist bei allen gewahlten Notationen, dass sie einerseits prazise genug sind – was fur stark formalisierteNotationen spricht – und dass sie auch vom Kunden verstanden werden – was meist gegen stark formalisierteNotationen spricht. Sequenzdiagramme sind jedoch ein recht einfach zu erlauterndes Mittel, das nach kurzenErlauterungen auch Nichtinformatikern verstandlich sein kann. Fur zustandsbasierte Kommunikation eignen sichauch Zustandsdiagramme. Ebenso kann man mit Aktivitatsdiagrammen komplexere Ablaufe gut beschreiben.
Bsp.: Das Diagramm hier beschreibt die Kommunikation als eine Abfolge von Nachrichten, die sich die Akteuregegenseitig zuschicken. Einige davon, wie z.B. gib-detail(), erhalten eine Antwort. Es bescheibt dieselbe Abfolge wieder naturlichsprachliche Text weiter oben. Das Sequenzdiagramm muss aber hierfur noch erganzt werden um dieBedeutung der Nachrichten. �
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Dokumente, die verwendet und produziert werden
Bezeichnung→ Kassenzettel
Inhalt→ gekaufte Ware, Preis, MWST, Datum,Verkaufer
Grad der Formalisierung, Aufbau→ genugt Gesetz
Verteiler→ Kunde und Laden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 130 / 634
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Fortsetzung)
Archivierung→ als Papier beim Kunden, elektronisch in derLadenkasse
von wem produziert/verwendet?
→ produziert von Kasse/Verkaufer→ verwendet von Kunde beim Umtausch,
Steuererklarung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 131 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Fortsetzung)
Archivierung→ als Papier beim Kunden, elektronisch in derLadenkasse
von wem produziert/verwendet?
→ produziert von Kasse/Verkaufer→ verwendet von Kunde beim Umtausch,
Steuererklarung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Eine wichtige Informationsquelle bei der Ist-Analyse liefern existierende Dokumente, die verwendet und produziertwerden. Meist mussen sie bei einer softwaretechnischen Losung im Rechner nachgebildet werden. Dokumentekonnen eher formalisiert sein, wie z.B. der Kassenbons im Fahrradladen, oder eher informell sein, wie z.B. derNotizzettel des Kaufers, auf dem er sich aufgeschrieben hat, was er einkaufen mochte und zu welchem Fahrrad inseinem Besitz der neue Artikel passen soll.
Bei diesen Dokumenten interessieren uns die Bezeichnung, der Inhalt, der Grad der Formalisierung, der Aufbau, derVerteiler (d.h. wer das Dokument erhalt), die Archivierung des Dokuments sowie die Produzenten undKonsumenten des Dokuments.
Bsp.: Im Fahrradladen gibt es beispielsweise den Kassenzettel. Sein Inhalt ist die gekaufte Warte, der Preis, dieanrechenbare Mehrwertsteuer, das Kaufdatum sowie der Verkaufer. Der Kassenzettel muss dem Gesetz genugenund ist darum recht formalisiert. Den Kassenzettel erhalt der Kunde, ein Durchschlag bleibt in der Kasse desLadens. Sowohl der Kunde als auch der Laden archivieren den Kassenzettel – der Kunde um gegebenenfalls seineGarantieanspruche durchzusetzen, der Laden fur das Finanzamt. Produziert wird der Kassenzettel von der Kassedes Ladens durch den Verkaufer und verwendet wird er vom Kunden im Falle eines Umtausches beziehungsweisevom Ladenbesitzer fur die Steuererklarung. �
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Umfang und Art der verarbeiteten Daten
Volumen und Wachstum→ 41 Flaschenhalter
Wertebereiche→ Radius Halterung, Abstand Schrauben,versch. Farben etc.
Datentrager→ Katalog in Papierform, Online-Katalog inHTML
Ordnungsstrukturen→ Name, Hersteller, Typ
Verarbeitungshaufigkeit→ wird alle drei Tage einmal verkauft
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 132 / 634
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Fortsetzung)
Art und Erfordernisse der Datensicherung→ Speicherung verkaufter Waren und desInventars
Abhangigkeiten zwischen den Daten→ passt nur an bestimmte Rahmen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 133 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Fortsetzung)
Art und Erfordernisse der Datensicherung→ Speicherung verkaufter Waren und desInventars
Abhangigkeiten zwischen den Daten→ passt nur an bestimmte Rahmen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Wir untersuchen die Dokumente, um die Daten zu ermitteln, die fur die Ist-Analyse relevant sind. Oft sind esverschiedene Daten, die in den Dokumenten aufgefuhrt und verknupft werden. Allerdings sind nicht alle relevantenDaten auf Dokumenten wiedergegeben. Im nachsten Schritt untersuchen wir weitere Daten, die moglicherweise nurmundlich ausgetauscht werden.
Um die Daten prazise und vollstandig zu modellieren, wird hierzu oft ein Datenmodell aufgestellt. DasDatenmodell beschreibt die wesentlichen Daten, ihre Eigenschaften, ihren Umfang und ihre Beziehungen. ZurReprasentation eignen sich fur eine Reihe der relevanten Aspekte beispielsweise UML-Klassendiagramme. DasDatenmodell beschreibt das Volumen und zukunftig erwartete Wachstum der Daten. Dies wird haufig als dasMengengerust bezeichnet. Es ist unerlasslich fur die Abschatzung des Speicherbedarfs und der Anforderungen andie Performanz der Algorithmen. Mit der Betrachtung des zukunftigen Wachstums stellen wir sicher, dass unserSystem skaliert und auch in einigen Jahren noch die notwendige Performanz zur Verfugung stellen wird. Die Datenhaben einen Typ, fur den wir den Wertebereich angeben. Sie werden in vielen Fallen dauerhaft gespeichert aufDatentragern, die aber nicht notwendigerweise unmittelbar elektronisch verarbeitbar sind, z.B. weil sie von Handauf Papier geschrieben werden. Viele Daten konnen sortiert werden, d.h. verfugen uber ein oder mehrereOrdnungskriterien. Unsere Programme mussen sie meist nach diesen Ordnungskriterien sortieren konnen. DieHaufigkeit ihrer Verarbeitung ist fur uns wichtig, weil wir damit die Zugriffe entsprechend organisieren mussen.Haufig verarbeitete Daten mussen schnell verfugbar sein. Schließlich interessieren uns die Art und Erfordernisse derDatensicherung sowie die Abhangigkeiten zwischen den Daten. Haufige solche Abhangigkeiten sind dieTeil-Von-Beziehung in Form der Aggregation und Komposition. Andere Beziehungen werden inUML-Klassendiagrammen mit allgemeinen Assoziationen modelliert.
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile (Fortsetzung)
Art und Erfordernisse der Datensicherung→ Speicherung verkaufter Waren und desInventars
Abhangigkeiten zwischen den Daten→ passt nur an bestimmte Rahmen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Bsp.: In unserem Fahrradladen gibt es beispielsweise 41 Flaschenhalter in funf verschiedenen Typen von dreiverschiedenen Herstellern. Ein Flaschenhalter wird beschrieben durch die Attribute Radius der Halterunggemessen in Zentimetern, der Abstand der Schrauben gemessen in Zentimetern, die Farben in rot, grun, gelb, blausowie der Preis im Bereich von 5 bis 25 Euro. Die Datentrager zu den Flaschenhaltern sind die Herstellerkataloge inPapierform als auch als Online-Kataloge in HTML. Name, Hersteller, Typ und Preis bilden die Ordnungsstrukturen.Von den Flaschenhaltern wird im Durchschnitt alle drei Tage einer verkauft. Dies bildet die Verarbeitungshaufigkeit.Die verkauften und im Lager befindlichen Flaschenhalter werden in einer Datenbank des Ladenbesitzers gespeichert.Die Flaschenhalter passen nur an bestimmte Rahmen; dies hangt vom Schraubenabstand und dem Radius ab. Eineweitere
”weiche“ Abhangigkeit ist die Farbe des Rahmens, zu der der Flaschenhalter passen soll. �
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Untersuchung auf:
Mangel
Unvollstandigkeiten
Redundanzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 134 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Bestandteile
Untersuchung auf:
Mangel
Unvollstandigkeiten
Redundanzen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Nachdem wir die oben genannten relevanten Aspekte des Ist-Zustands erfasst haben, analysieren wir sie aufSchwachstellen und Probleme. Dazu gehoren Mangel, Unvollstandigkeiten oder Redundanzen. Auf dieSchwachstellen werden wir sowohl durch eigene Analyse und Beobachtung der erhobenen Aspekte als auch durchBefragung und Beobachtung der Akteure selbst aufmerksam. Zu entsprechenden Techniken der Befragung undBeobachtung kommen wir weiter unten.
Anforderungsanalyse
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Beispielschwachstellen
Abhangigkeiten und wechselseitige Ausschlussevon Teilen sind nirgendwo dokumentiert
Verkaufer kennt nicht alle Einschrankungen
Kunde kennt seine Konfiguration nicht
Verkaufer kennt Sortiment nicht vollstandig
verschiedene uberlappende Teilekataloge
Inventarlisten sind obsolet
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 135 / 634
Ist-Zustand: Was?
Verstandnis von:
Struktur
Aufgaben
Kommunikation
Dokumenten
Daten
Schwachstellen
Beispielschwachstellen
Abhangigkeiten und wechselseitige Ausschlussevon Teilen sind nirgendwo dokumentiert
Verkaufer kennt nicht alle Einschrankungen
Kunde kennt seine Konfiguration nicht
Verkaufer kennt Sortiment nicht vollstandig
verschiedene uberlappende Teilekataloge
Inventarlisten sind obsolet
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Was?
Bsp.: In unserem Fahrradladen konnen wir beispielsweise durch unsere Analyse der erhobenen Aspekte und durchBeobachtung im Laden folgende Schwachstellen identifizieren:
• Die Abhangigkeiten und wechselseitige Ausschlusse der Bestandteile eines Fahrrads sind nirgendwo dokumentiert. EinVerkaufer kann sie nicht nachschlagen und muss sie alle kennen, um einen Kunden zu beraten.
• Nicht alle Verkaufer kennen aber alle Einschrankungen. Dies fuhrt dazu, dass weniger erfahrene Verkaufer Rucksprachehalten mussen mit erfahreneren Verkaufern oder gar Lieferanten und dass Kunden verargert ihre falschen Artikelumtauschen mussen, wenn sie falsch beraten wurden.
• Die Verkaufer konnen die Kunden nicht ausreichend beraten, weil der Kunde die bereits gekauften Fahrradbestandteilenicht genau kennt, zu denen der neu zu kaufende Artikel passen soll. Der Kunde muss in solchen Fallen unverrichteterDinge den Laden wieder verlassen und die Information besorgen.
• Verkaufer kennen das Sortiment nicht vollstandig und wissen nicht genau, was im Laden selbst oder im Lager nochverfugbar ist.
• Die Fahrradartikel sind in verschiedenen teilweise uberlappenden Teilekatalogen beschrieben. Dies fuhrt zu unnotigenRedundanzen.
• Die Inventarlisten sind obsolet. Der Ladenbesitzer weiß nicht genau, welche Ware noch vorratig, verkauft oder gargestohlen ist.
�
Anforderungsanalyse
Wegweiser
Ist-Analyse
Welchen Techniken konnen wir in der Ist-Analysenutzen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 136 / 634
Anforderungsanalyse
Ist-Zustand: Wie?
Erhebungstechniken
Auswertung vorhandener Dokumente
Befragung
schriftlicher FragebogenInterview
Beobachtung
anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 137 / 634
Ist-Zustand: Wie?
Erhebungstechniken
Auswertung vorhandener Dokumente
Befragung
schriftlicher FragebogenInterview
Beobachtung
anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Wie?
Wir wissen nun, was wir erheben sollen, aber leider noch nicht, wie wir das tun konnen. In diesem Abschnitt lernenwir hierfur verschiedene Erhebungstechniken kennen. Die Auswertung der vorhandenen Dokumente ist eine ersteoffensichtliche Technik. Daruber hinaus konnen wir jedoch auch die Akteure fragen oder beobachten.
Um Akteure zu befragen, konnen wir sie selbst interviewen oder ihnen aber einen schriftlichen Fragebogenzuschicken. Beim Interview kann man auch mit einem vorher grundlich ausgearbeiteten Fragebogen arbeiten oderaber nur eine grobe Skizze der Fragen haben, um dann die Fragen an die Situation spontan anzupassen. Ganz zuAnfang, wenn man sich ein Gebiet erschließen mochte, ist man oft gar nicht in der Lage, prazise Fragenauszuarbeiten. Das Interview hat gegenuber der Befragung durch einen schriftlichen Fragebogen, den der Befragteohne unser Beisein ausfullt, den Vorteil, dass wir auch Gestik und Mimik des Befragten sehen, seine Gegenfragendirekt klaren konnen und individuell auf die Situation reagieren konnen. Allerdings kann die Anwesenheit einesFragenden die Antworten des Befragten beeinflussen. Zum einen lasst sich die Anonymitat hier nicht sicher stellen,zum anderen fallen die Antworten oft auch abhangig davon aus, inwieweit der Fragende dem Befragtensympathisch ist. Außerdem ist das individuelle Interview erheblich zeitaufwandiger und teurer. Bei den schriftlichenFragebogen verhalt es sich gerade umgekehrt. Aus diesem Grunde werden wir meistens sowohl Interviews als auchschriftliche Fragebogen anwenden, weil sie sich bestens erganzen. Wir werden meist zu Anfang eine kleinere Zahlvon Interviews fuhren. Spater konnen wir auf Basis dieser Interviews prazise Fragebogen aufstellen, um eine großereDatenbasis zu schaffen.
Ist-Zustand: Wie?
Erhebungstechniken
Auswertung vorhandener Dokumente
Befragung
schriftlicher FragebogenInterview
Beobachtung
anekdotisch ↔ systematischteilnehmend ↔ nicht-teilnehmendoffen ↔ verdecktselbst ↔ fremdFeld ↔ Labor2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Ist-Zustand: Wie?
Statt zu fragen konnen wir auch beobachten. Beobachtungen haben aber viele Facetten, aus denen wir diegeeignete Beobachtungsart zusammen stellen mussen. Hier mussen wir zunachst entscheiden, ob wir systematischoder eher anekdotisch vorgehen wollen. Wenn wir z.B. ganz einfach einmal den Fahrradladen betreten und dort eineStunde verbringen, liefert das eher anekdotisches Wissen. Bei einem systematischen Vorgehen wurden wir vorherermitteln, wie sich die Kundenbesuche uber die Ladenoffnungszeiten verteilen. Dann wurden wir zu qualitativunterschiedlichen Zeiten den Laden betreten, z.B. Montag morgens, wenn nicht viel los ist, Mittwoch abends, wennmehr los ist, und Samstag vormittags, wenn der Laden meist voll ist. Außerdem mussen wir entscheiden, ob wir beider Beobachtung teilnehmen. Wir konnten uns also einerseits nur einfach in den Laden stellen und beobachten,oder aber konnten wir selbst Kunde spielen und uns beraten lassen. Die Beobachtung kann offen oder verdeckterfolgen. Erfolgt sie offen, kann das den Beobachtungsgegenstand beeinflussen. Ein Verkaufer wird sich in einersolchen Situation zum Beispiel eher freundlich verhalten, als wenn er sich unbeobachtet fuhlt. Andererseits werfenverdeckte Beobachtungen ethische Fragen auf und sind moglicherweise schlicht verboten. Dann mussen wir unsentscheiden, ob wir selbst beobachten oder die Beobachtung Dritten uberlassen. Wenn wir selbst beobachten,haben wir ein unmittelbareres Bild. Andererseits sind wir moglicherweise ungeubt, und ausgebildete und erfahrenedritte Beobachter sehen mehr als wir. Schließlich mussen wir uns zwischen einer Feld- oder Laborbeobachtungentscheiden. Im Labor konnen wir viel starker beeinflussende Faktoren kontrollieren, um so spezielle Situationenund den Einfluss der Faktoren durch deren Variation genauer zu studieren. So konnten wir z.B. eine stressigeLadensituation im Labor nachbilden, indem wir sehr viele Menschen unzufriedene Kunden schauspielern lassen. Dasnaturlichere Bild ergibt sich aber durch die Feldbeobachtung. Hier lassen sich aber keine Situationen nachstellen.
Auch hier gilt wieder, dass man Fur und Wider anhand der konkreten Ausgangslage und des Ziels abwagen muss.Eine Feldbeobachtung ist jedoch immer vernunftig. Im Labor kann man dann bestimmte Situationen nachstellenund naher untersuchen.
Anforderungsanalyse
Befragung
Fragen zu Fragen:
Wird die Frage verstanden?
Bezugsrahmen der Befragten?
Informationsstand der Befragten?
Art der Frage?
Anordnung der Fragen?
Erhebungssituation (Interviewereinfluss)?
Grunde fur die Antwort der Befragten?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 138 / 634
Befragung
Fragen zu Fragen:
Wird die Frage verstanden?
Bezugsrahmen der Befragten?
Informationsstand der Befragten?
Art der Frage?
Anordnung der Fragen?
Erhebungssituation (Interviewereinfluss)?
Grunde fur die Antwort der Befragten?
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Befragung
Die Antwort auf eine Frage hangt nicht nur vom Inhalt der Frage selbst, sondern auch vom Kontext und von derArt und Weise ab, wie man die Frage stellt. Aus diesem Grunde sollte man sich bei der Gestaltung einesFragebogens die Fragen und die Art der Frage sorgfaltig uberlegen und sich uber den Einfluss des Kontextes imKlaren werden. Die Sozialwissenschaften haben hierzu umfangreiche Lehrbucher entwickelt.
Zu unseren Fragen mussen wir uns selbst folgende Fragen stellen:
• Wird die Frage uberhaupt richtig verstanden? Benutzen wir Begriffe, zu denen der Befragte die gleichen Vorstellungenhat wie der Fragende? Bsp.: Wenn wir Softwaretechniker von Server sprechen und damit einen Prozess meinen, dannversteht der Befragte darunter moglicherweise den Rechner, auf dem seine Applikation laufen, wenn er etwasHintergrund in Computer-Hardware hat, oder gar lediglich Diener, wenn er Computer-Laie ist. �
• Was ist der Bezugsrahmen der Befragten? Was ist seine Rolle, was kann er wissen, was sind seine Ziele sowohlberuflicher als auch personlicher Art? Bsp.: Es hat keinen Sinn den Besitzer unseres Fahrradladens zum ublichen Ablaufvon Verkaufsgesprachen zu fragen, wenn er selbst seit langer Zeit das Verkaufen nicht mehr selbst praktiziert hat undlediglich Managementaufgaben wahrnimmt. �
• Informationsstand der Befragten? Was kann der Befragte uberhaupt wissen? Fragen wir ihn zu Dingen, die er nichtwissen kann, wird er keine Antwort abgeben konnen oder schlimmer noch, eine Antwort erfinden.
• Art der Frage? Ist eine offene, geschlossene oder hybride Frage angebracht (siehe unten)?
• Anordnung der Fragen? Die Reihenfolge der Fragen kann das Ergebnis beeinflussen. Uber jede Frage denkt der Befragtenach. Die Assoziationen konnen einen Kontext herstellen, der die Antwort auf die nachste Frage beeinflusst. Bsp.: Umein krasses Beispiel zu nennen: Wenn wir den Verkaufer in unserem Fahrradladen als erstes fragen wurden, ob er sichdurch den geplanten Einsatz unseres Softwaresystems unnutz fuhlen wurde, wird das vermutlich Einfluss auf den Verlaufder weiteren Befragung nehmen. �
Befragung
Fragen zu Fragen:
Wird die Frage verstanden?
Bezugsrahmen der Befragten?
Informationsstand der Befragten?
Art der Frage?
Anordnung der Fragen?
Erhebungssituation (Interviewereinfluss)?
Grunde fur die Antwort der Befragten?
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Befragung
• Was ist der mogliche Einfluss der Situation, in der der Fragebogen erhoben wird? Was ist insbesondere der Einfluss desInterviewers, falls die Fragen in einem Interview gestellt werden? Bsp.: Fragt man Menschen, die eben aus einemKinofilm zu einer Naturkatastrophe – wie z.B. einer Flutwelle – kommen, zum Thema Naturschutz, sind andereAntworten zu erwarten, wie wenn wir die selben Menschen bei einem Transatlantikflug zu ihrem Urlaubsort fragen. �Auch der Fragende hat einen moglichen Einfluss auf die Antworten. Ob uns jemand sympathisch oder unsympathisch ist,beeinflusst, wie kooperativ wir in einem Interview sind. Fatal ware es, wenn der Befragte vor dem Fragenden etwas zubefurchten hatte. Bsp.: So ware der Ladenbesitzer eher ungeeignet, Fragen zum Thema Auslastung und Schwachen derVerkaufer zu stellen, wenn sie zu befurchten haben, dass ihnen aus ehrlichen Antworten negative Konsequenzenerwachsen konnten. �
• Was sind die moglichen Grunde fur die Antwort der Befragten? Der Befragte konnte uns einen Gefallen tun wollen oderwill uns sabotieren. Er konnte bewusst oder unbewusst falsche Antworten liefern, weil er hinter den Fragen einbestimmtes Ziel vermutet, mit dem er nicht einverstanden ist.
Anforderungsanalyse
Fragetypen: Geschlossene Fragen
Geschlossene Fragen:
Welche Qualitat hat die GUI? Bitte ankreuzen.� sehr gut� gut� schlecht� weiß nicht
Antwortalternativen vorgegeben
auch Mehrfachantworten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 139 / 634
Fragetypen: Geschlossene Fragen
Geschlossene Fragen:
Welche Qualitat hat die GUI? Bitte ankreuzen.� sehr gut� gut� schlecht� weiß nicht
Antwortalternativen vorgegeben
auch Mehrfachantworten
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Fragetypen: Geschlossene Fragen
Fragen konnen in drei unterschiedlichen Formen verfasst sein: geschlossene, offene oder hybride Fragen. Sieunterscheiden sich durch die Form der Antworten, die auf sie moglich sind.
Bei geschlossenen Fragen sind alternative Antworten bereits vorgegeben, aus denen der Befragte eine odergegebenenfalls mehrere auswahlen kann. Haufig findet man solche Fragen fur Aspekte, die anhand einer Skalaeingeschatzt werden sollen, also zum Beispiel die Frage, ob einem die GUI sehr gut, gut oder nicht gefallt.
Durch die Vorgabe moglicher Antworten schafft man eine Normierung und kann die Antworten leicht automatisiertstatistisch auswerten.
Diesen Fragentyp kann man gut einsetzen, wenn man die moglichen Antworten gut vorwegsehen kann. Wenn manalso bereits eine bestimmte Hypothese hat, kann man sie durch solche Fragen leicht uberprufen. In Bereichen, indenen man jedoch die Antworten nur schlecht abschatzen kann, besteht die Gefahr, dass die Antwort, die jemandeigentlich geben mochte, nicht dabei ist. Hier sind solche Fragetypen eher ungeeignet. In jedem Falle sollte es beider Antwort immer moglich sein, dass der Befragte die Frage nicht beantworten kann oder will, um erzwungeneFalschantworten zu vermeiden.
Anforderungsanalyse
Fragetypen: Offene Fragen
Offene Fragen:
Wie sollte die GUI verbessert werden?
Antworten in eigenen Worten, im eigenen Referenzsystem
erfordert Ausdrucksfahigkeit der Befragten
starker Einfluss des Fragenden, wenn prasent (durch Aufschreiben,Weglassen)
hoher Auswertungsaufwand
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 140 / 634
Fragetypen: Offene Fragen
Offene Fragen:
Wie sollte die GUI verbessert werden?
Antworten in eigenen Worten, im eigenen Referenzsystem
erfordert Ausdrucksfahigkeit der Befragten
starker Einfluss des Fragenden, wenn prasent (durch Aufschreiben,Weglassen)
hoher Auswertungsaufwand
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Fragetypen: Offene Fragen
Offene Fragen sind solche, bei denen keine Antwort vorgegeben wird. Der Befragte beantwortet die Frage mitseinen eigenen Worten. Dazu kann er seine eigene Terminologie benutzen. Dies erfordert vom Befragten, dass ersich selbst ausdrucken kann. Da jede Antwort moglich ist, kann der Befragte in seiner Formulierung stark durch denanwesenden Fragenden beeinflusst werden. Dies gilt umso mehr, wenn nicht der Befragte die Antwortenaufschreibt, sondern der Fragende, wie das meist ublich ist. Dadurch werden die Aussagen vom Fragenden oftgefiltert und aufbereitet, statt nur wortlich wiedergegeben. Das Mindeste, was man dann tun sollte, ist es, demBefragten das Protokoll seiner Antworten nochmals zur Kontrolle vorzulegen, um sicher zu stellen, dass man seineAussagen korrekt wieder gegeben hat.
Da die Antworten nicht vorgegeben sind, muss ein Mensch sie durchlesen, verstehen und einordnen. Damit ist dieAuswertung erheblich aufwandiger als bei geschlossenen Fragen. Dem hohen Auswerteaufwand steht als Vorteilgegenuber, dass man die Antworten nicht schon beim Entwurf des Fragebogens vorwegsehen muss, wie das beigeschlossenen Fragen der Falle ist. Man hat also die Chance, Neues zu erfahren. Aus diesem Grund wendet mandiesen Fragetyp an, wenn man noch keine rechte Hypothese zu den moglichen Antworten hat.
Anforderungsanalyse
Fragetypen: Hybride Fragen
Hybride Fragen:
Was stort Sie an der GUI?� lange Reaktionszeit� mangelnde Selbsterklarungsfahigkeit� fehlendes
”Undo“
� umstandliche Dialogfuhrung�
Kombination von geschlossenen und offenen Fragen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 141 / 634
Fragetypen: Hybride Fragen
Hybride Fragen:
Was stort Sie an der GUI?� lange Reaktionszeit� mangelnde Selbsterklarungsfahigkeit� fehlendes
”Undo“
� umstandliche Dialogfuhrung�
Kombination von geschlossenen und offenen Fragen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Fragetypen: Hybride Fragen
Hybride Antworten kombinieren geschlossene und offene Fragen, indem eine Menge alternativer Antwortenvorgegeben wird, es aber dennoch moglich ist, durch Freitextfelder eigene Antworten zu formulieren. Dies ist invielen Fallen ein guter Kompromiss, der leichte Auswertbarkeit und die Moglichkeit, unvorhergesehene Antwortenzu liefern, bestmoglich vereint, solange die vorgegebenen Antworten moglichst viele echte Antworten abdecken.
Anforderungsanalyse
Wann welche Erhebungsform?
weniger strukturiertes Interview
unstrukturiertesUntersuchungsgebiet
offene Gesprachsfuhrung undgroßere Antwortspielraume
personlicher Kontakt moglich
Ortsbegehung moglich
stark strukturierter Fragebogen
vorstrukturiertesUntersuchungsgebiet
gute Kenntnisse desUntersuchungsgebiets
Operationalisierung derHypothesen moglich
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 142 / 634
Wann welche Erhebungsform?
weniger strukturiertes Interview
unstrukturiertesUntersuchungsgebiet
offene Gesprachsfuhrung undgroßere Antwortspielraume
personlicher Kontakt moglich
Ortsbegehung moglich
stark strukturierter Fragebogen
vorstrukturiertesUntersuchungsgebiet
gute Kenntnisse desUntersuchungsgebiets
Operationalisierung derHypothesen moglich
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Wann welche Erhebungsform?
Welche Form der Erhebung, ob stark oder weniger strukturiertes Vorgehen, nun angemessen ist, hangt imWesentlichen davon ab, wie gut wir unser Untersuchungsgebiet bereits durchdrungen haben.
In einer fruhen Phase, in der wir uns noch wenig auskennen und mogliche Antworten nicht vorweg sehen konnen,werden wir eher ein weniger strukturiertes Interview durchfuhren. Das Gesprach kann offen gefuhrt werden, und derBefragte hat einen großeren Spielraum bei Antworten. Der Fragende kann spontaner auf die Situation reagieren.Der personliche Kontakt und die Ortsbegehung werden uns weitere Einblicke gewahren.
Ist unser Untersuchungsgebiet bereits gut vorstrukturiert, dann kommt auch ein strukturierteres Vorgehen in Frage.Da wir bereits uber gute Kenntnisse des Untersuchungsgebiets verfugen, sind wir in der Lage, operationaleHypothesen aufzustellen, das heißt, Hypothesen, die wir objektiv durch Fragebogen uberprufen konnen.
Anforderungsanalyse
Frageformulierung
einfache Worte
kurz und konkret
keine doppelten Negationen
nur auf einen Sachverhalt bezogen
nicht hypothetisch
neutral, nicht suggestiv
Befragten nicht uberfordern
balanciert (negative und positive Antwortmoglichkeiten)
immer eine”weiß-nicht“-Kategorie bieten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 143 / 634
Frageformulierung
einfache Worte
kurz und konkret
keine doppelten Negationen
nur auf einen Sachverhalt bezogen
nicht hypothetisch
neutral, nicht suggestiv
Befragten nicht uberfordern
balanciert (negative und positive Antwortmoglichkeiten)
immer eine”weiß-nicht“-Kategorie bieten2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Frageformulierung
Auch uber die Formulierung der Fragen muss man sich vorher sorgfaltig Gedanken machen, da sie einen Einfluss aufdie Antwort hat. Man wahle moglichst einfache, klare Worte, so dass die Frage sicher verstanden werden kann. DieFragen sollten kurz und konkret sein. Lange Fragen beinhalten viele Aspekte, auf die man kaum eine klare,abgeschlossene Antwort geben kann. Auf abstrakte Fragen fallt die Antwort schwer. Doppelt negierte Fragen gilt eszu vermeiden, um den Befragten nicht zu verwirren. Gleichermaßen sollte man auf hypothetische Fragen mit vielenKonjunktiven verzichten. Ansonsten kann eine negative Antwort unterschiedliche Ursachen haben: die, die sich aufden eigentlichen Frageinhalt beziehen, oder jene, die die Pramissen in Frage stellen. Die Frage sollte neutral undnicht suggestiv gestellt werden, ansonsten legt man dem Befragten die Antwort bereits in den Mund. Man sollteeine gleiche Anzahl negativer und positiver Antwortmoglichkeiten vorsehen. Eine Disbalance von entwedernegativen oder positiven Fragen wirkt suggestiv. Außerdem gibt es eine menschliche Tendenz, eher positiv zuantworten. Auch bei geschlossenen Fragen sollte es stets moglich sein, dass der Befragte aussagen kann, dass er aufeine Frage nicht antworten kann oder will, um erzwungene Falschaussagen zu vermeiden.
Anforderungsanalyse
Beobachtung
Prinzipien der Ethnographie (teilnehmende Beobachtung in derFeldforschung):
Naturliche Umgebung
→ Aktivitaten in Alltagsumgebung untersuchen
Ganzheitlichkeit
→ Einzelverhalten im Kontext untersuchen
Beschreiben, nicht bewerten
→ Ist-Verhalten, nicht Soll-Verhalten
Sicht der Handelnden einnehmen
→ Verhalten beschreiben in Begriffen, die fur den Handelnden relevantund bedeutungsvoll sind
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 144 / 634
Beobachtung
Prinzipien der Ethnographie (teilnehmende Beobachtung in derFeldforschung):
Naturliche Umgebung
→ Aktivitaten in Alltagsumgebung untersuchen
Ganzheitlichkeit
→ Einzelverhalten im Kontext untersuchen
Beschreiben, nicht bewerten
→ Ist-Verhalten, nicht Soll-Verhalten
Sicht der Handelnden einnehmen
→ Verhalten beschreiben in Begriffen, die fur den Handelnden relevantund bedeutungsvoll sind2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Beobachtung
In der Befragung adressieren wir hauptsachlich das bewusste Wissen. Wir haben weiter oben schon gelernt, dassdas nur rund ein Drittel des menschlichen Wissens ausmacht. Durch Beobachtung konnen wir uns noch weiteresWissen erschließen.
In der Sozialwissenschaft hat sich die Ethnographie als Technik etabliert. Die Ethnographie ist eine teilnehmendeBeobachtung. Es hat offensichtlich keinen Sinn, das Leben von Urvolker zu ergrunden, indem man sie ihrer Heimatentreißt und sie im Labor untersucht. Eigenschaften von Sozialgemeinschaften sind abhangig vom Kontext undmussen deshalb in diesem Kontext untersucht werden.
Die Ethnographie folgt bei der Beobachtung einer Reihe von Prinzipien:
• Die soziale Gemeinschaft wird in ihrer naturlichen Umgebung beobachtet. Auf diese Weise werden ihre Aktivitaten in derAlltagsumgebung untersucht.
• Das Einzelverhalten wird im Kontext untersucht. Verhaltensweisen sind meist sehr komplex und lassen sich nur schwerisolieren und kontrollieren, wie das fur Laborversuche versucht wird.
• Im Vordergrund steht das neutrale Beschreiben und nicht die Bewertung. Wertung sozialen Handelns orientiert sich anmoralischen Maßstaben, die jedoch kontextabhangig sind. Setzen wir uns die eigene moralische Brille auf, werden wirmeist schlechtsichtiger und ubersehen wichtige Details. Wir sind bei der Ist-Analyse am Ist- und nicht am Soll-Verhalteninteressiert.
• Wir versuchen, die Sicht der Handelnden einzunehmen, d.h. wir beschreiben das Verhalten in Begriffen, die fur denHandelnden relevant und bedeutungsvoll sind.
Die Einhaltung dieser Prinzipien sichert uns einen besseren Einblick.
Anforderungsanalyse
Interview im Kontext
ist eine Form der ethnographischen Untersuchung
nach dem Meister-Lehrling-Modell
Lernen durch Vormachen und Beobachten sowie Fragen und Klaren
gepragt durch
BescheidenheitNeugierAufmerksamkeitkonkrete (statt abstrakter) Fragen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 145 / 634
Interview im Kontext
ist eine Form der ethnographischen Untersuchung
nach dem Meister-Lehrling-Modell
Lernen durch Vormachen und Beobachten sowie Fragen und Klaren
gepragt durch
BescheidenheitNeugierAufmerksamkeitkonkrete (statt abstrakter) Fragen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Interview im Kontext
Eine spezielle Form der ethnographischen Untersuchung ist das Interview im Kontext. Es orientiert sich amMeister-Lehrling-Modell. Lernen findet hier in der Beobachtung des Meisters, im aktiven Nachfragen und Zeigensowie im Mitmachen statt. Statt in einem Frontalunterricht im Horsaal zu theoretisieren, nimmt der Meister seinenLehrling mit auf die Baustelle. Der Meister arbeitet vor und der Lehrling lernt aus der Beobachtung. Der Lehrlingfragt nach, wenn ihm etwas nicht klar ist, und er versucht sich auch selbst. Das Meister-Lehrling-Modell ist gepragtdurch Bescheidenheit, Neugier, Aufmerksamkeit und konkrete (statt abstrakter) Fragen des Lehrlings imunmittelbaren Kontext.
Anforderungsanalyse
Beispiel eines Ablaufes
1 Einleitung (15 min)Vorstellung, Ziele, DankZustimmung zu Aufzeichnung, VertraulichkeitArbeit, nicht Person wird betrachtet!Meinungen zu technischer Unterstutzung?Uberblick gewinnen
2 Ubergang (1 min)Regeln, Rollen, Beziehungich frage, Sie durfen abwehren
3 Erhebung im Kontext (2 Std.)Beobachtung und NachfragenNotizen machen, mitlaufen, sich unsichtbar machenPausen nach Wunsch
4 Zusammenfassung (15 min)was die Beschaftigte tut, ihre Rollewas wichtig istErganzungen, Korrekturen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 146 / 634
Beispiel eines Ablaufes
1 Einleitung (15 min)Vorstellung, Ziele, DankZustimmung zu Aufzeichnung, VertraulichkeitArbeit, nicht Person wird betrachtet!Meinungen zu technischer Unterstutzung?Uberblick gewinnen
2 Ubergang (1 min)Regeln, Rollen, Beziehungich frage, Sie durfen abwehren
3 Erhebung im Kontext (2 Std.)Beobachtung und NachfragenNotizen machen, mitlaufen, sich unsichtbar machenPausen nach Wunsch
4 Zusammenfassung (15 min)was die Beschaftigte tut, ihre Rollewas wichtig istErganzungen, Korrekturen?
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Ist-Analyse
Beispiel eines Ablaufes
Ein Interview im Kontext dauert in der Regel zwei Stunden plus direkte Vor- und Nachbearbeitung. Es konnte wiefolgt ablaufen:
1. In einer Einleitung (15 min) stellt sich der Fragende kurz vor und erlautert das Ziel der Befragung. Er vergisst nicht,sich ausdrucklich fur das Interview zu bedanken. Er sichert absolute Vertraulichkeit zu und vergewissert sich uber dasEinverstandnis des Befragten. Er weist darauf hin, dass die Arbeit betrachtet werden soll und nicht die Person. Mankann technische Hilfen fur das Interview mitbringen, wie z.B. ein Audio- oder Videoaufnahmegerat. Wenn das der Fallist, holt man sich spatestens jetzt noch das Einverstandnis des Beobachteten ein.
2. Im Ubergang zur Erhebung im Kontext (1 min) bespricht man die Regeln, Rollen und die Beziehung zwischenBeobachter und Beobachtetem. Die Rolle des Beobachters ist es, zu beobachten und Fragen zu stellen. Die Rolle desBeobachteten ist es, sich moglichst wie gewohnlich zu verhalten. Eine Grundregel lautet, dass der Beobachtete Fragenauch abwehren darf.
3. Der Hauptteil ist die Erhebung im Kontext, die zwei Stunden moglichst nicht uberschreiten sollte, weil spatestens danndie Konzentration auf beiden Seiten nachgelassen hat. In der Erhebung beobachtet man und fragt nach. Man machtsich Notizen, lauft mit, macht sich aber moglichst unsichtbar, um das beobachtete Geschehen so wenig wie moglich zubeeinflussen. Pausen konnen nach Wunsch gemacht werden.
4. In der Zusammenfassung (15 min), erlautert man, was man beobachtet hat und lasst den Beobachteten korrigieren underganzen. Der Beobachtete erlautert sein Tun und seine Rolle und weist auf Wichtiges hin.
Anforderungsanalyse
Wegweiser
Soll-Analyse
Wie konnen wir dem Benutzer fruhzeitig einkonkretes Bild vermitteln, wie wir das Problem zu
losen gedenken?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 147 / 634
Wegweiser
Soll-Analyse
Wie konnen wir dem Benutzer fruhzeitig einkonkretes Bild vermitteln, wie wir das Problem zu
losen gedenken?
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Wegweiser
Durch Analyse von Dokumenten, Beobachtungen und Fragen haben wir den Ist-Zustand erfasst. Die Analyse desErfassten deckt die Schwachstellen auf, die wir mit einer softwaretechnischen Losung beseitigen sollen. Der nachsteSchritt ist nun auszuarbeiten, was die softwaretechnische Losung dazu leisten muss. Dieser Aufgabe widmet sichdie Soll-Analyse. Die Soll-Analyse muss die Anforderungen an die zu implementierende Software aufstellen. Dazugehort es auch, diese Anforderungen hinsichtlich ihrer Machbarkeit und Folgen einzuschatzen. In diesem Abschnittlernen wir eine Technik kennen, mit der wir sowohl Anforderungen uberprufen als auch technische Machbarkeituntersuchen konnen.
Beobachtungen setzen den beobachteten Gegenstand voraus. Somit zielen Beobachtungen klar auf den Ist-Zustandab. Unsere softwaretechnische Losung existiert aber noch nicht. Fragen hingegen sind sowohl hilfreiche Mittel furdie Ist-Analyse als auch fur die Soll-Analyse. Wir konnen z.B. die Benutzer fragen, wie etwas sein soll. Auf welcheProbleme wir dabei allerdings stoßen, haben wir schon ganz zu Anfang bei der Einfuhrung zur Anforderungsanalysebesprochen. Die Benutzer konnen oft auf Problem hinweisen, sie tun sich oft aber schwerer, eine geeignete Losungzu ersinnen. Insbesondere fehlt ihnen dazu meist die realistische Einschatzung zur technischen Machbarkeit, fur diesie einen softwaretechnischen Hintergrund brauchten. Zudem richten sich Fragen an das bewusste Wissen und wirkonnen damit nur eingeschrankt relevante Aspekte erfassen.
Wenn aber Beobachtungen ausscheiden und Fragen nicht hinreichend sind, wie konnen wir dann vorgehen? Es gibtdas geflugelte Wort des Benutzers: I know it when I see it. Ich weiß, was ich will, sobald ich es sehe. Dieses Prinzipkonnen wir umsetzen: Wir fuhren dem Benutzer unsere Losung vor, zu der er dann Stellung nehmen kann.Naturlich konnen wir uns es nicht leisten, gleich das gesamte System zu implementieren, denn der Schaden waregroß, wenn diese Losung dann doch nicht das war, was der Benutzer haben mochte. Statt dessen implementierenwir einen so genannten Prototypen.
Anforderungsanalyse
Prototyping
Zielsetzung:
Anforderungen anhand eines Beispiels erheben und uberprufen
technische Moglichkeiten uberprufen und demonstrieren
fruhzeitig mogliche Losungsansatze prasentieren
Idee:
rasche und billige Entwicklung eines prototypischen Systems alsDiskussionsgrundlage
Typen unterscheiden sich in . . .
Lebensdauer: Wegwerfprototyp, evolutionarer Prototyp
Zweck: technische Machbarkeit, Demonstration der Funktionalitatoder Interaktion
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 148 / 634
Prototyping
Zielsetzung:
Anforderungen anhand eines Beispiels erheben und uberprufen
technische Moglichkeiten uberprufen und demonstrieren
fruhzeitig mogliche Losungsansatze prasentieren
Idee:
rasche und billige Entwicklung eines prototypischen Systems alsDiskussionsgrundlage
Typen unterscheiden sich in . . .
Lebensdauer: Wegwerfprototyp, evolutionarer Prototyp
Zweck: technische Machbarkeit, Demonstration der Funktionalitatoder Interaktion2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Prototyping
Prototypen sind Zwischenprodukte in der Entwicklung, die dem Endprodukt in bestimmten relevanten Aspektenbereits stark ahneln sollen, die aber noch nicht vollstandig sind. Eine andere Sichtweise von Prototypen ist es, sieals ein kostengunstigeres Modell fur das Endprodukt zu betrachten.
Prototypen sind in anderen Ingenieursdisziplinen allgegenwartig. Architekten lassen dreidimensionalemaßstabsgetreue kleine Modelle eines Gebaudes anfertigen. Ein zukunftiger Bewohner kann auf diese Weise einenwesentlich lebendigeren Eindruck erhalten als es ihm mit einem Bauplan moglich ware. Flugzeugbauer erproben anPrototypen den Windwiderstand im Windkanal.
Diese Idee ubernimmt die Softwaretechnik. Die Ziele hierbei sind meist, die Anforderungen anhand eines Beispielszu erheben und uberprufen, technische Moglichkeiten zu uberprufen und demonstrieren oder fruhzeitig moglicheLosungsansatze zu prasentieren (letztere Prototypen werden auch als Demonstratoren bezeichnet). Die Idee derPrototypen in der Softwaretechnik ist dieselbe wie bei anderen Ingenieursdisziplinen: die rasche und billigeEntwicklung eines prototypischen Systems zur Erprobung.
Unter dem Begriff Prototypen versammeln sich in der Softwaretechnik aber sehr unterschiedliche Formen. Mankann sie unterscheiden anhand zweier unterschiedlicher Merkmale: zum einen anhand der Lebensdauer(Wegwerfprototyp, evolutionarer Prototyp), zum anderen anhand des Zwecks (Uberprufung der technischenMachbarkeit oder Demonstration der Funktionalitat oder Interaktion).Wir werden sie im Folgenden naher kennen lernen.
Anforderungsanalyse
Typen von Prototypen in Bezug auf Lebensdauer
Wegwerf-Prototyp:
beschreibt ein Softwaresystem exemplarisch
dient zur Erhebung und Analyse von Anforderungen oder zurUberprufung technischer Machbarkeit
demonstriert die Funktionalitat, die mit Stakeholdern diskutiertwerden soll
implementiert nicht notwendigerweise die gezeigte Funktionalitat(z.B. GUI-Prototyp)
ist als Komponente fur das Endprodukt ungeeignet, weil billig erstellt
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 149 / 634
Typen von Prototypen in Bezug auf Lebensdauer
Wegwerf-Prototyp:
beschreibt ein Softwaresystem exemplarisch
dient zur Erhebung und Analyse von Anforderungen oder zurUberprufung technischer Machbarkeit
demonstriert die Funktionalitat, die mit Stakeholdern diskutiertwerden soll
implementiert nicht notwendigerweise die gezeigte Funktionalitat(z.B. GUI-Prototyp)
ist als Komponente fur das Endprodukt ungeeignet, weil billig erstellt
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Typen von Prototypen in Bezug auf Lebensdauer
Der Wegwerfprototyp hat eine sehr begrenzte Lebensdauer. Er wird in keinem Fall zum Endprodukt werden. SeinZiel ist es, einen Aspekt – sei es Funktionalitat oder Interaktion – exemplarisch zu untersuchen oder zudemonstrieren. Dazu wird der relevante Aspekt mit moglichst billigen Mitteln realisiert (nicht notwendigerweiseimmer dadurch, dass tatsachlich Code geschrieben wird; siehe unten). Alle anderen Aspekte sind nicht realisiert.Weil der Prototyp unvollstandig ist und mit billigen Mitteln erstellt wird, ist er fur das Endprodukt ungeeignet –daher sein Name. Hat er den Aspekt demonstriert, wird er weggeworfen.
Anforderungsanalyse
Typen von Prototypen in Bezug auf Lebensdauer
Evolutionarer Prototyp:
dient zur schnellen Bereitstellung eines funktionsfahigen Systems imRahmen von evolutionaren Prozessmodellen zur Softwareentwicklung
wird in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 150 / 634
Typen von Prototypen in Bezug auf Lebensdauer
Evolutionarer Prototyp:
dient zur schnellen Bereitstellung eines funktionsfahigen Systems imRahmen von evolutionaren Prozessmodellen zur Softwareentwicklung
wird in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Typen von Prototypen in Bezug auf Lebensdauer
Im Gegensatz zum Wegwerf-Prototypen ist es beim evolutionaren Prototypen vorgesehen, ihn schrittweise zumEndprodukt auszubauen. Er dient dazu, ein funktionsfahiges Systems moglichst schnell bereit zu stellen, wobei aberzu Anfang nicht die vollstandige Funktionalitat erwartet wird. Evolutionare Prototypen finden ihren Einsatz unteranderem im Rahmen von evolutionaren Prozessmodellen zur Softwareentwicklung.
Der Vorteil dieser inkrementellen Entwicklung ist es, dass jede funktionstuchtige Ausbaustufe vom Benutzer erprobtwerden kann. Die Erfahrung und Kritik der Benutzer mit der Ausbaustufe nimmt Einfluss auf die nachsteAusbaustufe. Iterativ wird der evolutionare Prototyp in weiteren Ausbaustufen zum endgultigen Produktweiterentwickelt.
Bsp.: Die Ausbaustufen fur die evolutionare Entwicklung eines Textverarbeitungssystems konnten zum Beispiel soaussehen:
1. grundlegende Funktionalitat: Datei-Management, Editor, Textausgabe
2. erweiterte Funktionalitat: Style-Files, Bearbeitung mathematischer Formeln, Einbinden von Graphiken
3. zusatzliche Funktionalitat: Rechtschreibprufung, Grammatikuberprufung, Uberarbeitungsmodus
4. erganzende Funktionalitat: Tabellenkalkulation, Geschaftsgraphiken, E-Mail, Web-Browser, Scanner-Anbindung
�
Anforderungsanalyse
Typen von Prototypen in Bezug auf Zweck
Technischer Prototyp:
zeigt die technische Umsetzbarkeit von Ansatzen zur Problemlosung
implementiert einen (kleinen) Ausschnitt der Funktionalitat desSystems
wird eher zur Machbarkeitsabschatzung und -demonstration eingesetzt
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 151 / 634
Typen von Prototypen in Bezug auf Zweck
Technischer Prototyp:
zeigt die technische Umsetzbarkeit von Ansatzen zur Problemlosung
implementiert einen (kleinen) Ausschnitt der Funktionalitat desSystems
wird eher zur Machbarkeitsabschatzung und -demonstration eingesetzt
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Typen von Prototypen in Bezug auf Zweck
Wegwerfprototypen und evolutionare Prototypen unterscheiden sich anhand ihrer Lebensdauer. Ein vollig anderesUnterscheidungsmerkmal ist der Zweck, den man mit dem Prototypen verfolgt. Technische Prototypen zielen aufdie technische Umsetzbarkeit von Ansatzen zur Problemlosung. Dazu implementiert der Prototyp einen (kleinen)Ausschnitt der Funktionalitat des Systems. Technische Prototypen werden somit eher zur Machbarkeitsabschatzungund -demonstration eingesetzt. Sie gleichen dem Crash-Test-Stand, mit dessen Hilfe man das Verhalten vonKarosserien im Automobilbau untersucht.
Technische Prototypen konnen sowohl fur den Wegwurf oder den evolutionaren Ausbau vorgesehen sein. Siekonnen sich des Weiteren unterschieden in Bezug auf die Softwarearchitektur.
Anforderungsanalyse
Horizontaler vs. vertikaler technischer Prototyp
Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Oberflachenprototyp
System−Software
Netzwerk Datenhaltung
Anwendungslogik
Benutzungsschnittstelle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 153 / 634
Anforderungsanalyse
Horizontaler vs. vertikaler technischer Prototyp
Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Anwendungsprototyp
System−Software
Netzwerk Datenhaltung
Anwendungslogik
Benutzungsschnittstelle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 154 / 634
Horizontaler vs. vertikaler technischer Prototyp
Horizontaler Prototyp: realisiert Aspekte einer spezifischen Ebene desSoftwaresystems; Bsp: Anwendungsprototyp
System−Software
Netzwerk Datenhaltung
Anwendungslogik
Benutzungsschnittstelle2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Horizontaler vs. vertikaler technischer Prototyp
Softwaresysteme konnen zumindest konzeptionell in verschiedene Schichten eingeteilt werden, die jeweils vonbestimmten Aspekten abstrahieren. Grob kann die Implementierung einteilen in die Schicht der Systemsoftware, diedurch das Betriebssystem zur Verfugung gestellt wird, Schichten mit technischen Diensten, wieNetzwerkkommunikation oder Datenhaltung, sowie die Schicht, die die eigentlich anwendungsspezifische Logikimplementiert und die Schicht der Benutzungsschnittstelle, die die Interaktion mit dem Benutzer ubernimmt.
Hinsichtlich dieses konzeptionellen Aufbaus, kann man technische Prototypen weiter in horizontale und vertikalePrototypen unterscheiden.
Der horizontale technische Prototyp realisiert Aspekte einer spezifischen Ebene des Softwaresystems. DerAnwendungsprototyp implementiert zum Beispiel die Anwendungslogik und der Oberflachenprototyp dieBenutzungsschnittstelle. Hiermit untersucht oder demonstriert man die Funktionalitat einer ausgesuchten Schicht.
Da eine Schicht auf die andere aufbaut, aber nur eine Schicht implementiert wird, benotigen wir neben derImplementierung der relevanten Schicht selbst noch einen Simulator fur die Schicht, auf die sich die relevanteSchicht stutzt. Man kann diese als Stumpf implementieren. Ein Stumpf bietet nicht die volle Funktionalitat,sondern liefert auf die Anfragen der hoheren Schicht einfach nur vorgefertigte Ergebnisse. Oberflachenprototypenkonnen zum Beispiel so implementiert werden, dass die Anwendungsschicht alle Daten, die in der Oberflache furbestimmte Anwendungsszenarien sichtbar sein sollen, in internen Tabellen abgespeichert hat und sie ohne weitereBerechnungen einfach als Ergebnis einer aufgerufenen Operation zuruck liefert. Damit zeigt der Oberflachentypmoglicherweise falsche Daten an, aber zumindest die Interaktion lasst sich demonstrieren.
Anforderungsanalyse
Horizontaler vs. vertikaler technischer Prototyp
Vertikaler Prototyp: realisiert ausgewahlte Aspekte des Softwaresystemsvollstandig
System−Software
Netzwerk Datenhaltung
Anwendungslogik
Benutzungsschnittstelle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 155 / 634
Horizontaler vs. vertikaler technischer Prototyp
Vertikaler Prototyp: realisiert ausgewahlte Aspekte des Softwaresystemsvollstandig
System−Software
Netzwerk Datenhaltung
Anwendungslogik
Benutzungsschnittstelle2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Horizontaler vs. vertikaler technischer Prototyp
Der vertikale technische Prototyp realisiert ausgewahlte Aspekte des Softwaresystems vollstandig durch alleSchichten hindurch. Er stellt einen Durchstich durch das System dar. Mit seiner Hilfe lasst sich die Zusammenarbeitverschiedener Schichten untersuchen. Er findet auch bei inkrementeller Entwicklung Einsatz, bei der die ersteAusbaustufe funktionstuchtig ist (wenn auch nicht alle Funktionen implementiert sind). Dann wird der Durchstichin die Breite in den weiteren Ausbausstufen ausgedehnt, um die restliche Funktionalitat zu implementieren. Mangeht also zuerst in die Tiefe und dann in die Breite bei diesem Vorgehen.
Wir setzen solche Prototypen wahrend der Anforderungsanalyse ein, wenn wir kritische Anforderungen haben, vondenen wir nicht sicher sind, dass wir sie realisieren konnen. Ansonsten werden sie auch gerne vor Entwurf derArchitektur angewandt, um einzusetzende Technologien oder geplante Entwurfe zu untersuchen.
Anforderungsanalyse
Prototypen fur Interaktion: Storyboards
Storyboards:
Prototypen fur die Interaktion zwischen Mensch und Maschine
demonstrieren das zu diskutierende Systemverhalten als”Geschichte“
Typen:
passives Storyboard (Papierprototyp)
aktives Storyboard (animierter Prototyp)
interaktives Storyboard (ausfuhrbarer Prototyp)������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
Aufwand
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 156 / 634
Prototypen fur Interaktion: Storyboards
Storyboards:
Prototypen fur die Interaktion zwischen Mensch und Maschine
demonstrieren das zu diskutierende Systemverhalten als”Geschichte“
Typen:
passives Storyboard (Papierprototyp)
aktives Storyboard (animierter Prototyp)
interaktives Storyboard (ausfuhrbarer Prototyp)������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
Aufwand20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Prototypen fur Interaktion: Storyboards
In der Anforderungsanalyse mussen wir die Interaktion zwischen Benutzer und Anwender festlegen. DieserInteraktion nimmt eine Schlusselrolle ein, weil ein Softwaresystem, das alle gewunschten Funktionalitaten bietet,dennoch unbrauchbar sein kann, wenn man es nicht benutzen kann. Aus diesem Grunde wollen schon sehr fruh,Interaktion ausprobieren konnen und sie Kunden und Benutzern vorstellen. Hier konnen wir Oberflachenprototypenentwickeln.
Oberflachenprototypen sind horizontale Prototypen, bei denen die Interaktion untersucht oder demonstriert werdensoll. Meist dienen sie weniger der technischen Machbarkeit, sondern vielmehr der konzeptionellen Angemessenheitund Schlussigkeit. Wir untersuchen damit, ob der Benutzer spater mit unserem System effizient und effektivinteragieren kann.
Dem Oberflachenprototypen kommt unter den Prototypen eine Sonderstellung zu, weil es die Oberflache ist, die derBenutzer spater sehen und bedienen wird. Alle anderen Schichten sind fur ihn unsichtbar. Wenn wir die von unseinzusetzenden Implementierungsechnologien bereits sicher beherrschen, konnen wir auf solche technischePrototypen tieferer Schichten verzichten. Weil wir aber in der Anforderungsspezifikation auch dieBenutzungsschnittstelle beschreiben mussen und die Qualitat einer Software aus Benutzersicht steht und fallt mitihrer Benutzbarkeit, sind Oberflachenprototypen fur die Anforderungsanalyse unerlasslich.
Aus diesem Grunde genießen Oberflachenprototypen hier unser Hauptaugenmerk. Wir unterscheiden dabei diefolgenden Typen:
• passives Storyboard (Papierprototyp)
• aktives Storyboard (animierter Prototyp)
• interaktives Storyboard (ausfuhrbarer Prototyp)
Alle Typen von Storyboards beschreiben die zukunftige Interaktion mit dem System als eine Art Drehbuch, daherihr Name. Sie unterscheiden sich jedoch im Grad ihrer Interaktivitat. Das interaktive Storyboard bietet dabei diehochste Interaktivitat. Mit dem Grad der Interaktivitat steigen aber auch die Kosten fur die Entwicklung desStoryboards. Wir werden im Folgenden diese drei Typen naher beschreiben.
Anforderungsanalyse
Passive Storyboards
Demonstration:
Analytiker spielt die Bedienung mit dem System durch, indem erentlang eines Anwendungsszenarios Eingabemoglichkeiten undSystemreaktionen demonstriert
Mittel:
Skizzen
Bildschirm-Masken (Screenshots)
mogliche Systemausgaben
Bemerkung:
+ ermoglicht einfache und billige Prototyperstellung
+ ermoglicht Interaktion mit Beteiligten am Beispiel
- erfordert Anwesenheit des Analytikers
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 157 / 634
Passive Storyboards
Demonstration:
Analytiker spielt die Bedienung mit dem System durch, indem erentlang eines Anwendungsszenarios Eingabemoglichkeiten undSystemreaktionen demonstriert
Mittel:
Skizzen
Bildschirm-Masken (Screenshots)
mogliche Systemausgaben
Bemerkung:
+ ermoglicht einfache und billige Prototyperstellung
+ ermoglicht Interaktion mit Beteiligten am Beispiel
- erfordert Anwesenheit des Analytikers20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Passive Storyboards erlauben selbst keine Interaktion. Statt dessen spielt der Analytiker bei der Demonstration dieBedienung mit dem System durch, indem er entlang eines Anwendungsszenarios die Eingabemoglichkeiten undSystemreaktionen demonstriert.
Als Mittel werden Skizzen, Bildschirm-Masken in Form von Bildschirmabzugen (Screenshots) und moglicheSystemausgaben verwendet. Die einfachsten Materialien sind Papier und Bleistift. Dafur sprechen die besonderseinfache und billige Prototyperstellung sowie die Moglichkeit zur Interaktion mit den Beteiligten am konkretenBeispiel. Der Benutzer selbst kann mit diesen Materialien selbst umgehen und an der Entwicklung des Prototypendirekt mitwirken.
Passive Storyboards
Demonstration:
Analytiker spielt die Bedienung mit dem System durch, indem erentlang eines Anwendungsszenarios Eingabemoglichkeiten undSystemreaktionen demonstriert
Mittel:
Skizzen
Bildschirm-Masken (Screenshots)
mogliche Systemausgaben
Bemerkung:
+ ermoglicht einfache und billige Prototyperstellung
+ ermoglicht Interaktion mit Beteiligten am Beispiel
- erfordert Anwesenheit des Analytikers20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Beispiel passives Storyboard
Bsp.: Unsere Analyse der Schwachstellen in der Ist-Analyse zu unserem Fahrradladenbeispiel hat ergeben, dass esoft schwierig ist, einen Kunden beim Einkauf eines Artikels fur ein Fahrrad, das sich schon in seinem Besitzbefindet, richtig zu beraten, weil er nicht weiß, welche Daten das Fahrrad hat. Wenn er einen Flaschenhalter kaufenmochte, so muss er zu den Ausmaßen und Bohrungen sowie der Farbe des Rahmens passen. Wenn er sie nichtkennt, kann ihm der Verkaufer keine Empfehlung aussprechen.
Wir haben uns entschlossen, einen Einkaufsassistenten auf Basis eines PDAs zu entwickeln. Auf diesem tragbarenKleinrechner sind alle Einkaufe des Kunden erfasst und zwar branchenubergreifend, also Fahrradteile genauso wieComputer-Hardware etc. Wir mochten dem Benutzer die zukunftige Interaktion mit einem solchen PDAdemonstrieren. Die Interaktion mit einem PDA hat besondere Herausforderungen, weil die darstellbare Flache sehrbegrenzt und typische Eingabegerate wie Maus und Tastatur nicht vorhanden sind.
Bild 1: Wir fertigen einen Papierprototypen an, indem wir einen realen PDA hernehmen und die dargestelltenElemente zeichnen und auf das Display legen. Das Bild zeigt die Einstiegsmaske mit den Produktgruppen desKaufers, die mit dem PDA verwaltet werden. Im Fahrradladen wahlt er das Fahrradsymbol aus, wenn er einenArtikel fur sein Fahrrad kaufen mochte. Dadurch gelangt er zum nachsten Dialog. �
Anforderungsanalyse
Beispiel passives Storyboard
abfragenändernentfernenersetzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 159 / 634
Beispiel passives Storyboard
abfragenändernentfernenersetzen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Beispiel passives Storyboard
Bsp.: Bild 2: Im nachsten Dialog wird sein Fahrrad angezeigt. Er kann dann mit dem Stift auf ein Bestandteilseines Rades tippen. Darauf hin wird ein Menu eingeblendet, in dem er die nachste Aktion auswahlen kann. Er kanneinen Artikel abfragen, um Daten uber ihn abzufragen, andern, um den Artikel in seinen Eigenschaften zu andern,entfernen, um ihn aus seiner Konfiguration zu loschen, oder ersetzen, um ihn durch einen neuen Artikel zu ersetzen.�
Anforderungsanalyse
Beispiel passives Storyboard
1
2
47 Euro
78 Euro
100 Euro
145 Euro3
4
5
6
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 160 / 634
Beispiel passives Storyboard
1
2
47 Euro
78 Euro
100 Euro
145 Euro3
4
5
6
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Beispiel passives Storyboard
Bsp.: Bild 3: Nehmen wir an, wir wahlen den Sattel aus, und wahlen ersetzen. Dann gelangen wir zum nachstenDialog. Als nachstes werden alle Sattel angezeigt, die zum Fahrrad des Kunden passen, sortiert nach dem Preis. Eswerden maximal vier Artikel angezeigt. Diese Liste kann weiter verarbeitet werden, indem wir mit den Stift tippenoder die Tasten bedienen. Beruhren wir mit dem Stift das Bild des Sattels (1), den Beschreibungstext (2) oder denPreis, dann gelangen wir zum Kaufdialog. Bedienen wir auf dem Tastenfeld die Nach-Oben- (4) beziehungsweisedie Nach-Unten-Taste (5) konnen wir den sichtbaren Ausschnitt in der Liste der gefundenen Artikel nach obenbeziehungsweise nach unten bewegen. Mit der Auswahltaste (5) gelangen wir zum Kaufdialog. �
Anforderungsanalyse
Beispiel passives Storyboard
1 2 1 2
8747 Euro
78 Euro
100 Euro
145 Euro 145 Euro
5 64 4 5 6
neinja
Artikel kaufen?Wollen Sie diesen
Screen Auswahl Screen Kaufen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 161 / 634
Beispiel passives Storyboard
1 2 1 2
8747 Euro
78 Euro
100 Euro
145 Euro 145 Euro
5 64 4 5 6
neinja
Artikel kaufen?Wollen Sie diesen
Screen Auswahl Screen Kaufen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Beispiel passives Storyboard
Bsp.: Bild 4: Im Kaufdialog wird nur der ausgewahlte Artikel angezeigt und der Kunde wird gefragt, ob er denArtikel kaufen mochte. Bestatigt er mit der Schaltflache “Ja” (7), dann wird der Artikel in den virtuellenWarenkorb des elektronischen Verkaufsassistenten gelegt, der vom Verkaufer an der Kasse ausgelesen werden kann.Mit der Schaltflache “Nein” wird der Vorgang abgebrochen, und man gelangt zum Auswahldialog zuruck.
Die Entscheidung, maximal vier Artikel anzuzeigen, haben wir in der Vorbereitung des Papierprototypen getroffen.Wir hatten sehr schnell im maßstabgetreuen Modell feststellen konnen, dass mehr als vier Artikel nicht auf demkleinen Monitor zu prasentieren sind. Wir haben jedoch versaumt, irgendwie kenntlich zu machen, dass mehr alsvier Artikel als Ergebnis der Suchanfrage geliefert wurden, aber nicht alle sichtbar sind. Der Kunde fragt unswahrend der Vorfuhrung, wie das denn zu erkennen sei. Der Kunde nimmt dann einen roten Farbstift, zeichnetdafur rote Pfeile nach oben beziehungsweise unten uber dem ersten beziehungsweise letzten angezeigten Elementein und sagt uns, dass er das gerne so hatte. Wahrend wir dem Kunden diesen Prototypen vorfuhren, bemerktdieser außerdem, dass wir im Auswahldialog keine Moglichkeit vorgesehen haben, den Dialog durch einen anderenWeg als zum Kaufdialog zu verlassen. Uns ist also glucklicherweise fruh genug vom Kunden klar gemacht worden,dass wir in der Dialogfuhrung einige Dinge ubersehen haben. Die Uberarbeitung unseres Papierprototypen ist abereinfach. So einfach, dass es der Kunde gleich selbst ubernehmen konnte. �
Passive Storyboards eignen sich besonders in der fruhen Phase des Interaktions-Designs, in der man den Benutzeraktiv in den Design-Prozess einbeziehen mochte.
Anforderungsanalyse
Aktive Storyboards
Demonstration:
Abspielen einer selbstablaufenden Prasentation des Systemverhaltens
Mittel:
Film, Diashow
selbstablaufende Prasentation
Bemerkung:
+ ermoglicht einfache automatisierte Darstellung von typischenAnwendungsszenarien
+ erfordert nicht unbedingt die Anwesenheit von Analytikern
- erlaubt keine Interaktion wahrend der Prasentation
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 162 / 634
Aktive Storyboards
Demonstration:
Abspielen einer selbstablaufenden Prasentation des Systemverhaltens
Mittel:
Film, Diashow
selbstablaufende Prasentation
Bemerkung:
+ ermoglicht einfache automatisierte Darstellung von typischenAnwendungsszenarien
+ erfordert nicht unbedingt die Anwesenheit von Analytikern
- erlaubt keine Interaktion wahrend der Prasentation20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Wahrend passive Storyboards durch den Analytiker demonstriert werden mussen, sind aktive StoryboardsPrasentationen des Systemverhaltens, die von selbst ablaufen. Sie laufen wie ein Film ab. Dazu kann mantatsachlich kontinuierliche Sequenzen wie in einem Film darstellen (z.B. mit Werkzeugen wie Macromedia Flashoder Camtesia) oder aber Einzelbilder der Dialoge (z.B. mit einer Prasentationssoftware wie OpenOffice oderPowerpoint) anzeigen.
Typische Anwendungsszenarien konnen automatisiert dargestellt werden. Weil ein aktives Storyboard von alleinablauft, ist die Anwesenheit von Analytikern nicht unbedingt erforderlich. Damit konnen solche Demos an eineVielzahl von moglichen Benutzern verschickt und deren Meinung eingeholt werden. Allerdings erlauben aktiveStoryboards keine Interaktion wahrend der Prasentation, was gerade in der fruhen Phase des Interaktions-Designswunschenswert ist.
Aktive Storyboards eignen sich besonders in einer fortgeschritteneren Phase des Interaktions-Designs, in der manein ausgearbeitetes Konzept sehr vielen Benutzern vorstellen mochte.
Anforderungsanalyse
Interaktive Storyboards
Demonstration:
Prototyp ermoglicht dem Benutzer die fruhzeitige Interaktion mit demmoglichen System; Funktionalitat kann evtl. durch Analytiker
”von
Hand“ simuliert werden
Mittel:
ausfuhrbares Programm, das Teile der Funktionalitat realisiert
Bemerkung:
+ ermoglicht Interaktion des Nutzers mit dem System
+ erlaubt großtmogliche Nahe zum realen System
- erfordert hoheren Aufwand bei Prototyp-Erstellung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 163 / 634
Interaktive Storyboards
Demonstration:
Prototyp ermoglicht dem Benutzer die fruhzeitige Interaktion mit demmoglichen System; Funktionalitat kann evtl. durch Analytiker
”von
Hand“ simuliert werden
Mittel:
ausfuhrbares Programm, das Teile der Funktionalitat realisiert
Bemerkung:
+ ermoglicht Interaktion des Nutzers mit dem System
+ erlaubt großtmogliche Nahe zum realen System
- erfordert hoheren Aufwand bei Prototyp-Erstellung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Interaktive Storyboards bieten die großtmogliche Interaktion mit dem System. Dazu wird ein ausfuhrbaresProgramm entwickelt, was die Eigenschaften der Benutzungsschnittstelle demonstriert. Es konnen einzelne Teile derFunktionalitat bereits prototypisch implementiert sein. Meist genugen aber auch vorbereitete Daten fur bestimmteSzenarien, die nicht wirklich berechnet, sondern nur in Reaktion auf die Eingabe des Benutzers angezeigt werden.Die Daten mussen auch nicht korrekt sein, solange es nur um die Demonstration der Interaktion geht. DieFunktionalitat kann unter Umstanden auch durch den Analytiker
”von Hand“ simuliert werden.
Interaktive Storyboards ermoglichen echte Interaktion des Nutzers mit dem System mit einer großtmoglichen Nahezum realen System. Dabei muss der Analytiker nicht bei der Demonstration anwesend sein. Allerdings kann derBenutzer auch hier nicht selbst eingreifen, um eigene Vorstellungen einzubringen, und wir haben einen hoherenAufwand bei der Prototyp-Erstellung. GUI-Design-Werkzeuge konnen jedoch einen Teil des Aufwands reduzieren.
Interaktive Storyboards werden in der Regel in spateren Phasen des Interaktions-Designs entwickelt, bei denen manschon genaue Vorstellungen entwickelt hat. Sie konnen fur Nutzertests zur Gebrauchsttauglichkeit des Systemseingesetzt werden, indem man verschiedene Nutzer (pro Persona mindestens einen) mit dem System interagierenlasst und diese Interaktion beobachtet und auswertet.
Anforderungsanalyse
Vor- und Nachteile des Einsatzes von Prototypen
+ erlauben fruhzeitige Demonstration von Losungsansatzen
+ erlauben fruhzeitige Beteiligung der Benutzer
+ vermeiden das”Leere-Blatt-Syndrom“
+ reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mitBeteiligten
+ geeignete Werkzeuge ermoglichen die schnelle Erstellung vonPrototypen
– erfordern erhohten Entwicklungsaufwand durch (zusatzliche)Prototyp-Entwicklung
– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 164 / 634
Vor- und Nachteile des Einsatzes von Prototypen
+ erlauben fruhzeitige Demonstration von Losungsansatzen
+ erlauben fruhzeitige Beteiligung der Benutzer
+ vermeiden das”Leere-Blatt-Syndrom“
+ reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mitBeteiligten
+ geeignete Werkzeuge ermoglichen die schnelle Erstellung vonPrototypen
– erfordern erhohten Entwicklungsaufwand durch (zusatzliche)Prototyp-Entwicklung
– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Vor- und Nachteile des Einsatzes von Prototypen
Zum Ende des Abschnitts uber Prototypen fassen wir die Vor- und Nachteile von Prototypen zusammen.Vorteile:
+ Prototypen erlauben eine fruhzeitige Demonstration von Losungsansatzen mit vertretbaren Kosten. Gerade weil derInteraktion eine hohe Bedeutung zukommt und sie auch in der Anforderungsspezifikation genau beschrieben sein sollte,sollten wir in der Anforderungsanalyse prazise Konzepte entwickeln und sie dem Kunden und Benutzer vorfuhren, um dieKonzepte zu evaluieren und zu verbessern. Andererseits konnen wir zu einem so fruhen Zeitpunkt nicht die ganzeApplikation bereits entwickeln. Darum also Prototypen.
+ Prototypen erlauben damit eine fruhzeitige Beteiligung der Benutzer. Der Benutzer selbst kann sich ein genaueres Bilddes spateren Systems machen und fruhzeitig korrigierend eingreifen.
+ Prototypen vermeiden das”Leere-Blatt-Syndrom“, das wir von Schriftstellern kennen, die die erste Seite ihres neuen
Romans schreiben sollen. Mit Prototypen konnen wir direkt loslegen. Insbesondere Papierprototypen helfen uns einenschnellen Einstieg zu finden, weil sie billig herzustellen und leicht anderbar sind.
+ Prototypen reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mit Beteiligten. Wir wissen, wie teuer uns spateAnderungen kommen. Darum stellen wir durch fruhes Vorzeigen und Einbeziehen der Benutzer sicher, dass wir auf demrichtigen Weg sind. Dafur ist eine Anfangsinvestition notwendig, um den Prototypen zu entwickeln, die sich aber imVerlaufe des Projekts mit sehr hoher Wahrscheinlichkeit amortisiert, weil weniger Fehler in der Anforderungsanalysegemacht werden.
+ Geeignete Werkzeuge ermoglichen die schnelle Erstellung von Prototypen, so dass sich die Kosten in Grenzen halten.Beispielsweise gibt es GUI-Builder, mit denen man sich rasch graphische Benutzeroberflachen zusammen klicken kann.Oder man benutzt Werkzeuge wie Graphikprogramme (auch scripting-fahige, wie Adobe Flash) undPrasentationssoftware.
Vor- und Nachteile des Einsatzes von Prototypen
+ erlauben fruhzeitige Demonstration von Losungsansatzen
+ erlauben fruhzeitige Beteiligung der Benutzer
+ vermeiden das”Leere-Blatt-Syndrom“
+ reduzieren Entwicklungsrisiken durch fruhzeitige Diskussion mitBeteiligten
+ geeignete Werkzeuge ermoglichen die schnelle Erstellung vonPrototypen
– erfordern erhohten Entwicklungsaufwand durch (zusatzliche)Prototyp-Entwicklung
– Gefahr, dass Wegwerf-Prototyp Teil des Produkts wird (z.B. ausZeitdruck)2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Soll-Analyse: Prototyping
Vor- und Nachteile des Einsatzes von Prototypen
Nachteile:
– Auch wenn Prototypen billiger sind als das Endprodukt, so erfordern Prototypen einen erhohten Entwicklungsaufwanddurch die zusatzlich Prototyp-Entwicklung. Je nach Ausbau des Prototypen konnen die Kosten erheblich sein.
– Bei der Entwicklung von Wegwerfprototypen wird kein großer Wert auf Qualitat gelegt; sie mussen zeigen, was siezeigen sollen, und ansonsten moglichst billig sein. Der großte Nachteil dieser Prototypen ist somit die Gefahr, dass siezum Teil des Produkts werden (z.B. aus Zeitdruck). Bei interaktiven Storyboards erhalten Kunde und Projektmanagerden Eindruck, dass das System schon beinahe fertig ist. Die Versuchung ist groß, den Wegwerfprototypen auszubauen,statt ihn wie geplant wegzuwerfen. Das racht sich jedoch in der Regel, weil die Qualitat des Wegwerfprototypen einsolches Vorgehen nicht unterstutzt. Dieser Gefahr kann man durch Papierprototypen oder durch eine Entwicklung miteiner Programmiersprachen, die man spater fur das Endprodukt nicht benutzen mochte, vorbeugen.
Anforderungsanalyse
Wegweiser
Analysetechniken
Wann wird welche Analysetechnik eingesetzt?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 165 / 634
Anforderungsanalyse
Analysetechniken
Ist-Zustand Soll-Zustand FolgenAuswertung vorhandener + - -Daten/DokumenteBeobachtungen + ◦ -Befragung- geschlossene Fragen + ◦ -- offene Fragen + ◦ -- hybride Fragen + ◦ -Prototyping - + +partizipative Entwicklung - + +
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 166 / 634
Analysetechniken
Ist-Zustand Soll-Zustand FolgenAuswertung vorhandener + - -Daten/DokumenteBeobachtungen + ◦ -Befragung- geschlossene Fragen + ◦ -- offene Fragen + ◦ -- hybride Fragen + ◦ -Prototyping - + +partizipative Entwicklung - + +
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Zusammenfassung der Techniken
Analysetechniken
Zum Abschluss der Ist- und Sollanalyse fassen wir noch einmal die Techniken, die wir kennen gelernt haben,zusammen und bewerten ihre Eignung fur das Erfassen des Ist-Zustands, der Planung des Soll-Zustands und derAbschatzung mittel- und langfristiger Folgen unserer anvisierten Softwarelosung. Die folgende Tabelle gibt einenUberblick:
Ist-Zustand Soll-Zustand FolgenAuswertung vorhandener + - -Daten/DokumenteBeobachtungen + ◦ -Befragung- geschlossene Fragen + ◦ -- offene Fragen + ◦ -- hybride Fragen + ◦ -Prototyping - + +partizipative Entwicklung - + +
Die Auswertung vorhandener Dokumente ist ein Instrument rein fur die Erhebung des Ist-Zustands, weil sie aufExistierendem basiert. Befragung und Beobachtung setzen auch etwas Existierendes voraus. Man kann sie aberauch einsetzen, um Prototypen zu evaluieren. Prototypen sind eine Vision des Soll-Zustandes, die handfest unduberprufbar ist. Mit ihnen kann man durch geeignete Evaluierung auch die Folgen des Einsatzes des spaterensSystems abschatzen. Man kann also zum Beispiel demonstrieren, dass fruhere Redundanzen und manuelle Eingriffenicht mehr existieren werden, was die Fehleranfalligkeit reduziert. Außerdem kann man nachweisen, dass einBenutzer schneller seine Aufgabe erledigen kann, als das vorher der Fall war.
Analysetechniken
Ist-Zustand Soll-Zustand FolgenAuswertung vorhandener + - -Daten/DokumenteBeobachtungen + ◦ -Befragung- geschlossene Fragen + ◦ -- offene Fragen + ◦ -- hybride Fragen + ◦ -Prototyping - + +partizipative Entwicklung - + +
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Zusammenfassung der Techniken
Analysetechniken
Die partizipative Entwicklung ist die Softwareentwicklung, die die spateren Benutzer einbezieht – wohl gemerkt, dieBenutzer, nicht nur den Kunden. Es gibt hierfur verschiedene Auspragungen. Die Benutzer konnen zu Anfang in derPhase des Interaktions-Designs bei der Entwicklung von Prototypen einbezogen werden und gegen Ende beimAkzeptanztest. Bei inkrementellen Entwicklungsprozessen, bei denen ein System in kleineren funktionstuchtigenInkrementen entwickelt werden, werden sie noch starker einbezogen. Dort evaluieren sie jedes einzelne Inkrement –also Zwischenprodukt – und nicht nur das Endprodukt. Da die Anforderungsanalyse bei der Entwicklungsphase desnachsten Inkrements wieder durchlaufen wird, kann der Benutzer an vielen Punkten der Entwicklung Einflussnehmen. Diese Idee wird beim Extreme Programming, einem agilen Entwicklungsprozess, zum Extrem getrieben,indem ein Benutzer vor Ort der Entwicklung ist und wochentlich das System testet und Verbesserungsvorschlageunterbreitet. Die Gebrauchstauglichkeit kann auf diese Weise besser sicher gestellt werden. Außerdem habenBenutzer die Moglichkeit, das System, das sie spater einsetzen sollen, mitzugestalten, was zu einer hoherenAkzeptanz fuhren sollte.
Anforderungsanalyse
Wegweiser
Anforderungsspezifikation
Wie halten wir die Anforderungen fest?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 167 / 634
Anforderungsanalyse
Anforderungsspezifikation nach IEEE Std 610.12-1990
Definition
requirement: condition or capability needed by a user to solve a problemor achieve an objective.
specification: document that specifies, in a complete, precise, verifiablemanner, the requirements (, ...) of a system or component, and, often, theprocedures for determining whether these provisions have been satisfied.
software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 168 / 634
Anforderungsspezifikation nach IEEE Std 610.12-1990
Definition
requirement: condition or capability needed by a user to solve a problemor achieve an objective.
specification: document that specifies, in a complete, precise, verifiablemanner, the requirements (, ...) of a system or component, and, often, theprocedures for determining whether these provisions have been satisfied.
software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Anforderungsspezifikation nach IEEE Std 610.12-1990
An die Ist- und Sollanalyse schließt sich die Formulierung der Anforderungen an. Die Sollanalyse ergibt, was dieSoftware leisten muss, um die Schwachstellen, die durch die Ist-Analyse offenbar wurden, zu beseitigen. DieSollanalyse hat jedoch nur die prinzipiellen Konzepte erarbeitet. Diese mussen wir nun prazise ausarbeiten und ambesten schriftlich festhalten. In diesem Abschnitt setzen wir uns deshalb mit der Frage auseinander, wie dieAnforderungen formuliert sein sollen. Bevor wir jedoch dazu kommen, mussen wir uber ein paar grundlegendeBegriffe einig werden. Was ist denn eine Anforderungsspezifikation genau?
Im Englischen wird die Anforderungsspezifikation Requirement Specification genannt, was sich aus Requirement furAnforderung und Specification zusammen setzt. Das Software-Engineering-Glossar IEEE Std 610.12-1990 definiertRequirement wie folgt:
Requirement : condition or capability needed by a user to solve a problem or achieve an objective.
Zu Deutsch: eine Anforderung ist eine Bedingung oder Fahigkeit, die von einem Benutzer benotigt wird, um einProblem zu losen oder ein Ziel zu erreichen.
Eine Spezifikation ist wie folgt definiert:
Specification : document that specifies, in a complete, precise, verifiable manner, the requirements (, ...) of a systemor component, and, often, the procedures for determining whether these provisions have been satisfied.
Eine Spezifikation ist ein Dokument, das vollstandig, prazise und uberprufbar die Anforderungen an ein Systemoder eine Komponente spezifiziert und oft auch die Prufprozeduren nennt, um festzustellen, ob diese Forderungentatsachlich erfullt sind.
Diese Definition erlautert nicht nur den Begriff Spezifikation, sondern stellt auch eine Reihe von Forderungen furSpezifikation auf. Sie sollen vollstandig, prazise und uberprufbar sein. Vollstandig bedeutet, dass die Spezifikationalle relevanten Anforderungen nennt. Prazise heißt, dass keine Anforderung missverstanden werden kann.Uberprufbar bedeutet, dass man fur jede Anforderung eine Prufprozedur angeben kann, anhand derer man objektivnachweisen kann, dass eine Anforderung erfullt ist. Wir werden uns mit diesen Eigenschaften und mit weiterenQualitaten, die eine gute Anforderungsspezifikation auszeichnen, in diesem Abschnitt noch auseinander setzen.
Anforderungsspezifikation nach IEEE Std 610.12-1990
Definition
requirement: condition or capability needed by a user to solve a problemor achieve an objective.
specification: document that specifies, in a complete, precise, verifiablemanner, the requirements (, ...) of a system or component, and, often, theprocedures for determining whether these provisions have been satisfied.
software requirements specification (SRS): documentation of theessential requirements (functions, performance, design constraints, andattributes) of the software and its external interfaces.2
00
9-0
2-0
9
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Anforderungsspezifikation nach IEEE Std 610.12-1990
Der zusammengesetzte Begriff Software Requirements Specification ist wie folgt definiert:
Software Requirements Specification : documentation of the essential requirements (functions, performance, design constraints,and attributes) of the software and its external interfaces.
Diese Definition erganzt die einzelnen Definitionen von Anforderung und Spezifikation um den Inhalt, der in einerAnforderungsspezifikation aufgefuhrt ist. Die Anforderungsspezifikation ist demnach eine Dokumentation derwesentlichen Anforderungen (Funktionen, Performanz, Entwurfseinschrankungen, und Attribute) einer Softwaresowie ihrer externen Schnittstellen. Diese Inhalte entstammen einer anderen IEEE-Norm, die beschreibt, wieAnforderungsspezifikation aufgebaut sind und welche Inhalte sie haben. Mit dieser Norm werden wir uns hier nochauseinander setzen.
Anforderungsanalyse
Anforderungen
Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlichFunktion und Qualitat.⇒ Wir mussen also die Funktion und Qualitat definieren.
Definition
Funktion: in der Zeit ablaufende Transformation
von Eingabedaten
in Ausgabedaten
unter Verwendung von Ressourcen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 169 / 634
Anforderungen
Anforderungen sind gleichbedeutend mit Minimalbedingungen hinsichtlichFunktion und Qualitat.⇒ Wir mussen also die Funktion und Qualitat definieren.
Definition
Funktion: in der Zeit ablaufende Transformation
von Eingabedaten
in Ausgabedaten
unter Verwendung von Ressourcen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Anforderungen
Anforderungen legen die Minimalbedingungen hinsichtlich Funktion und Qualitat fest. Was aber sind Funktionenund wie definiert man Qualitat fur Software?
Wahrend sich Funktionen uber den Zusammenhang von Eingaben des Benutzers und darauf hin erwarteteAusgaben unter Verwendung einer maximalen Menge von Ressourcen definieren lassen, ist der BegriffSoftwarequalitat weniger offensichtlich.
Anforderungsanalyse
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Wiederher-stellbarkeit
Fehler-toleranz
Verbrauchs-verhalten
Software-qualitat
Sicherheit
Interoperabilitat
Richtigkeit
Angemessenheit
Funktionalitat
OrdnungsmaßigkeitReife
Anderbarkeit
Stabilitat
Prufbarkeit
Analysierbarkeit
Modifizierbarkeit
Austauschbarkeit
Installierbarkeit
Anpassbarkeit
Konformitat Zeitverhalten
Verstandlichkeit
Erlernbarkeit
Bedienbarkeit
Ubertragbarkeit
Zuverlassigkeit
EffizienzBenutzbarkeit
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 170 / 634
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Wiederher-stellbarkeit
Fehler-toleranz
Verbrauchs-verhalten
Software-qualitat
Sicherheit
Interoperabilitat
Richtigkeit
Angemessenheit
Funktionalitat
OrdnungsmaßigkeitReife
Anderbarkeit
Stabilitat
Prufbarkeit
Analysierbarkeit
Modifizierbarkeit
Austauschbarkeit
Installierbarkeit
Anpassbarkeit
Konformitat Zeitverhalten
Verstandlichkeit
Erlernbarkeit
Bedienbarkeit
Ubertragbarkeit
Zuverlassigkeit
EffizienzBenutzbarkeit
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Der Begriff Softwarequalitat ist sehr vielschichtig. Im Allgemeinen bedeutet Qualitat lediglich, zu welchem Grad einGegenstand bestimmte Attribute aufweist. Wahrend die Qualitat einer Schraube recht einfach durch die AttributeFestigkeit, Gewicht, Material, Preis etc. festgelegt werden kann, sind die wesentlichen Attribute bei Software nichtohne Weiteres offensichtlich.
Im internationalen Standard ISO/IEC-Standard 9126 (2001) werden typische Softwarequalitaten in Formallgemeiner Kategorien und Subkategorien wie folgt aufgefuhrt:
Funktionalitat: Vorhandensein von Funktionen mit festgelegten Eigenschaften, die die definierten Anforderungenerfullen:
• Richtigkeit: Liefern der richtigen oder vereinbarten Ergebnisse oder Wirkungen, z.B. die benotigte Genauigkeit vonberechneten Werten
• Angemessenheit: Eignung der Funktionen fur spezifizierte Aufgaben, z.B. aufgabenorientierte Zusammensetzung vonFunktionen aus Teilfunktionen
• Interoperabilitat: Fahigkeit, mit vorgegebenen Systemen zusammen zu wirken
• Ordnungsmaßigkeit: Erfullung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen undahnlichen Vorschriften
• Sicherheit: Fahigkeit, unberechtigten Zugriff, sowohl versehentlich als auch vorsatzlich, auf Programme und Daten zuverhindern
Zuverlassigkeit: Fahigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen uber einen festgelegtenZeitraum zu bewahren:
• Reife: Geringe Versagenshaufigkeit durch Fehlerzustande
• Fehlertoleranz: Fahigkeit, ein spezifiziertes Leistungsniveau bei Softwarefehlern oder Nicht-Einhaltung ihrer spezifiziertenSchnittstelle zu bewahren
• Wiederherstellbarkeit: Fahigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenenDaten wiederzugewinnen
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Wiederher-stellbarkeit
Fehler-toleranz
Verbrauchs-verhalten
Software-qualitat
Sicherheit
Interoperabilitat
Richtigkeit
Angemessenheit
Funktionalitat
OrdnungsmaßigkeitReife
Anderbarkeit
Stabilitat
Prufbarkeit
Analysierbarkeit
Modifizierbarkeit
Austauschbarkeit
Installierbarkeit
Anpassbarkeit
Konformitat Zeitverhalten
Verstandlichkeit
Erlernbarkeit
Bedienbarkeit
Ubertragbarkeit
Zuverlassigkeit
EffizienzBenutzbarkeit
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Benutzbarkeit: Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch einefestgelegte oder vorausgesetzte Benutzergruppe:
• Verstandlichkeit: Aufwand fur den Benutzer, das Konzept und die Anwendung zu verstehen
• Erlernbarkeit: Aufwand fur den Benutzer, die Anwendung zu erlernen (z.B. Bedienung, Ein-, Ausgabe)
• Bedienbarkeit: Aufwand fur den Benutzer, die Anwendung zu bedienen
Effizienz: Verhaltnis zwischen dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittelunter festgelegten Bedingungen:
• Zeitverhalten: Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausfuhrung
• Verbrauchsverhalten: Anzahl und Dauer der benotigten Betriebsmittel fur die Erfullung der Funktionen
Anderbarkeit: Aufwand, der zur Durchfuhrung vorgegebener Anderungen notwendig ist; Anderungen: Korrekturen,Verbesserungen oder Anpassungen an Anderungen der Umgebung, der Anforderungen und der funktionalenSpezifikationen:
• Analysierbarkeit: Aufwand, um Mangel oder Ursachen von Versagen zu diagnostizieren oder um anderungsbedurftigeTeile zu bestimmen
• Modifizierbarkeit: Aufwand zur Ausfuhrung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung anUmgebungsanderungen
• Stabilitat: Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Anderungen
• Prufbarkeit: Aufwand, der zur Prufung der geanderten Software notwendig ist
Ubertragbarkeit: Eignung der Software, von einer Umgebung in eine andere ubertragen zu werden (Umgebungkann organisatorische Umgebung, Hardware oder Softwareumgebung einschließen):
• Anpassbarkeit: Software an verschiedene festgelegte Umgebungen anpassen
• Installierbarkeit: Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist
• Konformitat: Grad, in dem die Software Normen oder Vereinbarungen zur Ubertragbarkeit erfullt
• Austauschbarkeit: Moglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zuverwenden, sowie der dafur notwendige Aufwand
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Wiederher-stellbarkeit
Fehler-toleranz
Verbrauchs-verhalten
Software-qualitat
Sicherheit
Interoperabilitat
Richtigkeit
Angemessenheit
Funktionalitat
OrdnungsmaßigkeitReife
Anderbarkeit
Stabilitat
Prufbarkeit
Analysierbarkeit
Modifizierbarkeit
Austauschbarkeit
Installierbarkeit
Anpassbarkeit
Konformitat Zeitverhalten
Verstandlichkeit
Erlernbarkeit
Bedienbarkeit
Ubertragbarkeit
Zuverlassigkeit
EffizienzBenutzbarkeit
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Produktqualitaten nach ISO/IEC-Standard 9126 (2001)
Diese Kategorien sind immer noch sehr allgemein und mussen fur die Anforderungen an eine bestimmte Softwarekonkretisiert und gewichtet werden. Dabei ist zu beachten, dass sich Qualitatsattribute gegenseitig (auch negativ)beeinflussen konnen. So stehen hohe Performanz und hohe Wartbarkeit meist in einem Spannungsfeld zueinander.
Die Konkretisierung und Gewichtung der Qualitatsattribute liefert das Qualitatsmodell. Fur das Qualitatsmodellmussen dann Prufkriterien festgelegt werden, anhand derer das Vorhandensein der gewunschten Eigenschaftenuberpruft werden kann. Im ISO/IEC-Standard 25000 (2005), der die Nachfolge von ISO/IEC-Standard 9126 (2001)angetreten hat, werden hierfur Metriken angegeben. Metriken sind ein numerisches Maß, das beschreibt, inwieweiteine bestimmte Qualitat vorliegt. Durch Einsatz der Metriken wird die Qualitat messbar. Uber die wesentlichenQualitatsattribute und sinnvolle Metriken zu ihrer Messung herrscht jedoch nicht immer Konsens.
Auch die Kategorisierung der Qualitatsattribute ist nicht immer gleich. Ludewig (2003) beispielsweise unterscheidet
auf oberster Ebene nach inneren und außeren Qualitaten. Außere Qualitaten sind solche, die fur den Benutzerdirekt spurbar sind. Innere Qualitaten richten sich primar an den Entwickler, sind jedoch zumindest indirekt auchfur den Benutzer spurbar durch den Aufwand und die Dauer fur Anderungen an der Software, um sie an neue undgeanderte Anforderungen anzupassen. Die folgende Grafik zeigt die Aufteilung nach Ludewig (2003):
PrüfbarkeitÄnderbarkeitPortabilität
NützlichkeitRobustheitBedienbarkeitSicherheit
Zuverlässigkeit
...
...
...
...
...
...
...
...
...
...
...
...............
...
...
...
...
...............
...
... ............
...
...
Produktqualität
innereErstellbarkeitWiederverwendbarkeit
Integrierbarkeit
Wartbarkeit
äußere
Anforderungsanalyse
Bedeutung einer Anforderungsspezifikation
Zweck Folge von Mangeln
Abstimmung mitKunden
Die Anforderungen bleiben ungeklart, Wunsche desKunden bleiben unberucksichtigt.
Entwurf Entwerfer fehlt Vorgabe, darum mehr Kommunikati-on / eigene Vorstellung als Vorgabe.
Benutzerhandbuch Basis fur das Handbuch fehlt, es wird darum phano-menologisch verfasst.
Testvorbereitung systematischer Test ist unmoglich
Abnahme Korrektheit ist subjektiv, Streit ist unvermeidbar.
Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar,darum schwer wiederzuverwenden.
spatere Reimple-mentierung
Kompatibilitat setzt voraus, dass man weiß, womitdie neue Software kompatibel sein soll.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 171 / 634
Bedeutung einer Anforderungsspezifikation
Zweck Folge von Mangeln
Abstimmung mitKunden
Die Anforderungen bleiben ungeklart, Wunsche desKunden bleiben unberucksichtigt.
Entwurf Entwerfer fehlt Vorgabe, darum mehr Kommunikati-on / eigene Vorstellung als Vorgabe.
Benutzerhandbuch Basis fur das Handbuch fehlt, es wird darum phano-menologisch verfasst.
Testvorbereitung systematischer Test ist unmoglich
Abnahme Korrektheit ist subjektiv, Streit ist unvermeidbar.
Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar,darum schwer wiederzuverwenden.
spatere Reimple-mentierung
Kompatibilitat setzt voraus, dass man weiß, womitdie neue Software kompatibel sein soll.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Bedeutung einer Anforderungsspezifikation
Die Anforderungsspezifikation ist von zentraler Bedeutung fur die Entwicklung. Sie wird von vielen Personen, dieam Entwicklungsprozess beteiligt sind, als Grundlage ihrer Arbeit verwendet. Eine minderwertigeAnforderungsspezifikation fuhrt zwangslaufig zu Mangeln aller davon abhangiger weiterer Arbeitsprodukte. Da alleweiteren Arbeitspakete von der Anforderungsspezifikation abhangig sind, haben solche Mangel also eine nachhaltigeAuswirkung auf die Qualitat. Deshalb sollte man sich die Muhe machen, die Anforderungen genau zu beschreibenund sie am auch aufzuschreiben.
Man kann die Auswirkungen einer mangelhaften Anforderungsspezifikation unterscheiden anhand der Zwecke, dieman mit der Anforderungsspezifikation verfolgt:
• Abstimmung: Die Anforderungsspezifikation dient der Abstimmung mit dem Kunden. Mangel in derAnforderungsspezifikation fuhren dazu, dass Anforderungen ungeklart und Wunsche des Kunden unberucksichtigtbleiben. Ohne eine ausgearbeitete Anforderungsspezifikation kann der Kunde nicht ohne Weiteres in fruhen Phasen desProjekts uberprufen, ob er richtig verstanden wurde und seine Wunsche wirklich umgesetzt werden.
• Entwurf: Der Softwarearchitekt entwirft auf Basis der Anforderungsspezifikation die Softwarearchitektur. Bei einerunzureichenden Anforderungsspezifikation fehlt dem Architekten dafur die notwendige Vorgabe. Dies fuhrt zu einemerhohten Bedarf an Kommunikation. Der Architekt muss beim Analytiker beziehungsweise beim Kunden nachfragen.Außerdem besteht die Gefahr, dass der Architekt seine eigene Vorstellung der Anforderungen entwickelt, die von der desKunden abweichen konnte.
• Benutzerhandbuch: Anhand der Anforderungsspezifikation wird das Benutzerhandbuch geschrieben. OhneAnforderungsspezifikation fehlt die Basis fur das Handbuch. Dies fuhrt dazu, dass es phanomenologisch erfasst wird; d.h.der Autor des Benutzerhandbuchs schreibt auf, was er beim lauffahigen System beobachtet. Das ist oft unzureichend,weil er nicht alle Moglichkeiten kennt und damit beobachten kann.
• Testvorbereitung: Ohne prazise und vollstandige Anforderungen ist ein systematischer Test unmoglich.
• Vertrag und Abnahme: In der Regel bildet die Anforderungsspezifikation die vertragliche Grundlage fur den Auftrag. AmEnde des Projekts wird bei der Abnahme uberpruft, ob die Anforderungen erfullt sind. Damit wird die Uberprufung derKorrektheit subjektiv und Streit ist unvermeidbar. Das fuhrt zur Unzufriedenheit des Kunden und haufig zuVertragsstreitigkeiten. Da aber die Anforderungen nicht vollstandig und prazise beschrieben sind, ist ein Streit um dasRecht muhsam.
Bedeutung einer Anforderungsspezifikation
Zweck Folge von Mangeln
Abstimmung mitKunden
Die Anforderungen bleiben ungeklart, Wunsche desKunden bleiben unberucksichtigt.
Entwurf Entwerfer fehlt Vorgabe, darum mehr Kommunikati-on / eigene Vorstellung als Vorgabe.
Benutzerhandbuch Basis fur das Handbuch fehlt, es wird darum phano-menologisch verfasst.
Testvorbereitung systematischer Test ist unmoglich
Abnahme Korrektheit ist subjektiv, Streit ist unvermeidbar.
Wiederverwendung nicht spezifizierte Systeme sind kaum durchschaubar,darum schwer wiederzuverwenden.
spatere Reimple-mentierung
Kompatibilitat setzt voraus, dass man weiß, womitdie neue Software kompatibel sein soll.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Bedeutung einer Anforderungsspezifikation
• Wiederverwendung: Ohne eine Beschreibung, was die Software leistet, kann man nicht ohne Weiteres beurteilen, obman die Software wiederverwenden kann. Nicht spezifizierte Systeme sind kaum durchschaubar, darum schwerwiederzuverwenden.
• Spatere Reimplementierung: Soll das System spater gegen ein neues System ersetzt werden, muss man wissen, was estut. Kompatibilitat setzt voraus, dass man weiß, womit die neue Software kompatibel sein soll.
Anforderungsanalyse
Angestrebte Eigenschaften der Spezifikation
inhaltlich
(1) zutreffend (nicht”korrekt“!)
(2) vollstandig (relativ zu den Wunschen des Kunden)(3) widerspruchsfrei (oder konsistent, damit auch realisierbar)(4) neutral d.h. abstrakt (und damit offen fur beliebigen Entwurf)
in der Darstellung
(5) leicht verstandlich (fur alle Zielgruppen!)(6) prazise (schließt Umgangssprache aus)
in der Form
(7) leicht erstellbar (was die Notationen und Modelle betrifft)(8) leicht verwaltbar (also auch zweckmaßig strukturiert)(9) objektivierbar (auch – nicht sinnvoll –
”testbar“ genannt)
Diese Merkmale konkurrieren, d.h. die Erfullung des einen erschwert oderverhindert die Erfullung des anderen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 172 / 634
Angestrebte Eigenschaften der Spezifikation
inhaltlich
(1) zutreffend (nicht”korrekt“!)
(2) vollstandig (relativ zu den Wunschen des Kunden)(3) widerspruchsfrei (oder konsistent, damit auch realisierbar)(4) neutral d.h. abstrakt (und damit offen fur beliebigen Entwurf)
in der Darstellung
(5) leicht verstandlich (fur alle Zielgruppen!)(6) prazise (schließt Umgangssprache aus)
in der Form
(7) leicht erstellbar (was die Notationen und Modelle betrifft)(8) leicht verwaltbar (also auch zweckmaßig strukturiert)(9) objektivierbar (auch – nicht sinnvoll –
”testbar“ genannt)
Diese Merkmale konkurrieren, d.h. die Erfullung des einen erschwert oderverhindert die Erfullung des anderen.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Angestrebte Eigenschaften der Spezifikation
Weil eine Anforderungsspezifikation von so tragender Bedeutung ist, streben wir eine hochqualitative an. WelcheEigenschaften mussen wir aber hierzu anstreben? Die anzustrebenden Eigenschaften lassen sich wie folgtkategorisieren:
Den Inhalt betreffend:
(1) zutreffend: die Anforderungen des Kunden werden richtig wieder gegeben; an manchen Stellen wird fur zutreffend auchder Begriff korrekt synonym verwendet; wir werden aber im Folgenden den Begriff korrekt fur das Verhaltnis derImplementierung zur Anforderungsspezifikation reservieren; eine Implementierung ist dann korrekt, wenn sie diespezifizierten Anforderungen richtig erfullt. Daraus kann man jedoch noch nicht unmittelbar schließen, dass dieImplementierung auch das implementiert, was der Kunde tatsachlich will. Hierzu ist es noch notwendig, dass dieAnforderungsspezifikation auch die Wunsche des Kunden zutreffend wiedergibt.
(2) vollstandig: alle Wunsche des Kunden werden berucksichtigt.
(3) widerspruchsfrei (oder konsistent, damit auch realisierbar): die Anforderungen widersprechen sich nicht; wurden sie sichwidersprechen, konnte man nichts implementieren, was alle Anforderungen erfullt.
(4) neutral, d.h. abstrakt: die Anforderungen sind aus Sicht des Kunden formuliert und nehmen keine unnotigen technischenDetails vorweg. Implementierungsaspekte gehoren nicht in die Anforderungsspezifikation, weil sie den Kunden in derRegel nicht interessieren, sondern eher verwirren. Außerdem bleibt damit dem Architekten beim Entwurf eingroßtmoglicher Gestaltungsspielraum.
Angestrebte Eigenschaften der Spezifikation
inhaltlich
(1) zutreffend (nicht”korrekt“!)
(2) vollstandig (relativ zu den Wunschen des Kunden)(3) widerspruchsfrei (oder konsistent, damit auch realisierbar)(4) neutral d.h. abstrakt (und damit offen fur beliebigen Entwurf)
in der Darstellung
(5) leicht verstandlich (fur alle Zielgruppen!)(6) prazise (schließt Umgangssprache aus)
in der Form
(7) leicht erstellbar (was die Notationen und Modelle betrifft)(8) leicht verwaltbar (also auch zweckmaßig strukturiert)(9) objektivierbar (auch – nicht sinnvoll –
”testbar“ genannt)
Diese Merkmale konkurrieren, d.h. die Erfullung des einen erschwert oderverhindert die Erfullung des anderen.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Angestrebte Eigenschaften der Spezifikation
Die Darstellung betreffend:
(5) leicht verstandlich: Die Anforderungsspezifikation ist leicht verstandlich fur alle Zielgruppen. Dazu gehoren nebenEntwicklern mit technischem Verstandnis auch Kunden und Benutzer, die meist mit formalen Methoden und Notationnichts anzufangen wissen. Selbst die Verwendung der Unified Modeling Language ist fur einen Kunden und Benutzernicht ohne Weiteres zumutbar, auch wenn manche sie als Notation fur die Kommunikation mit Kunden und Benutzernanpreisen. Die Vorteile einer (semi-)formalen Notation ist ihre Prazision und Pragnanz. Aus diesem Grund wurde mansich ihren Einsatz wunschen. Wird eine solche Notation verwendet, muss der Kunde aber darin geschult werden – oderwurden wir einen Vertrag in Hieroglyphen unterzeichnen?
(6) prazise: die Anforderungen mussen unmissverstandlich formuliert sein, sonst besteht die Gefahr, dass etwas Falschesimplementiert wird. Dies schließt Umgangssprache, die sich durch vage Begriffe und Mehrdeutigkeiten auszeichnet, aus.Ebenso sollten sprachliche Weichmacher wie konnte, musste, circa, ungefahr etc. vermieden werden.
Angestrebte Eigenschaften der Spezifikation
inhaltlich
(1) zutreffend (nicht”korrekt“!)
(2) vollstandig (relativ zu den Wunschen des Kunden)(3) widerspruchsfrei (oder konsistent, damit auch realisierbar)(4) neutral d.h. abstrakt (und damit offen fur beliebigen Entwurf)
in der Darstellung
(5) leicht verstandlich (fur alle Zielgruppen!)(6) prazise (schließt Umgangssprache aus)
in der Form
(7) leicht erstellbar (was die Notationen und Modelle betrifft)(8) leicht verwaltbar (also auch zweckmaßig strukturiert)(9) objektivierbar (auch – nicht sinnvoll –
”testbar“ genannt)
Diese Merkmale konkurrieren, d.h. die Erfullung des einen erschwert oderverhindert die Erfullung des anderen.
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Angestrebte Eigenschaften der Spezifikation
Die Form betreffend:
(7) leicht erstellbar: die Anforderungsspezifikation ist in vielen Fallen ein sehr umfangreiches Dokument. Darum ist eswichtig, das es leicht erstellt werden kann. Somit ist die Auswahl geeigneter Notationen und Modelle bedeutsam. Haufigwird sie nicht nur von einem Autoren erstellt, so dass die Zusammenarbeit mehrerer Autoren unterstutzt werden muss.Die Anforderungsspezifikation muss also modular aufgebaut sein.
(8) leicht verwaltbar: die Anforderungsspezifikation muss durch zweckmaßige Strukturierung, eindeutige Referenzierbarkeitund explizite Querbezuge leicht uberarbeitet und versioniert werden konnen. Idealerweise ist der Code uber den Entwurfhin zu den Anforderungen verknupft, um eine hohe Nachvollziehbarkeit zwischen diesen Dokumenten zu gewahrleisten,da die Dokumente nachgefuhrt werden mussen, wenn sich Dinge andern. Hierfur wurden eine Reihe von Werkzeugen,wie z.B. Doors, entwickelt
(9) objektivierbar: fur jede Anforderung muss es moglich sein, eine Prufprozedur anzugeben, mit deren Hilfe man objektiventscheiden kann, ob das resultierende System die Anforderung erfullt; synonym zu objektivierbar wird haufig auch derBegriff testbar verwendet; dieser Begriff suggeriert jedoch, dass man das System fur die Prufung ausfuhren konnen muss(vgl. das Kursmodul Test); die meisten Prufungen lassen sich aber ohne Ausfuhrung des Systems durchfuhren.Die Anforderung
”Die Programm soll eine hohe Performanz aufweisen“ ist ein Negativbeispiel fur eine objektivierbare
Anforderung. Hier ist unklar, was”hohe Performanz“ genau bedeutet. Statt dessen sollte die Anforderung vielmehr in
der folgenden Weise formuliert werden:”Die Ausgabe soll in mindestens 60 % aller Falle nach spatestens 20 Sekunden
erfolgen; nach hochstens 30 Sekunden soll die Ausgabe in 100 % aller Falle erfolgen. Die Berechnung muss mit maximal5 MB Hauptspeicher und 100 MB Plattenplatz auskommen“.
Leider ist es nicht immer moglich, alle diese Merkmale bei einer Anforderungsspezifikation zu erfullen, weil dieMerkmale konkurrieren konnen, das heißt die Erfullung des einen erschwert oder verhindert die Erfullung desanderen. Prazise Anforderungen sind in der Regel nur mit Hilfe formaler Spezifikationsprachen zu erreichen, die sindaber fur einen Kunden meist nicht verstandlich.
Anforderungsanalyse
Regeln fur Analyse und Spezifikation
Ein Begriffslexikon anlegen und entwickeln
Von der Aufgabe ausgehen, nicht von ihrer Losung
Daten suchen, nicht Programmablaufe beschreiben
Abstraktionsebene nicht in einer Darstellung wechseln
Die Spezifikation nach Aspekten organisieren
Ein Mengengerust bilden
Den Kunden (Benutzer) einbeziehen
Geeignete Sprachen und Werkzeuge verwenden
Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen
Die Spezifikation intensiv verwenden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 173 / 634
Regeln fur Analyse und Spezifikation
Ein Begriffslexikon anlegen und entwickeln
Von der Aufgabe ausgehen, nicht von ihrer Losung
Daten suchen, nicht Programmablaufe beschreiben
Abstraktionsebene nicht in einer Darstellung wechseln
Die Spezifikation nach Aspekten organisieren
Ein Mengengerust bilden
Den Kunden (Benutzer) einbeziehen
Geeignete Sprachen und Werkzeuge verwenden
Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen
Die Spezifikation intensiv verwenden20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Regeln fur Analyse und Spezifikation
Um eine gute Anforderungsspezifikation zu erreichen, ist es ratsam, einige Regeln zu befolgen.
• Ein Begriffslexikon (auch: Glossar) anlegen und entwickeln. Das Begriffslexikon beschreibt alle Begriffe, die der Kundeund wir benutzen, die nicht unmittelbar offensichtlich sind. Die schriftliche Niederlegung der Bedeutung aller Begriffezwingt uns und den Kunden zur notwendigen Prazision in unserem Dialog und hilft damit, Missverstandnisse zuvermeiden. Hier sollten auch alle Synonyme aufgezahlt werden. Im eigentlichen Inhalt der schriftlichenAnforderungsspezifikation sollten wir aber Synonyme vermeiden und immer nur dasselbe Wort benutzen. DieAnforderungsspezifikation ist kein literatisches Werk, das durch hohe Sprachvariation gefallen will, sondern soll einprazises, leicht verstandliches technisches Dokument sein. Unterschiedliche Worte fur denselben Sachverhalten verwirrennur.
• Von der Aufgabe ausgehen, nicht von ihrer Losung. Die Anforderungsspezifkation beschreibt das zu implementierendeSystem aus Sicht des Kunden. Wie das System intern implementiert wird, interessiert den Kunden nicht, sondernverwirrt ihn eher, weil er sich mit Implementierungsfragen in der Regel nicht auskennt. Implementierungsfragen gehorenin ein Entwurfsdokument, wie z.B. die Architekturbeschreibung. Wir sollten den Gestaltungsraum desSoftwarearchitekten durch die Anforderungsspezifikation nicht unnotig einschranken.
• Daten suchen, nicht Programmablaufe beschreiben. Primar sind wir an den Daten, d.h. den Objekten, derAnwendungsdomane interessiert. Sie andern sich meist weniger als die Ablaufe, in denen sie verarbeitet werden.Naturlich gehoren zur Beschreibung in der Anforderungsspezifikation die Kommunikation zwischen den Objekten undwelche Operationen sie prinzipiell beherrschen. Die Software muss ja Arbeitsflusse abbilden. Wie aber diese Operationenintern implementiert werden (der Programmablauf) ist ein Detail der Implementierung und sollte erst spater im Entwurfoder in der Implementierungsphase spezifiziert werden.
• Abstraktionsebene nicht in einer Darstellung wechseln. Um den Leser zu fuhren statt ihn zu verwirren, sollten wir unsDetails fur vertiefende Abschnitte aufheben. Die Anforderungsspezifikation sollte so gestaltet sein, dass der Leser ersteinen allgemeinen Uberblick uber alle Anforderungen an das System erhalt und erst dann einen detaillierten Einblick indie einzelnen Anforderungen. Ein Wechsel zwischen diesen Ebenen verwirrt unnotig.
Regeln fur Analyse und Spezifikation
Ein Begriffslexikon anlegen und entwickeln
Von der Aufgabe ausgehen, nicht von ihrer Losung
Daten suchen, nicht Programmablaufe beschreiben
Abstraktionsebene nicht in einer Darstellung wechseln
Die Spezifikation nach Aspekten organisieren
Ein Mengengerust bilden
Den Kunden (Benutzer) einbeziehen
Geeignete Sprachen und Werkzeuge verwenden
Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen
Die Spezifikation intensiv verwenden20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Regeln fur Analyse und Spezifikation
• Die Spezifikation nach Aspekten organisieren. Die Spezifikation ist nicht selten ein Dokument mit mehreren hundertSeiten. Es kann nicht ohne Unterbrechung gelesen werden. Außerdem wird es von Lesern mit sehr unterschiedlichenInteressen gelesen. Dazu gehoren auf Kundenseite neben dem Auftraggeber (auch hier gibt es meist verschiedene Rollen:der Auftraggeber, der fur den Inhalt verantwortlich ist und der Auftraggeber, der fur die Finanzierung und Termintreueverantwortlich ist) die verschiedenen Benutzerklassen. Auf der Seite der Hersteller wird das Dokument von denArchitekten, den Programmierern, den Handbuchautoren und den Testern gelesen. Alle interessieren sich furunterschiedliche Belange. Um die vielen Arten von Lesern zu unterstutzen, muss die Spezifikation uniform nachrelevanten Aspekten organisiert werden.
• Ein Mengengerust bilden. Damit der Architekt eine Vorstellung uber die Anforderungen an die Belastbarkeit des Systemserhalt, um das System dafur entsprechend auszulegen, muss er wissen, mit wie vielen Daten er es zu tun haben wird. Esmacht einen gravierenden Unterschied, ob ein System etwa 10 oder 10.000 Benutzer unterstutzen muss. Damit derArchitekt das System auch fur zukunftige Anforderungen skalierbar entwerfen kann, sollten neben dem heutigenMengengerust auch realistische Prognosen gemacht werden, wie sich das Mengengerust in Zukunft entwickeln wird.
• Den Kunden (Benutzer) einbeziehen. Wir entwickeln fur den Kunden, der uns dafur bezahlt, und fur die Benutzer, dieunser System spater benutzen sollen. Ihre Belange sind Ausgangspunkt unseres Projekts. Sie konnen an verschiedenenStellen im Entwicklungsprozess eingebunden werden, nicht nur wahrend der Anforderungsanalyse und am Ende beimAkzeptanztest. Beim partizipativen Vorgehen beispielsweise werden wir in kurzen Zeitabstanden Prototypen undverschiedene Inkremente des Systems vorfuhren, um ihr Feedback einzuholen. Ganz besonders benotigen wir sie aberwahrend der initialen Anforderungsanalyse. Um sicher zu stellen, dass wir die Anforderungsspezifikation die Wunsche desKunden und der Benutzer treffend widerspiegelt, sollte die Anforderungsspezifikation in einem Review mit Kunden undBenutzern abgenommen werden.
Regeln fur Analyse und Spezifikation
Ein Begriffslexikon anlegen und entwickeln
Von der Aufgabe ausgehen, nicht von ihrer Losung
Daten suchen, nicht Programmablaufe beschreiben
Abstraktionsebene nicht in einer Darstellung wechseln
Die Spezifikation nach Aspekten organisieren
Ein Mengengerust bilden
Den Kunden (Benutzer) einbeziehen
Geeignete Sprachen und Werkzeuge verwenden
Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen
Die Spezifikation intensiv verwenden20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Regeln fur Analyse und Spezifikation
• Geeignete Sprachen und Werkzeuge verwenden. Die Anforderungsspezifikation sollte moglichst prazise, aber eben auchverstandlich sein. Hierzu kann man Diagrammen benutzen. Die UML beispielsweise enthalt eine Reihe vonDiagrammtypen, mit deren Hilfe man bestimmte Aspekte verstandlich und genau beschreiben kann. Fur dasDatenmodell eignen sich zum Beispiel Klassendiagramme. Es versteht sich von selbst, dass wir dem Kunden unsereNotation erklaren mussen. Zur Erstellung des Dokuments bedient man sich am besten spezieller Werkzeuge. Nebenherkommlicher Editierfunktionen konnen uns hierbei Werkzeuge helfen, Anforderungen eindeutig zu nummerieren sowieVerweise einzufugen, zu verfolgen und zu prufen. Diese Werkzeuge konnen uns auch einen festen Rahmen vorgeben.Einfache Prufungen auf Vollstandigkeit werden damit moglich.
• Die Spezifikation so fruh wie moglich prufen und dem Konfigurationsmanagement unterstellen. DieAnforderungsspezifikation sollte wir selbst mit internen Reviews uberprufen. Nach Fertigstellung derAnforderungsspezifikation sollte mindestens eine Prufung mit dem Kunden und den Benutzern stattfinden. Weitere nochfruhere Prufungen kann man mit Hilfe von Prototypen erreichen.Die Anforderungsspezifikation wird sich andern, weil in Prufungen und auch spater Fehler und Lucken gefunden werden.Außerdem konnen sich bei einer langeren Projektlaufzeit Anforderungen auch noch wahrend der Entwicklung andernaufgrund geanderter Rahmenbedingungen. Zudem arbeiten meist mehrere Personen an der Anforderungsspezifikation.Aus diesem Grund muss die Anforderungsspezifikation von Anbeginn unter das Konfigurationsmanagement gestelltwerden.
• Die Spezifikation intensiv verwenden. Die Anforderungsspezifikation ist der Ausgang fur alle weiteren Entwicklungen. Siewird nicht nur benutzt beim Vertragsabschluss von Auftragnehmer und -geber sondern fur eine Reihe weiterer Personen,die fur die Entwicklung verantwortlich sind. Dazu gehoren Architekten, Programmierer, Tester und Handbuchautoren. Essollte eine Selbstverstandlichkeit sein, dass diese Menschen die Spezifikation intensiv nutzen. Leider hat die Praxisgezeigt, dass z.B. viele Programmierer Fehler deshalb machen, weil sie die Anforderungsspezifikation niemals gelesenhaben.
Regeln fur Analyse und Spezifikation
Ein Begriffslexikon anlegen und entwickeln
Von der Aufgabe ausgehen, nicht von ihrer Losung
Daten suchen, nicht Programmablaufe beschreiben
Abstraktionsebene nicht in einer Darstellung wechseln
Die Spezifikation nach Aspekten organisieren
Ein Mengengerust bilden
Den Kunden (Benutzer) einbeziehen
Geeignete Sprachen und Werkzeuge verwenden
Die Spezifikation so fruh wie moglich prufen und demKonfigurationsmanagement unterstellen
Die Spezifikation intensiv verwenden20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Regeln fur Analyse und Spezifikation
Nachdem wir wissen, welche Qualitaten der Anforderungsspezifikation wir anstreben und welche Regeln wireinhalten sollen, werden wir uns nun mit ihrem Inhalt und ihrer Struktur auseinander setzen. Glucklicherweisehaben sich dazu bereits viele Spezialisten Gedanken gemacht, die sogar in einen Standard gemundet sind. Da wirdas Rad nicht neu erfinden wollen und die Orientierung an Standards eine gute Ingenieurstugend ist, nehmen wiruns diesen Standard zum Vorbild. Wir konnen diesen Standard als einen Rahmen fur unsere Spezifikationverwenden und laufen so weniger Gefahr, etwas zu vergessen.
Es handelt sich dabei um den IEEE Recommended Practice for Software Requirements Specifications, IEEEStandard 830.1998. Er setzt vieles von dem um, was wir bislang kennen gelernt haben. Wir werden hierzuKonkretisierungen und daruber hinaus fuhrende Erganzungen kennen lernen (Ergebnisse der Soll-Analyse,Datenmodell und Prognosen fur zukunftige Anforderungen), die auch beschrieben sein sollten.
Anforderungsanalyse
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
1. Einfuhrung
1.1 Zweck1.2 Rahmen1.3 Definitionen, Akronyme und Abkurzungen1.4 Referenzen1.5 Ubersicht uber das Dokument
2. Allgemeine Beschreibung
2.1 Produktperspektive2.2 Produktfunktionen2.3 Charakteristika der Benutzer2.4 Einschrankungen2.5 Annahmen und Abhangigkeiten
3. Detaillierte Beschreibung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 174 / 634
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
1. Einfuhrung
1.1 Zweck1.2 Rahmen1.3 Definitionen, Akronyme und Abkurzungen1.4 Referenzen1.5 Ubersicht uber das Dokument
2. Allgemeine Beschreibung
2.1 Produktperspektive2.2 Produktfunktionen2.3 Charakteristika der Benutzer2.4 Einschrankungen2.5 Annahmen und Abhangigkeiten
3. Detaillierte Beschreibung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
Der Standard gibt eine dreiteilige Struktur vor: eine Einfuhrung, eine allgemeine Beschreibung und eine detaillierteBeschreibung. Er folgt hierin den oben erwahnten Regeln, nach Aspekten und Detaillierungsgrad zu ordnen. DieStruktur bis in die zweite Gliederungsebene ist wie folgt:
1. Einfuhrung
1.1 Zweck1.2 Rahmen1.3 Definitionen, Akronyme und Abkurzungen1.4 Referenzen1.5 Ubersicht uber das Dokument
2. Allgemeine Beschreibung
2.1 Produktperspektive2.2 Produktfunktionen2.3 Charakteristika der Benutzer2.4 Einschrankungen2.5 Annahmen und Abhangigkeiten
3. Detaillierte Beschreibung
Wir werden diese Abschnitte nun im Einzelnen im Detail kennen lernen. Ein Beispiel fur eine ausfuhrlicheAnforderungsspezifikation finden Sie unter . . . <<hier erganzen: gute Spec. vom ersten SWP zu PDAhinzufugen>>
Anforderungsanalyse
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
1. Einfuhrung
1.1 Zweck
Zweck der Spezifikationadressierte Leser
1.2 Rahmen
herzustellende Software mit Namewas die Software tut und nicht tutAnwendung der Software mit Nutzen und Zielen
1.3 Definitionen, Akronyme und Abkurzungen
1.4 Referenzen
1.5 Ubersicht uber das Dokument
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 175 / 634
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
1. Einfuhrung
1.1 Zweck
Zweck der Spezifikationadressierte Leser
1.2 Rahmen
herzustellende Software mit Namewas die Software tut und nicht tutAnwendung der Software mit Nutzen und Zielen
1.3 Definitionen, Akronyme und Abkurzungen
1.4 Referenzen
1.5 Ubersicht uber das Dokument20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
Das Ziel der Einfuhrung ist es, den Kontext und Rahmen der Anforderungsspezifikation abzustecken. Sie hatfolgende Struktur:
1.1 ZweckDieser Abschnitt beschreibt den Zweck der Spezifikation und an welche Leser sie sich wendet. Meist geschieht diesdurch eine kurze Beschreibung des Projektkontextes und der Ziele des Projekts. Dann folgt der Hinweis, dass in diesemDokument die Anforderungen dieses System spezifiziert werden sollen und oft die Aussage, dass dieses Dokument dievertragliche Grundlage bildet. Fur die adressierten Leser werden mindestens die konkreten Namen der Kunden undVertreter moglicher Benutzer genannt.
1.2 RahmenHier geben wir der zu erstellenden Software einen Namen und beschreiben ganz kurz, was die herzustellende Softwareleisten soll und auch, was wir explizit nicht von ihr erwarten, um gleich zu Anfang falschen Vorstellungen Einhalt zugebieten. Es folgt die Beschreibung der Anwendung der Software mit ihrem Nutzen und ihren Zielen. Dieser Abschnittsoll nur einen ersten Uberblick vermitteln, was die Software genau machen soll, folgt in den zwei nachfolgenden Kapiteln.Bsp.: Der PDA-basierte Einkaufsassistent, den wir als laufendes Beispiel verwenden, soll den Namen PDAss tragen. �
1.3 Definitionen, Akronyme und AbkurzungenHier ist er der Ort, an dem Begriffe definiert und Akronyme und Abkurzungen eingefuhrt werden konnen, die imweiteren Dokument benutzt werden. Damit wird der Standard unserer oben geaußerten Forderung gerecht, einBegriffslexikon (Glossar) zum Ausschluss von Missverstandnissen zu verwenden.Bsp.: Wir wurden hier beispielsweise das Akronym PDA fur
”Personal Digital Assistant“ erlautern. �
1.4 ReferenzenHier konnen weitere Dokumente aufgefuhrt werden, die fur das Verstandnis der Anforderungsspezifikation hilfreich sindund im folgenden Text referenziert werden. Dazu sollte auch z.B. der IEEE-Standard fur diese Anforderungsspezifikationgehoren.Bsp.: Hier konnten wir die Fahrradherstellerkataloge und weitere Dokumente, die wir in der Ist-Analyse gefunden haben,nennen. �
1.5 Ubersicht uber das DokumentSchließlich erfolgt hier in diesem Abschnitt eine kurze Ubersicht fur den Leser uber die weiteren Kapitel und Abschnittedieser Anforderungsspezfikation.
Anforderungsanalyse
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2. Allgemeine Beschreibung
2.1 ProduktperspektiveEinbettung in ein Gesamtsystem
2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,
Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle
2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und
nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)
2.1.8 Moglichkeiten der lokalen Anpassung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 176 / 634
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2. Allgemeine Beschreibung
2.1 ProduktperspektiveEinbettung in ein Gesamtsystem
2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,
Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle
2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und
nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)
2.1.8 Moglichkeiten der lokalen Anpassung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
Das Kapitel 2 beschreibt Allgemeines sowie die Anforderungen im Einzelnen, ohne jedoch gleich alle moglichenDetails zu nennen (letztere folgen im dritten Kapitel).
2.1 Produktperspektive
Dieser Abschnitt bettet das zu implementierende System in ein Gesamtsystem ein. Dazu werden alle seineSchnittstellen zu anderen Systemen und zum Benutzer beschrieben sowie weitere globale Einschrankungen.
Wir werden bei der Beschreibung der Schnittstellen feststellen, dass es nicht immer einfach ist, eine Schnittstelleeiner der unten aufgefuhrten Kategorien eindeutig zuzuordnen. Im Zweifel entscheiden wir uns fur eine und fugen inden anderen Abschnitten einen Querbezug zu dieser Beschreibung ein. Primar ist wichtig, dass die Schnittstellebeschrieben ist. Durch die Querbezuge stellen wir sicher, dass wir diese Beschreibung finden werden, egal inwelchem Abschnitt wir intuitiv suchen.
2.1.1 SystemschnittstellenUber Systemschnittstellen ist das zu implementierende System mit anderen Systemen verbunden, mit denen eszusammen arbeiten soll. Dazu gehoren z.B. Import- und Exportschnittstellen fur den Datenaustausch,Scripting-Schnittstellen, uber die sich das System programmieren lasst, sowie Application Interfaces (API), uber dasman das System programmatisch steuern kann.Bsp.: Hier konnten wir fur PDAss fordern, dass man die Herstellerkataloge in einem zu definierenden elektronischenXML-basierten Format einlesen konnen soll. �
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2. Allgemeine Beschreibung
2.1 ProduktperspektiveEinbettung in ein Gesamtsystem
2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,
Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle
2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und
nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)
2.1.8 Moglichkeiten der lokalen Anpassung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
2.1.2 BenutzungsschnittstelleEine besondere Schnittstelle ist die, die dem Benutzer angeboten wird. Die detaillierte Beschreibung dieser Schnittstelleerfolgt in Abschnitt 3.1.1. Hier werden lediglich die logischen Charakteristika der Schnittstelle erlautert, z.B. dasMonitorformat, das Seiten- oder Fensterlayout, den Inhalt von Berichten oder Menus oder die Verfugbarkeit vonFunktionstasten. Außerdem werden alle relevanten Regeln fur das Design der Schnittstelle genannt, wie z.B. dieallgemeinen (in aller Regel ohnehin verbindlichen) Richtlinien der Norm EN ISO 9241-10:1995 (1995) fur dieGebrauchstauglichkeit von Software. Die Angaben mussen aber hinreichend konkretisiert werden. Diese Regeln konnenauch eine einfache Liste von “Dos and Don’ts” sein, wie sich die Schnittstelle dem Benutzer darstellen soll.Beispielsweise ob kurze oder lange Fehlermeldungen vorzuziehen sind. In jedem Fall gilt auch hier, dass dieAnforderungen objektivierbar sein mussen. Statt
”benutzerfreundlich“ sollte es also besser
”Persona X kann die Funktion
Sortiment einsehen in zwei Minuten ausfuhren (nach einer Schulung von zehn Minuten)“ heißen.
Charakteristika der Benutzer werden in Abschnitt 2.3 angegeben.
Bsp.: Hier wurden wir z.B. die Auflosung des PDA-Monitors fur PDAss, die Farbtiefe, die Eingabemoglichkeiten uberStift und nur wenige Tasten und die minimalen Schriftgroßen etc. angeben. �
2.1.3 HardwareschnittstellenHardwareschnittstellen sind Schnittstellen zu Hardware, die das System voraussetzt beziehungsweise bedient. DieserAbschnitt ist insbesondere fur eingebettete Systeme von großer Bedeutung. Fur alle Arten von Systemen wurde manhier aber die zu unterstutzenden Prozessortypen beschreiben, auf denen die Software spater laufen soll. Hardware, dieeher der Benutzungsschnittstelle zuzuordnen ist, wird in Abschnitt 2.1.2 beschrieben.
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2. Allgemeine Beschreibung
2.1 ProduktperspektiveEinbettung in ein Gesamtsystem
2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,
Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle
2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und
nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)
2.1.8 Moglichkeiten der lokalen Anpassung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
2.1.4 SoftwareschnittstellenSoftwareschnittstellen sind Schnittstellen zu Software, die Bestandteil des System werden soll. Dazu gehorenBetriebssysteme, hohere Dienste wie z.B. Datenbanken sowie wiederverwendbare Bibliotheken, die eingebunden werdensollen.
Wir erinnern uns, dass Implementierungsdetails eigentlich nicht in die Anforderungsspezifikation gehoren. Insofern durfenwir nur solche Softwareschnittstellen hier aufzahlen, die tatsachlich von Interesse fur den Kunden sind, z.B. dann wenner diese Software bereits einsetzt und in diesem Kontext wieder verwenden mochte bzw. wenn sich aus ihrer Verwendungweitere lizenzrechtliche Aspekte fur den Kunden ergeben wurden.
Bsp.: Der Ladenverkaufer hat eine MySQL-Datenbank der Version 4.1 bereits im Einsatz und besteht darauf, dassunsere Software alle persistenten Daten darin speichern soll. �
2.1.5 KommunikationsschnittstellenSofern das System mit anderen Systemen uber ein Netzwerk kommuniziert, beschreiben wir hierfur dieKommunikationsschnittstelle sowie Netzwerkprotokolle etc. Auch hier gilt wieder, dass nur solche Schnittstelleninteressieren, die zu anderen Systemen fuhren beziehungsweise fur die der Kunde sorgen muss, damit unser Systemarbeiten kann. Ist eine solche Schnittstelle vollstandig intern und wird von uns mitgeliefert, handelt es sich um einImplementierungsdetail, das wir nicht in der Anforderungsspezifikation nennen.
Bsp.: Wir wollen den PDA mit dem Ladenrechner uber WLAN kommunizieren lassen. Wir setzen voraus, dass der Kundefur das WLAN in seinem Laden sorgt. Dann ware WLAN mit einem Netzwerkprotokoll wie TCP/IP in derAnforderungsspezifikation zu erwahnen. Wir durfen dann in unserer Implementierung voraussetzen, dass dieAusfuhrungsumgebung diese Komponenten bereit halt. �
2.1.6 SpeicherbeschrankungenHier nennen wir die mindestens verfugbare Große des Hauptspeichers und der Festplatten, die das korrekte Funktionierenunserer Software voraussetzen darf. Anforderungen an die Laufzeit werden im Kontext der Operationen festgelegt.
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2. Allgemeine Beschreibung
2.1 ProduktperspektiveEinbettung in ein Gesamtsystem
2.1.1 Systemschnittstellen2.1.2 Benutzungsschnittstelle (logische Charakteristika. z.B. Monitorformat,
Seiten- oder Fensterlayout, Inhalt von Berichten oder Menus,Verfugbarkeit von Funktionstasten) sowie Regeln fur die Schnittstelle
2.1.3 Hardwareschnittstellen2.1.4 Softwareschnittstellen2.1.5 Kommunikationsschnittstellen (Netzwerkprotokolle etc.)2.1.6 Speicherbeschrankungen2.1.7 Betriebsoperationen (Operationsmodi, Dauer interaktiver und
nichtinteraktiver Operationen, unterstutzendeDatenverarbeitungsfunktionen, Sicherungs- undWiederherstellungsoperationen)
2.1.8 Moglichkeiten der lokalen Anpassung
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
2.1.7 BetriebsoperationenNeben den eigentlichen Produktfunktionen bietet ein System meist noch eine Menge allgemeiner Operationen, die furden Betrieb der Software notwendig oder hilfreich sind. Dazu gehoren beispielsweise unterstutzendeDatenverarbeitungsfunktionen (wie z.B. Konsistenzprufungen oder allgemeine Statistiken uber die Datenvolumen) sowieSicherungs- und Wiederherstellungsoperationen. Außerdem unterstutzen viele Systeme verschiedene Operationsmodi, indenen unterschiedliche Produktfunktionen und Betriebsoperationen verfugbar beziehungsweise nicht verfugbar sind.Beispielsweise bietet eine Bank-Software einen Wartungsmodus, wahrend dessen Kunden keine Transaktionenveranlassen konnen, weil Jahresabschlusse berechnet werden.In diesem Abschnitt werden diese allgemeinen Betriebsoperationen, die relevanten Operationsmodi und die Dauer undHaufigkeit interaktiver und nichtinteraktiver Operationen aufgefuhrt.
2.1.8 Moglichkeiten der lokalen AnpassungSysteme bieten haufig die Moglichkeit, dass Benutzer lokale Anpassungen vornehmen konnen. Diese werden hierbeschrieben.
Bsp.: Der Ladenbesitzer soll beispielsweise einstellen konnen, wie viele Benutzer maximal gleichzeitig auf denLadenrechner zugreifen durfen. �
Die Norm ISO 9241-11:1998 (1998) weist Individualisierbarkeit als anzustrebendes Qualitatsmerkmal aus. Beispielsweisesollen Schriftgroßen einstellbar sein. Moglichkeiten der lokalen Anpassung der Benutzungsschnittstelle werden jedoch inAbschnitt 2.3 beschrieben.
Anforderungsanalyse
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2.2 Produktfunktionen
Zusammenfassung der Funktionen
2.3 Charakteristika der Benutzer
Bildungsstand, Erfahrung, technische Kenntnisse
2.4 EinschrankungenBeispiele:
Gesetzliche RahmenbedingungenHardwarebeschrankungenparallelisierte Ausfuhrungerforderliche Zuverlassigkeitsicherheitskritische AspekteDatenschutzaspekte
2.5 Annahmen und Abhangigkeiten
z.B. Betriebssystem ist auf Hardware verfugbar
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 177 / 634
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
2.2 Produktfunktionen
Zusammenfassung der Funktionen
2.3 Charakteristika der Benutzer
Bildungsstand, Erfahrung, technische Kenntnisse
2.4 EinschrankungenBeispiele:
Gesetzliche RahmenbedingungenHardwarebeschrankungenparallelisierte Ausfuhrungerforderliche Zuverlassigkeitsicherheitskritische AspekteDatenschutzaspekte
2.5 Annahmen und Abhangigkeiten
z.B. Betriebssystem ist auf Hardware verfugbar
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
2.2 ProduktfunktionenHier werden alle Produktfunktionen, die unterstutzt werden sollen, kurz zusammengefasst. Ihre Detaillierung folgt inKapitel 3.
2.3 Charakteristika der BenutzerIn diesem Abschnitt werden die Charakteristika der Benutzer beschrieben. Dies kann in Form der oben eingefuhrtenPersonas geschehen. Alle fur uns als Entwickler relevanten Details sollten erwahnt werden. Dazu gehoren meist derBildungsstand, die Erfahrung und vorhandene technische Kenntnisse.
2.4 EinschrankungenAlle maßgebenden Einschrankungen, die die Entwicklung betreffen, werden in diesem Abschnitt aufgefuhrt. Dazugehoren sowohl die so genannten nicht-funktionalen Produktattribute als auch organisatorische Rahmenbedingungen.Hier sind zum Beispiel gesetzliche Rahmenbedingungen, weitere Hardwarebeschrankungen, Zwang zur parallelisiertenAusfuhrung, erforderliche Zuverlassigkeit, sicherheitskritische Aspekte sowie Aspekte des Datenschutzes zu nennen.
2.5 Annahmen und AbhangigkeitenUnsere Entwicklung startet oft mit Annahmen, bei denen wir zum gegenwartigen Zeitpunkt nicht sicher sind, ob siezutreffen. Wenn die Entwicklung von solche Annahmen abhangt, stellen die Annahmen ein Risiko dar, das wir in diesemAbschnitt explizit benennen. Der Architekt kann dann versuchen, die potentiellen Auswirkungen dieser Risiken imArchitekturentwurf zu minimieren.
Jede Abhangigkeit von Dritten stellt ein weiteres Risiko dar. Sie fuhren zur Annahme, dass die, von denen wir abhangen,die von uns erwunschte Leistung erbringen. Aus diesem Grund werden alle Abhangigkeiten hier auch explizit aufgefuhrt.
Anforderungsanalyse
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
3. Detaillierte Beschreibung
3.1 Externe Schnittstellen
3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 Produktfunktionen
3.3 Performanzanforderungen
3.4 Entwurfseinschrankungenz.B. Standards
3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat
3.6 Andere Anforderungen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 178 / 634
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
3. Detaillierte Beschreibung
3.1 Externe Schnittstellen
3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 Produktfunktionen
3.3 Performanzanforderungen
3.4 Entwurfseinschrankungenz.B. Standards
3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat
3.6 Andere Anforderungen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
Den großten Anteil der Anforderungsspezifikation nimmt das Kapitel 3 ein, in dem die Anforderungen in großeremDetail beschrieben werden.
3. Detaillierte Beschreibung
3.1 Externe SchnittstellenIn den vier folgenden Abschnitten werden die verschiedenen Schnittstellen im Detail beschrieben. Auf die Spezifikationder Benutzungsschnittstelle gehen wir an dieser Stelle besonders ein.
3.1.1 BenutzungsschnittstelleDie Benutzungsschnittstelle kann durch einen GUI-Prototypen beschrieben werden. Wenn dieser ausfuhrbar ist,dann werden im Text hier die wesentlichen Interaktionskonzepte beschrieben; ansonsten wird auf denausfuhrbaren Prototypen verwiesen, der vom Kunden abgenommen sein muss. Ist der GUI-Prototyp nichtausfuhrbar, dann kann man hier die Screenshots und Skizzen einfugen, die in der Soll-Analyse erstellt wurden,um die Benutzungsschnittstelle vorzufuhren. Es genugt jedoch nicht, nur Bildschirmmasken aufzulisten. Es mussauch der Zusammenhang der Dialoge und der anderen Interaktionselementen mit den Anwendungsfallen (d.h.der Funktionalitat im Kontext des Arbeitsflusses, der unterstutzt werden soll) beschrieben werden. Fur jedeEingabemoglichkeit muss beschrieben sein, was damit ausgelost werden kann und welche Ausgabe erfolgt.Ebenso muss die Navigation zwischen allen Dialogen und etwaige Zustande der Schnittstelle beschrieben sein.Die Beschreibung soll so genau sein, dass man daraus ohne weitere Schritte ein Benutzerhandbuch erstellenkann. Die Entscheidung, wie die Benutzungsschnittstelle auszusehen hat, liegt also nicht beim Programmiererspater, sondern steht von Anfang an fest.
3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 ProduktfunktionenIn diesem Abschnitt werden die Produktfunktionen im Detail beschrieben. Dieser Abschnitt bildet in der Regel mit derBenutzungsschnittstelle zusammen den umfangreichsten Teil. Deshalb ist eine sinnvolle Glieder unabdingbar. Wir werdenweiter unten auf alternative Gliederungen eingehen. Der Zusammenhang zwischen Benutzungsschnittstellen (sowie allenanderen Schnittstellen) und der hier beschriebenen Produktfunktionen muss klar gemacht werden.
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
3. Detaillierte Beschreibung
3.1 Externe Schnittstellen
3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 Produktfunktionen
3.3 Performanzanforderungen
3.4 Entwurfseinschrankungenz.B. Standards
3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat
3.6 Andere Anforderungen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
3.3 PerformanzanforderungenFunktionale Anforderungen beschreiben die erwartete Ausgabe auf eine Eingabe hin. Bei Echtzeitsystemen mit hartenDeadlines muss nicht nur die erwartete Ausgabe angegeben werden, sondern auch nach welcher Zeit die Antworterfolgen muss, da sie ansonsten nicht mehr gebraucht wird. Bei Systemen ohne Echtzeitanforderungen hingegen werdenzeitliche Aspekte haufig nicht explizit angegeben. Das ist jedoch falsch. Denn auch bei interaktiven Systemen erwartenwir eine zeitnahe Reaktion des Systems auf unsere Eingabe hin, weil wir das Programm sonst nicht verwenden wollen.Erfolgen keine konkreten Angaben zur maximalen Reaktionszeit ist es schwer, uber die Vertragserfullung bei der Abgabezu diskutieren. Deshalb sollte man grundsatzlich Aussagen zur erforderlichen Performanz jeder Funktionalitat machen.Dies kann relativ zum Datenvolumen erfolgen oder in absoluten Zeitangaben. Im letzteren Fall nimmt das Mengengerusteine noch gewichtigere Stellung ein. Denn nur durch das Mengengerust konnen wir zu absoluten Zeiten kommen, diespater uberprufbar sind.
In diesem Abschnitt ist der Platz fur die Beschreibung der Performanzanforderungen aller Produktfunktionen. Alternativkann man diese Anforderungen auch bei der Beschreibung der Produktfunktionen angeben und dann auf diesenAbschnitt verzichten. Das Prinzip der Trennung von Aspekten, dem wir bei einer Anforderungsspezifikation folgen, legtaber einen eigenen Abschnitt nahe. Die Beschreibung kann z.B. durch einfache Tabellen erfolgen, in denen dieProduktfunktionen aufgefuhrt sind und die maximale Reaktionszeit in Abhangigkeit der Eingabe angegeben wird.
3.4 EntwurfseinschrankungenImplementierungsdetails gehoren – wie schon mehrfach gesagt – nicht in die Anforderungsspezifikation. Es gibt aberdennoch haufig Aspekte, die beim Entwurf berucksichtigt werden mussen. Dazu gehoren z.B. Standards, an die sich dieSoftware halten muss. In der Luft- und Raumfahrt beispielsweise gibt es Codierungsstandards wie MISRA, derenEinhaltung zuverlassigere Systeme verspricht. Hersteller von Software mussen sich an solche Standards halten, sonstwird ihr System nicht verwendet. In diesem Abschnitt werden aus diesem Grund alle weiteren Einschrankungen desEntwurfs beschrieben, sofern sie aus Kundensicht relevant sind.
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
3. Detaillierte Beschreibung
3.1 Externe Schnittstellen
3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 Produktfunktionen
3.3 Performanzanforderungen
3.4 Entwurfseinschrankungenz.B. Standards
3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat
3.6 Andere Anforderungen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
3.5 SoftwaresystemattributeNeben Performanzanforderungen gibt es noch weitere Systemattribute, zu denen die Anforderungsspezifikation Aussagenmachen muss. Dazu gehoren Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit, Portabilitat und weitereSoftwarequalitaten (oft auch nichtfunktionale Anforderungen genannt). Wir werden weiter unten noch darauf zusprechen kommen, dass diese Art Anforderungen konkret beschrieben werden mussen. Die Forderung
”Das System muss
sicher sein“ ist viel zu allgemein als dass man sie erfullen konnte.
3.6 Andere AnforderungenIn diesem Abschnitt konnen weitere relevante Anforderungen beschrieben werden, die in keine der oben genanntenAbschnitte passen.
Inhalt der Anforderungsspezifikation nach IEEE Standard830.1998
3. Detaillierte Beschreibung
3.1 Externe Schnittstellen
3.1.1 Benutzungsschnittstelle3.1.2 Hardwareschnittstelle3.1.3 Softwareschnittstelle3.1.4 Kommunikationsschnittstelle
3.2 Produktfunktionen
3.3 Performanzanforderungen
3.4 Entwurfseinschrankungenz.B. Standards
3.5 Softwaresystemattributez.B. Zuverlassigkeit, Verfugbarkeit, Sicherheit, Wartbarkeit,Portabilitat
3.6 Andere Anforderungen
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Inhalt der Anforderungsspezifikation nach IEEEStandard 830.1998
Erganzungen zum Standard:
Die Anforderungsspezifikation nach IEEE Standard 830.1998 verlangt nirgendwo, dass die Ergebnisse derIst-Analyse beschrieben werden sollen. Diese Ergebnisse sind jedoch wichtig, um die Anforderungen zu verstehenund einschatzen zu konnen. Man sollte deshalb entweder ein eigenes Dokument hierfur anlegen, das in derAnforderungsspezifikation referenziert wird, oder aber im Einfuhrungskapitel einen entsprechenden Abschnittverfassen.
Außerdem weist der Standard an keiner Stelle darauf hin, dass auch die moglichen zukunftigen Anderungen derAnforderungen beschrieben sein sollten. Diese sind jedoch wichtig, damit der Architekt die Architektur so entwerfenkann, dass diese Anderungen – so sie eintreffen – relativ einfach umgesetzt werden konnen. Aus diesem Grundeempfiehlt sich in Kapitel 2 beziehungsweise Kapitel 3 (je nach Detaillierungsgrad) ein Abschnitt zu zukunftigenEntwicklungen der Anforderungen.
Im Datenmodell modellieren wir die Objekte der Anwendungsdomane, die fur die Beschreibung unsererAnforderungen relevant sind. Im Standard wird kein Ort explizit genannt, an dem das Datenmodell beschriebenwerden soll. Hier bietet sich ein Unterabschnitt in Abschnitt 2.2 an.
Anforderungsanalyse
Softwaresystemattribute
Softwaresystemattribute:
oft als nicht-funktionale Anforderungen bezeichnet
mussen objektivierbar sein
Das System soll sicher sein.
versus:
PGP-Verschlusselung wird verwendet
Logging aller Aktionen
Nachrichten durfen nur uber Verschlusselungskomponente geschehen
Indizierte Zugriffe auf Felder mussen zur Laufzeit gepruft werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 179 / 634
Softwaresystemattribute
Softwaresystemattribute:
oft als nicht-funktionale Anforderungen bezeichnet
mussen objektivierbar sein
Das System soll sicher sein.
versus:
PGP-Verschlusselung wird verwendet
Logging aller Aktionen
Nachrichten durfen nur uber Verschlusselungskomponente geschehen
Indizierte Zugriffe auf Felder mussen zur Laufzeit gepruft werden20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Softwaresystemattribute
Wie oben beim Abschnitt 3.5 Softwaresystemattribute erwahnt sind neben den funktionalen Anforderungen auchdie so genannten nicht-funktionalen Anforderungen, wie Portierbarkeit etc., zu beschreiben. Wie wir auch schonoben diskutiert haben, sollen alle Anforderungen uberprufbar sein. Das heißt die Aussagen zu dennicht-funktionalen Eigenschaften mussen so genau und konkret sein, dass man eine Prufprozedur angeben kann, umbei Auslieferung uberprufen zu konnen, ob die Anforderung erfullt wurde. Die Forderung
”Das System muss sicher
sein“ genugt diesem Anspruch nicht, weil nicht klar ist, wogegen das System gesichert werden soll. Konkreter sollteman also etwa fordern:
• Alle Netzwerktransaktionen werden mit PGP verschlusselt.
• Alle Operationen des Administrators werden aufgezeichnet.
• Alle Benutzer mussen sich mit einem mindestens acht Zeichen langen Passwort authentifizieren.
Diese Aussagen sind uberprufbar. Interessanterweise stellen wir an dieser Stelle fest, dass aus den so genanntennicht-funktionalen Eigenschaften durch die Konkretisierung funktionale Eigenschaften werden konnen. DieTrennung in funktionale und nicht-funktionale Eigenschaften ist also etwas kunstlich bei allen Eigenschaften, dieexterne Eigenschaften betreffen. Externe Eigenschaften sind solche, die der Benutzer direkt wahrnehmen kann.Interne Eigenschaften betreffen vielmehr den inneren Aufbau.
Anforderungsanalyse
Softwaresystemattribute
Das System soll portierbar sein.
versus:
Anteil der plattformabhangigen Komponenten < 2%
Anteil der plattformabhangigen Codezeilen < 5%
Verwendung einer portierbaren Hochsprache
Einschrankung auf portierbare Sprachkonstrukte
Verwendung eines verbreiteten Betriebssystems
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 180 / 634
Softwaresystemattribute
Das System soll portierbar sein.
versus:
Anteil der plattformabhangigen Komponenten < 2%
Anteil der plattformabhangigen Codezeilen < 5%
Verwendung einer portierbaren Hochsprache
Einschrankung auf portierbare Sprachkonstrukte
Verwendung eines verbreiteten Betriebssystems
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Softwaresystemattribute
Aber auch Anforderungen zu inneren Eigenschaften der Software mussen hinreichend genau angegeben sein. DieAussage
”Das System soll portierbar sein“, die eine innere Qualitat darstellt, kann nicht uberpruft werden, weil
nicht klar ist, wohin portiert werden soll und was Portierbarkeit genau bedeuten soll. Besser muss angegebenwerden, auf welcher Hardware und fur welches Betriebssystem die Software portiert werden soll. Dann muss derBegriff portierbar konkretisiert werden, z.B. auf die folgende Weise:
• Der Anteil der plattformabhangigen Komponenten soll weniger als 2% ausmachen.
• Der Anteil der plattformabhangigen Codezeilen soll weniger als 5% sein.
• Es soll eine Hochsprache als Implementierungssprache verwendet werden, die auf allen Plattformen verfugbar ist, auf dieportiert werden soll.
• Alle verwendeten Konstrukte der Programmiersprache mussen auf allen Zielplattformen verfugbar sein.
Anforderungsanalyse
Prasentation der Anforderungen
Funktionale Anforderungen geordnet nach:
Operationsmodus
z.B. Kontrollsysteme: Training, Normal, Notfall
Benutzerklassen
z.B. Fahrzeugsteuerung: Fahrer, Fahrgaste, Wartungstechniker
Objekte und Klassen
z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal,Raume, Arztinnen, Medizinjede Klasse wird beschrieben durch ihre Attribute und Methoden
Features oder auch Anwendungsfalle (gewunschter nach außensichtbarer Service)
z.B. Telefonsystem: Nahgesprach, Weiterleitung, Konferenzgesprach
Stimuli (bei reaktiven Systemen)
z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel,Schlingern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 181 / 634
Prasentation der Anforderungen
Funktionale Anforderungen geordnet nach:
Operationsmodus
z.B. Kontrollsysteme: Training, Normal, Notfall
Benutzerklassen
z.B. Fahrzeugsteuerung: Fahrer, Fahrgaste, Wartungstechniker
Objekte und Klassen
z.B. Patientenmonitorsystem: Patienten, Sensoren, Pflegepersonal,Raume, Arztinnen, Medizinjede Klasse wird beschrieben durch ihre Attribute und Methoden
Features oder auch Anwendungsfalle (gewunschter nach außensichtbarer Service)
z.B. Telefonsystem: Nahgesprach, Weiterleitung, Konferenzgesprach
Stimuli (bei reaktiven Systemen)
z.B. Landesystem eines Flugzeugs: Energieverlust, Windwechsel,Schlingern
20
09
-02
-09
Software-Projekt
Anforderungsanalyse
Anforderungsspezifikation
Prasentation der Anforderungen
Wie oben erwahnt, kommt der Strukturierung des Abschnitts 3.2 Produktfunktionen eine große Bedeutung zu.Dieses Kapitel ist sehr umfangreich und alle Leser sollen sich moglichst einfach darin zurecht finden.
Welche Kategorisierung zu verwenden ist, hangt von der Art der Anwendung ab. Bei reaktiven Systemen, also z.B.Steuerungssystemen, kann man nach den Stimuli gruppieren, auf die die Software reagieren muss. Bei einerSoftware, die das Landen eines Flugzeugs steuert, konnte man z.B. nach plotzlichem Energieverlust, Windwechseloder Schlingern etc. ordnen. Zu den allgemeineren Ordnungskriterien, die bei sehr vielen Arten von SystemenAnwendung finden konnen, zahlen Operationsmodi. Kontrollsysteme haben z.B. haufig die OperationsmodiTraining, Normal und Notfall. Ein weiteres allgemeines Kriterium ist das der Benutzerklassen. Die Software einesBusses konnte unterscheiden in Produktfunktionen, die Fahrer, Fahrgaste oder Wartungstechniker betreffen. Beiobjektorientiertem Vorgehen ergeben sich in der Analyse Objekte und Klassen, nach denen man gruppieren konnte.In einem Patientenmonitorsystem erwarten wir als Klassen z.B. Patienten, Sensoren, Pflegepersonal, Raume,Arztinnen, Medizin. Jede dieser Klassen wird dann beschrieben durch ihre Attribute und Nachrichten, die sieversteht. Schließlich konnen wir auch nach Anwendungsfallen kategorisieren. Bei einem Telefonsystem waren daszum Beispiel das Nahgesprach, die Weiterleitung und das Konferenzgesprach.
Wie immer man sich entscheidet, man sollte in jedem Falle die Kategorisierung uniform anwenden. Es kanndennoch sinnvoll sein, Kategorien zu kombinieren, was kein Widerspruch zur Uniformitat sein muss. Dem Ziel derUniformitat genugend konnte man z.B. auf erster Ebene nach Benutzerklassen ordnen und auf zweiter Ebene nachAnwendungsfallen.
Anforderungsanalyse
Wiederholungsfragen I
Was ist an der Erhebung der Anforderungen so schwierig?
Erlautern Sie das Kano-Modell. Was folgt daraus fur dieAnforderungsspezifikation?
Wozu dient die Anforderungsspezifikation und welche Folgen habenihre Mangel?
Was sind die Schritte der Anforderungsspezifikation?
Was sind Personas und welches Ziel wird mit ihnen verfolgt?
In welchen Phasen des Entwicklungsprozesses konnen Personasverwendet werden?
Was ist das Ziel der Ist-Analyse und aus welchen Schritten bestehtsie?
Erlautern Sie Techniken zur Ist-Analyse. Bewerten Sie sie.
Insbesondere: Auf welchen Prinzipien basiert das Interview imKontext und wie wird es durchgefuhrt?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 182 / 634
Anforderungsanalyse
Wiederholungsfragen II
Welche Arten des Prototypings gibt es und wozu dienen sie?
Wegwerf-, technischer und evolutionarer Prototyp
horizontaler versus vertikaler Prototyp
passive, aktive, interaktive Storyboards
Welche Eigenschaften der Anforderungsspezifikation streben wir an?
Welche Bestandteile hat eine Anforderungsspezifikation?
Welche Systemattribute spielen in der Anforderungsspezifikation eineRolle und worauf ist bei ihrer Spezifikation zu achten?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 183 / 634
Objektorientierte Modellierung
Objektorientierte Modellierung
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
Wiederholungsfragen5 Objektorientierte Modellierung
LernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 184 / 634
Objektorientierte Modellierung
Lernziele
objektorientiert modellieren konnen
wesentliche Konstrukte der Unified Modeling Language (UML) lesenund anwenden konnen
Anmerkung: kein UML-Kurs; zur UML siehe z.B.: Storrle (2005).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 185 / 634
Objektorientierte Modellierung
Modellierung
Was ist ein Modell?
Abbild eines Originals
Wozu modellieren wir?
um etwas zu verstehenum Vorhersagen machen zu konnenum etwas zu dokumentieren
Wann modellieren wir?
jederzeit: Projektplan, Anforderungen, Architektur, . . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 187 / 634
Objektorientierte Modellierung
Objektorientierte Modellierung
Ausgehend von Geschaftsprozessen. . .
Identifiziere Aktoren
Beschreibe Anwendungsfalle
Bestimme statisches Modell
Identifiziere ObjekteIdentifiziere Eigenschaften der ObjekteBestimme Assoziationen zwischen ObjektenFasse Objekte zu Klassen zusammenOrdne Klassen in Vererbungshierarchien einBestimme Multiplizitaten der Assoziationen
Erstelle Verhaltensmodell
Identifiziere Ereignisse und modelliere Interaktionen inAnwendungsfallenIdentifiziere Verhalten der ObjekteBeschreibe das Verhalten (Vor- und Nachbedingungen)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 188 / 634
Objektorientierte Modellierung
Ausgehend von Geschaftsprozessen. . .
Identifiziere Aktoren
Beschreibe Anwendungsfalle
Bestimme statisches Modell
Identifiziere ObjekteIdentifiziere Eigenschaften der ObjekteBestimme Assoziationen zwischen ObjektenFasse Objekte zu Klassen zusammenOrdne Klassen in Vererbungshierarchien einBestimme Multiplizitaten der Assoziationen
Erstelle Verhaltensmodell
Identifiziere Ereignisse und modelliere Interaktionen inAnwendungsfallenIdentifiziere Verhalten der ObjekteBeschreibe das Verhalten (Vor- und Nachbedingungen)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Objektorientierte Modellierung
Objektorientierte Modellierung
Dies ist keine streng sequenzielle Folge. Die Aktivitaten verlaufen vielmehr parallel und iterativ.
Objektorientierte Modellierung
Ist → Soll
Schwierig: Dinge im Abstrakten beschreiben.
Einfacher: von konkreten Geschaftsprozessen ausgehen.
Definition
Ein Geschaftsprozess ist eine Folge von Schritten oder ein Rezept, umein Geschaftsresultat zu erzielen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 189 / 634
Objektorientierte Modellierung
Prosaische Geschaftsprozessbeschreibung im Fahrradladen
Geschaftsprozess Einkauf
Kunde Konig mochte Flaschenhalter kaufen; besitzt mehrereFahrrader
Konig tritt in den Laden und zuckt sein PDA
PDA bietet alle Rader des Kunden an
Konig wahlt sein 28”-Rennrad mit Rahmen-Standardbohrung aus;Rahmenfarbe: magenta
Konig wahlt “Hinzufugen” aus
Konig gibt “Flaschenhalter” ein und quittiert
PDA nimmt Verbindung mit Laden-Host-Rechner auf
PDA ubermittelt Anfrage fur Flaschenhalter (verschlusselt!)
Host-Rechner ubermittelt Sortiment Flaschenhalter (verschlusselt!)
PDA pruft auf Vertraglichkeit mit ausgewahltem Rad
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 191 / 634
Objektorientierte Modellierung
Beispiel Fahrradladen (Forts.)
Geschaftsprozess Einkauf (Forts.)
PDA prasentiert alle Flaschenhalter, die passen (hartes Kriterium)
Konig deselektiert alle Flaschenhalter mit unpassender Farbe (weichesKriterium)
Konig lasst nach Preis sortieren
Konig wahlt Flaschenhalter in bestimmtem Preissegment aus
Konig geht mit Auswahl zu Verkaufer
Verkaufer Volker betrachtet Auswahl und berat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 192 / 634
Objektorientierte Modellierung
Geschaftsprozess und Anwendungsfall (Use-Case)
Merkmale von Geschaftsprozessen:
systemubergreifend,
unterbrechbar,
lang laufend,
erfordern fortlaufende Interaktion zwischen vielen Akteuren,
bestehen aus Anwendungsfallen.
Definition
Anwendungsfall (auch: Nutzfall)
beschreibt eine Menge von Aktionssequenzen (Varianteneingeschlossen)
jede Sequenz reprasentiert die Interaktion zwischen externen Aktorenmit dem System
Folge ist beobachtbares Resultat, relevant fur Aktor
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 193 / 634
Objektorientierte Modellierung
Aktor
Definition
Aktor
reprasentiert eine koharente Menge von Rollen, die von Benutzern inder Interaktion mit dem System eingenommen werden konnen
konnen Menschen und andere Dinge sein (z.B. andere automatisierteSysteme)
Beispiel:
Geschaftsprozess Einkauf im Fahrradladen
ein Anwendungsfall darin: Kunde verbindet seinen PDA mit demLadenrechner
→ Akteure: Kunde, Ladenrechner
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 194 / 634
Objektorientierte Modellierung
Textuelle Beschreibung von Anwendungsfallen
Name: ArtikelerganzungAktoren:
Kunde und Verkaufer
Vorbedingung:Kunde mochte erganzenden Artikel kaufenKunde und Verkaufer sind im LadenPDA und Ladenrechner sind verbunden
Nachbedingung:Kunde hat Artikel ausgewahlt
Ablauf:1 Kunde wahlt zu erganzenden Artikeltyp fur Rad R aus2 Ladenrechner liefert alle Artikel dieses Typs, die zu R passen3 Kunde wahlt aus dieser Liste aus
Varianten:Kunde findet keinen passenden Artikel→ Verkaufer berat Kundekeine Verbindung zwischen PDA und Ladenrechner→ Verkaufer berat Kunde
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 195 / 634
Objektorientierte Modellierung
Aktoren und Anwendungsfalle
1 Identifiziere Aktoren
2 Betrachte System aus der Sicht der Aktoren3 Bestimme Anwendungsfalle fur Aktoren
→ liefert moglicherweise neue Aktoren
4 zuruck zu 1, bis keine neuen Aktoren/Anwendungsfalle mehrgefunden werden konnen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 197 / 634
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle (OMG)
System
Waren−
sortiment
pflegen
entfernen
Produkt
obsoletes
Passendes
Produkt
finden
Kunde Verkäufer
AktorAnwendungsfall
Assoziation
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 200 / 634
UML-Notation fur Anwendungsfalle (OMG)
System
Waren−
sortiment
pflegen
entfernen
Produkt
obsoletes
Passendes
Produkt
finden
Kunde Verkäufer
AktorAnwendungsfall
Assoziation
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle
UML-Notation fur Anwendungsfalle (OMG)
Assoziationen werden in Anwendungsfalldiagrammen nicht benannt. Assoziationen sind keine Datenflusse;Assoziationen beschreiben Kommunikationsbeziehungen zwischen Aktoren und dem System.
Objektorientierte Modellierung
Aktoren und Anwendungsfalle
Strukturiere Anwendungsfalle
1 identifiziere gemeinsame Anteile in Anwendungsfallen und faktorisiereentsprechend
2 fasse ahnliche Anwendungsfalle und Aktoren in Vererbungshierarchienzusammen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 201 / 634
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle (OMG)
Person
Ladenbesitzer
Verkäufer
Retinatest
Passwort−
abfrage
inherits
Authentifizierung
<<include>>
<<include>>
Waren−
sortiment
pflegen
Kunden−
daten
pflegen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 205 / 634
UML-Notation fur Anwendungsfalle (OMG)
Person
Ladenbesitzer
Verkäufer
Retinatest
Passwort−
abfrage
inherits
Authentifizierung
<<include>>
<<include>>
Waren−
sortiment
pflegen
Kunden−
daten
pflegen
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle
UML-Notation fur Anwendungsfalle (OMG)
Mit Hilfe von <<include>> kann man gemeinsames Verhalten aus Anwendungsfallen herausfaktorisieren und nureinmal beschreiben; hilft, Redundanz zu vermeiden.Bedeutung B <<include>> A:
• Anwendungsfall B (Base) inkludiert das Verhalten von Anwendungsfall A (Inklusion)
• Anwendungsfall B ist ohne Inklusion A nicht notwendigerweise ein vollstandiger Anwendungsfall
• Inklusion B kann ein Fragment sein
Verwendung
• Verhalten von Inklusion A wird in mehreren Anwendungsfallen benotigt
Generalisierung: Anwendungsfalle konnen durch die inherit-Beziehung spezialisiert werden. Entspricht derobjektorientierten Vererbung.Bedeutung
• Anwendungsfall A (Child) erbt das Verhalten von Anwendungsfall B (Parent)
• Anwendungsfall B ist ein vollstandiger, von A unabhangiger Anwendungsfall
• Anwendungsfall A ist ein vollstandiger Anwendungsfall
Verwendung
• Verhalten eines Anwendungsfalls wird spezialisiert
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle (OMG)
Spezialanwendungsfall
Basisanwendungsfall
Variationspunkt
Erweiterungsrelation
Express−
bestellung
ausführen Bestellung
Priorität setzenExtension Points:
ausführen
<<extend>>
(setze Priorität)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 206 / 634
UML-Notation fur Anwendungsfalle (OMG)
Spezialanwendungsfall
Basisanwendungsfall
Variationspunkt
Erweiterungsrelation
Express−
bestellung
ausführen Bestellung
Priorität setzenExtension Points:
ausführen
<<extend>>
(setze Priorität)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle
UML-Notation fur Anwendungsfalle (OMG)
Extend-Relation erlaubt die Beschreibung optionalen Verhaltens. Erlaubt damit die Trennung des optionalen vomnotwendigen Verhalten. Kann auch benutzt werden, um ein alternatives Teilverhalten zu beschreiben, das anBedingungen geknupft ist (z.B. Fehlerausgabe und Benachrichtigung des Systemadministrators falls Passwort falschist). Kann auch verwendet werden, um Teilsequenzen zu kombinieren, deren Ausfuhrung vom Benutzer bestimmtwird (z.B. Dialog zur Auswahl von Operationen).Bedeutung: A <<extend>> B:
• Anwendungsfall A (Extension) erweitert das Verhalten von Anwendungsfall B (Base)
• Anwendungsfall B ist auch ohne Extension A ein vollstandiger Anwendungsfall
• Extension A kann ein Fragment sein
Verwendung
• Verhalten eines Anwendungsfalls wird erweitert
Objektorientierte Modellierung
Beschreibung von Anwendungsfallen
Anwendungsfalldiagramme:
deklarieren voneinander unabhangige Anwendungsfalle
beschreiben die Einbettung der Anwendungsfalle in denSystemkontext (externe Akteure)
beschreiben (konkretisieren) die Anwendungsfalle jedoch nicht
→ folgt spater
sind Ausgangspunkt fur die objektorientierte Modellierung
statische Eigenschaften (Attribute)dynamische Eigenschaften (Verhalten)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 207 / 634
Objektorientierte Modellierung
Beispiel Fahrradladen
Identifiziere Objekte: Suche nach Substantiven in Anwendungsfallen.
Operation: Einkauf
Kunde Konig mochte Sattel kaufen; besitzt mehrere Fahrrader
. . .
Konig wahlt sein 28”-Rennrad mit aus; Rahmenfarbe: magenta
. . .
PDA nimmt Verbindung mit Laden-Host-Rechner auf
. . .
Konig lasst nach Preis sortieren
. . .
Verkaufer Volker betrachtet Auswahl und berat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 209 / 634
Objektorientierte Modellierung
Anwendungsfall → Objekte
Objekt:”Ding“ (Gegenstand, Entitat) mit eigener Identitat
Volker :
König :
+geld = 40 EUR
Königs Rennrad :
+preis = 1500 EUR
+farbe = magenta
+größe = 60 cm
Sattel #1234 :
+preis = 20 EUR
+farbe = schwarz
+härte = knallhart
+gewicht = 200 g
Objekt (unterstrichen)Eigenschaft/Attribut
Königs Hollandrad :
+preis = 400 EUR
+farbe = schwarz
+größe = 58 cm
Wert
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 210 / 634
Objektorientierte Modellierung
Anwendungsfall → Objekte
Assoziation: Beziehung zwischen Objekten
Volker :
König :
+geld = 40 EUR
Königs Rennrad :
+preis = 1500 EUR
+farbe = magenta
+größe = 60 cm
Sattel #1234 :
+preis = 20 EUR
+farbe = schwarz
+härte = knallhart
+gewicht = 200 g
Königs Hollandrad :
+preis = 400 EUR
+farbe = schwarz
+größe = 58 cm
besitzt
besitzt
passt-zu
berät+Berater+Interessent
im-sortiment
Assoziation
AssoziationsnameRichtung
Rolle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 212 / 634
Objektorientierte Modellierung
Objekte versus Klassen
Instanz-Ebene
Objektdiagramme beschreiben statische Zusammenhange auf derEbene einzelner, konkreter Dinge
Schema-Ebene
Klassendiagramme beschreiben statische Zusammenhangeunabhangig von Details konkreter Objekte, auf der Ebene mehrerergleichartiger Dinge
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 214 / 634
Objekte versus Klassen
Instanz-Ebene
Objektdiagramme beschreiben statische Zusammenhange auf derEbene einzelner, konkreter Dinge
Schema-Ebene
Klassendiagramme beschreiben statische Zusammenhangeunabhangig von Details konkreter Objekte, auf der Ebene mehrerergleichartiger Dinge
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Statische Eigenschaften: Klassendiagramme
Objekte versus Klassen
Bemerkung
• Objektdiagramme werden in der UML als Teil der Klassendiagramme aufgefasst
Objektorientierte Modellierung
Objekte → Klassen
Klasse: Menge von gleichartigen Objekten mit gemeinsamen Eigenschaften
Verkäufer
+name
Kunde
+name
+geld
Sattel
+artikelnummer
+preis
+farbe
+härte
+gewicht
Klasse
Rad
+preis
+farbe
+größe
besitzt
im-sortiment
berät
passt-zu
1
Multiplizität
1
*
*
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 215 / 634
Objektorientierte Modellierung
Generalisierungen
sind spezielle Beziehung auf Schema-Ebene
beschreiben Beziehungen zwischen einer allgemeineren Klasse(Oberklasse, Superclass) und einer spezielleren Klasse (Unterklasse,Subclass)
die Unterklasse”erbt“ die Eigenschaften der Oberklasse:
AttributeMethoden und deren AufrufschnittstellenAssoziationen
Unterklassen konnen
neue Attribute, Methoden und Assoziationen definieren
ererbte Attribute, Methoden und Assoziationen redefinieren(uberschreiben)
von mehreren Oberklassen erben (Mehrfachvererbung)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 217 / 634
Generalisierungen
sind spezielle Beziehung auf Schema-Ebene
beschreiben Beziehungen zwischen einer allgemeineren Klasse(Oberklasse, Superclass) und einer spezielleren Klasse (Unterklasse,Subclass)
die Unterklasse”erbt“ die Eigenschaften der Oberklasse:
AttributeMethoden und deren AufrufschnittstellenAssoziationen
Unterklassen konnen
neue Attribute, Methoden und Assoziationen definieren
ererbte Attribute, Methoden und Assoziationen redefinieren(uberschreiben)
von mehreren Oberklassen erben (Mehrfachvererbung)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Statische Eigenschaften: Klassendiagramme
Generalisierungen
Bemerkung: unterschiedliche Umsetzung in verschiedenen Programmierumgebungen bzgl. Uberschreiben undMehrfachvererbung
Objektorientierte Modellierung
Klassen → Klassenhierarchien
VerkäuferKunde
+geld
Rad
+farbe
+größe
Sattel
+farbe
+härte
+gewicht
Unterklasse
ist-ein-Relation
OberklassePerson
+name
abstrakt
Artikel
+preis
+artikelnummer
berät
im-sortiment
passt-zu
besitzt
{XOR}
Einschränkungzweier Beziehungen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 218 / 634
Klassen → Klassenhierarchien
VerkäuferKunde
+geld
Rad
+farbe
+größe
Sattel
+farbe
+härte
+gewicht
Unterklasse
ist-ein-Relation
OberklassePerson
+name
abstrakt
Artikel
+preis
+artikelnummer
berät
im-sortiment
passt-zu
besitzt
{XOR}
Einschränkungzweier Beziehungen
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Statische Eigenschaften: Klassendiagramme
Klassen → Klassenhierarchien
Gemeinsame Attribute werden in gemeinsamen Oberklassen zusammengefasst. Kunde und Verkaufer haben jeweilsNamen. Rad und Sattel haben einen Preis und eine Artikelnummer. Das Attribut Farbe taucht in diesem Beispielnicht in der Oberklasse auf. Die Konsequenz ware sonst, dass jeder mogliche Artikel dieses Attribut hat. Bei vielenArtikeln, wie z.B. bei einem Sattelrohr oder einer Schraube, spielt Farbe aber keine Rolle. Deshalb tritt Farbe nurbei Rad und Sattel auf. Eine alternative Modellierung ware eine weitere Oberklasse Gefarbte Artikel von Rad undSattel, die dieses Attribut einfuhrt. Allerdings konnte es noch eine weitere Klasse Sattelrohr geben, die zwar keineFarbe, aber eine Harte hatte. Dann mussten auch Sattel und Sattelrohr eine gemeinsame Oberklasse mit demAttribut Harte haben. Dies fuhrte dann zu Mehrfachvererbung, weil ein Sattel sowohl Farbe als auch Harte hat.Bei der Modellierung von Anwendungskonzepten kann es gelegentlich zu Mehrfachvererbungen kommen. Dies istnicht weiter tragisch, solange in jedem Falle Liskovs Substitutionsprinzip erfullt ist. Bei der Abbildung desAnalysemodells auf eine konkrete Implementierung mit einer Programmiersprache ohne Mehrfachvererbung wird esdann allerdings zu einem Bruch kommen. In der Analysephase konzentrieren wir uns jedoch auf eine genaue undeinfache Modellierung und sollten uns deshalb von solchen Implementierungseinschrankungen noch nicht beirrenlassen.Meist sind diese neuen Oberklassen abstrakt, d.h. es gibt eigentlich kein Objekt, das genau von diesem Typ ist. Soist Person naturlich ein abstraktes Gebilde: Es gibt eigentlich nur Kunden oder Verkaufer, aber nichts, was man nurals Person bezeichnen wurde.Abstrakte Klassen sind daran zu erkennen, dass ihr Name kursiv geschrieben wird. In diesem Beispiel sind Personund Artikel abstrakt.
Objektorientierte Modellierung
Attributierte Assoziationen
Assoziationsklassen
beschreiben Beziehungen, die gleichzeitig Klassen sind
werden genutzt, um Assoziationen Attribute zuzuordnen
konnen eigene Beziehungen eingehen
Verkäufer
Sattel
+artikelnummer
+preis
+farbe
+härte
+gewicht
im-sortiment
+anzahl
Assoziationsklasse
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 219 / 634
Objektorientierte Modellierung
Mehrstellige Assoziationen
Assoziationsklassen
konnen auch mehrere Klassen in Beziehung setzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 220 / 634
Objektorientierte Modellierung
Aufbau von Objekten
Aggregation
ist spezielle Assoziation zur Verdeutlichung von
”Teil-Ganzes-Beziehungen“
beschreibt Zusammenfassung von Komponenten zu einem Aggregat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 222 / 634
Aufbau von Objekten
Aggregation
ist spezielle Assoziation zur Verdeutlichung von
”Teil-Ganzes-Beziehungen“
beschreibt Zusammenfassung von Komponenten zu einem Aggregat2
00
9-0
2-0
9
Software-Projekt
Objektorientierte Modellierung
Statische Eigenschaften: Klassendiagramme
Aufbau von Objekten
Leserichtung der Aggregation: Rad besteht aus einem Rahmen; ein Rahmen kann Teil eines oder gar keines Radssein.
Objektorientierte Modellierung
Aufbau von Objekten
Komposition ist spezielle Aggregation:
Existenz der Komponenten ist an die Existenz des Aggregatsgekoppelt,
jede Komponente gehort zu genau einem Aggregat (strong ownership)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 223 / 634
Aufbau von Objekten
Komposition ist spezielle Aggregation:
Existenz der Komponenten ist an die Existenz des Aggregatsgekoppelt,
jede Komponente gehort zu genau einem Aggregat (strong ownership)2
00
9-0
2-0
9
Software-Projekt
Objektorientierte Modellierung
Statische Eigenschaften: Klassendiagramme
Aufbau von Objekten
Brennt der Laden ab, sind auch alle seine Artikel verloren. Ein Verkaufer ohne einen Laden, ist kein Verkaufer mehr(auch wenn er als Person weiter existiert).Man wurde kaum behaupten wollen, dass ein Artikel Teil eines Kunden ist. Die normale Assoziation erscheint hierangemessener. Kauft ein Kunde einen Artikel in einem Laden, ist dieser nicht langer Teil des Ladens; er geht in denBesitz des Kunden uber.
Objektorientierte Modellierung
Vergleich der Assoziationstypen
Vererbung: ist-ein-Relation (Liskovs Substitutionsprinzip erfullt)
Aggregation: teil-von-Relation
Komposition: teil-von-Relation
Teil gehort zu genau einem GanzenTeil existiert nur im Kontext des Ganzen
allgemeine Assoziation: sonst
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 224 / 634
Objektorientierte Modellierung
Liskovs Substitutionsprinzip (1988; 1994)
Definition
Liskovs Substitutionsprinzip: jede Instanz der Unterklasse kann immerund uberall dort eingesetzt werden, wo Instanzen der Oberklasse auftreten.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 225 / 634
Objektorientierte Modellierung
Zusammenfassung Klassendiagramme
Beschreibungsinhalt
statische Systemaspekte
Beschreibung der wesentlichen, unterscheidbaren Dinge eines Systemsund ihrer Beziehungen
zentrale Modellierungskonstrukte:
Klassen
Assoziationen (Beziehungsklassen)
spezielle Assoziationen: Generalisierung und Aggregation/Komposition
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 226 / 634
Objektorientierte Modellierung
Beschreibung von Anwendungsfallen
textuelle Szenario-Beschreibungen (siehe oben)
Interaktionsdiagramme
Aktivitatsdiagramme
Zustandsdiagramme
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 228 / 634
Objektorientierte Modellierung
UML-Notation fur Anwendungsfalle (OMG)
Kollaboration
Anwendungsfall
RealisierungPassendes
Produkt
finden Produkt−
suche
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 229 / 634
UML-Notation fur Anwendungsfalle (OMG)
Kollaboration
Anwendungsfall
RealisierungPassendes
Produkt
finden Produkt−
suche
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Verhaltenseigenschaften
UML-Notation fur Anwendungsfalle (OMG)
Anwendungsfalle konnen durch die inherit-Beziehung spezialisiert werden. Entspricht der objektorientiertenVererbung.
Objektorientierte Modellierung
UML-Interaktionsdiagramme (OMG)
Beschreibungsinhalt:
dynamische Systemaspekte
exemplarische Beschreibung von Interaktionsabfolgen zwischenkollaborierenden Objekten (Inter-Objektverhalten)
zentrale Modellierungskonstrukte:
Objekte:”Dinge“ mit eigener Identitat
Nachrichten
beschreiben den Austausch von Informationen zwischen Objekten zumAuslosen von Aktivitatensind Signale/Ereignisse oder Methodenaufrufe
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 230 / 634
Objektorientierte Modellierung
UML-Interaktionsdiagramme (OMG)
Anwendung
Prazisierung von Szenarien (exemplarische Folgen von Aktivitaten)
Protokollierung des Nachrichtenaustausches
Erhebung der von einzelnen Objekten bereit gestellten Funktionalitat(Dienste, Methoden)
Varianten
Sequenzdiagramme
betonen zeitlichen Ablauf
Kommunikationsdiagramme
betonen Objektstruktur
Grenzen:
beschreiben Verhalten nur beispielhaft und nicht vollstandig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 231 / 634
Objektorientierte Modellierung
UML-Sequenzdiagramme (OMG)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 232 / 634
UML-Sequenzdiagramme (OMG)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Sequenzdiagramme
UML-Sequenzdiagramme (OMG)
Aufruf: synchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfanger mit gefullterPfeilspitze. Sender setzt Aktivitat aus (gestrichelter Aktivierungsbalken); Empfanger wird aktiviert(Aktivierungsbalken beim Empfanger beginnt).
Antwort synchrone Nachricht als Reaktion auf einen Aufruf dargestellt durch gestrichelter Pfeil vom Sender zumEmpfanger mit offener Pfeilspitze). Antwortender Sender wird deaktiviert, ausgesetzter Empfanger lebtwieder auf.
Signal asynchrone Nachricht dargestellt durch durchgezogenen Pfeil vom Sender zum Empfanger mit offenerPfeilspitze; Sender und Empfanger setzen ihre Aktivitat parallel fort.
Bei synchroner Nachricht (Aufruf):
• Sender schickt Nachricht an Empfanger und gibt die Kontrolle uber den weiteren Prozess an den Empfanger
• Empfanger gibt nach Bearbeitung der Nachricht die Kontrolle an den Sender zuruck
• Interaktionen des Empfangers, die nach Erhalt der Nachricht begonnen wurden, mussen beendet sein, bevor derEmpfanger die Kontrolle an den Sender zuruckgibt (nested flow of control, method-call).
Anmerkung: Die Notation hat sich hier ab UML 2.0 geandert.
Objektorientierte Modellierung
UML-Kommunikationsdiagramme (OMG)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 233 / 634
UML-Kommunikationsdiagramme (OMG)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Kommunikationsdiagramme
UML-Kommunikationsdiagramme (OMG)
Kommunikationsdiagramme
• beschreiben Interaktionen zwischen Objekten durch gerichtete Graphen
• die Abfolge der Nachrichten wird durch Nummerierung angezeigt
Sequenz- und Kommunikationsdiagramme beschreiben semantisch identische Inhalte mit unterschiedlichem Fokus(zeitlicher Ablauf bzw. Objekte stehen im Vordergrund).
Objektorientierte Modellierung
Interaktions- und Klassendiagramme
Bemerkung:
Interaktionsdiagramme beschreiben exemplarischeInteraktionsszenarien eines Systems aus dynamischer Sicht
Klassendiagramme beschreiben diese Systeme aus statischer,schematischer Sicht
Interaktionsdiagramme dienen als Ausgangspunkt zur Erganzung undUberprufung von Klassendiagrammen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 235 / 634
Objektorientierte Modellierung
Interaktionen → Methoden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 236 / 634
Objektorientierte Modellierung
Interaktionen versus Methoden
Interaktionen
beschreiben das Wechselspiel zwischen Akteuren uberBotschaften/Methoden10
liefern Methoden fur die modellierten Klassen
beschreiben jedoch nicht die Methoden selbst
10Methoden beschreiben hier abstraktes Verhalten im Kontext der Anforderungen;sind noch nicht notwendigerweise die Methoden im Sinne der Implementierung (fuhrenletztlich aber zu diesen hin).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 237 / 634
Objektorientierte Modellierung
Methoden
Beschreibung:
Parameter: Eingabe und Ausgabe
Vorbedingung: beschreibt die Annahmen der Methode, die geltenmussen, damit sie ausgefuhrt werden kann
Nachbedingung: beschreibt das Resultat der Methode
Fehlerbedingungen: Verletzung der Vorbedingungen und Fehler, diewahrend der Ausfuhrung auftreten konnen
Verhalten in Fehlersituationen: Nachbedingung fur jedenaufgetretenen Fehler
Reaktionszeit: Maximale Dauer, bis Resultat vorliegt (sowohl imNormal- als auch im Fehlerfall)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 239 / 634
Objektorientierte Modellierung
Methoden
Beispiel Sortierung und Ausgabe der Artikelliste:
Parameter:Eingabe: Artikelliste, AttributAusgabe: Artikelliste’
Vorbedingung:Attribut kommt bei allen Artikeln der Artikelliste vor
Nachbedingung:Artikelliste’ ist sortiert, d.h.:∀ i : 1 ≤ i < len(Artikelliste′)⇒ element(Artikelliste′, i) ≤Attribut element(Artikelliste′, i + 1)Artikelliste’ ist eine Permutation von Artikelliste
Fehlerbedingungen: keine, außer Vorbedingung nicht erfullt
Verhalten in Fehlersituationen:Artikelliste wird zuruckgegebenFehlermeldung wird ausgegeben
Reaktionszeit: n · log(n) · 0, 001 [sec], wobei n die Lange der Liste ist
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 240 / 634
Objektorientierte Modellierung
Beschreibung der Benutzeroberflache
1
2
47 Euro
78 Euro
100 Euro
145 Euro3
4
5
6
1 Grafik des Artikels in der Große40x40 Pixel
2 Artikeldaten (10pt-Schrift)
3 Attribut, nach dem sortiertwurde (rot, 12pt-Schrift)
4 Scrolling nach oben; es wirdimmer um einen Artikel nachoben geschoben
5 Scrolling nach unten; es wirdimmer um einen Artikel nachunten geschoben
6 Auswahl des Artikels; alternativkann man mit dem Stift durchrasches doppeltes Anklickeneinen Artikel auswahlen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 241 / 634
Objektorientierte Modellierung
Zusammenhang von Benutzernachrichten und GUI
Nachrichten an Benutzer: Anzeige in GUINachrichten vom Benutzer: Aktionen des Benutzers mit GUI (Texteingabe,Mausklicks etc.)
1 2 1 2
8747 Euro
78 Euro
100 Euro
145 Euro 145 Euro
5 64 4 5 6
neinja
Artikel kaufen?Wollen Sie diesen
Screen Auswahl Screen Kaufen
beschaffe (artikel-nr)Einfachklick auf Auswahl.1Einfachklick auf Kaufen.7
ermittle (artikel-typ). . .
ende. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 242 / 634
Objektorientierte Modellierung
Aktivitatsdiagramme
Wurzeln: Flussdiagramme, Petrinetze
modellieren klassenubergreifendes Verhalten (Kontrollfluss)
beschreiben haufig Anwendungsfalle
Einsatz empfohlen bei hauptsachlich intern ausgelostenZustandsubergangen (einfacher Kontrollfluss)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 243 / 634
Aktivitatsdiagramme
Wurzeln: Flussdiagramme, Petrinetze
modellieren klassenubergreifendes Verhalten (Kontrollfluss)
beschreiben haufig Anwendungsfalle
Einsatz empfohlen bei hauptsachlich intern ausgelostenZustandsubergangen (einfacher Kontrollfluss)
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Aktivitatsdiagramme
Aktivitatsdiagramme
Laut UML-Standard 1.x ist ein Aktivitatsdiagramm der”Zustandsautomat einer Berechnung“. Ab UML 2.0 wird es
auf Token-Konzept von Petri-Netzen zuruck gefuhrt.
Eine gute Darstellung findet man unter: http://informatik.unibas.ch/lehre/hs07/cs203/se5full.pdf
Objektorientierte Modellierung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 244 / 634
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Aktivitatsdiagramme
Aktivitatsdiagramme: Bestandteile
• Aktionszustande: Zustande mit nur einer Eingangsaktion und ohne interne Transitionen
• Aufrufzustande: Aufruf einer Operation
• Subaktivitatszustande: Zustande mit internen Aktivitatsdiagrammen
• Entscheidungen (”
if−then−else“)
• Aktions-/Objekts-Flussbeziehungen
• Schwimmbahnen: unterteilen Zustandigkeiten fur auszufuhrende Aktionen
• Kontroll-Icons fur Signale
Objektorientierte Modellierung
Nebenlaufigkeit in Aktivitatsdiagrammen: Signale
Kaffee einschenken
Machineanschalten
Leuchte aus
an
braue Kaffee
Kaffeetasse
Kontroll-Icons deuten Richtung des Signals anRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 245 / 634
Objektorientierte Modellierung
UML-Zustandsautomatendiagramme
modellieren Objektlebenszyklus: Verhalten eines Objekts in Bezug aufdie verfugbaren Operationen seiner Klasse
gehen zuruck auf Zustandsautomaten nach Harel (1987)
Zustand: Menge von Attributwerten eines Objekts
Transition: Zustandsanderung
geeignet auch zur Beschreibung von Anwendungsfallen undProtokollen
erlauben Verschachtelung von Zustanden und Automaten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 246 / 634
Objektorientierte Modellierung
Zustandsautomatendiagramme: Beispiel
Busy
do/ play busy tonebusy
Invalid
do/ play message
dial digit(n)
[invalid]
Timeout
do/ play message
after (15 sec.) after (15 sec.)
caller hangs up
/disconnect
callee
hangs up
callee
answers
Pinned
Talking
/enable speech
callee answers
Ringing
do/ play ringing tone
connected
Connecting
dial digit(n)
[valid]
[incomplete]
dial digit(n)
Dialingdial digit(n)DialTone
do/ play dial tone
lift receiver
/get dial tone
Idle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 248 / 634
Objektorientierte Modellierung
lift receiver
/get dial tone
Active
Busy
do/ play busy tonebusy
Invalid
do/ play message
dial digit(n)
[invalid]
Timeout
do/ play message
after (15 sec.) after (15 sec.)
caller hangs up
/disconnect
callee
hangs up
callee
answers
Pinned
Talking
/enable speech
callee answers
Ringing
do/ play ringing tone
connected
Connecting
dial digit(n)
[valid]
[incomplete]
dial digit(n)
Dialingdial digit(n)DialTone
do/ play dial tone
Idle
Zustande
einfach/zusammengesetzt
”interne“ Aktionen: entry, exit , do, include , frei definierbare Events
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 249 / 634
lift receiver
/get dial tone
Active
Busy
do/ play busy tonebusy
Invalid
do/ play message
dial digit(n)
[invalid]
Timeout
do/ play message
after (15 sec.) after (15 sec.)
caller hangs up
/disconnect
callee
hangs up
callee
answers
Pinned
Talking
/enable speech
callee answers
Ringing
do/ play ringing tone
connected
Connecting
dial digit(n)
[valid]
[incomplete]
dial digit(n)
Dialingdial digit(n)DialTone
do/ play dial tone
Idle
Zustande
einfach/zusammengesetzt
”interne“ Aktionen: entry, exit , do, include , frei definierbare Events
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Zustandsautomatendiagramme
• do/ activity : Aktivitat, die im Zustand ausgefuhrt wird
• entry/ action : bei Eintritt ausgefuhrte Aktivitat
• exit/ action : bei Austritt ausgefuhrte Aktivitat
• include/ : Zustandsmaschine wird importiert
• ereignisabhangig: Event [Condition] / ActionˆSend Event
Objektorientierte Modellierung
lift receiver
/get dial tone
Active
Busy
do/ play busy tonebusy
Invalid
do/ play message
dial digit(n)
[invalid]
Timeout
do/ play message
after (15 sec.) after (15 sec.)
caller hangs up
/disconnect
callee
hangs up
callee
answers
Pinned
Talking
/enable speech
callee answers
Ringing
do/ play ringing tone
connected
Connecting
dial digit(n)
[valid]
[incomplete]
dial digit(n)
Dialingdial digit(n)DialTone
do/ play dial tone
Idle
Transitionen
Ausloser: Ereignis, Bedingung, Zeit
Auswirkung: Aktion (z.B. Methodenaufruf), Zustandsanderung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 250 / 634
Objektorientierte Modellierung
Nebenlaufigkeit
mehrere nebenlaufige Regionen
Parallelitat durch Gabelung/Join (bedingungsfrei!)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 251 / 634
Objektorientierte Modellierung
Synchronisation nebenlaufiger Regionen
”Pseudozustande“ zur Synchronisation
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 252 / 634
Objektorientierte Modellierung
Auswahl (Choice)
n-fache Verzweigung des Kontrollflusses gesteuert von einer logischenBedingung
dynamische bedingungsabhangige Verzweigung: Guards an denausgehenden Transitionen werden ausgewertet, nachdem die Aktionan der eingehenden Transition ausgefuhrt wurde.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 253 / 634
Auswahl (Choice)
n-fache Verzweigung des Kontrollflusses gesteuert von einer logischenBedingung
dynamische bedingungsabhangige Verzweigung: Guards an denausgehenden Transitionen werden ausgewertet, nachdem die Aktionan der eingehenden Transition ausgefuhrt wurde.
20
09
-02
-09
Software-Projekt
Objektorientierte Modellierung
Zustandsautomatendiagramme
Auswahl (Choice)
Dynamische Auswertung der Bedingungen der ausgehenden Transitionen
Objektorientierte Modellierung
Mehrfachkreuzung (Junction)
State2
State0 State1
State3 State4
e1[b>0] e1[b>0]/ a:=a+1 / a:=a+2[a<0]
[a=0] [a>0]
Kombination aus mehrfacher Fallunterscheidung und mehrfacherVerzweigung
Vereinigung mehrerer Transitionen
Verschmelzung eingehender Transitionen und/oder
Erzeugung einer statischen bedingungsabhangigen Verzweigung:Guards an den ausgehenden Transitionen werden ausgewertet, bevordie Aktion an der eingehenden Transition ausgefuhrt wird.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 254 / 634
Objektorientierte Modellierung
Anwendung von Zustandsdiagrammen
Beschreibung von Objektlebenszyklen pro Klasse
Beschreibung von Protokollen
Verfeinerung von Anwendungsfallen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 255 / 634
Objektorientierte Modellierung
Wiederholungsfragen I
Was ist ein Modell? Wann und wozu modellieren wir?
Welches sind die wesentlichen Schritte der objektorientiertenModellierung im Kontext der Anforderungsspezifikation?
Was ist ein Anwendungsfall? Wie konnen Sie Anwendungsfallebeschrieben?
Was ist ein Aktor?
Welche Beziehungen zwischen Anwendungsfallen unterstutzt dieUML?
Was ist der Unterschied zwischen Objekt- und Klassendiagrammen?
Erlautern Sie Klassendiagramme fur die Datenmodellierung.
Was ist eine Generalisierung?
Worin besteht das Liskovsche Substitutionsprinzip?
Wie lassen sich attributierte Assoziationen und n-stelligeAssoziationen mit n > 2 darstellen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 256 / 634
Objektorientierte Modellierung
Wiederholungsfragen II
Was ist eine Aggregation bzw. eine Komposition?
Wie wird ein Anwendungsfall textuell beschrieben?
Erlautern Sie Interaktionsdiagramme (Sequenzdiagramme undKommunikationsdiagramme).
Erstellen Sie ein Sequenzdiagramm fur ein bestimmtes Szenario.
Uberfuhren Sie dieses Sequenzdiagramm in einKommunikationsdiagramm.
Wie lassen sich Methoden aus den Interaktionsdiagrammen ableiten?
Wie sind Methoden zu beschreiben?
Erlautern Sie Aktivitatsdiagramme der UML. Erstellen Sie einAktivitatsdiagramm fur ein bestimmtes Szenario.
Erlautern Sie Zustandsautomatendiagramme der UML. Erstellen Sieein Zustandsautomatendiagramm fur ein bestimmtes Szenario.
Wofur konnen die genannten Diagrammarten benutzt werden?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 257 / 634
Objektorientierte Modellierung
Weiterfuhrende Literatur/Links
Buchtipp: Storrle (2005)
Ein kurzes Tutorial in Deutsch:http://ivs.cs.uni-magdeburg.de/~dumke/UML/
Eine sehr kurze Ubersicht in Englisch:http://bdn.borland.com/article/0,1410,31863,00.html
Weitere ausfuhrlichere Tutorials in Englisch:http://pigseye.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/http://uml.tutorials.trireme.com/
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 258 / 634
Prufung der Anforderungsspezifikation
Prufung der Anforderungsspezifikation
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragen
6 ReviewsMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 259 / 634
Prufung der Anforderungsspezifikation
Motivation
Entwurf
Anforderungs−spezifikation
analyseAnforderung−
Entwicklung = Sequenz von Aktivitaten mitZwischenprodukten (Anforderungsspezifikation,Entwurf, Code, Testfalle etc.)
Qualitat der Zwischenprodukte bestimmtwesentlich Qualitat der von ihnen abhangigenAktivitaten
→ die Qualitat der Zwischenprodukte muss gesichert werden
→ wir mussen sicher stellen, dass alle Beteiligten sich uber dasZwischenprodukt einig sind
Quellcode kann durch Tests uberpruft werden
aber was machen wir mit nicht direkt ausfuhrbaren Dokumenten wieAnforderungsspezifikation und Entwurf?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 260 / 634
Prufung der Anforderungsspezifikation
Lernziele
Im Allgemeinen:
Uberblick uber Software-Prufungen haben
Reviews beliebiger Dokumente durchfuhren konnen
Im Speziellen:
Bedeutung der Prufung fur die Anforderungsspezifikation kennen
Anforderungsspezifikation prufen konnen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 261 / 634
Prufung der Anforderungsspezifikation
Arten der Prufungen
Validierung: Are we doing the right thing?
Prufung, ob das, was entwickelt wird, gewunscht ist.
Verifikation: Are we doing the thing right?
Prufung, ob der Entwicklungsschritt X richtig durchgefuhrt wurde.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 262 / 634
Arten der Prufungen
Validierung: Are we doing the right thing?
Prufung, ob das, was entwickelt wird, gewunscht ist.
Verifikation: Are we doing the thing right?
Prufung, ob der Entwicklungsschritt X richtig durchgefuhrt wurde.
20
09
-02
-09
Software-Projekt
Reviews
Software-Prufungen
Arten der Prufungen
Zur Qualitatssicherung gehoren Prufungen; eine Prufung in der Entwicklung kann grundsatzlich nach zweiPrinzipien erfolgen.Vergleich mit einer Fahrt auf der Basis einer Wegbeschreibung:
A: Haben wir das vorgesehene Ziel erreicht?
B: Sind wir, wie es die Beschreibung verlangt, an der richtigen Stelle auf die richtige Straße abgebogen?
Offenbar sind beide Prufungen sinnvoll: (A) ergibt die wichtigere Aussage, lasst sich aber nur anwenden, wenn dasEndziel oder ein definiertes Zwischenziel erreicht wurde. (B) lasst sich nach jedem Schritt anwenden.Man beachte aber, dass die Worter Validierung und Verifikation auch anders gebraucht werden, namlich
• Validierung als Oberbegriff fur alle Prufungen,
• Verifikation speziell fur Prufungen formaler Art (Programmbeweis und ahnliches).
Zur Vermeidung von Missverstandnissen spricht man dann von externer und interner Validierung (entsprechend Aund B) bzw. von formaler Verifikation.
Prufung der Anforderungsspezifikation
Software-Prufung
TestsProgramm−analysen
ReviewsInspektionen
nicht−mechanisch(durch Menschen)
mechanisch(durch den Rechner)
Software−Prüfung
statisch dynamisch
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 263 / 634
Software-Prufung
TestsProgramm−analysen
ReviewsInspektionen
nicht−mechanisch(durch Menschen)
mechanisch(durch den Rechner)
Software−Prüfung
statisch dynamisch
20
09
-02
-09
Software-Projekt
Reviews
Software-Prufungen
Software-Prufung
Am popularsten ist der Test; aber man kann mit dem Rechner auch statisch prufen. Fast immer kann man aberinspizieren.
Prufung der Anforderungsspezifikation
. . . ist prufbar durchdas Dokument . . . Inspektion TestLastenheft XPflichtenheft XSystementwurf XDefinition der Daten und Algorithmen XBenutzerhandbuch XTestdaten XCode X XAnleitungen etc. X
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 264 / 634
. . . ist prufbar durchdas Dokument . . . Inspektion TestLastenheft XPflichtenheft XSystementwurf XDefinition der Daten und Algorithmen XBenutzerhandbuch XTestdaten XCode X XAnleitungen etc. X
20
09
-02
-09
Software-Projekt
Reviews
Software-Prufungen
Naturgemaß lassen sich mechanische Prufungen nur dann anwenden, wenn die zu prufenden Informationen einermechanischen Analyse zuganglich sind. Darum kommt in der Software-Entwicklung als Prufverfahren ganzuberwiegend die Inspektion in Frage.
Prufung der Anforderungsspezifikation
Reviews (Fruhauf u. a. 2000)
Prinzip
Eine Software-Einheit wird (dezentral) von mehreren Gutachterninspiziert;
in einer gemeinsamen Sitzung werden die Mangel zusammengetragenund dokumentiert.
Ziel
Fehler zu finden,
nicht, die Fehler auch zu beheben.
Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler imAllgemeinen wieder ohne Mitwirkung Dritter durchfuhrt.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 265 / 634
Reviews (Fruhauf u. a. 2000)
Prinzip
Eine Software-Einheit wird (dezentral) von mehreren Gutachterninspiziert;
in einer gemeinsamen Sitzung werden die Mangel zusammengetragenund dokumentiert.
Ziel
Fehler zu finden,
nicht, die Fehler auch zu beheben.
Fehlerbehebung ist ein separater Arbeitsschritt, den der Entwickler imAllgemeinen wieder ohne Mitwirkung Dritter durchfuhrt.2
00
9-0
2-0
9
Software-Projekt
Reviews
Reviews
Reviews (Fruhauf u. a. 2000)
Nachfolgend wird das technische Review beschrieben. In der Praxis gibt es zahlreiche Varianten. Zwischen diesenFormen gibt es keine simple Qualitatsordnung! Das heißt, wir wissen nicht, welche davon effektiver und effizienterist in der Fehlersuche.
Prufung der Anforderungsspezifikation
Reviews (Fruhauf u. a. 2000)
Prufling
kann jeder in sich abgeschlossene, fur Menschen lesbare Teil vonSoftware sein
Beispiele: ein einzelnes Dokument, ein Codemodul, ein Testfall
Voraussetzung:
Referenzunterlagen benotigt, die eine Beurteilung erlauben
dazu gehoren eine Vorgabe oder Spezifikation sowie die relevantenRichtlinien
zusatzlich konnen Fragenkataloge (Checklisten) verwendet werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 266 / 634
Prufung der Anforderungsspezifikation
Reviews (Fruhauf u. a. 2000)
Rollen
Moderator leitet das Review, ist also fur den ordnungsgemaßenAblauf verantwortlich.
Sekretar fuhrt das Protokoll.
Gutachter sind Experten (z.B. Kollegen), die den Prufling beurteilenkonnen.
Autor ist der Urheber des Pruflings oder ein Reprasentant des Teams,das den Prufling erstellt hat.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 267 / 634
Prufung der Anforderungsspezifikation
Review-Prozess
Vorbereitung
Nacharbeit
Analyse
Sitzung
Freigabe
Planung
1−2 Wvorher
2 h
1−2 W
[akzeptabel][nicht akzeptabel]
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 268 / 634
Prufung der Anforderungsspezifikation
Review
Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager,Tester, Architekten, Handbuchautoren, Wartungspersonal.
Aufgaben:
Vorbereitung: Prufling lesen und nach bestimmten, ihnen individuellzugeteilten Gesichtspunkten prufen.
Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben,gewichten und protokollieren
begutachtennicht korrigieren
Nacharbeit: Autor korrigiert nach Auflagen der Gutachter
eventuell weitere Iteration mit Gutachtern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 269 / 634
Review
Gutachter: andere Entwickler, Benutzer, Auftraggeber, Produkt-Manager,Tester, Architekten, Handbuchautoren, Wartungspersonal.
Aufgaben:
Vorbereitung: Prufling lesen und nach bestimmten, ihnen individuellzugeteilten Gesichtspunkten prufen.
Sitzung: gefundene Probleme vorbringen; Befund gemeinsam erheben,gewichten und protokollieren
begutachtennicht korrigieren
Nacharbeit: Autor korrigiert nach Auflagen der Gutachter
eventuell weitere Iteration mit Gutachtern20
09
-02
-09
Software-Projekt
Reviews
Ablauf von Reviews
Review
Beim technischen Review werden Kollegen als Gutachter beigezogen. Dafur kommen vor allem andere Entwickler inFrage, aber auch Benutzer, Produkt-Manager oder Auftraggeber. Die Gutachter erhalten im technischen Reviewkonkrete Auftrage:
• Im ersten Schritt des Reviews, in der Vorbereitung, mussen die Gutachter das zu prufende Dokument lesen und nachbestimmten, ihnen individuell zugeteilten Gesichtspunkten prufen.
• Den zweiten Schritt bildet die Review-Sitzung, in der die Gutachter ihre in der Vorbereitung gefundenen Problemevorbringen. Gemeinsam erheben, gewichten und protokollieren sie die Befunde. Der Auftrag fur die Review-Sitzunglautet also, das Dokument oder Programm zu begutachten und nicht zu korrigieren, d.h. die Sitzung hat das Ziel,Probleme aufzuzeigen, nicht sie zu losen.
• Die Nacharbeit selbst wird dem Autor oder den Autoren zugeteilt. Die Gutachter kommen bei der Uberprufung derNacharbeit evtl. nochmals zum Zug.
Prufung der Anforderungsspezifikation
Review-Regeln
Review-Sitzung ist auf 2h beschrankt.
Falls notig wird eine weitere Sitzung, fruhestens am nachsten Tag,einberufen.
Der Moderator kann die Sitzung absagen oder abbrechen. Grund desAbbruchs ist zu protokollieren.
z.B. weil Gutachter nicht erscheinen oder ungenugend vorbereitet sind
Moderator ist nicht zugleich Gutachter.
Jeder Gutachter bekommt Gelegenheit, seine Befunde angemessen zuprasentieren.
Der Prufling – nicht der Autor – steht zur Diskussion. Das heißt:
Gutachter mussen auf ihre Ausdrucksweise achten.Autor darf weder sich noch das Resultat verteidigen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 270 / 634
Prufung der Anforderungsspezifikation
Review-Regeln II
Stilfragen (außerhalb der Richtlinien) werden nicht diskutiert.
Das Review-Team identifiziert Schwachpunkte und Fehler.
Team macht keine konstruktiven Vorschlage, wie Mangel zu behebensind;Befunde werden nicht in der Form von Anweisungen an den Autorprotokolliert.
Der Konsens der Gutachter zu einem Befund wird laufendprotokolliert. Die einzelnen Befunde werden gewichtet als
kritischer Fehler (Prufling fur den vorgesehenen Zweck unbrauchbar,Fehler muss vor der Freigabe behoben werden)Hauptfehler (Nutzbarkeit des Pruflings beeintrachtigt, Fehler sollte vorder Freigabe behoben werden),Nebenfehler (beeintrachtigen den Nutzen kaum),gut (fehlerfrei, bei Uberarbeitung nicht andern)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 271 / 634
Prufung der Anforderungsspezifikation
Review-Regeln III
Review-Team gibt Empfehlung uber die Annahme des Pruflings:
akzeptieren ohne Anderungenakzeptieren mit Anderungen (kein weiteres Review)nicht akzeptieren (weiteres Review erforderlich)
Alle Sitzungsteilnehmer unterschreiben das Protokoll
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 272 / 634
Prufung der Anforderungsspezifikation
Checklisten: Fragenkatalog fur ein Anforderungsdokument
Prufen Sie bitte das Dokument als Vorbereitung zur Sitzung gemaß denIhnen in Punkt D der Einladung zugeteilten Aspekten aus der folgendenListe.
Aspekt Form: Ist die Darstellung im Dokument sinnvoll?a1 Sind Anforderungen als solche erkennbar, d.h. von Erklarungen
unterscheidbar?a2 Sind alle Anforderungen eindeutig referenzierbar?a3 Ist die Spezifikation jeder Anforderung eindeutig?a4 Sind alle Anforderungen uberprufbar formuliert?
Aspekt Schnittstellen: Sind alle Schnittstellen eindeutig spezifiziert?b1 Sind alle Objekte der Umgebung (Benutzer, andere Systeme,
Basis-Software etc.) sowie alle Informationsflusse von und nach diesenObjekten spezifiziert?
b2 Sind alle Benutzerklassen (Dauerbenutzer, gelegentliche Benutzer,System-Administrator, etc.) des Systems identifiziert?
b3 . . .b7 Sind Vorgaben gemacht bezuglich Verwendung von
Betriebssystem-Funktionen, Bibliotheken und Hilfsprogrammen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 273 / 634
Prufung der Anforderungsspezifikation
Checklisten: Fragenkatalog fur ein Anforderungsdokument
(Fortsetzung)
Aspekt Vertraulichkeit: Sind die wesentlichen Aspekte desDatenschutzes berucksichtigt?
d1 Ist spezifiziert, welche Information vertraulich zu behandeln ist?d2 Sind die Zugriffsrechte aller Benutzerklassen definiert?d3 Ist definiert, gegen welche Art von unberechtigtem Zugriff die
Information geschutzt werden muss?
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 274 / 634
Prufung der Anforderungsspezifikation
Varianten des Software-Reviews
Design and Code Inspection (nach Fagan)
mit Einfuhrungssitzung, Gutachter-Notizen, die abgegeben werden,Vorleser, Entscheidungskompetenz, Metriken-Erhebung.
Schreibtischtest (besser: die Selbstkontrolle)
fuhrt jeder Entwickler allein durch (vgl. Humphreys PSP);ersetzt die eigentliche Prufung nicht.
Stellungnahme
ist ein”off-line“–Review unter der Regie des Autors;
den Vorteilen (geringer Organisationsaufwand) stehen erheblicheNachteile gegenuber (Prufling nicht vor Weiterbearbeitung geschutzt,Qualitat der Prufung und Umsetzung der Resultate nicht kontrolliert).
Structured Walkthrough
ist die Billig-Variante des Reviews: Autor ist Moderator;er kompensiert durch seine Prasentation die Einsparung (oderReduktion) der Vorbereitung;wahrend seiner Vorbereitung entdeckt er selbst viele Fehler.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 275 / 634
Prufung der Anforderungsspezifikation
Varianten des Software-Reviews
Perspektivisches ReviewPrinzip:
Prufling wird von Gutachtern mit unterschiedlichem Interesse gepruftGutachter haben konkreten Auftrag: Prufling (hypothetisch) benutzen
Beispiel:
Tester → Testfalle entwickelnBenutzer → System benutzenHandbuchautor → Handbuch schreibenArchitekt → Entwurf erstellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 276 / 634
Prufung der Anforderungsspezifikation
Varianten des Software-Reviews
Empirische Studien legen nahe (Berling und Runeson 2003; Fusaro u. a.1997; Hayes 1999; Miller u. a. 1998; Porter u. a. 1995; Porter und Votta1998; Sandahl u. a. 1998):
Reviews, die auf Checklisten basieren, sind effektiver alsAd-Hoc-Reviews;
perspektivische Reviews sind effektiver und effizienter als Reviews, dieauf Checklisten basieren:
mehr Fehler/Mangel gefundenmehr Fehler/Mangel in gleicher Zeiteinheit gefunden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 277 / 634
Prufung der Anforderungsspezifikation
Woran scheitern Reviews? Fallen und Gegenmittel
Probleme bei der Ein-/Durchfuhrung von Reviews:
Es fehlen gute Moderatoren
→ Leute aussuchen und ausbilden
Es fehlen Bezugsdokumente
→ suchen, anpassen, bereitstellen
Entwickler haben Angst
→ erste Reviews grundlich vorbereiten (und auf die Angste eingehen,selbst wenn sie geleugnet werden)
Reviews beißen sich an Außerlichkeiten fest
→ Bedeutung der Außerlichkeiten klarstellen, aber dann weitergehen;→ beim zweiten Review sicherstellen, dass die Außerlichkeiten in Ordnung
sind.
Bezugsdokumente sind ungeeignet
→ diskutieren und verbessern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 278 / 634
Prufung der Anforderungsspezifikation
Woran scheitern Reviews? Fallen und Gegenmittel II
Zeitdruck sabotiert Prufungen
→ klare Entscheidungen uber die Prioritaten treffen
Geprufte Dokumente werden verandert
→ Konfigurationsmanagement verbessern
Interesse an Reviews kuhlt sich ab (,,Jetzt ist doch eigentlich alles inOrdnung!”)
→ Statistiken fuhren, Erfolg nachweisen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 279 / 634
Prufung der Anforderungsspezifikation
Wiederholungsfragen
Was ist der Unterschied zwischen Verifikation und Validierung?
Welche Arten der Software-Prufung gibt es?
Was ist ein Review? Welche Rollen sieht es vor? Wie wird esdurchgefuhrt?
Welche Review-Varianten gibt es?
Worauf ist bei Reviews zu achten?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 280 / 634
Prufung der Anforderungsspezifikation
Weiterfuhrende Literatur
Fruhauf u. a. (2000) fuhren in Software-Prufung ein.
Shull u. a. (2000) zeigen in ihren empirischen Untersuchungen, dassperspektivische Reviews effektiver sein konnen als Reviews, die nurauf allgemeinen Check-Listen basieren
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 281 / 634
Entwurf von Benutzungsschnittstellen
Entwurf von Benutzungsschnittstellen
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragen
7 Entwurf von BenutzungsschnittstellenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 282 / 634
Entwurf von Benutzungsschnittstellen
Lernziele
Ergonomische Software erstellen konnen:
Bedienelemente graphischer Benutzungsschnittstellen kennen undeinsetzen konnen
Ergonomie bewerten konnen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 285 / 634
Entwurf von Benutzungsschnittstellen
Ergonomie
Definition
Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist dieWissenschaft der Arbeitsbedingungen und deren optimale Anpassung anden Anwender.
“Design for Use”
Anpassung von Maschinen, Computern und Systemen an menschliche(Denk- und Kommunikations-) Fahigkeiten und Bedurfnisse
zentral ist Schnittstelle zwischen Mensch und Maschine(Mensch-Computer-Interaktion)
Auswirkungen auf zum Beispiel: Arbeitsablaufe, Menu-Hierarchien,Kommandosprachen, Farb- und Schriftwahl und dieFunktionsaufteilung zwischen Mensch und Computer
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 286 / 634
Ergonomie
Definition
Ergonomie: (von ergon (Arbeit, Werk) und nomos (Gesetz, Regel)) ist dieWissenschaft der Arbeitsbedingungen und deren optimale Anpassung anden Anwender.
“Design for Use”
Anpassung von Maschinen, Computern und Systemen an menschliche(Denk- und Kommunikations-) Fahigkeiten und Bedurfnisse
zentral ist Schnittstelle zwischen Mensch und Maschine(Mensch-Computer-Interaktion)
Auswirkungen auf zum Beispiel: Arbeitsablaufe, Menu-Hierarchien,Kommandosprachen, Farb- und Schriftwahl und dieFunktionsaufteilung zwischen Mensch und Computer
20
09
-02
-09
Software-Projekt
Entwurf von Benutzungsschnittstellen
Ergonomie
Ergonomie
Alternative Definition
”Der Software-Ergonomie geht es um eine Optimierung des Zusammenspiels aller Komponenten, die die
Arbeitssituation von Computerbenutzern bestimmen: Mensch, Aufgabe, Technik und organisatorischer Rahmen. Siebeschrankt sich ausdrucklich nicht - wie oft falschlich angenommen - auf die Behandlung der Prasentationsaspekteinteraktiver Software.“
– nach Susanne Maaß, Software-Ergonomie,”benutzer- und aufgabengerechte Systemgestaltung“,
Informatik-Spektrum, 16, 1993, 191-205
Entwurf von Benutzungsschnittstellen
Usability
Definition
Usability: eines Produktes ist das Ausmaß, in dem es von einembestimmten Benutzer verwendet werden kann, um bestimmte Ziele ineinem bestimmten Kontext effektiv, effizient und zufriedenstellend zuerreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998)
ubersetzt als”Benutzerfreundlichkeit” oder
”Benutzbarkeit”
Verbesserung ist Ziel der (Software-)Ergonomie
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 287 / 634
Usability
Definition
Usability: eines Produktes ist das Ausmaß, in dem es von einembestimmten Benutzer verwendet werden kann, um bestimmte Ziele ineinem bestimmten Kontext effektiv, effizient und zufriedenstellend zuerreichen. — Part 11: “Guidance on Usability” (ISO 9241-11:1998 1998)
ubersetzt als”Benutzerfreundlichkeit” oder
”Benutzbarkeit”
Verbesserung ist Ziel der (Software-)Ergonomie
20
09
-02
-09
Software-Projekt
Entwurf von Benutzungsschnittstellen
Ergonomie
Usability
Wird auch als”Ein Maß fur die Qualitat, mit der ein Benutzer die Interaktion mit einer Maschine erlebt.“ definiert.
Entwurf von Benutzungsschnittstellen
Psychologische und kognitive Grundlagen
Kurzzeitgedachtnis
Information strukturieren und begrenzen: 7± 2
menschliche Gestaltwahrnehmung
→ bei Prasentation beachtenz.B. Superzeichenbildung: 0 4 2 1 2 1 8 2 4 2 1 versus 0421/218-2421
geteilte Aufmerksamkeit
→ Fortsetzung nach Unterbrechung unterstutzen
begrenzte Konzentrationsfahigkeit
→ nicht uberfordern, Sicherheiten einbauen
Unerfahrenheit verunsichert
→ Metaphern verwenden, z.B. Ikonen wie Mulleimer, Briefkasten→ explorative Untersuchung unterstutzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 288 / 634
Entwurf von Benutzungsschnittstellen
Vergleich von GUI und Kommandosprachen
Kommandosprachen Graphical User Interface (GUI)komplexe Operationen einfache Operationen
intensive Nutzung, gelegentlicher Einsatz,Experten leichte Erlernbarkeit
funktionale Bedienung, ObjektorientierungBerechnungen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 291 / 634
Entwurf von Benutzungsschnittstellen
Wegweiser
Meilensteine in der Geschichte graphischerBenutzungsschnittstellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 292 / 634
Entwurf von Benutzungsschnittstellen
Die ersten Ideen
Memex (Memory Extender) von Bush (1945)
Kompakt-Analog-Rechner zur Verwaltungverlinkter Informationen
beruhrungssensitive Bildschirme projizierenMikrofilme
Mikrofilme verknupft
Vor- und Zuruckblattern uber Hebel
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 293 / 634
Die ersten Ideen
Memex (Memory Extender) von Bush (1945)
Kompakt-Analog-Rechner zur Verwaltungverlinkter Informationen
beruhrungssensitive Bildschirme projizierenMikrofilme
Mikrofilme verknupft
Vor- und Zuruckblattern uber Hebel
20
09
-02
-09
Software-Projekt
Entwurf von Benutzungsschnittstellen
Geschichte graphischer Benutzungsschnittstellen
Die ersten Ideen
Dank auch an Matthias Kirschner fur einige seiner Folien.
Entwurf von Benutzungsschnittstellen
Semi Automatic Ground Environment
Bedienung durch Laien
Lichtgriffel (Light-Pen)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 294 / 634
Entwurf von Benutzungsschnittstellen
Sketchpad
von Ivan Sutherland (1963)
Objektorientierung stattBitmaps
Generische Operationen furverschiedene Objekte
Constraints zu den graphischenObjekten (z.B. Lange)
Copy & Paste
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 295 / 634
Entwurf von Benutzungsschnittstellen
Computermaus
von Douglas Engelbart und Bill English (1963)
relative Positionsveranderung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 296 / 634
Entwurf von Benutzungsschnittstellen
Windows Icons Menus & Pointer
Fruhe Ideen: Xerox Palo Alto Research Center (1970)
Prinzipien:
abstrakte Datensicht, VisualisierungRaum und ObjekteMetaphorisierung: Schreibtisch (Desktop)“What you see is what you get” (Texteditor BRAVO, Vorlaufer vonMicrosoft Word)einheitliche Visualisierung und Interaktionwenige Modi, generische Kommandos
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 297 / 634
Entwurf von Benutzungsschnittstellen
Xerox Star GUI
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 298 / 634
Entwurf von Benutzungsschnittstellen
Marktreife
1984 X-Windows System, Apple Lisa
1985 Atari ST, Amiga, Windows 1.0
1987 farbige GUI, Apple II
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 299 / 634
Entwurf von Benutzungsschnittstellen
Wegweiser
Moglichkeiten graphischer Benutzungsschnittstellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 300 / 634
Entwurf von Benutzungsschnittstellen
Direkte Manipulation
Direkte Manipulation:
Metaphern visualisiert in Form von Ikonen (Gegenstande)
physische Aktionen mittels Zeigegeraten
permanente visuelle Ruckkopplung
nutzt Intuition und Erfahrungen der Anwender in der metaphorisiertenWelt aus
Interaktionen:
Auswahl: “Point & Click”
Verschieben:
Unmittelbar: “Drag & Drop”Unterbrechbar: “Cut & Paste”
Vervielfaltigen: “Copy & Paste”
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 301 / 634
Entwurf von Benutzungsschnittstellen
Ruckkopplung an Nutzer
Metaphern der physischenWelt, z.B. Raumlichkeit,→ Wiedererkennungswert
Verbergen von Irrelevantem,Information auf Abruf,Kontextsensitivitat
Fortschrittsanzeige,Aktivitatsanzeige
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 302 / 634
Entwurf von Benutzungsschnittstellen
Fenster I
Fokus
Desktop, Hauptfenster
Handles, Scrollbars
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 303 / 634
Entwurf von Benutzungsschnittstellen
Fenster II
Reiter, Split-Fenster
Layout Manager
Dialogfenster
modal: Dialog muss abgeschlossen werden, bevor nachster Dialogbeginntnicht-modal: Dialoge konnen ko-existieren
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 304 / 634
Entwurf von Benutzungsschnittstellen
Menus und Schaltflachen I
”Pull-Down-Menu“
Paneele, Gruppen
Baumstruktur
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 305 / 634
Entwurf von Benutzungsschnittstellen
Menus und Schaltflachen II
Kontextmenu
Schaltflache, Button
Toolbars
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 306 / 634
Entwurf von Benutzungsschnittstellen
Textelemente
Mnemonics, Tooltips
Formularfelder
Listen, Tabellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 307 / 634
Entwurf von Benutzungsschnittstellen
Ikone, Metaphern
Dateisymbole
Programmverknupfungen
Thumbnails
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 308 / 634
Entwurf von Benutzungsschnittstellen
Manipulatoren und Attribute
Checkbox(Boolean)
Radio-Button(Alternativen)
Slider(Zahlenwerte)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 309 / 634
Entwurf von Benutzungsschnittstellen
Listen
Teilmenge,Permutation
statisch vs.erweiterbar
Combo-Box
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 310 / 634
Entwurf von Benutzungsschnittstellen
Wegweiser
Eigenschaften guter graphischerBenutzungsschnittstellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 311 / 634
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Aufgabenangemessenheit: Benutzer wird unterstutzt, Arbeitsaufgabeeffektiv und effizient zu erledigen
Dialoge sollten nur sachdienliche Informationen enthaltenVermeidung von Ablenkungen
weniger ist mehr (Funktionen)den Bildschirm nicht uberfullenvermeide es, Befehle redundant anzubietenkeine unnotigen Dialoge und Popups
Optimieren von haufigen Aufgabenkleine Anzahl von benotigten Schritten; Anzahl
”Klicks“ klein halten
große Knopfe fur Hauptbefehle, Tastaturkurzeldie haufigsten Funktionen auf dem ersten Bildschirmwichtige Befehle → hervorstehende Stelleweniger haufig benutzte Befehle → weniger hervorstehende Stelle(Untermenu, Einstellungsdialog)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 312 / 634
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Aufgabenangemessenheit: Benutzer wird unterstutzt, Arbeitsaufgabeeffektiv und effizient zu erledigen
Dialoge sollten nur sachdienliche Informationen enthaltenVermeidung von Ablenkungen
weniger ist mehr (Funktionen)den Bildschirm nicht uberfullenvermeide es, Befehle redundant anzubietenkeine unnotigen Dialoge und Popups
Optimieren von haufigen Aufgabenkleine Anzahl von benotigten Schritten; Anzahl
”Klicks“ klein halten
große Knopfe fur Hauptbefehle, Tastaturkurzeldie haufigsten Funktionen auf dem ersten Bildschirmwichtige Befehle → hervorstehende Stelleweniger haufig benutzte Befehle → weniger hervorstehende Stelle(Untermenu, Einstellungsdialog)
20
09
-02
-09
Software-Projekt
Entwurf von Benutzungsschnittstellen
Software-ergonomische Richtlinien
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Weitere Qualitatsaspekte
• Fehler verringern
• Sicherheit erhohen
• Zuverlassigkeit erhohen
• Lernanforderungen verringern
• Wartbarkeit verbessern
• Wirksamkeit erhohen
• Produktivitat erhohen
• Arbeitsumgebung verbessern
• Ermudung verringern
• Langeweile und Eintonigkeit verringern
• Zugang zur Anwendung erleichtern
• Akzeptanz verbessern
• Arbeitszufriedenheit steigern
• Tatigkeitserweiterung ermoglichen
• Lebensqualitat verbessern
• . . .
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Selbstbeschreibungsfahigkeit: jeder einzelne Dialogschritt ist durchRuckmeldung unmittelbar verstandlich bzw. eine Erklarung ist auf Anfrageverfugbar
verstandliche Benennung von Feldern
Online-Hilfe
Erlauterung der Konsequenzen des nachsten Schritts
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 313 / 634
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Erwartungskonformitat: Dialog ist konsistent und entspricht denMerkmalen des Benutzers (z.B. Kenntnisse aus dem Arbeitsgebiet,Ausbildung u. Erfahrung sowie allgemeinen Konventionen)
vorhersagbares Verhalten
passende Ruckmeldung in angemessener Zeit
Konsistenz von Benutzeraktionen, Prasentation, Anordnung vonElementen, Text
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 314 / 634
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowieseine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist
erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oderzur Startseite zuruckzukommen
benutze modale Formulare sparsam
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 315 / 634
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Steuerbarkeit: Benutzer ist in der Lage, den Dialogablauf zu starten sowieseine Richtung und Geschwindigkeit zu beeinflussen, bis Ziel erreicht ist
erlaube es dem Benutzer, jederzeit die Anwendung zu verlassen oderzur Startseite zuruckzukommen
benutze modale Formulare sparsam
20
09
-02
-09
Software-Projekt
Entwurf von Benutzungsschnittstellen
Software-ergonomische Richtlinien
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Modaler Dialog: ein Dialog, der geschlossen werden muss, bevor weitere Aktionen anderer Dialoge durchgefuhrtwerden konnen. Beispiel: Datei-Offnen-Dialog.
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Fehlertoleranz: Ziel kann trotz erkennbarer fehlerhafter Eingabe mitminimalem Korrekturaufwand durch den Benutzer erreicht werden
Hinweise sind sichtbar oder einfach erreichbar
aussagekraftige Fehlermeldungen mit Hinweisen
einfaches Wiederaufsetzen nach Fehlern, z.B. fehlerhafte Eingabe inTextfeld wird nicht einfach geloscht,
Fehler werden vor Eintreten verhindert
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 316 / 634
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Individualisierbarkeit: Anpassungen an Erfordernisse der Arbeitsaufgabe,individuelle Vorlieben des Benutzers und Benutzerfahigkeiten sind moglich
Sprache ist einstellbar
Zeichensatze/-große sind einstellbar
Farben sind einstellbar
eigene Tastaturbefehle fur erfahrene Benutzer
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 317 / 634
Entwurf von Benutzungsschnittstellen
Qualitatskriterien (EN ISO 9241-10:1995 1995)
Definition
Lernforderlichkeit: Benutzer wird beim Erlernen des Dialogsystemsunterstutzt und angeleitet
Guided Tour
Undo erlaubt gefahrlose Exploration
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 318 / 634
Entwurf von Benutzungsschnittstellen
Wegweiser
Usability messen und verbessern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 319 / 634
Entwurf von Benutzungsschnittstellen
Usability-Engineering
Iterative Verbesserung der Usability
1 Festlegen der Parameter
2 Bewerten des Systems
3 Verbessern des Systems
4 Wiederhole ab 2 solange, bis Qualitat akzeptabel
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 320 / 634
Entwurf von Benutzungsschnittstellen
Parameter fur Bestimmung der Usability
Beispiel Textverarbeitung:
Ziel: Erstellen eines Textdokuments nach einer Papiervorlage
Aufgaben: Eingeben des TextesFormatierenEinfugen eines BildesRechtschreibung uberprufen. . .
Benutzer: wenig Vorkenntnisse uber Computerbenutzung imAllgemeinen und Textverarbeitung im Speziellen
Umgebung: Buroumgebung mit erheblichem Zeitdruck
Meßgroßen: Zeitaufwand, Unterschiede im Text (mit Gewichtung) undUnterschiede im Layout und Stil (auch mit Gewichtung)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 321 / 634
Entwurf von Benutzungsschnittstellen
Evaluationsverfahren
Wie kann man Usability messen?
objektiv versus subjektiv
Fakten versus Grunde
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 322 / 634
Entwurf von Benutzungsschnittstellen
Subjektive Messungen
Benutzerbefragung (Fragebogen oder Interviews)
subjektivbreit anwendbar und statistisch auswertbarStandardfragebogen existieren (z.B. ErgoNorm, SUMI, QUIS, PUTQ)
Experten-Reviews
Checklisten fur NormkonformitatHeuristiken
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 323 / 634
Entwurf von Benutzungsschnittstellen
Objektive Messungen
Evaluation eines Modells
direkte Beobachtung der Benutzer
Labor oder echte ArbeitsumgebungAufzeichnung: Video, Audio (Think-Aloud), Eye-Tracking
indirekte Beobachtung: Mitschnitte von Aktionen (z.B. Web-Logs)
breiter anwendbarviel Fakten, wenig Hinweise auf Grunde
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 324 / 634
Entwurf von Benutzungsschnittstellen
A-Posteriori Messungen
Messungen nach Auslieferung im Einsatz:
Anzahl der Hotline-Anrufe
Verkaufsrate
siehe oben
Speziell furs Web:
Traffic / Netzaufkommen
Besucherzahl
Anteil der Besucher, die zum Kauf eines Produkts animiert werdenkonnten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 325 / 634
Entwurf von Benutzungsschnittstellen
Zusammenfassung
entwickle fur den Benutzer
entwickle mit dem Benutzer
Usability ist entscheidend fur den Erfolg des Produktes
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 327 / 634
Entwurf von Benutzungsschnittstellen
Wiederholungsfragen
Wie kann Usability verbessert werden?
Wie lasst sich Usability messen?
Was sind die Qualitatskriterien von Benutzungsschnittstellen nach ENISO 9241-10:1995 (1995)? Erlautern Sie die Aspekte anhand eineskonkreten Szenarios.
Wie haben Sie diese konkret in Ihrem Projekt umgesetzt?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 328 / 634
Software-Architektur
Software-Architektur
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragen
8 Software-ArchitekturWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 329 / 634
Software-Architektur
Lernziele
Verstehen, was Software-Architektur ist
Verschiedene Architektursichten kennen
Qualitaten einer Architektur kennen
Eine angemessene Software-Architektur entwerfen konnen
Die Anderbarkeit einer Software-Architektur bewerten konnen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 330 / 634
Software-Architektur
Kontext
Implemen−tierung
Test
Wartung& Evolution
Architektur
Datenstrukturen
und Algorithmen
AnalyseEntwurf
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 331 / 634
Software-Architektur
Client-Server-Architektur: Dynamische Sicht
queries
queries
queries
: Shop Server
1 : PDA Client
2 : PDA Client
n : PDA Client
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 336 / 634
Software-Architektur
Client-Server-Architektur: Statische Sicht
PDA Client Shop Server
Network
send receive
<<call>> <<call>>
Stereotyp
Schnittstelle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 337 / 634
Software-Architektur
Was ist Architektur?
Architecture is the human organization of empty space usingraw material.
Richard Hooker, 1996.
Definition
Software-Architektur ist die grundlegende Organisation eines Systemsverkorpert (IEEE P1471 2002)
in seinen Komponenten,
deren Beziehungen untereinander und zu der Umgebung
und die Prinzipien, die den Entwurf und die Evolution leiten.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 338 / 634
Software-Architektur
Bedeutung von Software-Architektur
Kommunikation zwischen allen Interessenten
hoher Abstraktionsgrad, der von vielen verstanden werden kann
Fruhe Entwurfsentscheidungen
→ nachhaltige Auswirkungen→ fruhzeitige Analyse
Transferierbare Abstraktion des Systems
→ eigenstandig wiederverwendbar→ unterstutzt Wiederverwendung im großen Stil (Software-Produktlinien)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 339 / 634
Bedeutung von Software-Architektur
Kommunikation zwischen allen Interessenten
hoher Abstraktionsgrad, der von vielen verstanden werden kann
Fruhe Entwurfsentscheidungen
→ nachhaltige Auswirkungen→ fruhzeitige Analyse
Transferierbare Abstraktion des Systems
→ eigenstandig wiederverwendbar→ unterstutzt Wiederverwendung im großen Stil (Software-Produktlinien)
20
09
-02
-09
Software-Projekt
Software-Architektur
Was ist Software-Architektur?
Bedeutung von Software-Architektur
Die Softwarearchitektur reprasentiert hohe Abstraktion eines Systems, die von den meisten Interessentenverstanden werden kann und damit eine Grundlage zum gegenseitigen Verstandnis, zur Konsensbildung und zurKommunikation darstellt.Die Softwarearchitektur ist die Manifestation fruher Entwurfsentscheidungen; diese fruhe Fixierung kannnachhaltige Auswirkungen haben auf die nachfolgende Entwicklung, Auslieferung sowie Wartung und Evolution. SAist auch die fruheste Systembeschreibung, die analysiert werden kann.Die Softwarearchitektur konstitutiert ein relativ kleines intellektuell fassbares Modell daruber, wie das Systemstruktiert ist und wie seine Komponenten zusammenwirken; dieses Modell ist eigenstandig nutzbar und kann uberdas spezifische System hinaus transferiert werden; insbesondere kann es fur Systeme mit ahnlichen Eigenschaftenund Anforderungen wiederverwendet werden, um so Wiederverwendung im großen Stil zu unterstutzen (Stichwort:Software-Produktlinien).
Software-Architektur
Beispielsystem IS2000 (Hofmeister u. a. 2000)
User ControlPanel
Remote ImagingComputers
ImagingComputer
Probe
Network
IS2000
������
������
�����������������������������������������
���������������
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 340 / 634
Software-Architektur
Einflussfaktoren/Anliegen (Concerns)
Einflussfaktoren
Produktfunktionen und -attribute
z.B. Performanz, Anspruche an Zuverlassigkeit, Umfang und Stabilitatder Anforderungen
Organisation
z.B. Budget, verfugbare Zeit, Team-Große und -erfahrung
Technologie
z.B. verfugbare Hard- und Software
Keiner der Faktoren kann isoliert behandelt werden → globale Analyse.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 341 / 634
Software-Architektur
Einflussfaktoren
Anmerkung
Ein Faktor ist nur dann relevant, wenn er Einfluss auf die Architektur hat.Test:
Architektur A1 ergibt sich mit Betrachtung des Faktors
Architektur A2 ergibt sich ohne Betrachtung des Faktors
Nur wenn A1 und A2 sich unterscheiden, ist der Faktor relevant.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 342 / 634
Software-Architektur
Globale Analyse
1. Identifiziere und beschreibe Faktoren2. Charaktersiere ihre Flexibilität und Änderbarkeit3. Analysiere ihre Auswirkungen
Analysiere Faktoren
Entwickle Strategien1. Identifiziere Probleme und Einflussfaktoren
3. Identifiziere verwandte Strategien2. Entwickle Lösungen und spezifische Strategien
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Einfluss
Rückkopplung
neue Problemeoder Strategien
Problem−karten
Faktortabelle neue Faktoren
BlickwinkelGlobale Analyse
neue Faktoren
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 343 / 634
Software-Architektur
Globale Analyse: Analysiere Faktoren
1. Identifiziere und beschreibe Faktoren
Faktoren, die viele Komponenten betreffen
Faktoren, die sich uber die Zeit andern
Faktoren, die schwer zu erfullen sind
Faktoren, mit denen man wenig Erfahrung hat
Beispiele:
Umfang funktionaler Anforderungen
Abgabetermin
Stabilitat der Hardware-Plattform
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 344 / 634
Software-Architektur
Globale Analyse: Analysiere Faktoren
2.a Charakterisiere ihre Flexibilitat
Flexibilitat
Kann zu Beginn uber Faktoren verhandelt werden mit Beteiligten(Manager, Marketingleute, Kunde, Benutzer etc.)?
Relevante Fragen zur Flexibilitat (am Beispiel Auslieferung derFunktionalitat):
Kann der Faktor beeinflusst oder geandert werden, so dass derArchitekturentwurf vereinfacht werden kann?
Auslieferung der Funktionalitat ist verhandelbar. Weniger wichtigeFunktionalitat kann in spaterem Release ausgeliefert werden.
Wie kann man ihn beeinflussen?
Nur nach rechtzeitiger Absprache mit dem Kunden.
Zu welchem Grad kann man ihn beeinflussen?
Der Kunde hat Mindestanforderungen, die erfullt werden mussen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 345 / 634
Software-Architektur
Globale Analyse: Analysiere Faktoren
2.b Charakterisiere ihre Veranderlichkeit
Veranderlichkeit
Kann sich der Faktor wahrend der Entwicklung andern?
Relevante Fragen (am Beispiel Auslieferung der Funktionalitat):
In welcher Weise kann sich der Faktor andern?Prioritaten konnten sich andern.Anforderungen konnten wegfallen, weil nicht mehr relevant.Anforderungen konnten hinzukommen, weil sich Rahmenbedingungengeandert haben.
Wie wahrscheinlich ist die Anderung wahrend und nach derEntwicklung?
Moderat wahrend der Entwicklung; sehr hoch danach.
Wie oft wird er sich andern?Alle 3 Monate.
Wird der Faktor betroffen von Anderungen anderer Faktoren?Anderung technologischer Aspekte (Software-/Hardware-Plattform).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 346 / 634
Software-Architektur
Globale Analyse: Analysiere Faktoren
3. Analysiere die Auswirkungen der Anderung von Faktoren auf Architektur
Auswirkungen
Wenn sich der Faktor andert, was wurde davon betroffen und wie?
Auswirkungen auf:
Andere Faktoren
Z.B. moderater Einfluss auf Einhaltung des Zeitplans und damit darauf,was zu welchem Zeitpunkt ausgeliefert werden kann
Systemkomponenten
Z.B. geplante Komponenten mussen uberarbeitet werden;Komponenten konnen hinzu kommen oder wegfallen.
Operationsmodi des Systems
Andere Entwurfsentscheidungen
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 347 / 634
Software-Architektur
Faktortabelle zu organisatorischen Aspekten
Faktor Flexibilitat undVeranderlichkeit
Auswirkung
O1 : EntwicklungsplanO1.1 : Time-To-Market
AuslieferungJuli 2009
Keine Flexibilitat Nicht alle Funktionen konnenimplementiert werden
O1.2 : Auslieferung von Produktfunktionen
priorisierteFunktionen
Funktionen sind verhandelbar Die Reihenfolge bei derImplementierung derFunktionen kann sich andern
O2 : EnwicklungsbudgetO2.1 : Anzahl Entwickler
5 Entwick-ler
Keine neuen Entwicklerkonnen eingestellt werden.Entwickler konnen (temporar)ausfallen.
Moderater Einfluss aufZeitplan; partielleImplementierung droht
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 348 / 634
Software-Architektur
Weitere organisatorische Beispielfaktoren I
O1: Management
Selbst herstellen versus kaufen
Zeitplan versus Funktionsumfang
Umgebung
Geschaftsziele
O2: Personal: Fahigkeiten, Interessen, Starken, Schwachen
Anwendungsdomane
Softwareentwurf
Spezielle Implementierungstechniken
Spezielle Analysetechniken
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 349 / 634
Software-Architektur
Weitere organisatorische Beispielfaktoren II
O3: Prozess und Entwicklungsumgebung
Entwicklungsplattform
Entwicklungsprozess und -werkzeuge
Prozesse und Werkzeuge des Konfigurationsmanagements
Produktionsprozesse und -werkzeuge
Testprozesse und -werkzeuge
Releaseprozesse und -werkzeuge
O4: Entwicklungszeitplan
Time-To-Market
Auslieferung der Produktfunktionen
Release-Zeitplan
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 350 / 634
Software-Architektur
Weitere organisatorische Beispielfaktoren III
O5: Entwicklungsbudget
Anzahl Entwickler
Kosten von Entwicklungswerkzeugen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 351 / 634
Software-Architektur
Faktortabelle zu technischen Aspekten
Faktor Flexibilitat undVeranderlichkeit
Auswirkung
T2 : Domanenspezifische HardwareT2.1 : Aufzeichungs-Hardware
Nimmt Signal auf. Neuere Versionen alle 3Jahre.
Großer Einfluss aufAufzeichnungs- undBildverarbeitungskom-ponenten
T2.2 : Netzwerk
Kommunikationzwischen Aufzeichnungund allgemeinerHardware
Neuere Versionen alle 4Jahre
Großer Einfluss aufAufzeichnungs- undBildverarbeitungskom-ponenten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 352 / 634
Software-Architektur
Technische Beispielfaktoren I
T1: Hardware
Prozessoren
Netzwerk
Hauptspeicher
Plattenspeicher
domanenspezifische Hardware
T2: Software
Betriebssystem
Benutzerschnittstelle
Software-Komponenten
Implementierungssprache
Entwurfsmuster
Rahmenwerke
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 353 / 634
Software-Architektur
Technische Beispielfaktoren II
T3: Architekturtechnologie
Architekturstile/-muster und -rahmenwerke
Domanenspezifische Architekturen oder Referenzarchitekturen
Architekturbeschreibungssprachen
Software-Produktlinien-Technologien
Werkzeuge zur Analyse und Validierung von Architekturen
T4: Standards
Schnittstelle zum Betriebssystem (z.B. Posix)
Datenbanken (z.B. SQL)
Datenformate
Kommunikation (z.B. TCP/IP)
Kodierrichtlinien
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 354 / 634
Software-Architektur
Faktortabelle zu Produktfaktoren
Faktor Flexibilitat undVeranderlichkeit
Auswirkung
P3 : Funktionale EigenschaftenP3.2 : Performanz der Aufzeichnung
Performanz: Große undAnzahl von Bildern;Antwortszeit:Ein-Ausgabe-Deadlines
Etwas flexibel. Große Auswirkung aufalle Komponenten furAufzeichnung,Bildverarbeitung,Speicherung undBetrachtung;Auswirkung variiert mitPerformanztuning.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 355 / 634
Software-Architektur
Beispielproduktfaktoren I
P1: ProduktfunktionenP2: Benutzerschnittstelle
Interaktionsmodell
Funktionen der Benutzerschnittstelle
P3: Performanz
Ausfuhrungszeiten
Speicherbedarf
Dauer des Systemstarts und -endes
Wiederherstellungszeit nach Fehlern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 356 / 634
Software-Architektur
Beispielproduktfaktoren II
P4: Verlasslichkeit
Verfugbarkeit
Zuverlassigkeit
Sicherheit
P5: Fehlererkennung, -bericht, -behandlung
Fehlerklassifikation
Fehlerprotokollierung
Diagnostik
Wiederherstellung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 357 / 634
Software-Architektur
Beispielproduktfaktoren III
P6: Service
Service-Dienste (Konfigurations- und Wartungsdienste) fur denBetrieb des System
Installation und Aktualisierung
Test der Software
Wartung und Erweiterung der Systemimplementierung
P7: Produktkosten
Hardwarebudget
Softwarelizenzbudget (fur verwendete Software)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 358 / 634
Software-Architektur
Globale Analyse: Entwickle Strategien I
1. Identifiziere Probleme und deren EinflussfaktorenAnalysiere Faktorentabelle:
Grenzen oder Einschrankungen durch Faktoren
Unverruckbarer Abgabetermin erlaubt keinen vollen Funktionsumfang
Notwendigkeit, Auswirkung eines Faktors zu begrenzen
Entwurf muss Portierbarkeit vorsehen
Schwierigkeit, einen Produktfaktor zu erfullen
Speicher- und Prozessorbegrenzung erlaubt keine beliebig komplexenAlgorithmen
Notwendigkeit einer allgemeinen Losung zu globalen Anforderungenwie Fehlerbehandlung und Wiederaufsetzen nach Fehlern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 360 / 634
Software-Architektur
Globale Analyse: Entwickle Strategien II
2. Entwickle Losungen und spezifische Strategien. . . fur die Behandlung der Probleme, die sich implementieren lassen unddie notwendige Anderbarkeit unterstutzen.
Strategie muss konsistent sein zu:
Einflussfaktor,
dessen Veranderlichkeit
und dessen Interaktion mit anderen Faktoren.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 361 / 634
Software-Architektur
Globale Analyse: Entwickle Strategien III
2. Entwickle Losungen und spezifische Strategien
Ziele:
Reduzierung oder Kapselung des Faktoreinflusses
Reduzierung der Auswirkung einer Anderung des Faktors auf denEntwurf und andere Faktoren
Reduzierung oder Kapselung notwendiger Bereiche vonExpertenwissen oder -fahigkeiten
Reduzierung der Gesamtentwicklungsdauer und -kosten
3. Identifiziere verwandte Strategien
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 362 / 634
Software-Architektur
Globale Analyse: Entwickle Strategien IV
Problemkarten (Issue Cards) beschreiben Problem und passende Strategieneinmalig:
Name des Problems
Beschreibung des ProblemsEinflussfaktorenListe aller Einflussfaktoren
LosungDiskussion einer allgemeinen LosungStrategie: Name der Strategie AErlauterung der Strategie AStrategie: Name der Strategie BErlauterung der Strategie B. . .
Verwandte StrategienReferenzen zu verwandten Strategien.Diskussion, in welcher Weise sie verwandt sind.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 363 / 634
Software-Architektur
Beispiele
Ambitionierter Zeitplan
Abgabetermin ist fix, Ressourcen sind begrenzt. Moglicherweise konnennicht alle Produktfunktionen realisiert werden.EinflussfaktorenO1.1 : Time-To-MarketO1.2 : Auslieferung von ProduktfunktionenO2.1 : Anzahl Entwickler
Losung
Strategie: Schrittweiser AusbauSystem wird schrittweise ausgebaut. Anforderungen werden in der Rei-henfolge ihrer Prioritat realisiert.
Strategie: Einkaufen statt SelbstentwickelnEinbindung externer COTS-Komponenten.Strategie: WiederverwendungEinbindung interner wiederverwendbarer Komponenten.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 364 / 634
Software-Architektur
Anderungen in allgemeiner und domanenspezifischer Hardware
Regelmaßige Anderungen der Hardware; Software soll mit minimalenAufwand an Anderungen angepasst werden konnen.
EinflussfaktorenT1.1: Prozessoren werden leistungsfahiger.T2.1: Aufzeichnungs-Hardware andert sich alle drei JahreT2.2: Netzwerktechnologie andert sich alle vier Jahre
Losung
Strategie: Kapselung domanenspezifischer Hardware:Kapsle Details, die sich andern konnen.
Strategie: Kapselung allgemeiner Hardware:Kapsle Details, die sich andern konnen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 365 / 634
Software-Architektur
Betriebssystemanpassung
Weiterentwicklung des Betriebssystems (BS) und Wechsel auf ein neuesBS machen Anpassungen an betriebssystemspezifischen Komponentennotwendig. Fur die Wartung steht nur ein Entwickler zur Verfugung. DieAnpassungen mussen schnell vorgenommen werden.
EinflussfaktorenO1.1: Time-To-MarketO2.1: Anzahl EntwicklerT2.3: Betriebssystem
Losung
Strategie: Kapselung der BS-abhangigen AnteileBS-abhangige Anteile werden in Komponenten isoliert. Diese bilden einevirtuelle Maschine fur alle anderen Komponenten.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 366 / 634
Software-Architektur
Gebaudearchitektur
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 367 / 634
Gebaudearchitektur
20
09
-02
-09
Software-Projekt
Software-Architektur
Architektursichten und -blickwinkel
Gebaudearchitektur
In der Gebaudearchitektur ist es ublich, von einem zu bauenden Gebaude verschiedene Modelle zu erstellen, bevordas Gebaude tatsachlich gebaut wird. Teilweise werden die Modelle als Prototypen benutzt, um dem zukunftigenHausbesitzer einen Eindruck von der Asthetik oder Funktion zu vermitteln. Teilweise sind die Modelle Plane, wie esnachher tatsachlich werden soll. Es wird dabei stets eine Vielzahl unterschiedlicher Modelle erstellt, die jeweilsbestimmte Aspekte betonen und von anderen abstrahieren. Der Grund liegt daran, dass unterschiedliche Personen,die am Gebaudebau beteiligt sind, das Gebaude aus unterschiedlichen Perspektiven betrachten wollen. Der spatereBesitzer interessiert sich fur das Gesamterscheinungsbild, der Maurer fur den Gebauderahmen und der Elektriker furKabelschachte, Steckdosen, Schalter etc. Das Prinzip, Unterschiedliches auseinander zu halten, ist in derSoftwaretechnik als Separation of Concerns bekannt: die Trennung unterschiedlicher Belange. Dieses Prinzip wirdauch beim Softwarearchitekturentwurf angewandt. Man nennt diese unterschiedlichen Bauplane oft Sichten derArchitektur.Wahrend sich in der Gebaudearchitektur uber viele Jahre feste Normen zu Bauzeichnungen, das heißt,Architektursichten, etabliert haben, stehen wir in der Softwaretechnik noch ganz am Anfang einer Entwicklung hinzu normierten Architektursichten. Ein erster Meilenstand auf diesem Weg ist der IEEE-Standard IEEE P1471(2002) Recommended Practice for Architectural Description of Software-intensive Systems. Er stellt Richtlinien auf,wie man Sichten der Softwarearchitektur beschreiben soll. Da aber noch Uneinigkeit herrscht, welche Sichten derSoftwarearchitektur uberhaupt relevant sind, legt er uns nicht auf eine feste Menge solcher Sichten fest. Er gehtviel mehr einen indirekten Weg. Er uberlasst es uns, zu entscheiden, welche Sichten wir beschreiben wollen, fordertaber, dass fur alle unsere Sichten definiert ist, was sie bedeuten.
Software-Architektur
Architektursichten und -blickwinkel
Definition
Architektursicht (View): Reprasentation eines ganzen Systems aus derPerspektive einer koharenten Menge von Anliegen (IEEE P1471 2002).
Definition
Architekturblickwinkel (Viewpoint): Spezifikation der Regeln undKonventionen, um eine Architektursicht zu konstruieren und zubenutzen (IEEE P1471 2002).Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelleSichten entwickelt werden konnen, durch Festlegung von
Zweck,
adressierte Betrachter
und Techniken fur Erstellung, Gebrauch und Analyse.
Unterschiedliche Sichten helfen der Strukturierung: Separation ofConcerns.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 368 / 634
Architektursichten und -blickwinkel
Definition
Architektursicht (View): Reprasentation eines ganzen Systems aus derPerspektive einer koharenten Menge von Anliegen (IEEE P1471 2002).
Definition
Architekturblickwinkel (Viewpoint): Spezifikation der Regeln undKonventionen, um eine Architektursicht zu konstruieren und zubenutzen (IEEE P1471 2002).Ein Blickwinkel ist ein Muster oder eine Vorlage, von der aus individuelleSichten entwickelt werden konnen, durch Festlegung von
Zweck,
adressierte Betrachter
und Techniken fur Erstellung, Gebrauch und Analyse.
Unterschiedliche Sichten helfen der Strukturierung: Separation ofConcerns.
20
09
-02
-09
Software-Projekt
Software-Architektur
Architektursichten und -blickwinkel
Architektursichten und -blickwinkel
Dazu fuhrt der Standard eine Trennung von konkretem Inhalt und Bedeutung einer Sicht ein. Eine Architektursicht(im Englischen: View) ist die Reprasentation eines ganzen Systems aus der Perspektive einer koharenten Menge vonAnliegen (IEEE P1471 2002). Eine Architektursicht beschreibt also immer ein bestimmtes System, im Sinne derGebaudearchitektur ist das also zum Beispiel die Facadenansicht des neuen Burogebaudes in der Universitatsallee15. In der Software ist die Beschreibung der Klassen und ihrer Abhangigkeiten der Banksoftware PayMe der Version1.3 in Form eines Klassendiagramms eine Architektursicht. Damit man ein Klassendiagramme jedoch verstehenkann, muss beschrieben sein, welche Konstrukte in solch einem Diagramm auftauchen durfen, was sie bedeuten undwie sie kombiniert werden konnen. Wahrend das Klassendiagramm fur PayMe spezifisch und damit nur fur PayMerelevant ist, ist die Beschreibung, wie Klassendiagrammme an sich aussehen konnen und was sie bedeuten,ubergreifend gultig fur alle denkbaren Klassendiagramme unabhangig von den Systemen, die sie beschreiben.Fur die Beschreibung aller moglichen Klassendiagramme fuhrt der IEEE-Standard den BegriffArchitekturblickwinkel (im Englischen: Viewpoint) ein. Ein Architekturblickwinkel (Viewpoint) ist die Spezifikationder Regeln und Konventionen, um eine Architektursicht zu konstruieren und zu benutzen (IEEE P1471 2002). EinBlickwinkel ist ein Muster oder eine Vorlage, von der aus individuelle Sichten entwickelt werden konnen, durchFestlegung des Zwecks, der adressierten Betrachter und der Techniken fur die Erstellung, den Gebrauch und dieAnalyse aller Sichten, die durch den Blickwinkel spezifiziert werden.Diese Trennung zwischen Sicht und Blickwinkel ist der eigentlich bedeutende Beitrag des genannten Standards.Das heißt fur uns, wenn wir eine Architektur durch eine Sicht beschreiben wollen, mussen wir zunachst in Form desBlickwinkels die Bedeutung der Sicht spezifizieren.
Software-Architektur
Siemens-Blickwinkel (Hofmeister u. a. 2000)
Konzeptioneller Blickwinkel: beschreibt logische Struktur desSystems; abstrahiert weitgehend von technologischen Details
Modulblickwinkel: beschreibt die statische logische Struktur desSystems
Ausfuhrungsblickwinkel: beschreibt die dynamische logischeStruktur des Systems
Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des
Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien etc.)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 369 / 634
Siemens-Blickwinkel (Hofmeister u. a. 2000)
Konzeptioneller Blickwinkel: beschreibt logische Struktur desSystems; abstrahiert weitgehend von technologischen Details
Modulblickwinkel: beschreibt die statische logische Struktur desSystems
Ausfuhrungsblickwinkel: beschreibt die dynamische logischeStruktur des Systems
Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des
Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien etc.)
20
09
-02
-09
Software-Projekt
Software-Architektur
Architektursichten und -blickwinkel
Siemens-Blickwinkel (Hofmeister u. a. 2000)
In der Literatur wurden sehr viele unterschiedliche Blickwinkel zur Beschreibung von Softwarearchitekturvorgeschlagen. Zachman (1987); Sowa und Zachman (1992); Zachman (1999) war einer der ersten Autoren, derBlickwinkel vorgeschlagen hat. Er schlug vor, Informationssysteme durch 6× 6 verschiedene Blickwinkel zubeschreiben. Perry und Wolf (1992) haben mehrere Blickwinkel von Zachman zusammen gefasst und die Anzahlder Blickwinkel damit auf drei reduziert, die letzten Endes aber aquivalent sind und lediglich unterschiedlicheAspekte hervor heben. Von Kruchten (1995) stammen die 4+1-Blickwinkel. Dazu gehoren der logische Blickwinkel,der das System abstrakt und anwendungsnah beschreibt, der Prozessblickwinkel, der die dynamische Ausfuhrungbeschreibt sowie der statische Entwicklungsblickwinkel und der physikalische Blickwinkel, der das System in dieHardware einbettet. Diese vier Blickwinkel werden zusammen gehalten durch einen redundanten Blickwinkel, dermittels Anwendungsszenarien beschreibt, wie die vier anderen Blickwinkel zusammen spielen.Die unterschiedlichen Blickwinkel in der Literatur sind verwirrend, zumal sehr viele Blickwinkel unterschiedlicherAutoren sehr ahnlich sind. Etwas Ordnung hat hier das Buch von (Clements u. a. 2002) geschaffen, in demKategorien von Blickwinkeln beschrieben sind. Dieses Buch ist auch zu empfehlen fur die Frage, wie manSoftwarearchitektur dokumentiert.Immerhin ist festzuhalten, dass viele der Blickwinkel sich auch auf die vier Siemens-Blickwinkel abbilden lassen(Hofmeister u. a. 2000). Es scheint, als ob mindestens die folgenden Aspekte zur Beschreibung eines Systemsnotwendig sind, die durch die vier Siemens-Blickwinkel abgedeckt werden:
• Konzeptioneller Blickwinkel: beschreibt die logische Struktur des Systems. Er abstrahiert weitgehend vontechnologischen Details wie z.B. konkrete Technologien, mit denen das System implementiert wird. Dieser Blickwinkelist der Anwendungsdomane am nachsten.
• Modulblickwinkel: beschreibt die statische logische Struktur des Systems in Form von Modulen und ihrenAbhangigkeiten.
• Ausfuhrungsblickwinkel: beschreibt die dynamische logische Struktur des Systems, das heißt, die Ausfuhrung undEinbettung in die ausfuhrende Hardware.
• Code-Blickwinkel: beschreibt die”anfassbaren“ Elemente des Systems (Quelldateien, Bibliotheken, ausfuhrbare Dateien
etc.).
Die vier Siemens-Blickwinkel wurden durch Befragung praktizierender Softwarearchitekten bei Siemens ermittelt,haben also offenbar praktische Relevanz.
Software-Architektur
Siemens-Blickwinkel (Hofmeister u. a. 2000)
Modul−beschränkungen
ModuleSubsysteme
Schichten
neueModula−risierung
Änderungen
elementenan Laufzeit−
KonnektorenKonfiguration
Komponenten
KomponentenKonnektorenKonfiguration
Laufzeit−beschränk−ungen
neueModula−risierungLaufzeit−elemente
Modulblickwinkel
Code−Blickwinkel
Aus
führ
ungs
blic
kwin
kel
Konzeptioneller Blickwinkel
Software−Architektur
Einfluss
Rückkopplung
Module
Quell−Code
Har
dwar
e−A
rchi
tekt
ur
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 370 / 634
Siemens-Blickwinkel (Hofmeister u. a. 2000)
Modul−beschränkungen
ModuleSubsysteme
Schichten
neueModula−risierung
Änderungen
elementenan Laufzeit−
KonnektorenKonfiguration
Komponenten
KomponentenKonnektorenKonfiguration
Laufzeit−beschränk−ungen
neueModula−risierungLaufzeit−elemente
Modulblickwinkel
Code−Blickwinkel
Aus
führ
ungs
blic
kwin
kel
Konzeptioneller Blickwinkel
Software−Architektur
Einfluss
Rückkopplung
Module
Quell−Code
Har
dwar
e−A
rchi
tekt
ur
20
09
-02
-09
Software-Projekt
Software-Architektur
Architektursichten und -blickwinkel
Siemens-Blickwinkel (Hofmeister u. a. 2000)
In der Methode von Hofmeister u. a. (2000) sind diese vier Blickwinkel der Gegenstand des Entwurfes. DieSoftwarearchitektur wird entworfen, indem Sichten zu diesen vier Blickwinkeln erstellt werden.Wir werden im Folgenden naher auf diese Blickwinkel eingehen, indem wir sie im Kontext der Hofmeister-Methodebeschreiben.
Software-Architektur
− Ressourcenbudget
Globale Analyse− Faktoren− Strategien
globale Evaluation
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Modulblickwinkel
Code−Blickwinkel
Einfluss
RückkopplungQuell−Code
Konzeptioneller Blickwinkel
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
ur
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe
− Konfiguration− Konnektoren− Komponenten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 371 / 634
− Ressourcenbudget
Globale Analyse− Faktoren− Strategien
globale Evaluation
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Modulblickwinkel
Code−Blickwinkel
Einfluss
RückkopplungQuell−Code
Konzeptioneller Blickwinkel
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
ur
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe
− Konfiguration− Konnektoren− Komponenten
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Der Ausgangspunkt des Architekturentwurfes ist der konzeptionelle Blickwinkel. Mit Hilfe dieses Blickwinkels wirddie logische Struktur der angestrebten Architektur beschrieben. Ahnlich wie beim Datenbankentwurf, wo wirzunachst von einem konzeptionelle Schema ausgehen, das die Daten beschreibt so wie sie in derAnwendungsdomane sind. Es handelt sich noch nicht um den Entwurf einer konkreten Datenbank fur dasAnwendungsproblem, der ja letztlich stark von der verwendeten Technologie abhangt. In der Gebaudearchitekturgleicht der logische Blickwinkel, den ersten Skizzen, die der Architekt von dem spateren Haus macht. Dabei will erden Kopf noch frei haben von Detailentscheidungen, welche Heizung eingebaut wird etc.Ausgehend von der globalen Analyse der Einflussfaktoren, entwirft der Softwarearchitekt die Hauptkomponentenund -konnektoren des Systems. Eine Komponente ist eine Berechnungseinheit oder eine Einheit, die Datenspeichert. Dabei geht es nicht um einzelne Klassen oder gar spezifischen Algorithmen und Datenstrukturen,sondern um die grobe Verteilung der Zustandigkeiten in einem System auf großere Bausteine. Wie umfangreich soein Baustein ausfallt, hangt von der Große des Systems ab. Je großer das System, desto großer werden dieKomponenten initial ausfallen. Große Komponenten konnen dann spater verfeinert werden. Ein Beispiel fur eineKomponente in einem großeren System ist etwa eine Datenbank, in einer Client-Server-Architektur waren sowohlClient als auch Server erste Komponenten.Komponenten interagieren miteinander, um eine gemeinsame Aufgabe zu erfullen. Hierzu sind sie uber so genannteKonnektoren verbunden. Ein Konnektor stellt den Kontroll- und Datenfluss zwischen Komponenten dar. PrimitiveKonnektoren sind Methodenaufrufe, Parameterubergabe und Zugriffe auf Attribute. Komplexere Konnektoren sindbeispielsweise Mechanismen zur Interprozesskommunikation.Die Verbindung der Komponenten durch Konnektoren ergibt die Konfiguration. Ist eine Konfiguration entstanden,kann sie durch ein Review begutachtet werden. Ein Evaluationskriterium ist zum Beispiel, ob die Komponenten undKonnektoren alle geforderten Anwendungsfalle auch tatsachlich unterstutzen. Hierzu kann man auf dem Papieruberlegen, was die Komponenten und Konnektoren alles machen wurden fur jeden einzelnen Anwendungsfall.Abschließend werden noch die Ressourcen fur Komponenten und Konnektoren eingeplant, also wie viel Speicherund Rechenzeit Komponenten und Konnektoren zuerkannt bekommen.
Software-Architektur
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
ist der Anwendungsdomane am nachsten
Systemfunktionalitat wird abgebildet auf
Konzeptionelle Komponenten: rechenbetonte Elemente oderDatenhaltungKonnektoren: Kontroll- und Datenfluss zwischen konzeptionellenKomponenten
Engineering-Belange:
Wie erfullt das System seine Anforderungen?
Wie werden Commercial-off-the-Shelf-Components (COTS) in dasSystem integriert?
Wie wird domanenspezifische Soft- und Hardware einbezogen?
Wie kann die Auswirkung von Anforderungen oder derAnwendungsdomane minimiert werden?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 372 / 634
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
ist der Anwendungsdomane am nachsten
Systemfunktionalitat wird abgebildet auf
Konzeptionelle Komponenten: rechenbetonte Elemente oderDatenhaltungKonnektoren: Kontroll- und Datenfluss zwischen konzeptionellenKomponenten
Engineering-Belange:
Wie erfullt das System seine Anforderungen?
Wie werden Commercial-off-the-Shelf-Components (COTS) in dasSystem integriert?
Wie wird domanenspezifische Soft- und Hardware einbezogen?
Wie kann die Auswirkung von Anforderungen oder derAnwendungsdomane minimiert werden?
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
Wie gesagt, steckt hinter der Aufteilung in Blickwinkel das Prinzip der Trennung unterschiedlicher Belange. WelcheBelange adressiert der konzeptionelle Blickwinkel also? Es geht dabei um die folgenden Fragen:
• Wie erfullt das System seine Anforderungen?
• Wie werden Commercial-off-the-Shelf-Components (COTS) in das System integriert, falls dies geplant ist?
• Wie wird domanenspezifische Soft- und Hardware einbezogen?
• Wie kann die Auswirkung von Anforderungen oder der Anwendungsdomane minimiert werden? Idealerweise sollte mannur eine Komponente anfassen mussen, wenn sich eine neue Anforderung aus der Anwendungsdomane ergibt. Dazumuss man jedoch die moglichen Anderungen vorwegsehen und die Architektur entsprechend so entwerfen, dass es leichtfallen wird, die zukunftige Anforderung zu realisieren.
Software-Architektur
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
CComponent
CPort
Conceptual Configuration
CConnector
CRole
Protocolobeysobeys
cbindingcbinding
connection
11
* *
*
*
*
*
* *
* *
* *
1 1
0..1
0..1 0..1 0..1 0..10..1*
*
conjugate
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 373 / 634
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
CComponent
CPort
Conceptual Configuration
CConnector
CRole
Protocolobeysobeys
cbindingcbinding
connection
11
* *
*
*
*
*
* *
* *
* *
1 1
0..1
0..1 0..1 0..1 0..10..1*
*
conjugate
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
Nachdem wir nun die Rolle und den Zweck des konzeptionellen Blickwinkels kennen, betrachten wir naher, wie einekonzeptionelle Sicht aufgebaut sein kann. Wir wenden uns also der Frage zu, wie der logische Blickwinkel eigentlichaussieht.Wir haben bereits uber die prinzipiellen Modellierungselemente gesprochen: Komponenten, Konnektoren und dieArt und Weise, wie sie in einer Konfiguration angeordnet werden.Das folgende Diagramm in UML beschreibt den logischen Blickwinkel genauer:
CComponent
CPort
Conceptual Configuration
CConnector
CRole
Protocolobeysobeys
cbindingcbinding
connection
11
* *
*
*
*
*
* *
* *
* *
1 1
0..1
0..1 0..1 0..1 0..10..1*
*
conjugate
Wie wir sehen, besteht eine Konfiguration aus einer Menge von Komponenten und Konnektoren. SowohlKomponenten als auch Konnektoren konnen verfeinert werden, was die Komposition andeutet. Wenn eineKomponente verfeinert wird in Teilkomponenten, mussen diese selbstverstandlich auch uber Konnektoren wiederverbunden werden. Aus diesem Grunde ist auch die Komposition zwischen Konnektoren und Komponentenzwingend notwendig. Ahnliches gilt fur die Verfeinerung von Komponenten. Hiermit konnen wir beschreiben, wieein Konnektor durch Teilkomponenten und deren Konnektoren implementiert wird.
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
CComponent
CPort
Conceptual Configuration
CConnector
CRole
Protocolobeysobeys
cbindingcbinding
connection
11
* *
*
*
*
*
* *
* *
* *
1 1
0..1
0..1 0..1 0..1 0..10..1*
*
conjugate
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
Zur Verbindung von Komponenten und Konnektoren existieren entsprechende Beschreibungselemente: Anschlusse(Ports) und Rollen (Roles). Ein Anschluss (Port) ist ein Teil der Komponente. Das Pendant hierzu fur Konnektorenist die Rolle (Role). Wenn wir also beispielsweise eine Kommunikation zwischen einem Client und einem Serverbeschreiben wollen, dann werden diese zwei Komponenten uber einen Konnektor fur die Interprozesskommunikationverbunden, wie im oberen Teil der folgenden Grafik dargestellt:
Die Kommunikation dient dem Datenaustausch, deshalb wird hierfur ein Query-Konnektor verwendet, der fur
Anfragen an Server gedacht ist. UML-Stereotypen beschreiben die Diagrammelemente. Die Stereotypen
entstammen dem konzeptionellen Blickwinkel.
Software-Architektur
Komponenten und Konnektoren
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 374 / 634
Komponenten und Konnektoren
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Komponenten und Konnektoren
Eine solche Kommunikation ist im Falle einer Client-Server-Architektur asymmetrisch, das heißt, der Konnektorwird unterschiedlich benutzt von den Komponenten. Wahrend der Server am Konnektor auf eingehende Anfragenwartet und diese dann beantwortet, ergreift der Client die Initiative und schickt dem Server seine Anfragen. DerQuery-Konnektor fur die Interprozesskommunikation hat also eine Rolle fur den Client und eine fur den Server. DerTeil der Komponente, der die jeweilige Rolle, die durch einen Konnektor vorgegeben wird, anspricht ist der Port.Angenommen der Query-Konnektor wird durch spater durch Remote Method Invocation (RMI) in Javaimplementiert, dann kann man sich den Port konkret vorstellen als der Code in der Komponente, der denRMI-Aufruf absetzt.Konnektoren beschreiben Kontroll- und/oder Datenfluss. Man kann entweder auf die allgemeinen Data-beziehungsweise Control-Konnektoren zuruck greifen oder aber sich seine eigenen Konnektoren definieren. In derzweiten Zeile des Diagramms sehen wir zum Beispiel einen allgemeinen Data-Konnektor fur den Datenaustauschzwischen einem Produzenten und Konsumenten und in der dritten Zeile einen Control-Konnektor, der einenObserver benachrichtigt, wann immer sich eine observierte Komponenten in ihrem Zustand andert. Die letzte Zeilebeschreibt einen selbst definierten Konnektor fur den Datenaustausch uber eine Pipe, wie das zum Beispiel in Unixunterstutzt wird.Die Verbindung von Komponenten und Konnektoren ist bislang rein strukturell dargestellt. Das bisher Gesagtebeschreibt nur, dass Komponenten und Konnektoren interagieren, aber nicht wie. Wie eine Interaktion aussieht,wird durch ein Protokoll beschrieben, also etwa die Reihenfolge, in der Operationen ausgefuhrt werden. Der Porteiner Komponente hat ein Protokoll, ebenso erwartet der Konnektor fur eine Rolle eine vorgegebenVerwendungsweise, hat also auch ein Protokoll. Diese beiden Protokoll mussen selbstverstandlich kompatibel sein.Zu der Bedeutung und den Einschrankungen von cbinding kommen wir spater noch.
Software-Architektur
Strategie
Lege externe Schnittstellen fest.pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 376 / 634
Strategie
Lege externe Schnittstellen fest.
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Wir illustrieren nun an unserem laufenden Beispiel, wie die Hofmeister-Methode eine konzeptionellen Sicht entwirft.Ausgangspunkt sind die Strategien, die wir in der globalen Analyse aufgestellt haben, um mit Entwurfskonfliktenumzugehen. Sie werden nun eingesetzt.Wir beschreiben den Entwurfsprozess top-down, das heißt, wir beginnen im Folgenden mit dem System als einegroße Komponente und verfeinern sie weiter. Das ist ein gangiges Vorgehen. Sollen aber existierende Komponentenwiederverwendet werden, dann kombiniert man den Top-Down-Ansatz mit einem Bottom-Up-Vorgehen. Letzterergeht von den existierenden Komponenten aus und baut sie zu einem großeren Ganzen sukzessive zusammen. In derKombination entwirft man sowohl top-down als auch bottum-up und versucht, die beiden Entwurfsrichtungenaufeinander zuzufuhren. Beim reinen Top-Down-Vorgehen kann es dazu kommen, dass existierende Komponentennicht wiederverwendet werden, weil sie nicht das Gefuge passen; außerdem konnen redundante Komponentenentstehen. Erfahrene Architekten beherrschen beide Richtungen.
Strategie
Lege externe Schnittstellen fest.
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Wir beginnen hier also zunachst mit dem System als eine einzige Komponente. In der Anforderungsanalyse habenwir uns bereits damit auseinander gesetzt, welche Schnittstellen nach außen das System bieten muss. Diese werdennun eingezogen. Es ergibt sich das folgende Bild:
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Die schwarzen Kastchen am Rande der Komponente sind ihre Ports, das heißt, ihre Schnittstellen nach außen.
Software-Architektur
Strategie
Fuhre Komponenten fur Aufzeichnung, Bearbeitung und Export ein.
:Contr
ol
:Data
sender
receiv
er
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 377 / 634
Strategie
Fuhre Komponenten fur Aufzeichnung, Bearbeitung und Export ein.
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Nun fuhren wir Komponenten fur Aufzeichnung, Bearbeitung und Export ein. Diese Aufteilung folgt demEVA-Prinzip (Eingabe/Verarbeitung/Ausgabe) und stellt eine Umsetzung des Strategie Separation of Concern dar.Die inneren Komponenten werden uber innere Konnektoren verbunden. Hier gilt die Regel, dass eine Verbindungzwischen einem Port und einer Rolle nur moglich ist, wenn die zugehorigen Komponenten und Konnektoren imselben anderen Element (Komponente oder Konnektor) enthalten sind. Mit anderen Worten, die Verbindung kannkeine Abstraktionsebene durchqueren. Wir stellen fest, dass die Komponenten und Konnektoren wie gefordert Teilder selben Komponente sind. Damit ist das Diagramm in diesem Punkt wohlgeformt.
:Contr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Strategie
Fuhre Komponenten fur Aufzeichnung, Bearbeitung und Export ein.
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Wir erkennen des Weiteren eine Verbindung zwischen zwei Ports und zwar von den inneren Komponenten zu denPorts der umgebenden Komponente. Dies sind die so genannten CBindings, auf die wir bislang noch nichteingegangen sind. Sie dienen dazu, darzustellen wie die außeren Ports auf die inneren Ports beziehungsweise dieaußeren Rollen auf die inneren Rollen abgebildet werden, stellen also den Kontext der außeren Schnittstellen zuminneren Aufbau her. Hier ist die Regel, dass ein CBinding von einem inneren Ports nur zu einem Port derunmittelbar umschließenden Komponente verlaufen darf. Entsprechendes gilt fur ein CBinding zwischen Rollen. DasDiagramm halt sich auch an diese Regel.
Software-Architektur
Strategie
Kapselung domanenspezifischer Hardware.
:Contr
ols
ender
receiv
er
:Probe
Control
:DataCollection
:Contr
ol
:Data
sender
receiv
er
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 378 / 634
Strategie
Kapselung domanenspezifischer Hardware.
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Im nachsten Schritt wenden wir die Strategie der Kapselung domanenspezifischer Hardware an, damit wir vorAnderungen dieser Hardware weitgehend geschutzt sind. Dazu fuhren wir zwei weitere Teilkomponenten ein, dievon den Eigenschaften der Eingabe-Hardware abstrahieren, die sich andern konnen. Diese beiden Komponentenstellen Geratetreiber dar.
:Co
ntr
ols
en
de
rre
ce
ive
r:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Wir erkennen in diesem Diagramm, wie die Anschlussbindung der innersten Komponenten zu den außerstenSystemschnittstellen von IS2000 uber zwei Ebenen hinweg erfolgt.
Software-Architektur
Strategie
Entkopple Interaktionsmodell.
:Acquire
:Monitor
:Contr
ols
ender
receiv
er
:Probe
Control
:DataCollection
:Contr
ol
:Data
sender
receiv
er
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 379 / 634
Strategie
Entkopple Interaktionsmodell.
:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Um auch gefeit zu sein gegen Anderungen in der Art und Weise, wie mit dem Benutzer interaktiv kommuniziertwird, fuhren wir analog zu den Geratetreibern eigene Teilkomponenten ein, die von Eingabe beziehungsweiseAusgabe von und zum Benutzer abstrahieren. Wir wenden damit eine Strategie zur Entkopplung desInteraktionsmodells an.
:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
:Acquisition
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Software-Architektur
Strategie
Separiere nach Anliegen: Separation of Concern.
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
ender
receiv
er
:Probe
Control
:DataCollection
:Contr
ol
:Data
sender
receiv
er
source dest
:Exporting
:Imaging
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 380 / 634
Strategie
Separiere nach Anliegen: Separation of Concern.
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Die Trennung in der Komponente Acquisition in zwei Teilkomponenten fuhrt dazu, dass die verbleibendeFunktionalitat dieser Komponente, die weder hardware-spezifisch noch spezifisch fur das Interaktionsmodell ist, ineiner weiteren Komponente Aquisition-Management versammelt werden muss.
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Contr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
:Imaging
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Software-Architektur
Strategie
Separiere zeitkritische Komponenten.
:Data :Data :Data
:Contr
ol
source dest source dest
receiv
er
sender
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
ender
receiv
er
:Probe
Control
:DataCollection
:Contr
ol
:Data
sender
receiv
er
source dest
:Exporting
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 381 / 634
Strategie
Separiere zeitkritische Komponenten.
:Data :Data :Data
:Co
ntr
ol
source dest source dest
rece
ive
rse
nd
er
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
In analoger Weise mussen wir auch bei der Komponente Imaging so verfahren. Hier nehmen wir aber noch eineweitere Verfeinerung vor. Und zwar trennen wir Algorithmen mit Echtzeitanforderungen (also z.B. das komprimierteAbspeichern des aufgenommenen Bildes, damit kein Bild verloren geht) und weiterfuhrende Algorithmen ohneEchtzeitanforderungen (wie z.B. das Aufhellen dunkler Bilder). Auf diese Weise konnen die Algorithmen mitunterschiedlichen Prioritaten versehen und auch auf unterschiedlichen Prozessoren ausgefuhrt werden.
:Data :Data :Data
:Contr
ol
source dest source dest
rece
ive
rse
nd
er
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Contr
ol
:Data
se
nd
er
rece
ive
r
source dest
:Exporting
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Software-Architektur
Strategie
Kapselung domanenspezifischer Bild-Daten.
:Data
:Data
:Contr
ol
source dest
sender
receiv
er
source dest
:Exporting
:ImageCollection
:Comm
:Export
:Data :Data :Data
:Contr
ol
source dest source dest
receiv
er
sender
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
ender
receiv
er
:Probe
Control
:DataCollection
:Contr
ol
:Data
sender
receiv
er
source dest
pro
beC
om
mands
pro
beD
ata
userA
cqC
ontro
luserIm
ageE
xport
userA
cqD
ispla
y
networkAccess
:IS2000
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 382 / 634
Strategie
Kapselung domanenspezifischer Bild-Daten.
:Data
:Data
:Co
ntr
ol
source dest
se
nd
er
rece
ive
r
source dest
:Exporting
:ImageCollection
:Comm
:Export
:Data :Data :Data
:Co
ntr
ol
source dest source dest
rece
ive
rse
nd
er
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Schließlich verfeinern wir noch die Komponenten Exporting. Hier wollen wir den Aufwand fur den Export inunterschiedliche Bildformate minimieren. Wir wenden dazu eine Strategie an, die domanenspezifischer Bild-Datenkapselt. Wir wahlen hierfur eine interne Reprasentation unserer Bild-Daten in einer DatenhaltungskomponenteImage Collection. Fur den Export gibt es dann je eine Transformation des internen in das gewunschte Format. DieKomponente Export ubernimmt hierfur die notwendige Interaktion mit dem Benutzer. Außerdem konnen die Bilderauch noch uber ein Netzwerk verschickt werden. Diese Aufgabe ubernimmt die Komponente Comm.
:Data
:Data
:Contr
ol
source dest
se
nd
er
rece
ive
r
source dest
:Exporting
:ImageCollection
:Comm
:Export
:Data :Data :Data
:Contr
ol
source dest source dest
rece
ive
rse
nd
er
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Contr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Contr
ol
:Data
se
nd
er
rece
ive
r
source dest
pro
be
Co
mm
an
ds
pro
be
Da
tau
se
rAcq
Co
ntro
lu
se
rIma
ge
Exp
ort
use
rAcq
Dis
pla
y
networkAccess
:IS2000
Strategie
Kapselung domanenspezifischer Bild-Daten.
:Data
:Data
:Co
ntr
ol
source dest
se
nd
er
rece
ive
r
source dest
:Exporting
:ImageCollection
:Comm
:Export
:Data :Data :Data
:Co
ntr
ol
source dest source dest
rece
ive
rse
nd
er
source dest
:Imaging
:ImageProcessing
:PostProcessing
:Control :Control
senderreceiver receiver sender
:Acquisition
Management
:Acquisition:Acquire
:Monitor
:Co
ntr
ols
en
de
rre
ce
ive
r
:Probe
Control
:DataCollection
:Co
ntr
ol
:Data
se
nd
er
rece
ive
r
source dest
pro
beC
om
mands
pro
beD
ata
userA
cqC
on
trol
use
rImageE
xpo
rtuserA
cq
Dis
pla
y
networkAccess
:IS2000
20
09
-02
-09
Software-Projekt
Software-Architektur
Konzeptioneller Blickwinkel
Wir haben in diesem Abschnitt gesehen, wie man eine konzeptionelle Sicht sukzessive durch Anwendung dervorbereiteten Strategien verfeinert. Dabei sollte jede Anwendung einer Strategie unbedingt dokumentiert werden,damit die Entwurfsentscheidungen nachvollziehbar werden. Die Begrundungen fur bestimmteEntwurfsentscheidungen lassen sich namlich auch nicht durch Reverse-Engineering-Techniken, die allein vomQuellcode ausgehen, nicht wieder rekonstruieren. Der Quellcode ist die sicherste Beschreibung dafur, was dieSoftware macht. Er enthalt aber keinen Hinweis darauf, was er hatte machen sollen, warum er was macht undwarum er es gerade so macht.
Software-Architektur
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Code−Blickwinkel
Einfluss
RückkopplungQuell−Code
− Schnittstellen
Globale Analyse− Faktoren− Strategien
globale Evaluation
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
urModulblickwinkel
Konzeptioneller Blickwinkel
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe− Module− Schichten− Subsysteme
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 383 / 634
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Code−Blickwinkel
Einfluss
RückkopplungQuell−Code
− Schnittstellen
Globale Analyse− Faktoren− Strategien
globale Evaluation
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
urModulblickwinkel
Konzeptioneller Blickwinkel
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe− Module− Schichten− Subsysteme
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Im nachsten Schritt uberfuhren wir die konzeptionelle Sicht in die Modulsicht, die den statischen Aufbau desSystems beschreibt in Form von Modulen, Schnittstellen, Subsystemen und Schichten. Es ist gut moglich, dass sichbeim Entwurf der konzeptionellen Sicht, sich neue Aspekte ergeben haben, so dass wir die globale Analysegegebenfalls wiederholen, bevor wir uns an die zentrale Entwurfsaufgaben machen, die Module zu entwerfen. NachEntwurf der Module und ihre Anordnung in Schichten und Subsystemen, entwerfen wir abschließend derenSchnittstellen.In diesem Abschnitt vertiefen wir den Modulsichtentwurf. Es sei voraus geschickt, dass wir nicht streng sequentiellModulsicht, dann Ausfuhrungs- und dann Code-Sicht entwerfen. Vielmehr ist der Entwurfsprozess meist iterativ.
Software-Architektur
Modulblickwinkel
bildet Komponenten und Konnektoren auf Module, Schichten undSubsysteme ab
setzt konzeptionelle Losung mit aktuellen Softwareplattformen(Programmiersprachen, Bibliotheken) und Technologien um
beschreibt statische Aspekte
Engineering-Belange:
Wie wird das Produkt auf die Software-Plattform abgebildet?
Welche Softwaredienste werden benutzt und von wem?
Wie wird das Testen unterstutzt?
Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?
Wie kann die Wiederverwendung von Modulen maximiert werden?
Welche Techniken konnen eingesetzt werden, um Auswirkungen vonAnderungen zu minimieren.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 384 / 634
Modulblickwinkel
bildet Komponenten und Konnektoren auf Module, Schichten undSubsysteme ab
setzt konzeptionelle Losung mit aktuellen Softwareplattformen(Programmiersprachen, Bibliotheken) und Technologien um
beschreibt statische Aspekte
Engineering-Belange:
Wie wird das Produkt auf die Software-Plattform abgebildet?
Welche Softwaredienste werden benutzt und von wem?
Wie wird das Testen unterstutzt?
Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?
Wie kann die Wiederverwendung von Modulen maximiert werden?
Welche Techniken konnen eingesetzt werden, um Auswirkungen vonAnderungen zu minimieren.
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Modulblickwinkel
Beim Entwurf der Modulsicht bilden wir die Komponenten und Konnektoren der konzeptionellen Sicht auf Module,Schichten und Subsysteme ab. Hierzu setzen wir die konzeptionelle Losung mit der aktuellen Softwareplattforme(Programmiersprachen, Bibliotheken, Werkzeuge) und Technologien um. Dabei werden rein statische Aspektebeschrieben.Die Belange, die durch die statische Modulsicht adressiert werden sind die folgenden:
• Wie wird das Produkt auf die Software-Plattform abgebildet?
• Welche Softwaredienste werden benutzt und von wem?
• Wie wird das Testen unterstutzt?
• Wie konnen Abhangigkeiten zwischen Modulen minimiert werden?
• Wie kann die Wiederverwendung von Modulen maximiert werden?
• Welche Techniken konnen eingesetzt werden, um Auswirkungen von Anderungen zu minimieren.
Fur die Modulsichten interessieren sich Programmierer fur die Programmierung. Tester interessieren fur denBlackbox-Komponententest sowie den Integrationstest. Ein Projektleiter kann von der Modulsicht Gebrauchmachen, um festzulegen, welcher Entwickler welches Modul implementieren soll.
Software-Architektur
Modulblickwinkel (Hofmeister u. a. 2000)
Module (layer) A uses
Module
Interface
Layer
module (layer) B whenA requires an interfacethat B provides
Subsystem
use
0..1
require *
*
*
require
* provide
*
* * * * *
0..1
0..1
use *
* *
* assigned−to
*
cont
ain
provide
contain
0..1
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 385 / 634
Modulblickwinkel (Hofmeister u. a. 2000)
Module (layer) A uses
Module
Interface
Layer
module (layer) B whenA requires an interfacethat B provides
Subsystem
use
0..1
require *
*
*
require
* provide
*
* * * * *
0..1
0..1
use *
* *
* assigned−to
*
cont
ain
provide
contain
0..1
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Modulblickwinkel (Hofmeister u. a. 2000)
Der Modulblickwinkel wird durch das folgende UML-Diagramm beschrieben:
Module (layer) A uses
Module
Interface
Layer
module (layer) B whenA requires an interfacethat B provides
Subsystem
use
0..1
require *
*
*
require
* provide
*
* * * * *
0..1
0..1
use *
* *
* assigned−to
*
cont
ain
provide
contain
0..1
Ein Modul ist eine statische, austauschbare Gliederungseinheit mit einem bestimmten Zweck. Es kann in derBeschreibung durch Teilmodule verfeinert werden. Ein Modul hat zwei Kategorien von Schnittstellen: dieSchnittstellen, die es selbst anderen anbietet (provides) und jene, die es von anderen benotigt require). In denmeisten Programmiersprachen kann man nur die zur Verfugung gestellten Schnittstellen angeben, aber nicht jene,die das Modul voraussetzt. Wenn Module aber ausgetauscht werden und die Auswirkung von Anderungen analysiertwerden sollen, dann benotigt man auch Wissen daruber, welche Schnittstelle ein Modul voraussetzt.Module konnen zu Schichten angeordnet werden. Damit wird die Sichtbarkeit von Modulen festgelegt. Bei einemstrikten Schichtenmodell durfen Module einer Schicht nur auf Module der nachst tieferen Schicht zugreifen. Dieserhoht die Austauschbarkeit. Ein Schicht implementiert eine Art virtuelle Maschine. Auch Schichten haben beideArten von Schnittstellen und konnen wieder weiter in Teilschichten verfeinert werden.Schließlich konnen Module nochmal unabhangig von Schichten zu einem Subsystem zusammen gefasst werden. EinSubsystem ist eine weitere Gliederungseinheit, die orthogonal zu hierarchischen Modulen und zu Schichten ist. IhreDaseinberechtigung wird spater im Kontext des Code-Blickwinkels deutlicher.Ein Modul benutzt (use) ein anderes Modul beziehungsweise Schicht, wenn das Modul auf eine Schnittstellezugreift, das von dem anderen Modul beziehungsweise der Schicht zur Verfugung gestellt wird.Die use-Beziehung ist eine allgemeine Form von Abhangigkeit. Man kann unter ihr auch eine Vererbungsbeziehungsubsumieren. Die Unterklasse benutzt ihre Oberklasse dadurch, dass sie von ihr erbt.
Software-Architektur
Notation fur Module
<<Modul>>
A
+sichtbar
-unsichtbar
<<call>> <<Modul>>
B
+sichtbar
-unsichtbar
<<use>>
<<Modul>>
C
+sichtbar
-unsichtbar
<<call>>
Schnittstelle
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 386 / 634
Notation fur Module
<<Modul>>
A
+sichtbar
-unsichtbar
<<call>> <<Modul>>
B
+sichtbar
-unsichtbar
<<use>>
<<Modul>>
C
+sichtbar
-unsichtbar
<<call>>
Schnittstelle
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Notation fur Module
Module sind ein etwas allgemeineres Konzept als Klassen. Klassen sind ein Konzept einer Programmiersprache unddes objektorientierten Paradigmas. Module konnen aber in C auch durch Dateien implementiert werden. Oft werdensie durch mehrere Dateien oder Klassen implementiert. Insofern hat das Konzept Modul seine Berechtigung.Weil Module aber Klassen ahneln, kann man fur sie auch eine ahnliche Notation verwenden. Im folgendenDiagramm verwenden wir den Stereotyp Modul um zu kennzeichnen, dass die Klassenikone als Module zuinterpretieren sind.
<<Modul>>
A
+sichtbar
-unsichtbar
<<call>> <<Modul>>
B
+sichtbar
-unsichtbar
<<use>>
<<Modul>>
C
+sichtbar
-unsichtbar
<<call>>
Schnittstelle
Die UML-Notation fur sichtbare und unsichtbare Elemente konnen zur Spezifikation der provides-Schnittstelleverwendet werden. Alternativ kann man auch auf die UML-Darstellungen fur Schnittstellen zuruck greifen. DerLolipop an Modul B besagt, dass B eine Schnittstelle zur Verfugung stellt, von der Modul C abhangt.
Software-Architektur
Beispiel einer Modulsicht
<<module>>
Comm<<module>>
Remote Imaging
<<module>>
dispatcher
sender receiver
Network
<<Layer>>
<<module>>
forwarder
<<module>>
receiver
<<Layer>>TCP/IP
<<module>>
sockets
+socket()
+bind()
+listen()
+accept()
+recvmsg()
+sendmsg()
<<module>>
wrapper
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 388 / 634
Beispiel einer Modulsicht
<<module>>
Comm<<module>>
Remote Imaging
<<module>>
dispatcher
sender receiver
Network
<<Layer>>
<<module>>
forwarder
<<module>>
receiver
<<Layer>>TCP/IP
<<module>>
sockets
+socket()
+bind()
+listen()
+accept()
+recvmsg()
+sendmsg()
<<module>>
wrapper
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Beispiel einer Modulsicht
Als Beispiel fur eine Modulsicht verfeinern wir einen Aspekt der konzeptionellen Sicht unseres laufenden Beispielsder IS2000. Wir wenden uns hierzu der Komponente Comm der konzeptionellen Sicht zu. Ihre Aufgabe ist es, dieNetzwerkkommunikation zu realisieren.Das folgende Beispieldiagramm beschreibt diesen kleinen Ausschnitt:
<<module>>
Comm<<module>>
Remote Imaging
<<module>>
dispatcher
sender receiver
Network
<<Layer>>
<<module>>
forwarder
<<module>>
receiver
<<Layer>>TCP/IP
<<module>>
sockets
+socket()
+bind()
+listen()
+accept()
+recvmsg()
+sendmsg()
<<module>>
wrapper
Beispiel einer Modulsicht
<<module>>
Comm<<module>>
Remote Imaging
<<module>>
dispatcher
sender receiver
Network
<<Layer>>
<<module>>
forwarder
<<module>>
receiver
<<Layer>>TCP/IP
<<module>>
sockets
+socket()
+bind()
+listen()
+accept()
+recvmsg()
+sendmsg()
<<module>>
wrapper
20
09
-02
-09
Software-Projekt
Software-Architektur
Modulblickwinkel
Beispiel einer Modulsicht
Das Diagramm beschreibt, wie die Comm-Komponente den Netzwerkzugriff realisiert. Wir haben uns dazuentschlossen das Netzwerkprotokoll TCP/IP zu verwenden, um Daten uber das Internet auszutauschen. Da derDatentransfer zwischen einer heterogenen Rechnerlandschaft geschieht und deshalb Binardaten konvertiert werdenmussen, legen wir uber die TCP/IP-Schicht noch eine weitere Schicht, die das Ein- und Auspacken dertransferierten Daten vornimmt. Außerdem konnen wir auf diese Weise von TCP/IP abstrahieren und es bei Bedarfleicht gegen ein anderes Protokoll austauschen. Die Schicht Network wird sowohl von der IS2000 als auch vonanderen Prozessen, die auf entfernten Rechnern ausgefuhrt werden, verwendet (stellvertretend steht hierfur dasModule Remote Imaging). Die Schicht Network gliedert sich in ein Dispatcher-Modul, der die Verwaltung desSendens und Empfangens ubernimmt, und in ein Modul forwarder fur das Einpacken fur den Datenversand und einModul receiver fur das Entpacken der Daten. Letztere beiden Module mussen sich auf eine gemeinsameDatenreprasentation einigen. Aus diesem Grund sind sie dem selben Modul wrapper zugeordnet.Wir haben hier ein vergleichsweise kleines Detail der logischen Sicht auf Module abgebildet und bereits eineansehnliche Anzahl von Modulen erhalten. Das Beispiel sollte deutlich machen, dass wir fur die gesamtekonzeptionelle Sicht eine große Anzahl von Modulen erhalten werden. Damit wir uns in diesem Abbildungsprozessverlieren, haben wir glucklicherweise die konzeptionelle Sicht, die alles zusammen halt und an der wir unsorientieren konnen.
Software-Architektur
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Einfluss
RückkopplungQuell−Code
Code−Blickwinkel
Konzeptioneller Blickwinkel
Globale Analyse− Faktoren− Strategien
Har
dwar
e−A
rchi
tekt
ur
globale Evaluation
− Ressourcenzuweisung
Ausführungsblickwinkel
Modulblickwinkel
Zentrale Entwurfs−aufgabe− Laufzeitelemente− Kommunikationspfade− Ausführungskonfiguration
AbschließendeEntwurfsaufgabe
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 389 / 634
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Einfluss
RückkopplungQuell−Code
Code−Blickwinkel
Konzeptioneller Blickwinkel
Globale Analyse− Faktoren− Strategien
Har
dwar
e−A
rchi
tekt
ur
globale Evaluation
− Ressourcenzuweisung
Ausführungsblickwinkel
Modulblickwinkel
Zentrale Entwurfs−aufgabe− Laufzeitelemente− Kommunikationspfade− Ausführungskonfiguration
AbschließendeEntwurfsaufgabe
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Software ist primar Verhalten. Durch die Modulsicht wird aber nur der innere strukturelle Aufbau beschrieben. Imnachsten Schritt kummern wir uns um dynamische Aspekte, also Dinge, die zur Laufzeit relevant sind. Dazu bildenwir die Module auf Elemente der Ausfuhrungsplattform (sowohl Hardware als auch Software) ab. Dazu dient derAusfuhrungsblickwinkel.
Software-Architektur
Ausfuhrungsblickwinkel
beschreibt dynamische Aspekte
beschreibt, wie Module auf Elemente der Ausfuhrungs- undHardwareplattform abgebildet werden
definiert Laufzeitelemente und deren Attribute (Speicher- undZeitbedarf, Allokation auf Hardware)
Engineering-Belange:
Wie verlauft Kontroll- und Datenfluss zwischen Laufzeitkomponenten?
Wie kann Ressourcenverbrauch ausgewogen werden?
Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreichtwerden, ohne die Algorithmen unnotig zu verkomplizieren?
Wie konnen Auswirkungen von Anderungen in derAusfuhrungsplattform minimiert werden?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 390 / 634
Ausfuhrungsblickwinkel
beschreibt dynamische Aspekte
beschreibt, wie Module auf Elemente der Ausfuhrungs- undHardwareplattform abgebildet werden
definiert Laufzeitelemente und deren Attribute (Speicher- undZeitbedarf, Allokation auf Hardware)
Engineering-Belange:
Wie verlauft Kontroll- und Datenfluss zwischen Laufzeitkomponenten?
Wie kann Ressourcenverbrauch ausgewogen werden?
Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreichtwerden, ohne die Algorithmen unnotig zu verkomplizieren?
Wie konnen Auswirkungen von Anderungen in derAusfuhrungsplattform minimiert werden?
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Ausfuhrungsblickwinkel
Der Ausfuhrungsblickwinkel definiert die Laufzeitelemente und deren Attribute wie Speicher- und Zeitbedarf undAllokation auf Hardware. Wir beschreiben hierbei, welche Prozesse und Objekte existieren, wie sie miteinander zuAusfuhrungszeit kommunizieren und wie sie auf die ausfuhrende Hardware abgebildet werden.Die adressierten Belange des Ausfuhrungsblickwinkels sind damit:
• Wie verlauft der Kontroll- und Datenfluss zwischen den Laufzeitkomponenten (Prozesse, Objekte etc.)?
• Wie kann der Ressourcenverbrauch (Speicher, Rechenzeit etc.) ausgewogen werden?
• Wie konnen Nebenlaufigkeit, Replikation und Verteilung erreicht werden, ohne die Algorithmen unnotig zuverkomplizieren?
• Wie konnen Auswirkungen von Anderungen in der Ausfuhrungsplattform minimiert werden (also Anderungen derHardware)?
Software-Architektur
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
SoftwarePlatform
PlatformElement
PlatformResource
HardwareResource
CommunicationPath
RuntimeEntity
CommunicationMechanism
Module
*
* * *
consumeconsume
* contain
is a
communicate over
*
1
use mechanism
assigned to
* 2..*
1
*
assigned to
*
*
*
* 1
*
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 391 / 634
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
SoftwarePlatform
PlatformElement
PlatformResource
HardwareResource
CommunicationPath
RuntimeEntity
CommunicationMechanism
Module
*
* * *
consumeconsume
* contain
is a
communicate over
*
1
use mechanism
assigned to
* 2..*
1
*
assigned to
*
*
*
* 1
*
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Das folgende UML-Diagramm beschreibt den Ausfuhrungsblickwinkel:
SoftwarePlatform
PlatformElement
PlatformResource
HardwareResource
CommunicationPath
RuntimeEntity
CommunicationMechanism
Module
*
* * *
consumeconsume
* contain
is a
communicate over
*
1
use mechanism
assigned to
* 2..*
1
*
assigned to
*
*
*
* 1
*
Die Software-Plattform halt alle Aspekte der Ausfuhrung zusammen. Sie besteht zunachst aus Plattformelementen,dies sind Dinge, die zur Laufzeit angelegt werden und ausgefuhrt werden konnen (z.B. Prozesse; wir lernen weitereBeispiele weiter unten kennen).
Die Plattformelemente haben Instanzen, die Laufzeiteinheiten (Runtime Entity). Die Laufzeiteinheiten
kommunizieren uber Kommunikationspfade (Communication Path) mit einander. Mindestens zwei konkrete
Laufzeitinstanzen kommunizieren dabei. Die Kommunikationspfade verwenden hierzu einen
Kommunikationsmechanismus, wie beispielsweise eine Remote Method Invocation in Java oder eine
Corba-Interprozesskommunikation.
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
SoftwarePlatform
PlatformElement
PlatformResource
HardwareResource
CommunicationPath
RuntimeEntity
CommunicationMechanism
Module
*
* * *
consumeconsume
* contain
is a
communicate over
*
1
use mechanism
assigned to
* 2..*
1
*
assigned to
*
*
*
* 1
*
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Bei der Ausfuhrung konsumiert eine Laufzeiteinheit Laufzeitressourcen wie Speicher oder Rechenzeit.Auf der rechten Seite des Diagramms sehen wir die Einbettung in die Hardwareumgebung und in die statischeModulsicht. Module sind den Laufzeiteinheiten, die sie ausfuhren. Dabei kann ein Modul naturlich von vielenLaufzeiteinheiten verwendet werden. Durch diese Bezuge zur Modulsicht werden die beiden Sichten miteinanderverknupft.Die Plattformressourcen werden auf konkrete Hardware-Ressourcen abgebildet, die sie zur Verfugung stellen, wiebeispielsweise Prozessoren oder gemeinsamer Speicher.
Software-Architektur
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Platform Element
Thread
Process
Task
Socket
Queue
File
Shared Memory
Shared Library
DLL
...
Platform Resource
CPU Time
Address Space
Memory
Semaphore
Timer
...
Communication Mechanism
DCOM
IPC
RPC
...
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 392 / 634
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Platform Element
Thread
Process
Task
Socket
Queue
File
Shared Memory
Shared Library
DLL
...
Platform Resource
CPU Time
Address Space
Memory
Semaphore
Timer
...
Communication Mechanism
DCOM
IPC
RPC
...
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Die Konzepte des Ausfuhrungsblickwinkels sind noch relativ abstrakt. Die folgende Vererbungshierarchiekonkretisiert die Konzepte. Ein Plattformelement ist eine Softwareeinheit, die zur Laufzeit existiert. Dazu gehorenzum Beispiel Objekte als Instanzen von Klassen. Fur die Realisierung von paralleler Ausfuhrung haben wir Threads(als leichtgewichtige Prozesse mit gemeinsamem Speicher), Prozesse mit getrennten Speicher oder Tasks (alseigenes Sprachkonstrukt aus einer Programmiersprache). Diese Prozesse kommunizieren uber weiterePlattformelemente wie Sockets, Warteschlangen, Dateien oder geteiltem Speicher. Außerdem kann man Modulebundeln in dynamischen Bibliotheken und auf unterschiedlichen Rechnern installieren.
Platform Element
Thread
Process
Task
Socket
Queue
File
Shared Memory
Shared Library
DLL
...
Platform Resource
CPU Time
Address Space
Memory
Semaphore
Timer
...
Communication Mechanism
DCOM
IPC
RPC
...
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Platform Element
Thread
Process
Task
Socket
Queue
File
Shared Memory
Shared Library
DLL
...
Platform Resource
CPU Time
Address Space
Memory
Semaphore
Timer
...
Communication Mechanism
DCOM
IPC
RPC
...
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
Plattformressourcen sind Ressourcen, die uns von der Software- und Hardwareplattform zur Verfugung gestelltwerden, die von den Plattformelementen konsumiert werden, wahrend sie ihre Arbeit erledigen. Dazu gehohrenneben Speicher und CPU-Zeit Betriebsmittel fur die Synchronisation wie Semaphore oder Timer.Kommunikationsmechanismen schließlich dienen den Plattformelementen zum Nachrichtenaustausch. Unter demBetriebssystem Windows gibt es hierfur zum Beispiel DCOM. Plattformunabhangigere Mechanismen sind dieInterprozesskommunikation (IPC) oder der Remote Procedure Call (RPC), bei Java auch bekannt als RemoteMethod Invocation (RMI).
Software-Architektur
Beispiel einer Ausfuhrungssicht
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 393 / 634
Beispiel einer Ausfuhrungssicht
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Beispiel einer Ausfuhrungssicht
Fur Diagramme, die die Ausfuhrungssicht beschreiben, gibt keine Standardnotation. Die Diagrammart in der UML,die der Ausfuhrungssicht am nachsten kommt, ist das Deployment-Diagramm. Es zeigt aber nicht alle Aspekte, dieim Ausfuhrungsblickwinkel nach Hofmeister u. a. (2000) moglich sind. Hofmeister u. a. (2000) schlagen deshalbeine eigene Notation vor, die an das Deployment-Diagramm der UML angelehnt ist. Das folgende Diagramm ist einBeispiel hierfur:
Beispiel einer Ausfuhrungssicht
20
09
-02
-09
Software-Projekt
Software-Architektur
Ausfuhrungsblickwinkel
Beispiel einer Ausfuhrungssicht
Wir erkennen darin drei Rechnertypen, die als Quader dargestellt sind. In ihnen geschachtelt tauchen dreiProzesstypen, die mit dem Stereotyp process gekennzeichnet sind. Die Schachtelung druckt aus, dass dergeschachtelte Prozess auf dem jeweiligen Rechner ausgefuhrt wird. Die Module, die die Prozesse dabei ausfuhren,sind in den Prozessen geschachtelt. Die Kommunikationspfade werden als Assoziationen zwischen den Prozessendargestellt. Die Beschriftung der Assoziation gibt den Kommunikationsmechanismus wieder. Die Multiplizitaten anden Kommunikationspfaden gibt an, wie viele Prozess jeden Typs in der Kommunikation involviert sind. In unseremFall ist das je eine n:1-Beziehungen, das heißt, mehrere Shop-Assistents kommunizieren mit einem Shop-Server undmehrere Shop-Server kommunizieren mit einem Datenbank-Server.Wie viele Instanzen es von den Typen von Hardware-Ressourcen und Plattformelementen zur Laufzeit gibt, wirddurch die Zahl in den Kasten wieder gegeben. Den Ladenrechner und Datenbankrechner gibt es nur einmal, es kannaber beliebig viele PDAs geben. Auf jedem PDA wird nur ein Prozess vom Typ Personal Shop Assistent gestartet.Gleiches gilt fur den Datenbankrechner, auf dem nur eine Instanz des Prozesstyps Data Base Server existiert. UmAusfallsicherheit und Skalierbarkeit zu sichern, hat sich der Architekt entschlossen, auf dem Ladenrechner nInstanzen von Shop Server anzulegen.
Software-Architektur
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Einfluss
RückkopplungQuell−Code
− Build−Prozess− Konfigurations− management
Globale Analyse− Faktoren− Strategien
globale Evaluation
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
ur
Konzeptioneller Blickwinkel
Code−Blickwinkel
Modulblickwinkel
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe− Quellkomponenten
− Auslieferungskomp.− Zwischenprodukte
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 394 / 634
Produktfaktoren
Organisatorische,undtechnologische Faktoren,
Einfluss
RückkopplungQuell−Code
− Build−Prozess− Konfigurations− management
Globale Analyse− Faktoren− Strategien
globale Evaluation
Aus
führ
ungs
blic
kwin
kel
Har
dwar
e−A
rchi
tekt
ur
Konzeptioneller Blickwinkel
Code−Blickwinkel
Modulblickwinkel
AbschließendeEntwurfsaufgabe
Zentrale Entwurfs−aufgabe− Quellkomponenten
− Auslieferungskomp.− Zwischenprodukte
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Nachdem wir Modulsicht und Ausfuhrungssicht entworfen haben, planen wir die konkrete Implementierung.Elemente aus der Modulsicht und Ausfuhrungssicht sind abstrakte Konzepte, die dann in einerProgrammiersprachen realisiert werden mussen. Dies geschieht, indem Programmierer Dateien anlegen, in denender Implementierungscode (textuell oder graphisch) aufgefuhrt ist. Wir nennen dies die Quellkomponenten. Ausden Quellkomponenten werden dann moglicherweise uber Zwischenprodukte das erzeugt, was schließlich als Codean den Kunden ausgeliefert wird. Beispielsweise haben wir unser Programm in C geschrieben. Dann erzeugt derCompiler daraus als Zwischenprodukt Objektdateien und moglicherweise Bibliotheken. Daraus erzeugt der Linkerschließlich das ausfuhrbare Programm. Das ausfuhrbare Programm und alle dynamischen Bibliotheken stellen dieAusfuhrungskomponenten dar. Da Dateien meist die Einheit sind, in der Aufgaben an Programmierer verteiltwerden, und die meisten Versionskontrollsysteme nur ganze Dateien verwalten, bestimmt die Aufteilung in Dateiendie Aufgabenverteilung und das Konfigurationsmanagement. Außerdem kann der Build-Prozess unter Umstandenbei großen Systemen, die nicht selten in vielen unterschiedlichen Programmiersprachen geschrieben wird, sehrkomplex werden. Der Build-Prozess benotigt nicht selten viel Zeit selbst auf machtiger Hardware. Aus diesenGrunden sollte fur mittlere und große Systeme die Abbildung der abstrakten Konzepte aus der Modulsicht undAusfuhrungssicht auf “anfassbare” Dateien und auch der Build-Prozess geplant und dokumentiert werden. Dies istdie Aufgabe der Code-Sicht.Bevor wir die Code-Sicht entwerfen, ist es moglicherweise notwendig, die globale Analyse nochmals zu wiederholen,wenn sich durch den Entwurf der vorherigen Sichten Einflussfaktoren und Strategien geandert haben sollten.
Software-Architektur
Code-Blickwinkel
bildet Laufzeiteinheiten auf installierbare Objekte (ausfuhrbareDateien, dynamische Link-Bibliotheken etc.) ab
bildet Module auf Quellkomponenten (Dateien) ab
zeigt, wie die installierbaren Dateien aus den Quellkomponentengeneriert werden
Engineering-Belange:
Wie kann die Zeit und der Aufwand fur Produkt-Upgrades verringertwerden?
Wie sollen Produktversionen verwaltet werden?
Wie kann die Build-Zeit verringert werden?
Welche Werkzeuge werden in der Entwicklungsumgebung benotigt?
Wie wird Integration und Test unterstutzt?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 395 / 634
Code-Blickwinkel
bildet Laufzeiteinheiten auf installierbare Objekte (ausfuhrbareDateien, dynamische Link-Bibliotheken etc.) ab
bildet Module auf Quellkomponenten (Dateien) ab
zeigt, wie die installierbaren Dateien aus den Quellkomponentengeneriert werden
Engineering-Belange:
Wie kann die Zeit und der Aufwand fur Produkt-Upgrades verringertwerden?
Wie sollen Produktversionen verwaltet werden?
Wie kann die Build-Zeit verringert werden?
Welche Werkzeuge werden in der Entwicklungsumgebung benotigt?
Wie wird Integration und Test unterstutzt?
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel
Die Code-Sicht bildet die Laufzeiteinheiten auf installierbare Objekte (ausfuhrbare Dateien, dynamischeLink-Bibliotheken etc.) ab. Außerdem bildet sie Module auf Quellkomponenten (Dateien) ab und zeigt, wie dieinstallierbaren Dateien aus den Quellkomponenten generiert werden.Die Belange, die mit der Code-Sicht adressiert werden, sind wie folgt:
• Wie kann die Zeit und der Aufwand fur Produkt-Upgrades verringert werden? Dazu mussen wir wissen, welcheausgelieferten Einheiten wir erneuern mussen. Im schlimmsten Fall muss der Kunde alles neu installieren. Dies wollen wiraber vermeiden.
• Wie sollen Produktversionen verwaltet werden? Unter Umstanden mussen wir nachvollziehen konnen, welche einzelnenDateien fur die Installation bei einem bestimmten Kunden eingeflossen sind, um zum Beispiel Fehler zu diagnostizieren.Diese Information muss durch das Konfigurationsmanagement bereit gehalten werden.
• Wie kann die Build-Zeit verringert werden? Die Zeit fur die vollstandige Ubersetzung kann erheblich sein und damit dieEntwicklung stark hemmen. Bei großen Systemen kann es viele Stunden dauern, bis ein System vollstandig ubersetzt ist.Wir wollen deshalb die Abhangigkeiten zwischen den Dateien moglichst gering halten, um den Build-Prozess so kurz wiemoglich zu halten.
• Welche Werkzeuge werden in der Entwicklungsumgebung benotigt? In manchen Fallen konnen zum Beispiel Teile desCode automatisch generiert werden.
• Wie wird Integration und Test unterstutzt? Bei der inkrementellen Integration werden Systemteile sukzessivhinzugenommen und in ihrer Interaktion getestet. Dazu muss man den inneren Aufbau und die Abhangigkeiten aus derModulsicht kennen und wissen, welche Dateien dazu jeweils zu ubersetzen und zu testen sind.
Software-Architektur
Code-Blickwinkel (Hofmeister u. a. 2000)
RuntimeEntity
Interface
Module
Layer
SubsystemSoftwarePlatform
Executable ConfigurationDescriptionLibraryBinary
ComponentSource
Component
trace
trace
trace
trace
*
1 * 1 * * *
link
*
* 11 * *
0..1
0..1
0..1
0..1
*
*
* 1
*
*
*
*
*
*
* * * *
instantiate
link
compile
linkcompile
import
use at runtimegenerate
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 396 / 634
Code-Blickwinkel (Hofmeister u. a. 2000)
RuntimeEntity
Interface
Module
Layer
SubsystemSoftwarePlatform
Executable ConfigurationDescriptionLibraryBinary
ComponentSource
Component
trace
trace
trace
trace
*
1 * 1 * * *
link
*
* 11 * *
0..1
0..1
0..1
0..1
*
*
* 1
*
*
*
*
*
*
* * * *
instantiate
link
compile
linkcompile
import
use at runtimegenerate
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel (Hofmeister u. a. 2000)
Code-Sichten werden durch den folgenden Code-Blickwinkel beschrieben:
RuntimeEntity
Interface
Module
Layer
SubsystemSoftwarePlatform
Executable ConfigurationDescriptionLibraryBinary
ComponentSource
Component
trace
trace
trace
trace
*
1 * 1 * * *
link
*
* 11 * *
0..1
0..1
0..1
0..1
*
*
* 1
*
*
*
*
*
*
* * * *
instantiate
link
compile
linkcompile
import
use at runtimegenerate
Code-Blickwinkel (Hofmeister u. a. 2000)
RuntimeEntity
Interface
Module
Layer
SubsystemSoftwarePlatform
Executable ConfigurationDescriptionLibraryBinary
ComponentSource
Component
trace
trace
trace
trace
*
1 * 1 * * *
link
*
* 11 * *
0..1
0..1
0..1
0..1
*
*
* 1
*
*
*
*
*
*
* * * *
instantiate
link
compile
linkcompile
import
use at runtimegenerate
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel (Hofmeister u. a. 2000)
Alles, was fur die Konstruktion des Systems notwendig ist, wird versammelt unter der Software-Plattform (SoftwarePlatform). Dazu gehoren primar die Quell-Komponenten (Source Component), die die Module und Schnittstellenimplementieren. Das sind in Java beispielsweise die Java-Quelldateien. Sie hangen zum Teil von einander ab, indemsie sich importieren. In Java gibt es dafur die import-Anweisung. Außer reinen Code-Dateien betrachten wir auchzum Beispiel UML-Diagramme als Quell-Komponenten, wenn aus ihnen Quell-Code generiert wird. DieQuell-Komponenten werden bei kompilierten Sprachen von einem Compiler in eine Binarform ubersetzt. In Java istdas der Java-Bytecode. Die Binardateien werden in einem weiteren Schritt oft in statischen oder dynamischenBibliotheken zusammen gefasst. In Java sind das die JAR-Bibliotheken. Ein Linker linkt die Binardateien undBibliotheken schließlich zu einem ausfuhrbaren Programm. Das Linken kann auch erst zum Zeitpunkt desProgramms stattfinden, dann spricht man von einem dynamischen Linker. Die ausfuhrbaren Programme konnenhaufig durch Konfigurationsdateien (Configuration Description) zur Start- oder Laufzeit konfiguriert werden.Beispielsweise kann die Sprache, in der mit dem Anwender kommuniziert wird, bei internationalisiertenProgrammen eingestellt werden.Auf der linken Seite des Diagramms zum Code-Blickwinkel finden wir Elemente des statischen Modulblickwinkelsund des Ausfuhrungsblickwinkels. Auf diese Weise werden die verschiedenen Sichten miteinander verbunden.Zwischen Quell-Komponenten und Modulen und Schnittstellen haben wir eine trace-Beziehung. Sie beschreibt,welche Module durch welche Dateien implementiert werden, und ermoglicht damit die Nachvollziehbarkeit (imEnglischen: Traceability) zwischen unterschiedlichen Ebenen eines Systems. Schichten und Subsysteme sind meistkeiner einzelnen Quell-Komponente zuzuordnen. Vielmehr bilden wir sie ab auf die Software-Plattform. Eine Schichtoder ein Subsystem implementiert damit eine Software-Plattform.Die Programme erzeugen (instantiate) wahrend ihrer Ausfuhrung die Laufzeiteinheiten (Runtime Entity).
Software-Architektur
Code-Blickwinkel: Beispiel
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 397 / 634
Code-Blickwinkel: Beispiel
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel: Beispiel
Das folgende Diagramm ist ein Beispiel fur eine Code-Sicht:
Die Modul dispatcher wird durch die Datei dispatcher.java implementiert. Das Modul wrapper sowie seineDie Teilmodule forwarder und receiver werden durch die Dateien forwarder.java und receiver.java umgesetzt. Daszusammengesetzte Modul wrapper wird nicht unmittelbar durch eine Quell-Komponente implementiert. Vielmehrbesteht es aus den oben genannten Teilmodulen, die bestimmten Quell-Komponenten zugeordnet sind.Hierarchische Module werden als reine Gliederungseinheiten verwendet. Die Moduldekomposition ergibt einenBaum. Nur die Blatter dieses Baumes stellen Module dar, fur die auch Code geschrieben werden muss.Die aus den Java-Dateien generierten Class-Dateien werden in einer JAR-Bibliothek fur den Server abgelegt. BeiAusfuhrung der Bibliothek, indem die entsprechende main-Methode aktiviert wird, wird dann der Server-Prozesserzeugt.
Code-Blickwinkel: Beispiel
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel: Beispiel
Das Modell von Hofmeister ist sehr stark an herkommlichen Sprachen wie C oder C++ orientiert. Im Falle vonJava sind einige Spezialisierungen beziehungsweise Anpassungen sinnvoll.Eine Erleichterung in Java ist der Umstand, dass eine Class-Datei mit genau einer Java-Quelldatei korrespondiert(und umgekehrt; außer fur innere Klassen). Und die Package-Struktur korrespondiert mit der physischenDateisystem-Struktur.Die Bibliotheken in Java heißen JAR-Dateien (Java Archive; im Wesentlichen nichts anderes als ein Zip-Archiv mitJava-Class-Dateien). Die Class-Dateien werden nicht zu den Bibliotheken gelinkt, sondern lediglich hinzugefugt.Es gibt in Java eigentlich kein Exectuable wie bei C oder C++. Jede Klasse, die eine statische Methode main hat,kann zum Hauptprogramm werden. Enthalt eine JAR-Datei mindestens eine solche Klasse, kann sie als Executablebetrachtet werden. Eine JAR-Datei (oder auch eine Class-Datei) instantiates eine Runtime Entity, wenn ihr mainaufgerufen wird, oder wenn ein Thread aktiviert wird.
Software-Architektur
Code-Blickwinkel: Beispiel
Tabellendarstellung:
Module Source File JAR
dispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .
JAR instantiates
server.jar Shop Server. . . . . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 398 / 634
Code-Blickwinkel: Beispiel
Tabellendarstellung:
Module Source File JAR
dispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .
JAR instantiates
server.jar Shop Server. . . . . .
20
09
-02
-09
Software-Projekt
Software-Architektur
Code-Sicht
Code-Blickwinkel: Beispiel
In der Praxis wird man kaum fur die in der Code-Sicht auftretenden Relationen ein UML-Diagramm zeichnen, da esviel zu viele sind. Einfacher beschreibt man sie durch Tabellen, wie zum Beispiel:
Module Source File JARdispatcher dispatcher.java server.jarforwarder forwarder.java server.jarreceiver receiver.java server.jar. . . . . . . . .
JAR instantiatesserver.jar Shop Server. . . . . .
Wenn Namenskonventionen existieren (im Falle von Java heißt die Class-Datei, die zu einer Java-Dateimyfile.java gehort, schlicht myfile.class, wenn es sich nicht um eine innere Klasse handelt) mussen nicht alleRelationen durch Tabellen beschrieben werden.
Software-Architektur
Was ist Modularisierung?
Definition
Modularisierung: Dekomposition eines Systems in Module.Modul: austauschbares Programmteil, das eine geschlosseneFunktionseinheit bildet.Arbeitspaket: von einer Person oder einer kleinen Gruppe von Entwicklernentwerfbar, implementierbar, testbar, verstehbar, anderbar, . . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 399 / 634
Software-Architektur
Conways Gesetz:
Conways Gesetz:
Die Struktur der Software spiegelt die Struktur der Organisation wider.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 405 / 634
Software-Architektur
Schnittstellen
Definition
Schnittstelle (allgemein): Teil eines Systems, das dem Austausch vonInformationen, Energie oder Materie mit anderen Systemen dient.
– Wikipedia, die freie Enzyklopadie
Definition
Schnittstelle: Menge der Annahmen, die das Modul uber seine Umgebungmacht, sowie jene, die die Umgebung uber das Modul macht.
Definition
Syntaktische Schnittstelle: offentliche Attribute und Methoden mitderen Signaturen.
Zwei Module sind uber ihre Schnittstellen verbunden und damit abhangig.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 406 / 634
Software-Architektur
Ein Wort zu Schnittstellen
+ Draw()
Figure
Rectangle
+ Draw()
Circle
+ Draw()+ width+ height + radius
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 407 / 634
Software-Architektur
Eine offene Schnittstelle
a b s t r a c t c l a s s F i g u r e {
p u b l i c a b s t r a c t v o i d Draw ( ) ;}c l a s s C i r c l e e x t e n d s F i g u r e {
p u b l i c v o i d Draw ( ) {} ;p u b l i c i n t r a d i u s ;
}c l a s s R e c t a n g l e e x t e n d s F i g u r e {
p u b l i c v o i d Draw ( ) {} ;p u b l i c i n t h e i g h t ;p u b l i c i n t width ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 408 / 634
Software-Architektur
Geheimnisprinzip (Information Hiding) nach Parnas (1972)
Schnittstellen sind ein Kontrakt zwischen:
Verwender:
darf sich nur auf zugesicherte Annahmen verlassenmuss Vorbedingungen einhalten
Anbieter:
muss zugesichertes Verhalten implementierendarf sich nur auf zugesicherte Vorbedingungen verlassen
Der Kontrakt fuhrt zu einer Kopplung zwischen Verwender und Anbieter.
Schnittstellen werden so entworfen, dass
Kopplung auf das Mindestmaß beschrankt wird;
d.h. die Details, die sich andern konnen, werden hinter Schnittstelleverborgen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 409 / 634
Software-Architektur
Programmiersprachenunterstutzung
a b s t r a c t c l a s s F i g u r e {
p u b l i c a b s t r a c t v o i d Draw ( ) ;}c l a s s C i r c l e e x t e n d s F i g u r e {
p u b l i c v o i d Draw ( ) {} ;p r i v a t e i n t r a d i u s ;
}c l a s s R e c t a n g l e e x t e n d s F i g u r e {
p u b l i c v o i d Draw ( ) {} ;p r i v a t e i n t h e i g h t ;p r i v a t e i n t width ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 410 / 634
Software-Architektur
Verwender der Klasse
p u b l i c v o i d Drawing ( F i g u r e A Figure , i n t Times ) {
f o r ( i n t i = 0 ; i < Times ; i ++) {A F i g u r e . Draw ( ) ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 411 / 634
Software-Architektur
Klassendiagramm
Drawing+ Draw()
Figure
Rectangle
+ Draw()
Circle
+ Draw()
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 412 / 634
Software-Architektur
Klassendiagramm
Graphs
Node
+ Draw()
Edge
+ Draw()
Drawing+ Draw()
Figure
Rectangle
+ Draw()
Circle
+ Draw()
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 413 / 634
Software-Architektur
Klassendiagramm
Graphs
Node
+ Draw()
Edge
+ Draw()
Drawing
+ Draw()
Figure
Rectangle
+ Draw()
Circle
+ Draw()
Drawable
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 415 / 634
Software-Architektur
Schnittstelle als eigenes Sprachkonstrukt
Schnittstelle:
i n t e r f a c e Drawable {v o i d Draw ( ) ;
}
Schnittstellenverwender:
p u b l i c v o i d Drawing ( Drawable Drawab le Object , i n t Times ) {
f o r ( i n t i = 0 ; i < Times ; i ++) {D r a w a b l e O b j e c t . Draw ( ) ;
}}
Schnittstellenanbieter:
a b s t r a c t c l a s s F i g u r e implements Drawable {}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 416 / 634
Software-Architektur
Zusammenfassung zu Schnittstellen
Schnittstelle ist Kontrakt zwischen Anbieter und Verwender, der dieerlaubten wechselseitigen Annahmen festlegt
Programmiersprachen erlauben die Spezifikation syntaktischerEigenschaften von Schnittstellen
moderne Programmiersprachen bieten Schnittstellen als eigenesSprachkonstrukt an
nur wenige erlauben die Spezifikation semantischer Eigenschaften
Vor- und Nachbedingungenweitere Zusicherungen, wie z.B. Speicher- und Zeitkomplexitat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 417 / 634
Software-Architektur
Kopplung und Zusammenhalt
Definition
Kopplung: Grad der Abhangigkeit zwischen Modulen.
Definition
Zusammenhalt (Koharenz): Verwandtschaft der Teile eines Moduls.
Modul A Modul B
Modul A Modul B
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 418 / 634
Kopplung und Zusammenhalt
Definition
Kopplung: Grad der Abhangigkeit zwischen Modulen.
Definition
Zusammenhalt (Koharenz): Verwandtschaft der Teile eines Moduls.
Modul A Modul B
Modul A Modul B
20
09
-02
-09
Software-Projekt
Software-Architektur
Kopplung und Zusammenhalt
Kopplung und Zusammenhalt
Der Architekt eines Konzertsaals bemuht sich, den Saal so zu bauen, dass die akustische Storung von außen extremgering ist, die Horbarkeit im Saal dagegen extrem hoch. Dem entspricht bei der Arbeit des Software-Architekten dieGliederung in Module so, dass
• die Kopplung (d.h. die Breite und Komplexitat der Schnittstellen) zwischen den Modulen moglichst gering,
• der Zusammenhalt (d.h. die Verwandtschaft zwischen den Teilen eines Moduls) moglichst hoch wird.
Das Konzept von Kopplung und Zusammenhalt basiert ursprunglich auf den FORTRAN- und COBOL-Programmender fruhen 70‘er Jahre. Heute haben wir Sprachen, die uns mehrere Abstraktionsebenen bieten. Dabei streben wirauf der Modulebene vor allem niedrige Kopplung (bei maßigem Zusammenhalt), auf der Prozedurebene vor allemhohen Zusammenhalt (bei erheblicher Kopplung) an.
Software-Architektur
Stufen des Zusammenhalts (von schlecht nach gut)
Stufe innerhalb einer Funktion/Moduls betrifft
keinZusammenhalt
rein zufallige Zusammenstellung Module
Ahnlichkeit z.B. ahnlicher Zweck, also etwa alleMatrixoperationen; auchFehlerbehandlung
Module
zeitliche Nahe Verwendung zum selben Zeitpunkt,z.B. Initialisierung, Abschluss
Module,Funktionen
gemeinsameDaten
Zugriff auf bestimmte Daten,exklusiv, z.B. Kalenderpaket(Systemuhr)
Funktionen,Module
Hersteller /Verbraucher
ein Teil erzeugt, was der andereverwendet
Module,Funktionen
einziges Datum Kapselung einer Datenstruktur,Zusammenfassung der Operationen
Module,Funktionen
einzige Operation Operation, die nicht mehr zerlegbarist
Funktionen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 419 / 634
Software-Architektur
Stufen der Kopplung (von schlecht nach gut)
Stufe zwischen Funktionen/Modulen betrifft
Einbruch Veranderung des Codes Funktionen
volle Offnung Zugriff auf alle Daten, z.B. auf alleAttribute einer Klasse
(Module)Funktionen
selektiveOffnung
bestimmte Attribute sind zuganglich oderglobal durch expliziten Export/Import
Module,Funktionen
Funktions-kopplung
nur Funktionsaufruf und Parameter Module(Funktion)
keineKopplung
Es besteht keine logische Beziehung(Zugriff ist syntaktisch unmoglich)
Module
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 420 / 634
Software-Architektur
Kriterien fur einen guten Software-Entwurf
Jeder Entwurf ist ein Kompromiss.
Geringe Kopplung zwischen allen Modulen
Hoher Zusammenhalt in allen Funktionen und Modulen
Kriterium der naiven Suche: Jede Einheit sollte einen leichterkennbaren Sinn haben.
Abstraktion: Implementierungsdetails verbergen
Kapselung von Dingen, die sich andern konnen (Geheimnisprinzip;Information Hiding)
Etwa gleich große Einheiten (Module, Funktionen). Abweichungensollten plausibel sein; generell durfen einfache Objekte großer sein alskomplizierte.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 421 / 634
Software-Architektur
Kriterien fur einen guten Software-Entwurf (Forts.)
Uniforme Entwurfsstrategie; wenn z.B. eine Schichtenstruktur gewahltwurde, sollte sie nicht an irgendeiner Stelle korrumpiert sein.
Uniforme Gestaltung der Schnittstellen.
Uniforme Benennung.
Prinzip der Isomorphie zur Realitat (Michael Jackson11): Die Softwaresollte der Realitat strukturell gleichen, damit die Anderungen derRealitat in der Software leicht nachvollzogen werden konnen.
11Nein, nicht der Michael Jackson.Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 422 / 634
Software-Architektur
Bewertung von Modularisierung
Software Architecture Analysis Method (SAAM) (Kazman u. a. 1996):
1 Lege wichtige Qualitatsaspekte fest
2 Beschreibe alternative Modularisierungen
3 Entwickle Szenarien fur die Qualitatsaspekte
4 Spiele die Szenarien durch und bewerte die Modularisierungen
5 Betrachte Wechselwirkungen zwischen den Qualitatsaspekten
6 Fasse die Evaluation zusammen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 423 / 634
Software-Architektur
Beispiel: Key Word in Context (KWIC) (Parnas 1972)
Bistum Osnabrück
Friede von Osnabrück
Friede westfälischer
Osnabrück Bistum
vonOsnabrück Friede
Friedevon Osnabrück
westfälischer Friede
Zeilen
Sortierung der
westfälischer Friede
Friede westfälischer
Friede von Osnabrück
vonOsnabrück Friede
Friedevon Osnabrück
Bistum Osnabrück
Osnabrück Bistum
jeder Zeile
zyklische Vertauschung
von
Bistum Osnabrück
westfälischer Friede
OsnabrückFriede
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 426 / 634
Software-Architektur
Betrachtete Qualitatsaspekte und Szenarien
Anderbarkeit
Eingabeformat andert sichgroßere Dateien mussen verarbeitet werdenriesige Dateien mussen verarbeitet werden
separate Entwickelbarkeit
verteile Arbeit an Entwicklungsteams
Performanz
berechne KWIC fur FB3-Webseiten
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 427 / 634
Software-Architektur
Ablauf
1 Eingabe der Daten
2 Interne Speicherung der Daten
3 Indizierung (Zeile, Wortanfang, Wortende)
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
W e s t f ä l i s c h e r F r i e d e
F r i e d e v o n O s n a b r ü c k
B i s t u m O s n a b r ü c k
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16
(3, 12, 20)
(3, 8, 10)
(3, 1, 6)
(2, 8, 16)
(2, 1, 6)
(1, 15, 20)
(1, 1, 13)
4 Zyklische Rotation der Indizierung
5 Sortierung der Indizierung
6 Ausgabe der Indizierung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 428 / 634
Software-Architektur
Erste Modularisierung (ablauforientiert)
<<Modul>>
Master Control
<<Modul>>
Input<<Modul>>
Shifter
<<Modul>>
Sorter
characters index sorted_index
<<Modul>>
Output
<<call>>
1.
<<call>> <<call>><<call>>
2. 3. 4.
<<use>><<set>><<use>>
<<use>>
<<set>>
<<use>> <<set>>
<<use>>
Eingabe Ausgabe
Wissen über Eingabeformat
Wissen über internes Datenformat
Wissen, dass alle Daten im Speicher sind
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 430 / 634
Software-Architektur
Qualitaten
Anderbarkeit:betroffene Module
Input Shifter Sorter Output
Eingabeformat ×großere Dateien × × × ×riesige Dateien × × × ×
Getrennte Entwicklung:
alle Datenstrukturen mussen bekannt sein
komplexe Beschreibung notwendig
Performanz:
schneller Zugriff auf globale Variablen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 431 / 634
Software-Architektur
Geheimnisprinzip (Information Hiding) (Parnas 1972)
Definition
Geheimnisprinzip: Module verbergen alleImplementierungsentscheidungen, die sich andern konnen, hinter einerabstrakten Schnittstelle.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 432 / 634
Software-Architektur
Zweite Modularisierung (objektbasiert)
. . . nach dem Geheimnisprinzip (Information Hiding) (Parnas 1972)
<<Modul>>
Master Control
<<Modul>>
Input
-Eingabeformat
<<Modul>>
Indexer
-zyklisches Schieben
<<Modul>>
Sorter
-Sortieralg.
<<Modul>>
Output
-Ausgabeformat
<<call>>
1.
<<call>><<call>>
<<call>>2.
3.
4.
<<call>>
Eingabe Ausgabe
<<Modul>>
Lines
-int. Speicherung
+add(c:char)
+<<interface>> Iteration()
+get(l:linenr,w:wordnr)
<<Modul>>
Index
-Indexstruktur
+add(l:linenr,w:wordnr)
+<<interface>> Iteration()
+swap(p1:pos,p2:pos)
<<call>><<call>> <<call>> <<call>>
<<call>>
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 433 / 634
Software-Architektur
Qualitaten
Anderbarkeit:betroffene Module
Input Lines Index Indexer Sorter Output
Eingabeformat ×großere Dateien ×riesige Dateien ×
Getrennte Entwicklung:
nur Schnittstellen mussen bekannt sein
Performanz:
zusatzliche Aufrufe
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 434 / 634
Software-Architektur
Abschließendes Wort zur Modularisierung
Es gibt viele Modularisierungsmoglichkeiten.
Jede ist gut fur einen Zweck, schlecht fur einen anderen.
Mit gangigen Programmiersprachen muss man sich auf eine festlegen.
Definition
Querschnittsbelange (Cross-Cutting Concerns):Implementierungsaspekte, die eine große Zahl von Modulen betreffen.
Beispiele: Fehlerbehandlung, Logging-Mechanismen, Vermeidung vonSpeicherlochern etc.
Aspektorientierte Programmiersprachen erlauben eine separateBeschreibung dieser Aspekte und ein
”Einweben“ des Aspekts in das
System.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 435 / 634
Software-Architektur
Wiederholungsfragen I
Was ist Software-Architektur und welche Bedeutung hat sie?
Welche Faktoren spielen eine Rolle fur die Architektur?
Erlautern Sie den Prozess von Hofmeister et al. zum Entwurf einerArchitektur (globale Analyse, Faktoren, Strategien,Blickwinkelentwurf).
Was ist ein Architekturblickwinkel bzw. eine Architektursicht?
Erlautern Sie die Blickwinkel von Hofmeister et al. Wer hat jeweils einInteresse an diesen Blickwinkeln?
Warum verschiedene Blickwinkel? Warum gerade diese vierBlickwinkel?
Wie lautet das Gesetz von Conway?
Was ist Modularisierung?
Was ist eine Schnittstelle?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 436 / 634
Software-Architektur
Wiederholungsfragen II
Was ist das Prinzip des Information-Hidings?
Was versteht man unter Kopplung und Zusammenhalt?
Nennen Sie Regeln fur einen guten Architekturentwurf.
Wie lasst sich Architektur prufen? Erlautern Sie insbesondere SAAM.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 437 / 634
Software-Architektur
Weiterfuhrende Literatur
Bass u. a. (2003) geben eine gute Ubersicht zu allen relevantenAspekten von Software-Architektur
Hofmeister u. a. (2000) beschreiben eine Methode fur denArchitekturentwurf, die auf vier verschiedenen Architektursichtenberuht
Shaw und Garlan (1996) geben eine Einfuhrung inSoftware-Architektur und beschreiben einige Architekturstile bzw.-muster
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 438 / 634
Architekturstile und Entwurfsmuster
Architekturstile und Entwurfsmuster
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragen
9 Architekturstile und EntwurfsmusterWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 439 / 634
Architekturstile und Entwurfsmuster
Lernziele
Verstehen, was Entwurfsmuster und Architekturstile sind
Qualitaten und Einsetzbarkeit der Entwurfsmuster/Architekturstilekennen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 440 / 634
Architekturstile und Entwurfsmuster
Kontext
Implemen−tierung
Test
Wartung& Evolution
Architektur
Datenstrukturen
und Algorithmen
AnalyseEntwurf
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 441 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster
Each pattern describes a problem which occurs over and overagain in our environment, and then describes the core of thesolution to that problem, in such a way that you can use thissolution a million times over, without ever doing it the same waytwice.
Christopher Alexander (Architekt und Mathematiker),“A pattern language”, 1977.
Definition
Entwurfsmuster:”Musterlosung“ fur ein wiederkehrendes
Entwurfsproblem.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 442 / 634
Architekturstile und Entwurfsmuster
Bestandteile eines Entwurfsmusters
Name (kurz und beschreibend)
Problem: Was das Entwurfsmuster lost
Losung: Wie es das Problem lost
Konsequenzen: Folgen und Kompromisse des Musters
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 443 / 634
Architekturstile und Entwurfsmuster
Beispielentwurfsproblem
Laufrad
+entfernen()
Felge
+entfernen()
Mantel
+entfernen()
Rahmen
+entfernen()
10..1
10..1
1
0..1
0..1
1..2
Artikel
+entfernen()
Rad
+entfernen()
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 444 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) I
Name: Composite
Zweck: Teil-von-Hierarchie mit einheitlicher Schnittstelle beschreiben(uberall wo ein Ganzes benutzt werden kann, kann auch ein Teilbenutzt werden und umgekehrt)
Motivation: . . . Einfuhrung anhand eines konkreten Beispiels. . .
Anwendbarkeit:
wenn Teil-von-Beziehung beschrieben werden solluniforme Schnittstelle fur alle Elemente der Hierarchie
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 445 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) II
Struktur:
for each c in children c.operation()
spezifischeErweiterungen
childrenClient
myElem+operation()
myComp+operation()
Composite
+add(component)+remove(component)+getChild(int)
+operation()
Leaf+operation()
operation()Component
+operation()
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 446 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) I
Teilnehmer:
Client:
manipuliert Objekte der Komponenten nur durch die Schnittstelle vonComposite
Component:
deklariert einheitliche Schnittstelle(optional) implementiert Standardverhalten
p u b l i c a b s t r a c t c l a s s Component {p u b l i c a b s t r a c t v o i d o p e r a t i o n ( ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 447 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) II
Leaf :
reprasentiert atomare Komponentedefiniert Verhalten fur atomare Komponenten
p u b l i c a b s t r a c t c l a s s L e a f e x t e n d s Component {p u b l i c a b s t r a c t v o i d o p e r a t i o n ( ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 448 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) III
Composite:
definiert Standardverhalten fur zusammengesetzte Komponentenspeichert Teileimplementiert Operationen zur Verwaltung von Teilen
i m p o r t j a v a . u t i l . L i s t ;i m p o r t j a v a . u t i l . A r r a y L i s t ;p u b l i c a b s t r a c t c l a s s Composite e x t e n d s Component {
p r i v a t e L i s t <Component> c h i l d r e n= new A r r a y L i s t <Component >() ;
p u b l i c v o i d o p e r a t i o n ( ) {f o r ( Component c : c h i l d r e n ) c . o p e r a t i o n ( ) ;
}p u b l i c v o i d add ( Component c ) { c h i l d r e n . add ( c ) ; }p u b l i c v o i d remove ( Component c ) { c h i l d r e n . remove ( c ) ; }p u b l i c Component g e t C h i l d ( i n t i ) { r e t u r n c h i l d r e n . g e t ( i ) ; }}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 449 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) I
Kollaborationen:
Clients benutzen Component-Schnittstelle
falls Empfanger ein Leaf ist, antwortet es direkt
falls Empfanger ein Composite ist, wird die Anfrage an Teileweitergeleitet (moglicherweise mit weiteren eigenen Operationen vorund/oder nach der Weiterleitung)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 450 / 634
Architekturstile und Entwurfsmuster
Beschreibung von Mustern (Gamma u. a. 2003) II
Konsequenzen:
zweiteilt die Klassenhierarchie in Leaf und Composite miteinheitlicher Schnittstelle
uniforme Verwendung auf Seiten des Clients
neue Komponenten konnen leicht hinzugefugt werden
konnte die Struktur unnotig allgemein machen (dynamische versusstatische Typisierung)
Implementierung: . . . Hinweise zur Implementierung . . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 451 / 634
Architekturstile und Entwurfsmuster
Dynamische versus statische Typisierung
Laufrad
+entfernen()
Felge
+entfernen()
Mantel
+entfernen()
Rahmen
+entfernen()
10..1
10..1
1
0..1
0..1
1..2
Artikel
+entfernen()
Rad
+entfernen()
Artikel
+entfernen()
+hinzufügen(Artikel)
+alleTeile(): list of Artikel
Behälter
+entfernen()
Blatt
+entfernen()
+hinzufügen(Artikel)
Mantel
+entfernen()
Rahmen
+entfernen()
Felge
+entfernen()
Laufrad
+entfernen()
Rad
+entfernen()
VerwenderTeile
for each t in Teile
t.entfernen()
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 452 / 634
Architekturstile und Entwurfsmuster
Kategorien von Entwurfsmustern
Erzeugungsmuster
betreffen die Erzeugung von ObjektenBeispiel: Factory Method
Strukturelle Muster:
betreffen Komposition von Klassen und ObjektenBeispiel: Composite
Verhaltensmuster:
betreffen Interaktion und VerantwortlichkeitenBeispiel: Observer
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 453 / 634
Architekturstile und Entwurfsmuster
Fahrradladenbeispiel: Erweiterung fur andere Domanen
Anforderungen:
Artikeldaten sollen von einer Datei gelesen werden konnen
zukunftig sollen andere Domanen unterstutzt werden (Fahrrad,Computer und Klettern)
die Objekte dieser Domanen sind unterschiedlich
notwendige Anpassungen sollen einfach realisiert werden konnen
Losungsstrategien:
die Klassen der Benutzungsschnittstelle beziehen sich nur auf dieSchnittstelle der abstrakten Klasse Artikel
Datei hat gleiche Syntax fur alle Domanen (nur die Inhalte variieren)
die Artikel werden beim Einlesen der Datei als Objekte erzeugt
→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oderwas?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 454 / 634
Architekturstile und Entwurfsmuster
Losungsstrategie
FelgeRahmen
+ Preis()
Artikel
GUI
ComputerArtikel FahrradArtikel
+ lies(dateiname)
Leser
id=datei.liesId()
s.FabrikMethode(id)
+ Artikel FabrikMethode(id)
ArtikelSchopfer
+FabrikMethode(id)
FahrradSchopfer
+FabrikMethode(id)
ComputerSchopfer
if (id == ”rahmen”)return new Rahmen
if (id == ”felge”)return new Felge�create�
�create� �create�
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 455 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster: Factory Method
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 456 / 634
Architekturstile und Entwurfsmuster
Anwendbarkeit
eine Klasse weiß in manchen Fallen nicht im Voraus, von welcherKlasse ein zu erzeugendes Objekt sein soll
die konkreten Unterklassen einer Klasse sollen dies entscheiden
Verantwortlichkeit wird an Unterklassen delegiert, und das Wissenuber die Unterklasse, an die delegiert wird, soll nur an einem Punktvorhanden sein
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 457 / 634
Architekturstile und Entwurfsmuster
Teilnehmer
Product
deklariert die Schnittstelle von Objekten, die die Fabrikmethodeerschafft
ConcreteProduct
implementiert die Product-Schnittstelle
Creator
deklariert die Fabrikmethode(optional) implementiert eine Standardfabrikmethode, die einspezifisches konkretes Objekt erzeugtkann Fabrikmethode aufrufen, um ein Product-Objekt zu erzeugen
ConcreteCreator
uberschreibt die Fabrikmethode, um konkretes Product-Objekt zuerschaffen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 458 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer
Anwendbarkeit
Komponenten hangen von anderen Komponenten ab
Anderung der einen Komponente muss Anderung der anderen nachsich ziehen
Komponenten sollen lose gekoppelt sein: Komponente kennt seineAbhangigen nicht im Voraus (zur Ubersetzungszeit)
Losungsstrategie
Abhangige registrieren sich bei Komponente
Komponente informiert alle registrierten Abhangigen uberZustandsanderung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 459 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Struktur
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 460 / 634
Entwurfsmuster Observer: Struktur
20
09
-02
-09
Software-Projekt
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer
Entwurfsmuster Observer: Struktur
Man beachte die Beziehung zu den Architekturmustern Blackboard und Model-View-Controller.
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Teilnehmer Subject
kennt seine Observer (zur Laufzeit)
kann beliebig viele Observer haben
stellt Schnittstelle zur Verfugung, um Observer zu registrieren undabzutrennen
i m p o r t j a v a . u t i l . L i s t ;i m p o r t j a v a . u t i l . A r r a y L i s t ;
p u b l i c a b s t r a c t c l a s s S u b j e c t {
p r i v a t e L i s t <Observer> o b s e r v e r s= new A r r a y L i s t <Observer >() ;
p u b l i c v o i d Attach ( O b s e r v e r c ) { o b s e r v e r s . add ( c ) ; }p u b l i c v o i d Detach ( O b s e r v e r c ) { o b s e r v e r s . remove ( c ) ; }p u b l i c v o i d N o t i f y ( ) {
f o r ( O b s e r v e r o : o b s e r v e r s ) o . update ( ) ;}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 461 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Teilnehmer Observer
deklariert Schnittstelle fur die Update-Nachricht
p u b l i c a b s t r a c t c l a s s O b s e r v e r {p u b l i c a b s t r a c t v o i d update ( ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 462 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Teilnehmer ConcreteSubject
hat einen Zustand, der ConcreteObserver interessiert
sendet Bekanntmachung via Notify(), wenn sich Zustand andert(SetState)
p u b l i c c l a s s Ampel e x t e n d s S u b j e c t {
p r i v a t e b o o l e a n r o t = f a l s e ;
p u b l i c b o o l e a n i s t r o t ( ) { r e t u r n r o t ;}
p u b l i c v o i d s c h a l t e n ( ) {s e t ( ! r o t ) ;
}
p r i v a t e v o i d s e t ( b o o l e a n newValue ) {r o t = newValue ;N o t i f y ( ) ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 463 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Teilnehmer ConcreteObserver
kennt ConcreteSubject-Objektverarbeitet Zustand dieses Subjectsimplementiert Update, um auf veranderten Zustand zu reagieren
p u b l i c c l a s s Auto e x t e n d s O b s e r v e r {p r i v a t e Ampel ampel ;p r i v a t e b o o l e a n g a s p e d a l = f a l s e ;p u b l i c v o i d update ( ) {
i f ( ! ampel . i s t r o t ( ) ) f a h r e n ( ) ;}p u b l i c v o i d f a h r e n ( ) {
ampel . Detach ( t h i s ) ;g a s p e d a l = t r u e ;}p u b l i c v o i d s t o p p e n ( Ampel a ) {
ampel = a ;ampel . Attach ( t h i s ) ;g a s p e d a l = f a l s e ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 464 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Konsequenzen
abstrakte Kopplung zwischen Subject und Observer
unterstutzt Rundfunk (Broadcast)
unerwartete Updates, komplizierter Kontrollfluss
viel Nachrichtenverkehr, auch dann wenn sich ein irrelevanter Aspektgeandert hat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 465 / 634
Architekturstile und Entwurfsmuster
Entwurfsmuster Observer: Verfeinerungen
Push-Modell
Subject sendet detaillierte Beschreibung der Anderung→ umfangreiches Update→ vermeidet GetState(), aber nicht Update()
Pull-Modell
Subject sendet minimale Beschreibung der Anderung→ Observer fragt gegebenfalls die Details nach→ erfordert weitere Nachrichten, um Details abzufragen
Explizite Interessen
Observers melden Interesse an spezifischem Aspekt an; Aspekt wirdzusatzlicher Parameter von Update
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 466 / 634
Architekturstile und Entwurfsmuster
Architekturstile
Definition
Architekturstil: beschreibt eine Familie von Architekturen/Systeme alsein Muster der strukturellen Organisation durch
ein Vokabular (Komponenten- und Konnektorentypen)
und eine Menge von Einschrankungen, wie Komponenten undKonnektoren verbunden werden durfen.
Synonyme: Architekturmuster oder Architekturidiom.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 467 / 634
Architekturstile und Entwurfsmuster
Architekturstil: Schichtung
System−Software
Netzwerk
Anwendungslogik
Nutzungsoberfläche
Datenhaltung Utilities
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 468 / 634
Architekturstile und Entwurfsmuster
Architekturstil: Schichtung I
Vokabular:
Komponenten: Module und SchichtenKonnektoren: Use-Beziehung
Struktur:
Module sind eindeutig einer Schicht zugeordnetModule einer Schicht durfen nur auf Module derselben und der direktdarunter liegenden Schicht zugreifen
Ausfuhrungsmodell:
Aufruf von Methoden tieferer SchichtenDatenfluss in beide Richtungen (von der unteren Schicht zur oberendurch Ruckgabeparameter)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 469 / 634
Architekturstile und Entwurfsmuster
Architekturstil: Schichtung II
Vorteile:
Schicht implementiert virtuelle Maschine, deren Implementierung leichtausgetauscht werden kann, ohne dass hohere Schichten geandertwerden mussen
Nachteile:
hoherer Aufwand durch das”Durchreichen“ von Information
Redundanz durch Dienste tieferer Schichten, die in hohen Schichtenbenutzt und auf allen Ebenen dazwischen repliziert werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 470 / 634
Architekturstile und Entwurfsmuster
Anforderungen
Sonstige: 18%Mäntel: 43%Felgen: 23%Rahmen: 4%Sättel: 12%
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 471 / 634
Anforderungen
Sonstige: 18%Mäntel: 43%Felgen: 23%Rahmen: 4%Sättel: 12%
20
09
-02
-09
Software-Projekt
Architekturstile und Entwurfsmuster
Architekturstil Model-View-Controller
Anforderungen
Unterschiedliche Diagrammarten stellen statistische Daten uber die nachgefragten Artikel dar. Die Diagrammemussen alle konsistent zu den aktuellen Daten sein. Neue Diagramme sollen leicht hinzugefugt werden konnen.
Architekturstile und Entwurfsmuster
Model-View-Controller (Buschmann u. a. 1996)
Observer
update
Subject
an View (Anzeige) Model (Fachlogik) bzw. in Nachrichten an− übersetzt Eingaben eingaben− akzeptiert Benutzer−
Fachlogik− implementiert
Controller View
Model
GUI
− visualisiert Informationen über Model
− holt sich Information vom Model
und Controllers− registriert Views
Änderungüber− informiert Observer
1. register
2. display
3. getData
4. call service
5. update
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 472 / 634
Architekturstile und Entwurfsmuster
Model-View-Controller Beispiel
Ein Model: Wert in festem Bereich
ProgressView
SliderView
Ein Controller: Verschiebung in SliderView verandert Model
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 473 / 634
Model-View-Controller Beispiel
Ein Model: Wert in festem Bereich
ProgressView
SliderView
Ein Controller: Verschiebung in SliderView verandert Model
20
09
-02
-09
Software-Projekt
Architekturstile und Entwurfsmuster
Architekturstil Model-View-Controller
Model-View-Controller Beispiel
Dieses Beispiel und der Code dazu stammen von Thilo Mende. Ihm gilt mein Dank.
Architekturstile und Entwurfsmuster
Beispiel-Model: Zustand
1 i m p o r t j a v a . u t i l . A r r a y L i s t ;2 i m p o r t j a v a . u t i l . L i s t ;3 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;4 i m p o r t j a v a x . swing . e v e n t . C h a n g e L i s t e n e r ;5
6 p u b l i c c l a s s Model {7
8 // Wer t ebe r e i ch :9 p r i v a t e f i n a l i n t min = 0 ; // un t e r e Grenze
10 p r i v a t e f i n a l i n t max = 1 0 0 ; // obe re Grenze11
12 // Zustand13 p r i v a t e i n t v a l u e = 5 0 ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 474 / 634
Architekturstile und Entwurfsmuster
Beispiel-Model: Oberver-Behandlung
1 // a l l e Obse rve r2 p r i v a t e L i s t <C h a n g e L i s t e n e r > o b s e r v e r s ;3
4 // Kont ruk to r5 p u b l i c Model ( ){6 o b s e r v e r s = new A r r a y L i s t <C h a n g e L i s t e n e r >() ;7 }8
9 // neuen Obse rve r r e g i s t r i e r e n10 p u b l i c v o i d a d d C h a n g e L i s t e n e r ( C h a n g e L i s t e n e r o b s e r v e r ) {11 o b s e r v e r s . add ( o b s e r v e r ) ;12 }13
14 // Benach r i c h t i gung a l l e r Obse rve r ;15 // au f z u r u f e n b e i a l l e n Zustands anderungen16 p r i v a t e v o i d N o t i f y ( ){17 f o r ( C h a n g e L i s t e n e r o b s e r v e r : o b s e r v e r s ){18 o b s e r v e r . s t a t e C h a n g e d ( new ChangeEvent ( t h i s ) ) ;19 }20 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 475 / 634
Architekturstile und Entwurfsmuster
Beispiel-Model: Setter und Getter
1 p u b l i c i n t getMin ( ) { r e t u r n min ;}2
3 p u b l i c i n t getMax ( ) { r e t u r n max ;}4
5 p u b l i c i n t g e t V a l u e ( ) { r e t u r n v a l u e ;}6
7 p u b l i c v o i d s e t V a l u e ( i n t v a l u e ) {8 i f ( v a l u e < min ){9 t h i s . v a l u e = min ;
10 } e l s e i f ( v a l u e > max ){11 t h i s . v a l u e = max ;12 } e l s e {13 t h i s . v a l u e = v a l u e ;14 }15 t h i s . N o t i f y ( ) ;16 // Zustand hat s i c h ge a nde r t17 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 476 / 634
Architekturstile und Entwurfsmuster
Beispiel-Controller
1 p u b l i c c l a s s C o n t r o l l e r {2
3 p r i v a t e Model model ; // das Model des C o n t r o l l e r s4
5 // In d i e s e r Va r i a n t e kennt de r C o n t r o l l e r s e i n e6 // View n i c h t ; d i e A s s o z i a t i o n von View und C o n t r o l l e r7 // wi rd vom Hauptprogramm e t a b l i e r t8
9 p u b l i c C o n t r o l l e r ( Model model ) {10 t h i s . model = model ;11 }12
13 p u b l i c v o i d s e t V a l u e ( i n t v a l u e ) {14 model . s e t V a l u e ( v a l u e ) ;15 }16 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 477 / 634
Architekturstile und Entwurfsmuster
Beispiel-ProgressView I
1 i m p o r t j a v a x . swing . J P r o g r e s s B a r ;2 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;3 i m p o r t j a v a x . swing . e v e n t . C h a n g e L i s t e n e r ;4
5 p u b l i c c l a s s P r o g r e s s V i e w e x t e n d s J P r o g r e s s B a r6 imp lements C h a n g e L i s t e n e r {7
8 p r i v a t e C o n t r o l l e r c o n t r o l l e r ; // View kennt C o n t r o l l e r9 p r i v a t e Model my model ;
10
11 p u b l i c P r o g r e s s V i e w ( C o n t r o l l e r c o n t r o l l e r , Model my model ){12 s u p e r (VERTICAL ) ;13 t h i s . c o n t r o l l e r = c o n t r o l l e r ;14 t h i s . my model = my model ;15
16 // Zustand von Model d a r s t e l l e n :17 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ;18
19 // R e g i s t r i e r u n g b e i Model20 my model . a d d C h a n g e L i s t e n e r ( t h i s ) ;21 }22
23 // R e d e f i n i t i o n ; e r e r b t von ChangeL i s t ene r ;24 // e n t s p r i c h t update25 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {26 s y n c h r o n i z e d ( t h i s ){27 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; }28 }29 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 478 / 634
Architekturstile und Entwurfsmuster
Beispiel-ProgressView II
1 // R e d e f i n i t i o n ; e r e r b t von ChangeL i s t ene r ;2 // e n t s p r i c h t update3 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {4 s y n c h r o n i z e d ( t h i s ){5 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ; }6 }7
8 } // Ende Prog re s sV i ew
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 479 / 634
Architekturstile und Entwurfsmuster
Beispiel-SliderView I
1 i m p o r t j a v a x . swing . J S l i d e r ;2 i m p o r t j a v a x . swing . e v e n t . ChangeEvent ;3 i m p o r t j a v a x . swing . e v e n t . C h a n g e L i s t e n e r ;4
5 p u b l i c c l a s s S l i d e r V i e w e x t e n d s J S l i d e r6 imp lements C h a n g e L i s t e n e r {7 p r i v a t e C o n t r o l l e r m y c o n t r o l l e r ; // View kennt C o n t r o l l e r8 p r i v a t e Model my model ;9
10 // R e d e f i n i t i o n ; e r e r b t von ChangeL i s t ene r ;11 // e n t s p r i c h t update12 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {13 t h i s . s e t V a l u e ( my model . g e t V a l u e ( ) ) ;14 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 480 / 634
Architekturstile und Entwurfsmuster
Beispiel-SliderView II
1 // Kons t ruk to r2 p u b l i c S l i d e r V i e w ( f i n a l C o n t r o l l e r c o n t r o l l e r , Model model ) {3 s u p e r ( model . getMin ( ) , model . getMax ( ) , model . g e t V a l u e ( ) ) ;4 t h i s . my model = model ;5 t h i s . m y c o n t r o l l e r = c o n t r o l l e r ;6
7 // R e g i s t r i e r u n g b e i Model8 model . a d d C h a n g e L i s t e n e r ( t h i s ) ;9
10 // Zustand von Model d a r s t e l l e n :11 t h i s . a d d C h a n g e L i s t e n e r ( new C h a n g e L i s t e n e r ( ) {12 p u b l i c v o i d s t a t e C h a n g e d ( ChangeEvent arg0 ) {13 i f ( ! g e t V a l u e I s A d j u s t i n g ( ) ){14 m y c o n t r o l l e r . s e t V a l u e ( g e t V a l u e ( ) ) ;15 }16 }17 } ) ;18 }19 } // Ende von S l i d e rV i ew
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 481 / 634
Architekturstile und Entwurfsmuster
Beispiel-Hauptprogramm I
1 i m p o r t j a v a . awt . BorderLayout ;2 i m p o r t j a v a x . swing . JFrame ;3 i m p o r t j a v a x . swing . WindowConstants ;4
5 p u b l i c c l a s s MVCDemo {6 p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {7 MVCDemo demo = new MVCDemo ( ) ;8 }9 }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 482 / 634
Architekturstile und Entwurfsmuster
Beispiel-Hauptprogramm II
1 p u b l i c MVCDemo( ) {2 Model model = new Model ( ) ;3
4 // A s s o z i a t i o n d e s s e l b e n C o n t r o l l e r s mit be i d en Views5 C o n t r o l l e r c o n t r o l l e r = new C o n t r o l l e r ( model ) ;6 P r o g r e s s V i e w p r o g r e s s = new P r o g r e s s V i e w ( c o n t r o l l e r , model ) ;7 S l i d e r V i e w s l i d e r = new S l i d e r V i e w ( c o n t r o l l e r , model ) ;8
9 // Fen s t e r um a l l e s10 JFrame d i s p l a y F r a m e = new JFrame ( ” D i s p l a y ” ) ;11 d i s p l a y F r a m e . getContentPane ( )12 . add ( p r o g r e s s , BorderLayout . CENTER ) ;13 d i s p l a y F r a m e . getContentPane ( )14 . add ( s l i d e r , BorderLayout .SOUTH) ;15 d i s p l a y F r a m e . s e t D e f a u l t C l o s e O p e r a t i o n16 ( WindowConstants . EXIT ON CLOSE ) ;17 d i s p l a y F r a m e . pack ( ) ;18 d i s p l a y F r a m e . s e t V i s i b l e ( t r u e ) ;19 }20
21 } // End MVCDemoRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 483 / 634
Architekturstile und Entwurfsmuster
Wiederholungsfragen
Was ist ein Entwurfsmuster?
Warum sind sie interessant fur die Software-Entwicklung?
Erlautern Sie eines der in der Vorlesung vorgestellten Entwurfsmuster.
Was ist ein Architekturstil?
Nennen Sie Beispiele fur Architekturstile. Erlautern Sie die Stile.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 484 / 634
Architekturstile und Entwurfsmuster
Weiterfuhrende Literatur
Buschmann u. a. (1996) beschreiben Architekturstile bzw. -muster
Shaw und Garlan (1996) geben eine Einfuhrung inSoftware-Architektur und beschreiben einige Architekturstile bzw.-muster
Das Standardbuch zu Entwurfsmustern ist das von Gamma u. a.(2003)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 485 / 634
Software-Test
Software-Test
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragen
10 Software-TestBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 486 / 634
Software-Test
Lernziele
Notwendigkeit und Grenzen des Tests verstehen
Arten und Varianten des Software-Tests kennen
eine geeignete Test-Strategie auswahlen konnen
Testplane erstellen konnen
Tests durchfuhren konnen
N.B.: Diese Darstellung folgt in weiten Teilen Kapitel 11 des Buchs vonBrugge und Dutoit (2004).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 487 / 634
Software-Test
Ein korrektes Programm?
c l a s s K a l e n d e r {p u b l i c s t a t i c c l a s s MonatUngue l t ig e x t e n d s E x c e p t i o n {} ;p u b l i c s t a t i c c l a s s J a h r U n g u e l t i g e x t e n d s E x c e p t i o n {} ;p u b l i c s t a t i c b o o l e a n i s t S c h a l t J a h r ( i n t j a h r )
{ r e t u r n ( j a h r % 4) == 0 ;}p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r )
throws MonatUnguelt ig , J a h r U n g u e l t i g {i n t anzTage ;i f ( j a h r < 1) { throw new J a h r U n g u e l t i g ( ) ; }i f ( monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 3 2 ;}e l s e i f ( monat i n {4 , 6 , 9 , 11}) { anzTage = 3 0 ; }e l s e i f ( monat == 2) {
i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 2 9 ;e l s e anzTage = 2 8 ;
} e l s e throw new MonatUngue l t ig ( ) ;r e t u r n anzTage ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 488 / 634
Software-Test
Testen und seine Begriffe
Definition
Zuverlassigkeit: Maß fur den Erfolg, inwieweit das beobachtete Verhaltenmit dem spezifizierten ubereinstimmt.
Software-Zuverlassigkeit: Wahrscheinlichkeit, dass ein Software-Systemwahrend einer festgelegten Zeit unter festgelegten Bedingungen keinenSystemausfall verursachen wird (IEEE Std. 982-1989 1989).
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 489 / 634
Software-Test
Fehlerbegriff
Definition
Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.
Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.
Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.
Die Funktion istSchaltjahr(200) liefert true.
Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.
Die Prufung in istSchaltjahr ist falsch.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 491 / 634
Fehlerbegriff
Definition
Storfall (Ausfall, Failure): jegliche Abweichung des beobachtetenVerhaltens vom spezifizierten.
Im Nicht-Schaltjahr 200 wird fur den Monat Februar 29 ausgegeben.
Fehlerhafter Zustand (Error): Zustand, in dem ein Weiterlaufen desSystems zu einem Storfall fuhren wurde.
Die Funktion istSchaltjahr(200) liefert true.
Fehler (Defekt, Fault): mechanische oder algorithmische Ursache einesfehlerhaften Zustands.
Die Prufung in istSchaltjahr ist falsch.20
09
-02
-09
Software-Projekt
Software-Test
Begriffe des Testens
Fehlerbegriff
Mechanische Ursache: Fehler in der virtuellen Maschine (Plattform); z.B. Bug in Java-Virtual-Machine, Compileroder Hardwaredefekt.
Algorithmische Ursache: Fehler im Algorithmus, z.B. Off-by-One-Fehler, uninitialisierte Variable,
Performanzengpasse aufgrund eines schlechten Entwurfs.
Software-Test
Testen und seine Begriffe
Definition
Test: systematischer Versuch, in der implementierten Software Defekte zufinden.
Erfolgreicher (positiver) Test: Test, der Defekt aufgedeckt hat.
Erfolgloser (negativer) Test: Test, der keinen Defekt aufgedeckt hat.
→ Tests sind Experimente zur Falsifikation der Hypothese “System istkorrekt”.
→ Aus negativem Test folgt noch lange nicht, dass kein Defektvorhanden ist.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 492 / 634
Software-Test
Der Test und seine Verwandten
Tests sind nur ein Mittel, die Zuverlassigkeit zu steigern:
Fehlervermeidung (z.B. Entwicklungsmethoden, Verifikation, statischeAnalyse)
Fehlerentdeckung (z.B. Tests, assert, “Quality-Feedback-Agent”,Flugschreiber)
Fehlertoleranz: Behandlung von Fehlern zur Laufzeit, um Programmfortzusetzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 493 / 634
Software-Test
Soziologie des Testens
Testen wird haufig (aber zu unrecht) als niedere Arbeit angesehen
→ Frischlinge werden zu Testern
Tester brauchen jedoch ein umfassendes Systemverstandnis(Anforderungen, Entwurf, Implementierung)
Tester brauchen daruber hinaus, Wissen uber Pruftechniken
Autoren haben eine Lesart der Spezifikation verinnerlicht
Denkfehler in der Implementierung werden sich bei Erstellung vonTestfallen wiederholen
→ Tester sollten nicht gleichzeitig Autoren sein
Tester versuchen, Fehler zu finden
das Produkt wird kritisiert, dann fuhlen sich Autoren selbst kritisiert
→ Egoless-Programming (eine schone Illusion)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 494 / 634
Software-Test
Testplan
Komponententest
Integrationstest
Strukturtest
Funktionstest
Leistungstest
Akzeptanztest
Installationstest
Benutzbarkeitstest
Feldtest
Normalbetrieb
Management-plan
Klassen-entwurf
Integrations-strategie
Subsystem-zerlegung
FunktionaleAnforderungen
NichtfunktionaleAnforderungen
Benutzungs-handbuch
Projekt-vereinbarung
Benutzungs-schnittstellen-
entwurf
Entwickler Kunde Benutzer
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 495 / 634
Testplan
Komponententest
Integrationstest
Strukturtest
Funktionstest
Leistungstest
Akzeptanztest
Installationstest
Benutzbarkeitstest
Feldtest
Normalbetrieb
Management-plan
Klassen-entwurf
Integrations-strategie
Subsystem-zerlegung
FunktionaleAnforderungen
NichtfunktionaleAnforderungen
Benutzungs-handbuch
Projekt-vereinbarung
Benutzungs-schnittstellen-
entwurf
Entwickler Kunde Benutzer
20
09
-02
-09
Software-Projekt
Software-Test
Testaktivitaten
Quelle: Brugge und Dutoit (2004)
• Testplanung: Betriebsmittelzuteilung und Zeitplan
• Benutzbarkeitstest: Fehler im Benutzerschnittstellenentwurf aufdecken; siehe (Papier-)Prototypen
• Komponententest: Fehler in einzelner Komponente (Klasse, Paket o.A.) aufdecken
• Integrationstest: Fehler im Zusammenspiel von Komponenten aufdecken
• Strukturtest: Integrationstest mit allen Komponenten (abschließender und vollstandiger Integrationstest)
• Systemtest: Test aller in einem System zusammengefasster Subsysteme mit dem Ziel, Fehler bezuglich der Szenarien ausder problemstellung sowie der Anforderungen und Entwurfsziele, die in der Analyse bzw. im Systementwurf identifiziertwurden, zu finden
• Funktionstest: testet die Anforderungen aus dem Lastenheft und die Beschreibung des Benutzerhandbuchs
• Leistungstest: Test der Leistungsanforderungen (Performanz und Speicherbedarf)
• Installationstest: Test der Installation beim Kunden (evtl. mit der Hilfe der Entwickler)
• Akzeptanztest: Prufung bzgl. Projektvereinbarung durch den Kunden (evtl. mit der Hilfe der Entwickler)
Software-Test
Testfall
Ein Testfall besteht aus:
Name
Ort: vollstandiger Pfadname deslauffahigen Testprogramms
Eingabe: Eingabedaten oderBefehle
Orakel: erwarteteTestergebnisse, die mit denaktuellen Testergebnissen desTestlaufs verglichen werden
Protokoll: gesamte Ausgabe, diedurch Test erzeugt wird
Eingabe Ist-ErgebnisPrüfling
Vergleich Protokoll
Soll-Ergebnis
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 496 / 634
Software-Test
Komponententest: Teststumpfe und -treiber
Benutzerklasse X
Benutzte Klasse A Benutzte Klasse B
Prüfling C
Testtreiber
Benutzte Klasse A Teststumpf für benutzte Klasse B
Prüfling C
Benutzerklasse Y
spätere Umgebung Testumgebung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 497 / 634
Komponententest: Teststumpfe und -treiber
Benutzerklasse X
Benutzte Klasse A Benutzte Klasse B
Prüfling C
Testtreiber
Benutzte Klasse A Teststumpf für benutzte Klasse B
Prüfling C
Benutzerklasse Y
spätere Umgebung Testumgebung2
00
9-0
2-0
9
Software-Projekt
Software-Test
Teststumpfe und -treiber
Komponententest: Teststumpfe und -treiber
Bestreben: Komponenten so fruh wie moglich testen.Problem: die benutzenden Komponenten und die benutzten Komponenten existieren moglicherweise noch nicht.Losung: Testtreiber und -stumpfe
• Prufling/Testkomponente: die zu testende Klasse/Komponente
• Testtreiber: simuliert den Teil des Systems, der die Testkomponente benutzt
• Teststumpf: simuliert die Komponenten, die die Testkomponente benutzt
In vielen Fallen: Aufwand fur Teststumpf entspricht Aufwand fur die eigentliche Komponente→Bottom-Up-Entwicklung der Komponenten
Software-Test
Typen von Komponententests
Definition
Black-Box-Tests: Komponente wird nur mit Kenntnis derSchnittstellenbeschreibung entworfen (Implementierung unbekannt).
Techniken:
Aquivalenztest
Grenztest
(zustandsbasierter Test)
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 498 / 634
Software-Test
Typen von Komponententests
Definition
White-/Glass-Box-Tests: Testfall wird mit Kenntnis der Implementierungentworfen.
Techniken:
Pfadtest
(zustandsbasierter Test)
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 499 / 634
Software-Test
Aquivalenztest I
Ziel: Testfalle minimieren.Idee:
Aquivalente Testfalle werden zusammengefasst.
Ein Testfall wird als Reprasentant der Aquivalenzklasse aufgestellt.
Kriterien:
Abdeckung: Jede mogliche Eingabe gehort zu einer derAquivalenzklassen
Disjunktion: Keine Eingabe gehort zu mehr als einer einzigenAquivalenzklasse
Reprasentation (die Hoffnung): Falls Ausfuhrung einen fehlerhaftenZustand anzeigt, sobald ein bestimmtes Mitglied einerAquivalenzklasse als Eingabe benutzt wird, dann kann derselbefehlerhafte Zustand entdeckt werden, wenn irgendein anderes Mitglieddieser Aquivalenzklasse als Eingabe verwendet wird
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 500 / 634
Software-Test
Aquivalenztest II
Fur jede Aquivalenzklasse werden mindestens zwei Testeingabenausgewahlt:
typische Eingabe, die den allgemeinen Fall abpruft
unvollstandige Eingabe, die auf korrektes Verhalten im Fehlerfall pruft
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 501 / 634
Software-Test
Ein korrektes Programm?
c l a s s K a l e n d e r {p u b l i c s t a t i c c l a s s MonatUngue l t ig e x t e n d s E x c e p t i o n {} ;p u b l i c s t a t i c c l a s s J a h r U n g u e l t i g e x t e n d s E x c e p t i o n {} ;p u b l i c s t a t i c b o o l e a n i s t S c h a l t J a h r ( i n t j a h r )
{ r e t u r n ( j a h r % 4) == 0 ;}p u b l i c s t a t i c i n t TageProMonat ( i n t monat , i n t j a h r )
throws MonatUnguelt ig , J a h r U n g u e l t i g {i n t anzTage ;i f ( j a h r < 1) { throw new J a h r U n g u e l t i g ( ) ; }i f ( monat i n {1 , 3 , 5 , 7 , 10 , 12}) { anzTage = 3 2 ;}e l s e i f ( monat i n {4 , 6 , 9 , 11}) { anzTage = 3 0 ; }e l s e i f ( monat == 2) {
i f ( i s t S c h a l t J a h r ( j a h r ) ) anzTage = 2 9 ;e l s e anzTage = 2 8 ;
} e l s e throw new MonatUngue l t ig ( ) ;r e t u r n anzTage ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 502 / 634
Software-Test
Beispielspezifikation
Kalender.TageProMonat(monat,jahr) liefere die Tage eines Monatswie folgt:
monat ∈ {1, 3, 5, 7, 8, 10, 12} ⇒ 31
monat ∈ {4, 6, 9, 11} ⇒ 30
jahr ist ein Schaltjahr ∧ monat = 2⇒ 29
jahr ist kein Schaltjahr ∧ monat = 2⇒ 28
Fehlerfall
monat < 1 ∨monat > 12⇒ throw MonatUngueltig
jahr < 0⇒ throw JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 503 / 634
Software-Test
Beispielaquivalenzklassen
Aquivalenzklassen:
fur Monate:
Monate mit 31 TagenMonate mit 30 TagenMonate mit 28 oder 29 Tagenmonat außerhalb gultigen Bereichs
fur Jahre:
SchaltjahreJahre, die keine Schaltjahre sindjahr außerhalb gultigen Bereichs
→ Kombination der Aquivalenzklassen fur alle Eingabeparameter ergibtAquivalenzklassen fur TageProMonat
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 504 / 634
Software-Test
Beispieltestfalle
Test der Interaktion von monat und jahr durch Kombination:
Aquivalenzklasse monat jahr Soll
31-Tage-Monat, Nicht-Schaltjahre 7 1901 3131-Tage-Monat, Schaltjahre 7 1904 31
30 Tage-Monat, Nicht-Schaltjahre 6 1901 3030 Tage-Monat, Schaltjahre 6 1904 30
Februar, Nicht-Schaltjahre 2 1901 28Februar, Schaltjahre 2 1904 29
monat inkorrekt, jahr korrekt 17 1901 MonatUngueltigmonat korrekt, jahr inkorrekt 7 -1901 JahrUngueltigmonat inkorrekt, jahr inkorrekt 17 -1901 MonatUngueltig
∨JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 505 / 634
Software-Test
Komponententest mit JUnit
i m p o r t j u n i t . f ramework . ∗ ;
p u b l i c c l a s s K a l e n d e r T e s t e x t e n d s TestCase {
p u b l i c K a l e n d e r T e s t ( S t r i n g name ) {s u p e r ( name ) ;
}. . .// Test−Methoden. . .p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
j u n i t . s w i n g u i . TestRunner . run ( K a l e n d e r T e s t . c l a s s ) ;}
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 506 / 634
Software-Test
Komponententest mit JUnit
p u b l i c v o i d testTageProMonat1 ( ) {// 31−Tage−Monat , Nicht−S c h a l t j a h r ea s s e r t E q u a l s ( 3 1 , K a l e n d e r . TageProMonat ( 7 , 1 9 0 1 ) ) ;
}
p u b l i c v o i d testTageProMonat9 ( ) {// monat i n k o r r e k t , j a h r i n k o r r e k tt r y { i n t t = K a l e n d e r . TageProMonat ( 1 3 , −1901);
a s s e r t T r u e ( f a l s e ) ; }c a t c h ( K a l e n d e r . J a h r U n g u e l t i g j e ) {} // expec t edc a t c h ( K a l e n d e r . MonatUngue l t ig me) {} // expec t edc a t c h ( E x c e p t i o n e ) { f a i l ( ” E x c e p t i o n e x p e c t e d ” ) ; }
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 507 / 634
Software-Test
Komponententest mit JUnit
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 508 / 634
Software-Test
Grenztest
Beobachtung: “Off-by-one”-Fehler kommen haufig vor.
Idee: Grenzen (Randbereiche) von Aquivalenzklassen testen.
Schaltjahrregel: Ein Jahr ist ein Schaltjahr, wenn
es durch 4 teilbar ist,
es sei denn, es ist durch 100 teilbar,
es sei denn, es ist durch 400 teilbar
2000 ist ein Schaltjahr, 1900 ist kein Schaltjahr.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 509 / 634
Software-Test
Grenztest
Aquivalenzklasse monat jahr Soll
Schaltjahre teilbar durch 400 2 2000 29Nicht-Schaltjahre teilbar durch 100 2 1900 28
gultige Monate 1 2000 31gultige Monate 12 2000 31
Nichtpositive ungultige Monate 0 1234 MonatUngueltigPositive ungultige Monate 13 1234 MonatUngueltiggultiges Jahr 2 0 29gultiges Jahr 3 Max-Int 31
ungultiges Jahr 2 -1 JahrUngueltig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 510 / 634
Software-Test
Pfadtest
Ziel: Testfalle sollten alle Code-Teile testen.
Idee: Konstruiere Testfalle, die jeden moglichen Pfad mindestens einmalausfuhren.
Ausgangspunkt: Kontrollflussgraph (KFG) pro Methode.
Knoten: Anweisungen und Pradikate
zwei weitere Knoten: eindeutiger Anfang und Ende einer Methode
Kanten: Kontrollfluss zwischen Anweisungen (unbedingt) undPradikaten (bedingt)
Pfad: Menge von Kanten, die vom Anfang zum Ende des KFGs fuhren
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 511 / 634
Software-Test
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 512 / 634
Software-Test
Maße der Testabdeckung
C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 513 / 634
Maße der Testabdeckung
C0, Anweisungsuberdeckung (Befehlsabdeckung/Statement-Coverage):Verhaltnis von Anzahl der mit Testdaten durchlaufenenAnweisungen zur Gesamtanzahl der Anweisungen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Befehlsabdeckung / statement coverage / C0-Abdeckung: Gesucht ist eine Menge von Testfallen, die jeden Befehlin dem zu testenden Code mindestens einmal ausfuhren. Dieses Kriterium ist sehr schwach, denn es werden in derRegel nur sehr wenige Fehler (20%) gefunden. Fehler entstehen meist dadurch, dass Befehle in bestimmtenZustanden ausgefuhrt werden und nicht nur in irgendeinem.Ein Code-Coverage-Tool kann helfen, um zu sehen, welche Befehle nicht oder selten ausgefuhrt werden. Denn einnotwendiges Kriterium ist die Befehlsabdeckung allemal.
Software-Test
Maße der Testabdeckung
C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 514 / 634
Maße der Testabdeckung
C1, Zweig-/Entscheidungsuberdeckung Verhaltnis von Anzahl der mitTestdaten durchlaufenen Zweige zur Gesamtanzahl derZweige.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Jedes Pradikat muss im Code mindestens einmal wahr und einmal falsch sein. Schließt die Befehlabdeckung mit ein(es sei denn, es gibt unerreichbare Befehle) und ist aquivalent zur Befehlsabdeckung, wenn jeder wahr/falsch-Fallauch mindestens einen Befehl beinhaltet. Dieses Kriterium ist weiterhin relativ schwach. Erfahrungsgemaß 25%Fehlerfindung.
Software-Test
Maße der Testabdeckung
C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.
i := 1 ;l o o p
found := a ( i ) = key ;e x i t when found o r i = M a x E n t r i e s ;i := i + 1 ;
end l o o p ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 515 / 634
Maße der Testabdeckung
C2, Bedingungsabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Terme innerhalb von Entscheidungen zurGesamtanzahl der Terme.
i := 1 ;l o o p
found := a ( i ) = key ;e x i t when found o r i = M a x E n t r i e s ;i := i + 1 ;
end l o o p ;
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Nur verschieden von C1, wenn logische Operatoren keine Short-Circuit-Operatoren sind (d.h. es werdengrundsatzlich alle Operanden eines logischen Operators ausgewertet).In jedem Pradikat wird jeder Bedingungsteil (Konjunktions- oder Alternationsglied) mindestens einmal wahr undeinmal falsch gesetzt.N.B.: Das umfasst nicht die Entscheidungsfallabdeckung:true and false→ false-Kantefalse and true→ false-Kante(sofern der Operator and kein Short-Circuit-Operator ist).Man sollte beide kombinieren.Man bedenke, dass false and x→ false ist wenn x keine Seiteneffekte hat.
Software-Test
Maße der Testabdeckung
C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 516 / 634
Maße der Testabdeckung
C3, Abdeckung aller Bedingungskombinationen Verhaltnis von Anzahl dermit Testdaten durchlaufenen Bedingungskombinationen zurGesamtanzahl der Bedingungskombinationen.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
Bedingungenkombinationsabdeckung / multiple condition coverage: Hier werden Pradikate gemaß einerWahrheitstabelle alle Bedingungskombinationen aller in allen Kombinationen mal wahr und mal falsch gesetzt.Interessanterweise bringt dies nicht viel mehr an Erfolg, aber viel mehr an Aufwand. ·
Software-Test
Maße der Testabdeckung
C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 517 / 634
Maße der Testabdeckung
C4, Pfadabdeckung Verhaltnis von Anzahl der mit Testdatendurchlaufenen Pfade zur Gesamtanzahl der Pfade.
throw new JahrUngueltig
[jahr < 1]
n = 32[monat in {1,3,5,7,10,12}]
n = 30[monat in {4,6,9,11}]
[monat == 2]
throw new MonatUngueltig n = 29 n = 28
[istSchaltJahr(jahr)]
return n
Anfang
Ende
Aktivität
VerzweigungBedingung
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Maße der Testabdeckung
(Eingeschrankte) Pfadabdeckung: Hier werden auch bei Schleifen mehrere Durchlaufe gemacht (keinmal, einmal,zweimal, typische Anzahl, maximale Anzahl). In aller Regel wird nicht auf diese Weise getestet, da der Aufwandsehr groß ist.
Software-Test
Probleme beim Pfadtest
Unrealisierbare Pfade:
f o r ( i = 0 ; i < o . f o o ( ) ; i ++) // immer o . foo ( ) == 0 ?{
x = . . .}
. . .x. . . // hat x d e f i n i e r t e n Wert?
i f ( p ) {. . .}
i f ( q ) { // p => not q??. . .
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 518 / 634
Software-Test
Polymorphismustest
c l a s s T { p u b l i c i n t f o o ( ) ; }c l a s s NT e x t e n d s T { p u b l i c i n t f o o ( ) ; }c l a s s F a c t o r y { T c r e a t e ( i n t i ) ; }
c l a s s UnderTest {v o i d bar ( i n t i ){ T t = ( new F a c t o r y ) . c r e a t e ( i ) ;
i f ( t . f o o ( ) > 0)doSomething ( ) ;
}}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 519 / 634
Polymorphismustest
c l a s s T { p u b l i c i n t f o o ( ) ; }c l a s s NT e x t e n d s T { p u b l i c i n t f o o ( ) ; }c l a s s F a c t o r y { T c r e a t e ( i n t i ) ; }
c l a s s UnderTest {v o i d bar ( i n t i ){ T t = ( new F a c t o r y ) . c r e a t e ( i ) ;
i f ( t . f o o ( ) > 0)doSomething ( ) ;
}}
20
09
-02
-09
Software-Projekt
Software-Test
Maße der Testabdeckung
Polymorphismustest
Methode bar kann nicht in Isolation getestet werden. Welches foo im Beispiel ausgefuhrt wird, hangt vomdynamischen Typ von t ab. Davon hangen wiederum die weiteren Pfade ab.
Software-Test
Zustandsbasiertes Testen
Verhalten von Komponente hangt ab von
der Eingabe
ihrem Zustand
c l a s s Stack {p u b l i c s t a t i c c l a s s EmptyStack e x t e n d s E x c e p t i o n {} ;p u b l i c s t a t i c c l a s s F u l l S t a c k e x t e n d s E x c e p t i o n {} ;
p u b l i c Stack ( i n t maxSize ) {. . .} ;
p u b l i c b o o l e a n isEmpty ( ) {. . .} ;p u b l i c i n t s i z e ( ) {. . .} ;
p u b l i c Object top ( ) throws EmptyStack {. . .} ;p u b l i c v o i d push ( Object o ) throws F u l l S t a c k {. . .} ;p u b l i c v o i d pop ( ) throws EmptyStack {. . .} ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 520 / 634
Software-Test
Zustande eines Stacks
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 521 / 634
Software-Test
Zustandsbasiertes Testen
Fur alle Zustande einer Komponente:
Komponente wird in zu testenden Zustand gebracht
Test fur alle moglichen Stimuli:
korrekte Eingaben,fehlerhafte Eingabenund Aktionen, die Zustandsubergange bewirken
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 522 / 634
Software-Test
Zustandsbasiertes Testen I
p u b l i c v o i d t e s t S t a t e F u l l ( ) {// t e s t o f S ta t e f u l lf i n a l i n t max = 1 0 0 ;Stack s = new Stack ( max ) ;Object l a s t = new Object ( ) ;
// put Stack i n t o s t a t e f u l lf o r ( i n t i = 1 ; i <max ; i ++) {
l a s t = new Object ( ) ;s . push ( l a s t ) ;// e x c e p t i o n ( i f any ) w i l l be caught by JUn i t
}
// t e s t l e g a l a c t i o n ’ s i z e ’ ; no t r a n s i t i o na s s e r t E q u a l s (max , s . s i z e ( ) ) ;
// t e s t l e g a l a c t i o n ’ top ’ ; no t r a n s i t i o na s s e r t E q u a l s ( l a s t , s . top ( ) ) ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 523 / 634
Software-Test
Zustandsbasiertes Testen II
// t e s t l e g a l a c t i o n ’ i sEmpty ’ ; no t r a n s i t i o na s s e r t E q u a l s ( f a l s e , s . i sEmpty ( ) ) ;
// t e s t i l l e g a l a c t i o n ’ push ’t r y { s . push ( new Object ( ) ) ; f a i l ( ” e x c e p t i o n e x p e c t e d ” ) ; }c a t c h ( Stack . F u l l S t a c k e ) {} // OK
// t e s t l e g a l a c t i o n / t r a n s i t i o n ’ pop ’s . pop ( ) ;
// r e v e r s e t r a n s i t i o ns . push ( new Object ( ) ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 524 / 634
Software-Test
Vergleich von White- und Black-Box-Tests
Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.
White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.
Eigenschaft Black-Box-Test White-Box-Test
Test auf Basis von Schnittstellen- Losungspezifikation
Wiederverwendung bei ja eingeschrankt
Anderung der Struktur
Geeignet fur Testart alle Komponententest
Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 525 / 634
Vergleich von White- und Black-Box-Tests
Black-Box-Tests (Funktionstests) betrachten den Prufling als schwarzeBox. Sie setzen keine Kenntnisse uber die Interna voraus.
White-Box-Tests (Strukturtests, Glass-Box-Tests) betrachten Interna desPruflings, um Testfalle zu entwickeln.
Eigenschaft Black-Box-Test White-Box-Test
Test auf Basis von Schnittstellen- Losungspezifikation
Wiederverwendung bei ja eingeschrankt
Anderung der Struktur
Geeignet fur Testart alle Komponententest
Finden Fehler aufgrund von Abweichung von Spez. eher Kodierfehler
20
09
-02
-09
Software-Projekt
Software-Test
Zustandsbasiertes Testen
Vergleich von White- und Black-Box-Tests
White-Box Methoden eignen sich lediglich fur den Modultest, allenfalls noch fur den Integrationstest. Die Idee istes, die Testfalle anhand der inneren Programmstruktur zu finden.Achtung: White-Box-Testing testet keine fehlenden Pfade oder Anweisungen. Das ist eine echte Schwache, denn eswird nur das getestet, woran der Programmierer auch wirklich (wenn auch evtl. fehlerhaft) gedacht hat!Black-Box-Tests konnen wiederverwendet werden, wenn sie die Struktur, aber nicht das Verhalten andert.
Software-Test
Black- versus White-Box-Tests
Nicht entweder-oder, sondern sowohl-als-auch!
Komplementare Verwendung:
1 Erstelle Funktionstest
2 Messe Abdeckung
3 Wenn Abdeckung nicht ausreichend; erganze durch Strukturtest;zuruck zu 2.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 526 / 634
Software-Test
Strategien des Integrationstests I
Urknalltest: alle Komponenten werden einzeln entwickelt und dann ineinem Schritt integriert
→ erschwert Fehlersuche
Bottom-Up: Integration erfolgt inkrementell in umgekehrter Richtungzur Benutzt-Beziehung
→ keine Testrumpfe notwendig (aber Testtreiber)→ Fehler in der obersten Schicht werden sehr spat entdeckt; die enthalten
jedoch die Applikationslogik
Top-Down: Integration erfolgt in Richtung der Benutzt-Beziehung
→ Fehler in der obersten Schicht werden sehr fruh entdeckt→ Testrumpfe notwendig
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 527 / 634
Software-Test
Strategien des Integrationstests II
Sandwich-Test-Strategie: Kombination von Top-Down undBottom-Up
Identifikation der zu testenden Schicht: Zielschicht
zuerst: individuelle Komponententests
dann: kombinierte Schichttests:- Oberschichttest mit Zielschicht- Zielschicht mit Unterschicht- alle Schichten zusammen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 528 / 634
Software-Test
Leistungstests
Hartetest: viele gleichzeitige Anfragen
Volumentest: große Datenmengen
Sicherheitstests: Sicherheitslucken aufspuren
Zeitvorgabentests: werden spezifizierte Antwortzeiten eingehalten?
Erholungstests: Tests auf Erholung von fehlerhaften Zustanden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 529 / 634
Software-Test
Zusammenfassung der Testarten
Strategie:− Urknall− Top−Down− Bottom−Up− Sandwich
SystemtestIntegrationstestKomponententest
Äquivalenztest
Grenztest zustands−basierter Test
Pfadtest
White−Box−TestBlack−Box−Test
Härtetest
Leistungstest
Feldtest
Erholungstest
Zeitvorgabentest
Funktionstest Installationstest
Akzeptanztest
Sicherheitstest
Volumentest
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 530 / 634
Software-Test
Testdokumentation: Aufzeichnung der Testaktivitaten
Testplan: Projektplan furs Testen
Testfallspezifikation: Dokumentation eines jeden Testfalls
Testvorfallbericht (Testprotokoll): Ergebnisse des Tests undUnterschiede zu erwarteten Ergebnissen
Testubersicht: Auflistung aller Fehler (entdeckt und noch zuuntersuchen)
→ Analyse und Priorisierung aller Fehler und deren Korrekturen
Testplan und Testfallspezifikation konnen sehr fruh schon erstellt werden.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 531 / 634
Software-Test
Testplan (IEEE Std. 829-1998 1998)
1. Einfuhrung
2. Beziehung zu anderen Dokumenten
3. Systemuberblick
4. Merkmale, die getestet/nicht getestet werden mussen
5. Abnahmekriterien
6. Vorgehensweise
7. Aufhebung und Wiederaufnahme
8. Zu prufendes Material (Hardware-/Softwareanforderungen)
9. Testfalle
10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 532 / 634
Testplan (IEEE Std. 829-1998 1998)
1. Einfuhrung
2. Beziehung zu anderen Dokumenten
3. Systemuberblick
4. Merkmale, die getestet/nicht getestet werden mussen
5. Abnahmekriterien
6. Vorgehensweise
7. Aufhebung und Wiederaufnahme
8. Zu prufendes Material (Hardware-/Softwareanforderungen)
9. Testfalle
10. Testzeitplan: Verantwortlichkeiten, Personalausstattung undWeiterbildungsbelange, Risiken und Schadensmoglichkeiten, Zeitplan2
00
9-0
2-0
9
Software-Projekt
Software-Test
Testplan
Testplan (IEEE Std. 829-1998 1998)
(Entspricht einer vereinfachten Variante von IEEE Std. 829-1998 (1998).)2.: Beziehung zu Anforderungsspezifikation und Architekturbeschreibung; Einfuhrung von Namenskonventionen, umTests und Anforderungen/Architektur in Beziehung zu setzen.
3.: Uberblick uber System hinsichtlich jener Komponenten, die durch Komponententests gepruft werden sollen.Granularitat der Komponenten und ihre Abhangigkeiten.4.: Konzentration auf funktionale Gesichtspunkte beim Testen; identifiziert alle merkmale und Kombinationen vonMerkmalen, die getestet werden mussen. Beschreibt auch diejenigen Merkmale, die nicht getestet werden und gibtGrunde dafur an.5.: Spezifiziert Abnahmekriterien fur die Tests (z.B. Testabdeckung).6.: Allgemeine Vorgehensweisen beim Testablauf; Integrationsstrategien.7.: Kriterien, wann Testaktivitaten ausgesetzt werden. Testaktivitaten, die wiederholt werden mussen, wenn dasTesten wieder aufgenommen wird.8.: Notwendige Betriebsmittel: physikalische Eigenarten der Umgebung sowie Anforderungen an Software,Hardware, Testwerkzeuge und andere Betriebsmittel (z.B. Arbeitsraum).9.: (das Herzstuck des Testplans) Auflistung aller Testfalle anhand individueller Testfallspezifikationen.
Software-Test
Testfallspezifikation
Testfallbezeichner: eindeutiger Name des Testfalls; am BestenNamenskonventionen benutzen
Testobjekte: Komponenten (und deren Merkmale), die getestetwerden sollen
Eingabespezifikationen: erwartete Eingaben
Ausgabespezifikationen: erwartete Ausgaben
Umgebungserfordernisse: notwendige Software- undHardware-Plattform sowie Testrumpfe und -stumpfe
Besondere prozedurale Anforderungen: Einschrankungen wieZeitvorgaben, Belastung oder Eingreifen durch den Operateur
Abhangigkeiten zwischen Testfallen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 533 / 634
Software-Test
Testschadensbericht
welche Merkmale wurden getestet?
wurden sie erfullt?
bei Storfallen: wie konnen sie reproduziert werden?
→ Sammlung und Priorisierung in der Testubersicht→ Test 6= Fehlersuche bzw. -korrektur!
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 534 / 634
Software-Test
Wiederholungsfragen I
Erlautern Sie die Unterschiede in den Fehlerbegriffen Storfall,fehlerhafter Zustand und Fehler.
Was ist ein positiver, was ein negativer Testfall?
Wer sollte testen?
Welche Arten von Tests gibt es?
Was ist ein Testfall?
Welche Aufgabe erfullen Teststumpfe und -treiber fur denKomponententest?
Was ist der Unterschied von Black- und Glass-Box-Tests?
Welche Techniken des Komponententests gibt es?
Erlautern Sie die Idee von Aquivalenztests am konkreten Beispiel.
Erlautern Sie die Idee von Grenztests am konkreten Beispiel.
Erlautern Sie die Idee von Pfadtests am konkreten Beispiel.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 535 / 634
Software-Test
Wiederholungsfragen II
Wie benutzt man JUnit fur den Komponententest?
Wozu benotigt man Polymorphismustests?
Erlautern Sie die Idee von zustandsbasierten Tests am konkretenBeispiel.
Welche Testabdeckungsmaße gibt es?
Nennen Sie Strategien fur Integrationstests und diskutieren Sie sie.
Erlautern Sie Leistungstests.
Was ist ein Testplan?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 536 / 634
Implementierung
Implementierung
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragen
11 ImplementierungMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 537 / 634
Implementierung
Lernziele
Feinentwurf eines Systems durchfuhren konnen
Programmierrichtlinien entwerfen, kennen und einhalten
Verstandnis fur Codequalitat entwickeln
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 538 / 634
Implementierung
Feinentwurf
Der Feinentwurf ist die Brucke zwischen abstrakter Architektur unddetailliertem Code.
Er legt fest:
Datenstrukturen
→ Klassendiagramme mit zusatzlichen Implementierungsdetails; (z.B.Navigierbarkeit, Implementierung von Assoziationen, Behandlung vonMehrfachvererbung oder weiteren Implementierungsklassen etc.)
Ablaufe
→ Zustandsautomaten→ Aktivitatsdiagramme→ Sequenzdiagramme
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 539 / 634
Implementierung
Architekturkonformitat
Architekturbeschreibung und Quellcode sind zwei voneinanderabhangige, aber separate Dokumente
in der Weiterentwicklung werden oft Anderungen im Quellcodegemacht, die in der Architekturbeschreibung nicht nachgezogenwerden
Folge: Architekturbeschreibung wird obsolet
Planung erfolgt aber meist auf Basis der Architekturbeschreibung
Folge: boses Erwachen in der Umsetzung
→ Reflektionsmethode von Murphy u. a. (1995, 2001) zurSynchronisation von Modulsicht und Quellcode
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 540 / 634
Implementierung
Reflektionsmethode (Murphy u. a. 2001)
1 Stelle Architekturmodell auf
2 Extrahiere Implementierungsmodell
3 Bilde Modelle aufeinander ab
4 Berechne Reflektionsmodell
5 Verfeinere/korrigiere
Beispiel
H3H2H1
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 541 / 634
Implementierung
Warum Programmierrichtlinien?
bis zu 80% der Gesamtkosten fur Software sind Wartungskosten
Originalautor wartet Software oft nicht selbst
Code muss lesbar und verstandlich sein
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 543 / 634
Implementierung
Programmierrichtlinien: Schlechte Beispiele
// i n k o n s i s t e n t e MethodennamenT e x t F i e l d . s e t T e x t ( ) ;L a b e l . s e t T e x t ( ) ;Button . s e t L a b e l ( ) ;A b s t r a c t B u t t o n . s e t T e x t ( ) ;
// i n k o n s i s t e n t e Pa r ame t e r s o r t i e r u ngS t r i n g B u f f e r . s e t C h a r A t ( i n t index , c h a r c ) ;V e c t o r . s e t E l e m e n t A t ( Object o , i n t i n d e x ) ;L i s t . s e t ( i n t index , Object o ) ;
// l e n g t h oder s i z e ?l e n O f A r r a y = myArray . l e n g t h ;l e n O f S t r i n g = myStr ing . l e n g t h ( ) ;myL i s t . s i z e ( ) ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 545 / 634
Implementierung
Programmierrichtlinien: Sinnvolle Namen
// S i n n l o s e Namens t a t i c f i n a l i n t ONE = 1 ;s t a t i c f i n a l i n t TEN = 1 0 ;s t a t i c f i n a l i n t TWENTY = 3 0 ;
// b e s s e rs t a t i c f i n a l i n t INPUT MODE = 1 ;s t a t i c f i n a l i n t INPUT BUFSIZE = 1 0 ;s t a t i c f i n a l i n t OUTPUT BUFSIZE = 3 0 ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 546 / 634
Implementierung
Programmierrichtlinien: Lokale Variablen
// Man kann ’ s auch u b e r t r e i b e n . . .f o r ( i n t o u t e r I n d e x = 0 ; o u t e r I n d e x < maxOuter Index ;
o u t e r I n d e x++){
f o r ( i n t i n n e r I n d e x = 0 ; i n n e r I n d e x < o u t e r I n d e x ;i n n e r I n d e x ++)
{r e s u l t M a t r i x [ o u t e r I n d e x ] [ i n n e r I n d e x ]
= o u t e r I n d e x ∗ i n n e r I n d e x ;}
}
// S c h l e i f e n v a r i a b l e n / I n d i z e s => ku r ze Namenf o r ( i n t i = 0 ; i < max ; i ++){
f o r ( i n t j = 0 ; j < i ; j ++){
r e s u l t [ i ] [ j ] = i ∗ j ;}
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 547 / 634
Implementierung
Ausdrucke in naturlicher Form
// schwer v e r s t a n d l i c h e r Ausdrucki f ( ! ( b l o c k I d < a c t b l k s ) | | ! ( b l o c k I d >= u n b l o c k s ) )
// b e s s e ri f ( ( b l o c k I d >= a c t b l k s ) | | ( b l o c k I d < u n b l o c k s ) )
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 548 / 634
Implementierung
Magische Zahlen
// Wer v e r s t e h t d i e s e Zah len ?m = 60 ∗ h + em ;s = 60 ∗ m + e s ;t c = 60 ∗ b + l c ;
// So i s t ’ s b e s s e r .s t a t i c f i n a l s h o r t MINUTES PER HOUR = 6 0 ;s t a t i c f i n a l s h o r t SECONDS PER MINUTE = 6 0 ;s t a t i c f i n a l s h o r t CLIPS PER BOX = 6 0 ;...m inutes = MINUTES PER HOUR ∗ h o u r s + e x t r a M i n u t e s ;s e c o n d s = SECONDS PER MINUTE ∗ minutes + e x t r a S e c o n d s ;t o t a l C l i p s = CLIPS PER BOX ∗ boxes + l o o s e C l i p s ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 549 / 634
Implementierung
Hartcodiert: String-Literale im Code
t r y{
s t o r e . o p e n S t o r e ( ” . / c o n f i g . xml ” , ”PSA” ) ;manager . r e a d C o n f i g u r a t i o n ( s t o r e ) ;
}c a t c h ( T r e e S t o r e E x c e p t i o n e ){
System . e r r . p r i n t l n( ” Konnte K o n f i g u r a t i o n s d a t e i n i c h t l e s e n . ” ) ;
}c a t c h ( C o n f i g E x c e p t i o n x ){
System . e r r . p r i n t l n( ” F e h l e r beim A u s l e s e n d e r K o n f i g u r a t i o n s d a t e i . ” ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 550 / 634
Implementierung
Character sind zwar Zahlen, aber...
// Wie b i t t e ?i f ( ( c >= 65) && ( c <= 90) ). . .
i f ( ( c >= ’A ’ ) && ( c <= ’Z ’ ) ). . .
// Ach so !i f ( C h a r a c t e r . i s U p p e r C a s e ( c ) )
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 551 / 634
Implementierung
Sprachkonstrukte zur Berechnung von Großen
// Doppe l te Z a h l e n r e f e r e n zc h a r buf [ ] = new c h a r [ 1 0 2 4 ] ;f o r ( i n t i = 0 ; i < 1 0 2 4 ; i ++)
// Sprachmechanismus nutzen !c h a r buf [ ] = new c h a r [ 1 0 2 4 ] ;f o r ( i n t i = 0 ; i < buf . l e n g t h ; i ++)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 552 / 634
Implementierung
Uberflussige Kommentare
/∗∗ d e f a u l t∗/
d e f a u l t :b r e a k ;
/∗ r e t u r n SUCCESS ∗/r e t u r n SUCCESS ;
zeroCount++: /∗ I nc r ement z e r o e n t r y coun t e r ∗/
/∗ I n i t i a l i z e t o t a l to numberRece ived . ∗/Node . t o t a l = Node . numberRece ived ;
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 553 / 634
Implementierung
Uberflussige Kommentare
w h i l e ( ( ( c = getChar ( ) ) != EOF) && ( i s S p a c e ( c ) ) ); /∗ s k i p wh i t e space ∗/
i f ( c == EOF) /∗ end o f f i l e ∗/t y p e = END OF FILE ;
e l s e i f ( c == ’ ( ’ ) /∗ l e f t paren ∗/t y p e = LEFT PAREN ;
e l s e i f ( c == ’ ) ’ ) /∗ r i g h t paren ∗/t y p e = RIGHT PAREN ;
e l s e i f ( c == ’ ; ’ ) /∗ s em i co l on ∗/t y p e = SEMICOLON ;
e l s e i f ( i sOp ( c ) ) /∗ op e r a t o r ∗/t y p e = OPERATOR;
e l s e i f ( i s D i g i t ( c ) ) /∗ number ∗/t y p e = NUMBER;. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 554 / 634
Implementierung
Verschluckte (hicks) Exceptions
t r y{
F i l e O u t p u t S t r e a m out = new F i l e O u t p u t S t r e a m ( strName ) ;. . .out . f l u s h ( ) ;out . c l o s e ( ) ;
}c a t c h ( I O E x c e p t i o n e ){ ;}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 555 / 634
Implementierung
idKldW
i n t f ( i n t f [ ] , i n t l , I tem k ){ i n t i ;
f o r ( i =0; i < l ; i ++)i f ( f [ i ] == k ) r e t u r n i ;
}
In der Kurze liegt die Wurze (idKldW)?
i n t I n d e x ( i n t ∗ f i e l d , i n t l e n g t h , I tem key ){ i n t i ;
f o r ( i =0; i < l e n g t h ; i ++)i f ( f i e l d [ i ] == key ) r e t u r n i ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 556 / 634
Implementierung
Software-Redundanz
for (j = 1; j < MAX; j++) { x = func() * y + x;}
for (i = 1; i < MAX; i++) { x = func() * y + x;} for (i = 1; i < MAX; i++) {
x = func() * y + x;}
for (i = 1; i < MAX; i++) { x2 = func() * y2 + x2;}
for (i = 1; i < MAX; i++) { x1 = func() * y1 + x1;}
...
...
...
...
...
......
...
foo.c bar.c fred.c
Typisch: 5 – 30 % des Codes sind redundant. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 557 / 634
Implementierung
Software-Redundanz
for (i = 1; i < MAX; i++) { *x = func() * y + *x;}
}
float *x, float y) {void set_coordinate (
int i;
...
...
......
...
......
...
set_coordinate (&x, y);
set_coordinate (&x, y);
set_coordinate (&x, y);set_coordinate (&x1, y1);
set_coordinate (&x2, y2);
foo.c bar.c fred.c
. . . und konnen abstrahiert werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 558 / 634
Implementierung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 559 / 634
Implementierung
Uberlange Methoden
//// java provides a variety of conditional branch instructions, so// that a number of operators merit special handling:// constant operand
5 // negation (we eliminate it)// equality// ?: && and || (partial evaluation)// comparisons// Other expressions are just evaluated and the appropriate
10 // branch emitted.//// TODO: return a bool that is true if the statement being branched over is// even needed (if statements and other places might have a constant false// expression, allowing the next block of code to be skipped entirely).
15 //void ByteCode::EmitBranchIfExpression(AstExpression* p, bool cond, Label& lab, AstStatement* over){ p = StripNops(p);
20 assert(p −> Type() == control.boolean_type);
if (p −> IsConstant()) { if (IsZero(p) != cond)
25 EmitBranch(OP_GOTO, lab, over); return; }
AstPreUnaryExpression* pre = p −> PreUnaryExpressionCast();30 if (pre) // must be !
{ // // branch_if(!e,c,l) => branch_if(e,!c,l) //
35 assert(pre −> Tag() == AstPreUnaryExpression::NOT); EmitBranchIfExpression(pre −> expression, ! cond, lab, over); return; }
40 AstConditionalExpression* conditional = p −> ConditionalExpressionCast(); if (conditional) { if (conditional −> test_expression −> IsConstant()) {
45 // // branch_if(true?a:b, cond, lab) => branch_if(a, cond, lab); // branch_if(false?a:b, cond, lab) => branch_if(b, cond, lab); // EmitBranchIfExpression((IsZero(conditional −> test_expression)
50 ? conditional −> false_expression : conditional −> true_expression), cond, lab, over); } else if (IsOne(conditional −> true_expression))
55 { // // branch_if(expr?true:true, c, l) => expr, branch if c // branch_if(expr?true:false, c, l) => branch_if(expr, c, l); // branch_if(expr?true:b, c, l) => branch_if(expr || b, c, l);
60 // if (IsOne(conditional −> false_expression)) { EmitExpression(conditional −> test_expression, false); if (cond)
65 EmitBranch(OP_GOTO, lab, over); } else if (IsZero(conditional −> false_expression)) { EmitBranchIfExpression(conditional −> test_expression,
70 cond, lab, over);
Mai 31, 05 7:18 Seite 1/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 1/12
} else if (cond) { EmitBranchIfExpression(conditional −> test_expression, true,
75 lab, over); EmitBranchIfExpression(conditional −> false_expression, true, lab, over); } else
80 { Label skip; EmitBranchIfExpression(conditional −> test_expression, true, skip, over); EmitBranchIfExpression(conditional −> false_expression, false,
85 lab, over); DefineLabel(skip); CompleteLabel(skip); } }
90 else if (IsZero(conditional −> true_expression)) { // // branch_if(expr?false:true, c, l) => branch_if(expr, ! c, l); // branch_if(expr?false:false, c, l) => expr, branch if ! c
95 // branch_if(expr?false:b, c, l) => branch_if(!expr && b, c, l); // if (IsOne(conditional −> false_expression)) { EmitBranchIfExpression(conditional −> test_expression,
100 ! cond, lab, over); } else if (IsZero(conditional −> false_expression)) { EmitExpression(conditional −> test_expression, false);
105 if (! cond) EmitBranch(OP_GOTO, lab, over); } else if (! cond) {
110 EmitBranchIfExpression(conditional −> test_expression, true, lab, over); EmitBranchIfExpression(conditional −> false_expression, false, lab, over); }
115 else { Label skip; EmitBranchIfExpression(conditional −> test_expression, true, skip, over);
120 EmitBranchIfExpression(conditional −> false_expression, true, lab, over); DefineLabel(skip); CompleteLabel(skip); }
125 } else if (IsOne(conditional −> false_expression)) { // // branch_if(expr?a:true, c, l) => branch_if(!expr || a, c, l);
130 // if (cond) { EmitBranchIfExpression(conditional −> test_expression, false, lab, over);
135 EmitBranchIfExpression(conditional −> true_expression, true, lab, over); } else {
140 Label skip;
Mai 31, 05 7:18 Seite 2/12b.cppGedruckt von Rainer Koschke
2/12 Dienstag Mai 31, 2005
EmitBranchIfExpression(conditional −> test_expression, false, skip, over); EmitBranchIfExpression(conditional −> true_expression, false, lab, over);
145 DefineLabel(skip); CompleteLabel(skip); } } else if (IsZero(conditional −> false_expression))
150 { // // branch_if(expr?a:false, c, l) => branch_if(expr && a, c, l); // if (! cond)
155 { EmitBranchIfExpression(conditional −> test_expression, false, lab, over); EmitBranchIfExpression(conditional −> true_expression, false, lab, over);
160 } else { Label skip; EmitBranchIfExpression(conditional −> test_expression, false,
165 skip, over); EmitBranchIfExpression(conditional −> true_expression, true, lab, over); DefineLabel(skip); CompleteLabel(skip);
170 } } else { //
175 // branch_if(expr?a:b, c, l) => // branch_if(expr, false, lab1) // branch_if(a, c, l) // goto lab2 // lab1: branch_if(b, c, l)
180 // lab2: // Label lab1, lab2; EmitBranchIfExpression(conditional −> test_expression, false, lab1, over);
185 EmitBranchIfExpression(conditional −> true_expression, cond, lab, over); EmitBranch(OP_GOTO, lab2, over); DefineLabel(lab1); CompleteLabel(lab1);
190 EmitBranchIfExpression(conditional −> false_expression, cond, lab, over); DefineLabel(lab2); CompleteLabel(lab2); }
195 return; }
AstInstanceofExpression* instanceof = p −> InstanceofExpressionCast(); if (instanceof)
200 { AstExpression* expr = StripNops(instanceof −> expression); TypeSymbol* left_type = expr −> Type(); TypeSymbol* right_type = instanceof −> type −> symbol; if (right_type −> num_dimensions > 255)
205 { semantic.ReportSemError(SemanticError::ARRAY_OVERFLOW, instanceof −> type); } if (left_type == control.null_type)
210 {
Mai 31, 05 7:18 Seite 3/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 3/12
// // We know the result: false. But emit the left expression, // in case of side effects in (expr ? null : null). //
215 EmitExpression(expr, false ); if (! cond) EmitBranch(OP_GOTO, lab, over); } else if (expr −> IsConstant() || // a String constant
220 expr −> BinaryExpressionCast()) // a String concat { // // We know the result: true, since the expression is non−null // and String is a final class.
225 // assert(left_type == control.String()); EmitExpression(expr, false ); if (cond) EmitBranch(OP_GOTO, lab, over);
230 } else if ((expr −> ThisExpressionCast() || expr −> SuperExpressionCast() || expr −> ClassLiteralCast() || expr −> ClassCreationExpressionCast() ||
235 expr −> ArrayCreationExpressionCast()) && left_type −> IsSubtype(right_type)) { // // We know the result: true, since the expression is non−null.
240 // EmitExpression(expr, false ); if (cond) EmitBranch(OP_GOTO, lab, over); }
245 else { EmitExpression(expr); PutOp(OP_INSTANCEOF); PutU2(RegisterClass(right_type));
250 EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); } return; }
255 // // dispose of non−binary expression case by just evaluating // operand and emitting appropiate test. // AstBinaryExpression* bp = p −> BinaryExpressionCast();
260 if (! bp) { EmitExpression(p); EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); return;
265 }
// // Here if binary expression, so extract operands //
270 AstExpression* left = StripNops(bp −> left_expression); AstExpression* right = StripNops(bp −> right_expression);
TypeSymbol* left_type = left −> Type(); TypeSymbol* right_type = right −> Type();
275 switch (bp −> Tag()) { case AstBinaryExpression::AND_AND: // // branch_if(true&&b, cond, lab) => branch_if(b, cond, lab);
280 // branch_if(false&&b, cond, lab) => branch_if(false, cond, lab);
Mai 31, 05 7:18 Seite 4/12b.cppGedruckt von Rainer Koschke
4/12 Dienstag Mai 31, 2005
// if (left −> IsConstant()) { if (IsOne(left))
285 EmitBranchIfExpression(right, cond, lab, over); else if (! cond) EmitBranch(OP_GOTO, lab, over); } //
290 // branch_if(a&&true, cond, lab) => branch_if(a, cond, lab); // branch_if(a&&false, cond, lab) => emit(a), pop; for side effects // else if (right −> IsConstant()) {
295 if (IsOne(right)) EmitBranchIfExpression(left, cond, lab, over); else { EmitExpression(left, false);
300 if (! cond) EmitBranch(OP_GOTO, lab, over); } } //
305 // branch_if(a&&b, true, lab) => // branch_if(a,false,skip); // branch_if(b,true,lab); // skip: // branch_if(a&&b, false, lab) =>
310 // branch_if(a,false,lab); // branch_if(b,false,lab); // else if (cond) {
315 Label skip; EmitBranchIfExpression(left, false, skip, over); EmitBranchIfExpression(right, true, lab, over); DefineLabel(skip); CompleteLabel(skip);
320 } else { EmitBranchIfExpression(left, false, lab, over); EmitBranchIfExpression(right, false, lab, over);
325 } return; case AstBinaryExpression::OR_OR: // // branch_if(false||b, cond, lab) => branch_if(b, cond, lab);
330 // branch_if(true||b, cond, lab) => branch_if(true, cond, lab); // if (left −> IsConstant()) { if (IsZero(left))
335 EmitBranchIfExpression(right, cond, lab, over); else if (cond) EmitBranch(OP_GOTO, lab, over); } //
340 // branch_if(a||false, cond, lab) => branch_if(a, cond, lab); // branch_if(a||true, cond, lab) => emit(a), pop; for side effects // else if (right −> IsConstant()) {
345 if (IsZero(right)) EmitBranchIfExpression(left, cond, lab, over); else { EmitExpression(left, false);
350 if (cond)
Mai 31, 05 7:18 Seite 5/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 5/12
EmitBranch(OP_GOTO, lab, over); } } //
355 // branch_if(a||b,true,lab) => // branch_if(a,true,lab); // branch_if(b,true,lab); // branch_if(a||b,false,lab) => // branch_if(a,true,skip);
360 // branch_if(b,false,lab); // skip: // else if (cond) {
365 EmitBranchIfExpression(left, true, lab, over); EmitBranchIfExpression(right, true, lab, over); } else {
370 Label skip; EmitBranchIfExpression(left, true, skip, over); EmitBranchIfExpression(right, false, lab, over); DefineLabel(skip); CompleteLabel(skip);
375 } return; case AstBinaryExpression::XOR: // ^ on booleans is equavalent to != assert(left_type == control.boolean_type); // Fallthrough!
380 case AstBinaryExpression::EQUAL_EQUAL: case AstBinaryExpression::NOT_EQUAL: // // One of the operands is null. We must evaluate both operands, to get // any side effects in (expr ? null : null).
385 // if (left_type == control.null_type || right_type == control.null_type) { EmitExpression(left, left_type != control.null_type); EmitExpression(right, right_type != control.null_type);
390 if (left_type == right_type) { if (cond == (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL)) { EmitBranch(OP_GOTO, lab, over);
395 } } else { if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL)
400 EmitBranch(cond ? OP_IFNULL : OP_IFNONNULL, lab, over); else EmitBranch(cond ? OP_IFNONNULL : OP_IFNULL, lab, over); } return; }
405
// // One of the operands is true. Branch on the other. // if (left_type == control.boolean_type &&
410 (IsOne(left) || IsOne(right))) { EmitBranchIfExpression(IsOne(left) ? right : left, cond == (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL), lab, over);
415 return; }
// // Both operands are integer.
Mai 31, 05 7:18 Seite 6/12b.cppGedruckt von Rainer Koschke
6/12 Dienstag Mai 31, 2005
420 // if (control.IsSimpleIntegerValueType(left_type) || left_type == control.boolean_type) { assert(control.IsSimpleIntegerValueType(right_type) ||
425 right_type == control.boolean_type);
if (IsZero(left) || IsZero(right)) { if (left_type == control.boolean_type)
430 { // // One of the operands is false. Branch on the other. // EmitBranchIfExpression(IsZero(left) ? right : left,
435 cond == (bp −> Tag() != AstBinaryExpression::EQUAL_EQUAL), lab, over); } else {
440 // // One of the operands is zero. Only emit the other. // EmitExpression(IsZero(left) ? right : left);
445 if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) EmitBranch((cond ? OP_IFEQ : OP_IFNE), lab, over); else EmitBranch((cond ? OP_IFNE : OP_IFEQ), lab, over); } }
450 else { EmitExpression(left); EmitExpression(right);
455 if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) EmitBranch((cond ? OP_IF_ICMPEQ : OP_IF_ICMPNE), lab, over); else EmitBranch((cond ? OP_IF_ICMPNE : OP_IF_ICMPEQ), lab, over); }
460
return; }
//465 // Both operands are reference types: just do the comparison.
// if (IsReferenceType(left_type)) { assert(IsReferenceType(right_type));
470 EmitExpression(left); EmitExpression(right);
if (bp −> Tag() == AstBinaryExpression::EQUAL_EQUAL) EmitBranch((cond ? OP_IF_ACMPEQ : OP_IF_ACMPNE), lab, over);
475 else EmitBranch((cond ? OP_IF_ACMPNE : OP_IF_ACMPEQ), lab, over);
return; }
480 break; case AstBinaryExpression::IOR: // // One argument is false. Branch on other. //
485 if (IsZero(left) || IsZero(right)) { EmitBranchIfExpression(IsZero(left) ? right : left, cond, lab, over);
Mai 31, 05 7:18 Seite 7/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 7/12
return;490 }
// // One argument is true. Emit the other, and result is true. //
495 if (IsOne(left) || IsOne(right)) { EmitExpression(IsOne(left) ? right : left, false ); if (cond) EmitBranch(OP_GOTO, lab, over);
500 return; } break; case AstBinaryExpression::AND: //
505 // One argument is true. Branch on other. // if (IsOne(left) || IsOne(right)) { EmitBranchIfExpression(IsOne(left) ? right : left,
510 cond, lab, over); return; }
//515 // One argument is false. Emit the other, and result is false.
// if (IsZero(left) || IsZero(right)) { EmitExpression(IsZero(left) ? right : left, false );
520 if (! cond) EmitBranch(OP_GOTO, lab, over); return; } break;
525 default: break; }
//530 // here if not comparison, comparison for non−integral numeric types, or
// integral comparison for which no special casing needed. // Begin by dealing with non−comparisons // switch (bp −> Tag())
535 { case AstBinaryExpression::LESS: case AstBinaryExpression::LESS_EQUAL: case AstBinaryExpression::GREATER: case AstBinaryExpression::GREATER_EQUAL:
540 case AstBinaryExpression::EQUAL_EQUAL: case AstBinaryExpression::NOT_EQUAL: break; // break to continue comparison processing default: //
545 // not a comparison, get the (necessarily boolean) value // of the expression and branch on the result // EmitExpression(p); EmitBranch(cond ? OP_IFNE : OP_IFEQ, lab, over);
550 return; }
// //
555 // Opcode opcode = OP_NOP, op_true, op_false;
Mai 31, 05 7:18 Seite 8/12b.cppGedruckt von Rainer Koschke
8/12 Dienstag Mai 31, 2005
assert(left_type != control.boolean_type);560 if (control.IsSimpleIntegerValueType(left_type))
{ // // we have already dealt with EQUAL_EQUAL and NOT_EQUAL for the case // of two integers, but still need to look for comparisons for which
565 // one operand may be zero. // if (IsZero(left)) { EmitExpression(right);
570 switch (bp −> Tag()) { case AstBinaryExpression::LESS: // if (0 < x) same as if (x > 0) op_true = OP_IFGT;
575 op_false = OP_IFLE; break; case AstBinaryExpression::LESS_EQUAL: // if (0 <= x) same as if (x >= 0) op_true = OP_IFGE;
580 op_false = OP_IFLT; break; case AstBinaryExpression::GREATER: // if (0 > x) same as if (x < 0) op_true = OP_IFLT;
585 op_false = OP_IFGE; break; case AstBinaryExpression::GREATER_EQUAL: // if (0 >= x) same as if (x <= 0) op_true = OP_IFLE;
590 op_false = OP_IFGT; break; default: assert( false); break;
595 } } else if (IsZero(right)) { EmitExpression(left);
600
switch (bp −> Tag()) { case AstBinaryExpression::LESS: op_true = OP_IFLT;
605 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: op_true = OP_IFLE; op_false = OP_IFGT;
610 break; case AstBinaryExpression::GREATER: op_true = OP_IFGT; op_false = OP_IFLE; break;
615 case AstBinaryExpression::GREATER_EQUAL: op_true = OP_IFGE; op_false = OP_IFLT; break; default:
620 assert( false); break; } } else
625 { EmitExpression(left); EmitExpression(right);
Mai 31, 05 7:18 Seite 9/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 9/12
switch (bp −> Tag())630 {
case AstBinaryExpression::LESS: op_true = OP_IF_ICMPLT; op_false = OP_IF_ICMPGE; break;
635 case AstBinaryExpression::LESS_EQUAL: op_true = OP_IF_ICMPLE; op_false = OP_IF_ICMPGT; break; case AstBinaryExpression::GREATER:
640 op_true = OP_IF_ICMPGT; op_false = OP_IF_ICMPLE; break; case AstBinaryExpression::GREATER_EQUAL: op_true = OP_IF_ICMPGE;
645 op_false = OP_IF_ICMPLT; break; default: assert( false); break;
650 } } } else if (left_type == control.long_type) {
655 EmitExpression(left); EmitExpression(right);
opcode = OP_LCMP;
660 // // branch according to result value on stack // switch (bp −> Tag()) {
665 case AstBinaryExpression::EQUAL_EQUAL: op_true = OP_IFEQ; op_false = OP_IFNE; break; case AstBinaryExpression::NOT_EQUAL:
670 op_true = OP_IFNE; op_false = OP_IFEQ; break; case AstBinaryExpression::LESS: op_true = OP_IFLT;
675 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: op_true = OP_IFLE; op_false = OP_IFGT;
680 break; case AstBinaryExpression::GREATER: op_true = OP_IFGT; op_false = OP_IFLE; break;
685 case AstBinaryExpression::GREATER_EQUAL: op_true = OP_IFGE; op_false = OP_IFLT; break; default:
690 assert( false); break; } } else if (left_type == control.float_type)
695 { EmitExpression(left); EmitExpression(right);
Mai 31, 05 7:18 Seite 10/12b.cppGedruckt von Rainer Koschke
10/12 Dienstag Mai 31, 2005
switch (bp −> Tag())700 {
case AstBinaryExpression::EQUAL_EQUAL: opcode = OP_FCMPL; op_true = OP_IFEQ; op_false = OP_IFNE;
705 break; case AstBinaryExpression::NOT_EQUAL: opcode = OP_FCMPL; op_true = OP_IFNE; op_false = OP_IFEQ;
710 break; case AstBinaryExpression::LESS: opcode = OP_FCMPG; op_true = OP_IFLT; op_false = OP_IFGE;
715 break; case AstBinaryExpression::LESS_EQUAL: opcode = OP_FCMPG; op_true = OP_IFLE; op_false = OP_IFGT;
720 break; case AstBinaryExpression::GREATER: opcode = OP_FCMPL; op_true = OP_IFGT; op_false = OP_IFLE;
725 break; case AstBinaryExpression::GREATER_EQUAL: opcode = OP_FCMPL; op_true = OP_IFGE; op_false = OP_IFLT;
730 break; default: assert( false); break; }
735 } else if (left_type == control.double_type) { EmitExpression(left); EmitExpression(right);
740 switch (bp −> Tag()) { case AstBinaryExpression::EQUAL_EQUAL: opcode = OP_DCMPL; op_true = OP_IFEQ;
745 op_false = OP_IFNE; break; case AstBinaryExpression::NOT_EQUAL: opcode = OP_DCMPL; op_true = OP_IFNE;
750 op_false = OP_IFEQ; break; case AstBinaryExpression::LESS: opcode = OP_DCMPG; op_true = OP_IFLT;
755 op_false = OP_IFGE; break; case AstBinaryExpression::LESS_EQUAL: opcode = OP_DCMPG; op_true = OP_IFLE;
760 op_false = OP_IFGT; break; case AstBinaryExpression::GREATER: opcode = OP_DCMPL; op_true = OP_IFGT;
765 op_false = OP_IFLE; break; case AstBinaryExpression::GREATER_EQUAL: opcode = OP_DCMPL;
Mai 31, 05 7:18 Seite 11/12b.cppGedruckt von Rainer Koschke
Dienstag Mai 31, 2005 11/12
op_true = OP_IFGE;770 op_false = OP_IFLT;
break; default: assert(false); break;
775 } } else assert(false && "comparison of unsupported type");
if (opcode != OP_NOP)780 PutOp(opcode); // if need to emit comparison before branch
EmitBranch (cond ? op_true : op_false, lab, over);}
Mai 31, 05 7:18 Seite 12/12b.cppGedruckt von Rainer Koschke
12/12 Dienstag Mai 31, 2005
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 560 / 634
Implementierung
Ignoranz, Not-Invented-Here-Syndrom oder dieneuerfundenen Rader
p u b l i c c l a s s A r t i c l e s {p r i v a t e A r t i c l e i tem ;p r i v a t e A r t i c l e s n e x t ;
p u b l i c A r t i c l e s ( ) { . . . }p u b l i c v o i d Add ( A r t i c l e a r t ) { . . . }p u b l i c v o i d Show ( ) { . . . }
}
p u b l i c c l a s s A r t i c l e s {p r i v a t e j a v a . u t i l . L i n k e d L i s t a r t i c l e s ;
p u b l i c A r t i c l e s ( ) { . . . }p u b l i c v o i d Add ( A r t i c l e a r t ) { . . . }p u b l i c v o i d Show ( ) { . . . }
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 561 / 634
Implementierung
Die Oglala des 21. Jahrhunderts
p u b l i c c l a s s A r t i c l e s {p r i v a t e j a v a . u t i l . L i n k e d L i s t a r t i c l e s ;
p u b l i c A r t i c l e s ( ) { . . . }
p u b l i c v o i d Add ( A r t i c l e a r t ) { a r t i c l e s . addLast ( a r t ) ; }
p u b l i c v o i d Show ( ) {L i s t I t e r a t o r l i s t I t r = a r t i c l e s . l i s t I t e r a t o r ( ) ;w h i l e ( l i s t I t r . hasNext ( ) ) {
A r t i c l e a r t = ( A r t i c l e ) l i s t I t r . n e x t ( ) ;a r t . show ( ) ;
}}
}
Oglala (bedeutet:”Die ihre Habe verschleudern“ im Sinne von
Großzugigkeit) sind ein Stamm der Lakota-Sioux-Indianer.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 562 / 634
Implementierung
Prinzipien
einheitlich
so einfach wie moglich
sprechend, direkt verstandlich
pragnant
frei von Redundanz
ubersichtlich
strukturiert
abgeschlossen
abstrakt
Separation of Concerns
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 563 / 634
Implementierung
Was alles in den Code-Inspektionen 2004/05 auffiel
Verwendung von verketteten Listen, wo Maps angebracht waren;manuelle Implementierung der entsprechenden Map-Zugriffe
Verwendung von verketteten Listen, wo ArrayList angebrachter ware;z.B. Iterieren durch die LinkedList uber Indexzugriffe...
alle Methoden einer Klasse static; die statischen Variablen werdenuber den Konstruktor initialisiert
alle Methoden einer Klasse static, die Instanz, auf der die Methodenarbeiten, werden z.B. als LinkedList jeweils ubergeben
Neuimplementierung von Sortieralgorithmen
die gesamte GUI wird in einer einzigen Klasse implementiert
Datenbankzugriffe werden uber alle Klassen verteilt, statt gekapselt
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 564 / 634
Implementierung
Was alles in den Code-Inspektionen 2004/05 auffiel
Query wird mit select * gemacht, danach werden manuell diebenotigten Spalten rausgefiltert
Datenbanknamen usw. werden hartcodiert
manuelle Implementierung von Parsern fur verschiedene Zwecke (woz.B. XML oder Properties-Datei angebracht ware)
mehrfache Implementierung der gleichen Hilfsklassen vonverschiedenen Leuten, z.B. Ubersetzungen (dementsprechend auchmit verschiedenen Dateiformaten)
keine Berucksichtigung von Performance (z.B. bei Operationen aufverketteter Liste, Dateioperationen; Konfigurationsdatei wird beijedem Methodenaufruf neu eingelesen)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 565 / 634
Implementierung
Wiederholungsfragen
Was sind Refactorings und Bad Smells?
Wie wird Refactoring durchgefuhrt?
Nennen Sie Beispiele fur Bad Smells.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 566 / 634
Benutzerdokumentation
Benutzerdokumentation
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragen
12 BenutzerdokumentationLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 567 / 634
Benutzerdokumentation
Lernziele
Eine Benutzerdokumentation erstellen konnen
wissen, was hinein gehort
Arten kennen
ihre Qualitaten kennen
Prozess ihrer Erstellung kennen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 568 / 634
Benutzerdokumentation
Was ist Benutzerdokumentation?
Definition (Benutzerdokumentation)
ist eine Methode, technische Information einer Software an Nichttechnikerzu vermitteln, um sie in ihrer Aufgabe zu unterstutzen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 572 / 634
Benutzerdokumentation
Ist eine Methode. . . zu vermitteln. . .
Es ist nur eine Methode unter vielen:
Schulungen
Seminare
Coaching
Versuch-und-Irrtum
Selbsterklarungsfahigkeit der Software
Hotline (Help-Desk)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 573 / 634
Benutzerdokumentation
. . . Nichttechnikern . . .
Benutzer sind keine Software-Experten und wollen auch keine werden.
Sie wollen das wissen, was Sie fur Ihre Aufgabe benotigen und nicht mehr.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 574 / 634
Benutzerdokumentation
. . . um sie in ihrer Aufgabe zu unterstutzen. . .
Ihre Aufgabe ist es nicht, Software zu bedienen, sondern ein realesProblem zu losen.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 575 / 634
Benutzerdokumentation
Arten der Dokumentation
Benutzungshandbuch
Referenzhandbuch
Tutorial
Administrationshandbuch
Installationshandbuch
Quick Start Guide
Reference Card
Wall Charts und Poster
Online-Dokumentation (Multi-Media)
Online-Kontexthilfe
Readme.txt
Known-Bugs
. . .
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 576 / 634
Benutzerdokumentation
Arten und Leser der Dokumentation (Sommerville 2004)
Systemevaluators
Functionaldescription
Descriptionof servicesprovided
Systemadministrator
How toinstall
Noviceusers
Introductorymanual
Referencemanual
Systemadminstrator
Installationdocument
Experiencedusers
Systemadmin. guide
Gettingstarted
Details of allsystemfacilities
Operateand maintain
system
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 577 / 634
Benutzerdokumentation
Wie findet man, was zu dokumentieren ist?
Quellen:
Kommandos und Menus in der Benutzungsoberflache
Aufgaben der Benutzer (was sie tun)
Definition von Begriffen (Glossar)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 578 / 634
Benutzerdokumentation
Struktur I
Titel
Inhaltsverzeichnis
1. Einfuhrung
a. Adressierte Leserb. Zweckc. Verwandte Dokumented. Konventionene. Information uber die Verwendung des Dokumentsf. Instruktionen fur Problemberichte
2. Ubersicht
a. Zugrunde liegende Konzepte, Einbettungb. Funktionale Beschreibungc. Gefahren und Warnungen
3. Instruktionen (fur jeden Benutzertyp einzeln)
a. Produktfunktionen (mit Beispielen)b. Problembehandlung: Ursachen und Grunde
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 579 / 634
Benutzerdokumentation
Struktur II
4. Referenz
a. Fehlermeldungen und -ursachen
b. Index der Operationen
Anhang
A Glossar
B Index (notwendig fur ≥ 30 Seiten, sonst mindestens nutzlich)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 580 / 634
Benutzerdokumentation
Scheibchen toter Baume oder doch besser Elektrizitat?
Papier:
”150 Euro — und dafur nur eine CD?“
deutsches Gesetz schreibt Handbuch vor
Papier ist die zuverlassigere und bedienbarere Technologie
erschwert Software-Piraterie
Online-Dokumentation:
einfachere Suche
Information kann in vielen Formaten verpackt werden
interaktiv (z.B. Tool-Tips)
niedrigere Produktionskosten
→ beides, aber mindestens Papier
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 581 / 634
Benutzerdokumentation
Wer sollte schreiben?
Programmierer technischer Schreiber
Technische Detailkenntnisse + -Schreibqualitaten - +Anwenderbrille - +
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 582 / 634
Benutzerdokumentation
Wozu Dokumentation?
Zwecke der Dokumentation:
Erlauterung
Definitionen, Beschreibungen, Erklarungen, Ubersichten,Prozessbeschreibung
Instruktion
Produktfunktionen, Aufgaben
Referenz
Regelungen, Listen, Tabellen, spezifische Funktionen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 583 / 634
Benutzerdokumentation
Wann werden Benutzer die Dokumentation benutzen?
. . . wenn sie zuversichtlich sind, dass
sie finden, was sie suchen
sie verstehen, was sie finden
die Information korrekt ist
die Information vollstandig ist
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 584 / 634
Benutzerdokumentation
Der Prozess, eine Dokumentation zu erstellen (Stimely1990)
1 Definition
2 Entwurf
3 Schreiben
4 Editieren
5 Korrekturlesen
6 Produktion
7 Anpassung/Anderung
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 585 / 634
Benutzerdokumentation
1. Definition
(5-10% der Gesamtzeit fur Dokumentation)
Erste Frage: Wer sind die Leser?
Identifiziere den”normalen“ Leser. Beschreibe, was Du uber ihn weißt.
Identifiziere die Annahmen uber den Leser.
Es konnte mehrere Kategorien von Lesern geben. Identifiziere sie alle.
Beschreibe, was sie benotigen (Erlauterung, Instruktion, Referenz).
Lege Gegenstande der Dokumentation (mit Namen) und Medien fest
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 586 / 634
Benutzerdokumentation
2. Entwurf
(10-30% der Gesamtzeit fur Dokumentation)
Plane fur jeden Gegenstand:
Inhaltsverzeichnis
Schatzung der Anzahl Seiten/Fenster
Musterlayout
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 587 / 634
Benutzerdokumentation
3. Schreiben
(1-3 Stunden pro Seite/Fenster)
Erste Fassung so schnell wie moglich schreiben. Dabei nicht editieren.
Schreibblockade uberkommen durch
Verbalisieren (z.B. einem Unbedarften erklaren)
Zerlegung eines komplexen Gegenstands in seine Einzelteile
Brain-Dump
Mind-Map
Auszeit nehmen und ausruhen
(temporar) aufgeben und zum nachsten Abschnitt ubergehen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 588 / 634
Benutzerdokumentation
4. Editing
(1-3 Stunden pro Seite/Fenster)
Iterative Verbesserung:
Bedurfnisse des Lesers GrammatikStruktur OrthographieRelevanz KonsistenzVollstandigkeit Konformitatansprechende graphische Darstellung Ausdrucksweise
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 589 / 634
Benutzerdokumentation
5. Korrekturlesen
(5-20 Minuten pro Seite/Fenster)
Unabhangige Begutachtung von
technischer Korrektheit
Vollstandigkeit
Verwendbarkeit
Einhaltung des Stils
Rechtmaßigkeit
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 590 / 634
Benutzerdokumentation
6. Produktion
(dauert immer langer als man denkt)
Druck und Verteilung
Herstellung der CD und Verteilung
Publikation im Web
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 591 / 634
Benutzerdokumentation
7. Anpassung/Anderung
(benotigt Zeit – muss eingeplant werden)
regelmaßige Uberprufung, um sicher zu stellen, dass Dokumentationaktuell bleibt
Programmierer mussen Handbuch kennen!
Dokumentation muss bei Analyse von Anderungsauswirkungen(Change-Impact) berucksichtigt werden
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 592 / 634
Benutzerdokumentation
Hinweise und Regeln
erklare das zu losende Problem
stelle die Konzepte dar, nicht nur die Produktfunktionen
beschreibe auch Anwendungsdomane, nicht nur die Software selbst
die Lekture soll Spaß machen
schreibe zur Leserschaft, nicht uber sie
konsistentes (und eingeschranktes) Vokabular benutzen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 593 / 634
Benutzerdokumentation
Hinweise und Regeln
sei bestimmt
fasse dich kurz (kurze Satze, Paragraphen, Abschnitte)
benutze einfache Sprache
aktive statt passive Sprache
erklare den Zweck eines jeden Schritts
sage, was in jedem Schritt passieren wird
teste mit echten Benutzern
kenne deinen Leser
beachte Markenzeichen und Copyrights
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 594 / 634
Benutzerdokumentation
Wiederholungsfragen
Auf welche Weisen konnen Benutzer die Bedienung von Softwareerlernen?
Was ist Benutzerdokumentation?
Nennen Sie Beispiele fur Software-Dokumentationen.
Wie sollte eine Benutzerdokumentation strukturiert werden?
Wer sollte eine Benutzerdokumentation erstellen?
Wie verlauft der Prozess, um eine Benutzerdokumentation zuerstellen?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 595 / 634
Antworten auf gesammelte Fragen im Wiki
Antworten auf gesammelte Fragen im Wiki
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragen
13 Antworten auf gesammelte Fragen im WikiObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 596 / 634
Antworten auf gesammelte Fragen im Wiki
Objektorientierte Modellierung
Ubersicht uber alle UML Diagramme: Welche gibt es alle undwas ist ihr Verwendungsgebiet? (Keine Wiederholung uber dieErstellung, Eigenschaften u.a.)
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 597 / 634
Antworten auf gesammelte Fragen im Wiki
Objektorientierte Modellierung
Anwendungsfalldiagramm
→ Ubersicht von Anwendungsfallen, Zusammenhang mit Akteuren,Beziehungen zwischen Anwendungsfallen
Klassendiagramm
→ statische Beziehungen zwischen Dingen:
Daten- bzw. DomanenmodellKlassenentwurf
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 598 / 634
Antworten auf gesammelte Fragen im Wiki
Objektorientierte Modellierung
Sequenzdiagramm
→ Interaktionen zwischen Akteuren
Interaktionen in AnwendungsfallenInteraktionen zwischen Komponenten der ArchitekturProgrammablauf (Methoden und Klassen)
Kollaborationsdiagramme
→ aquivalent zu Sequenzdiagrammen
→ heben Akteure und deren prinzipielle Interaktion hervor, Reihenfolgetritt in den Hintergrund
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 599 / 634
Antworten auf gesammelte Fragen im Wiki
Objektorientierte Modellierung
Zustandsdiagramme
→ zustandsbasiertes Verhalten, Reaktion auf Stimuli
Modellierung von Anwendungsfallen mit ZustandenObjektlebenszyklusProtokolle in Architekturzustandsbasiertes Testen
Aktivitatsdiagramme
→ Ablaufe: Aktionen und ihre Reihenfolge
Modellierung von GeschaftsprozessenBeschreibung von AnwendungsfallenSpezifikation/Entwurf von AlgorithmenPfadtest
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 600 / 634
Antworten auf gesammelte Fragen im Wiki
Softwarearchitektur
Außerdem aus gegebenem Anlass, zu den unterschiedlichenBlickwinkel des Architekturentwurfs.
Konzeptionelle Sicht nach Hofmeister u. a. 2000: Data undControl Konnektoren, Unterschiede? (Wir haben z.B. bei jederVerbindung beides benutzt...??)
Alternative Modellierung der Konzeptionellen Sicht mit UML?Vielleicht ein kleines Beispiel?
Die Unterschiede und Zusammenhange zwischen System,Subsystem, Modul und Komponente nochmal erlautern
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 601 / 634
Antworten auf gesammelte Fragen im Wiki
Konzeptioneller Blickwinkel (Hofmeister u. a. 2000)
CComponent
CPort
Conceptual Configuration
CConnector
CRole
Protocolobeysobeys
cbindingcbinding
connection
11
* *
*
*
*
*
* *
* *
* *
1 1
0..1
0..1 0..1 0..1 0..10..1*
*
conjugate
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 602 / 634
Antworten auf gesammelte Fragen im Wiki
Konzeptionelle Sicht
«Component»
Main
«Component»
FrontEnd
«Component»
MiddleEnd
«Component»
BackEnd
«call»
call ist ein Control-Konnektor;
ein einfacher Aufruf
«call»
«call»
«Data»
AST-Pipe
Producer
Consumer
«bind» «bind»
«Data»
IL-Pipe
Producer
Consumer
«bind» «bind»
«Data»
Text-Pipe
«Data»
Assembler-Pipe
Compiler
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 603 / 634
Antworten auf gesammelte Fragen im Wiki
Modulblickwinkel (Hofmeister u. a. 2000)
Module (layer) A uses
Module
Interface
Layer
module (layer) B whenA requires an interfacethat B provides
Subsystem
use
0..1
require *
*
*
require
* provide
*
* * * * *
0..1
0..1
use *
* *
* assigned−to
*
cont
ain
provide
contain
0..1
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 604 / 634
Antworten auf gesammelte Fragen im Wiki
Modulsicht
Lexer SyntaxAnalysis SemanticAnalysis
GetToken
TextBuffer
GetText
Open
Main
Parse Decorate
AST
Lookup
Create
Annotate
<<Subsystem>> FrontEnd
Traverse
ControlFlowAnalyzerILGenerator
IL
Generate
Traverse
<<Subsystem>>
MiddleEnd
Optimizer
Run Run
Run
<<Layer>>
Programrepresentation
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 605 / 634
Antworten auf gesammelte Fragen im Wiki
Ausfuhrungsblickwinkel (Hofmeister u. a. 2000)
SoftwarePlatform
PlatformElement
PlatformResource
HardwareResource
CommunicationPath
RuntimeEntity
CommunicationMechanism
Module
*
* * *
consumeconsume
* contain
is a
communicate over
*
1
use mechanism
assigned to
* 2..*
1
*
assigned to
*
*
*
* 1
*
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 606 / 634
Antworten auf gesammelte Fragen im Wiki
Ausfuhrungssicht
Processor2Processor1
Lexer
SyntaxAnalysis
SemanticAnalysis
TextBuffer
Main AST
ControlFlowAnalyzerILGenerator
ILOptimizer
11
Shared Memory
<<Thread>>
<<Thread>>
*
1
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 607 / 634
Antworten auf gesammelte Fragen im Wiki
Entwurfsmuster und Architekturstile
die factory method an einem kleinen konkretenImplementierungsbeispiel darstellen
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 608 / 634
Antworten auf gesammelte Fragen im Wiki
Fahrradladenbeispiel: Erweiterung fur andere Domanen
Anforderungen:
Artikeldaten sollen von einer Datei gelesen werden konnen
zukunftig sollen andere Domanen unterstutzt werden (Fahrrad,Computer und Klettern)
die Objekte dieser Domanen sind unterschiedlich
notwendige Anpassungen sollen einfach realisiert werden konnen
Losungsstrategien:
die Klassen der Benutzungsschnittstelle beziehen sich nur auf dieSchnittstelle der abstrakten Klasse Artikel
Datei hat gleiche Syntax fur alle Domanen (nur die Inhalte variieren)
die Artikel werden beim Einlesen der Datei als Objekte erzeugt
→ aber der Leser muss doch die Konstruktoren der Objekte kennen, oderwas?
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 609 / 634
Antworten auf gesammelte Fragen im Wiki
Losungsstrategie
FelgeRahmen
+ Preis()
Artikel
GUI
ComputerArtikel FahrradArtikel
+ lies(dateiname)
Leser
id=datei.liesId()
s.FabrikMethode(id)
+ Artikel FabrikMethode(id)
ArtikelSchopfer
+FabrikMethode(id)
FahrradSchopfer
+FabrikMethode(id)
ComputerSchopfer
if (id == ”rahmen”)return new Rahmen
if (id == ”felge”)return new Felge�create�
�create� �create�
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 610 / 634
Antworten auf gesammelte Fragen im Wiki
Artikelklassen
p u b l i c a b s t r a c t c l a s s A r t i k e l {d o u b l e P r e i s ( ) { . . . }
}
p u b l i c a b s t r a c t c l a s s F a h r r a d A r t i k e l e x t e n d s A r t i k e l {. . . }
p u b l i c c l a s s F e l g e e x t e n d s F a h r r a d A r t i k e l {. . . }
p u b l i c c l a s s Rahmen e x t e n d s F a h r r a d A r t i k e l {. . . }
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 611 / 634
Antworten auf gesammelte Fragen im Wiki
Leser
p u b l i c c l a s s L e s e r {
A r t i k e l S c h o e p f e r s c h o e p f e r ;
L e s e r ( A r t i k e l S c h o e p f e r s c h o e p f e r ) {t h i s . s c h o e p f e r = s c h o e p f e r ;
}
p r i v a t e S t r i n g r e a d i d ( F i l e I n p u t S t r e a m i n ) {. . . }
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 612 / 634
Antworten auf gesammelte Fragen im Wiki
Leser (Forts.)
p u b l i c v o i d l i e s ( S t r i n g date iname ) throws j a v a . i o . I O E x c e p t i o n {F i l e I n p u t S t r e a m i n = new F i l e I n p u t S t r e a m ( date iname ) ;S t r i n g i d ;A r t i k e l a r t i k e l ;w h i l e ( i n . a v a i l a b l e ( ) > 0) {
i d = r e a d i d ( i n ) ;t r y {
a r t i k e l = s c h o e p f e r . Fabr ikMethode ( i d ) ;}c a t c h ( A r t i k e l S c h o e p f e r . Unknown Id e ) {
System . out . p r i n t ( ”unknown i d ” + i d ) ;// keep go ing
}}i n . c l o s e ( ) ;
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 613 / 634
Antworten auf gesammelte Fragen im Wiki
Schopfer
p u b l i c a b s t r a c t c l a s s A r t i k e l S c h o e p f e r {
p u b l i c c l a s s Unknown Id e x t e n d s E x c e p t i o n {} ;a b s t r a c t A r t i k e l Fabr ikMethode ( S t r i n g i d ) throws Unknown Id ;
}
p u b l i c c l a s s F a h r r a d S c h o e p f e r e x t e n d s A r t i k e l S c h o e p f e r {
F a h r r a d A r t i k e l Fabr ikMethode ( S t r i n g i d ) throws Unknown Id {i f ( i d == ” rahmen ” ) r e t u r n new Rahmen ( ) ;e l s e i f ( i d == ” f e l g e ” ) r e t u r n new F e l g e ( ) ;throw new Unknown Id ( ) ;
}
}
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 614 / 634
Antworten auf gesammelte Fragen im Wiki
Softwaretechnik im Allgemeinen
kleiner Exkurs uber agile Softwareentwicklung im Vergleich zumWasserfallmodell
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 615 / 634
Antworten auf gesammelte Fragen im Wiki
Extreme Programming (Beck 2000)
Wasserfallmodell — Extreme Programming — Code&FixExtreme Programming (XP) ist eine agile Methode fur
kleinere bis großere Entwicklerteams (max. 10-15 Personen),
Probleme mit vagen Anforderungen
und Projekte, bei denen ein Kundenreprasentant stets greifbar ist.
http://www.extremeprogramming.org/
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 616 / 634
Antworten auf gesammelte Fragen im Wiki
Extreme Programming (Beck 2000)
Anerkannte Prinzipien und Praktiken werden”extrem“ umgesetzt:
Code-Reviews → permanente Reviews durch Pair-Programming
Testen → standiges Testen: Unit-Tests sowie Akzeptanztests durchden Kunden/Benutzer
klare Struktur → jeder verbessert sie kontinuierlich durch Refactoring
Einfachheit → stets die einfachste Struktur wahlen, die die aktuellenAnforderungen erfullt
Integration → permanente Integration auch mehrmals am TagValidierung:
Kunde/Benutzer ist stets involviert bei der Planung neuer Iterationenund verantwortlich fur Akzeptanztestkurze Iterationen → Dauer in Minuten und Stunden, nicht Wochen,Tage, Jahre
aber auch Auslassung anerkannter Prinzipien:
Dokumentation: mundliche Uberlieferung, Tests und Quellcode
Planung: sehr begrenzter HorizontRainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 617 / 634
Antworten auf gesammelte Fragen im Wiki
Weitere XP-Charakteristika
Kunde vor Ort
eine Metapher statt einer Architekturbeschreibung
40-Stundenwoche
Code ist kollektives Eigentum
Kodierungsstandards
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 618 / 634
Antworten auf gesammelte Fragen im Wiki
Agile versus weit voraus planende Prozessmodelle (Boehmund Turner 2003)
Risiken agiler Methode:
Skalierbarkeit, Kritikalitat, Einfachheit des Entwurfs,Personalfluktuation, Personalfahigkeiten
Risiken weit voraus planender Prozessmodelle:
Stabilitat der Anforderungen, steter Wandel, Notwendigkeit schnellerResultate, Personalfahigkeiten
Generelle Risiken:
Unsicherheiten bei der Technologie, unterschiedlicheInteressengruppen, komplexe Systeme
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 619 / 634
Das SWP-Lied
Das SWP-Lied
Ziele und InhaltAngestrebte ResultateAktivitaten der Software-EntwicklungAblaufZeitplanAnmeldungScheinbedingungenProjektplanVorstellung der AufgabeKontaktdatenRessourcenLehrbucherEigenschaften von SoftwareSoftware-LebenszyklusSoftware-EvolutionEntstehung der SoftwaretechnikMerkmale der SoftwaretechnikProjektVorgehenInhaltZeitplanPlanung und Aufwand im SWP 05/06RisikenRisiko-ManagementErfahrungen aus dem SWP 05/06Allgemeine Risiken in einem Software-ProjektWiederholungsfragenLernzieleHerausforderungenAktivitatenIst-Analyse
ErhebungstechnikenBefragungBeobachtung
Soll-Analyse: PrototypingZusammenfassung der TechnikenAnforderungsspezifikation
BedeutungAnzustrebende EigenschaftenRegelnAufbau und Inhalt
WiederholungsfragenLernzieleModellbildungObjektorientierte ModellierungGeschaftsprozesseAnwendungsfalleUML-Notation fur AnwendungsfalleStatische Eigenschaften: KlassendiagrammeVerhaltenseigenschaftenInteraktionsdiagrammeSequenzdiagrammeKommunikationsdiagrammeAktivitatsdiagrammeZustandsautomatendiagrammeWiederholungsfragenMotivationLernzieleSoftware-PrufungenReviewsAblauf von ReviewsReview-RegelnReview-ChecklistenReview-VariantenFallen und GegenmittelWiederholungsfragenMotivationLernzieleErgonomiePsychologische und kognitive GrundlagenKommandosprachen versus GUIGeschichte graphischer BenutzungsschnittstellenInteraktionsmechanismenSoftware-ergonomische RichtlinienUsability messen und verbessernZusammenfassungWiederholungsfragenWas ist Software-Architektur?EinflussfaktorenArchitektursichten und -blickwinkelKonzeptioneller BlickwinkelModulblickwinkelAusfuhrungsblickwinkelCode-SichtModularisierungSchnittstellenKopplung und ZusammenhaltQualitatenBewertung von ArchitekturenWiederholungsfragenWas ist ein Entwurfsmuster?Bestandteile eines EntwurfsmustersKategorien von EntwurfsmusternEntwurfsmuster Factory MethodEntwurfsmuster ObserverArchitekturstileArchitekturstil SchichtungArchitekturstil Model-View-ControllerWiederholungsfragenBegriffe des TestensSoziologie des TestensTestaktivitatenTestfallTeststumpfe und -treiberKomponententestsAquivalenztestKomponententest mit JUnitGrenztestPfadtestMaße der TestabdeckungZustandsbasiertes TestenIntegrationstestLeistungstestsZusammenfassung der TestartenTestmanagementTestplanTestfallspezifikationTestschadensberichtWiederholungsfragenMotivationArchitekturkonformitatProgrammierrichtlinienAnhangWiederholungsfragenLernzieleWas ist Benutzerdokumentation?Arten der DokumentationStrukturAuf Papier oder elektronisch?AutorWie schreibt man eine Dokumentation?Hinweise und RegelnWiederholungsfragenObjektorientierte ModellierungSoftwarearchitekturEntwurfsmuster und ArchitekturstileSoftwaretechnik im Allgemeinen
14 Das SWP-Lied
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 620 / 634
Das SWP-Lied
SWP-Lied
Melodie: Paul McCartney:”Let it be“; Text: Jochen Quante
Irgendwann im Informatik-Studiumkommt was, was ich nicht versteh’:Software Engineering – SWP.
Pflichtenheft, Entwurfsbeschreibung. . .Sowas braucht man doch wohl nie?!Wir soll’n all das schreiben – SWP.
SWP, SWP, SWP, SWP.Koschke sagt:
”Des g’hort so“– SWP.
Wir wollen lieber programmieren,Java hacken, schnell was dreh’n!Soviel Dokumente – SWP.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 621 / 634
Das SWP-Lied
SWP-Lied (Forts.)
Und wenn wir endlich starten durfen,ist das Wissen ganz passe:Wie ging noch mal Java? – SWP.
SWP, SWP, SWP, SWP.Was war noch mal Java? – SWP.
Die Zeit wird knapp, die Nachte kurzer,manch einer fallt aus – oh je.Keine Zeit fur’s Testen – SWP.
Die Software wurde grad’ noch fertig,war’n wir doch zuviel am See?Dafur war die Planung – SWP.
SWP, SWP, SWP, SWP.Dafur also Planung – SWP.
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 622 / 634
Das SWP-Lied
1 Balzert 1998 Balzert, Helmut: Lehrbuch der Software-Technik.Spektrum Akademischer Verlag, 1998. – derzeit nicht mehr verfugbar,wird neu aufgelegt. – ISBN 978-3827403018
2 Bass u. a. 2003 Bass, Len ; Clements, Paul ; Kazman, Rick:Software Architecture in Practice. 2nd edition. Addison Wesley, 2003
3 Beck 2000 Beck, Kent: Extreme Programming Explained.Addison-Wesley, 2000 (The XP Series). – ISBN 201-61641-6
4 Berling und Runeson 2003 Berling, T. ; Runeson, P.: Evaluationof a perspective based review method applied in an industrial setting.In: IEE Proceedings 150 (2003), Juni, Nr. 3
5 Boehm und Turner 2003 Boehm, B. ; Turner, R.: Using risk tobalance agile and plan-driven methods. In: IEEE Computer 36 (2003),Juni, Nr. 6, S. 57–66
6 Boehm 2000 Boehm, Barry: Project Termination Doesn’t EqualProject Failure. In: IEEE Computer (2000), September, S. 94–96
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 623 / 634
Das SWP-Lied
7 Brugge und Dutoit 2004 Brugge, Bernd ; Dutoit, Allen H.:Objektorientierte Softwaretechnik. Prentice Hall, 2004
8 Buschermohle u. a. 2006 Buschermohle, Ralf ; Eekhoff, Heike ;Josko, Bernhard: Success – Erfolgs- und Misserfolgsfaktoren bei derDurchfuhrung von Hard- und Softwareentwicklungsprojekten inDeutschland. www.offis.de/umfragesuccess. 2006
9 Buschmann u. a. 1996 Buschmann, Frank ; Meunier, Regine ;Rohnert, Hans ; Sommerlad, Peter ; Stal, Michael:Pattern-oriented Software Architecture: A System of Patterns. Bd. 1.Wiley, 1996
10 Bush 1945 Bush, Vannevar: As We May Think. In: Atlantic Monthly(1945), Juli, S. 101 ff
11 Clements u. a. 2002 Clements, Paul ; Bachmann, Felix ; Bass,Len ; Garlan, David ; Ivers, James ; Little, Reed ; Nord,Robert ; Stafford, Judith: Documenting Software Architecture.Boston : Addison-Wesley, 2002
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 624 / 634
Das SWP-Lied
12 EN ISO 9241-10:1995 1995 : Ergonomische Anforderungen furBurotatigkeiten mit Bildschirmgeraten – Teil 10: Grundsatze derDialoggestaltung. Europaische Norm, ISO-Standard. 1995
13 Fjeldstadt und Hamlen 1984 Fjeldstadt ; Hamlen: ApplicationProgram Maintenance Study: Report to Our Respondents. In: Proc.GUIDE 48, IEEE Computer Society Press, April 1984
14 Fruhauf u. a. 2000 Fruhauf ; Ludewig ; Sandmayr:Software-Prufung. 4. Auflage. vdf Zurich, 2000
15 Fusaro u. a. 1997 Fusaro, P. ; Lunibile, F. ; Visaggio, G.: Areplicated experiment to assess requirements inspection techniques. In:Empirical Software Engineering 2 (1997), S. 39–57
16 Gamma u. a. 2003 Gamma, Erich ; Helm, Richard ; Johnson,Ralph ; Vlissides, John: Desig Patterns—Elements of ReusableObject-Oriented Software. Addison Wesley, 2003
17 Gilb 1988 Gilb, Tom: Principles of Software EngineeringManagement. Harlow, UK : Addison-Wesley, 1988
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 625 / 634
Das SWP-Lied
18 Harel 1987 Harel, David: State Charts: a Visual Formalism forComplex Systems. In: Science of Computer Programming 8 (1987),Nr. 3, S. 231–274
19 Hayes 1997 Hayes, Frank: Managing User Expectations. In:Computerworld (1997), November
20 Hayes 1999 Hayes, W.: Research synthesis in software engineering: acase for meta-analysis. In: Proc. 6th Int. Symp. on Software Metrics,IEEE Computer Society Press, November 1999, S. 143–151
21 Hofmeister u. a. 2000 Hofmeister, Christine ; Nord, Robert ;Soni, Dilip: Applied Software Architecture. Addison Wesley, 2000(Object Technology Series)
22 IEEE P1471 2002 : IEEE Recommended Practice for ArchitecturalDescription of Software-intensive Systems—Std. 1471-2000. ISBN0-7381-2518-0, IEEE, New York, NY, USA. 2002
23 IEEE Standard 830.1998 1998 : IEEE Recommended Practice forSoftware Requirements Specifications, IEEE Standard 830.1998. 1998
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 626 / 634
Das SWP-Lied
24 IEEE-Std-1058 1987 : ANSI/IEEE Standard for Software ProjectManagement Plans. ANSI/IEEE Std. 1058.1-1987. 1987
25 IEEE Std 610.12-1990 1990 : IEEE Standard Glossary of SoftwareEngineering Terminology. IEEE Standard 610.12-1990. 1990
26 IEEE Std. 829-1998 1998 : IEEE Standard for Software TestDocumentation. IEEE Standards Board, IEEE Std. 829-1998. 1998
27 IEEE Std. 982-1989 1989 : IEEE Standard Guide for the Use of IEEEStandard Dictionary of Measures to Produce Reliable Software. IEEEStandards Board, IEEE Std. 982-1989. Juli 1989
28 ISO 9241-11:1998 1998 : Ergonomic requirements for office work withvisual display terminals (VDTs) – Part 11: Guidance on usability.ISO-Standard. 1998
29 ISO/IEC-Standard 25000 2005 ISO/IEC 25000:2005 SoftwareEngineering – Software product Quality Requirements and Evaluation(SQuaRE). 2005. – umgesetzt in DIN 66272
30 ISO/IEC-Standard 9126 2001 ISO/IEC 9126-1:2001 Softwareengineering – Product quality. 2001. – umgesetzt in DIN 66272
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 627 / 634
Das SWP-Lied
31 Kano 1984 Kano, N.: Attractive Quality and Must-be Quality. In:Journal of the Japanese Society for Quality Control 4 (1984), S. 39–48
32 Kazman u. a. 1996 Kazman, Rick ; Abowd, Gregory ; Bass, Len ;Clements, Paul: Scenario-Based Analysis of Software Architecture. In:IEEE Software (1996), November, S. 47–55
33 Kruchten 1995 Kruchten, Phillipe: The 4+1 View Model ofArchitecture. In: IEEE Software 12 (1995), November, Nr. 6, S. 42–50
34 Lehman und Belady 1985 Lehman, M. ; Belady, L.: ProgramEvolution: Processes of Software Change. London : Academic Press,1985
35 Liskov 1988 Liskov, Barbara: Data Abstraction and Hierarchy. In:SIGPLAN Notices 23 (1988), Mai, Nr. 5
36 Liskov und Wing 1994 Liskov, Barbara ; Wing, Jeanette M.: ABehavioral Notion of Subtyping. In: ACM Transactions on ProgrammingLnguages and Systems 16 (1994), Nr. 6, S. 1811–1841
37 Ludewig 2003 Ludewig, Jochen: Einfuhrung in die Softwaretechnik.Vorlesungs-Skriptum. 2003
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 628 / 634
Das SWP-Lied
38 Ludewig und Lichter 2006 Ludewig, Jochen ; Lichter, Horst:Software Engineering – Grundlagen, Menschen, Prozesse, Techniken.dpunkt.verlag, 2006
39 Maaß 2001 Maaß, Susanne: Soziotechnische Systeme.Vorlesungs-Skriptum. 2001
40 McKee 1984 McKee, J.R.: Maintenance as a Function of Design. In:AFIPS National Computer Conference, Las Vegas (Ch. 27), 1984
41 Miller u. a. 1998 Miller, J. ; Wood, M. ; Roper, M.: Furtherexperiences with scenarios and checklists. In: Empirical SoftwareEngineering 3 (1998), S. 37–64
42 Murphy u. a. 1995 Murphy, Gail C. ; Notkin, David ; Sullivan,Kevin: Software Reflexion Models: Bridging the Gap Between Sourceand High-Level Models. In: Proc. of the Third ACM SIGSOFTSymposium on the Foundations of Software Engineering, 1995, S. 18–28
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 629 / 634
Das SWP-Lied
43 Murphy u. a. 2001 Murphy, Gail C. ; Notkin, David ; Sullivan,Kevin J.: Software Reflexion Models: Bridging the Gap between Designand Implementation. In: IEEE Transactions on Software Engineering 27(2001), April, Nr. 4, S. 364–380
44 Neumann 1999 Neumann, Peter G.: Risks to the Public inComputers and Related Systems. In: ACM SIGSOFT SoftwareEngineering Notes 24 (1999), Nr. 1, S. 31
45 Object Management Group 2003 Object Management Group:OMG Unified Modeling Language Specification. March 2003. – Version1.5
46 OMG Object Management Group (OMG): Unified ModelingLanguage. http://www.uml.org
47 Parnas 1972 Parnas, David L.: On the Criteria to Be Used inDecomposing Systems into Modules. In: Communications of the ACM15 (1972), Dezember, Nr. 12
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 630 / 634
Das SWP-Lied
48 Partsch 1998 Partsch, H.: Requirements-Engineering systematisch -Modellierung fur softwaregestutzte Systeme. Berlin, Heidelberg, NewYork : Springer-Verlag, 1998
49 Perry und Wolf 1992 Perry, Dewayne E. ; Wolf, Alexander L.:Foundations for the Study of Software. In: ACM SIGSOFT 17 (1992),Oktober, Nr. 4, S. 40–52
50 Porter und Votta 1998 Porter, A. ; Votta, L.: Comparingdetection methods for software requirements inspection: a replicationusing professional subjects. In: Empirical Software Engineering 3 (1998),S. 355–379
51 Porter u. a. 1995 Porter, A. ; Votta, L. ; Basili, V.: Comparingdetection methods for software requirements inspection: a replicatedexperiment. In: IEEE Transactions on Software Engineering 21 (1995),Nr. 5, S. 563–575
52 Pressman 2003 Pressman, Roger: Software Engineering – APractioner’s Approach. Funfte Ausgabe. McGraw-Hill, 2003
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 631 / 634
Das SWP-Lied
53 Rodiger 2004 Rodiger, Karl-Heinz: VortragRechtlicher Rahmen der Software-Entwicklung in der VorlesungSoftware-Projekt. Vorlesungs-Skriptum. 2004
54 Sandahl u. a. 1998 Sandahl, K. ; Blomkvist, O. ; Karlsson, J. ;Krysander, C. ; Lindvall, M. ; Ohlsson, N.: An extendedreplication of an experiment for assessing methods for softwarerequirements inspections. In: Empirical Software Engineering 3 (1998),S. 327–354
55 Sauer und Cuthbertson 2003 Sauer, C. ; Cuthbertson, C.: TheState of IT Project Management in the UK.http://www.cw360ms.com/pmsurveyresults/surveyresults. 2003
56 Shaw und Garlan 1996 Shaw, Mary ; Garlan, David: SoftwareArchitecture – Perspectives on an Emerging Discipline. Upper SaddleRiver, NJ : Prentice Hall, 1996. – ISBN ISBN 0-13-182957-2
57 Shull u. a. 2000 Shull, Forrest ; Rus, Ioana ; Basili, Victor: HowPerspective-Based Reading Can Improve Requirements Inspections. In:IEEE Computer 33 (2000), Nr. 7, S. 73–79
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 632 / 634
Das SWP-Lied
58 Sommerville 2004 Sommerville, Ian: Software Engineering. SiebteAusgabe. Addison-Wesley, 2004
59 Sowa und Zachman 1992 Sowa, J. F. ; Zachman, J. A.: Extendingand formalising the framework for information systems architecture. In:IBM Systems Journal (1992)
60 Standish Group 1994
61 Standish Group 2004 Standish Group: Third Quarter ResearchReport. http://www.standishgroup.com. 2004
62 Stimely 1990 Stimely, Gwen L.: A stepwise approach to developingsoftware documentation. In: ACM SIGDOC Asterisk Journal ofComputer Documentation 14 (1990), Nr. 4, S. 121–124
63 Storrle 2005 Storrle, Harald: UML 2 fur Studenten. PearsonStudium, 2005. – ISBN 3-8273-7143-0
64 Sun microsystems 1999 Sun microsystems: Code Conventions forthe JavaTM Programming Language. April 1999. – URL http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 633 / 634
Das SWP-Lied
65 Winter 2003 Winter, Andreas: Einfuhrung in die Softwaretechnik.Vorlesungs-Skriptum. 2003
66 Zachman 1987 Zachman, J. A.: A framework for information systemsarchitecture. In: IBM Systems Journal 26 (1987), Nr. 3
67 Zachman 1999 Zachman, J. A.: A framework for information systemsarchitecture. In: IBM Systems Journal 38 (1999), Nr. 2&3, S. 454—470
68 Zuser u. a. 2004 Zuser, W. ; Grechenig, T. ; Kohle, M.: SoftwareEngineering mit UML und dem Unified Process. Zweite Ausgabe.Pearson Studium, 2004
Rainer Koschke (Uni Bremen) Software-Projekt Wintersemester 2008/09 634 / 634