Information Technology Reference
In-Depth Information
9.12 Managing Implementation
9.12.1 Documenting Transformations
Implementation and transformations enable us to improve specific aspects of the
object design model and to convert it into source code. By providing systematic
recipes for recurring situations, transformations enable us to reduce the amount of
effort and the overall numbers of errors in the source code. However, to retain this
benefit throughout the lifetime of the system, we need to document the application
of the changes to the object design model or source code. Reverse engineering
attempts to alleviate this problem by allowing us to reconstruct the object design
model from source code. If we could maintain a one-to-one mapping between the
source code and the object design model, we would not need any documentation.
Most useful transformations are not one-to-one mappings. As a result, information
is lost in the process of applying transformations (Bruegge and Dutoit
2000
).
Association multiplicity and collections. Unidirectional one-to-many associa-
tions and many-to-many associations map to the same source code. In general,
information about association multiplicity is distributed in several places in the
source code, including checking code in the boundary objects.
Association multiplicity and buried association. One-to-many associations and
one-to-one associations implemented as a buried association in a database schema
suffer from the same problem. Most of the time associations are realized as sep-
arate tables and all information about association multiplicity are lost.
When mapping contracts to exception handling code, we generate checking
code only for preconditions. Postconditions and invariants are not mapped to
source code. Changes in postconditions or invariants make the system inconsistent.
The
following
principles
reduce
consistency
problems
when
applied
systematically:
• For a given transformation, use the same tool. If you are using a modeling tool to
map associations to code, use the same tool when you change association mul-
tiplicities. Modern modeling tools generate markers as source code comments to
enable the repetitive generation of code from the same tool. However, this
mapping can break when developers use different text editors or different asso-
ciation tools.
• Keep the contracts in the source code, not in the object design model. Contracts
describe the behavior of methods and restrictions on parameters and attributes.
Developers change the behavior of an object by modifying the body of a
method, not by modifying the object design model.
• Use the same names for the same objects. When mapping an association to source
code or a class to a database schema, use the same names on both sides of the
transformation. If the name is changed in the model, change it in the source code.
By doing this you make it easier for developers to identify transformations.
