CSE 503: Software Engineering
Spring 2011

David Notkin

Basics Assigned Work

Basics: CSE 503 generally focuses on research issues in software engineering, and it will do so this quarter.  At the same time, based on the initial questionnaires, there seems to be a mix of those interested primarily in the research side and those interested primarily in the development side.  Therefore we will focus on a mixture of the two -- which are not always so distant from one another -- in lectures.  Some readings and assignments may have separate choices for those more interested in research vs. development.
  • Lectures: Tuesday and Friday, 10:30-11:50AM (in CSE 403)
  • Notkin's coordinates: CSE 542, 206-685-3798, notkin@cs.washington.edu
  • Office hours: Friday 1-2PM or by appointment.  Also, whenever my door is open, feel free to see if I can meet then; if not, we can find a time we can meet.  (I anticipate being on campus only on Tuesdays, Thursdays and Fridays this quarter, but I will be checking email frequently on the other days.)
  • Syllabus: Calendar, readings, assignments (below)
  • Readings: Free access to papers (unless marked) through UW Libraries from any UW IP address or by clicking the off-campus access link at the top-right of lib.washington.edu)
  • Course mailing list: cse503a_sp11@u.washington.edu
  • Course discussion board: https://catalyst.uw.edu/gopost/board/notkin/21623/
  • TA: none
  • Academic misconductThis is a very serious offense and will be dealt with through the departmental, college and university processes. Copying others' work, including from this or previous quarters or from publicly available sources without attribution, is considered cheating.  If in doubt about what might constitute cheating, send the instructor email describing the situation. For more details see the CSE Academic Misconduct web page.  Do not read this in a way that discourages genuine collaboration and discussion.

Assigned work

