Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Discrepencies between GUI specs and DB specs?

 
Paul Tongyoo
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all--
I was reading through the interface class given for my database and I noticed it defined an operation that isn't explicitly required as a function of my user interface. Has this happened to anyone? Is this normal?
Does the presence of that operation imply that I should support it through my GUI? The instructions mentioned no points would be given for features that went beyond the original specification.

Thanks!
Paul
 
Michael Fitzmaurice
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul
Yes, this is normal, as far as I can tell. The question of whether or not you should make such operations available on the client (whether or not they are ultimately accessible via the GUI) has recently been kicked to death in this thread:
Should lock methods be callable by the client?
You pays your money and you takes your choice...
 
Paul Tongyoo
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Michael--
Thank you for the reply--I can understand why the lock/unlock methods wouldn't be defined in the GUI specs; I'm concerned about the create and delete methods of my db interface.
So just to be clear: even though my DB interface defines operations to create/delete records, should I have to implement the GUI to perform these operations? Sun's specs don't mention creating/deleting records as part of the GUI's functionality.
If there's a use for the create/delete operations beyond the GUI then that makes sense why they wouldn't be in the GUI specs. Or maybe Sun included those operations in the interface in case future GUI updates (they said the GUI should be flexible and allow upgrading) want to provide those features?
Any thoughts?
Paul
 
Michael Fitzmaurice
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul
I understand your question - you are specifically asking whether delete functionality should be built into your GUI. I would say that you should not expect to drop points for omitting this, since it is not required according to your instructions. My instructions only require the GUI to allow search and book, not delete or create, so I will not be adding that functionality to the GUI.
However, this fits into the broader question of whether or not all of the methods of the data access class should be available client-side (whether or not you provide GUI access to them). For example, if you do decide to add delete functionality to your GUI, your server will obviously need to expose the corresponding method. This then begs the question 'Do I need to expose all of the db functionality to the client, even though the specific GUI requirements are much more limited than the db?'.
So, even if you decide not to provide that functionality on your GUI, you may still want to think about whether or not it is available to the client. It all pretty much hinges on your interpretation of the word 'provide', as discussed in the thread above. If you do make it available to the client (which I will not be doing), it does make it easier for you to add it to the GUI later if you feel the need.
 
Bart
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since it is not a requirement for the GUI to do create/delete you should not implement it. By adding it to the GUI, you have made it available to the end user which could possibly violate an undocumented requirement not to have this functionality available.
I would have testing code which can exercise the create/delete and I would use it to populate and clear my data.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bart,
Welcome to JavaRanch.
We don't have many rules here, but one we do have is our Official Policy On Registered Names. This requires you to have both a first and last name in your displayed name. Could you please add a last name to your displayed name? You can do that here.
Thanks,
Andrew
 
Michael Fitzmaurice
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bart... which could possibly violate an undocumented requirement not to have this functionality available

How does one violate an undocumented requirement? If it is not documented, then it is not a requirement, hence you cannot violate it. Otherwise, everything you do could possibly be in violation of something or other that has not been documented, and you would end up doing nothing. Come to think of it, maybe I'll remember that one as an excuse to use at work - 'I didn't want to violate any undocumented requirements, so I haven't written any code today...' . I think we have enough to think about in interpreting the documented requirements.
I agree with your point that having this functionality available in the GUI is not a requirement, and therefore is something you should not do. I think this is quite straightforward - they ain't asked for it, so don't give it to 'em.
However, as I have been hinting, the less straightforward question is whether or not there is a requirement to have this behaviour available to the client (without adding it to the GUI). This is the next logical question to ask yourself after deciding what behaviour should be accessible through the GUI.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic