Service Implementation Phase
In this phase or layer you will accomplish the following:
- Consolidate the logical data model
- Create the database
- Implement service contracts
The Static Prototype will directly lead to a logical data model. The initial logical data model can be worked out by a development lead based on these screens. The approach is not that different from coming up with domain objects based on use cases in the rational process. The logical data model can be further refined as the service contracts take shape.
Once the logical data model is in place it makes sense to describe the relationships of tables in an annotated document called an annotated logical data model. Each page will have four or five tables and describe how they are related. This is in contrast to a single logical diagram that spans a wall in an office.
There is one document that I have found most useful in the execution of these projects. I call this the API doc. This essentially documents the service contracts. The table of contents of this document may look like this:
- A list of all the screens in the system.
- Each screen contains:
- A prototype picture of the screen
- A bulleted list of responsibilities or how this screen works (especially the not-so-obvious ones)
- A list of APIs for that screen
- Each API contains:
- What is the responsibility or functionality of the API
- Input objects
- Output objects
Using this document service implementers can write the APIs to satisfy the contracts. This document can also be used by the UI developers to know what the screen looks like and what needs to be done slightly better than the use case document. Or UI developers can help write this document as they start coding each UI screen.
Extreme Prototyping allows you to make a steady progress while postponing the lesser known issues to the rear which gets worked when their turn comes instead of tackling the entire problem once. In the process, it offers the following benefit:
- Early risk avoidance.
- Early savings in cost and resources.
- Guaranteed system quality as the prototype clearly lays out the system.
- Reduced dependency on the skills of Java developers for designing the UI.
- Increased the number of UI developers to distribute the screens during the dynamic prototype. This is possible because you have reduced (or postponed) the dependencies through interfaces.
- Parallel development of services and UI at the same time by allowing simulated services.
- Faster, cheaper, and better product in the end.
Return to ONJava.com.
Where's the business value?
2006-11-17 05:27:10 DaveRooney [View]