Closed-book, closed-note, and using Canvas.

Review

Bring your textbook to the review!

These are sample questions; some may be on the exam, but the exam question is likely to be worded differently and there will be questions on other material as well. Use these to make sure you are familiar with each of the topics, to get practice thinking about the sorts of questions you will see, and to make sure you know the technical terminology.

General approach:

  • know material, terminology; be ready to apply it
  • ensure you are telling me all that's relevant
  • be cautious of using the terms in the question in your answer (especially for definitions!)
  • think in terms of answering in sentences
  • If a question asks for a reason, you might ask your self "why?" a couple times to make sure you really do give a reason or otherwise go beyond what's written in the question itself.
    • Good answers typically uses terminology that you were taught in a prerequisite course or this course. If the term is in this course, think about whether you need to define the term. Generally, try to answer how you might if you were at a technical interview for a job in computing.

Topics

The exam will cover all of the material since the beginning of the term. Ask if you are not quite sure what material that includes! Some key things to know:

The waterfall model and where design fits into software processes.

Rational for studying design patterns and how they are communicated.

How to apply the noun identification method to construct domain class diagrams.

The RIBS criteria for classes: you should be able to identify each in good domain classes.

How to describe coupling and cohesion (in general) and their specific types such as "common coupling" and "functional cohesion".

UML notation, especially for class diagrams; practice drawing the notation! Know sequence diagrams to the depth covered in class.

Design patterns, including

  • names, indicators, advantages of using, disadvantages
  • constructing class and sequence diagrams showing the application of a design pattern to a problem
  • writing code illustrating applying the pattern

Don't try to memorize diagrams and code; you will remember just pieces of it and fail to apply key concepts. Understand how the pattern works and you can apply it in new domains.

When to use an abstract class and when to use an interface (in Java).

General design principles such as don't repeat yourself, program to interfaces, not implementations, the open-closed principle (extend, don't modify), and preferring composition to inheritance

Other technical terms discussed in lecture and the textbook(s).

This is not a comprehensive list. But these items tend to show up on quizzes and exams, so provide a solid starting point. Do read the textbook: it gives important context that helps you remember key concepts and explanations.

Terms to Know

Software development and design

  • waterfall model: requirements, design, implementation, verification, maintenance
  • requirements (what) vs. design (how)
  • functional and non-functional requirements (speed, security, robustness)
  • design qualities: efficiency, maintainability, testability
  • object-oriented vs. procedural design
  • user story (“As a … I want … so that …”)
  • removing if statements; why to avoid instanceof

Domain modeling

  • domain (problem-space) classes vs. solution-space classes
  • noun identification method (nouns: classes and attributes; verbs: methods)
  • responsibility vs. behavior
  • RIBS: responsibility, identity, behavior, state
  • attribute (an item without identity)
  • doit classes, system class
  • Single Responsibility Principle (SRP)
  • naming guidelines: avoid abbreviations, singular names, follow standards

UML

  • class diagram: class, attribute, method, stereotype (<<interface>>, <<abstract>>)
  • association (directed, undirected), navigability, multiplicity, role name
  • generalization (is-a, extends) and realization (implements)
  • has-a (association) and needs-a (composition, closed diamond)
  • aggregation (open diamond) and why to not use it
  • minimal clutter; domain-level diagram vs. contract diagram
  • sequence diagram: object (instance), lifeline/timeline, message (that is, a method call), create (new), return

Design principles

  • program to an interface, not an implementation
  • open-closed principle (extend, don’t modify)
  • favor composition over inheritance
  • elements should not refer to their containers
  • don’t repeat yourself (DRY); code duplication
  • abstract class vs. interface

Coupling and cohesion

  • module, component, subsystem, modularity
  • encapsulation, information hiding
  • coupling (goal: low) and cohesion (goal: high)
  • content coupling (e.g., reflection, instanceof)
  • common coupling (global/public static data)
  • control coupling, flags
  • stamp coupling
  • data coupling
  • coincidental, logical, temporal, procedural, communicational, sequential, and functional cohesion

Design patterns in general

  • design pattern elements: name, problem, solution (with diagram), advantages, consequences (costs)
  • behavioral, structural, and creational patterns
  • indicators for applying a pattern

Strategy Pattern

  • Context, Strategy, ConcreteStrategy
  • using inheritance as an alternative to Strategy

Decorator Pattern

  • Component, ConcreteComponent, Decorator (abstract), ConcreteDecorator
  • wrapping/wrapped object, delegation
  • adding behavior at run time; class explosion
  • why not to use float or double for money
  • How java.io uses decorators (but no details such as specific class names)

Observer Pattern

  • Subject, ConcreteSubject, Observer, ConcreteObserver
  • attach, detach, notifyObservers, update
  • one-to-many dependency; events and state changes
  • push model vs. pull model
  • cascading updates

Version control (git)

  • clone, pull, commit, push
  • merge, merge conflict
  • .gitignore: ignoring folders and files

Review Questions

  1. What are advantages of object-oriented designs over non-OO designs (that is, procedural designs: collections of steps)?
  2. What would you tell a student in Data Structures to encourage them to prioritize domain classes in their designs?
  3. In this course we talk about the importance of designing a solution before starting to write code. Does this mean you should completely specify every element of the software before writing code? Explain why.
  4. Give three or more examples of classes that would appear in a solution space but not a problem space.
  5. What are the goals of the noun (and verb) identification method for systems design?
  6. Name 3 things that fail to have identity.
  7. Consider a registration system: what would be good responsibilities for
    • Class, Section, Schedule, Room, Student, Instructor, Professor
    • Draw a class diagram showing the relationships between these (and any other obvious classes).
    • How would advisors be handled in this system?
  8. Suppose a design includes a class called Main that captures the main in a program along with other stuff. Explain how this class violates the RIBS criteria in multiple ways.
  9. Explain how a high-level class diagram (covering just domain classes) is useful in system design.
  10. Explain a possible reason behind the name of the worst type of coupling, "content coupling". That is, explain the use of "content" in that context.
  11. What type of cohesion does a Java program exhibit if it has just one class, Main? Explain.
  12. What is the difference between temporal cohesion and procedural cohesion?
  13. Why do you suppose the highest form of cohesion is termed "functional"?
  14. How would you describe the design pattern for a classroom? What would be the features? What would be reasons to not apply this pattern?
  15. Identify how the Decorator pattern could be applied to a classroom in a software system, describe that system, and draw a diagram showing the application. Which classes need to be abstract or interfaces?
  16. Give significant differences between the Strategy and Decorator patterns (so that a programmer could decide which to use).
  17. Why would it be important that the Observer Pattern be based on observing events?
  18. Give rules for when to apply Strategy, Decorator, and Observer