New to Part 2: What should be in the class diagram
david chen
Ranch Hand
Posts: 44
Francis Amanfo
Ranch Hand
Posts: 44
posted 11 years ago
What to put in class diagram?
Some spices, pepper, garlic and not too much salt but don't forget onions. It'll then taste great!
Sorry, trying to be funny but not mean. I would have to say however that your question is too general. Maybe you should read some of the software design books first.
Regards
F
[ January 03, 2006: Message edited by: Francis Amanfo ]
Some spices, pepper, garlic and not too much salt but don't forget onions. It'll then taste great!
Sorry, trying to be funny but not mean. I would have to say however that your question is too general. Maybe you should read some of the software design books first.
Regards
F
[ January 03, 2006: Message edited by: Francis Amanfo ]
Terry McKee
Ranch Hand
Posts: 175
posted 11 years ago
Hey David,
If you browse through the posts here, you will see that people have done it a variety of ways. Most of the posts that I have read indicate that you shouldn't put implementation specific classes into the diagram (like controllers, EJBs, etc.). In fact, many that have done this have had to resubmit their assignment later.
As Francis indicated, reading more about software design (architecture) will help you to make decisions about what is important to put in the class diagrams. People have passed by modifying and people have passed by not modifying the original Business Domain Diagram. The key then is not in so much the decisions you make (although if you make a crazy class model you clearly won't pass), rather, (1) how consistent you are acoss all of your documents and (2) how clearly you justify your decisions in your documentation.
If you browse through the posts here, you will see that people have done it a variety of ways. Most of the posts that I have read indicate that you shouldn't put implementation specific classes into the diagram (like controllers, EJBs, etc.). In fact, many that have done this have had to resubmit their assignment later.
As Francis indicated, reading more about software design (architecture) will help you to make decisions about what is important to put in the class diagrams. People have passed by modifying and people have passed by not modifying the original Business Domain Diagram. The key then is not in so much the decisions you make (although if you make a crazy class model you clearly won't pass), rather, (1) how consistent you are acoss all of your documents and (2) how clearly you justify your decisions in your documentation.
| It is sorta covered in the JavaRanch Style Guide. |