Mapping models to Code

A transformation aims at improving the design of the system with respect

to some criterion.
• Four types of transformations :
model transformations, refactorings, forward engineering and
reverse engineering.
A model transformation improves the compliance of the object design
model with a design goal.
A refactoring improves the readability or the modifiability of the source
code
A Forward engineering improves the consistency of the source code with
respect to the object design model.
A Reverse engineering tries to discover the design behind the source code.
Model transformation is applied to an object
model and results in another object model.
• The purpose of object model transformation
is to simplify or optimize the original model,
bringing it into closer compliance with all
requirements in the specification.
• A transformation can also add information to
the model or remove information from it.
• A transformation may add, remove, or rename
classes, operations, associations, or attributes.
Refactoring
A refactoring is a transformation of the source
code that improves its readability or modifiability
without changing the behavior of the system .
Refactoring aims at improving the design of a
working system by focusing on a specific field or
method of a class.
The refactoring is done in small incremental steps
that are interleaved with tests.
The existence of a test driver for each class allows
developers to confidently change the code.
Forward engineering is applied to a set of model
elements and results in a set of corresponding
source code statements, such as a class
declaration, a Java expression, or a database
schema.
• The purpose of forward engineering is to
maintain a strong correspondence between the
object design model and the code, and to
reduce the number of errors introduced during
implementation, thereby decreasing
implementation effort.
Reverse engineering is applied to a set of source
code elements and results in a set of model
elements.
• The purpose of this type of transformation is to
recreate the model for an existing system, either
because the model was lost or never created.
• Reverse engineering creates a UML class for each
class declaration statement, adds an attribute for
each field, and adds an operation for each
method.
• CASE tools support reverse engineering.
• Transformation Principles
To avoid introducing new errors, all transformations should follow
these principles:
• Each transformation must address a single criteria: A
transformation should improve the system with respect to only one
design goal.
• Each transformation must be local: A transformation should
change only a few methods or a few classes at once.
• Each transformation must be applied in isolation to other
changes: Transformations should be applied one at the time.
• Each transformation must be followed by a validation step:
After completing a transformation and before initiating the next one,
validate the changes
 Mapping Activities
We focus on transformations during the
following activities:
• Optimizing the Object Design Model
• Mapping Associations to Collections
• Mapping Contracts to Exceptions
• Mapping Object Models to a Persistent
Storage Schema
Optimizing the Object Design Model
• The analysis model focuses on the functionality of the
system and does not take into account system design
decisions.
• During object design, we transform the object model to
meet the design goals identified during system design,
such as minimization of response time, execution time,
or memory resources.
• four simple but common optimizations:
1. adding associations to optimize access paths
2. collapsing objects into attributes
3. delaying expensive computations
4. caching the results of expensive computations.
1.Optimizing access paths
a. Repeated association traversals.
To identify inefficient access paths,
identify operations that are invoked often and examine, with
the help of a sequence diagram, the subset of these
operations that requires multiple association traversal.
Frequent operations should not require many traversals, but
should have a direct connection between the querying object
and the queried object
If that direct connection is missing, you should add an
association between these two objects.
b. “Many” associations.
For associations with “many” multiplicity, you
should try to decrease the search time by
reducing the “many” to “one.”
This can be done with a qualified association
If it is not possible to reduce the multiplicity of
the association, you should consider ordering or
indexing the objects on the “many” side to
decrease access time.
c. Misplaced attributes.
Another source of inefficient system performance is
excessive modeling.
During analysis many classes are identified that turn out to
have no interesting behavior.
If most attributes are only involved in set() and get()
operations, you should reconsider folding these attributes
into the calling class.
After folding several attributes, some classes may not be
needed anymore and can simply removed from the model.
2. Collapsing objects:
Turning objects into attributes
After the object model is restructured and
optimized a couple of times, some of its
classes may have few attributes or behaviors
left.
Such classes, when associated only with one
other class, can be collapsed into an attribute,
thus reducing the overall complexity of the
model.
3.Delaying expensive computations
Often, specific objects are expensive to create. However, their
creation can often be delayed until their actual content is
needed.
4.Caching the result of expensive computations
Some methods are called many times, but their results are
based on values that do not change or change only infrequently.
Reducing the number of computations required by these
methods substantially improve overall response time.
In such cases, the result of the computation should be cached as
a private attribute
 Mapping Associations to Collections

