We will have a quiz on four pre-defined dates. The instructor cannot accommodate quizzes on a different date. However, we will count the best 3 quizzes out of 4 quizzes. Each quiz should take about 20 minutes.
Each team should submit a written report (max 10 pages) to the
CCLE system. Each team should consist of 3 to 4 people. You may
include an appendix beyond 10 pages, but your paper must be
understandable without it. Submissions should be in the ACM
format. In Week 5, I will release a few sample project
ideas to guide you with the process of choosing a project topic. A
short proposal is due on Week 6 and a final project report is due
on the final exam week.
Your report should be structured like a conference paper,
meaning that your report should contain:
Motivation & Problem Definition
Related Work
Approach
Evaluation
Results
Discussions & Future Work
Clarity and Writing
How Does It Work?
1) Think. The teacher provokes students' thinking with a
question or prompt or observation. The students should take a few
moments (probably not minutes) just to THINK about the question.
2) Pair. Using designated partners (such as with Clock Buddies),
nearby neighbors, or a deskmate, students PAIR up to talk about the
answer each came up with. They compare their mental or written notes
and identify the answers they think are best, most convincing, or most
unique.
3) Share. After students talk in pairs for a few moments (again,
usually not minutes), the teacher calls for pairs to SHARE their
thinking with the rest of the class. She can do this by going around
in round-robin fashion, calling on each pair; or she can take answers
as they are called out (or as hands are raised). Often, the teacher or
a designated helper will record these responses on the board or on the
overhead
Lectures |
Reading | |
Week 1 4/1 (Mon) 4/3 (Wed) |
Introduction to Software Engineering Syllabus Background Survey Software Design and Software Architecture Ease of Change Software Architecture Architecture Description Support |
OPTIONAL: On
the criteria to be used in decomposing systems into modules READ: An Introduction to Software Architecture OPTIONAL: ArchJava: Connecting Software Architecture to Implementation |
Week 2 4/8 (Mon) 4/10 (Wed) |
Software Architecture Styles and
Constraints Software Design Patterns Design Patterns |
Design
Patterns: FactoryMethod, Singleton,
Adapter,
Bridge,
Flyweight,
Strategy,
Mediator,
Observer |
Week 3 4/15 (Mon) 4/17 (Wed) |
Quiz 1 (4/15 Monday) Interactive Code Review API Usage Mining |
Book Chapter on Software
Evolution (Section 1, Section 2, and Section 4.1) READ: Interactive Code Review for Systematic Changes (local pdf) READ: Are Code Examples on an Online Q&A Forum Reliable? A Study of API Misuse on Stack Overflow (local_pdf) OPTIONAL: Visualizing API Usage Examples at Scale (local_pdf) |
Week 4 4/22 (Mon) 4/24 (Wed) |
Software Design Patterns Empirical Studies of Software Evolution Code Decay Reverse Engineering and Knowledge Discovery Reflexion Model Software Visualization |
Design
Patterns: FactoryMethod, Singleton,
Adapter,
Bridge,
Flyweight,
Strategy,
Mediator,
Observer READ: Does code decay? Assessing the evidence from change management data READ: Software reflexion models: bridging the gap between design and implementation OPTIONAL: Polymetric views-a lightweight visual approach to reverse engineering |
Week 5 4/29 (Mon) 5/1 (Wed) |
Hoare Logic and Weakest Precondition Software Verification Quiz 2 (4/29 Monday) |
|
Week 6 5/6 (Mon) 5/8 (Wed) |
Program Differencing and
Merging The Longest Common Sub-sequence Algorithm Abstract syntactic tree based program differencing Control Flow Graph based Program Differencing Refactoring Refactoring Practices Refactoring Reconstruction |
Book Chapter on Software
Evolution (Section 4.2) READ: A differencing algorithm for object-oriented programs. OPTIONAL: Identifying syntactic differences between two programs Identifying and summarizing systematic code changes via rule inference Interactive Code Review for Systematic Changes Basic Background: Abstract Syntax Tree Control Flow Graph Book Chapter on Software Evolution (Section 3.4) READ: A Field Study of Refactoring Benefits and Challenges OPTIONAL: Template-based Reconstruction of Complex Refactorings |
Week 7 5/13 (Mon) 5/15 (Wed) |
Refactoring Refactoring Practices Refactoring Reconstruction Refactoring Automated Refactoring Quiz 3 (5/13 Monday) |
READ:
Does
Automated Refactoring Obviate Systematic Editing? OPTIONAL: LASE: Locating and Applying Systematic Edits by Learning from Examples |
Week 8 5/20 (Mon) 5/22 (Wed) |
Debugging and Fault Localization Delta Debugging Spectra-based fault localization FindBug |
READ: Yesterday, my program worked. Today, it does not. Why? OPTIONAL: Simplifying and Isolating Failure-Inducing Input Locating Causes of Program Failures Isolating Cause Effect Chains from Computer Programs READ: Visualizing information to assist fault localization OPTIONAL: Finding bugs is easy |
Week 9 5/27 (Mon)--No Class 5/29 (Wed) Class |
Memorial Day Search Based Software Engineering Part 1 |
READ:
Optimizing
Existing Software With Genetic Programming |
Week 10 6/4 (Mon) 6/6 (Wed) |
Change Impact Analysis Quiz 4 (6/3 Monday) Search Based Software Engineering Part 2 |
Book Chapter on Software Evolution (Section 5) READ: Chianti: a tool for change impact analysis of java programs OPTIONAL: FaultTracer: a spectrum-based approach to localizing failure-inducing program edits OPTIONAL: Regression Test selection for Java software OPTIONAL: Scaling regression testing to large software systems READ: GenProg: A Generic Method for Automatic Software Repair |
Final Week |
Final Project Presentation |
Each
member of the university is expected to uphold these values through
integrity, honesty, trust, fairness, and respect toward peers and
community. In your first week, you must read and sign UCLA's Academic
Integrity Statement.