Home

Software Engineering - Fachbereich Informatik

1. Trenne was nicht zusammengeh r be m F r Funktionen Klassen Komponenten Starker Zusammenhalt Strong Cohesion Kohasion ist ein Ma daf r wie eng die Beziehungen und der Fokus der Verantwortlichkeiten in einem Modul Funktion Klasse sind Schwache Koh sion e Ein Modul ist verantwortlich f r viele Aufgaben Starke Koh sion e Jeder Modul hat einen einzigen klaren Zweck z B jede Operation einer Klasse hat einen einzigen klaren Zweck und z B die Operationen einer Klasse bilden eine Gruppe zusammengeh render Aufgaben 160 6 1 Grundprinzipien fur das Design Grundprinzip 1 Starker Zusammenhalt Strong Cohesion Trennung von Zustandigkeiten Separation of Concerns m Unterteile das System so in Teile dass jeder Teil genau eine Aufgabe hat gt Diese Aufgabe wird auch nur von diesem Teil erledigt gt Die Abgrenzung gegen ber anderen Teilen ist klar erkennbar gt Die Aufgabe ist genau und pr gnant definiert und spiegelt sich im Namen des Teils wider gt Trenne Teile an denen sich voraussichtlich keine nderungen ergeben von Teilen an denen sich wahrscheinlich Anderungen ergeben m Vorteile von getrennten Zust ndigkeiten gt Ein Systemteil der nur eine Zust ndigkeit hat ndert sich nur wenn an dieser einen Zust ndigkeit eine Anderung n tig wird m SWE Prof Dr W Weber h_da Fachbereich Informatik 161 il HOCHSCHULE DARMSTADT E 6 1 Grundprinzipien f r das Design I
2. hda HSCHULE DARM En SWE Prof Dr W Weber h_da Fachbereich Informatik 455 u i I 3 ________ Dee 11 1 Modelle zur Bewertung von Software Entwickungsprozessen V Modell XT 1 workflow is dependant on SPICE meta model oe SWE Prof Dr W Weber h_da Fachbereich Informatik H Hi ADT I UNIVERSITY OF APPLIED SCIENCES 456 i i 11 1 Modelle zur Bewertung von Software Entwickungsprozessen Impliziert die Verwendung des V Modells XT eine gute Bewertung in SPICE oder CMMI m In der Beschreibung des V Modells XT wird gezeigt dass die einzelnen spezifischen und generischen Ziele von Level 2 und 3 des CMMI auf Vorgaben im V Modell XT abgebildet werden k nnen m Das hei t nicht dass bei Verwendung von V Modell XT automatisch CMMI Level 3 erreicht ist m CMMI ist ein Modell zur berpr fung des F higkeitgrads bzw Reifegrades eines Entwicklungsprozesses gt Es muss unabh ngig von der Verwendung eines Vorgehensmodells gepr ft werden inwieweit die spezifischen und generischen Ziele bei der Umsetzung des Prozesses wirklich erreicht sind gt Durch die Verwendung des V Modells XT ist eine gute Basis gelegt fur eine gute Bewertung in CMMI aber erst nach dem Appraisal Begutachtungs Prozess kann entschieden werden welcher Level erreicht ist m Die gleiche Argumentation gilt f r SPICE SWE Prof Dr W Weber h_da Fachbereich Informatik 457
3. gt systematische und nachvollziehbare Durchf hrung von nderungen Was wurde gegen ber der letzten Konfiguration ge ndert In welchen Konfigurationen wird diese Version der Komponente noch verwendet gt Wiederherstellung von alten Konfigurationen wenn z B ein Fehler zu einem Release gemeldet wird m Konfigurationsmanagement Tools gt verwalten sehr viele Dateien und zus tzliche Datenstrukturen darauf gt verwalten Versionen von Quellcode bekannt als Checkln und CheckOut gt bieten Funktionen zum Suchen Verzweigen und Zusammenf hren von Dateien Beispiele Open Source Subversion SVN Concurrent Version System CVS Ty wessen SWE Prof Dr W Weber h_da Fachbereich Informatik 466 Hochschule Darmstadt Fachbereich Informatik software Engineering 13 Zusammenfassung h da san i ii HOCHSCHULE DARMSTADT an ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 467 e 13 Zusammenfassung Themen in der Veranstaltung m Software Engineering im Projekt gt Anforderungsanalyse Spezifikation Abnahme und Systemtests gt Architektur gt Design gt Implementierung gt Test m Querschnittsthemen gt Qualitatsmanagement gt Software Metriken gt Vorgehens und Prozessmodelle gt Technisches Management Prozessorientiertes Qualit tsmgmt CMMI SPICE Assessments leider nicht geschafft SWE Prof Dr
4. 5 Software Architektur Literatur Len Bass et al Software Architecture in Practice Addison Wesley 2003 Documenting Software Paul Clements et al N Documenting Software Architectures Beyond Addison Wesley 2002 i Johannes Siedersleben Moderne Software Architektur dpunkt 2004 ne Software Architektur SWE Prof Dr W Weber h_da Fachbereich Informatik 98 E as S oftware Architektur Literatur Ralf Reussner Wilhelm Hasselbring RE Handbuch der Software Architektur Software dpunkt verlag 2006 A Riumes Douglass06 Bruce Powel Douglass Real Time UML Third Edition Addison Wesley 2006 ADVANCES IN THE UML FOR REAL TIME Systems Kruchten95 Philippe Kruchten Architectural Blueprints The 4 1 View Model of Software Architecture in IEEE Software 12 6 November 1995 pp 42 50 SWE Prof Dr W Weber h_da Fachbereich Informatik 99 Hochschule Darmstadt Fachbereich Informatik software Engineering 5 1 Architekturstile h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 100 5 1 Architekturstile Auf der Suche nach dem Architekturstil Architekturmuster fur ein Programm system Beispiel KWIC m Aufgabe gt Wie sieht eine Architektur f r folgendes einfache System aus The KWIC KeyWord in Context index
5. Generic Resources Diese Indicators helfen dem Assessor den Capability Level des Prozesses zu bestimmen Generic Work Products SWE Prof Dr W Weber h_da Fachbereich Informatik 446 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Attributes Generic Practices Generic Resources Generic Work Products fur Level 2 Managed Process aus ISO IEC 15504 5 Process Attribute 2 1 Performance Management is a measure of the extent to which the performance Durchf hrung of the process is managed mM Generic Practices Identify the objectives Ziele for the performance of the process Plan and monitor the performance of the process Adjust the performance of the process if planned results are not achieved E Generic Resources project planning management tools and control tools m Generic Work Products Documentation of the objectives milestones and timetable results and status of the process 1 generic practice generic resource generic work product Process Attribute 2 2 Work Product Management is a measure of the extent to which the work products produced by the process are appropriately managed Configuration management SWE Prof Dr W Weber h_da Fachbereich Informatik 447 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen SPICE Capability Level 3 Level 3 Established Process m Der Live Cycle Process existiert als ein or
6. Jj a SWE Prof Dr W Weber h_da Fachbereich Informatik 247 a 8 Testund Integration Was ist ein Fehler m Abst rze E Datenverluste m Fehlverhalten gt falsch implementierte Regeln Berechnungen gt 1 Ursache Programmierfehler L sung Test der Programme gt 2 Ursache unzureichendes Verst ndnis der Sachverhalte L sung Nachfragen bei Unklarheiten Missverst ndnissen bei Anforderungsanalyse und w hrend des Projektes gt Spezifikation pr zisieren Beispiel sPrime 1 liefert false der Test erwartet true wer hat recht II HOCHSCHULE DARMSTADT SWE Prof Dr W Weber h_da Fachbereich Informatik 248 THE 8 Test und Integration Was ist ein Fehler Il E aber auch unerfullte Erwartungen der Benutzer hat sich etwas anderes vorgestellt gt mangelnde unvollst ndige Kommunikation mit den Anwendern L sung Sorgf ltige Anforderungsermittlung Prototypen Schlechte Performance gt bei Anforderungsermittlung definiert gt auch technische Machbarkeit pr fen L sung Performance Prototypen Performance Tests Inkonsistente Benutzerschnittstellen gt st ren Arbeitsfluss gt erzeugen Fehlbedienungen gt verursachen geringe Akzeptanz gt erzeugen hohen Schulungsbedarf L sung genauer spezifizieren Prototypen zum Testen der Verst ndlichkeit Einhaltung Regeln zur Ergonomie SWE Prof Dr W Weber h_da Fachbereich Informatik 249 8 Test und Integrat
7. x 2 1 lt lt Task gt gt Alarm Filtering Thread lt lt Task gt gt CmdRequest Queue lt lt Message Queue gt gt 1 Monitor Thread lt lt Task gt gt 1 Aircraft Flight Plan 1 1 Alarm Annunciation Thread 1 1 1 1 1 1 lt lt Task gt gt lt lt Semaphore gt gt 1 ListView lt lt Resource gt gt 1 Concurrency TR SWE Prof Dr W Weber h_da Fachbereich Informatik DARMSTADT IVERSITY OF APPLIED SCIENCES 136 Weg 5 2 Darstellung der Architektur a Prozess Sicht tin aniehnung an tkruchtenas Thread Level Concurrency and Resource View Darstellung der Kommunikation zwischen cd PHP Request Threads Prozessen 1 HTML Get URI lt lt process gt gt gt lt lt process gt gt Mozilla HTMLClient Apache Webserver 4 return HTMLPage lt HTML_Code lt D amp oO I He g pom gt 2 D oe 2 PHP Parse lt lt process gt gt tempPHP PHP hda kocnsenute oamusmaor SWE Prof Dr W Weber h_da Fachbereich Informatik 137 5 2 Darstellung der Architektur a eS ca Einsatz Deployment Physische Sicht ict m Betrachtet wie die Softwarearchitektur auf die physikalischen Komponeten abgebildet wird Rechnerknoten im Netz Prozessoren etc m Viele Embedded Systeme bestehen aus Multiprozssorsystemen mit vielen unterschiedlichen Hardwareeinheiten Manche Autos haben mehr als 50 Prozessorknoten und mehr
8. 10 Metriken Halstead Metriken Textuelle Komplexitat m Anzahl der unterschiedlichen Operatoren n1 m Anzahl der unterschiedlichen Operanden n2 m Anzahl des Auftretens von Operatoren N1 m Anzahl des Auftretens von Operanden N2 Operatoren Anz Operanden Primitives Beispiel zur void 1 x Veranschaulichung des MaBes N J y void tausch float amp x float amp y amp 2 z fimt z float 3 zei 3 X y y z 1 1 4 ni 8 N1 16 n2 3 SWE Prof Dr W Weber h_da Fachbereich Informatik Anz N2 9 363 10 Metriken Halstead Metriken Textuelle Komplexit t m Abgeleitete Ma e gt Gr e des Vokabulars tausch 8 3 11 L nge der Implementierung tausch 16 9 25 gt Berechnete L nge tausch N 8 ld 8 3 ld 3 N 24 4 75 28 75 gt Programmgr e Volumen V 25 ld 11 25 3 5 87 5 n ni n2 N N1 N2 N n1 ld n1 n2 ld n2 V N ld n gt es gibt viele weitere Ma e mit umstrittener Aussagekraft SWE Prof Dr W Weber h_da Fachbereich Informatik PP 10 Metriken McCabe Ma zyklomatische Zahl Strukturelle Komplexit t m Gibt Auskunft ber die Komplexit t der Kontrollstruktur einer Funktion m zyklomatische Zahl z G gt Originaldefinition z G P P Anzahl der linear unabh ngigen Pfade durch den Programm Graphen G gt Alternative Berechnung z G e n 2p e Anzahl Kanten von G n Anzahl Knoten von G
9. Analysierbarkeit f1 STMT f2 VG f8 AVGS f4 COMF f5 FAN_IN f6 FAN OUT SWE Prof Dr W Weber h_da Fachbereich Informatik 374 10 1 Metriken und Tools Darstellung der Messergebnisse Kiviatdiagramm COMF AVGS le_stat ct_vg ct_bran VOCF de_lvars ic_param de_calls ct_exit i _varp de_callm ct_path LEVL HOCHSCHULE DARMSTADT ct_bran ct_vg ic_param dc_calls ct_exit ic_varpe de_calling po OT oo VALUE 7 00 60 00 SWE Prof Dr W Weber h_da Fachbereich Informatik ax ax 0 00 3 00 RR x x CT 0 00 1 00 KK x 4 00 RER Ausrei er gt Ursache untersuchen 375 10 1 Metriken und Tools Darstellung der Messergebnisse Kontrollflussgraph Kontrollflussgraph eines Teils der Implementierung des Spiels Carcasonne il PE SWE Prof Dr W Weber h_da Fachbereich Informatik 376 i a 10 1 Metriken und Tools Metriken und Tools m Mit modernen Tools k nnen sehr viele verschiedene vordefinierte Metriken auf die Arbeitsergebnisse vor allem auf Code angewandt werden m Die Darstellungen erlauben eine schnelle Identifizierung von Ausrei ern und die interaktive Analyse der Ursachen gt Die Versuchung ist gro viele Metriken zu verwenden gt Die Versuchung ist gro AusreiBer in allen Metriken zu analysieren gt Die intelligente Auswahl der Metriken und Grenzwerte wird umso wichtiger en S
10. Prof Dr W Weber h_da Fachbereich Informatik 291 i f 8 1 3 Testdurchfuhrung Einordnung im V Modell il ER SWE Prof Dr W Weber h_da Fachbereich Informatik N a 292 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 2 Modultest h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 293 8 2 Modultest Was istein Modultest m Ein Modultest ist der Test eines einzelnen Teilst cks der Software eines Moduls gt Funktionen lokales Testen von globalen Funktionen Funktionen in Klassen gt Klassen Testen aller Funktionen Schnittstelle mit Aufruf von Funktionen der gleichen Klasse gt Ketten von verbundenen Klassen z B durch Assoziationen gegenseitige Aufrufe Testen von Eunktionen mit Aufruf von Funktionen anderer Klasseninstanzen gt Komponenten Testen aller Funktionen der Schnittstelle der Komponente Jede Funktion wird zuerst einzeln f r sich getestet Aber wie all oe SWE Prof Dr W Weber h_da Fachbereich Informatik 294 8 2 Modultest driver A lsolierter Test einzelner Funktionen i m Drivers sind Testmodule die gt das Verhalten einer aufrufenden Funktion simulieren Modul A un nn Datenbank Datei N Attribute von Klassen globale Variablen stub A1 stub A2 die zu testende n Funkt
11. Web_ Browser lt lt provided Interfaces gt gt Themelnterface PluginInterface lt lt required Interfaces gt gt InternetAccessForWebBrowserl nterface lt lt realizations gt gt Browser GUl HTML _Translator White Box mit Interna lt lt component gt gt __ Web_Browser SWE Prof Dr W Weber h_da Fachbereich Informatik InternetAccessForWebBrowserInterface lt lt component gt gt Internet_Access Themelnterface Web_ Browser Theme C lt lt component gt gt Plugin Black Box Uberblick Plugin greift auf PluginInterface Webbrowser zu lt lt Interface gt gt Plugininterface lt lt UuSe gt gt lt lt component gt gt Plugin 130 ia 52 Darstellung der Architektur En Komponenten Sicht Komponentendiagramm em s um Darstellungselemente Komponente Komplexer implementierte Schnittstelle UML2 glasklar Pot N component Komponente2 component Komponente1 gt Klasse Bestandteile einer Komponente N g N Kompositions N konnektor N N AN ITF N i A Realisierungs X L f N Cee s Allgemeine N Ahhin 257 hawiahs r N Abh ngigkeitsbeziehung Bestandteil2 beziehung Verwendungs beziehung Ny use artifact D manifest Komponente A Implementierungs beziehung Ben tiate Delegationskonnektor Delegationskennektor lt Spades i Schnittstelle hda T voc sonns oamusm
12. p Anzahl der verbundenen Komponenten gt Alternative Berechnung f r p 1 z G T 1 f r p 1 t Anzahl der Verzweigungen ber booleschen Bedingungen in G SWE Prof Dr W Weber h_da Fachbereich Informatik 365 i 10 Metriken McCabe Ma Programm Graph of ce af 1 lt 2 3 7 8 10 gt 2 lt 2 4 6 8 10 gt 3 lt 2 4 6 8 9 8 10 gt 4 lt 1 5 gt lt 2 3 7 8 9 8 10 gt ist z B linear abh ngig 3 2 1 M z G e n 2p 10 8 2 4 10 Kanten 8 Knoten 1 Komponente Bz G 1 1 3 1 4 Verzweigungen Start a f SWE Prof Dr W Weber h_da Fachbereich Informatik 10 Metriken Bewertung McCabe m Das McCabe Ma gt ist nur f r Code anwendbar gt betrachtet nicht wie kompliziert eine einzelne Anweisung ist oder wie stark sie verschachtelt ist gt dennoch wird das McCabe Ma oft eingesetzt Zerlege jedes Programm mit z G 2 10 in Teilprogramme so dass f r jedes Teilprogramm gilt z G lt 10 rca nee Be SWE Prof Dr W Weber h_da Fachbereich Informatik 367 ij E 10 Metriken Ma e zur Beurteilung der der Kopplung zwischen Teilen des Systems Informationsfluss Analyse IF4 lt lt component gt gt Plugin m Informationsfluss Analyse gt Fla fan in Zahl der Datenfl sse die zu einem Modul m f hren gt FO fan out Zahl der Datenfl sse die von einem Modul wegf hren gt IF4 S Flm FO Ma zahl f r
13. 8 5 Beispiel Modul Integrationstest Beispiel Integrationstest m Teilsysteme d e werden zu gr eren Teilsystem c zusammengesetzt d oder e kann auch Fremdsystem sein m Beispiel in unserem Praktikum d und e sind Teilsysteme mischen und start c ist Gesamtsystem gt Integrationstest der obersten Stufe bei uns recht trivial gt Ein Testfall f r diesen Integrationstest ist der normalerweise schon nach der Anforderungsdefinition spezifizierte Abnahmetestfall SWE Prof Dr W Weber h_da Fachbereich Informatik 326 si 85 Beispiel Modul Integrationstest Beispiel Integrationstest Teil bzw Gesamtsystem Gewichtwert von externer Waage wenn simuliert gt deterministisch Teilsystem mischen Teilsystem start Kommandos Ventil auf an externe Dosierer Bildschirm ausgabe Bl Attribut Al A2 Daten von externen y i ee ead Attribute A1 a Gew Wert auf Display atelen l Nachzustand Vorzustand Bildschirm eingabe Bl Bildschirm eingabe B2 SWE Prof Dr W Weber h_da Fachbereich Informatik 397 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 6 Testwerkzeuge h da san i ii HOCHSCHULE DARMSTADT an ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 328 E 8 6 Testw
14. KWIC Prozeduraler Stil Direct Memory Access Subprogram Call OO Sys 2 I Circular Shift Alphabetizer Alphabetized Input ndex Output Medium gt Zerlegung in vier Basisfunktionen gt Koordination durch ein Hauptprogramm das sie sukzessive aufruft gt Daten werden als gemeinsame Ressource von den Modulen verwendet gt Keine Kapselung der Daten Subroutine with shared data Master Control SWE Prof Dr W Weber h_da Fachbereich Informatik 103 e 5 1 Architekturstile KWIC Objektorientierter Stil zentral gesteuert Subprogram Call Master Control Abstract Data Types System IO ge 5 a O ATpnabetic Input Output Medium Medium gt Kontrollfluss durch zentrale Koordination gt Datenkapselung gt Algorithmen und Datenreprasentation der einzelnen Klassen k nnen ge ndert werden ohne die anderen zu beeinflussen a gt Circular Shift SWE Prof Dr W Weber h_da Fachbereich Informatik 104 5 1 Architekturstile KWIC Eventgesteuerter Stil Implicit Invocation Subprogram Call IO Control System input Circular Shift Implicit Invocation Output gt Keine zentrale Steuerung gt Ver nderung der Daten l st Events aus gt Events f hren zu Aktionen die ihrerseits Events erzeugen gt Modell aktiver Daten SWE Prof Dr W Weber h_da Fachbereich
15. Konfig d Prozesses Zeit ill een SWE Prof Dr W Weber h_da Fachbereich Informatik 407 ii Vorgehens und Prozessmodelle Disziplinen Arbeitsschritte und Phasen im RUP Phases Disciplines Arbeitsschritte Organization along time A Organization along content Core Process Workflows Business Modeling Requirements Analysis amp Design Implementation Test Deployment Core Supporting Workflows Configuration amp Change Mgmt v Project Management Environment l u Iterations Quelle Rational Unified Process 2000 Tool J ee SWE Prof Dr W Weber h_da Fachbereich Informatik 408 aE i iL Vorgehens und Prozessmodelle Disziplinen Arbeitsschritte und Phasen im RUP Beispiel Disciplines Arbeitsschritte Organization along content Core Process Workflows Business Modeling Requirements Analysis amp Design Implementation Test Deployment Core Supporting Workflows Configuration amp Change Mgmt Project Management Environment terations 7 7 Implementierungs Meilensteine Machbarkeitsstudien Kernsystem incl fertiges System incl mit Prototyping Tests System Anpassungen ee SWE Prof Dr W Weber h_da Fachbereich Informatik i i UNIVERSITY OF APPLIED SCIENCES i 409 E 11 Vorgehens und Prozessmodelle Bewertung RUP UP Vorteile Nachteile m Durch die berlappung verk rzt sich Dauer m RUP stellt hohe Anforderungen an
16. glichenTestf lle laufen zu lassen Welche Prinzipien zur Auswahl von Testf llen kennen Sie Wie unterscheiden sich Black Box Tests und White Box Tests Welche Unterschiede gibt es zwischen Anweisungs Zweig Pfad und Bedingungs berdeckung Was ist Integration Was halten Sie von der Aussage Sie haben das Programm doch getestet wie kann dann so ein Fehler auftreten Warum muss man in der Architektur im Design schon an Test denken Warum gibt es im V Modell 4 Testphasen Wie unterscheiden sie sich Woher wei CppUhnit welche Tests ausgef hrt werden sollen wenn die Testklassen nicht in der Main Funktion instanziiert werden SWE Prof Dr W Weber h_da Fachbereich Informatik 345 Hochschule Darmstadt Fachbereich Informatik software Engineering Teil Il Querschnittsthemen 22258 hda ves fii HOCHSCHULE DARMSTADT n SBHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 346 Querschnittsthemen Was sind Querschnittsthemen m Bisher wurden die Themen entlang eines Projektdurchlaufs behandelt gt es gibt aber auch Themen die den einzelnen Phasen bergeordnet sind oder in vielen Phasen vorkommen m Wir behandeln folgende Querschnittsthemen weiterhin aus der Sicht eines Software Entwicklers gt Qualit tssicherung gt Software Metriken gt Vorgehens und Prozessmodelle gt Technisches Management gt Proz
17. in Komponenten und Schnitt stellen zeigen z B Audio Source und Audio Manager und die Verantwortlichkeiten dokumentieren gt Verteilungsdiagramme welche die Hardware und die jeweils darauf laufende Software aufzeigen Soundprozessor Entwicklungsrechner Target etc gt Timing Diagramme welche die Umsetzung von kritischen Vorg ngen mit Prozessen und Threads zeigen z B f r Zeitverhalten beim Uberblenden gt Sequenzdiagramme welche die Umsetzung von Use Cases skizzieren die mehrere Komponenten betreffen z B Audioquelle wechseln gt weitere Dokumente und Diagramme je nach Entwicklungsprozess Die Anzahl und Art der Diagramme h ngt stark vom Entwicklungsprozess dem Projekt dem Team und dem Kommunikationsbedarf ab SWE Prof Dr W Weber h_da Fachbereich Informatik 146 5 3 Zusammenfassung Software Architektur Nutzen einer SW Architektur en SWE Prof Dr W Weber h_da Fachbereich Informatik m f r den Entwicklungsprozess gt trifft weitreichende fr he Designentscheidungen gt weist Machbarkeit von Softwarefunktionalit t nach gt macht Vorgaben f r Design und Implementierung gt strukturiert den Entwicklungsprozess gt bietet Kommunikationsplattform m f r die Planbarkeit gt liefert die Einheiten der Planung f r Design Implementierung Test und Wartung m fur die Wettbewerbsf higkeit gt reduziert Kosten durch Wiederverwendung im Gro en gt erh ht Flexibilit t durch Bet
18. rigkeit sollte sich auf einen gemeinsamen Fokus ein Verhalten oder eine Funktionalit t im Gesamtsystem beziehen Wir sammeln Operationen die Bezug haben zum Katalog Management wie Sort_Catalog und Search_Catalog Ebenso identifizieren wir alle Operationen und Attribute die Bezug haben zu einem einzelnen Ausleiheobjekt wie z B Print_Item Delete_Item etc gt Finde eine geeignete Oberstruktur f r diese neuen Gruppierungen natural homes um sie dort einzubinden Im Beispiel sind dies die bereits vorhandenen Klassen Catalog und Item SWE Prof Dr W Weber h_da Fachbereich Informatik 530 6 4 Anti Patterns The Blob L sungsans tze Il gt L se alle redundanten oder indirekten Beziehungen und ersetze sie durch direkte Beziehungen Im Beispiel betrifft dies die Beziehung zwischen Item und Library Jedes Item steht zun chst in unmittelbarer Beziehung zu einem Katalog und nur ber diesen also indirekt auch in Beziehung zur gesamten B cherei Wir verzichten auf die Beziehung zwischen Item und Library und definieren die direkte Beziehung zwischen Catalog und Item gt Pr fe ob assoziierte Klassen ggf als Klassen erkannt werden k nnen die von einer gemeinsamen Basisklasse abgeleitet sind gt Ersetze f ge hinzu transiente Beziehungen und Beziehungsklassen durch Klassen die die entsprechenden Attribute und Operationen kapseln Im Beispiel entstehen bei diesem Schritt Klassen wie Che
19. rstellt dufeh Tear Was habe ich erreicht Was will ich heute erreichen Priorisierte Liste von zu liefernden Funktionen Welche Hindernisse Stories erstellt durch Product Owner ScrumMaster beseitigt Hindernisse hda SWE Prof Dr W Weber h_da Fachbereich Informatik 433 Die agile Vorgehensweise Scrum Arbeitstechniken Sprint Review Meeting 4 Std am Ende des Sprints Team pr sentiert Project Owner neue Funktionalit t Daily Scrum Meeting 24 Stunden nn Potenziell lieferf higes Sprint Produkt Product Backlog 2 4 Wochen inkrement Backlog k Sprint Sprint Retrospective Meeting Scrum Flow 15 Min nach Review Meeting ScrumMaster berlegt mit Team Quelle wie Ablauf des n chsten Sprints Aufgabenliste f r Sprint http www microtool de instep de scrum asp verbessert werden kann erstellt durch Team so dass Arbeit effizienter wird und mehr Spa macht Priorisierte Liste von zu liefernden Funktionen Stories erstellt durch Product Owner hda SWE Prof Dr W Weber h_da Fachbereich Informatik 434 11 Vorgehens und Prozessmodelle Bewertung agiles Vorgehen Vorteile m Einsatzf hige Produkte f r den Auftraggeber in kurzen Abst nden m Integration der Erfahrungen der Anwender in die Entwicklung M Uberschaubare Projektgr e Korrigierbare Entwicklungsrichtung m Keine Ausrichtung auf einen einzigen Endtermin m Wissensverbreiterung dur
20. E 4 Abnahmetest Beispiel Ableiten von Funktionstests Ill Aktivitaten mit Ausnahmen O Aufforderung PIN Eingabe gt Kundenreaktion os keine Eingabe f r 30 Sek Kunde bricht ab PIN Eingabe erfolgt PIN falsch und lt 3 Fehlversuche PIN Validierung e al PIN falsch und gt 3 Fehlversuche PIN als richtig validiert System gibt Zugang frei Abbruch SWE Prof Dr W Weber h_da Fachbereich Informatik 79 m 4 Abnahmetest Ableiten von Funktionstests IV m Man kann das System nicht mit allen m glichen Eingabedaten testen gt man teilt die Menge der Testf lle der m glichen Eingaben in Klassen ein so dass man sagen kann o Falls ein Testfall aus der Menge der Testf lle der Klasse richtig abl uft so laufen auch die anderen mit gro er Wahrscheinlichkeit richtig ab m gliche Testf lle e ausgew hlter Testfall m Testplan besteht aus der Menge der ausgew hlten Testf lle e m Fur jeden Testfall sind alle Eingabewerte Bildschirmeingaben Zust nde des Systems und Ausgabewerte Bildschirmausgaben Zust nde des Systems spezifiziert SWE Prof Dr W Weber h_da Fachbereich Informatik 80 4 tl HOCHSCHULE DARMSTADT INIVERSITY OF APPLIED SCIENCES 4 Abnahmetest Ableiten von Funktionstests IV Zweigtesten Frage Wie teile ich in Aquivalenzklassen ein Welche Eingabedaten wahlen Sie fur die Testfalle m 3 Arten der Einteilung i
21. Entwurfsmustern Erich Gamma Richard Helm Ralph Johnson John Vlissides Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1994 deutsch Entwurfsmuster 1996 Beispiele des Skripts stammen aus diesem sign Patterns Elements of Reusable Object Oriented Software _ Buch 5 Entwurfsmuster von Kopf bis Fu Eric Freeman amp Elisabeth Freeman et al 3 Entwurfsmuster von Kopf bis Fu O REILLY 2006 OREILLY SWE Prof Dr W Weber h_da Fachbereich Informatik a 6 3 Entwurfs muster Fazit zu Entwurfsmustern m Entwurfsmuster gt bieten bew hrte L sungen fur immer wiederkehrende Probleme im Design gt sind als L sung durch Literatur dokumentiert und international bekannt gt machen einen Entwurf nderbar und flexibel gt helfen existierende SW Entw rfe zu analysieren und zu reorganisieren m Aber gt Entwurfsmuster machen das Design komplizierter und abstrakter gt es muss nicht jedes Problem mit einem Entwurfsmuster gel st werden gt Entwurfsmuster sollten nur dann eingebaut werden wenn die Flexibilit t auch tats chlich ben tigt wird ill ee SWE Prof Dr W Weber h_da Fachbereich Informatik 223 6 3 Entwurfsmuster Arten von Mustern m Architekturmuster Architekturstile Architectural Patterns gt dokumentieren Entwurfserfahrungen die sich auf globale Aspekte des Gesamtsystems beziehen gt siehe Kapitel Architektur z B 4 Sc
22. L sung ist gut welche L sung ist schlecht E Wege zu einem guten Design gt Prinzipien lernen gt Regeln Tipps und Tricks lernen Best Practices gt aus eigenen Fehlern lernen gt Designprinzipien gt Regeln gt ben m Weitere M glichkeiten gt Bekannte und gute L sungen einsetzen gt Design Patterns gt aus bekannten Fehlern lernen gt Anti Patterns SWE Prof Dr W Weber h_da Fachbereich Informatik 155 6 Design Zur Erinnerung aus OOAD Regeln fur ein gutes Design I E Grundprinzipien gt Trennung von Zust ndigkeiten gt starker Zusammenhalt jeder Teil jede Klasse hat genau eine Aufgabe gt Minimierung von Abh ngigkeiten Minimiere die Abh ngigkeiten zwischen Systemteilen gt Geheimnisprinzip Kapsele das interne Wissen eines Systemteils und verrate es niemand anderem gt Homogenit t Lose hnliche Probleme mit hnlichen L sungen und verwende hnliche Strukturierungsgr en innerhalb einer Strukturierungsebene gt Redundanzfreiheit Keine Teile sind doppelt vorhanden SWE Prof Dr W Weber h_da Fachbereich Informatik 156 6 Design Zur Erinnerung aus OOAD Regeln fur ein gutes Design Il m Regeln zum Entwurf von Klassen gt Setze Vererbung sparsam ein gt Normalisiere das Datenmodell gt Vermeide transitive Assoziationen gt Analysiere m n Beziehungen genau gt Vermeide 1 1 Beziehungen gt Modelliere nur fachliche nie technische
23. Muster Composite Pattern Zweck m F ge Objekte zu Baumstrukturen zusammen um Teil Ganzes Hierarchien zu repr sentieren m Erm glicht es Klienten sowohl gt einzelne Objekte Bl tter eines Baumes als auch gt Kompositionen von Objekten Nicht Blatt Knoten einheitlich zu behandeln z B zeichne Motivation m Aufbau komplexer Diagramme aus einfachen Komponenten z B grafische Anwendungen m Der Benutzer kann aus elementaren Komponenten Bl tter eines Baumes gr ere Komponenten zusammenf gen und aus diesen wiederum gr ere Komponenten etc m dee Ein Client sollte bei der Verwendung der Komponenten nicht differenzieren m ssen ob es sich um eine elementare oder eine zusammengesetzte Komponente handelt SWE Prof Dr W Weber h_da Fachbereich Informatik 215 Ve 6 3 Entwurfsmuster Das Kompositum Muster 1x rekursive Beziehung Zeichne lt FuegeHinzu Grafik Entferne Grafik GibKindobjekt int eineAbbildung grafiken Abbildung in mf Zeichne Zeichne Zeichne 1Zeichne FuegeHinzu Grafik Entferne Grafik GibKindobjekt int eine rekursive Struktur aus Grafikobjekten Zeichne fur alle in grafiken g gt Zeichne FugeHinzu Graphik g Fuge g in Liste der Grafikobjeke ein Liste die Teil von Beziehung realisiert Anwendbarkeit Reprasentation von Teil Ganzes Hierarchien Klient soll in der Lage sein die Unterschiede
24. OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 258 8 1 1 Black Box Test Spezifikation Beis piel Hi 1 ber den float Zahlen sei folgende Fkt definiert f x sin x fur 0 lt X lt 360 270 360 0 o o gt X f x 1 f r x gt 360 0 90 1 1 Aquivalenzklassen gt Es gibt vier Klassen von Eingaben 0 T 0 360 360 und Eingabe float falls diese Eingabe m glich g ltige quvalenzklassen sind abgeleitet aus den Fallunterscheidungen hier jeder Zeile der Spezifikation plus zwei ung ltige Aquivalenzklassen Teste einen Vertreter in jeder Klasse 2 Grenzwerte gt An den R ndern passieren gerne Fehler gt Teste die Grenzwerte jeder Aquivalenzklasse 3 Erfahrung intuitive Tests gt Der Sinus f r 90 270 wird oft aus dem Sinus von 0 90 berechnet um Speicherplatz zu sparen gt Teste in jedem Sinus Segment durch einen Vertreter ob die Berechnung stimmt SWE Prof Dr W Weber h_da Fachbereich Informatik 259 Spezifikation 8 1 1 Black Box Test Reduzierung der Tests durch Bildung von Aquivalenzklassen a m Bilden von Aquivalenzklassen gt Einteilung der Menge der m glichen Werte zu einer Eingabe z B Parameter einem Eingabezustand z B das Ergebnis beeinflussendes Attribut der Klasse in Aquivalenzklassen gt Annahme Das Testobjekt reagiert bei der Verarbeitung eines Vertreters
25. Programmiersprachen wirken sich nat rlich auch auf die Wartbarkeit und bertragbarkeit aus gt Die Festlegung der geforderten Qualit tseigenschaften ist genauso wichtig wie die Festlegung der Funktionalit t SWE Prof Dr W Weber h_da Fachbereich Informatik 30 2 1 Grundlagen des Software Engineering Softwarequalitat Ma e fur Qualitat seigenschaften m Bei der Spezifikation muss die Qualit t der zu erstellenden Software definiert werden gt Es kann nach der Fertigstellung nachgepr ft werden ob die Software den spezifizierten Qualit tsanforderungen gen gt m Funktionserf llung gt Test Funktioniert die Software so wie vereinbart gt d h tut die Software das was in der vom Auftraggeber abgezeichneten Spezifikation steht m Effizienz gt spezifiziert durch Angabe von maximalen Antwortzeiten Speicherverbrauch etc m Zuverl ssigkeit gt Spezifiziert durch Wahrscheinlichkeit dass in der Zeit 0 t kein Fehler auftritt m Andere Ma e wie z B f r Erweiterbarkeit oder Wartbarkeit gt sind schwieriger zu definieren gt Kapitel Softwaremetriken SWE Prof Dr W Weber h_da Fachbereich Informatik 24 E 2 1 Grundlagen des Software Engineering Softwarequalit t Qualit t in der deutschen Sprache m Die Qualit t die ein Produkt hat wird h ufig in direkter Verbindung mit der Fehlerfreiheit gesehen gt Es gibt allerdings viele andere Qualitatseigenschaften welche die Qualit t eines Pr
26. S ule 2 a 50 b 30 c 20 aule 3 Bei Ver nderung gt benachrichtige fur alle angemeldeten Beobachter b b gt aktualisiere Nach Benachrichtigung gt aktualisiere peobachteter Zustand subjekt gt gibZustand SWE Prof Dr W Weber h_da Fachbereich Informatik 209 6 3 Entwurfs muster Beobachtermuster Observer Pattern Aufrufverhalten einKonkretesSubjekt einKonkreterBeobachter einAndererKonkreterBeobachter konkretesSubjekt konkreterBeobachter konkreterBeobachter setzeZustand benachrichtige l l l aktualisiere gibZustand return Zustand aktualisiere gibZustand return Zustand en SWE Prof Dr W Weber h_da Fachbereich Informatik TIT RMSTADT HE UNIVERSITY OF APPLIED SCIENCES 210 6 3 Entwurfsmuster Beobachtermuster Observer Pattern Einsatz in der Modellierung Beobachter EEE aktualisiere a meldeAn Beobachter meldeAb Beobachter benachrichtige KonkreterBeobachter beobachteterZustand subjektZustand gibZustand setzeZustand m Ein Pattern ist eine weltweit bekannte Musterl sung gt Bitte ordnen Sie die Klassen auch genau so an evil als eigenes Diagramm gt benennen Sie die Klassen Subjekt und Beobachter und Methoden auch so passen Sie nur die Parameter an SWE Prof Dr W Weber h_da Fachbereich Informatik 2141 Pe 6
27. SWE Prof Dr W Weber h_da Fachbereich Informatik 401 11 Vorgehens und Prozessmodelle 2 Wie ist ein Prototyp aufgebaut Il vertikaler Prototyp gt exemplarisch ausgew hlte Teilfunktionen des zuk nftigen Systems vollkommen realisieren gt z B Performanz einer kritischen Anwendung gt auch als explorativer Prototyp vertikaler Prototyp Aes SWE Prof Dr W Weber h_da Fachbereich Informatik 402 11 Vorgehens und Prozessmodelle 2 Wie ist ein Prototyp aufgebaut Ill Gesamtsystem mit L cken gt alle Teilsysteme realisiert au er z B Plausibilit tspr fungen Ausnahme und Fehlersituationen komplexe Berechnungsroutinen Prototyp mit L cken SWE Prof Dr W Weber h_da Fachbereich Informatik 403 z A 11 Vorgehens und Prozessmodelle 3 Inwieweit findet der Prototyp Anwendung im endgultigen System SE Throw away Prototype Quick and dirty P Rapid Specification P gt findet keine Verwendung bei nachfolgender Implementierung gt dient einzig und allein zur Entwicklung korrekter robuster Spezifikationen Add on Prototype Rapid Cyclic Prototype gt wird bei der Implementierung des Zielsystem mitverwendet gt ausgehend von einem ersten Add on Prototype wird zum Zielsystem weiterentwickelt z B Prototypenmodell In jeder Iterationsstufe gt wird der schon entwickelte Teil weiter verbessert gt wird System vom Umfang her erwei
28. Standards Richtlinien Methoden und Werkzeuge m F r ein konkretes Softwareentwicklungsprojekt muss das Vorgehensmodell konkretisiert werden neu deutsch Tailoring all MOSEHEOAMENET SWE Prof Dr W Weber h_da Fachbereich Informatik 11 Vorgehens und Prozessmodelle Welche Vorgehensmodelle gibt es Klassische Modelle Code amp Fix Wasserfall Modell Evolutionares Modell Inkrementelles Modell V Modell Prototypen Modell t Unterscheiden sich in der Abfolge von Phasen SWE Prof neue komlexe Modelle Rational Unified Process RUP V Modell XT Agile Entwicklung j Definieren den Gesamtprozess mit Definition der Aktivit ten Arbeitsergebnissen etc der einzelnen Prozessschritte Phasen Dr W Weber h_da Fachbereich Informatik 388 ma B 11 Vorgehens und Prozessmodelle Code amp Fix Erstelle erste Version ndern bis der Kunde zufrieden ist Einsatz der Version Entwicklung gt Verbesserung il BETEN SWE Prof Dr W Weber h_da Fachbereich Informatik il 389 E 11 Vorgehens und Prozessmodelle Bewertung von Code amp Fix Vorteile m Geringer Managementaufwand m Zufriedene Kunden Nachteile Schlechtere Wartbarkeit Zuverl ssigkeit und bersichtlichkeit des Codes Starke Abh ngigkeit vom individuellen Programmierer Differenzen ber Funktionsumfang zwischen Entwickler und Anwender Keine Entwicklung von Dokument
29. User_ID Items_Out Fines Zuverl ssigkeit 3 oo Erweiterbarkeit Funktonsert nnd oo Wartbarkeit Library_Main_Control Current Catalog Current_Item User_ID Fine_Amount Etc www antipatterns com catalog him Do_Inventory EN Check_Out_ tem Item Check_In_Item Item ie Add_Item Item Cost Delete_Item Item Date In Print_Catalog Qty Sort_Catalog etc Search_Catalog Params l Edit_Item Find_Item Print Open_Library List_Catalogs Issue_Library_Card Archive_Catalogs Frage Was ist schlecht Was kann man besser machen Calculate_Late_Fine SWE Prof Dr W Weber h_da Fachbereich Informatik 297 6 4 Anti Patterns The Blob ein Beispiel mM Typisch f r den Blob ist eine Klasse welche die gesamte Verarbeitung als Monopol verwaltet w hrend andere Klassen prim r die Daten kapseln gt fast die gesamte Verantwortung liegt bei einer einzelnen Klasse gt unubersichtlich m m Klassendiagramm dr ckt sich dies dadurch aus dass eine komplexe Controller Klasse umgeben ist von zahlreichen einfachen Datenklassen gt fette Spinne im Netz m Im Grunde genommen entspricht der Blob einem prozeduralen Entwurf der mit Hilfe einer objekt orientierten Sprache implementiert wird Jj E SWE Prof Dr W Weber h_da Fachbereich Informatik 228 6 4 Anti Patterns The Blob ein Software Development Anti Pattern m Symptome gt Einzelne Klasse mi
30. W Weber h_da Fachbereich Informatik 468 Hochschule Darmstadt Fachbereich Informatik software Engineering 13 1 Ergebnisse im Praktikum h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 469 13 1 Ergebnisse im Praktikum Inhalt des Praktikums m Der CocktailPro war kein wirklich gro es Projekt gt relativ geringer Umfang kurze Laufzeit kleines Team gt keine Wartung gt keine Change Requests gt wenige Schnittstellen nach au en z B Zulieferung von Fremdcode gt keine Ausnahme und Fehlerbehandlung m aber es wurden dennoch viele Themen behandelt gt OOA OOD Modellierung Use Cases Klassendiagramme Sequenzdiagramme gt Implementierung Guidelines Objektorientierung Beobachter Muster gt Integration Zulieferung Rezeptbuch verteilte Entwicklung gt Test Blackbox Whitebox C Unit gt Review gt Metriken gt CASE Tool Round Trip Engineering SWE Prof Dr W Weber h_da Fachbereich Informatik 470 13 1 Ergebnisse im Praktikum Wie gut ist lhr Entwurf m Analysieren Sie bitte folgende Change Requests es wird ein neues Rezeptbuch mit neuen Rezepten zugeliefert das User Interface soll in Deutsch und Englisch verf gbar sein es wird in den Rezepten ein neuer Verarbeitungsschritt R hren eingef hrt es soll bei einem F llstand von 200g ein Warnungs Piepton au
31. Wartbarkeit gt erh ht die Verst ndlichkeit des Codes f r Teammitglieder und Neulinge gt reduziert Bedarf an speziellem Fachwissen m Integrierbarkeit gt Vermeidung von spat auffallenden Inkompatibilitaten von Bibliotheken Einheitliche Aufteilung des Codes auf Quellcode Dateien m Zuverl ssigkeit gt klare Regeln zum Umgang mit fehlertr chtigen Konstrukten z B Pointern m Robustheit gt Initialisierungsregeln Zuweisungsregeln m Testbarkeit gt Einheitliche Fehlerbehandlung m Effizienz der Entwicklung gt Bietet eine Kommunikationsbasis Empfehlung von anerkannten bew hrten Elementen gt Vermeidung von bekannten fehleranf lligen Sprachkonstrukten SWE Prof Dr W Weber h_da Fachbereich Informatik 242 7 Implementierung Nachteile einer Programmierrichtlinie m Echte Nachteile gt Einschr nkung der Individualit t des Entwicklers Gew hnung an die vorgegebene L sungen erforderlich m beliebte Ausreden zur Umgehung gt Sch nes Programmieren ruiniert die Performanz der Unterschied wird von heutigen Compilern weg optimiert gt Kommentare in halbfertigem Code sind sinnlos grundlegende Entscheidungen wurden im Modell getroffen gt Die Anpassungen mache ich wenn ich fertig bin das passiert dann nie m Oft Widerstand speziell von den Programmier Profis 243 SWE Prof Dr W Weber h_da Fachbereich Informatik E 7 Implementierung Kontrollfragen Impl
32. amp b Complex operator Complex amp a Complex amp b Darstellung vereinfacht Tatsachlich gibt es deutlich mehr Klassen und Methoden innerhalb des Frameworks Fi estenden Klasse i ssi SWE Prof Dr W Weber h_da Fachbereich Informatik 337 i UNIVERSITY OF APPLIED SCIENCES A if 8 6 Testwerkzeuge C Unit mit TestSuite m Wie konstruiere ich den Test so dass ich alle Tests zusammen laufen lassen kann gt Kreiere eine Suite mit mehreren Tests gt Mit Hilfe des Frameworks werden einzelne TestCases aus den Methoden der konkretenTestfixture z B ComplexNumberTest gebildet und der Suite hinzugef gt Jeder TestCase besteht aus der SetUp der Test der TearDown und der run TestResult Methode In der run TestResult Methode werden die anderen Methoden aufgerufen gt Beim Ausf hren der Suite werden dann alle Elemente der Suite ausgef hrt run aller Elemente wird aufgerufen gt Elemente der Suite k nnen TestCases oder auch Suites sein Compositum Muster gt Falls das Element ein TestCase ist wird durch Run die SetUp Test und TearDown Methode des TestCase ausgef hrt gt Falls das Element eine TestSuite ist werden in run die Run Methoden der darunterliegenden Elemente aufgerufen Die oben aufgef hrten Schritte und die Registrierung der Suite werden ber Macro Aufrufe des Frameworks durchgef hrt SWE Prof Dr W Weber h_da Fachbe
33. auf einer abstrakten Ebene m Verfeinere die SW Architektur gt Verteile die Komponenten welche durch die Architektur festlegt sind f r die Ausarbeitung der Details an interne Teams oder auch an Externe gt die Beziehungen zwischen den Komponenten legt die Architektur fest Die Erf llbarkeit der wesentlichen Anforderungen wurde mit der Architektur analysiert und getestet SWE Prof Dr W Weber h_da Fachbereich Informatik 153 e i 6 Design Die Aufgabe des Designs m Die SW Architektur gt gibt eine Zerlegung in Arbeitspakete mit Verantwortlichkeiten vor gt macht Vorgaben fur das weitere Vorgehen und die Umsetzung z B Installation Prozesse Verteilung auf Rechner usw gt Es fehlen noch s mtliche detaillierte Beschreibungen mit Methoden Parametern konkreten Abl ufen m Im Design gt werden Details ausgearbeitet Klassen mit Methoden und Datentypen Abl ufe Betriebssystemanbindung Threads Scheduler Timer gt entstehen Klassendiagramme Sequenzdiagramme Zustandsdiagramme usw gt erfolgt die Umsetzung auf Programmiersprache n Betriebssystem e Hardware gt RSITY OF APPLIED SCIENCES 1 54 Il il I 6 Design Gutes Design m Im Design gt gibt es viele L sungen gt sind viele L sungen ungeeignet einige sind geeignet gt je konkreter die Randbedingungen vorgegeben sind desto weniger gute L sungen gibt es bis hin zu berhaupt keiner Frage Welche
34. aus einer quivalenzklasse genauso wie bei allen anderen Werten dieser quivalenzklasse d h l uft das Testobjekt mit dem Repr sentanten der quivalenzklasse fehlerfrei dann l uft es auch mit allen anderen Werten dieser quivalenzklasse fehlerfrei gt Beim quivalenzklassentest testet man das System mit jeweils einem Repr sentanten pro quivalenzklasse gt Es gibt g ltige quivalenzklassen mit g ltigen Eingabewerten und ung ltige quivalenzklassen mit ung ltigen Eingabewerten SWE Prof Dr W Weber h_da Fachbereich Informatik 260 Spezifikation 8 1 1 Black Box Test Aquivalenzklassen Beispiel Dreieck I a m Spezifikation der Funktion Dreieck m DREIECKTYP dreieck SEITE1 int SEITE2 int SEITES int mit R ckgabewert enum DREIECKTYP NORMAL GLEICHSCHENKLIG GLEICHSEITIG KEIN_DREIECK m Zweck gt SEITE1 SEITE2 und SEITES sind die Seitenl ngen eines Dreiecks gt Die Seitenl ngen seien positive Werte gt Die Funktion stellt fest ob es sich um ein einfaches normales ein gleichschenkliges ein gleichseitiges oder um gar kein Dreieck handelt gt Zul ssige Eingabewerte seien die positiven ganzen Zahlen SWE Prof Dr W Weber h_da Fachbereich Informatik 261 8 1 1 Black Box Test Spezifikation Aquivalenzklassen Beispiel Dreieck Il a gt KEIN DREIECK wenn 2 Seiten zusammen k rzer sind als die 3 Seite SEITE1 SEITE2 lt SEITE3
35. bo Erklarung der Elemente Teilnehmerverwaltung bietet einen Port mit den Schnittstellen Sortierter Zugriff und Wahlfreier Zugriff an und ben tigt die Schnittstelle Speichermedium Speichermedium wird bereit gestellt durch Komponente Datenbankmanagementsystem Datenbankmanagementsystem besteht aus 2 Komponeneten Listengenerator ben tigt die Schnittstelle Sortierter Zugriff Paginierer und Satzprogramm sind Unterkomponenten von Listengenerator die von Listengenerator ben tigt werden Die Komponenete Listengenerator wird durch Lister v2 0 ear realisiert Frage Was k nnten bei Cocktail Pro Komponenten sein SWE Prof Dr W Weber h_da Fachbereich Informatik 134 5 2 Darstellung der Architektur a Prozess Sicht Thread Level Concurrency und Resourcen View a m Richtet sich auf das Management von Resourcen und die Nebenl ufigkeitsaspekte der Systemausf hrung m Die Sicht beschreibt die Synchronisation von Threads und die gemeinsame Nutzung von Resourcen m Dies ist insbesondere f r Embedded Systeme und Systeme zur Prozesssteuerung eine der wichtigsten Sichten SWE Prof Dr W Weber h_da Fachbereich Informatik 135 Fs Be 5 2 Darstellung der Architektur Prozess Sicht Thread Level in aniehnung an Douglasso6y Concurrency and Resource View Darstellung von Beziehungen zwischen Buitis Tesi Thread Threads uilt in Test rea lt lt Task gt gt 1 Separation Distance Monitor Thread
36. das des Projektes Management durch die hohe Parallelit t des m Unterst tzt die Planung und Steuerung von Entwicklungsprozesses Projekten durch Standardisierung m Die Anforderungen werden relativ fr h F r jeden Teil Prozess festgelegt Welche Arbeiten welche Arbeitsergebnisse wer verantwortlich m Anpassbar an projektspezifische Anforderungen Tailoring Gute Anbindung zur UML Gut dokumentiertes Modell J ses SWE Prof Dr W Weber h_da Fachbereich Informatik En Rest von RUP nur zur Info nicht prufungsrelevant ET aaa SWE Prof Dr W Weber h_da Fachbereich Informatik 411 11 Vorgehens und Prozessmodelle Unterschied zwischen Rational Unified Process RUP und Unified Process UP UP wurde 1999 von Jacobson ver ffentlicht W RUP ist eine konkrete Implementierung des UP durch die Firma Rational nach 1999 RUP wird von Rational inzwischen aufgekauft von IBM als Produkt vertrieben Rational bietet f r RUP eine Reihe von darauf abgestimmte Formularen und Werkzeugen an UP teilt Projekte in folgende Disziplinen Arbeitsschritte ein gt Anforderungen gt Analyse gt Entwurf gt Implementierung gt Test Wir sehen es fehlen gegen ber dem RUP gt Gesch ftsmodellierung gt Auslieferung Konfigurations und Anderungsmanagement siehe Kap 9 gt Projektmanagement mit Risiko Personal Budget und Vertragsmanagement gt Erstellung und Pflege der Infrastruktur Selbstvers
37. den Modul m im System S gt IF4 S Fl FO Ma zahl f r die Architektur des Systems S i 1 en SWE Prof Dr W Weber h_da Fachbereich Informatik 368 e 10 Metriken Beispiel fur die Informations fluss Analyse Pa A B C D seien Funktionen und C ruft A auf mit Aufruf Parametern y z und R ck gabeparameter_x Oder A B C D seien Klassen und z B eine Funktion der Klasse A ruft eine Funktion der Klasse C mit Aufrufparameter x auf und eine Funktion der Klasse C ruft eine Funktion der Klasse A mit Aufrufparametern y z auf m Beispiel SWE Prof Dr W Weber h_da Fachbereich Informatik 369 10 Metriken Relevanz der Mafe fur den Informationsfluss m Empirische Studien haben gezeigt gt Es besteht eine starke Abh ngigkeit zwischen Informationsfluss Ma en und dem Wartungsaufwand gt Beim Altern der Software entartet sehr oft die Struktur gt IF4 und die verschiedenen IF4i k nnen aufzeigen ob und wo ein Re Engineering notwendig bzw sinnvoll w re m F4 kann benutzt werden um Architekturen miteinander zu vergleichen gt Deutlich geringeres IF4 gt weniger starke Kopplung unter den Komponenten gt Ein Blob mit Daten au erhalb des Blobs zeigt ein sehr hohes IF4 m Welches ist die optimale Gr e von Moduln gt Zu diesem Zweck k nnen kombinierte Ma e wie LOCi IF4i oder McCabei IF4i benutzt werden um ausgeartete Module
38. den gemessenen Werten ziehen durch Verkn pfung und Gewichtung STMT Analysierbarkeit VG AVGS COMF FAN_IN FAN OUT LEVL Wartbarkeit nderbarkeit PARAval NBCALLING Stabilitat COND STRUCT Testbarkeit Teil des Qualitatsmodells des Testtools Logiscope der Fa Verilog SWE Prof Dr W Weber h_da Fachbereich Informatik 373 Ve 10 1 Metriken und Tools Komplexe zusammengesetzte Qualit tsma e STMT Anzahl der Statements einer Komponente Je gr er die Anzahl der Statements in einem Programm um so schwerer ist es zu verstehen d h um so gr er ist der Aufwand zur Fehlersuche oder bei Anderungen in der Wartung zyklomatisches Ma nach McCabe AVGS durchschnittliche L nge der Statements Dieses Ma ist ein komplexes Ma und wird nach folgender Gleichung berechnet AVGS N1 N2 1 STMT 1 wobei N1 Gesamtanzahl der Operatoren Halstead N2 Gesamtanzahl der Operanden Je l nger eine Anweisung ist um so gr er ist der Aufwand sie zu verstehen COMF Kommentarfrequenz Verh ltnis von Kommentaren und Anweisungen FAN_IN Zahl der Datenfl sse die zu einem Modul f hren Je gr er diese Zahl f r einen Modul ist um so st rker wird der Modul durch seine Umgebung die rufenden Module beeinflusst FAN OUT Zahl der Datenfl sse die von einem Modul wegf hren Je gr er diese Zahl f r einen Modul ist um so gr er ist der Einfluss dieses Moduls auf seine Umgebung besonders genau berpr fen
39. der Reflexion daruber K nnen wir wiederkehrende Muster erkennen m Einmal erkannte Muster leiten unsere Wahrnehmung M C Escher Luft und Wasser 8 SWE Prof Dr W Weber h_da Fachbereich Informatik 19 D 6 3 Entwurfsmuster Ein Problem aus der IT Welt m Beispiel Absatzformatierung in einer Textverarbeitung gt es gibt verschiedene Strategien um Abs tze schnell oder sch n zu formatieren gt neue Strategien sollen leicht einbaubar sein am besten ohne nderung in der eigentlichen Textverarbeitung gt dann entsteht eine Klasse f r jede Strategie wenn aber z B die Rechtschreibkorrektur ebenfalls in D verschiedenen Verfahren existiert dann g be es f r alle Kombinationen von Formatierern und Korrekturen je eine Klasse z B TextV_FormatiererA_KorrekturA II HOCHSCHULE DARMSTAD Yet SWE Prof Dr W Weber h_da Fachbereich Informatik 193 TE i 6 3 Entwurfs muster Ein Problem aus der IT Welt 2 Versuch 2 Idee Die Textverarbeitung muss gar nicht wissen welche Formatierung oder Rechtschreibkorrektur gew nscht ist es reicht wenn die Aufrufweise bekannt ist gt Definiere eine einheitliche Schnittstelle f r die austauschbaren Algorithmen ein Interface mit einer Methode z B Formatiere oder Rechtsschreibkorrektur gt Jeder Algorithmus erbt diese Schnittstelle und implementiert sie gt Der gew nschte Algorithmus muss der
40. des Aktionsplans durchgef hrt werden gt Risiken in einem Projekt sind normal und unvermeidbar gt Als Entwickler sind Sie vor allem an der Risikoidentifikation und Risikoanalyse beteiligt gt Risikomanagement erlaubt den bewussten Umgang mit diesen Risiken und verhindert b se berraschungen gt Evtl auch Einsatz von Prototypen zur Risikobewertung SWE Prof Dr W Weber h_da Fachbereich Informatik 464 12 Technisches Management Ko nfig u ratio ns management I Quelle IEEE Standard Glossary of Software Engineering Terminology m A system is a collection of components Systemteile organized to accomplish a specific function or set of functions gt Hardware Komponenten gt Software Komponenten gt Firmware Komponenten gt m Die Konfiguration eines Systems beschreibt die Komponenten die jeweils in einer bestimmten Version vorliegen und mit einer wohl definierten Prozedur zu dem System zusammengesetzt werden k nnen m W hrend der Entwicklung eines Systems entstehen viele Konfigurationen gt Jedes Release entspricht mindestens einer Konfiguration gt Jedes Testszenario entspricht einer Konfiguration gt Jeder Zwischenstand in der Integration entspricht einer Konfiguration SWE Prof Dr W Weber h_da Fachbereich Informatik 465 ma SS 12 Technisches Management Konfigurationsmanagement II m Beim Konfigurationsmanagement geht es darum die vielen entstehenden Konfigurationen zu verwalten
41. eas Wy Modul Imple Test mentierung falle ET are pon SWE Prof Dr W Weber h_da Fachbereich Informatik _ 3 Anforderungsanalyse Lernziel Anforderungsanalyse m Sie sollen in diesem Kapitel verstehen gt Was in der Anforderungsanalyse gemacht wird gt Warum die Anforderungsanalyse so schwierig ist gt Woher die Kommunikationsprobleme in der Anforderungsanalyse kommen Welche Arten von Anforderungen es gibt gt Welche Dokumente zu einer Anforderungs Spezifikation geh ren SWE Prof Dr W Weber h_da Fachbereich Informatik 54 E 3 Anforderungsanalyse Typischer Beginn eines Projekts m Auftraggeber gt hat ein Problem und sucht eine L sung gt kennt sich oft nicht mit SW aus gt Formuliert evtl die Randbedingungen gt hat ein gewisses Budget gt Formuliert den Bedarf gt hat eine eigene Sprache gt hat eigene Prozesse m Auftragnehmer SW Firma 4 soll einen L sungskonzept erstellen hat ein bestimmtes Fachwissen in SW kennt die Randbedingungen nicht soll ein Angebot machen kennt sich mit der Anw dom ne nicht aus hat eine eigene Sprache hat eigene Prozesse cal Jj bu SWE Prof Dr W Weber h_da Fachbereich Informatik 55 E 3 Anforderungsanalyse Typischer Beginn eines Projekts Il m Ziele gt Abgestimmte Beschreibung des Lieferumfangs aber nur mit eingeschr nktem Aufwand angestrebter Detaillierungsgrad i
42. glichst mit Erfahrungen mit hnlichen Bauvorhaben gt die den Bau leiten und die Arbeiten koordinieren m Es werden diverse Pl ne erstellt die die Br cke bzgl verschiedener Aspekte zeigen gt Technische Zeichnungen zu Stahlkonstruktion gt Fundamentpl ne gt Statikpl ne mit Kraftevektoren gt Seilaufbaupl ne m Die Arbeiten m ssen in Arbeitspakete zerlegt werden gt Die Realisierung erfolgt sp ter durch mehrere spezialisierte Teams Jj E SWE Prof Dr W Weber h_da Fachbereich Informatik 93 ee SWE Prof Dr W Weber h_da Fachbereich Informatik m 5 Software Architektur Software Projekt Fahrerinformationssystem BLAUPUNKT ALTER WALL ger mr ig B RSENBR CKE K 43 1147 DJ 12km MO Quelle www blaupunkt com Umfang gt Bereitstellung neuer Funktionalit t Spracheingabe gt Neuentwicklung gro er Teile User Interface komplett Auslieferung von Zwischenst nden m Team ca 50 SW Entwickler Management Querschnitt m Dauer 2 3 Jahre m Budget ca 30 Mio Frage Wie gehe ich solch ein Projekt an 5 Software Architektur Situation im Projekt gt Es ist mehr oder weniger verstanden was der Auftraggeber will gt Es ist ein gro es Projekt gt Nun geht es an die Umsetzung in Software aber wie gehe ich in einem gro en Projekt vor Idee Erstelle eine grobe Skizze des Systems noch keine Details Implementierung Programmiersprac
43. gt es werden Festlegungen getroffen Systembestandteile Schnittstellen zu anderen Systemen Interne Schnittstellen zwischen Systemteilen Grundlegende Art der Umsetzung z B Schichtenarchitektur gt Ergebnis Das System wird in grundlegende Bestandteile Komponenten zerlegt die in Architekturdiagrammen z B Komponentendiagramm dargestellt werden Tests f r die grundlegenden Eigenschaften des Systems Qualit tseigenschaften gt Die Architektur beschreibt grob Wie das System aufgebaut ist SWE Prof Dr W Weber h_da Fachbereich Informatik 39 E 2 2 Grundlagen des Software Engineering Phasen der Softwareentwic klung Design Feinentwurf m Im Entwurf gt wird die IT L sung nahe am Zielsystem entworfen gt werden diverse Festlegungen getroffen welches Betriebssystem welche Programmiersprache welche Hardware Grundlegende Umsetzungsprinzipien Design Patterns Datenbanksystem notwendige Systemschnittstellen zu Fremdsystemen etc gt Ergebnis Das System bzw seine Komponenten wird in Klassen zerlegt die in Designdiagrammen z B Klassen Sequenzdiagramm dargestellt werden Testplane f r die einzelnen Module und zusammengebaute Bestandteile gt Das Design beschreibt Wie das System im Detail aufgebaut ist J Brenn SWE Prof Dr W Weber h_da Fachbereich Informatik 40 TEE ia 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklu
44. heren Zeitpunkten UNIVERSITY OF APPLIED SCIENCES All a SWE Prof Dr W Weber h_da Fachbereich Informatik I 11 Vorgehens und Prozessmodelle Das evolutionare Modell m Kernanforderungen des Auftraggebers ion wird f hren direkt zur Nullversion ausgeliefert m Konzentration auf lauff hige Teilprodukte m Stufenweise Entwicklung durch Modell Steuerung durch die Erfahrung der Benutzer m Vermeidung der Implementierung eines Produkts gleich in voller Breite m Neue Anforderungen gt neue Version den Prozess SWE Prof Dr W Weber h_da Fachbereich Informatik Analyse des Teilsystems zum nachsten Zyklus TS Definition des f Teilsystems Entwurf des Teilsystems y N i Implementierung und Test des 7 x Betrieb und Evaluation des m Integration von Piegeaktivitaten in Teilsystems Abnahme des Teilsystems Teilsystems 393 E 11 Vorgehens und Prozessmodelle Bewertung des evolutionaren Modells Vorteile Nachteile m Einsatzf hige Produkte fur den m Eventuell mangelnde Flexibilit t der Auftraggeber in kurzen Abst nden Nullversion zur Anpassung an m Integration der Erfahrungen der unvorhersehbare Evolutionspfade Anwender in die Entwicklung m Eventuell komplette nderung der m berschaubare Projektgr e Architektur in sp teren Versionen E Korrigierbare Ent
45. ist das systematische Zusammenspiel von Prozessbausteinen mit dem Ziel Risiken letztlich akzeptierbar zu machen 1 Risikoidentifikation Nicht alle Risiken sind unmittelbar bekannt Sie m ssen proaktiv gesucht und entdeckt werden Das Ergebnis ist ein Dokument das f r jedes Risiko neben seiner Beschreibung auch die Wahrscheinlichkeit seines Auftretens und den m glichen Verlust identifiziert 2 Risikoanalyse In der Risikoanalyse werden die erkannten Risiken nach wohldefinierten Kriterien analysiert und nach ihrer relativen Bedeutung f r das Projekt priorisiert Das Ergebnis der Risikoanalyse ist eine priorisierte Risikoliste 3 Risikoplanung Auf der Basis der priorisierten Risikoliste werden in einem Aktionsplan Szenarien entwickelt und die Alternativen zur Aufl sung von Risiken beschrieben Es werden Schwellwerte festgelegt wann der Aktionsplan zum Einsatz kommen soll Das Ergebnis der Risikoplanung ist ein Aktionsplan SWE Prof Dr W Weber h_da Fachbereich Informatik 463 12 Technisches Management Risikomanagement III mM Der Risikomanagement Prozess fortgesetzt 4 Risikoverfolgung Hierbei wird berpr ft ob w hrend des Projektverlaufs bestimmte Metriken die im Aktionsplan festgelegten Schwellwerte berschreiten und gegebenenfalls werden bestimmte Abl ufe des Aktionsplans ausgel st 5 Risikoaufl sung Die Risikoaufl sung ist die Reaktion auf einen Ausl ser wobei dann bestimmte Teile
46. k nnen bevor die Software l uft Manuelle Pr fverfahren zur Pr fung der fertigen Artifakte Reviews vgl OOAD Automatische Pr fverfahren zur Pr fung der fertigen Artifakte Automatische statische Codeanalyse zur berpr fung des Codes auf potenziell fehlerhafte Konstrukte z B in einer If Bedingung und auf Verst e gegen die Implementierungsrichtlinien e Konsistenz Checks ber dem UML Modell mit Hilfe des CASE Tools e Kompilierung des Codes zum Finden formaler Fehler z B Syntaxfehler e Codeanalyse mit Werkzeugen zur Bestimmung von Qualit ts Ma en vgl Kapitel Metriken Mathematisches Beweisen der Korrektheit von Programmen Formale Verifikation SWE Prof Dr W Weber h_da Fachbereich Informatik 351 m 9 Qualitatssicherung QS Ma nahmen bersicht konstruktiv QS Sicherung Produkt Qualit t dynamisch Test Kap 8 analytische QS man Pr fverf Review QS lt statisch automatische Pr fverf Ma nahmen math Beweisen N Sicherung Prozess Qualit t Kap 11 SWE Prof Dr W Weber h_da Fachbereich Informatik 352 9 Qualitatssicherung Statische Codeanalyse Beispiel einer analytischen statischen QS Ma nahme m Bei der autom statischen Codeanalyse eM SOSE untersucht ein Tool den Quellcode ne and gt es werden beliebte Fehlerquellen const double three entdeckt und angezeigt double x y Z Array berschreitungen x 1 three Zuweisung statt
47. or SEITE1 SEITE3 lt SEITE2 or Frage Wie sehen die SEITE2 SEITE3 lt SEITE1 sonst Aquivalenzklassen gt GLEICHSEITIG wenn 3 Seiten gleich und Testf lle aus SEITE1 SEITE2 SEITE3 sonst gt GLEICHSCHENKLIG wenn Dreieck bei dem 2 Seiten gleich 3 verschieden SEITE1 SEITE2 and SEITE1 SEITES or SEITE1 SEITE3 and SEITE1 SEITE2 or SEITE2 SEITE3 and SEITE2 SEITE1 sonst gt EINFACH wenn Dreieck bei dem alle Seiten verschieden SEITE1 SEITE2 and SEITE1 SEITE3 and SEITE2 SEITE3 Frage k nnen wir nicht einfach sagen Gem mathematischer Definition m Notwendigkeit einer formalen Spezifikation gt Gem der Mathematik beinhalten gleichschenklige Dreiecke gleichseitige Dreiecke gt Die obige Spezifikation von GLEICHSCHENKLIG definiert abweichend von der mathematische Definition Bei GLEICHSCHENKLIG m ssen zwei Seiten ungleich sein also disjunkte Aufteilung der Menge der Dreiecke SWE Prof Dr W Weber h_da Fachbereich Informatik 262 e 8 1 1 Black Box Test Aquivalenzklassen Beispiel Dreieck III Spezifikation m Welche quivalenzklassen ergeben sich auf Grund der Spezifikation BE gt Aquivalenzklasse 1 gt Aquivalenzklasse 2 Zahlen fur die kein Dreieck konstruiert werden kann eine Seitenlange langer oder gleich der Summe der beiden anderen Seiten Soll Ergebnis KEIN DREIECK Reprasentant 1 2 5 3 gleich
48. position string address 1 1 4 Die aufrufenden Objekte erfahren dass die Umsetzung Uber einen Stack erfolgt Die aufrufenden Objekte m ssen sogar Stackoperationen verwenden und die Funktionsweise eines Stacks verstehen m Eselsbr cke Geheimagenten Prinzip m Jeder verr t nur das was ein anderer wissen muss um mit ihm zu arbeiten gt Jeder wei nur das was er wissen muss um seinen Job zu machen il a SWE Prof Dr W Weber h_da Fachbereich Informatik 164 6 1 Grundprinzipien fur das Design Grundprinzip 3 Geheimnisprinzip Information Hiding m Kapsele das interne Wissen eines Systemteils und verrate es niemand anderem gt Abl ufe Daten und Strukturen sind gekapselt gt Systemteile sind benutzbar ohne Kenntnis der Realisierung Nur Schnittstelle ist bekannt nicht die Implementierung interne nderungen sind von au en nicht sichtbar m Umsetzung in C gt Sichtbarkeit private f r alle Attribute und interne Methoden m Vorteile des Geheimnisprinzips gt unterst tzt Trennung von Zust ndigkeiten und Minimierung der Abh ngigkeiten gt erleichtert verteilte Entwicklung u All SER SWE Prof Dr W Weber h_da Fachbereich Informatik 165 E 6 1 Grundprinzipien fur das Design Idee fur das 4 Grundprinzip C C GPS Driver Navi System Navigation Die Komponenten des Systems haben star unterschiedliche Komplexitat _ Eme
49. system accepts an ordered set of lines each line is an ordered set of words and each word is an ordered set of characters Any line may be gt circulary shifted by repeatedly removing the first word and appending it at the end of the line The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order On the Criteria for Decomposing Systems into Modules David Parnas CACM 1972 m Anwendung z B Index im Unix Manual oder auch in Bibliotheken gt Suche nach Stichw rtern siehe auch Software Architecture Perspectives on an Emerging Discipline Mary Shaw and David Garlan Prentice Hall 1996 SWE Prof Dr W Weber h_da Fachbereich Informatik 101 E 5 1 Entwicklung einer SW Architektur Funktionalitat von KWIC m Eingabe gt Perspectives on Software Architecture Computers in Context m Zwischenergebnis zyklische Shifts Ausgabe sortiert Perspectives on Software Architecture Architecture Perspectives on Software on Software Architecture Perspectives Computers in Context Software Architecture Perspectives on Context Computers in Architecture Perspectives on Software in Context Computers Computers in Context on Software Architecture Perspectives in Context Computers Perspectives on Software Architecture Context Computers in Software Architecture Perspectives on Allg roms um SWE Prof Dr W Weber h_da Fachbereich Informatik 102 5 1 Architekturstile
50. ter durch Quicksort ersetzen W rden Sie dazu ein Strategiemuster verwenden SWE Prof Dr W Weber h_da Fachbereich Informatik 202 6 3 Entwurfs muster Noch ein Problem aus der IT Welt Observer Muster kennen Sie schon m Stellen Sie sich vor Sie sollen die Systemuhr f r ein modernes Betriebssystem implementieren gt Polling zyklische Abfrage soll vermieden werden gt Bereitstellung der neuesten Zeit und des neuesten Datums gt Unterst tzung f r eine im Voraus nicht bekannte Anzahl von Interessenten Word Tray Clock gt Die L sung soll m glichst bertragbar sein z B f r den Batteriestatus m Entwerfen Sie Komponenten mit Verantwortlichkeiten und Beziehungen gt Analysieren Sie folgende Szenarien 1 Die Uhrzeit ndert sich und soll ohne Polling angezeigt werden 2 Interessenten kommen w hrend der Laufzeit hinzu oder fallen weg 3 Analoge Aufgabe Ermitteln des Batteriestatus des Rechners SWE Prof Dr W Weber h_da Fachbereich Informatik 203 6 3 Entwurfsmuster 1 Die Uhrzeit ndert sich und soll ohne Polling angezeigt werden Systemuhr Datum gibStunde O aktualisiere m Idee Drehe den Spie um und sage Bescheid wenn sich die Zeit ndert gt Bei einer Zeit nderung ruft die Systemuhr beim UhrClient eine Methode auf gt UhrClient besorgt sich dann von der Systemuhr die erw nschten Daten gt Definiere dazu beim Client eine Metho
51. welcher Funktionen was sind Parameter gt Delta Gewicht zu dosierendes Sollgewicht gem Rezeptschritt Erh hungsgewicht f r welche Funktion und zus tzlich m Wo erfolgt das Instanziieren Setzen der Zust nde bergeben Annehmen der Parameter der zu testenden Funktion Pr fung der Ergebnisse gt Im Driver SWE Prof Dr W Weber h_da Fachbereich Informatik 304 E 85 Beispiel Modul Integrationstest Wie schreiben wir Tests m Wohin m Wie None SWE Prof Dr W Weber h_da Fachbereich Informatik 322 8 5 Beispiel Modul Integrationstest Wie schreiben wir Tests Wollen Sie es so realisieren Tests oder Testaufrufe in main Oder Erstellung der Test Funktionen in eigener Klasse z B WaageTest void main includes Test Driver void Waage_getdelta_gewichtTest Instanziieren der Klasseninstanzen Vorzustand setzen d h z B setze Attribut dieWaage deltaGew zu 4 Evtl Instanziieren von Pointern auf Klassenobjekte global und Kreieren von Objekten zu Pointern und Setzen von Attributen auch au erhalb in spezieller SetUp Fkt die vor jedem Test aufgerufen wird Waage dieWaage dieWaage SetDeltaGew 4 Aufruf von dieWaage getdelta_ gewicht und Testen des Ergebnisses auf Korrektheit per assert Statement oder Ausgabe der Ergebnisse anschlie end manueller Vergleich assert dieWaage getdelta_gewicht 4 oder if Allgemein Ergebnis kann sein Ruckgab
52. zwischen zusammengesetzten und einzelnen Objekten zu ignorieren d h Klient soll alle Objekte im Kompositum einheitlich behandeln k nnen SWE Prof Dr W Weber h_da Fachbereich Informatik 216 6 3 Entwurfsmuster Das Kompositum Muster Operation kindobjekte FuegeHinzu Komp Entferne Komp GibKindobjekt int Struktur einKompositum ana eis einBlatt Operation Operation FuegeHinzu Komp Entferne Komp einBlatt einBlatt einBlatt ee rekursive Struktur aus Komponenten Teilnehmer Komponente Schnittstellendeklarationen Implementierungen von Defaultverhalten Blatt Besitzt keine Kindobjekte definiert Verhalten f r die primitiven Objekte in der Komposition Kompositum Definiert Verhalten f r Objekte die Kindobjekte haben speichert Kindobjektkomponenten implementiert entsprechende Operationen der Schnittstelle von Komponenten Klient Manipuliert die Objekte in der Komposition durch Schnittstelle Operationen von Komponenten ra SWE Prof Dr W Weber h_da Fachbereich Informatik 217 UNIVERSITY OF APPLIED SCIENCES 6 3 Entwurfsmuster Das Kompositum Muster Interaktionen m Klienten verwenden Schnittstellen der Klasse Komponente um mit Objekten der Komponentenstruktur zu interagieren m Wenn Empf nger Blatt Direkte Abhandlung der Anfrage m Wenn Empf nger Kompositum gt Weiterleitung der Anfrage an Kindobjekte SWE Prof Dr W Weber h_da Fachber
53. 1 0 0 2 bei Testgeschwindigkeit von 10 Tests Sek m 26 1 8 1019 verschiedene Eingaben gt Ein Testdurchlauf 585 Jahre D ohne Herleitung Sollergebnisse und Vergleich mit den Sollergebnissen F r einen Multiplizierer f r 64 Bit Zahlen 10 8 Trilliarden Jahre gt Aber Durch Testen kann in der Regel nicht die Fehlerfreiheit der Software nachgewiesen werden gt Sondern Testen kann nur Zuverl ssigkeit verbessern He SWE Prof Dr W Weber h_da Fachbereich Informatik HOCHSCHULE DARMSTADT li HI UNIVERSITY OF APPLIED SCIENCES wa i i 252 HOCHSCHULE DARMSTADT INIVERSITY OF APPLIED SCIENCES 8 Test und Integration Auswahl von Testf llen m Wie finde ich geschickte Stichproben Testf lle so dass mit gro er Wahrscheinlichkeit viele Fehler entdecket werden gt Bilde Bereiche gleichen Verhaltens quivalenzklassen und f hre Test f r je einen Vertreter durch gt Fehler werden meist da gemacht wo sich etwas ndert gt teste an den Grenzen von quivalenzklassen von Schleifen in Bedingungen In der Mitte eines Bereichs gibt es kaum Fehler gt Erg nze durch Intuitive Testf lle Erfahrung SWE Prof Dr W Weber h_da Fachbereich Informatik 253 E 8 Test und Integration Kontrollfragen zum Test Wann ist ein Programm oder eine Funktion fehlerfrei Ist es normalerweise m glich alle Testf lle laufen zu lassen Was kann man tun um die Anzahl der Te
54. 3 Entwurfsmuster Beobachtermuster Beispielcode Digitaluhr Beobachter Struktur Beobachter meldeAn Beobachter EEE meldeAb Beobachter aktualisiere AN benachrichtige 1 Subjekt Zeitgeber beobachteterZustand subjektZustand peobachteterZustand gibStunde aktualisiere zeichne setzeZustand weitere m gl Beobachter z B Kalender Analoguhr SWE Prof Dr W Weber h_da Fachbereich Informatik 212 6 3 Entwurfs muster Beobachtermuster Beispielcode Digitaluhr class Subjekt public virtual Subjekt virtual void meldeAn Beobachter virtual void meldeAb Beobachter virtual void benachrichtige protected Subjekt private Liste lt Beobachter gt beobachter void Subjekt meldeAn Beobachter beobachter _beobachter gt haengeAn beobachter Methode von Liste void Subjekt meldeAb Beobachter beobachter _beobachter gt entferne beobachter void Subjekt benachrichtige Listenlterator lt Beobachter gt iter _beobachter for iter start iter istFertig iter weiter iter aktuellesElement gt aktualisiere this hda IVERSITY OF APPLIED SCIENCES en SWE Prof Dr W Weber h_da Fachbereich Informatik class ZeitGeber public Subjekt public ZeitGeber virtual int gibStunde virtual int gibMinute virtual int gibSekunde void tick z hlt um eine Sekunde hoch benachr
55. 9 ye Hochschule Darmstadt Fachbereich Informatik software Engineering 6 Fein Design h da san i ii HOCHSCHULE DARMSTADT an ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 150 6 Design Einordnung im V Modell A Testf lle eee j 2 twurf Testf le Integrations ign test Modul Imple Test mentierung falle SWE Prof Dr W Weber h_da Fachbereich Informatik 151 SSS 6 Design Lernziel Design Frage Was wissen Sie schon Uber das Design von Software Welche Modelle kennen Sie bereits zum Design von SW aus OOAD Welche Grundprinzipien Welche Regeln des Designs kennen Sie m Sie sollen in diesen Kapitel gt verstehen was im Design passiert weitere Techniken kennen lernen die einen guten Entwurf f rdern wiederholen welche Grundprinzipien beim Entwurf gelten wiederholen welche Regeln es zum Entwurf von Klassen und Assoziationen gibt verstehen warum man Design Patterns verwenden sollte verstehen was ein Anti Pattern ist verstehen warum ein Blob kein guter Entwurf ist tTigidgd SWE Prof Dr W Weber h_da Fachbereich Informatik 152 6 Design Vorgehen im Projekt m Situation im Projekt gt Ein relativ kleines Team von Systemanalytikern und Architekten hat t die Anforderungen bestimmt und eine Architektur entworfen E Nat gt Die Architektur beschreibt das System
56. APPLIED SCIENCES ee SWE Prof Dr W Weber h_da Fachbereich Informatik 179 yy 6 2 Regeln zum Entwurf von Klassen L sung B normalisiert Object Diagram Lied normalisiert Not That Kind Lied Not That Kind Album I m Outta Love Lied Anastacia Interpret Cowboys amp Kisses Lied Class Diagram Lied normalisiert Interpret Album name String _ titel String titel String ort String cover Bild lange Int Pink Floyd Wish You Were Shine On You Interpret Here Album raz Sant Lie Ist der Name des Interpreten oder das Album falsch geschrieben so muss dies nur im Objekt Interpret bzw Album korrigiert werden Weitere zu Album geh rende Daten wie z B das Album Cover sind nicht redundant vorhanden m I ee SWE Prof Dr W Weber h_da Fachbereich Informatik Billy I 180 EE 62 Regeln zum Entwurf von Klassen Aufgabe 3 m Modellieren Sie folgenden Sachverhalt aus einem Auftragssystem Kunden k nnen Bestellungen aufgeben gt Mehrere Bestellungen zusammen bilden einen Monats Auftrag gt Ein Monats Auftrag bezieht sich immer auf einen Kunden SWE Prof Dr W Weber h_da Fachbereich Informatik 181 6 2 Regeln zum Entwurf von Klassen Losung A Transitive Assoziationen Object Diagram Bestellung mit Zykel lt M ller Kunde Huber Kunde z J Class Diagram Bestellung mit Z
57. Analyse der Ergebnisse gt wertvolle Hinweise auf potenzielle Schwachstellen gt Anregungen zur Verbesserung des pers nlichen Entwicklungsstils m aber auch die Gefahren gt bertrieben gute Ergebnisse f r halbfertigen Code keine Fehlerbehandlung gt die Erfassung und Auswertung zu vieler Metriken verursacht viel Arbeit E Haben Sie jetzt besser verstanden was Design ist gt Geheimnisprinzip schwache Kopplung und starker Zusammenhalt gt Vererbung und Uberladung als praktische Techniken Verwendung von Klassen und Sichtbarkeit mE Haben Sie den Nutzen von Design Patterns jetzt besser verstanden Observer als praktisches Pattern gt Tipp Das einfache Singleton Pattern h tte einiges stark vereinfacht SWE Prof Dr W Weber h_da Fachbereich Informatik 473 Hochschule Darmstadt Fachbereich Informatik software Engineering 13 2 Gesamtergebnis h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 474 13 2 Gesamtergebnis Haufige Mangel in Software Projekten sind verme cba Ar ae a Avy WN w How the Project Leader How the Analyst designed it understood it How the customer explained it What the customer really needed How the project was What operations installed How the customer was billed How it was supported documented SWE Pro
58. Dr W Weber h_da Fachbereich informatik 1 Einleitung Konzept der Veranstaltungen OOAD und SWE m OOAD m Praktikum OOAD gt Objektorientierung gt Umgang mit dem Handwerkszeug gt Analyse und Design Erste Modellierung gt Dokumentation der Arbeit Entwickeln eines Mini Projekts UML Arbeit mit der UML Kennenlernen des CASE Tools Kennenlernen der Entw umgebung i Desi Gutes Design siehe Prakt Aufgabe letztes Semester m SWE m Praktikum SWE gt Gesamtkonzept Zusammenh nge Er gen Arbeit in gro en Projekten Anwendung der Verlanren aus Anwendung des Handwerkszeugs OOAD und SWE Qualit tssicherun gt Entwicklung eines Systems in kleinen ur Teams Organisation gt M glichst hohe Realit tsn he Eigenstandige L sung der Aufgaben berpr fung durch Reviews Aufteilung der Arbeiten im Team gt Handwerkszeug f r SW Entwickler SWE Prof Dr W Weber h_da Fachbereich Informatik E E Einleitung Literatur N Methodische objektorientierte Softwa re E ntwi ckl u n g i Methodische objektorientierte g Mario Winter Software 0993 dpunkt Verlag 2005 SAN Software Engineering un Jochen Ludewig Horst Lichter EEE s dpunkt Verlag 2006 Software Engineering lan Sommerville a Pearson Studium An ENGINEERING 9 Auflage 2010 MR Software entwicklung von on bj Softwareentwicklung von Kopf bis Fu Dan Pilone Russ Miles O Reill
59. E Prof Dr W Weber h_da Fachbereich Informatik 276 a 8 1 2 White B ox Test White Box Test m Alternative Begriffe Glas Box Test Strukturtest gt Man schaut in den Kasten hinein gt Die innere Struktur das Wie des Programms wird zur berpr fung hinzugezogen m Zus tzliche Testf lle werden aus der inneren Struktur abgeleitet Es wird je nach Testziel gepr ft gt ob alle Anweisungen Zweige Pfade des Programms durchlaufen werden bzw ob alle Teilausdr cke von zusammengesetzten Bedingungen mindestens einmal true und einmal false sind easier SWE Prof Dr W Weber h_da Fachbereich Informatik 277 7 8 1 2 White Box Test Codebeispiel ergebnis int fak x ee ergebnis 1 gt 0 ergebnis 1 for i 2 i lt X i ergebnis ergebnis i else return ergebnis RETURN Frage Was ist vollst ndige Kontrollflussgraph gerichteter Programmgraph Anweisungstberdeckung der Berechnung der Fakultat SWE Prof Dr W Weber h_da Fachbereich Informatik 278 E 8 1 2 White Box Test Testziele I ergebnis 1 m Vollst ndige Anweisungs berdeckung gt Jede Anweisung des zu testenden Programms wird mindestens einmal ausgef hrt gt Bedeutung Wichtig f r Laufzeitfehler z B SpeicherUbergriffe uninitialisierte Variablen etc ELSE Frage Wie viele Testf lle Was gebe ich als Parameter ein RETUR
60. E Zuverlassigkeit SW Effizienz Performance Benutzbarkeit Robustheit Testbarkeit Wiederverwendbarkeit GZ Jj a SWE Prof Dr W Weber h_da Fachbereich Informatik fi UNIVERSITY OF APPLIED SCIENCES 360 10 Metriken Metriken die Grundidee E Leite elementare Eigenschaften aus den Arbeitsergebnissen ab gt z B f r Code Codegr e Anzahl der Zeichen Zeilen etc Anteil an Kommentaren Anzahl an komplexen Konstrukten IF WHILE Anzahl von Vererbungen gt z B f r die Architektur Anzahl der Abh ngigkeiten zwischen Klassen Gr e der Dokumentation E Durch K mbinaton von elementaren Eigenschaften k nnen Aussagen ber SW Qualit tseigenschaften abgeleitet werden z B gt Verst ndlichkeit gt Wartbarkeit All sa a SWE Prof Dr W Weber h_da Fachbereich Informatik 361 LA 10 Metriken Metriken Einfache Ans tze m Wie messe ich die Gr e eines Programms einer Funktion Anzahl Zeilen LOC Durch viele Anweisungen in einer Zeile wird ein Programm nicht kleiner einfacher Durch Leerzeilen oder bertriebene Aufteilung aber auch nicht gr er gt Anzahl Anweisungen Durch Zusammenfassung von Einzelanweisungen zu komplizierten Anweisungen wird ein Programm nicht kleiner gt Anzahl Bytes Durch Sparen von Bytes z B kurze Variablennamen wird ein Programm auch nicht kleiner il a SWE Prof Dr W Weber h_da Fachbereich Informatik 362
61. ED 2 1 1 Modelle zur Bewertung von Software Entwickungsprozessen Rational Unified Process RUP ordered as workflow is dependant on 1 responsible Meta model of the V Model XT ordered as workflow is dependant on hda nq fl HOCHSCHULE DARMSTADT j i UNIVERSITY OF APPLIED SCIENCES e 458 11 1 Modelle zur Bewertung von Software Entwickungsprozessen Impliziert die Verwendung des RUP eine gute Bewertung in SPICE oder CMMI m Wir haben hier die gleichen Argumente wie beim V Modell XT Durch die Verwendung des RUP ist eine gute Basis gelegt f r eine gute Bewertung in SPICE oder CMMI aber erst nach dem Appraisal Prozess kann entschieden werden welcher Level erreicht ist SWE Prof Dr W Weber h_da Fachbereich Informatik 459 Hochschule Darmstadt Fachbereich Informatik software Engineering 12 Technisches Management h da u i ii HOCHSCHULE DARMSTADT i ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK Quellenhinweis Einige Folien dieses Kapitels entstammen Prasentationen von Prof A del Pino SWE Prof Dr W Weber h_da Fachbereich Informatik 460 E 12 Technisches Management Anderungsmanagement Change Management m Anforderungen ndern sich im Lauf der Zeit gt neue Anforderungen kommen hinzu gt bestehende Anforderungen werden modifiziert gt Die Priorit ten bestehender Anforderungen ndern sich m Change Managemen
62. ER SWE Prof Dr W Weber h_da Fachbereich Informatik 377 Hochschule Darmstadt Fachbereich Informatik software Engineering 10 2 Umgang mit Metriken h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 378 10 2 Umgang mit Metriken Gefahren von Metriken m Metrik Teufelskreis 1 Das Projekt hat Terminverzug 2 Das Management will den Grund f r den Verzug verstehen und fordert detaillierte Metriken 3 Die Mitarbeiter sammeln Daten f r Metriken anstatt produktiv zu arbeiten 4 GOTO1 m Metrik Overkill gt ein von Metriken und Zahlen berzeugter Manager l sst zu viele Daten erfassen gt Die Mitarbeiter sammeln Daten f r Metriken anstatt produktiv zu arbeiten Dilbert Here s my time report in fifteen minute increments SWE Prof Dr W Weber h_da Fachbereich Intormatik 379 E 10 2 Umgang mit Metriken Umgang mit Metriken m Metriken ein normales und wichtiges Arbeitsmittel in modernen Projekten gt es sollten einige wenige angebrachte Metriken ausgew hlt und konsequent verfolgt werden gt Metriken liefern Hinweise auf potenzielle Problemstellen aber nicht jede Verletzung der Metrikvorgabe muss ein Problem sein Manchmal sind Dinge auch einfach kompliziert gt Mit modernen Tools k nnen Metriken schnell berechnet und die Ergebnisse ber sichtlich visualisiert werden Dies lie
63. Eingabe m glich Representanten 6 a 2 Grenzwerte 0 Ausgabegrenzwert M zus zu beachten gt Ist Ausgabewert im Typ des Ausgabewerts darstellbar lt Max Ausgabetyp gt Weitere ung ltige Aquivalenzklasse gt Ja quivalenzklassen bez glich maximal darstellbarer Zahlenwerten f r die Ausgabe Eingabe Max Ausgabetyp ist abh ngig vom Rechner m gt Falls Ausgabewert vom Typ Integer 1 Aquvalenzklassen g ltig int sqr MAX_INT int sqr MAX_INT ansonsten ist x gt MAX_INT ung ltig Eingabe integer int sqr MAX_INT 1 _ int sqr MAX_INT 1 Representanten 6 a int sqr 5 345 432 100 int sqr 5 345 432 100 2 Grenzwerte g ltig int sar 4 294 967 296 int sar 4 294 967 296 O Ausgabegrenzwert ung ltig int sqr 4 294 967 296 1 int sqr 4 294 967 296 1 x g integer ist nicht geordnet gt kein Grenzwert SWE Prof Dr W Weber h_da Fachbereich Informatik 268 8 1 1 Black Box Test Erganzung der Tests durch Intuitive Testfallermittlung Spezifikation a m Ein erfahrener Tester kennt die beliebten Fehler und Umsetzungsvarianten der Entwickler gt der Tester macht Annahmen ber die wahrscheinliche Umsetzung innerhalb der Black Box und erg nzt die Testf lle entsprechend gt Oft findet man dabei Spezialf lle die auch bei der Spezifikation bersehen wurden vgl IsPrime 1 gt Zum Finden von intuitive Tes
64. Hochschule Darmstadt Fachbereich Informatik software Engineering 1 Einleitung h da HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK Quellenhinweis Diese Folien entstanden in enger Kooperation mit Prof R Hahn Einige Folien stammen aus Pr sentationen von Prof G Raffius Prof B Humm und anderen Professoren des FBI SWE Prof Dr W Weber h_da Fachbereich Informatik E Eine Anekdote Spitzenleute werden auf ein teures Seminar geschickt Sie sollen lernen auch in ungewohnten Situationen L sungen zu erarbeiten Am zweiten Tag wird einer Gruppe von Managern die Aufgabe gestellt die H he einer Fahnenstange zu messen Sie beschaffen sich also eine Leiter und ein MaBband Die Leiter ist aber zu kurz also holen sie einen Tisch auf den sie die Leiter stellen Es reicht immer noch nicht Sie stellen einen Stuhl auf den Tisch aber immer wieder f llt der Aufbau um Alle reden durcheinander jeder hat andere Vorschl ge zur L sung des Problems Eine Frau kommt vorbei sieht sich das Treiben an Dann zieht sie die Fahnenstange aus dem Boden legt sie auf die Erde nimmt das MaBband misst die Stange schreibt das Ergebnis auf einen Zettel und dr ckt ihn einem der M nner in die Hand Kaum ist sie um die Ecke sagt einer Typisch Frau Wir ben tigen die H he der Stange und sie misst die L nge Deshalb lassen wir Weiber auch nicht in den Vorstand Was wird hier falsch gemacht
65. IENCES _Die spezielle Art der Kundenverwaltung wird an mehreren Stellen ber cksichtigt SWE Prof Dr W Weber h_da Fachbereich Informatik 168 E 6 1 Grundprinzipien f r das Design Grundprinzip 5 Redundanzfreiheit DRY Don t Repeat Yourself m Entwerfe das System so dass jedes St ck Know how in dem System nur an genau einer Stelle umgesetzt wird die eindeutig und zust ndig ist gt Damit ist nicht nur Code gemeint Es kann sich um alle Teile handeln in denen Know how steckt also auch um Teile des Entwurfs ein Datenbankschema oder auch die Dokumentation gt ziehe mehrfach verwendete Teil heraus und mache Sie f r Andere verf gbar gt finde eine eindeutige und sinnvolle Heimat f r das Know how gt vermeide Copy amp Paste Entwicklung m Vorteile der Redundanzfreiheit gt f rdert die Trennung der Zust ndigkeiten man muss sich entscheiden gt Korrekturen m ssen nur noch an einer Stelle erfolgen Ioe SWE Prof Dr W Weber h_da Fachbereich Informatik 169 lli HOCHSCHULE DARMSTADT e 6 1 Grundprinzipien fur das Design Zusammenfassung der Grundprinzipien m 5 Grundprinzipien gt Trennung von Zust ndigkeiten Koh sion Zusammenhalt Be Minimierung von Abh ngigkeiten schwache Kopplung K gt Geheimnisprinzip gt Homogenitat QO gt Redundanzfreiheit m Es gibt weitere Prinzipien bzw diverse Varianten dieser Prinzipien gt die Kernaussage bzw Zielrich
66. Informatik 105 5 1 Architekturstile KWIC Pipes amp Filters als Stil Input m re Pipe System IO Pipes and Filters Circular Shift Output Alphabetizer gt Verteilte Steuerung jeder Filter arbeitet sobald Daten an seiner Eingabe anliegen gt Die Daten existieren nur tempor r als I O zwischen den Filtern gt Die Filter sind voneinander unabh ngig sie kommunizieren nur ber die Pipes zwischen ihnen gt Datenfluss und Kontrollfluss fallen zusammen Frage Ist Compiler durch Pipes amp Filters realisiert SWE Prof Dr W Weber h_da Fachbereich Informatik 106 5 1 Architekturstile Architekturstil Pipes and Filters Beispiel Compiler ASCII Programmtext Lexikalische Analyse Scanner Token Strom Syntaxanalyse Parser Abstrakter Syntaxbaum Semantische Analyse Attributierter abstrakter Syntaxbaum Zwischencode Generierung Zwischencode Optimierung Optimierter Zwischencode Mips Intel Sparc Interpreter Programm a RE SWE Prof Dr W Weber h_da Fachbereich Informatik 107 E 5 1 Architekturstile Architekturstil 4 Schichten Layers Typischer Einsatz Mit Hilfe des Layers Stils lassen sich Anwendungen strukturieren die in Gruppen von Teilaufgaben zerlegbar sind und in denen diese Gruppen auf verschiedenen Abstraktionsebenen Treiber liegen ill en DA SWE Prof Dr W Weber h_da Fachbereich Informatik 108 I E 5 1 Architekturstile Zuor
67. Modultests besteht ob die integrierten Module die Integrationstests bestehen il a SWE Prof Dr W Weber h_da Fachbereich Informatik 330 E 8 6 Testwerkzeuge xUnit http cppunit sourceforge net projects cppunit m xUnit Familie von Open Source Frameworks f r das Testen JUnit f r Java CppUnit f r C NUnit f r Net uvm gt alle mit gleichem Funktionsprinzip und hnlicher Verwendungsweise mM xUnit erm glicht gt die verteilte und unabh ngige Entwicklung von funktionalen Tests gt die einfache Zusammenf hrung der verschiedenen Tests gt die automatische Durchf hrung der Tests gt die automatische Protokollierung und berpr fung der Ergebnisse gt Tests in der gleichen Programmier Sprache wie die Anwendung gt und viele anderer n tzliche Dinge nn SWE Prof Dr W Weber h_da Fachbereich Informatik 331 8 6 Testwerkzeuge Ein einfacher Test mit CppUnit I Prinzip Aufgabe m Wir wollen eine Klasse Complex zum Rechnen mit komplexen Zahlen in C entwickeln Complex gt mit den blichen mathematischen Operatoren Complex double r double i m Wir wollen eine Testklasse ComplexNumberTestCase bool operator entwickeln die die Klasse Complex mit CppUnit testet once A gt Die Testklasse enth lt nee nee Eine Testmethode runTest welche Methoden der zu testenden Klasse aufruft bezieht sich auf Die Methoden setUp und tearDown die vor bzw nach jeder Testmet
68. N Was ist Zwe Ig uberdecku Ng Kontrollflussgraph gerichteter Programmgraph der Berechnung der Fakultat SWE Prof Dr W Weber h_da Fachbereich Informatik 279 8 1 2 White Box Test Testziele Il m Vollst ndige Zweig berdeckung gt Jeder Zweig des Programms wird mindestens einmal durchlaufen ELSE gt Zweig Kante gt im gerichteten Programmgraphen gt Ein gerichteter Programmgraph ist ein Graph der jeden moglichen Kontrollfluss des Programms enthalt z B Programm Ablauf Plan PAP Aktivitatsdiagramm gt Ein If hat in dieser Darstellung immer einen Then und einen Else Zweig auch wenn dieser im Code nicht explizit angegeben wurde gt Frage Unterschied zu ee Die Zweig berdeckung testet zus tzlich leere Else Zweige Frage Wie viele Testf lle Was gebe ich als Parameter ein Was ist Pfad berdeckung RETURN Kontrollflussgraph gerichteter Programmgraph der Berechnung der Fakult t ee SWE Prof Dr W Weber h_da Fachbereich Informatik INIVERSITY OF APPLIED SCIENCES 280 8 1 2 White B ox Test Testziele Il m Vollst ndige Pfad berdeckung gt Jeder Pfad im Ablauf des Programms wird mindestens einmal durchlaufen gt Pfad Weg durch den Ausf hrungsbaum von seinem Anfang bis zu einem Ende Der Ausf hrungsbaum enth lt alle m glichen Abl ufe im Programm Schleifen werden mehrfach durchlaufen Beispiel Ein Programm mit einer Schleife die 1 bis 3 Mal
69. Prototypen zur fr hzeitigen Kl rung von Problemen gt Auswahl alternativer L sungsm glichkeiten gt Sicherstellung der Realisierbarkeit akzeptiert nein ndern und erweitern Prototypen Modell gt Vervollstandigen Korrigieren von Anforderungen m Einbeziehen von Anwendern in die Entwicklung Prototypen Phasen Modell m Schrittweise Weiterentwicklung des ersten Prototyps der fr hen Produktversionen add on Prototyp s u Al Sasse SWE Prof Dr W Weber h_da Fachbereich Informatik 397 11 Vorgehens und Prozessmodelle Prototypen m Verwendung von Prototypen nicht nur im Prototypen Modell sondern auch bei Verwendung anderer Vorgehensmodelle zur Pr fung der Machbarkeit Verbesserung von Anforderungsspezifikation und Entwurf Definition m Ein Prototyp ist ein Experimentiersystem mit dessen Hilfe Fragestellungen zu Eigenschaften des endg ltigen Produkts oder seiner Einsatzumgebung gekl rt werden 3 m Prototyping ist die systematische Anwendung von Prototypen m 3 Klassifikationskriterien 1 Was wird durch den Prototyp getestet 2 Wie ist der Prototyp aufgebaut 3 Inwieweit findet der Prototyp Verwendung bei der Implementierung des endg ltigen Systems SWE Prof Dr W Weber h_da Fachbereich Informatik 398 11 Vorgehens und Prozessmodelle 1 Was wird durch den Prototyp getestet I m Benutzer Prototyp Explorativer Prototyp gt dient als Kommunikation
70. SWE Prof Dr W Weber h_da Fachbereich Informatik 1 Einleitung Aussagen im Umfeld des Software Engineering Programmieren klappt doch auch so Wen interessieren schon Boxen und Linien Ihr werdet nicht f r bunte Folien mit K stchen bezahlt Prozesse haben noch nie ein Produkt geliefert gt Wozu brauchen Sie Software Engineering SWE Prof Dr W Weber h_da Fachbereich Informatik Ral mi Einleitung Szenario m Stellen Sie sich bitte folgendes vor gt Sie arbeiten in einem Software Projekt mit einem Entwicklungsaufwand von ca 15 Mio Euro 50 Personen ber 3 Jahre Geplanter Umsatz des Projekts sind ca 500 Mio Euro Sie m ssen nach der Auslieferung 10 Jahre Wartung bieten gt Die Zukunft Ihrer Firma Ihr Gehalt und Ihre Karriere h ngen am Erfolg des Projektes Welche Probleme k nnen dann auf Sie zukommen gt in der Entwicklung SWE Prof Dr W Weber h_da Fachbereich Informatik 1 Einleitung Grunde fur den Einsatz von Software Engineering Komplexitat Funktion Qualit t Wartung Planung Organisation Methodik Strukturierung Verbergen von Details Erfassen der W nsche von Kunde und eigener Firma Sicherheit Regressanspruch Zug nglichkeit Gew hrleistung Dokumentation Umfang Personal Kosten Termine Qualit t Reporting Teamgr e Standortverteilung unterschiedliche Sprache Arbeitstechniken Prozesse Standa
71. Sie unter http www microtool de instep de scrum asp SWE Prof Dr W Weber h_da Fachbereich Informatik 431 Ei Die agile Vorgehensweise Scrum Rollen 83 Jr d Rollen Product Owner User Customer Management Nimmt Interessen der Stakeholder wahr legt Ziele der Entwicklung fest Stellt Finanzierung sicher Product Owner amp Cross functional Team Organisiert sich eigenstandig amp Sch tzt jeweils Aufw nde f r Entwicklung crumMaster an ScrumMaster amp Sorgt daf r dass Team produktiv arbeiten kann Ermittelt Verbesserungspotential im Prozess 3 3 Scrum Rollen Optimiert Arbeitsbedingungen Quelle http www microtool de instep de scrum asp SWE Prof Dr W Weber h_da Fachbereich Informatik 432 E O O Die agile Vorgehensweise Scrum Arbeitstechniken _ r Sprint Planning Meeting 8 Std Product Owner pr sentiert Product Backlogs mit h chster Priorit t Daily Scrum Meeting 24 Stunden Potenziell lieferf higes Verst ndnisfragen von SED ar daniel Teammitgliedern Product acklog 4 Wochen iInkremen i x Backlog s Sprint Team w hlt FUNKIONEN f r kommenden Sprint Team erzeugt Sprint Backlog Daily Scrum Meeting 15 Min T glich gleicher Ort u Zeit Alle Teammitglieder Nur einer redet Scrum Flow Quelle Aufgabenliste f r Sprint http www microtool de instep de scrum asp Jedes Teammitglied
72. Systems und wie sie zusammenpassen Darstellung z B durch das Komponenten diagramm der UML m Es gibt keine klare Unterscheidung zwischen Subsystemen und Komponenten m Wenn wir annehmen dass Subsysteme die gr ten Teile eines Systems sind dann sind Komponenten Teile von Subsystemen oder Komponenten m Ein Subsystem eine Komponente ist ein sehr gro es Teil des Systems das ber Komposition kleinere Teile des Systems enth lt die die Arbeit des Subsystems der Komponenete erledigen m Das Kriterium f r die Aufnahme in ein Subsystem Komponente ist ein gemeinsamer zu erf llender Zweck starke Koh sion m Ein Subsystem eine Komponente stellt gut definierte Interfaces zur Verf gung und delegiert die Dienste zu internen versteckten Teilen m Die konkrete Kommunikation zwischen instanziierten Komponenten beschreibt den Ablauf des Systems Darstellung z B durch Kommunikations oder Sequenz diagramme der UML SWE Prof Dr W Weber h_da Fachbereich Informatik 126 5 2 Darstellung der Architektur A aes a Subsystem Sicht in aniehnung an Dougiassos Logische Sicht Pass Darstellung der Subsysteme und der Beziehungen zwischen den Subsystemen K nnte auch mit UML Komponentendiagramm dargestellt werden 1 Air Traffic Control Primary Radar O Display Subsystem Radar_Subsystem AircraftSpace lt lt subsystem gt gt lt lt subsystem gt gt Subsystem lt lt subsystem gt gt O Controller Alarm_Subsystem Second
73. TOP Modul 1 Modul 2 Modul 3 Modul Modul 1 1 1 2 SWE Prof Dr W Weber h_da Fachbereich Informatik 302 8 3 Integrationstest Bottom Up Vorgehensweise m Zuerst Implementierung Montierung und Test der untersten Schicht gt die dar ber liegenden Module werden durch Driver simuliert gt sukzessives Ersetzen der dar ber liegenden Driver durch echte Funktionen Version 1 driver 1 driver Modul 1 u Modul 2 Modul 1 1 Modul 1 2 driver A Version 2 ea Modul 1 Modul 2 fe F a x P Modul 1 1 Modul 1 2 E no SWE Prof Dr W Weber h_da Fachbereich Informatik N 303 8 3 Integrationstest Vergleich Bottom Up Vorgehensweise lt gt Top Down Vorgehensweise m Bottom Up Vorgehensweise gt Vorteil Ergebnisse die auf oberster montierter Schicht zu sehen sind sind echt da das System darunter schon fertig ist Es kommen keine Stubs zur Anwendung gt Nachteil Der Benutzer sieht erst in den sp ten Phasen der Entwicklung etwas das dem Endergebnis entspricht Benutzschnittstelle ist normalerweise oben m Top Down Vorgehensweise gt Vorteil Der Benutzer sieht schon zu Beginn der Integration etwas gt Nachteil Die Ergebnisse auf oberster Schicht sind nicht echt Simulationen E Kombination von Bottom Up und Top Down ist m
74. Textverarbeitung bekannt sein Realisierung als Aggregation Pointer auf konkreten Formatierer interface Formatierer formatierer TextVerarbeitung lt gt Formatiere 0 NL Repariere verwendet Reparier epee pFormatiererobjekt gt Formatiere soll formatieren EinfacherFormatierer TeXFormatierer ArrayFormatierer Formatiere Formatiere Formatiere Frage Wie kann hier Rechtschreibkorrektur integriert werden SWE Prof Dr W Weber h_da Fachbereich Informatik 194 6 3 Entwurfs muster Das Strategie Muster Struktur strategie 7 KontextSchnittstelle Strategie AlgorithmusSchnittstelle gt ne KonkreteStrategieA KonkreteStrategieB KonkreteStrategieC AlgorithmusSchnittstelle AlgorithmusSchnittstelle AlgorithmusSchnittstelle E Teilnehmer und Interaktionen gt Kontext Wird mit einem KonkreteStrategieX Objekt konfiguriert verwaltet eine Referenz auf ein Objekt einer konkreten Strategieklasse und kann eine Schnittstelle f r den Zugriff auf seine Daten definieren gt Strategie Schnittstellendeklarationen f r alle unterst tzten Algorithmen gt Konkrete Strategie Implementiert einen Algorithmus unter Verwendung der Strategieschnittstelle SWE Prof Dr W Weber h_da Fachbereich Informatik 195 6 3 Entwurfsmuster Das Strategie Muster Strategy Pattern m Konsequenzen gt Strategien ersetzen Bedingungsanweisunge
75. Vergleich y 4 three Gefahr von Rundungsfehlern Lo 4 ENEE lt tiv if x y 2 gt z B Codecheck in Understand QA ne else cout lt lt 1 3 4 3 5 3 return 0 C von QA Systems oder PC lint for C C gt Nette bung bei PC lint suchen Sie den Fehler im Bug of the month http www gimpel com html bugs htm PC lint liefert gt Sie k nnen dort auch in der Interactive if x y 2 bug777 cpp 15 Demo Ihren eigenen Code untersuchen Testing floats for equality lassen PC lint weist auf ein wahrscheinlich unerwartetes Ergebnis des Vergleichs hin namlich false wegen Rundungsfehlern die bei float s auftreten SWE Prof Dr W Weber h_da Fachbereich Informatik 353 9 Qualitatssicherung Formale Verifikation Beispiel einer analytischen statischen QS Ma nahme m Es wird mathematisch bewiesen gt dass ein Programm zu zul ssigen Eingabewerten die richtigen Ergebnisse Ausgabewerte liefert d h richtig ist und gt dass der Algorithmus in jedem Fall terminiert m Vorgehen bei der formalen Verifikation gt Jede Funktionalit t eines Softwaresystems hat die Aufgabe aus bestimmten Anfangsbedingungen ber Daten precondition bestimmte Endbedingungen ber Daten postcondition herbeizuf hren gt Dies ist wie ein Vertrag zu sehen zwischen demjenigen der eine Funktionalit t benutzt und dem der sie erf llt m Die formale Verifik
76. Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien Methoden und Werkzeugen f r die arbeitsteilige ingenieurm ige Entwicklung und Anwendung von umfangreichen Software Systemen in Anlehnung an Balzert SWT Lehrbuch SWE Prof Dr W Weber h_da Fachbereich Informatik 15 2 Grundlagen des Software Engineering Was ist Software Engineering 2 Zeit m Die Kunst wie man Softwaresysteme PA N in der erforderlichen Qualit t zum COGIR A gt Qualit t gew nschten Termin mit gegebenen Das magische Dreieck Kosten erstellt gt d h Vermittlung von Modellen Methoden und Techniken f r die konstruktiven Phasen der Software Entwicklung Analyse Entwurf Implementierung die verwendet werden um die Arbeitsergebnisse dieser Phasen zu strukturieren Definition von Qualit t Qualit tseigenschaften Qualit tsmodelle zeitlichen Strukturierung in verschiedene Entwicklungsphasen Phasenmodelle berpr fung der Phasenergebnisse Test Verifikation Qualit tssicherung SWE Prof Dr W Weber h_da Fachbereich Informatik 16 lfi HOCHSCHULE DARMSTADT 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 1 m Inder Steinzeit der Software Entwicklung in den 50er und 60er Jahren gt Hardware war sehr teuer und wenig leistungsf hig m Wo waren Computer eingesetzt Welche T tigkeiten konnte man damals durch den Computer unterst tzen gt Softwar
77. achzust nde werden hergeleitet gt Beim Testlauf f r den Test eines Testfalls Durch eine Setup Funktion wird die Testumgebung erstellt z B Instanziierung von Klassen etc und die Vorzust nde z B Attributwerte von Klasseninstanzen globale Variablen Datenbankzust nde etc werden gesetzt Das Testwerkzeug ruft die Funktion mit vorgegebenen Eingabedaten auf und testet das Ergebnis auf Korrektheit Ergebnis muss manuell hergeleitet werden Evtl m ssen auch Nachzust nde auf Korrektheit gepr ft werden Nach Testlauf Das Testwerkzeug r umt auf Tear down Funktion d h durch new instanziierte Klassen m ssen destruiert werden etc SWE Prof Dr W Weber h_da Fachbereich Informatik 290 E 8 1 3 Testdurchf hrung Toolunterstutzung m Test Tools gt erleichtern die Erstellung von Testfallen und das Aufsetzen der Zust nde f r den Test z B JUnit C Unit gt verwalten Testfalle und automatisieren die Test Durchf hrung gt markieren nach der Durchf hrung einer Menge von Testf llen die durchlaufenen Anweisungen Zweige und Bedingungen man muss nur noch fehlende Tests erg nzen erleichtert schnelle Erkennung von schwer nicht testbaren Programmteilen gt Bei schlechter berdeckung berarbeitung des Codes zur Verbesserung der Testbarkeit Entfernen von unbenutztem Code Einbau von Zugriffsm glichkeiten zu Testzwecken Design for Testability il er SWE
78. ahme Integrations Definition Test Architektur Integration Komponenten Test Implementierung il eee SWE Prof Dr W Weber h_da Fachbereich Informatik 35 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Phasen bei der Softwareentwicklung m Im Praktikum Programmieren gt wurde immer eine Aufgabe gestellt d h die Definition war vorgegeben es wurde nie gefragt ob die Entwicklung sinnvoll ist gt Sie mussten sich nur wenig Gedanken ber den Aufbau des Systems machen es ging direkt los mit der Implementierung es war keine Planung erforderlich m Bei der Entwicklung gro er Systeme gibt es wichtige Phasen schon vor der Implementierung gt Analyse Einarbeitung in die fachlichen Gegebenheiten Soll ein System erstellt werden Ist eine Erstellung unter Kostengesichtspunkten ratsam und m glich gt Definition oft Teil der Analyse Phase Spezifikation des Funktionsumfang und Qualit t gemeinsam mit Benutzer Auftraggeber gt Architektur und Entwurf Strukturierung des Systems und Entwurf der IT L sung SWE Prof Dr W Weber h_da Fachbereich Informatik 36 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Analyse m Inder Analysephase gt wird erarbeitet und verstanden was die Software leisten soll gt Ein Systemanalytiker muss das Anwendungsgebiet verstehen den Ist Ablauf aufnehmen begreifen was der Kunde will die Schwachs
79. ahnstufen wie Ingenieur etc relevant werden SWE Prof Dr W Weber h_da Fachbereich Informatik 174 Lr UU 6 2 Regeln zum Entwurf von Klassen Losung A mit Generalisierung Spezialisierung Object Diagram Person mit Vererbung Class Diagramm Person mit Vererbung Redundanter Name und Adresse wenn Huber sowohl Kunde als auch Lieferant ist adresse String name String Huber Kunde Huber Lieferant Lieferant Mitarbeiter Bei der Bef rderung von Schmidt vom Arbeiter zum Manager muss das Arbeiter Objekt gel scht ein neues Manager Objekt angelegt und alle Attribute vom Arbeiter zum Manager Objekt kopiert werden Arbeiter Manager Schmidt Arbeiter Schmidt Manager Einf gen neuer Personen wie Gesellschafter etc oder weiterer Laufbahnstufen wie Ingenieur etc erfordern eine strukturelle Anderung des Modells ee SWE Prof Dr W Weber h_da Fachbereich Informatik 175 6 2 Regeln zum Entwurf von Klassen L sung B Mit Assoziation bzw Komposition Aggregation Dieselbe Person kann verschiedene Rollen haben Name und Adresse werden nur einmal gespeichert Kunde Rolle Class Diagram Person mit Assoziation Person Rolle adresse String typ enum Kunde Lieferant Mitarbeiter Arbeiter name String Mitarbeiter Manager Die Bef rderung vom Arbeiter zum Manager wird durch Anderung des At
80. alidierung a PIN falsch und lt 3 Fehlversuche Frage Wie viele Tests hatten wir wenn validiert ro VIPs teoto wir PIN unendlich oft eingeben kOnnen und nur durch Abbruch Aufforderung PIN Eingabe Kundenreaktion keine Eingabe f r 30 Sek raus kommen Kunde bricht ab Ingabe erfolgt Validi N En EIN E PIN falsch und PIN als richtig validiert gt 3 Fehlversuche System gibt Zugang frei Abbruch om SWE Prof Dr W Weber h_da Fachbereich Informatik 85 HOCHSCHULE DARMSTADT INIVERSITY OF APPLIED SCIENCES E 4 Abnahmetest Ableiten von Funktionstests IX Pfadtesten m Spezifikation der Aquivalenzklassen Soll Soll Zwischenergebnisse ausgaben Endergebnis ein Mal falsche PIN eingegeben beim 2 Versuch richtige PIN 1 Mal Aufforderung der erneuten PIN Eingabe Zugang frei zwei Mal falsche PIN eingegeben beim 3 Versuch richtige PIN 2 Mal Aufforderung der erneuten PIN Eingabe Zugang frei drei Mal falsche PIN eingegeben 2 Mal Aufforderung der erneuten PIN Eingabe Abbruch keine Eingabe f r 30 Sek satt 1 Pin Eingabe Abu Abbruch sat 1 PNE O OOO O o Abbruch statt 3 PIN Eingabe 2 Mal Aufforderung der erneuten PIN Eingabe Abbruch Frage Wie sieht der Testplan aus SWE Prof Dr W Weber h_da Fachbereich Informatik 86 gt 4 Abnahmetest Ableiten von Funktionstests X gt Schwierigkeit bei den obigen Verfahren Ich habe oft nicht das gesamte System al
81. als R ckbesinnung auf das eigentliche Ziel lauffahige Software gt Es stellt Menschen lauff hige Software Zusammenarbeit und Anderungsbereitschaft ber Prozesse Dokumentation Vertr ge und Pl ne Software Engineering Prof Dr R Hahn Prof Dr W Weber WS 2013 h_da Fachbereich Informatik 25 Ei Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 2 1 Grundlagen des Software Engineering Softwarequalit t h da u i iii HOCHSCHULE DARMSTADT EEH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 26 2 1 Grundlagen des Software Engineering Softwarequalitat Ziel des Software Engineering m Ziel gt Softwaresysteme in der erforderlichen Qualit t zum gew nschten Termin mit gegebenem Kosten erstellen m Welche Eigenschaften machen f r SIE die Qualit t einer Software aus gt aus Entwicklersicht gt aus Benutzersicht m Was ist Qualit t eine Qualit tseigenschaft Und welche Qualit t ist erforderlich Wie definiere ich das SWE Prof Dr W Weber h_da Fachbereich Informatik 07 2 1 Grundlagen des Software Engineering Softwarequalitat Softwarequalitats eigenschaften Funktionserf llung Benutzersicht NG Zuverlassigkeit Qualit tsmerkmale aus Benutzbarkeit Sicherheit Erweiterbarkeit Wartbarkeit Entwicklersicht bertragbarkeit Wiederverwendbarkeit Qua
82. als automatischer Schnittstelle zwischen den einzelnen Phasen des Software Lifecycles SWE Prof Dr W Weber h_da Fachbereich Informatik 23 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 7 7 Definition verschiedener konkurrierender objektorientierter Methoden ab 1990 gt Es entstanden parallel verschiedene objektorientierte Analyse und Entwurfsmethoden Booch Jacobson Rumbaugh Shlaer Mellor Coad Yourdon u a gt Die Methoden wurden in CASE Tools realisiert 8 Integration der OO Methoden zur UML Unified Modeling Language ab 1995 Jacobson Booch und Rumbaugh schlie en sich zusammen und entwickeln die UML Die UML soll die Schw chen der fr hen OO Methoden beseitigen und ein weltweit g ltiger einheitlicher Standard werden SWE Prof Dr W Weber h_da Fachbereich Informatik 24 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 8 9 Definition von machtigen Methoden zur Entwicklung von Systemen ab 1997 gt Es entstanden parallel verschiedene Vorgehensmodelle RUP Rational Unified Process seit 1998 Modell XT seit 2005 u a gt Die Methoden erfordern oft m chtige Tools 10 Agile Software Entwicklung seit 2000 gt Das Agile Manifest wird von Kent Beck und 16 weiteren anerkannten Gr en der Software Entwicklung unterschrieben und ver ffentlicht 2001 gt Gegenbewegung zu den schwergewichtigen Methoden
83. aor SWE Prof Dr W Weber h_da Fachbereich Informatik 131 T 5 2 Darstellung der Architektur bo Komponenten Sicht Komponentendiagramm gem r um Darstellungselemente m Port Kommunikationspunkt interaction point Z B zur Gruppierung mehrerer Schnittstellen die evtl nur gewissen anderen Komponenten zur Verf gung gestellt werden m In einer Komponenete k nnen auch die in ihr enthaltenen Klassen und deren Beziehungen untereinander dargestellt sein auch m glich in einem Kompositionsstrukturdiagramm S 191f in UML2glasklar oder Structured Class Douglass06 SWE Prof Dr W Weber h_da Fachbereich Informatik 132 E E 52 Darstellung der Architektur bog Komponenten Sicht Komponentendiagramm gem s um Darstellungselemente Satzprogramm component UML2 glasklar component Teilnehmerverwaltung Sortierter Zugriff Listengenerator Wahlfreier Zugriff manifest A artifact N Lister_v2 0 ear component Datenbankmanagementsystem subsystem component Ausgabesystem XML Schnittstelle manifest artifact N Oracle component Bi Hardwarezugriffsschicht Hardwarezugriff Hardwarezugriff Dateizugriff SWE Prof Dr W Weber h_da Fachbereich Informatik 133 5 2 Darstellung der Architektur Ee X Komponenten Sicht Komponentendiagramm gemas um Beispiel
84. ary Radar Antenna lt lt subsystem gt gt Subsystem lt lt subsystem gt gt AircraftCommunication i O Subsystem 1 NAS Interface Se Subsystem lt lt subsystem gt gt Scheduling Aircraft National Subsystem Airspace System lt lt subsystem gt gt hda 127 Flight Planning System 52 Darstellung der Architektur i ae T Komponenten Sicht in antehnung an Douglasso6 Logische Sicht bo Komponenten des Display Subsystems Protocol Stack lt lt use gt gt lt use gt gt Aircraft CL Database see a Ba Flight Scheduling DI Database lt lt use gt gt nn a a Display C_ Manager CS Icon Library S rg Jisplay Widget it am Pr 2 lt lt use gt gt Fi Math Library lt lt Uuse gt gt SWE Prof Dr W Weber h_da Fachbereich Informatik 128 5 2 Darstellung der Architektur F Komponenten Logische Sicht tin Anlehnung an Kruchtenos bo cod Autoradio component a Audio Manager Audio Requests component a Audio Source Control abstract component J component J component a component a Traffic Announcement Radio Cassette CD eE SWE Prof Dr W Weber h_da Fachbereich Informatik 129 5 2 Darstellung der Architektur Ee X Komponenten Sicht Komponentendiagramm gemas umu Beispiel 02 lt lt component gt gt a
85. ase Anforderungsermittlung ermittelten Domain Analyseklassen in Entit tsklassen berf hrt SWE Prof Dr W Weber h_da Fachbereich Informatik 113 5 1 Architekturstile Persistente Datenhaltung m Diese Schicht enth lt die persistent gespeicherten Daten m Entweder gt werden Instanzen von als persistent gekennzeichnete Klassen gespeichert OODBMS oder gt die Daten werden in z B relationalen DBMS abgelegt Mit Umsetzungsschicht die f r die Transformation der Klassensicht in relationale Sicht und umgekehrt zust ndig ist Z B Hibernate SWE Prof Dr W Weber h_da Fachbereich Informatik 114 E 5 1 Entwicklung einer SW Architektur Welchen Architekturstil wende ich f r meine Aufgabe an mM Der richtige Architekturstil gt ist abh ngig von der Anwendung Teilanwendung Hardware z B bei KWIC Passen Daten in Hauptspeicher es k nnen auch mehrere Stile kombiniert werden z B ereignisgesteuert objektorientiert und 4 Schichten gt ist abh ngig von den Anforderungen nderungsfreundlichkeit bez glich Datenstruktur Funktionalit t Performance Platz Laufzeit m Jeder Architekturstil hat Vorteile und Nachteile gt die resultierende Implementierung ist stark verschieden Al oe Software Engineering Prof Dr R Hahn Prof Dr W Weber WS 2013 h_da Fachbereich Informatik 115 ililla HOCHSCHULE DARMSTADT I 5 1 Entwicklung einer SW Architektur Vorgehen beim Gro
86. asenmodelle regeln auch die Zusammenarbeit zwischen den am Softwareerstellungsprozess Beteiligten Es existieren verschiedene Phasenmodelle f r die Softwareentwicklung SWE Prof Dr W Weber h_da Fachbereich Informatik 46 2 2 Grundlagen des Software Engineering Phasen der Softwareentwic klung Wasserfallmodell Anforderungs definition NN Imple mentierung Test u Abnahme NN Einf hrung Betrieb SWE Prof Dr W Weber h_da Fachbereich Informatik 47 E 2 2 Grundlagen des Software Engineering Phasen der Softwareentwic klung Wasserfallmodell gt V Modell urspr ngliche Version i A A d ee N nwendungsszenarien nn Abnahmetest LL Testf ll n estfalle Eau mend eStalle _ an 7 II en se SWE Prof Dr W Weber h_da Fachbereich Informatik 48 THLE 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Ergebnisse der Phasen m Als Ergebnis jeder Phase entstehen Dokumente I gt die als Grundlage f r das Weiterarbeiten dienen gt Fehler in fr hen Phasen verursachen sehr hohe Kosten in sp teren Phasen z B Auswirkungen von Fehlern oder missverstandlichen Formulierungen in der Spezifikation die erst zum Zeitpunkt der Abnahme festgestellt werden alle Phasen m ssen noch mal durchlaufen werden man muss sich in den Aufbau des Programms hineindenken und nderungen im Code vornehmen System ist neu zu testen Komponenten und Integrat
87. ation eines Systems verl uft nun folgenderma en gt Durch formales Anwenden von Regeln der mathematischen Pr dikatenlogik wird ber die Wirkungsweise des Algorithmus der Beweis gef hrt dass er aus seinen Anfangsbedingungen die Endbedingungen herstellt gt Gelingt dieser Beweis erf llt das System exakt die Spezifikation und ist korrekt SWE Prof Dr W Weber h_da Fachbereich Informatik 354 e 9 Qualitatssicherung Kontrollfragen Qualitatssicherung m Was ist der Unterschied zwischen Prozessqualitat und Produktqualit t m Angenommen Sie verwenden einen Standard zur Sicherung der Prozessqualit t z B ISO 9001 Entsteht dadurch eine gute Produktqualit t m Angenommen Sie unternehmen zur Sicherung der konstruktiven Produktqualit t erhebliche Anstrengungen Entsteht dadurch eine gute Produktqualit t m Angenommen Sie unternehmen zur Sicherung der analytischen Produktqualit t erhebliche Anstrengungen Entsteht dadurch eine gute Produktqualit t wall 355 Hochschule Darmstadt Fachbereich Informatik software Engineering 10 Metriken h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 356 E 10 Metriken Motivation I m Situation gt Projekt mit 100 Mitarbeitern Laufzeit 3 Jahre gt anschlie end 10 Jahre Wartung gt SIE sind Projektleiter m Woher wissen Sie als Projektleite
88. ation und Testf llen am SWE Prof Dr W Weber h_da Fachbereich Informatik 390 11 Vorgehens und Prozessmodelle Das Wasserfall Modell m Sequentieller Entwicklungsablauf m Top Down Vorgehen Durchf hrung jeder Aktivit t in der richtigen Reihenfolge und in vollem Umfang m Abgeschlossene Dokumentation am Ende jeder Aktivit t lterationen nur zwischen zwei al aufeinanderfolgenden Stufen lfi HOCHSCHULE DARMSTADT Analyse Definition i l i wahrend der Entwicklung SWE Prof Dr W Weber h_da Fachbereich Informatik nderungen 1 I oer i i FRA 1 SER 1 I 1 x N N Entwurf v gt gt nderungen Fehlerkorrektur w hrend der TS Implementier I h I ung Wartung und Test I j Abnahme Betrieb und P Evaluation 391 e B 11 Vorgehens und Prozessmodelle Bewertung des Wasserfall Modells Vorteile Nachteile m Extrem einfaches Modell m Strenge Sequentialitat oft nicht m Geringer Management Aufwand sinnvoll machbar m Disziplinierter kontrollierbarer und m M glichkeit von Feedback kaum sichtbarer Prozessablauf gegeben Erkennen von Problemen erst am Ende Benutzerbeteiligung nur bei Anforderungen und im Betrieb Gefahr einer zu starken Gewichtung der Dokumentation Lange Projektlaufzeit keine Zwischenversionen zu fr
89. bentwurf Finden der richtigen Architektur Idee Entwerfen und Analysieren gt Durch Entwerfen von Komponenten Beziehungen und Verantwortlichkeiten z B OOAD Komponentendiagramme gt iteratives Analysieren der Anforderungen mit Szenarien Welche nderungen werden erwartet Sind wahrscheinlich vgl OOAD Sequenzdiagramme Kommunikationsdiagramme auf Klasseninstanz Ebene gt Erleichterung durch Wieder Verwendung von bew hrten Mustern mit bekannten Eigenschaften Architektur Stile SWE Prof Dr W Weber h_da Fachbereich Informatik 116 Hochschule Darmstadt Fachbereich Informatik software Engineering 5 2 Darstellung der SW Architektur h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 117 E 5 2 Darstellung der Architektur Darstellung der Architektur Was macht ein Architekt Viele Plane ura nem out o sa h Mean un El mu i ae LEN ra DATEL se a ery one oo Woks i N bs Ries Elektro h CE IT Sanit r J Br SWE Prof Dr W Weber h_da Fachbereich Informatik 118 TEE ia 5 2 Darstellung der Architektur Sichten der Software Architektur m Beim Hausbau gibt es viele verschieden Pl ne Sichten gt Raumaufteilung Grund und Seitenriss gt Elektroinstallation und Datennetz gt Sanitare Installation ee
90. bereitung j Down void tearl delete m_10_1 delete m_1_1 delete m_11_2 hi Was muss jetzt noch hinzugef gt werden a ee SWE Prof Dr W Weber h_da Fachbereich Informatik iH I 335 E O 8 6 Testwerkzeuge C Unit setUp und tearDown und die einzelnen Tests in der TestFixture void testEquality CPPUNIT_ASSERT m_10_1 m_10_1 CPPUNIT_ASSERT m_10_1 m_11_2 void testAddition CPPUNIT_ASSERT m_10_1 m_1_1 m_11_2 Zu jeder der hier aufgef hrten 2 Testmethoden wird vom Framework ein TestCase mit einem runTestQ erstellt in dem jeweils setUp und tearDown vor und nach dem eigentlichen Test hier z B testEquality abl uft Al ee SWE Prof Dr W Weber h_da Fachbereich Informatik 336 alll S 86 Testwerkzeuge C Unit mit TestSuite berblick Test run TestResult abstract TestFixture setUp abstract tearDown abstract ComplexNumberTest testEquality testAddition setUp tearDown TestCase TestSuite run TestResult abstract run TestResult setUp abstract addTest Test tearDown abstract TestMain cpp Main Funktion zum Aufrufen der Tests durch das Framework konkrete durch das Framework aus den TexFixtures erstellte TestCases Complex double r double i bool operator Complex amp a Complex
91. bs nicht notwendig m aktualisiere von Dosierer Modultest mit Stubs und mit schon ausprogrammierten aufzurufenden Funktionen E aktiviere von Waage nur Test mit schon ausprogrammierten Funktionen SWE Prof Dr W Weber h_da Fachbereich Informatik 319 SESE 8 5 Beispiel Modul Integrationstest Beispiel Modultest Wird bei Ihnen gewKennz Gewichtskennzeichen so zur ckgegeben Aufrufhierarchie in Form dieWaage eines Strukturdiagramm A Be aktiviere f r das Beispie arate ER Observermuster der erhoehe_gewichte Fa gewKennz dieWage benachrichtige gewKennz dasDisplay aktualisiere derDosierer aktualisiere deltaGew 1 deltaGew gewKennz dieWaage dasDisplay getdelta_gewicht zeigeAn derDosierer vergleicheGewicht dieWaage getdelta_gewicht Woher kommt Delta Sollgewicht von Zutat Parameter Attribut Displayausgabe deltaGew Attribut von welcher Instanz Attribut deltaGew SWE Prof Dr W Weber h_da Fachbereich Informatik 390 8 5 Beispiel Modul Integrationstest Beispiel Modultest Beobachtermuster Observer Pattern m K nnen Sie eine Funktion einer Klasse einfach aufrufen gt Nein erst instanziieren initialisieren der Klasseninstanzen m Welche Zust nde m ssen Sie setzen zum Austesten
92. ch Pair Programming Weniger B rokratie mehr Spa fe Ph cee SWE Prof Dr W Weber h_da Fachbereich Informatik Nachteile m Auftraggeber und Team m ssen mitspielen sehr gute Vertrauensbasis zum Auftraggeber erforderlich m Erfordert hohe Prozessreife des Teams m Verzicht auf ein regul res Anforderungsmanagement erschwert Planung von Kosten und Terminen m Das Projektmanagement muss fr hzeitig kommunizieren und Entscheidungen f llen andernfalls k nnen gesch tzter und realer Aufwand auseinanderlaufen 435 11 Vorgehens und Prozessmodelle Kontrollfragen Vorgehensmodelle Wozu sind Vorgehensmodelle wichtig Was beinhaltet ein Vorgehensmodell Was ist ein iterativ inkrementelles Modell Welche Nachteile hat das Wasserfallmodell Welche Vorteile bietet das V Modell Welche Klassifikationen von Prototypen gibt es Was halten Sie von der Aussage In meinem letzten Projekt hat sich das Modell X bewahrt so mache ich das jetzt immer Ist der RUP ein agiles Vorgehens Modell Denken Sie an Iterationen Zyklusl ngen Zeitpunkt der Architekturentstehung Dokumentation Welches Vorgehensmodell haben wir im Praktikum eingesetzt SWE Prof Dr W Weber h_da Fachbereich Informatik 436 Folgendes Kapitel nicht prufungsrelevant Kap 11 1 al Sr SWE Prof Dr W Weber h_da Fachbereich Informatik i Hochschule Darmstadt Fachbereich Informatik software Engineering 11 1 Mode
93. chbereich Informatik 477 E 13 2 Gesamtergebnis Kontrollfragen zum Software Engineering m Wie stellen Sie in einem gro en Projekt sicher dass eine Person nicht alles wissen muss dass Qualit tsauflagen intern oder vom Auftraggeber erf llt werden dass die Wartungsverpflichtung ber cksichtigt wird dass Ihr Kunde auch das kriegt was er will dass Sie auch in Teams an verschiedenen Standorten arbeiten k nnen dass die Ergebnisse der Teams auch zusammen passen dass die Software stabil l uft dass die Entwickler nicht alles neu erfinden LEE EL 2 I Bie ee oan SWE Prof Dr W Weber h_da Fachbereich Informatik 478 ENDE SWE Prof Dr W Weber h_da Fachbereich Informatik 479 m Erg nzungsfolien HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES SWE Prof Dr W Weber h_da Fachbereich Informatik 480 Operationen der Schnittstellen Klasse zu Rezeptbuch class SKRezeptbuch public void SKRezeptbuch int GetAnzahlRezepte int GetAnzahlRezeptschritte int NrRezept string GetNameRezept int NrRezept string GetZutat int NrRezept int NrRezeptschritt float GetMenge int NrRezept int NrRezeptschritt SWE Prof Dr W Weber h_da Fachbereich Informatik 481 FE Operationen der Realisierungs Klasse in Komponente KRezeptbuch class KompRezeptbuch public SKRezeptbuch public void KompRezeptbuch Rezeptbuch dasRezeptbuch int GetAnzahlRezepte
94. cked out Item transient vor bergehend existierend SWE Prof Dr W Weber h_da Fachbereich Informatik 231 6 4 Anti Patterns The Blob die uberarbeitete Losung Library _Main_Control Current_Catalog Current_ItemFine_Amount Name Etc User_ID Items Out Fines Do_Inventory Search_Catalog Params Print Open_Library Issue_Library_Card Calculate_Late Fine Topic Inventory Print_Catalog U Sort_Catalog List_Catalogs ee Archive_Catalogs Cost Date _In Qty Checked out Item Check Out Item Due_Date Add Item Delete_Item Edit_Item Find_Item Check_In_Item He SWE Prof Dr W Weber h_da Fachbereich Informatik 232 6 4 Anti Patterns Fazit zu Anti Patterns m Der Blob gt ist ein beliebtes Entwurfsprinzip bei Anf ngern gt einfache Kommunikation einfache Zust ndigkeit einfache Realisierung gt erschwert aber Wartung Modifizierbarkeit Wiederverwendbarkeit etc gt kann leicht vermieden werden wenn man das Anti Pattern kennt m Regeln zum Umgang mit Anti Patterns nach Hays W McCormick gt Anti Patterns veranschaulichen h ufige Fehler und bieten bessere Ans tze gt Anti Patterns sind normale L sungen die den Stand der Entwicklung widerspiegeln Manche Anti Patterns muss man tolerieren SWE Prof Dr W Weber h_da Fachbereich Informatik 233 6 Zusammenfassung Design Kontrollfragen Design Was ist die Aufgabe des Designs Welche Grundprinzipien f r de
95. da Fachbereich Informatik 284 8 1 2 White B ox Test Testziele Ill m Vollst ndige Bedingungs berdeckung gt Jede Teilbedingung und Gesamtbedingung in einer Abfrage nimmt mindestens einmal den Wert true und mindestens einmal den Wert false an gt Beispiel IF Z A OR Z E OR Z I Testf lle A E X gt Bedeutung Fehler bei der Erstellung von Bedingungen werden erkannt Bemerkung F r eine Bedingungs berdeckung langt nicht dass jede Gesamtbedingung mindestens einmal den Wert true und mindestens einmal den Wert false annimmt Zweig berdeckung SWE Prof Dr W Weber h_da Fachbereich Informatik 285 8 1 2 White B ox Test Vergleich der Testprinzipien BIOMZ Ped s un uipag Ergebnisse f r vollst ndige Abdeckung Bunyospieqn S UNSIOMUY Bunyoap aqn Bunyospieqn Bunyospieqn schwierige Fehler in IF Bedingungen BREE IE Entdecken von fehlerhaften Teilbedingungen im IF Rand Fehler in komplexer Bedingung x gt 0 statt x 20 viele SWE Prof Dr W Weber h_da Fachbereich Informatik wird entdeckt wird nicht entdeckt wird tlw entdeckt 286 8 1 2 White B ox Test Kombination von Testprinzipien m H ufig treten in der Software Fehler auf weil eine If Abfrage an der Grenze zwischen den beiden F llen unsauber formuliert ist z B x gt 0 statt x20 Kombiniere die Zweig berdeckung mit der Grenzwertanalyse m d h teste nicht nur irgend ei
96. de aktualisiere gt kein Polling und dennoch immer die aktuelle Uhrzeit SWE Prof Dr W Weber h_da Fachbereich Informatik 204 6 3 Entwurfsmuster 2 Interessenten kommen wahrend der Laufzeit hinzu oder fallen weg LY Beobachter ee abstract aktualisiere gt 4 UhrClient meldeAn Beobachter Pack meldeAb Beobachter eye aktualisiere penachrichtige anzeigen m Idee Alle Interessenten UhrClients registrieren sich bei der Systemuhr gt Bei einer Zeit nderung ruft die Systemuhr in ihrer Methode benachrichtige bei allen registrierten Clients die Methode aktualisiere auf gt aber das geht nur wenn alle UhrClients zu einer Klasse geh ren gt Einf hrung einer abstrakten Oberklasse Beobachter und Verschiebung der Assoziation realisiert durch list of Beobachter Systemuhr Z Aue Dat lt atum qT N gibStunde setzeStunde SWE Prof Dr W Weber h_da Fachbereich Informatik 205 6 3 Entwurfsmuster 3 Analoge Aufgabe f r den Batteriestatus des Rechners Beobachter aktualisiere EN UhrClient aktualisiere m Idee Das Registrieren und Benachrichtigen ist ein allgemeines Verfahren unabh ngig von den bereitgestellten Daten gt Herausziehen dieses Teils durch Vererbung Subjekt gt Verschieben der Assoziation zum Benachrichtigen Zeit Beobachter eobachter SWE Prof Dr W Weber
97. dee f r das 2 Grundprinzip m Fur Funktionen Klassen Komponenten Schwache Kopplung Loose Coupling gt Kopplung ist ein Ma daf r wie sehr ein Element von anderen abh ngt gt z B Klasse A ist von B abh ngig wenn A hat ein Attribut vom Typ B oder verwendet eine Methode eines Objekts vom Typ B A hat eine Methode mit Parameter Return vom Typ B Aist von B abgeleitet oder A implementiert die Schnittstelle von B gt Das Prinzip der schwachen Kopplung fordert Klassen so zu definieren dass nur die n tige Kopplung da ist k j ee SWE Prof Dr W Weber h_da Fachbereich Informatik 162 6 1 Grundprinzipien fur das Design g Grundprinzip 2 Schwache Kopplung Loose Coupling Minimierung von Abh ngigkeiten m Minimiere die Abh ngigkeiten zwischen Systemteilen gt fasse stark zusammenh ngende Teile zusammen gt berpr fe die Verantwortlichkeiten auf eine saubere Trennung gt entkopple abh ngige Teile evtl durch Auslagerung in einen neuen Teil m Vorteile von minimierten Abh ngigkeiten gt Ver nderungen eines Systemteils tangieren nur wenige andere Klassen 163 UNIVERSITY OF APPLIED SCIENCES All SER SWE Prof Dr W Weber h_da Fachbereich Informatik 6 1 Grundprinzipien fur das Design Idee fur das 3 Grundprinzip Class Diagram CRM CustomerStack void push string name string address int getPositionInStack string name void modify int
98. dnung der 4 Schichtenarchitektur zu Klassen Stereotypen Stereotypname Symbol Schnittstellenklasse lt lt boundary gt gt Kontrollklasse lt lt control gt gt Entit tsklassen lt lt entity gt gt eee ne SWE Prof Dr W Weber h_da Fachbereich Informatik 109 I 5 1 Architekturstile Beispiel Aufruf von Funktionen in einer 4 Schichten S oftware Architektur Schicht 1 Externen Schnittstelle Schicht 2 Anwendungslogik Schicht 3 Anwendungsdaten Schicht 4 Persistente Datenobjekte Objekte mit Funktionen SWE Prof Dr W Weber h_da Fachbereich Informatik 110 5 1 Architekturstile Was sind Schnittstellenklassen I m Schnittstellenklassen sind zust ndig f r die Interaktion des System mit seiner Umgebung wie gt Benutzer gt anderen Systemen die das entwickelte System benutzen m Die Interaktionen beinhalten in der Regel die Auswahl und Aktivierung bestimmter Anwendungs Funktionen sowie gt die Ein und Ausgabe von Daten m Weitere Aufgaben gt Umsetzung der Interaktionen der Akteure in anwedungsinterne Ereignisse gt Pr fung von Eingabedaten gt Umsetzung von Eingabedaten in eine f r Akteure verwertbare Form gt Ausgabe von Daten m Wir k nnen aus Use Cases Schnittstellenklassen ableiten gt diese sind zust ndig f r die in dem Use Case spezifizierte Kommunikation mit dem Akteuren gt Klassenname Use Case Name mit angeh ngten AF Wi05 oder UC GeldAbhebenUC g
99. dschirme gt auch Installation Datenkonvertierung Start und Benutzerhandbuch Initialisierung gt Robustheitstests Pr fen der Reaktion bei gt auch Betriebsfunktionen wie Backup und Recovery unzul ssigen Eingaben gt auch Provozieren von Abst rzen um Lauffahigkeit gt evtl Volumentests z B maximale und Robustheit zu pr fen Datenmengen Datei defekt Plattenausfall Datenbank korrupt gt evil Stresstests z B maximale gt auch Ber cksichtigung von au ergew hnlichen Anforderung von Prozessorleistung Zust nden des Systems Datenbank etc gt auch Ber cksichtigung von Schnittstellen nach au en andere IT Systeme Peripherieger te wie Drucker etc Br Se SWE Prof Dr W Weber h_da Fachbereich Informatik 309 8 4 Systemtest Abnahmetest Leistungs Performance Test m Bedingungen gt Normale Last gt Messen von Antwortzeiten und Kapazit t m Selbstverst ndliche Forderungen gt Sofortige Antwort bei Tastendruck 1 2 Sekunden f r leichte Fragen gt Ein Bescheid wenn es l nger dauert gt Batch Jobs ber Nacht fertig SWE Prof Dr W Weber h_da Fachbereich Informatik 310 8 4 Systemtest Abnahmetest Volumentest m Ziele gt Maximale Datenmengen gt Mehr als Maximum gt Randomgenerierte oder alte Daten gt Versuchen Sie den ganzen Platz zu belegen m Beobachtungen gt Verliert das System Daten gt Verf lscht das System Daten gt Stoppt da
100. durchlaufen werden kann muss zumindest 3 Mal getestet werden so dass die Schleife beim 1 Testlauf 1 Mal beim 2 Testlauf 2 Mal und beim 3 Testlauf 3 Mal durchlaufen wird gt Bedeutung Sehr gr ndliche Tests aber schnell sehr gro e Menge an Testf llen Falls eine Schleife beliebig oft durchlaufen werden darf brauchten wir unendlich viele Testf lle Frage Bei Funktion fak n Wie viele Testf lle Was gebe ich ein SWE Prof Dr W Weber h_da Fachbereich Informatik 281 8 1 2 White Box Test Pfaduberdeckung ergebnis 1 l ELSE ENDOFFOR Testfall 1 x 1 a c j Testfall 2 x 0 a b d h k j Frage alle Pfade p fbar ENDOFFOR Kontrollflussgraph der Fakult ts Berechnung Testfall 3 x 2 Testfall 4 5 x 3 4 a b d e f g h k j a b d e f g h k j i 2 3 rat SWE Prof Dr W Weber h_da Fachbereich Informatik 282 DARMSTADT UNIVERSITY OF APPLIED SCIENCES E 8 1 2 White Box Test Pfaduberdeckung Ausfuhrungsbaum RETURN RETURN Testfall 1 6 X 1 a c j x 0 5 a b d e f g i h j RETURN RETURN SWE Prof Dr W Weber h_da Fachbereich Informatik 283 3 8 1 2 White Box Test Pfad berdeckung Frage Wie oft muss dieses Programm bei vollst ndiger Pfad berdeckung getestet werden A Mal SWE Prof Dr W Weber h_
101. e Klasse und nderungen an Reisender oder Reiseauftrag EN SWE Prof Dr W Weber h_da Fachbereich Informatik IVERSITY OF APPLIED SCIENCES 186 hda fi HOCHSCHULE DARMSTADT INIVERSITY OF APPLIED SCIENCES 6 2 Regeln zum Entwurf von Klassen L sung B m n Beziehungen aufgel st Class Diagram CRM mit 1 n Beziehungen Reisender Reisevoraussetzung Visum_ Status Reiseauftrag Object Diagram CRM mit 1 n Beziehungen HuberNachMallorca Reisevoraussetzung Visum keins Huber Reisender HuberNachlndien Reisevoraussetzung Visum OK MayerNachlndien Reisevoraussetzung Visum beantragt MayerNachRussland Reisevoraussetzung Visum OK Mayer Reisender Zu einem Reiseauftrag k nnen nun f r alle Mallorca Reiseauftrag Indien Reiseauftrag Russland Reiseauftrag Reisenden die Reisevoraussetzungen gespeichert werden Damit keine transitive Assoziation entsteht wird die Assoziation zwischen Reiseauftrag und Reisender jetzt ber die Reisevoraussetzung gef hrt SWE Prof Dr W Weber h_da Fachbereich Informatik 187 6 2 Regeln zum Entwurf von Klassen Regel 4 Analysiere m n Beziehungen genau m Hinter m n Beziehungen k nnen sich leicht Probleme verbergen gt Hinter m n Beziehungen stecken oft eigenst ndige Klassen vgl Assoziations Klassen oder auch Attribute die in der Analyse nicht aufgetaucht sind
102. e Dich auf das f r das System Notwendige gt Beispiel Sollen f r einen Reisekatalog die Ausstattungen von Hotels Pool Sauna Tennis etc modelliert werden so sind nur die Kategorien relevant Irrelevant ist hier dass Tennis eine Sportart ist ob Pool und Saunabereich aneinander grenzen etc SWE Prof Dr W Weber h_da Fachbereich Informatik 189 B 6 2 Regeln zum Entwurf von Klassen Zusammenfassung der Regeln m Regeln zum Entwurf von Klassen gt Setze Vererbung sparsam ein Normalisiere das Datenmodell Vermeide transitive Assoziationen Analysiere m n Beziehungen genau Vermeide 1 1 Beziehungen Modelliere nur fachliche nie technischen Aspekte 5 gt gt 5 gt Beschranke Dich auf das fur das System Notwendige il BETEN SWE Prof Dr W Weber h_da Fachbereich Informatik Ei Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 6 3 Entwurfsmuster h da sag H H HOCHSCHULE DARMSTADT a HHHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 191 6 3 Entwurfs muster Muster Patterns a SR ll Rp eee hacer Ae te PE SSSA eh AR RR IE SS Re RT eee EEE Gm m nn a aa m m nn m TI I en Sm I L Pe ee ee uus m Put n un nn m a PIERRE e nt Auf der Grundlage von Erfahrung und
103. e Parameter amp Parameter oder Zustande von Attributen globale Variablen Datei Datenbankfelder Nachzustand Zur cksetzen Attribute destruieren Klasseninstanzen evtl auch in spezieller tearDown Funktion die nach jedem Test aufgerufen wird z B durch new erzeugte Instanzen m ssen gel scht werden ee SWE Prof Dr W Weber h_da Fachbereich Informatik 323 35 Beispiel Modul Integrationstest Wie schreiben wir Tests void Dosierer_vergleicheGewichtT est deltaGewicht sollGewicht als Attribut in Dosierer void Dosierer_aktualisiereTest Instanziieren der Klasseninstanzen setze Attribut Aufruf von aktualisiere 1 mit getdelta_gewicht und vergleicheGewicht als Stubs bzw 2 mit getdelta_gewicht und vergleicheGewicht als schon fertige Funktionen Integrierte Funktionen Ausgabe Ergebnis Zur cksetzen Attribute void Dosierer_aktualisiereTest2 evtl nur mit Stubs oder mit anderen R ckgabewert f r gew_Kennz SWE Prof Dr W Weber h_da Fachbereich Informatik 324 E 8 5 Beispiel Modul Integrationstest Wie schreiben wir Tests eigentlicher Test Test 1 REN Waage_getdelta_gewichtTest Test 2 creas Dosierer_vergleicheGewichtTest Test3 eee Dosierer_aktualisiereTest Test 4 ae Dosierer_aktualisiereTest2 mit Stubs Test n SWE Prof Dr W Weber h_da Fachbereich Informatik 395
104. e Zahlen Soll Ergebnis GLEICHSEITIG Reprasentant 3 3 3 Alle folgenden Aquivalenzrelationen sind nicht KEIN_DREIECK mit folgenden zus Bed gt Aquivalenzklasse 3a gt Aquivalenzklasse 3b gt Aquivalenzklasse 3c gt Aquivalenzklasse 4 gt Aquivalenzklasse 5 SWE Prof Dr W Weber h_da Fachbereich Informatik 1 und 2 Zahl gleich 3 ungleich Soll Ergebnis GLEISCHENKLIG Reprasentant 3 3 4 1 und 3 Zahl gleich 2 ungleich Soll Ergebnis GLEISCHENKLIG Repr sentant 3 4 3 2 und 3 Zahl gleich 1 ungleich Soll Ergebnis GLEISCHENKLIG Repr sentant 4 3 3 alle Zahlen ungleich Soll Ergebniss EINFACH Repr sentant 4 2 3 fehlerhafte Eingabewerte Soll Ergebnis Typfehler falls Eingabe m gl Repr sentant 1 15 0 ung ltige quivalenzklasse 263 Spezifikation 8 1 1 Black Box Test Regeln fur Aquivalenzklassen po Folgende Regeln sollten beachtet werden m Falls Eingabetyp Wertebereich z B Tage 1 31 gt eine g ltige Aquivalenzklasse 1 lt Tage lt 31 gt zwei ung ltige quivalenzklassen Tage lt 1 Tage gt 31 m Ist anzunehmen dass Elemente einer Aquivalenzklasse unterschiedlich verarbeitet werden z B Gleichschenkliges Dreieck gt evtl Aufteilung in schmalere quivalenzklassen m Falls Eingabetyp Aufz hlungstyp Zahlungsart Scheck berweisung bar gt f r jeden Wert eine g ltige Aquivalenzklasse mit einem Repr sentant gt und eine ung l
105. e umfassende Dokumentation e Zusammenarbeit mit dem Kunden ber e Vertragsverhandlungen e Reaktion auf nderungen ber e Befolgung eines Plans Obwohl die rechten Punkte ihren Wert haben bewertet die agile SW Entw die linken h her SWE Prof Dr W Weber h_da Fachbereich Informatik 425 11 Vorgehens und Prozessmodelle Die agile SW Entwicklung die Grundidee m Der Kunde kennt die wirklichen Anforderungen zum Projektbeginn meist noch nicht komplett Er fordert Features die er nicht braucht und vergisst solche die ben tigt werden m Wie begegnet die agile Methode typische Gefahren f r Software Entwicklungsprojekte gt Unbenutzbarkeit aufgrund von Programmierfehlern L sung Viele und fr he Tests gt Unbenutzbarkeit aufgrund von Fehlentwicklung L sung Kunde mit in den Entwicklungsprozess einbeziehen gt Unwartbarkeit L sung Viele und fr he Tests gt Zeitplan nicht einhaltbar L sung Nur Implementieren was h chstes Nutzen Aufwand Verh ltnis hat gt Featuritis Vielleicht brauchen wir einmal dieses Feature L sung Lass es SWE Prof Dr W Weber h_da Fachbereich Informatik 426 11 Vorgehens und Prozessmodelle Die agile SW Entwicklung die Grundidee m verzichte auf einen strikten Anforderungskatalog gt Kundenw nsche die sich noch w hrend der SW Entwicklung ergeben werden einfach noch ber cksichtigt E implementiere nur die im aktuellen Iterationsschrit
106. e und Computer fast ausschlie lich im naturwissenschaftlichen Bereich gt Die eingesetzten Programme dienten haupts chlich der L sung mathematischer Probleme gt Die relativ kleinen Programme waren sehr preisg nstig oder wurde von den Anwendern selbst geschrieben SWE Prof Dr W Weber h_da Fachbereich Informatik 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 2 m Durch sinkende Hardwarepreise gt Computer wurden f r eine gr ere Zielgruppe erschwinglich m Es ver nderten sich die Anforderungen an die Software Software wurde f r die verschiedensten Bereiche gebraucht Der Umfang der Software wurde immer gr er Ihre Komplexit t war mit den bis zu diesem Zeitpunkt bekannten Vorgehensweisen f r das Programmieren im Kleinen nicht mehr zu beherrschen gt fehlerhafte und unzuverl ssige Programme gt nicht termingerechte Fertigstellung gt geplante Kosten wurden berschritten gt Dieser Zustand der Software Industrie wurde charakterisiert mit dem Begriff Softwarekrise SWE Prof Dr W Weber h_da Fachbereich Informatik 18 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 3 m Reaktion darauf gt strukturierte Programmiersprachen keine GOTOs gt Entwicklungsmethoden m Der Begriff Software Engineering wurde zuerst auf einer Software Engineering Konferenz der NATO 1968 in Garmisch gepr gt gt Diese Konferenz gilt al
107. edes Lied soll der Titel des Lieds Titell nge der Interpret der Wohnort des Interpreten der Name des Albums und das Bild des Album Covers gespeichert werden m Pr fen Sie wie die folgenden naheliegenden Punkte mit Ihrer L sung umgesetzt werden k nnen gt Wurde der Name des Interpreten oder des Albums falsch geschrieben so kann dies leicht korrigiert werden gt In der n chsten Version sollen zu einem Album weitere Daten gespeichert werden wie z B das Genre Klassik Rock SWE Prof Dr W Weber h_da Fachbereich Informatik 178 6 2 Regeln zum Entwurf von Klassen Losung A mit Redundanzen Class Diagram Lied interpret String intepret wohnort String album String album cover Bild titel String titel l nge Int Object Diagram Lied Not That Kind Lied interpret Anastacia album Not That Kind I m Outta Love Lied Cowboys amp Kisses Lied interpret Anastacia interpret Anastacia Shine On You Craz Diamond Lied interpret Pink Floyd album Wish You Were Here album Not That Kind album Not That Kind Ist der Name des Interpreten oder das Album falsch geschrieben so muss dies in allen Objekten vom Typ Lied korrigiert werden Inkonsistente Eintr ge k nnen leicht entstehen Weitere zu Album geh rende Daten wie z B das Album Cover sind in allen Liedern redundant vorhanden hda i UNIVERSITY OF
108. edictable 4 Vorhersagbar Established 3 Etabliert Managed 2 Gemanagt Performed 1 Durchgef hrt Incomplete 0 Unvollst ndig Process Prozess 1 2 3 4 5 6 n Dimension e g ACQ 1 ACQ 3 ENGI SUP 10 ACQ 2 ACQ 4 ENG 2 SWE Prof Dr W Weber h_da Fachbereich Informatik 443 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Capability Level 0 und 1 Wie sind die Capability Levels der Live Cycle Processe definiert Level 0 Incomplete unvollst ndiger Process m Der Prozess ist nicht implementiert Level 1 Performed durchgefuhrter Process ive cycle process m Level 1 ist erreicht wenn der implementierte Prozess den Zweck as Process Purpose des Prozesses erf llt Zur Bewertung wird gepr ft ob ns 1 1 m die Process outcomes erzielt werden die base practices implementiert sind m die input and output work products existieren process purpose SWE Prof Dr W Weber h_da Fachbereich Informatik AAA 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Beispiel ENG 1 aus ISO IEC 15504 5 Process ID ENG 1 Process name Requirements elicitation Process purpose The purpose of the requirements elicitation process is to gather process and track evolving customer needs and requirements Process outcomes As a result of successful implementation of requirements elicitation process 1 continuing communication with
109. ehen Testplan Keine EingabefersoSek n Abbruch Taste gear cktk Anbmehn Gilige PIN zu Kunden st 47it_ richtige PIN 4711 eingegeben Zugangmei PIN 1234 2436 7777 2 Mal Aufforderung der G ltige PIN zu Kunden ist 4711 eingegeben erneuten PIN Eingabe Abbruch SWE Prof Dr W Weber h_da Fachbereich Informatik 83 4 Abnahmetest Ableiten von Funktionstests VII Pfadtesten gt Jedes m gliche Szenario wird mindestens einmal getestet gt d h jeder m gliche Pfad in den zu den Use Cases geh renden Aktivit tsdiagrammen wird mindestens ein Mal durchlaufen gt Anzahl der Wege wird schnell zu gro gt Auswahl wichtiger Tests Frage Was ist der Unterschied zwischen Zweig und Pfad Frage Wie oft muss ich den obigen Use Case durchlaufen SWE Prof Dr W Weber h_da Fachbereich Informatik 84 Pe 4 Abnahmetest Beispiel Ableiten von Funktionstests VIII Pfadgraph keine Eingabe f r 30 Sek Kundenreaktion EEE eo ale Ein Pfadgraph stellt alle m glichen Pfade PIN Validierung dar Er hat keine R ckw rtsspr nge PIN als PIN falsch und lt 3 Fehiversuche Ein Szenario ist ein Weg vom Startknoten zu Le einem Endknoten gt Wenn jeder Pfeil mindestens ein Mal durchlaufen ist sind alle Pfade durchlaufen er keine Engate tirat Sale d h jedes m gliche Szenario ist mindestens _Kundenreaktion ein Mal durchgespielt Kunde bricht ab PIN Eingabe erfolgt PIN V
110. eich Informatik 218 6 3 Entwurfsmuster Das Kompositum Muster Beispiel Klassendiagramm Ger te Komponenten Leistung als Teil Ganzes FuegeHinzu Geraet Hierarchien bzw Entferne Geraet Enthaltensein Erzeugelterator Hierarchien ZusammengesetztesGeraet DEREN CC Leistung FuegeHinzu Geraet Entferne Geraet Erzeugelterator Oooo 5 o Leistung Leistung Leistung GesamtPreis GesamtPreis GesamtPreis DiscountPreis DiscountPreis DiscountPreis SWE Prof Dr W Weber h_da Fachbereich Informatik FloppyDisk Leistung Leistung GesamtPreis GesamtPreis DiscountPreis DiscountPreis 219 3 VE Das Kompositum Muster Beispielcode 1 class Geraet p blie virtual Geraet const char Name return _name virtual Watt Leistung class ZusammengesetztesGeraet public Geraet public virtual ZusammengesetztesGeraet virtual Watt Leistung virtual Betrag GesamtPreis virtual Betrag GesantPreis virtual Betrag DiseountPreis virtual Betrag DiseosunePreis virtual FuegeHinzu Geraet virtual FuegeHinzu Geraet virtual Entferne Geraet virtual Entferne Geraet virtual Iterator lt Geraet gt virtual Iterator lt Geraet gt Erzeugelterator Erzeugelterator protected ZusammengesetztesGeraet const char private protected Geraet const char private Liste lt Geraet
111. ektur stellt Zusammenspiel der Systemteile dar wie Subsysteme SW HW Komponenten und Tasks m Einige Subsysteme verwenden nur Artifakte aus einer Dom ne Paket andere benutzen Teile aus verschiedenen Dom nen m Die Physikalische Architektur beschreibt auch die Nutzung der Infrastruktur des Systems m Folgende Sichten sind in der Literatur beschrieben gt Subsystem und Komponenten Sicht Logische Sicht gt Prozess Sicht Thread Level Concurrency and Resource View gt Einsatz Deployment Physische Sicht was l uft auf welcher HW Komponente gt Implementation Dateien Sicht gt Anwendungs Sicht nach Kruchten95 E gt Tafelbild SWE Prof Dr W Weber h_da Fachbereich Informatik 124 2 eg 5 2 Darstellung der Architektur ee Ebenen der Abstraktion Subsysteme Komponenten Threads siehe pougiasso6 System Level Systems Engineering Level lt lt subsystem gt gt pe Electronic Software Mechanic ae ae Level komponent omponent J Software Component omponent komponent L evel lt lt active gt gt lt lt active gt gt lt lt active gt gt SWE Prof Dr W Weber h_da Fachbereich Informatik Thread Level 125 5 2 Darstellung der Architektur 7 Subsystem Sicht Komponenten Sicht Logische Sicht er m Die Subsystem und Komponenten Sicht identifiziert die gro en Teile des
112. ektvolle Kommunikation Kritik Informationen gt Pair Programming zwei Programmierer einer codiert einer denkt mit regelm ig die Rollen tauschen Vier Augen Prinzip gt Testgesteuerte Programmierung erst Unit Tests schreiben dann Funktionalit t programmieren SWE Prof Dr W Weber h_da Fachbereich Informatik 429 11 Vorgehens und Prozessmodelle Die agile Vorgehensweise Extreme Programming XP Grundprinzipien m Prinzipien Auswahl gt Inkrementelles Design d h Design ist nicht von vornherein festgelegt sondern st ndig nderbar erweiterbar gt St ndige Integration neu erstellter ver nderter Teile Build sollte in 10 Minuten durchf hrbar sein gt Refactoring systematisches und regelm iges berarbeiten der Ergebnisse entferne Redundanz l sche berfl ssige Funktionalit t berarbeite das Design gt W chenzyklen Meeting mit Planung der Arbeit f r eine Woche gt Quartalszyklus Meeting mit Besprechung der Themen f r n chstes Quartal SWE Prof Dr W Weber h_da Fachbereich Informatik 430 Die agile Vorgehensweise Scrum Grundprinzipien Rollen mM Scrum ist ein Prozessmodell f r agile Produkt und Softwareentwicklung m F r Scrum sind auch die oben beschriebenen Prinzipien g ltig m Scrum besteht aus einfachen Arbeitstechniken und Ritualen sowie wenigen Rollen und Artifakten m Eine kurze aber etwas detailliertere Beschreibung finden
113. elationship Modell konzeptionelles Datenmodell mit Datenobjekten und Bez Software Ergonomie bedienerfreundliche Benutzerschnittstelle SWE Prof Dr W Weber h_da Fachbereich Informatik 04 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 5 3 Entwicklung von phasenspezifischen Software Engineering Methoden 1972 1975 gt Umsetzen der Software Engineering Prinzipien in Entwurfsmethoden Struktogramme HIPO Hirachical Input Process Output Jackson Constantine Methode Structured Analysis Workflow Structured Design Spezielle Aufrufhierarchiediagramme 4 Entwicklung von phasenspezifischen Werkzeugen 1975 1985 gt Einsatz von SE Methoden mit maschineller Unterst tzung z B Programminversion zu einer Prozedur Tabellarische Auflistung von gerufenen Prozeduren rufenden Prozeduren Verwendeten Bildschirmmasken gelesene geschriebene Dateien auch als Aufrufmatrix gt Kap Metriken Batchwerkzeuge SWE Prof Dr W Weber h_da Fachbereich Informatik 00 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 6 5 Entwicklung von phasenubergreifenden integrierten Software Engineering Methoden ab 1980 gt Automatische Weitergabe der Ergebnisse einer Phase des Software Lifecycles an die nachste Phase Methodenverbund 6 Entwicklung von phasen bergreifenden integrierten Werkzeuge Case Tools ab 1980 gt Einsatz einer Datenbank
114. elopment Complex Debug Complex exe testEquality OK itestNonEquality OK test ddition assertion ComplexNumberTest testDivision OK ComplexNumberTest testDivideByZeroThrows OK complexTest cpp 49 Assertion Test name ComplexNumberTest testaddition assertion failed _ Expression m 10 1 mm 1 1 lt Si 11 2 Failures Run 5 Failure total 1 Failures 1 Errors O il PE SWE Prof Dr W Weber h_da Fachbereich Informatik 341 UNIVERSITY OF APPLIED SCIENCES 8 6 Testwerkzeuge Testen mit xUnit Sonstiges Im xUnit Framework ist es recht einfach Tests zu erstellen wenn man das Prinzip verstanden hat Ein funktionierendes Beispiel erleichtert den Start aber erheblich ist der Zugriff auf private Attribute und Methoden normalerweise nicht m glich Es gibt aber oft Tricks um zu Testzwecken darauf zugreifen zu k nnen wird der praktische Einsatz diverser Design Patterns demonstriert kann testgetrieben entwickelt werden d h es wird immer erst ein Test geschrieben und erst dann der Code der den Test zum Erfolg bringt SWE Prof Dr W Weber h_da Fachbereich Informatik 342 8 6 Testwerkzeuge Testen mit xUnit im Gesamtzusammenhang m Mit entsprechenden Addons zu xUnit gt kann aus den Tesifallen eine Dokumentation der Testf lle erzeugt werden gt kann die erzielte Anweisungs oder Zweig berdeckung berechnet und dargestellt werden Test Coverage gt k
115. ementierung m Warum sind Programmierrichtlinien oft unbeliebt m Wie kann man den Widerstand der Entwickler reduzieren m Warum wird die Einhaltung von Regeln h her gewichtet als Effizienz Stimmung und Entwicklungsgeschwindigkeit m Was passiert in einem gro en Projekt wenn es keine Programmierrichtlinien gibt m Wann treten erstmalig Probleme auf wenn Sie eine andere String Bibliothek verwenden als die in den Richtlinien vorgegebene Le TR aaa SWE Prof Dr W Weber h_da Fachbereich Informatik DAA Hochschule Darmstadt Fachbereich Informatik software Engineering 8 Test und Integration h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 245 e 8 Test und Integration Einordnung im V Modell i co 7 2 o Integrations test LL al era SWE Prof Dr W Weber h_da Fachbereich Informatik 246 E 8 Test und Integration Lernziel Test und Integration m Sie sollen in diesen Kapitel verstehen gt was ein Fehler ist gt was Testen ist gt wie man geschickt Testf lle ausw hlt gt dass Black Box und White Box unterschiedliche Testm glichkeiten bieten gt welche Unterschiede es gibt zwischen Anweisungs Zweig Pfad und Bedingungs berdeckung gt was Integration ist gt warum es im V Modell 4 Testphasen gibt gt was in den einzelnen Testphasen zu tun ist
116. en die Qualit t des SW Entwicklungsprozesses in Organisationen Prozess Bewertungs Modelle SPICE CMMI nicht die Qualit t der Software Prinzipien die beachtet werden m ssen N Prinzipien sollten beachtet werden Assessment Appraisal SW Entwicklungsprozess Modelle Durch Tailoring wird der SW Entwicklungsprozess an die Erfordernisse des Projektes angepasst Tools Templates Methoden Rollen U Modell XT P N Wird verwendet von Projekte in der Organisation Projekte verwenden einen projektspezifischen SW Entwicklungsprozess Planung Abwicklung des Projektes FR SWS lt a Fr 2 kocnsenute oamusmaor SWE Prof Dr W Weber h_da Fachbereich Informatik 441 I 11 1 Modelle zur Bewertung von Software Entwickungsprozessen Was ist SPICE Das Process Reference Model PRM ISO IEC 15504 5 PRIMARY Life Cycle Processes ORGANIZATIONAL Life Cycle Processes Acquisition Process Group ACQ ACQ 1 Acquisition preparation Management Process Group MAN ACQ 2 Supplier selection MAN 1 Organizational alignment ACQ 3 Contract agreement MAN 2 Organizational management ACQ 4 Supplier monitoring MAN 3 Project management MAN 4 Quality management ACQ 5 Customer acceptance MAN 5 Risk management Supply Process Group SPL MAN 6 Measurement SPL 1 Supplier tendering SPL 2 Product release Process Improvement Process Group PIM SPL 3 Product acc
117. enn alle Prozess Attribute gt des Levels mindestens largely achieved sind und gt die Prozess Attribute der darunterliegenden Levels fully achieved sind SWE Prof Dr W Weber h_da Fachbereich Informatik 452 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen Was ist CMMI m Die Zielsetzung vom CMMI ist die gleiche wie die Zielsetzung von SPICE gt Bewertung des SW Entwicklungsprozesses in CMMI zus System Entw Process CMMI bietet 2 Methoden zur Bewertung an gt Die kontinuierliche Darstellung continuous representation ist SPICE sehr hnlich Bewertet einzelne Process Areas Live Cycle Processes in SPICE mit einem Capability Level wie im Target Profile definiert Process Assessment Modell in SPICE gt Die stufenformige Darstellung staged representation bewertet die Organisation mit einem Reifegrad maturity level Im Normungsgremium von SPICE wurde inzwischen auch eine stufenf rmiger Darstellung erarbeitet SWE Prof Dr W Weber h_da Fachbereich Informatik 453 SSS 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen CMMI Continuous Representation SPICE meta model Teena SWE Prof Dr W Weber h_da Fachbereich Informatik END 2 1 1 Modelle zur Bewertung von Software Entwickungsprozessen CMMI Staged Representation have to be examined 1 Meta model of the CMMI Continuous Representation
118. entdeckt man solche Klassen oder Attribute erst in der Wartungsphase entsteht unerw nschter Aufwand weil die Anderung mehrere Klassen betrifft gt Das gezielte Hinterfragen der m n Beziehung l st im Beispiel das Problem Gibt es irgendetwas das jeder einzelne Reisende f r eine Reise braucht liefert Ja f r diverse L nder braucht man ein spezielles Visum gt Reisevoraussetzung m Wandle m n Beziehungen um wenn es sinnvoll erscheint gt L se m n Beziehungen in mehrere 1 n Beziehungen auf gt F ge dazu neue Klassen ein vgl Umsetzung von Assoziationsklassen in C und finde fachlich passende Begriffe f r die neuen Entit ten Manchmal gibt es noch keinen Begriff f r die neue Entit t Dieser sollte dann zusammen mit der Fachabteilung festgelegt werden H ufig enthalten die neu entstehenden Entit ten weitere fachliche Informationen z B ein Datum SWE Prof Dr W Weber h_da Fachbereich Informatik 188 6 2 Regeln zum Entwurf von Klassen Weitere Regeln eigentlich selbstverstandlich aber m Vermeide 1 1 Beziehungen gt Stehen zwei Entit ten in einer 1 1 Beziehung so sollte man sie sofern fachlich sinnvoll in eine Entit t zusammenfassen Das vereinfacht das Modell Beispiel Auftrag und Auftragskopf gt Auftrag m Modelliere nur fachliche nie technischen Aspekte gt Beispiel Eine Entit t Liste oder gar VerketteteListe gibt es nicht Realisierung von x n Assoziation m Beschrank
119. entierung m In Programmieren und Il haben Sie gelernt Konzeption von Datenstrukturen und Algorithmen Strukturierung von Programmen Dokumentation der L sung und der Implementierung Umsetzung der Konzepte in C grobes Testen der entwickelten Programme gt allerdings f r kleine Projekte in kleinen Teams Programmieren im Kleinen E Im Software Engineering geht es um Programmieren im Gro en gt die erlernten Implementierungstechniken bleiben g ltig gt aber die Randbedingungen ndern sich gt Wartbarkeit und Beherrschung der Komplexit t dominieren die Entwicklung he FR are pon SWE Prof Dr W Weber h_da Fachbereich Informatik 238 E 7 Implementierung Bedeutung von Programmierrichtlinien m Ziele gt Zusammenarbeit in einem Projekt erleichtern gt Integration und Test erleichtern gt Langj hrige Wartung erm glichen gt Zuverl ssigkeit und Robustheit erh hen gt Steigerung der Effizienz der Entwicklung m Richtlinien gt sind verbindlich f r den Entwickler gt sollten nach M glichkeit eingehalten werden gt werden bei Beauftragungen zur Auflage gemacht All SER SWE Prof Dr W Weber h_da Fachbereich Informatik 239 i 7 Implementierung Exemplarischer Inhalt einer Programmierrichtlinie mit Beispielen gt Allgemeines Esistnach dem ISO C Standard zu programmieren gt Kommentierung Jede Klasse muss am Ort ihrer Deklaration mit einem Kommentar eingeleitet
120. eptance support PIM 1 Process establishment PIM 2 Process assessment Engineering Process Group ENG PIM 3 Process improvement ENG 1 Requirements elicitation ENG 2 System requirements analysis ENG 3 System architectural design Resource and Infrastructure Process ENG 4 Software requirements analysis Group RIN ENG 5 Software design RIN 1 Human resource management ENG 6 Software construction RIN 2 Training ENG 7 Software integration RIN 3 Knowledge management ENG 8 Software testing RIN 4 Infrastructure ENG 9 System integration ENG 10 System testing ENG 11 Software installation ENG 12 Software and system maintenance Reuse Process Group REU REU 1 Asset management REU 2 Reuse program management REU 3 Domain engineering Operation Process Group OPE OPE 1 Operational use OPE 2 Customer support SUPPORTING Life Cycle Processes Support Process Group SUP SUP 1 Quality assurance SUP 6 Product evaluation SUP 2 Verification SUP 7 Documentation SUP 3 Validation SUP 8 Configuration management SUP 4 Joint review SUP 9 Problem resolution management SUP 5 Audit SUP 10 Change request management een SWE Prof Dr W Weber h_da Fachbereich Informatik 442 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Process Assessment Model PAM Die Qualit t eines Prozesses z B ENG 1 ist bewerted mit einem Capability Capability Level Fahigkeits Dimension Optimizing 5 Optimierend Pr
121. epte Gesetzliche Auflagen z B Hygiene Reinigungskonzept Aussagen zu nicht funktionalen Anforderungen z B Erweiterbarkeit Auflagen f r Programmiersprache Betriebssystem LE EL LE LI LEL SWE Prof Dr W Weber h_da Fachbereich Informatik 63 3 Anforderungsanalyse Erstellung eines Pflichtenhefts I m Annahme Es liegt ein gutes Lastenheft vor m Was fehlt noch Details gt gemeinsame Sprache gt Glossar gt gemeinsames Verst ndnis der Funktion gt Funkt Anf gt gemeinsames Verst ndnis der Randbedingungen gt n funkt Anf gt gemeinsame Vorstellung ber das Zielsystem gt GUI m Wie kommt man dahin amp gt Extrahieren Validieren und Verifizieren NV Mi 4 nach K Pohl Process a gt x Centered Requiremens A Engineering 1996 Spezifizieren yerhandeln lt F SWE Prof Dr W Weber h_da Fachbereich Informatik 64 3 Anfo rderungsanalyse En Ss r T und Verifizieren Erstellung eines Pflichtenhefts II MAREE S 4 gt Spezifizieren sp acon m Extrahieren Extraction Elicitation nn gt Kennenlernen der Anwendungsdom ne Aufnahme Istablauf gt Gemeinsames Brainstorming Diskussionen Anwenderbefragungen Dokumenten und Literaturstudium gt Schwachstellen Verbesserungsvorschl ge W nsche verborgene Anforderungen finden L sungsalternativen finden und ausw hlen m Spezifizieren Specification gt Thema verst ndlich und kommunizierbar machen dokumenti
122. ere hundert Sensoren SWE Prof Dr W Weber h_da Fachbereich Informatik 138 5 2 Darstellung der Architektur a ae tr Einsatz Deployment S icht in Anlehnung an Douglass06 I P hysische Sicht ic Verteilungs Deployment f Primary diagramm Main Data Radar Aqu Radar Processor Bus Secondary Radar Backup Data Aqu Processor GPS Network Tape System engo Flight Recorder Mirrored Tape System Scheduling NAS Interface Backup Display Device Controller Display Terminal Controller ee SWE Prof Dr W Weber h_da Fachbereich Informatik 139 5 2 Darstellung der Architektur nv RH Einsatz Deployment Physische Sicht in Anlehnung an Kruchten95 csd Audio Video Hardware Audio Video System CD DVD Player vorne CD1 Control Send ee cone Vorne Liest DVD Empf ngt TV Signal und liefert ein TV Video Monitor zeigt eine Videoquelle an Antenne ee SWE Prof Dr W Weber h_da Fachbereich Informatik 140 52 Darstellung der Architektur ug Im plementations S icht in Anlehnung an Kruchten95 bo E Komponentendiagramm mit Dateien Repositories und deren Beziehungen untereinander cod CocktailPro2006 n n D component on use ps ee cpp artifact DO use artifact DO artifact DO men Zee Rezepturprozessor cpp Rezeptbuch hpp Rezeptbuch o Fa component oe pets Dosierer Dosierer pet
123. eren m Validieren gt Werden Erwartungen der Benutzer Auftraggeber wirklich erf llt gt Diskussionen von Auftragnehmer amp Auftraggeber m Verifizieren gt Konsistenz der Einzelspezifikationen pr fen Technische berpr fung z B durch Spezialisten Test Team m Verhandeln Negotiation gt Einigung auf Reihenfolge Priorit t Umfang etc einer Realisierung mit allen Stakeholdern SWE Prof Dr W Weber h_da Fachbereich Informatik 65 3 Anforderungsanalyse Bestandteile eines Pflichtenhefts m Funktionale Anforderungen gt konkrete Anwendungsf lle und Abl ufe z B Use Cases Story Cards Text gt Benutzer Akteure Die konkrete Art m Nicht funktionale Anforderungen gt Systematische Betrachtung der Qualit tseigenschaften gt Priorisierung der Qualit tseigenschaften m Benutzungsschnittstelle GUl Graphical User Interface HMl Human Machin Interface gt Skizzen und Snapshots Navigationskonzepte Dialogf hrung m Glossar gt Zentrale Sammlung der Definitionen aller wichtigen Dinge der Problemwelt gt den Auftraggeber nicht mit neuen Begriffen beglucken gt Universalausdr cke vermeiden genau spezifizieren System Komponente m Sonstiges gt z B Modellierung der Daten des interessierenden Realweltausschnitts Analyse Klassendiagr li poese omar SWE Prof Dr W Weber h_da Fachbereich Informatik 66 3 Anforderungsanalyse Tatigkeiten bei der Anforderungsanaly
124. erkzeuge Testen in gr eren Projekten I m Stellen Sie sich nun vor alle Ihre zu testenden Programme sind Module die zu einem gr eren Projekt geh ren gt Die Module sollen regelm ig integriert und getestet werden Sie m ssen die Testaufrufe aus den Main Funktionen der Einzelprojekte zu EINER zunehmend un bersichtlichen Main Funktion zusammenf hren Die Tests f r ein Modul k nnen dann nicht mehr einzeln durchgef hrt werden Jeder neue Testfall erfordert eine nderung an der Main Funktion Die Reihenfolge der Tests kann evtl eine Auswirkung auf das Ergebnis haben gt Die manuelle Durchf hrung dieser Tests w re in der Summe sehr aufw ndig w re nicht reproduzierbar w re nicht systematisch w re nicht zuverl ssig genug f r ein professionelles Projekt KI eee me SWE Prof Dr W Weber h_da Fachbereich Informatik 329 gt SS 8 6 Testwerkzeuge Testen in gr eren Projekten Il m blicherweise findet in einem gr eren Projekt die Entwicklung von Modulen in verschiedenen Teams statt gt Die Tests m ssen einzeln durchf hrbar sein aber auch leicht zusammen zu f hren sein gt Jedes Team entwickelt seine Klassen und schreibt entsprechende Tests m blicherweise findet in einem gr eren Projekt die Entwicklung in Iterationen statt Nach jeder Iteration also t glich oder mindestens w chentlich muss getestet werden ob die entwickelten Module noch die
125. es m Bei der Software gibt es ebenfalls verschiedene Sichten gt Logische Zerlegung gt Verteilung auf Zielsysteme gt Quelldateien gt Prozesse Threads 119 5 2 Darstellung der Architektur Logische and Physikalische Architektur nach Douglasss04 Real Time UML Addison Wesley 2004 S 3 va Physical Logical m wv Architecture Architecture Folgende Namen hat diese Sicht in der Literatur Folgende Namen haben diese Sichten in der Literatur e Paket Sicht Dom nen Sicht Logische Architektur e Subsystem und Komponenten Sicht Logische Sicht e Prozess Sicht Thread Level Concurrency and Resource View Einsatz Deployment Physische Sicht HW Komponenten e Implementations Dateien Sicht e Anwendungs Sicht nach Kruchten95 il a SWE Prof Dr W Weber h_da Fachbereich Informatik 120 5 2 Darstellung der Architektur sigue I Paket Sicht Dom nen Sicht Logische Architektur En m Organisiert Dinge die zur Design Zeit existieren m System wird in Pakete Dom nen gegliedert m Ein Paket ist ein Bereich mit Dingen Ergebnisse von Arbeitsprozessen Artifakte normalerweise mit einem eigenen Vokabular Namensraum bei Programmen m Jeder Artifakt ist genau einem Paket zugewiesen m Pakete werden oft in Abh ngigkeits Hierarchien angeordnet Gliederung des Gesamtpakets zum System Menge aller Artifakte in Schichten z B Paket f r Anforderungsanalyse Design Implementierung siehe auch li
126. essorientiertes Qualitatsmgmt ISO CMM Assessments gt S gibt aber noch viele andere Themen SWE Prof Dr W Weber h_da Fachbereich Informatik 347 Hochschule Darmstadt Fachbereich Informatik software Engineering 9 Qualitatssicherung h da sa i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 348 9 Qualitatssicherung Qualitatssicherung m Qualitatssicherung beinhaltet Ma nahmen die sicherstellen sollen dass ein Produkt ein vorgegebenes Qualit tsniveau erreicht gt es geht darum eine vorgegebene Qualit t zu erreichen nicht unbedingt um die h chste Qualit t m Produktqualit t gt Die Ma nahmen zielen auf die Qualit t der Bestandteile des Produkts SEE Anwendung konstruktiver Ma nahmen bei der Entwicklung des Produktes n chste Anwendung analytischer Ma nahmen zur Untersuchung der Produktteile Folien m Prozessqualitat gt Die Ma nahmen zielen auf die Qualit t des Prozesses mit dem das Produkt erstellt wird Definition bzw Festlegung und Anwendung eines Entwicklungsprozesses Aktive Suche nach Schwachstellen im Entwicklungsprozess Systematische Verbesserung des Entwicklungsprozesses so dass beim n chsten Projekt nicht wieder die gleichen Fehler gemacht werden siehe z B Norm ISO 9001 CMM CMMI SPICE SWE Prof Dr W Weber h_da Fachbereich Informatik 349 9 Qua
127. f Dr W Weber h_da Fachbereich Informatik HSCHULE DARMSTADT RSITY OF APPLIED SCIENCES 475 132 Gesamtergebnis H ufige M ngel in Software Projekten sind vermeidbar Reviews Vorgehens Modelle Metriken Anf analyse Pflichtenheft Architektur Design Implementierung I Anforderungs A g Analyse Pflichtenheft Lastenheft locumented Model lierung nn Projekt Dokumen i Management tation Abnahme SWE Prof Dr W Weber h_da Fachbereich Informatik 476 13 2 Gesamtergebnis Kritische Bemerkungen zum Schluss m Modelle und Prozesse sind wichtige Instrumente auf dem Weg zur Software gt aber die Software ist das Ziel nicht das Modell oder der Prozess gt Modelle sind sinnvoll solange sie Aufwand reduzieren auch in der Wartung das Modell darf aber kein Selbstzweck werden gt In der Modellierung geht es nicht darum die neuesten UML Features zu verwenden Sie dokumentieren f r Ihre Kollegen und f r die Wartungsphase Verwenden Sie einfach eine Notiz im Modell um Hinweise zu geben Dokumentieren Sie auch Zusatzinformationen wie Zwischenergebnisse grunds tzliche Ideen und L sungsans tze nicht so leicht ersichtliche Randbedingungen und die Gr nde bei einer Entscheidung mit Alternativen gt Ein Prozess soll helfen Wenn er mehr behindert als n tzt ist er der falsche f r dieses Projekt SWE Prof Dr W Weber h_da Fa
128. fert wertvolle Hinweise f r die Entwicklung gt Die Interpretation der Ergebnisse erfordert oft viel Erfahrung und Sachkenntnis m Metriken m ssen von allen Beteiligten mit Verstand eingesetzt werden gt Ein Entwickler kann Metriken immer austricksen Kennt man die Berechnungsvorschrift kann man die Metrik auch manipulieren gt Ein Manager darf die Ergebnisse der Metriken nicht berbewerten ern SWE Prof Dr W Weber h_da Fachbereich Informatik aa E 10 Metriken Kontrollfragen Metriken m Was halten Sie von LOC Lines of Code zur Beurteilung Ihres Arbeitsfortschritts Welche Metrik ist besser Wozu sind Metriken wichtig Wof r k nnen Metriken definiert werden Warum sind Metriken oft bei Managern beliebt und bei Entwicklern unbeliebt Was passiert wenn zus tzliche Metriken Ma zahlen erfasst werden um den Verzug eines Projekts zu verstehen Wie k nnen Tools die Einhaltung von Metriken mit Sollwerten visualisieren Welche Bedeutung hat das Ma IF4 il a SWE Prof Dr W Weber h_da Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik software Engineering 11 Vorgehens und Prozessmodelle h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 382 ma B 11 Vorgehens und Prozessmodelle Lernziel Vorgehensmodelle m Sie sollen in diesen Kapitel lernen gt was e
129. fwendiger als im Programmierpraktikum Ist ein externer Auftraggeber vorhanden berpr ft dieser die Systemfunktionen mit einem eigenen Pr fkatalog gt Ergebnis Im Programmierpraktikum Sie bekamen Ihre Abnahme fertig Bei der kommerziellen Softwareentwicklung Die Software kommt zum Einsatz d h der Betrieb des Systems SWE Prof Dr W Weber h_da Fachbereich Informatik 42 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Einfuhrung m Inder Einf hrung Rollout gt wird das neue System in Betrieb genommen und evil ein altes System abgeschaltet Evtl st ckweise Umstellung Evtl mit M glichkeit zur Wiederherstellung des alten Systems Rollback Evtl anfangs Parallelarbeit im alten und neuen System gt T tigkeiten Planung der Einf hrung Termine Ank ndigungen Verteilung von Anleitungen usw Schulung des Personals Aufbereitung Migration von Daten Erfassung von Daten Installation der Software der Hardware Bereitstellung einer Hotline Eigentliche Umstellung gt Ergebnis Das System ist bereit f r den Normalbetrieb SWE Prof Dr W Weber h_da Fachbereich Informatik 43 E 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Betrieb m Betriebsphase gt ist die l ngste aller Phasen gt verursacht oft sehr hohe Kosten Frage Was meinen Sie Wie lang Wie viel der Kosten gt ca 80 der Kosten aller Phasen
130. ganisationseinheitlich festgelegter Standard Prozess m Ein Projekt verwendet eine angepasste tailored Version dieses Standard Prozesses gt definierter Prozess m W hrend der Prozessausf hrung Identifikation von Schwachstellen Verbesserung des Standardprozesses m Der Established Process hat auch wieder 2 Process Attributes f r die die Generic Practices Generic Resources Generic Work Products nachgepr ft werden SWE Prof Dr W Weber h_da Fachbereich Informatik 448 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen SPICE Capability Level 4 Level 4 Predictable Process m In jedem Projekt werden Schl sseldaten gesammelt wie z B Anzahl der im Integrationstest gefundenen Fehler pro Zeile statistische Daten Uber den Grund der Fehler m Es k nnen Schl sseldaten von unterschiedlichen Projekten verglichen werden wegen Einf hrung Standardprozess m Es k nnen statistische Auswertungen ber den archivierten Schl sseldaten gemacht werden gt Wir k nnen Konsequenzen von Entscheidungen voraus sagen gt Wir k nnen vor dem Eintreten negativer Auswirkungen reagieren gt Das Management kann das Projekt objektiv bewerten SWE Prof Dr W Weber h_da Fachbereich Informatik 449 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Capability Level 5 Level 5 Optimizing Process m Quantitative Prozessziele werden gesetzt und die Einhaltung verfolg
131. gen Il a Produktfunktionen Cocktail auf Knopfdruck Il b Produktschnittstellen Wasser Strom Dosierer Il c Anwenderprofile Wirte geringe Ausbildung Nichtfunktionale Anforderungen Ill a Qualit tsanforderungen einfaches GUI Knopf Cocktail 1 Cocktail in 30 Sek IIl b Techn Anforderungen Innenraum Wandmontage Lieferumfang Gesamtsystem Code Wartung Abnahmekriterien 50 Cocktails ohne St rung Anh nge Systemskizze Beschreibung von Dosierer etc EN EEE SWE Prof Dr W Weber h_da Fachbereich Informatik 61 E3 Anforderungsanalyse bung CocktailPro Ill System berblick aus Sicht des Auftraggebers Rezeptur Rezept Waage he FR are pon SWE Prof Dr W Weber h_da Fachbereich Informatik 3 Anforderungsanalyse Ubung CocktailPro IV Offene Punkte m Obwohl das Lastenheft alle Punkte anspricht fehlen noch viele Infos m Unklar ist zum Beispiel gt Wer liefert den Rechner das Geh use Woher kommen die Rezepte Wie werden neue Rezepte eingespielt Remote vor Ort Schnittstelle Wie viele Rezepte werden angeboten Das GUI Konzept verlangt je 1 Knopf GUI Sprachen Internationalisierung Sonderzeichen Aufl sung Farbe Was passiert bei einer St rung Fernwartung oder F hrung durch System Wer zahlt bei St rungen in zugelieferten Teilen Wie viele Zutaten k nnen gemischt werden Dosierer Was wird gewartet Ausgelieferte Systeme oder nur die Software Rez
132. glich gt Es kommen dann gleichzeitig Drivers und Stubs zum Einsatz SWE Prof Dr W Weber h_da Fachbereich Informatik 304 E 8 3 Integrationstest Integrationstest m Was ist ein Integrationstest gt Pr fung ob mehrere Module fehlerfrei zusammenwirken gt Test von Teilen des Gesamtsystems gt Fokus auf das Zusammenspiel der Systemkomponenten m Wie f hre ich einen Integrationstest durch gt durch ein Test bzw Integrations Team gt Schrittweiser Zusammenbau des Teilsystems und Ansteuerung mit Drivers und Verwendung von Stubs m Was wird in einem Integrationstest getestet gt Ein Verbund aus bereits einzeln getesteten Systemkomponenten oder bereits integrierte und getestete Teilsystemen gt Die verwendeten Module h ngen von deren Verf gbarkeit zum Zeitpunkt des Tests sowie der gew hlten Integrationsstrategie ab il ae SWE Prof Dr W Weber h_da Fachbereich Informatik 305 ae 8 3 Integrationstest Frage Integrationstest Wo finden wir im SW Entwurf mit UML f r den OO Test die Aufrufhierarchie gt In den Sequenzdiagrammen Wie sind Sie in im Praktikum vorgegangen Wie wurden Sie Vorgehen beim Test von Konstruktor Dosierverwalter bzw entsprechende Fkt zur Erstellung der Dosierer in Rezeptprozessor Was ist der Vorzustand die Eingabe der Nachzustand die Ausgabe SWE Prof Dr W Weber h_da Fachbereich Informatik 306 Hochschule Darmstadt Fachbereich Informatik s
133. gt _teile const char _name Betrag Einzelteil_Preis class FloppyDisk public Geraet class Gehaeuse public public ZusammengesetztesGeraet FloppyDisk const Chart public virtual FloppyDisk Gehaeuse const char virtual Watt Leistung el se 0 virtual Betrag GesamtPreis en Wane Dee ne O virtual Betrag DiscountPreis virtual Betrag GesamtPreis virtuali Betrag Diseetmtrreiet 7 Most INIVERSITY OF APPLIED SCIENCES Das Kompositum Muster Beispielcode 2 class ZusammengesetztesGeraet Betrag ZusammengesetztesGeraet GesamtPreis public Geraet Iterator lt Geraet gt iter Erzeugelterator Betrag gesamt 0 publie re for iter gt Start iter gt IstFertig iter gt Weiter virtual Betrag GesamtPreis gesamt iter gt AktuellesElement gt GesamtPreis delete iter Lg return gesamt Einzelteil_Preis Instanziierung eines Baums Gehaeuse gehaeuse new Gehaeuse PC Gehaeuse Rahmen rahmen new Rahmen PC Rahmen gehaeuse gt FuegeHinzu rahmen Bus bus new Bus MCA Bus bus gt FuegeHinzu new Karte 16Mbs Token Ring rahmen gt FuegeHinzu bus rahmen gt FuegeHinzu new FloppyDisk 3 5in Floppy cout lt lt Der Gesamtpreis betraegt lt lt gehaeuse gt GesamtPreis lt lt endl ee SWE Prof Dr W Weber h_da Fachbereich Informatik 004 m 7 6 3 Entwurfsmuster Literatur zu
134. gt d h es rentiert sich Aufwand zu investieren f r die Erstellung bersichtlich entworfener und gut getesteter Programme mit guter Dokumentation gt Ergebnis Fehler und Unzul nglichkeiten am Produkt werden hier bereinigt SW wird an ge nderte Einsatzzwecke und betriebliche Abl ufe angepasst Oft ist das Zur ckgehen ber mehrere Phasen hinweg notwendig aly eee eae SWE Prof Dr W Weber h_da Fachbereich Informatik AA E 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Der Software Lebenszyklus Software Life Cycle Einf hrung Betri Analyse Zul Abnahme Integrations Definition Test Architektur Integration Implementierung m Die Detaillierung der einzelnen Phasen h ngt vom Bedarf ab gt Zusammenlegung uninteressanter Phasen gt Verfeinerung interessanter Phasen en SER SWE Prof Dr W Weber h_da Fachbereich Informatik 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Phasenmodelle m Durch den Einsatz von Phasenmodellen wird ein Softwareprojekt zeitlich strukturiert Es wird festgelegt gt u GUY Welche Arbeiten sind in welchen Phasen zu erledigen Welche Arbeitsergebnisse m ssen in den Phasen erzeugt werden Welche Personen haben die Ergebnisse zu erarbeiten Wie sollen die Ergebnisse dokumentiert werden Welche Termine m ssen eingehalten werden Welche Standards und Richtlinien sind einzuhalten Ph
135. h_da Fachbereich Informatik 206 6 3 Entwurfsmuster Ein anderes Problem mit der gleichen Losung gt Mehrere Diagramme h ngen von einem a gemeinsamen Datenobjekt ab gt Sr Anderungen der Daten sollen in allen Saule 3 7 Diagrammen angezeigt werden a gt Die Anzahl der Diagramme ist variabel Pe S ule 2 a 50 b 30 c 20 S ule 3 il ee SWE Prof Dr W Weber h_da Fachbereich Informatik N a E S ule 1 E S ule 2 E S ule 3 E Segment 1 E Segment 2 El Segment 3 207 E 6 3 Entwurfsmuster Ein anderes Problem mit der gleichen Losung gt es gibt eine Datenbasis Subjekt gt es gibt mehrere Beobachter gt das Subjekt benachrichtigt die Beobachter ber Anderungen S ule 1 2 0 0000 S ule 2 a 50 b 30 c 20 S ule 3 ee gt 1 Benachrichtigung ber Anderung an El Segment 3 2 Holen der Ver nderungen Aufruf gibt Zustand zur ck SWE Prof Dr W Weber h_da Fachbereich Informatik 208 ltte 6 3 Entwurfs muster Beobachtermuster Observer Pattern Beobachter Beobachter meldeAn Beobachter LS meldeAb Beobachter aktualisiere abstrakt N benachrichtige KonkreterBeobachter beobachteterZustand aktualisiere V 1 Subjekt gibZustand setzeZustand
136. he Technik Aufteilung in Teile Pakete Komponenten Beschreiben der Verantwortlichkeiten der Pakete Komponenten Beschreiben der Kommunikation der Pakete Komponenten erste Evaluation der Funktionalit t m glich SWE Prof Dr W Weber h_da Fachbereich Informatik 95 _ 5 Software Architektur Definition Die Software Architektur eines Rechnersystems beschreibt die Struktur der Software des Systems die aus Dilbert Komponenten deren extern sichtbaren lisa bunanofshapes Eigenschaften und Verantwortlichkeiten connected by lines und deren Beziehungen besteht Len Bass et al Eine von vielen Definitionen siehe auch http www sei cmu edu architecture definitions html a BETEN SWE Prof Dr W Weber h_da Fachbereich Informatik 96 5 Software Architektur Lernziel Software Architektur m Sie sollen in diesem Kapitel verstehen LEE EL EL warum eine Software Architektur f r ein gro es Projekt wichtig ist was eine Software Architektur ist dass es viele Architekturen zu einer Aufgabe gibt dass die verwendeten Techniken der SW Architektur von der Anwendung abh ngen dass die Qualit tsanforderungen entscheidend f r die Architektur sind dass es bekannte Architekturstile mit bekannten Qualit tseigenschaften gibt dass es schwierig ist eine gute Architektur zu entwickeln wie man eine Architektur darstellt SWE Prof Dr W Weber h_da Fachbereich Informatik 97
137. hichten SW Architektur m Entwurfsmuster Design Patterns machen lokale sich auf wenige Klassen beziehende Entwurfserfahrungen der Wiederverwendung zug nglich gt nur abstrakt UML Modelle gt oft keine Implementierung gt Sie kennen Beobachtermuster Strategiemuster Kompositum Muster m Software Development Antipatterns gt demonstrieren h ufig gemachte Entwurfsfehler n chstes Kapitel m Rahmenwerke Frameworks erlauben Wiederverwendung von ganzen Entw rfen mit teilweiser Implementierung umfassen wesentliche Aspekte einer Gruppe hnlicher Anwendungssysteme siehe Programmieren Sie kennen Visual C sp ter C Unit ag SWE Prof Dr W Weber h_da Fachbereich Informatik 004 Ei Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 6 4 Anti Patterns h da ssy fii HOCHSCHULE DARMSTADT u HHHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 225 6 4 Anti Patterns Software Development Anti Patterns RRR meern Anti Patterns m While patterns help you to identify and implement procedures designs and codes that work Anti Patterns do the exact opposite Brown Malveau McCormick Mitp Verlag 2004 www antipatterns com catalog htm AN ERR SWE Prof Dr W Weber h_da Fachbereich Informatik 226 6 4 Anti Patterns The Blob ein Beispiel amp Catalog Topic Inventory Name
138. hode ausgef hrt werden ComplexNumberTestCase gt Mit speziellen Zusicherungen Assert s werden runTest zu pr fende Soll Ergebnisse festgelegt setUp Dow m Bei der testgetriebenen Entwicklung entwickeln Sie N erst den Test und dann die zu testende Klasse SWE Prof Dr W Weber h_da Fachbereich Informatik 330 Ih El 8 6 Testwerkzeuge C Unit Ein einfacher Test Case Prinzip Als Erstes entwickeln wir den Testfall Testgetriebene Entwicklung finclude hier m ssen u a Dateien des Frameworks inkludiert werden class ComplexNumberTestCase public CppUnit_NS TestCase public ComplexNumberTest string name CppUnit_NS TestCase name void runTest CPPUNIT_ASSERT Complex 10 1 Complex 10 1 CPPUNIT_ASSERT Complex 1 1 Complex 2 2 win Wir entwickeln nun die zu testende Klasse Complex und den Operator so dass der Test l uft class Complex friend bool operator const Complex amp a const Complex amp b double real imaginary public Complex double r double i 0 real r imaginary i bool operator const Complex amp a const Complex amp b return a real b real amp amp a imaginary b imaginary Dann Sl wir den TestCase ComplexNumberTestCase instanziieren und runTest aufrufen hda HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES SWE Prof Dr W Weber h_da Fachbere
139. ich Informatik 8 6 Testwerkzeuge C Unit Mehrere Tests mit setUp und tearDown TestFixture m Normalerweise wollen wir einige Instanzen der zu testenden und evil weiterer Klassen incl Daten vorher definieren und m mit diesen Instanzen eine Anzahl von Tests fahren z B testEquality s o und TestAddition Bei jedem Test soll aber der Zustand vor dem jeweiligen Test jeweils in den definierten Anfangs zustand gebracht werden TestFixture Wir verwenden die Klasse TestFixture setUp tearDown in der die abstrakten Operationen setUp und tearDown stehen die vor nach jedem Test den definierten Zustand herstellen Testcase die setUp und tearDown Methoden wie auch nile se die eigentlichen Tests z B testEquality und eee testAddition werden in der eigentlichen Testfixture z B ComplexNumberTest implementiert testEquality Die eigentlichen TestCases werden dann durch das testAddition C Unit Framework zusammengestellt und aufgerufen setUp tearDown ComplexNumberTest SWE Prof Dr W Weber h_da Fachbereich Informatik 334 8 6 Testwerkzeuge C Unit setUp und tearDown in der TestFixture include class ComplexNumberTest public CppUnit_NS TestFixture private Complex m_10_1 m_1_1 m_11_2 7 public void setUp ___ 0000000 m_10_1 new Complex 10 1 m_1_1 new Complex z TI 3 m_11_2 new Comple z 2 Ba 2 fesmach
140. ichtige y class Beobachter public virtual Beobachter virtual void aktualisiere Subjekt geaendSubjekt 0 pure virtual protected Beobachter class DigitalUhr public Widget public Beobachter public DigitalUhr ZeitGeber subjekt _subjekt subjekt _subjekt gt meldeAn this virtual DigitalUhr meldeAb this virtual void aktualisiere Subjekt geaendSubjekt Zeichne virtual zeichne int stunde _subjekt gt gibStunde private ZeitGeber _subjekt E 213 6 3 Entwurfsmuster Diskussion Beobachtermuster m Vor und Nachteile beim Einsatz des Beobachter Musters Beobachter k nnen leicht hinzugef gt oder entfernt werden Es wird nur aktualisiert wenn sich etwas ge ndert hat Wenn es nur wenige und feste Beobachter sind ist es etwas komplizierter als eine direkte Implementierung mit Abh ngigkeiten m Anwendungen gt E Mail Verteiler f r SW Updates Benachrichtigung automatisch Aktualisierung manuell Anzeige der Uhr in vielen Clients auf einem PC gt im Praktikum Dosierer Mischbeh lter und Display beobachten die Waage m Diskussion gt W rden Sie bei einer traditionellen Kuckucksuhr den Kuckuck als Beobachter der Uhr implementieren gt Wie w rden Sie in einem Autoradio implementieren dass CD Kassette etc bei einer Verkehrsfunkdurchsage anhalten SWE Prof Dr W Weber h_da Fachbereich Informatik 214 6 3 Entwurfsmuster Das Kompositum
141. ierung ur Test des Teilsystems D Abnahme des Teilsystems Betrieb amp E valuation des Teilsystems Def des Teilsystems i Entwurf des Teilsystems Projekt B iterativ mit Teilsystemen Def des Teilsystems A des Teilsystems p Implementierung und Test des Teilsystems p Abnahme des Teilsystems Betrieb amp Evaluatich des Teilsystems Analyse des Teilsystems i Implementierung und Test des Teilsystems p Abnahme des Teilsystems Betrieb amp Evaluation des Teilsystems SWE Prof Dr W Weber h_da Fachbereich Informatik 385 E 11 Vorgehens und Prozessmodelle Warum braucht man Vorgehens modelle m Softwareentwicklung ist ein komplexer Prozess und erfordert ein systematisches geplantes Vorgehen m Ein Vorgehensmodell gt gibt einen bew hrten Leitfaden f r den Entwicklungsprozess gt erlaubt die Beschreibung Optimierung und Zertifizierung von Entwicklungsprozessen SWE Prof Dr W Weber h_da Fachbereich Informatik 386 E 11 Vorgehens und Prozessmodelle Was ist ein Vorgehensmodell m Ein Vorgehensmodell legt fest gt die Reihenfolge des Arbeitsablaufs Entwicklungsstufen Phasenkonzepte gt Jeweils durchzuf hrende Aktivit ten in den Phasen gt Definition der Teilprodukte Arbeitsergebnisse gt Fertigstellungskriterien und Abnahmekriterien gt Notwendige Mitarbeiterqualifikationen gt Verantwortlichkeiten und Kompetenzen gt Anzuwendende
142. igprodukte Durch Projekttyvariante bedingte zu entscheidende Projektmerkmale Exportverzeichnis CY Anden E A Vorgehens und Prozessmodelle V Modell XT Entscheidungspunkte Projektdurchfuhrungsstrategie Entscheidungspunkte UNI pUnK i 2 3 4 F 5 a Ausschreibung Angebot Vertrag 12 F A e ane SWE Prof Dr W Weber h_da Fachbereich Informatik 420 Rest von V Modell XT ob nur zur Info nicht prufungsrelevant m Fre SWE Prof Dr W Weber h_da Fachbereich Informatik 421 SSS V Modell XT Metamodell Aes workflow is dependant on oe SWE Prof Dr W Weber h_da Fachbereich Informatik H Hi ADT I UNIVERSITY OF APPLIED SCIENCES i i 422 11 Vorgehens und Prozessmodelle V Modell XT Vorgehensbausteine Messung und Kaufmannisches Projektmanagement Vorgehensmodells Projektmanagement z B SW Entwicklung gt Systemerstellung Keane management W438 4 2POW A gt Qual Sicherung etc Qualit tssicherung ___ Problem und Anderungsmanagement Legende Alle V Modell Projekte Organisationsspezifisches Vorgehensmodell Die Yelt I Um B auswahlen zu A B k nnen muss auch A gew hlt werden ayya hda a HOCHSCHULE DARMSTADT A C ben tigt mindestens einen ee UNIVERSITY OF APPLIED SCIENCES B gt c der Bausteine A bzw B Bedarfsermittlu
143. in Vorgehensmodell beinhaltet gt wozu Vorgehensmodelle wichtig sind gt was die verschiedenen Modelle auszeichnet gt wodurch sich die verschiedenen Modelle unterscheiden il eee SWE Prof Dr W Weber h_da Fachbereich Informatik 383 iH 11 Vorgehens und Prozessmodelle Vorgehen in Projekten am Beispiel Pp Projekt A Projekt B en x te Weiterentwicklung mit innovatives Produkt basierend auf J langer Wartung traditionellem Produkt traditionelles Autoradio neuartiges Navigationssystem Auftraggeber wei genau was er will wei nicht wirklich was er will Auftragnehmer wei genau wie es geht wei auch nicht so genau was sinnvoll ist m Wie w rden Sie diese Projekte angehen m In welcher Reihenfolge w rden Sie die bekannten Entwicklungsphasen durchlaufen m W rden Sie die Phasen einmal vollst ndig oder eher inkrementell durchlaufen SWE Prof Dr W Weber h_da Fachbereich Informatik 384 11 Vorgehens und Prozessmodelle Die Grundidee fur Vorgehensmodelle am Beispiel m Die Projekte erfordern ein unterschiedliches Durchlaufen der Phasen Analyse L Definition i Entwurf N Implementier ung und Test Projekt A N ein Durchlauf Abnahme alles sofort vollst ndig N Betrieb und Evaluation Analyse des Teilsystems Analyse des Teilsystems Def des Teilsystems y i Entwurf des Teilsystems p Implement
144. inal ist zur Entwicklung solcher Projekte nicht geeignet gt Wir ben tigen andere Vorgehensweisen als f r das Programmieren einer kleinen Anwendung gt Wie kann man ingenieurm ig Software entwickeln SWE Prof Dr W Weber h_da Fachbereich Informatik 13 2 Grundlagen des Software Engineering Begriffsklarung Was ist Software m Software Enges Verst ndnis unter Software subsumiert man alle immateriellen Teile d h alle auf einer Datenverarbeitungsanlage einsetzbaren Programme Lexikon der Informatik und Datenverarbeitung H J Schneider Hrsg 1986 Mittleres Verst ndnis Software engl eigtl weiche Ware Abk SW Sammelbezeichnung f r Programme die f r den Betrieb von Rechensystemen zur Verf gung stehen einschl der zugeh rigen Dokumentation Brockhaus Enzyklop die Weites Verst ndnis Unser Verst ndnis Software Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten die f r ihre Anwendung notwendig oder hilfreich sind Ein Begriffssystem f r die Softwaretechnik W Hesse et al 1984 Software Computer programs procedures rules and possibly associated documentation and data pertaining to the operation of a computer system IEEE Standard Glossary of Software Engineering Terminology ANSI 1983 SWE Prof Dr W Weber h_da Fachbereich Informatik 14 2 Grundlagen des Software Engineering Was ist Software Engineering 1 m
145. ingabefehler k nnen in jedem Wert auftreten gt Totaler Test m glich gt Teste jeden einzelnen Wert bis zur maximalen Gr e oe SWE Prof Dr W Weber h_da Fachbereich Informatik 071 ry ey aN SWE Prof Dr W Weber h_da Fachbereich Informatik 8 1 1 Black Box Test Spezifikation Beispiel Fakult t L sung bei Eingabe Ausgabe Integer m Aquivalenzklassen gt g ltige Klassen 0 9 0 1 J1 12 2 gt ung ltige Klassen nicht ganze Zahlen 13 hen gt Testf lle 5 1 0 1 5 120 1 5 UNDEF 13 UNDEF Er m nach der Methode der Grenzwertanalyse gt Testf lle 1 1 0 1 1 1 2 2 12 479001600 13 UNDEF bei Eingabewert kann nat rlich nur maximal MAX_INT MAX_INT eingegeben werden gt Grenzwert 212 Spezifikati 8 1 1 Black Box Test K i a Black Box Test Beispiel Suchen in Liste po Zu testende Funktion void suche int Wert int amp Nr_des_Elementes in der Klasse Liste in der Klasse Liste Eingabewert Integer Wert Eingabezustand Liste Ausgaben Nr des gefundenen Elements int Falls nicht gefunden 1 class Liste L void suche int Eingabe int amp Nr_des_Elementes void anfuege int Element Welche Aquivalenzklassen abh ngig von welchen Werten Welche Testf lle Wie sieht das Testprogramm aus ie SWE Prof Dr W Weber h_da Fachbereich Informatik 273 8 1 1 Black Box Test ak Black B
146. ion Wie findet man Fehler m Entwicklertests gt sollen zeigen dass das Programm funktioniert demonstratives Testen gt berpr fen die Funktion der Software auf Korrektheit im normalen Betrieb gt werden vom Entwickler freiwillig durchgef hrt gt das kennen Sie in beschr nktem Umfang aus Ihrer Entwicklert tigkeit m Robustheitstests gt berpr fen die Funktion der Software auf Korrektheit am Rande bzw au erhalb des normalen Betriebs gt werden oft von einem speziellen Test Team durchgef hrt gt versuchen systematisch Fehler aufzudecken destruktives Testen gt das kennen Sie in beschr nktem Umfang von der Praktikumsabnahme in Programmieren SWE Prof Dr W Weber h_da Fachbereich Informatik 250 E 3 Test und Integration Grundidee Testen m Ein Test fall zu einem Fehler erzeugt ein vom Soll Ergebnis abweichendes Ergebnis wenn der Fehler vorliegt Frage Wie finde ich Soll Ergebnis gt Falls Ist Ergebnis Soll Ergebnis gt dieser Testfall ist richtig abgelaufen und der Fehler liegt nicht vor gt Falls Ist Ergebnis Soll Ergebnis gt es liegt mindestens ein Fehler vor Teste alle m glichen 2 Eingabekombinationen Frage Was halten Sie von diesem Konzept Ist das m glich SWE Prof Dr W Weber h_da Fachbereich Informatik 254 u E 3 Test und Integration Grenze des Testens Frage Zeit fur Test eines Multiplizier Verfahrens fur 2 Zahlen a 32 Bit 0 1
147. ion en des Moduls aufrufen und mit Parametern versorgen Bildschirmeingaben definieren oder durch Umleitung des Streams automatisch einspielen Ergebnisse entgegennehmen Ergebnisse Ausgabeparameter Bildschirmausgaben und Ausgangszust nde Datenbank Datei Klassenattribute globale Variablen pr fen bzw den Benutzer bei der Pr fung unterst tzen System in Zustand vor dem Test zur ckversetzen m Stubs sind Testfunktionen die gt das Antwort Verhalten einer echten aufgerufenen Funktion mehr oder weniger simulieren Parameter von der zu testenden Funktion entgegennehmen Ergebnisparameter die evil falsche Werte besitzen k nnen nach oben zur ckgeben SWE Prof Dr W Weber h_da Fachbereich Informatik 295 8 2 Modultest Besonderheiten beim Modultest m Test von Funktionen in Klassen gt Instanziieren von Klasseninstanzen gt Eine Funktion hat evtl auch Attribute von Klasseninstanzen als Eingabe oder Ausgabezust nde gt Beim Test ber cksichtigen m Aufrufhierarchien von mehreren Funktionen gt Es werden einzeln getestete Funktionen zu Aufrufhierarchien auch ber Klassengrenzen hinweg zusammengef hrt innerhalb einer Klasseninstanz Teil des Klassentests ber Klasseninstanzgrenzen hinweg Hier k nnen Attributwerte der anderen Klasseninstanzen auch Ein Ausgabezust nde sein SWE Prof Dr W Weber h_da Fachbereich Informatik 296 E 8 2 Modultest Modultest m Was i
148. ionstest des gesamten Systems Dokumentation ist anzupassen m Qualit tssichernde Ma nahmen z B Reviews und Codeinspektionen gt pr fen die Phasen Ergebnisse gt und evil auch innerhalb der Phasen an so genannten Meilensteinen anfallende Zwischenergebnisse SWE Prof Dr W Weber h_da Fachbereich Informatik 49 2 Grundlagen des Software Engineering Kontrollfragen Geh ren Dokumentation und Skizzen auch zur Software Was war die Software Krise Was ist strukturierte Programmierung Was ist schrittweise Verfeinerung Was ist Qualitat von Software Was ist das magische Dreieck Was passiert in der Phase Betrieb Diskussion Warum verkauft sich Software mit Fehlern trotzdem eee SWE Prof Dr W Weber h_da Fachbereich Informatik il Ho 50 Hochschule Darmstadt Fachbereich Informatik software Engineering 3 Anforderungsanalyse h da sa i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 51 3 Anforderungsanalyse How the customer was billed How the project was documented What operations installed How it was supported What the customer really needed SWE Prof Dr W Weber h_da Fachbereich Informatik 3 Anforderungsanalyse Phasenmodell Zur Erinnerung V Modell nas Anwendungsszenarien Testf lle ee EEE E N T E E 2 u estf lle
149. it formeller Protokollierung SWE Prof Dr W Weber h_da Fachbereich Informatik 73 4 Abnahmetest FURPS Modell m Was muss getestet werden gt F Eunctonality Funktionalit t gt U Usability Benutzbarkeit gt R Reliability Zuverl ssigkeit gt P Performance Leistung gt S Supportability Wartbarkeit m Funktionstests gt berpr fung auf korrekte Funktion des Systems m Benutzbarkeitstests gt berpr fung der Bedienoberfl che durch Endanwender gt Intuitive Bedienung Lesbarkeit Reaktivit t SWE Prof Dr W Weber h_da Fachbereich Informatik 74 4 Abnahmetest Tests RPS m Zuverlassigkeitstests gt Zuverl ssigkeit Max Anzahl der Abst rze Fehlfunktionen in Zeitintervall T gt Beim Funktionstest bekommt man auch Hinweise auf die Zuverl ssigkeit gt Eigentlicher Zuverlassigkeitstest erst im Einsatz mM Leistungstests gt berpr fung der Nichtfunktionalen Anforderungen zu Performance Zeitvorgaben d h berpr fung der Schnelligkeit durch berpr fung der Zeitvorgaben P Robustheit Belastungs oder Stresstest d h Funktionstests auch bei maximaler Last maximaler Durchsatz hohem Datenaufkommen etc m Wartbarkeitstest gt berpr fung von Code und Dokumentation auf Verst ndlichkeit gt z B durch Anwendung von Metriken sp ter in der Vorlesung SWE Prof Dr W Weber h_da Fachbereich Informatik 75 4 Abnahmetest Tests Funk
150. l 8 3 Anforderungsanalyse Versteckte Anforderungen m Nur wenige Menschen werden Ihnen sofort Anforderungen nennen gt Oft erhalten Sie L sungsvorschl ge gt es gibt meist viele versteckte Anforderungen Ihre Aufgabe ist es diese Anforderungen herauszufinden Es gibt oft versteckte Hinweise auf Anforderungen in Dokumenten und Pr sentationen schauen bzw h ren Sie genau hin information hiweiszs at O O OOS SWE Prof Dr W Weber h_da Fachbereich Informatik 59 3 Anforderungsanalyse Ubung CocktailPro I Firmenprasentation Cocktail4U m Cocktail4U GmbH gt 5 Mitarbeiter gt 100 Tochter der DfF GmbH Dosierer f r Fertigungsstra en automatisierte Dosierer Waagen Mischer uvm Einsatz in Brauereien Konditoreien Lebensmittelverpackung m Gesch ftsidee Cocktail4U CocktailPro gt Wandger t f r Kneipen und Bars ocktailPro gt hochwertige Cocktails auf Knopfdruck B Bzombie m Situation Bez gt DfF hat die Dosierer Waage etc a gt es fehlt nur noch die Steuer und Kontrolleinheit gt Cocktail4U beauftragt die Entwicklung bei IHNEN il er SWE Prof Dr W Weber h_da Fachbereich Informatik 60 El 3 Anforderungsanalyse Ubung CocktailPro II Lastenheft CocktailPro Cocktail4U GmbH Zielbestimmung und Zielgruppen l a Produktperspektive Standardausstattung in der Gastronomie l b Einsatzkontext Cocktailbar Restaurant Kneipe Funktionale Anforderun
151. l st werden gt Falls transitive Beziehungen nicht vermeidbar sind m ssen Widerspr che ber Constraints ausgeschlossen werden z B Kunde der Bestellung muss gleich sein dem Kunden des Auftrags aT fy vas senteoamnenor SWE Prof Dr W Weber h_da Fachbereich Informatik 184 6 2 Regeln zum Entwurf von Klassen Aufgabe 4 m Es soll ein Customer Relation Management CRM f r einen Reiseveranstalter entworfen werden Modellieren Sie folgenden Sachverhalt gt Reisende k nnen viele Reisen buchen d h Reiseauftr ge erteilen gt Ein Reiseauftrag kann mehrere Reisende umfassen m Pr fen Sie wie der folgende naheliegende Punkt mit Ihrer L sung umgesetzt werden kann gt Das System soll in der Wartungsphase so umgebaut werden dass zus tzlich der Status eines Visa f r jede Reise und jeden Reisenden erfasst werden kann SWE Prof Dr W Weber h_da Fachbereich Informatik 185 6 2 Regeln zum Entwurf von Klassen Losung A m n Beziehungen a m Ps Class Diagram CRM mit m n Beziehungen Object Diagram CRM mit m n Beziehungen _ Huber Kunde Mallorca Reiseauftrag Reisender Indien Reiseauftrag Mayer Kunde Russland Reiseauftrag HuberNachlndien Reisevoraussetzun Reiseauftrag Ein Visum ist abh ngig vom Reisenden und vom Reiseziel Der Zustand muss in einer Assoziationsklasse abgespeichert werden Das erfordert allerdings in der Realisierung eine neu
152. lichen Algorithmen in einer Klasse fest zu codieren gt Jeder Algorithmus wird als Strategie in einer Klasse gekapselt und ist ber eine abstrakte Superklasse die eine geeignete Schnittstelle zur Verf gung stellt anwendbar SWE Prof Dr W Weber h_da Fachbereich Informatik 200 e 6 3 Entwurfsmuster Das Strategie Muster Eigenschaften Il m Anwendbarkeit gt Viele verwandte Algorithmen unterscheiden sich nur in ihrem inneren Verhalten gt Unterschiedliche Varianten eines Algorithmus werden ben tigt z B mit unterschiedlichen Vor und Nachteilen bzgl der Geschwindigkeit und des Speicherplatzverbrauchs gt Daten die f r den Algorithmus relevant sind aber dem Aufrufer nicht bekannt sein sollen k nnen in einer Strategie verborgen werden SWE Prof Dr W Weber h_da Fachbereich Informatik 201 6 3 Entwurfsmuster Diskussion Strategie Muster m Vorteile beim Einsatz des Strategie Musters gt Strategien k nnen leicht hinzugef gt oder entfernt werden gt Der Aufruf wird nicht komplizierter blo weil es verschiedene Strategien gibt m Nachteile gt Die Implementierung ist etwas schwieriger m Diskussion gt Ein Navigationssystem bietet Ihnen die sch nste Route die schnellste Route oder auch die k rzeste Route Wie w rden Sie dies als Strategiemuster umsetzen gt Sie implementieren eine Klasse die Daten sortiert Vorerst implementieren Sie aber nur Bubblesort und wollen dies sp
153. lit tsmerkmale aus SWE Prof Dr W Weber h_da Fachbereich Informatik SW Effizienz Performance NO 8 2 1 Grundlagen des Software Engineering Softwarequalit t Softwarequalit tseigenschaften Beispiele m Funktionserfullung geplantes System tats chlich realisierter Funktionsumfang m Effizienz gt Hohe Ablaufgeschwindigkeit Performanz gt wenig HW Ressourcenverbrauch z B geringer Speicherplatzbedarf HW wird immer billiger gt verliert immer mehr an Bedeutung Aber immer noch wichtig bei hohen St ckzahlen z B bei embedded Systems gt Schnelle Algorithmen SWE Prof Dr W Weber h_da Fachbereich Informatik 29 2 1 Grundlagen des Software Engineering Softwarequalitat Softwarequalitats eigenschaften Bedeutung m Die Umsetzung von Qualit tseigenschaften verursacht erhebliche Aufwande gt nachtr gliche nderungen von nicht eingeplanten Qualit tseigenschaften sind in der Regel sehr aufw ndig gt Qualitatseigenschaften sind nicht unabh ngig voneinander Werden Ma nahmen zur Verbesserung einer Qualit tseigenschaft getroffen so wirken sich diese m glicherweise auf andere Qualit tseigenschaften negativ aus m Beispiel gt Wird die Effizienz verbessert kann dies ein unzuverl ssigeres System ergeben die Robustheit kann sinken das System kann schwerer nderbar sein weil die Effizienzsteigerung z B durch Assemblereinsatz erreicht wurde gt Hardwarenahe
154. litatssicherung Produktqualitat Konstruktive Qualitatssicherung m Es wird versucht das Entstehen von Qualit tsm ngeln bereits w hrend der Entwicklung Konstruktion des Produkts zu verhindern gt Beseitige bei entdeckten M ngeln nicht nur den Mangel selbst sondern auch seine Ursache n gt Gestalte den Entwicklungsprozess so dass Qualit tsm ngel seltener werden m Dazu werden w hrend der Entwicklung geeignete Ma nahmen eingesetzt gt bew hrte Methoden Techniken Konstruktionsprinzipien UML Pair Programming Test First OO Entwurf 4 Schichten Architektur gt formale Verfahren formale Spezifikation gt Werkzeuge Case Tool IDE gt Vorgehensmodelle und Vorgehensrichtlinien Wasserfallmodell V Modell Einsatz von Prototypen Coding Guidelines SWE Prof Dr W Weber h_da Fachbereich Informatik 350 gt 9 Qualitatssicherung Produktqualitat Analytische Qualitatssicherung m Es wird versucht entstandene Fehler zu entdecken und zu beseitigen indem die vorliegenden Teile des Produkts analysiert werden gt Untersuche Teil Produkte nach ihrer Fertigstellung auf Qualit t gt Bessere nach wo M ngel auftreten m In der analytischen Qualit tssicherung unterscheidet man gt dynamische Ma nahmen welche die laufende Software untersuchen Tests Performancetests Robustheitstests Test berdeckungen usw vgl Kap Test gt statische Ma nahmen die eingesetzt werden
155. lle zur Bewertung von Software Entwickungsprozessen h da sss i ii HOCHSCHULE DARMSTADT u EHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 438 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen Lernziel Vorgehensmodelle m Sie sollen in diesen Kapitel lernen gt wie man im Modell SPICE vorgeht um die G te von Software Entwickungsprozessen zu bewerten gt was die Unterschiede zu CMMI sind CMMI ist ein anderes Model zur Bewertung von SW Entwicklungsprozessen gt was die Unterschiede zu V Modell XT bzw RUP sind JJ EEE SWE Prof Dr W Weber h_da Fachbereich Informatik 439 I N 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen Einf hrung Jedem hier ist klar Projekt Seit dem es Computer gibt m scheitern SW Projekte mM zugesagte Termine werden nicht eingehalten fc m kalkulierte Kosten werden berschritten m die Qualit t der SW ist viel geringer als erwartet gt Wir brauchen einen klar strukturierten SW Entwicklungsprozess gt Wir m ssen bewerten k nnen wie gut man die durchzuf hrenden Aufgaben mit dem eingesetzten SW Entwicklungsprozess l sen kann oO gt Yu SWE Prof Dr W Weber h_da Fachbereich Informatik 440 m h da 11 1 Modelle zur Bewertung von Software Entwickungsprozessen Prozess Bewertungs Modell SW Entwicklungsprozess Modelle und Projekte Mess
156. n gt Bei Hinzuf gung einer konkreten Strategie keine nderung im Kontext TextVerarbeitung kleine nderung bei der Instanziierung und bergabe der Strategieklasse m Beispielcode mit und ohne Strategieobjekt ta void TextVerarbeitung Repariere switch _umbruchStrategie case EinfacheStrategie FormatiereMitEinfacherStrategie break void TextVerarbeitung Repariere case TeXStrategie FormatiereMitTeXStrategie break ae mein_formatierer gt Formatiere gt SWE Prof Dr W Weber h_da Fachbereich Informatik 196 6 3 Entwurfsmuster Das Strategie Muster Beispielcode fur die Absatzformatierung 1 class TextVerarbeitung class Formatierer public virtual int Formatiere 0 public Hier wird die s re TextVerarbeitung Formatierer gew nschte oeda void Repariere _ Seh ao Vorbereitung der bergabeparameter bergeben i der Formatiere Funktion mein_formatierer gt Formatiere Darstellung gem der vom Formatierer berechneten und zur ck gelieferten Daten ee private Formatierer mein_formatierer class ArrayFormatierer public Formatierer public ArrayFormatierer int breite virtual int Formatiere SWE Prof Dr W Weber h_da Fachbereich Informatik 197 6 3 Entwurfsmuster Das Strategie Muster Beispielcode f r die Absatzformatierung 2 Instan
157. n Aspekte gt Beschr nke Dich auf das f r das System Notwendige m Regeln zum Entwurf von Operationen und Schnittstellen Operationen sind unabh ngig von der verwendeten Technologie gt Gib keine Referenzen nach au en gt Normalisiere die Schnittstelle Mache die Operationen grobgranular Mache die Operationen idempotent Mache die Operationen kontextfrei SWE Prof Dr W Weber h_da Fachbereich Informatik E 6 Design Zur Erinnerung aus OOAD Regeln fur ein gutes Design Ill m Es gibt weitere Prinzipien bzw diverse Varianten dieser Prinzipien gt die Kernaussage bzw Zielrichtung ist allerdings seit vielen Jahren unumstritten m Diese Grundprinzipien sind anwendbar gt f r implementierungsnahen Entwurf Feinentwurf gt aber auch f r den Entwurf von Anwendungen auf h herer Abstraktionsebene Software Architektur bis hin zu Anwendungslandschaften il eee SWE Prof Dr W Weber h_da Fachbereich Informatik 158 E amp Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 6 1 Wiederholung f r die die nochmals nachschauen wollen Grundprinzipien f r das Design h da ssn i iii HOCHSCHULE DARMSTADT Hii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 159 il Sr SWE Prof Dr W Weber h_da Fachbereich Informatik 6 1 Grundprinzipien fur das Design Idee fur das 1 Grundprinzip
158. n Entwurf kennen Sie Erkennen Sie in Ihrem Praktikumsentwurf von SWE Teile des Blob Warum sollte man Design Patterns verwenden Wozu sind Anti Patterns gut Woran erkennen Sie ein Design Muster bei Ihrer Arbeit Wann setzen Sie das Strategiemuster ein Erkl ren Sie die Funktionsweise Warum kann man Strategien nicht einfach als Vererbung umsetzen Woher wissen Sie welche Klassen und Operationen ihr Entwurf enthalten sollte PER SWE Prof Dr W Weber h_da Fachbereich Informatik 034 Hochschule Darmstadt Fachbereich Informatik software Engineering 7 Implementierung h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 235 e Zn 7 Implementierung Einordnung im V Modell Anwendungsszenarien as Ter Testfalle ie u estt lle Integrations test LL l eSt mentierung f lle SWE Prof Dr W Weber h_da Fachbereich Informatik 236 E 7 Implementierung Lernziel Implementierung m Sie sollen in diesen Kapitel verstehen gt wo der Unterschied zwischen Implementierung in Programmieren amp II und Implementierung in OOAD amp SWE liegt gt was Programmierrichtlinien festlegen gt warum Programmierrichtlinien wichtig sind gt warum Programmierrichtlinien unbeliebt sind il eee SWE Prof Dr W Weber h_da Fachbereich Informatik 237 E 7 Implementierung Implem
159. n Klassen Testf lle so ausw hlen dass folgendes gilt m Aktivit tentest Aktivit ten berdeckung gt Jeder Kasten des Aktivit tsdiagramms wird 1 Mal durchlaufen gt So viel Durchl ufe dass jeder Kasten mind 1 Mal durchlaufen wird Frage wie oft muss ich den obigen Use Case durchlaufen m Zweigtesten gt Jeder der Zweige des Aktivitatendiagramms wird mindestens ein Mal durchlaufen gt d h jeder Pfeil im Aktivit tsdiagramm wird mindestens ein Mal durchlaufen gt Jeder Durchlauf ist ein Testfall Frage wie oft muss ich den obigen Use Case durchlaufen SWE Prof Dr W Weber h_da Fachbereich Informatik 81 E 4 Abnahmetest Beispiel Ableiten von Funktionstests V Aktivitatsdiagramm Zweiggraph O Aufforderung PIN Eingabe gt Kundenreaktion keine Eingabe f r 30 Sek Kunde bricht ab PIN Eingabe erfolgt PIN falsch und en lt 3 Fehlversuche PIN Validierung Co PIN falsch und PIN als richtig gt 3 Fehlversuche validiert System gibt Zugang frei Abbruch SWE Prof Dr W Weber h_da Fachbereich Informatik 82 4 Abnahmetest Ableiten von Funktionstests VI Zweigtesten Eingabe Soll Zwischenergebnisse Soll Ergebnis keine Eingabe f r 30 Sek Abbruch Abbruch Taste gedr ckt Abbruch richtige PIN eingegeben Zugang frei 3x falsche PIN eingegeben 2 Mal Aufforderung der erneuten PIN Eingabe Abbruch Frage Ist dies ein Testplan Wie w rde ein Testplan auss
160. n und Navigationsrichtungen eintragen SWE Prof Dr W Weber h_da Fachbereich Informatik 172 6 2 Regeln zum Entwurf von Klassen Entwurf von Klassen m Bisher kennen Sie ein Standardverfahren zur Bestimmung von Klassen und den Beziehungen dazwischen gt es geht darum die Klassen so zu entwerfen dass die Qualit tsanforderungen m glichst gut erf llt werden gt aber es gibt immer viele verschiedene L sungen mit unterschiedlichen Eigenschaften welche die Qualit tseigenschaften mehr oder weniger gut erf llen m Wir betrachten nun einige Beispiele und gt erarbeiten jeweils eine naheliegende L sung gt analysieren die Nachteile dieser L sung gt diskutieren eine zweite L sung welche die Nachteile nicht hat gt leiten daraus eine Regel f r den Entwurf von Klassen ab SWE Prof Dr W Weber h_da Fachbereich Informatik 173 6 2 Regeln zum Entwurf von Klassen Aufgabe 1 m Modellieren Sie folgenden Sachverhalt gt Ein Softwaresystem f r eine Firma soll Kunden Lieferanten und Mitarbeiter verwalten gt Alle werden durch Name und Adresse identifiziert gt Ein Mitarbeiter ist entweder Arbeiter oder Manager m Pr fen Sie wie die folgenden naheliegenden Punkte mit Ihrer L sung umgesetzt werden k nnen gt Kunden k nnen gleichzeitig auch Lieferanten sein gt Arbeiter k nnen zu Managern bef rdert werden gt In Zukunft k nnen auch weitere Personen wie Gesellschafter etc aber auch weitere Laufb
161. nd erw nschten Systemeigenschaften gt Kunde Erweiterungsf higkeit Integrationsf higkeit Zuverl ssigkeit Robustheit Fehlertoleranz gt Intern Wartungsfreundlichkeit Erweiterungsf higkeit Portabilit t SWE Prof Dr W Weber h_da Fachbereich Informatik 315 m 8 4 Systemtest Abnahmetest Test Gesamtplanung m Erstellung der Montage und Testplanung Erstellung der Testf lle erfolgt bereits an den jeweiligen Phasenenden V Modell SWE Prof Dr W Weber h_da Fachbereich Informatik 316 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 5 Beispiel Modul Integrationstest h da san i ii HOCHSCHULE DARMSTADT an ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 317 E 8 5 Beispiel Modul Integrationstest Beispiel Modultest Beobachtermuster Observer Pattern dieWaage dasDisplay derDosierer nn KonkreterBeobachter KonkreterBeobachter aktiviere Interaktionen DE erhoehe_gewichte benachrichtige out delta_gewicht r Aufgabe Leiten Sie SWE Prof Dr W Weber h_da Fachbereich Informatik die Aufrufhierarchje ab e 8 5 Beispiel Modul Integrationstest Beispiel Modultest Beobachtermuster Observer Pattern Es sollen folgende Funktionen getestet werden m getdelta gewicht von Waage Stubs nicht erforderlich m vergleicheGewicht von Dosierer Stu
162. nen Wert pro Zweig sondern die Grenzwerte gt Werte die falls sie etwas gr er bzw kleiner w ren den Ablauf in den anderen Zweig steuern w rden R nder von Schleifen SWE Prof Dr W Weber h_da Fachbereich Informatik 287 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 1 3 Testdurchf hrung h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 288 E 8 1 3 Testdurchf hrung Allgemeine Strategie 1 Testf lle nach Black Box Test suchen 2 Wenn m glich erg nzende Testfalle nach White Box Test suchen nach Zweig berdeckung evtl zus tzliche Testf lle gem Bedingungs berdeckung evtl teilweise Pfad berdeckung 3 Zus tzlich intuitive Testfalle suchen m Testziel gt Ziel ist es so viele Fehler wie m glich zu finden und nicht die Fehlerfreiheit nachzuweisen gt psychologischer Grund Pr fer muss motiviert werden Fehler zu finden k i SR SWE Prof Dr W Weber h_da Fachbereich Informatik 8 1 3 Testdurchfuhrung Ablage von Testdaten m Tests m ssen reproduzierbar sein gt die Funktion muss erneut getestet werden k nnen z B nach einer Programm nderung Eingabe und Ausgabedaten m ssen aufgehoben werden m Ablage und Testautomatisierung mit Hilfe von Testwerkzeugen gt Bei Erstellung des Testplans Ein Ausgabedaten und Vor N
163. nforderungsanalyse so schwierig Welche Arten von Anforderungen gibt es Welche Dokumente geh ren zu einer Anforderungs Spezifikation Welche Methode eignet sich zur Dokumentation von funktionalen Anforderungen Was geschieht wenn man ein Projekt ohne aufw ndige Anforderungsanalyse angeht angehen muss il a SWE Prof Dr W Weber h_da Fachbereich Informatik 69 Hochschule Darmstadt Fachbereich Informatik software Engineering 4 Aonahmetest h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 70 4 Abnahmetest V Modell Testfalle a T Systemtest AS i LL aa ae Integrations test a LL 35 og Aa 35 So Qo an T 2 SWE Prof Dr W Weber h_da Fachbereich Informatik 71 4 Abnahmetest Lernziel Abnahmetest m Sie sollen in diesem Kapitel verstehen gt Was ein Abnahmetest ist gt Warum ein Abnahmetest wichtig ist gt Wie man Testf lle f r die Abnahme findet All ee SWE Prof Dr W Weber h_da Fachbereich Informatik 72 4 Abnahmetest Was ist ein Abnahmetest und wie fuhre ich ihn durch m Was ist ein Abnahmetest gt Pr fung ob erstelltes System spezifiziertes System gt die Abnahmetests sind Bestandteil des Vertrags Nach erfolgreicher Abnahme wird bezahlt m Wie f hre ich einen Abnahmetest durch gt Zusammen mit dem Auftraggeber gt M
164. ng Implementierung Integration und Tests m Implementierung und Test gt kennen Sie schon aus der Lehrveranstaltung Programmieren gt Zumindest kleine Programme wurden von Ihnen implementiert und grob getestet E Komponenetentest Integration und Integrationstest bei gro en Systemen gt Bei gro en Systemen kann man das System nicht als Ganzes implementieren und testen gt implementiere und teste zuerst die einzelnen Module Funktionen bzw Komponenten Funktionen bzw Komponententest gt montiere anschlie end diese getesteten Module schrittweise zusammen Integration und teste sie Integrationstest Systemtest Vor Beginn der eigentlichen Codierung Es wird entschieden in welcher Reihenfolge die Komponenten implementiert und zusammengebaut werden z B Top Down oder Bottom Up Vorgehensweise Detaillierte Testpl ne f r die einzelnen Funktionen Komponenten f r die Teilsysteme und das Gesamtsystem sind falls nicht schon in vorhergehenden Phasen geschehen zu erstellen SWE Prof Dr W Weber h_da Fachbereich Informatik 41 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Abnahme m Abnahme gt Kennen Sie schon aus dem Programmierpraktikum gt Es wird gepr ft Stimmen die Leistungen des Systems mit den in der Spezifikation vereinbarten Leistungen berein Abnahmetest Ein Abnahmetest f r ein gro es System muss systematisch geplant werden und ist wesentlich au
165. ng und Bedarsdeckung in der Bundeswehr CPM i 423 11 Vorgehens und Prozessmodelle V Modell XT Vorgehensbausteine Entscheidungspunkte Verpflichtende Vorgehensbausteine Optionale Vorgehensbausteine Entscheidungspunkte Inkrementelle Systementwicklung AN Wartung und Pflege von Systemen AN i aaa AN Komponentenbasierte Systementwicklung AN Agile Systementwicklung AN Projektmanagement Projekt genehmigt V Modell Kern BE Qualit tssicherung Messung und Analyse Projekt definiert Konfigurationsmanagement Kaufm nnisches Projektmanagement Iteration geplant Problem und nderungsmanagement Projekt abgeschlossen Schnittstelle Lieferung und Abnahme AN Lieferung und Abnahme AG Auftraggeber Vertragsschluss AN Vertragsschluss AG SWE Prof Dr W Weber h_da Fachbereich Informatik 424 11 Vorgehens und Prozessmodelle Agile Softwareentwicklung m Gegenbewegung zu den oft als schwergewichtig und b rokratisch angesehenen Softwareentwicklungsprozessen wie RUP oder V Modell m Idee Schnell eine einsetzbare Software ausliefern und inkrementell in kurzen Zyklen in engem Kontakt mit dem Kunden ausbauen m Agile Werte bilden das Fundament der Agilen Softwareentwicklung gt Offenheit und Kommunikation statt Formalismen m Die Grundprinzipien der agilen SW Entwicklung agiles Manifest Beck stellen e Individuen und Interaktion ber e Prozesse und Werkzeuge e Lauff hige Software ber
166. nkes Fenster im Case Tool des Praktikums gt Unter Anforderungsanalyse F r jedes Use Case Diagramm ein Unter Paket gt Unter Design Aufteilen der Klassen des Klassendiagramms auf versch Pakete Eine Generalisierungshierarchie befindet sich normalerweise in einem Paket gt Unter Implementierung mehreren Pakete getrennte Name spaces f r den Code SWE Prof Dr W Weber h_da Fachbereich Informatik 424 5 2 Paketdiagramme in der UML 53203 Paket Sicht gem s umL siehe Vorl 00AD w weben Dom nen Sicht Logische Architektur a Praktikum OOAD Abn ngigkeit Implementierung Hierarchie von Paketen dargestellt durch Schachtelung import Das Quellpaket Paket bei dem Pfeil beginnt kann auf alle public Elemente des Zielpaketes ohne Qualifizierung Zielpaket zugreifen gt Programmier Vorl Paket std SWE Prof Dr W Weber h_da Fachbereich Informatik 122 5 2 Paketdiagramme in der UML Paket Sicht Dom nen Sicht Logische Architekturin aniennung an Douglassos i P i mY m Beispiel mit ie Darstellung en Alarm Domain der Klassen I N und deren j Beziehungen in den Paketen Text List Hold classes N and types for User Interface Hold classes and N types that represent hardware SWE Prof Dr W Weber h_da Fachbereich Informatik 123 5 2 Darstellung der Architektur Physikalische Architektur a aco m Physikalische Archit
167. nnen Messungen fur Last und Performancetests Profiling durchgef hrt werden gt k nnen leere Rahmen f r zu schreibende Testklassen erzeugt werden EI ai m Es gibt neben den Unit Tests weitere Testwerkzeuge gt f r die Verwaltung Planung und Automatisierung der Testdurchf hrung gt f r automatisierte GUI Tests gt zur Durchf hrung von statischen Tests die den Code nur analysieren aber nicht ausf hren gt uvm SWE Prof Dr W Weber h_da Fachbereich Informatik 343 E 8 Testund Integration Literatur zu Testen Balzert Helmut Lehrbuch der Softwaretechnik Softwaremanagement Softwarequalit tssicherung Unternehmensmodellierung Spektrum akademischer Verlag 1998 Vigenschow Uwe Objektorientiertes Testen und Testautomatisierung dpunkt Verlag 2005 Westphal Frank Testgetriebene Entwicklung mit JUnit amp FIT dpunkt Verlag 2006 K hler Der C C Projektbegleiter dpunkt Verlag 2007 http cppunit sourceforge net projects cppunit http sourceforge net apps mediawiki cppunit http cppunit sourceforge net doc lastest cppunit_cookbook html http www evocomp de tutorials tutorium cppunit howto tutorial cppunit html Jp poese omar SWE Prof Dr W Weber h_da Fachbereich Informatik 344 8 Test und Integration Kontrollfragen Test und Integration UI e l U g Wann ist ein Programm fehlerfrei Was bedeutet es wenn alle Tests fehlerfrei laufen Ist es normalerweise m glich alle m
168. odukts bestimmen gt Die Zuverl ssigkeit ist nur eine dieser Qualit tseigenschaften gt Die erforderliche Qualit t h ngt stark vom Projekt ab und wird auch oft von verschiedenen Beteiligten unterschiedlich gesehen aus Sicht der Entwicklerfirma soll das Produkt z B erweiterbar sein und wenig Wartungskosten verursachen aus Sicht des Anwenders soll es z B die gew nschten Funktionen bieten zuverl ssig und sicher sein gt Es gibt Qualit t im Sinn von Zuverl ssigkeit und Qualit t als Oberbegriff f r die gesammelten Qualit ts Eigenschaften eines Systems a a Software Engineering Prof Dr R Hahn Prof Dr W Weber WS 2013 h_da Fachbereich Informatik 32 Ei Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung h da u i iii HOCHSCHULE DARMSTADT EHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 33 E E2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Phasen der Softwareentwicklung m Was denken Sie Welche Phasen gibt es im SW Erstellungsprozess Welche Phasen kennen Sie schon SWE Prof Dr W Weber h_da Fachbereich Informatik 34 E 2 2 Grundlagen des Software Engineering Phasen der Softwareentwic klung Der Software Lebenszyklus Software Life Cycle Einf hrung Betrieb Analyse Abn
169. oftware Engineering 8 4 Systemtest Abnahmetest h da san ii HOCHSCHULE DARMSTADT an ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 307 8 4 Systemtest Abnahmetest Unterschied zwischen Systemtest und Abnahmetest Was ist ein Abnahmetest Was ist ein Systemtest gt die Abnahmetests sind Bestandteil des gt Test des integrierten Gesamtsystems Vertrags gt Alles was beim Abnahmetest getestet wird aber gt Nach erfolgreicher Abnahme wird bezahlt noch ausf hrlicher Wie f hre ich einen Abnahmetest durch Wie f hre ich einen Systemtest durch gt Zusammen mit dem Auftragsgeber in der gt ohne den Auftraggeber echten Zielumgebung mit Entwicklern und Qualit tssicherung in der echten gt Mit formeller Protokollierung Zielumgebung SWE Prof Dr W Weber h_da Fachbereich Informatik 308 8 4 Systemtest Abnahmetest Unterschied zwischen Systemtest und Abnahmetest Was wird in einem Abnahmetest getestet Was wird in einem Systemtest getestet gt Alles was spezifiziert wurde gt Funktionstests Leistungstests Benutzbarkeitstests gt Funktionstests v Robustheitstests Volumentests Stresstests evtl gt Leistungstests z B Antwortzeiten bei ausf hrlicher als beim Abnahmetest Normallast gt au erdem Sicherheit Zuverl ssigkeit Wartbarkeit gt Benutzbarkeitstests z B einheitliche Dokumentation Benutzerschnittstelle Help Bil
170. on gt Der Test ob mehrere Systemkomponenten fehlerfrei zusammen wirken hei t Integrationstest SWE Prof Dr W Weber h_da Fachbereich Informatik 299 HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES 8 3 Integrationstest Integrationstest die Idee m Ein komplexes System besteht aus sehr vielen Systemkomponenten die zu unterschiedlichen Zeitpunkten fertig werden m Das Lokalisieren von Fehlern in einem solchen System ist sehr schwer m Ich mache nderungen an nur wenigen Stellen gt neu entdeckte Fehler h ngen mit der letzten nderung zusammen gt Fehler k nnen aber durchaus auch in den alten Teilen liegen SWE Prof Dr W Weber h_da Fachbereich Informatik 300 E E g3 Integrationstest Inkrementelle Integration weiterer Testfall nach Testen von Testfall T1 T2 und T3 4 a Integration Komponente Teilsystem Testfolge 1 Testfolge 2 AuBerdem Sukzessives Ersetzen von Stubs und Drivers durch echte Module JJ Se a SWE Prof Dr W Weber h_da Fachbereich Informatik 301 8 3 Integrationstest Top Down Vorgehensweise m Zuerst Implementierung Montierung und Test der obersten Schicht gt die noch nicht hinzugef gten Funktionen werden durch Stubs simuliert gt sukzessives Ersetzen der darunter liegenden Stubs durch echte Funktionen Version 1 TOP Modul 1 STUB2 Modul3 Version 2
171. opaweit sieht man junge modebewusste M nner B ten Cardigans die jedoch nicht opahaft son dern ck und ein biss viele Teenager und Iwens uni Li die oft dicken wollig war menden ee ee rg t Kn pfen t t Rei verschl ssen Oft po Ren die Strickjacken tats chlich Be auf Sak kos und sind als Zweireiher gestaltet Der Ralph Lau ren Styleguide schreibt Pe Krawatte einen l ssigen sr Sa Se ea TE paces pt Look ihrem Getr nkeautomaten Foto Jaspersen
172. ox Test Beispiel Suchen in Liste po Zu testende Funktion void suche int Wert int amp Nr_des_Elementes in der Klasse Liste Welche quivalenzklassen abh ngig von welchen Werten Welche Testf lle Eingabe Listenl nge 1 Ein Wert in Liste U eingegebener Wert in Liste hier 6 Wert nicht in Liste hier 7 Listenl nge l nger als 1 hier Eintr ge in Liste 6 4 3 2 und Wert erstes Element der Folge hier Wert 6 Wert mittleres Element der Folge hier 2 Element Wert 4 Wert letztes Element der Folge hier Wert 2 Wert nicht in Folge hier Wert 10 Listenl nge 0 und Wert nicht in Liste hier 6 unabh ngig von Listenl nge Wert ein Character hier W SWE Prof Dr W Weber h_da Fachbereich Informatik 274 8 1 1 Black Box Test eae Black Box Test Beispiel Suchen in Liste Bu Zu testende Funktion void suche int Wert int amp Nr_des_Elementes in der Klasse Liste Wie sieht das Testprogramm aus Testprogramm zu Testfall 1 Liste dieListe dieListe anfuege 6 int Nr_des_Elementes dieListe suche 6 Nr_des_ Elementes if not Nr_ des Elementes cout lt lt Testfall 1 mit Fehler SWE Prof Dr W Weber h_da Fachbereich Informatik 275 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 1 2 White Box Test h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SW
173. r fr hzeitig ob das Ergebnis wartbar sein wird ob die versprochene Funktionalit t geboten wird ob der Code effizient l uft ob die Tests einfach erstellt werden k nnen ob das Projekt aus dem Ruder l uft EI 2 14 ob die Investition von ber 50 Mio Euro ein Erfolg wird I J ERR SWE Prof Dr W Weber h_da Fachbereich Informatik 357 10 Metriken Motivation Il m Situation gt SIE sind einer der 100 Mitarbeiter gt Sie entwickeln selbst ndig einen Teil m Woher wissen Sie vor dem Review ob Ihr Arbeitsergebnis gut genug ist ob Sie genug Kommentare haben ob Ihr Code erweiterbar ist ob Ihr Code wiederverwendbar ist ob Ihr Code testbar ist wo Sie Ihr Ergebnis noch verbessern sollten ee ee ee a ob Sie ein guter oder schlechter Entwickler sind a SWE Prof Dr W Weber h_da Fachbereich Informatik lla Ho 358 10 Metriken Lernziel Metriken m Sie sollen in diesen Kapitel lernen ca te 2 wozu Metriken gedacht sind was mit Metriken gemessen werden soll was mit Metriken tatsachlich gemessen wird welche Standard Metriken es gibt wie Tools den Umgang mit Metriken erleichtern wie Metriken sinnvoll in Projekten eingesetzt werden welche Gefahren Metriken bergen SWE Prof Dr W Weber h_da Fachbereich Informatik 359 E y 10 Metriken Was will man messen m Arbeitsfortschritt und Qualit tseigenschaften Funktionserf llung LEE N
174. rachtung von Varianten ohne Umsetzung 147 5 3 Zusammenfassung Software Architektur Auswirkungen von Fehlern in der SW Architektur m Falsche Requirements gt Untersch tzung der Bedeutung bersehen eines wichtigen Requirements Schwerwiegende nderungen in sp teren Phasen keine Wiederverwendung gt bersch tzung der Bedeutung Unn tige Arbeit und Kosten gt Falsche Gewichtung der Requirements gegeneinander Falsche Ausrichtung der Architektur Verfehlung des Projektziels m Fehler in der Struktur aus Komponenten und deren Beziehungen gt Ungeschickte Aufteilung bzw Festlegung der Verantwortlichkeiten Kleine nderungen haben gro e Auswirkung gt Zu grobe Struktur Keine ausreichenden Vorgaben f r die Entwicklung bersehen von Problemen gt Zu feine Struktur Ineffiziente Architektur Arbeit SWE Prof Dr W Weber h_da Fachbereich Informatik 148 E 5 3 Zusammenfassung Software Architektur Kontrollfragen zur Software Architektur Warum ist eine Software Architektur f r ein gro es Projekt wichtig Was passiert wenn die Bedeutung einer Anforderung untersch tzt wird Welche Aspekte des Entwurfs dr ckt man in der SW Architektur aus Wie wirkt sich die Verwendung eines Architektur Stils aus H ngt die SW Architektur von der Programmiersprache dem Betriebssystem ab Wie dokumentieren Sie eine SW Architektur il era SWE Prof Dr W Weber h_da Fachbereich Informatik 14
175. rdings k nnen die verschiedenen Arbeitsschritte zu einem Programmteil in unterschiedlichen Iterationen ablaufen s n chste Folie Im Gegensatz zu dem normale iterativ inkrementellen Ansatz k nnen sich hier die Zyklen berlappen d h der Folgezyklus beginnt bevor der Vorg ngerzyklus abgeschlossen ist Nicht nur die Ziele und Produkte der einzelnen Disziplinen sondern auch die Ziele und Produkte der Iterationen Meilensteine m ssen definiert sein und durch Reviews berpr ft werden SWE Prof Dr W Weber h_da Fachbereich Informatik 417 11 Vorgehens und Prozessmodelle V Modell XT mM Verbindliches Vorgehensmodell bei der Vergabe von Entwicklungsprojekten durch Bundesbeh rden m V Modell 1988 gt V Modell 97 1997 gt V Modell XT 2005 m XT extreme Tailorig gt kann durch Tailoring an unterschiedliche Projektarten angepasst werden m Es wird vom Staat ein rechnerunterst tztes Tailoringsystem angeboten m Die zugeschnittene Auspr gung des V Modell XT ist abh ngig von gt dem Projekttyp Projekt aus Auftragnehmer oder Auftraggeber Sicht gt weiteren Projektmerkmalen Fertigprodukt Projekt mit hohem Risiko gt der Projektdurchf hrungsstrategie inkrementelle Entwicklung komponentenbasierte Entwicklung agile Entwicklung Wartung gt ausgew hlten Entscheidungspunkten Meilensteine z B System spezifiziert und einer vorgeschlagenen Reihenfolge der Entscheidungsp
176. rds HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES SWE Prof Dr W Weber h_da Fachbereich Informatik 1 Einleitung Konkrete Gr nde f r die Notwendigkeit von Software Engineering m In komplexen Projekten kann und will eine Person nicht mehr alles wissen ist Aufgabenteilung erforderlich gibt es oft verteilte Entwicklung gibt es Wartungsverpflichtungen muss ein Budget realistisch abgesch tzt und dann eingehalten werden gibt es Mitarbeiterfluktuation w hrend der Laufzeit gibt es Qualit tsauflagen Intern oder vom Auftraggeber LEI EL EL m Software Engineering oder auch Software Technik gt bietet Methoden um damit umzugehen gt ist der einzige bekannte L sungsansatz f r komplexe Projekte gt wird in der industriellen SW Entwicklung von Informatikern erwartet SWE Prof Dr W Weber h_da Fachbereich Informatik BE Einleitung SWE im Projekt Auszug aire nats Ges RG Manager oe Controlling Projektleitung Durchf hrung von Ma nahmen Qualit tssicherung SWE Prof Dr W Weber h_da Fachbereich Informatik m mi Einleitung SWE im Projekt Auszug po Yy orgehen Kunde rag U 7 K Aiae er Mite gen lt UML gt _ SET ONE ae a a Manager Qualit t cx Controlling Ya C Prozesse gt aka Sy un a rn Projektleitung ug 9 Durchf hrung von Ma nahmen Prozesse gt SWE Prof
177. reich Informatik 338 SSS E 8 6 Testwerkzeuge C Unit mit TestSuite Erstellung und Registration in der TestFixture Finclude ss class ComplexNumberTest public CppUnit_NS CPPUNIT_TEST_SUITE ComplexNumberTest Se CPPUNIT_TEST testEquality CPPUNIT_TEST testAddition CPPUNIT_TEST_SUITE_END CPPUNIT_TEST_SUITE_REGISTRATION ComplexNumberTest oe SWE Prof Dr W Weber h_da Fachbereich Informatik H Hi ADT I UNIVERSITY OF APPLIED SCIENCES i i 339 8 6 Testwerkzeuge C Unit Der Testlauf m Zur Ausf hrung des Tests muss aus den Angaben in der Registry der Test erstellt und anschlie end ausgef hrt werden include int main CppUnit_NS TextUi TestRunner runner runner addTest CppUnit_NS TestFactoryRegistry getRegistry makeTest bool wasSuccessful runner run return wasSuccessful m m Framework gibt es noch Listener Resultcollectors und Outputter mit denen die Results des Tests gesammelt und bersichtlich ausgegeben werden k nnen SWE Prof Dr W Weber h_da Fachbereich Informatik 340 36 Testwerkzeuge Testen mit xUnit Das Ergebnis m In den Zusicherungen wird das Soll Ergebnis mit dem Ist Ergebnis verglichen Gibt es einen Unterschied erfolgt eine entsprechende Meldung gt Die Tests werden jedenfalls weiter ausgef hrt und nicht abgebrochen lt terminated gt Complex exe C C Local Application C Links SWE Dev
178. return dasRezeptbuch GetAnzahlRezepte int GetAnzahlRezeptschritte int NrRezept return dasRezeptbuch getRezept NrRezept gt getAnzahlRezeptschritte string GetNameRezept int NrRezept return dasRezeptbuch getRezept NrRezept gt getName string GetZutat int NrRezept int NrRezeptschritt return dasRezeptbuch getRezept NrRezept gt getRezeptschritt NrRezeptschritt gt getM_Zutat float GetMenge int NrRezept int NrRezeptschritt gt GetM Menge SWE Prof Dr W Weber h_da Fachbereich Informatik 482 m Nicht aktuelle Folien HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES SWE Prof Dr W Weber h_da Fachbereich Informatik 483 Cocktail Mischmaschine mar es in Portugal neben dem slowenischen entwickelt der neun verschiedene Cocktails Maribor re gr Buropas Bae mixt Die Rezepte f r Sex on the Beach de Chile Hongkong Orlando im US Staat oder Screwdriver sind auf kleinen Chip Florida sowie das australische Darwin Bei karten gespeichert die die Benutzer vor ein den L ndern ist das Top Ziel eine berra Leseger t halten m ssen Aus mehreren schung Uganda Es folgen Birma Myanmar Tanks mischt der Automat dann das richtige Burma und die Ukraine Verh ltnis von Schnaps S ften und ed STRICK SAKKO Die S cke ist das mit Grausen doch als Mietger t f r Partys neue Sakko behauptet die M Marc kommt die Maschine an O Polo und in der Tat Eu r
179. rgencyCall z B die gesamte Navigation im Vergleich zu einem Statusbar und sind auch nicht intuitiv angeordnet z B in Schichten f r Treiber Anwendungen usw Statusbar il ee SWE Prof Dr W Weber h_da Fachbereich Informatik It a 166 SEL 6 1 Grundprinzipien fur das Design amp Grundprinzip 4 Homogenitat N m Verwende hnliche Strukturierungsgr en innerhalb einer Strukturierungsebene gt entwerfe Systemteile innerhalb einer Strukturierungsebene z B Anwendungsschicht so dass die Gr e und Komplexit t ungef hr gleich ist gt verwende bei Bedarf mehrere jeweils homogene Strukturierungsebenen m l se hnliche Probleme mit hnlichen L sungen gt verwende bereits bekannte L sungen erneut sofern es keine wichtigen Gr nde f r eine andere L sung gibt m Vorteile der Homogenit t gt vermeidet unn tiges Neuerfinden von vorhandenen L sungen gt erleichtert die Entscheidungsfindung Jj a SWE Prof Dr W Weber h_da Fachbereich Informatik 167 ej f f 6 1 Grundprinzipien fur das Design Idee fur das 5 Grundprinzip Class Diagram CRM CustomerManager Die Verwaltung der Kunden erfolgt so dass dabei ist zu beachten Ss CustomerUser Dies muss so sein weil die Verwaltung der Kunden so erfolgt dass dabei ist zu beachten HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SC
180. rscheidung zum Aquivalenzklassentest gt Nicht irgendein Element aus der Aquivalenzklasse wird als Repr sentant ausgew hlt sondern ein oder mehrere Elemente so dass jeder Rand der quivalenzklasse getestet wird bez glich der Eingabewerte zust nde und Ausgabewerte zustande m Testf lle decken die Grenzwerte der quivalenzklassen ab gt Erh hung der Quote der gefundenen Fehler gt Nur sinnvoll wenn Elemente einer quivalenzklasse auf nat rliche Weise geordnet sind z B Tage aber nicht Zahlungsart SWE Prof Dr W Weber h_da Fachbereich Informatik 266 a E 7 f x Beispiel ver nderte Sinusfunktion _ 4 f x sin x f r 0 lt X lt 360 0 210 360 f x 1 fur x gt 360 1 Aquivalenzklassen gt Es gibt zwei g ltige Klassen von Eingaben 0 360 360 Es gibt zwei Klassen von ung ltigen Eingaben 07 Eingaben float gt Teste einen Vertreter in jeder Klasse 1 180 370 a 2 Grenzwerte gt Eingaben zu Eingabegrenzwerten 0 360 360 0001 0 0001 evtl auch gr te kleinste darstellbare Zahl abh v Rechner Ergebnis auch noch im g ltigen Zahlenbereich gt Eingaben zu Ausgabegrenzwerten 90 zu max f x 1 270 zu min f x 1 SWE Prof Dr W Weber h_da Fachbereich Informatik 267 Beispiel X Quadrat f x x fur x ist Integer m 1 Aquvalenzklassen g ltig ung ltig Eingaben integer falls diese
181. s artifact Dosierer cpp SWE Prof Dr W Weber h_da Fachbereich Informatik 141 m 7 EF Darstellung der Architektur Anwendungs S ICht nach Kruchten95 m Darstellung des Verhalten des Systems der Interaktion z B zwischen Komponenten Objekten mE Umsetzung Sequenz Kommunikationsdiagramme u a sd Stationstaste aufrufen Radio Ul Ul Page Stationmanager ActiveTuner Tuner Radioh rer i SelectPreset n CallStation n SetFrequency f HOCHSCHULE DARMSTADT UNIVERSITY OF APPLIED SCIENCES 142 5 2 Darstellung der Architektur Dokumentation und Tools Die UML bietet diverse M glichkeiten um Architektursichten darzustellen Zum Beispiel Paket Sicht Logische Architektur Dom nen Sicht Paketdiagramm Subsystem und Komponenten Logische Sicht gt Statik Komponentendiagramm Klassendiagramm Kompositionsstrukturdiagramm Structured Classes gt Dynamik Kommunikationsdiagramm Sequenzdiagramm Prozess Thread Sicht Concurrency and Resource View gt Zustandsdiagramm Kommunikationsdiagramm Sequenzdiagramm Message Sequence Chart Aktivitatsdiagramm Timing Diagramm Einsatz Deployment Physische Sicht gt Verteilungs Diagramm Komponentendiagramm Implementations Sicht Dateien Sicht gt Komponentendiagramm SWE Prof Dr W Weber h_da Fachbereich Informatik 143 Hochschule Darmstadt Fachbereich Informatik software Engineering 5 3 Zusammenfa
182. s Geburtsstunde des Software Engineering SWE Prof Dr W Weber h_da Fachbereich Informatik 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 4 1 Erster Ansatz zur Entwicklung Ubersichtlicher Programme 1968 gt strukturierte Programmierung Vermeidung von GOTO Anweisungen etc Dijkstra 2 Entwicklung von Software Engineering Prinzipien 1968 1974 gt Strukturiertere Entwicklung von Programmen strukturierte Programmierung schrittweise Verfeinerung Geheimnis Prinzip Programmmodularisierung Software Lifecycle Entitiy Relationship Modell Software Ergonomie Frage Wissen Sie was sich hinter den Begriffen verbirgt SWE Prof Dr W Weber h_da Fachbereich Informatik 20 2 Grundlagen des Software Engineering Geschichtliche Entwicklung 4 1 Erster Ansatz zur Entwicklung Ubersichtlicher Programme 1968 gt strukturierte Programmierung Vermeidung von GOTO Anweisungen etc Dijkstra 2 Entwicklung von Software Engineering Prinzipien 1968 1974 gt Strukturiertere Entwicklung von Programmen strukturierte Programmierung keine GOTOs nur Verzweigung Schleifen Pozeduren schrittweise Verfeinerung Hierarchie von Funktionen Top down Entwurf Geheimnis Prinzip rufende Prozedur kennt nur Schnittstellen der aufgerufenen Proz Programmmodularisierung Aufteilen des Programms in Teile Software Lifecycle mehrere Phasen der SW Entwicklung Entitiy R
183. s System mit Meldung ohne Meldung gt Braucht es enorme Zeit SWE Prof Dr W Weber h_da Fachbereich Informatik 311 8 4 Systemtest Abnahmetest Stresstest m Ziele gt Maximale Input Geschwindigkeit gt Input an allen Linien z B alle Sensoren senden gleichzeitig gt Dasselbe Kommando an allen Linien gt Alarm an allen Linien gt Komplizierte Funktionen gt Nicht alle Systemressourcen zug nglich m Reaktionen gt Werden Inputs vergessen gt Bricht das System zusammen gt Braucht es zu lange Zeit Werden Daten verf lscht m Ein ungeheuer wichtiger Test bei Realzeitsystemen SWE Prof Dr W Weber h_da Fachbereich Informatik 312 8 4 Systemtest Abnahmetest Benutzbarkeitstest Evaluation durch Experten Ergonomen Standard f r Benutzerschnittstelle Messen der Lernkurve Beurteilung der Voraussetzungen SWE Prof Dr W Weber h_da Fachbereich Informatik 313 E 8 4 Systemtest Abnahmetest Sicherheitstest m Ziel Durchbrechen der Zugangskontrolle des Systems Kontrollieren Sie die Zugangsprivilegien f r jede Benutzerklasse und jede Funktion Destruktiver Test Kontrolle von Backup und Recovery Funktionen Paralleler Zugriff von mehreren Terminals auf die selben Resourcen Virus Check Arbeitsumfeld Organisation SWE Prof Dr W Weber h_da Fachbereich Informatik 314 E 8 4 Systemtest Abnahmetest Weitere Tests m Abh ngig von den erwarteten u
184. s Use Cases sondern nur einige Scenarien definiert gt Ich muss mir berlegen welche Scenarien ich zu Testzwecken noch zus tzlich spezifizieren sollte gt Wie teste ich nun Aktivit tentesten Zweigtesten oder Pfadtesten es kommt darauf an wie ausf hrlich man bei der Abnahme testen m chte gt Testen aller Aktivit ten gt Testen einiger Zweige gt vollst ndiger Zweigtest gt Zweigtesten einige Pfade aus dem Pfadgraphen oder gt vollkommener Pfadtest falls berhaupt m glich Wenn man z B die PIN Eingabe beliebig oft wiederholen darf gt Pfadgraph ist unendlich gro gt vollkommener Pfadtest nicht m glich gt ung ltige quivalenzklassen Eingabe A Hier darf das System auch nicht absturzen Fehlertoleranz gt zus tzlich intuitive Testf lle Eingabe 0 oder Blank SWE Prof Dr W Weber h_da Fachbereich Informatik 87 E 4 Abnahmetest Kontrollfragen zum Abnahmetest Welches Ziel haben Abnahmetests Wann werden Abnahmetests festgelegt Wie finden Sie Tests f r funktionale Anforderungen Kann es unendlich viele Testpfade geben Was tun Sie wenn es zu viele Testpfade gibt Wie testen Sie nicht funktionale Anforderungen Welche Bedeutung hat der Abnahmetest im vertraglichen Sinn Wie h ngt der Abnahmetest mit den Anforderungen zusammen il a SWE Prof Dr W Weber h_da Fachbereich Informatik 88 Hochschule Darmstadt Fachbereich Informatik soft
185. se und Dokumentationsformen m Definition der Funktionalit t gt siehe OOAD Use Cases Aktivit tsdiagramme Zustandsdiagramme lt Definition der nichtfunktionalen Anforderungen gt Qualit tseigenschaften als Text dokumentieren lt Erstellung von HMI Skizzen und Navigation gt Vorlesung Entwicklung nutzerorientierter Anwendungen ENA m Glossar oY gt Normale alphabetische Definitionsliste evtl mit Index m Sonstiges oy gt z B Modellierung der Anwendungsdomane siehe OOAD Analyseklassenmodell SWE Prof Dr W Weber h_da Fachbereich Informatik 67 E 3 Anforderungsanalyse Anforderungsanalyse Was ist eigentlich daran so schwer m Nette Gespr chsrunden viel Kaffee viele Kekse gt gemeinsames Verst ndnis finden gt Aufschreiben der Ergebnisse gt und fertig m Nicht ganz denn gt in der Regel k nnen nicht alle Anforderungen umgesetzt werden Priorisierung Planung und Verhandlung ist erforderlich Ablehnung von Anforderungen ist oft n tig gt die Anforderungen ndern sich mit der Zeit Umgang mit neuen ge nderten Anforderungen Konsistenz der Anforderungen erhalten Verwaltung der Anforderungen ee SWE Prof Dr W Weber h_da Fachbereich Informatik 68 E 3 Anforderungsanalyse Kontrollfragen zur Anforderungsanalyse Welches Ziel verfolgt die Anforderungsanalyse Was wird in der Anforderungsanalyse gemacht Warum ist die A
186. sgegeben werden die gleiche Zutat kann in mehreren Dosierern sein es soll automatisch umgeschaltet werden wenn ein Dosierer leer ist die Cocktails sollen schneller gemischt werden indem die Zutaten parallel abgewogen werden Dazu erh lt jeder Dosierer eine eigene Messvorrichtung In welchen Klassen und Methoden m ssen Sie nderungen machen Ist die nderung eher ein Hack oder passt sie ins Design gt K nnte die nderungen auch leicht jemand anderes machen gt Wie viele Stunden brauchen Sie zur Umsetzung gt K nnten Sie diese nderungen auch im Code Ihres Kollegen machen SWE Prof Dr W Weber h_da Fachbereich Informatik 471 13 1 Ergebnisse im Praktikum Lessons Learned I m Haben Sie den Wert der Modelle erkannt gt die Abstraktion hilft beim Bewahren des Uberblicks gt die Darstellung erleichtert das Verst ndnis gt In den Modellen werden Entscheidungen getroffen und wichtige Vorgaben gemacht gt die Implementierung wird geradlinig und einfacher oder auch nicht falls die Modelle nicht ad quat sind E aber falls der Detaillierungsgrad nicht stimmt klappt es nicht gt z B Implementierung trotz unvollst ndiger Klassen und Sequenzdiagramme f hrt zu h ufigen Schnittstellenanderungen es SWE Prof Dr W Weber h_da Fachbereich Informatik 472 13 1 Ergebnisse im Praktikum Lessons Learned Il E Haben Sie den Wert von Metriken erkannt gt schnelle und fr he
187. sgrundlage zwischen Endbenutzer und den Systementwicklern gt Sp tere Arbeitsweise wird durchgespielt Schw chen und Fehler der Spezifikation werden erkannt und vor der Weiterarbeit beseitigt gt Beispiel Implementierung eines Teils der Benutzeroberfl che e ohne oder e mit darunterliegender Logik und Datenbank SWE Prof Dr W Weber h_da Fachbereich Informatik 399 11 Vorgehens und Prozessmodelle 1 Was wird durch den Prototyp getestet Il m Technischer Prototyp Experimenteller Prototyp Labormodell gt dient den Entwicklern intern als Bewertungsgegenstand der Fragen der technischen Umsetzung und Realisierbarkeit kl ren soll gt Beispiel f r Zielsetzungen von technischen Prototypen berpr fung der Machbarkeit Absch tzung des Aufwandes des Zeitbedarfs der Kosten der Realisierung Vergleich von Alternativen Performance Tests Fragen der Konfiguration Anschluss von Druckern Vernetzung Einsatz von Tools SWE Prof Dr W Weber h_da Fachbereich Informatik 400 e 11 Vorgehens und Prozessmodelle 2 Wie ist ein Prototyp aufgebaut I horizontaler Prototyp gt z B nur Schnittstelle zum Benutzer gt Mit Hilfe solch eines Prototyps kann das Arbeiten mit dem System gezeigt werden gt Da die tieferen Ebenen fehlen liefert das System normalerweise falsche Werte horizontaler Prototyp uull Verarbeitungslogik S m Dateizugriffe
188. ssung SW Architektur h da san ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 144 5 3 Zusammenfassung Software Architektur Beispiel zur Softwarearchitektur I m Stellen Sie sich vor Sie sollen ein einfaches Autoradio entwickeln mit Radio inklusive Verkehrsfunk Kassette und CD gt mit den blichen Verst rkerfunktionen m Was sollten Sie nun in der Architektur festlegen gt alles was festgelegt werden muss bevor die Bestandteile des Systems einzeln bearbeitet werden k nnen die Aufteilung des Systems in Komponenten z B Radio CD usw mit Verantwortlichkeiten die Schnittstellen zwischen diesen Komponenten untereinander und zur Au enwelt die Verteilung der Software auf Dateien m den Aufbau des Systems als Hardware die Umsetzung von kritischen Vorg ngen z B Timingverhalten beim berblenden die Verteilung der Software zur Laufzeit auf Hardware Entwicklungsrechner Target die Umsetzung von komponenten bergreifenden Use Cases zur Veranschaulichung z B Wechsel von CD auf Radio betrifft CD Amplifier und Radio 145 a 5 3 Zusammenfassung Software Architektur ae re Beispiel zur Softwarearchitektur Il Audio Requests m Ein Ergebnis der Architektur f r das Autoradio k nnte sein ee abstract gt Diverse Komponentendiagramme welche die Aufteilung des Systems 7 ee
189. st definiert im Vorgehensmodell gt Vertragsinhalte festlegen Funktionalit t Bezahlung Termine Abnahme Strafen Iteration des Pflichtenhefts und evtl Lastenhefts Erarbeiten eines gemeinsamen Verstandnisses SWE Prof Dr W Weber h_da Fachbereich Informatik 56 a 3 Anforderungsanalyse Inhalt eines Lastenhefts Idealergebnis Titel Systemname Datum Autor Zielbestimmung und Zielgruppen Ausgangssituation grunds tzl Zielsetzung l a Produktperspektive Erwartete Verbesserung l b Einsatzkontext Einsatzm glichkeiten Funktionale Anforderungen Welche Leistung liefert das Produkt Il a Produktfunktionen Funktionalit t Il b Produktschnittstellen Schnittstellen zu anderen Systemen Il c Anwenderprofile potenzielle Benutzer Nichtfunktionale Anforderungen Wie gut wird die Leistung erbracht IIl a Qualit tsanforderungen siehe n chste Folie IIl b Technische Anforderungen Einsatzumgebung Lieferumfang Dokumente Systeme Code Wartung Abnahmekriterien Minimalkriterien f r die Akzeptanz Anh nge Sonstiges Quelle M Winter Methodische objektorientierte Softwareentwicklung SWE Prof Dr W Weber h_da Fachbereich Informatik 57 3 Anforderungsanalyse Zur Erinnerung Softwarequalitatseigenschaften Funktionserf llung bertragbarkeit Wiederverwendbarkeit SWE Prof Dr W Weber h_da Fachbereich Informatik SW Effizienz Performance Q
190. st ein Modultest gt Beim Modultest wird f r ein Modul die Erf llung der Spezifikation gepr ft gt Da ein Modul meistens alleinstehend nicht lauff hig ist wird zun chst eine Testumgebung erstellt d h Programme welche das Modul mit Testdaten versorgen gt Fehler k nnen dann z B mit einen Debugger lokalisiert werden m Wie f hre ich einen Modultest durch gt als Entwickler in einer simulierten Zielumgebung ohne den Auftraggeber m Was wird in einem Modultest getestet gt Die Funktion eines einzelnen Moduls SWE Prof Dr W Weber h_da Fachbereich Informatik 297 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 3 Integration und Integrationstest h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 298 8 3 Integrationstest Zur Erinnerung Tatigkeiten im Design m Zerlegung des Systems in Programmteile amp Systemkomponenten Module gt Anbindung an konkrete Programmiersprache Betriebssystem Hardware gt Ausarbeiten von Details Klassen mit Methoden und Attributen mit Datentypen Abl ufe Betriebssystemanbindung Threads Scheduler Timer gt Umsetzung der Vorgaben aus der Architektur m Das Grob Design die SW Architektur zerlegt das System in Systemkomponenten gt Das Zusammenbauen von Systemkomponenten zu Teilsystemen Sub Systemen hei t Integrati
191. stf lle zu reduzieren K nnen wir die Fehlerfreiheit durch Testen nachweisen Wie erreichen wir dass die Zuverl ssigkeit nach dem Test m glichst hoch ist Wo treten besonders h ufig Fehler auf und wie w hlt man geschickt Testf lle aus en SWE Prof Dr W Weber h_da Fachbereich Informatik 254 8 Test und Integration Inhalt eines Testfalls m Ein Testfall ist ein Durchlauf durch das Programm m Erzeugt er ein vom Soll Ergebnis abweichendes Ergebnis gt es liegt ein Fehler vor m Aber gt Ein Testfall muss den Test genau spezifizieren gt die Durchf hrung muss immer das gleiche Ergebnis liefern Frage z B Erstellung Angebot Eingabe 3 Wasserkocher Summe ist 30 beim Test in 3 Wochen Summe ist 33 Warum Frage Beim Geld abheben gebe ich ein 500 aber es kommt kein Geld raus Warum Liegt hier ein Fehler vor Auch der Zustand sowohl vor dem Test als auch nach dem Test muss vollst ndig beschrieben werden gt Ein Testfall wird beschrieben durch ein Paar Eingangszustand Eingabe Sollausgabe Sollzustand nach dem Test SWE Prof Dr W Weber h_da Fachbereich Informatik 255 8 Test und Integration Was muss bei der Spezifikation eines Testfalls angegeben werden Eingabe R ckgabe Parameter einer Funktion Daten die ber Bildschirm ein und ausgegeben werden Daten die gelesen und geschrieben werden z B von in Datenbanken Sensoren externe Ger te ev
192. t m Prozesse werden fortlaufend verbessert m Innovative Ans tze werden erpobt und ber erhobene Schl sseldaten bewertet Bemerkung Wegen des hohen Aufwands wird normalerweise nur das Erreichen von Capability Level 2 oder 3 angestrebt SWE Prof Dr W Weber h_da Fachbereich Informatik 450 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Bestimmung des Capability Level F higkeitsgrad eines Prozesses Wir Bewerten das Erfulltsein von Prozess Attributen bzw das Durchf hren von generischen Praktiken e Verf gbarsein von generischen Resourcen und e Vorhandensein von Arbeitsergebnissen Wann ist ein bestimmter Capability Level erreicht II HOCHSCHULE DARMSTAD Lee SWE Prof Dr W Weber h_da Fachbereich Informatik 451 e 11 1 Modelle zur Bewertung von Software E ntwickungsprozessen SPICE Evaluation der Prozess Attribute und Bestimmung des Capability Levels des Prozesses Bewertung des Erf lltseins eines Prozess Attributes m F Fully achieved mM L Largely achieved m P Partially achieved m N Not achieved Um F zu erreichen gt m ssen nicht unbedingt alle Praktiken implementiert sein gt m ssen nicht unbedingt alle geforderten Resourcen verf gbar sein m ssen nicht unbedingt alle Arbeitsergebnisse erstellt werden gt Es h ngt vom speziellen Umfeld und der Meinung des Assessorenteams ab was unbedingt vorhanden sein muss m Ein Level ist erreicht w
193. t Systematischer Umgang mit nderungsantr gen 1 Analyse der Veranderungen gegenuber geplanten Zeiten Kosten und Risiken 2 Analyse der Auswirkung dieser Veranderung auf andere Anforderungen 3 Freigabe der nderung und Einarbeitung in das Pflichtenheft Designdokumente Achtung Die Analyse jedes Change Requests erfordert bereits Ressourcen gt F r die Umsetzung m ssen oft Kosten nachverhandelt werden ay eose ommon SWE Prof Dr W Weber h_da Fachbereich Informatik 461 N N 12 Technisches Management Risikomanagement l m In jedem Projekt bestehen Risiken gt Mitarbeiter k nnen k ndigen oder das Projekt verlassen gt Getroffene Annahmen stellen sich als falsch heraus z B Arbeitspaket X ist in 3 Tagen fertig gt Zulieferungen bleiben aus oder versp ten sich z B Technologie X ist bis zum Termin Y verf gbar gt p m Ein Risiko ist der Zusammenhang zwischen einer Ursache die mit einer gewissen Wahrscheinlichkeit eintreten kann und einer in der Regel negativen Auswirkung bei der ein Verlust entsteht gt Die negative Auswirkung muss nicht zwangsl ufig eintreten man kann auch Gl ck haben gt Der Verlust kann zum Beispiel eine zeitliche Verz gerung zus tzliche Kosten oder eine Verschlechterung der Qualit t sein Wie geht man mit Risiken um SWE Prof Dr W Weber h_da Fachbereich Informatik 462 12 Technisches Management Risikomanagement II m Ein Risikomanagement Prozess
194. t Oft haben Use Cases auch Kontrollfunktion In Wi05 p E Schnittstellenklassen sind oft versteckt in GUI Frameworks SWE Prof Dr W Weber h_da Fachbereich Informatik 111 5 1 Architekturstile Was sind Kontrollklassen m Kontrollklassen beinhalten die anwendungsfallbezogene meistens mehrere Instanzen von Entit tsklassen betreffende fachliche Logik m Sie steuern die Abl ufe m Sind Vermittler zwischen Schnittstellen und Entit tsklassen und kontrollieren ob die von der Schnittstellenklasse angenommenen Eingaben und Modifikationen der Akteure auf den Entit tsklassen ausgef hrt werden d rfen m Falls Anwendungslogik trivial Auch direkte Kommunikation zwischen Schnittstellen und Entit tsklassen In Schnittstellenklassen ist dann evil anwendungsfallbezogene fachliche Logik integriert SWE Prof Dr W Weber h_da Fachbereich Informatik 112 5 1 Architekturstile Was sind Entitatsklassen O m Enthalten Daten m Enthalten die fachliche Logik die die einzelnen Instanzen der Entit tsklasse betreffen Die fachliche Logik die nur eine Instanz einer Entit tsklasse betrifft sollte nicht in Kontrollklassen untergebracht sein vor allem nicht in einer gro en Kontrollklasse die die gesamte Anwendungslogik enth lt Blob m Jede Entit tsklasse ist daf r verantwortlich dass ihre Instanzen nur die gem Gesch ftsregeln erlaubten Zust nde annehmen Setter Getter m u a werden oft die in der Ph
195. t ndlich brauchen wir in UP auch die in RUP explizit zus tzlich erw hnten Disziplinen SWE Prof Dr W Weber h_da Fachbereich Informatik 412 11 Vorgehens und Prozessmodelle Phasen und E rgebnisse Siehe auch S 39 45 in Arlow Neustadt Elabor Gesch ftsprozess Modellierung Anforderungsdefinition Analyse Design Implementierung u Test Auslieferung ProjektManagement ENV Infrastruktur eingerichtet SWE Prof Dr W Weber h_da Fachbereich Informatik 413 11 Vorgehens und Prozessmodelle Phasen und E rgebn isse Siehe auch S 39 45 in Arlow Neustadt Elaboration Phase Ausarbeitung Entwurf Geschaftsprozess Mit den Stakeholder berarbeitetes endg ltiges Gesamtgeschaftsprozessmodell als Modellierung Workflow mit verbalen Beschreibungen liegt vor UML Use Case Diagramm fertig UML Use Case Beschreibungen fast fertig Anforderu ngsdefi nition nichtfunktionale Anforderungen sind definiert Statische und dynamische UML Modelle zu Analyse fertig Analyse Design Architektur fertig Design zum gro en Teil fertig Benutzerdokumentation begonnen Ein belastbares robustes ausgetestetes ausf hrbares Kernsystem Prototyp Implementierung u Test Testplan und Testf lle fast fertig Kernsystem zum Pr fen ausgeliefert Auslieferung ProjektManagement Detaillierter Projektplan mit einer realistischen Einsch tzung ber ben tigte Zeit Geld und weitere Resourcen verfeiner
196. t ben tigten Merkmale m durchlaufe immer wieder in kurzen Zyklen typ eine Woche s mtliche Disziplinen der klassischen Softwareentwicklung gt Anforderungsanalyse Design Implementierung Test m verwende kurze Release Zyklen und integriere dauernd gt lauff hige Systeme in kurzen Zeitabst nden m erstelle eine gute Dokumentation gt leicht verst ndlich vollst ndig aber nicht ausschweifend SWE Prof Dr W Weber h_da Fachbereich Informatik 427 11 Vorgehens und Prozessmodelle Agile Vorgehensweisen Agile SW Entwicklung ist nicht eine bestimmte sondern ein Uberbegriff f r verschiedenen Vorgehensweisen Extreme Programming K Beck Adaptive Software Development J Highsmith Lean Software Development M Poppendieck Crystal A Cockburn Scrum K Schwaber m Wir wollen hier Extreme Programming und Scrum n her anschauen SWE Prof Dr W Weber h_da Fachbereich Informatik 428 11 Vorgehens und Prozessmodelle Die agile Vorgehensweise Extreme Programming XP Grundprinzipien m Prinzipien Auswahl Extreme _ rogramming gt Sit together das gesamte Team entwickelt in einem Raum gt Alle Informationen sind jedem zug nglich z B auch auf an den W nden gt Kollektives Eigentum jeder darf jederzeit jeden Quellcode ver ndern gt Enge Einbeziehung zum Kunden Story Cards beschreiben Anwendungsf lle exemplarisch in Form kurzer Geschichten gt offene und resp
197. t einer gro en Anzahl von Attributen Operationen oder beidem Mehr als 50 Attribute und Operationen gt Blob gt Fehlendes objekt orientiertes Design Die einzige Controller Klasse kapselt die gesamte Funktionalit t des Programms hnlich einer prozeduralen Main Funktion gt Eine Klasse enth lt eine Ansammlung der unterschiedlichsten Attribute und Operationen die keine Beziehungen untereinander haben Trennung von Zust ndigkeiten gt Eine einzige Controller Klasse mit wenigen assoziierten einfachen Daten Objekt Klassen m Konsequenzen gt Der Blob begrenzt die M glichkeiten das System zu modifizieren ohne die Funktionalit t anderer gekapselter Objekte zu beeinflussen Geheimnisprinzip gt Typischerweise ist der Blob zu komplex f r Wiederverwendbarkeit und Tests Es ist nahezu ausgeschlossen Untermengen der Funktionalit t eines Blobs wieder zu verwenden gt Es kann aufw ndig sein eine Blob Klasse in den Speicher zu laden da sie exzessiv Ressourcen verbraucht selbst f r einfache Operationen SWE Prof Dr W Weber h_da Fachbereich Informatik 229 6 4 Anti Patterns The Blob L sungsans tze I m Ziel einer Neustrukturierung ist es gt Verhalten aus dem Blob herauszunehmen und gekapselten Datenobjekten zuzuordnen Im Beispiel kapselt die Library Klasse die Summe aller System Funktionalit ten gt Identifiziere oder kategorisiere zusammengeh rige Attribute und Operationen Die Zusammengeh
198. te Risikoanalyse Kosten Nutzenanalyse liegt vor DARMSTADT UNIVERSITY OF APPLIED SCIENCES SWE Prof Dr W Weber h_da Fachbereich Informatik 414 11 Vorgehens und Prozessmodelle Phasen und E rgebnisse Siehe auch S 39 45 in Arlow Neustadt Ergebnisse Produkte der Gesch ftsprozess BEN SWE Prof Dr W Weber h_da Fachbereich Informatik 415 11 Vorgehens und Prozessmodelle Phasen und E rgebnisse Siehe auch S 39 45 in Arlow Neustadt Ergebnisse Produkte der Gesch ftsprozess Modellierung Auslieferung ProjektManagement Env Zielsystem eingerichtet SWE Prof Dr W Weber h_da Fachbereich Informatik 416 11 Vorgehens und Prozessmodelle Phasen und Ergebnisse Iterationen Bei gr eren Projekten sind insbesondere die Phasen Ausarbeitung Erstellung und Ubergang in mehrere Iterationen unterteilt Nach jeder Iteration ist man den Endziel etwas n her gekommen und es sind weitere Ergebnisse Produkte entstanden Es entstehen u a Zwischenversionen des lauff higen Programms incl Dokumentation die entweder nur intern zur Bewertung des Arbeitsfortschritts dienen oder die an den Kunden zum Testen oder schon f r den produktiven Einsatz ausgeliefert werden Man spricht von einem iterativ inkrementellen Prozess da in jeder Iteration ein Inkrement Produkte eines Arbeitsschritts d h UML Modelle lauffahiger Code zum System hinzugef gt wird Alle
199. tellen analysieren und Verbesserungsvorschl ge pr fen zus tzliche W nsche ber cksichtigen Verstehen was die Software leisten soll gt Ergebnis Die fachlichen Anforderungen an die Software werden dokumentiert und mit dem Auftraggeber abgestimmt Es wird analysiert ob die Aufgabe durchf hrbar l sbar ist ob sie finanzierbar ist und ob das notwendige Personal vorhanden ist Es wird eine erste Kostenkalkulation vorgenommen gt Fehler in der Analysephase sind sehr teuer und wirken sich auf alle folgenden Phasen aus SWE Prof Dr W Weber h_da Fachbereich Informatik 37 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Definition oft auch Teil der Analysephase m Inder Definitionsphase gt informellen Anforderungen der Analyse berf hrt in eine gt m glichst vollst ndige konsistente Spezifikation gt Ergebnis Beschreibt wie das Produkt aus Benutzersicht funktionieren soll insbesondere wird der Abnahmetest mit dem Benutzer Auftraggeber festgelegt Soll normalerweise implementierungsunabhangig formuliert sein Legt bereits Qualitatseigenschaften fest gt Die Definition beschreibt Was das System tun soll SWE Prof Dr W Weber h_da Fachbereich Informatik 38 2 2 Grundlagen des Software Engineering Phasen der Softwareentwicklung Architektur Grobentwurf m Inder Architektur gt wird die IT L sung auf einer hohen Abstraktionsebene entworfen
200. tert gt wird weiterentwickelt bis das Zielsystem vorliegt SWE Prof Dr W Weber h_da Fachbereich Informatik 404 E 11 Vorgehens und Prozessmodelle Bewertung Prototypen Prototypen Modell Vorteile Nachteile m Sinnvolle Integration in andere m Erh hter Entwicklungsaufwand Vorgehensmodelle m glich durch zus tzliche Herstellung von m Schaffung einer starken Prototypen R ckkopplung zwischen m Gefahr der Umwandlung eines Endbenutzern und Herstellern Wegwerf Prototyps zu einem Teil m Schnelle Erstellung von Prototypen des Endprodukts aus durch geeignete Werkzeuge Termingr nden m Prototypen ersetzen fehlende Dokumentation ET oa SWE Prof Dr W Weber h_da Fachbereich Informatik 405 E 11 Vorgehens und Prozessmodelle Rational Unified Process oS gt S p o m Der Rational Unified Process RUP ist ein von der Firma Rational 7 UNI FEY w Software parallel zur Unified Modeling Language entwickeltes Vorgehensmodell zur Softwareentwicklung m Der RUP definiert 6 3 grundlegende Disziplinen und m orthogonal dazu 4 Phasen SWE Prof Dr W Weber h_da Fachbereich Informatik 406 11 Vorgehens und Prozessmodelle Disziplinen Arbeitsschritte im RUP Disciplines Arbeitsschritte A Geschaftsprozessmodellierung Anforderungsanalyse Analyse amp Design Implementierung Test Auslieferung Projektmanagement Konfigurations und Anderungsman Erst d Umgebung
201. tf llen sollten Tester und Entwickler unterschiedliche Personen sein m Beispiele gt Wert 0 bei Ein Ausgabewerten Steuerzeichen in Zeichenketten gt Kein Eintrag oder leerer Eintrag bei Tabellenverarbeitung gt Einlesen von Kommazahlen in Integerfelder gt Gleichzeitiges oder andauerndes Dr cken von Tasten SWE Prof Dr W Weber h_da Fachbereich Informatik 269 8 1 1 Black Box Test Spezifikation Beispiel Fakultat a m Entwickeln Sie die Testf lle gt nach der Methode des quivalenzklassentests nach der Methode der Grenzwertanalyse gt Erg nzen Sie intuitive Testf lle gt FAK n n integer Berechnung der Fakult t n n n 1 3 2 1 gt Unsere Funktion FAK n sei abweichend von der math Def folgenderma en definiert gt FAK n 1 wennn lt O gt 1 wennn Oorn 1 gt n FAK n 1 sonst I J ERR SWE Prof Dr W Weber h_da Fachbereich Informatik 270 E Spezifikation 8 1 1 Black Box Test Beispiel Fakultat Losung m Aquivalenzklassen gt g ltige Klassen 0 0 1 1 0 _ _ I gt ung ltige Klassen Eingabewert ganze Zahlen gt Testf lle 5 1 0 1 5 120 1 5 UNDEF m nach der Methode der Grenzwertanalyse gt Testf lle 1 1 0 1 1 1 2 2 m Intuitive Testf lle gt Die Funktion w chst so schnell dass die Berechnung oft durch eine Wertetabelle ersetzt wird FAK 13 gt MAX_INT FAK 21 gt MAX_LONG gt E
202. the customer is established 2 agreed customer requirements are defined and baselined 3 a change mechanism is established 4 a mechanism is established for continuous monitoring of customer needs Base practices Obtain customer requirements and requests Outcome 1 4 Agree on requirements Outcome 2 Establish customer requirements baseline Outcome 2 3 Input work products Commitment agreement Outcome 2 Change request Outcome 3 Output work products Customer requirements Outcome 2 3 Communication record Outcome 1 4 Change control record Outcome 3 4 hda ST fy messe oanusmor SWE Prof Dr W Weber h_da Fachbereich Informatik ie 445 11 1 Modelle zur Bewertung von Software Entwickungsprozessen SPICE Capability Level 2 Process Attributes and Indicators Level 2 Managed Process mM Der Performed durchgef hrte Process Level 1 gt wird zus tzlich geplant verfolgt und angepasst und gt Die Arbeitsprodukte sind adequat implementiert stehen unter Konfigurationsmanagement werden qualit tsgesichert gemanaged und fortgeschrieben F r die Bewertung eines Processes gen gt keine informelle Beschreibung gt Process Attributes und Indicators m Zu Capability Level 2 oder h her existieren jeweils 2 gt Process Attributes gt F r jedes Process Attribute sind Indicators definiert Generic Practices ne
203. tige quivalenzklasse z B Zahlungsart gemischt m Falls durch den Eingabetyp Eingabebedingungen beschrieben werden z B erstes Zeichen muss Buchstabe sein gt eine g ltige quivalenzklasse 1 Zeichen Buchstabe gt eine ung ltige Aquivalenzklasse 1 Zeichen kein Buchstabe SWE Prof Dr W Weber h_da Fachbereich Informatik 264 Spezifikation 8 1 1 Black Box Test Kombination von Aquivalenzklassen u m Wie ist zu testen falls mehrere Eingabewerte zust nde existieren und zu jedem Eingabewert zustand mehrere Aquivalenzklassen existieren gt Bilde das Kreuzprodukt der Aquivalenzklassen N dimensionaler Raum gt Kombinationen aller kombinierbaren Repr sentanten m z B bei 2 Eingabevariablen ergeben sich max n m Testl ufe gt mitn m Anzahl der quivalenzklassen der Eingabevariablen oft weniger da gt ung ltige quivalenzklassen zu einem Eingabewert oft nur einmal getestet werden m ssen da unabh ngig von anderen Eingabewerten z B direkter Abbruch unabh ngig von anderen Werten gt Auch Eingabewerte von g ltige quivalenzklassen k nnen unabh ngig von anderen Werten sein gt zwischen n m und n m Testl ufen m falls zu viele Testlaufe gt Einschr nkung auf Teilmenge der Eingabewertekombinationen SWE Prof Dr W Weber h_da Fachbereich Informatik 265 Spezifikation 8 1 1 Black Box Test Erganzung der Tests durch die Grenzwertanalyse a m Unte
204. tionstest im Detail F m Woher kennen wir die gew nschte Funktionalit t gt In der Anforderungsanalyse wurden die Funktionalit t durch Eingaben und die darauf erwartete Reaktion des Systems beschrieben m Annahme Wir haben Anwendungsf lle beschrieben gt In Anwendungsfallen sind Eingaben ins System und Ausgaben vom System dokumentiert gt Beim Abnahmetest werden die einzelnen Anwendungsfalle ein oder mehrmals durchgespielt gt Um nachzupr fen ob die vom Anwendungsfall beschriebene Funktionalit t wie erwartet abl uft il er SWE Prof Dr W Weber h_da Fachbereich Informatik 76 2 LUMCUClt t 4 Abnahmetest Ableiten von Funktionstests I aus Use Cases Trigger Login System fragt Kunden nach PIN Basic 1 System fordert zur PIN Eingabe auf POUSE 2 Kunde gibt PIN ein Gef hrlich 3 System validiert PIN Wirklich gt O i System gibt Zugang frei immer O Alternate Step Condition Action s eu Kunde bricht ab Abbruch Keine Eingabe f r 30 Sek Abbruch PIN stimmt nicht und Versuche lt 3 PIN stimmt nicht und Versuche gt 3 Abbruch SWE Prof Dr W Weber h_da Fachbereich Informatik 77 4 Abnahmetest Ableiten von Funktionstests Il Essentielle Aktivit ten ohne Fehler und Ausnahmesituationen Kundenreaktion Aufforderung PIN Eingabe PIN Validierung System gibt Zugang frei ET aaa SWE Prof Dr W Weber h_da Fachbereich Informatik 78
205. tl zu simulieren gt replizierbare Ergebnisse Globale Variablen die vom zu testenden Programm gelesen geschrieben werden Attribute von Klasseninstanzen die vom zu testenden Programm gelesen geschrieben werden Ruckgabeparameter von aufgerufenen Unterfunktionen Auch der Zustand des zu testenden Programms ist vollst ndig zu beschreiben sowohl vor dem Test als auch nach dem Test Ein Testfall wird beschrieben durch ein Paar Eingangszustand Eingabe Sollausgabe Sollzustand nach dem Test SWE Prof Dr W Weber h_da Fachbereich Informatik 256 8 Test und Integration Varianten von Testobjekten Es gibt 2 grundlegende Varianten m Black Box Spezifikation Das zu testende Modul ist ein schwarzer Kasten gt Die innere Struktur ist f r den Tester unbekannt gt Interne Zust nde des Moduls sind nicht sichtbar gt Man sieht nur die Oberfl che das Was d h die Modulspezifikation Nur daraus k nnen Testf lle abgeleitet werden gt z B externe Software Zulieferungen als Object File oder Abnahmetest m White Box gt Man schaut in den Kasten hinein Methoden gt Die innere Struktur das Wie des Programms wird zur berpr fung hinzugezogen gt z B Eigenentwicklungen SWE Prof Dr W Weber h_da Fachbereich Informatik 257 Hochschule Darmstadt Fachbereich Informatik software Engineering 8 1 1 Black Box Test h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY
206. tributstyps dargestellt MyPosition Rolle typ Mitarbeiter Arbeiter gt typ Mitarbeiter Manager Schmidt Person Neue Rollen wie Gesellschafter etc k nnen durch einfache Erweiterung des Aufz hlungstyps dargestellt werden Basen SWE Prof Dr W Weber h_da Fachbereich Informatik i UNIVERSITY OF APPLIED SCIENCES 176 6 2 Regeln zum Entwurf von Klassen Regel 1 Setze Vererbung Generalisierung Spezialisierung sparsam ein ii HOCHSCHULE DARMSTADT Vererbung Generalisierung Spezialisierung ist das am meisten Uberschatzte und Uberbenutzte Konzept der Objekt Orientierung gt Setze Vererbung nur bei echter ist ein Beziehung ein gt Ersetze wo sinnvoll m glich eine Vererbung durch eine Assoziation Beispiele gt Ein Kunde ist eine Person gt eine Person hat die Rolle Kunde gt Eine Frau ist eine Person gt eine Person hat das Geschlecht weiblich gt Ein Rothaariger ist eine Person gt eine Person hat die Haarfarbe rot Verwende nur einfache Vererbung Single Inheritance gt Bei der Einfachvererbung hat man nur einen Schuss und der muss sitzen Schachtele Vererbungsb ume nicht zu tief gt Tiefe 2 3 reicht meistens aus SWE Prof Dr W Weber h_da Fachbereich Informatik IENCES 177 6 2 Regeln zum Entwurf von Klassen Aufgabe 2 m Modellieren Sie folgenden Sachverhalt gt In einem MP3 Archiv sollen Lieder gespeichert werden gt F r j
207. tung ist allerdings seit vielen Jahren unumstritten m Diese Grundprinzipien sind anwendbar gt f r implementierungsnahen Entwurf Feinentwurf gt aber auch f r den Entwurf von Anwendungen auf h herer Abstraktionsebene Software Architektur bis hin zu Anwendungslandschaften SWE Prof Dr W Weber h_da Fachbereich Informatik 170 E amp Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 6 2 Wiederholung f r die die nochmals nachschauen wollen Regeln zum Entwurf von Klassen h da u i ii HOCHSCHULE DARMSTADT Hii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 171 6 2 Regeln zum Entwurf von Klassen Zur Erinnerung Schritte zum Entwickeln von Klassendiagrammen 1 Klassen kandidaten finden gt Substantive bestimmen gt berfl ssige Begriffe rausfiltern gt Attribute identifizieren gt Operationen ber Verben suchen 2 Spezialisierungsbeziehungen suchen gt hnliche Klassen identifizieren Aber Ist ein Regel beachten gt Evtl Schnittstellen durch abstrakte Klasse Spezialisierung definieren 3 Assoziationen zwischen Klassen bestimmen gt Kennt Beziehungen normale Assoziation gt Besteht aus Beziehung Aggregation bzw Komposition gt evil Leserichtung und Rollen angeben gt Objekte deren Existenz an einer Assoziation h ngt Assoziationsklasse 4 Multiplizit te
208. unkte Workflow gt Zu jeden Entscheidungspunkt werden Produkte vorgeschlagen die beim Eintreten des Entscheidungspunkts vorliegen m ssen gt gewissen Projekttypen k nnen gewissen Vorgehensbausteine zugeordnet werden Vertragsabschluss AG Evaluierung Fertigprodukte Systemerstellung Alle Abbildungen in diesem Kapitel aus V Modell XT Release 1 3 SWE Prof Dr W Weber h_da Fachbereich Informatik 418 E V Modell XT Tailoringsystem KA V Modell XT Projektassistent 1 3 Neues Projekt Datei Hilfe Projekttyp Anwendungsprofil Vorgehensbausteine und Projekttypvarianten Bestimmen Sie den Projekttyp und die Projekttypvariante i Das Projekt kann jetzt exportiert werden Projekttyp Projekttypvariante Systementwicklungsprojekt AG AG Projekt mit einem Auftragnehmer Systementwicklungsprojekt AN AG Projekt mit mehreren Auftragnehmern Systementwicklungsprojekt AG AN O Einf hrung und Pflege eines organisationsspezifischen Vorgehensmodells Ubersicht Durch Projekttyp bedingte Yorgehensbausteine Projektmanagement Qualitatssicherung Problem und Anderungsmanagement Konfigurationsmanagement Anforderungsfestlegung Lieferung und Abnahme AG Vertragsschluss AG Durch Projekttyvariante bedingte Yorgehensbausteine Multi Projektmanagement Durch Projekttyp bedingte zu entscheidende Projektmerkmale Systemsicherheit AG Kaufm nnisches Projektmanagement Messung und Analyse Fert
209. ware Engineering 5 Software Architektur Grob Design 22258 hda u fii HOCHSCHULE DARMSTADT a HHHH UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 89 5 Software Architektur Einordnung im V Modell tn cn d Stfalle Integ Be Dan We AN Modul Imple Test mentierung f lle SWE Prof Dr W Weber h_da Fachbereich Informatik 90 E y 5 Software Architektur Architektur einer Br cke Diese Br cke kann von einer Person E Se a realisiert werden Quelle R Hahn Einfacher Bauplan Einfache Arbeitsschritte Einfache Werkzeuge h da CRT SWE Prof Dr W Weber h_da Fachbereich Informatik i E DARMSTADT UNIVERSITY OF APPLIED SCIENCES 91 E 5 Software Architektur Architektur einer gro en Br cke every large software project is similar to the first attempt to build a flying buttress construction cathedral Richard P Gabriel Die Funktion der gro en H nge Br cke ist im Prinzip gleich aber diese Br cke wird von vielen spezialisierten Personen gruppen realisiert in mehrj hriger Bauzeit komplizierte Baupl ne Quelle Wikipedia GFDL aufw ndige Arbeitsschritte viele spezielle Werkzeuge SWE Prof Dr W Weber h_da Fachbereich Informatik 92 E 5 Software Architektur Bau einer gro en Brucke m Es gibt mehrere professionelle Architekten gt m
210. werden der Name und Zweck der Klasse Autor Erstellungsdatum und Version sowie eine Anderungsliste enth lt gt Namenskonventionen Die C Schl sselw rter sind als Symbolnamen auch in Gro buchstaben nicht zul ssig gt Deklarationen Bei paarweise existierenden Operatoren wie und muss falls einer berladen wird auch der andere berladen werden gt Fehlerbehandlung Der R ckgabewert von new muss vor der ersten Verwendung gepr ft werden gt Sonstiges Statt der Funktionen alloc und free sind new und delete zu verwenden Bei Bedarf sind die Standard Datentypen string vector und set zu verwenden SWE Prof Dr W Weber h_da Fachbereich Informatik 240 7 Implementierung Inhalt einer Programmierrichtlinie Weitere Themen m Festlegung der I O Methoden der verwendeten Zeichensatze von erlaubten Dateinamen von Variablennamen mit Datentypen z B uint32MyNumber m Regeln ee ee ee zur Verwendung von Zeigern zur Verwendung von Sichtbarkeiten Zugriffsrechten zum Umgang mit dem Preprozessor Compiler Warnungen zum Aufteilung des Codes auf Dateien z B eine h Datei enthalt eine Klasse zur Art der Fehlerbehandlung zur Initialisierung von Variablen zu Layout Formatierung des Codes und vieles mehr je nach Projekt und Bedarf SWE Prof Dr W Weber h_da Fachbereich Informatik 241 7 Implementierung Vorteile einer Programmierrichtlinie m
211. wicklungsrichtung Keine Ausrichtung auf einen einzigen Endtermin ere SWE Prof Dr W Weber h_da Fachbereich Informatik N 394 11 Vorgehens und Prozessmodelle Das iterativ inkrementelle Modell 7 m M glichst vollst ndige Erfassung und Modellierung der Anforderungen an das zu entwickelnde Gesamtprodukt Realisierung der n chsten Ausbaustufe unter Ber cksichtigung der Erfahrungen des Auftraggebers mit der laufenden Version Einsatzf higes System f r den Auftraggeber schon nach relativ kurzer Zeit nderungen Plane erst das Gesamtsystem dann baue in Zyklen die Teilsysteme Analyse des Gesamtsystems Def des Gesamtsystems inkl Zyklenplanung _ _ nn u Bea Anpassungen auf Grund von Erfahrung mit dem Teilsystem p Implementierung und Test des Teilsystems Teilsystems Betrieb amp Evaluation des Teilsystems bereich Informatik 395 e 11 Vorgehens und Prozessmodelle Bewertung des inkrementellen Modells Vorteile Nachteile m zus tzlich zu den Vorteilen der m Vollst ndige Spezifikation nicht evolution ren Entwicklung immer m glich m Inkrementelle Erweiterungen passen KM die Entwicklung der ersten Version zum bisherigen System dauert l nger als beim evolution ren Modell II eee Lee SWE Prof Dr W Weber h_da Fachbereich Informatik 396 11 Vorgehens und Prozessmodelle Prototypen m Erstellung von lauffahigen
212. y Verlag 2008 SWE Prof Dr W Weber h_da Fachbereich Informatik Ei Hochschule Darmstadt Fachbereich Informatik Objektorientierte Analyse und Design 2 Grundlagen des Software Engineering 22258 hda sss HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 11 il ee SWE Prof Dr W Weber h_da Fachbereich Informatik P E 2 Grundlagen des Software Engineering Lernziele m Sie sollen in diesem Kapitel verstehen gt was alles zu Software geh rt wie Software Engineering entstanden ist was Qualit t von Software ausmacht wie wichtig die Qualit tseigenschaften f r die Software sind welche Phasen in der SW Entwicklung vorkommen welche Inhalte die Entwicklungsphasen haben ff 2 12 2 Grundlagen des Software Engineering Was ist das Problem m Komplexe SW Projekte sind gekennzeichnet durch gt Software wird in mehreren Versionen weiterentwickelt und erweitert Bedeutung von Dokumentation und Modellen f r die Wartbarkeit gt Lange Entwicklungszeit Bedeutung von Projektplanung und Termin berwachung gt Einsatz von Entwicklerteams evtl an mehreren Standorten Bedarf an Standards und Regeln f r Kommunikation und Dokumentation gt Lange Lebensdauer mit sich ver ndernden Anforderungen Bedeutung von Dokumentation und Modellen f r die nderbarkeit Die Methode VHIT Vom Hirn Ins Term
213. ykel Dezember Monats Auftrag Bestellung M ller hat den Monats Auftrag f r Hubers Bestellungen Da ist nat rlich fachlich falsch Das Datenmodell erlaubt es aber Das Modell k nnte durch eine entsprechende Einschr nkun Constraint korrigiert werden aber es g be immer noch eine redundante Assoziation SCHULE DARMSTADT o SWE Prof Dr W Weber h_da Fachbereich Informatik 182 6 2 Regeln zum Entwurf von Klassen Losung B Ohne transitive Assoziationen Object Diagram Bestellung ohne Zykel M ller Kunde Class Diagram Bestellung ohne Zykel Dezember Monats Auftrag Der Kunde als Auftraggeber ist 2 nun eindeutig bestimmt Bestellung eae SWE Prof Dr W Weber h_da Fachbereich Informatik DARMSTADT IVERSITY OF APPLIED SCIENCES 183 E 6 2 Regeln zum Entwurf von Klassen Regel 3 Vermeide transitive Assoziationen Class Diagram Bestellung mit Zykel 7 m Transitive Beziehungen bieten mehrere Wege fur eine Beziehung zwischen zwei Objekten gt in L sung A gibt es die direkte Beziehung gibt auf von Kunde zu Bestellung eine Beziehung von Kunde ber Auftrag zu Bestellung gt Man kann die Beziehungen mit unterschiedlichen Objekten assoziieren wie in L sung A m Vermeide transitive Assoziationen gt Transitive Beziehungen k nnen meist durch Weglassen von redundanten Assoziationen aufge
214. ziierung verschiedener Kompositions Objekte TextVerarbeitung schnell new TextVerarbeitung new EinfacherFormatierer TextVerarbeitung schick new TextVerarbeitung new TeXFormatierer TextVerarbeitung icon new TextVerarbeitung new ArrayFormatierer SWE Prof Dr W Weber h_da Fachbereich Informatik 198 6 3 Entwurfsmuster Das Strategie Muster Beispielcode fur die Absatzformatierung 3 Instanzen und Verzeigerungen fur Beispiel TextVerarbeitung icon new TextVerarbeitung new ArrayFormatierer bS Objekt der Klasse Textverarbeitung Repariere icon Pionter auf Objekt der KlasseTextverarveitung mein_formatierer Pionter auf Objekt der Klasse Arrayformatierer Objekt der Klasse Arrayformatierer Aufruf Formatiere icon gt Repariere Repariere ruft auf mein_formatierer gt Formatiere SWE Prof Dr W Weber h_da Fachbereich Informatik 199 6 3 Entwurfsmuster Das Strategie Muster Eigenschaften I m Zweck gt Das Strategiemuster erm glicht es einen Algorithmus unabh ngig von den ihn nutzenden Klienten zu variieren gt es k nnen sogar mehrere Algorithmen austauschbar gemacht werden gt Definiere eine Familie von Algorithmen kapsele jeden einzelnen und mache sie austauschbar m Auch bekannt als gt Policy m Motivation gt Es gibt unterschiedliche Algorithmen f r ein spezielles Problem gt Es ist nicht w nschenswert alle m g
215. zu lokalisieren SWE Prof Dr W Weber h_da Fachbereich Informatik 370 10 Metriken Messwerte und Schlussfolgerungen Wer viel misst misst viel Mist m Man kann fast alles messen Reinhard K Sprenger gt z B die Anzahl von Pizzadeckeln im Papierkorb als Ma f r den Terminverzug m und aus den Messungen fast alles folgern gt Die Auswahl der richtigen Metriken ist entscheidend gt Die Interpretation der Ergebnisse erfordert viel Erfahrung und Sachkenntnis m Beispiel 1 Was sagt uns eine Mitarbeiter Fluktuation von nur 2 Prozent gt Dass die Angestellten zufrieden sind und es der Firma gut geht oder gt dass die Mitarbeiter keine Alternative haben weil die Firma in einer exotischen Nische lebt m Beispiel 2 Was sagt uns die Anzahl der vergangenen Tage seit Projektbeginn im Vergleich zu anderen Projekten gt Nichts Aber mit schicken Grafiken kann Wally seinen unf higen Chef beeindrucken Dilbert 1996 SWE Prof Dr W Weber h_da Fachbereich Informatik 371 Hochschule Darmstadt Fachbereich Informatik software Engineering 10 1 Metriken und Tools h da san i ii HOCHSCHULE DARMSTADT u ii UNIVERSITY OF APPLIED SCIENCES fbi FACHBEREICH INFORMATIK SWE Prof Dr W Weber h_da Fachbereich Informatik 372 10 1 Metriken und Tools Tools E Tools gt messen und berechnen grundlegende Metriken gt bieten komplexe zusammengesetzte Qualit tsma e die Schlussfolgerungen aus

Software Engineering - Fachbereich Informatik

Contents

Download Pdf Manuals

Related Search

Related Contents