Hi Kitty, I've been working as a J2EE software engineer for a couple of years, and this is how the projects usually go:
1. Business users and analaysts get together and discuss what they need the product to do. A list of requirements is drawn up and this becomes the requirements document, e.g. application must provide the facility to edit the text on the following web pages... application must prevent unauthorized access etc. It is also common at this stage to consider the usage/load requirements,development time involved, necessary hardware, support requirements and hence budget available to meet these needs for the forseeable future
2. Using the requirements document the business analysts and UI designers come up with a set of screen shots (often a demo too using dynamic HTML) that show how the application will look and feel, and what the inputs and outputs will be, where the data comes from, and where it goes after the various use cases are complete
3. Using the information from step 2 (this is where I come in!) a detailed design document is drafted. The document first describes the high level architecture, technologies and hardware involved. Next it will specify exactly how all the pretty screen shots will work behind the scenes (through UML sequence, class, and activity diagrams). The UML will explain what exactly happens from the moment a request is received to the time the response is committed. Decisions about every layer of the application must be tied down, such as how is security handled(is there an LDAP server we authenticate against, will we use ceritificate-based encryption), how will DB access be achieved(with a framework like Hibernate maybe, or a straight coded DAO pattern), how will logging take place/what will be logged(Log4J, commons logging), how will the application be configured/initialised, how will input validation occur(commons validator), how will the views be rendered(JSPs, tag libraries), what design patterns are going to be employed etc. etc. etc. The most common patterns I use are the MVC(a la Struts),Session Facade(Sessions EJBs),DAO(Entity EJBs),Value/Transfer Object,Service Locator,Template,Abstract Factory. If any of the design seems unfeasible, we may need to go back to the end user and ask if they really, really need a particular piece of functionality
4. The design document is reviewed by a panel of experts external to the project, and if it passes...
5. Coding begins: the framework is put in place, some prototype code is written to ensure all the layers work individually and are happy with each other, and then coding of the use cases begins. I would usually write the JSPs first (hopefully the CSS files would be provided), then write the Struts action classes, then any DB access code. After each logical module of code is complete, it is unit tested using one of the extensions of JUnit (usually StrutsTestCase for the front end, or Cactus for testing EJBs). Throughout coding there will be communication with the end users to clarify anything that needs more detail
6. When all the code is complete and satisfactorily unit tested (does it do everything we said it would, and in the way we said it would do it?) The application is deployed in a Systems Integration Testing environment where it is picked apart by a QA team. Any bugs thrown up are fixed (if possible) by the coders, and after SIT, it is passed to the end user for the final stage of testing. Hopefully by this stage they like the application and don't demand any extra functionality that they allegedly asked for at the beginning. They usually will make some ridiculous claims at this stage, so it's best to get everything in writing all the way through!
7. Oh yes... someone has to support the application in case anything goes wrong when it has been deployed to the production environment. Hopefully that person isn't me!
Hope this gives a bit of insight - as for a complete example, it would be unusual to find one freely available because it's a lot of work to produce a "medium" sized J2EE project and people need to protect their investment. I'm sure some smaller complete examples are available in books...
[ January 19, 2005: Message edited by: Fletcher Estes ]