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

1.2.2006
Ü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

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 2

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

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 3

Fagan’s 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
Fagan, M. E., Design and Code
8. trainierter Moderator Inspections to Reduce Errors in
Program Development.
9. Statistiken werden geführt IBM Systems Journal 15(3), 1976.

10. Inspektionsrate wird einhalten

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 4

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!
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 5
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?
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 6
• 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?
• …
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 7
• …
• 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?

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 8

Probleme mit Checklisten

• Umfangreiche Listen sind schwer im

Kopf zu behalten!!!
 Aufteilung auf mehrere Phasen
 Training / Einarbeitung
 Werkzeugunterstützung
 Preprocessing (z.B. Coding rules)

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 9

Pause

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 10

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
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 11
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

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 12

Beispiel: Java Code Conventions

http://java.sun.com/docs/codeconv
• 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
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 13
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

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 14

Beispiel: Corporate Coding Rules

http://www.abxsoft.com/rules.htm

2.8.1 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
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 15
Automatisch prüfbar!

// ---------- Rule 2.8.1 ----------

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

H. Schlingloff, Software-Engineering II 1.2.2006 Folie 16

How To Write Unmaintainable Code
Ensure a job for life ;-) Roedy Green, http://thc.org/root/phun/unmaintain.html

• 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.
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 17
Statische Analyse: Compiler

• Typkorrektheit
• Initialisierung von Variablen
• Programmflussgraph
 Unerreichbarer Code
 Unveränderliche Felder
 Konstante Terme und Bedingungen

• Feldgrenzenverletzung ?
• Nullzeiger-Dereferenzierung ?
• Synchronisationsfehler ?
H. Schlingloff, Software-Engineering II 1.2.2006 Folie 18