Contents Phase 1: Design Concepts 2 Project Description 2 Use Cases 3 Data Dictionary 4 High Level Design Components 5 Detailed Design: Checkout 7 Diagrams 7 Design Analysis 8 Detailed Design: Product Research 9 Diagrams 9 Design – Using Pseudocode 10 Product Profit 10 Phase 2: Sequential Logic Structures 11 Design 11 Product Profit 11 Phase 3: Problem Solving with Decisions 12 Safe Discount 12 Return Customer Bonus 13 Applying Discounts 14 Phase 4: Problem Solving with Loops 15 Total order 15 Problems to Solve 16 Calculate Profits 16 Rock, Paper, Scissors 18 Number Guessing Game 20 Phase 5: Using Abstractions in Design 22 Seeing Abstractions 22 Refactoring 22

Phase 1: Design Concepts
Project Description
Although we may be late to the game, we will nevertheless join the world of e-commerce to sell our fantastic product on the Internet. To do so, we need a Web site that will allow for commerce and sales. To be quick about it, we require the following: * Searchable inventory and shopping pages * A shopping cart * A place for customers to register when they make purchases * A checkout process to make the purchase
Within this main process, there are a bunch of other needs that must be met, as follows: * We want to track the date of the last purchase a customer make so we can offer incentives and discounts based on the last time they shopped. * We will offer sales based on the number of different items that a person purchases. * We will also give discounts for bulk orders a discount when a person buys many of the same item
In addition to sales feature, the solution must provide the ability to manage and research the sales of products. It must include the following: * Must be able to add, update and remove product inventory in real time on the site * Needs to have research capabilities to determine how well a product is selling, such as the following: * How often the item is viewed, added to shopping carts, and then purchased * How a price change affects sales and profit

Use Cases
From the description above, we can relate this to the following use cases, which describe how the user will interact with our system. Each use case is a set of screens that the users would interact with to accomplish something they need on the site.

In addition to the customer’s activity, the solution will allow Sales Analysts to manage and research product sales.

Data Dictionary Variable Name | Type | Description | todaysDate | Date | Today’s date, when the program is running | creationDate | Date | The date the customer created their account | priorPurchases | Integer | Number of Purchases this customer has made in the past | lastPurchaseDate | Date | The date of the last purchase the customer made | lineItemPrice | Array | The price of each line item the customer has added to the cart | lineItemQuantity | Array | The quantity of each line item the customer has added to the cart | membershipLevel | Integer | The account nature of the customer 1 – Guest 2 – Registered 3 – Preferred | totalPurchaseAmount | Double | The cost of all the items in their current purchase | salesTaxRate | Double | The sales tax to be charged on a purchase | productCategory | Integer | An indicator of the category of the product 1 – Consumer Goods 2 – Electronics 3 – Clothing | productPrice | Double | The price of the product as sold to the customer | wholesalePrice | Double | The price at which we purchase the product | numberInCarts | Integer | The total number of times this product has been added to a shopping cart | numberOfPurchases | Integer | The number of times this product has been purchased | allProductSalesNumbers | Array | A list for each product of the number of times a product has sold | allProductPrices | Array | A list for each product of the product price | allProductWholesalePrices | Array | A list for each product of the product wholesale price |

High Level Design Components
Our architects have created the following components to be realized by our development team in meeting the use cases above.
SearchEngine
ProductInventory
ShoppingCart
CardProcessing
Purchasing
CustomerManager
UserSecurity
SearchEngine
ProductInventory
ShoppingCart
CardProcessing
Purchasing
CustomerManager
UserSecurity

Fill out the following table to describe which components are used by each use case and how each component will help realize the use case: Use Case | Component | Services Provided | Search/Browse Inventory | ProductInventory | Provides access to the database of inventory of all products and their descriptions and prices and such. | | SearchEngine | Allows for searching on many criteria within the product database | | | | Register As Customer | CustomerManager | Create and manage customer profile and personal information | | UserSecurity | Provide security solutions for the visitors to the site | | | | Choose Products | <fill me> | <fill me> | | | | | | | | | | Checkout | <fill me> | <fill me> | | | | | | | | | | Apply Discounts | <fill me> | <fill me> | | | | | | | | | | Manage Products | <fill me> | <fill me> | | | | | | | | | | Research Sales | <fill me> | <fill me> | | | | | | | | | |

