• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Class diagram and business objects

 
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see an initial class diagram as an extension of the BODM with some more classes (to address some issues more in detail) and attributes for each of the classes. In the assumption this understanding is more or less correct, the more technical class diagram (in the iterations to come) will be extended with implementation related stuff. For example, TO's are introduced, factories, dao's etc.

I always assumed that classes from the initial BODM are automatically used more or less as TO's. I'll explain this by giving an example:



In the BODM will have the classes 'customer', 'product' and 'shopping card'. The class diagram (in which I retake this BODM) will add several classes to solve more detailed problems, and give the classes attributes.

In this example, a product has a base price. But this is not the real price a customer has to pay. The real price depends on the currency of the customer and the import taxes which are bound to his country.

So, to solve this I'm adding a "PaymentService" . This class acts as a real business object since it will calculate the price of each product on the shoppingcard based upon the country of the customer. The payment serivce will use the database and probably some webservices to figure out the currency, the formula to convert to currenty, and the amount of import taxes that should be payed.

In this stage I will also rename "shopping card" to "shopping card service" since it will act as a business object responsible for storing (probably in memory) the products for a certain customer.

Supose this is all the business logic that my application requires, it is centralized in two business object. Now, the class customer and product will be nothing more then classes with data , they will not contain any behaviour. So in fact, they end up being POJO's having only getters and setters.

It it right to use them as TO's later on in the more detailed class diagrams ?
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic