Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

business objects and class/BODM diagram

 
Jim Janssens
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you start from a conceptual model (BODM) you already identified several parts ("nouns") of the system.
For an online shop you might with the following classes in your BODM: "customer [1] ---- has---- [0..*] LineItems".
After that, you can continue to add more system related elements to your BODM so it will form the high level class diagram.

One of those "things" I add are classes containing logic to "do" something with the classes from the conceptual model.
Some of these classes having logic will be responsable for storage.

I add entity bean classes to manage storage, Session bean facades for interaction with the clients and possibly some internal 'processor' classes dealing with business logic. My class diagram then might looks like this:

Scenario1:




As you see the customer is the original class from the BODM. In this case it contains no logic at all, it is a plain java bean only having get/setters and a internal collection to administer the relation with LineItem. In fact by doing this, I automatically treat my BODM class Customer as a Transfer Object. Both client, entity bean and DAO have a dependency with Customer, as they will send it forward an backward.

The customer entity bean will be a composite entity. For me this means that it will have more then one DAO to store the complex object Customer. For example:




I feel that there is a problem with this approach. I think that customer class and the LineItem class should be the BusinessObject itself. Thus I will create business objects from the original classes comming from the BODM rather then creating additional ones.

In order to do this, I must create a business object for LineItem as well, otherwise I cannot indicate the relation of these two classes. The diagram then looks like this:

Scenario2:



This way I still keep the composite view, since my facade session bean will use the customer entity bean (which has a getter to get the customerTO's wich has a getter for LineItemTO's loaded by the LineItem entity bean).


My questions:

a) is scenario 1 a valid solution ? Is it right to treat BODM classes like TO's in the class diagram ?
b) is it valid to use composite entity like in scenario 1 ? Having one entity bean as the "composite view" with several DAO's and no more real entity beans as ?
c) Should I go with scenario 1 or 2 ? or are there other (better) scenario's ?

Thanks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic