This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Journey To Enterprise Agility and have Daryl Kulak & Hong Li on-line!
See this thread for details.
Win a copy of The Journey To Enterprise Agility this week in the Agile and Other Processes forum! And see the welcome thread for 20% off.
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Jeanne Boyarsky
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Paul Clapham
  • Junilu Lacar
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Ganesh Patekar
  • Tim Moores
  • Pete Letkeman
  • Stephan van Hulst
  • Carey Brown
  • Tim Holloway
  • Joe Ess

business objects and class/BODM diagram  RSS feed

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:


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:


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 ?

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!