This exercise tests the student’s knowledge of issue models. The student can either draw a graph or use idented text to represent the resulting issue model. The text below shows a simple representation using idented text and tags. Once the issue model is completed, the reader may notice that some of the proposals were not thoroughly discussed and argued and that one of the pseudo requirements (modeled as a criterion) was not met.

Below is an excerpt from a system design document for an accident management system. It is a natural
language description of the rationale for a relational database for permanent storage. Model this rationale
with issues, proposals, arguments, criteria, and resolutions, as defined in Section 12.3.

One fundamental issue in database design was database engine realization. The initial
nonfunctional requirements on the database subsystem insisted on the use of an object-oriented
database for the underlying engine. Other possible options included using a relational database, a
file system, or a combination of the other options. An object-oriented database has the advantages
of being able to handle complex data relationships and is fully buzzword compliant. On the other
hand, OO databases may be too sluggish for large volumes of data or high-frequency accesses.
Furthermore, existing products do not integrate well with CORBA, because that protocol does
not support specific programming language features such as Java associations. Using a relational
database offers a more robust engine with higher performance characteristics and a large pool of
experience and tools to draw on. Furthermore, the relational data model integrates nicely with
CORBA. On the downside, this model does not easily support complex data relationships. The
third option was proposed to handle specific types of data that are written once and read
infrequently. This type of data (including sensor readings and control outputs) has few
relationships with little complexity and must be archived for extended periods of time. Files offer
an easy archival solution and can handle large amounts of data. Conversely, any code would need
to be written from scratch, including serialization of access. We decided to use only a relational
database, based on the requirement to use CORBA and in light of the relative simplicity of the
relationships between the system’s persistent data.

Key: I[1] = issue 1, P[1] = proposal 1, A[1] = argument 1, C[1] = criterion 1, R[1] = resolution to I[1].
I[1]: Which database engine realization?
P[1]: OO DBMS.
A[1] for P[1]: Can handle complex data relationships.
A[2] for P[1]: Buzzword compliant. (see C[1])
A[3] against P[1]: Sluggish for large volumes of data or high-frequency accesses.
A[4] against P[1]: Existing products do not integrate well with CORBA. (see C[2])
P[2]: Relational DBMS.
A[5] for P[2]: More robust engine than OO DBMS.
A[6] for P[2]: Higher performance characteristics.
A[7] for P[2]: Large pool of experience.
A[8] for P[2]: Some relational DBMS integrate well with CORBA.(see C[2])
P[3]: File system
A[9] for P[3]: Good for serial data with simple relationships, including sensor data.
A[10] against P[3]: Need to rewrite many programs to provide similar functionality than a
DBMS, including serialization of access.
P[4]: Combination of P[1,2,3].
C[1]: Database subsystem should use an OO database.(Pseudorequirement)
C[2]: Needs to co-exist with CORBA. (Prior design decision)
R[1]: P[2], because of C[2] and simplicity of relationships of system’s persistent data.