Michael Müller [Michael Müller] - Practical JSF in Java EE 8 : Web Applications ​in Java for the Enterprise

Nowwhere to start? With a prototype of the GUI that can be provided to the customer for further review? In many projects, that might be the option of choice. Some dialogs might be sketched first, including some navigation buttons to show the planned behavior of the software. These prototypes might be built by using presentation software or directly implemented with the target language (here, Java with JSF). The latter method conveys a better feeling to the customer.

Or should we model the big picture and the activity by drawing UML or other diagrams? Or design the data model (for example, with an entity diagram) first?

In practice, youll see all these approaches and many more. Which one is the best way to start a project depends on the project properties and the personal preferences of those involved.

The following procedure is what we call the waterfall model :

1. Collect and write down all requirements

2. Design and document the overall software architecture

3. Write down all planned functionality in detail

4. Program everything

5. Test the whole system

6. Write the user documentation and deliver it

That seems an elaborate method. And by the time the system is delivered, the requirements may have changed or some function may behave differently than how the customer expected (if the customer had a clear view about what to expect). A lesson: the waterfall method mostly fails. Agile methods are preferable. The Agile Manifesto (read it at http://agilemanifesto.org ) was a milestone in this movement.

Chop the project into pieces that are iterative and implemented in increments. For each iteration , we need a short planning session. A piece of software is developed or refined and tested andvery importantdelivered to the customer, or at least to an internal substitute of the customer. Thus, a short feedback loop can be included in the development process. The customer gets a quick overview of the software. Requirement changes can be incorporated quickly. Many agile people dont like the comparison, but in agile, within each iteration the development in fact follows something similar to the waterfall model, though a (very) small waterfall with a short feedback loop.

As a result of an iterative process, the development order might be changed due to influencing factors. And the detailed order becomes a bit less important because after every iteration , or sometimes within it, a correction might be applied.

For data-driven applications like Books (which mostly presents data stored somewhere to the user), I prefer to create dialog boxes as soon as possible. Because the first dialog should present a bit of the future look and feel to the user, we need an overall layout, a kind of frame where the dialog will be embedded.

What data should be used for this dialog? It depends on the size of the project, the number of people involved, their experience, and more. In any case, a good starting point is the data model. Depending on the team structure, the dialog can use this model and mock away any persistence. Database specialists might connect the data model via a service layer to the database.

Mocking data may be useful for testing or if different persons implement different parts for one feature (for example, the database part, service part, or presentation part). To present the work in progress to the user, some real data handling often suits better. As well see after implementing a first dialog in the next chapter, the service layer to access the data can be generalized and reused. So, its no problem to work with persisted data for each dialog from the very beginning.

In case of Books, the data structure isnt difficult to designwe start with the data model and database access and then create the dialog that uses this data. Working iteratively, this procedure is similarly repeated for every dialog.