CS 230: Software Engineering

Lecture: Mon/Wed 12:00 PM to 1:50 PM FRANZ 2258A
Final Exam: Monday June 12th, 2007: 11:30 AM - 2:30 PM
Instructor: Dr. Miryung Kim (BH 4532 H)
Office Hours: By appointment 
General Description
As software systems become increasingly large and complex, automated software engineering analysis and development tools play an important role in various software engineering tasks: design, construction, evolution, and testing and debugging of software systems. This course will introduce students to the foundations, techniques, tools, and applications of automated software engineering technology. Students will develop, extend, and evaluate a mini automated software engineering analysis tool and assess how the tool fits into the software development process. This class is intended to introduce current research topics in automated software engineering.

Undergraduate level knowledge of data structures and object-oriented program languages is required. A prior course in software engineering (undergraduate) such as CS130 is recommended. Please feel free to take a look at CS 130 syllabus here. You are welcome to just sit in for a few days and see how this class feels. By understanding the fundamentals behind automated software engineering analysis algorithms, techniques and tools, students will acquire keen eyes on how to systematically design, analyze, and extend large software systems. This will prepare students to become principle software architects and development leads in the future.  
  • Intelligent integrated development environments
  • Computer-aided design of software
  • Automated testing and verification
  • Computer-aided bug finding and advanced debugging techniques 
  • Computer-aided program understanding
  • Computer-aided refactoring and documentation

Audience and Prerequisites

This class is intended to introduce current research topics in software engineering with focus on software evolution. Undergraduate level knowledge of data structures and object-oriented program languages is required. Knowledge of compilers, program analysis and program representations is encouraged. If you are unsure of your qualifications, please contact the instructor, who will be happy to help you decide if this course is right for you. You are welcome to just sit in for a few days and see how this class feels.


Reading Assignment Instruction

Please download the above paper from the ACM Digital Library. Access to ACM digital library is free if you are using a computer on campus with a valid UCLA IP address. Please submit short questions or comments through Piazza before each paper discussion. The grading of reading questions will depend on the overall quantity and quality of your questions.
  •     Cool or significant ideas. What is new here? What are the main contributions of the paper? What did you find most interesting? Is this whole paper just a one-off clever trick or are there fundamental ideas here which could be reused in other contexts?
  •     Fallacies and blind spots. Did the authors make any assumptions or disregard any issues that make their approach less appealing? Are there any theoretical problems, practical difficulties, implementation complexities, overlooked influences of evolving technology, and so on? Do you expect the technique to be more or less useful in the future? What kind of code or situation would defeat this approach, and are those programs or scenarios important in practice? Note: we are not interested in flaws in presentation, such as trivial examples, confusing notation, or spelling errors. However, if you have a great idea on how some concept could be presented or formalized better, mention it.
  •     New ideas and connections to other work. How could the paper be extended? How could some of the flaws of the paper be corrected or avoided? Also, how does this paper relate to others we have read, or even any other research you are familiar with? Are there similarities between this approach and other work, or differences that highlight important facets of both?


We will have a short quiz on 4/17 (Mon),  5/3 (Wed), 5/17 (Wed), and 5/31 (Wed). 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. 

Class Discussion: Think-Pair-Share

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

Class Schedule, Reading List, and Project Milestones 

Week 1
4/3 (Mon)
4/5 (Wed)
Introduction to Software Engineering
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
ArchJava: Connecting Software Architecture to Implementation

Week 2
4/10 (Mon)
4/12 (Wed)

Software Design Patterns
Design Patterns
Design Patterns: FactoryMethod, Singleton, Adapter, Bridge, Flyweight, Strategy, Mediator, Observer
Week 3
4/17 (Mon)
4/19 (Wed)- No Class
Empirical Studies of Software Evolution
Code Decay
Quiz 1 (4/17 Monday)

READ: Does code decay? Assessing the evidence from change management data

Week 4
4/24 (Mon)
4/26 (Wed)
Reverse Engineering and Knowledge Discovery
Reflexion Model
Software Visualization

Program Differencing and Merging
The Longest Common Subsequence Algorithm
Abstract syntactic tree based program differencing
Control Flow Graph based Program Differencing
READ: Software reflexion models: bridging the gap between design and implementation
OPTIONAL: Polymetric views-a lightweight visual approach to reverse engineering

READ: A differencing algorithm for object-oriented programs.
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
Week 5
5/1 (Mon)
5/3 (Wed)

Refactoring Practices
Refactoring Reconstruction
Automated Refactoring
Quiz 2 (5/3 Wednesday)
READ: A Field Study of Refactoring Benefits and Challenges
OPTIONAL: Template-based Reconstruction of Complex Refactorings

READ: Does Automated Refactoring Obviate Systematic Editing?
OPTIONAL: LASE: Locating and Applying Systematic Edits by Learning from Examples
Week 6
5/8 (Mon)
5/10 (Wed)

Debugging and Fault Localization
Delta Debugging
Spectra-based fault localization
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 7
5/15 (Mon)
5/17 (Wed)
Regression Testing and Change Impact Analysis
Quiz 3 (5/17 Wednesday)
READ: Regression Test selection for Java software
OPTIONAL: Scaling regression testing to large software systems

READ: Chianti: a tool for change impact analysis of java programs
OPTIONAL: FaultTracer: a spectrum-based approach to localizing failure-inducing program edits
Week 8
5/22 (Mon)
5/24 (Wed)
Hoare Logic
Weakest Precondition and Loop Invariant
Week 9
5/29 (Mon)--No Class
5/31 (Wed)
Quiz 4 (5/31 Wednesday)
Code Clones
READ: CCFinder: A multilinguistic token-based code clone detection system for large scale source code
OPTIONAL: An empirical study of code clone genealogies
Week 10
6/5 (Mon)
6/7 (Wed)
Mini PC Meeting

6/12 (Mon)
Final Project Presentation during Final Exam

Mini Projects

Each team should submit a written report (max 10 pages) to the CCLE system. You may include an appendix beyond 10 pages, but your paper must be understandable without it. Submissions should be in the ACM format. Each team may consist of 4 to 5 people, and will be limited by the time limit we have for final presentations. In Week 4, 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 5 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:

If you are doing a project that involves implementation, please submit your source code by sharing an on-line repository. Please describe how to run and test your code in your report.

Here's grading guidelines for your project report.

Motivation & Problem Definition

Related Work




Discussions & Future Work

Clarity and Writing

Mini PC Meeting

Mini PC meeting emulates an actual programming committee meeting where program committee members select peer-reviewed research articles for technical conferences. Each committee member will review papers assigned to them and submit a critical assessment for each assigned paper, either from a perspective of an advocate or from a perspective of skeptic. A review template will be provided and you will write a review but also provide scores to indicate your assessment of the paper's originality, comprehensiveness, and new research contributions. Only after you submit your reviews, you will be able to see other committee members' reviews. On the days of PC meetings, I will take a role of PC chairs and we will have a roundtable PC meeting where each paper is discussed by the committee members who review the paper.

Feedback Statement

During this course, I will be asking you to give me feedback on your learning in both informal and formal ways, e.g., including anonymous midpoint survey about how my teaching strategies are helping or hindering your learning. It is very important for me to know your reaction to what we are doing in the class, so I encourage you to respond to these surveys, ensuring that we can create an environment effective for teaching and learning.  Occasionally, at the end of the lecture, I will hand out index cards to ask "what is the most important thing you have learned in this class session?" and "what questions do you still have?" This feedback will be anonymous and this is to check your understanding and promote Q&A. Please also take the time to write written comments when submitting your course instructor survey. Your course instructor survey is important to me and future students. To reward your participation, I will add 3% of the total grade for participating in the course instructor survey.

Grading Scheme

Project reports, milestone and presentations will be graded in the scale of 5pt.

Class Discussion

We are using Piazza for class discussions. Link: piazza.com/ucla/spring2017/cs230/home
Please note that not all in-class announcements will be repeated through Piazza.