CMU 15-672

Methods of Software Development

Fall 1996

Course Overview

Daniel Jackson

Handout 1

August 26 1996

Instructor Teaching Assistant Administrator
Prof. Daniel Jackson James Ivers Rosey Hornyak
dnj+te@cs.cmu.edu jivers@cs.cmu.edu rosemary@cs.cmu.edu
Wean Hall 8019 (8-5143) Wean 4615.29 (8-5842) Wean 8106(8-3853)
Office hours: Wed. 3-4pm Office hours: Tues. 2-4pm

Overview

This course is about developing software in a methodical and systematic fashion. This course addresses the critical early stages of requirements analysis and specification construction; a related course (Architectures of Software Systems, 15-675) addresses the design issues that follow. The emphasis of the course is on techniques and activities rather than notations; a complementary course (Models of Software Systems, 15-671) focuses on semantic models and notations.

The course advocates a lightweight approach to methods. A method should not demand uniform application across the artifact or the lifecycle; it should be possible to apply it incrementally; and it should yield benefit in proportion to the effort invested. It should not require elaborate tools, and its notations should be spare and simple.

Most "methodologies"; are oversold; claiming to be good for everything, they end up being good for nothing. A powerful method must be closely tailored to a class of problems. For problems in this class, the method can provide the right notations, analyses and techniques to help the developer recognize difficulties and overcome them. For other problems, the method is unlikely to be useful. It is vital, therefore, to have some way of classifying problems, to characterize their essential parts, and to match methods to their appropriate problem classes .

Problem frames are a recent proposal for a way to classify problems [Jac94]. In this course, three problem frames will be studied. A reactive system, such as a nuclear reactor controller, interacts continuously with its environment; complexity arises from the need to control phenomena that are not entirely predictable. A workpiece system, such as a word processor, provides the user with operations to construct and modify ëworkpiecesí, such as documents; complexity arises from the structure of the workpieces and the operations. An information system, such as a web indexing server, collects data from the environment and responds to queries; complexity arises from the need to organize the data to make it immune to changes in the range of queries provided.

A single case study problem will run through the course. Aspects of the same problem corresponding to the three problem frames will be studied. Students will learn how to apply appropriate techniques in each case, and will develop practical skills by working in teams on the case study problem. For each problem frame, related techniques (less applicable to the case study but important nonetheless) will also be examined. Consequently, students will become familiar with most of the techniques and representations that appear in packaged methodologies.

The field of development method has been burdened with more than its fair share of platitudes, impractical dogmas and unfounded claims. A purpose of this course is to equip students with a sophisticated understanding of the nature of development method, so they are able to critically appraise existing methodologies, and to appreciate their strengths and limitations. To this end, in a concurrent thread of the course, a series of articles on fundamental aspects of method will be read and discussed.

The course has no official prerequisites, although students will be expected to have a background in basic discrete maths and some experience in developing large-scale software.

Organization

WWW page Information about the class may be found at http://www.cs.cmu.edu/afs/cs/user/dnj/pub/www/15-672/home.html.

Classes Classes are on Monday from 1:30 to 2:50pm in Wean 3412, and on Wednesday from 1:00 to 2:20pm in Wean Hall 4615a. There will be three kinds of classes: lectures, clinics and presentations

Projects There will be four projects, one for each problem frame plus a final project. All project work will be done in teams of 3-5.

Readings For each lecture, a set of short articles from the textbook and some papers are to be studied in advance. Note that the readings listed in the reading schedule are to have been completed before the lecture under which they appear. One student will present a 5 minute soap-box talk summarizing the short articles. All students are expected to be well prepared so they can participate fully in ensuing class discussion.

Presentations When a project has been completed, one of the teams will be chosen to present its work for critique and discussion. Presentations must adhere to the following format: maximum of 6 overhead projector slides, landscape mode, at least 18 point type (preferably 24pt).

All teams will produce written reports in two parts: the artifact itself (eg, specification and analysis), and a candid appraisal of how successful the exercise was, what difficulties were encountered, etc. Strict page limits will be specified for each project.

Clinics Students will have an opportunity to present work in progress. Each team will be allotted about 10 minutes to present their work and solicit comments. Slides must adhere to the format of the final presentations. No written reports are required.

Exercises Students will be given weekly exercises in order to develop basic proficiency in representations and techniques before applying them in case studies. These will be done individually, and not in teams.

Office hours The instructor and teaching assistant have scheduled office hours for answering questions and providing help with projects. They will also be happy to help at other times, but cannot promise always to be available: try to email or call first. Comments and suggestions about the class are very welcome.

Grading The course grade will be determined as a combination of four factors: projects (50%), exercises (20%), class participation (20%) and instructorís judgment (10%). Teams will receive a joint grade for each project but the other elements will be determined individually. There will be no final exam.

Class Schedule

# Date Topic
1 M 8/26 Introduction
2 W 8/28 Abstract modelling: entities, sets and relations
M 9/2 Labor Day, no class
3 W 9/4 Abstract modelling: relational operators and properties
4 M 9/9 Abstract modelling: first-order constraints
5 W 9/11 Abstract modelling: using Nitpick, simulation & checking
6 M 9/16 Designation and definition
7 W 9/18 Problem frames 1
M 9/23 Yom Kippur, no class
8 W 9/25 Problem frames 2
9 M 9/30 Information system frame: entity-relationship modelling
10 W 10/2 Information system frame: specifying updates and queries
11 M 10/7 Information system frame: event modelling of domains
12 W 10/9 Information system frame: case study clinic
M 10/14 Mid-semester break, no class
W 10/16 No class
13 M 10/21 Information system frame: final presentation
14 W 10/23 Reactive systems frame: scenario investigation
15 M 10/28 Reactive systems frame: specifying interactions with machines
16 W 10/30 Reactive systems frame: specifying interactions with tables
17 M 11/4 Reactive systems frame: case study clinic
18 W 11/6 Reactive systems frame: case study final presentation
19 M 11/11 Workpieces frame: object modelling: identifying classes & methods
20 W 11/13 Workpieces frame: information hiding and data abstraction
21 M 11/18 Workpieces frame: inheritance, subtyping and polymorphism
22 W 11/20 Workpieces frame: case study clinic
23 M 11/25 Workpieces frame: case study final presentation
W 11/27 Thanksgiving holiday, no class
24 M 12/2 Special topic
25 W 12/4 Conclusions

Reading Schedule

# Date Topic
2 W 8/28 Abstract modelling: entities, sets and relations
Ambiguity, Brilliance, Individuals, Partial Descriptions, [WD96: chs. 7 & 8, pp. 83-113], [Jac96]
3 W 9/4 Abstract modelling: relational operators and properties
Aspects of Software Development, Method, Procrustes, [Hoa86, Nau82, Hoa96, JW96]
4 M 9/9 Abstract modelling: first-order constraints
Critical Reading, Dataflow Diagrams 1 & 2, Top-down, Graphic Notations, [Fer92], [WD96:Chs. 12-14, pp. 165-215]
5 W 9/11 Abstract modelling: using Nitpick, simulation & checking
Deskilling, Fudge Factor, Software Engineering, [JD96: Chs. 1-3]
6 M 9/16 Designation and definition
Descriptions, Definition, Designation, Phenomena, Narrow Bridge, [Zem80]
7 W 9/18 Problem frames 1
Problem Context, Problem Frames, Problem Complexity, Problem Sensitivity, [Pol57a, Pol57b]
8 W 9/25 Problem frames 2
Misfits, Polya, Domains, Domain Characteristics, Frame Diagrams
9 M 9/30 Information system frame: entity-relationship modelling
Simple IS Frame, Entity-Relation Span, Models, [Che76, Qui87]
10 W 10/2 Information system frame: specifying updates and queries
Refutable Descriptions, [WD96: Chs. 11 & 12, pp. 147-183], [Cod70]
11 M 10/7 Information system frame: event modelling of domains
Mood, Calendar, [Jac83, Cam86]
14 W 10/23 Reactive systems frame: scenario investigation
Software, Requirements, Specifications, [R+91]
15 M 10/28 Reactive systems frame: specifying interactions with machines
Application Domain, Simple Control Frame, [Har87, Har88, Jac76]
16 W 10/30 Reactive systems frame: specifying interactions with tables
Composition, Shared Phenomena, [CP93, PM95, Hen80]
19 M 11/11 Workpieces frame: object modelling: identifying classes & methods
Workpieces frame, Classification, Object-oriented Analysis, [Boo86]
20 W 11/13 Workpieces frame: information hiding and data abstraction
What and How, [Par72, LZ75, Gut77]
21 M 11/18 Workpieces frame: inheritance, subtyping and polymorphism
Classification,Span of Description, [Lis87]

Italicized entries refer to articles in [Jac95] ; all are required reading.
Cited articles in square brackets are required unless in italic font.

References

Required texts

[Jac95] M. Jackson, Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices: Addison-Wesley, 1995.

Recommended texts

[WD96] Jim Woodcock and Jim Davies. Using Z: Specification, Refinement and Proof. Prentice Hall Europe, 1996.

Reference manuals

[JD96] Daniel Jackson and Craig A. Damon. Nitpick: A Checker for Software Specifications (Reference Manual). Technical Report CMU-CS-96-109, School of Computer Science, Carnegie Mellon University, Pittsburgh, January 1996.
[Spi92] J. M. Spivey,The Z Notation: A Reference Manual, Second edition, Prentice Hall, 1992.

