Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Folie 2 H. Schlingloff, Software-Engineering II Überblick 1. Eingebettete Systeme 1.1. Definitionen 1.2. Anforderungsanalyse 1.3. Modellierung 1.4. Architektur 1.5. Automotive Software Engineering 2. Software-Qualität 2.1 Definitionen und Standards 2.2 Funktionstest, Überdeckungsmaße 2.3 Integrations-, HiL- und Abnahmetests 2.4 Verifikation und Validierung 3. Projektmanagement 3.1 Qualitätsstandards (CMM/I, SPICE, ISO) 3.2 Aufwandsschätzung, Planungstechnik 3.3 Risikomanagement

Folie 3 H. Schlingloff, Software-Engineering II V&V: Peer Review Informelle QS-Methode sehr populär, sehr effektiv oft obligatorisch, vollständig! Ergänzung formaler Methoden Abgleich mit den ursprünglichen Zielen Aufzeigen von inhaltlichen (nichtformalen) Fehlern - z.B. intuitive Bedeutung versus textuelle Gestalt eines Identifiers Verbesserung von Lesbarkeit und Verständlichkeit Durchführungsmöglichkeiten Code Walkthrough (Fagan) Inspektion

Folie 4 H. Schlingloff, Software-Engineering II Fagans Inspektionsmethode 1. überall im Entwicklungsprozess 2. alle Arten von Fehlern 3. ohne big boss 4. mehrere Einzelschritte 5. Checklistenbasiert 6. max. 2 Stunden 7. Rollen werden zugewiesen 8. trainierter Moderator 9. Statistiken werden geführt 10. Inspektionsrate wird einhalten Fagan, M. E., Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal 15(3), 1976.

Folie 5 H. Schlingloff, Software-Engineering II Checklisten essenziell für die Vorbereitung des Reviews selbe Form, aber deutlich andere Schwerpunktsetzung als Codierrichtlinien sind vor Beginn der Entwicklung bekannt, werden den Reviewern bekannt gemacht dienen als Richtlinie bei der Durchführung des Reviews Kategorisierung der Defekte, Fokus auf Probleme mit hohen ökonomischen Auswirkungen!

Folie 6 H. Schlingloff, Software-Engineering II Checklisten für Codereviews Beispiel: Java Code Inspection Checklist von Christopher Fox Variable and Constant Declaration Defects 1.Are descriptive variable and constant names used in accord with naming conventions? 2.Are there variables with confusingly similar names? 3.Is every variable properly initialized? 4.Could any non-local variables be made local? 5.Are there literal constants that should be named constants? 6.Are there macros that should be constants? 7.Are there variables that should be constants?

Folie 7 H. Schlingloff, Software-Engineering II Function Definition Defects (FD) 8.Are descriptive function names used in accord with naming conventions? 9.Is every function parameter value checked before being used? 10.For every function: Does it return the correct value at every function return point? Class Definition Defects (CD) 11.Does each class have an appropriate constructor and destructor? 12.For each member of every class: Could access to the member be further restricted? 13.Do any derived classes have common members that should be in the base class? 14.Can the class inheritance hierarchy be simplified? …

Folie 8 H. Schlingloff, Software-Engineering II … Performance Defects 54.Can better data structures or more efficient algorithms be used? 55.Are logical tests arranged such that the often successful and inexpensive tests precede the more expensive and less frequently successful tests? 56.Can the cost of recomputing a value be reduced by computing it once and storing the results? 57.Is every result that is computed and stored actually used? 58.Can a computation be moved outside a loop? 59.Are there tests within a loop that do not need to be done? 60.Can a short loop be unrolled? 61.Are there two loops operating on the same data that can be combined into one?

Folie 9 H. Schlingloff, Software-Engineering II Probleme mit Checklisten Umfangreiche Listen sind schwer im Kopf zu behalten!!! Aufteilung auf mehrere Phasen Training / Einarbeitung Werkzeugunterstützung Preprocessing (z.B. Coding rules)

Folie 10 H. Schlingloff, Software-Engineering II Pause

