• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Application Corporate Context

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic