MWF 12.10-1.00, Howe hall 1220
|
Instructor Professor Suraj C. Kothari
|
Teaching Assistants
|
Contents
Aim:
The objective of the course is to learn about the real-world challenges of
maintaining and evolving large software.
Upon completion of this course, students will
have the ability to:
· Understand the Software Evolution and Maintenance terminology and taxonomy.
· Gather, analyze, organize, and communicate information about Software Evolution and Maintenance.
· Design and apply Software Evolution and Maintenance problem solving strategies.
· Evaluate and apply the tools for solving Software Evolution and Maintenance problems.
· Understand the basics of program analysis.
Lectures:
Meeting Times: M W F 12.10-1.00
Location: Howe Hall, Room 1220
The lectures will be interactive and discussion oriented. We will occasionally have slides but not very often. You are expected to write notes based on the lectures. You will need these notes to prepare for exams and homework. Regular attendance and participation in lectures is required. Instructor should be informed if you are going to miss a lecture.
Topics:
· Software Evolution and Maintenance: what it encompasses and why it is important
· Program comprehension and inspection techniques
· Efficient techniques for debugging, defect analysis, impact analysis, and architectural analysis
· Use of software analysis tools
· Metrics for maintainability and quality
Learning Activities:
· Assimilating new technical information and asking questions to advance your understanding.
· Working with examples of code - illustrative short examples as well as large real-world software.
· Collecting and organizing information on technical topics.
· Experimental studies with and without tools.
· Presentations by students.
References:
The material will be selected from research papers and reference books.
The website has a list of papers. The reference books are listed below.
1. Homework, includes code reading projects and technical presentations (60%)
2. Two exams, 20% each (40%)
· Grading will be pretty close to the scale with A: 91% and above, B:81% to 90%, and so on.
Academic Integrity
All your work (including the labs) should be done individually unless otherwise
specified. You are not allowed to use work done by others, or obtain the
answers directly in any form (such as from the web). If you have any
questions about what is allowed/not allowed, please contact the instructor or
the TAs.
Any cases of cheating will be dealt with the strictest possible measures
allowed by the university, please refer to the university
policies on academic dishonesty.
Disability
Students with disability should inform the instructor so that appropriate
arrangements can be made to help them.
Office hours
|
|
Hours |
Location |
|
Professor Kothari |
Tuesday: 11:10-12:00, Friday 1:10-2:00 |
3132 Coover Hall |
|
Week |
Day |
Lecture Topics |
HW/Project |
|
Week 1 |
M Aug 20 |
About Software Engineering: What are the hotspots where
companies spend money? What is being outsourced
and what is expected to be outsourced? |
|
|
W Aug 22 |
How do companies measure
productivity? – discussion of LOC What is software evolution and why is it important to study? - three viewpoints: one who will work a software engineer, one who will do research, |
||
|
F Aug 24 |
What are the various software evolution tasks? How and why program reading is important? |
||
|
Week 2 |
M Aug 27 |
Systematic
Debugging What are the different breeding grounds for software bugs? Two programs for debugging Homework activity: Debug the two programs |
|
|
W Aug 29 |
Students narrate their debugging experiences with their observations and conclusions. In the next couple of classes, we will generalize student’s experiences – what are the lessons learnt, their applicability, and practice. Essential Ingredients: · Domain knowledge, programming knowledge and their examples in the context of two programs. · Why does debugging take time? - long runtimes, necessity to do multiple runs. What else? What is Programming Knowledge? - We will continue to see more of it and how it is applicable. |
||
|
F Aug 31 |
· Tracing a single run can take a lot of effort because of the many possibilities fro setting break points. · Discussion of simple examples to show how to reduce the search space for tracing. · Discussion of a tool that colors exactly those lines of code relevant to a particular failure specified by line number and variable. · Terminology: failure –unexpected behavior that users observe, error – incorrect code that a developer has written, infection – propagation of incorrect behavior from error to failure. · Home Work: Students to read about the ddmin tool. |
||
|
Week 3 |
M Sep 3 |
Labor Day |
|
|
W Sep 5 |
|
||
|
F Sep 7 |
|
||
|
Week 4 |
M Sep 10 |
|
|
|
W Sep 12 |
|
||
|
F Sep 14 |
|
||
|
Week 5 |
M Sep 17 |
|
|
|
W Sep 19 |
|
||
|
F Sep 21 |
· Matching Pair (MP) problems as a generalization of the memory leak problem. Four types of MP problems: (a) the program block within which the matching pair must occur can predetermined syntactically – matching parentheses, (b) The matching pair could be across not only many program blocks, but it could span several functions and the matching has to occur on all possible execution paths – enable() and disable() functions to enable and disable interrupts, (c) Like the type (b), but the matching pair also involves a reference to a resource such as file, memory location etc. The matching pair must be with respect to the same reference. The references propagate through pointer variables which must also be tracked, (d) Like the type (c), but the matching pairs could be across concurrent execution paths and the references are communicated through shared dta structures. |
||
|
Week 6 |
M Sep 24 |
Demonstration of Understand C++ tool |
|
|
W Sep 26 |
· A complex memory leak problem involving multiple functions and passing of pointers through a data structure shared by concurrent execution paths where one path may do the memory allocation and another path may do the deallocation. · Memory allocation in the dswrite() function in XINU. |
||
|
F Sep 28 |
Tracking the C code to using the Understand C/C++ tool and gathering evidence to prove that the apparent memory leak in dswrite() is really not a memory leak. |
||
|
Week 7 |
M Oct 1 |
· Memory leak and invalid pointer problems in C++ · Relevant syntax:: constructors, destructors, new() · Invalid access: object has a pointer to memory allocated on stack – the pointer becomes invalid after the function returns · Memory leak: object has pointer to dynamically allocated memory and the pointer is reset without releasing the memory. Examples of C++ programs to illustrate the problems. |
|
|
|
|
||
|
|
|
||
|
Week 8 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 9 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 10 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 11 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 12 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 13 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 14 |
|
|
|
|
|
|||
|
|
|||
|
Week 15 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 16 |
|
|
|
|
|
|
||
|
|
|
||
|
Week 17 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last Revision: Wednesday, August 29, 2007