Folie 11 H. Schlingloff, Software-Engineering II statische Analyse ohne semantische Konsequenzen Coding Rules Checker, Linker, … mit semantischer Bedeutung Range and Bounds Checker Pointer and Storage Allocation Race Condition Verifikationswerkzeuge Modellprüfer, Äquivalenzprüfung interaktive Beweisverfahren

Folie 12 H. Schlingloff, Software-Engineering II Coding Rules Ziel der Programmierung: Verständlichkeit 20% Erstellungs-, 80% Analyse-Aufwand keine Software wird nur vom Autor gepflegt Einschränkung der kreativen Freiheit Lesbarkeit wird durch starre Regeln verbessert für Auslieferung ist Intersubjektivität notwendig Portierbarkeit ist wesentlicher Aspekt verbindliche Vorgaben über die Nutzung von Programmiersprachen Sprachabhängig Firmenabhängig

Folie 13 H. Schlingloff, Software-Engineering II Beispiel: Java Code Conventions Namenskonventionen example.java, example.class interface RasterDelegate; getBackground(); float myWidth; static final int MIN_WIDTH = 4; Kommentarregeln z.B. Name, Version, Datum, Copyright z.B. wann soll kein Kommentar stehen Formatierungsanweisungen Zeilenumbruch, Einrückungsregeln, Leerzeichen eine Deklaration pro Zeile, am Blockanfang Format von Methodenköpfen Sample(int i, int j) { Format von Anweisungen if (condition) { Programmierstil

Folie 14 H. Schlingloff, Software-Engineering II Programmierstil Lokalitätsprinzip Don't make any instance or class variable public without good reason Avoid using an object to access a class (static) variable or method Numerical constants (literals) should not be coded directly Seiteneffekte Do not use embedded assignments in an attempt to improve run-time performance. This is the job of the compiler Use parentheses liberally in expressions involving mixed operators. Even if the operator precedence seems clear to you, it might not be to others Try to make the structure of your program match the intent

Folie 15 H. Schlingloff, Software-Engineering II Beispiel: Corporate Coding Rules Use typedef names rather than the basic C types (int, long, float, etc.) for data members Example: In a program dealing with money, use typedef float Money; Money salary, bonus; // Good rather than float salary, bonus; // Bad Justification: This rule follows the principle of data abstraction. Typedef names do not increase the type safety of the code, but they do improve its readability. Furthermore, if we decide at a later time that money should be an int or a double we only have to change the type definition, not search the code for all float declarations and then decide which ones represent money. Reference: Paragraph 4.21, XYZ C++ Guidelines

Folie 16 H. Schlingloff, Software-Engineering II Automatisch prüfbar! // Rule if ( dcl_member ) { if ( dcl_variable && dcl_base != DEFINED_TYPE ) { warn( 9281, "Declare %s using a typedef name, not a basic C type.", dcl_name() ); } Verschiedene Werkzeuge verfügbar Oftmals ad-hoc-Software

Folie 17 H. Schlingloff, Software-Engineering II How To Write Unmaintainable Code Ensure a job for life ;-) Roedy Green, Buy a copy of a baby naming book and you'll never be at a loss for variable names. Fred is a wonderful name, and easy to type. If you're looking for easy-to- type variable names, try asdf or qwert If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor. Further, nobody will be able to guess what they are for. If anyone even hints at breaking the tradition honoured since FØRTRAN of using i, j, and k for indexing variables, warn them about what the Spanish Inquisition did to heretics In naming functions and variables, make heavy use of abstract words like it, everything, data, handle, stuff, do, routine, perform and the digits e.g. routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method Choose variable names with irrelevant emotional connotation. e.g.: marypoppins = (superman + starship) / god; This confuses the reader because they have difficulty disassociating the emotional connotations of the words from the logic they're trying to think about.

Folie 18 H. Schlingloff, Software-Engineering II Statische Analyse: Compiler Typkorrektheit Initialisierung von Variablen Programmflussgraph Unerreichbarer Code Unveränderliche Felder Konstante Terme und Bedingungen Feldgrenzenverletzung ? Nullzeiger-Dereferenzierung ? Synchronisationsfehler ?