I am going to build a Online ticket selling systme of a cinema. JSP , servlet, session and entity beans...etc will be used. However, I am still unclear about beans and servlet. Is that "they" will appear together in my project design? For example, JSP is acted as the client layer to collect user's input and those input will pass to the beans in order to carry out certain function and interact with the database. Here, what does servlet do?
In my class diagram, is that 'enough' for me to show my system like following:
JSP class <--> Servlet class <--> Beans Container class <--> DB <--> other classes
Actually, there will be more than 1 jsp pages, is that I should show all of them in my class diagram? or just a single one to represent all jsp pages? (Also, same question about servlet and beans. Should I represent all of them in my class diagram?)
For documentation? You might include a single diagram that illistrates the flow of control from the user interface (HTML) thru your servlet, then on to your business logic layer.
For design/analysis? I would exclude any JSP/servlet oriented diagrams and focus soley on the business layer. The presentation layer is so well understood and defined (via patterns and frameworks) that modeling it would add little value. Use UML as a brainstorming tool to examine the complexities of the system. The value is in the exercise, not the artifact.
Hi, If your purpose is to develop the system (and not documenting the project - refer to Roger's reply), you should model with UML until the design is clear for you. For some parts of the system, it means going to implementation-level detail (operations, attributes, and so on), but for most parts, high-level class diagrams are sufficient. As for servlets and JSPs in particular, they are essentially J2EE components, and as such they are best modeled in a component diagram. If you have trouble with the execution flow, draw an interaction diagram (like sequence for example).
Bruno Collet<br /><a href="http://www.practicalsoftwarearchitect.com" target="_blank" rel="nofollow">www.practicalsoftwarearchitect.com</a><br />- The Paradox of Software Architecture: It is easy to make a complex architecture, but it is difficult to make a simple architecture.