CS 509: Design of Software Systems

Quiz #3 covered chapters 7, 8 and 9 in the text book. The solutions below either come from student quizzes or are taken directly from the text book, and are examples of "good" answers to the questions. Some of the questions may have alternate answers, so this page is intended as a guide and does not represent the only definitive solutions.

The three storage management strategies mentioned in the book are listed below.

• Flat Files: Object or data structure contents can be stored in binary by simply writing the data out to a file which is then managed by the OS.
• Relational Database: Data is stored in tables, defined by a schema, where columns typically represent attributes and rows represent the particular values for those attributes.
• Object-oriented Database: Data is stored as objects and associations, and mechanisms are provided for representing OO concepts such as inheritance and abstract data types.

Which strategy to choose for a particular application depends on trade-offs between size of data storage, ease and speed of access, and management features such as multi-user access and recovery from system failures.

The three types of control flow mentioned in the book are listed below.

• Procedure Driven: Control flow is pre-defined and if user input is required, an operation must wait for that input before control can proceed to the next task.
• Event Driven: Control flow is determined by events at run-time such as messages or user actions. An "event loop" runs continuously, waiting for events and responding with an appropriate action when they occur.
• Multi-threaded: An arbitrary number of threads can be created to handle numerous user or system interactions at the same time. Requires language support for threads.

Application domain objects come from requirements and analysis, and represent concepts in the problem domain. Solution domain objects come from system and object design as needed for the eventual implementation, and represent concepts with no counterparts in the problem domain.

The six design patterns covered in Chapter 8 are listed below.

1. Bridge: Decouples the interface of a class from its implementation by using an abstract interface which may be implemented by several concrete classes, which each provide realizations of the interface for different uses.
2. Adapter: Encapsulates legacy code not designed to work with the system by providing an Adapter class which implements the interface expected by the client. The Adapter delegates requests from the client to the legacy code and performs any necessary conversions.
3. Strategy: Encapsulates behavior by decoupling an algorithm from its implementation, or decoupling a policy-deciding class from a set of mechanisms such that different mechanisms can be interchanged transparently at run-time.
4. Abstract Factory: Encapsulates the creation of a family of related objects while shielding clients from the creation process, and from different platforms that provide varied implementations for the same set of concepts.
5. Command: Decouples objects responsible for command processing from the commands themselves; encapsulates requests so they can be executed, undone or queued without concern for the content of the request.
6. Composite: Encapsulates hierarchies by providing a common superclass (component) for aggregate and leaf nodes so they can be treated uniformly through a common interface, and so new types of leaves and aggregates can be added without modifying existing code. The component superclass specifies the services that are shared among leaf and aggregate classes. Aggregates implement services by iterating over each contained component (which can be leaves or other aggregates), while the leaf services do the actual work.

Visibility has to do with the accessibility of a method or an attribute. Any one of the three visibility modifiers used in the book and in Java (public, private, or protected) would be an appropriate example. Public means the method/attribute is accessible by any class. Private means the method/attribute is only accessible within the class where it is defined. And protected means the method/attribute is accessible by the class where it is defined and any sub-class, but not accessible by other outside classes.

An invariant is a predicate which is always true for all instances of a class. They are used at design time to specify consistency constraints among class attributes and methods, which must be maintained during implementation. For example, in a class which models a fraction, an invariant would be that the denominator's value will never be zero. Another example would be in a class that models a meeting, stating that the end time must be after the start time.