Advanced Topics in Software Engineering
Methods and Tools for Software Modularity
Readings and Course Schedule
Note: 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.
Most readings are provided as a download here.
Some of these are only accessible from the UCSD
campus or using the UCSD VPN. Papers not posted here will be made available on Piazza under Resources > Resources (yes, there are nested tabs).
- Tuesday (First three readings 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.
- Wikipedia: Refactoring
- Thursday: Early History of Modularity (fill out one form for all four 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. [on Piazza]
- Orthogonality and the DRY Principle, A Conversation with
Andy Hunt and Dave Thomas, Part II by Bill Venners, March 2003.
- Chapter 3: Martin Fowler, UML Distilled, Addison-Wesley, 2003. [on Piazza] (For the upcoming lab only, will not be discussed. Feel free to read later.)
LAB: Identify 4 design decisions that are interwined with another design decision (violating SRP) and/or exposed between classes (violating DRY) and refactor to hide them. Ideally these design decisions should be deemed likely to change, or that the tangling of each design decision with the other code presents problems, such as comprehensibility. Your choice of each design decision should be clearly motivated.
- Thursday - Depending on Interfaces, not Implementations
- (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 Open-Closed Principle", C++ Report, January 1996. [on Piazza]
- Robert C. Martin, "The Dependency Inversion Principle", C++ Report, May 1996. [on Piazza]
- Bonus Reading: Robert C. Martin, "The Liskov Substitution Principle", C++ Report, March 1996. [on Piazza]
- pages 1-23 of Chapter 1: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004. [LINK]
- Chapter 5: Martin Fowler, UML Distilled, Addison-Wesley, 2003. (not for discussion or mark-up.)
LAB: Employ Dependency Inversion to make the app testable (and write, run, and pass the tests). See Piazza for details.
- Thursday: Object-Oriented Design
- (Background/review only, no form or markup) Chapters 3, 5, 6: Martin Fowler, UML Distilled, Addison-Wesley, 2003.
LAB: Apply OO Design to the entire project to identify essential core SRP objects with
interfaces that sound like what that object would do to itself. Refactor the project
to realize the indicated classes.
- Thursday: Micro-Architecture
- finish Chapter 1 (Strategy), pages 24-35: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [LINK]
- Chapter 2 (Observer): Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [LINK]
- Chapter 14 (Mediator), pages 614-15: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [LINK]
- 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.
LAB: Identify all "notifications" and "when's" that are appropriate for Observer pattern and refactor accordingly. Apply Mediators and MVP so that "base" objects (i.e., models, subjects) don't have to manage relationships or be Observers.
- Thursday: The Modularity of "Making" and Configuring
- Chapter 4 (Factory Patterns), pages 109-136 only: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [LINK]
- Bonus reading: Chapter 14 (Builder only), pages 614-615 only: Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates: Head First Design Patterns, O'Reilly Media, 2004 [LINK]
- G. Kiczales, Why Black Boxes are so Hard to Reuse (video), University Video Communications, October 1994.
- G. Kiczales, J. Lamping, C.V. Lopes, C. Maeda, A. Mendhekar, and G.
Murphy, Open Implementation Design Guidelines, Proceedings of the 19th
International Conference on Software Engineering, pp. 481-490,
April 1997. LINK
LAB: Isolate all object creation, initialization, and configuration from other responsibilities
by applying appropriate Factory patterns/idioms and/or Open Implementation. The refactorings
should also be directed at achieving OCP where appropriate (classes having "no reason" to change).
Apply full-on Factory Method to at least one class-creation responsibility. Apply Open
Implementation to at least one class.
- Thursday: Pre-/post-condition semantics revisited
- 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.
LAB: Identify "defensive" classes, and refactor into "contract form" (2)
LAB: Determine the system's architecture, and identify (and document) major architectural violations/inconsistencies in the code. Correct the violations through refactoring, where practical. Document the architecture and critique its strengths and weaknesses. Don't forget to explain what refactorings you had to do to bring the system into compliance.
- K. Lieberherr, I. Holland, and A. Riel. 1988. Object-oriented programming: an objective sense of style. In Conference proceedings on Object-oriented programming systems, languages and applications (OOPSLA '88), Norman Meyrowitz (Ed.). ACM, New York, NY, USA, 323-334. [link]
- "Decoupling and the Law of Demeter", selection from: A. Hunt and D. Thomas, The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley, 352 pages, 1999.
LAB: Identify and remove all violations of the Law of Demeter (object
version, p. 327). Use before/after code samples or related comparison techniques
to illustrate your changes. Use UML sketches or other graphical notations,
as appropriate, to show how removing excessive dependencies have improved the design.
- Thursday: Crosscutting and Aspect-Oriented Programming
- G. Kiczales, Aspect Oriented Programming: Radical Research in Modularity (video), Google TechTalk, May 16, 2006.
- (optional) G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes,
J. M. Loingtier, and J. Irwin, Aspect-Oriented
Programming, 11th European Conference on Object-Oriented
Programming, Springer-Verlag, pp. 220-242, June, 1997.
- (optional) Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., and Griswold, W. 2001. Getting started with ASPECTJ. Commun. ACM 44, 10 (Oct. 2001), 59-65. DOI= http://doi.acm.org/10.1145/383845.383858
- William G. Griswold, Kevin Sullivan, Yuanyuan Song, Macneil Shonle, Nishit Tewari, Yuanfang Cai, and Hridesh Rajan. 2006. Modular Software Design with Crosscutting Interfaces. IEEE Software, vol. 23, no. 1 (January 2006), pp. 51-60. DOI: https://doi.org/10.1109/MS.2006.24
- LAB: Employ AspectJ to your project to better manage crosscutting concerns, improving SRP and bringing the application into better ``architectural compliance''. Employ the XPI method in defining and using pointcuts, e.g., XPI's are part of a provider interface. Reflect on the benefits and drawbacks.
- Thursday - Closing Lecture (readings optional, for reference)
- D.L. Parnas, G. Handzel, and H. Wurges, Design and Specification of the
Minimal Subset of an Operating System Family, Transactions on
Software Engineering, IEEE, SE-2, December 1976. Page
- Chapter 2 of: C.Y. Baldwin and K.B. Clark, Design Rules: The Power of Modularity, vol. 1, MIT Press, 2000.
- Chapter 3 of: C.Y. Baldwin and K.B. Clark, Design Rules: The Power of Modularity, vol. 1, MIT Press, 2000.
- Sullivan, K. J., Griswold, W. G., Cai, Y., and Hallen, B. 2001. The structure and value of modularity in software design. In Proceedings of the 8th European Software Engineering Conference Held Jointly with 9th ACM SIGSOFT international Symposium on Foundations of Software Engineering (Vienna, Austria, September 10 - 14, 2001). ESEC/FSE-9. ACM, New York, NY, 99-108. DOI= http://doi.acm.org/10.1145/503209.503224
Back to CSE 218 Course Page