Detailed Design: Checkout
Diagrams
We could realize this design as either structured or Object-Oriented given the following design diagrams. calculate OrderTotal
Calculate Subtotal bigBuyer Discount bulkBuyer Discount returnCustomer Bonus daysSinceLast Purchase calculate OrderTotal
Calculate Subtotal bigBuyer Discount bulkBuyer Discount returnCustomer Bonus daysSinceLast Purchase

Figure [ 1 ] Structure Design for calculateOrderTotal

;Order
;DiscountManager
;Customer
;Taxes
bigBuyerDiscount() bulkBuyerDiscount() returnCustomerBonus() daysSinceLastPurchase() calculateSubtotal()
;Order
;DiscountManager
;Customer
;Taxes bigBuyerDiscount() bulkBuyerDiscount() returnCustomerBonus() daysSinceLastPurchase() calculateSubtotal() Figure [ 2 ]: Sequence Diagram for calculateOrderTotal
Design Analysis
Given the designs above, we need to analyze which approach we should take and how the code realization will differ.
Structure Design * Describe the implementation of the structure design in Figure 1 and how it relates to the Checkout use case. * What procedures and functions are being created in the design? * What data would be passed between these procedures and functions?
Object-Oriented Design * Describe the implementation of the object-oriented design in Figure 2 and how it relates to the Checkout use case. * What methods are being created in the design? * What data would be passed between these methods?
Comparison
* How do these approaches (Structured versus OO) differ? * How much will the detailed implementation when we get to code differ because of the high level design approach we choose?

Detailed Design: Product Research
Diagrams
For the product research use case, take a stab at either a structured design diagram or a sequence diagram that would fulfill at least part of the functionality of the use case. We will compare what you create here to the detailed design we create through the rest of the course as a way of measuring your progress. * Provide a diagram of your choice here to show a flow for researching products.
The exact details are flexible within the description of the functionality, so do your best to create a flow that looks like a code solution using the components above or ones you think you need. This is practice that will give you a measuring stick for your learning as we see problems later in the course related to this system.

Design – Using Pseudocode
Product Profit
Description
It is important to know the profit each product is providing to the bottom line. Given that we know the wholesale cost, the retail cost to consumers and the number of items we have sold, calculate the profit for a given product.
Pseudocode
function productProfit(productPrice : Double, wholesalePrice : Double, numberOfPurchases : Integer) Return Double <add your logic here> End function

Phase 2: Sequential Logic Structures
Design
Product Profit
Description
Continuing with the same example of calculation product profit, utilize the same scenario to create a flowchart.
Description - It is important to know the profit each product is providing to the bottom line. Given that we know the wholesale cost, the retail cost to consumers and the number of items we have sold, calculate the profit for a given product.
Flowchart
<insert here>
Additional Pseudocode
Discuss how input/output, operators, and expressions are presented in pseduocode as well as how they are used to accommodate needs for sequential logic within business applications. Additionally, discuss how various data types may be used within sequential logic structures.

Phase 3: Problem Solving with Decisions
Safe Discount
Description
We want to ensure that the system will not accidentally discount a product below the price that it is purchased for. Thus, we want an operation to ensure that, when a discount is applied, it always stays more than the original purchase price.
Sample data could include the following: * A product at $10 with a wholesale price of $5 and a discount of 10% returning $9. * A product at $10 with a wholesale price of $6 and a discount of 50% returning $6.
Pseudocode
function applyDiscount(productPrice : Double, wholesalePrice : Double, discount : Double) Return Double <add your logic here> End function
Flowchart
<insert here>

