CS 230: Software Engineering

Instructor: Dr. Miryung Kim (BH 4532 H)
Office Hours: MW 11-12 AM BH 4532H 
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.


Project: 45% (Note that Final Exam Time will be used for project presentations. Monday, June 06, 2016 8:00 AM - 11:00 AM)
Student Learning Presentation: 20%
Mini PC Meeting: 20%
Reading Questions and Participation: 15%

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 one paragraph review in the form of comment of 1 or 2 questions through Piazza before each paper discussion. Your questions should reveal your critical analysis of the assigned reading. 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?

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
3/28 (Mon)
3/30 (Wed)
Introduction to Software Engineering
Background Survey
Software Design and Software Architecture
Ease of Change
Software Architecture
On the criteria to be used in decomposing systems into modules
An Introduction to Software Architecture

Week 2
4/4 (Mon)
4/6 (Wed)

Software Design and Software Architecture
Architecture Description Support
Design Patterns
ArchJava: Connecting Software Architecture to Implementation

Design Patterns: FactoryMethod, Singleton, Adapter, Bridge, Flyweight, Strategy, Mediator, Observer
Week 3
4/11 (Mon)
4/13 (Wed)
Empirical Studies of Software Evolution
Code Decay

Reverse Engineering and Knowledge Discovery
Reflexion Model
Software Visualization
Does code decay? Assessing the evidence from change management data
Mining Version Histories to Guide Software Changes

Software reflexion models: bridging the gap between design and implementation
Polymetric views-a lightweight visual approach to reverse engineering
Week 4
4/18 (Mon)
4/20 (Wed)
Program Differencing and Merging
The Longest Common Subsequence Algorithm
Abstract syntactic tree based program differencing
Control Flow Graph based Program Differencing
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
4/25 (Mon)
4/27 (Wed)

Refactoring Practices
Refactoring Reconstruction
Automated Refactoring
A Field Study of Refactoring Benefits and Challenges
Template-based Reconstruction of Complex Refactorings
LASE: Locating and Applying Systematic Edits by Learning from Examples
Does Automated Refactoring Obviate Systematic Editing?
Week 6
5/2 (Mon)
5/4 (Wed)

Debugging and Fault Localization
Delta Debugging
Spectra-based fault localization
Simplifying and Isolating Failure-Inducing Input
Locating Causes of Program Failures
Isolating Cause Effect Chains from Computer Programs
Visualization of test information to assist fault localization
Finding bugs is easy
Week 7
5/9 (Mon)
5/11 (Wed)
Regression Testing and Change Impact Analysis Regression Test selection for Java software
Scaling regression testing to large software systems
Chianti: a tool for change impact analysis of java programs
FaultTracer: a spectrum-based approach to localizing failure-inducing program edits
Week 8
5/16 (Mon)
5/18 (Wed)
No Class (ICSE 2016)
Week 9
5/23 (Mon)
5/25 (Wed)
Code Clones
Mini PC Meeting

CCFinder: A multilinguistic token-based code clone detection system for large scale source code
An empirical study of code clone genealogies
Week 10
5/30 (Mon)
No Class
6/1 (Wed)
Mini PC Meeting

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 3 to 5 people, and will be limited by the time limit we have for final presentations.

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

Student Learning Presentation.

Two students jointly have a 20 minute presentation to discuss recent advances on the lecture's topic (or each student will have a 10 minute presentation). For example, in Week 5, the class discussion topic is refactoring, and the students will select a state-of-the-art recent papers (ideally in the last two to three years) on the topic of refactoring practices, refactoring reconstruction, and automated refactoring support. The student will perform critical reading of the paper and assess the technology and concept. The student will then present their findings and analysis to complement my lecture and class discussion, which are based on seminal papers in each topic. You are welcome to consult me on the choice of your paper. You may also include a short demo of relevant tools if necessary.      

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 2% 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.

Reading reviews/questions will be graded in the scale of 1 pt.

Class Discussion

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