Required articles

[Boo86] Grady Booch. Object-oriented software development. IEEE Transactions on Software Engineering, vol. 12, no. 12, pp. 211-221, 1986.
[Che76] Peter Chen. The entity-relationship model--toward a unified view of data. ACM Transactions on Database Systems, vol. 1, no. 1, pp. 9-36, 1976.
[CP93] P.-J. Courtois and D. L. Parnas. Documentation for safety-critical software. Proc. International Conference on Software Engineering, Baltimore, MD, 1993. pp. 315-323.
[Har87] David Harel. Statecharts: a visual formalism for complex systems. Science of Computer Programming, vol. 8, no. 3, pp. 231-274, June 1987.
[Hoa86] C.A.R. Hoare. The mathematics of programming. Inaugural lecture delivered before Oxford University, 17 October 1985. Reprinted as Ch. 21 of Essays in Computing Science, ed. C.A.R. Hoare and C.B. Jones, pp. 351-370.
[Jac83] Michael Jackson. Chs.1-3 (pp. 3-37) of System Development , Prentice Hall International (UK) Ltd, 1983.
[Jac96] Daniel Jackson. Requirements need form, maybe formality. in IEEE Software, vol. 12, No. 6, pp. 21-22, 1996.
[JW96] Daniel Jackson and Jeannette Wing. Lightweight formal methods. Contribution to An invitation to formal methods. IEEE Computer, vol. 29, 1996, pp. 16-30.
[Lis87] Barbara H. Liskov. Data abstraction and hierarchy. Proc. Object-oriented Programming Systems, Languages and Applications, Orlando, FL, Oct. 1987, pp. 17-34.
[LZ75] Barbara H. Liskov and Stephen N. Zilles. Specification techniques for data abstraction. IEEE Transactions on Software Engineering. Vol SE-1, No. 1 (March 1975).
[Nau82] Peter Naur. Formalization in program development. BIT 22(4): 437-453, 1982.
[Par72] D. L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of the ACM, vol. 12, no. 15, pp. 1053-1058, 1972.
[PM95] D. L. Parnas and J. Madey. Functional documents for computer systems. Science of Computer Programming, vol. 25, pp. 41-61, 1995.
[Pol57a] G. Polya. Problems to find, problems to prove. in How to solve it, second ed., Princeton Univ. Press, Princeton, NJ, 1957, pp. 154-157.
[Pol57b] G. Polya. Practical problems. in How to solve it, second ed., Princeton Univ. Press, Princeton, NJ, 1957, pp. 149-154.
[Qui87] W.V. Quine. Classes versus Properties. in Quiddities: An Intermittently Philosophical Dictionary. Belknap Press of Harvard University Press, Cambridge, MA, and London, England, 1987, pp. 22-24.
[R+91] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and William Lorensen. Dynamic Modeling. Section 8.5 (pp. 169-179) of Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991.
[Zem80] H. Zemanek. Abstract architecture. in Abstract Software Specifications, ed. D. Bjorner, Lecture Notes in Computer Science 86. Springer-Verlag, 1980, pp. 1-42. Read: The transition from informal to formal, pp. 14-17.

Recommended articles

[Cam86] John Cameron. An overview of JSD. IEEE Transactions on Software Engineering, vol. SE-12, No. 2, pp. 222-240, 1986.
[Cod70] E. F. Codd. A relational model of data for large shared data banks. Communications of the ACM, vol. 13, no. 6, pp. 377-387, 1970.
[Fer92] Eugene S. Ferguson. Engineering and the Mindís Eye. Ch. 5 (pp. 114-152): The Development and Dissemination of Engineering Knowledge. MIT Press, Cambridge, MA, 1992.
[Gut77] John V. Guttag. Abstract data types and the development of data structures. Communications of the ACM, Vol. 20, No. 6 (June 1977), pp. 396-404.
[Har88] David Harel. On visual formalisms. Communications of the ACM, vol. 31, no. 5,1988, pp. 514-530,
[Hen80] K. Heninger. Specifying software requirements for complex systems: new techniques and their applications. IEEE Transactions on Software Engineering, vol. SE-6, pp. 2-13, 1980.
[Hoa96] C.A.R. Hoare. How did programs get so reliable without proof? Proc. Third International Symposium of Formal Methods Europe, Oxford, England, March 1996.
[Jac76] Michael Jackson. Constructive Methods of Program Design. Lecture Notes on Computer Science, Vol. 44. Springer Verlag, 1976, pp. 236ñ262.
[Jac94] Michael Jackson. Software development method. in A Classical Mind: Essays in Honour of C.A.R. Hoare, Prentice Hall International Series in Computer Science, A. W. Roscoe, ed.Prentice Hall, 1994, pp. 211-230.