Din Don

Greenhorn
+ Follow
since Apr 29, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Din Don

Hi,

Should we include EntityBean classes in the class diagram ?

Thanks.
Hi,

The part 2 assignment only requires UML diagrams and assumption of the requirements as deliverables. It does not require other documentation to cover application logic, functionalities of classes. These are the main essence of the arhcitecture of an IT system. These information can be implied by the mehtod names and attributes in the class diagram as well as the sequence diagram. But the names have to be very informative. In reality, class/method/attributes name are concise and do tell much about what they represent.

The only place we can document the application logic/functionalities is the assumption deliverable, but as the name itself implied, only assumptions to clear ambiguity of requirement is to be provided.

Can anyone suggest we should document architected functionalities in the 'assumption' deliverable ?
Hi,

Is it reasonable to group classes into packages according to which use case they belong ?

Do we need to show the package of each class in the class diagram ?

Thanks a lot.
Hi,
1. Do I need to include JSP in the class diagrams ? A JSP is not a class but it will be translated to a servlet which is a class.

2. Is it ok to treat servlet as a class and include them in the class diagram ?

Thanks.
Hi All,
According to UML standard, when making up stereotypes/constraint in UML sequence diagram, am I free to use whatever description I wish ?

For example, in the object box for a EJB, I put the stereotype as <<stateless session bean>>, or in a message sent from a servlet to an actor who is a real person, I put down {https} as the constraint. Are these OK ?

Thanks a lot for any advice.