Return Customer Bonus
Description
We want to reward customers for returning to make a purchase. To incentivize, they receive a bonus discount as by the following levels. * Less than a week = 10% * More than 6 months = 6% * Otherwise, 1% for each month (consider a month to be 30 days)
Sample data for testing: Scenario | todaysDate | lastPurchaseDate | totalPuchaseAmount | Return amount | 1 | 2/1/2014 | 1/25/2014 | $100 | $90 | 2 | 2/1/2014 | 3/17/2013 | $100 | $94 | 3 | 2/1/2014 | 12/11/2013 | $100 | $TBD | 4 | 2/1/2014 | 9/25/2013 | $100 | $ TBD |

Flowchart
<insert here>
Pseudocode
function returnCustomerBonus (todaysDate : Date, lastPurchaseDate : Date, totalPurchaeAmount : Double) returns double <add your logic here> end function

Applying Discounts
Description
A customer receives his or her discount based on his or her membership status. Preferred members receive a return member bonus, and all registered members receive a bulk discount, but guests do not receive any discounts.
This should reuse the discounts from the prior work, so test cases from there would apply. Just make sure that guests receive no discount, registered members just get a discount for any items for the bulk discount, and preferred members get both the bulk discount and the return customer bonus.
Flowchart
<insert here>
Pseudocode
function applyDiscounts (todaysDate : Date, lastPurchaseDate : Date, totalPurchaseAmount : Double, membershipLevel : Integer) returns double <add your logic here> end function

Phase 4: Problem Solving with Loops
Total order
Description
Once the final prices are calculated for each product, we need to total up the order and then add in sales tax. We need to go through the line items in an order and figure out the final price.
Create variable Double: subtotal
Return
calculateSubtotal (subtotal, salesTaxRate)
Subtotal = subtotal + lineItemTotal index = each item in lineItemPrice lineItemTotal= lineItemPrice[index] * lineItemQuantity[index] Create variable Double: subtotal
Return
calculateSubtotal (subtotal, salesTaxRate)
Subtotal = subtotal + lineItemTotal index = each item in lineItemPrice lineItemTotal= lineItemPrice[index] * lineItemQuantity[index] Flowchart

Pseudocode function totalOrder (lineItemPrice: Array, lineItemQuantity : Array, saleTaxRate : Double) returns double Create variable Double : subtotal for (index = each item in lineItemPrice) lineItemTotal = lineItemPrice[index] * lineItemQuantity[index] subtotal = subtotal + lineItemTotal end loop return calculateSubtotal (subtotal, salesTaxRate) end function
Problems to Solve
Fill in the following table by walking through the logic above. The idea is to analyze how the chart and pseudocode was created, because you will be doing this in a few minutes, so do not just jump to the easy answer. Follow the steps as if you are the computer executing the software designed. Problem | lineItemPrice | lineItemQuantity | saleTaxRate | Return amount | 1 | [5.50, 3.00, 2.25] | [12, 3, 10] | 5% | | 2 | [5.50] | [5] | 5% | | 3 | [] | [] | 5% | |

Calculate Profits
Description
Given the list of all the product prices and wholesale prices as well as a list of all the items sold for each product calculate the net profit for all the products.
Flowchart
<insert here>
Pseudocode
function totalProfits (allProductSalesNumbers: Array, allProductPrices : Array, allProductWholesalePrices : Array) returns double <add your logic here> end function

Rock, Paper, Scissors
Description
To expand further, we want to try out logic in interacting with users. Here is a sample of a game, using loops and decisions to allow a person to play rock-paper-scissors with a computer.
Pseudocode
We have a helper function that we will use here that tells us who won. It will result in +1 if the player wins, a -1 if the computer wins, and a 0 if it is a tie. function compareOutcome(computerMove: Integer, playerChoice : Integer) returns Integer And the main flow of our logic is as such. while (true) Integer : computerChoice = randomChooser() Integer : playerEntry = prompt user to enter a value If (playerEntry is not a valid input) Prompt user they have picked a bad number and try again Else Integer : outcome = compareOutcome(computerMove, playerEntry) If (outcome = 0) Prompt user it is a tie, and try again Else if (outcome = -1) Prompt user they lost Break out of loop Else Prompt user they won Break out of loop End if End if end loop
Flowchart
true

playerEntry is not a valid input

outcome =
0

outcome =
-1
Integer : computerChoice = ramdonChooser()
Integer : playerEntry = prompt user to enter a value
Prompt user they have picked a bad number and try again
Integer : outcome = compareOutcome(computerMove, playerEntry)
Prompt user it is a tie, and try again
Prompt user they lost
Break
Prompt user they won
End of game
Break
true

playerEntry is not a valid input

outcome =
0

outcome =
-1
Integer : computerChoice = ramdonChooser()
Integer : playerEntry = prompt user to enter a value
Prompt user they have picked a bad number and try again
Integer : outcome = compareOutcome(computerMove, playerEntry)
Prompt user it is a tie, and try again
Prompt user they lost
Break
Prompt user they won
End of game
Break

Note: In this case, note the advantages and disadvantages of flowcharts and pseudocode. The flowchart is easy to follow the logic for one scenario, but does it make it easier or harder to understand the code as a whole? There is no strict answer, but one that tells you a bit about your way of thinking and personal preference.
Interaction Scenario
For either of the solutions above, follow the logic and map out your interaction step-by-step, trying to exercise all paths of the logic. You will have to take at least 2 times through the game to map all scenarios.
Scenario 1 Step | User Input | System Response | 1 | User chooses 50 | System says lower | 2 | … | .. | 3 | | | 4 | | |
Scenario 2 Step | User Input | System Response | 1 | | | 2 | | | 3 | | | 4 | | |

(copy and add more if needed/desired)
Number Guessing Game
Description
Now it is your turn to try out user interaction with a simple game. This goes back to the number guessing game. The user will input a number each time, say between 1 and 100. The computer will randomly select 1 number each game (note this is different than the example above where it selects a new answer each round), and the game continues until the user guesses the right number.
Like above, your solution should accommodate for invalid input, but do not worry about how to make that logic work for now. Your solution should give some hints though if the guess the user made was too high or too low, to help them on their way.
Flowchart
<Your solution here>
Pseudocode
<your solution here>

Phase 5: Using Abstractions in Design
Seeing Abstractions
Throughout this course, we have been realizing the detailed design for the pieces of the whole picture we started with at the beginning of the course. We have built many abstractions, so let’s go back and document what we have found and see the abstractions we have created. Abstraction Name | Parameter List | Scope/Purpose | calculateSubtotal | (totalPurchaseAmount :double, salesTaxRate : double) | Applies sales tax and computes the final amount due | <keep going> | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Refactoring
Sometimes it is easy to see how the whole solution can be broken into pieces, and other times it is done as you see abstractions and opportunities for reuse in the resulting design. This is called refactoring. For the pseudocode you see below, look for abstractions you could create and create a flowchart using your simplifications.

Psuedocode in Need of Refactoring Array : namesInSystem Array : phoneNumbersInSystem String : nameInput While (nameInput is not valid) nameInput = prompt user for input if (nameInput is provided and not blank) break out of loop end loop Prompt user the input is required and not blank End loop Integer : indexForName = -1 For (index = all items in namesInSystem If (nameInput = namesInSystem[index]) indexForName = index end if End loop If (indexForName = -1) Prompt user “We cannot find your account, please call us” Else String : phoneNumberInput While (phoneNumber is not valid) phoneNumber = prompt user for input if (phoneNumber is provided and not blank) break out of loop end loop Prompt user the input is required and not blank End loop If (phoneNumber = phoneNumbersInSystem[indexForName]) Prompt “we found your account welcome” Else Prompt “we cannot validate your account, try again later” End if End if
Refactored Flowchart
The above pseudocode is long, but you can omit much of the details. You can accomplish the same logic removing more than 30 lines. You do not have to show all of the details removed if moved into an abstraction, simply name the abstraction and define the parameters to be passed to the call replacing the lines of code.
<insert your flowchart here>