Guideline: Creating and Applying Implementation Mechanisms |
Transform design mechanisms into implementation mechanisms in an evolving software design.
Relationships
Related Elements | Design the Solution Developer
Main Description
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.
More Information
Concepts | Analysis Mechanism Architectural Mechanism Design Mechanism Implementation Mechanism
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.