Win a copy of Kotlin for Android App Development this week in the Kotlin forum!
  • 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 ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Devaka Cooray
  • Jeanne Boyarsky
  • Bear Bibeault
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • salvin francis
  • Carey Brown
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

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 ?

All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!