Implementation Recommendations

What

Implementation recommendations

How

The dish

Implementation recommendations

Ingredients

• All diagrams produced so far

Process

The objective of the Implementation phase is to construct a part of the system-to-be based on the models produced in the Design phase. Typically, we will choose to work on a small set of use cases � maybe just a single use case � for the current iteration. If possible, it is preferable to split the classes needed into three packages in order to implement each use case, namely interface, model and function.

Interface

The interface package contains the classes that set up the user interface. Try to avoid calculations and similar actions in these classes.

Model

The model package contains the classes that model the things from the real world which the system-to-be is all about.

Function

he function package contains the classes that glue the interface and the model classes together.

A typical scenario

  1.     The user hits a button in an interface object
  2.     A function object is activated
  3.     The function object reads the relevant parts of the interface object
  4.     The function object decides what to do and interacts with one or more model ojects
  5.     The function object updates the interface object. 

The sequence of implementation

There is no "correct" sequence of implementation, but nevertheless we will try to come up with some good advice. For any given use case you can implement the interface classes and the model classes at the same time and finally implement the function classes. In this way, it is possible to let experts in human-computer interaction focus on the interface and let other developers focus on the "core" of the system-to-be � the so-called business logic.

Unit testing

It is a good idea to make testing an integrated part of the implementation process. Each time a developer has developed a version of a class, the developer should consider testing the class by writing a piece of code that invokes methods of objects of the class and inspects and tests the return values. If the objects interact with other objects where the corresponding classes have not been constructed yet, you can use "dummy"classes � so-called stubs � to represent these objects in the test code.

Consistency

The models produced in earlier stages of the development process are the blueprints for the Implementation phase. It is important to check the consistency between the different models and the classes implemented continuously. It is not unusual that you find another and better way to implement a class, which is not consistent with the blueprints, during the Implementation phase. In this case, you should discuss the situation in the development team and adjust the models to ensure consistency.

Why

Interface, model and function packages

If you split your classes into these three packages, you only have to worry about how to communicate with the user when you design interface classes. Doing the business logic calculations right will be your only concern when designing the model classes. This separation is especially important when your system-to-be will have different user interfaces. For example, if you plan to have PDA and web versions of the system-to-be,then it it possible to use the same model classes in both systems eliminating redundancy problems.

The sequence of implementation

A consequence of the above-mentioned separation concern is that it is possible for the experts in user interfaces to work in parallel with the experts in the business logic.

Unit testing

It is very important to test the individual units before testing a collection of these units. If you skip unit testing and the collection does not perform as planned, you will face serious problems trying to find out where things went wrong.

Checking units continuously will also provide the developers with a sense of progress.

Some system development approaches recommends that you plan the test before programming the classes. The planning of the test process will help you understand the responsibility of the class, and consequently make the programming easier.

Consistency

Different models represent different views on the system-to-be. If these views are not consistent you will get confused and developers will construct parts of the system that do not match each other.