Solution to Lab Assignment #7

OOD - Class diagram

OOD - Scenario (trace) for "write to Cache"

A scenario or trace represents one of the many possible behaviours achieved through the interaction of the classes in a system. Similar to tracing program execution through many if-statements to show that a correct result can be achieved, tracing the completion of a task by a system involves following a sequence of steps. It is also helpfull to mention "who," meaning which object AND type of object is responsible for a certain step to know how responsibility for achieving something is distributed to different classes. Multiple scenarios are typically necessary to show how each of many functions of a system can be achieved.

Strictly speaking, messages are not sent from one class to another but rather from an object of a certain class to another object of another (not necessarily different) class.

Scenarios can help with:

  1. Breaking up the system into classes (analysis)
  2. Documenting how responsibility for a certain task is distributed throughout the system (design)

Scenario for a write to a Cache.

The functions that this program uses and simulates are reads and writes to a cache, therefore, the scenarios for these would be necessary in an OOD document. As an example, here's what a scenario for a "write" should look like. Notice that there are other possible scenarios depending on which paths of any if-statements are taken, the "then" part or the "else" part. For example, "write_back" messages may be sent for some writes to cache and not for others.

In a thorough OOD document each one of the messages that a write to cache can generate would themselves be expanded into scenarios. Also, notice that there are many guidelines and methodologies for what exactly these scenarios should contain (Coad/Nicola proposes one of them), but regardless of their format, they must be present in an OOD document. Scenarios capture the dynamic behaviour of a system, which is otherwise not captured by a class diagram.