Home

Skript - Fachgebiet Echtzeitsysteme

Contents

1. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 141 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Weitere f r uns neue Funktionen von ClearCase U Versionierung kann sogar transparent hinter Filesystem Schnittstelle erfolgen nicht nur Quelltexte werden versioniert sondern auch daraus abgeleitete Objekte mit allen zugeh rigen Erzeugungsinformationen h ufig ben tigte abgeleitete Objekte werden im Cache gehalten weniger h ufig ben tigte bei Bedarf rekonstruiert neu erzeugt auch Verzeichnissse Directories unterliegen der Versionierung es k nnen neue Attribute f r bestimmte Arten versionierter Objekte eingef hrt werden propiert re Diff und Merge Algorithmen einzelner Werkzeuge k nnen integriert werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 142 i i Fachgebi SE II Konfigurationsmanagement Echtzeit systeme Gebr uchliche Verteilungsarchitekturen f r ClearCase Repositories One Way Propagation Centralized Main Repository Star Peer to Peer Solution Circular Propagation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 143 Fachgebiet AN SE II Konfigurationsmanagement Echtzeit 5 Geschichte der verteilten Versionierungs Systeme CVS 1990 Time 1990 U YCS Version Control System Q DVCS Distributed Version Contr
2. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 242 SE II Statische Programmanalyse amp Metriken Echtzeit systeme 3 7 Zus tzliche Literatur Ka00 St Kan Metrics and Models in Software Quality Engineering Addison Wesley 2nd Ed 2003 528 Seiten SD98 J Stasko J Domingue M Brown et al Software Visualization MIT Press 1998 562 Seiten SG96 M Shaw D Garlan Software Architecture Perspectives on an Emerging Discipline Prentice Hall 1996 Tha00 G Thaller Software Metriken einsetzen bewerten messen VT Verlag Technik Berlin 2 Auflage 2000 208 Seiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 243 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme 4 Dynamische Programmanalysen und Testen The older I get the more aggressive I get about testing I like Kent Beck s rule of thumb that a developer should write at least as much test code as production code Testing should be a continuous process No code should be written until you know how to test it Once you have written it write the tests for it Until the test works you cannot claim to have finished writing the code FS98 Lernziele Schwierigkeiten des systematischen Tests von Software verstehen Minimalstandards f r Test von Software kennenlernen wichtige Werkzeuge f r Performanzanalyse kennenlernen Werkzeuge f
3. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 178 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Kontrollflussgraph eines Programms Prozedur Methode PROCEDURE countVowels IN s Sentence OUT count INTEGER start Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER Kontrollflussgraph BEGIN mit 7 Knoten count 0 i 0 init 8 Kanten WHILE sli DO IF slil a OR sli e OR s il i OR slil 0 OR sli u THEN count count 1 END i i 1 ni END WHILE Nfinal END countVowels final Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 179 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Kontrollflussgraph formale Definition Ein Kontrollflussgraph eines Programms Prozedur ist ein gerichteter Graph G N E Nstart N final mit N ist die Menge der Anweisungen Knoten Nodes eines Programms Ec N xN ist die Menge der Zweige Kanten Edges zwischen den Anweisungen des Programms Near E N ist der Startknoten des Programms N na E N ist der Endknoten des Programms alternativ k nnte man auch eine Menge von Endknoten betrachten Es gilt f r den Kontrollflussgraphen gt IneN N ngap E keine in den Startknoten einlaufenden Kanten 2 JISneN
4. END i i 1 c i d i END WHILE en Noura found sli gt u s u i c found Nfinal END countVowels final Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 316 Fachgebi SE II Dynamische Programmanalysen und Testen Echtzeit systeme All p uses Test am Beispiel PROCEDURE countVowels IN s Sentence OUT count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot 1 f r d s bei nsan Pfad zu n und n u i d s O Nstart 2 f r d i bei nipi Pfad zu Nynie und n u count 3 f r d i bei n Pfad zu Nypi und n Ninit Es reicht also jede Eingabe mit folgendem Aus i Nwhile f hrungspfad nyart Ninit Nwhile Nif Ni Nwhile Nif Nif s Awhile gt Afinal Minimaler Testfall bb N Nfinal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 317 Fachgebi SE II Dynamische Programmanalysen und Testen Echtzeit systeme All c uses Test am Beispiel PROCEDURE countVowels IN s Sentence OUT count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot f r d 1 bei nipit Pfad zu n f r d count bei nipit Pfad zu non und definitionsfreier direkter Pfad zu n 1 f r d count bei nun Pfad ZU N oun Und definitionsfreier direkter Pfa
5. Manual PERT Chart Project Evaluation and Review Technique Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 401 Fachgebiet 4 SE II Management der Software Entwicklung Echtzeit Planung von Arbeitspaketabh ngigkeiten fr heste Anfangszeiten A 16 Tag Listen aufbau A 34 Tag Anfrage 6 Tage operationen A 1 Tag A 11 Tag A 16 Tag 0 Tage A 44 Tag A 54 Tag Datenbank g Integration schema Systemtest A 34 Ta 5 Tage 10 Tage g 10 Tage Update operationen A 34 Tag Analyse Design Abnahme A 16 Ta Benutzer Online Hilfe oberfl che Manual Vorw rtsberechnung von Startdatum f r Aufgabe fr heste Anfangszeit Max fr heste Vorg ngeranfangszeit Vorg ngerdauer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 402 Fachgebiet 4 SE II Management der Software Entwicklung Echtzeit Planung von Arbeitspaketabh ngigkeiten sp teste Endzeiten A 16 E 33 Listen aufbau A 34 E 43 Anfrage 6 Tage operationen 1 E 10 11 E 15 16 E 33 gt A 1 E 10 A 11 E 15 A 16 E 33 O Tage A 44 E 53 A 54 E 63 Datenbank Integration schema Systemtest A 34 E 43 5 Tage 10 Tage 10 Tage Update operationen A 34 E 53 Analyse Design Abnahme A 16
6. gt oder weitere Personen im Projekt besch ftigen Umrechnung auf konkrete Datumsangaben fehlt noch gt Ber cksichtigung von Wochenenden 5 Arbeitstage pro Woche gt ggf auch Ber cksichtigung von Urlaubszeiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 406 SE II Management der Software Entwicklung systeme Verfeinerung von Abh ngigkeiten und Zeitplanung Bislang gilt f r abh ngige Aktivit ten Al und A2 mit A2 h ngt von Al ab Finish to Start Folge FS Normalfolge Nachfolgeaktivit t A2 kann erst bearbeitet werden wenn Vorg nger Al vollst ndig abgeschlossen ist Al Finish 1 lag lt A2 Start Manchmal lassen sich aber abh ngige Aktivit ten auch parallel bearbeiten Start to Start Folge SS Anfangsfolge Aktivit ten k nnen gleichzeitig beginnen also Al Start lag lt A2 Start Finish to Finish Folge FF Endfolge Aktivit ten k nnen gleichzeitig enden also Al Finish lag lt A2 Finish Start to Finish Folge SF Sprungfolge nicht benutzen A1l Start lag lt A2 Finish fr her f r R ckw rtsrechnungen eingesetzt Des weiteren sind manchmal zus tzliche Verz gerungszeiten sinnvoll fr hestm glicher Beginn einer Aktivit t wird um Verz gerungszeit lag nach vorne oder hinten verschoben f r feste Puffer berlappungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Daten
7. Jeder Knoten des Kontrollflussgraphen mu mindestens einmal ausgef hrt werden Q Minimalkriterium da nicht mal alle Kanten des Kontrollflussgraphen traversiert werden Q viele Fehler bleiben unentdeckt Beispiel amp als Testfall gen gt ein konsonan tenfreier Satz wie etwa a Verschiebung von I I 1 in if Anweisung wird nicht entdeckt fehlerhafte Anweisung count 1 wird nicht entdeckt fehlerhafte Bedingung wird nicht entdeckt Q nicht betrachtet N Nstart Ninit Nwhile Nif Nendif Nfinal count 0 i 0 WHILE s i DO IF s il gt OR count 1 141 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 299 SE II Dynamische Programmanalysen und Testen Echtzeit systeme Kontrollflusstest Zweig berdeckung C4 Test Jede Kanten des Kontrollflussgraphen mu mindestens einmal ausgef hrt werden realistisches Minimalkriterium Nstart umfasst Anweisungs berdeckung Ninit count 0 i 0 Fehler bei Wiederholung oder anderer Kombination von Zweigen Nun WHILE sfi DO while bleiben unentdeckt Nif IF s i b OR Beispiel Testfall ax f r countVowels Ncount Count 1 w rde Kriterium bereits erf llen Zuweisung count 1 wird nicht als fehlerhaft erkannt ebenso nicht die Bedingung s i
8. kann ISO 9000 und CMM als Bausteine enthalten U ISO Norm SPiCE http www sqi gu edu aw SPICE integriert und vereinheitlicht CMM und ISO 9000 als ISO IEC 15504 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 388 i Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit SPICE Software Process Improvement and Capability dEtermination Internationale Norm f r Prozessbewertung und Verbesserung Sie bildet einheitlichen Rahmen f r Bewertung der Leistungsf higkeit von Organisationen deren Aufgabe Entwicklung oder Erwerb Lieferung Einf hrung und Betreuung von Software Systemen ist Norm legt Evaluierungsprozess und Darstellung der Evaluierungsergebnisse fest Unterschiede zu CMM Q orthogonale Betrachtung von Reifegraden und Aktivit tsbereichen deshalb andere Definition der 5 Reifegrade z B 1 alle Aktivit ten eines Bereiches sind vorhanden Qualit t der Aktivit ten noch unerheblich jedem Aktivit tsbereich oder Unterbereich kann ein anderer Reifegrad zugeordnet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 389 Fachgebiet Echtzeit SE II Management der Software Entwicklung systeme Aktivit tsbereiche von SPiCE Customer Supplier Bereich Aquisition eines Projektes Angebotserstellung gt Engineering Bereich Software Entwicklung Anforderungsanalyse Systemin
9. Aktionen durch grafische Darstel lung aussagenlogischer Ausdr cke Die weitere Vorgehensweise ist wie folgt Eine Wirkung wird ausgew hlt Zu der Wirkung werden alle Kombinationen von Ursachen gesucht die diese Wirkung hervorrufen F r jede gefundene Ursachenkombination wird eine Spalte der Entscheidungstabelle erzeugt Die Spalten der Entscheidungstabelle entsprechen Testf llen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 291 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Ursache Wirkungs Graph Beispiel aus SL12 quivalenz lassen gg PIN erneut Eingabe Wirkungen Aktionen trag erneut anfordern S KD op op i 2 aa Sai Be Q 3 N System zust nd gt Geld auszahlen Legende Ny Negation 4 logische UND Verkn pfung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 292 SE II Dynamische Programmanalysen und Testen Echtzeit systeme Entscheidungstabellen Beispiel aus SL12 a un Si nn permena o r a e a 1 Tale Karte einbehalten Nein Nein Nein Ja Nein Nein anfordern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 293 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Anwendunggsfallbasiertes Testen aus SL12 Ausgangspunkt f r diese Te
10. Klasse 5 Eingabe ist sehr lang und enth lt ganz viele Vokale Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 281 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Beispiel Lagerverwaltung einer Baustoffhandlung Holzbretter bei Holzbrettern wird die Holzart eingegeben als String Eiche Kiefer und Buche sind bekannt E es wird die Brettl nge eingegeben zwischen 100 und 500 cm E jede Lieferung erh lt eine Auftragsnummer die mit H beginnt und eine L nge von 1 bis 20 Zeichen hat U aus Brettl nge und Holzart errechnet sich der Preis des Auftrags Weitere Regeln f r die Bildung von quivalenzklassen bei Intervallen O aus quivalenzklassen die geschlossene Intervalle sind werden jeweils die beiden Grenzwerte und ein weiterer Wert z B aus der Mitte des Intervalls ausge w hlt ohne platzraubenden Zwischenschritt der Zerlegung in drei Teilintervalle einelementige quivalenzklasse und Wert aus dieser quivalenzklasse werden nicht unterschieden also statt v schreiben wir gleich v regul re Ausdr cke werden zur Definition v String quivalenzklassen eingesetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 282 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Grafische Darstellung von quivalenzklassen als Klassifikationsbaum Eingabewerte Holzart nn nge
11. Prinzipien echt verteilter Versionierungs Systeme wie git Jeder Entwickler hat eigenes lokales Versionierungs Repository mit Snapshots wie bei SVN Subversion zus tzlich zu blichen Arbeitskopien von Dateien Check Out Commit arbeiten erst mal nur auf eigenen lokalem Repository Austausch zwischen Repositories erfolgt mit Push und Pull zwischen bekannten Personen Rechnern via Email oder ssh oder Bei Push Pull werden parallele Revisionen angelegt die dann mit merge zusammengef hrt werden m ssen Bewertung Entwickler k nnen auch offline mit eigenem Repository arbeiten nderungen k nnen zu selbst gew hltem Zeitpunkt integriert werden merge Nach Platten Crash ist lokales Repository weg Hoher Aufwand f r Verteilung von nderungen an andere Entwickler merge Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 147 Fachgebiet z SE II Konfigurationsmanagement Echtzeit gt Ablauf der Propagation von nderungen Alice s Rechner Bob s Rechner O nderungen Revisionen von Bob werden als paralleler Zweig v Alice gepullt Alice merged dann ihre neueste Revision V4 mit neuester Revision V4 von Bob Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 148 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Verteilte Peer to Peer Versionierung Syst
12. Pro gramm Visualisierung bersetzung Instrumentierung Objektcode instr O Code Auswertung o Binden Generierung Bibliotheken Executable Statistiken Objektcode f r untersuchte Software wird vor Ausf hrung instrumentiert um zus tzliche Anweisungen erg nzt zus tzliche Anweisungen erzeugen w hrend der Ausf hrung statistische Daten ber Laufzeitverhalten Speicherplatzverbrauch Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 268 SE II Dynamische Programmanalysen und Testen Echtzeit systeme Aufbau eines Testrahmens gem SL12 Testfall 1 Testfall 2 De Testfalln Testtreiber i PoC Test gt U PoO ausgaben Vergleich Protokolle Laufzeitumgebung Teststummel Analysewerkzeuge Monitore Q Point of Control PoC Schnittstelle ber die Testobjekt mit Testdaten versorgt wird U Point of Observation PoO Schnittstelle ber die Reaktionen Ausgaben des Testobjekts beobachtet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 269 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Untersuchung des Laufzeitverhaltens eines Programms U wie oft wird jede Operation aufgerufen oder Quellcodezeile durchlaufen U welche Operation ruft wie oft welche andere Operation descendants auf oder von welchen Operationen callers wird ein Programm wie oft gerufen wieviel Prozen
13. SE II Management der Software Entwicklung systeme Ziele des Managements Hauptziel des Projektmanagements ist die Erh hung der Produktivit t Allgemeine Definition von Produktivit t Produktivit t Produktwert Aufwand oder Leistung Aufwand F r Software Entwicklung oft verwendete Definition Produktivit t Gr e der Software geleistete Mitarbeitertage Probleme mit dieser Definition m Ma f r Gr e der Software gt Ber cksichtigung der Produktqualit t gt Aufwand Mitarbeitertage gt Nutzen Return Of Investment Gr e der Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 359 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Einflussfaktoren f r Produktivit t ACF97 Angabe der Form 1 X steht f r Produktivit tssteigerung um maximal Faktor X Angabe der Form 1 Y steht f r Produktivit tsminderung um maximal Faktor Y gt Werkzeug Einsatz 1 1 6 gt Geeignete Methoden 1 1 9 Produktkomplexit t 1 2 4 Hohe Zuverl ssigkeitsanforderung 1 1 9 Firmenkultur corporate identity 1 11 Arbeitsumgebung eigenes B ro abschaltbares Telefon 1 Begabung der Mitarbeiter 1 10 Erfahrung im Anwendungsgebiet 1 1 6 gt gt gt gt gt gt gt Bezahlung Berufserfahrung kein messbarer Einfluss Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f
14. SE II Software Entwicklung Wartung und Re Engineering Echtzeit t Konstruktives Qualit tsmanagement zur Fehlervermeidung U technische Ma nahmen Sprachen wie z B UML f r Modellierung Java f r Programmierung gt Werkzeuge UML CASE Tool wie Together oder organisatorische Ma nahmen Richtlinien Gliederungsschema f r Pflichtenheft Programmierrichtlinien Standards f r verwendete Sprachen Dokumentformate Management gt Checklisten wie z B bei Ende einer Phase m ssen folgende Dokumente vorliegen oder Softwareprodukt erf llt alle Punkte des Lastenheftes Einhaltung von Richtlinien Standards und berpr fung von Checklisten kann durch Werkzeugeinsatz technische Ma nahmen erleichtert erzwungen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 21 SE II Software Entwicklung Wartung und Re Engineering Eentzeit gt 2 Beispiel f r die Wichtigkeit konstruktiver Qualit tssicherung Das Mariner Ungl ck Mariner 1 Venus Sonde musste 4 Minuten nach dem Start wegen unberechenbarem Flugverhalten zerst rt werden Ger chten zufolge war fol gender Softwarefehler in einem Fortranprogramm schuld Korrektes Programm Fehlerhaftes Programm DO 3 i 1 3 DO 3 i 1 3 irgendwelche Befehle irgendwelche Befehle 3 CONTINUE 3 CONTINUE Erl uterung korrektes Programm ist eine Schleife die dreimal ausgef hrt wird f r
15. ersten beiden Stellen der Revisionsnummer oft werden jedoch die ersten beiden Stellen der Revisionsnummern in cvs nicht verwendet und bleiben auf 1 1 gesetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 110 SE II Konfigurationsmanagement Echizeit gt t Hauptentwicklungszweig und mehrere Wartungsnebenzweige Entwicklungszweig f r Release V 4 1 Status code freeze Wartungszweig mit Tag V 4 1 12 alpha release potentiell instabil Wartungszweig mit Tag V 4 2 Q233 beta release hoffentlich stabiler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 111 SE II Konfigurationsmanagement Eentzeit gt S Hauptentwicklungszweig und ein Wartungsnebenzweig Entwicklungszweig f r Release V 4 1 Status code freeze Wartungszweig mit Tag V 4 1 a2 alpha release potentiell instabil Wartungszweig mit Tag V 4 2 beta release hoffentlich stabiler Wartung von V4 x wird eingestellt Strategie Fliegender Fisch Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 112 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Inversion von Wartungs und Entwicklungszweig Z1 Status code freeze S Entwicklungszweig f r Release V 4 1 Y Entwicklungszweig f r V 5
16. i 141 Kontrollflussfehler nur bedingte Inkr von i END END WHILE END countVowels countVowels baeiou count In diesem Fall ist die if Bedingung bei jedem Schleifendurchlauf wahr also hat man keine Zweig berdeckung Fehler werden nicht entdeckt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 302 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Minimale Mehrfachbedingungs berdeckungj test mit xbaeiou PROCEDURE hasVowels s Sentence VAR exists BOOLEAN Returns true iff sentence contains vowels Sentence must be terminated by a dot VAR i INTEGER BEGIN exists FALSE i 0 WHILE sli OR NOT exists DO Kontrollflussfehler OR statt AND falsch IF s i b OR sli a OR Kontrollflussfehler Pr fung auf b falsch THEN exists TRUE END i i 1 END WHILE END countVowels countVowels xbaeiou exists Man hat Zweig berdeckung Fehler werden trotzdem nicht gefunden Besser w ren hier viele kurze Eingaben mit einem Schleifendurchlauf anstelle einer langen Eingabe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 303 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme Modifizierter Bedingungs berdeckungstest Der modifizierte Bedingungs berdeckungstest Definierter Bedingungst
17. metrics General preferences for metrics Number of decimal places for Average and Standard Deviation IV Display project level metrics after a build completes Enable out of range warnings Display metrics in this order NSM Number of Static Methods TLOC Total Lines of Code CA Afferent Coupling RMD Normalized Distance NOC Number of Classes SIX Specialization Index RMI Instability NOF Number of Attributes NOP Number of Packages MLOC New Methods Lines of Code WMC Weighted methods per Class NORM Number of Overridden Methods NSF Number of Static Attributes NED Nested Block Depth NOM Number of Methods LCOM Lack of Cohesion of Methods YG McCabe Cyclomatic Complexity PAR Number of Parameters RMA bstractness NOI Number of Interfaces CE Efferent Coupling NSC Number of Children DIT Depth of Inheritance Tree Erase All Warnings Restore Defaults pply cme Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 237 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit 3 6 Zusammenfassung Die Visualisierung von Software ist sowohl beim Forward Engineering f r den Entwurf neuer Programmarchitekturen als auch beim Reverse Engineering f r das Studium von Legacy Software mit unbekannter Programmstruktur sehr hilfreich Werkzeugunterst tzte statische Analyseverfahren
18. systeme Grafische bersicht ber Aufgaben und Rollenverteilung Change Manager ProjectManager Developers Configuration Manage Integrator Create Project Setup Change M i Create Config M Create Workspace Create Workspace M Change Reques N Assign Task Make Change Deliver Change Integrate Changes Require Changes Create Baseline Promote Baseline Make Audit Make Release Monitor Projeci Bu Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 62 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Workspaces f r das Konfigurationsmanagement Public Workspace Repository Check Out Check In Check Out Check In amp Update amp Update Add Developer Workspace s Integrator Workspace alle Dokumente Objekte Komponenten zu einem bestimmten Projekt werden in einem gemeinsamen Repository public workspace aufgehoben im Repository werden nicht nur aktuelle Versionen sondern auch alle fr heren Versionen aller Dokumenten gehalten beteiligte Entwickler bearbeiten ihre eigenen Versionen dieser Dokumente in ihrem privaten Arbeitsbereich private workspace developer workspace es gibt genau einen Integrationsarbeitsbereich integrations workspace f r die Systemintegration Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 63 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Aktivit ten be
19. E 33 Benutzer Online Hilfe oberfl che 15 Tage A 34 E 53 Manual 20 Tage R ckw rtsberechnung von Enddatum f r Aufgabe sp teste Endzeit Min sp teste Nachfolgerendzeit Nachfolgerdauer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 403 Fachgebiet z SE II Management der Software Entwicklung Echtzeit Planung von Arbeitspaketabh ngigkeiten kritische Pfade u Aufgaben A 16 E 33 Listen aufbau A 34 E 43 Anfrage 6 Tage operationen A 1 E 10 A 11 E 15 A 16 E 33 0 Tage A 44 E 53 A 54 E 63 Datenbank Integration schema Systemtest A 34 E 43 5 Tage 10 Tage 10 Tage Update operationen A 34 E 53 Analyse Design Abnahme A 16 E 33 Benutzer Online Hilfe oberfl che 15 Tage A 34 E 53 Manual 20 Tage Berechnung kritischer Pfade mit kritischen Aufgaben f r kritische Aufgabe gilt fr heste Anfangszeit Dauer sp teste Endzeit 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 404 SE II Management der Software Entwicklung Echizeit gt 2 Zusammenfassung der Berechnung Q Vorw rtsberechnung fr hester Anfangszeiten f r Aufgaben fr heste Anfangszeit erster Aufgabe 1 fr heste Anfangszeit von Folgeaufgabe Maximum fr heste Anfangszeit Dauer einer Vorg
20. Ein Modul Paket bietet ber seine Schnittstelle Dienste an und benutzt importiert zu ihrer Realisierung Dienste anderer Module Pakete Ein Modul fasst verwandte Prozeduren Klassen zusammen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 162 Fachgebiet 4 y SE II Statische Programmanalyse amp Metriken Echtzeit systeme Programmarchitekturen in C U C besitzt keine Sprachmittel zur Deklaration von Teilsystemen Oft werden Dateib ume Subdirectories zur Teilsystembildung eingesetzt U Module werden in C durch cpp cc Dateien realisiert h eader Dateien definieren wie in C die Schnittstellen von Modulen U include Beziehungen textuelles Einkopieren von h Dateien realisieren Modulimporte Zus tzliche Programmstrukturen in C U Vererbungshierarchien auf Klassen sonstige Beziehungen zwischen Klassen Kontrollfluss eines Programms E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 163 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Softwarearchitekturen sind mehr als Teilsysteme und Module Q Inden 80er Jahren wurden Programmarchitekturen mit sogenannten Module Interconnection Languages MIL definiert die nur Module und Import Beziehungen kennen Seit den 90er Jahren werden auch Architecture Description Languages ADLs eingesetzt die Komponenten mit Eing ngen und Ausg ng
21. Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Erl uterungen zum Variantenbeispiel SW Produktlinie Q es handelt sich um die Softwarearchitektur eines fiktiven Assemblers die aus 8 Moduln Pakete Komponenten besteht und in 6 Varianten existiert es gibt ein Hauptprogramm assembler das ein Assemblerprogramm in 2 oder 3 Durchl ufen in Maschinencode bersetzt ohne und mit Behandlung von Makros passO expandiert Makros in dem Assemblerprogramm liest Eingabe aus Datei schreibt Ausgabe auf Datei pass1 merkt sich Sprungmarken Konstanten und deren Werte in einer Symboltabelle pass2 f hrt die eigentliche bersetzung mit Hilfe der Symboltabelle durch messages bietet eine Abbildung von Fehlernummern auf Texte in Dateien Implementierung h ngt in kleinen Teilen von Sprache und Betriebssystem ab files bildet die Schnittstelle zum Dateisystem f r Unix und Windows globals sind Konstanten Funktionen etc die berall ben tigt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 99 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Software Produktlinien Entwicklung Variantenmanagement im Gro en Eine Software Produkt Linie SPL ist eine Menge verwandter Softwaresysteme f r eine bestimmte Anwendungsdom ne U die auf Basis einer gemeinsamen Plattform Rahmenwerk entwickelt werden Die Plattform enth lt all
22. Nfa N E keine aus dem Endknoten auslaufenden Kanten Manchmal wird zus tzlich gefordert dass Kontrollflussgraph zusammenh ngend ist VneN es gibt einen Pfad von n zU n VneN esgibteinen Pfad von n nach ngna Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 180 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Pfade im Kontrollflussgraphen formale Definition Ein Pfad in einem Kontrollfluss Graphen G N E Ngars Nfina ist eine h MUENENEEDIARE Knotenfolge n Ng sodass gilt 7 Knoten 8 Kanten gt n n EN Viel kl n n eE Ein zyklenfreier Pfad enth lt keinen Knoten zweimal Neount 1 Ein Zyklus ist ein Pfad mit n n Beispiel f r einen Pfad Netart gt Ninit gt P while gt Dir gt Deount gt Di gt Awhile gt Der Pfad ist nicht zyklenfrei Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 181 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Kontrollflussgraphsegmente formale Definition Ein Segment oder Block eines Kontrollflussgraphen G N E Ngyars Nfina 1st ein Knoten s der einen Teilgraph G N E N sats D fina von G ersetzt der aus einem zyklenfreien Pfad n tan Nj Nk N fna besteht mit N n Ng DD N c NAE ENr Nx lt N AM ins Nsa E D Vn eN n mat I neN
23. Principles and Techniques Springer Verlag 2005 467 Seiten Ve00 G Versteegen Projektmanagement mit dem Rational Unified Process Springer Verlag 2000 Ve03 G Veersteegen Hrsg G Weischedel Konfigurationsmanagement Springer Verlag 2003 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 151 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme VSH01 G Versteegen K Salomon R Heinhold Change Management bei Software Projekten Springer Verlag 2001 Wh00 A Zeller J Krinke Programmierwerkzeuge Versionskontrolle Konstruktion Testen Fehlersuche unter Linux dpunkt Verlag 2000 Wie11 S Wiest Continuous Integration mit Hudson Jenkins Grundlagen und Praxiswissen f r Einsteiger und Umsteiger dpunkt verlag 2011 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 152 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 3 Statische Programmanalyse amp Metriken Statische Codeanalyse verlangt ein stures monotones Anwenden von relativ einfachen Regeln auf oft umfangreichen Code Diese Aufgabe erfordert keinerlei Kreativit t aber eine sehr gro e bersicht und Kontrolle Statische Codeanalyse ist daher pr destiniert zur Auto matisierung durch Werkzeuge Ich empfehle Ihnen diese Techniken entweder werkzeuggest tzt oder gar nicht einzusetzen LiO2 Lernziele verschiedene Arten der statisc
24. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 308 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Abstraktes Beispiel f r Boundary Interior Test IF b1 THEN ni ELSE n2 END WHILE b2 DO n3 WHILE b3 DO IF b4 THEN n4 ELSE n5 END END END Durchl ufe f r modifizierten Boundary Interior Test n1 n2 kein Durchlauf ni n3 n2 n3 1x ussere 0x innere Schleife n1 n3 n4 n2 n3 n4 1x ussere 1x innere Schleife n1 n3 n5 n2 n3 n5 n1 n3 n4 n4 n2 n3 n4 n4 1x ussere 2x innere Schleife n1 n3 n4 n5 n2 n3 n4 n5 n1 n3 n5 n4 n2 n3 n5 n4 n1 n3 n5 n5 n2 n3 n5 n5 n1 n3 n3 n2 n3 n3 2x ussere 0x innere Schleife Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 309 i Fachgebiet g 5 SE II Dynamische Programmanalysen und Testen Echtzeit Bewertung der Kontrollflusstests Q Anweisungs berdeckung wird durch RTCA DO 178B Standard f r Software Anwendungen in der Luftfahrt der Kritikalit tsstufe C gefordert Software deren Ausfall zu einer bedeutenden aber nicht kritischen Fehlfunktion f hren kann Zweig berdeckung wird durch RTCA DO 178B Standard f r Software Anwen dungen in der Luftfahrt der Kritikalit tsstufe B gefordert Software deren Aus fall zu schwerer aber noch nicht katastrophaler Systemfehlfunktion f hren kann modifizierte Bedingungs
25. S 283 328 Nicht zu alter Aufsatz mit berblickscharakter zum Thema dieses Kapitels Beschr nkt sich allerdings im wesentlichen darauf die drei Systeme OIKOS Ambriola EPOS Conradi und SPADE Fugetta der drei Autoren miteinander zu vergleichen Es handelt sich dabei um Systeme der zweiten Generation die in die sem Kapitel nicht vorgestellt wurden Ba98 H Balzert Lehrbuch der Softwaretechnik Band 2 Software Management Software Qualit tssicherung Unternehmensmodellierung Spektrum Akademischer Verlag 1998 Hier findet man fast alles Wissenswerte zum Thema Management der Software Entwicklung BP84 V R Basili B T Perricone Software Errors and Complexity An Empirical Investigation Communicati ons of the ACM Vol 27 No 1 42 52 ACM Press 1984 Eine der ersten Publikationen zu empirischen Untersuchungen ber den Zusammenhang von Software komplexit t und Fehlerh ufigkeit K Beck Extreme Programming Explained Embrace the Change Addison Wesley 1999 Eins der Standardwerke zum Thema XP geschrieben vom Erfinder Mehr Bettlekt re mit Hintergrundin formationen und Motivation f r XP Techniken als konkrete Handlungsanweisung K M Dymond CMM Handbuch Springer Verlag 2002 Einfach zu verstehende schrittweise Einf hrung in CMM Levels und Upgrades von einem Level zum n chsten in deutscher Sprache Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 410 SE II Management
26. T E Datei Bearbeiten Ansicht Favoriten Extras Me Oz O1 2 MI Ann Koran in EB JS Adresse A C Vocal projects tinycad doxygen html index html Wechseln zu Links A amp CDocResource JAA CDrawingObject le 9 5 a w 5 2 TEF LEALLAS EES E S 43413 pazi a B E B B D a 88 77 a a w w e 5 a n u 2 w 2E E CDrawCentre my S amp amp amp 5 E CDrawError E CDrawLine m m m m A J E m s 5 m 5A a amp CDrawRectOutline E08 TE BR FB E 3 w m ws gt S List of all members Protected Member Functions CDrawRectOutline CTinyCadDoc pDesign virtual void Display BOOL erase TRUE void DrawHandles Context amp dc virtual int IsInsideField CPoint p virtual void MoveField int w CPoint r virtual int SetCursorEdit CPoint p Constructor amp Destructor Documentation CDrawRectOutline CDrawRectOutline CTinyCadDoc pDesign inline protected Member Function Documentation void CDrawRectOutline Display BOOL erase TRUE protected virtual Reimplemented from CDrawingObject void CDrawRectOutline DrawHandles Context amp dc protected int CDrawRectOutline IsInsideField CPoint p protected virtual EI CLibrarsFile ei Reimolemented from CDrawineObiect se PT Te start BJ Outiook He E Microsoft P windows T U Freew
27. Testmanagement startet mit Projektbeginn vs Testaktivit ten werden erst nach der Erstellung der Software gestartet gt Testerstellungsansatz berdeckungskriterien Orientierung an Standards f r Vorgehensmodelle vgl Kapitel 5 U Testen und Risiko Risiken beim Testen Ausfall von Personal Risikobasiertes Testen Fokus auf Minimierung von Produktrisiken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 351 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Meldung von Fehlern Fehlermanagement Es m ssen alle Informationen erfasst werden die f r das Reproduzieren eines Fehlers notwendig sind Eine Fehlermeldung kann wie folgt aufgebaut sein Status Bearbeitungsfortschritt der Meldung Neu Offen Analyse Abgewiesen Korrektur Test Erledigt Klasse Klassifzierung der Schwere des Problems Menschenleben in Gefahr Systemabsturz mit Datenverlust Sch nheitsfehler Priorit t Festlegung der Dringlichkeit mit der Fehler behoben werden muss sofort da Arbeitsablauf blockiert beim Anwender Anforderung die Stelle n in der Anforderungsspezifikation auf die sich der Fehler bezieht Fehlerquelle in welcher Softwareentwicklungsphase wurde der Fehler begangen Fehlerart Berechnungsfehler Testfall genaue Beschreibung des Testfalls der Fehler ausl st Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f
28. Werkzeuge f r Last und Performanztests dynamische Analysen Laufzeitmes sungen Speicherplatzverbrauch Komparatoren vergleichen erwartete mit tats chlichen Ergebnissen filtern unwesentliche Details k nnen ggf auch Zustand von Benutzeroberfl chen pr fen Werkzeuge zur berdeckungsanalvyse f r gew hlte berdeckungsmetrik wird Buch dar ber gef hrt wieviel Prozent berdeckung erreicht ist welche Programmausschnitte noch nicht berdeckt s nd Werkzeuge f r statische Analysen Berechnung von Metriken Kontroll und Datenflussanomalien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 354 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit 4 8 Zusammenfassung Dynamische Programmanalysen und das traditionelle Testen sind die wichtigsten Mittel der analytischen Qualit tssicherung Mindestens folgende Ma nahmen sollten immer durchgef hrt werden U Suche nach Speicherlecks und Zugriff auf nichtinitialisierte Speicherbereiche oder falsche Speicherbereiche mit geeigneten Werkzeugen U automatische Regressions Testdurchf hrung mit entsprechenden Frameworks zur Testautomatisierung berpr fung der Zweig berdeckung durch Testf lle anhand von Kontrollfluss graph durch Werkzeuge Verwendung von Black Box Testverfahren mit quivalenzklassenbildung f r Eingabeparameter Objekte zur Bestimmung von Testf llen Einbau m glichst vi
29. b Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 300 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Kontrollflusstest Bedingungs berdeckung Jede Teilbedingung einer Kontrollflussbedingung z B von if oder while Anweisung mu einmal den Wert true und einmal den Wert false annehmen atomare Bedingungs berdeckungj test keine Anforderung an Gesamtbedingung bei falschem countVowels reicht Testfall baeiou gt umfasst nicht mal Anweisungs berdeckung Beispiel minimale Mehrfachbedingungs berdeckung test gt jede Teil und Gesamtbedingung ist einmal true und einmal false bei falschem countVowels reicht Testfall xbaeiou Orientierung an syntaktischer Struktur von Kontrollflussbedingungen Bedingung umfasst Zweig berdeckung trotzdem werden viele Bedingungsfehler nicht entdeckt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 301 i Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit Atomare Bedingungs berdeckungj test mit baeiou PROCEDURE hasVowels s Sentence VAR exists BOOLEAN Returns true iff sentence contains vowels Sentence must be terminated by a dot VAR i INTEGER BEGIN exists FALSE i 0 WHILE sli DO IF s i b OR sli a OR Kontrollflussfehler Pr fung auf b falsch THEN exists TRUE
30. n n e E genau eine auslaufende Kante D Vn eN n ant I meN n n e E genau eine einlaufende Kante Einlaufende Kanten von n a und auslaufende von n fna werden auf s umgelenkt Beispiel f r ein Segment kompakte Notation von Graphen Er Nstart EN Nstart Ncount 0 ZU einem Knoten Segment Fi Segment zusammengefasster Teilgraph Mit Ncount o als Startknoten 5 und n o als Endknoten Nwnhile Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 182 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Datenflussattribute eines Kontrollflussgraphen Die Anweisungen eines Kontrollflussgraphen G N E N ar Nginap besitzen Daten flussattribute die den Zugriffen auf Variable Parameter in den Anweisungen entsprechen gt ne N besitzt das Attribut def v oder kurz d v falls n eine Zuweisung an v enth lt Wert von v definiert gilt auch f r Eingabeparameter bei nur n e N besitzt das Attribut c use v oder kurz c v falls n eine Berechnung mit Zugriff auf v enth lt c compute implizite Zuweisung an Ausgabeparameter am Ende ist auch c use n N besitzt das Attribut p use v oder kurz p v falls n eine Fallentscheidung mit Zugriff auf v enth lt p predicative n e N besitzt das Attribut r v falls es das Attribut c v oder p v besitzt also lesend auf v zugreift r reference dient nur der Zusammen fassung von c v
31. r Datentechnik Seite 352 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Arten von Testwerkzeugen 1 Testwerkzeuge werden oft Computer Aided Software Test Werkzeuge genannt CAST Tools Man unterscheidet folgene Arten von CAST Tools U Werkzeuge zum Testmanagement und zur Testplanung Erfassen von Testf llen Abgleich von Testf llen mit Anforderungen Verwaltung und statistische Aus wertung von Fehlermeldungen Werkzeuge zur Testspezifikation Testdaten und Soll Werte f r zugeh rige Ergebnisse werden manuell festgelegt und verwaltet Testdatengeneratoren aus Softwaremodellen Code Grammatiken werden automatisch Testdaten generiert Testtreiber passend zu Schnittstellen von Testobjekten werden Testtreiber bzw Testrahmen zur Verf gung gestellt die die Aufruf von Tests mit bergabe von Eingabewerten Auswertung der Ergebnisse etc abwickeln Simulatoren bilden m glichst realit tsnah Produktionsumgebung nach mit Simulation von anderen Systemen Hardware Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 353 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme Arten von Testwerkzeugen 2 Testroboter Capture amp Replay Werkzeug zeichnet interaktive Benutzung einer Bedienungsoberfl che auf und kann Dialog wieder abspielen solange sich Ober fl che nicht zu stark ver ndert
32. rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 199 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Korrigiertes ggT Programm mit verbleibender du Datenflussanomalie PROCEDURE ggT IN m n INTEGER OUT o INTEGER start BEGIN Q die Anweisung m 0 f hrt statisch o Nn gesehen zu einer du Anomalie da while Schleife WHILE n gt 0 DO nach Zuweisung beendet sein k nnte IF m gt n THEN tats chlich passiert aber zur Laufzeit das m m n wenn m ein neuer Wert bei zuge ELSE wiesen wird muss n gr er als O sein dann wird die while Schleife wieder betreten und auf m lesend zugegriffen n m if n gt 0 THEN l l Saa es gibt also in Realit t keine nutzlose m 0 Zuweisung an m weitere scheinbare du Anomalie wird durch die Zuweisung hervorgerufen echte du Anomalie auf m wird f r n O nie END ggf lesend zugegriffen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 200 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Probleme mit statischer Datenflussanalyse f r Datenstrukturen funktioniert nicht gut f r komplexe Datenstrukturen wie Felder Arrays bei denen man jede einzelne Komponente wie eigene Variable behandeln m sste s i x y sfk Obiges Programmfragment hat keine du und ur Anomalie falls i k aber die Gleichheit von i und k oder anderen Ausdr cke
33. schen Rahmen zur Qualit tssicherung fest Das ISO 9000 Zertifikat best tigt dass die Verfahren eines Unternehmens der ISO 9000 Norm entsprechen Wichtige Teile OD ISO 9000 1 allgemeine Einf hrung und berblick U ISO 9000 3 Anwendung von ISO 9001 auf Softwareproduktion U ISO 9001 Modelle der Qualit tssicherung in Design Entwicklung Produktion Montage und Kundendienst U ISO 9004 Aufbau und Verbesserung eines Qualit tsmanagementsystems Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 380 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Von ISO 9000 3 vorgeschriebene Dokumente Vertrag Auftraggeber Lieferant T tigkeiten des Auftraggebers Behandlung von Anforderungs nderungen Annahmekriterien Abnahmetest Spezifikation funktionale Anforderungen Ausfallsicherheit Schnittstellen des Softwareprodukts Entwicklungsplan Zielfestlegung Projektmittel Entwicklungsphasen Management eingesetzte Methoden und Werkzeuge Qualit tssicherungsplan Qualit tsziele messbare Gr en Kriterien f r Ergebnisse v Entwicklungsphasen Planung von Tests Verifikation Inspektionen Testplan Teststrategie f r Integrationstest Testf lle Testwerkzeuge Kriterien f r Testvollst ndigkeit Testende Wartungsplan Umfang Art der Unterst tzung Konfigurationsmanagement Plan f r Verwaltung von Softwareversionen und Softwarevar
34. siehe Abschnitt 4 3 davon abgeleitetete in der Praxis durchf hrbare Verfahren gt boundary test alle Pfade auf denen Schleifen maximal einmal durchlaufen werden ohne besondere praktische Bedeutung boundary interior test alle Pfade auf denen Schleifen maximal zweimal in direkter Folge durchlaufen werden Achtung Anzahl Pfade explodiert bei geschachtelten Schleifen und vielen bedingten Anweisungen gt modifizierter boundary interior test bei geschachtelten Schleifen wird beim Durchlauf einer u eren Schleife die Anzahl der inneren Schleifen durchl ufe nicht unterschieden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 307 i Fachgebiet g y SE II Dynamische Programmanalysen und Testen Echtzeit Abstraktes Beispiel f r Boundary Interior Test IF b1 THEN ni ELSE n2 END WHILE b2 DO n3 WHILE b3 DO IF b4 THEN n4 ELSE n5 END END END Durchl ufe f r Boundary Interior Test n1 n2 kein Durchlauf n1 n3 n2 n3 1x ussere 0x innere Schleife n1 n3 n4 n2 n3 n4 1x ussere 1x innere Schleife n1 n3 n5 n2 n3 n5 n1 n3 n4 n4 n2 n3 n4 n4 1x ussere 2x innere Schleife n1 n3 n4 n5 n2 n3 n4 n5 n1 n3 n5 n4 n2 n3 n5 n4 n1 n3 n5 n5 n2 n3 n5 n5 n1 n3 n3 n2 n3 n3 2x ussere 0x innere Schleife n1 n3 n4 n3 n2 n3 n4 n3 2x ussere 1x u 0x innere Schleife es fehlen noch 7 Zeilen
35. systeme Deltaspeicherung von Revisionen als gerichtete Graphen a logische Struktur b sccs Vorw rtsdeltas c R ckw rtsdeltas d res Vorw rts und R ckw rtsdeltas Hauptzweig Legende Revision u direkt verf gbar zu rekonstruieren Nachfolgerelation Rekonstruktionsrelation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 83 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A Concurrent Version Management System CVS Zun chst Aufsatz auf RCS sp ter Reimplementierung das Revisionsverwaltung f r ganze Directoryb ume durchf hrt und zus tzlich anbietet optimistisches Sperrkonzept mit fast automatischem Verschmelzen merge von parallel durchgef hrten nderungen in verschiedenen privaten Arbeitsbereichen Dreiwegeverschmelzen mit manueller Konfliktbehebung Revisionsidentifikation und damit rudiment res Releasemanagement auch durch frei w hlbare Bezeichner gt Auszeichnen zusammengeh riger Revisionen durch symbolische Namen mit Hilfe sogenannter Tags diverse Hilfsprogramme wie z B cvsann das jeder Zeile einer Textdatei die Information voran stellt wann sie von wem zum letzten Mal ge ndert wurde Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 84 Fach
36. tigt aber nur 0 39 der Laufzeit die Ausf hrungszeit variiert sehr stark 61 bis 247 ms Durchschnitt liegt aber nahe beim Maximum mit 244 ms die Methode OnDraw wird von Main 51 mal sowie von UpdateWindow und DoModal jeweils einmal im Beispiellauf gerufen die Methode OnDraw ruft ihrerseits die Methoden SetPixel Snap am meisten Zeit ben tigen die 327 124 Aufrufe von SetPixel n mlich fast 75 der Zeit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 272 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit systeme y Untersuchung des Speicherplatzverhaltens eines Programms U welche Operationen fordern wieviel Speicherplatz an geben ihn frei U wo wird Freigabe von Speicherplatz vermutlich bzw bestimmt vergessen memory leak Speicherloch bestimmt vergessen Objekt lebt noch kann aber nicht mehr erreicht werden Garbage Collector von Java w rde es entsorgen vermutlich vergessen Objekt lebt noch und ist erreichbar wird aber nicht mehr benutzt Garbage Collector von Java kann es nicht freigeben wo wird auf bereits freigegebenen Speicherplatz zugegriffen nur f r C bzw wo wird Speicherplatz mehrfach freigegeben nur f r C wo wird auf nicht initialisierten Speicherplatz zugegriffen anders als bei der statischen Programmanalyse wird f r jede Feldkomponente Speicherzelle getrennt Buch dar ber gef hrt wo finden Zugriffe jenseits der
37. und Apply Patch Funktionen in Eclipse benutzen genau das gerade eingef hrte Unified Diff Format Dabei werden bei der Erzeugung von Hunks wohl folgende Heuristiken Regeln verwendet ein Hunk scheint in der Regel mit drei unver nderten Kontextzeilen zu beginnen inklusive Leerzeilen zwei Bl cke ge nderter Zeilen m ssen durch mindestens sieben unver nderte Zeilen getrennt sein damit daf r getrennte Hunks erzeugt werden Bei der Anwendung von Patches werden folgende Heuristiken Regeln verwendet werden der Kontext oder die zu l schenden Zeilen eines Patches so nicht gefun den dann endet die Patch Anwendung mit einer Fehlermeldung befindet sich die zu patchende Stelle eines Textes nicht mehr an der angegebenen Stelle Zeile so wird trotzdem der Patch angewendet gibt es mehrere identische Stellen in einem Text auf die ein Patch angewendet werden kann so wird die Stelle ver ndert die am n chsten zur alten Position ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 78 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Eigenschaften von SCCS f r beliebige Text Dateien verwendbar und nur f r solche Schreibsperren auf ausgecheckten Revisionen E Revisionsb ume mit manuellem Konsistenthalten von Entwicklungszweigen E Rekonstruktionszeit von Revisionen steigt linear mit der Anzahl der Revisionen Durchlauf durch Bl
38. 2 Hypothese es gibt einfachen Zusammenhang zwischen der gemessenen Softwarekomplexit t und der Anzahl sp ter gefundener Fehler pro Codezeile Frage Wie validiert man all diese Hypothesen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 210 Fachgebiet 4 y SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiel f r eine falsche Hypothese Modularisierung von Programmen verringert d e Zahl der Fehler also steigende Anzahl von Modulen verursacht fallende Fehlerzahl Gemessene Werte f r verschiedene Projekte y x Projektklasse 1 klein o Projektklasse 2 gross Anzahl Fehler pro Zeile Code p Anzahl Module Die hier aufgetragenen Werte sind fiktiv reale Untersuchungen haben aber qualitativ hnliche Ergebnisse geliefert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 211 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Eine Erkl rung f r tats chlichen Zusammenhang Modulzahl Fehlerzahl gt Schnitt x Projektklasse 1 klein stellen o Projektklasse 2 gross fehler x pro Zeile Code p Anzahl Module f r gleiche Programmgr e sonstige x Projektklasse 1 klein nn o Projektklasse 2 gross pro Zeile Code gt Modulgr e Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 212
39. 3 iteration 4 iteration 5 sicht nm aa m mm zum um zum un u un Firma IBM ehemals Rational dominiert e Entwicklung der Standard OO Modellierungssprache UML und des zugeh rigen Vorgehensmodells Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 367 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Phasen der Lebenszyklusgenerationen Inception Vorbereitung Definition des Problembereichs und Projektziels f r Produktgeneration mit Anwendungsbereichsanalyse Domain Analysis und Machbarkeitsstudie f r erste Generation aufw ndiger bei Erfolg weiter zu Elaboration Entwurf erste Anforderungsdefinition f r Produktgeneration mit grober Softwarearchitektur und Projektplan ggf mit Rapid Prototyping bei Erfolg weiter zu Construction Konstruktion Entwicklung der neuen Produktgeneration als eine Abfolge von Iterationen mit Detailanalyse design wie beim evolution ren Vorgehensmodell bei Erfolg weiter zu Transition Einf hrung Auslieferung des Systems an den Anwender inklusive Marketing Support Dokumentation Schulung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 368 SE II Management der Software Entwicklung Echizeit gt 2 Eigenschaften des Rational Unified Prozesses RUP Q modellbasiert f r die einzelnen Schritte des Prozesses ist festgelegt welc
40. Auftragsnummer Eiche Buche Kiefer sonst Minint 0 1 99 100 500 501 Maxlnt Hn Hnn n sonst I NA AN N Ahorn Minint 1 0 1 50 99 100 250 500 501 502 MaxInt Hi H00 0000 123 8 zun chst wird Eingabewerte in alle Eingabeparameter des Programms zerlegt zusammengesetzte Eingabeparameter werden weiter zerlegt nicht im Beispiel schlie lich wird der Wertebereich eines atomaren Eingabeparameters betrachtet der Wertebereich wird in quivalenzklassen hnlicher Werte zerlegt dabei werden auch nicht erlaubte Eingabewerte Fehlerklassen betrachtet ebenso werden extreme erlaubte Werte Stresstestklassen betrachtet E E E J E E E aus jedem Wertebereich werden Repr sentanten f r den Test ausgew hlt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 283 SE II Dynamische Programmanalysen und Testen Echtzeit y g y systeme Unvollst ndige fehlerhafte Auswahl von Eingabewertekombinationen Eingabewerte Holzart u nn Auftragsnummer Eiche Buche Kiefer sonst Minint 0 1 99 100 500 501 Maxlnt Hnn n sonst N A S SS Ahorn min 1 0 1 50 99 100 250 500 501 502 max H1 H00 0000 123 8 zul ssige Eingabe Test1 fehlerhafte Eingabe Test2 Stresstest O Test3 Test4 Problem trotz Bildung von quivalenzklassen bleiben zu viele m gliche Eingabe wertekombinationen im Beispiel s
41. Beispiel f r makefiles Es soll ein makefile geschrieben werden das folgende Anforderungen erf llt U beim Aufruf von make ohne Parameter sollen im aktuellen Verzeichnis alle Dateien mit der Endung gif in Dateien mit der Endung jpg bersetzt werden daf r wird das Kommando convert verwendet das Konvertieren soll nur passieren wenn die jpg Datei zu einer gif Datei noch nicht existiert oder einen lteren Zeitstempel besitzt alle jpg Dateien mit zugeh riger gif Datei werden zu einer Datei einem Archiv images zip zusammengepackt mit dem Kommando zip die zip Datei wird nur erzeugt wenn vorher mindestens eine jpg Datei neu erzeugt wurde nur neue jpg Dateien werden im Archiv ausgetauscht f r ein einfaches makefile k nnen sie davon ausgehen dass das aktuelle Verzeichnis nur die Dateien tobias gif johannes gif markus gif und andy jpg enth lt ein fortgeschrittenes makefile muss f r beliebig viele gif und jpg Dateien funktionieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 131 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Einfaches makefile f r bekannte Dateien default images zip images zip tobias jpg johannes jpg markus jpg zip u images zip tobias jpg johannes jpg markus jpg tobias jpg tobias gif convert tobias gif tobias jpg johannes jpg johannes gif convert johannes gif johannes jpg markus jpg markus gif convert markus
42. Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Testen von Hypothesen mit Regressionsrechnung Schnitt Y x Projektklasse 1 klein stellen o Projektklasse 2 gross fehler x pro Zeile Code X Be Anzahl Module Getestet werden soll die Hypothese dass ein linearer Zusammenhang zwischen der Anzahl der Module und der Anzahl der Schnittstellenfehler pro Zeile Code in einem Programm besteht l es wird die Gerade ermittelt die die Messwerte nach der Methode der kleinsten Fehlerquadrate am besten approximiert nach Gauss es wird berechnet wie gut die Streuung der Messwerte in Y Richtung durch zuf llig verteilte Messfehler um berechnete Gerade herum erkl rt wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 213 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Berechnung der Regressionsgeraden Gesucht wird Y b b X Gegeben sind Paare von Messwerten x y gt lt gt Xp Yn Berechnung der Mittelwerte Mittelwert x x x n Mittelwert y y y n Berechnung von Koeffizient b ZN DRIN O E 7 EEEE Pe 26 2 1 Berechnung von Koeffizient by Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 214 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Berechnung des Korrelationskoeffizienten r Sa x PL F i 1 man
43. OR Kontrollflussfehler falsche Pr fung auf b THEN count 1 Berechnunggsfehler count wird nicht erh ht i 141 Kontrollflussfehler nur bedingte Inkr von i END END WHILE END countVowels countVowels to be or not to be count Schnittstellenfehler dot im Satz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 297 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Grundideen des kontrollflussbasierten Testens mit im Grunde zun chst beliebigen Verfahren werden Testf lle festgelegt diese Testf lle werden alle ausgef hrt und dabei wird notiert welche Teile des Programms durchlaufen wurden es gibt meist ein Test Orakel dass f r jeden ausgef hrten Testfall ermittelt ob die berechnete Ausgabe Verhalten des Programms korrekt ist schlie lich wird festgelegt ob die vorhandenen Testf lle den Kontrollfluss des Programms hinreichend berdecken ggf werden solange neue Testf lle aufgestellt bis hinreichende berdeckung des Quelltextes Kontrollflusses erreicht wurde ggf werden alte Testf lle gestrichen die die selben Teiles des Quelltextes Kontrollflusses berdecken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 298 SE II Dynamische Programmanalysen und Testen Kontrollflusstest Anweisungs berdeckung Cy Test Fachgebiet Echtzeit systeme
44. Regressionstest passt zu den heute blichen inkrementellen und iterativen Softwareentwicklungsprozessen siehe Kapitel 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 263 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Systemtest grunds tzliche Vorgehensweise U Nach abgeschlossenem Integrationstest und vor dem Abnahmetest erfolgt der Systemtest beim Softwareentwickler durch Kunden a Test U Variante Systemtests bei ausgew hlten Pilotkunden vor Ort Test Systemtest berpr ft aus der Sicht des Kunden ob das Gesamtprodukt die an es gestellten Anforderungen erf llt nicht mehr aus Sicht des Entwicklers anstelle von Testtreibern und Teststummeln kommen nun soweit m glich immer die realen Hardware Komponenten zum Einsatz Systemtest sollte nicht beim Kunden in der Produktionsumgebung stattfinden sondern in m glichst realit tsnaher Testumgebung durchgef hrt werden beim Test sollten die tats chlichen Gesch ftsprozesse beim Kunden ber cksich tist werden in die das getestete System eingebettet wird dabei durchgef hrt werden Volumentests gro e Datenmengen Stresstests ber lastung Test auf Sicherheit Stabilit t Robustheit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 264 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Systemtest nichtfunktionale Anfor
45. Software Qualit tssteigerung Functionality richtige Funktionalit t Usability gute Benutzeroberfl che Reliability zuverl ssige Funktionsweise Performance schnelle Reaktionszeiten Supportability gute Programmstruktur Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 19 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Prinzipien der Qualitit tssicherung U Qualit tszielbestimmung Auftraggeber und Auftragnehmer legen vor Beginn der Software Entwicklung gemeinsames Qualit tsziel f r Software System mit nachpr fbarem Kriterienkatalog fest als Bestandteil des abgeschlossenen Vertrags zur Software Entwicklung quantitative Qualit tssicherung Einsatz automatisch ermittelbarer Metriken zur Qualit tsbestimmung objektivierbare ingenieurm ige Vorgehensweise konstruktive Qualit tssicherung Verwendung geeigneter Methoden Sprachen und Werkzeuge Vermeidung von Qualit tsprobleme integrierte fr hzeitige analytische Qualit tssicherung systematische Pr fung aller erzeugten Dokumente Aufdeckung von Qualit tsproblemen unabh ngige Qualit tssicherung Entwicklungsprodukte werden durch eigen st ndige Qualit tssicherungsabteilung berpr ft und abgenommen verhindert u a Verzicht auf Testen zugunsten Einhaltung des Entwicklungszeitplans Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 20 systeme
46. Spezialisierung Fortsetzung Redefinitionen virtual void greenOn precondition isYellow verbotene Versch rfung von isYellow isRed postcondition isGreen virtual void yellowOn precondition isGreen isRed postcondition isYellow amp amp isRed erlaubte Versch rfung der Nachbedingung virtual void redOn precondition isYellow isFlashing erlaubte Lockerung der Vorbedingung postcondition isRed private bool flashing Anmerkung Die Einschr nkung dass die blinkende Ampel nur noch in gr n schalten darf wenn sie im Zustand gelb ist f hrt dazu dass sich die blinkende Ampel nicht mehr wie eine normale Ampel der Klasse TrafficLight verh lt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 333 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Vor berlegungen zur Realisierung von Invarianten O die teuere berpr fung von Invarianten muss durch Compile Flag abschaltbar sein entweder systemweit oder je Subsystem O die berpr fungen d rfen das Verhalten des ausf hrbaren Programms abgesehen von Laufzeit und Speicherplatzverbrauch nicht ver ndern bei abgeschalteten berpr fungen sollte der Code f r diese berpr fungen nicht Bestandteil des ausf hrbaren Programms sein die Reaktion auf fehlgeschlagene berpr fungen muss an einer St
47. Zeilen werden mit markiert reale Deltas enthalten unver nderte Kontextzeilen zur besseren Identifikation von nderungsstellen ein Vorw rtsdelta zwischen zwei Dateien d1 und d2 kann als patch zur Erzeugung von Datei d2 auf Datei d1 angewendet werden inverses R ckw rtsdelta zwischen zwei Dateien d1 und d2 kann als patch zur Wiederherstellung von Datei d1 auf Datei d2 angewendet werden SCCS Deltas sind in einer Datei gespeichert deshalb weder Vorw rts noch R ck w rts sondern Inline Deltas Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 70 R ckw rtsdeltas Beisp PROCEDURE Pla b INT BEGIN IF a lt b THEN XXX END END P SE II Konfigurationsmanagement iel PROCEDURE P v w INT BEGIN IF v lt w THEN XXX ELSE yyy END Fachgebiet Echtzeit systeme PROCEDURE P v w INT BEGIN WHILE v lt wDO XXX END END P 01 01 Hunk 1 PROCEDURE P v w INT saI ON I PROCEDURE Pla b INT kkkkkkkkkkkkkkkkkkkkkkkkkkk 10 13 Hunk 2 IF v lt w THEN XXX ELSE mEnE En IF a lt b THEN XXX kkkkkkkkkkkkkkkkkkkkkkkkkkk diff patch kkk 10 11 kkk Hunk 1 kkkk WHILE v lt w DO XXX J0 IF v lt w THEN XXX ELSE T yyy kkkkkkkkkkkkkkkkkkkkkkkkkkkk Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 71 Fachgebiet 4 y SE II Konfigurationsmanag
48. const bool isYellow const bool isRed const bool isOff const ffentliche ver ndernde Operationen Modifier virtual void lightOn precondition isOff postcondition isRed virtual void lightOff precondition isGreen isYellow isRed postcondition isOff Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 328 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Implementierung der Ampelsteuerung Fortsetzung virtual void offOnFault precondition isOff postcondition greenOk amp amp yellowOk amp amp redOk isOff virtual void greenOn precondition isYellow isRed postcondition isGreen virtual void yellowOn precondition isGreen isRed postcondition isYellow virtual void redOn precondition isYellow postcondition isRed private bool off green yellow red Initialisierung off true green yellow red false protected berpr fung der Funktionsf higkeit der drei Lampen bool greenOk bool yellowOk bool redOk he Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 329 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit A Prinzipien bei der Spezialisierung der Ampelsteuerung es d rfen beliebig neue Methoden Attribute als neue Fun
49. der Software Entwicklung Eentzeit gt 2 Hu99 R H rten Function Point Analysis Theorie und Praxis Die Grundlage f r ein modernes Software Management expert verlag 1999 177 Seiten Kompaktes Buch zur Kostensch tzung mit Function Point Methode das Wert auf nachvollziehbare Bei spiele legt Zus tzlich gibt es eine Floppy Disc mit entsprechenden Excel Sheets Hu96 W S Humphrey Introduction to the Personal Software Process SEI Series in Software Engineering Addison Wesley 1996 Das CMM Modell f r den kleinen Mann Das Buch beschreibt wie man als einzelner Softwareentwickler von bescheidenen Anf ngen ausgehend die Prinzipien der Prozess berwachung und verbesserung einsetzen kann Zielsetzungen sind zuverl ssigere Zeit und Kostensch tzungen Fehlerreduktion JBR99 I Jacobson G Booch J Rumbaugh The Unified Software Development Process Addison Wesley 1999 Pr sentation des auf die UML zugeschnittenen Vorgehensmodells der Softwareentwicklung eine Variante des hier vorgestellten Rational Unified Objectory Prozesses Jo92 C Jones CASE s Missing Elements IEEE Spektrum Juni 1992 S 38 41 IEEE Computer Society Press 1992 Enth lt u a ein vielzitiertes Diagramm ber Produktivit ts und Qualit tsverlauf bei Einsatz von CASE OHJ99 B Oestereich Hrsg P Hruschka N Josuttis H Kocher H Krasemann M Reinhold Erfolgreich mit Objektorientierung Vorgehensmodelle und Managementpraktike
50. dliche berdosis bei Krebstherapie mit Strahlenbehandlung da Niedrigenergie Elektronen Hochenergie R ntgenstrahl strahl Modus 5 MeV Modus 25 MeV Maschine hat zwei Betriebsmodi Niedrigenergie und Hochenergiebestrahlung t dliche Bestrahlung im Hochenergiemodus wird allein durch Flattener verhindert der Strahl modifiziert in mehreren F llen war Flattener bei Hochenergiebestrahlung falsch positioniert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 26 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit 2 Externe Sicht auf einen Ungl cksfall Techniker tippt x f r X Ray Behandlung ein anstatt e f r electron mode Techniker entdeckt Fehler allerdings sofort und korrigiert Fehleingabe sehr schnell und startet Behandlung auf dem Bildschirm wird die Fehlermeldung Malfunction 54 ausgegeben hnliche Fehlermeldungen hatten bislang immer vorzeitigen Abbruch einer Behandlung ohne Bestrahlung angezeigt Techniker wiederholt also den Vorgang Behandlung zweimal Patient wird dreimal mit 25 MeV bestrahlt und stirbt 4 Monate sp ter Techniker beharrt hartn ckig darauf dass Therac 25 eine Fehlfunktion hatte diese l sst sich aber zun chst nicht reproduzieren Herstellerfirma streitet das wohl zun chst l ngere Zeit ab weitere Todesf lle sind die Folge Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut
51. eingereicht Status submitted ein eingereichter nderungswunsch wird evaluiert und dabei entweder abgelehnt Status rejected oder als Duplikat erkannt Status duplicate oder mit Kategorie und Priorit t versehen Status accepted ein akzeptierter nderungswunsch wird von dem f r seine Kategorie Zust ndigen gt f r ein bestimmtes Release zur Bearbeitung freigegeben Status assigned gt oder vorerst aufgeschoben Status postponed ein zugewiesener nderungswunsch wird von dem zust ndigen Bearbeiter in Angriff genommen Status opened irgendwann ist die Bearbeitung eines nderungswunsches beendet und die nderung wird zur Pr fung freigegeben Status released erf llt die durchgef hrte nderung den nderungswunsch so wird schlie lich der nderungswunsch geschlossen Status closed Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 139 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A Funktionalit t von nderungsmanagement Werkzeugen nderungsw nsche k nnen ber Browserschnittstelle bermittelt werden nderungsw nsche werden in Datenbank verwaltet Betroffene werden vom Statuswechsel eines nderungswunsches benachrichtigt Integration mit Projektmanagement und KM Management Trendanalyse und Statistiken als Grafiken Anzahl neuer Fehlermeldungen Werkzeuge f r das nderungsmanagement O Open Software Produkt Sourceforge GForge d
52. f r Ausfall von 2 oder 3 Versionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 257 SE II Dynamische Programmanalysen und Testen Eehtzeit gt s z systeme Der Testprozess als Bestandteil des Softwareentwicklungsprozesses durch Entwickler Testabteilung Komponententest durch Entwickler Testabteilung Klasse durch Entwickler Testabteilung Integrationstest j durch Testabteilung SW System t durch Auftraggeber Gesamt Akzeptanztest System Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 258 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Einbettung in modifiziertes V Modell Anforderungsdefinition Akzeptanztest funkt Systementwurf Systemtest Konstruktion Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 259 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Komponententest Unit Test und Subsystemtest jeweils ein einzelner Softwarebaustein wird berpr ft isoliert von anderen Softwarebausteinen des Systems U die betrachtete Komponente Unit kann eine Klasse Paket Modul sein Subsystemtest kann als Test einer besonders gro en Komponente aufgefasst werden getestet wird gegen die Spezifikation der Schnittstelle der Komponente dabei betrachtet werden funktionales Verhalten Robustheit Effizienz Testziele s
53. flashingOn redOn new lightOn flashingOn lightOff new lightOn flashingOn offOnFault greenOk new lightOn flashingOn offOnFault yellowOk new lightOn flashingOn offOnFault redOk new lightOn yellowOn flashingOn new lightOn yellowOn greenOn flashingOn new lightOn yellowOn greenOn redOn new lightOn yellowOn greenOn lightOff new lightOn yellowOn greenOn offOnFault greenOk new lightOn yellowOn greenOn offOnFault yellowOk new lightOn yellowOn greenOn offOnFault redOk new lightOn yellowOn lightOff 1 2 d 4 9 6 1 8 9 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 344 i Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit Die Tests f r irrelevante irregul re Transitionen new lightOff Test f r den Zustand Off new lightOn greenOk new lightOn yellowOk new lightOnf redOk new offOnrFault new redOn new yellowOn new greenOn new flashingOn 10 new lightOn FlashingOn lightOn Test f r den Zustand Flashing 11 L 2 3 4 5 6 1 8 9 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 345 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Behandlung ereignisloser Transitionen Automatenmodelle f r die Verhaltensbeschrei
54. i 1 bis 3 falsches Programm ist eine Zuweisung DO3i 1 3 in Fortran spielen n mlich Leerzeichen keine Rolle Variablen brauchen nicht deklariert werden DO3i ist eine Real Variable es gibt keine reservierten Schl sselw rter wie etwa DO Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 22 SE II Software Entwicklung Wartung und Re Engineering Echizeit gt 2 Schlussfolgerungen aus Mariner Vorfall durch systematisches Testen h tte man den Fehler vermutlich bei Testl ufen Simulationen finden k nnen eine vern nftige Programmiersprache h tte die Verwendung eines Dezimal punktes anstelle von Komma als Syntaxfehler zur bersetzungszeit gefunden das Aufstellen von durch Werkzeuge berpr fte Programmierrichtlinien f r Fortranprogramme h tte das Ungl ck auch vermieden alle Variablen werden deklariert obwohl es nicht notwendig ist gt die Verwendung von Leerzeichen in Variablennamen wird verboten ebenso die Verwendung von Schl sselw rtern in Variablennamen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 23 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t Analytisches Qualit tsmanagement zur Fehleridentifikation analysierende Verfahren der Pr fling Programm Modell Dokumentation wird von Menschen oder Werkzeugen auf Vorhandensein Abwesenheit von Eigenschaften
55. mit Wiederverwendung bereits getesteten Codes reduziert die Menge an neu geschriebenen zu testenden Code die Vererbung ist eine der Hauptfehlerquellen falsche Interaktion mit geerbten Code bzw falsche Redefinition von geerbten Methoden dynamisches Binden erschwert die Definition sinnvoller berdeckungsmetriken ungemein beim White Box Test Verhalten von Objektmethoden ist fast immer zustandsabh ngig Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 321 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Prinzipien des Tests objektorientierter Programme beim Black Box Test wie bisher vorgehen Objekte als Eingabeparameter werden gem interner Zust nde verschiedenen quivalenzklassen zugeordnet beim White Box Test werden Kontrollflussgraphen erweitert um so Effekte des dynamischen Bindens mit zu ber cksichtigen wird hier nicht weiter verfolgt Zustandsautomaten werden zus tzlich zu Kontrollflussgraphen zur Testplanung herangezogen dieses Verfahren wird oft dem Black Box Test zugeordnet Einbau von Konsistenz berpr fungen Plausibilit ts berpr fungen assert in Java in Methoden zu Beginn und nach Abarbeitung von Methodencode defensive Programmierung Code f ngt alle erkennbaren Inkonsistenzen ab geerbter Code wird wie neu geschriebener Code behandelt und immer vollst ndig im Kontext der erbenden Klasse neu ge
56. nf Kursanbieter akkreditiert und es gab etwa 550 zertifizierte Tester auf Foundation Level inzwischen gibt es alleine 17 sogenannte Premiumanbieter solcher Kurse angeblich bestehen ca 80 der Pr fungsteilnehmer die Pr fung zum Certified Tester Foundation Level wir werden auch dieses Jahr wieder Studierenden der TU Darmstadt die M glichkeit bieten am Ende des Semester gegen erm igte Pr fungsgeb hr hier in Darmstadt die Pr fung zum Certified Tester abzulegen empfohlene Lehrmaterialien und weitere Links sind gt Lehrbuch hierzu SL12 gt weitere Informationen unter http www certified tester de Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 12 Fachgebiet A Echtzeit FA systeme Wichtige Literaturquellen Ba00 H Balzert Lehrbuch der Software Technik Band 1 Software Entwicklung Spektrum Akademischer Verlag 2000 2 te Auflage 1136 Seiten Sehr umfangreiches und gut lesbares Nachschlagewerk mit CD Auf der CD findet man Werkzeuge Videos bungsaufgaben mit L sungen aber nicht unsere H Balzert Lehrbuch der Software Technik Band 2 Software Management Software Qualit tssiche rung Unternehmensmodellierung Spektrum Akademischer Verlag 1998 769 Seiten Hier findet man fast alles ber das Gebiet Software Technik was nicht bereits in Ba00 abgehandelt wurde Wieder ist eine CD mit den entsprechenden Werkzeugen beigelegt R V Beizer T
57. ngeraufgabe R ckw rtsberechnung sp tester Endzeiten f r Aufgaben sp teste Endzeit letzter Aufgabe fr heste Anfangszeit Dauer 1 sp teste Endzeit von Vorg ngeraufgabe Minimum sp teste Endzeit Dauer einer Nachfolgeraufgabe kritische Aufgabe auf kritischem Pfad Anfangs und Endzeiten liegen fest gt fr heste Anfangszeit sp teste Anfangszeit sp teste Endzeit Dauer 1 sp teste Endzeit fr heste Endzeit fr heste Anfangszeit Dauer 1 kritische Kante auf kritischem Pfad zwischen zwei kritischen Aufgaben gt fr heste Endzeit Kantenquelle 1 sp teste Anfangszeit Kantensenke Pufferzeit nichtkritischer Aufgabe Zeit um die Beginn verschoben werden kann Pufferzeit sp teste Anfangszeit fr heste Anfangszeit Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 405 SE II Management der Software Entwicklung Echizeit gt 2 Probleme mit der Planung des Beispiels U zu viele Aufgaben liegen auf kritischen Pfaden wenn kritische Aufgabe l nger als gesch tzt dauert schl gt das auf Gesamtprojektlaufzeit durch an einigen Stellen zus tzliche Pufferzeiten einplanen um Krankheiten Fehlsch tzungen auffangen zu k nnen einige eigentlich parallel ausf hrbare Aufgaben sollen von der selben Person bearbeitet werden gt Ressourcenplanung f r Aufgaben durchf hren gt Aufgaben serialisieren um Ressourcenkonflikte aufzul sen
58. r Datentechnik Seite 48 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit S Reverse Engineering von Legacy Software Beim Reverse Engineering ist das vorhandene Software System der Ausgangspunkt der Analyse Ausgehend von existierender Implementierung wird meist nur das Design rekonstruiert und dokumentiert Es wird noch nicht das betrachtete System modifiziert Anforderungen Code Legacy Software Fragen L sst sich das Software System noch restrukturieren sanieren U Oder kann man sein Innenleben verkapseln und zun chst weiterverwenden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 49 SE II Software Entwicklung Wartung und Re Engineering Echtzeit Strategien des Reengineerings Reengineering befa t sich mit der Sanierung eines vorhandenen Software Systems bzw seiner Neuimplementierung Dabei werden die Ergebnisse des Reverse Engineerings als Ausgangspunkt genommen Restrukturierung des Designs Kapselung des Codes Anforderungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 50 SE II Software Entwicklung Wartung und Re Engineering Echtzeit S systeme Forward und Re verse engineering Round Trip Engineering Redesign Tool Anforderungs R Mit Upper CASE Tools analyse lt N Computer Aided N Forward N Engineering CASE Computer Aide
59. r eine Variable Parameter v gilt 1 d v f r n Anweisung n definiert Wert f r v 2 r v f r n Anweisung n benutzt Wert von v 3 f r alle Anweisungen n auf Pfad p ohne n gilt nicht d v f r n n ndert also nicht den bei n festgelegten Wert von v Die Kanten des Datenflussgraphen verbinden also Zuweisungen an Variablen oder Parameter mit den Anweisungen in denen die zugewiesenen Werte benutzt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 188 SE II Statische Programmanalyse amp Metriken Eentzeit gt s J Beispiel f r Datenflussgraph zu countVowels Kontrollflussgraph countVowels Datenflussgraph countVowels IN s Sentence OUT count INT count 0 i 0 Nstart IN S WHILE si DO IF s il a OR Ncount 1 Count count 1 Ncount 1 Nfinal OUT count Knoten setzende lesende Variablenzugriffe Knoten Anweisungsbl cke Kanten Datenfluss der zugewiesenen Werte Kanten Kontrollfluss Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 189 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Programm Slices zur Fehlersuche und nderungsfolgesch tzung Ein Abh ngigkeitsgraph A N E eines Programms ist ein gerichteter Graph der alle Knoten und Kanten des Datenflussgraphen enth lt ohne Zusammen fassung von Teilgraphen zu Segmenten
60. rdenstandards V Modell richtig integriert Qualit tssicherung ist kein eigener Aktivit tsbereich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 373 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit 5 3 Leichtgewichtige Prozessmodelle Herk mmlichen Standards f r Vorgehensmodelle zur Softwareentwicklung V Modell RUP wird vorgeworfen dass sie sehr starr sind Unmengen an Papier produzieren und nutzlos Arbeitskr fte binden Deshalb werden seit einiger Zeit sogenannte leichtgewichtige Prozessmodelle light weight processes propagiert die sinnlosen b rokratischen Overhead vermeiden wollen Extreme Programming XP radikale Abkehr von bisherigen Vorgehens modellen und Ersatz durch best practices der Programmierung Be99 Agile Prozessmodelle Versuche herk mmliche Prozessmodelle auf das unbedingt notwendige zur ckzuschneiden und situationsbedingt flexibel und schnell agil voranzuschreiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 374 SE II Management der Software Entwicklung Echizeit gt 2 Grundideen von XP E Verzicht auf Phasen der Softwareentwicklung Arbeitsbereiche keine eigenst ndigen Analyse oder Designaktivit ten vor der Codierung keine Erstellung getrennter Dokumentationsdokumente Modelle der gut kommentierte Code ist seine eigene Dokumentation
61. sowie zus tzlich Kanten f r Pfade des Kontrollflussgraphen von allen Bedingungen zu direkt kontrollierten Anweisungen das sind die Anweisungen deren Aus f hrung von der Auswertung der betrachteten Bedingung direkt abh ngt Es gibt zwei Arten von Ausschnitten Slices eines Abh ngigkeitsgraphen A Q Vorw rts Slice f r Knoten n e N mit Datenflussattribut d v alle Pfade in A die von Knoten n ausgehen der Variable v definiert der Slice Graph enth lt alle Knoten und Kanten der Pfade Q R ckw rts Slice f r Knoten n e N mit Datenflussattribut r v alle Pfade in A die in Knoten n einlaufen der Variable v referenziert der Slice Graph enth lt alle Knoten und Kanten der Pfade Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 190 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Abh ngigkeitsgraph zu countVowels PROCEDURE countVowels IN s Sentence Slice f r alle Knoten von countVowels OUT count INTEGER VAR i INTEGER Nstart IN s BEGIN count 0 i 0 init WHILE sli DO IF sli a OR sli e OR s i i OR sli 0 OR sli u THEN count count 1 END 2 x Q Nfinal OUT count i 1 END WHILE END countVowels final schwarze Kanten Datenflusskanten rote Kanten Kontrollflusskanten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 1
62. unabh ngig voneinander z B haben alle Versionen dieselben Anforderungsdefinitionsfehlern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 254 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Mutationstestverfahren Erzeugung von Mutationen durch Vertauschen von Anweisungsfolgen Umdrehen von Kontrollflussbedingungen L schen von Zuweisungen ndern von Konstanten Zielsetzungen Identifikation fehlender Testf lle f r jeden Mutanten sollte mindestens ein Testfall existieren der Original und Mutant unterscheiden kann Eliminination nutzloser Testf lle Gruppe von Testf llen verh lt sich bez glich der Erkennung von Mutanten v llig gleich Sch tzung der Restfehlermenge RF RF GF M GM 1 mit GM Anzahl gefundener eingebauter Fehler Mutationen M Gesamtzahl absichtlich eingebauter Fehler GF Anzahl gefundener echter Fehler F Gesamtzahl echter Fehler GF RF Annahme GF F GM M Korrelation gilt allenfalls f r bestimmte Fehler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 255 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit N Versionen Programmierung Back to Back Testing Zielsetzungen gt eine Version kann als Orakel f r die Korrektheit der Ausgaben einer ande ren Version herangezogen werden geht ab 2 Versionen gt Robustheit der ausgelief
63. und p v wenn Unterschied c p irrelevant ist n e N besitzt das Attribut u v falls v in dieser Anweisung noch keinen definierten Wert mehr besitzen kann Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 183 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Kontrollflussgraph mit Datenflussattributen PROCEDURE countVowels IN s Sentence OUT count INTEGER systeme start Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN count 0 i 0 init WHILE s i DO IF slil a OR sli OR s i i OR sli 0 OR sli u THEN count count 1 END i 1 END WHILE END countVowels final Achtung Reihenfolge der Datenfluss attribute ist manchmal wichtig von links nach rechts oben nach unten lesen und auswerten Mehrfache Auftreten von Datenfluss attributen an einem Knoten werden meist zusammen gefasst d s u count u i d count d i Ncount 1 Ni 1 Nfinal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 184 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Kontrollflussgraphsegmente mit Datenflussattributen Sei s ein Kontrollflussgraphsesment mit Pfad Nan N1 Nk Ngina Und attr n die Sequenz der Datenflussat
64. wie entdeckte Fehler behoben werden k nnen Beurteilung der F higkeiten des Autors lange Diskussion ob ein entdeckter Fehler tats chlich ein Fehler ist Inspektionsergebnis gt formalisiertes Inspektionsprotokoll mit Fehlerklassifizierung Fehlerstatistiken zur Verbesserung des Entwicklungsprozesses Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 175 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Ablauf einer Inspektion Planung des gesamten Verfahrens durch Management und Moderator Ausl sung der Inspektion durch Autor eines Dokumentes z B durch Freigabe Eingangspr fung durch Moderator bei vielen offensichtlichen Fehlern wird das Dokument sofort zur ckgewiesen Einf hrungssitzung bei der Pr fling den Gutachtern vorgestellt wird Individualuntersuchung des Pr flings Ausschnitt durch Gutachter zur Vorbereitung auf gemeinsame Sitzung anhand ausgeteilter Referenzdokumente auf Inspektionssitzung werden Pr fergebnisse mitgeteilt und protokolliert sowie Pr fling gemeinsam untersucht Nachbereitung der Sitzung und Freigabe des Pr flings durch Moderator oder R ckgabe zur berarbeitung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 176 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Technisches Review abgeschw chte Form der Inspektion L Prozessverbesserung und Erste
65. 393 i Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Konsequenzen f r die eigene Software Entwicklung Im Rahmen von Studienarbeiten Diplomarbeiten k nnen Sie keinen CMM Level 5 oder SPiICE Software Entwicklungsprozess verwenden aber Einsatz von Werkzeugen f r Anforderungsanalyse Modellierung und Projektplanung in der Vorlesung Software Engineering Einf hrung behandelt Einsatz von Konfigurations und Versionsmanagement Software gt wird in dieser Vorlesung behandelt Einsatz von Werkzeugen f r systematisches Testen Messen der Produktqualit t gt wird in dieser Vorlesung behandelt Einsatz von Extreme Programming Techniken siehe Software Praktikum und z B Be99 vom Erfinder Kent Beck Einsatz von Techniken zur Verbesserung des pers nlichen Vorgehensmodells siehe Hu96 ber den Personal Software Process Buchautor Humphrey ist einer der Erfinder von CMM Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 394 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit 5 5 Projektpl ne und Projektorganisation Am Ende der Machbarkeitsstudie steht die Erstellung eines Projektplans mit Identifikation der einzelnen Arbeitspakete Terminplanung zeitliche Aufeinanderfolge der Pakete gt Ressourcenplanung Zuordnung von Personen zu Paketen Hier wird am deutlichst
66. 4 Release wird freigegeben und weiterverbreitet gt Weiterentwicklung neuer Releases wird wieder aufgenommen gt freigegebenes Release muss parallel dazu gepflegt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 108 Fachgebiet 4 y5 SE II Konfigurationsmanagement Echtzeit A systeme Standardl sung f r parallele Pflege und Weiterentwicklung V 4 Entwicklungszweig Wartungszweig f r Release mit Tag V 4 1 f r Weiterentwicklung des n chsten Releases und Wartung des gerade freigegebenen Releases werden unterschiedliche Revisionszweige verwendet alle auf dem Wartungszweig liegenden Revisionen erhalten den Namen des Releases Versionsnummer als Tag Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 109 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Strategien f r die Vergabe von Versions und Revisionsnummern U Software Releases erhalten blicherweise zweistellige Versionsnummern die erste Stelle wird erh ht wenn sich die Funktionalit t signifikant ndert die zweite Stelle wird f r kleinere Verbesserungen erh ht oft wird erwartet dass x 2 x 4 stabiler als x 1 x 3 sind E E E E die in cvs vierstelligen internen Revisionsnummern eines KM Systems m ssen mit den extern sichtbaren Versionsnummern nichts zu tun haben in den vorigen Beispielen galt aber Versionsnummer
67. 91 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Vorw rts Slice Beispiel und Nutzen Ein Vorw rts Slice zu einer Anweisung n die Vorw rts Slice f r count count 1 einer Variable v einen Wert zuweist bestimmt alle die Stellen eines Programms Nstart IN s die von einer nderung des zugewiesenen Wertes Berechnungsvorschrift betroffen sein k nnten Der Vorw rts Slice zu count count 1 count count 1 END countVowels final mit R ckgabe count Ein Vorw rts Slice dient der Absch tzung von Folgen einer Programm nderung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 192 SE II Statische Programmanalyse amp Metriken Echtzeit systeme R ckw rts Slice Beispiel und Nutzen Ein R ckw rts Slice zu einer Anweisung n R ckw rts Slice f r i i 1 die eine Variable referenziert bestimmt alle die Stellen eines Programms die den Wert der Nstart IN s Variable direkt oder indirekt bestimmt haben Der R ckw rts Slice zu i it1 PROCEDURE countVowels IN s Sentence OUT count INTEGER VAR i INTEGER BEGIN start count 0 i 0 WHILE s i DO 141 Ein R ckw rts Slice ist bei der Fehlersuche hilfreich um schnell irrelevante Programmteile ausblenden zu k nnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 193 SE II Statische
68. A systeme Revision Control System RCS von Berkley Purdue University Je Dokument immer Textdatei gibt es eine eigene History Datei die eine neueste Revision vollst ndig und andere Revisionen als Deltas speichert O optionale Schreibsperren verhindern ggf paralleles ndern Revisionsb ume mit besserem Zugriff auf Revisionen schneller Zugriff auf neueste Revision auf Hauptzweig langsamer Zugriff auf ltere Revisionen auf Hauptzweig mit R ck w rtsdeltas langsamer Zugriff auf Revisionen auf Nebenzweigen mit Vorw rtsdeltas U Versionsidentifikation auch durch frei w hlbare Bezeichner Offene Probleme kein Konfigurationsbegriff und kein Variantenbegriff Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 81 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Beispielszenario der Softwareentwicklung Hauptzweig V1 erstes f r Kunden sichtbare Release V1 5 ausgelieferte Bugfixes f r V1 V2 zweites Kundenrelease Wartungszweig V1 sehr wenige Zugriffe 7 G2 nderungen V1 5 G 89 zur ckpropagiert aufgegeben Wartungszweig V2 Fehlerkorrekturen Bug fixes bernommen Verbesserungen 27 bernommen viele Zugriffe g sehr viele Zugriffe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 82 i Fachgebiet SE II Konfigurationsmanagement Echtzeit
69. B 18 Institut f r Datentechnik Seite 285 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme Sinnvolle Auswahl von Testf llen am Beispiel demonstriert die fehlerhaften Auftragsnummern H und 123 treten nur in jeweils einem Testfall auf die fehlerhafte Eingabe Ahorn ebenfalls gleiches gilt f r eine zu kleine und eine zu gro e L ngenangabe die extrem lange Auftragsnummer HO0 0000 tritt ebenfalls nur einmal in einem Testfall auf zu kleine und zu gro e L ngenangaben fehlerhafte Auftragsnummern falsche Holzarten und die extrem lange Auftragsnummer treten nicht im selben Testfall auf alle zul ssigen Kombinationen von quivalenzklassen f r Holzarten und L ngen angaben m ssen durchgetestet werden da laut Spezifikation Holzart und L nge gemeinsam den Preis des Auftrags bestimmen da Auftragsnummern laut Spezifikation der Software unabh ngig von Holzarten und L ngen verarbeitet werden wird jede Kombination von Holzart und L nge nur mit einer normalen Auftragsnummer getestet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 286 Fachgebiet 5 SE II Dynamische Programmanalysen und Testen Echtzeit Ge ndertes Beispiel f r Testparameterauswahl Wieder soll eine Vorschrift zur Berechnung des Preises von Brettern getestet werden Die Eingabeparameter sind dieses Mal Holzart Aufz hlungstyp Buche Eiche Kiefer U Brettl nge Zahl g
70. CMMI Es gibt F higkeitsgrade f r einzelne Prozessgebiete hnlich zu SPiCE 0 Incomplete Ausgangszustand keine Anforderungen 1 Performed die spezifischen Ziele des Prozessgebiets werden erreicht 2 Managed der Prozess wird gemanagt 3 Defined der Prozess wird auf Basis eines angepassten Standard Prozesses gemanagt und verbessert 4 Quantitatively Managed der Prozess steht unter statistischer Prozesskontrolle 5 Optimizing der Prozess wird mit Daten aus der statistischen Prozesskontrolle verbessert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 392 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Eigenschaften von CMMI Fortsetzung Es gibt Reifegrade die F higkeitsgrade auf bestimmten Prozessgebieten erfordern hnlich zu CMM 1 Initial keine Anforderungen diesen Reifegrad hat jede Organisation automatisch 2 Managed die Projekte werden gemanagt durchgef hrt und ein hnliches Projekt kann erfolgreich wiederholt werden 3 Defined die Projekte werden nach einem angepassten Standard Prozess durchgef hrt und es gibt eine kontinuierliche Prozessverbesserung 4 Quantitatively Managed es wird eine statistische Prozesskontrolle durchgef hrt 5 Optimizing die Prozesse werden mit Daten aus statistischen Prozesskontrolle verbessert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite
71. Grenzen von Arrays statt Laufzeitfehler in guter Programmiersprache Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 273 systeme i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Analyse des Speicherplatzverhalten mit Purify Rational IBM WF Falintel Purily Dala Erserser Furily Turplalere B mie Git Yew Sebar Uini HA Eg ESEN lajx sis an la w ajaj asiel ala AE e ella ze 2E E 4j al Tlam Eror Yiew madule view Ale mew Function uiet view a aslo Marge E UHR Uninitialized memory read in Chraufover IsInsidefint int int int E Run H UIR Uninitialized memory read in FultiByteToWidechar 1 occurrence EH UHR Uninitialized merwry read in kHultiEyteTolidechar 3 occurrences WEP Starting thread x488 FM Starting thread ode agt ABY Array bounds write in RegEnunkeyExY 19 occurrences SM Starting thread x47 H UWR Uninitialized memory read in FultiByteToWidechar 1 occurrence r jummary of all memory leaks 8061 bytes 25 blocks SP HPK Potential menory Leah oF 6224 bytes From 4 blocks allocated in i EE i HPK Potential menory leak of 1008 bytes From 4 blocks allocated in B HLE Henory Leak of 397 bytes From A blocks allocated in ScreenToCli i H HPK Potential menory leak of 170 bytes From 4 blocks allocated in 5 E A HLE Henory Leak of 136 bytes From 1 bloch allocated in calloc SUC i H HPK Potential nenory l
72. Konstanten und Typdefinitionen berall in allen anderen h und c Dateien das Hauptprogramm assembler besitzt keine Schnittstelle f r andere Module es besteht also nur aus einer c Datei jede Quelltextdatei M c mit Suffix c wird in eine Objektdatei M o bersetzt dabei werden h Dateien aller importierten Module verwendet alle Objektdateien mit Suffix o werden zu einem ausf hrbaren Programm zusammengebunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 115 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Altes Beispiel genauerer Abh ngigkeitsgraph assembler assembler o assembler c pass lt n gt o N pass lt n gt h VG N GN Z X om global h pass lt n gt c Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 116 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme bersetzungs und Bindevorg nge Beispiel 1 assembler c Modul h Datei c Datei M1 M2 Importbeziehung pass0 h amp c pass1 h amp c pass2 h amp c M1 c Datei includes Pa M2 h Datei messages h amp c symbtab h amp c alle Module Pakete h ngen davon ab files h amp c global h die Implementierung einer Prozedur von messages messages c ndert sich nur message
73. LOC Programmteil Anzahl der Knoten im Kontrollflussgraphen dazu Beispiel LOC countVowels 7 oder 8 ohne init Segment Idee dieser Ma zahl betrachtete Programmteile oder ganze Programme mit hoher LOC sind zu komplex no separation of concerns und deshalb fehlertr chtig Programmteile mit geringer LOC sind zu klein und f hren zu unn tigen Schnittstellenproblemen Probleme mit dieser Ma zahl Kanten Kontrollflusslogik spielen keine Rolle wie bewertet man geerbten Code einer Klasse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 219 Fachgebiet 4 y SE II Statische Programmanalyse amp Metriken Echtzeit systeme Zyklomatische Zahl nach McCabe ZZ Programmteil IEI INI 2k mit G als Kontrollflussgraph des untersuchten Programmteils und EI Anzahl Kanten von G INI Anzahl Knoten von G k Anzahl Zusammenhangskomponenten von G Anzahl der nicht miteinander verbundenen Teilgraphen von G Beispiel ZZ countVowels 8 7 2 3 Regel von McCabe ZZ eines in sich abgeschlossenen Teilprogramms Zusammenhangskomponente sollte nicht h her als 10 sein da sonst Programm zu komplex und zu schwer zu testen ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 220 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Interpretation und Probleme mit der zyklomatischen Zahl es wird die Anzah
74. Nummer ber die sie angesprochen wird Nummern werden nach einem bestimmten Schema erzeugt Verwendung von Attributen Tags Revisionen werden durch Attribute und deren Werte indirekt identifiziert Beispiele sind gt Kunde f r den Revision erstellt wurde Entwicklungssprache Java C Entwicklungsstatus in Bearbeitung getestet freigegeben gt Verwendung von Zeitstempeln Spezialfall der attributbasierten Identifikation f r jede Revision ist der Zeitpunkt ihrer Fertigstellung commit bekannt deshalb k nnen Revisionen ber den Zeitraum ihrer Erstellung j ngste Revision vor Mai 2003 etc identifiziert werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 90 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Offene Probleme mit Deltaspeicherung und Verschmelzen Berechnung von Deltas funktioniert hervorragend f r Textdateien mit Zeilenenden als Synchronisationspunkte f r Vergleich Berechnung minimaler Deltas von Bin rdateien w re wesentlich schwieriger Textverarbeitungsprogramme wie Word oder CASE Tools besitzen deshalb eigene Algor thmen zur Berechnung und Anzeige von Deltas Verschmelzung von Textdateien funktioniert meist gut kann aber zu t ckischen Inkonsistenzen f hren Verschmelzung von Bin rdateien oder Grafiken Diagrammen ist im allgemeinen nicht m glich Programme wie Word oder CASE Tools besitze
75. Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 88 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Synchronisierung mit Watch Edit Unedit In manchen F llen will man wegen gr erer Umbauten eine Datei Revision ungest rt bearbeiten also zumindest eine Meldung erhalten wenn andere Entwickler dieselbe Datei bearbeiten um sie zu warnen U watch on schaltet das Beobachten einer Datei ein beim checkout wird die gew nschte Revision der Datei nur mit Leserecht lokal zur Verf gung gestellt U watch off ist das Gegenst ck zu watch on watch add nimmt Entwickler in Beobachtungsliste f r Datei auf f r die er vorher ein checkout gemacht hat nderungen an Revisionen der Datei werden per Email allen Entwicklern auf Beobachtungsliste gemeldet watch remove entfernt Entwickler von Beobachtunssliste f r Datei edit verschafft Entwickler Schreibrecht auf lokal verf gbarer Revision einer Datei und meldet das anderen interessierten Entwicklern enth lt watch add unedit nimmt Schreibrecht zur ck und meldet das enth lt watch remove Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 89 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Identifikation gew nschter Revisionen Zusammenfassung 1 Verwendung von Revisionsnummern Identifikatoren jede Revision einer Datei erh lt eine eigene eindeutige
76. Programmanalyse amp Metriken Echizeit gt 2 Datenfluss und Kontrollflussanomalien Eine Anomalie eines Programms ist eine verd chtige Stelle in dem Programm Eine solche verd chtige Stelle ist keine garantiert fehlerhafte Stelle aber eine potentiell fehlerhafte Stelle im Programm Datenflussanomalien meist deutliche Hinweise auf Fehler sind etwa es gibt einen Pfad im Kontrollflussgraphen auf dem eine Variable v referenziert wird bevor sie zum ersten Mal definiert wird Zugriff auf undefinierte Variable es gibt einen Pfad im Kontrollflussgraphen auf dem eine Variable v zweimal definiert wird ohne zwischen den Definitionsstellen referenziert zu werden nutzlose Zuweisung an Variable Kontrollflussanomalien sind bei modernen Programmiersprachen von geringerer Bedeutung Im wesentlichen handelt es sich dabei bei Programmiersprachen ohne goto Anweisungen um nicht erreichbaren Code ansonsten beispielsweise Spr nge in Schleifen hinein Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 194 SE II Statische Programmanalyse amp Metriken Beispiel f r Programm mit Datenflussanomalien PROCEDURE ggT IN m n INTEGER OUT o INTEGER BEGIN WHILE n gt 0 DO IF m gt n THEN endif final Fachgebiet A Echtzeit kay systeme Nstart Nwhile n gt 0 Nif m gt n Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechni
77. Quality Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 5 Fachgebiet Echtzeit systeme Zielsetzungen der Vorlesung Zuh rer f r die Realit t der Software Entwicklung fit machen Techniken und Werkzeuge zum Umgang mit bestehender Software vermitteln berblick ber systematische Software Analyse und Testverfahren geben Zielsetzungen der bung praktische Vertiefung der Lehrinhalte an einem realen Beispiel Konfrontation mit kommerziellen und Open Source Werkzeugen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 6 Fachgebiet Echtzeit Fi systeme Inhaltsverzeichnis der Vorlesung 1 1 Software Entwicklung Wartung und Re Engineering 1 1 Einleitung 1 2 Software Qualit t 1 3 Iterative Softwareentwicklung 1 4 Forward Reverse und Reengineering 1 5 Zusammenfassung Konfigurationsmanagement 2 1 Einleitung 2 2 Versionsmanagement 2 3 Variantenmanagement 2 4 Releasemanagement 2 5 Buildmanagement 2 6 nderungsmanagement 2 7 Verteilte Softwareentwicklung plus Industrievortrag 2 8 Zusammenfassung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 7 Fachgebiet Echtzeit 1 systeme Inhaltsverzeichnis der Vorlesung 2 3 Statische Programmanalysen und Metriken 3 1 Einleitung 3 2 Softwarearchitekturen und visualisierung 3 3 Kontroll und datenflussorientiert
78. Rahmenwerks f r interaktive Anwendungen Klassen eines Teilsystems besitzen dieselbe Farbe Beziehungen zwischen Klassen aus Gr nden der bersichtlichkeit weggelasssen siehe http www sst informatik tu cottbus de CrocoCosmos Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 168 SE II Statische Programmanalyse amp Metriken Eentzet gt s i Statische Visualisierung von Programmstrukturen Fortsetzung Ausschnitte der Programmlogik Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 169 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Programmvisualisierung mit Doxygen und Graphviz U Doxygen generiert Programmdokumentation Architekturdiagramme siehe http www stack nl 7Edimitri doxygen index html Graphviz dot ist Hilfsprogramm f r Layoutberechnung siehe http www graphviz org Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 170 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Programmvisualisierung mit Doxygen include Abh ngigkeiten a TinycAD Microsoft Internet Explorer TTTVVVVTTTTTTTTTJTA E as Ansicht Favoriten Extras nd Qaia O x EI WI I uen Koran pin JE Adresse B C ocal projects tinycad doxygenhtml jndex html Wechseln zu Links TinyCAD Main Page Class Hierarchy Alphabetical List Compound List File Lis
79. Software Engineering Wartung und Qualit tssicherung Prof Dr Andy Sch rr Fachgebiet Echzeitsysteme FB ETiT Informatik Technische Universit t Darmstadt Merckstr 25 D 64283 Darmstadt Andy Schuerr es tu darmstadt de Tel 06151 16 6940 Raum S 306 313 WWW Seite der Vorlesung http www es tu darmstadt de lehre se ii v Bildquelle Jules Verne The Great Explorers of the XIXth Century Nora Ta Werra New York Charles Scribner s Sons 1912 favourite engineering tool Fachgebiet Echtzeit systeme WWW Seite der Vorlesung http www es tu darmstadt de Lehre se ii v Verankerung als Wahlmodul in Pr fungspl nen von Studieng ngen Q ETIT DT U Wirtschafts Informatik Informationssystemtechnik Mechatronik Termine der Lehrveranstaltung Vorlesung Montag 10 00 s t bis 11 30 Uhr in S11011402 Donnerstag 8 00 s t bis 8 45 in S11011A01 am 23 10 bis 9 30 O bung ab 30 10 2014 Donnerstag 8 45 bis 9 30 in S11011A01 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 2 Fachgebiet Echtzeit systeme Wissensgebiete der Software Technik Der IEEE Computer Society Guide to the Software Engineering Body of Knowledge SWEBOK http www swebok org z hlt folgende Wissensgebiete auf 1 Software Requirements es wird festgelegt was ein Software System leisten soll und warum Software Design das Wie steht nun
80. TU Darmstadt FB 18 Institut f r Datentechnik Seite 249 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit U Datenflussfehler falscher Zugriff auf Variablen und Datenstrukturen siehe vor allem Abschnitt 4 2 und Abschnitt 4 5 Variable wird nicht initialisiert Initialisierungsfehler falsche Arrayindizierung Zuweisung an falsche Variable Zugriff auf Nil Pointer oder bereits freigegebenes Objekt Objekt wird nicht freigegeben U Zeitfehler gefordertes Zeitverhalten wird nicht eingehalten siehe Abschnitt 4 2 Implementierung ist nicht effizient genug wichtige Interrupts werden zu lange blockiert Redefinitionsfehler geerbte Operation wird nicht semantikerhaltend redefiniert siehe Abschnitt 4 6 ein Nutzer der Oberklasse geht von Eigenschaften der aufgerufenen Operation aus die Redefinition in Unterklasse nicht mehr erf llt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 250 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Beispiel f r fehlerhafte Prozedur PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN count 0 Initialisierungsfehler i wird nicht initialisiert WHILE sli DO IF s i a OR sli OR s i 0 OR sli u Kontrollflussfehler keine Pr
81. U Darmstadt FB 18 Institut f r Datentechnik Seite 239 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Vorgehensweise Fortsetzung 3 Mittel zur Bestimmung des aktuellen Standes zu messende Aspekte Kosten und Zeitverfolgung beim Entwicklungsprozess Definition von Qualit tsma en f r Produkt pro Phase Erhebung von Fehlerstatistiken 4 Analyse der Ergebnisse und Erarbeitung von Verbesserungsvorschl gen Auswertung der Ma e Definition von Zielen auf Basis der Messwerte Entscheidung f r Verbesserung in bestimmten Phasen Auswahl geeigneter Methoden und Werkzeuge Einf hrung der Methoden und Werkzeuge in Entwicklungsprozess 5 Bewertung der durchgef hrten nderungen Kontinuierliche Weiterauswertung der Ma e erneute Analyse nach Abklingen von Einschwingvorg ngen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 240 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Abstraktes Fallbeispiel aus Li02 l Angestrebt wird die deutliche Reduktion der Fehleranzahl mit dem Ziel den Kunden in Zukunft zuverl ssigere Produkte zur Verf gung zu stellen Minimiert wird daf r das Zuverl ssigkeitsma MTBF Mean Time Between Failure mittlere verstrichene Zeit zwischen zwei Fehlern innerhalb von 343 Tagen wurden 17 schwerwiegende Fehler gemeldet gt MTBF 20 2 alle 20 2 Tage tritt durchschnittlich ein Fehler auf Die
82. Wartungszweig 3 2 f r Release V 4 1 Wartungszweig f r Release V 4 2 Vorgehensweise bei Linux Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 113 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme 2 5 Buildmanagement Das Buildmanagement Software Manufacturing automatisiert den Erzeugungsprozess von Programmen Software Releases Altes Beispiel einfache Assemblerimplementierung in C assembler c Modul h Datei c Datei M1 M2 Importbeziehung pass0 h amp c pass1 h amp c pass2 h amp c M1 c Datei includes Pa M2 h Datei messages h amp c symbtab h amp c alle Module Pakete h ngen davon ab files h amp c global h Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 114 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Erl uterungen zum Beispiel Implementierung in C U jedes normale Modul M besteht aus zwei Textdateien gt die Header Datei M h beschreibt die Schnittstelle des Moduls die von anderen Moduln ben tigt wird Konstanten Typen Prozedurdefinitionen die Implementierungsdatei M c enth lt die C Quelltexte der Prozeduren das Modul global besteht nur aus einer Textdatei global h die Datei enth lt berall ben tigte
83. aber gro es Gewicht auf sorgf ltige Testplanung Tests werden immer zusammen mit oder gar vor Code geschrieben nach jeder nderung werden alle Tests durchlaufen Regressionstests unbedingtes Einhalten der 40 Stunden Woche Auftraggeber soll permanent neue Anforderungen aufstellen und priorisieren sehr kurze Iterationszyklen h ufige Releases Pair Programming Teams E E E E E E E E E E E Subsets obiger Ideen d rfen nicht XP genannt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 375 SE II Management der Software Entwicklung Echizeit gt 2 Randbedingungen maximal 5 bis 10 Programmierer an einem Projekt beteiligt Beschr nkung auf relativ kleine Projekte Kommunikation zwischen Programmierern und mit dem Kunden sehr intensiv keine r umlich verteilten Teams Kunde verzichtet auf separate Dokumentation der Software I zugunsten einer durch ausf hrliches Testen unterst tzten Rapid Prototyping Vorgehensweise Programmierer versuchen nicht bei der Realisierung des aktuellen Releases bereits k nftige Releases mit zu ber cksichtigen Programmierer sind aber zum st ndigen Umbau Redesign der bereits erstellten Software bereit Prinzip des Refactorings von Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 376 SE II Management der Software Entwicklung Echizeit gt 2 Bewertung von XP s
84. alifikationen und Rollen nach SL12 U Testmanager Leiter ist f r Testplanung sowie Auswahl von Testwerkzeugen zust ndig und vertritt Testinteressen gegen ber Projektmanagern U Testdesigner Analyst erstellt Testspezifikationen und ermittelt Testdaten Erg nzung k nnte beim modellbasierten Testen auch f r die Erstellung von Testmodellen und Festlegung von berdeckungskriterien zust ndig sein Testfallgenerator werden Testf lle aus Modellen bzw Spezifikationen automa tisch erzeugt so bedarf es einer weiteren Rolle die die Testfallgenerierung mit Werkzeugunterst tzung durchf hrt Testautomatisierer realisiert die automatisierte Durchf hrung der spezifizierten Testf lle durch ausgew hlte Testwerkzeuge Testadministrator stellt die Testumgebung mit ausgew hlten Testwerkzeugen zur Verf gung zusammen Systemadministratoren etc Tester ist f r Testdurchf hrung protokollkierung und auswertung zust ndig entspricht Certified Tester Foundation Level Kompetenzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 350 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Weitere Aspekte des Testmanagements nach SL12 Betrachtung von Kosten und Wirtschaftlichkeitsaspekten Ermittlung und Absch tzung von Fehlerkosten Ermittlung und Absch tzung von Testkosten Testaufwand Wahl einer Teststrategie proaktiv vs reaktiv
85. and Techniques Springer Verlag 2005 467 Seiten Ein Lehr Buch zum Software Produkt Familien Management von Software Varianten S001 I Sommerville Software Engineering Addison Wesley Pearson Studium 6 Auflage 2001 711 Seiten Ins Deutsch bersetztes Lehrbuch das sehr umfassend alle wichtigen Themen der Software Technik knapp behandelt Empfehlenswert SL12 A Spillner T Linz Basiswissen Softwaretest dpunkt verlag 2012 5 Auflage 290 Seiten Diesem Buch liegt der Lehrplan Grundlagen des Testens f r den ASQF Certified Tester Foundation Level zugrunde Wh00 B A White Software Configuration Management Strategies and Rational ClearCase Addison Wesley 2000 305 Seiten Clearcase war lange Zeit das kommerzielle Pendant zu CVS es besitzt wesentlich mehr Features die Administration erfordert allerdings auch mehr Aufwand Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 14 SE II Software Entwicklung Wartung und Re Engineering Eentzeit gt S Software Entwicklung Wartung und Re Engineering Software Systeme zu erstellen die nicht ge ndert werden m ssen ist unm glich Wurde Software erst einmal in Betrieb genommen ent stehen neue Anforderungen und vorhandene Anforderungen ndern sich S001 Lernziele Wissen ber Entwicklungsprozesse und Qualit tssicherung auffrischen Probleme mit der Pflege langlebiger Softwar
86. are L html 5 2 intern Y Unbenannt E owhe ZH 8 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 172 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 3 3 Manuelle statische Testverfahren Systematische Verfahren zur gemeinsamen Durchsicht von Dokumenten wie z B erstellte UML Modelle implementierten Klassen Programminspektion stark formalisiertes Verfahren bei dem Dokument nach genau festgelegter Vorgehensweise durch Gutachterteam untersucht wird Fokus auf Fehlersuche und nicht auf Diskussion alternativer Reali sierungsm glichkeiten Technisches Review weniger formale manuelle Pr fmethode weniger Aufwand als bei Programminspektion hnlicher Nutzen ggf zus tzlicher Schwerpunkt auf Diskussion und Bewertung von Alternativen Walkthrough Informelles Review unstrukturierte Vorgehensweise Autor des Dokuments liest vor Gutachter stellen spontan Fragen Empirische Ergebnisse zu Programminspektion Pr faufwand liegt bei ca 15 bis 20 des Erstellungsaufwandes 60 bis 70 der Fehler in einem Dokument k nnen gefunden werden gt Nettonutzen 20 Ersparnis bei Entwicklung 30 bei Wartung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 173 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Psychologische Probleme bei analytischen Testverfahren Entwickler sind in alle
87. as cvs mit nderungs managementdiensten kombiniert siehe http sourceforge net Q Open Software Produkt Bugzilla f r reines nderungsmanagement siehe http bugzilla mozilla org kommerzielles Produkt ClearQuest von Rational IBM passend zu KM Werkzeug ClearCase siehe Abschnitt 2 7 flexibles Projektmanagement Werkzeug Redmine http www redmine org Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 140 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s 2 7 Verteilte Softwareentwicklung Die bisher vorgestellten KM Systeme Versionsverwaltungssysteme eignen sich nur bedingt f r das Management sehr gro er und geographisch verteilter Projekte Ein kommerzielles Produkt wie ClearCase Rational IBM bietet f r die verteilte Softwareentwicklung in gro en Projekten u a folgende Vorteile gegen ber cvs und Subversion siehe auch Wh00 U Repositories Version Object Bases VOBs k nnen ber beliebig viele Fileserver transparent verteilt werden Replica von Dokumentversionen k nnen auf beliebig vielen Fileservern gehalten werden ein Server h lt aber das Original Master mit Schreibrecht Entwickler k nnen entweder im isolierten Workspace mit eigenen Objekten arbeiten hoher Speicher platzverbrauch geringere Netzlast oder ber dynamische Sichten auf gemeinsamen Repository arbeiten geringe rer Speicherplatzverbrauch h here Netzlast
88. ationsmanagement handelt es sich um die Entwicklung und Anwendung von Standards und Verfahren zur Verwaltung eines sich weiterentwickelnden Systemprodukts S001 Lernziele verstehen warum Konfigurationsmanagement KM wichtig ist Einf hrung in die wichtigsten Aufgabengebiete des KMs Open Source und kommerzielle CASE Werkzeuge f r KM kennenlernen KM f r verteilte Software Entwicklung in Open Source Projekten erleben selbst ndig KM Planung f r kleine Softwareprodukte durchf hren k nnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 55 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme 2 1 Einleitung Behandelte Fragestellungen Das System lief gestern noch was hat sich seitdem ge ndert Wer hat diese fehlerhafte nderung wann und warum durchgef hrt Wer ist von meinen nderungen an dieser Datei betroffen Auf welche Version des Systems bezieht sich die Fehlermeldung Wie erzeuge ich Version x y aus dem Jahre 1999 wieder Welche Fehlermeldungen sind in dieser Version bereits bearbeitet Welche Erweiterungsw nsche liegen f r das n chste Release vor Die Platte ist hin ber was f r einen Status haben die Backups 6 6 6 6 6 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 56 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Definition von Software KM na
89. auch Kontrollflussfehler besser geeignet f r objektorientierte Programme mit oft einfachem Kontrollfluss aber komplexem Datenfluss es gibt kaum Werkzeuge die datenflussbasierte Testverfahren unterst tzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 311 SE II Dynamische Programmanalysen und Testen Echtzeit systeme Zur Erinnerung Kontrollflussgraph mit Datenflussattributen PROCEDURE countVowels IN s Sentence OUT count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN start count 0 i 0 init WHILE sli DO IF slil a OR sli e OR s il i OR slil 0 OR sli u THEN count count 1 END i i 1 i d i n END WHILE Nfinal END countVowels final Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 312 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A Kriterien f r den Datenflusstest 1 Q all defs Kriterium f r jede Definitionsstelle d x einer Variablen muss ein definitionsfreier Pfad zu einer Benutzung r x existieren und getestet werden Kriterium kann statisch berpr ft werden entdeckt sinnlose Zuweisungen umfasst weder Zweig noch Anweisungs berdeckung bei countVowels reichen Testbeispiele und a Verfahren findet ei
90. ausserhalb des betrachteten Teilsystems abh ngen Instabilit t I I Ce Ce Ca I hat einen Wert zwischen 0 und 1 falls nicht Ce Ca 0 gilt mit 0 max stabil u 1 max unstabil der Wert 1 besagt dass Ca 0 ist das betrachtete Teilsystem exportiert also nichts nach au en keine Klassen und deren Methoden der Wert 0 besagt dass Ce 0 ist das betrachtete Teilsystem importiert also nichts von au en keine Klassen und deren Methoden Der undefinierte Fall Ca 0 und Ce 0 kann nur auf ein sinnloses isoliertes Teilsystem zutreffen das weder importiert noch exportiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 232 Fachgebiet y SE II Statische Programmanalyse amp Metriken Echtzeit Weitere Metriken Kopplung von Klassen 2 Q Coupling als Change Dependency between Classes CDBC CDBC zwischen Client Class CC und Server Class SC n falls SC Oberklasse von CC ist n Anzahl Methoden in CC n falls CC ein Attribut des Typs SC hat gt jfalls SC in j Methoden von CC benutzt wird als Typ lokaler Variable Parameter oder Methodenaufruf von SC CDBC bewertet den Aufwand der mit nderung der Klasse SC in CC verbunden sein k nnte sollte m glichst gering sein Encapsulation als Attribute Hiding Factor AHF gt Summe der Unsichtbarkeiten aller Attribute in allen Klassen geteilt durch die Anzahl aller Attribute Unsichtbarkeit eines Attribu
91. ber unabh ngig von Entwicklungsprozess Projektstruktur Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 120 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Werkzeuge f r das Build Management 2 Q Das Werkzeug Maven deklarativer Ansatz mit relativ einfachen Konfigurationsdateien macht viele Annahmen ber Entwicklungsprozess Projektstruktur keine frei definierbaren Regeln f r bestimmte Sprachen Werkzeuge sondern stattdessen Plugins Fokus liegt auf der Unterst tzung von Java Projekten holt sich Plugins Libraries aus zentralen Repositories oft kombiniert mit Nexus f r Einrichten lokaler Cache Repositories Das Werkzeug Jenkins fr her Hudson gt erg nzt Build Werkzeuge wie Ant und Maven gt unterst tzt die kontinuierliche Integration Konstruktion von Produkten automatische Integration von Build Test Reporting Werkzeugen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 121 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Das Programm make zur Automatisierung von Build Vorg ngen Q make wurde in den 70er Jahren nebenbei von Stuart F Feldman f r die Erzeugung von Programmen unter Unix programmiert U Varianten von make gibt es heute auf allen Betriebssystemplattformen oft integriert in oder spezialisiert au
92. berdeckung wird durch RTCA DO 178B Standard f r Software Anwendungen in der Luftfahrt der Kritikalit tsstufe A gefordert Soft ware deren Ausfall zu katastrophaler Systemfehlfunktion f hren kann Zweig berdeckung sollte f r uns Mindestanforderung beim Testen darstellen Kontrollflussfehler Bedingungsfehler werden relativ gut gefunden Datenfluss fehler nat rlich weniger gut Einfache Variante von modified boundary interior test zur Erg nzung f r jede Schleife gibt es Testf lle Pfade die sie gar nicht genau einmal und mindestens zweimal ausf hren die Randbedingung alle Pfade wird komplett aufgegeben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 310 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit 4 5 Datenflussbasierte Testverfahren Ausgangspunkt ist der Datenflussgraph einer Komponente bzw der mit Datenflussattributen annotierte Kontrollflussgraph Bei der Auswahl von Testf llen wird darauf geachtet dass gt f r jede Zuweisung eines Wertes an eine Variable mindestens eine berechnende pr dikative Benutzung dieses Wertes getestet wird gt oder f r jede Zuweisung eines Wertes an eine Variable alle berechnenden pr dikativen Benutzungen dieses Wertes getestet werden Die datenflussbasierten Testverfahren haben folgende Vor und Nachteile einige Verfahren enthalten die Zweig berdeckung und finden sowohl Daten flussfehler als
93. bung wie UML Statecharts erlauben oft auch die Definition ereignisloser Transitionen Diese werden wie folgt beim Testen behandelt U Transition ohne Ereignis mit Bedingung b sobald die Bedingung erf llt ist schaltet die Transition beim Aufstellen von Testsequenzen sind zwei F lle zu unterscheiden zwei Unterb ume im Transitionsbaum Bedingung b ist bereits erf llt wenn Startzustand der Transition betreten wird Transition wird mit der Bedingung b true markiert und schal tet sofort bei der Testausf hrung Bedingung ist nicht erf llt wenn Startzustand betreten wird wird sp ter aber erf llt Transition wird mit Ereignis b gt true markiert und schaltet sobald die Bedingung b erf llt ist Transition ohne Ereignis und ohne Bedingung die Transition schaltet sobald der Startzustand betreten wird der Startzustand erh lt im Transitionsbaum eine ausgehende Kante Transition ohne Markierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 346 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Ausf hrung der Testsequenzen U Testvorbereitung Objekt muss in initialen Zustand zur ck versetzt werden Testausf hrung einer Sequenz von Methodenaufrufen Testvektor es wird unterschieden white box Sicht es gibt Zugriffsoperationen f r Abfrage des internen Zustands man kann also am Ende einer Testsequenz abfragen ob richtiger Zustand
94. bute name und addr zu Es gilt dann es gibt 10 verschiedene Paarungen und P 4 und Q 6 also LOCOMI 0 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 230 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Bindungsmetriken LOCOM2 Low Cohesion Metric Die Bindung der Methoden einer Klasse wird untersucht Methoden sind eng aneinander gebunden wenn sie auf viele gemeinsame Attribute Felder zugreifen m Anzahl Methoden m einer Klasse m a Anzahl Methoden die auf Attribut a zugreifen a Anzahl Attribute a einer Klasse gt LOCOM2 1 m a m a m a Gew nscht wird kleiner Wert von LOCOM2 z B kleiner 0 3 30 Beispiel getName und setName der Klasse Person greift auf Feld name zu getAddr und setAddr der Klasse Person greift auf Feld addr zu compare greift auf Felder name und addr zu Es gilt dann m name m addr 3 und LOCOM2 1 3 3 10 0 4 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 231 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Weitere Metriken Kopplung von Klassen 1 Q Afferent Coupling Ca AC Die Anzahl der Klassen ausserhalb eines betrachteten Teilsystems Kategorie die von den Klassen innerhalb des Teilsystems abh ngen Efferent Coupling Ce EC Die Anzahl der Klassen innerhalb eines betrachteten Teilsystems Kategorie die von Klassen
95. ch IEEE Standard 828 1988 IEEE98 SCM Software Configuration Management constitutes good engineering practice for all software projects whether phased development rapid prototyping or ongoing maintenance It enhances the reliability and quality of software by Providing structure for identifying and controlling documentation code interfaces and databases to support all life cycle phases Supporting a chosen development maintenance methodology that fits the requirements standards policies organization and management philosophy Producing management and product information concerning the status of baselines change control tests releases audits etc Anmerkung U wenig konkrete Definition unabh ngig von Software Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 57 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Definition nach DIN EN ISO 10007 KM Konfigurationsmanagement ist eine Managementdisziplin die ber die gesamte Entwicklungszeit eines Erzeugnisses angewandt wird um Transparenz und berwachung seiner funktionellen und physischen Merkmale sicherzustellen Der KM Prozess umfasst die folgenden integrierten T tigkeiten Q Konfigurationsidentifizierung Definition und Dokumentation der Bestandteile eines Erzeugnisses Einrichten von Bezugskonfigurationen O Konfigurations berwachung Dokumentation und Begr ndung vo
96. cklungspersonal Fehlerbehebung f hrt neue Fehler ein stetige Verschlechterung der Programmstruktur Zusammenhang zwischen Programm und Dokumentation geht verloren zur Entwicklung eingesetzte Werkzeuge CASE Tools Compiler sterben aus ben tigte Hardware steht nicht mehr zur Verf gung Resourcenkonflikte zwischen Fehlerbehebung und Anpassung Erweiterung v llig neue Anspr che an Funktionalit t und Benutzeroberfl che E E E E E E E E Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 42 systeme SE II Software Entwicklung Wartung und Re Engineering Eee 2 Einfaches Software Lebenszyklus Prozessmodell f r die Wartung nderungsw nsche Bewertung Versionsplanung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 43 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Das V Modell Standard der Bundeswehr bzw aller Bundesbeh rden SE 1 System Anforderungs 88 9 berleitung in die analyse N Nutzung l 1 SE 2 System Entwurf lt SE 8 System Integration l 1 SE 3 SW HW Anforderungs SE 7 analyse SW Integration SE 4 SW Grobentwurf SE 5 SW Feinentwurf r SE 6 SW Implementierung weitere Informationen zu Prozessmodellen in Kapitel 5 der Vorlesung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 44 SE II Software Entwicklung Wa
97. d Reverse Re Integrations ae CARE amp Systemtest Code Generator I ntegrated CASE Tool Upper Lower CASE Tool Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 51 SE II Software Entwicklung Wartung und Re Engineering Eentzeit gt t 1 5 Zusammenfassung Die Lehrveranstaltung Software Engineering Einf hrung und das SW Praktikum haben sich nur mit dem Forward Engineering von Software Systemen befasst also nur mit ca 20 40 des Software Lebenszyklus Das Thema Software Qualit ts sicherung wurde zudem nur kurz angerissen In dieser Vorlesung befassen wir uns deshalb mit Q Kapitel 2 Management von Software nderungsprozessen O Kapitel 3 Analyse und berwachung von Software Qualit t U Kapitel 4 Qualit tssicherung durch systematisches Testen Kapitel 5 Management der Software Entwicklung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 52 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t 1 6 Zus tzliche Literatur BD00 B Bruegge A H Dutoit Object Oriented Software Engineering Conquering Complex and Changing Systems Prentice Hall 2000 BEM92 A W Brown A N Earl J A McDermid Software Engineering Environments Automated Support for Software Engineering McGraw Hill 1992 Di72 E W Dijkstra The Humble Programmer Communications of the ACM V
98. d zu ngna 4 f r d i bei n Pfad zu n Minimale Anzahl von Testf llen l a 2 3 aa A I I a Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 318 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme All p uses some c uses Test am Beispiel PROCEDURE countVowels IN s Sentence OUT count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot 1 f r d s bei nsan Pfad zu n und n u i d s O Nstart f r d i bei Ninit h Pfad zu N while und N r u cou nt f r d count bei Ninit Pfad zu Neount oder Ninit definitionsfreier direkter Pfad zu ngra s j Np f r d count bei n un Pfad zu non oder ADIE definitionsfreier direkter Pfad zu ngra Nif 5 f r d i bei n Pfad zu Nypi und n Es reicht also jede Eingabe mit folgendem Aus f hrungspfad Nstart gt Ninit gt Awhile gt Pif gt gt Heount gt N Awhile gt Nif gt Nwhile gt Afinal ni Minimaler Testfall ab Nfinal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 319 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Zusammenfassung des berdeckungsbasierten Testens Q man w hlt ein oder mehrere berdeckungskriterien aus die der Kritikalit t der zu entwickelnden Software ge
99. der geerbten Invarianten invariant isOff isFlashing isGreen isYellow isRed neue Observer Operation bool isFlashing neue Modifier Operation virtual void flashingOn precondition isRed isYellow isGreen postcondition isFlashing Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 331 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Erlaubte Versch rfung ge nderter Invarianten class FlashingTrafficLight public TrafficLight bietet neue Operation blinkendes gelbes Licht an verbietet direkten bergang von rotem Licht zu gr nem Licht bei der Gelbphase nach der Rotphase ist auch das rote Licht an public invariant isOff isOn ge nderte geerbte Bedingung v TrafficLight invariant isGreen isYellow isRed isOn neue geerbte Bedingung Mus erlaubte Versch rfung der geerbten Invarianten invariant isFlashing isOn hinzugef gte Bedingung in FlashingTrafficLight neue Observer Operation bool isFlashing neue Modifier Operation virtual void flashingOn precondition isRed isYellow isGreen postcondition isFlashing Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 332 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Implementierung der
100. derungen U Lasttest Messung des Systemverhaltens bei steigender Systemlast Performanztest Messung der Verarbeitungsgeschwindigkeit unter bestimmten Randbedingungen Kompatibilit t Vertr glichkeit mit vorhandenen anderen Systemen korrekter Im und Export externer Datenbest nde Benutzungsfreundlichkeit bersichtliche Oberfl che verst ndliche Fehlermel dungen Hilfetexte f r die jeweilige Benutzergruppe Benutzerdokumentation Vollst ndigkeit Verst ndlichkeit nderbarkeit Wartbarkeit modulare Systemstruktur verst ndliche Entwickler Dokumentation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 265 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Akzeptanztest Abnahmetest U Es handelt sich um eine spezielle Form des Systemtests gt der Kunde ist mit einbezogen bzw f hrt den Test durch gt der Test findet beim Kunden aber in Testumgebung statt Test in Produktionsumgebung zu gef hrlich auf Basis des Abnahmetests entscheidet Kunde ob das bestellte Softwaresystem mangelfrei ist und die im Lastenheft festgelegten Anforderungen erf llt die durchgef hrten Testf lle sollten bereits im Vertrag mit dem Kunden spezifiziert sein im Rahmen des Abnahmetests wird gepr ft ob System von allen relevanten Anwendergruppen akzeptiert wird im Rahmen von sogenannten Feldtests wird dar ber hinaus ggf das System in verschiedene
101. derungsmarkierung Aufeinander folgende Hunks sind durch mindestens eine unver nderte Zeile getrennt KK KK KK KK KK K K K K K K K K K K Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 74 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Richtiges Diff Ergebnis 2 ge nderte Zeilen 1 neue 1 gel schte KKK 01 03 KKK Hunk 1 KKK Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile und enth lt sonst nur ge nderte gel schte oder neu eingef gte Zeilen 01 02 Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile KK K K K K K K K K K K K K K K K K K K K x 05 06 KKK Hunk 2 KKK nderungsmarkierung Hunks sind durch mindestens eine unver nderte Zeile getrennt 04 06 nderungsmarkierung Aufeinander folgende Hunks sind durch mindestens eine unver nderte Zeile getrennt KKK K K K K K K K K K K K K K K K K K K K K Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 75 Fachgebiet 4 SE II Konfigurationsmanagement Echtzeit A systeme Beispiel alte Version Zeilennummern nicht Bestandteil der Zeile Die Anzahl der Zeilen aller Hunks eines Deltas zweier Dateien wird m glichst klein gehalten Jeder Hunk beginnt mit genau e
102. e Analysen 3 4 Softwaremetriken 3 5 Zusammenfassung Dynamische Programmanalysen und Testen 4 1 Einleitung 4 2 Laufzeit und Speicherplatzverbrauchsmessungen 4 3 Funktionsorientierte Testverfahren 4 4 Kontrollflussbasierte Testverfahren 4 5 Datenflussbasierte Testverfahren 4 6 Testen objektorientierter Programme plus Vortrag zu modellbasiertem Testen 4 7 Testmanagement und Testwerkzeuge plus zwei Industrievortr ge 4 8 Zusammenfassung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 8 Fachgebiet Echtzeit systeme Inhaltsverzeichnis der Vorlesung 3 5 Management der Software Entwicklung 5 1 Neuere Vorgehensmodelle 5 2 Rational Unified Process f r UML 5 3 Leichtgewichtige Prozessmodelle 5 4 Verbesserung der Prozessqualit t 5 5 Projektpl ne und Projektorganisation 5 6 Weitere Literatur Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 9 Fachgebiet 7 Echtzeit ay systeme Ihre fiktive Aufgabe ist es die Software eines Open Source Projektes weiterzuentwickeln ImageJ unter http rsbweb nih gov ij bungen zur Vorlesung Vorgehensweise Organisation als Teams von jeweils etwa 4 Studenten in Pr senz bungen werden Musterl sungen f r bungsaufgaben vorgestellt es gibt meist klausur hnliche Hausaufgaben Einsatz verschiedener CASE Tools f r Open Source Softwareentwicklung zus tzliche Betreuungsterm
103. e SW Artefakte die f r alle Instanzen der Produktlinie gleich sind Damit ist die Software Produktlinien Entwicklung SPLE Software Product Line Engineering eine logische Verallgemeinerung des Variantenmanagements eines Softwaresystems Man unterscheidet beim SPLE zwischen der Dom nenentwicklung Domain Engineering der gemeinsamen Plattform development for reuse der Anwendungsentwicklung Application Engineering von SPL Instanzen development with reuse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 100 SE II Konfigurationsmanagement Dom nen und Anwendungsentwicklung Product Management Domain Requirements Engineering Domain Realisation Domain Engineering Application Requirements Engineering Application Application Design Realisation Ih o hri Application Testing Fachgebiet Echtzeit systeme Abb aus IPBLO5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 101 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Variabilit tsmodell Feature Modell einer SPL So genannte Variabilit ts oder Feature Modelle beschreiben alle m glichen Eigenschaften einer Software Produktlinie und zul ssige Kombinationen Konfigura tionen Varianten Instanzen dieser Produktlinie Eine Vielzahl von Notationen und Werkzeugen unterst tzen die Erstellung solcher Modelle du
104. e der 27 m glichen 3er Kombinationen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 288 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Bewertung der funktionalen quivalenzklassenbildung G te des Verfahrens h ngt stark von G te der Spezifikation ab Aussagen ber erwartete zul ssige Eingabewerte und Ergebnisse O Verwaltung von quivalenzklassen und Auswahl von Testf llen kann durch Werkzeugunterst tzung vereinfacht werden ausf hrbare Modelle z B in UML erstellt k nnen bei der Auswahl von quivalenzklasssen Testf llen helfen und als Orakel verwendet werden Test von Benutzeroberfl chen zeitlichen Beschr nkungen Speicherplatz beschr nkungen etc nichtfunktionale Anforderungen wird kaum unterst tzt mindestens einmalige Ausf hrung jeder Programmzeile wird nicht garantiert Test zustandsbasierter Software Ausgabeverhalten h ngt nicht nur von Eingabe sondern auch von internem Zustand ab geht so nicht sp ter Spezifikation und Testplanung mit Hilfe von Automaten Statecharts gt Grenzfall zwischen funktionalem und strukturorientiertem Softwaretest Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 289 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Weitere Black Box Testverfahren intuitives Testen aus dem Bauch heraus zus tzliche Testf lle festlegen Q Zufa
105. e kennenlernen Begriffe Software Wartung und Evolution definieren k nnen Forward Reverse und Reengineering unterscheiden k nnen Motivation f r den Inhalt dieser Lehrveranstaltung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 15 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit S 1 1 Einleitung Zur Erinnerung die Geschichte der Software Technik Ausl ser f r Einf hrung der Software Technik war die Software Krise von 1968 Der Begriff Software Engineering wurde von F L Bauer im Rahmen einer Study Group on Computer Science der NATO gepr gt Bahnbrechend war die NATO Konferenz Working Conference on Software Engineering vom 7 10 Oktober 1968 in Garmisch Das Gebiet Software Technik wird der praktischen Informatik zugeordnet hat aber auch Wurzeln in der theoretischen Informatik Informatik bergreifende Aspekte spielen eine wichtige Rolle wie Projektplanung Organisation Psychologie Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 16 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Definition des Begriffs Software Technik Software Engineering Software Technik ist nach Ka93 die Entwicklung die Pflege und der Einsatz qualitativ hochwertiger Software unter Einsatz von wissenschaftlichen Methoden wirtschaftlichen Prinzipien
106. eak of 50 bytes From 1 block allocated in Scr md HOK Datoanti al nannien Inal nE CA hubnr Coena 4 Innu allnraknrd dn u k welFerem Jaf Timbavad errinee esf 0O Auben kehad MIEG Achtung so viele Speicherl cher ist typisch f r Programmierung in C Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 274 SE II Dynamische Programmanalysen und Testen Echtzeit systeme 4 3 Funktionsorientierte Testverfahren Sie testen Implementierung gegen ihre Spezifikation und lassen die interne Programmstruktur unber cksichtigt Programm wird als Black Box behandelt f r Abnahmetest ohne Kenntnis des Quellcodes geeignet setzt eigentlich vollst ndige und widerspruchsfreie Spezifikation voraus zur Auswahl von Testdaten und Interpretation von Testergebnissen repr sentative Eingabewerte m ssen ausgew hlt werden man kann im allgemeinen nicht alle Eingabekombinationen testen man braucht Orakel f r berpr fung der Korrektheit der Ausgaben braucht man allerdings bei allen Testverfahren rn MADO Ausgaben Orakel Y Ausgabe ok Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 275 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Kriterien f r die Auswahl von Testdaten An der Spezifikation orientierte quivalenzklassenbildung so dass f r alle Werte einer quivalenzklasse Eingabe
107. eference lebendige Variablen Anzahl 1 min max min max hilf min min max hilf 2 3 min max min max hilf 4 max hilf max hilf Live Variables 2 5 Variablenspanne 1 1 pur min 2 1 ur max 2 f r hilf 5 E 1 4 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 227 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Erste berlegungen zu Metriken f r objektorientierte Programme Betrachtet wird oft Kopplung von Klassen Benutzt Beziehungen zwischen Klassen geringer fan out wenige auslaufende Benutzt Beziehungen ist positiv da sich dann eine Klasse auf wenige andere Klassen abst tzt hoher fan in viele einlaufende Benutzt Beziehungen ist positiv da dann eine Klasse von vielen Klassen wieder verwendet wird beides kann nicht maximiert werden da ber alle Klassen hinweg gilt Summe fan in Summe fan out Eine Klasse A benutzt eine Klasse B wenn in A ein Verweis auf Objekt der Klasse B verwendet wird in A eine Operation einen Parameter der Klasse B verwendet gt in A eine Operation der Klasse B aufgerufen wird Achtung hnlich kann man Kopplung von Modulen Pakete bzw Kopplung von Methoden studieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 228 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Metriken f r OO Pr
108. el f r Probleme mit dem automatischen Verschmelzen PROCEDURE P a b INTEGER BEGIN IF a lt b THEN PROCEDURE P v w INTEGER PROCEDURE P a b INTEGER VAR a INTEGER BEGIN BEGIN ni IF a lt b THEN WHILE v lt w DO ELSIF a b THEN PROCEDURE P v w INTEGER END VAR a INTEGER END P BEGIN WHILE v lt w DO ELSIF a b THEN syntaktisch fehlerhafte Zeile END Fr semantisch fehlerhafte Bindung von a an ENDP lokale Variablendeklaration statt an v Selbst wenn keine Konflikte gemeldet werden kann Ergebnis syntaktisch oder semantisch fehlerhaft sein in der Praxis passiert das aber selten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 87 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Optimistisches Sperrkonzept mit Merge Entwickler A macht checkout einer Revision n Entwickler A ver ndert Revision n lokal zu n1 Entwickler B macht checkout derselben Revision n Entwickler B ver ndert Revision n lokal zu n2 Entwickler B macht commit seiner ge nderten Revision n2 Entwickler A versucht commit seiner ge nderten Revision n1 wird mit Fehlermeldung abgebrochen Entwickler A macht update seiner ge nderten Revision nl automatisches merge von nl und n2 mit Basis n f hrt zu n Entwickler A l st Verschmelzungskonflikte manuell auf und erzeugt n Entwickler A macht commit von Revision n inklusive nderungen von B
109. eler abschaltbarer Konsistenzpr fungen in Code Vor und Nachbedingungen und ggf defensive Programmierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 355 i Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit 4 9 Erg nzende Literatur Bi00 R V Binder Testing Object Oriented Systems Addison Wesley 2000 1191 Seiten BP84 V R Basili B T Perricone Software Errors and Complexity An Empirical Investigation Communica tions of the ACM Vol 27 No 1 42 52 ACM Press 1984 FRSW03 F Fraikin E H Riedemann A Spillner M Winter Basiswissen Softwaretest Certified Tester Skript zu Vorlesungen an der TU Darmstadt Uni Dortmund Bremen und FH K ln 2003 FS98 M Fowler K Scott UML konzentriert Die neue Standard Objektmodellierungssprache anwenden Addison Wesley 1998 188 Seiten MSO1 J D McGregor D A Sykes A Practical Guide to Testing Object Oriented Software Addison Wesley 2001 SL12 A Spillner T Linz Basiswissen Softwaretest dpunkt verlag 2012 5 Auflage 290 Seiten V105 U Vigenschow Objektorientiertes Testen und Testautomatisierung in der Praxis dpunkt verlag 2005 331 Seiten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 356 SE II Management der Software Entwicklung a systeme 5 Management der Software Entwicklung Themen dieses Kapitels U bessere modernere Pr
110. elle ver nderbar festgelegt werden Programmabbruch Ausnahmeerweckung die berpr fungen sollten m glichst lesbar niedergeschrieben werden Invarianten werden auch vor der Ausf hrung einer Methode und nach der Ausf hrung von Observer Methoden berpr ft um illegale Objektzugriffe entdecken zu k nnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 334 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme Zusicherungen Assertions in Java Q Java besitzt ab Version 1 4 assert Statement das f r den Einbau von berpr fungen Vor Nachbedingungen Invarianten genutzt wird Q die berpr fung von assert Statements kann durch Runtime Flags generell oder klassenweise an bzw abgeschaltet werden enableassertions ea und disableassertions da die berpr fungen sollten das Verhalten des ausf hrbaren Programms abgesehen von Laufzeit und Speicherplatzverbrauch nicht ver ndern der Programmierer muss das sicherstellen soll der Code f r assert Statements nicht Bestandteil des ausf hrbaren Programms sein so muss der Compiler davon berzeugt werden dass der Code wegoptimiert werden kann static final boolean assertChecksOn false to eliminate asserts if assertChecksOn assert assert Verletzungen k nnen als AssertionError Ausnahmen abgefangen
111. eme Virtuell existiert ein gemeinsames globales Repository f r alle Entwickler Es gibt dennoch keinen ausgew hlten zentralen Server Tats chlich besitzt jeder Peer ein eigenes Repository mit allen Dateien oder ausgew hlter Menge von Revisionen Das P2P Versionierungs System ist immun gegen Ausscheiden einzelner Peers Revisionen werden auf mehreren Peers gehalten Bei Netzpartitionierungen Spezialfall einzelner Entwickler arbeitet offline wird je Partition ein eigener Branch angelegt Schlie en sich Partitionen wieder zusammen dann werden Branches wieder verschmolzen im allgemeinen mit Entwicklerhilfe Fazit P2P Versionierungssysteme sollen die Vorteile von VCS und DVCS vereinen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 149 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme 2 8 Zusammenfassung Mit einem f r die jeweilige Projektgr e sinnvollen KM Management steht und f llt die Qualit t eines Softwareentwicklungsprozesses insbesondere nach der Fertigstellung des ersten Softwarereleases Meine Ratschl ge f r das KM Management besteht ihr System aus mehr als einer Handvoll Dateien so sollte ein Buildmanagementsystem wie make Ant Maven verwendet werden haben sie Entwicklungszeit von mehr als ein paar Tagen oder mehr als einem Entwickler so ist ein Versionsmanagementsystem wie svn oder git ein Muss haben sie mehr als eine
112. ement Echtzeit A systeme A Genauere Instruktionen zur Erzeugung von Deltas Jedes diff Werkzeug hat seine eigenen Heuristiken wie es m glichst kleine und oder lesbare Deltas Patches erzeugt die die Unterschiede zweier Dateien darstellen Ein m glicher und in den bungen verwendeter Satz von Regeln zur Erzeugung von Deltas sieht wie folgt aus 1 Die Anzahl der ge nderten gel schten und neu erzeugten Zeilen aller Hunks eines Deltas zweier Dateien wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile und enth lt sonst nur ge nderte gel schte oder neu eingef gte Zeilen Ausnahme Dateianfang Aufeinander folgende Hunks sind also durch jeweils mindestens eine unver n derte Zeile getrennt Optional Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man die nderungsmarkierung a Durch diese Regeln nicht gel stes Problem Wie erkenne ich ob eine nderung in Zeile i durch Einf gen einer neuen Zeile oder durch ndern einer alten Zeile zustande gekommen ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 72 Fachgebiet 4 SE II Konfigurationsmanagement Echtzeit A systeme A Beispiel alte Version Zeilennummern nicht Bestandteil der Zeile Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile und enth lt sonst nur ge nderte gel sc
113. en dass eine Machbarkeitsstudie ohne ein grobes Design der zu erstellenden Software nicht durchf hrbar ist da gt Arbeitspakete ergeben sich aus der Struktur der Software Abh ngigkeiten und Umfang der Pakete ebenso Realisierungsart der Pakete bestimmt ben tigte Ressourcen Konsequenz Projektplanung und organisation ist ein fortlaufender Prozess Zu Projektbeginn hat man nur einen groben Plan der sukzessive verfeinert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 395 SE II Management der Software Entwicklung Echizeit gt 2 Terminologie Prozessarchitektur grunds tzliche Vorgehensweise einer Firma f r die Beschreibung von Software Entwicklungsprozessen Notation Werkzeuge Prozessmodell Vorgehensmodell von einer Firma gew hlter Entwicklungs prozess Wasserfallmodell oder RUP oder Projektplan an einem Prozessmodell sich orientierender Plan f r die Durchf h rung eines konkreten Projektes Vorgang Aufgabe Arbeitspaket abgeschlossene Aktivit t in Projektplan die bestimmte Eingaben Vorbedingungen ben tigt und Ausgaben produziert Personal und sonstige Betriebsmittel f r Ausf hrung braucht eine bestimmte Zeitdauer in Anspruch nimmt und Kosten verursacht und oder Einnahmen bringt Phase Zusammenfassung mehrerer zusammengeh riger Vorg nge zu einem globalen Arbeitsschritt Meilenstein Ende einer Gruppe von Vorg ngen Phase
114. en Software systems zu erfassen Gesch ftsvorf lle Abl ufe U Requirements Capture befasst sich damit die Anforderungen an ein Software system noch sehr informell zu erfassen Analysis Design pr zisiert mit grafischen Sprachen Klassendiagramme etc die Anforderungen und liefert Systemarchitektur Implementation Test entspricht den Aktivit ten in den Phasen Codierung bis Integrationstest des Wasserfallmodells Deployment entspricht Auslieferung und Installation des Wasserfallmodells Configuration Management befasst sich mit der Verwaltung von Softwareversionen und varianten Project Management mit der Steuerung des Entwicklungsprozesses selbst Environment bezeichnet die Aktivit ten zur Bereitstellung ben tigter Ressourcen Rechner Werkzeuge Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 372 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit systeme Bewertung des Rational Unified Prozesses Manager hat die grobe Inception Elaboration Construction Transition Sicht Entwickler hat zus tzlich die feinere arbeitsbereichsorientierte Sicht Wartung ist eine Abfolge zu entwickelnder Produktgenerationen es wird endg ltig die Illusion aufgegeben dass Analyse Design zeitlich begrenzte strikt aufeinander folgende Phasen sind komplexes noch in Ver nderung befindliches Vorgehensmodell f r UML noch nicht mit Beh
115. en mit Abschluss jeder Phase deutlich an bei XP verspricht man sich eine konstante Kosten kurve f r die Durchf hrung gew nschter nderungen da nur Code zu ndern ist Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 378 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit 5 4 Verbesserung der Prozessqualit t Ausgangspunkt der hier vorgestellten Ans tze sind folgende berlegungen Softwareentwicklungsprozesse sind selbst Produkte deren Qualit t ber wacht und vIQMerbessert werden muss bei der Softwareentwicklung sind bestimmte Standards einzuhalten Ent wicklungsprozess muss dokumentiert und nachvollziehbar sein es bedarf kontinuierlicher Anstregungen um die Schw chen von Entwick lungsprozessen zu identifizieren und zu eliminieren Hier vorgestellte Ans tze ISO 9000 Normenwerk Int Standard f r die Softwareindustrie Capability Maturity Model CMM CMMI des Software Engineering Institutes SEI an der Carnegie Mellon University 1ISO Norm SPiCE http www sqi gu edu au SPICE integriert und vereinheitlicht CMM und ISO 9000 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 379 SE II Management der Software Entwicklung a systeme Qualit tssicherung mit der ISO 9000 Das ISO 9000 Normenwerk http www iso 9000 co uk legt f r das Auftraggeber Lieferantenverh ltnis einen allgemeinen organisator
116. en und Verbindungen dazwischen verwenden siehe Vorlesung Echtzeitsysteme siehe auch SG96 Heute verwendet man einen noch umfassenderen Architekturbegriff n Software Engineering I werden folgende Architektursichten im Zusammenhang mit der Unified Modeling Language UML eingef hrt gt Teilsystem Sicht Paketdiagramme Struktur Sicht Klassendiagramme Kollaborationsdiagramme Datenfluss Sicht Aktivit tsdiagramme gt Kontrollfluss Sicht Aktivit tsdiagramme gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 164 SE II Statische Programmanalyse amp Metriken Beispiel f r ADL ala in aata PR ER im Me Sero Belea Degn rory Bin inion Gep Sea tjitro Mely bk Eieren P DENI Frani ENTE RE Hoaf Name a nn em Properties Rules Suracnune Types Rupeesemane i ame i j HE Pamti gga wea eg m chin Va Fachgebiet Echtzeit systeme Komponente Verbindung Acme Studio Werkzeug http www 2 cs cmu edu acme AcmeStudio Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 165 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Software Visualisierung Begriffskl rung siehe auch SD98 Algorithmus versus Programm Algorithmenvisualisierung die prinzipielle Idee eines Algorithmus wird durch Visualisierung erl utert Programmvisualisierung da
117. ener Fehler Einhaltung von Standards z B als Anzahl Verletzung von Stilregeln Prozessmetriken messen Eigenschaften des Entwicklungsprozesses Dauer oder Kosten der Entwicklung z B als Mitarbeitermonate gt Zufriedenheit des Kunden z B als Anzahl nderungsw nsche Achtung die Software Engineering Literatur verwendet meist die Begriffe Ma und Metrik als Synonyme Metrik in der Mathematik Entfernung zweier Punkte die gemessen werden kann Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 207 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Gew nschte Eigenschaften von Ma Metrik U Einfachheit berechnetes Ma l sst sich einfach interpretieren z B Zeilenzahl einer Datei Eignung Validit t es besteht ein einfacher Zusammenhang zwischen der gemessenen Eigenschaft und der interessanten Eigenschaft z B zwischen Programml nge und Fehleranzahl Stabilit t gemessene Werte sind stabil gegen ber Manipulationen untergeordneter Bedeutung z B die Unterschiede zwischen zwei Projekten wenn man aus erstem Projekt R ckschl sse auf zweites Projekt ziehen will Rechtzeitigkeit das Ma kann zu einem Zeitpunkt berechnet werden zu dem es noch zur Steuerung des Entwicklungsprozesses hilfreich ist Gegenbeispiel Programml nge als Ma f r Sch tzung des Entwicklungsaufwandes Reproduzierbarkeit am besten automatisch berechenbar ohne sub
118. entwicklung Release 1 1 Wartung Release 1 2 Weiterentwicklung Release 2 Weiterentwicklung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 68 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Exkurs zu diff und patch Beispiel PROCEDURE P a b INT PROCEDURE P v w INT PROCEDURE P v w INT BEGIN 2 BEGIN BEGIN IF a lt b THEN l iF yv amp wTHEN i WHILE v lt w DO END ELSE END END P zE END P END diff patch 01 01 Hunk 1 10 13 Hunk 1 PROCEDURE P a b INT i 01 01 IF v lt w THEN PROCEDURE P v w INT kkkkkkkkkkkkkkkkkkkkkkkkkkk ELSE kkk 10 11 kkk Hunk 2 kkkk Er 10 11 __ I IF a lt b THEN WHILE v lt w DO I a ie IFV lt wTHEN kkkkkkkkkkkkkkkkkkkkkkkkkkkk en ELSE aa kkkkkkkkkkkkkkkkkkkkkkkkkkk Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 69 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Erl uterungen zu diff und patch Q diff Werkzeug bestimmt Unterschiede zwischen Text Dateien Deltas ein Delta diff zwischen zwei Textdateien besteht aus einer Folge von Hunks die jeweils nderungen eines Zeilenbereiches beschreiben nderungen von Zeilen werden mit markiert Hinzuf gen von Zeilen werden mit markiert L schen von
119. er Software Bibliotheken Rahmenwerke Feinentwurf der Modulschnittstellen und Algorithmen vorgibt Ergebnisse Entwurfsdokument mit Software Bauplan gt detailierte re Testpl ne Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 35 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t Codieren und Modultest programming in the small Die eigentliche Implementierungs und Testphase in der einzelne Module in einer bestimmten Reihenfolge realisiert und validiert werden Aufgaben Programmieren im Kleinen Implementierung einzelner Module Einhaltung von Programmierrichtlinien Code Inspektionen kritischer Modulteile Walkthroughs gt Test der erstellten Module Ergebnisse gt Menge realisierter Module Implementierungsberichte Abweichungen vom Entwurf Zeitplan technische Dokumentation einzelner Module gt Testprotokolle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 36 SE II Software Entwicklung Wartung und Re Engineering Eentzeit gt t Integration und Systemtest Die einzelnen Module werden schrittweise zum Gesamtsystem zusammengebaut Diese Phase kann mit der vorigen Phase verschmolzen werden falls der Test isolierter Module nicht praktikabel ist Aufgaben Systemintegration Zusammenbau der Module Gesamtsystemtest in Entwicklungsorganisation durch K
120. er o wird also zu assembler verk rzt bezeichnet alle Objekte einer Regel rechts vom z B assembler o bezeichnet alle Objekte einer Regel rechts vom die neuer als das Ziel sind lt bezeichnet das erste Objekt rechts vom Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 127 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A Muster Suche und Substitutionen in make Oft ben tigt man auf der rechten Seite einer Regel oder in der Kommandozeile alle Dateinamen im aktuellen Verzeichnis die einem bestimmten Namensmuster entsprechen also etwa mit einem bestimmten Suffix enden wildcard Muster liefert bzw sucht alle Dateien im aktuellen Verzeichnis die dem angegebenen Muster entsprechen Das Muster kann beispielsweise folgende Form haben wildcard c liefert alle Dateien zur ck die das Suffix c besitzen der matcht alles Will man in einer Liste von Dateinamen durch Leerzeichen getrennte Strings einen Teilstring durch einen anderen Teilstring ersetzen substituieren verwendet man patsubst Suchmuster Ersatzstring Liste von W rtern Folgender Ausdruck ersetzt alle c Suffixe durch o Suffixe patsubst c o Liste von W rtern Das Zeichen bezeichnet den gleichbleibenden Teil bei der Ersetzung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechn
121. erreicht wurde interne Zust nde der Implementierung m ssen mit extern definierten Zust nden korrespondieren black box Sicht Aussenverhalten muss berpr ft werden im Beispiel der Ampel beobachtbares Verhalten der Ampel ggf Test ob bei weite ren Eingaben sich die Steuerung so verh lt wie sie sich im entsprechenden Zustand verhalten m sste Testbeendigung ggf wird Sequenz von Methodenaufrufen so vervollst ndigt dass am Ende der Ausf hrung Objekt sich in einem terminalen Zustand befindet Kombination von Testsequenzen um Aufwand f r Initialisierung zu reduzieren werden m glichst lange Testsequenzen generiert bzw kombiniert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 347 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Abschlie ende Checkliste f r Klassentest nach Bi00 jede Methode auch die geerbten wird mindestens einmal ausgef hrt alle Methodenparameter und alle nach aussen sichtbaren Attribute werden mit geeigneter quivalenzklassenbildung durchgetestet alle ausl sbaren ausgehenden Ausnahmen werden mindestens einmal ausgel st alle von gerufenen Methoden ausl sbaren eingehenden Ausnahmen werden mindestens einmal behandelt oder durchgereicht alle identifizierten Objektzust nde auch hier quivalenzklassenbildung werden beim Testen erreicht jede zustandsabh ngige Methode wird in jedem Zustand ausgef hrt a
122. erte f r Metrik werden aus Qualit tsanforderungen errechnet ein Wunschtraum Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 216 SE II Statische Programmanalyse amp Metriken Eentzeit gt Gleichzeitige Darstellung mehrere Messwerte mit Kiviatdiagramm Variablenspanne zyklomatische Zahl kritische Bereiche Messwerte f r ein Subsystem Modul Halstead N Lines of Code LOC y Live Variables Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 217 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Lines Of Code LOC Die Zeilenzahl des Quelltextes ist die naheliegendste Metrik f r ein Softwaresystem betrachtetes Programmteil Doch wie legt man die Lines Of Code LOC einen Programmteil fest M glichkeiten Anzahl aller Zeilen der Textdatei en des betrachteten Programmteils Anzahl Zeilen der Textdatei en ohne Kommentare und Leerzeilen Anzahl Trennzeichen zwischen Anweisungen also oder Anzahl Trennzeichen wie plus Schl sselw rter wie IF Anzahl Knoten im Kontrollflussgraphen siehe folgende Folien Programml nge nach Halstead siehe folgende Folien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 218 Fachgebiet 4 y SE II Statische Programmanalyse amp Metriken Echtzeit systeme Lines of Code LOC
123. erten Software kann erh ht werden durch gleichzeitige Berechnung eines ben tigten Ergebnisses durch mehrere Versionen einer Software gt Liefern verschiedene Versionen unterschiedliche Ergebnisse so wird Mehrheitsentscheidung verwendet geht ab 3 Versionen Probleme gt N Versionen enthalten mehr Fehler als eine Version falsche Versionen k nnen richtige berstimmen oder gemeinsame Ressourcen blockieren Fehler verschiedener Versionen sind nicht immer unabh ngig voneinander Fehler aus der Anforderungsdefinition oder typische Programmierspra chenfehler oder falsche Algorithmen k nnen alle Versionen enthalten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 256 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Wann erh hte Robustheit bei n Versionen Programmierung n Versionen enthalten in etwa n mal so viele Fehler wie eine Version aber falls Wahrscheinlichkeit A f r fehlerhafte Ausgabe oder Ausfall einer Version v unabh ngig vom Ausfall anderer Versionen ist dann gilt U richtiges Ergebnis wird berechnet solange h chstens n 1 2 Versionen fehlerhaft arbeiten n ist sinnvoller Weise ungerade Zahl U Wahrscheinlichkeit f r gleichzeitigen Ausfall von k unabh ngigen Versionen Mai 2 xax an L xA x Ay l i 1 U Wahrscheinlichkeit f r Ausfall des Gesamtsystems mit n Versionen 5 7 xA x 1 A k n 1 2 bein 3 Wahrscheinlichkeit
124. ertung der Ursache Wirkungs Graph und Anwendungsfall Testens Beide Methoden lassen sich sehr fr h im Software Lebenszyklus einsetzen und eignen sich insbesondere f r die Erstellung von Akzeptanztestf llen Q Die Ursache Wirkungsgraph Methode erlaubt die bei der quivalenzklassen Bildung fehlende Verkn pfung von Eingaben und Ausgaben Ursachen und Wirkungen Das Anwendungsfallbasierte Testen erlaubt hingegen nicht nur die Beschreibung einzelner Testvektoren Eingabewertkombinationen sondern auch die Spezifika tion ganzer Interaktionssequenzen zwischen Umgebung zu testendem System Insbesondere das Anwendunsgsfallbasierte Testen unterst tzt aber nicht die syste matische Identifikation fehlender Testf lle f r bestimmte Eingabetestvektoren Fazit Alle vorgestellten Black Box Testmethoden Funktionsorientierte Testverfahren besitzen ihre St rken und Schw chen und erg nzen einander Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 296 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit 4 4 Kontrollflussbasierte Testverfahren Ausgangspunkt ist der Kontrollflussgraph einer Komponente getestet werden sollen PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN count 0 i 0 WHILE sli DO IF s i b OR sli a
125. es ist schwer Systemarchitektur des ersten Prototypen so zu gestalten dass s e alle sp ter notwendigen Erweiterungen erlaubt Prozess der Prototyperstellung nicht festgelegt Spiralmodell von Berry B hm integriert Phasen des Wasserfallmodells evolution re Entwicklung der Anforderungsdefinition birgt Gefahr in sich dass bereits realisierte Funktionen hinf llig werden Endresultat sieht ggf wie Software nach 10 Jahren Wartung aus Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 365 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Rapid Prototyping Throw Away Prototyping Mit Generatoren ausf hrbaren Spezifikationssprachen Skriptsprachen etc wird Prototyp des Systems seiner Benutzeroberfl che realisiert dem Kunden demonstriert und anschlie end weggeschmissen Bewertung erlaubt schnelle Kl rung der Funktionalit t und Risikominimierung Vermeidung von Missverst ndnissen zwischen Entwickler und Auftraggeber fr her Test der Benutzerschnittstelle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 366 Fachgebiet 4 y SE II Management der Software Entwicklung Echtzeit y 5 2 Rational Unified Process f r UML Product Life Cycle Stand 1999 D Manager l Ba EN ie transition inception phase elaboration phase construction phase sicht P p p p phase Entwickler 5 iteration 1 iteration 2 iteration
126. est Minimaler Mehrfachbedingungstest ben tigt wie die bisherigen berdeckungskriterien eine linear mit der Anzahl der atomaren Teilbedingungen steigende Anzahl von Testf llen Es werden aber 1 a bessere Testf lle als bei der minimalen Mehrfachbedingungs berdeckung gew hlt Die Bedingungen sind U jeder atomaren Teilbedingung lassen sich zwei Testf lle zuordnen verschiedene Teilbedingungen d rfen aber die selben Testf lle nutzen U die Werte aller Teilbedingungen die wegen short circuit Evaluation des Compilers von Booleschen Ausdr cken nicht ausgewertet werden bleiben im Testfall undefiniert und k nnen deshalb beliebig gesetzt werden die beiden Testf lle zu einer atomaren Teilbedingung setzen diese einmal auf true und einmal auf false und unterscheiden sich nur in der gerade betrachteten atomaren Teilbedingung undefiniert kann mit true u false gleichgesetzt werden die beiden Testf lle zu einer atomaren Teilbedingung setzen die Gesamtbedingung einmal auf true und einmal auf false Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 304 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Beispiele f r short circuit Evaluierung von links nach rechts IF lt Ausdruck der true liefert gt OR b THEN die Belegung von b ist irrelevant f r das Testen und wird in vielen Programmiersprachen deshalb nicht ausgewertet IF lt Ausdruc
127. esting Object Oriented Systems Models Patterns Tools Addison Wesley 2000 1191 Seiten Umfassende Quelle zum angesprochenen Thema Gut geschrieben und umbedingt empfehlenswert falls man die Thematik Testen vertiefen will CFP06 B Collins Sussman B W Fitzpatrick C M Pilato Versionskontrolle mit Subversion O Reilly 2006 Subversion SVN ist der moderne Nachfolger von CVS FBOl K Fogel M Bar Open Source Projekte mit CVS mitp Verlag 2002 2 te berarbeitete Auflage 428 Seiten Dieses Buch liefert gut lesbar das notwendige Know how f r die Verwendung und Administration von CVS sowie eine Einf hrung in die Prinzipien des Managements von Open Source Projekten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 13 Fachgebiet Echtzeit Fi systeme He03 H Herold make das Profitool zur automatischen Generierung von Programmen Addison Wesley 2003 230 Seiten Akzeptable Einf hrung in make das Open Source Werkzeug zur Automatisierung von bersetzungs und Programmgenerierungsprozessen Li02 P Liggesmeyer Software Qualit t Testen Analysieren und Verifizieren von Software Spektrum Akademischer Verlag 2002 523 Seiten Ein Standardwerk zum Thema Software Qualit tssicherung Kapitel 3 und 4 der Vorlesung st tzen sich vor allem darauf ab PBLOS5 K Pohl G B ckle F van der Linden Software Product Line Engineering Foundations Principles
128. ethods NORM die Anzahl der in einer Klasse gerufenen Methoden fremder Klassen also nicht die Klasse selbst oder eine ihrer Oberklassen Attribute Complexity AC die gewichtete Summe der Attribute einer Klasse wird gebildet Gewichte werden gem Typen Klassen der Attribute vergeben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 235 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Beispiele f r Mess Werkzeuge U JHawk http www virtualmachinery com jhawkprod htm f r Java unterst tzt viele Z hl Metriken Anzahl von Parametern unterst tzt die klassischen zweifelhaften Metriken Halstead kommerzielles Produkt U metrics http metrics sourceforge net f r Java Open Source Software gt unterst tzt deutlich weniger Metriken als JHawk aber ebenfalls Ca Ce Tiefe von Vererbungshierarchien U Together scheint von Borland nicht mehr unterst tzt zu werden gt UML Werkzeug mit enger Modell Code Integration unterst tzt e viele Metriken f r C und Java fast alle hier vorgestellten komplexeren OO Metriken stammen aus der Together Dokumentation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 236 Fachgebiet Echtzeit systeme SE II Statische Programmanalyse amp Metriken Screendumps von JHawk und metrics File Edit Navigate Search Project R
129. eugte abgeleitete Objekte werden also immer privat gehalten makefiles selbst m ssen manuell aktuell gehalten werden programmiersprachenspezifisches makedepend erzeugt makefiles Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 134 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Erzeugung von Makefiles l in jedem Quelltextverzeichnis gibt es ein normales Makefile das den bersetzungsprozess mit make in diesem Verzeichnis steuert normale Makefiles werden von makedepend durch Analyse von Quelltextdateien erzeugt in C werden includes von h Dateien gesucht ein Super Makefile sorgt daf r dass makedepend nach relevanten Quelltext nderungen in den entsprechenden Verzeichnissen aufgerufen wird in allen normalen Makefiles dieselben Makrodefinitionen verwendet werden soweit gew nscht gt ge nderte Makefiles oder Makrodefinitionen dazu f hren dass in den betroffenen Verzeichnissen alle abgeleiteten Objekte neu erzeugt werden Achtung Makefile Erzeugung ist eine Wissenschaft f r sich wenn viele verschiedenen bersetzer und Generatoren in einem Projekt verwendet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 135 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Generierung von Makefiles mit GNU Autotools Ca10 Die GNU Autotools sind mehrere Wer
130. f r Datentechnik Seite 27 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit 2 Interne Sicht auf den Vorfall Q Intensit t des Elektronenstrahls und Position des Flatteners werden allein durch Software kontrolliert zu schnelle Eingabe der Daten f hrte dazu dass Flattener zwar aus Strahl entfernt wurde Intensit t des Elektronenstrahls aber nicht korrigiert wurde erkannter Fehlerzustand f hrte zu kryptischer Fehlermeldung aber nicht zur Blockade Abbruch der Behandlung allein fehlerhaft implementierte Software Locks sollen verhindern dass Elektronenstrahl mit 25 MeV ohne Flattener den Patienten trifft Sperre wird durch Inkrementieren eines Bytes um 1 gesetzt Sperre wird durch Dekrementieren des Bytes um 1 r ckgesetzt Sperren berpr fung erfolgt durch Test auf Wert ungleich 0 ein rekursiver Warteprozess f hrt zun chst beliebig viele Sperr anforderungen aus bevor er schlie lich alle Sperren wieder freigibt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 28 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit S Fehleranalyse und ursachen aus Managementsicht bliche Sicherheitsanalyse f r Therac 25 ging davon aus dass die verwendete Software immer fehlerfrei funktionieren w rde weil Zitate aus Bericht x Programming errors have been reduced by extensive testing
131. f Compiler einer Programmiersprache U make werden durch ein sogenanntes makefile Erzeugungsabh ngigkeiten zwischen Dateien mitgeteilt Q make benutzt Zeitmarken um festzustellen ob eine Datei noch aktuell ist Zeitmarke j nger als die Zeitmarken der Dateien von denen sie abh ngt Aufbau einer Abh ngigkeitsbeschreibung ziel objekt1 objekt 2 objekt3 Kommando zur Erzeugung von ziel aus objekt1 Achtung Kommandozeile muss mit lt tab gt Tabulator beginnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 122 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Abh ngigkeitsbeschreibungen f r unser Beispiel assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files o cc o assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files o assembler o assembler c global h passO h pass1 h pass2 h pass3 h cc c assembler c pass0 o passO h pass0 c global h messages h CC c pass0 c Achtung Das Zeichen muss immer letztes Zeichen einer fortgesetzten Zeile sein Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 123 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Aufruf von make ohne Parameter nach nderung von messages c 1 der Aufruf sucht eine Datei namens makefile und soll eine aktuelle Version des Ziels der ersten Abh ngigke
132. f Entwickler des Codes kann noch zugegriffen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 46 SE II Software Entwicklung Wartung und Re Engineering Echizeit gt 2 Wunsch und Wirklichkeit der Software Evolution Software Systeme zu erstellen die nicht ge ndert werden m ssen ist unm glich Wurde Software erst einmal in Betrieb genommen ent stehen neue Anforderungen und vorhandene Anforderungen ndern sich S001 Software Evolution W nsche Wartung ndert Software kontrolliert ohne Design zu zerst ren Konsistenz aller Dokumente bleibt erhalten Software Evolution Wirklichkeit urspr ngliche Systemstruktur wird ignoriert Dokumentation wird unvollst ndig oder unbrauchbar Mitarbeiter verlassen Projekt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 47 SE II Software Entwicklung Wartung und Re Engineering Eentzet gt t Ergebnis unkontrollierter Software Evolution Anforderungen Design Legacy Software Legacy wertvolles Erbe amp der Code ndert sich mit Sicherheit seine Struktur bleibt meist erhalten auch wenn sie neuen Anforderungen eigentlich nicht gewachsen ist das Design wird nach einer gewissen Zeit nicht mehr aktualisiert die Anforderungsdokumente werden erst recht nicht mehr gepflegt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f
133. fung auf e THEN count count 2 Berechnungsfehler count wird um 2 erh ht END count i 1 Datenflussfehler Zuweisung nicht an i END WHILE END countVowels countVowels to be or not to be count Schnittstellenfehler dot im Satz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 251 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Was wird also getestet Testverfahren f r Softwarekomponenten Operation Klasse Modul Paket System k nnen danach klassifiziert werden was getestet wird Q Funktionalit tstest das Ein Ausgabeverhalten der Software das steht beim Testen zun chst stark im Vordergrund und wird in Abschnitt 4 3 bis Abschnitt 4 5 behandelt Benutzbarkeitstest es geht um die gute Gestaltung der Benutzeroberfl che schwieriges Thema das hier nicht weiter vertieft wird Performanztest Laufzeitverhalten und Speicherplatzverbrauch einer Kompo nente werden gemessen und dabei oft durchlaufene ineffiziente Programmteile oder Speicherlecks identifiziert siehe Abschnitt 4 2 Stresstest die Komponente wird mit sehr gro en Datenmengen oder sehr gro er Anzahl gleichzeitiger Anfragen oder getestet siehe Auswahl von Testdaten in Abschnitt 4 3 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 252 Fachgebiet SE II Dynamische Programmanalysen und Te
134. g von Fehlern schwierig Arbeitsteilung kaum m glich Testen beginnt zu sp t Top down Testverfahren zuerst A mit Dummies f r B C und D dann B mit Dummies f r E und F zu testendes System Erstellung vern nftiger Dummies schwierig gt Test der Basisschicht sehr sp t Bottom Up Testverfahren zuerst E F G und H mit Testtreibern die Einbin dung in B C und D simulieren dann B C und D mit Testtreiber Test des Gesamtverhaltens des Systems gegen Lastenheft erst am Ende Designfehler und Effizienzprobleme werden oft erst sp t entdeckt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 262 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit G ngige Integrationsteststrategien Fortsetzung Inkrementelles Testen Grundger st vorhanden weitere Komponenten werden st ckweise hinzugef gt gt wie erstellt und testet man Grundger st z B Top Down Testen mit Depth First Strategie Hinzuf gen von Komponenten kann bisherige Testergebnisse entwerten Regressionstest System nderungen bei Wartung oder inkrementellem Testen k nnen Fehler in bereits getesteten Funktionen verursachen gt m glichst viele Tests werden automatisiert gt bei jeder nderung werden alle vorhandenen Tests durchgef hrt gt neue Testergebnisse werden mit alten Testergebnissen verglichen Achtung Nur inkrementelles Testen kombiniert mit
135. gebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Dreiwegeverschmelzen von Text Dateien Basisversion B A Nachfolgeversion NV1 Nachfolgeversion NV2 a Ergebnisversion E Verschmelzungsregeln f r Revisionen Varianten Textzeile in B NV1 und NV2 gleich gt Textzeile in E Textzeile in B aber nicht in NV x oder und NV y gt Textzeile nicht in E Textzeile in NV x oder und NV y aber nicht in B gt Textzeile in E Textzeile aus B in NV1 und NV2 ge ndert gt manuelle Konfliktbehebung gilt auch f r neue Textzeilen in NV1 und NV2 an gleicher Stelle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 85 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Beispiel f r das automatische Verschmelzen PROCEDURE P a b INT BEGIN IF a lt b THEN IN PROCEDURE P v w INT PROCEDURE P v w INT BEGIN VAR a INTEGER i BEGIN WHILE a lt b DO ER IFv lt aTHEN END PROCEDURE P v w INT u END P VAR a INTEGER ELSIF v w THEN BEGIN u u END WHILE a lt b DO END P IF v lt a THEN ELSIF v w THEN END END P Gemeldeter Konflikt zwischen nderungen an derselben Zeile muss vom Benutzer aufgel st werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 86 Fachgebiet 5 SE II Konfigurationsmanagement Echtzeit systeme Beispi
136. gemeldeten Fehler lassen sich wie folgt den Phasen des Entwicklungs prozesses zuordnen und der Aufwand f r ihre Behebung ist wie folgt 5 Fehler aus der Anforderungsdefinitionsphase mit 27 PT durchschnittli chem Korrekturaufwand PT Personentage 3 Fehler aus der Entwurfsphase mit 5 7 PT Korrekturaufwand gt 10 Fehler aus der Implementierungsphase mit 0 6 PT Korrekturaufwand Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 241 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Abstraktes Fallbeispiel Fortsetzung 4 Ziele zur Verbesserung des Entwicklungsprozesses und Softwareprodukts gt Reduktion der Fehleranzahl in der Definitionsphase zur deutlichen Auf wandsreduktion Reduktion der Fehleranzahl in der Implementierungsphase zur deutlichen Verbesserung der Qualit t der ausgelieferten Software 5 Auswahl von Verbesserungsma nahmen in der Anforderungsdefinitionsphase falls ungenaue Spezifikation der Anforderungen des Kunden dann Einsatz von semi formalen Spezifikationstechniken gt falls genaue Spezifikation falscher Anforderungen des Kunden dann Einsatz von Rapid Prototyping Vorgehensweise 6 Auswahl von Verbesserungsma nahmen in der Implementierungsphase h tte Datenflussanalyse die Fehler gefunden h tte Metrix X fehlerhaften Code als qualitativ zweifelhaft erkannt h tten systematischere Testverfahren die Fehler aufgedeckt
137. geplanten Vorgehensmodellen Werkzeugen quantifizierbaren Zielen Bislang in Software Engineering Einf hrung kennengelernt Entwicklung von Software aber nicht Pflege und Einsatz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 17 SE II Software Entwicklung Wartung und Re Engineering Echtzeit t systeme 40 Jahre nach Beginn der Software Krise Standish Group http www standishgroup com ver ffentlich in regelm igen Abst nden den sogenannten Chaos Report U 25 aller betrachteten IT Projekte sind gescheitert U 50 aller betrachteten IT Projekte sind dabei zu scheitern U 25 aller betrachteten IT Projekte sind erfolgreich wurden im geplanten Finanz und Zeitrahmen beendet Hauptgr nde f r Scheitern von Projekten Nach wie vor unklare Anforderungen und Abh ngigkeiten sowie Probleme beim nderungsmanagement Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 18 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t 1 2 Software Qualit t Ziel der Software Technik ist die effiziente Entwicklung messbar qualitativ hochwertiger Software die gt gew nschte Funktionalit t anbietet benutzerfreundliche Oberfl che besitzt korrekt bzw zuverl ssig arbeitet effizient konomisch mit Hardwareressourcen umgeht wartbar und leicht nderbar ist FURPS Modell von HP zur
138. geschnittenes moderneres Build Tool siehe http jakarta apache org ant index html Noch moderner sind Maven und Jenkins f r Continuous Integration also die automatisierte permanente Erzeugung von Software Releases Nicht generierte Anteile von Konfigurationsdateien m ssen selbst unbedingt der Versionsverwaltung unterworfen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 137 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s 2 6 nderungsmanagement Ein festgelegter nderungsmanagementprozess sorgt daf r dass W nsche f r Anderungen an einem Softwaresystem protokolliert priorisiert und kosteneffektiv realisiert werden nderungsmanagement frei nach S001 Ausf llen eines nderungsantragsformulars Analyse des nderungsantrags if nderung notwendig und noch nicht beantragt then Bewertung wie nderung zu implementieren ist Einsch tzung der nderungskosten Einreichen der nderung bei Kommission if nderung akzeptiert then Durchf hren der nderung f r Release else nderungsantrag ablehnen else nderungsantrag ablehnen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 138 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a nderungsmanagement frei nach Wh00 1 ein nderungswunsch feature request oder eine Fehlermeldung bug report wird
139. gif markus jpg Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 132 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Besseres makefile f r beliebige Dateien jpg files patsubst gif jpg wildcard gif default images zip images zip jpg files zip u jpg gif convert Variante f r inkrementelle Aktualisierung von images zip Will man nur die ver nderten jpg Dateien neu in das Archiv aufnehmen dann ist eine Regel wie folgt zu ndern images zip jpg files zip u Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 133 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Bewertung des Buildmanagements mit make nur ein Bruchteil der Funktionen von make wurde vorgestellt urspr ngliches make f hrt Erzeugungsprozesse sequentiell aus GNU make kann Arbeit auf mehrere Rechner verteilen und parallel durchf hrbare Erzeugunsgsschritte gleichzeitig starten Steuerung durch Zeitmarken ist sehr grob gt zu h ufiges neu generieren irrelevante nderungen wie ndern von Kommentaren f r bersetzung werden nicht erkannt gt zu seltenes neu generieren nderung von bersetzerversionen U bersetzungsoptionen etc werden nicht erkannt kaum Verzahnung mit Versionsverwaltung gt make wird in aller Regel auf eigenem Repository durchgef hrt gt erz
140. handlung error gt menschliche Handlung des Entwicklers die zu einem Fehlerzustand in der Software f hrt gt menschliche Handlung des Anwenders die ein unerw nschtes Ergebnis zur Folge hat Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 246 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Ursachenkette f r Fehler in Anlehnung an DIN 66271 U jeder Fehler fault oder Mangel ist seit dem Zeitpunkt der Entwicklung in der Software vorhanden Software n tzt sich nicht ab er ist aufgrund des fehlerhaften Verhaltens error eines Entwicklers entstanden und wegen mangelhafter Qualit tssicherungsma nahmen nicht entdeckt worden ein Softwarefehler kommt nur bei der Ausf hrung der Software als Fehlerwirkung failure zum Tragen und f hrt dann zu einer ggf sichtbaren Abweichung des tat s chlichen Programmverhaltens vom gew nschten Programmverhalten Fehler in einem Programm k nnen durch andere Fehler maskiert werden und kommen somit ggf nie zum Tragen bis diese anderen Fehler behoben sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 247 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Validation und Verifikation durch dynamische Tests Validation von Software Pr fung ob die Software das vom Anwender wirklich gew nschte Verhalten zeigt in einem bestimmten Anwend
141. he Modelle Dokumente des Produkts zu erzeugen sind Q prozessorientiert die Arbeit ist in eine genau definierte Abfolge von Aktivit ten unterteilt die von anderen Teams in anderen Projekten wiederholt werden k nnen iterativ und inkrementell die Arbeit ist in eine Vielzahl von Iterationen unter teilt das Produkt wird inkrementell entwickelt risikobewusst Aktivit ten mit hohem Risiko werden identifiziert und in fr hen Iterationen in Angriff genommen zyklisch die Produktentwicklung erfolgt in Zyklen Generationen Jeder Zyklus liefert eine neue als kommerzielles Produkt ausgelieferte Systemgeneration ergebnisorientiert jede Phase Iteration ist mit der Ablieferung eines definierten Ergebnisses meist zu einem konkreten Zeitpunkt Meilenstein verbunden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 369 SE II Management der Software Entwicklung a systeme Faustregeln f r die Ausgestaltung eines Entwicklungsprozesses U die Entwicklung einer Produktgeneration dauert h chstens 18 Monate eine Vorbereitungsphase dauert 3 6 Wochen und besteht aus einer Iteration eine Entwurfsphase dauert 1 3 Monate und besteht aus bis zu 2 Iterationen eine Konstruktionsphase dauert 1 9 Monate und besteht aus bis zu 7 Iterationen eine Einf hrungsphase dauert 4 8 Wochen und besteht aus einer Iteration jede Iteration dauert 4 8 Wochen ggf exklusive Vorbereitungs und Nachberei tungszeiten die mi
142. helfen fr hzeitig bei der Identifikation kritischer Programmstellen Es sollten folgende Analyseverfahren immer eingesetzt werden gt Stilanalyse berpr fung vereinbarter Programmierkonventionen dead code Analyse oft in Compiler eingebaut nie verwendete Methoden Variablen Parameter wurde bisher nicht angesprochen Datenflussanalyse wenn Werkzeug verf gbar Weitere Analyseverfahren und vor allem Metriken sollten in gro en Projekten zumindest versuchsweise eingesetzt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 238 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Vorgehensweise beim Einsatz von Ma en aus Li02 1 Fragen zur Ausgangssituation In welcher Phase Aktivit tsbereich des Softwareentwicklungsprozesses soll eine Verbesserung eingef hrt werden z B Design Codierung Was soll damit erreicht werden bzw welche Art von Fehler soll reduziert werden z B Reduktion C Codierungsfehler Welche Methode soll eingesetzt werden z B OO Metriken Welche Technik Werkzeug soll eingesetzt werden 2 Bewertung des aktuellen Standes des Entwicklungsprozesses gt Welche Kosten u welcher Aufwand entstehen in welcher Phase gt Wie ist die Qualit t der Ergebnisse jeder Phase In welcher Phase entsteht welcher Anteil an Fehlern und welcher Teil der Fehlerbeseitigungskosten Prof Dr Andy Sch rr T
143. hen Programmanalyse kennenlernen einige Werkzeuge zur statischen Programmanalyse einsetzen k nnen Zusammenh nge zwischen Softwarequalit t und Analyseverfahren verstehen strukturorientierte Analyse und Messverfahren lernen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 153 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit systeme 3 1 Einleitung U Oft fast immer finden sich 80 aller Probleme mit einem Softwaresystem in 20 des entwickelten Codes U Die statische Programmanalyse versucht meist werkzeuggest tzt fr hzeitig die problematischen 20 eines Softwaresystems zu finden Statische Analyseverfahren identifizieren Programmteile von fragw rdiger Qualit t und liefern damit Hinweise auf potentielle Fehlerstellen Statische Analyseverfahren versuchen die Qualit t von Software zu messen k nnen deshalb zur Festlegung von Qualit tsma st ben eingesetzt werden Die statische Programmanalyse setzt keine vollst ndig ausf hrbaren Programme voraus Die statische Programmanalyse kann also fr hzeitig bei der Neuentwicklung und kontinuierlich bei der Wartung eines Softwaresystems eingesetzt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 154 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Arten von Analyseverfahren zur Erinnerung analysierende Verfahren statische Programmanaly
144. hgeklopfter Automat mit einfacheren Transitionsbedingungen ka ie von den Zust nden Red Yellow Green Flashing lightOn green k amp amp yellow k Flashin ghtOnfg 8 amp amp y nk amp amp redOk greenOn lt lt delete gt gt lightOff 4 In dem flachen Automaten Statechart gibt es zus tzlich zu den eingezeichneten Transitionen von jedem der Zust nde Red Yellow Green Flashing jeweils drei Transitionen zu dem Zustand Off mit den Aufschriften gt offOnFault greenOk gt offOnrFault yellowOk gt offOnFault redOk Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 342 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Ein m glicher Transitionsbaum f r Ampelsteuerung xxx jeweils eine eigene Transition f lN a lightOff 1 Blatt offOnFault greenOk offOnFault yellowOk offOnFault redOk flashingOn lightOn yellowOn 4 Bl tter redOn flashingOn greenOn 1 Blatt 4 Bl tter 1 Blatt 4 Bl tter flashingOn redOn Flashing 21 Bl tter 21 Testsequenzen Ba 1 Blatt 4 Bl tter Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 343 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit a Die normalen Testsequenzen new Konstruktoraufruf delete Destruktoraufruf new lightOn greenOk amp yellowOk amp redOk
145. hleifen ber Intervallen gebildet die genau f r die Grenzf lle falsch programmiert sind Beispiel f r die Grenzwertanalyse zul ssiger Eingabebereich besteht aus reellen Zahlen Float mit zwei zu betrachtenden Nachkommastellen zwischen 1 und 1 Fehlerklassen in Rot vor Grenzwertanalyse l 1 0 F 1 0 1 0 1 0 o gt nach Grenzwertanalyse I 1 01 1 01 1 0 1 0 1 0 1 0 1 01 1 01 o Beispiele f r gew hlte Werte 2 1 01 1 0 0 1 0 1 01 2 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 280 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Auswahl von Testeingaben f r countVowels mit Zeichenketten PROCEDURE countVowels s Sentence VAR count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot Klasse 1 s endet nicht mit einem Punkt oh je das geht schief Q Klasse 2 s endet mit einem Punkt und enth lt keine Vokale S besteht nur aus einem Punkt S besteht aus einem Konsonanten gefolgt von einem Punkt gt S enth lt sonstige Sonderzeichen wie etwa 8 amp Klasse 3 s endet mit einem Punkt und enth lt einen Vokal 3a S enth lt ein a e i O u gt 3b s enth lt ein A E I O U oh je dieser Fall wurde auch vergessen Klasse 4 s enth lt mehrere Vokale 4a mehrere gleiche Vokale 4b mehrere verschiedene Vokale
146. hte oder neu eingef gte Zeilen Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die nderungsmarkierung Hunks sind durch mindestens eine unver nderte Zeile getrennt Beispiel neue Version Zeilennummern nicht Bestandteil der Zeile Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die nderungsmarkierung Aufeinander folgende Hunks sind durch jeweils mindestens eine unver nderte Zeile getrennt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 73 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Falsches Diff Ergebnis 5 ge nderte Zeilen wk 01 06 Hunk 1 Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile und enth lt sonst nur ge nderte gel schte oder neu eingef gte Zeilen Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die nderungsmarkierung Hunks sind durch mindestens eine unver nderte Zeile getrennt 01 06 Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die n
147. i der Arbeit mit Workspaces Q Personen holen sich Versionen neuer Dokumente die von anderen Personen erstellt wurden checkout in ihren privaten Arbeitsbereich U Personen passen ihre Privatversionen ggf von Zeit zu Zeit an neue Versionen im ffentlichen Repository an update Sie f gen hoffentlich nur konsistente Dokumente als neue Versionen in das allgemeine Repository ein checkin commit Ab und an werden neue Dokumente dem Repository hinzugef gt add Jede Person kann f r sich entscheiden ob sie mit neuen oder lteren Versionen im Repository arbeiten will Probleme Wie wird Konsistenz von Gruppen abh ngiger Dokumente sichergestellt Q Was passiert bei gleichzeitigen nderungsw nschen f r ein Dokument U Wie verwaltet man alle Versionen eines Dokuments effizient Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 64 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Weitere Begriffe des Konfigurationsmanagements Q Dokument Gegenstand der der Konfigurationsverwaltung unterworfen wird eine einzelne Datei oder ein ganzer Dateibaum oder Versions Objekt Zustand einer Dokument zu einem bestimmten Zeitpunkt in einer bestimmten Auspr gung Varianten parallel zueinander gleichzeitig existierende Auspr gungen eines Dokuments die unterschiedliche Anforderungen erf llen Revisionen zeitlich aufeinander folgende Zust nde e
148. ianten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 381 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Von ISO 9000 3 vorgeschriebene T tigkeiten Q Konfigurationsmanagement f r Identifikation und R ckverfolgung von nderungen Verwaltung parallel existierender Varianten U Dokumentmanagement f r geordnete Ablage und Verwaltung aller bei der Softwareentwicklung erzeugten Dokumente Qualit tsaufzeichungen Fehleranzahl oder Metriken f r Verbesserungen am Produkt und Prozess Festlegung von Regeln Praktiken und bereinkommen f r ein Qualit ts sicherungssystem Schulung aller Mitarbeiter sowie Verfahren zur Ermittlung des Schulungsbedarfes Zertifizierung Die Einhaltung der Richtlinien der Norm wird von unabh ngigen Zertifizierungs stellen im j hrlichen Rhythmus berpr ft Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 382 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Bewertung von ISO 9000 lenkt die Aufmerksamkeit des Managements auf Qualit tssicherung ist ein gutes Marketing Instrument reduziert das Produkthaftungsrisiko Nachvollziehbarkeit von Entscheidungen Nachvollziehbarkeit und Dokumentation von Prozessen reicht aus keine Aussage ber Qualit t von Prozessen und Produkten f r kleine Firmen nicht bezahlbarer b rokratischer Aufwand Qualifikation der Zertifizieru
149. icklung Wartung und Re Engineering Echizeit gt 2 Probleme mit dem Wasserfallmodell zu Projektbeginn sind nur ungenaue Kosten und Ressourcensch tzungen m glich ein Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen das erste sehr sp t entsteht Risikomaximierung es gibt F lle in denen zu Projektbeginn kein vollst ndiges Pflichtenheft erstellt werden kann weil Anforderungen nicht klar Anforderungen werden fr h eingefroren notwendiger Wandel aufgrund organisa torischer politischer technischer nderungen nicht eingeplant strikte Phaseneinteilung ist unrealistisch R ckgriffe sind notwendig Wartung mit ca 60 des Gesamtaufwandes ist eine Phase Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 40 SE II Software Entwicklung Wartung und Re Engineering Andere Darstellung der Aufwandsverteilung Verstehen Qualit ts sicherung Analyse Entwickeln Entwurf Implementierung ndern Fachgebiet Echtzeit systeme nach Nosek und Palvia 1990 wenn man Verstehen bestehenden Codes ganz dem Bereich Software Wartung zuschl gt kommt man sogar auf 80 Wartungsaufwand Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 41 SE II Software Entwicklung Wartung und Re Engineering Echizeit gt 2 Typische Probleme in der Wartungsphase U Einsatz wenig erfahrenen Personals nicht Entwi
150. ik Seite 128 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Einsatz von Muster Suche und Substitution h files wildcard h alle h Dateien im aktuellen Verzeichnis werden der Var h files zugewiesen o files patsubst c o wildcard c alle c Dateien im aktuellen Verzeichnis werden gefunden und mit ausgetauschtem Suffix c wird gegen o getauscht o files zugewiesen assembler o files LD DEBUG LDFLAGS assembler o c h files CC IDEBUG CFLAGS c Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 129 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Muster Regeln in make Manchmal will man Regeln schreiben die alle Dateien mit einem bestimmten Pr fix oder Suffix aus einer anderen Datei mit unterschiedlichem Pr fix oder Suffix aber ansonsten gleichem Namen errechnen So wird z B jede c Datei in eine o Datei anson sten gleichen Namens bersetzt Die Muster Regel ist f r die Definition solcher Abh ngigkeiten geeignet prefix1 suffix1 prefix1 suffix2 Kommando Beispiel f r Muster Regel bersetzung von c Dateien in o Dateien geht wie folgt 0 c h files CC DEBUG CFLAGS lt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 130 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Ein letztes
151. im Vordergrund der Bauplan Architektur Software Construction gem Bauplan wird das Software System realisiert Software Testing Fehler werden systematisch gesucht und eliminiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 3 Fachgebiet Echtzeit systeme Software Maintenance die Pflege und Weiterentwicklung der Software nach Auslieferung Software Configuration Management die Verwaltung von Software Versionen und Konfigurationen Software Engineering Management Projekt Management von Personen Organisationen Zeitpl nen Software Engineering Process Definition und Verbesserung von Software Entwicklungsprozessen Software Engineering Tools and Methods Werkzeuge und Methoden f r die Software Entwicklung Software Quality Messen und Verbessern der Software Qualit t Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 4 Fachgebiet Echtzeit systeme Aufteilung auf Lehrveranstaltungen Software Engineering Einf hrung Software Requirements Software Design Software Construction Software Engineering Tools and Methods Software Engineering Wartung und Qualit tssicherung Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods gt gt N gt gt gt gt Software
152. in Programmverifikation und symbolische Ausf hrung Beweis der Korrektheit eines Programms mit Logikkalk l oder anderen mathematischen Mitteln siehe etwa Vorlesungen zu Verifikationstechnologien Eveking Mantel Stilanalysen Programmierkonventionen f r Programmiersprachen Java Programmierkonventionen im Software Praktikum und Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 156 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiele stilistischer Regeln f r C 1 6 vermeide komplexe Zuweisungen anstelle von i j 20 h j 20 j j j 1 i h Ili i h nicht zu viele Laufvariablen in Schleifen for i 0 j 0 k 10 1 1 i lt cent it jt k 1 2 do something besser I 1 for i 0 j 0 k 10 i lt cnt i j k do something 2 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 157 Fachgebi a SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiele stilistischer Regeln f r C 2 6 kein teilweises berladen von Methoden aus Oberklasse class Animal public void oper int i void oper bool b class Elephant Animal public void oper char c fehlende Methode void oper int i void oper bool b L sung Methode oper int i in Unterklasse Elephant mit auff hren dan
153. ind 4 12 4 verschiedene Testl ufe m glich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 284 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Heuristiken f r die Reduktion m glicher Eingabewertekombinationen Q aus jeder quivalenzklasse wird mindestens einmal ein Wert ausgew hlt es gibt also jeweils mindestens einen Testfall in dem ein Eingabewert der Aquivalenz klasse verwendet wird bei Grenzwertanalyse werden drei Werte ausgew hlt bei abh ngigen Eingabeparametern m ssen Testf lle f r alle Kombinationen ihrer jeweiligen normalen quivalenzklassen aufgestellt werden Parameter sind abh ngig wenn sie gemeinsam das Verhalten des Programms steuern und deshalb nicht unabh ngig voneinander betrachtet werden k nnen der ausgew hlte Wert einer Fehler quivalenzklasse wird in genau einem Testfall verwendet Fehler quivalenzklassen sind solche quivalenzklassen die unzul s sige Eingabewerte zusammenfassen der ausgew hlte Wert einer Stresstestklasse wird ebenfalls genau einmal in einem Testfall verwendet Stresstestklassen sind solche quivalenzklassen die beson ders gro e lange zul ssige g ltige Eingabewerte zusammenfassen hat man mehrere Eingabeparameter wird h chstens einer mit einem Wert aus einer Fehler oder Stresstestklasse belegt verhindert Verdeckung von Fehlern Prof Dr Andy Sch rr TU Darmstadt F
154. ind das Aufdecken von Berechnungsfehlern Kontrollflussfehlern getestet wird in jedem Fall die Komponente f r sich mit gt Teststummel Platzhalter Dummies Stubs f r ben tigte Dienste anderer Komponenten gt Testtreibern Driver f r den automatisierten Test der Schnittstelle f r Eingabe von Parametern Ausgabe von Parametern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 260 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit A Integrationstest das gesamte Software System oder ein abgeschlossenes Teilsystem wird getestet Schwerpunkt liegt dabei auf Test des Zusammenspiels der Einzelkomponenten Q normalerweise wird vorausgesetzt dass Einzelkomponenten vorab bereits getestet wurden auch hier m ssen wieder Testtreiber geschrieben werden die interaktive Benutzer schnittstellen ersetzen und Tests automatisieren auf Teststummel kann meist verzichtet werden da alle ben tigten Teilsysteme zusammen getestet werden Testziel ist vor allem das Aufdecken von Schnittstellenfehlern und insbesondere Fehler beim Austausch von Daten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 261 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme G ngige Integrationsteststrategien Q Big Bang Strategie alle Teile sofort integrieren und nur als Gesamtheit testen Lokalisierun
155. ine im PC Pool bei Bedarf Betreuer Johannes B rdek Johannes Buerdek es tu darmstadt de Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 10 Fachgebiet Echtzeit systeme bungs Beispiel ImageJ Screendump EG BES ax Counters Actions File Edit Image Process UEITZ Plugins Window Help File Edit Font na OOA measure str A Analyze Particles Summarize Distribution Label Clear Results Set Measurements mn Counter Window Histogram of ogo 300x240 pixels 8 bit 70K Polygon selections 36800 198 772 4 299 e e e e e e le le ie Set Scale Rest na iv Show Numbers Histogram C Show All Save Markers logo_gross jpg Load Markers 300x184 pixels ROB 144K Export Image C esae Plot Profile Surface Plot Gels Tools 0 Count 36800 Mean 198 772 StdOev 68 598 Min 4 Max 255 Mode 255 17688 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 11 Fachgebiet A Echtzeit 1 systeme Zertifizierung zum Software Tester bernommen von Dr Falk Fraikin U ASOF Arbeitskreis Software Qualit t Franken bietet in Zusammenarbeit mit dem iSQI international Software Quality Institute standardisierte Ausbildung Foundation Advanced Diploma Level zum Certified Tester an mit Unterst tzung durch Gesellschaft f r Informatik in Deutschland waren 2003 f
156. iner unver nderten Kontextzeile Hunks sind durch mindestens eine unver nderte Zeile getrennt Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die nderungsmarkierung Beispiel neue Version Zeilennummern nicht Bestandteil der Zeile Die Anzahl der Zeilen aller Hunks eines Deltas wird m glichst klein gehalten Jeder Hunk beginnt mit genau einer unver nderten Kontextzeile Anstelle von L schen und Neuerzeugen einer Zeile i verwendet man immer die nderungsmarkierung Aufeinander folgende Hunks sind durch jeweils mindestens eine unver nderte Zeile getrennt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 76 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Darstellung von Deltas im neueren Unified Diff Format Index MyFile MyFile revision 1 MyFile revision 2 1 1 1 1 PROCEDURE P a b INT PROCEDURE P v w INT 10 2 10 4 IF a lt b THEN IF v lt w THEN XXX Es handelt sich nur um eine etwas andere Art der Darstellung von Unterschieden zwischen verschiedenen Dateien Dateirevisionen Anderungen werden als L schung gefolgt von Einf gung dargestellt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 77 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Create und Apply Patch in Eclipse Die Create Patch
157. ines Dokuments Konfiguration komplexes Versionsobjekt eine bestimmte Auspr gung eines Programmsystems oft hierarchisch strukturierte Menge von Dokumenten Baseline eine Konfiguration die zu einem Meilenstein Ende einer Entwick lungsphase geh rt und evaluiert getestet wird Release eine stabile Baseline die ausgeliefert wird intern an Entwickler oder extern an bestimmte Kunden oder Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 65 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Abstraktes Beispiel Anwendungslogik v1 v2 v1 v2 Datenhaltung Benutzeroberfl che Dokument Datei deutsch Variante v1 v2 v1 v2 v1 V2 Revision Anwendungslogik A Datenhaltung D und Benutzeroberfl che B sind drei Pakete Dokumente aus denen das Gesamtprodukt besteht jedes Paket existiert in zwei Varianten die jeweils in beliebig vielen zeitlich auf einander folgenden Revisionen vorliegen k nnen es gibt also f r das Gesamtprodukt acht m gliche Konfigurationen falls es f r jede Variante genau eine Revision gibt sonst entsprechend mehr Beispielkonfiguration A profi v1 D DB v2 B englisch v2 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 66 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A 2 2 Versionsmanagement Versionsmanagement befasst sich i
158. ische Programmanalyse amp Metriken Echizeit gt 2 Definitionen starker Datenflussanomalien Geg Kontrollflussgraph G zu Programm P mit Datenflussattributen ohne Segmente starke ur Anomalie zu Anweisungen n mit Attribut u v und ber einen Pfad von n erreichbarem n mit r v gibt es keinen segmentfreien Pfad in G n n nK n in dem n nur einmal auftritt und f r den gilt es existiert 1 2 k 1 mit n besitzt Attribut d v oder u v Idee dieser Definition vonnmitu v nach n mit r v gibt es mindestens einen Ausf hrungspfad ausgeschlossen werden zyklische Pfade durch n um so die Analyse auf die erste Ausf hrung einer Anweisung in einer Schleife zu einzuschr nken auf keinem Pfad wird an Variable v ein Wert zugewiesen bevor bei n lesend auf v zugegriffen wird des weiteren werden Situationen ausgeschlossen bei denen die gerade betrachtete ur Anomalie teilweise durch irgendeine andere Anomalie berlagert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 203 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Definitionen starker Datenflussanomalien Fortsetzung starke du Anomalie zu Anweisungen n mit Attribut d v und ber einen Pfad von n erreichbarem n mit u v gibt es keinen segmentfreien Pfad in G n n n n in dem n nur einmal auftritt und f r den gilt es existiert 1 2 k 1
159. iteren werden Situationen ausgeschlossen bei denen die gerade betrachtete dd Anomalie teilweise durch irgendeine andere Anomalie berlagert wird Achtung unser Programm ggT enth lt keine starken Datenflussanomalien sondern ausschlie lich potentielle Datenflussanomalien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 205 Fachgebi A SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiel f r Programm ohne starke Datenflussanomalien PROCEDURE ggT IN m n INTEGER OUT o INTEGER BEGIN Nstart WHILE n gt 0 DO Nwhile n gt 0 IFm gt n THEN Ntm gt n o n keine starke dd Anomalie m m n ELSE n m m 0 keine starke ur Anomalie END endif END ggT final keine starke du Anomalie f r m Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 206 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit 5 X 3 5 Softwaremetriken Die Definition von Software Ma en basiert auf dem Wunsch einen quantitativen Zugang zum abstrakten Produkt Software zu gewinnen Dabei ist zwischen der Vermessung von Eigenschaften einer Software und der quantitativen Kontrolle des zugrundeliegenden Entwicklungs prozesses zu unterscheiden LiO2 Produktmetriken messen Eigenschaften der Software gt Qualit t der Software z B als Anzahl gefund
160. itsbeschreibung erzeugen erstes Ziel ist assembler also wird berpr ft ob diese Datei noch aktuell ist Daf r wird zun chst rekursiv berpr ft ob alle o Dateien von denen assembler abh ngt aktuell sind wenn sie bereits existieren messages o h ngt nur von Dateien ab f r die es keine eigenen Regeln gibt Deshalb bricht der rekursive Prozess ab und es wird nur die Zeitmarke von messages o mit den Zeitstempeln von messages c verglichen messages o hat eine ltere Zeitmarke als messages c und wird deshalb durch Ubersetzung neu erzeugt assembler besitzt nun eine ltere Zeitmarke als messages o und wird deshalb neu mit dem Binder Linker erzeugt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 124 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit systeme Makefiles mit mehreren Zielen assembler unix assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files unix o cc o assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files unix o make oder make assembler unix f hrt den obigen Bindevorgang aus assembler windows assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files windows o cc o assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files windows o make assembler windows f hrt den obigen Bindevorgang aus cleanup rm assembler o pass0 o pass1 o pass2 o pass3 o me
161. jektive Ein flussnahme des Messenden Gegenbeispiel Beurteilung der Lesbarkeit eines Pro gramms durch manuelle Durchsicht Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 208 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Ma skalen Nominalskala frei gew hlte Menge von Bezeichnungen wie etwa Programm in C Java Fortran geschrieben Q Ordinalskala geordnete Menge von Bezeichnern wie etwa Programm gut lesbar einigerma en lesbar absolut grauenhaft Rationalskala Messwerte k nnen zueinander in Relation gesetzt werden und prozentuale Aussagen mit Multiplikation und Division sind sinnvoll wie etwa Programm A besitzt doppelt halb soviele Programmzeilen wie Programm B weiteres Beispiel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 209 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Zielsetzung von Softwaremetriken hier U Metrik soll zur Prognose der Fehler einer bestimmten Art in einem Softwaresystem eingesetzt werden Q Softwarequalit t wird also mit etwas leicht messbaren wie der Anzahl der Fehler pro Codezeile die bis zum Zeitpunkt x gefunden wurden gleichgesetzt 1 Hypothese komplexer Code enth lt mehr Fehler als einfacher Code pro Zeile Quelltext gesucht werden also Metriken f r Komplexit t eines untersuchten gemessenen Softwaresystems U
162. k Seite 105 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Variantenmanagement f r Quelltextdateien Hierf r gibt es kaum eigene Unterst tzung Im wesentlichen bleiben folgende M glichkeiten zur Verwaltung verschiedener Varianten eines Dokuments Mit Hilfe der Versionsverwaltung wird je Variante ein eigener Entwicklungs zweig gepflegt mit entsprechendem Tag nderungen von einem Zweig werden mit Hilfe der Dreiwegeverschmelzung in andere Zweige propagiert Die verschiedenen Varianten werden alle in einer Datei gespeichert durch Bedingungsmakros ifdef Unix werden die f r eine Variante ben tigten Quelltextteile ein und ausgeblendet siehe pure variants Die verschiedenen Varianten einer Klassenimplementierung werden in Unterklassen ausgelagert Einsatz von Vererbung Ben tigte Varianten werden aus einer dom nenspezifischen Beschreibung generiert mit Quelltexttransformationen aspektorientierter Programmierung Achtung Auswahl Konfiguration Transformation ben tigter Quelltextdateien durch das Build Management siehe Abschnitt 2 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 106 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s 2 4 Releasemanagement Ein Release ist eine an Kunden ausgelieferte Konfiguration eines Soft ware Systems bestehend aus ausf hrbaren Programmen Bibliotheken Dokumentation Que
163. k Seite 195 SE II Statische Programmanalyse amp Metriken Undefined Reference Datenflussanomalie Eine ur Datenflussanomalie bez glich einer Variable v ist wie folgt definiert es gibt einen segmentfreien Pfad n Ng n hat Attribut u v v besitzt also keinen definierten Wert bein n Ng hat nicht Attribut d v v erh lt also keinen definierten Wert n hat Attribut r v auf v wird also lesend zugegriffen Beispiele f r ur Datenflussanomalien L Aufruf von ggT mit m n Q bei N na besitzt o keinen Wert Aufruf von ggT mit m 2 und n 6 bei nn o besitzt o keinen Wert Fachgebiet Echtzeit systeme O or 3 p Nstart Nwhile n gt 0 Ntm gt n No N Nm m n Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 196 SE II Statische Programmanalyse amp Metriken Defined Defined Datenflussanomalie Eine dd Datenflussanomalie bez glich einer Variable v ist wie folgt definiert es gibt einen segmentfreien Pfad n Ng n hat Attribut d v v erh lt also bein einen neuen Wert n Ng hat nicht Attribut rldlu v v wird also bis n nicht verwendet n hat Attribut d v alter Wert von v wird bei n unbenutzt berschrieben Beispiel f r dd Datenflussanomalie Q Aufruf von ggT mit m 6 und n 2 bei n wird Wert von o beim zweiten Mal berschrieben ohne vorher referenzier
164. k der false liefert gt AND b THEN die Belegung von b ist irrelevant f r das Testen und wird in vielen Programmiersprachen deshalb nicht ausgewertet Einfaches Beispiel f r modifzierten Bedingungs berdeckungstest b a OR b 0 0 1 1 1 Anmerkung der erste Testfall wird f r die Bedingung a und b genutzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 305 SE II Dynamische Programmanalysen und Testen Fachgebie Echtzeit systeme Komplexeres Beispiel f r Bedingungs berdeckungsalternativen Art der berdeckung b a OR b AND c atomar 0 Zweig min mehrfach modifiziert mehrfach Ol e Ol DOl ll DODl I 8 0 0 1 0 1 0 1 1 0 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 306 Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit systeme y Kontrollflusstest Pfad berdeckung C unenaiicn TeSt Jeder m gliche Pfad des Kontrollflussgraphen muss einmal durchlaufen werden U rein theoretisches Kriterium sobald Programm Schleifen enth lt unendliche viele verschiedene Pfade Programmdurchl ufe m glich dient als Vergleichsma stab f r andere Testverfahren findet trotzdem nicht alle Fehler z B Berechnungsfehler da kein ersch pfender Test aller m glichen Eingabewerte
165. kann zeigen dass der Korrelationskoeffizient r e 1 gilt die Grenzf ller und r treten auf wenn schon alle gemessenen Punkte x y auf einer Geraden liegen die Regressionsgerade steigt f r r und f llt f r r 7 f r r 0 verl uft die Gerade parallel zur X Achse es besteht also kein linearer Zusammenhang zwischen X und Y Werten r heisst Bestimmtheitsma und l sst sich interpretieren als Anteil der durch die Regression erkl rten Streuung der YWerte hat man z B r 0 7 erhalten dann ist r 0 49 d h 49 der Streuung der Y Werte werden durch die lineare Abh ngigkeit von X erkl rt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 215 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Auswertung von ordinalen rationalen Metriken l aufgrund von Erfahrungswerten sind sinnvolle untere und obere Grenzwerte f r einen Messwert bekannt siehe Kiviatdiagramm alle Komponenten Module Klassen Methoden mit kritischen Werten werden genauer untersucht und ggf saniert neu geschrieben solche Grenzwerte f r Messergebnisse sind nicht bekannt alle Komponenten Module Klassen Methoden werden untersucht deren Messwerte ausserhalb des Bereichs liegen in dem 95 der Messwerte liegen oder 80 oder 3 funktionaler Zusammenhang zwischen Metrik und gew nschtem Qualit tsmerkmal genauer bekannt zul ssige W
166. ktionalit t hinzugef gt werden es d rfen neue Invarianten hinzugef gt werden bzw die bestehenden Invarianten der Klasse versch rft werden geerbte und neue Methoden erhalten mindestens die geerbten Invarianten es d rfen Methoden redefiniert werden wenn dabei Vorbedingungen allenfalls gelockert werden redefinierte Methode ist min destens dann aufrufbar wenn geerbte Vorbedingungen erf llt sind gt Nachbedingungen allenfalls versch rft werden redefinierte Methode erf llt mindestens die geerbten Nachbedingungen Achtung Werden Invarianten versch rft hinzugef gt so m ssen auch die unver ndert gebliebenen geerbten Methoden diese neuen Invarianten erf llen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 330 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Implementierung der Spezialisierung in C class FlashingTrafficLight public TrafficLight bietet neue Operation blinkendes gelbes Licht an verbietet direkten bergang von rotem Licht zu gr nem Licht bei der Gelbphase nach der Rotphase ist auch das rote Licht an public erlaubte Versch rfung der geerbten Invarianten invariant isOff isFlashing amp amp isGreen isYellow isRed invariant isGreen amp amp isRed isYellow invariant isOff amp amp isFlashing verbotene Lockerung
167. kzeuge die aufbauend auf make das Build Management also die Erstellung und Installation von Softwarekonfigurationen f r verschiedenste Zielplattformen erleichtern Fokus liegt auf Softwareprojekten in denen vor allem C C oder Fortran 77 als Programmiersprachen eingesetzt werden U die Werkzeuge eignen sich nicht kaum f r Java Projekte oder SW Entwicklung im Windows Umfeld Automake unterst tzt Generierung guter makefiles aus deutlich kompakteren Konfigurationsdateien die von allen popul ren make Varianten ausf hrbar sind Autoconf unterst tzt Konfigurationsprozess von Software durch Generierung von config h Skelette Konfigurationsskripte schlie lich gibt es noch Libtool das Umgang mit Bibliotheken erleichtert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 136 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Zusammenfassung und Ratschl ge U Bereits in kleinsten Projekten ist die Automatisierung von Erzeugungsprozessen Buildmanagement ein Muss in einfachen F llen bietet der verwendete Compiler die notwendige Unterst tzung Im Linux Unix Umfeld ist GNU make das Standardwerkzeug f r die Automatisierung von Erzeugungsprozessen In jedem Projekt sollte es genau einen Verantwortlichen f r die Pflege von Konfigurationsdateien Makefiles und Build Prozesse geben F r Java Programmentwicklung gibt es mit Ant ein speziell zu
168. l der Verzweigungen unabh ngigen Pfade in einem Programm gemessen gt es wird davon ausgegangen dass jede Zusammenhangskomponente Teilprogramm genau einen Eintritts und einen Austrittsknoten hat damit besitzt jede Zusammenhangskomponente mit n Knoten mindestens n I Kanten diese immer vorhandenen Kanten werden nicht mitgez hlt die kleinste Komplexit t einer Zusammenhangskomponente soll 7 sein also wird von der Anzahl der Kanten n abgezogen und 2 addiert in GOTO freien Programmen wird damit genau die Anzahl der bedingten Anweisungen und Schleifen if while Statements gemessen die Zahl ndert sich nicht beim Einf gen normaler Anweisungen deshalb ist die Regel von McCabe mit ZZ Komponente lt 11 umstritten da allenfalls eine Aussage ber Testaufwand Anzahl der zu testenden unabh ngigen Programmpfade getroffen wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 221 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Halstead Metriken Eingangsgr en Die Halstead Metriken messen verschiedene Eigenschaften einer Software komponente Als Eingabe dienen immer U n Anzahl der unterschiedlichen Operatoren eines Programms verwendete arithmetische Operatoren Prozeduren Methoden U n Anzahl der unterschiedlichen Operanden eines Programms verwendete Variablen Parameter Konstanten N Gesamtzahl der verwendeten Operatoren in einem Program
169. l uses Kriterium all p uses all c uses Kriterium wird kaum benutzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 314 F i Dynamisc a un n Eee SE II Dynamische Programmanalysen und Teste systeme Beispiel f r fehlende Zweig berdeckung von all defs mit und a PROCEDURE countVowels IN s Sentence OUT count INTEGER Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER u i d s BEGIN start u count ne d count d i count 0 i 0 init WHILE sli DO IF slil a OR sli e OR s il i OR slil 0 OR sli u THEN count i 1 Datenflussfehler d count END i i 1 c i d i n END WHILE ul Nfinal END countVowels final c count Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 315 SE II Dynamische Programmanalysen und Testen Echtzeit systeme Beispiel f r fehlende Anweisungs berdeckung von all defs mit b PROCEDURE findVowel IN s Sentence OUT found BOOLEAN Searches for first vowel in sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN start u i d s u found 0 init d i WHILE sli DO IF s il a OR sli e OR s i i OR s i 0 OR sli u THEN break Schleife wird verlassen
170. llstest w hlt aus Menge der m glichen Werte eines Eingabedatums zuf llig Repr sentanten aus ggf gem bekannter statistischer Verteilung zur Erg nzung gut geeignet es werden ggf ganz unerwartete Testdaten ausgew hlt Smoke Test es wird nur Robustheit des Testobjekts getestet berechnete Ausgabe werte spielen keine Rolle auf Tastatur h mmern Syntax Test ist f r Eingabewerte der erlaubte syntaktische Aufbau bekannt als Grammatik angegeben kann man daraus systematisch Testf lle generieren Beispiele zul ssige Email Adresse ganze Zahl Float Pfadangaben von Unterverzeichnissen Zustandsbezogener Test siehe Abschnitt 4 6 Ursache Wirkungs Graph Analyse siehe folgende Folien Anwendungsfallbasiertes Testen siehe folgende Folien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 290 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Ursache Wirkungs Graph Analyse Verfahren aus SL12 Es handelt sich eigentlich um eine Kombination von zwei Verfahren Die Basis bilden sogenannte Entscheidungstabellen die Bedingungen an Eingaben und ausgel ste Aktionen eines Systems miteinander verkn pfen F r die systematische Erstellung einer Entscheidungstabelle wird zun chst ein Ursache Wirkungs Graph erstellt Ein Ursache Wirkungs Graph verkn pft Eingaben Ursachen Bedingungen mit daraus resultierenden Ausgaben Wirkungen
171. lltexte Installationsskripte Das Releasemangement dokumentiert ausgelieferte Konfigurationen und stellt deren Rekonstruierbarkeit sicher Aufgaben des Releasemanagement Festlegung der zus tzlichen Funktionalit t eines neuen Releases Festlegung des Zeitpunktes der Freigabe eines neuen Releases E Q Erstellung und Verbreitung eines Releases siehe auch Buildmanagement E Dokumentation des Releases welche Revisionen welcher Dateien sind Bestandteil des Releases welche Compilerversion wurde verwendet Betriebssystemversionen auf Entwicklungs und Zielplattform Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 107 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Planungsprozess f r neues Release 1 Vorbedingungen f r neues Release werden berpr ft viel Zeit vergangen neues Release aus Publicity Gr nden viele Fehler behoben neues Release mit allen Patches viele neue Funktionen hinzugef gt Weiterentwicklung wird eingefroren freeze Feature Freeze Soft Freeze nur noch Fehlerkorrekturen und kleine Ver besserungen erlaubt nur vermutlich nicht destabilisierende nderungen gt Code Freeze Hard Freeze nur noch absolut notwendige nderungen selbst gef hrliche Fehlerkorrekturen werden verboten 3 Letzte Fehlerkorrekturen und umfangreiche Qualit tssicherungsma nahmen Tests werden durchgef hrt
172. llung von Statistiken steht nicht im Vordergrund U Moderator gibt Pr fling nicht frei sondern nur Empfehlung an Manager kein formaler Inspektionsplan mit wohldefinierten Inspektionsregeln Ggf auch Diskussion alternativer Realisierungsans tze Walkthrough Informelles Review U Autor des Pr flings liest ihn vor ablauforientiert im Falle von Software Gutachter versuchen beim Vorlesen ohne weitere Vorbereitung Fehler zu finden E U Autor entscheidet selbst ber weitere Vorgehensweise E Zielsetzungen Fehler Probleme im Pr fling identifizieren gt Ausbildung Einarbeitung von Mitarbeitern Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 177 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 3 4 Kontroll und Datenflussorientierte Analysen Der Kontrollflussgraph ist eine h ufig verwendete Methode zur Darstellung von Programmen Die Verarbeitungssteuerung berneh men die Kontrollstrukturen der Software unter Nutzung der Daten werte Eingabedaten werden gelesen um Zwischenergebnisse zu bestimmen die in den Speicher geschrieben werden Die Daten flie en quasi durch die Software von Eingaben zu Ausgaben LiO2 Definition gerichteter Graph Ein gerichteter Graph G ist ein Tupel N E mit N Menge von Knoten Nodes Ec N xN einer Menge gerichteter Kanten eine Kante e V1 V2 E wird Kante von v nach v genannt
173. m jede Verwendungsstelle wird separat gez hlt N Gesamtzahl der verwendeten Operanden in einem Programm jede Verwendungsstelle wird separat gez hlt n n N Anzahl der verwendeten Deklarationen Programmvokabular N N N Anzahl der angewandten Auftreten von Deklarationen wird auch normale Programml nge genannt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 222 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit A Halstead Gr en eines Programms Prozedur Methode PROCEDURE countVowels IN s Sentence OUT count INTEGER start Counts how many vowels occur in a sentence Sentence must be terminated by a dot VAR i INTEGER BEGIN count 0 i 0 init WHILE s i DO IF slil a OR sli e OR s i OR s i 0 OR sli u THEN count count 1 END 1 END countVowels final n Anzahl unterschiedlicher Operatoren N Anzahl unterschiedlicher Operanden N Gesamtzahl verwendeter Operatoren N Gesamtzahl verwendeter Operanden n n tN S N N N Achtung es ist Vereinbarungssache ob Kon trollstrukturen Klammen etc wie WHILE IF auch als Operatoren gez hlt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 223 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzei
174. mit n besitzt Attribut d v oder u v oder r v Idee dieser Definition von n mit d v nach n mit u v gibt es mindestens einen Ausf hrungspfad ausgeschlossen werden wieder zyklische Pfade um so die Analyse auf die erste Ausf hrung einer Anweisung in einer Schleife zu einzuschr nken auf keinem Pfad wird an Variable v bei n zugewiesener Wert verwendet bevor er bei n undefiniert wird des weiteren werden Situationen ausgeschlossen bei denen die gerade betrachtete du Anomalie teilweise durch irgendeine andere Anomalie berlagert wird Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 204 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Definitionen starker Datenflussanomalien Fortsetzung starke dd Anomalie zu Anweisungen n mit Attribut d v und ber einen Pfad von n erreichbarem n mit d v gibt es keinen segmentfreien Pfad in G n n n n in dem n nach n nur einmal auftritt und f r den gilt es existiert 1 2 k 1 mit n besitzt Attribut d v oder u v oder r v Idee dieser Definition von n mit d v nach n mit d v gibt es mindestens einen Ausf hrungspfad ausgeschlossen werden wieder zyklische Pfade um so die Analyse auf die erste Ausf hrung einer Anweisung in einer Schleife zu einzuschr nken auf keinem Pfad wird an Variable v bei n zugewiesener Wert verwendet bevor bei n erneut ein Wert zugewiesen wird des we
175. mit besonderer Bedeu tung f r die Projekt berwachung und wohldefinierten Ergebnissen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 396 SE II Management der Software Entwicklung rg systeme Beispielprojekt Kundenbeschreibung der Anforderungen Motor Vehicle Reservation System MVRS A rental office lends motor vehicles of different types The assort ment comprises cars vans and trucks Vans are small trucks which may be used with the same driving license as cars Some client may reserve motor vehicles of a certain category for a certain period He or she has to sign a reservation contract The rental office guaran tees that a motor vehicle ofthe desired category will be available for the requested period The client may cancel the reservation at any time When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract Within the reserved period at latest at its end the client returns the motor vehicle and pays the bill Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 397 SE II Management der Software Entwicklung Eentzeit gt 2 Annahmen f r MVRS Projektplanung ber Grob Design der Software Q es wird eine sehr einfache Dreischichtenarchitektur verwendet U alle Daten werden in einer Datenbank gespeichert Datenbankschema muss entworfen werden gt Anfrageopera
176. mp c M1 c Datei includes ea M2 h Datei messages h amp c symbtab h amp c alle Module Pakete h ngen davon ab global h files h amp c in global h wird eine Konstante ge ndert alle c Dateien m ssen in beliebiger Reihenfolge parallel neu bersetzt werden cc c files c cc c messages c cc c symbtab c cc c pass0 c Hauptprogramm assembler muss neu aus allen o Dateien erzeugt werden cc o assemb assemb o pass0 o pass1 o pass2 o messages o files o Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 119 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Werkzeuge f r das Build Management siehe auch P009 Wie11 Das Werkzeug make im folgenden im Detail pr sentiert deklarativer regelbasierter Ansatz es werden Abh ngigkeiten zwischen Entwicklungsartefakten definiert mit zus tzlichen Kommandos zur Erzeugung abgeleiteter Artefakte unabh ngig v Entwicklungsprozess Programmiersprachen Werkzeugen Das Werkzeug Ant make Nachfolger im Java Umfeld gt gemischt deklarativer imperativer Ansatz es werden Abh ngigkeiten zwischen Aufgaben Tasks definiert Tasks k nnen mit Kontrollstrukturen ausprogrammiert werden verwendet XML Syntax f r Konfigurationsdateien in Java und vor allem f r Java Projekte entwickelt a
177. n Vorgehensmodell das den Gesamtproze der Software Erstellung und pflege in einzelne Schritte aufteilt Q Zus tzlich m ssen Verantwortlichkeiten der beteiligten Personen in Form von Rollen im Software Entwicklungsprozess klar geregelt sein Zur Erinnerung das Wasserfallmodell war lange Zeit das Standardvorgehensmodell zur Erstentwicklung von Software U in den letzten Jahren wurden f r die Weiter Entwicklung von Software bessere iterative Vorgehensmodelle entwickelt V Modell Rational Unified Process Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 31 systeme SE II Software Entwicklung Wartung und Re Engineering Eee S Die Phasen des Wasserfallmodells im berblick nn Einteilung in Phasen studie Phasen erzeugen Dokumente Anforderungs analyse System entwurf Codieren und Modultest Entwicklungszeit Integrations amp Systemtest Auslieferung amp Installation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 32 SE II Software Entwicklung Wartung und Re Engineering Echtzeit S systeme Machbarkeitsstudie feasibility study Die Machbarkeitsstudie sch tzt Kosten und Ertrag der geplanten Software Ent wicklung ab Dazu grobe Analyse des Problems mit L sungsvorschl gen Aufgaben Problem informell und abstrahiert beschreiben verschiedene L sungsans tze erarbeiten Koste
178. n quasi modal Methoden isoliert testen f r alle Zustands quivalenz klassen Aufrufreihenfolge der Methoden fest uni modal alle zul ssigen und verbote nen Reihenfolgen testen modal alle zul ssigen verbotenen Reihenfolgen testen f r alle Zustands quivalenzklassen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 325 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit C 5 X Beispiel Ampelsteuerung modale Klasse Eine Klasse Ampel TrafficLight wird im folgenden als Beispiel verwendet Sie bietet Grundfunktionen f r die Realisierung von Ampelsteuerungen an und verkapselt die Gemeinsamkeiten der Ampelsteuerungen verschiedener L nder eine Ampel ist aus oder im Rot Gelb Gr n Zyklus oder blinkt Zusatzfunktion von Rotphase wird entweder ber Gelb nach Gr n gewechselt oder direkt in Gelbphase nach Rot leuchtet entweder nur gelbes Licht oder auch rotes Licht eine Ampel kann immer ausgeschaltet werden oder nach Blinken wechseln vom Zustand Blinken wechselt eine Ampel immer nach Rot eine defekte Ampel ein Licht geht nicht schaltet sich automatisch ab Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 326 i Fachgebiet g 5 SE II Dynamische Programmanalysen und Testen Echtzeit Prinzipien bei der OO Implementierung der Ampelsteuerung U folgende Arten von Methoden we
179. n nderun gen Genehmigung oder Ablehnung von nderungen Planung von Freigaben Konfigurationsbuchf hrung R ckverfolgung aller nderungen bis zur letzten Bezugskonfiguration Konfigurationsauditierung Qualitit tssicherungsma nahmen f r Freigabe einer Konfiguration eines Erzeugnisses siehe Kapitel 3 und Kapitel 4 KM Planung Festlegung der Grunds tze und Verfahren zum KM in Form eines KM Plans Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 58 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Werkzeugorientierte Sicht auf KM Aktivit ten 1 KM Planung Beschreibung der Standards Verfahren und Werkzeuge die f r KM benutzt werden wer darf muss wann was machen Abschnitt 2 1 Versionsmanagement Verwaltung der Entwicklungsgeschichte eines Produkts also wer hat wann wo was und warum ge ndert Abschnitt 2 2 Variantenmanagement Verwaltung parallel existierender Auspr gungen eines Produkts f r verschiedene Anforderungen L nder Plattformen Abschnitt 2 3 Releasemanagement Verwaltung und Planung von Auslieferungsst nden wann wird eine neue Produktversion mit welchen Features auf den Markt geworfen Abschnitt 2 4 Buildmanagement Erzeugung des auszulieferenden Produkts wann muss welche Datei mit welchem Werkzeug generiert bersetzt werden Abschnitt 2 5 nderungsmanagement Verwaltung von nderungsanforderungen also Bearbeit
180. n l sst sich im allgemeinen nur schwer garantieren noch gr ere Probleme hat man bei verzeigerten Datenstrukturen delete obj1 obj3 obj2 Obiges Programmfragment ist nur dann in Ordnung wenn die Variablen obj1 und obj2 nicht auf dasselbe Objekt zeigen sonst w rde n mlich in der zweiten Zeile u obj1 und u obj2 gelten Unterscheidung von in out und inout Parametern in Java C Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 201 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Probleme mit statischer Datenflussanalyse bei Fallunterscheidungen IF Bedi THEN x expri ELSE y expr2 END IF Bed2 THEN z x ELSE z y END Das obige Programm funktioniert falls Bed1 und Bed2 quivalent sind Trotzdem liefert die Datenflussanalyse immer Anomalien da von ihr die quivalenz von Bed1 und Bed2 nicht erkannt wird Problem reale Programme enthalten oft viele Anomalien die nicht echte Program mierfehler sind zu viele nutzlose Warnungen werden erzeugt restriktivere Definitionen von sogenannten starken Anomalien bersehen andererseits u U zu viele echte Fehler siehe folgende Folien L sung zun chst neue Definitionen starker Anomalien verwenden dann bisherige Definitionen von schwachen Anomalien verwenden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 202 SE II Stat
181. n Anwender oder mehr als ein Release der Software so ist ein Changemanagementsystem wie in Bugzilla Redmine einzusetzen svn git make Bugzilla sind das Minimum f r jedes ernsthafte Projekt Sourceforge mit Kombination von svn git und Bugzilla Funktionalit t sinnvoll alles weitere h ngt von der Projektgr e und art ab Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 150 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme 2 9 Zus tzliche Literatur Ca10 J Calcote A Practitioner s Guide to GNU Autoconf Automake and Libtool William Pollock Publ 2010 Wh00 B Collins Sussman B W Fitzpatrick C M Pilato Version Control with Subversion Version 1 1 2004 http svnbook red bean com CW98 R Conradi B Westfechtel Version Models for Software Configuration Management ACM Computing Surveys vol 30 no 2 ACM Press 1998 232 282 DIN96 DIN EN ISO 10007 1996 Leitfaden f r Konfigurationsmanagement IEEE88 IEEE Standard 1042 1987 IEEE Guide to Software Configuration Management IEEE Computer Society Press 1988 IEEE98 IEEE Standard 828 1998 IEEE Standard for Software Configuration Management Plans IEEE Computer Society Press 1998 Po09 G Popp Konfigurationsmangement mit Subversion Maven und Redmine dpunkt verlag 3 Auflage 2009 PBLO5 K Pohl G B ckle F van der Linden Software Product Line Engineering Foundations
182. n Ausgabeparameter Charakter besitzen in Pascal Modula gibt es nur mit VAR gekennzeichnete inout Parameter in Sprachen wie C oder C hat man nur die M glichkeit out Parameter als Zeiger Referenzen auf Variable Objekte zu simulieren F r solche Parameter mit Ein und Ausgabecharakter m ssen wir wie folgt vorgehen Deklaration der Prozedur countVowels IN s INOUT count f r Nsa wird d count sowie d s angenommen da beide Variablen bei der bergabe einen definierten Wert haben sollten f r Nna wird c count angenommen da am Ende der Prozedur der Wert von count durch versteckte Zuweisung an Aufrufstelle bergeben wird Aufruf der Prozedur countVowels aSentence aCounter es wird c aSentence und c aCounter in normaler Anweisung oder p aSentence und p aCounter in Pr dikat gefolgt von d aCounter angenommen da beim Aufruf versteckte Zuweisungen die Werte von aSentence und aCounter an die Parameter s und count zuweisen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 187 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Datenflussgraph formale Definition Ein Datenflussgraph D V4 Ea zu einem Kontrollflussgraphen G eines Programms besteht aus einer Menge von Knoten V f r alle Anweisungen V des Programms einer Menge von Datenflusskanten E n n E genau dann wenn es einen Pfad p im Kontrollflussgraphen G von n nach n gibt sodass f
183. n Produktionsumgebungen getestet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 266 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Testen testen wann ist Schluss damit U nie nach jeder Programm nderung wird eine gro e Anzahl von Testf llen auto matisch ausgef hrt siehe Regressionstest U Testbudget verbraucht bzw Auslieferungszeitpunkt f r Software erreicht der Kunde testet unfreiwillig weiter je Testfall Zeiteinheit gefundene Fehlerzahl sinkt unter gegebene Grenze in der Hoffnung dass die Anzahl der im Programm verbliebenen Fehler mit der Anzahl der pro Zeiteinheit gefundenen Fehler korreliert n absichtlich von einer Gruppe implantierter Fehler seeded bugs wurden von Testgruppe gefunden siehe auch Mutationstestverfahren gem systematischen Verfahren werden aus allen m glichen Eingabedaten kombinationen typische Repr sentanten ausgew hlt und genau diese getestet siehe Abschnitt 4 3 Testf lle decken hinreichend viele relevante Programmdurchl ufe ab siehe Test berdeckungsmetriken in Abschnitt 4 4 und Abschnitt 4 5 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 267 i Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit 4 2 Laufzeit und Speicherplatzverbrauchsmessungen Gemeinsame Eigenschaft aller hier vorgestellten Werkzeuge Verfahren ist Anzeige o
184. n deshalb eigene Verschmelzungsfunktionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 91 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Verbleibende M ngel von CVS zugeschnitten auf Textdateien bei Deltaberechnung und Verschmelzen keine Versionierung von Verzeichnisstrukturen Directories nicht integriert mit Build und Changemanagement keine gute Unterst tzung f r geographisch verteilte Software Entwicklung als Open Software ohne Anschaffungskosten erh ltlich immer noch in manchen Open Software Projekten eingesetzt Administrationsaufwand h lt sich in Grenzen f r Build und Changemanagement gibt es erg nzende Produkte Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 92 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s CVS Nachfolger Subversion Wh00 P009 immer ganze Dateib ume werden durch commit versioniert inklusive Erzeugen L schen Kopieren und Umbenennen von Dateien und Unterverzeichnissen commit ganzer Verzeichnisse ist eine atomare Aktion auch bei Server Abst rzen Netzwerkzusammenbr chen die ganz oder gar nicht erfolgt Metadaten Dateiattribute Tags werden als versionierte Objekte unterst tzt Deltaberechnung funktioniert f r beliebige Dateien auch Bin rdateien Ver schmelzungsoperationen sind aber weiterhin eher auf Textdateien
185. n erster Linie mit der Verwaltung der zeitlich aufeinander folgenden Revisionen eines Dokuments Bekannteste open source Produkte in zeitlicher Reihenfolge sind Source Code Control System SCCS von AT amp T Bell Labs effiziente Speicherung von Textdateiversionen als Patches Revision Control System RCS von Berkley Purdue University schnellerer Zugriff auf Textdateiversionen Concurrent Version Control System CVS zun chst Skripte f r RCS Verwaltung von Dateib umen gt parallele Bearbeitung von Textdateiversionen Subversion SVN CVS Nachfolger von CollabNet initiiert http www collab net Versionierung von Dateib umen Git Mercurial als verteilte Versionsmanagementsysteme gt jeder Entwickler hat eigene lokale Versionsverwaltung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 67 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Source Code Control System SCCS von AT amp T Bell Labs Je Dokument Quelltextdatei gibt es eine eigene History Datei die alle Revisionen als eine Liste jeweils ge nderter Text Bl cke speichert gt jeder Block ist ein Delta das nderungen zwischen Vorg ngerrevision und aktueller Revision beschreibt jedes Delta hat SCCS Identifikationsnummer der zugeh rigen Revision lt ReleaseNo gt lt LevelNo gt lt BranchNo gt lt SequenceNo gt Revisionsb ume von SCCS Release 1 1 Neu
186. n f r die objektorientierte Softwareentwick lung Oldenbourg Verlag 1999 Ein von Praktikern geschriebenes Buch mit einer F lle von Tipps und Tricks Es enth lt eine kurze Einf h rung in den Unified Software Development Process sowie in das V Modell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 411
187. n ist klar dass wirklich oper f r neuen Parametertyp eingef hrt werden soll Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 158 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiele stilistischer Regeln f r C 3 nie Attribute in Unterklasse mit selbem Namen wie in Oberklasse class Animal public int attr1 class Elephant Animal public int attr1 something Grund Es werden zwei Attribute mit dem Namen attr1 deklariert f r Objekte der Klasse Elephant ist aber nur das neue Attribut attri direkt zugreifbar L sung Anderen Namen verwenden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 159 Fachgebiet 4 y SE II Statische Programmanalyse amp Metriken Echtzeit systeme Beispiele stilistischer Regeln f r C 4 6 Beachte bliche Namenskonventionen Klassennamen beginnen immer mit Gro buchstaben alle anderen Namen mit Kleinbuchstaben Variablennamen enthalten nur Kleinbuchstaben und Ziffern 6 keine komplexen Ausdr cke in Schleifenbedingungen for int i 0 i lt vector size i do something Besser vectorsize vector size for int i 0 i lt vectorsize i do something Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 160 Fachgebiet 5 SE II Statische Programmanal
188. ndy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 225 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 Live Variables und Variablenspanne Live Variables einer Komponente ist durchschnittliche Anzahl lebendiger Variablen in einem Programm pro Zeile U eine Variable ist von ihrer ersten Definitionsstelle vom Startknoten aus bis zur letzten Definitions oder Referenzierungsstelle vor dem Endknoten lebendig Variablenspanne einer Komponente ist die durchschnittliche Spanne zweier direkt aufeinander folgender definierender oder referenzierender Auftreten derselben Variable in beiden F llen wird der Kontrollfluss des Programms Schleifen bedingte Verzweigungen ignoriert und es werden einfach nur Programmzeilen gez hlt Anmerkung Mit diesen beiden Metriken versucht man nicht die Kontrollflusskomplexit t oder einfache Gr e einer Softwarekomponente sondern die Komplexit t des Datenflusses zu bewerten wieviele Variablen muss man wie lange beim Erstellen von Programm zeilen im Kopf behalten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 226 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Beispiel f r Live Variables und Variablenspanne 1 IF min gt max THEN 2 hilf min 3 min max 4 max hilf Berechnung der Metriken Zeile define r
189. ngsstellen umstritten oft gro e Abweichungen zwischen zertifiziertem Prozess und realem Prozess Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 383 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Das Capability Maturity Model CMM Referenzmodell zur Beurteilung von Softwarelieferanten vom Software Engineering Institute entwickelt http www sei cmu edu cmm cmms html Softwareentwicklungsprozesse werden in 5 Reifegrade unterteilt Reifegrad maturity entspricht Qualit tsstufe der Softwareentwicklung h here Stufe beinhaltet Anforderungen der tieferen Stufen Stufe 1 chaotischer initialer Prozess ihr Stand vor dieser Vorlesung Prozess Charakteristika unvorhersehbare Entwicklungskosten zeit und qualit t kein Projektmanagement nur K nstler am Werke notwendige Aktionen Planung mit Kosten und Zeitsch tzung einf hren gt nderungs und Qualit tssicherungsmanagement Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 384 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Stufe 2 wiederholbarer intuitiver Prozess Stand nach dieser Vorlesung Prozess Charakteristika Kosten und Qualit t schwanken gute Terminkontrolle Know How einzelner Personen entscheidend notwendige Aktionen Prozessstandards entwickeln gt Methoden f r Analyse E
190. nhand von Lastenheft Pflichtenheft ein Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen das erst sehr sp t entsteht Risikomaximierung gt andere Prozessmodelle mit Erstellung von Prototypen Anforderungen werden fr h eingefroren notwendiger Wandel aufgrund organisa torischer politischer technischer nderungen nicht eingeplant gt andere Prozessmodelle mit evolution rer Software Entwicklung strikte Phaseneinteilung ist unrealistisch R ckgriffe sind notwendig gt andere Prozessmodelle mit iterativer Vorgehensweise Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 363 SE II Management der Software Entwicklung systeme Evolution res Modell evolution res Prototyping Planung und erste Produktdefinition Prototyperstellung Validierung durch Anwender Modifikation der Produktdefinition Prototyp ok Auslieferung und Einsatz Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 364 SE II Management der Software Entwicklung Echizeit gt 2 Bewertung des evolution ren Modells es ist sehr fr h ein durch Kunden evaluierbarer Prototyp da Kosten und Leistungsumfang des gesamten Softwaresystems m ssen nicht zu Beginn des Projekts vollst ndig festgelegt werden Projektplanung vereinfacht sich durch berschaubarere Teilprojekte Systemarchitektur muss auf Erweiterbarkeit angelegt sein
191. nige Berechnungsfehler und kaum Kontrollflussfehler all p uses Kriterium f r jede Definitionsstelle d x wird jeweils ein definitions freier Pfade zu allen erreichbaren pr dikativen Benutzungen p x getestet entdeckt vor allem Kontrollflussfehler Berechnungsfehler bleiben oft unentdeckt Anmerkung manchmal wird auch Test aller definitionsfreien Pfade von d x zu allen p x gefordert die Schleifen nicht mehrfach durchlaufen m s sen dann ist Zweig berdeckung enthalten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 313 i Fachgebiet g 5 SE II Dynamische Programmanalysen und Testen Echtzeit A systeme Kriterien f r den Datenflusstest 2 Q all c uses Kriterium f r jede Definitionsstelle d x wird jeweils ein definitions freier Pfade zu allen erreichbaren berechnenden Benutzungen c x getestet gt entdeckt vor allem Berechnungsfehler Kontrollflussfehler bleiben oft unentdeckt l sst sich wegen Bedingungen oft nicht erzwingen all p uses some c uses Kriterium f r jede Definitionsstelle d x wird jeweils ein definitionsfreier Pfade zu allen erreichbaren pr dikativen Benutzungen p x getestet gibt es keine pr dikate Benutzung p x so wird wenigstens ein Pfad zu einem berechnenden Zugriff c x betrachtet gt entdeckt Kontrollfluss und auch Berechnungsfehler umfasst all def und all p uses Kriterium U all c uses some p uses Kriterium wird kaum benutzt Q al
192. nsch tzung durchf hren Angebotserstellung Ergebnisse Lastenheft sehr grobes Pflichtenheft Projektkalkulation gt Projektplan gt Angebot an Auftraggeber Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 33 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t Anforderungsanalyse requirements engineering In der Anforderungsanalyse wird exakt festgelegt was die Software leisten soll aber nicht wie diese Leistungsmerkmale erreicht werden Aufgaben gt genaue Festlegung der Systemeigenschaften wie Funktionalit t Leistung Benutzungsschnittstelle Portierbarkeit im Pflichtenheft Bestimmen von Testf llen Festlegung erforderlicher Dokumentationsdokumente Ergebnisse Pflichtenheft Anforderungsanalysedokument gt Akzeptanztestplan Benutzungshandbuch 1 te Version Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 34 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t Systementwurf system design programming in the large Im Systementwurf wird exakt festgelegt wie die Funktionen der Software zu realisieren sind Es wird der Bauplan der Software die Software Architektur entwickelt Aufgaben Programmieren im Gro en Entwicklung eines Bauplans Grobentwurf der System in Teilsysteme Module zerlegt Auswahl bereits existierend
193. ntwurf Testen einf hren Stufe 3 definierter qualitativer Prozess Stand der US Industrie 1989 Prozess Charakteristika zuverl ssige Kosten und Terminkontrolle schwankende Qualit t institutionalisierter Prozess unabh ngig von Individuen U notwendige Aktionen Prozesse vermessen und analysieren gt quantitative Qualit tssicherung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 385 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Stufe 4 gesteuerter geleiteter quantitativer Prozess Prozess Charakteristika gt gute statistische Kontrolle ber Produktqualit t Prozesse durch Metriken gesteuert U notwendige Aktionen gt instrumentierte Prozessumgebung mit berwachung gt konomisch gerechtfertigte Investitionen in neue Technologien Stufe 5 optimierender r ckgekoppelter Prozess U Prozess Charakteristika quantitative Basis f r Kapitalinvestitionen in Prozessautomatisierung und verbesserung U notwendige Aktionen kontinuierlicher Schwerpunkt auf Prozessvermessung und verbesserung zur Fehlervermeidung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 386 SE II Management der Software Entwicklung Echizeit gt 2 Stand von Organisationen im Jahre 2000 2007 Daten vom Software Engineering Institute SEI aus dem Jahr 2000 2007 unter http www sei cmu edu ap
194. nwendung des inversen Deltas Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 96 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Zweidimensionaler Zustandsraum des Subversion Repositories Dateiverzeichnis proj trunk sub1 file1 file2 sub2 branches b1 sub1 file1 file2 sub2 ps sub3 S a p r3 snapshot history Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 97 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A 2 3 Variantenmanagement Software Produktlinien Das Variantenmanagement befasst sich mit der Verwaltung neben einander existierender Versionen eines Dokuments die jeweils eine zeitliche Entwicklungsgeschichte besitzen Beispiel assembler Legende M mit Makros M o O ohne Makros D deutsche Meldungen E englische Meldungen gt U f r Unix Importbeziehun pass1 pass2 W f r Microsoft Windows p g Pea Denkbare Varianten M D U mit Makros f r Deutsch und Unix O D U ohne Makros f r Deutsch Unix DW EU M E U messages symboltab alle Module Komponenten h ngen davon ab global Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 98
195. ockliste U Revisionsidentifikation nur durch Nummer und Datum Offene Probleme kein Konfigurationsbegriff und kein Variantenbegriff keine Unterst tzung zur Verwaltung von Konsistenzbeziehungen zwischen verschiedenen Objekten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 79 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Probleme mit Schreibsperren SCCS realisiert ein sogenanntes pessimistisches Sperrkonzept Gleichzeitige Bearbeitung einer Datei durch mehrere Personen wird verhindert ein Checkout zum Schreiben single write access mehrere Checkouts zum Lesen multiple read access In der Praxis kommt es aber fter vor dass mehrere Entwickler dieselbe Datei zeit gleich ver ndern m ssen oder Person mit Schreibrecht commit vergisst Unbefriedigende L sungen Entwickler mit Schreibrecht macht commit unfertiger Datei Entwickler mit dringendstem nderungswunsch macht checkout mit Schreibrecht inkonsistente Zust nde in Repository nur einer darf Arbeiten Q weitere Entwickler mit Schreibwunsch stehlen Datei machen also checkout mit Leserecht und modifizieren Datei trotzdem gt Problem Verschmelzen der verschiedenen nderungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 80 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit
196. odlerumng Cork Datbaukschema C k LEt atar zak Be nt role mie Cak Upe pe ratoe i Cak Artageope ratioei 4 Cokumentatlaor Doa Maral Dokt i llne Hihe Inte ratlon 5 Abnahme Aufgabenhierarchie Tann ou 1 cin Ea s 30 days DEET adag 18 das DEST DESE 37 days 20da i5 dms iD das PES Dauer Mon 14 04 05 Moi 23 04 05 Mar 05 05 03 Mor 05 05 05 Mor 19 05 05 Mor 05 05 05 Moi 02 05 05 Mor 2 05 05 Thu 01 03 03 Thi 01 05 05 Mor 2 05 05 Mor 15 05 05 Mor 20 05 05 otat Ende Fri 25005 F ri 02 0503 Fri 13 06 03 Fri 16 0505 Moi 25 05 05 Ved 25 05 03 Preckc zz on Fri 130505 6 Fri 130503 Fri 20 06 03 Vied 25 05 05 Fr 6 Fria 05 05 Fri 11 00 03 Datum eTa 10 11 12 Abh ngigkeiten Echtzeit systeme Achtung Start und Ende von Aufgaben werden aus Dauer der Aufgaben und Zeitpunkt f r Projektbeginn automatisch errechnet siehe folgende Folien Fachgebiet h 2 A Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 400 Fachgebiet z SE II Management der Software Entwicklung Echtzeit Planung von Arbeitspaketabh ngigkeiten mit PERT Charts Idee Listen aufbau 6 Tage Anfrage operationen 0 Tage Datenbank schema Integration Systemtest 10 Tage 10 Tage Update operationen Analyse Abnahme Benutzer Online Hilfe oberfl che 15 Tage
197. ogramme weitere berlegungen Gesucht werden Metriken die neben der Kopplung von Klassen folgende Aspekte in Ma zahlen zusammenfassen die Methoden einer Klasse sollten enge Bindung high cohesion besitzen also einem hnlichen Zweck dienen wie misst man das die Klassen einer Vererbungshierarchie sollten ebenfalls enge Bindung besitzen die in einem Modul bzw Paket zusammengefassten Klassen oder die in einer Klasse zusammengefassten Methoden sollten enge Bindung besitzen Klassen in verschiedenen Modulen sollte lose gekoppelt sein wie misst man das loose coupling Klassen und Module bzw Pakete sollten ein Implementierungsgeheimnis verbergen data abstraction encapsulation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 229 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Bindungsmetriken LOCOM1 Low Cohesion Metric Die Bindung der Methoden einer Klasse wird untersucht Methoden sind eng aneinander gebunden wenn sie auf viele gemeinsame Attribute Felder zugreifen P Anzahl der Paare von Methoden ohne gemeinsame Attributzugriffe Q Anzahl der Paare von Methoden mit gemeinsamen Attributzugriffen gt LOCOM1 ifP gt Qthen P Q else 0 Gew nscht wird Wert von LOCOMI nahe bei 0 Beispiel getName und setName der Klasse Person greift auf Attribut name zu getAddr und setAddr der Klasse Person greift auf Attribut addr zu compare greift auf Attri
198. ol 15 No 10 1972 Fu93 A Fugetta A Classification of CASE Technology Computer Vol 26 No 12 S 25 38 IEEE Computer Society Press 1993 GJ96 P K Garg M Jazayeri Eds Process Centered Software Engineering Environments IEEE Computer Society Press 1996 Hr00 P Hruschka Mein Weg zu CASE von der Idee ber Methoden zu Werkzeugen Hanser Verlag 1991 IEEE83 IEEE Standard Glossar of Software Engineering Terminology IEEE Standard 729 IEEE Computer Society Press 1983 Jo92 C Jones CASE s Missing Elements IEEE Spektrum Juni 1992 S 38 41 IEEE Computer Society Press 1992 Ka98 B Kahlbrandt Software Engineering Objektorientierte Software Entwicklung mit der Unified Mode ling Language Springer Verlag 1998 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 53 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Na96 M Nagl ed Building Thightly Integrated Software Development Environments The IPSEN Approach LNCS 1170 Springer Verlag 1996 R092 Ch Roth Die Auswirkungen von CASE Proc GI Jahrestagung 1992 Karlsruhe Informatik aktuell S 648 656 Sn87 H M Sneed Software Management M ller GmbH 1987 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 54 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Konfigurationsmanagement Beim Konfigur
199. ol System Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 144 SE II Konfigurationsmanagement Echizeit gt t WWW Seiten einiger DVCS Systeme in Entwicklung U Monotone http monotone ca Mercurial aka hg http www selenic com mercurial wiki U Bazaar http bazaar vcs org Q sit http git scem com Anmerkung zu ClearCase Das System ist ein Grenzfall zwischen VCS und DVCS Es handelt sich zwar um kein reines Client Server System mehr aber die Verteilung auf mehrere Server und deren Kooperation hat doch noch sehr zentralistischen Charakter im Gegensatz zu den reinen DVCS die auf dem Rechner eines jeden Entwicklers eine eigene Instanz laufen haben Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 145 i Fachgebiet SE II Konfigurationsmanagement Echtzeit systeme Echt verteilte Versionierungs Systeme Jeder Benutzer hat sein eigenes vollst ndiges Repository statt globale Repositories f r Teilgruppen von Entwicklern wie bei ClearCase Alice s Rechner Bob s Rechner lokales lokales Repository Repository working working Copy Copy Push Revisionen zu anderen Repositories aktiv propagieren Pull Revisionen von anderen Repositories aktiv holen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 146 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme
200. on a hardware simulator and under field conditions Program software does not degrade due to war fatigue or reproduction process Computer execution errors are caused by faulty hardware components and Die Wahrscheinlichkeit f r Computer selects wrong energy wurde deshalb auf 10 gesetzt angenommener Zeitraum ist mir unbekannt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 29 SE II Software Entwicklung Wartung und Re Engineering Echtzeit S systeme Schwerpunkte meiner Software Engineering Vorlesungen Schwerpunkte von Software Engineering Einf hrung Sprachen f r die Entwicklung Modellierung von Software gt Werkzeuge zur Konstruktion von Software Vorgehensmodelle f r konstruktive Qualit tssicherung Schwerpunkte von Software Engineering hier Vorgehensmodelle f r analytische Qualit tssicherung Werkzeuge zur berpr fung von Software Qualit t Vorgehensweisen zur Verbesserung Restrukturierung von Software konstruktive Ma nahmen zum Management von Software Entwicklungs und Anderungsprozessen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 30 systeme SE II Software Entwicklung Wartung und Re Engineering Echtzeit t 1 3 Iterative Software Entwicklung Voraussetzung f r den sinnvollen Einsatz von Notationen und Werkzeugen zur Software Entwicklung ist ei
201. ondern kopiert Rumpf an Aufrufstelle ein h Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 337 Fachgebiet z SE II Dynamische Programmanalysen und Testen Echtzeit Einsatz von Automaten Statecharts zur Testplanung Oft lassen sich die Vorbedingungen f r den Aufruf von Methoden besser durch ein Sta techart hierarchischer Automat siehe Software Eng Einf hrung darstellen offOnFault greenOk amp amp lt lt new gt gt ellowOk amp amp redOk redOn lightOn greenOk amp amp yellowOk Flashing amp amp redOk lt lt delete gt gt lightOff Achtung im Zustand Yellow ist aul das rote Licht an Ein solches Statechart kann dann hnlich wie ein Kontrollflussgraph zur Planung von Testf llen zur Berechnung von Test berdeckungsmetriken herangezogen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 338 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Pr zisierung der vier verschiedenen Arten von Klassen U Nicht modale Klasse keine Methode der Klasse hat eine Vorbedingung der Zustandsautomat der Klasse besteht aus einem Zustand Quasimodale Klasse gt mindestens eine Methode der Klasse hat eine Vorbedingung der Zustandsautomat der Klasse besteht aus einem Zustand U Unimodale Klasse der Zustandsautomat der Klasse besteht aus mehreren Zust nden keine Transi
202. ozessmodelle Verbesserung Qualit t von Softwareprozessmodellen Projektmanagement werkzeuge Achtung Viele im folgenden vorgestellten berlegungen sind nicht ausschlie lich f r Software Entwicklungsprozesse geeignet sondern werden ganz allgemein f r die Steuerung komplexer technischer Entwicklungsprozesse eingesetzt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 357 Fachgebiet SE II Management der Software Entwicklung Echtzeit systeme Aufgaben des Managements Q Planungsaktivit ten Ziele definieren Vorgehensweisen ausw hlen Termine fest legen Budgets vorbereiten Vorgehensmodelle Kostensch tzung Projektpl ne Organisationsaktivit ten Strukturieren von Aufgaben Festlegung organisatori scher Strukturen Definition von Qualifikationsprofilen f r Positionen Rollenmodelle Team Modelle Projektpl ne Personalaktivit ten Positionen besetzen Mitarbeiter beurteilen weiterbilden nicht Thema dieser Vorlesung Leitungsaktivit ten Mitarbeiter f hren motivieren koordinieren nicht Thema dieser Vorlesung Kontrollaktivit ten Prozess und Produktstandards entwickeln Berichts und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturen gt Qualitit tsmanagement insbesondere f r Software Entwicklungsprozesse Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 358
203. praisal program profile profile html Die Daten in Klammern betreffen das Jahr 2007 f r den Vergleich mit dem Stand im Jahr 2000 die genannte URL existiert nicht mehr U 32 3 1 7 der Organisationen im Zustand initial 39 3 32 7 der Organisationen im Zustand wiederholbar 19 4 36 1 der Organisationen im Zustand definiert 5 4 4 2 der Organisationen im Zustand kontrolliert 3 7 16 4 der Organisationen im Zustand optimierend Genauere Einf hrung in CMM findet man in DyO2 weitere Informationen zum Nachfolger CMMI von CMM siehe folgende Seiten findet man unter http cmmiinstitute com Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 387 SE II Management der Software Entwicklung Echizeit gt 2 ISO 9000 TQM und CMM im Vergleich Schwerpunkt der ISO 9001 Zertifizierung liegt auf Nachweis eines Qualit ts managementsystems im Sinne der Norm allgemein f r Produktionsabl ufe geeignet genau ein Reifegrad wird zertifiziert CMM konzentriert sich auf Qualit ts und Produktivit tssteigerung des gesamten Softwareentwicklungsprozesses gt auf Softwareentwicklung zugeschnitten gt dynamisches Modell mit kontinuierlichem Verbesserungsdruck TOM ist eine ganzheitliche umfassende Unternehmensphilosophie die Qualit t aus der Sicht des Kunden als oberstes Ziel verfolgt gt umfassender Ansatz mit Ber cksichtung sozialer Aspekte
204. r er gleich Null mit folgenden Intervallen in denen unterschiedliche Berechnungsschemata verwendet werden kurze Bretter mit 0 99 cm normale Bretter mit 100 300 cm zu lange Bretter mit 300 cm U Auftragsart Aufz hlungstyp DoltYourself Normal Express Alle drei Parameter interagieren bei der Berechnung des Preises eines Bretts also m ssten eigentlich zumindest alle 3x3x3 27 Kombinationen v quivalenzklassen getestet werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 287 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Paarweiser Testansatz Pairwise Testing Die Praxis zeigt dass ca 80 aller von bestimmten Parameterwertkombinationen ausgel sten Softwarefehler bereits durch Wahl bestimmter Paarkombinationen beobachtet werden k nnen Also werden beim paarweisen Testen einer Funktion mit n Parametern nicht alle m glichen Kombinationen berpr ft sondern nur alle paarweisen Kombinationen Beispiel Holzart Buche Buche Buche Eiche Eiche Eiche Kiefer Kiefer Kiefer L nge kurz norm lang kurz norm lang kurz norm lang Auftragsart Dolt Norm Expr Expr Dolt Norm Norm Expr Dolt Im Beispiel werden f r die Erzeugung aller m glichen paarweisen Kombinationen von quivalenzklassen von Testwerten nur 9 Testf lle Testvektoren ben tigt anstell
205. r Datentechnik Seite 360 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit 5 1 Neuere Vorgehensmodelle Die naheliegendste Idee zur Verbesserung des Wasserfallmodells ergibt sich durch die Einf hrung von Zyklen bzw R ckgriffen Sie erlauben Wiederaufnehmen fr herer Phasen wenn in sp teren Phasen Probleme auftreten Machbarkeits studie Anforderungs R ckgriff b analyse System entwurf Weitere Vorgehensmodelle das V Modell umgeklapptes Wasserfallmodell Q das evolution re Modell iteriertes Wasserfallmodell U Rapid Prototyping Throw Away Prototyping Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 361 SE II Management der Software Entwicklung a systeme Zur Erinnerung das Wasserfallmodell Machbar keitsstudie Anforderungs analyse System entwurf Codieren und Moduiltest Integrations amp Systemtest Auslieferung amp Installation Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 362 SE II Management der Software Entwicklung Echizeit gt 2 Probleme mit dem Wasserfallmodell insgesamt Wartung mit ca 60 des Gesamtaufwandes ist eine Phase andere Prozessmodelle mit Wartung als eigener Entwicklungsprozess zu Projektbeginn sind nur ungenaue Kosten und Ressourcensch tzungen m glich gt Methoden zur Kostensch tzung a
206. r Identifikation von Speicherlecks Kennenlernen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 244 Fachgebiet 4 y SE II Dynamische Programmanalysen und Testen Echtzeit C 5 X 4 1 Einleitung Anforderungsdefinition korrekte fehlerhafte Lastenheft Anforderungen Anforderungen Systemspezifikation korrekte Spezifikations induzierte Fehler Detailanalyse Spezifikation fehler aus Anforderungen Entwurf Design Se EN u induzierte Fehler aus Realisierung a e induzierte Fehler aus T dl korrektes korrigierte gefundene nicht unbekannte est und Integration Programm Fehler korrigierte Fehler Fehler Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 245 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Fehlerzustand Fehlerwirkung und Fehlhandlung DIN 66271 Q Fehlerzustand fault inkorrektes Teilprogramm inkorrekte Anweisung oder Datendefinition die Ursache f r Fehlerwirkung ist Zustand eines Softwareprodukts oder einer seiner Komponenten der unter spezifischen Bedingungen eine geforderte Funktion beeintr chtigen kann Fehlerwirkung failure Wirkung eines Fehlerzustandes die bei der Ausf hrung des Testobjektes nach aussen in Erscheinung tritt gt Abweichung zwischen spezifiziertem Soll Wert Anforderungsdefinition und beobachtetem Ist Wert bzw Soll und Ist Verhalten Fehl
207. r Regel von der Korrektheit der erzeugten Komponenten berzeugt ihre Komponenten werden h chstens falsch benutzt Komponententest wird als l stige Pflicht aufgefasst die Folgearbeiten mit sich bringt Fehlerbeseitigung Glauben in die eigene Unfehlbarkeit ersch ttert Entwickler will eigene Fehler unbewusst nicht finden und kann sie auch oft nicht finden da ggf sein Testcode von denselben falschen Annahmen ausgeht Fehlersuche durch getrennte Testabteilung ist noch rgerlicher die sind zu doof zum Entwickeln und weisen mir permanent meine Fehlbarkeit nach Programminspektion und seine Varianten sind u a ein Versuch diese psychologi schen Probleme in den Griff zu bekommen Rolle des Moderators ist von entscheidender Bedeutung f r konstruktiven Verlauf von Inspektionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 174 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Vorgehensweise bei der Programminspektion Inspektionsteam besteht aus Moderator Autor passiv Gutachter n Protokoll f hrer und ggf Vorleser nicht dabei sind Vorgesetzte des Autors Gutachter sind in aller Regel selbst in anderen Projekten Entwickler Inspektion berpr ft ob gt Dokument Spezifikation erf llt Implementierung konsistent zu Modell f r Dokumenterstellung vorgeschriebene Standards eingehalten wurden Inspektion hat nicht zum Ziel zu untersuchen
208. r darstellbarer Integer Zahl uv Maxlnt f r Intervalle mit gr ter darstellbarer Integer Zahl offene Intervallgrenzen sind nat rlich erlaubt f r reelle Zahlen Float mit Voraussetzung kleinste gr te Zahl nicht darstellbar ov oder ov f r nach unten offene Intervalle uv oder uv f r nach oben offene Intervalle alle Mischformen von Intervallen mit festen unteren und oberen Grenzen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 277 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Regeln f r die Festlegung von Eingabewerteklassen Fortsetzung f r Zeichenketten String Definition ber regul re Ausdr cke oder Grammatiken gt Aufz hlung konkreter Werte siehe n chster Punkt f r beliebige Wertebereiche v1v2v3 vn f r Auswahl von genau n verschiedenen Werten f r zusammengesetzte Wertebereiche gt Anwendung der obigen Prinzipien auf die einzelnen Wertebereiche gt ggf braucht man noch zus tzliche Einschr nkungen Constraints die nur bestimmte Wertekombinationen f r die Teilkomponenten zulassen Eingabewerteklassen die aus genau einem Wert bestehen v es ist aber auch die Repr sentation v oder v blich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 278 Fachgebiet SE II Dynamische Programmanalysen und Testen Ech
209. r jeden Zustand alle sonst m glichen Ereignisse Methodenaufrufe ausgef hrt gew nschte Reaktion Ignorieren oder Programmabbruch oder Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 340 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Testplanung mit Transitionsbaum bergangsbaum aus Bi00 l das gegebene Statechart wird in einen flachen Automaten bersetzt 2 Transitionen mit komplexen Boole schen Bedingungen werden in mehrere Transitionen mit Konjunktion atomarer Bedingungen bersetzt Transition mit al amp amp a2 01 amp amp b2 wird ersetzt durch Transition mit al amp amp a2 und Transition mit b1 amp amp b2 ein Baum wird erzeugt der initialen Zustand als Wurzelknoten ersten obersten Knoten besitzt Zustandsknoten im Baum werden expandiert indem alle Transitionen zu anderen Zust nden und sich selbst als Kindknoten hinzugef gt werden gt jeder Zustand wird nur einmal als Knoten im Transitionsbaum expandiert jeder Pfad in dem Baum von Wurzel zu einem Blatt entspricht einer Testsequenz zus tzlich werden in jedem Zustand alle Ereignisse ausgel st die nicht im Transitionsbaum aufgef hrt sind spezifikationsverletzende Transitionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 341 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Flac
210. rch Festlegung aller ausw hlbaren Eigenschaften Merkmale Features der Instanzen der Produktlinie vor allem die optionalen alternativen Eigenschaften hierarchische Zerlegung von Merkmalen in Untermerkmale das Feature Dialog Sprache Englisch wird zerlegt in US Englisch Festlegung von Auswahl Optionen der Art eins aus n m aus n eine SPL Instanz l uft entweder auf Windows oder auf Unix Definition von Abh ngigkeiten und Ausschlusskriterien einzelner Merkmale in ganz verschiedenen Teilhierarchien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 102 Fachgebi A SE II Konfigurationsmanagement Echtzeit systeme Beispiel eines Variabilit tsmodells Assembler Assembler obligat optional optional Makro Pr pr lt Makro Pakete braucht genau eine Sprache muss Fa werden beliebig viele Pakete k nnen gew hlt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 103 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Werkzeugunterst tzung f r SPL Entwicklung grafische Erstellung von Variabilit tsmodellen Unterst tzung bei der Auswahl erlaubter Merkmalkombinationen Erzeugung von Produktinstanzen Implementierungen f r bestimmte Merkmalkombinationen Unterst tzung beim systematischen Tes
211. rden unterschieden und sp ter beim Testen unterschiedlich behandelt gt Konstruktoren und Destruktoren die Objekt erzeugen bzw l schen beobachtende Methoden Observer die Objektzustand nicht ndern ver ndernde Methoden Modifier es werden sogenannte Invarianten Invariants aufgeschriebenen die nach bzw vor Ausf hrung aller Methoden immer gelten m ssen Invarianten k nnen durch Observer nicht zerst rt werden Invarianten m ssen am Ende des Codes eines Konstruktors gelten Invarianten gelten vor Aufruf eines Modifiers und m ssen am Ende des Codes eines Modifiers wieder gelten f r Observer Modifier und Destruktoren k nnen Vorbedingungen Preconditions angegeben werden die bei Aufruf zus tzlich zu Invarianten gelten f r Konstruktoren Modifier und Observer k nnen Nachbedingungen Postcon ditions angegeben werden die nach Ausf hrung zus tzlich zu Invarianten gelten Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 327 Fachgebiet z 5 SE II Dynamische Programmanalysen und Testen Echtzeit Implementierung der Ampelsteuerung in C class TrafficLight public invariant isOff isGreen isYellow isRed invariant isOff amp amp isGreen isYellow isRed Konstruktoren und Destruktoren TrafficLight TrafficLight ffentliche beobachtende Operationen Observer bool isGreen
212. recht werden U Kombination von einem kontrollflussbasierten und einem datenflussbasierten berdeckungskriterium sinnvoll man w hlt nach beliebiger Methodik initiale Menge von Testf llen aus siehe etwa Abschnitt 4 3 ber funktionsorientierte Testverfahren dann wird berpr ft zu wieviel Prozent die gew hlten Kriterien erf llt sind Prozentsatz ausgef hrter Anweisungen beim C Test Prozentsatz getesteter Definitionsstellen beim all defs Kriterium gt es werden solange Testf lle hinzugef gt bis eine vorab festgelegte Prozentzahl f r alle gew hlten berdeckunsskriterien erf llt ist 90 oder Achtung 100 l sst sich in vielen F llen nicht erreichen wegen Anomalien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 320 Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit systeme 4 6 Testen objektorientierter Programme Zustandsbezogenes Testen Prinzipiell lassen sich in objektorientierten Sprachen geschriebene Programme wie alle anderen Programme testen Allerdings gibt es einige Besonderheiten die das Testen sowohl erschweren als auch erleichtern k nnen die Datenkapselung konzentriert Zugriffsoperationen auf Daten an einer Stelle und erleichtert damit das Testen Einbau von Konsistenzpr fungen amp die Datenkapselung erschwert das Schreiben von Testtreibern die auf interne Zust nde von Objekten zugreifen m ssen die Vererbung
213. rtung und Re Engineering Echtzeit systeme Beschreibung der einzelnen Phasen des V Modells Systemanforderungsanalyse Gesamtsystem einschlie lich aller Nicht DV Kom ponenten wird beschrieben fachliche Anforderungen und Risikoanalyse Systementwurf System wird in technische Komponenten Subsysteme zerlegt also die Grobarchitektur des Systems definiert Softwareanforderungsanalyse technischen Anforderungen an die bereits identi fizierten Komponenten werden definiert Softwaregrobentwurf Softwarearchitektur wird bis auf Modulebene festgelegt Softwarefeinentwurf Details einzelner Module werden festgelegt Softwareimplementierung wie beim Wasserfallmodell inklusive Modultest Software Systemintegration schrittweise Integration und Test der verschiede nen Systemanteile berleitung in die Nutzung entspricht Auslieferung bei Wasserfallmodell Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 45 SE II Software Entwicklung Wartung und Re Engineering Echizeit gt 2 1 4 Forward Reverse und Reengineering Beim Forward Engineering ist das fertige Softwaresystem das Ergebnis des Entwicklungsprozesses Ausgehend von Anforderungsanalyse Machbarkeitsstudie wird ein neues Softwaresystem entwickelt Anforderungen Design Code gt Anforderungs und Design Dokumente f r Code existieren hoffentlich alle Dokumente sind da voneinander abgeleitet noch konsistent au
214. s lt source gt mit allen Unterverzeichnissen und Dateien gt und wendet die nderungen auf die Dateien im aktuellen Workspace Verzeichnis ggf angegeben durch lt wcpath gt Working Copy Path an gt ge ndert werden dabei einzelne Dateien und ganze Unter Verzeichnisse Variante des merge Kommandos svn merge lt srce1 gt lt snapshot1 gt lt src2 gt lt snapshot2 gt lt wcpath gt Dieses Kommando wendet das Delta zweier verschiedener Dateien oder Unterverzeichnisse vorgegebener Revisionen durch Snapshot Nummer auf den aktuellen Workspace an Wird keine Revision angegeben so wird jeweils die neueste Revision Head verwendet Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 95 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme Beispiele f r Verwendung von merge Anwendung aus Sicht von Wartungszweig 1 propagate changes merge r 3 4 myproject branches b1 wcpath gt propagiert alle nderungen von Revision 3 auf Revision 4 des Wartungs zweiges in die ausgecheckte Working Copy des Hauptzweiges oder eines anderen Wartungszweiges gt die neue Revision des Hauptzweiges kann anschlie end als Snapshot 7 eingecheckt werden Anwendung aus Sicht von Wartungszweig 1 undo changes merge r 4 3 myproject branches b1 wcpath gt eliminiert alle propagierten nderungen aus Wartungszweig 1 wieder durch Berechnung und A
215. s Programm selbst Implementierung eines Algorithmus wird visualisiert Struktur versus Verhalten Struktur Aufbau von Algorithmus oder Programm wird visualisiert gt Verhalten Ablauf eines Algorithmus oder Programms wird visualisiert U statisch versus dynamisch statisch ein Bild Diagramm wird zur Visualisierung verwendet gt dynamisch Bildsequenz Film wird zur Visualisierung eingesetzt Programmvisualisierung versus visuelles Programmieren Modellieren Programmvisualisierung Programm wird grafisch dargestellt gt visuelles Programmieren es wird grafisch programmiert modelliert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 166 Fachgebiet SE II Statische Programmanalyse amp Metriken Echtzeit Dynamische Algorithmenvisualisierung Beispiel E Heapsot OOO M By 1 2 amp 4 5 6 7 8 9 History List Max at A 1 12 Select A 1 12 and A 2 5 Max at A 1 12 Exchange A 0 12 with A 1 9 Select A 1 9 and A 3 10 Dargestellt wird hier die Arbeitsweise des Sortieralgorithmus Heapsort nicht mehr verf gbare Implementierung der TU Wien Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 167 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Statische Visualisierung von Programmstruktur mit CrocoCosmos amp Programmlogik klassen grafische Darstellung eines
216. s c muss neu in messages o bersetzt werden cc c messages c Hauptprogramm assembler muss neu aus allen o Dateien erzeugt werden cc o assemb assemb o pass0 o pass1 o pass2 o messages o files o Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 117 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme bersetzungs und Bindevorg nge Beispiel 2 assembler c Modul h Datei c Datei M1 M2 Importbeziehung pass0 h amp c pass1 h amp c pass2 h amp c M1 c Datei includes Pa M2 h Datei messages h amp c symbtab h amp c Schnittstelle Typdefinition von messages messages h ndert sich ggf muss man auch messages c ndern messages c muss neu in messages o bersetzt werden CC c messages c pass0 c passi c und pass2 c m ssen neu bersetzt werden cc c pass0 c cc c passi c cc c pass2 c Hauptprogramm assembler muss neu aus allen o Dateien erzeugt werden cc o assemb assemb o pass0 o pass1 o pass2 o messages o files o Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 118 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme bersetzungs und Bindevorg nge Beispiel 3 assembler c Modul h Datei c Datei M1 M2 Importbeziehung pass0 h amp c pass1 h amp c pass2 h a
217. se der Pr fling Programm Modell Dokumentation wird von Menschen oder Werkzeugen auf Vorhandensein Abwesenheit von Eigenschaften untersucht Inspektion Review Walkthrough organisiertes Durchlesen in Gruppe statische Analyse werkzeuggest tzte Ermittlung von Anomalien Verifikation werkzeuggest tzter Beweis von Eigenschaften testende Verfahren dynamische Programmanalyse der Pr fling wird mit konkreten oder abstrakten Eingabewerten von Menschen oder Werkzeugen ausgef hrt dynamischer Test Simulation Ausf hrung mit konkreten Eingaben symbolischer Test Interpretation mit symbolischen Eingaben die oft unendliche Mengen m glicher konkreter Eingaben repr sentieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 155 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Arten der statischen Programmanalyse 1 Q Visualisierung von Programmstrukturen un sthetisches Layout liefert Hinweise auf sanierungsbed rftige Teilsysteme siehe Abschnitt 3 2 ber Softwarearchitekturen und Visualisierung manuelle Inspektionsverfahren organisiertes Durchlesen u Diskutieren von Entwicklungsdokumenten auch Audit genannt ggf mit Werkzeugunterst tzung siehe Abschnitt 3 3 ber manuelle Inspektionsverfahren Compilerpr fungen Syntaxpr fungen Typpr fungen sollten hinreichend bekannt se
218. ssages o symbtab o files o make cleanup l scht immer o Dateien da Datei cleanup nicht existiert Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 125 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Besseres Makefile mit selbstdefinierten Makros CC cc Aufruf des C Compilers CFLAGS c Flag f r Ubersetzung LD cc Name des Binders hier in C Compiler integriert LDFLAGS 0 Flags f r Binden DEBUG Debugoption deaktiviert Aktivierung als g assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files o LD DEBUG LDFLAGS assembler assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files o assembler o assembler c global h passO h pass1 h pass2 h pass3 h CC DEBUG ICFLAGS assembler c Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 126 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme A Weniger redundantes Makefile mit sogenannten internen Makros assembler o pass0 o pass1 o pass2 o pass3 o messages o symbtab o files o LD DEBUG LDFLAGS assembler o c global h passO h pass1 h pass2 h pass3 h CC DEBUG CFLAGS c Erl uterung der seltsamen Sonderzeichen Makros bezeichnet immer das Ziel einer Regel mit Suffix z B o oder c bezeichnet immer das Ziel einer Regel ohne Suffix assembl
219. sten Echtzeit systeme Wie wird getestet U Funktionstest black box test die interne Struktur der Komponente wird nicht betrachtet getestet wird Ein Ausgabeverhalten gegen Spezifikation siehe Abschnitt 4 3 Strukturtest white box test interne Struktur der Komponente wird zur Testplanung und berwachung herangezogen Kontrollflussgraph siehe Abschnitt 4 4 Datenflussgraph siehe Abschnitt 4 5 Automaten siehe Abschnitt 4 6 Diversifikationstest Verhalten einer Kompo nentenversion wird mit Verhalten anderer Kom ponentenversionen verglichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 253 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Diversifikationstestverfahren Das Verhalten verschiedener Varianten eines Programms wird verglichen Q Mutationstestverfahren ein Programm wird absichtlich durch Transformationen ver ndert und damit in aller Regel mit Fehlern versehen Einbau von Fehlern l sst sich mehr oder weniger automatisieren eingebaute Fehler entsprechen oft nicht tats chlich gemachten Fehlern eingebaute Fehler st ren Suche nach echten Fehlern N Versionen Programmierung verschiedene Versionen eines Programms wer den v llig unabh ngig voneinander entwickelt sehr aufw ndig da man mehrere Entwicklerteams braucht und gegebenfalls sogar Hardware mehrfach beschaffen mu Fehler der verschiedenen Teams nicht
220. stmethodik ist die Beschreibung von sogenannten Anwendungsf llen Nutzungsszenarien Gesch ftsvorf llen eines Systems im Zuge der Anforderungsanalyse Dabei kommt in der Regel die Unified Modeling Language UML mit ihren Anwendungsfalldiagrammen zum Einsatz siehe etwa Vorlesung Software Engineering Einf hrung Q Anwendungsfalldiagramme erlauben die Beschreibung von Nutzungsszenarien und damit von Akzeptanztestf llen auf sehr hohem Abstraktionsniveau sowie die Unterscheidung zwischen normalen Abl ufen und Ausnahmen U Werden einzelne Anwendungsf lle informell in nat rlicher Sprache beschrieben so werden die dazugeh rigen Testf lle manuell erstellt U Werden f r die Beschreibung einzelner Anwendungsf lle formalere Notationen wie Sequenz oder Aktivit tsdiagramme der UML eingesetzt so k nnen Testwerkzeuge daraus automatisch Code f r die Testfallausf hrung und bewertung generieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 294 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Anwendungsfalldiagramm Beispiel aus SL12 Geldausgabe einheit extension poin Kunde PIN Abfrage x S extend x Condition _ 3 falsche PIN Eingabe Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 295 i Fachgebiet 4 5 SE II Dynamische Programmanalysen und Testen Echtzeit Bew
221. t systeme In Literatur vorgeschlagene Z hlregeln f r Java Programme Arithmetische und logische Standardoperatoren I amp amp amp amp U Auch weitere Operatoren Sonderzeichen also Zuweisung Konkatenation von Anweisungen also Klammerungen in Ausdr cken gt gt gt Attributselektion gt gt Alle reservierten Java Schl sselw rter extern register static typedef virtual mutable inline break enum try abstract implements extends U Definitionen von Methoden und Funktionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 224 Fachgebiet 5 SE II Statische Programmanalyse amp Metriken Echtzeit Halstead Metriken Definition 1 Berechnete Programml nge L n log n 1 109 n2 h ngt also nur von Anzahl verwendeter Operatoren und Operanden ab postuliert wird dass man mit einer festen Anzahl von Operatoren und Operanden immer Programme einer bestimmten logischen Gr e schreibt Programmgr e V N log n Programme Volume optimale Codierung des Programms als Bitvektor Bewertung Es gibt eine ganze Reihe weiterer Halstead Metriken die versuchen zu bewerten Schwierigkeit der Erstellung eines Programms Ad quatheit einer bestimmten Programmiersprache f r Problemstellung Aufwand f r Erstellung eines Programms Nutzen dieser Metriken ist stark umstritten Prof Dr A
222. t Compound Members File Members E Main Page ZI File List my Anotate cpp File Reference m m m je SE FE sj E Bus cpp include stdafx h a ChildFrm cpp include TinyCadView h z 3 include diag h E ChildFrm h include colour h include option h D a O 5 a 5 g o o 5 Include dependency graph for Anotate cpp m 2 o eo R R an g a context h object h m TinyCadDoc h rulerh library h EditToolBar h _ option h m yyy 135 ma a BEE 7DE SsHr P o m B editbar cpp mi fo Fine fo fo fo Fre fo fo Fin fsa amp a k h S stdafx h TinyCadView h m y m amp fer 5 5 5 i E help cpp E Io cpp E Item cpp w fm Fa Anotate cpp gn M 8 E Layer h Defines E Libdiag cpp gs 5 fs 3 3 s define theArea CRect a x ay b x b y y 4 AsL ITNNNNETTT m start outlook He E Microsoft P amp windows T C Freeware Ep htmi 3 intern W unbenannt BE oomp 29 he G 1 6 m mi fm fo Fan m j E 5 3 m Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 171 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Programmvisualisierung mit Doxygen generierte Dokumentation a TinycAD Microsoft Internet ExplorerTTTVVTTTTTTTTTUUV T T
223. t anderen Iterationen berlappen d rfen das gew nschte Ergebnis Software Release einer Iteration ist sp testens bei ihrem Beginn festgelegt oft Abh ngigkeit von Ergebnissen vorheriger Iterationen die geplante Zeit f r eine Iteration wird nie h chstens um 50 berschritten innerhalb der Konstruktionsphase wird mindestens im w chentlichen Abstand ein internes Software Release erstellt mindestens 40 Reserve an Projektlaufzeit f r unbekannte Anforderungen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 370 SE II Management der Software Entwicklung a systeme Arbeitsbereiche Workflows im RUP vr Understand x Identify js SAPADA Realize Accepted Business Case i Solution Solution Workflows Business Modeling Requirements ei v b zu Implementation mn N Four Test E e Iteration Deployment wa Types Analysis amp Design Configuration _ amp Change Mgmt Project Management H Environment Be Bee One 6 i f Ea ea Iteration rS Iteratic v oO ws y En O oO n http www rational net rupcenter siehe RUP Resource Center Time nal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 371 i Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Anmerkungen zu den Arbeitsbereichen Workflows des RUP Business Modeling befasst sich damit das Umfeld des zu erstellend
224. t der Gesamtlaufzeit wird mit Ausf hrung einer bestimmten Operation verbracht ggf aufgeteilt nach callers und descendants E Nutzen der ermittelten Daten Operationen die am meisten Laufzeit in Anspruch nehmen k nnen leicht identifiziert und optimiert werden tats chliche Aufrufabh ngigkeiten werden sofort sichtbar Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 270 SE II Dynamische Programmanalysen und Testen Echtzeit y g y systeme Laufzeitanalyse mit Quantify Rational IBM su ala Sue ales als e BS DA Meran om z T pral projects nyed ter pebug ug een A Run 17 4 2003 16 27 08 ao ion lime 1243 7B 035 ef Focus 11453371 6 39 39 of Focus 34423 61 35 247 84 Clscahprojszte umycadierc Debug Tirylscexe CAacalprajacte imrcadcherc Partopp Line ind UedeleWinder Dialog DaoModa Carte Pixel Transfomsrap rap CTrytadbos Ge PagsBsundies CTpledvVen Getlocumer Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 271 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme Erl uterungen zu Quantify Beispiel untersucht wird die Methode Operation Funktion OnDraw im untersuchten Testlauf wurde OnDraw 53 mal aufgerufen die Ausf hrung der Methode OnDraw inklusive gerufener Methoden braucht 39 der Gesamtlaufzeit der Code der Methode OnDraw selbst ben
225. t von SPLs E Beispiel Werkzeug Weit verbreitet zumindest im deutschen Sprachraum ist das Werkzeug pure variants der Firma pure systems siehe http www pure systems com Es benutzt eine andere grafische Darstellung von Featuremodellen als das vorgestellte Variabilit tsmodell Anmerkung es gibt dutzende verschiedene Notationen die alle mehr oder weniger quivalent von ihrer Ausdruckskraft her sind Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 104 SE II Konfigurationsmanagement Echtzeit systeme Das Produktlinienverwaltungswerkzeug pure variants Eile Edit Navigate Search Project Run Window Help A Heig avid ex Fall Fe Variant Projects XA gt B Simple Car Example ur Sample Config Space with Transfc 2 Sample Config Space with Traf Ebyn H P Safety Functions E E Brakes ea ben tigt 3 Gear Box amp Feature 1 HE Outline 22 N Visualization 2 Label E car eu oder m aus n Brake Engine Gea Front Gear Box Count Gears Rear 4 X oder 1 aus n Diesel Disc Disc Drum Drum 9988 tette Electric 13 Detail g Graph Constraints Electrohydraulic E Properties 23 _Tasks Problems Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechni
226. t zu werden Fachgebiet Echtzeit systeme Nstart Nwhile n gt 0 Nif m gt n No N Nm m n Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 197 SE II Statische Programmanalyse amp Metriken Defined Undefined Datenflussanomalie Eine du Datenflussanomalie bez glich einer Variable v ist wie folgt definiert es gibt einen segmentfreien Pfad n ny n hat Attribut d v v erh lt also einen definierten Wert bei n n Ng hat nicht Attribut rldlu v v wird also bis n nicht verwendet n hat Attribut u v v wird also auf undefiniert gesetzt Beispiel f r du Datenflussanomalie Aufruf von ggT mitm 2 n 2 bei nn o erh lt m definierten Wert der nie mehr referenziert wird Fachgebiet Echtzeit systeme Nstart Nwhile n gt 0 Nftm gt n No N Nm m n Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 198 Fachgebi amp SE II Statische Programmanalyse amp Metriken Echtzeit systeme Korrektur des Programms mit Datenflussanomalien geht das PROCEDURE ggT IN m n INTEGER OUT o INTEGER BEGIN Nstart WHILE n gt 0 DO Nwhile n gt 0 IF m gt n THEN Ntm gt n dd f r o du f r m n m m 0 urf ro du f r m END endif END ggT final ur f r o Prof Dr Andy Sch
227. technik Seite 323 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Prinzipien beim Test einzelner Klassen 2 3 Quasi modale Klasse Zustand der Objekte bestimmt zul ssige Reihenfolge von Methodenaufrufen und nur dieser gt Methoden werden isoliert getestet aber f r alle zu unterscheidenden quivalenzklassen des internen Objektzustandes Automaten mit Objekt zust nden werden zur Testplanung herangezogen Beispiel Ger testeuerung mit setStatus Methode und getStatus Methode die nur 100 000 Status Wechsel zul sst und dann den Dienst verweigert nach Wartung verlangt Modale Klasse Methoden k nnen nur in fest vorgegebenen Reihenfolgen aufge rufen werden zus tzlich hat Objektzustand Einfluss auf Zul ssigkeit von Aufrufen Kombination der Testmethoden f r uni modale und quasi modale Klassen notwendig Testplanung mit Automaten Beispiel Ger testeuerung mit init setStatus und getStatus Methode mit zus tzlicher Beschr nkung auf 100 000 Status Wechsel Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 324 SE II Dynamische Programmanalysen und Testen Fachgebiet A Echtzeit 1 systeme Tabellarische bersicht ber verschiedene Arten von Klassen beim Testen Zustand bestimmt nicht Methodenaufrufbarkeit Zustand bestimmt Methodenaufrufbarkeit Aufrufreihenfolge der Methoden flexibel nicht modal Methoden isoliert teste
228. technik Seite 407 Fachgebiet SE II Management der Software Entwicklung Echtzeit C gt Balkendiagramm Gantt Chart 1917 von Henry Gantt erfunden Idee 14 4 03 28 4 03 5 5 03 19 5 03 2 6 03 16 6 03 30 6 03 11 7 03 1 Analyse 2 Design E 3 1 DB Schema E 3 2 DB Updates 3 3 DB Queries 3 4 Listen 3 5 Benutzeroberfl che 5 1 Manual 5 2 Online Hilfe 4 Integration Systemtest 6 Abnahme Zeitraum f r Paketbearbeitung E F Nettozeit Pufferzeit float Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 408 SE II Management der Software Entwicklung Eentzeit gt s 2 Balkendiagramm mit Personalplanung 14 4 03 28 4 03 5 5 03 19 5 03 2 6 03 16 6 03 30 6 03 11 7 03 Valerie Design DB Schema Listen DB Updates Integration verantwort 50 50 lich f r alle TA Phasen 50 50 Edeltraud Manual Online Hilfe i Nettozeit O Achtung Durch Ressourcenzuteilung entstehen zus tzliche Zeit Pufferzeit I EB i float restriktionen z B Listen nach DB Schema Abnahme Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 409 SE II Management der Software Entwicklung Echizeit gt 2 5 6 Weitere Literatur ACF97 V Ambriola R Conradi A Fugetta Assessing Process Centered Software Engineering Environments ACM TOSEM Vol 6 No 3 ACM Press 1997
229. tegration Software Wartung Support Bereich Qualit tssicherung gt Management Bereich Projekt Management gt Organisations Bereich Prozess Verbesserung gt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 390 SE II Management der Software Entwicklung Eentzeit gt 2 CMMI Capability Maturity Model Integration neue Version von CMM CMMI ist die neue Version des Software Capability Maturity Model Es ersetzt nicht nur verschiedene Qualit ts Modelle f r unterschiedliche Entwicklungs Diszipli nen z B f r Software Entwicklung oder System Entwicklung sondern integriert diese in einem neuen modularen Modell Dieses modulare Konzept erm glicht zum einen die Integration weiterer Entwicklungs Disziplinen z B Hardware Entwick lung und zum anderen auch die Anwendung des Qualit tsmodells in bergreifenden Disziplinen z B Entwicklung von Chips mit Software Geschichte von CMM und CMMI gt 1991 wird Capability Maturity Model 1 0 herausgegeben 1993 wird CMM berarbeitet und in der Version 1 1 bereitgestellt 1997 wird CMM 2 0 kurz vor Verabschiedung vom DoD zur ckgezogen 2000 wird CMMI als Pilotversion 1 0 herausgegeben 2002 wird CMMI freigegeben Ende 2003 ist die Unterst tzung CMM ausgelaufen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 391 SE II Management der Software Entwicklung a systeme Eigenschaften von
230. testet inkrementelles Testen mit Regressionstests unter Verwendung von Frameworks wie JUnit http www junit org siehe Softwarepraktikum Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 322 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Prinzipien beim Test einzelner Klassen 1 Es werden in B100 vier verschiedene Arten von Klassen unterschieden 1 Nicht modale Klassen Methoden der Klasse k nnen immer zu beliebigen Zeit punkten aufgerufen werden interner Zustand der Objekte spielt dabei keine Rolle gt Methoden k nnen isoliert f r sich getestet werden bei der Auswahl der Testf lle muss Objektzustand nicht mit ber cksichtigt werden Beispiel Ger testeuerung mit setStatus Methode u getStatus Methode die Zustand liefert Beispiel ist Grenzfall besser Klasse ohne Attribute Uni modale Klasse Methoden k nnen nur unabh ngig vom internen Zustand der Objekte in einer bestimmten Reihenfolge aufgerufen werden warum Testf lle m ssen alle zul ssigen und nicht zul ssigen Reihenfolgen von Methodenaufrufen durchprobieren interne Objektzust nde nicht relevant Automaten mit zul ssigen Methodenaufrufen als Transitionen werden zur Testplanung herangezogen Beispiel Ger testeuerung mit init setStatus und getStatus Methoden init Methode muss zuerst aufgerufen werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Daten
231. tion des Automaten hat eine Bedingung W chter zus tzlich zu den Zust nden gibt es keine Vorbedingungen an Methoden U Modale Klasse der Zustandsautomat der Klasse besteht aus mehreren Zust nden gt mindestens eine Transition des Automaten hat eine Bedingung W chter zus tzlich zu den Zust nden gibt es Vorbedingungen an Methoden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 339 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit systeme y Definition von Test berdeckungsmetriken f r Statecharts U Tests m ssen garantieren dass alle Zust nde mindestens einmal erreicht werden entspricht Anweisungs berdeckung aus Abschnitt 4 4 U Tests m ssen garantieren dass jede Transition mindestens einmal ausgef hrt wird entspricht Zweig berdeckung aus Abschnitt 4 4 nachdem hierarchisches Sta techart in flachen Automaten bersetzt wurde siehe SW Eng Einf hrung Tests m ssen garantieren dass jede Transition mit allen sich wesentlich unter scheidenden Belegungen ihrer Bedingung ausgef hrt wird entspricht modifizier tem Bedingungs berdeckungstest aus Abschnitt 4 4 Tests m ssen alle m glichen Pfade durch Statechart bis zu einer vorgegebenen L nge oder vorgegebenen Anzahl von Zyklen ausf hren entspricht eingeschr nk ten Varianten der Pfad berdeckung aus Abschnitt 4 4 zus tzlich zum Test aller explizit aufgef hrten Transitionen werden f
232. tionen setzen auf Schema auf und geben Ergebnisse in Listenform aus gt Update Operationen setzen auf Datenbankschema auf und sind unabh ngig von Anfrageoperationen die Realisierung der Benutzeroberfl che ist von der Datenbank entkoppelt f r den sinnvollen Modultest der Operationen braucht man aber die Oberfl che um das Beispiel nicht zu kompliziert zu gestalten wird das Wasserfallmodell mit Integration der einzelnen Teilsysteme im Big Bang Testverfahren verwendet gedruckte Manuale und Online Hilfe enthalten Screendumps der Benutzer oberfl che teilweise parallele Bearbeitung trotzdem m glich Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 398 SE II Management der Software Entwicklung a systeme Aufteilung des MVRS Projekts in Arbeitspakete Aufgaben MVRS 1 Anal a pedi 3 Codierung 4 Integration Een N zesign Modultest Systemtest FAONAAME 3 4 Listen 3 1 Datenbank 51M aufbau schema en 3 5 Benutzer 3 2 Anfrage 5 2 Online oberfl che operationen Hilfe 3 3 Update operationen Im obigen Bild fehlen noch die Angaben f r die gesch tzten Arbeitszeiten zur Bearbei tung der einzelnen Teilaufgaben des Motor Vehicle Reservation System Projekts Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 399 SE II Management der Software Entwicklung Organisation von Aufgaben mit MS Project WBS Arakse Deski C
233. tribute der n Dann ist attr s attr n attr n die Konkatenierung der Datenflussattributsequenzen von n bis n Ein Knoten n mit einer Sequenz von Datenflussattributen attr n attr attr ist immer eine abk rzende Schreibweise f r einen Pfad von Knoten n Nk sodass jeder Knoten n genau ein Datenflussattribut besitzt attr n attr U Allen folgenden Definitionen liegt immer ein segmentfreier Kontrollflussgraph zugrunde in dem jeder Knoten genau ein Datenflussattribut besitzt Beispiel f r Zusammenfassung Expansion von Kontrollflussgraphknoten M l p attr n i 1 r i attr ni N ir attr s ttr n dli r i d j r i d i d count a n attr Ncount 0 attr Ncount 0 d count Neount 0 d count count Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 185 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Werkzeug PMD Kontrollflussgraph mit Datenflussattributen tine Gen Nenodesl Dataflomtpes Type line Variable Method 4 u r W UR 4 12 r littleGauss DD 10 r littleGauss Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 186 SE II Statische Programmanalyse amp Metriken Echizeit gt 2 Inout Parameterdiskussion und Aufruf von Prozeduren Die meisten Programmiersprachen erlauben nicht die Auszeichnung von Variablen die reine
234. ts Prozentzahl der Klassen f r die das Attribut nicht sichtbar ist abgesehen von eigener Klasse Sind alle Attribute als private definiert dann ist AHF 1 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 233 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Weitere Metriken U Tiefe von Vererbungshierarchien zu tiefe Hierarchien werden un bersichtlich man weiss nicht mehr was man erbt Breite von Vererbungshierarchien zu breite Vererbungshierarchien deuten auf Fehlen von zusammenfassenden Klassen hin Anzahl Redefinitionen in einer Klassenhierarchie je mehr desto gef hrlicher Anzahl Zugriffe auf geerbte Attribute sind ebenfalls gef hrlich da beim ndern von Attributen oder Attributzugriffen in Oberklasse die Zugriffen in den Unterklassen oft vergessen werden Halstead Metriken Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 234 SE II Statische Programmanalyse amp Metriken Echtzeit systeme Komplexit tsma e Response For Class RFC die Anzahl der in der Klasse deklarierten Methoden die Anzahl der geerbten Methoden die Anzahl sichtbarer Methoden anderer Klassen Alle Methoden die aufgerufen werden k nnen Sehr schwammig definiert Weighted Methods Per Class WMPCD die Summe der zyklomatischen Zahlen ZZ aller Methoden der Klasse ohne geerbte Methoden Number of Remote M
235. tzeit Auswahl von Testdaten aus Eingabewerteklassen U aus jeder Eingabewerteklasse wird mindestens ein Wert ausgew hlt Fehler und Stressklassen werden sp ter gesondert behandelt U gew hlt werden meist nicht nur die Grenzen selbst sondern auch die um eins gr eren und kleineren Werte siehe ISTQB Pr fung im Folgenden werden aus Platzgr nden bei den Beispielen aber nur Grenzwerte selbst ausgew hlt als Intervalle dargestellte Eingabewerteklassen werden oft durch die so genannte Grenzwertanalyse nochmal in Unterklassen Teilintervalle zerlegt Juv ov wird zerlegt in inc uv Jinc uv dec ov dec ov uv ov wird zerlestin uv Juv ov ov inc uv liefert den n chstgr eren Wert zu uv dec ov liefert den n chstkleineren Wert zu ov Achtung bei Float muss f r inc und dec die gew nschte Genauigkeit festgelegt werden mit der aufeinanderfolgende Werte gew hlt werden Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 279 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit A Zus tzliche Wahl von Testdaten durch Grenzwertanalyse Bilden Eingabewerteklassen einen Bereich Intervall so selektiert die Grenzwert analyse also immer Werte um die Bereichsgrenzen herum gew hlt werden meist nicht nur die Grenzen selbst sondern auch die um eins gr eren und kleineren Werte im Folgenden aus Platzgr nden weggelassen U Idee dabei oft werden Sc
236. uch in den Zust nden in denen ihr Aufruf nicht zul ssig ist alle m glichen Zustands berg nge mit allen Kombinationen von Bedingungen an den berg ngen werden aktiviert zus tzlich werden die blichen Performanz Stress Tests durchgef hrt Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 348 Fachgebiet 5 SE II Dynamische Programmanalysen und Testen Echtzeit 4 7 Testmanagement und Testwerkzeuge Testen wird nach SL12 immer wie durchgef hrt U Testplanung es werden die zum Einsatz kommenden Methoden und Werkzeuge festgelegt Panun Spezifikation Testimplementierung die festgelegten Testf lle En werden automatisch ausf hrbar implementiert mA Durchf hrung Testdurchf hrung die ausgew hlten Testf lle wer den durch Werkzeuge automatisiert ausgef hrt Paa Protokollierung Testprotokollierung Testergebnisse werden proto kolliert sowie erreichte Test berdeckung ggf Aus er k uswertung wahl weiterer Testf lle notwendig U Testspezifikation die Testf lle werden entweder manuell oder durch Werkzeuge generiert festgelegt Testauswertung Bericht ber Reifegrad des Test objektes Testaufwand erreichter berdeckungsgrad ggf weiterer Testzyklus notwendig Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 349 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Aufgaben Qu
237. un Window Help BrHBis 0a BR Bor ih Nrmors Problems Javadoc Deciaration Hawk Metrics LI 1 System Details F Package Details Class Details AII Classes 39 All Methods 4 Save in CSV Format I Save in XML HTML Format Preferences type filter text v Demo version Only one of your classes will be analysed General Metrics Preferences Methods in class Filelnfo getOffset j io Filelnfo getTypeQ ijio Fileinfo toStringO j o Filelnfo getBytesPerPixel ijio File A COMP NOA NOC VDEC VREF NOS NEXP MON HLTH HVOC HVOL HDIF HEFF HBUG TDN CAST 16 12800 1 29 31 38147 250 95368 12 5019 500 25095 a 57325 250 143315 445859 43 1987 3 Method Package Method Name Exceptions Thrown Variables Declared Classes Referenced External Methods called Number of Expressions Number of Operands Number of Comments Max Depth of Nesting Number of Loops Halstead Bugs Halstead Effort Halstead Vocabulary Maintainability ijio Filelnfo v Method Class Arguments Exceptions Referenced Variables Referenced Local Methods called Casts Number of Statements Number of Operators Complexity Total Depth of Nesting No Logic Branch points Halstead Difficulty Halstead Length Halstead Volume Maintainability NC Filelnfo compression 1 Ant Help Install Update Java Metrics Preferences Plug in Development Run Debug Team
238. unden o Test Fertigstellung der Dokumentation Ergebnisse gt fertiges System gt Benutzerhandbuch gt technische Dokumentation gt Testprotokolle Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 37 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Auslieferung und Installation Die Auslieferung Installation und Inbetriebnahme der Software beim Kunden findet h ufig in zwei Phasen statt Aufgaben Auslieferung an ausgew hlte Pilot Benutzer Test Auslieferung an alle Benutzer Schulung der Benutzer Ergebnisse fertiges System Akzeptanztestdokument Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 38 SE II Software Entwicklung Wartung und Re Engineering Echtzeit t systeme Wartung Maintenance Nach der ersten Auslieferung der Software an die Kunden beginnt das Elend der Software Wartung das ca 60 der gesamten Software Kosten ausmacht Aufgaben m ca 20 Fehler beheben corrective maintenance ca 20 Anpassungen durchf hren adaptive maintenance ca 50 Verbesserungen vornehmen perfective maintenance Ergebnisse Software Problemberichte bug reports gt Software nderungsvorschl ge neue Software Versionen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 39 SE II Software Entw
239. ung von Fehlermeldungen und nderungsw nschen Feature Requests sowie Zuordnung zu Auslieferungsst nden Abschnitt 2 6 Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 59 i Fachgebi SE II Konfigurationsmanagement Echtzeit systeme Systementwicklung im V Modell zur Erinnerung siehe SE1 SE 1 System Anforderungs I amp __________ SE 9 berleitung in die analyse N Nutzung l 1 SE 2 System Entwurf lt SE 8 System Integration l 1 SE 3 SW HW Anforderungs gt analyse m SE 7 SW Integration SE 4 SW Grobentwurf SE 5 SW Feinentwurf 4 SE 6 SW Implementierung Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 60 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme a Integration des Konfigurationsmanagements im V Modell PM Projektmanagement Projekt planen und kontrollieren Plandaten Istdaten SEU QS Ergebnisse QS Anforderungen vorgeben O m gt 5 z O Q D pmi c 5 amp Produkte pr fen QS Qualit ts sicherung Softwareentwicklungsumgebung SEU bereitstellen Plandaten Istdat Istdaten Plandaten stdaten SEU Produktstruktur Produkte u Rechte verwalten Rechte KM Konfigurations SR management Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 61 i Fachgebiet SE II Konfigurationsmanagement Echtzeit
240. ungsszenario Haben wir das richtige Softwaresystem realisiert U Verifikation von Software Pr fung ob die Implementierung der Software die Anforderungen erf llt die vorab vertraglich festgelegt wurden Haben wir das Softwaresystem richtig realisiert Achtung Eine richtig realisierte korrekte Software erf llt die spezifizierten Anforderungen muss noch lange nicht das wirklich gew nschte Verhalten zeigen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 248 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Typische Programmiierfehler nach BP84 Berechnungsfehler Komponente berechnet falsche Funktion z B Konvertierungsfehler in Fortran bei Variablen die mit I J oder K anfangen und damit implizit als Integer deklariert sind Schnittstellenfehler Inkonsistenz bez glich erwarteter Funktionsweise zwischen Aufrufsstelle und Deklaration siehe vor allem Abschnitt 4 3 bergabe falscher Parameter Vertauschen von Parametern Verletzung der Randbedingungen unter denen aufgerufene Komponente funktioniert Q Kontrollflussfehler Ausf hrung eines falschen Programmpfades siehe vor allem Abschnitt 4 4 gt Vertauschung von Anweisungen gt falsche Kontrollbedingung z B kleiner statt kleiner gleich off by one Schleife wird einmal zuwenig oder zu oft durchlaufen Prof Dr Andy Sch rr
241. untersucht Inspektion Review Walkthrough organisiertes Durchlesen in Gruppe statische Analyse werkzeuggest tzte Ermittlung von Anomalien Verifikation werkzeuggest tzter Beweis von Eigenschaften testende Verfahren der Pr fling wird mit konkreten oder abstrakten Eingabewerten von Menschen oder Werkzeugen ausgef hrt dynamischer Test Simulation Ausf hrung mit konkreten Eingaben symbolischer Test Interpretation mit symbolischen Eingaben die oft unendliche Mengen m glicher konkreter Eingaben repr sentieren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 24 SE II Software Entwicklung Wartung und Re Engineering Echtzeit systeme Beispiel f r Wichtigkeit analytischer Qualit tssicherung Therac 25 Therao25 Unit Treatment Table Motion power swufbch Therapy room Room i intercom emergency i y 1 switch S di 2 Ty camera Turntable position monitor Control console Pine SR T Di monitor Room Motion enable Beam ontot light nee emergency switch ifo otswiteh BRITEN switches beplay terminal Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 25 SE II Software Entwicklung Wartung und Re Engineering Eentzeit gt 2 Therac 25 ein rein softwaregesteuertes Bestrahlungsger t Mindestens 6 Personen erhalten zwischen 1985 und 1987 gr tenteils t
242. werden und damit im Code festgelegte Reaktionen ausl sen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 335 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Makros f r die berpr fung von Invarianten in C ifdef DEBUG define ASSERT condition if condition lt raise exception or terminate program or print error message or gt nur im Debug Modus werden Zusicherungen berpr ft else define ASSERT condition endif define INVARIANT ASSERT invariant im Debug Modus wird als protected Methode jeder Klasse codierte Invariante berpr ft define POST condition ASSERT condition INVARIANT zus tzlich zu Nachbedingung wird Einhaltung der Invariante sichergestellt define PRE condition INVARIANT ASSERT condition Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 336 Fachgebi SE II Dynamische Programmanalysen und Testen Echtzeit systeme berpr fung von Invarianten in C class TrafficLight public Konstruktoren und Destruktoren TrafficLight INVARIANT E TrafficLight INVARIANT ffentliche ver ndernde Operationen Modifier void lightOn PRE isOff POST isRed k protected inline bool invariant const return bersetzer ruft inline Methode nicht auf s
243. wertklasse sich das Softwareprodukt gleich verh lt U Unterteilung in Klassen von Eingabewerten f r die das Programm sich laut Spezifikation gleich verhalten muss Alle Klassen von Eingabewerten zusammen m ssen den ganzen m glichen Eingabewertebereich des betrachteten Programms abdecken Aus jeder quivalenzklasse wird mindestens ein repr sentativer Wert getestet Unterteilung in g ltige und ung ltige Eingabewerte fehlerhafte Eingaben wird durchgef hrt und sp ter bei der Auswahl von Testwerten ber cksichtigt Oft gibt es auch eine gesonderte Betrachtung von quivalenzklassen f r besonders gro e oder besonders kleine g ltige Eingaben Stresstest Hier nicht mit betrachtet wird die Problematik der Suche nach Eingabewerte klassen die zu bestimmten Klassen von Ausgabewerten f hren Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 276 Fachgebiet SE II Dynamische Programmanalysen und Testen Echtzeit Regeln f r die Festlegung von Eingabewerteklassen f r geordnete Wertebereiche gt Juv ov ist ein offenes Intervall aller Werte zwischen uv und ov uv und ov selbst geh ren nicht dazu gt uv ov ist ein geschlossenes Intervall aller Werte zwischen uv und ov uv und ov selbst geh ren dazu gt Mischformen Juv ov und uv ov sind nat rlich erlaubt f r ganze Zahlen Integer Minint ov f r Intervalle mit kleinste
244. yse amp Metriken Echtzeit Arten der statischen Programmanalyse 2 Kontroll und Datenflussanalysen die Programmstruktur wird untersucht um potentielle Zugriffe auf undefinierte Variablen m glicherweise nie ausgef hrten Code etc zu entdecken siehe Abschnitt 3 4 Metriken Programmeigenschaften werden gemessen und als Zahl repr sentiert in der Hoffnung dass kausaler Zusammenhang zwischen Softwarequalit t z B Fehlerzahl und berechneter Ma zahl besteht siehe Abschnitt 3 5 Anmerkung In Abschnitt 3 5 mehr zur Bewertung von Metriken und Validierung von Hypothesen ber Zusammenhang von Softwarequalit t und Ma zahlen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 161 SE II Statische Programmanalyse amp Metriken Eentzeit gt 2 3 2 Softwarearchitekturen und visualisierung Gro e Systeme sind immer in Subsysteme gegliedert von denen jedes eine Anzahl von Diensten bereitstellt Der fundamentale Prozess zur Definition dieser Subsysteme und zur Errichtung eines Rahmenwerkes f r die Steuerung und Kommunikation dieser Subsysteme wird Entwurf der Architektur genannt S001 Begriffe nach Sommerville U Ein Softwaresystem besteht aus Teilsystemen die zusammengeh rige Gruppen von Diensten anbieten und m glichst unabh ngig voneinander realisiert sind Ein Teilsystem kann wiederum aus Teilsystemen aufgebaut werden die aus Moduln Paketen bestehen
245. ystematisches Hacking Kompromiss zwischen Wirklichkeit der Programment wicklung in vielen F llen und sehr aufw ndigen Vorgehensmodellen Betonung der menschlichen Komponente 40 Stunden Woche intensive Kommu nikation Pair Programming Empfehlungen f r Arbeitsumgebung systematisches evolution res Rapid Prototyping durch Testen und Refactoring Software Sanierung in kleinen Schritten versucht man Nachteile zu vermeiden Endprodukt besitzt ausser Kommentaren im Quellcode und Testf lle keine Dokumentation Entwicklung des ben tigten Gesamtsystems wird durch schnelle Produktion vieler kleiner Releases nicht unbedingt sehr zielgerichtet sein Grundannahmen z B leichte nderbarkeit des so erstellten Codes ber gesamte Projektlaufzeit hinweg nicht hinreichend empirisch belegt nur f r kleine Projekte in nicht sicherheitskritschen Anwendungsbereichen Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 377 Fachgebiet 4 5 SE II Management der Software Entwicklung Echtzeit Lineare Kostenkurve Wasserfallmodell XP Ansatz c c ab D D an C gt gt pa pa go go ec lt lt S S S S C 3 i O Xx X pe Analyse Design Impl Test Wartung 1 Release 2 Release 3 Release zeitlicher Projektverlauf zeitlicher Projektverlauf tats chlich vermutet Bei klassischen Projekten steigen die Kosten f r ge nderte Anforderung
246. zugeschnitten geographisch verteilte Softwareentwicklung wird besser unterst tzt Dateib ume und Dateien werden durch URL ss identifiziert Datenaustausch kann ber http Protokoll erfolgen Ungew hnliche aber einfache effiziente Behandlung von mehreren Entwicklungs zweigen sowie von Systemrevisionen mit bestimmten Eigenschaften Tags als lazy Copies keine echten Kopien sondern nur neue Verweise Links Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 93 SE II Konfigurationsmanagement Beispielszenario in Subversion nderung Hauptzweig Dateibaum myproject trunk Eee e ea ee ee E z o NO n Anderun 3 y Snapshot 5 15 Branch aufgegeben mit delete myproject branches b1 ler 2 ZUFEEKPFOBAgIaN nn een ee mit merge Abfolge der Snapshots jeweils aller Unterverzeichnisse Fachgebiet Echtzeit 1 systeme Unterverzeichnisse Legende echte nderung nur virtuelle Kopie IN 73 N _ Prof Dr Andy Sch rr TU Darmstadt FB 18 Institut f r Datentechnik Seite 94 Fachgebiet 4 y SE II Konfigurationsmanagement Echtzeit A systeme s Einsatz von merge in Subversion svn merge r lt snapshot1 gt lt snapshot2 gt lt source gt lt wcpath gt Dieses Kommando berechnet alle Unterschiede zwischen lt snapshot1 gt und lt snapshot2 gt als Vorw rts bzw R ckw rtsdelta des Verzeichnisse

Download Pdf Manuals

Related Search

Related Contents

Job Aids for ADA Curb Ramp Evaluation and Design  Studer SBM-02 Manual Rev2e.cdr  Baby Bear children mobile phone User manual  DolphinTOUCH EN-1  MODULO R 726 - Leroy Somer  Placa de rede local sem fios Nokia C110/C111 Manual do utilizador  Philips C240P4QPYEW  Formulaire d`inscription à télécharger (PDF – 281.3 ko)  Philips SB7100    

Copyright © All rights reserved. Failed to retrieve file