• 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 ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Class diagram and business objects  RSS feed

 
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
  • 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 ?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!