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. 1. 2. 1. 3. 1. 4. 1. 5. Definitionen Anforderungsanalyse Modellierung Architektur Automotive Software Engineering • 2. Software-Qualität § § 2. 1 2. 2 2. 3 2. 4 Definitionen und Standards Funktionstest, Überdeckungsmaße Integrations-, Hi. L- und Abnahmetests 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 8. trainierter Moderator 9. Statistiken werden geführt Fagan, M. E. , Design and Code Inspections to Reduce Errors in Program Development. 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 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 Raster. Delegate; get. Background(); float my. Width; 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-totype 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. routine. X 48, Perform. Data. Function, Do. It, Handle. Stuff 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
Скачать презентацию Software-Engineering II Eingebettete Systeme Softwarequalität Projektmanagement Prof Dr
50d9712050888a97548131cdec29042e.ppt