Human Complexity of Software CPRE 556 – Lecture 15 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Software Complexities Machine Centric Goal - optimize and scale the use of machine resources: CPU time, memory space Human Centric Goal - optimize and scale the use of human resources for developing high-quality software 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Two Scenarios Human complexity needs to be studied in the context of: Developing brand new software from scratch Maintaining and evolving exiting software. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Different Solutions Complementary approaches to address human complexity: Language centric – modular, object-oriented, aspect-oriented programming languages Process centric - IEEE/EIA 12207 Software Life Cycle, CMMI Tool centric – Integrated Development Environments (IDEs) like Eclipse or Visual Studio, model-based tools like Simulink, debugging tools, testing tools, and compilers. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Why tools are necessary Manual processes are error-prone and time consuming – we need to be able to automate tedious analysis and transformation tasks. Software has become a part of critical infrastructure – we need to be able to produce and maintain robust and reliable software at a reasonable cost. Reliance on documentation and developer’s knowledge are passive and unreliable information sources – we need to be able to extract on-demand and reliable information. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Defect Analysis We will use defect analysis as an illustration. The first line of defense – compilers. The second line of defense – testing. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Why compilers are not enough Compilers perform primarily syntactic analysis. Compilers can also perform a limited amount of semantics analyses called the static analyses. Bad news: The Rice-Myhill-Shapiro theorem (1953) implies that all interesting questions about the behavior of programs are undecidable. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Why is testing not enough Test plans are usually derived from specifications – defects are due to un-specified behaviors. Testing traverses one execution path at a time – defective paths may not be covered during the test runs. A brute-force coverage of all paths is not possible – the number execution paths is typically an astronomically large number. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Four Defect Models These models relate to a particular class of defects. Basic pattern: we require matching pairs and it is a defect if we do not have matches. We will consider four successively more difficult models of matching pair (MP) defects. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved First MP Defect Model Matching pairs are defined by a syntactic pattern. A program statement (or a block) can have different types of parentheses and there must be matching pairs of open and close parentheses with the LIFO property. These types of defects can be easily detected and analyzed by compilers. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Second Defect Model Matching pairs are defined with respect to the control flow. A program employs different types of functions and there must be matching pair of f and f -1 functions along each feasible execution path. The defect analysis must consider the control flow. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Control Flow Graphs A control flow graph (CFG) is a directed graph, in which nodes correspond to program points and edges represent possible flow of control. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Example: Program and its CFG 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved f E1 S2 Defective Path E3 E2 f -1 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Third Defect Model A program employs different types of functions each associated with a unique id. The id is assigned to one or more tokens which gets passed along different execution paths. There must be matching pair of f(id) and f -1 (id) functions using the same id along each feasible execution path. The defect analysis must take into account the control flow and the data flow of the program. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Fourth Defect Model Fourth Model: Same as the third model, but the program has disconnected (not linked by the control flow) execution paths and the functions f(id) and f -1 (id) may occur on disconnected paths. Concurrent and interrupt-driven processing involve disconnected execution paths. The defect analysis must take into account the control flow, the data flow and the disconnected execution paths of the program. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved f f -1 Shared pool of tokens E1 S2 f -1 disconnected execution path Not a defective Path 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Beyond Compilers Compilers deal with the first defect model. The remaining three defect models are beyond compilers. The remaining three defect models involve program analysis problems that are known to be intractable. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved Human Complexity The defect models that are beyond compilers are very difficult for humans too. Manual processing – tedious and time consuming, depends a lot on guesswork, prone to human errors. The limitations of compilers and the complexity of human processing are wide-spread problems that affect defect analysis and other areas of software engineering. Currently, human complexity is a serious limitation to improving software productivity and quality. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved New Tools New tools for program comprehension and transformation. Comprehension tools are needed for: Defect analysis, impact analysis, architectural analysis, debugging, and testing. Transformation tools are needed for: Platform migration, automated instrumentation for gathering runtime information typically for performance, accuracy, and test analysis. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved New Tools We will look at a new generation of tools that can go far beyond compilers. We will first study and experiment with a tool called C-vision. Experiments will include defect analysis and architecture extraction. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved A Tool Illustration CCG is an example of a tool for program comprehension. Generic call graphs are often so huge that they defeat the purpose of understanding. With the CCG tool, users can interactively filter the call graph to focus attention on their concerns and use CCG to understand and navigate through complex code. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved A CCG Example The networking code from the XINU OS is used as an example. The user specifies memory allocation and deallocation as the concern by identifying the corresponding functions. Three views illustrate how program comprehension is enabled by focusing on the concern: View I: Generic Call Graph (CG). View II: Concern-sensitive Call Graph (CCG) with behavior not relevant to the concern filtered out. View III: CCG after the exception handling behavior is filtered out. 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved View 1 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved View 2 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved

Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved View 3 11/27/2018 Lecture Notes – Copyright © 2006 S.C. Kothari All rights reserved