Hello Monica,
I will try my best to give you some information based on the things you had told in this message.
First thing is we are talking about mobile applications, Where time is surely a most important criteria.
So considering that I think it best to have less number of classes than loosing time in generating several objects and using it.
I feel a single servlet is a fine choice, but make sure if your application goes very big then I do not recommend it.
The number of use cases, should be more or less equal to the number of scenarios. I do not think it is a good choice to have one use case for every menu item.
The process
* Should have some use case diagrams, where you show the different scenarios that happen from the perspective of the user ( not something that happens within the application).
* Try to come up with a risk list after analyzing what all you must deliver before some one expects something done by you at a certain point of time. This can be one of the most driving feature that I had experienced in short time projects. Concentrate your thoughts on the high risk elements. (Refer to Larman book for risk list details). If there is a technical challenge please do a small prototype, it is worth doing it.
* Make sure you identify the generic pieces like reporting error, logging..., as these will be used all through your application and so it must be at least be prototyped (atleast make the interface). This can lead to coming up with several grouping of classes, do not decide on the group names but make sure you note it down, no matter you think it was a wise or bad choice as it helps you later.
* Make sure you have a Domain class diagram, which abstracts all the conceptual classes of your application. (this is where u normal end up doing use case realization through sequence diagrams to identify the abstract classes)
* Take each high risk scenarios, come up with the domain model then start you class diagram (do not get deep into it, make it from the conceptual perspective).
* Any high risk workflow, like process like call waiting must have an activity diagram. It really helps you identify the hidden aspects of the application.
* Have the design patterns catalog in front of you while heading for class diagrams, it helps you to see if any design pattern will make a good fit.
* Code development can start simultaneously at this point.
* Once you are at this stage then it is normally a iterative process.
The above process is not 100% right, but I belv. at this short point of time in your case I will take up steps something similar to what I had said above.
Hope it helps.
Please let me know if you have any questions.
