Concepts: Design Mechanisms

Topics

• Example: Characteristics of Design Mechanisms
• Refining the Mapping between Design and Implementation Mechanisms
• Example: Mapping Design Mechanisms to Implementation Mechanisms

Example: Characteristics of Design Mechanisms

Consider the analysis mechanism for Persistency:

• There might be a need for many (2,000) small objects (200 bytes each) to be stored for a few seconds, with no need for survival.
• There might be a need for several very large objects to be stored permanently on disk for several months, never updated, but with sophisticated means of retrieval.

These objects will require different support for persistency; the following design mechanisms for persistency support might be identified:

• In-memory storage; characteristics: for up to 1 Mb total (size x volume); very fast access for read write update.
• Flash card; characteristics: for up to 8 Mb; slow update and read access; moderate read access.
• Binary file; characteristics: for 100 Kb to 200 Mb; slow update; slow access.
• Database Management System (DBMS); characteristics: for 100 Kb to 2 Gb; even slower read and write access.

Refining the Mapping between Design and Implementation Mechanisms

Initially, the mapping between design mechanisms and implementation mechanisms is likely to be less than optimal but it will get the project running, identify yet-unseen risks, and trigger further investigations and evaluations. As the project continues and gains more knowledge, the mapping needs to be refined.

Proceed iteratively to refine the mapping between design and implementation mechanisms, eliminating redundant paths, working both "top-down" and "bottom-up."

Working Top-Down. When working "top-down," new and refined use-case realizations will put new requirements on the needed design mechanisms via the analysis mechanisms needed. Such new requirements might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. There is also a compromise between the system's complexity and its performance:

• Too many different design mechanisms make the system too complex.
• Too few design mechanisms can create performance issues for some implementation mechanisms that stretch the limits of the reasonable ranges of their characteristics values.

Working Bottom-Up. When working "bottom-up," investigating the available implementation mechanisms, you might find products that satisfy several design mechanisms at once, but force some adaptation or repartitioning of your design mechanisms. You want to minimize the number of implementation mechanisms you use, but too few of them can also lead to performance issues.

Once you decide to use a DBMS to store objects of class A, you might be tempted to use it to store all objects in the system. This could prove very inefficient, or very cumbersome. Not all objects which require persistency need to be stored in the DBMS. Some objects may be persistent but may be frequently accessed by the application, and only infrequently accessed by other applications. A hybrid strategy in which the object is read from the DBMS into memory and periodically synchronized may be the best approach.

Example

A flight can be stored in memory for fast access, and in a DBMS for long term persistency; this however triggers a need for a mechanism to synchronize both.

It is not uncommon to have more than one design mechanisms associated with a client class as a compromise between different characteristics.

Because implementation mechanisms often come in bundles in off-the-shelf components (O.S., and middleware products) some optimization based on cost, or impedance mismatch, or uniformity of style needs to occur. Also, mechanisms often are inter-dependent, making clear separation of services into design mechanisms difficult.

Examples

• The notification mechanism can be based on the inter-process communication mechanism.

• The error reporting mechanism can be based on the persistency mechanism.

Refinement continues over the whole elaboration phase, and is always a compromise between:

• An exact 'fit' with the requirements of the clients of the design mechanism, in terms of the expected characteristics.
• The cost and complexity of having too many different implementation mechanisms to acquire and integrate.

The overall goal is always to have a simple clean set of mechanisms that give conceptual integrity, simplicity and elegance to a large system.

Example: Mapping Design Mechanisms to Implementation Mechanisms

The Persistence design mechanisms can be mapped to implementation mechanisms as follows:

A possible mapping between analysis mechanisms and design mechanisms. Dotted arrows mean "is specialized by," implying that the characteristics of the design mechanisms are inherited from the analysis mechanisms but that they will be specialized and refined.

Once you have finished optimizing the mechanisms, the following mappings exist:

The design decisions for a client class in terms of mappings between mechanisms; the Flight class needs two forms of persistency: in-memory storage implemented by a ready-made library routine, and in a database implemented with an off-the-shelf ObjectStorage product.

The map must be navigable in both directions, so that it is easy to determine client classes when changing implementation mechanisms.