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
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.
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.
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.
Preconditions: Customer has chosen products to buy from inventory.
Postconditions: Products are no longer in inventory. Store cash balance is increased.
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
3. The clerk can remove items from the purchase by pressing the "Void
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.
Originally posted by victor gu:
51. Which of the following are recommended when developing an OO system?
Write a description of the concept that a class represents whenever a new class is declared.
Use interfaces for types or roles that objects may play, independent of their location in the class hierarchy.
Apply design patterns where applicable in the system.
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.
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).
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton