• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SCEA Beta Part II Level of Details

 
Sohail Naseem
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just start working on part II class & sequence diagrams. What should be the level of details for all diagram? The case study of SCEA for J2ee study guide by Mark Cade uses class name, stereotype and relationship for class diagram no attributes, no operations. Similarly sequence/collaboration diagrams use only operation name for messages without using argument or return type. Same is true for design pattern very simplified single object diagram.

Are details given in Mark Cade bookd good enough to pass exam or we need to add more details like operation arguments, return type, class attributes etc? In that case do we need to make assumptions about some attribute not given in use cases?

Should we strict to use cases given in assigment and we should assume that user will logon to application? or should we add the sequence diagram for example "login use case" although it is not given in the assignment.
This is just example not related to specific contents of assignment
[ November 28, 2007: Message edited by: Sohail Naseem ]
 
Juan Pablo Crossley
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you must work only in the things mentioned in the assignment, that's the requirement document. but if one of them has lack of information, or you must fill the blanks you should write it in the final document as an assumption.

The logon is an example of that, put in the assumptions that your system lays on JAAS and that's it.
 
Juan Pablo Crossley
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question in the same direction of yours, I'm (like many of you) following the Mark Cade's book. In the component diagrams he does not use components to specify any detail of patterns like "Composite View", "Bussiness Delegate", etc. but it's obvious that all the modern application use some kind of those patterns.

Should we put that in the assumptions? something like: "the home and remote interfaces for the EJBs have not been added, because those interfaces have a tendency to clutter the diagram and the developers already know how that an EJB needs a home and remote interface" (Extracted from Mark's book) (off course... this is just an example, I'm trying to avoid the remove of this message... just replace home and remote by Composite View, etc)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic