There will be three exams. All exams are in-person, closed book. The instructor is unable to accommodate different dates for mini exams. No exceptions will be made. However, you may drop one exam out of three exams and your best two exams will be counted towards the final grade.
Each team should submit a written report (max 10 pages)
to the BruinLearn system. Each team should consist of 5 to
6 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 2, 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 3 and a
final project report is due on the final exam week. A part
of instruction time will be reserved for project team
meetings with the instructor and there will be a sign up
via Piazza. While it is a team project, each team member
is not automatically entitled to receive the same grade
and their score will be adjusted based on each one's
contribution, if necessary. Multiple sources of evidence
including a peer evaluation will be collected.
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 3/28 (Mon) 3/30 (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/4 (Mon) 4/6 (Wed) |
Software Architecture
Styles and Constraints Software Design Patterns Design Patterns |
Design Patterns: FactoryMethod,
Singleton, Adapter, Bridge, Flyweight, Strategy, Mediator, Observer |
Week 3 4/11 (Mon) 4/13 (Wed) |
Developers Tools for Heterogeneous
Computing Software Engineering for Data Analytics |
READ: HeteroGen: Transpiling C to
Heterogeneous HLS Code with Automated Test Generation
and Program Repair (local_pdf) READ: Software Engineering for Data Analytics (local_pdf) |
Week 4 4/18 (Mon) 4/20 (Wed) |
Mini Exam 1 on 4/18 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 5 4/25 (Mon) 4/27 (Wed) |
Empirical Studies of
Software Evolution Code Decay Program Differencing and Merging The Longest Common Sub-sequence Algorithm Abstract syntactic tree based program differencing Control Flow Graph based Program differencing |
READ: Does
code decay? Assessing the evidence from change
management data 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 |
Week 6 5/2 (Mon) 5/4 (Wed) |
Refactoring Refactoring Practices Refactoring Reconstruction Automated Refactoring |
Book Chapter on Software Evolution (Section 3.4) 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 7 5/9 (Mon) 5/11 (Wed) |
Mini Exam 2 on 5/9 Monday 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 8 5/16 (Mon) 5/18 (Wed) |
Change Impact Analysis |
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 |
Week 9 5/23 (Mon) 5/25 (Wed) |
ICSE Travel Video Lectures: Hoare Logic and Weakest Precondition |
Hoare Logic Part 1 Hoare Logic Part 2 |
Week 10 5/30 (Mon)--No Class 6/1 (Wed) Class |
Memorial Day Automated Repair Mini Exam 3 on 6/1 Wednesday |
READ: GenProg: A Generic Method for Automatic Software Repair |
Final Week |
6/6 Monday Final Presentation 11:30 AM to 2:30 PM
|
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.