Hi, I never did agree with posts which said, in effect:
The specifications do not say anything about 1. Adding a new, unbooked record to the database, 2. Unbooking an already booked record, therefore, I am under no obligation to carry out these operations, and I won't. Furthermore, if I did, I may make inappropriate assumptions and get counted down in my grade.
Do we have to make assumptions? I think so. For we have to at some point state unambiguous requirements for this application; and, this involves making assumptions. I noticed today, that my assignment says that two kinds of people will be using this application: 1. The customer service representative (CSR), and 2. The customer, i.e., the individual from their home or some remote location is implied. I always assumed that if I were to submit my application, that it must handle, at least, adding new records which can be booked at a future time. But, the fact the the home-user might be using this application remotely, means that I now have some reasoning why I would not add either 1) ability to unbook, and 2) ability to add new, bookable record. Because, to add these introduces security concerns. Therefore, this is my reasoning. And, if I had not stumbled upon some legitimate reason such as the above, then I would have implemented both add-ons, with the reasoning that this was a production application. My reasoning now is: this is a production application, but someone else, although it's not state who, when, where, what, but someone else is going to implement these other features in some form or another. And, probably, this other person will expect to use DBMain and Data; or, if I document it, I can say, "no, this other person will be using my server's services, and will not directly use DBMain or Data." I should say, that I most probably will do as stated above; if I can find some reasonable way to address the security concerns (i.e., you don't want Mr. Smith at home saying that Hotel Montura has an open room available to be booked, nor do you want Mr. Smith booking over someone else's booking, nor do you want Mr. Smith unbooking another person's booking), then I might implement these features. For instance, one idea is to come up with roles based upon the ID: range of ID's = someone who can only book (the customer at home) range of ID's = someone who can book, unbook, add new record (the CSR) range of ID's = someone who can add new record (the hotel owner). Then I would say that security will be handled by someone else, and this problem awaits being solved. For instance, anyone could write their own Java code, make up a new ID, and add new records maliciously; so, I might make the assumption that the clients, whether CSR, customer at home, or hotel representative, can be trusted and can be trusted only to use their correct ID. At some point, there may be a front-end which authenticates ID's and passwords (I will definitely not go into this area of passwords and authentication for this application's iteration). Just some thoughts, which some of you may have thought of before, but I never saw any reasoning in this way on this topic yet (though I obviously have not read all the posts). Thanks, Javini Javono [ January 19, 2004: Message edited by: Javini Javono ]
I need a new interior decorator. This tiny ad just painted every room in my house purple.