• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Cade's example: Payment

 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi folks,

regarding Cade's example, what's the purpose of the class "Payment" in the class diagram?

thanks, for help,
Harbo
 
Ramon Gill
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It captures details of payments for the order. For example, an order total of $50 could be paid in 2 installments of $25 each. Each payment must be by credit card. Payment could consist of attributes payment date, amount, card number.

Ray
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Cade's example, there is a subsystem called Payment and the Order domain object is broadened to accomodate payment. In the assignment, there is no such payment domain object. Is it a common practice to close the loop, so to speak, by having a payment object? Is it logical that the execution of the pay itinerary use case would result in a payment object being created in the system? Or is it open for interpretation? Is such a broadening logical/required?

I am not sure whether we need to model payment as a class in the system as the requirements dont talk about it.

Any help appreciated..

Parag
 
H. Hafer
Ranch Hand
Posts: 108
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In contrast to the BDOM which shows the business objects and their relationships on a conceptual level, the class diagram shows the design perspective for a software solution.
For me, this means that it does not only show classes which represent business objects, but also classes which help the software to satisfy the requirements -- on a design level.
That is to say, if the requirements state that there is something to pay, all these well-known related "problemlets" can be captured by established constructions as payment, order and so on (kind of domain patterns) -- by maintaining high cohesion, low coupling and separation of concerns. For sure, most likely the requirements don't demand a payment class even there is something to pay: req's are on domain level.

For short: Yes, I think, the class diagram should contain any "helper" classes which help to satisfy the requirements.

HTH,
Harbo
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic