The development cycle using the CDE is as follows:
Write the Java classes that provide the core components of your application.
Using the editor, write the coordination contracts that are necessary to establish the interactions between objects of the classes developed in the previous step.
Use CDE commands to automatically generate Java classes implementing the contracts and to adapt the component classes in order to work with the contracts in which they may participate.
Compile all classes generated in the previous step.
Use the animator to dynamically create, destroy and execute objects and contract instances, hence simulating possible scenarios in your final application.
Develop the remaining classes of your application.
Compile all classes developed in the previous step.
To evolve the application, go to step 1.
Steps 1 and 6 are best performed with a Java integrated development environment (IDE). However, in this guide we only assume the existence of JDK.
In summary, the application will have a 3-tier layered architecture which is developed and evolved in a bottom up fashion, and in which each layer is unaware of the layers above it.
| Layer | Uses Layer(s) | Purpose |
|---|---|---|
| 3. Presentation | 2 and 3 | Establishes application interface (API, GUI) to the environment (human or computational user). |
| 2. Contracts | 1 | A contract superposes interactions between given components. |
| 1. Components | 1 | A component implements core computational activities. |
The editor provides support to develop the second layer, and the animator helps in having an idea of the functionality provided by the superposition of contracts on components, without building the upper layer.
When evolving an application, in general one has to start again in layer 1, as prescribed in step 8 above. However, if properly designed, components will be changed or added only occasionally, and most changes to the application functionality will be achieved by adding new contracts.
To illustrate these general ideas, this guide will use a toy example from a domain with a high degree of agility: banking. The application to be developed is to be used by clerks at the bank agencies to perform simple operations. The application allows the withdrawal and deposit of money in a given account, and the choice of whether a given customer can overdraw a given account or not, and by how much.
The overall steps are:
Two classes are created: Customer and Account. The withdraw and deposit methods of Account have no constraints other than amounts must not be negative and withdrawals may only be performed by the account's owners.
Three contracts, each between a Customer and an Account, are defined: contract Traditional forbids to withdraw more money than available in the account; contract Credit allows overdrawing an account up to a given amount, which is an attribute of the contract; contract LimitedTraditional always withdraws the minimum between the amount asked for and the available money.
The animator is used to create a customer and an account, but different contracts, and to experiment a sequence of deposits and withdrawals, checking that they behave differently. The credit amount is also changed dynamically.
Classes are created to build a simple text-based bank clerk application. Contrary to the animator, where all configuration changes have to be done manually, the application automatically enforces that there is always exactly one contract between each customer/account pair, by default the Traditional contract.
These steps will now be further detailed in the remaining sections.