Compiler Design Spring 2018 5.0 Software design Thomas R. Gross - PowerPoint PPT Presentation

Compiler Design Spring 2018 5.0 Software design Thomas R. Gross Computer Science Department ETH Zurich, Switzerland 1

Outline § Code quality § What to do about it § Practical example 2

Code quality What is “quality”? § All exams have high quality. § § Student: Exam asks questions that check material on the handout. § Lecturer: Exam shows that students can apply material to new problem(s). § Dean (head of studies): The results follow normal distribution. § Provost: Successful students are great ambassadors for the college. § Teaching assistant: Exam was multiple choice (and therefore could be graded while watching soccer). 3

Quality § Need to identify dimensions § Need to define “low” and “high” marks § Without clarification vague § Near term goal: code reviews § By students § Of students’ code: Solution submitted for Homework 3 4

Quality § Near term goal: code reviews § Why? § Code reviews are common § Code reviews highly effective to improve software systems § Other techniques exist as well 5

Code quality § First focus: software system artifact § Source code § Documents § External characteristics of software system § Visible/noticeable by “user” § Internal characteristics of software system § Primarily of interest to developer § Other aspects: process, environment, … 6

External characteristics § Boundary to internal characteristics not always strict § Dimensions are not always mutually exclusive § Correctness: freedom from faults § Faults in specification § Faults in design § Faults in implementation § Faults in execution § Robustness: ability to handle invalid input § Useful error messages § May have to include handling of hardware faults 7

External characteristics (cont’d) § Usability § Serves its purpose § Adaptability: system can be used w/o modifications in other scenarios § Interoperates with other systems as designed/specified § Integrity: prohibit unauthorized/improper access 8

External characteristics (cont’d) § Traceability: completeness of access traces and/or logs § Accuracy: results acceptable with regard to quantitative input § Could be considered a correctness issue § Reliability: system performs under stated conditions 9

Internal characteristics § Flexibility: system can be modified (with little or no effort) to be used for unintended environments § Reusability: system can be used in another operating environment § Readability: source code can be understood 10

Readability § Numerous factors influence readability § Consistent style (formatting) § Use of white space § Use of indentation § Tools can help § Rules for names, naming conventions § Rules for comments § Use of language features § Choice of programming language(s) 11

Readability § Numerous factors influence readability § Use of assertions § Coding conventions § Size of functions § Use of exceptions § File (project) organization/directory structure 12

Readability à Understandability System structure § Reflects high-level design § Modularity § Coherence and cohesion § Number of interaction points with other modules § Number of parameters § Control flow § Use of exceptions § Control/data plane § 13

Understandability § Level required to comprehend system § Classes (structs, records) § Class hierarchies § Depth § Frameworks § Patterns 14

Internal characteristics (cont’d) § Maintainability: source code can be modified to address changing requirements § Improve performance § Improve usability § Address correctness and security problems § Correct defects as well as react to environment changes § Testability: Can you unit test the system? § How easy it is to verify that the system meets requirements 16

public void HandleStuff(CORP_DATA inputRec, int crntQtr, EMP_DATA empRec, double estimRevenue, double ytdRevenue, int screenX, int screenY, COLOR_TYPE newColor, COLOR_TYPE prevColor, Adapted from S. McConnell, Code Complete (2 nd Edition) StatusType status, int expenseType) { int i ; for ( i = 0; i < 100; i ++) { inputRec.revenue [ i ] = 0; inputRec.expense[i] = MASTER.corpExpense [crntQtr][i]; } MASTER.UpdateCorporateDatabase( empRec ); estimRevenue += ytdRevenue * 4.0 / (double) crntQtr; newColor.color = prevColor.color; status.result = Result.SUCCESS; if ( expenseType == 1) { for ( i = 0; i < 12; i ++) MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type1[i]; } else if ( expenseType == 2) { MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type2[i]; } else if ( expenseType == 3) MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type3[i]; 18 }

What’s wrong with this routine? Look at this example of Java code and find with your neighbor problems with it. You should be able to find at least 10 different problems. Take 5 minutes. 20

Comments § Internal/external characteristics may overlap § Correlated, not independent § Often no fixed rule on “good design” § Example: size of functions/methods § Example: number of method arguments § Texts to consider Steve McConnell: Code Complete: A Practical Handbook of Software Construction, § Microsoft Press, 2004. George A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our § 26 Capacity for Processing Information, Psychological Review, 1956, vol. 63, pp. 81-97

Software quality § Goal: design & implementation of software systems with desirable internal and external characteristics § Desirable: depends on context and objectives § Combinations of characteristics § Steps to ensure software quality § Identify quality dimensions § Set priorities § Allow (and discuss) tradeoffs § Establish objectives 27 § Establish ways to measure quality

Objectives § Many possible dimensions § Development time and cost § Code length § Memory usage § Execution speed § … 28

Quality assurance § Implicit and explicit quality assurance steps § Focus here on explicit steps § Guidelines for software construction § Software process § Follow process § Testing strategy § Informal reviews § Formal reviews § External audits 29

Informal reviews § Objective: catch errors early § Misuse of informal reviews § Assign blame § Staff evaluation § Budget control § Informal 30

Informal reviews (cont’d) § Kinds of informal reviews 1. Inspection § Reviewers look at code § Reviewers meet developers, ask questions (person-person interaction) 2. Walk-through § Presentation of system § Guide tour by developer(s) 3. Code reading § Feedback via comment, review § Usually done by co-developer 31

Informal reviews § Execution of system, test cases may be part of the review § Emphasis usually on understanding source code 32

Inspections § Participants with clearly defined roles § Some roles mutually exclusive 33

Roles § Moderator § Keeps review going § Must be technical person § Neither reviewer nor developer § Author § Developed software system under review § May start out review with an overview § May answer factual questions (if asked) § Explain parts § Does not defend decision § Do not argue 34 § Key is to listen, code should speak for itself

Roles (cont’d) § Reviewer(s) § Find problems § Identify defects § Find good features § Find good uses § Scribe § Takes notes § Record defects, problems § Not a reviewer § May also be moderator 35

Roles (cont’d) § Management: 36

Roles (cont’d) § Management: Absent from inspection § Inspection is for developers § Objective is not review of developer performance § Number of participants § At least three: author, reviewer, moderator § Moderator and scribe are the same person § Large groups more difficult to manage than small ones 40

Preparation § Planning § Code or design delivered to moderator § Moderator selects reviewer(s) § Setup § Overview by developer § Danger: developer “directs” reviewers § Preparation § Reading of code/design documents § Inspection meeting § Inspection report 41

Follow up § Reports state problems § Moderators assign defects for repair § May be manager maps requests to developers/authors § Another inspection § Depends on number and severity of defects § Keep logs, collect data § Number of defects § Size of software system § Length of meetings § Number of reviewers 42

Code inspection § Well-defined process § Even though process is informal § “Homework IV”: Participate in inspection process § Review other students’ code § Have your code reviewed § Details later (not today) § Process presented here: A possible way to organize reviews § Other processes used in practice § A case study: The OpenJDK review process 43

OpenJDK § Open Java Development Kit § Free and open-source implementation of the Java Platform § Java Platform § Java Class Library § E.g., packages like java.lang , java.io , java.math § (Static) Java compiler javac § Translate Java programs → bytecode instructions for Java Virtual Machine § HotSpot Java Virtual Machine § Just-in-time compilers C1 and C2 (translate bytecode → native code) § Interpreter (template-based) § Runtime system § Garbage collectors 44 § …