aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Explaining Client Design? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Explaining Client Design?" Watch "Explaining Client Design?" New topic
Author

Explaining Client Design?

Vikas Sood
Ranch Hand

Joined: Sep 03, 2002
Posts: 109
Hi Friends
My instructions say:
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a control scheme that will support this with minimal disruption to the users when this occurs.

How should i support this in my final design documents.I have used MVC pattern in my client implementation.What are the main points which should be included in design doc,regarding the avove quote
Kindly comment
VikasSood
Bigwood Liu
Ranch Hand

Joined: Feb 26, 2003
Posts: 240
this is what I wondered. Any reply will be great helpful.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

Hi Vikas,
I think you need to consider what changes could happen, and what impact these changes would have on your program.
So what would happen if a column was added? Will your screen(s) attempt to display it?
What about column name changes? Will your searches still work?
Or even worse - columns being reorderd! It could happen - how much recoding would be needed? Any?
And if the system needed more data for a booking (for example with FBNS, if they decided that they needed to know whether the booking was Business class/Economy class or Adult/Child) how extensible is your design to handle the extra fields necessary? Would it require a complete redisign of some screens? If so, what happens to the poor user who now has to learn new screen formats?
There are many more changes that could happen in real life, but I think trying to cater for them would be impossible - the ones I mentioned are the ones that I think we should be able to handle without too much problem.
Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
S. Ganapathy
Ranch Hand

Joined: Mar 26, 2003
Posts: 194
I hope, the requirements indirectly says, MVC is must. As MVC is very flexible, future extensions is very easy to implement. Means, if datamodel changes, we need not change view, or controller. This is what I understood. Any comments?
Regards,
Ganapathy.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

Hi Ganapathy,
Yes, the model can hide the implementation of the datamodel from the end user. So a change to the database schema could be hidden from the view(s) which display it. Or a change to the database type (for example currently flatfile, could become relational database) is likewise hidden from the view(s).
This is subset of one of the benefits of MVC: that each portion of the MVC is only doing one job. So the model is only concerned with providing access to the data source(s) - the model does not have to concern itself with how the data will be displayed. The view(s) are only concerned with displaying the data - they dont care about how to access the data.
Another benefit of the MVC is that you can have more than one view for any given model, So one view can be designed for an application that runs on a local PC (as our applications do), another view can be designed for a web interface, another view can be designed for a WAP interface etc. All these views can be connected to the one model.
Regards, Andrew
S. Ganapathy
Ranch Hand

Joined: Mar 26, 2003
Posts: 194
Hi Andrew,
You are right. Thankyou verymuch.
So I have some light to fine grain my client design.
Regards,
Ganapathy.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Explaining Client Design?