Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

design low level and high level design

 
kri shan
Ranch Hand
Posts: 1467
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can i design low level and high level design from the Requirements doc for J2EE apps ?
 
Malli Raman
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Malli Raman
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic