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

Help needed for Design choice

 
Reshma Das
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
someone pls give a valid reasons for the following .
1. Extending Data class than adding new functionality in Data class itself.
2. Having 2 seperate jar files for client.jar and server.jar. The common classes like DataInfo,... jared in both jar files.
3. do we have to give UML diagram ,sequence diagram in design document?
4. what is the structure of user documentation.
5. what is the advantage of locking/unlocking seat from server side over client side.
pls reply asap.
 
Kalichar Rangantittu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO:
1. Extending Data class than adding new functionality in Data class itself.
Do we really need to extend Data? Is data in a working condition as is? What will extension provide you with? Once you ask these questions, I guess you will hit the answer.
2. Having 2 seperate jar files for client.jar and server.jar. The common classes like DataInfo,... jared in both jar files.
Convinience I think. Its easier to run. IMHO you dont really need to provide that. If the program asked for dynamic class loading, using webstrart etc, then maybe we could do a lot of fancy stuff. Looks to me they will unjar your file and run whatever you tell them to.
3. do we have to give UML diagram ,sequence diagram in design document?
Questions to ask. Is this a UML exam? Will the evaluator think higher of your abilities if you do provide them or will they simply get bored???
Might not hurt if you provide a few where you feel is important.
4. what is the structure of user documentation.
I am going to document how to exactly use the tool.

5. what is the advantage of locking/unlocking seat from server side over client side.
I prefer server side locking as you could easily ensure transactions work as they must, allowing the client to handle the procedure is more of a hassle with more room for error. Also consider the events that will work out: Client calls lock(), Client calls read(), Client calls modify(), Client calls unlock(). How many remote calls are we talking??? If instead we had just one single book() or store() method, it would be one single remote call right? You are saving on network traffic by using a server side implementation.
However, as far as our exam goes, looks like a requirement is to expose the entire lock/store/unlcok api to the client. Why did they do this??? Your analysis should apply here. Can we provide the client side api but still use a store/book method? Your justification again.
Hope this helps... Good luck to u.....
 
Reshma Das
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"However, as far as our exam goes, looks like a requirement is to expose the entire lock/store/unlcok api to the client. Why did they do this??? Your analysis should apply here. Can we provide the client side api but still use a store/book method? Your justification again."
Thanks for ur reply. it is very helpful for me. But i didnt understand the exact message from above paragraph. Can u pls explain me in detail?
ther is one more issue which is bothering me.
I created a commonm
interface DataInf extenda Remote{
// definition of all public methods of data throws RemoteException;
}
class Data implements DataInf {
}
class Server implements DataInf{
}
class Client {
DataInf inf;
client() {
if (local)
inf = new Data();
else
inf = Naming.lookup(server);
}
Now iam worried weather this is a good chioce. in local mode my Data implements an interface which extends Remote class.
Can u help me in this design.
Thanks in advance.
 
Kalichar Rangantittu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I meant by the lines you have a doubt is that you should reason take a design decision one way or the other and justify your way out. Lets say you want to go with the server side way, and will handle the entire operation of booking seats with a single book() method which will be a remote call. Now, if you do this, you should explain your design choice and why you are doing it, why exposing the lock/unlock api to client side is not good etc. You have to explain your design choice .
Look for some explanations on the forum by Peter Den Haan. Very good reasoning for your interface problem I would think. Good luck
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic