Activity: Implement Design Elements

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 focussed 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, 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, which describe how changes are controlled and versioned, and how they are delivered for integration.

Analyse Existing Implementation

Before you implement a class from scratch, consider whether there is existing code that can be reused or adapted. Understanding where the implementation fits in to the architecture and design of the rest of the system can help the implementer identify such reuse opportunities, as well as ensuring that the implementation fits with the rest of the system.

Implement Incrementally

It is recommended that you implement incrementally; compile, link and run 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 faults is in itself an error-prone activity, it is important to implement the fixes incrementally, to make it easy to locate where any new faults are occurring from.

The implementer must be aware of, and follow any project-specific implementation guidelines, including programming guidelines for the specific programming languages.

Implement Operations

To implement operations, do the following:

• Choose an algorithm
• Choose data structures appropriate to the algorithms
• Define new classes and operations as necessary
• Code the operation

Choose an Algorithm

Many operations are simple enough to be implemented straight away from the operation and its specification.

Nontrivial algorithms are primarily needed for two reasons: to implement complex operations for which a specification is given, and to optimize operations for which a simple but inefficient algorithm serves as definition.

Choose Data Structures Appropriate To the Algorithms

Choosing algorithms involves choosing the data structure they work on. Many implementation data structures are container classes, such as, arrays, lists, queues, stacks, sets, bags, and variations of these. Most object-oriented languages, and programming environments provide class libraries with these kinds of reusable components.

Define New Classes and Operations as Necessary

New classes may be found to hold intermediate results for example, and new low-level operations may be added on the class to decompose a complex operation. These operations are often private to the class, that is, not visible outside the class itself.

Code the Operation

Write the code for the operation, starting with its interface statement. Follow applicable programming guidelines.

Implement States

The state of an object may be implemented by reference to the values of its attributes, with nothing special for representation. The state transitions for such an object will be implicit in the changing values of the attributes, and the varying behaviors are programmed through conditional statements.  This solution is not satisfactory for complex behavior because it usually leads to complex structures which are difficult to change as more states are added or the behavior changes.

If the design element's (or its constituents') behavior is state-dependent, there will typically be one or more statechart diagrams which describe the behavior of the model elements which constitute the design element. These statechart diagrams serve as an important input during implementation.

The state machines shown in statechart diagrams make an object's state explicit and the transitions and required behavior are clearly delineated. A state machine may be implemented in several ways:

• for simple state machines, by defining an attribute which enumerates the possible states, and using it to select the behavior for incoming messages in, for example, a switch statement in Java or C++. This solution does not scale very well for complex state machines and may lead to poor run-time performance. See [DOUG98], Chapter 4, 4.4.3 for an example of this method
• for more complex state machines, the State pattern may be used. See [GAM94] for a description of the State pattern. [DOUG98], Chapter 6, 6.2.3, State Pattern, also describes this approach
• a table-driven approach works well for very complex state machines where ease of change is a criterion. With this approach, for each state, there are entries in a table which map inputs to succeeding states and associated transition actions. See [DOUG98], Chapter 6, 6.2.3, State Table Pattern, for an example of this method.

State machines with concurrent substates may be implemented by delegating state management to active objects - one for each concurrent substate - because concurrent substates represent independent computations (which may, nevertheless, interact). Each substate may be managed using one of the techniques described above.

Use Delegation to Reuse Implementation

If a class or parts of a class can be implemented reusing an existing class, use delegation rather than inheritance.

Delegation means that the class is implemented with the help of other classes. The class references an object of the other class by using a variable. When an operation is called, the operation calls an operation in the referenced object (of the reused class), for actual execution. Thus, you can say that it delegates responsibility to the other class.

Implement Associations

A one-way association is implemented as a pointer - an attribute which contains an object reference. If the multiplicity is one, then it is implemented as a simple pointer. If the multiplicity is many, then it is a set of pointers. If the many end is ordered, then a list can be used instead of a set.

A two-way association is implemented as attributes in both directions, using techniques for one-way associations.

A qualified association is implemented as a lookup table (for example, a Smalltalk Dictionary class) in the qualifying object. The selector values in the lookup table are the qualifiers, and the target values are the objects of the other class.

If the qualifier values must be accessed in order, then the qualifiers can be arranged into a sorted array or a tree. In this case, access time will be proportional to log N where N is the number of qualifier values.

If the qualifiers are drawn from a compact finite set, then the qualifier values can be mapped into an integer range and the association can be efficiently implemented as an array. This approach is more attractive if the association is mostly full rather than being sparsely populated and is ideal for fully populated finite sets.

Most object-oriented languages and programming environments provide class libraries with reusable components to implement different kinds of associations.

Implement Attributes

Implement attributes in one of three ways: use built-in primitive types, use an existing class, or define a new class. Defining a new class is often more flexible, but introduces unnecessary indirection. For example, an employee's Social Security number can either be implemented as an attribute of type String or as a new class.

Alternative implementations of an attribute.

It may also be the case that groups of attributes are combined into new classes, as the following example shows. Both implementations are correct.

The attributes in Line are implemented as associations to a Point class.

Provide Feedback to Design

If a design error is discovered in any of the steps, rework feedback has to be provided to the design.

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 affects several classes, for example a change in a public operation, then it may be necessary to submit a formal change request.

Evaluate the Code

This is where you verify that the code is fit for purpose.  The following are checks you should do prior to unit testing:

• Always compile the code. Set the compiler's warning level to the most detailed level.
• Mentally check the operations. Read through the code, trying to follow all the paths, and identify all exception conditions. Do this as soon as anything new is implemented.
• Use tools to check the code for errors. For example, a static code rule checker.

Rational Unified Process