I'll like the discus the follow issue (from my specs) :
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
and its possible impact on the final score(and particular on UI score).
I think that one the most usual mistake here is to provide a UI where you can change some labels(or other attributes) from some UI components but in main the UI remains the same. This is a functional solution but for any "future functional enhancements" the UI class(es) must be changed. A good UI can be extended without (or with minimal) code changing, something like :
The UI remains(no code changing) the same we just plug in/out the features.
What you guys think about ?
Regards M. [ September 21, 2006: Message edited by: Mihai Radulescu ]
The requirements seem pretty vague about this...one thing I do that might fall into this category is to generate the table and search form dynamically based on the schema obtained from the server. I'm not sure how "future functionality enhancements" could be implemented without requiring a new program version, since dynamic class downloading is not allowed.
I'm not sure how "future functionality enhancements" could be implemented without requiring a new program version, since dynamic class downloading is not allowed
Dynamic class downloading is forbidden. This means that all clases must be accesible in your client classpath (always fulfiled due to delivering jar structure), and your server stubs must be compiled via rmic.
But, at least in my specs, nothing is said about dinamic class loading.
I have implemented too a plugabble framework, and the only drawback i can think is that maybe is out of the junior programmer understanding...
Roy, the dynamic class downloading is not covered in this exam. I agree with Oricio here.
Oricio, that exactly what I mean. Pluggable features. The search feature by example. If the actual search is not good enough in the future you just plug a new one. The same logic goes for the add/remove records features or for any other feature. Can you detailate a little bit your (pluggable)architecture ? Thanks.
Regards M. [ September 25, 2006: Message edited by: Mihai Radulescu ]