This may give you some ideas:
Blueprinting a Struts Application by Ted Husted - Sample specification and API for the Struts Example application. Struts UML Diagrams (PDF) by Jean-Pierre Schnyder In this case forget about the term "architecture" in this context. You are creating an overall map of how your design satisfies the requirements outlined in the use cases. Model only the "interesting bits" as the trivial aspects will tend to drown out your design.
Travel Light. There is no point repeating the same ActionForm, ActionMapping, ActionClass cluster with slightly different class names over and over again.
Keep focused on Class/Responsibility/Collaboration. Focus a diagram on a small number of classes/objects that collaborate to accomplish a non-trivial task.
Class hierarchies are useful where
polymorphism is important.
Static class diagrams can show collaboration but Communication and Sequence diagrams are usually better because they also show the division of responsibilities.
Have a look over
Introduction to the Diagrams of UML 2.0 to get a sense what each of the diagram types are good for - and then only use them when you have a actual need for them.
Also have a look at
this topic.
Originally posted by ashishk kumar:
I have the use cases in front of me and I have to design the architecture of the presentation tier ONLY.
The use cases are supposed to be used to identify the necessary business functionality. It is possible to build the business layer before the presentation layer. To design the presentation layer
you should at least have an idea of the interfaces that the business layer exposes.
