URLyBird Requirements

[Kris Reid]

I'm working on the URLyBirrd project and am having trouble determining the requirements.

In the section "Background"
It states that the CSR's use the application. They need to be able to generate a list of accommodations that match a customer's criteria.

I'm guessing the CSR's can then book the accommodation for the customer using a customer number. This isn't stated.


The project outline also states that you must implement the DMMain interface.
This has methods create and delete.

Do the CSR's need to have access via the GUI interface to create and delete records?

I'm basically asking what functionality needs to be available via the GUI?

Thanks

[Andrew Monkhouse]

Hi Kris,

In the section "Background"
It states that the CSR's use the application. They need to be able to generate a list of accommodations that match a customer's criteria.

I'm guessing the CSR's can then book the accommodation for the customer using a customer number. This isn't stated.

Correct. In your instructions you should find text similar to "The id value (an 8 digit number) of the customer who has booked this. Note that for this application, you should assume that customers and CSRs know their customer ids." (from the database schema section), and from the user interface section: "It must allow the user to book a selected record, updating the database file accordingly".

Do the CSR's need to have access via the GUI interface to create and delete records?

Most candidates in this forum do not provide such functionality.

I'm basically asking what functionality needs to be available via the GUI?

It is up to your interpretation of the requirements. Once you have made your decisions, document them in your design decisions document.

When in doubt, refer to the following line (if you have it) in your instructions: "You will not receive extra credit points for work beyond the requirements of the specification."

In my opinion, the assignment is really designed to show your mastery of various J2SE concepts. A GUI that allows search / view / book already shows mastery of many standard GUI design concepts. Adding an extra screen for create/delete/unbook will not really show any new GUI concepts.

However there are some specific concepts (especially relating to locking and thread safety) that are shown in the create/delete methods in the Data class.

Regards, Andrew

[Charles Fung]

Andrew Monkhouse: A GUI that allows search / view / book already shows mastery of many standard GUI design concepts. Adding an extra screen for create/delete/unbook will not really show any new GUI concepts.

I think the create/delete GUI imposes more design questions:

On the GUI side, assume that you use these typical CRUD workflow:
search / book
search / delete
The search in each case has a different criterion: search for book should return only valid entries that can be booked (room in the future, 48 hours rule, etc), while search for delete should return all entries that can be deleted (rooms at any time, booked rooms(?), etc). They may return different set of entries, but we have only one search(String []) method in the interface. You'll need some creative way to do it.

On the data server side, if you cache the records in memory, the create/delete will change the cache and that needs to be protected for thread-safety.

[Andrew Monkhouse]

Hi Charles,

On the GUI side, assume that you use these typical CRUD workflow:
search / book
search / delete
The search in each case has a different criterion: search for book should return only valid entries that can be booked (room in the future, 48 hours rule, etc), while search for delete should return all entries that can be deleted (rooms at any time, booked rooms(?), etc). They may return different set of entries, but we have only one search(String []) method in the interface. You'll need some creative way to do it.

I don't see any additional GUI concepts being used here.

Nor do I see any new programming concepts being used. We already have the issue where the Data's search method must return records that perform a "starts with" match, while the GUI requires an "exact match". In addition, the URLyBird candidates also have the date issue to deal with. So a successful candidate will have already shown that they can handle applying business logic creativly using provided interfaces.

On the data server side, if you cache the records in memory, the create/delete will change the cache and that needs to be protected for thread-safety.

True, however this would presumably be done at the Data class level (or lower if you are using the Fa�ade design pattern), so you have to do this anyway.

Regards, Andrew

[Kris Reid]

I am using 2 JComboBox one with set of all the hotel names and the other a set of all the hotel locations. Do you think this is ok for the search function?

[Charles Fung]

Andrew,

Say, I have these hotel rooms:
1. Hilton 2004-Oct-01
2. Hilton 2005-Jan-26
3. Hilton 2005-Oct-01

When the client searches 'Hilton' for booking, the view should ideally show #2 only , so the client cannot book rooms that have expired or beyond 48 hours from now. This also meets GUI usability consideration.

If the client searches 'Hilton' for deletion, the view should diaplay all three. This allows the client to delete any room for data cleanup.

My point is the search mechanism should be smart enough to handle this. I maybe thinking too deep and there are certainly other ways to work around it, but I found it to be challenging to accomplish this with the given DB interface.

Regards,

[Eric Chang]

I would not see the point in making the Search function any smarter than to fit the requirements. I don't think you would ever see any application with a Search for Records to Delete and a Search for Records to Update. I to would just include a Search method and you would narrow down your search based on the criteria you fill in (in my case: Hotel Name and Hotel Location).