In addition to the assignments and projects below:
  • 5% of your grade will be for class participation, broadly construed including lecture, the course mailing list, etc.
  • 7.5% of the grade is not yet defined, but will likely require a mixture of a small assignment or two and some summaries of selected research papers.
  • There are no examinations.
  1. Assignment #1 "Looking backwards" (5% of course grade): Due on Monday April 4 @ 10PM
    • Write a 2-3 page scholarly assessment of what people "got right" and "got wrong" about software engineering through around 1980. That is, based on literature (likely starting with the above, but with more through following citations, searches, asking Notkin, etc.) (a) identify some assumptions or conclusions upon which people based their perceptions of software engineering, and (b) document why in 2011 there is evidence that they were correct or incorrect.
    • 2-3 pages means reasonable spacing, reasonable margins, reasonable assumptions. 
    • It's perfectly fine to share ideas, references, have discussions, etc.  But you are to write it yourself.
    • Due on Catalyst Collect it by 4/4/2011 @ 10PM, ideally in pdf.

  2. Assignment #2 "Looking sideways" (2.5% of course grade): Due on Monday April 11 @ 10PM
    • I will assign each of you responses to Assignment #1 written by two of your peers (by close-of-business on Tuesday 4/5).
    • You are to write informal, but careful, evaluations of each of the two assignments; I expect these to be about a page, but it could be more or less, if you think it is sufficient, necessary, etc.  Think of this as the kind of thing I might write when grading an assignment :-).
    • Due on Catalyst by 4/11/2011 @ 10PM, ideally in pdf.

  3. Project #1 "Pushing your boundaries" (35% of course grade): Due Monday May 2, 2011 @ 10PM
    • For those with significant development experience, this should be an aggressive use of a model checker, of selected tools, of some new technology, etc.  There should be a focus to the effort; not "just playing around" with the tool or technology.  The intent is to have you learn, in some depth, about an approach to build better software or to build software better.  The specific project must be approved by me.  The results of the project will be a web page that describes the effort, assess the strengths/weakness of the approach, lists problems you faced (you might do this by starting a mini-blog right away), links to the tools, etc.  You can work individually or in pairs.

      High-level examples include:
      • The Daikon invariant detector.
      • One of CMU's many model checkers -- I haven't vetted any of these recently, so caveat emptor.
      • The SPIN model checker.
      • Alloy from MIT.
      • Pex from Microsoft Research (and conceivably even Pex for Fun, although I'm not sure what the project could actually be).
      • You might find some other interesting tools from Microsoft Research here.
      • There are lots of other possibilities -- search some, talk to me, etc. for other ideas.

    • For those with less development experience, this should be an aggressive "classic" software development effort -- done in groups of two or three people.  The intent will be to focus on software design, software implementation, and (to a lesser degree) software teamwork to a level possible in about a month.  The specific project must be approved by me.  The results of the project will (a) a well-documented software system, including directions on how to easily install and run it,  and (b) a one-to-two page description of what was learned about design, implementation and teamwork written independently by each team member.  

      High-level examples include:
      • A soup-to-nuts set of designs and implementations of the (in)famous KWIC system; see D. L. Parnas. 1972. On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 12 (December 1972), 1053-1058, http://doi.acm.org/10.1145/361598.361623. You should also see David Garlan, Gail E. Kaiser, and David Notkin. 1992. Using Tool Abstraction to Compose Systems. Computer 25, 6 (June 1992), 30-38, http://dx.doi.org/10.1109/2.153255.  One specific objective of this example would be to provide a set of designs and implementations that could be used at the undergraduate level for comparing and contrasting designs.
      • If you are looking for an in-depth Java experience, you can do the Husky Maps project from CSE331.  On the linked page, this is assignments 2 through 7 (inclusive); you can omit the null-pointer type-checking piece of the project.  You also do not have to do the questions in the various assignments, only the coding and documentation.  Your team can organize the work as you see fit. 
      • There are lots of other possibilities -- search some, talk to me, etc. for other ideas.

    • Project #2 Pushing the field's boundaries (45% of the course grade): Due Wednesday June 8, 2011 @ 10PM
      A "research" project (primary or secondary research) -- done individually or in "right-sized" groups.  The project must be approved by me.   [More information will be forthcoming.]

      • Primary research examples include:
      • As I will discuss in the first week or two of lectures, I am increasingly interested in the notion of software complexity.  I have found the work in this area, to date, very weak; and I finally have a hypothesis about why I think it's weak.  Specifically, complexity measures look at static program properties, while I posit that the complexity of the relationship of between the static program and its behaviors has been omitted.  Projects that explore this notion would be lovely. 
      • More generally, the question of getting a strong handle on the gap between essential and incidental complexity intrigues me, and project proposals in that area would be attractive to me.
      • What is the value of a test (roughly in information theoretic terms)?
      • ...
      • Secondary research examples include:
        • State-of-the-art of automated testing: probably a slightly narrow variant.
        • State-of-the-art of <your favorite topic>.
        • People who did the "development" variant of Project #1 can do (a slightly more aggressive version of) its "research" variant for Project #2.

Syllabus: calendar, reading, assignments
March 28- April 1
Introduction (pptx, pdf)
  • History (brief, NATO conferences)
  • Does software (engineering) really suck?
  • A different set of questions about software engineering -- that should drive more research
  • Overview of course expectations
Reading (see above for access information)
Programs, Behaviors, Ambiguity (pptx, pdf)
  • Properties of programs -- correctness, reliability, safety, performance, usability, etc.
  • Approaches to software engineering -- people, processes, tools, programming languages, etc.
  • "goto" controversy
  • Is software engineering really Engineering?
  • What can/can't programming languages do, what can/can't software engineering do?
  • Requirements, specifications, programs
Reading (see above for access information)
April 4-8
Monday 4/4: Assignment #1 due @10PM

Complexity and proofs of ADTs (pptx, pdf)

Electrifying formal methods (pptx, pdf)
  • Bounded model checking
Reading (before lecture)
  • Alloy tutorial -- at least Session 1 (and use the PDF or ODP, but not Powerpoint for the ODP)
April 11-15
Symbolic model checking (pptx, pdf)
Classic software testing (pptx, pdf)
  • Terminology, characterization
  • Partitions, structural coverage
  • Mutation testing
  • Random (feedback-directed) testing
April 18-22
Modern software testing (pptx, pdf)
  • Automated test generation
  • Concolic testing
  • ...
Design (pptx, pdf)

And brief project #1 presentations
April 25-29
Design II (pptx, pdf)
Aspect-oriented programming: video watched in class

Reading: either of the following two papers -- the first is more language-oriented, the second is more of the core motivatio nfor AOP
  • Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. 2001. An Overview of AspectJ. In Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP '01), Juergen Lindskov Knudsen (Ed.). Springer-Verlag, London, UK, UK, 327-353. [please search for the paper itself.]
  • Kiczales, Gregor; John Lamping, Anurag Mendhekar, Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, and John Irwin (1997).  "Aspect-oriented Programming."  Proceedings of the European Conference on Object-Oriented Programming, vol.1241. pp. 220–242. [please search for the paper itself.]
May 2-6
Design Patterns (pptx, pdf)
Software architecture I (pptx, pdf)
May 9-13
Project #2 proposals (pptx, pdf)
More proposals
May 16-20
Proposals and discussion of research incentives
Software engineering research, economics, governance (pptx, ppt)
May 23-27
May 30-June 3

Project #2 Due on Wednesday June 8, 2011 @ 10PM