Design mechanism

An architectural mechanism used during the design process, during the period in
which the details of the design are being worked-out (elaborado). They are related
to associated analysis mechanisms, of which they are additional refinements, and
they may bind (vincular) one or more architectural and design patterns (patrones).
There is not necessarily any difference in scale between the analysis mechanism
and the design mechanism? It is thus possible to speak of a persistence
mechanism at the analysis level and the design level and mean the same thing, but
at a different level of refinement. ; A design mechanism assumes some details of
the implementation environment, but it is not tied to a specific implementation (as is
an implementation mechanism). For example, the analysis mechanism for inter-
process communication may be refined by several design mechanisms for inters
process communication (IPC): shared memory, function-call-like IPC, semaphore-
based IPC, and so on. Each design mechanism has certain strengths and
weaknesses; the choice of a particular design mechanism is determined by the
characteristics of the objects using the mechanism.

Architectural pattern

[BUS96] defines an architectural pattern as:

"An architectural pattern expresses a fundamental structural organization schema

for software systems. It provides a set of predefined subsystems, specifies their
responsibilities, and includes rules and guidelines for organizing the relationships
between them."

This is the interpretation we use in the RUP. To elaborate a little: an architectural

pattern is a pattern (that is, a solution template) at a particular scale, and is a
template for concrete software architectures. It deals in system-wide properties and,
typically, subsystem-scale (not class level) relationships. Architectural patterns
seem, by their nature, not to be application domain dependent? The vocabulary of
a particular domain seems not to intrude into the description of the pattern?
Although there is no reason in principle why architectural patterns cannot become
specialized in this way. Compare with analysis pattern. The Software Architecture
Document will present the architectural patterns used in the system.

Analysis mechanism

An architectural mechanism used early in the design process, during the period of
discovery when key classes and subsystems are being identified. Typically
analysis mechanisms capture the key aspects of a solution in a way that is
implementation independent. Analysis mechanisms are usually unrelated
(desligado) to the problem domain, but instead are "computer science" concepts.
They provide specific behaviors to a domain-related class or component, or
correspond to the implementation of cooperation between classes and/or
components. They may be implemented as a framework. Examples include
mechanisms to handle persistence, inter-process communication, error or fault
handling, notification, and messaging, to name a few.

Implementation mechanism

An architectural mechanism used during the implementation process. They are

refinements of design mechanisms, which specify the exact implementation of the
mechanism, and which will also very likely employ several implementation patterns
(idioms) in their construction. Again, there is not necessarily any difference in scale
between the design mechanism and the implementation mechanism. For example,
one particular implementation of the inter-process communication analysis
mechanism is a shared memory design mechanism utilizing a particular operating
system's shared memory function calls. Concurrency conflicts (inappropriate
simultaneous access to shared memory) may be prevented using semaphores, or
using a latching (pasar pestillo) mechanism, which in turn rest upon other
implementation mechanisms.

Framework

A micro- architecture that provides an extensible template (plantilla) for

applications within a specific domain.

Identify Design Mechanisms

To refine the analysis mechanisms into design mechanisms based on the

constraints imposed by the implementation environment.

Categorize Clients of Analysis Mechanisms

Analysis mechanisms provide conceptual sets of services which are used by

Analysis Classes. They offer a convenient short-hand for fairly complex behaviors
which will ultimately have to be worried about, but which are out of scope for the
analysis effort. Their main purpose is to allow us to capture the requirements on
these yet-to-be designed services of the system without having to be concerned
about the details of the service provider itself.

Now we must begin the refine the information gathered on the analysis
mechanisms. The steps for doing this are as follows:
Identify the clients of each analysis mechanism. Scan all clients of a given
analysis mechanism, looking at the characteristics they require for that mechanism.
For example, a number of Analysis Classes may make use of a Persistence
mechanism, but their requirements on this may widely vary: a class which will have
a thousand persistent instances has significantly different persistence requirements
than a class which will have four million persistent instances. Similarly, a class
whose instances must provide sub-millisecond response to instance data will
require a different persistence approach than a class whose instance data is only
accessed through ad-hoc queries and batch reporting applications.

Identify characteristic profiles for each analysis mechanism. There may be

widely varying characteristics profiles, providing varying degrees of performance,
footprint, security, economic cost, etc. Each analysis mechanism is different.
Different characteristics will apply to each. Many mechanisms will require
estimates of the number of instances to be managed, and their expected size in
terms of the expected number of bytes. The movement of large amounts of data
through any system will create tremendous performance issues which must be
dealt with (distribuido con).

Group clients according to their use of characteristic profiles. Form groups of

clients that seem to share a need for an analysis mechanism with a similar
characteristics profile; identify a design mechanism based on each such need.
These groupings provide an initial cut at the design mechanisms. An example
analysis mechanism, "inter-process communication", may map onto a design
mechanism "object request broker". Different characteristic profiles will lead to
different design mechanisms which emerge from the same analysis mechanism.
The simple persistence mechanism in analysis will give rise to a number of
persistence mechanisms in design: in-memory persistence, file-based, database-
based, distributed, etc. The design mechanisms are refinements of the analysis
mechanisms, based on different characteristic profiles.

Inventory the Implementation Mechanisms

Proceed bottom-up and make an inventory of the implementation mechanisms

(see Concepts: Design and Implementation Mechanisms) that you have at your
disposal:

 Mechanisms offered by a middleware product or component framework.

 Mechanisms offered by operating systems.
 Mechanisms offered by a component.
 Mechanisms offered by a class library.
 Legacy code (see also Activity: Incorporate Existing Design Elements)
 Special purpose packages: GUI builder, Geographical Information System,
DBMS, etc.

Determine where existing implementation mechanisms can be used and where

new implementation mechanisms need to be built.

Map Design Mechanisms to Implementation Mechanisms

Design mechanisms provide an abstraction of the implementation mechanisms,

bridging the gap between Analysis Mechanisms and Implementation Mechanisms.
The use of abstract architectural mechanisms during design allows us to consider
how we are going to provide architectural mechanisms without obscuring the
problem-at-hand with the details of a particular mechanism. It also allows us to
potentially substitute one specific implementation mechanism for another without
adversely affecting the design.

Determine the ranges of characteristics. Take the characteristics identified for

the design mechanisms to determine reasonable, economical, or feasible ranges of
values to use in the candidate-implementation mechanism.

Consider the cost of acquisition for purchased components. For candidate

implementation mechanisms, consider the cost of acquisition or licensing, the
maturity of the product, relationship with the vendor, support, etc. in addition to
purely technical criteria.

Conduct a search for the right components, or build the components. You will
often find that there is no apparently suitable implementation mechanism for some
design mechanisms; this will trigger a search for the right product, or identify the
need for in-house development.

You may also find that some implementation mechanisms are not used at all.

The choice of implementation mechanisms is based not only on a good match for
the technical characteristics, but also on the non-technical characteristics, such as
cost. Some of the choices may be provisional; almost all have some risks
attached to them: performance, robustness, and scalability are nearly always
concerns and must be validated by evaluation, exploratory prototyping, or inclusion
in the architectural prototype.

Document Architectural Mechanisms

The role of the Software Architect in this activity is to decide upon and validate
these mechanisms by building, or integrating them, and verifying that they do the
job, and then consistently imposes them upon the rest of the system design. The
software architect role collaborates with the process engineer role to document the
mechanisms and details regarding their use in project-specific design guidelines.
See Activity: Prepare Project Specific Guidelines. The relationship (or mapping) of
analysis mechanisms to design mechanisms to implementation mechanisms, and
the associated rationale for these choices, should be documented in the Software
Architecture Document. The mechanisms themselves are Design Model elements
(such as Design Package, Design Class, and Design Subsystem) which are
detailed in Artifact: Design Model as part of their respective design activities.

Design and Implementation Mechanisms

Introduction to Design and Implementation Mechanisms

A design mechanism is a refinement of a corresponding analysis mechanism (see

also Concepts: Analysis Mechanisms). A design mechanism adds concrete detail
to the conceptual analysis mechanism, but stops short of requiring particular
technology - for example, a particular vendor's implementation of, say, an object-
oriented database management system. As with analysis mechanisms, a design
mechanism may instantiate one or more patterns, in this case architectural or
design patterns.

Similarly, an implementation mechanism is a refinement of a corresponding design

mechanism, using, for example, a particular programming language and other
implementation technology (such as a particular vendor's middleware product). An
implementation mechanism may instantiate one or more idioms or implementation
patterns.

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
characteristics of 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 write access;
moderate read access.
 Binary file; characteristics: for 100 Kb to 200 Mb; slow update; slow read
and write access.
  Database Management System (DBMS); characteristics: for 100 Kb and
upwards (with essentially no upper limit); even slower update, read and write
access.

Note that these speeds are only rated 'slow' relative to in-memory
storage. Obviously, in some environments, the use of caching can improve
apparent access times.

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 (operating systems 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.

Example

 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.

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.

Describing Design Mechanisms

Design mechanisms, and details regarding their use, are documented in the
Artifact: Project Specific Guidelines. The relationship (or mapping) of analysis
mechanisms to design mechanisms to implementation mechanisms, and the
associated rationale for these choices, is documented in the Artifact: Software
Architecture Document.
As with analysis mechanisms, design mechanisms can be modeled using a
collaboration, which may instantiate one or more architectural or design patterns.

Example: A Persistency Mechanism

This example uses an instance of a pattern for RDBMS-based persistency drawn

from JDBC™ (Java Data Base Connectivity). Although we present the design here,
JDBC does supply actual code for some of the classes, so it is a short step from
what is presented here to an implementation mechanism.

The figure Static View: JDBC shows the classes (strictly, the classifier roles) in the
collaboration.

Static View: JDBC

The yellow-filled classes are the ones which were supplied; the others (myDBClass
etc.) were bound by the designer to create the mechanism.

In JDBC, a client will work with a DBClass to read and write persistent data. The
DBClass is responsible for accessing the JDBC database using the
DriverManager class. Once a database Connection is opened, the DBClass can
then create SQL statements that will be sent to the underlying RDBMS and
executed using the Statement class. The Statement class is what “talks” to the
database. The result of the SQL query is returned in a ResultSet object.
The DBClass class is responsible for making another class instance persistent. It
understands the OO-to-RDBMS mapping and has the behavior to interface with the
RDBMS. The DBClass flattens the object, writes it to the RDBMS and reads the
object data from the RDBMS and builds the object. Every class that is persistent
will have a corresponding DBClass.

The PersistentClassList is used to return a set of persistent objects as a result of

a database query (e.g., DBClass.read()).

We now present a series of dynamic views, to show how the mechanism actually
works.

JDBC: Initialize

Initialization must occur before any persistent class can be accessed.

To initialize the connection to the database, the DBClass must load the appropriate
driver by calling the DriverManager getConnection() operation with a URL, user,
and password.

The operation getConnection() attempts to establish a connection to the given

database URL. The DriverManager attempts to select an appropriate driver from
the set of registered JDBC drivers.

Parameters:

url: A database url of the form jdbc:subprotocol:subname. This URL is used to

locate the actual database server and is not Web-related in this instance.

user: The database user on whose behalf the Connection is being made

pass: The user's password

Returns:

a Connection to the URL.

 JDBC: Create

To create a new class, the persistency client asks the DBClass to create the new
class. The DBClass creates a new instance of PersistentClass with default values.
The DBClass then creates a new Statement using the Connection class
createStatement() operation. The Statement is executed and the data is inserted
into the database.

JDBC: Read

To read a persistent class, the persistency client asks the DBClass to read. The
DBClass creates a new Statement using the Connection class createStatement()
operation. The Statement is executed and the data is returned in a ResultSet
object. The DBClass then creates a new instance of the PersistentClass and
populates it with the retrieved data. The data is returned in a collection object, an
instance of the PersistentClassList class.

Note: The string passed to executeQuery() is not necessarily exactly the same
string as the one passed into the read(). The DBClass will build the SQL query to
retrieve the persistent data from the database, using the criteria passed into the
read(). This is because we do not want the client of the DBClass to need the
knowledge of the internals of the database to create a valid query. This knowledge
is encapsulated within DBClass.

JDBC: Update

To update a class, the persistency client asks the DBClass to update. The
DBClass retrieves the data from the given PersistentClass object, and creates a
new Statement using the Connection class createStatement() operation. Once the
Statement is built the update is executed and the database is updated with the new
data from the class.

Remember: It is the job of the DBClass to "flatten" the PersistentClass and write it
to the database. That is why is must be retrieved from the given PersistentClass
before creating the SQL Statement.

Note: In the above mechanism, the PersistentClass must provide access routines
for all persistent data so that DBClass can access them. This provides external
access to certain persistent attributes that would have otherwise have been private.
This is a price you have to pay to pull the persistence knowledge out of the class
that encapsulates the data.
 JDBC: Delete

To delete a class, the persistency client asks the DBClass to delete the
PersistentClass. The DBClass creates a new Statement using the Connection
class createStatement() operation. The Statement is executed and the data is
removed from the database.

In the implementation of this design, some decisions would be made about the
mapping of DBClass to the persistent classes, e.g. having one DBClass per
persistent class and allocating them to appropriate packages. These packages will
have a dependency on the supplied java.sql (see JDBC™ API Documentation)
package which contains the supporting classes DriverManager, Connection,
Statement and ResultSet.