Associations are UML concepts that denote collections

of bidirectional links between two or more objects.
Object-oriented programming languages, however, do
not provide the concept of association.
Instead, they provide references, in which one object
stores a handle to another object, and collections, in
which references to several objects can be stored and
possibly ordered.
References are unidirectional and take place between
two objects.
• Unidirectional one-to-one associations.
• Bidirectional one-to-one associations.
• One-to-many associations.
• Many-to-many associations.
• Qualified associations.
• Associations classes
 Mapping Contracts to Exceptions
A simple mapping would be to treat each operation in the contract
individually and to add code within the method body to check the
preconditions, postconditions, and invariants relevant to the operation:
• Checking preconditions. Preconditions should be checked at the
beginning of the method, before any processing is done.
• Checking postconditions. Postconditions should be checked at the end
of the method, after all the work has been accomplished and the state
changes are finalized.
• Checking invariants. When treating each operation contract individually,
invariants are checked at the same time as postconditions.
• Dealing with inheritance. The checking code for preconditions and
postconditions should be encapsulated into separate methods that can
be called from subclasses.
• Coding effort. In many cases, the code required for checking
preconditions and postconditions is longer and more complex than
the code accomplishing the real work. This results in increased
effort that could be better spent in testing or code clean-up.
• Increased opportunities for defects. Checking code can also include
errors, increasing testing effort.
• Obfuscated code. Checking code is usually more complex than its
corresponding constraint and difficult to modify when constraints
change. This leads to the insertion of many more bugs during
changes, defeating the original purpose of the contract.
• Performances drawback. Checking systematically all contracts can
significantly slow down the code, sometimes by an order of
magnitude. Although correctness is always a design goal, response
time and throughput design goals would not be met.
 Mapping Object Models to a Persistent
Storage Schema
• A schema is a description of the data, that is, a meta-model
for data
• In UML, class diagrams are used to describe the set of valid
instances that can be created by the source code.
• Similarly, in relational databases, the database schema
describes the valid set of data records that can be stored in
the database.
• Relational databases store both the schema and the data.
• Relational databases store persistent data in the form of
tables (also called relations )
• A table is structured in columns, each of which represents an
attribute.
• A primary key of a table is a set of attributes whose values
uniquely identify the data records in a table
• Sets of attributes that could be used as a
primary key are called candidate keys.
• Only the actual candidate key that is used in the
application to identify data records is the
primary key.
• A foreign key is an attribute (or a set of
attributes) that references the primary key of
another table.
• A foreign key links a data record in one table
with one or more data records in another table.
• Mapping classes and attributes
– When mapping attributes, we need to select a
data type for the database column..
– Next, we focus on the primary key. There are two
options when selecting a primary key for the table.
– The first option is to identify a set of class
attributes that uniquely identifies the object.
– The second option is to add a unique identifier
attribute that we generate.
• Mapping associations
– The mapping of associations to a database schema
depends on the multiplicity of the association.
– One-to-one and one-to-many associations are
implemented as a so-called buried association
[using a foreign key.
– Many-to-many associations are implemented as a
separate table.
• Buried associations. Associations with multiplicity
one can be implemented using a foreign key. For
one-to-many associations, we add a foreign key to
the table representing the class on the “many” end.
For all other associations, we can select either class
at the end of the association.
• Separate table. Many-to-many associations are
implemented using a separate two-column table
with foreign keys for both classes of the association.
We call this the association table. Each row in the
association table corresponds to a link between two
instances.
• Mapping inheritance relationships
Relational databases do not directly support inheritance,
but there are two main options for mapping an
inheritance relationship to a database schema.
In the first option, called vertical mapping, similar to a
one-to-one association, each class is represented by a
table and uses a foreign key to link the subclass tables to
the superclass table.
In the second option, called horizontal mapping, the
attributes of the superclass are pushed down into the
subclasses, essentially duplicating columns in the tables
corresponding to subclasses.