WWW.CUTELITTLEFAVORS.
COM
MIS 4330 (Group 3)
Christopher Freedman
Orlando Salazar
David Alvarado
Adrian Chapa
Shawn Mathew
TABLE OF CONTENTS
Executive Summary - 1 ...................................................................................... 2
BACKGROUND 1.1................................................................................................ 2
System Proposal - 2 ........................................................................................... 3
SOURCE DOCUMENT 2.1 .......................................................................................
PROPOSAL 2.2 ....................................................................................................
3
4
ANALISYS
Context Diagram - 3 ........................................................................................... 5
CURRENT SYSTEM 3.1 ......................................................................................... 5
PROPOSED SYSTEM 3.2 ....................................................................................... 6
Process Model - 4 ............................................................................................... 7
USE-CASE DIAGRAM FOR PROPOSED SYSTEM 4.1 ................................................. 7
USE-CASE DESCRIPTION 4.2 ................................................................................ 8
Data Model 5 ................................................................................................. 11
CLASS DIAGRAM FOR PROPOSED SYSTEM 5.1 ..................................................... 11
Objective Behavior Model 6 ........................................................................ 12
SEQUENCE DIAGRAM FOR MAYOR USE CASE 6.1 ................................................. 12
Data Documentation 7 ................................................................................. 13
DATA DICTIONARY FOR PROPOSED AND CURRENT SYSTEM 7.1 ............................ 13
Functional Specification Document for Proposed System 8 .................... 18
DESIGN
Interface Design 9 ........................................................................................ 19
Database Design 10 ..................................................................................... 20
Complete Class Diagrams 11 ...................................................................... 21
Software Design 12 ...................................................................................... 22
METHODS 12.1.................................................................................................. 22
Controls 13 ................................................................................................... 25
Implementation 14 ........................................................................................ 26
PROJECT MANAGEMENT DELIVERABLES ................................................... 31
1|Page
1. Executive Summary
WWW.CUTELITTLEFAVORS.COM is a website that sells party favors for a
variety of events including Weddings, Baby Showers, Sweet 16th and other special
occasions. Being a retail online store that requires customers to register and log in, it
has various challenges. The website has products ready to buy and customizable
products. As is with most custom shops that sell merchandise, cutelittlefavors.com must
provide their customers with orders that are up to their needs, and meets their
satisfaction. This benefits the website by generating more revenue from increased
sales, and also creates more satisfied customers.
With that in mind, we as a group met with one the administrator for the website
(Gustavo Lopez) for a behind the scenes look at their ordering process, storing and
shipping details, and small glances into their database of merchandise. Gustavo gave
us a look at the custom shopping cart he created for CutteLittleFavors.com and gave us
some ideas on what he tough the website was lacking. We suggested that we help
them redesign some of their databases and process through UML diagrams and model
our proposed new features.
We used context diagrams, use case diagrams and sequence diagrams to make
a model for possible future development and optimization of their interesting website.
Hopefully, by allowing us to come up with new designs and ideas, this little website with
little current traffic will become the new Amazon of favors.
2|Page
2. System Proposal
Source Document 2.1
Current Registration page
Current Confirmation Page
3|Page
Proposal 2.2
For the current system, it lacks the ability to send an email to the customer about
their order status. It also does not verify any users that register for an account. It also
doesnt send a text for status updates. We are proposing that we add the
implementation of the following:
1. Implementation of auto email confirmation and order status
a. When the customer signs up for an account, they will be asked for their
email address in the initial sign up.
b. The email address is then added to the database storing customer
records.
c. The customer will then be sent an email confirmation to continue
registration. This email will also describe the type of account that they
have as well.
d. Once the customer has confirmed email address, they will be able to place
an order.
e. After the customer has placed an order, the website will then send out
another email with order and shipment status.
2. Choosing notification options
a. When the customer submits an order, they can choose between email
notifications and text notifications.
3. Billing address request upon registration
When the customer sings up, they will be required to provide their billing address to
optimize all information into the database.
4|Page
3. Context Diagram
Current System 3.1
5|Page
Proposed System 3.2
6|Page
4. Process Model
Use-Case Diagram for Proposed System 4.1
(Use-Case Diagram for proposed system)
7|Page
Use-Case Description 4.2
Use Case Name: Process Login
Primary Actor:
Customer
Stakeholders:
Cutelittlfavors.com
Trigger:
Customer Clicks login
Normal Flow of
Events:
1.
User enters user ID and Password
2.
The system authenticates user ID and Password
3.
The system displays a welcome screen consisting of the user
profile
Exception Flows:
4.
End Do
2a.
If the user ID and Password do not match user database
Then display an error message and ask the user to reenter the user ID
and Password
Use Case Name: Customer Places Order
Primary Actor:
Customer
Stakeholders:
Cutelittlfavors.com
Trigger:
Customer Clicks Add to Cart
Normal Flow of
Events:
1.
The user provides quantity
2.
The system estimates shipping cost
3.
The system proceeds to check out
4.
Customer inputs Billing address and Shipping address, Shipping Method,
Payment Method and Information
5.
Customer places order
6.
System sends order to website administrator and updates order database
7.
System returns order number to customer
4a.
Payment information not valid, Prompt error message
Exception Flows:
8|Page
Use Case: Register
Primary Actor:
Customer
Stakeholders:
Cutelittlfavors.com
Trigger:
Customer Clicks
Normal Flow of Events:
1. The user provides user profile information
2. The system creates a new user profile
3. The system updates the customer database
4. The system displays a welcome screen consisting of the user
Profile
5. End Do
Exception Flows:
Use Case: Prepare Order
Primary Actor:
Website Admin
Stakeholders:
Cutelittlfavors.com
Trigger:
New order is created
Normal Flow of
Events:
1.
The web admin retrieves order from the order database
2.
The web admin checks stock in the inventory database
3.
Web admin send order to warehouse to fulfill
4.
Web admin receives confirmation of shipment from warehouse
Exception Flows:
2a. If item is out of stock Website Admin notifies customer of when it
will be in stock Place order on backorder
9|Page
Use case: Update order status
Primary Actor:
Website Admin
Stakeholders:
Cutelittlfavors.com
Trigger:
New order is created
Normal Flow of
Events:
1.
The web admin accesses inventory database
2.
Web admin updates inventory database to decrease inventory
3.
Web admin updates customer profile
Exception Flows:
10 | P a g e
5. Data model
Class Diagram for Proposed System 5.1
11 | P a g e
6. Object Behavior Model
Sequence Diagram for Mayor Use Case 6.1
12 | P a g e
7. Data Documentation
7.1 Data Dictionary for Proposed System and Current System*
*Proposed System Changes are in Bold
Registration
a) Your personal Details= gender + first name+ last name+ date of birth + email
-Gender= [Male | Female]
-Date of Birth= Day + Month + Year
b) Primary Billing Address=Country + State + City +Address 1+ (Address 2)
+Zip Code + Phone Number
-Country= [USA|.|Venezuela]
c) Company Details= Company name
d) Options= (Yes | No) radio button for newsletter
e) Your Password= password + confirm password
13 | P a g e
Log In
a) Returning Customer= Email + Password+ Remember Me
-Remember Me= (Yes | No) radio button to auto fill
Product Page
a) Product= Name + SKU + Price + Quantity
-Quantity= [1|.|]
14 | P a g e
Shopping Cart
a) Shopping Cart= 1{SKU +Product(s) + Price+ Quantity+ Total}*
b) Discount Code= Code
c) Estimate Shipping= Country + State/Province + Zip Code
-Country= [USA|.|Venezuela]
15 | P a g e
Checkout
a) Billing Address= [AutoFill| Enter Manually]
-Enter Manually=First Name+ last Name + Email + (Company)+ Country +
State +City + Address 1+ (Address 2) + Zip Code + Phone Number + (Fax
Number)
-Country= [USA|.|Venezuela]
b) Shipping Address=First Name+ last Name + Email + (Company) + Country +
State + City +Address 1+ (Address 2) + Zip Code + Phone Number + (Fax
Number)
c) Shipping Method= [UPS ground | UPS 3 day Select]
d) Payment Information= Cardholder Name + Select Credit Card + Card Number
+ Expiration date + Card Code
-Select Credit Card= [Visa | Master Card | Discover | AMEX]
16 | P a g e
-Expiration Date= Month + Year
-Month= [01||12]
-Year= [2014||2028]
e) Confirm Order= Order Number + (Email Notification) + (Text Notification) + (Sign
up for our newsletter)
-Email Notification= [Yes | No] radio button
-SMS Notification= [Yes | No] radio button
17 | P a g e
8. Functional Specification Document for Proposed System
1) The System will allow the user to register using personal details, email, primary
billing address, and password selection. The system will then prompt the user to
view an email confirmation of registration. Upon viewing that email, the user will
click a link to finish registration.
2) The System will allow users to login to the system after registering with proper
identification.
3) The system will allow users to view products based on name, SKU, price and
quantity.
4) The system will provide estimated shipping cost based on country, region, and
area code.
5) Upon selection of products to purchase the system allows the user to proceed to
checkout.
6) The system will auto fill the billing address information for the users primary
billing address information, unless the user decides to enter a new address
manually.
7) The system will auto fill the shipping address information from billing address
unless the user specifies a new address.
8) The system will allow for a shipping method to be selected by the user as well as
show cost.
9) The system will accept payment in the form of credit card from Visa, Master
Card, Discover, and American Express. It will require customers to input valid
name, card number, expiration, and card code.
10) Upon completion of order, the system will send email confirmation of order.
11) Upon completion of the order, the user can select to have email or text/SMS
shipment notification provided for them using the information provided by
registration. This will include tracking numbers for shipment and estimated
delivery time.
18 | P a g e
9. Interface Design
9.1 Registration Page Interface Design Modified to add Address Field
9.2 Confirmation Page Modified to Add Email and Text Message
Notification for Orders
19 | P a g e
10. Database Design
20 | P a g e
11. Complete Class Diagram
21 | P a g e
12. Software Design
Method 1
Class Name: Initial Billing Address
Clients (Users): users
Description of Responsibilities: When user register obtain a billing address to
facilitate future orders
Arguments Received:
Type of Value Returned:
Pre-Conditions: User must register for an account
Post-Conditions:
For every user
Register for an account ask for billing address
IF billing address is valid
Allow user to register
ELSE
Prompt user to enter a valid billing address
ENDIF
IF user places order
USE register billing address as default parameter
ELSE
Allow user to manually enter billing address for specific order
ENDIF
END
Method 2
Class Name: email verification
Clients (Users): users
Description of Responsibilities: Verify the email of any user who is registering to
allow the user to make a purchase.
Arguments Received:
Type of Value Returned: Valid email registration
Pre-Conditions: User should provide a valid email for verification
Post-Conditions:
For every user
Register for an account
Send verification email with email confirmation
IF email not verified
User is not able to place order
ELSE
Allow user to make purchase
ENDIF
END
22 | P a g e
Method 3
Class Name: Phone number verification
Clients (Users): users
Description of Responsibilities: Verifies user phone number to allow text
message order status
Arguments Received:
Type of Value Returned: text message confirmation to user
Pre-Conditions: User should provide a valid phone number
Post-Conditions:
For every user
Register for an account
Send Text message verification
IF text not verified
User is not able to obtain order status through text message
ELSE
Allow user to obtain order status through text message
ENDIF
Existing users
IF user changes phone number
Resend Text message verification for new phone number
ENDIF
END
Method 4
Class Name: Text order updates
Clients (Users): users
Description of Responsibilities: Notify user of order status via text message
Arguments Received:
Type of Value Returned: text message notification
Pre-Conditions: Phone number verification
Post-Conditions:
For every user
Places an order
IF user allows order updates through text message
USE order from database to send push notification to users
ENDIF
END
23 | P a g e
Method 5
Class Name: Order email confirmation
Clients (Users): users
Description of Responsibilities: To make sure that the user is verified
Arguments Received:
Type of Value Returned:
Pre-Conditions: Register user
Post-Conditions: Allow to place order
For every user
Places an order
IF user Email not confirmed
Notify user that he/she must confirmed email before placing
Order
Else
Place order
ENDIF
END
24 | P a g e
13. Controls.
1. System allows user to check the order status from cutelittlefavors.com and
notifies users via email of the order status.
2. The user is allowed to login in by having a registered account
3. The user is allowed to place an order only if they have a valid email address that
has been confirmed by the user
4. The system requires the user to initially provide a billing address for current and
future orders
5. It also allows for such address to be modify at any point in time by user in the
system
6. System allows web admin to review and change the status of an order
7. It also allows user to check the order status from cutelittlefavors.com and notifies
users via email of the order status.
8. The system allows users to opt out of such email notifications and text messages
25 | P a g e
14. Implementation (Extra Credit)
Code to Send Email to User in C#
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Net.Mail;
using Nop.Core.Domain.Messages;
namespace Nop.Services.Messages
{
public partial class EmailSender:IEmailSender
{
/// <summary>
/// Sends an email
/// </summary>
/// <param name="emailAccount">Email account to use</param>
/// <param name="subject">Subject</param>
/// <param name="body">Body</param>
/// <param name="fromAddress">From address</param>
/// <param name="fromName">From display name</param>
/// <param name="toAddress">To address</param>
/// <param name="toName">To display name</param>
/// <param name="bcc">BCC addresses list</param>
/// <param name="cc">CC addresses ist</param>
public void SendEmail(EmailAccount emailAccount, string subject, string body,
string fromAddress, string fromName, string toAddress, string toName,
IEnumerable<string> bcc = null, IEnumerable<string> cc = null)
{
26 | P a g e
SendEmail(emailAccount, subject, body,
new MailAddress(fromAddress, fromName), new MailAddress(toAddress, toName),
bcc, cc);
}
/// <summary>
/// Sends an email
/// </summary>
/// <param name="emailAccount">Email account to use</param>
/// <param name="subject">Subject</param>
/// <param name="body">Body</param>
/// <param name="from">From address</param>
/// <param name="to">To address</param>
/// <param name="bcc">BCC addresses list</param>
/// <param name="cc">CC addresses ist</param>
public virtual void SendEmail(EmailAccount emailAccount, string subject, string body,
MailAddress from, MailAddress to,
IEnumerable<string> bcc = null, IEnumerable<string> cc = null)
{
var message = new MailMessage();
message.From = from;
message.To.Add(to);
if (null != bcc)
{
foreach (var address in bcc.Where(bccValue =>
!String.IsNullOrWhiteSpace(bccValue)))
{
message.Bcc.Add(address.Trim());
}
}
27 | P a g e
if (null != cc)
{
foreach (var address in cc.Where(ccValue => !String.IsNullOrWhiteSpace(ccValue)))
{
message.CC.Add(address.Trim());
}
}
message.Subject = subject;
message.Body = body;
message.IsBodyHtml = true;
using (var smtpClient = new SmtpClient())
{
smtpClient.UseDefaultCredentials = emailAccount.UseDefaultCredentials;
smtpClient.Host = emailAccount.Host;
smtpClient.Port = emailAccount.Port;
smtpClient.EnableSsl = emailAccount.EnableSsl;
if (emailAccount.UseDefaultCredentials)
smtpClient.Credentials = CredentialCache.DefaultNetworkCredentials;
else
smtpClient.Credentials = new NetworkCredential(emailAccount.Username,
emailAccount.Password);
smtpClient.Send(message);
}
}
}
}
28 | P a g e
Task to Queued Message to Send Message in C#
using System;
using Nop.Services.Logging;
using Nop.Services.Tasks;
namespace Nop.Services.Messages
{
/// <summary>
/// Represents a task for sending queued message
/// </summary>
public partial class QueuedMessagesSendTask : ITask
{
private readonly IQueuedEmailService _queuedEmailService;
private readonly IEmailSender _emailSender;
private readonly ILogger _logger;
public QueuedMessagesSendTask(IQueuedEmailService queuedEmailService,
IEmailSender emailSender, ILogger logger)
{
this._queuedEmailService = queuedEmailService;
this._emailSender = emailSender;
this._logger = logger;
}
/// <summary>
/// Executes a task
/// </summary>
public void Execute()
{
var maxTries = 3;
var queuedEmails = _queuedEmailService.SearchEmails(null, null, null, null,
true, maxTries, false, 0, 500);
29 | P a g e
foreach (var queuedEmail in queuedEmails)
{
var bcc = String.IsNullOrWhiteSpace(queuedEmail.Bcc)
? null
: queuedEmail.Bcc.Split(new char[] { ';' },
StringSplitOptions.RemoveEmptyEntries);
var cc = String.IsNullOrWhiteSpace(queuedEmail.CC)
? null
: queuedEmail.CC.Split(new char[] { ';' },
StringSplitOptions.RemoveEmptyEntries);
try
{
_emailSender.SendEmail(queuedEmail.EmailAccount, queuedEmail.Subject,
queuedEmail.Body,
queuedEmail.From, queuedEmail.FromName, queuedEmail.To,
queuedEmail.ToName, bcc, cc);
queuedEmail.SentOnUtc = DateTime.UtcNow;
}
catch (Exception exc)
{
_logger.Error(string.Format("Error sending e-mail. {0}", exc.Message), exc);
}
finally
{
queuedEmail.SentTries = queuedEmail.SentTries + 1;
_queuedEmailService.UpdateQueuedEmail(queuedEmail);
}
}
}
}
}
30 | P a g e
PROJECT MANAGEMENT DELIVERABLES
Meeting 1: September 3 (5:30-8:30PM) (all team members present)
First group meeting
Broke project into sections and assigned to each person
Christopher Freedman (Parts 1, 2 and 3)
Orlando Salazar (Parts 12, 13, and 14)
Adrian Chapa (parts 10 and 11)
David Alvarado (Parts 4, 5 and 6)
Shawn Mathew (Parts 7, 8 and 9)
Created a Google Docs collaboration document that each member could access
Initial timeline created
Sept. 18th Parts 1 and 2 needs to be complete and document/project
proposal started
Oct. 2nd Parts 3 and 4 needs to be complete and uploaded to Google
Docs
Oct 16th Parts 5 and 6 needs to be mostly complete
Nov. 6th Parts 7, 8 and 9 need to be complete
Nov. 20th Parts 10, 11 and 12 need to be complete
Dec 4th Everything complete
Meeting 2: September 18th
(5:30-6:36PM) (All team members attend except Adrian, participation through
google hangouts)
Parts 1 and 2 completed. Format needed to be adjusted and made to fit the other
content.
Timeline still intact
No changes need for parts 3
Parts 1 and 2 uploaded to Google Docs as completed
31 | P a g e
Meeting 3: Oct 2nd (5:30 7:10)
Chris Freedman, David Alvarado, Adrian Chapa, Orlando Salazar (Shawn
Mathew participation through google hangouts)
All time frames kept for project timeline
No adjustments needed to planned timeline
Combined parts 1, 2, 3 and 4 into rough draft of project through Google Docs
Discussed redoing part 3 to include more in the context diagram
Meeting 4: Oct 16th (5:30 6:30)
All group members present for meeting
Time frame needed to be adjusted; part 5 and 6 had not been completed yet
Group discussed how to complete the class diagram
Had issues with foreign keys
Uploaded to google docs when completed
Time frame for planned timeline for parts 6 extended to Nov 6th meeting
Meeting 5: Nov 6th (5:20 6:30)
Chris Freedman, David Alvarado and Orlando Salazar
Other team members had other classes/events to attend
Part 6 completed
Parts 7, 8 and 9 were completed
All parts added to the Google Docs for completion
Meeting 6: Nov 20th (5:30 7:00)
32 | P a g e
David Alvarado, Shawn Mathew, Adrian and Orlando Salazar (Chris Freedman
had work)
Meeting notes taken by Orlando Salazar and transferred to Chris to put in
Document
All parts up to the planned timeline had been completed
Met with website admin (Gustavo Lopez) to discuss any other ideas to add
Admin approved of all suggestions, is going to implement email notifications
portion
Short meeting before holiday
Meeting 7: Dec 4th (8:30 9:45)
All team members present
Meeting right after short class
Started to put everything together
Had to change a few things
Class diagram needed to include methods
David updated class diagram during meeting
Meeting 8: Dec 5th (3:00 5:00)
All team members other than Adrian (he had work)
Recorded project
Submitted project
33 | P a g e
