jQuery in Action, 2nd edition*
The moose likes OO, Patterns, UML and Refactoring and the fly likes design low level and high level design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "design low level and high level design " Watch "design low level and high level design " New topic
Author

design low level and high level design

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1381
How can i design low level and high level design from the Requirements doc for J2EE apps ?
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Originally posted by kri shan:
How can i design low level and high level design from the Requirements doc for J2EE apps ?


Hi Kri shan,

Based on the customer requirements you will prepare the HLD which gives overview about your project design, System environment , architecture and policies/securities if any. (You can say HLD is for customer!).

You will prepare LLD for your code development which covers the use case preparation,preparing class diagrams, sequence diagrams,object diagrams, program specs. LLD must be a detailed document about your application.
Using your LLD the testing team will prepare the test cases!

Regards,
M.S.Raman.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The "ility" side of your requirements will probably help you get to an architecture: availability, scalability, usability, portability, reliability, compatability, and so on. Sounds like you've already gotten as far as J2EE. That still leaves more architecture choices ... plain servlets? Struts? Custom tag libs? Spring? Hibernate? Your skills and budget and timeline will influence all of those.

Early on I'd try to pick a candidate architecture, take two or three of your best people and implement one business function from end-to-end, browser to database or whatever. Chances are good that once you get some basic issues under control most new business functions will be more of the same: accept a request, read some data, format and display it, accept updates, apply to database, etc. Then you can pile on the whole team. In my life we get a new back-end or external partner every week, so the interfaces to other systems never ends, but you might get lucky with a very stable architecture right off the bat.

Leaping from a requirements document to an object model is not easy the first, um, thousand times. There are whole books on OOAD. Do you have any good ones yet?


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
Malli Raman
Ranch Hand

Joined: Nov 07, 2001
Posts: 312
Hi Stan James,

Can you please help me how the basic flow will go from the requirements in java design prospective. The basic idea I have is,

1) Study the requirements.
2) Prepare the use cases.
3) Based on the use cases identify the domains(objects).
4) Identify the relation between the domain objects.
4i) Prepare the prototype using html pages for web application.
5) prepare the class diagram. (applying pattern will come here)
6) prepare the object diagram(optional)
7) prepare the sequence diagrams (general flow).
8) prepare the deployment diagrams.

Please let me know if I have missed anything.

thanks & Regards,
M.S.Raman
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Those are pretty good text book steps. If you read up on Agile methods, say Scott Ambler's AgileModeling.com, you'll find they try to do "barely sufficient" work in any area. I love that term ... if somebody sayd "But that's not enough!" you can say "Sure it is, it says it must be sufficient right there!" You will likely find you don't need diagram X or document Y at all on this use case, or even a use case. Years ago my team tried to do all the artifacts for every use case and found that all the object interaction diagrams looked exactly the same. The architecture and framework made it so simple to add new business functions that detailed modeling was a waste of time.

The agile folks also like to do all these steps in a matter of minutes. Sit with a domain expert, pick a very small unit of functionality, do the businessy stuff in a short conversation, sit with a fellow coder and do the technical design stuff in a short session.

And don't feel locked into the order. Frinstance, prototypes are great requirement discovery tools. Doing them after all requirements are signed off is too late ... users will surely view them and remember things they forgot or come up with new ideas.

So, why do text books still show these steps in a locked down order? Because schools must make you memorize things that you can repeat on a test. Don't let the man keep you down! No, wrong decade. Anyhow, relax, do what seems to fit the situation, don't feel bad if you have to go back and visit the user again late in the game - better that than deliver something she hates. Read Scott's site. He talks a lot about doing the right thing at the right time.

Have fun! Come here often and tell us how it's working!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: design low level and high level design