• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • paul wheaton
  • Ron McLeod
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Piet Souris
Bartenders:

Part II : Assumptions and Explanations

 
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Any ideas on:
1. Is there 1 assumption file, or there should be separate assumption for each diagram.
2. Any examples for assumptions (not necessarily real assigment ones)
3. Does each diagram need explanation on how we came up with this design?
Thanks,
Sanz
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is entirely up to you. Keep in mind that the project is intended to be read by someone knowledgable in J2EE and UML. Therefore, you don't need to explain UML or J2EE to the reader. The assumptions/design notes page is only there to explain things that are not immediately obvious to the reader or justify certain design decisions that may not be cut and dry.
In my case, I included less than a page of design notes and I did just fine. Overall, your design diagrams should be self-explanatory and stand on their own. A large part of this is accomplished by picking good class names. When in doubt have a friend look it over...
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sanz,
i have made 1 assumption file only which contains assumptions/design decisions for all diagrams. Seq diag more or less make up for their expln as 'notes comment'. Comp diag decisions FLOWS r documented and class diagrams CONCEPTS r documented...Well i think the examiner will understand.. i would be submitting in a day or two..still doing some fine tuning...as for any example, i can tell u like "Since web svr and app svr r on diff nodes, it is safe to assume that the front business interface of ejbs should have a remote interface " and this is the foundation for my facade; my facade deals with local interfaces also..
 
Ranch Hand
Posts: 1327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
for example you can say ur system doesn't support internationlization
 
sanz nsgha
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all ...
Question to Nishant and others ...
Are you putting stereotypes like <<StatelesSessionBean>> <<EntityBean>> <<ValueObject>> in your class diagram?
The reason I am asking is: as soon as you indicate some object is of type VO, it wont have operation and logic in it and that will change the Class diagram.
 
Nishant Anshul
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Sanz...For ejbs... yes i m stereotyping..but for DAO, VO kinda objects..i m just indicating with suffixes like XXXVO or XXXDAO.. byee
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic