Activity: Implement Design Elements
|
Purpose
| |
| Role: Implementer | |
| Frequency: Repeated throughout each iteration (with the possible exception of Inception iterations when no prototyping is required) | |
Steps
| |
Input Artifacts:
| Resulting Artifacts:
|
| Tool Mentors:
| |
More Information:
| |
| Workflow Details:
|
Prepare for Implementation
Understand the Task/Problem
Before starting with an implementation activity, the implementer must be clear on the scope, as specified in work assignments and iteration plans. An implementation task can be focused on achieving some specific functionality (such as implementing a design use-case realization or fixing a defect) that involves implementing several design elements that contribute to that functionality. Alternatively, an implementation task can be focused on a particular design element, such as a Design Subsystem or a Design Class, implementing it to the extent required for the current iteration.
Configure Development Environment
This activity results in creating or updating one or more files (Implementation Elements). As part of preparing for implementation, the implementer must ensure that his or her development environment is correctly configured so that the right element versions are available. This should be done for both the elements to be updated and any other elements required for compilation and unit testing. The implementer must be aware of, and follow, the project's configuration and change management procedures. These procedures describe how changes are controlled and versioned, and how they are delivered for integration.
Analyze Existing Implementation
Before you implement a class, consider whether there is existing code that can be reused or adapted. Understanding where the implementation fits into the architecture and design of the rest of the system can help the implementer identify such reuse opportunities. It can also ensure that the implementation fits with the rest of the system.
Implement Incrementally
It is recommended that you implement incrementally by compiling, linking and running some regression tests a couple of times a day. It is important be aware that not all public operations, attributes and associations are defined during design.
When dealing with defects, ensure that you have fixed the problem, not the symptom. The focus should be on fixing the underlying problem in the code. Make one change at a time because fixing errors is in itself an error-prone activity. It is important to implement the fixes incrementally to make it easy to locate the origin of any new errors.
The implementer must be aware of, and follow, any project-specific implementation guidelines, including programming guidelines for the specific programming languages.
Transform Design to Implementation
There are various techniques for transforming design to implementation. Here are some examples:
- Platform-specific visual models can be used to generate an initial code
framework. This code framework can be further elaborated with additional code
not specified in the design.
- Models can be detailed and used to generate executable prototypes. Both
structure (class and package diagrams) and behavior diagrams (such as state
and activity diagram) can be used to generate executable code. These prototypes
can be further refined as needed.
- Models can also be detailed to the point where the model completely represents
the implementation. In this case, rather than transform an abstract design
to a code implementation, you take the design and add implementation details
directly in the model.
- The design may be platform independent to varying degrees, and platform
specific design models or code may be generated via transformations that use
various rules to decide how high level abstractions should be mapped to platform
specific elements. This is the focus of the Object Management Group (OMG)
Model Driven Architecture (MDA) (http://www.omg.org)
initiative.
- Standard patterns can also be applied to generate design and code elements from related design and implementation. For example, a standard transformation pattern can be applied to a data table to create java classes to access the data table. Another example is using an Eclipse Modeling Framework (http://www.eclipse.org/emf/) model to generate code for storing data that matches the model, and to generate a user interface implementation for populating data.
In all cases, however, some design abstraction is detailed to become the implementation, either manually or through the application of some automated transformation.
Complete the Implementation
As described in the previous step, transformation of design to implementation can result in varying degrees of completeness of implementation. It may be a complete and acceptable implementation. Typically, however, there is substantial effort required to complete the implementation. For example:
- Tuning the results of transformation (for example, to improve performance
or to improve the user interface)
- Adding missing details, such as:
- completing operations described in the design
- adding supporting classes, operations, and data structure
Evaluate the Implementation
This is where you verify that the implementation is fit for purpose. In addition to testing (described in other activities), some additional checks are often useful:
- Read through the code. Consider keeping a checklist of common mistakes that you make in your implementations.
- Use tools to check the code for errors. For example, a static code rule checker, or compiler set to detailed warning level.
- Use tools that can visualize the code. Code visualization can help an implementer identify patterns such as excessive coupling, circular dependencies, and so forth.
Provide Feedback to Design
As designs are implemented and tested, errors that affect the design are inevitably discovered. If a design abstraction is maintained for future maintenance efforts, or for contractual or communication reasons, then the design has to be updated.
How this is done depends on the project's configuration and change management process. Generally, if the required change is small, and the same individual is designing and implementing the class, then there is no need for a formal change request. The individual can do the change in the design.
If the required change has a broad impact, for example a change in a public operation, then it may be necessary to submit a formal change request.
