• 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

Extensiveness of implementing business rules

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

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!
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic