Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part II : Assumptions and Explanations

 
sanz nsgha
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • 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
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • 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...
 
Nishant Anshul
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • 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..
 
Billy Tsai
Ranch Hand
Posts: 1304
  • Mark post as helpful
  • send pies
  • 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
  • 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
  • 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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic