jQuery in Action, 3rd edition
The moose likes OO, Patterns, UML and Refactoring and the fly likes design issues and documentation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "design issues and documentation" Watch "design issues and documentation" New topic

design issues and documentation

Raj Ohadi
Ranch Hand

Joined: Jun 30, 2006
Posts: 316
I have been doing java/j2ee for several years. Mainly I have focused on coding and sometimes I do UML diagram and database ER design as well. But I have not been in an architect role.

I am trying to push myself toward the architect direction (though I know I have to keep learning..). If you're an architect, can you share with me

1) some good j2ee desgin book
2) more importantly, usually what document an architect prepare/deliver when he/she starts designing a j2ee project ? Where can I find some online sample to learn and digest ?
3) any other tips will be appreciated.

Thank you.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The purpose of documentation is to communicate something to someone. So the right documentation is whatever tells somebody what they need to know. Who wants to read it and what do they want to learn?

Written documentation turns out to be a relatively poor medium for transmitting knowledge. Wouldn't it be better if you could stand at a white board and talk it through together? Video conference? Web meeting?

Bottom line is we can't give you a good "standard" or template for written docs. Figure out how they'll be used in your environment and what should be in them - if anything - will be clear. Sorry for such a non-answer.

Sun has a nifty set of J2EE patterns online and in money-for-dead-tree books. TheServerSide.com has several books online. For a more leading-edge view, look at Rod Johnson's Books about J2EE without EJB and J2EE with Spring. If you must have EJBs ook hard at a design with a single stateless session bean and a lot of POJOs.

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
dinesh pande
Ranch Hand

Joined: Apr 07, 2003
Posts: 124
Hi Raj,

I am almost in a similar situation as yours..

The best way to learn how to be an architect is by becoming one. On this occassion , there is no replacement such as reading books/document samples etc.,

And even worse, what is exactly expected from an architect in terms of documentation etc., could be different from one organisation to an other.

Anyway, to point you to a starting place, the best bet would be to gain access to all the architecture documents from all the projects in which you were a programmer/developer. Have a good read at them, and you will know what architects do and ofcourse plenty of templates from them.

After you have digested all of them and still not lost then you may try to appreciate the advantages/disadvantages in each of those architectures. And if you are really ready, just take the requirements document and create an architecture of your own and see how to compares to the one which are already implemented.

Hope that should start you off.
I agree. Here's the link: http://aspose.com/file-tools
subject: design issues and documentation
It's not a secret anymore!