How to Design and Architect a Java/Java EE web application? [closed]

Answer 1

more details

1. Before embarking on coding get the business requirements down. Build a complete list of requested features, sample screen shots (if available), use case diagrams, business rules etc as a functional specification document. This is the phase where business analysts and developers will be asking questions about user interface requirements, data tier integration requirements, use cases etc. Also prioritize the features based on the business goals, lead-times and iterations required for implementation.

2. Prepare a technical specification document based on the functional specification. The technical specification document should cover: Purpose of the document: e.g. This document will emphasize the customer service functionality. Overview: This section basically covers background information, scope, any inclusions and/or exclusions, referenced documents etc. Basic Architecture: discusses or references baseline architecture document. Answers questions like Will it scale? Can this performance be improved? Is it extendable and/or maintainable? Are there any security issues? Describe the vertical slices to be used in the early iterations, and the concepts to be proved by each slice. Etc. For example which MVC [model-1, model-2 etc] paradigms should we use? Should we use Struts, JSF, and Spring MVC etc or build our own framework? Should we use a business delegate to decouple middle tier with the client tier? Should we use AOP (Aspect Oriented Programming) ? Should we use dependency injection? Should we use annotations? Do we require internationalization? Etc. Assumptions, Dependencies, Risks and Issues: highlight all the assumptions, dependencies, risks and issues. For example list all the risks you can identify. Design alternatives for each key functional requirement. Also discuss why a particular design alternative was chosen over the others. This process will encourage developers analyze the possible design alternatives without having to jump at the obvious solution, which might not always be the best one. Processing Logic: discuss the processing logic for the client tier, middle tier and the data tier. Where required add process flow diagrams. Add any pre-process conditions and/or post-process conditions. UML diagrams to communicate the design to the fellow developers, solution designers, architects etc. Usually class diagrams and sequence diagrams are required. The other diagrams may be added for any special cases. State Chart diagram: useful to describe behavior of an object across several use cases Activity diagram: useful to express complex operations. Supports and encourages parallel behavior. Activity and State chart diagram are beneficial for workflow modeling with multi threaded programming. Collaboration and Sequence diagrams: Use a collaboration or sequence diagram when you want to look at behavior of several objects within a single use case. If you want to look at a single object across multiple use cases then use state chart. Object diagrams: The Object diagrams show instances instead of classes. They are useful for explaining some complicated objects in detail such as highlighting recursive relationships. List the package names, class names, database names and table names with a brief description of their responsibility in a tabular form.

3. Prepare a coding standards document for the whole team to promote consistency and efficiency. Some coding practices can degrade performance for example: Inappropriate use of String class. Use StringBuffer instead of String for compute intensive mutations. Code in terms of interface. For example you might decide the LinkedList is the best choice for some application, but then later decide ArrayList might be a better choice. Wrong approach �� ArrayList list = new ArrayList(); Right approach �� List list = new ArrayList(100); Set the initial capacity of a collection appropriately (e.g. ArrayList, HashMap etc). To promote consistency define standards for variable names, method names, use of logging, curly bracket positions etc.
4. Prepare a code review document and templates for the whole team. Let us look at some of the elements the code review should cover: Proper variable declaration: e.g. instance versus static variables, constants etc. Performance Issues: e.g. Use ArrayList, HashMap etc instead of Vector, Hashtable when there is no thread-safety issue. Memory Issues: e.g. Improper instantiation of objects instead of object reuse and object pooling, not closing valuable resource in a finally block etc. Thread-safety issues: e.g. Java API classes like SimpleDateFormat, Calendar, DecimalFormat etc are not thread safe, declaring variables in JSP is not thread safe, storing state information in Struts action class or multi-threaded servlet is not thread safe. Error handling: e.g. Re-throwing exception without nesting original exception, EJB methods not throwing EJB exception for system exceptions, etc. Use of coding standards: e.g. not using frameworks, System.out is used instead of log4j etc. Design issues: No re-use of code, no clear separation of responsibility, invalid use of inheritance to get method reuse, servlets performing JDBC direct access instead of using DAO (Data Access Objects) classes, HTML code in Struts action or servlet classes, servlets used as utility classes rather than as a flow controller etc. Documentation of code: e.g. No comments, no header files etc. Bugs: e.g. Calling setAutoCommit within container-managed transaction, binary OR “|” used instead of logical OR “||”, relying on pass-by-reference in EJB remote calls, ResultSet not being closed on exceptions, EJB methods not throwing EJBException for system exceptions etc.
5. Prepare additional optional guideline documents as per requirements to be shared by the team. This will promote consistency and standards. For example: Guidelines to setting up J2EE development environment. Guidelines to version control system (CVS, VSS etc). Guidelines to deployment steps, environment settings, ant targets etc. Guidelines for the data modeling (any company standards). Guidelines for error handling. Guidelines for user interface design. Project overview document, Software development process document etc.