COS520: Software Engineering I
Fall 1999 Syllabus/Readings

Larry Latour
Associate Prof, Dept. of CS


Catalog Description: This course provides the knowledge and tools necessary for the design, specification, implementation, and maintenance of non-trivial, reliable software. Various specification and design methodologies will be explored. (Prerequisites: COS350 and COS431 or equivalent)

Instructor: Larry Latour, Dept. of Computer Science.

Required Readings:

Winograd, Terry. Bringing Design to Software, ACM Press and Addison-Wesley, 1996.

Readings Packet, available from the instructor. There will be a nominal per-page charge to defray the copying costs of the papers.

Required Videotapes:

Videotapes roughly every other week..

Topics:

1. Introduction: An overview of the development process: design, specification, implementation and verification, architectural concerns, the nature of software decomposition and abstraction, and the need for formal methods. Case studies of Leslie Lamport's Distributed Resource Allocation System and Parnas's KWIC Index System.

Case Study 1: A Distributed Resource Allocation System: based on Leslie Lamport's Time, Clocks, and the Ordering of Events in a Distributed System. Formal analysis of requirements, specification, and verification of the system. Introduction/review of the concepts of distributed systems, concurrency, state machines, logical and physical time, and Einstein's theory of relativity.

Case Study 2: A KWIC Index System: based on David Parnas's On the Criteria to be Used in Decomposing Systems into Modules . An example of one of the first published examples of object oriented decomposition along with advantages over traditional functional decomposition.

Readings:

Lamport, Leslie. "Time, Clocks, and the Ordering of Events in a Distributed System", pps. 558-565, CACM, Vol. 21, No. 7, July, 1978 (in readings packet).

Parnas, David. "On the Criteria To Be Used in Decomposing Systems into Modules", pps. 1053-1058, CACM, Vol. 15, No. 12, December, 1972 (in readings packet).

2. Design Context: The importance of the user and the context in which software is designed, the need to be "interdisciplinary", and the role of the Winograd text in the course. All Winograd readings include an attached profile.

Readings:

Winograd Text (1.), Kapor, Mitchell. "A Software Design Manifesto", and profile on Software Design and Architecture.

Winograd Text (2.), Liddle, David. "Design of the Conceptual Model", and profile on The Alto and the Star.

3. The Software Design Process and Documentation Support: Design process based on separation of concerns and information hiding, functional, structural, and implementation architectures, documentation as a driving concern (case study: stoplight control system). Hypermedia support for system documentation. Available Tools: LaTex, HTML, web servers, viewers, and sources, graphical formats and transformation tools.

Readings:

Hester, S.D, Parnas, D.L., and Utter, D.F. "Using Documentation as a Software Design Medium", pps. 1942-1977, The Bell System Technical Journal, October, 1981 (in readings packet).

Parnas, David L. and Clements, Paul C. "A Rational Design Process: How and Why to Fake It", Presented at the Tapsoft Joint Conference on Theory and Practice of Software Development, Berlin, March, 1985 (in readings packet).

Wheeler, Tom. Software System Development Through The Use of Formal Documentation, Ch. 2 (System Documentation), PhD. Thesis, 1988 (in readings packet).

Biggerstaff, Ted, "Hypermedia as a Tool to Aid Large Scale Reuse", Proceedings of the Rocky Mountain Institute of Software Engineering Workshop on Software Reuse, October, 1987 (in readings packet)

Winograd Text (4.), Rheinfrank, John, and Evenson, Shelley. "Design Languages", and profile on Macintosh Human Interface Guidelines.

Winograd Text (6.), Denning, Peter, and Durgan, Pamela. "Action-Centered Design", and profile on Business-Process Mapping.

4. Software Architectures: overview of the concept of an architecture, architectural styles and types (case study: cruise control system), architectural mismatch, tools, reuse and genericity, DSSAs (domain specific software architectures), views, formalism, and research directions. A case study of Leslie Lamport's Reliable Distributed Multiprocess System.

Case Study 3: A Reliable Distributed Multiprocess System: based on Leslie Lamport's The Implementation of Reliable Distributed Multiprocess Systems . Formal analysis of proper system behavior in the face of "failure" or "malfunction", where "failure" means doing nothing and "malfunction" means doing something incorrectly. An algorithm and its proof of correctness are described for a system of 3 processes with perfect clocks, and is then generalized for n processes with imperfect clocks. This algorithms uses Lamport's Distributed Resource Allocation System as a base.

Readings:

Garlan, David. "Research Directions in Software Architecture", ACM Computing Surveys, Vol 27, No. 2, June, 1995 (in readings packet).

Booasson, Maarten. "The Artistry of Software Architecture", Guest Lecturer's Introduction, pps. 13-16, IEEE Software, November, 1995 (in readings packet).

Shaw, Mary. "Comparing Architectural Design Styles", pps. 27-41, IEEE Software, November, 1995 (in readings packet).

Booch, Grady, Software Components with Ada, Chapter 2 (Ada and Object Oriented Development), Benjamin Cummings, 1983 (in readings packet).

Garlen, David, Allen, Robert, and Ockerbloom, John. "Architectural Mismatch: Why Reuse Is So Hard", pps. 17-26, IEEE Software, November, 1995 (in readings packet).

Kruchten, Phillippe P. "The 4+1 View Model of Architecture", pps. 42-50, IEEE Software, November, 1995 (in readings packet).

Hayes-Roth, Barbara, et. al. "A Domain-Specific Software Architecture for Adaptive Intelligent Systems", pps. 288-301, IEEE Transactions on Software Engineering, Vol. 21, No. 4, April , 1995 (in readings packet).

Winograd Text (10.), Schrage, Michael, "Cultures of Prototyping", and profile on Hypercard, Director, and Visual Basic.

Winograd Text (7.), Brown, John Seely, and Duguid, Paul. "Keeping it Simple", and profile on Microsoft Bob.

5. Abstraction in Program Development: Benefits of abstraction, programming in the large vs. programming in the small, specifications of procedure and data abstractions, abstract interfaces, implementing and using abstractions, aids in understanding abstractions, parameterized abstractions , exception handling.

Readings:

Liskov, Barbara, and Guttag, John. Abstraction and Specification in Program Development, Chapters 3 (Procedural Abstraction) and 4 (Data Abstraction), McGraw-Hill, 1986 (in readings packet).

Winograd Text (8.), Kelley, David, and Hartfield, Bradley, "The Designer's Stance", and profile on IDEO.

6. Formal Specifications - Algebraic vs. Model based Approaches. The Larch two-tiered approach to specification using Larch: auxiliary specifications, interface specifications, a comparison to the model based approach, executable specifications.

Readings:

Liskov, Barbara H., and Berzins, Valdis. An Appraisal of Program Specifications, in Research Directions in Software Technology, edited by P. Wegner, pps. 276-301, MIT Press (in readings packet).

Swartout, William, and Balzer, Robert. "On the Inevitable Intertwining of Specification and Implementation", pps. 438-440, CACM, 25 (7), July, 1982 (in readings packet).

Guttag, John V. "Notes on Type Abstraction", Proceedings of Conference on Specifications of Reliable Software, 1979 (in readings packet).

Guttag, John V., Hornung, James J., and Wing, Jeannette M. "The Larch Family of Specification Languages", IEEE Software, pps. 24-36, September, 1985 (in readings packet).

Guttag, John V., and Hornung, James J. "Formal Specification as a Design Tool", Seventh Annual ACM Symposium on Principles of Programming Languages, pps. 251-261, 1980 (in readings packet).

Liskov, Barbara, and Guttag, John. Abstraction and Specification in Program Development, Chapter 10 (Writing Formal Specifications), McGraw-Hill, 1986 (in readings packet).

Winograd Text (11.), Gal, Shahaf, "Footholds for Design", and profile on The Spreadsheet.

7. Program Verification: Reasoning about straight-line code, programs with multiple paths, procedures, data abstractions.

Readings:

Goguen, Joseph A. "More Thoughts on Specification and Verification", ACM SIGSOFT, 6(3), pps. 38-41, 1981 (in readings packet).

Liskov, Barbara, and Guttag, John. Abstraction and Specification in Program Development, Chapter 11 (A Quick Look at Program Verification), McGraw-Hill, 1986 (in readings packet).

Winograd Text (12.), Norman, Donald. "Design as Practiced", and profile on The Design of Everyday Things".

8. Model Based Specification: An overview of Z (pronounced "Zed"), basic terminology: mathematical concepts, functions, schema notation, reasoning rules (logical calculi), case studies: symbol table, telephone switching network, text editor, notation for software architecture description.

Readings:

Hayes, Ian. Specification Case Studies, Glossary, The Logical Calculi, and Part A - Tutorials, pp. 8-88, Prentice-Hall International, 1987 (in readings packet).

Sufrin, Bernard. "Formal Specification of a Display-Oriented Text Editor", Science of Computer Programming, 1, pp. 157-202, 1982 (in readings packet).


Grading:

Exams - 30 points.

Class Participation and Weekly Homework - 10 points.

Projects - 50 points.

Journal - 10 points.

Important: Each of the eight portions of the course listed above (2 exams, homework, 4 projects, and the journal) must be completed to the satisfaction of the instructor.


Journal Contents

The following information should be included in your journal in a timely manner:

Students should be prepared to hand in their journal in type-written form on Wednesday or Friday, and it should be up to date to the previous syllabus topic. The journal might or might not be collected on those days, and the journal reviewer might be the instructor or some other class member. Timeliness of journal entries will play a major role in the journal grade.


Team Project

Each student will be responsible for working with a classmate, with the goal of delivering a working system on the public presentation day, the final class period of the semester.

The choice of software and hardware platform, and support tools, are all up to the team.


Deliverables:


Last Updated: 9/2/99