aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Need clarifications on 2 ICE questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Need clarifications on 2 ICE questions" Watch "Need clarifications on 2 ICE questions" New topic
Author

Need clarifications on 2 ICE questions

Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
30. What, if anything, is WRONG with the following analysis use case?
Use case: Sell goods
Description: Accept tender from a customer, package products being purchased, and remove the products from inventory.
Actors: Clerk
Preconditions: Customer has chosen products to buy from inventory.
Postconditions: Products are no longer in inventory. Store cash balance is increased.
Steps:
A.
There are design details intermixed with the requirements.
B.
The actor's actions and system responses are not separated.
C.
"Sell goods" is too broad to be a use case.
D.
There is nothing wrong with this use case.
My answer is D. But I am not really sure.
------------------------------------------------
51. Which of the following are recommended when developing an OO system?
A.
Write a description of the concept that a class represents whenever a new class is declared.
B.
Use interfaces for types or roles that objects may play, independent of their location in the class hierarchy.
C.
Apply design patterns where applicable in the system.
D.
Name classes based on their design specifics, such as "array" or "queue".
I think A, B, C, are all possible. But we need to choose the best answer.
Really need help on these two questions. What do you think?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
See
http://www.coderanch.com/t/98097/patterns/case
and
http://www.coderanch.com/t/96601/patterns/help-IBM-test


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thanks for your reply.
The first question is still not clear, people seem divided evenly.
We need to choose the bestanswer, not correct answers like asked in the previous version of this sample test. A, B, C are all possible, but which one is the best?
Chintan Rajyaguru
Ranch Hand

Joined: Aug 19, 2001
Posts: 341
You seem to agree that D is NOT the answer. So, let us not talk about that. On the other thread, since the people are divided evenly, let us try to look at each choice and find out what is wrong with it.
A. There are design details intermixed with the requirements.
I do not see any design details here. Do you? Accept order, package product, remove product from the inventory are all requirements (if you package product and send it but do not remove the product from the inventory, you are not satisfying the requirement). So, A is not the answer.
B. The actor's actions and system responses are not separated.
I would pick this IF multiple selections were allowed. Let us hold on to this for now.
C. "Sell goods" is too broad to be a use case.
This one sounds promising because this use case is trying to capture multiple activities. I would like to see the use case as
"Customer accepts tender from the customer [by clicking Accept button on the screen]"
- tender details get submitted to the database
- database generates a confirmation number
- blah blah blh...
and so on for other activities such as packaging the product, sending it and changing the inventory.
Now, we are still struggling between B and C but which one do you think is the "best" answer? I am not sure if it is required to separate user actions and system responses in a use case. I would go for C.
As a side note, on confusing questions, I have found it to be helpeful to eliminate wrong answers rather find the right one. Look at each choice and try to find what is wrong with it, if nothing is wrong, hold on to it and move on to the next choice.
Hope this helps


ChintanRajyaguru.com
SOADevelopment.com - Coming soon!
rgulati
Greenhorn

Joined: Aug 07, 2002
Posts: 6
For question - 30
I would go for 'A'.
The use case should only reflect the analysis phase of the project. But to me, this use is more than the analysis phase. It is not totally talking about design, but to some extent design details are mixed with analysis approach.
Other option is 'C' but I would rule it out.
Use case can be broad. From use case, based on the number of scenarios, one can draw sequence diagram for each scenario. So at the end of the day there can be many Sequence diagrams from the use case - which practically means that the use case even though it is broad is valid.
rgulati
Greenhorn

Joined: Aug 07, 2002
Posts: 6
For Question - 51
D is out - Design specifics is too early in the game.
C is out - because it is too early to talk about design patterns
B and A are two options according to me But I would go for A because the first thing is to identify nouns which are classes. Basically come up with the context diagram (Take a conceptual approach). Once the classes are identified, lay out the description. So I think 'A' should be the answer rather than 'B' because we should not identify objects first.
Chintan Rajyaguru
Ranch Hand

Joined: Aug 19, 2001
Posts: 341
rgulati,
Why do you think design details are mixed with the use case as in choice A?
Sell goods (business)
Accept tender from a customer (biz requirement),
package products being purchased (biz req)
and remove the products from inventory (biz req)
There is no design (to me at least)
C
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
Thanks guys for your clarifications. Your analyses are very helpful, I understand problems better.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Hi "rgulati",
thanks for joining the discussion!
We don't have many rules here at the ranch, but we do have a naming policy. I would very much appreciate it if you would edit your display name to conform to it.
Again, thanks!
[ March 30, 2003: Message edited by: Ilja Preuss ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by rgulati:
D is out - Design specifics is too early in the game.
C is out - because it is too early to talk about design patterns

"too early"? Where does the question refer to something along the lines of "early in development"?
IMO, D is out because class names should be named based on their responsibility, not on their implementation specifics.

B and A are two options according to me But I would go for A because the first thing is to identify nouns which are classes. Basically come up with the context diagram (Take a conceptual approach). Once the classes are identified, lay out the description. So I think 'A' should be the answer rather than 'B' because we should not identify objects first.

How can you distinguish between the two? After all, the whole purpose of classes is to be instantiated as objects, so it seems to me.
Also, I don't think it's a good approach to "search for nouns to find classes". See http://www.aw.com/samplechapter/0201379430.pdf for an alternative view.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Chintan Rajyaguru:
C. "Sell goods" is too broad to be a use case.
This one sounds promising because this use case is trying to capture multiple activities. I would like to see the use case as
"Customer accepts tender from the customer [by clicking Accept button on the screen]"
- tender details get submitted to the database
- database generates a confirmation number
- blah blah blh...
and so on for other activities such as packaging the product, sending it and changing the inventory.

If I remember correctly, a Use Case needs to be initiated by an action of an actor. The only action I see here is "clicking accept button", all other activities of the system should probably follow automatically. So I think it deserves to be *one* use case.
I also don't like your idea of putting implementation details like the existence of a database into a use case...
Mike Paul
Greenhorn

Joined: Dec 18, 2002
Posts: 2
Hi might be too late to enter this discussion, but think I might be able to shed some light on the use case question. Having seen previous discussions on this question, there are differences to what is in the actual question
Below is the version from an earlier incarnation of the exam.

). What, if anything, is WRONG with the following analysis use case?
Use case: Sell goods
Description: Accept tender from a customer, package products being purchased, and remove the products from inventory.
Actors: Clerk
Preconditions: Customer has chosen products to buy from inventory.
Postconditions: Products are no longer in inventory. Store cash balance is increased.
Steps:
1. The clerk scans the product codes on each item being purchased.
2. As each item is scanned, the system calculates a running total,
prints line items on a receipt, and displays the line items to the clerk on
the ReceiptPanel.
3. The clerk can remove items from the purchase by pressing the "Void
item" button.
4. ?
5. Once the customer has paid for the items, the items are removed from
inventory and the cash register balance is incremented by the total
amount of the good sold.

Within the steps there are definitely design details intermixed eg, product codes are "scanned" in, pressing the "void button" etc.
I'm not sure whether IBM have changed some of the questions but not changed the marking behind them, as I have found other instances where the current question is slightly different from those discussed in earluer forums.
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Mike Paul:
What, if anything, is WRONG with the following analysis use case?
Use case: Sell goods
Description: Accept tender from a customer, package products being purchased, and remove the products from inventory.
Actors: Clerk
Preconditions: Customer has chosen products to buy from inventory.
Postconditions: Products are no longer in inventory. Store cash balance is increased.
Steps:
1. The clerk scans the product codes on each item being purchased.
2. As each item is scanned, the system calculates a running total,
prints line items on a receipt, and displays the line items to the clerk on
the ReceiptPanel.
3. The clerk can remove items from the purchase by pressing the "Void
item" button.
4. ?
5. Once the customer has paid for the items, the items are removed from
inventory and the cash register balance is incremented by the total
amount of the good sold.

Within the steps there are definitely design details intermixed eg, product codes are "scanned" in, pressing the "void button" etc.

Ans C "Sell goods". This is the goal of this use case for the user. He wants this portion of his final system to 'Sell goods'. Therefore this answer in Wrong.
Ans B The steps above separate the actions of the Clerk from the system (except maybe step 4). So, this is wrong also.
Ans A Even though scanning is mentioned, this does not help me with the design of code to write this system and therefore is not design. Removal of stock from an inventory is a standard business practise and therefore is a business requirement rather than design. This answer is Wrong also.
The only option left is D.
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by victor gu:

51. Which of the following are recommended when developing an OO system?
A.
Write a description of the concept that a class represents whenever a new class is declared.
B.
Use interfaces for types or roles that objects may play, independent of their location in the class hierarchy.
C.
Apply design patterns where applicable in the system.
D.
Name classes based on their design specifics, such as "array" or "queue".
I think A, B, C, are all possible. But we need to choose the best answer.


A = Documentation. How many systems have been developed and work perfectly without the proper (any?) documentation? This is an "important but not necessary"
C Whatever you code is a design pattern. It may not be a good design, but it is your pattern (read solution to the problem). Design patterns are nice to have - it is always handy to have someone else solve your problem. Again this is a "nice to have".
B This deals directly with Object Oriented design and is a 'correct' way to use interfaces. In other words this is a recommendation for developing OO systems.
If you do not use Design Patterns you can still build a good OO system. If you do not document your classes correctly you can still build a good OO system. If you do not use interfaces wisely you can get very bogged down in your code. Therefore I would say that B is the correct answer.
Regards,
Fintan
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Fintan Conway:
Whatever you code is a design pattern. It may not be a good design, but it is your pattern (read solution to the problem).

Just wanted to note that a very common requirement for a Pattern is "successfully used in at least three different situations".
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Need clarifications on 2 ICE questions