Can anybody suggest me how to relate UML design/any application design with J2EE designing with respect to session facade,frontrunner,message facade,MVC or JDO etc etc????
Thanx in advance
...maybe it's hard for me to answer to your question because i'm quite new to java world, but i'll try!
UML is just a model language and some tools can use it to write simple (the simplest) code.
The most advanced tools are TogetherJ or RationalRose; the simplest is JVision (according to me).
Anyway: uml is to design, that's all!
Reverse-engineering some classes can work, but not the opposite way.
That's all i know/use.
To modify again the query I have asked, all that I need to know is how to make use of UML design in the context of J2EE design pattern all those I have mentioned.
Not sure about where has UML standard move to these days....but certainly you can have JDO, Session Beans, Entity Beans, etc in UML stereotypes format to illustrate a J2EE pattern or simply to model your problem domain or even your persistence strategy, etc.
If I'm still not answering your question, then maybe you can obtain the book, EJB Design Pattern, authored by Floyd M. of theServerSide.com
- Simon See
I have in fact gone through that book by Floyd but did n't find anything as such regarding the perticular issue I have put forward here.
I know all those design pattern used in the industry now-a-days but hardly could able to relate all those conventioanl ways of designing a system.
U know, the patterns like UML,RUP,OOAD all those things seem to be missing when I start thinking about J2EE design pattern.
I dont know how do I relate or make use of my POST-ANALYSIS phase to the EJB(J2EE) design pattern.
anybody else here to discuss more on this topic.
I don't quite understand your stmt here: -
> U know, the patterns like UML,RUP,OOAD all those things seem to be missing when I start thinking about J2EE design pattern.
J2EE design patterns has got nothing to do with RUP. Most of the time patterns used UML to illustrate the pattern problem and solution. OOAD? That's just the analysis and design side of any OO project whether J2EE or smalltalk is used.
I think your problem seems to be a large one. Why not take a step at a time. Concentrate on your domain model first. Then later you can place in design patterns. Your company should establish RUP or a similar one a a process of doing software and UML as the notation of communication and documentation.
Thanx for your prompt response,But,I need more clarification on yr stmt like
"oncentrate on your domain model first. Then later you can place in design patterns."
Ok let me tell u once again abt my problem
Let me say I am finished with Analysis and design phase during the SDLC.
Now time is to go for CODING phase.
My question is here I have to know which J2EE design pattern I must use (all that I have stated above)..
Lets say during design phase I have come out with UML Design where I ahve all those structural and behavioral views of my system.
Now question arises how to make use of them vis-a-vis my J2EE design of any type.
I suppose U understand my problem.
Though right now I am not in a practical phase but thearetically thinking abt this problem.
Can u give me an example so that it could suffice to your reply.
well, I guess you already have a domain model. You may implement it as Plain Old Java Objects or Entity Beans (local interfaces, CMP 2.0).
Now, put some Session Facades around your domain model: they are Stateless Session Beans implementing the workflow described by related use cases. Please don't use a Session Facade per use case; group related use cases in a Session Facade instead.
Finally, design your Front Controller: it's a servlet that takes a client request (usually from a JSP), forwards the request to the Session Facade, waits for some response (usually a Data Transfer Object assembled by the Data Access Object or Entity Bean) and then, based on the response it just got, chooses the JSP to be displayed next.
So you have the following J2EE patterns:
. Front Controller
. Service Locator (to find the Session Facade the client will be interacting with)
. Session Facade
. Data Access Object (if you're using Plain Old Java Objects in your domain model; DAOs won't be needed if you're using Entity Beans)
. Data Transfer Objects (to transfer the information got from the DB by DAOs or Entity Beans to the presentation layer)
You might use more patterns, but the above 5 will suffice 90% of the time.
That's it. Not so simple, but not so complicated either :-).
Is this an answer to your question?
You somewhat answered to my question.Well I got an idea how to make use of UML design pattern in the context of the prevailing J2EE design pattern.
Anyway thanx cris for yr valuable support.
UML (Unified Modeling Language)is just a language. In most of the UML tools we can set Stereotype. During Design Phase you can set these Steriotypes to the classes or rather Objects. You can have Sequence Diagram which gives clear picture of the flow of request or data. e.g. JSP -> FrontController -> BusinessDelegate -> Session Facade -> Entity Bean or DAO
You can name these classes appropriately... The Developers then can see your design and write code accordingly.
I know it's hard to find books or articles addressing J2EE from an architectural point of view. You'll find many books and articles focused on specific design patterns, but almost none explaining how to combine such patterns in a meaningful way.
To be honest, the only book I know that actually tries to fill this gap is "Sun Certified Enterprise Architect for J2EE Technology Study Guide" by Mark Cade and Simon Roberts. It's a very good book, but it's also very concise. Besides, being the first edition it still has some inconsistencies. Even so, in the last part you'll find a sample project that includes all the patterns I mentioned before.
If you take a look at the sample project, you'll find out it uses only a subset of UML. I would advise you to stick to the same subset:
. Class diagrams: use it to describe your domain model. At the architectural level, don't worry about attributes and operations. Use associations only and stereotypes to identify the Session and Entity Bean (if any) classes. Example: <
. Component diagrams: use them to describe the so called Development Architectural View (it describes the static organization of your app in its development environment). Though rarely used, component diagrams are very useful because they allow you to safely distribute the work load and, as a consequence, to keep track of how your project is evolving. Again, use stereotypes to identify JSPs, servlets, session and entity beans.
. Sequence diagrams: use them as a means to show how use cases will make use of the components you've defined. Designers will later take those diagrams and use them as a basis for the detailed design.
Hope this helps a bit more :-),
Nice reply but can You tell me if that book is freely available over net.
Unfortunately, it isn't, Pratap. You can buy a copy from Amazon or Bookpool, for example.