Relationship among Design Mechanisms, Implementation Mechanisms and Idioms
An implementation mechanism may utilize one or more language idioms in its realization. Idioms are specific to
programming languages and underlying runtime infrastructure used in a software project. Unlike design mechanisms,
idioms are not portable. Idioms describe how to solve particular programming issues using the features of the selected
language. Object lifecycle management, container iteration, object comparison, copying and memory management are
examples of idioms.
Selecting Implementation Mechanisms
Think about the design problem in which you are involved, bearing in mind how design and implementation mechanisms help
solve creational, structural and behavioral problems. Make an inventory of the implementation mechanisms you have at
your disposal, if any. Review the documented problem space of each mechanism. Review information about each mechanism's
intent, benefits and liabilities. Understand variations of the mechanism you want to use.
Mechanisms are available from many sources, including:
-
Middleware product or component framework.
-
Operating systems.
-
Standalone components.
-
Class libraries.
-
Legacy code.
-
Special purpose packages such as GUI builders, Geographical Information System, DBMS, etc.
-
Books (for example, patterns or platform specific tutorials)
Determine where to use existing implementation mechanisms in the inventory and where building new implementation
mechanisms are required.
Map Design Mechanisms to 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 risks, and trigger further investigations and evaluations. As the project
continues and participants gain more knowledge about the implementation environment, 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
New and refined requirements put new emphasis on the design mechanisms needed via the analysis mechanisms needed. These
requirements might uncover additional characteristics of a design mechanism, forcing a split between mechanisms. There
is also a compromise among the system's complexity, reliability, maintainability and performance:
-
Too many different design mechanisms used in the same area make the system too complex and hard to maintain.
-
Too few design mechanisms can create performance and reliability issues for some implementation mechanisms that
stretch the limits of developer's ability to write effective, low-defect code.
Working Bottom-Up
Investigate the available implementation mechanisms. Find products that satisfy several design mechanisms at once, but
force some adaptation or repartitioning of your design mechanisms. Minimize the number of implementation mechanisms
used, but too few of them can also lead to performance or reliability issues. The trade-off is creating new code to
satisfy implementation mechanism needs.
Because implementation mechanisms often come in bundles in off-the-shelf components (operating systems and middleware
products) some optimization based on cost, impedance mismatch, or uniformity of style will occur. In addition,
mechanisms often are inter-dependent, making clear separation of services into design mechanisms difficult.
Refinement continues over the life of the project and there are always compromises 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 set of mechanisms that give conceptual integrity, simplicity and elegance
to a large system. 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 mechanism. This will trigger a search for the right
product or identify the need for in-house development. You may also find some unused implementation mechanisms in the
inventory.
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.
Base the choice of implementation mechanisms on a good match for the technical characteristics and on the non-technical
characteristics such as cost. Some of the choices may be provisional and almost all have some risks attached to them
such as performance, robustness, and scalability. These are concerns requiring validation by evaluation, exploratory
prototyping, or inclusion in early versions of the architecture.
Applying Implementation Mechanisms
Understand the structure and collaborations of an implementation mechanism before attempting to apply it. Valuable
examples include previous applications or documentation included with the mechanism.
Integrating implementation mechanisms into an existing system might require rework of existing classes and addition of
new classes. The participants of a specific implementation mechanism need meaningful names within the context of the
software's problem domain. The participants have a specific role in realizing the mechanism in the software. Name the
methods and relationships for existing and new classes participating within the mechanism in a way that provides
meaning in the context of the software application and their role in the mechanism.
Finally, implement any code to realize the mechanism in the software. Use the specific language and runtime idioms of
the environment to satisfy these requirements.
|