Notes:
Unless otherwise stated, a class meeting format is ``discussion''. Details on the presentation format or the ``required'' status of a particular reading is subject to change.
Readings and Labs are subject to change, don't rush ahead without checking with us first.
Most readings are provided as a download here. Some are only accessible from the UCSD campus or using the UCSD VPN. Papers not posted here will be made available on Canvas under Files.
All Lab assignments will be elaborated on Piazza.
Week 1
Tuesday (the first three readings are strictly optional - Griswold presents with discussion)
W.W. Gibbs, Software's Chronic Crisis, Scientific American, pages 72-81, September, 1994.
L.A. Belady and M.M. Lehman, A Model of Large Program Development. IBM Systems Journal, 15(3), 1976.
D.L. Parnas, Why Software Jewels are Rare, Computer, 29(2), 1996.
Thursday: Early History of Modularity (fill out one form for each reading) [LINKS TO "OFFLINE" READINGS]
D. L. Parnas, Information Distribution Aspects of Design Methodology. Proceedings of the IFIP Congress, vol. 1, pp. 339-344, 1971.
D. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, Communications of the ACM, 15 (12), 1972.
Robert C. Martin, "SRP: The Single Responsibility Principle", from the book Agile Software Development, Principles, Patterns, and Practices.
Andrew Hunt and David Thomas, The Pragmatic Programmer, excerpt: "Don't Repeat Yourself" from Chapter 2.
(No write-up. For use in upcoming Labs only, will not be discussed. Feel free to read later.) Chapter 3: Martin Fowler, UML Distilled, Addison-Wesley, 2003.
Week 2
Tuesday
LAB 1: Identify the design decisions (responsibilities) in the project that are intertwined with another design decision (violating SRP) and/or exposed between classes (violating DRY). Be on the lookout especially for design decisions deemed likely to change, or that the tangling presents problems, such as comprehensibility or flexibility.
Thursday - Depending on Interfaces, not Implementations [LINKS TO "OFFLINE" READINGS]
(background - if OO is new to you or you're somewhat rusty; no write-up) Wegner, P. 1987. Dimensions of object-based language design. In Conference Proceedings on Object-Oriented Programming Systems, Languages and Applications (Orlando, Florida, United States, October 04 - 08, 1987). N. Meyrowitz, Ed. OOPSLA '87. ACM, New York, NY, 168-182. DOI= http://doi.acm.org/10.1145/38765.38823
Robert C. Martin, "The Liskov Substitution Principle", C++ Report, March 1996.
Robert C. Martin, "The Dependency Inversion Principle", C++ Report, May 1996.
HFDP: pages 1-23 of Chapter 1: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004. [online 2020 edition] [online 2004 edition]
(No write-up. To help you write up your Labs.) Chapter 5 (through pg. 68): Martin Fowler, UML Distilled, Addison-Wesley, 2003.
Week 3
Tuesday
LAB 2: Refactor to reorganize the Sprite class hierarchy to also be a type hierarchy. Compose the resulting types instead of concrete classes to achieve Dependency Inversion.
Thursday: OCP, Design Patterns, and the Observer Pattern
Robert C. Martin, "The Open-Closed Principle", C++ Report, January 1996.
HFDP: pages 24-32 of Chapter 1: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004.
HFDP: Chapter 2 (Observer), through p. 60 ("Power up the Weather Station"): Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004.
Week 4
Tuesday
LAB 3: Identify all "notifications" and "when's" that are appropriate for Observer pattern and refactor accordingly so that "base" data objects (i.e., subjects or models) don't have to know about views derived from their data.
Thursday: The Model-View-Presenter Pattern
HFDP: Chapter 14 (Mediator), pages 614-15: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004
K.J. Sullivan and D. Notkin, Reconciling Environment Integration and Component Independence, Proceedings of the SIGSOFT '90 Fourth Symposium on Software Development Environments, December, 1990.
Week 5
Tuesday
LAB 4: Apply Mediators and MVP so that "base" objects (i.e., models or subjects) don't have to manage relationships and "views" don't have the additional responsibility of being Observers.
Thursday: Design Patterns as Architecture - Making MVP a Rule
D. L. Parnas, "Designing Software for Ease of Extension and Contraction," in IEEE Transactions on Software Engineering, vol. SE-5, no. 2, pp. 128-138, March 1979, doi: 10.1109/TSE.1979.234169.
HFDP: Chapter 7: The Adapter and Façade Patterns, pages 255-269 (From "Home Sweet Home Theater" through "The Façade Pattern and the Principle of Least Knowledge").
bonus: "Write code that is easy to delete, not easy to extend", blog post from programming is terrible. Feb. 13, 2016.
Week 6
Tuesday
LAB 5: Apply the Pyramid of Mediators concept, Façades/VMs, and the Principle of Least Knowledge to minimize the "knows about" relation for interfaces as well as SRP in general. That is, apply MVP, Mediators, and/or Facades recursively as necessary to achieve a hierarchy of Mediator/MVPs/Façades in which components know about friends but not strangers.
Thursday: The Modularity of "Making" - Creational Patterns
HFDP: Chapter 4 (Factory Patterns), pages 109-162 only: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004.
HFDP: Chapter 14 (Builder only), pages 614-615 only: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004.
Week 7
Tuesday
LAB 6: Isolate object creation, initialization, and configuration from other responsibilities by applying appropriate Factory patterns/idioms. The refactorings should also be directed at achieving OCP where appropriate (classes having "no reason to change"), as regards object creation. Apply full-on Abstract Factory to at least one compatible-parts-creation responsibility. Apply Builder to at least one composite-class-creation responsibility.
Thursday: Object-Oriented Design
(Background/review only, no form or markup) Chapters 3 and 5 (to pg. 68): Martin Fowler, UML Distilled, Addison-Wesley, 2003.
Week 8
Tuesday
LAB 7: Apply an OO Design analysis to the entire project to identify core domain-relevant responsibilities (SRP objects) with interfaces that sound like what that object would do to itself. Refactor the project to realize the indicated classes.
Thursday: Design at Large - Software Architecture
D. Garlan and M. Shaw, An Introduction to Software Architecture, only pages 1-14 (through §3.6), 16-22 (§4.1), 33-37 (§4.6 to end). In Advances in Software Engineering and Knowledge Engineering, 1993. More information on software architecture is available from Garlan's and Shaw's home pages. (Note that although this article is many pages, it is actually not very long. The margins are wide, the fonts are large, and the figures are large as well.)
E.W. Dijkstra, The Structure of the "THE"-Multiprogramming System. Communications of the ACM, 11(5), 1968.
Readings on the Entity-Component-Systems architecture (write up in a single form):
Entity Component System, Wikipedia.
David Colson, How to Make a Simple Entity-Component-System in C++, david-colson.com, Feb. 2020.
bonus (if you need or want more reading):
What's an Entity System?, Entity Systems Wiki, hosted by wikidot.com.
RDBMS with Code in Systems, Entity Systems Wiki, hosted by wikidot.com.
Week 9
Tuesday
LAB 8: You have two options (think twice about undertaking the second one :):
(1) Determine and document the ideal architecture for your system, based on what it is today, (2) identify (and document) major architectural violations/inconsistencies in the code (relative to (1)). (3) Correct the violations through refactoring, where practical, and document which violations, if any weren't corrected. (4) Explain what refactorings you had to do to bring the system into compliance. (5) Critique your architecture's strengths and weaknesses.
Refactor your system into the ECS Architecture. Explain what refactorings you performed. Critique the result. Note: you can start from the original system, if you wish.
Thursday: Design by Contract - LSP and pre-/post-condition semantics revisited (write-up as a single reading, for annotation combine the PDFs)
Meyer, B. 1992. Applying "Design by Contract". Computer, 25, 10 (Oct. 1992), 40-51. DOI= http://dx.doi.org/10.1109/2.161279
R. Mitchell and J. McKim, Design by Contract: By Example, Chapters 1 and 2.
Week 10
Tuesday
LAB 9: Identify "defensive" (abstract) class implementations and implicitly-contracted interfaces (and abstract classes), and refactor into "contract form". This involves (a) redesigning interfaces (and abstract classes) for good contractable design (as needed), (b) removing defensive code, and (c) writing the contracts for the resulting classes and interfaces.
Thursday - Closing Lecture: A Theory of Modularity (no reading - attendance required)
K.J. Sullivan, W.G. Griswold, Y. Cai, and B. Hallen. The Structure and Value of Modularity in Software Design. Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE-9). Association for Computing Machinery, New York, NY, USA, 99–108, 2001. https://doi.org/10.1145/503209.503224
Based on ideas from this book: C.Y. Baldwin and K.B. Clark, Design Rules, Vol. 1: The Power of Modularity, MIT Press, pp. 483, 1999. https://doi.org/10.7551/mitpress/2366.001.0001 (PDF available)