jQuery in Action, 3rd edition
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Extensiveness of implementing business rules Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Extensiveness of implementing business rules" Watch "Extensiveness of implementing business rules" New topic

Extensiveness of implementing business rules

John Samuels

Joined: Jul 29, 2011
Posts: 9

I can think of many business rules, but am unsure as to which I should implement. The specifications say I should not do more than is asked, but there are certain things the specifications "asks" in a manner which it does not explicitly require with a "must".

For instance, the specifications mention that the customer id is an 8 digit number, but it does not qualify that with a "must implement" of any sort. A subtler, yet much larger issue, is as follows:

1. A client locks, retrieves, and unlocks a certain record.
2. A second client locks, retrieves, unlocks, locks, books, unlocks (i.e. retrieves and books ) the same record.
3. The first client still displays the record as vacant, and so, the CSR books the already-booked record... how should the server react?

Unlike the customer id issue, the specifications does not even mention this. Yet this is such a huge issue that it's hard for me to just glaze over. After all, this could easily happen in real life, and a customer is suddenly out of a room. Being so hard to ignore, I implemented did implement this business rule - before booking, I check whether or not the record is vacant (if the 'owner' field is all blanks, as specified), and notify the user with a JOptionPane if it was already booked. Then again, the specifications did indeed not mention this; however, it does explicitly mention that implementing extraneous things may result in point deductions.

What are you guys' thoughts on this whole business rule issue in general, as well as these two specific cases? As always, your help is greatly appreciated!
Roel De Nijs

Joined: Jul 19, 2004
Posts: 8401

The instructions clearly say a customer id should be an 8 digit number, so that's what I did. No question about that.

I don't think it's a good thing when 2 customers can book the same room without knowing it from each other. You'll get a double booking, 2 people will show up at the hotel and that's just bad publicity for the company. So that's why I added an extra check to see if a room is still vacant before booking (although that's not in the instructions).

You also have something like the 48 hours rule in the instructions. I ignored that one and justified that decision in my choices.txt

SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
Roberto Perillo

Joined: Dec 28, 2007
Posts: 2271

Howdy, Howard.

Champ, one of the goals of this certification is to see how you deal with ambiguities and requirements that are not so clear to understand. Regarding the features that have to be made available to the final users, one thing you can do is verify the User Interface section of the instructions that were provided to you. It normally tells you that you must allow the user to search for rooms, given a criteria, and that you must allow the user to book rooms. These are the features that you must provide to your user. The other things are only "musts" that must be followed.

The usage of the locking mechanism is part of a non-functional requirement. You now just have to follow what is asked in the document and there should be no surprises.

Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
S. Thakker
Ranch Hand

Joined: Aug 11, 2011
Posts: 45
Hi Howard,

Don't overthink it... Its ok for a booking to fail, and you can just reject the second booking. Verify that the room is still available right before you execute the update.

I agree. Here's the link: http://aspose.com/file-tools
subject: Extensiveness of implementing business rules
It's not a secret anymore!