• 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:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

Class Diagram question...

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

I am a little concerned about my class diagram. Most people here seem to have passed well with just over 20 classes in their class diagram.

I have got just 11, so obviously I could say, well everyone implements it differently, but the difference in number is quite a lot between me and most other of you, so I was starting to think that I may have missed some crucial point that I could suffer from if I hand in the diagram with 11 classes.

I'd like to know, when people create their class diagrams are they including EJB's, VO's and any other components that help with the diagrams understanding, similar to the example in Cale's book, or are these all POJO's?

Thank you for your help!

Regards,
James.
 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i my opinion class diagram only refers to domain model, and is techology indepent., contain the business domain for the problem, not classes about some techical or architectural desitions.
(my class diagram has about 17 classes)
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

You said:

I'd like to know, when people create their class diagrams are they including EJB's, VO's and any other components that help with the diagrams understanding, similar to the example in Cale's book, or are these all POJO's?



Cade's class diagram shows obviously the business object classes and also three workflow helper classes, marked as Stateless Session Beans. These three classes might be implemented as POJOs. So, these classes are somehow just an extension to the business objects. It's logic about creation of objects, search, and control logic which we don't want to have within the business objects.

So, to sum it up: Cade's class diagram is primarily about the business objects and it's almost technology independent.

Regards,
Dan
 
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

Yes, you can deploy you assignment with a small class number and you should be able to pass. For may own experience, I have used only a few classes in my assignment and I have passed with a very good score in the class diagram.

And talking about the business classes in the class diagram, you should attempt that this approach must be used with something else in mind over only enlarge the classe number.

It is considered correct that an class diagram should be technology independent. But using business classes like EJB's in the class diagram it is not considered wrong. I have seem many people following the Cade's example for the assignment and they're using EJB classes in the diagram just because HE DID. But anyone really understand why you should put business classes with your domain model and why Cade's did.

Well, the short explanation is: You have to put business classes at the class diagram when you want to enphatize the DEPENDENCY between the business classes (an EJB for instance) and some domain classes. Maybe it is crucial for the application, document the potential impact of changes in the domain classes, and it's a good idea show that this changes will affect the business classes. Large and complex systems should use this approach everytime.

But, for a small application like the TRS (Travel Reservation System), I don't think that it is essential meet this requirement. For desing pourposes, you could hide this information from the classe domain model.

Anyway, this is my point of view. I can't say that this should be a rule for every enterprise project. Use the good sense for that!

Best Regards!
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ricardo,

Thank you for this nice explanation!

OK, So why do you think Cade showed these three classes implemented as EJBs in the class diagram instead of showing these classes without implementation details?

Regards,
Dan
[ July 11, 2006: Message edited by: Dan Drillich ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic