Download Merkley Headgear

Merkley Headgear
_______________________
System Design
Prepared For
_________________________
TA: Tianhan Wang
Instructor: John Mylopoulos
Date: April 11, 2003
Presented by
_________________________
Anthony Ku Ong
Michelle Li
Leeor Engel
Table of Contents
System Design
1
2
3
Introduction ............................................................................................................... 7
1.1
Objective ............................................................................................................. 7
1.2
The Organization ................................................................................................ 7
System Overview ....................................................................................................... 7
2.1
The Current System ............................................................................................. 7
2.2
The Problem ........................................................................................................ 8
2.3
The Proposed System .......................................................................................... 8
Global Architecture .................................................................................................. 9
3.1
Software Architecture ......................................................................................... 9
3.1.1
Repository-Based Architecture ................................................................... 9
3.1.2
Model View Controller (MVC) Architecture ........................................... 10
3.1.3
Client Server Architecture ........................................................................ 10
3.1.3.1 Two-Tier Client Server Architecture .................................................... 11
3.1.3.2 Three-Tier Client Server Architecture .................................................. 11
3.1.4
Recommendation ...................................................................................... 11
4
3.2
Computer Network Specification ...................................................................... 11
3.3
Web Application Server Specification .............................................................. 12
Platform Selections ................................................................................................. 12
4.1
Overview: Criteria for the Computing Platform .............................................. 12
4.1.1
Open System Criteria: ............................................................................... 12
4.1.2
Black-Box Criteria .................................................................................... 12
4.2
Hardware Platform ........................................................................................... 13
4.2.1
Reasons for the Use of Microcomputers ................................................... 13
4.3
Software Selection ............................................................................................. 14
4.3.1
Operating System ...................................................................................... 14
4.3.2
Database Server ........................................................................................ 14
4.3.3
Design Justification for Using Oracle9i Database .................................... 14
4.3.3.1 Scalability ............................................................................................. 14
4.3.3.2 Increased Security ................................................................................. 15
4.3.3.3 Ease of Integration ................................................................................ 15
4.4
Programming Language ................................................................................... 15
4.4.1
SQL ........................................................................................................... 15
Merkley Headgear System Design
2
4.4.1.1
4.4.1.2
4.4.1.3
4.4.1.4
4.5
5
Reasons for Using SQL ........................................................................ 15
The Use of SQL .................................................................................... 16
Advantages of Embedded SQL............................................................. 16
Reasons for Embedded SQL with Java ................................................. 17
Web Programming Technologies ...................................................................... 17
Program Design and Subsystems .......................................................................... 18
5.1
Subsystem Descriptions .................................................................................... 18
5.1.1
Client Subsystem ...................................................................................... 18
5.1.2
Customer and Product Administration Subsystem ................................... 18
5.1.3
Manufacturing Subsystem ........................................................................ 19
5.1.4
Shipping Subsystem .................................................................................. 19
5.2
Using the BCED Approach ............................................................................... 19
5.3
Class Diagram Modifications ........................................................................... 21
5.4
Use Cases .......................................................................................................... 21
5.5
Sequence Diagram ............................................................................................ 22
5.6
Activity Diagram ............................................................................................... 23
5.7
Collaboration Diagram .................................................................................... 23
5.8
State Diagram ................................................................................................... 24
5.8.1
Entire System ............................................................................................ 24
5.8.2
Web Ordering Application Subsystems .................................................... 25
5.8.3
Administration & Order Processing Application System ......................... 26
6
Database Design ...................................................................................................... 27
6.1
Database Design Criteria: Conforming to ACID ............................................. 27
6.2
Relational Schema Formation .......................................................................... 28
6.2.1
Main Identifiers ......................................................................................... 28
6.2.2
Constraints ................................................................................................ 28
6.2.3
Preliminary Relational Schema................................................................. 29
6.3
Redundancy Analysis ........................................................................................ 29
6.3.1
Removing Generalizations ........................................................................ 29
6.3.2
Merging Concepts ..................................................................................... 29
6.3.3
Removing Entity and Relation Redundancies .......................................... 30
6.4
Schema Normalization ...................................................................................... 30
6.4.1
Normalizing Relational Schemas in First Normal Form .......................... 30
6.4.1.1 Relation Customer to be in First Normal Form .................................... 30
6.4.1.2 Decomposition Alternative One into 1NF ............................................ 31
6.4.1.3 Decomposition Alternative Two into 1NF ........................................... 31
6.4.1.4 Decomposition Selection ...................................................................... 31
6.4.2
Normalizing Relational Schemas in Second Normal Form ...................... 32
Merkley Headgear System Design
3
6.4.3
6.4.4
6.5
Normalizing Relational Schemas in Third Normal Form ......................... 33
Optimized Relational Schema................................................................... 33
Entity Relationship Diagram and Design ......................................................... 34
6.6
Workload Data and Cost Comparisons ............................................................ 35
6.6.1
Table of Volumes ...................................................................................... 35
6.6.2
Operational Requirements ........................................................................ 35
6.6.3
Cost Comparison Summary ...................................................................... 36
6.7
7
Database Design Summary ............................................................................... 37
Interface Design ...................................................................................................... 37
7.1
User Groups ...................................................................................................... 38
7.1.1
Customers ................................................................................................. 38
7.1.1.1 Corporate Customers ............................................................................ 38
7.1.1.2 Personal Customers ............................................................................... 38
7.1.2
Employees ................................................................................................. 38
7.1.2.1 Production Clerks.................................................................................. 38
7.1.2.2 Shipping Clerks ..................................................................................... 38
7.1.2.3 Sales Representatives ............................................................................ 39
7.2
Online Ordering System Interface .................................................................... 39
7.3
Administration & Order Processing Application Interface .............................. 41
7.4
Input/Output Design.......................................................................................... 42
7.4.1
Ordering Module ....................................................................................... 42
7.4.1.1 Order a Product ..................................................................................... 42
7.4.1.2 View Order Status ................................................................................. 43
7.4.1.3 Modify Account Information ................................................................ 43
7.4.2
Order Tracking Module ............................................................................ 43
7.4.2.1 View Orders .......................................................................................... 43
7.4.2.2 Update Order Status .............................................................................. 43
7.4.3
Customer and Product Administration Module ........................................ 43
7.4.3.1 Add Customer Account......................................................................... 44
7.4.3.2 Modify Customer Information .............................................................. 44
7.4.3.3 Delete Customer Account ..................................................................... 44
7.4.3.4 Search Customer ................................................................................... 44
8
Conclusion ............................................................................................................... 45
Appendix A: System Information Flow ....................................................................... 47
Appendix B: Software Architecture .............................................................................. 48
Appendix B-1: Repository-Based Architecture ............................................................. 48
Appendix B-2: Model View Controller (MVC) Architecture ........................................ 49
Merkley Headgear System Design
4
Appendix B-3: Server Client Architecture .................................................................... 50
Appendix B-3.1: Two-Tier Server Client Architecture ............................................ 50
Appendix B-3.2: Three-Tier Server Client Architecture .......................................... 51
Appendix B-3.3: Comparison between Two-Tier and Three-Tier Architecture ...... 52
Appendix C: Computer System Configuration ............................................................ 53
Appendix D: Use Cases ................................................................................................... 54
Appendix D-1: General Use Case................................................................................. 54
Appendix D-2: Customer Use Case .............................................................................. 55
Appendix D-3: Sales Representative Use Case ............................................................ 56
Appendix D-4: Integrated Database Use Case ............................................................. 57
Appendix E: Sequence Diagram .................................................................................... 58
Appendix F: Activity Diagram ...................................................................................... 59
Appendix G: Class Diagrams ......................................................................................... 60
Appendix G-1: Class Diagram Overview (With Redundancies)................................... 60
Appendix G-2: Finalized Class Diagram (Without Redundancies) .............................. 62
Appendix G-3: Data Dictionary.................................................................................... 63
Appendix G-4: Additional Classes not included in Entity Class Diagram ................... 64
Appendix G-4.1 Class Web-based Client Application ............................................. 64
Appendix G-4.2 Class Integrated Database .............................................................. 65
Appendix G-4.3 Manufacturing, Shipping Class and Record Class ......................... 66
Appendix H: Collaboration Diagram............................................................................ 67
Appendix I: State Diagrams ........................................................................................... 68
Appendix I-1: System Overview .................................................................................... 68
Appendix I-2: Web Ordering System ............................................................................ 69
Appendix I-3: Administration & Order Processing System .......................................... 71
Appendix J: OCL Descriptions...................................................................................... 72
Appendix K: Database Table Design ............................................................................ 74
Appendix L: ACID Compliant Database ..................................................................... 75
Merkley Headgear System Design
5
Appendix M: Preliminary Entity Relationship Diagram ............................................ 76
Appendix N: Final Entity Relationship Diagram and Design .................................... 77
Appendix N-1: Final Entity Relationship Diagram ...................................................... 77
Appendix N-2 Data Dictionary for Final Relational Schema ....................................... 78
Appendix O: Operation Costs........................................................................................ 79
Appendix P: User Interface Design ............................................................................... 84
Appendix P-1: Web Ordering System Application........................................................ 84
Appendix P-2: Administration & Order Processing Application ................................. 90
Appendix Q: Functional Requirements ........................................................................ 92
Appendix Q-1: Details of Data Storage ........................................................................ 92
Appendix Q-2: Details of Output .................................................................................. 92
Appendix Q-3: Details of Input ..................................................................................... 93
Appendix Q-4: Details of Information Processing ....................................................... 94
Appendix R: Non-Functional Requirements ................................................................ 95
Appendix R-1: Interface Requirements ......................................................................... 95
Appendix R-2: Performance Requirements .................................................................. 95
Appendix R-3: Operating Requirements ....................................................................... 96
Appendix R-4: Lifecycle Requirements ......................................................................... 97
Appendix R-5: Economic Requirements ....................................................................... 97
Appendix R-6: Server Requirements ............................................................................. 98
Appendix R-7: System Infrastructure ............................................................................ 98
Appendix S: Glossary of Terms ................................................................................... 100
Appendix T: Team Meetings........................................................................................ 101
Appendix U: Team Report Form ................................................................................ 103
Merkley Headgear System Design
6
1 INTRODUCTION
1.1 Objective
The objective of this study is to design a global system architectural which will
include hardware, software and networking specifications as outlined and proposed by
the requirements analysis to assess the ordering and inventory problems at Merkley
Headgear. In addition, a proposed detailed software architecture defining a relational
database schema and suitable I/O procedures and interfaces will be discussed to deploy a
complete operational system. The new architectural system is to improve errors created,
through inspection and human techniques, by means of an efficient design.
The document outlines the design of the new system to substantial improve the
current system and will be addressed to John Kovacs, the Head of Operations and the
Database Management Programming Staff for further approval.
1.2 The Organization
Established in 1978, Merkley Headgear is the world’s largest ski headgear
supplier with offices in Toronto, Buffalo, Colorado, Japan, and Germany. The company
currently employs 200 people; the Toronto corporate office is home to all of its product,
design, graphics, production, sales and marketing, and customer service departments.
Merkley Headgear currently sells in 23 countries to clients like ski resorts, golf resorts
and corporate companies including those in the Fortune 500. It also provides headwear
for world-class sporting events, such as the PGA tour, World Alpine Championships, and
the past five Olympic Winter Games. There are presently 2200 customers with 60007000 ship to addresses. Merkley also receives contract work from clients as well as
orders from individual customers.
2 SYSTEM OVERVIEW
2.1 The Current System
Merkley Headgear’s current system is an Oracle-based system that is used for
labour and production tracking, inventory tracking, as well as for keeping financial
records. The process of taking and processing an order and updating inventory involves
sales representatives taking a customer order by phone, fax or mail. The representative
enters the received order into an electronic form on a Microsoft Excel spreadsheet (refer
to Appendix A of Feasibility Study). The order form is then sent out to the production
department, which creates a work order indicating the number of hats to produce,
materials to use, and how to manufacture the hats. Once the hats are produced, they are
put into the warehouse as inventory. Inventory is kept track in the ERP (Enterprise
Resource Planning) system and is manually updated on a daily basis. When an item
Merkley Headgear System Design
7
needs to be retrieved from the warehouse one must find the item in storage, tag the item,
fill out a form to update inventory figures, and send it to a front office clerk to enter the
data into the ERP system.
2.2 The Problem
The company faces many problems with its current mode of operation.
According to John Kovacs, Director of Operations and Chief Financial Officer of
Merkley Headgear, there are numerous errors in processing orders, tracking inventory,
and tracking labour and production (refer to Appendix B of Feasibility Study). Not only
does this operation create many errors in inventory data and order records, it is also
expensive and inefficient.
When a customer wants to make an order, a sales representative must be
contacted with order information by phone, fax or mail. Customers do not have a
standard form to fill out, thus pertinent information needed to fulfill an order, such as the
hat model, style, size, and company ship to, is occasionally omitted when placing orders
by fax or mail. Additionally, since these orders are hand-written, it may be difficult to
read the information to create the order. Both of these situations result in the sales
representative needing to contact the customer to obtain or verify the vital information
required. This evidently wastes time and decreases the efficiency of the sales
representative to take new orders from other customers. Once the sales representative
acquires all the proper information from the customer, the data must be entered into the
electronic order form. During this process, typos may occur and the data is incorrectly
inputted, which may lead to severe consequences. For example, if an order is made for
100 hats and the amount is accidentally entered as 1000 or if the product number is off,
leading to a whole production of hats in the wrong style, the company would experience a
great financial loss, not only in inventory but in operation costs as well.
2.3 The Proposed System
The new system uses an online order form with order legitimacy verification
software and digital work orders. To answer the error-prone and time consuming data
entry problems associated with current order receipt procedure, an online order form
would be created. Through this online form, customers would input and submit their
order information online (eliminating the need for manual data entry to the ERP system).
Submission of this form would then prompt the insertion of the information into a raw
customer orders database. To combat the tedium and potential inefficiency of sorting
through online orders, (particularly the possibility of numerous illegitimate orders)
legitimacy verification software could be implemented to comb through the raw order
submissions database and port legitimate orders to a valid orders table linked to the raw
orders table by order ID, while flagging certain orders and porting them to another table
in the database (also linked by order ID) for further verification by order processing
personnel. These personnel could be notified via automated e-mail notification of any
suspicious orders. The verification software would use various criteria to assess the
Merkley Headgear System Design
8
validity of orders including order size, by keyword, and credit card verification.
To help alleviate difficulties encountered during the order processing phase,
which currently causes significant inventory problems including delayed and often
inaccurate stock and order status information, a system utilizing digital work orders with
completion signature technology could be implemented. In this system, when an order
has been made and must be sent to the factory floor for manufacturing, a computer can
generate a digital work order. This work order would contain a special signature, which is
based upon its unique primary key in the legitimate orders database. The work order
would be generated through functionality offered by the integrated database, where a
small application would interface the database and make functionality such as this
possible. Upon generation of the work order, the database is updated by changing a field
in the database marked Order Status to “In Production”. Upon completion or filling of
the order, a member of the order processing team simply queries the database by the
signature generated by the digital work order through the program that interfaces the
database, and indicates that the order has been filled. When this command is entered, it
prompts a changing of the order status to “Shipped”, and modifies inventory records
(stored in a linked database) in real-time. This thereby eliminates the need for manual
modification of inventory records and current order status.
Through this system, additional functionality could even be offered to customers.
Order status could be obtained as well as checking their order information and perhaps
making modifications (under the condition their order has not yet reached the production
phase). This functionality would be implemented in an analogous fashion to the interface
offered to employees.
3 GLOBAL ARCHITECTURE
3.1 Software Architecture
There are a various number of software architectures that can be employed to
facilitate communication between software system components (refer to Appendix A:
System Information Flow). This section will review three types of architecture
considered for Merkley Headgear’s system.
3.1.1 Repository-Based Architecture
A repository-based architecture has a central data structure and a multiple number
of independent components that operate on the central structure.1 Typically, one process
completes before another one begins. For Merkley’s system, the central data structure
would be the Oracle database and the independent components are the end-user
applications. Each application accesses the database, allowing for transmission and
reception of information between the central and peripheral structures (refer to Appendix
B-1: Repository-Based Architecture)
1
Source: CSC340 Lecture 18: Software Architectures. Slides 10-11
Merkley Headgear System Design
9
3.1.2 Model View Controller (MVC) Architecture
Since user interfaces are a key aspect in the proposed system, the Model View
Controller (MVC) architecture serves as a viable alternative. The MVC architecture
involves the following three subsystems (refer to Appendix B-2: Model View Controller
Architecture):
Model
- provides the main functionality of the application and is aware of each of its
dependent view and controller components
- the model for Merkley’s system would be the Oracle database
View
- each view corresponds to a particular style and format of presentation of
information to the user
- the view for Merkley’s system would be the web ordering system
application, which retrieves data from the model and updates its
presentations when data has been changed in one of the views
Controller - accepts user input in the form of events that trigger the execution of
operations within the model
- the controller for Merkley’s system would be the order processing and
shipping application, which may trigger updates to the model and views.
3.1.3 Client Server Architecture
A client server architecture is a modular infrastructure that uses a relational
database management system (DBMS) to quickly perform user queries.2 It consists of
two components: service consumers (clients) and service providers (servers). The client
and server communicate with each other through exchanging messages. There are three
protocols by which requests and responses are sent:
a) Remote Procedure Call (RPC)
The client invokes a remotely located procedure, which is executed and the results
are sent back to the client.
b) Remote Data Access (RDA)
The invoked procedure is a database query (e.g. SQL) and the response is often a
large set of data.
c) Queued Message Processing
Requests are queued and processed whenever possible.
For Merkley’s application system, the most appropriate protocol to use would be
the RDA protocol since querying a database and receiving large data results are necessary
functions. With a client server architecture, two models need to be discussed: two-tier
and three-tier architecture.
2
Source: http://www.sei.cmu.edu/str/descriptions/clientserver_body.html
Merkley Headgear System Design
10
3.1.3.1 Two-Tier Client Server Architecture
The client is the user-interface application located on the user’s desktop
environment. The client queries and updates information on the server (database
layer). The client contains the code base required to query the database and to
format data returned from the server. The database tier contains the DBMS and
business logic to service multiple simultaneous clients. The two-tier architecture
allows direct communication between the user application and database, thus
processing management is divided between the client and the server (refer to
Appendix B-3.1: Two-Tier Server Client Architecture).
3.1.3.2 Three-Tier Client Server Architecture
Three-tier client server architecture differs from two-tier architecture in
that three-tier architecture involves a processing layer between the user interface
client environment and the database management server environment (refer to
Appendix B-3.2: Three-Tier Server Client Architecture). The client and server do
not communicate directly with each other, but with a processing layer instead.
The middle layer handles the processing management that carries out the business
logic and processes queries from the user application. In this model, the user
application sends requests (query or information updates) to the processing layer,
which then sends the processed queries to the database server. The server returns
data from the database to the processing tier, which then sends the data to the
client application.
3.1.4 Recommendation
For Merkley’s application system a client server architecture will be employed.
A client server architecture is the most feasible because simultaneous users must access
data from the database. A thin client (most of the functionality is provided by the server)
and thick server (offers a lot of functionality) will be utilized. The client and server will
communicate using an RDA protocol, allowing clients to query the shared database and
allowing the server to return large amounts of data back to the clients. The specific client
server architecture used for the system will be a three-tier model. From the model
comparison summary (refer to Appendix B-3.3: Comparison Between Two-Tier and
Three-Tier Architecture), the three-tier model is the best solution as it provides more
flexibility, maintainability, and scalability than the two-tier model.
3.2 Computer Network Specification
The current networking at Merkley uses a 45 Node TCP/IP Windows system.
The cables used for the network are copper Ethernet, and has a maximum transmission
rate at 100Mbps. The network hub will support the interface between the machine
running the Oracle database (refer to Appendix R: Non-Functional Requirements) and the
Merkley Headgear System Design
11
host machine, which will run the web server application (refer to Appendix R: NonFunctional Requirement).
In order to avoid any disruptions with the information flow, the microcomputers
will be separated within an acceptable distance so that data flow can be split and
efficiently channeled by the switched hub.
The new proposed system can use the existing network to connect to the database
and the web server (using TCP/IP), and at the same time query the database and return
the results.
3.3 Web Application Server Specification
The system is using off-the-shelf servers from Dell and the facility has been very
satisfied with the services provided. The technical support that Dell provides was also
very good and they actually helped with setting up the infrastructure. Refer to Appendix
C: Computer System Configuration) for more details.
For survivability reasons an auto-backup feature needs to run every week where
the backup is stored on a Tape Backup (fulfilling non-functional requirements as
specified in Appendix R: Non-Functional Requirements). This feature is built into the
server.
4 PLATFORM SELECTIONS
4.1 Overview: Criteria for the Computing Platform
It is necessary to select a computing platform that consists of hardware, and
software such that it meets the demands of Merkley's inventory problem and at the same
time, offer an efficient solution to run all required operations. The criteria for the
hardware platform are listed below.
4.1.1 Open System Criteria:
We want flexibility so that the hardware we choose can be easily replaced by a
similar system from a different manufacturer. This is because Merkley needs to
implement this system in their other global branches. The other option is to have a
proprietary system. The problems with a proprietary system are that such a system is
costly and only available from one vendor, which will create potential problems for
Merkley. However, by imposing an open system, Merkley can easily change vendors;
competition from other vendors will keep system costs low.
4.1.2 Black-Box Criteria
Since customers will be involved in secure transactions online, we do not want a
"Glass Box" system, where the internal system design and implementation can be
Merkley Headgear System Design
12
accessed by a customer. A "Black Box" system will be imposed for security reasons to
avoid outsiders such as hackers to steal protected customer information, and to protect
Merkley employees from manipulating the system (refer to Appendix R: Non-Functional
Requirements).
4.2 Hardware Platform
The first task is to determine which hardware platform to choose from. From a
business perspective, we can choose from 4 possibilities:
 Mainframes are large centralized computers. They can provide the bulk of
business computing through time-sharing.
 Commercial Minicomputers are single-user, relatively simple machines running
simple program-launcher operating systems that are now replaced by
microcomputers.
 Microcomputers are essentially smaller, less expensive versions of mainframes
for businesses that cannot afford true mainframes
 Embedded Systems combine computer hardware and software, and perhaps
additional mechanical or other parts, designed to perform a dedicated function
4.2.1 Reasons for the Use of Microcomputers
1) The cost and maintenance of mainframes and commercial minicomputers are high.
Merkley would not require a mainframe because although they do handle largescale tasks, such as updating large inventory systems, standard microcomputers
have evolved to become powerful and fast enough to perform many of the main
operations that mainframes can handle. In fact, because the number of transistors
in computer chips doubles every eighteen months according to Moore's Law, many
microcomputers have become fast enough, and will be even faster than the
mainframes we have today.
Reference: (http://www.db2mag.com:8080/db_area/archives/2002/q3/lynch.shtml)
2) Mainframes and commercial minicomputers are only ideal for extremely large
tasks, such as keeping a centralized billing system worldwide. Integrating a worldwide system is not necessary and can be harder to maintain since Merkley is more
concerned about reliability. For instance, if the mainframe crashes it will affect the
whole system, resulting in longer time for repairs and higher costs. With the use of
microcomputers, standard components would be readily be available allowing for
quicker repairs.
3) An embedded system such as an integrated telecommunication hardware or
software is not necessary at this moment, according to Merkley. Paying the higher
costs for this system will only reduce Merkley's profits.
Merkley Headgear System Design
13
4.3 Software Selection
There are a couple of software components that need to be discussed: operating
system and database server.
4.3.1 Operating System
The operating system (OS) will serve as a backbone that bridges communication
between software, hardware and any other applications running under the operating
system. All desktops use the Windows 2000 Server operating system. For ease of
integration, an OS with a GUI interface is required considering the machines were
purchased from Dell- an Apple OS has already been ruled out. Again, Windows is a
viable OS because of the staff ‘s familiarity with it. Also, since the Merkley’s current
system has been recently upgraded to Windows 2000 Server (refer to Appendix R: NonFunctional Requirements), it would not be necessary to upgrade to Windows XP as
employees have not been experiencing any problems with the current OS. Additionally,
due to licensing issues, a bid for Windows 98 had failed.
4.3.2 Database Server
The database system will be implemented using the existing Merkley Oracle
software currently under license. Merkley currently has Oracle8i database tools under
license and would purchase Oracle9i Developer Suite for Java development with SQL as
software to interface the database and offer the proposed functionality. The database will
preside on a dedicated server, which will be securely connected to the website and will be
accessible to a Merkley intra-network.
4.3.3 Design Justification for Using Oracle9i Database
The following design justifications for using Oracle9i Database are based on our
Requirements Analysis (refer to Appendix R: Non-Functional Requirements).
4.3.3.1 Scalability
Oracle is the most scalable database in the market. Scalability is a requirement
for Merkley due to the fact that Merkley's branches are located worldwide.
Oracle's database scalability is attributable to the fact that it offers OLAP
(Analytic Queries Per Minute technology) with Real Application clusters, which
surpasses both Microsoft and Hyperion. Comparing this software to others, it
performs up to 75 times faster than any of the competition. Oracle enables
delivery of enterprise-scale business intelligence to thousands of users efficiently
and cost-effectively.
Source:(http://www.databasejournal.com/features/mssql/article.php/2170201)
Merkley Headgear System Design
14
4.3.3.2 Increased Security
Once again, you cannot beat Oracle in the security space. Oracle9i database has
15 international security evaluations to its credit along with a slew of other
security features built from the ground up not bolted on, including control data
access down to the row level, and meeting federal and international standards for
data privacy and assurance.
4.3.3.3 Ease of Integration
Integration between Merkley’s existing Oracle software and the new software will
be much easier than implementing new software. The time it takes to set up
different database software will take more time and waste many man hours in
order to training staff to learn new software. In addition, according to Oracle's
web page http://www.oracle.com/, we know that Oracle has several upgrade
options from Oracle8i to 9i, depending on the client’s needs. Moreover, Oracle
provides many courses for the current database administrators to upgrade their
experience to Oracle9i from Oracle8i database as well as articles and tips on
migration from 8i-developed databases to 9i for greater scalability, reliability, and
safety.
In sum, the upgrade is primarily due to the fact that there are a few functional
aspects included in Oracle9i that is not offered in Oracle8i database. By using Oracle9i,
there will be an improved database on several fronts. With superior security and
increased scalability with new data processing techniques, Merkley would save a lot of
money and have a more efficient system to boot.
4.4 Programming Language
4.4.1 SQL
The Structured Query Language is a database query language that was adopted as
an industry standard. SQLs widespread acceptance by relational database vendors will
substantially increase the speed it takes for orders to be processed. The strengths of SQL
will benefit all ranges of users, including Merkley's employees and customers.
4.4.1.1 Reasons for Using SQL
Costs
The SQL data sub language is already supported with the existing Oracle8i
relational database to which Merkley currently holds a license. Purchasing new
hardware and software may accrue higher costs for Merkley.
Integration with Oracle
Merkley Headgear System Design
15
SQL is tightly integrated with Oracle. As a data sub language, SQL is specifically
designed to interface a relational database, such as Oracle8i, and all SQL
statements are instructions to the database. In other words, SQL statements use an
optimizer as part of Oracle8i that determines the fastest means of accessing the
specified data. Oracle8i also provides techniques you can use to make the
optimizer perform its job better.
Functionality
SQL processes sets of data as groups rather than as individual units so that we can
find queries quicker since it also provides automatic navigation to the data. For
example, to retrieve a set of rows from a table, you define a condition used to
filter the rows. All rows satisfying the condition are retrieved in a single step and
can be passed as a unit to the user, to another SQL statement, or to an application.
You need not deal with the rows one by one, nor do you have to worry about how
they are physically stored or retrieved.
4.4.1.2 The Use of SQL
SQL statements will be used to process the queries in our tables. An embedded
SQL program basically consists of code written in an ordinary programming
language mixed with SQL commands in specially marked sections. To build the
program, the source code is first passed to the embedded SQL preprocessor,
which converts it to an ordinary C or Java program. Afterwards it can be
processed by a C or Java compilation tool chain. Embedded SQL has advantages
other methods for handling SQL commands from C and Java code.
4.4.1.3 Advantages of Embedded SQL

One of the advantages of embedded SQL is that it can help Merkley reduce
overhead, improve performance, and increase productivity. For example,
without embedded SQL, Oracle must process SQL statements one at a time.
Each SQL statement results in another call to the server with higher
overhead. However, with embedded SQL you can send an entire block of
SQL statements to the server. This minimizes communication between the
web application and Oracle database system.

Secondly, embedded SQL takes care of the tedious passing of information to
and from variables in Java and C programs. Also SQL in C or Java is defined
in the SQL standard and supported by many other SQL databases.
Embedded SQL is typically implemented in C, however we propose that Merkley
instead incorporates Java in the embedded SQL instead of doing it in C/C++. The
main reason for this decision is due to the benefits of Java over C/C++.
Merkley Headgear System Design
16
4.4.1.4 Reasons for Embedded SQL with Java
There are some advantages not to use the C/C++ language, which is typically
used to program in SQL and to use embedded SQL in Java instead.
1) The absence of pointers and its automatic garbage collection eliminates many
bugs. In addition, it facilitates programming and the safety of program
execution considerably as programmers do not need to dynamically allocate
memory and then remember to free it later. Thus it avoids the risk of memory
leaks.
2) Java is easier to teach and learn because of its streamlined syntax. It inherits
less baggage from the C language. The extensive and standardized Java API
makes it considerably easier to program in Java than in C++.
3) The standard Java API includes built in, standardized libraries for TCP/IP
network sockets and services, SQL Database access, and many other areas.
C++ libraries which perform similar functions to the Java API are usually
available, but there are typically several competing and mutually
incompatible versions with overlapping functionality which cannot easily be
used together.
4) Lastly, Java can be programmed for multiple plaforms with little regard
towards platform-specific characteristics like hardware data types, floating
point implementations, or OS libraries.
4.5
Web Programming Technologies
The online web application will be developed using Java server-side technology
(servlets). Along with SQL statements, the server-side code will perform the necessary
database I/O that is required to facilitate the proposed functionality. JavaScript will be
used on the client side for all verification and page validation of customer submissions.
Justification for Using Servlets
1) Compared to other server-side technologies such as CGI, servlet technology is
much faster and more efficient.
2) Since servlets are simply Java programs, it allows an entire web application to be
developed using one programming language alone. The interactions remain within
this single language domain and eliminate extra levels of data transmission.
Merkley Headgear System Design
17
5 PROGRAM DESIGN AND SUBSYSTEMS
In order to give a full description of the detailed design of the application
component of the system, we will analyze the components and subsystems in terms of
Boundary Classes, Control Classes, Entity Classes, Database Classes, Use Cases,
Sequence Diagrams, State Diagrams, and Activity Diagrams.
5.1 Subsystem Descriptions
Before the final UML diagrams can be described, we must consider all the
subsystems that were mentioned in the Requirements Analysis. Below is an overview
that outlines the key subsystems involved in the order processing cycle. The following is
a summary of their functionalities:
 Client subsystem – Represents the interaction between a client and the web-based
ordering application.
 Customer and product administration subsystem – Represents the interaction
between the sales representative and database in order to manage customers and
products
 Manufacturing subsystem – Represents the interaction between manufacturing
staff and the Administration & Order Processing application.
 Shipping subsystem – Represents the interaction between shipping staff and the
Administration & Order Processing application.
5.1.1 Client Subsystem
Activities and Entities/Actors Involved:
 A customer creates a new order online by filling out an online order form with the
required information
 A customer has the option to modify account information (e.g. new address) and
must access and change their account information via a web form
 A customer checks the current status of an order that he or she has submitted
 A customer browses or searches Merkley’s online catalogue for products
 A customer adds an item found in the catalogue to the cart of present order
5.1.2 Customer and Product Administration Subsystem
Activities and Entities/Actors Involved:
 A sales representative can create or delete a new user
 A sales representative may update user account information and permissions
 A sales representative can search for existing customers
 A sales representative can add or remove a product to and from the catalogue
 A sales representative can configure a new product or modify existing product
details
Merkley Headgear System Design
18
5.1.3 Manufacturing Subsystem
Activities and Entities/Actors Involved:
 A manufacturing clerk generates a digital work order from the Administration &
Order Processing application
 An order processing person signifies an order complete to the Administration &
Order Processing application
5.1.4 Shipping Subsystem
Activities and Entities/Actors Involved:
 The shipping staff pulls up the orders to be shipped that day from the
Administration & Order Processing application
 A shipping person signifies that the order had been shipped to the Administration
& Order Processing application
5.2 Using the BCED Approach
In the design process, there are four types of classes that must be considered,
which can be broken down by identifying the classes in our system that make up the all
our BCED classes.
Boundary Classes: These specify interface functions and applications. In our case, this
will be the WebBasedClientApplication. Further details about the interface are described
in Section 7: Interface Design. Refer also to Appendix G-3: Data Dictionary.
Control Classes: These specify business logic functions and other processes involved in
processing and delivering information in the system. Refer to Appendix G-3: Data
Dictionary.
Manufacturing Class:
Manufacturing staff are responsible for the production of products as well as
delivering information within the system.
Shipping Class:
Shipping staff are responsible for the process involving delivering a product to a
customer and completing a business function in the overall system.
Merkley Headgear System Design
19
Entity Classes: These represent in-memory, run-time data structures for the database.
Any redundant information is removed from the classes, which model the relational
schemas (tables) in the database (refer to Appendix G: Class Diagrams).
Customer Class
This is part of the entity class because the database needs to retrieve information
about the customer such as their Customer ID shipping address in order to process an
order.
Order Class
The database will need an order entity so that it can match the Order ID to find a
product in Merkley's inventory.
Product Class
The justification that this must be an entity as part of the database is that Merkley
does not only have one product, but many. Each must be identified by Product ID so that
a customer order can be completed.
Inventory Class
We also need an inventory class that will act as a relationship in our Entity
Relationship Diagram (to be further discussed in Section 5: Database Design) because
we know that inventory is composed of a composition of products. We need a way to
access any particular product from the database.
Database Classes: These correspond to the application classes and describe what will be
stored persistently (refer to Appendix G: Class Diagrams).
WebBasedClientApplication
This database class describes the interaction between a client and the online web
application. It also provides a channel for the information flow between the web
application and the Oracle database.
Integrated Database
This is the actual database class that will handle the queries that are made by
either the customer or the Merkley’s employees.
Merkley Headgear System Design
20
5.3 Class Diagram Modifications
From the classes above, we have modeled only the relevant classes in our class
diagram. The interactions between the BCED classes can be merged and simplified to
create two class diagrams that are fundamental in the design process.
Overall Class Diagram - This class diagram will provide an overview of the system
described above. Specifically, it will model the Boundary, Control, Entity, and Database
Classes in a simplified form. See the Appendix G: Class Diagrams for the overall class
diagrams.
Entity Class Diagram - This class diagram is vital later on for generating the relational
schemas and the ER diagrams (further described in Section 5: Database Design). The
entities presented in this class diagram show a reduced, yet very efficient design of the
information system that is to be modeled.
5.4 Use Cases
General Use Case
The use case diagram illustrated in the general use case for the information
system (refer to Figure D.1 under Appendix D: Use Cases). Either a personal or corporate
customer will use the online web application. Depending on their activity in the system,
they will query the customer table or the orders table by creating or modifying account
information, placing an order, or checking on the status of their orders. These interactions
occur between the online web application and the database. Once this information is
stored in the database, a sales representative may modify any of the information including
information about products in the catalogue. A sales representative may also manually
create a corporate account for a corporate customer. All these interactions are made
between the sales rep and the Administration & Order Processing application. This
application interacts with the database as the online web application does. Once all
information about accounts and orders has been modified, manufacturing staff generates
a digital work order and completes the order, telling the application it is complete. Then
shipping staff ships the item to the customer.
Customer Use Case
This use case describes the available options to a customer that is logged onto the
web system (refer to Figure D.2 under Appendix D: Use Cases). Customers have an
option to create a customer account, as well as view and modify account information.
Customers may also place an order by submitting an electronic order form and then check
the status of their order. Lastly, the customer must log out of the system for security
measures.
Merkley Headgear System Design
21
Sales Representative Use Case
This use case shows the interaction between a Merkley sales representative and
the database (refer to Figure D.3 under Appendix D: Use Cases). As can be seen the sales
representative can perform the following operations: login/logout of the system; create,
modify, or delete a customer account; search for customers; search for products; add or
delete a product; modify information about a product; and update a product's inventory
records.
Integrated Database Use Case
This use case describes the functionality of the integrated database (refer to Figure
D.4 under Appendix D: Use Cases). When an order form is sent to the database, the
values are inserted into their appropriate tables. That is to say, customer information is
placed in a Customer table by customer ID, and product information is placed into a
Product table, sorted by a unique product ID number. In the case that the customer wants
to update or modify the account or ordering information, the integrated database must
also modify those values in its appropriate tables. For these operations, the integrated
database must also have the ability to search for a customer in the Customer table by
customer ID. Lastly, the integrated database must have the ability to search for a
particular product so that the customers and employees may get information for a specific
product.
5.5 Sequence Diagram
Customer Interaction
The purpose of the sequence diagram is to represent the use case previously
presented without being limited by the relationships between the actors of the system.
That is, we are not only interested between the interactions between the actors and
entities of the system, but we also want to know both the synchronous and asynchronous
relationships between each actor as a function of time.
The sequence diagram illustrates the timeline from customer account creation until
shipment (refer to Appendix E: Sequence Diagram) from the perspective of a personal
customer. First a customer enters the site and creates an account. After the account has
been created the web server will send confirmation back to the client. That customer may
then login. If they enter a valid login they are logged into the system. Once a customer
has created an order, they submit it to the web server. The web server then verifies the
order and sends a confirmation message with the order number for reference. At this
stage the order processing begins. First the database will check if the product is currently
available in inventory. If it is, the shipping staff may immediately ship it. Otherwise the
order is sent to production for filling of the order. Once the order is completely produced,
it is sent back to shipping and then shipped to the custom
Merkley Headgear System Design
22
5.6 Activity Diagram
We chose to model the ordering process from a personal customer’s perspective
with an activity diagram because we want to show the activities that describe
concurrency and synchronization when a customer creates an order online (refer to
Appendix F: Activity Diagram).
Description:
1) The first activity involves a customer going online and starting the order
application. A synchronization bar is needed because there are two parallel
transitions. One transition involves the process of logging into the system to place
an order.
2) At the same time, the customer must already have an existing account. Unless, a
customer has both an account and has logged in successfully, he or she will not be
able to place an order. In both cases, an error arises if either a customer does not
have an account or is not able to login because of an invalid user name or
password.
3) For each order that is placed, an electronic order form that contains the desired
items must be filled out. The diamond shape symbol after the "Fill Electronic
Order Form" activity represents a decision with alternate paths. The outgoing
alternates indicate if the condition is sufficient for an order request to be
processed.
4) If the order form is filled out properly with a valid credit card number and has no
missing fields, the order can be processed by the Oracle database. However, if
even one field is invalid, then the order is cancelled. In both cases, this would end
a customer transaction.
5.7 Collaboration Diagram
The purpose of this collaboration diagram is to show the interaction between a
customer (more specifically, a personal customer) and the actors involved in placing an
order in this system (refer to Appendix H: Collaboration Diagram). This will model the
sequence of events and actions without the time factor.
Interaction #1:
The first interaction occurs between the web server and customer. Upon initial
use of the web ordering application, the customer creates a new account.
Interaction #2:
The customer can then proceed to log into the system.
Merkley Headgear System Design
23
Interaction #3:
The customer interacts with the Web Server by submitting an electronic online
order form. Similarly, the web server receives the online form from the customer to be
processed.
Interaction #4:
This interaction occurs between the web server and the Oracle database. Before
the orders can be inserted into the database, the verification system must confirm that all
fields on the online form are not missing and that a valid credit card number is entered.
Interaction #5:
It is vital for the shipping staff to communicate and interact with the Oracle
database in order to check the status of a given order. The searchProduct( ) functionality
that the shipping staff and Oracle database both require in order to communicate with
each other is important because this will allow inventory to be kept up-to-date in an
electronic database. At the same time, this will also inform staff if the order needs to be
sent to the manufacturing staff to produce more items, or if they can ship the product
directly.
Interaction #6:
This interaction is a subclass of the interaction between the shipping staff and
both the customers and manufacturing staff. In the case that the product is available, the
product can be shipped directly to the customer and a direct interaction occurs.
Interaction #6:
The shipping staff also needs to interact with the manufacturing staff. This occurs
if a product is not available in Merkley's inventory. In this case, the manufacturing staff
must create a digital work order and start production.
5.8 State Diagram
5.8.1 Entire System
The state diagram modeled in Appendix I-1: System Overview illustrates the order
processing cycle from order submission to shipment. Once the customer goes online, we
enter the order super state. Once the customer has completed his/her order, it is verified
by the online application; if no errors or omissions are detected, it then moves to the next
state- the validation super state.
Within the validation super state, the order is first received and placed into the
Orders table of the database. The verification system then analyzes the orders for any
suspicious entries. If the order is determined to be completely invalid, it is immediately
discarded and the process ceases. Otherwise, the order is confirmed and inventories are
checked for stock.
If enough items are determined to be in stock (i.e. not a custom order), order
processing personnel execute the order completion function. If not enough of the item is
Merkley Headgear System Design
24
in stock a digital work order is generated by order processing personnel. At this stage the
order status becomes “In Progress”. Production then commences. The order completion
function is then executed and inventories are updated. Order status is now changed to
“Completed production”. If more items must now be produced to fill the order), the
shipping department waits for order completion. Once all items are in stock, the order is
sent to the shipping department and ported to the shipping table for shipping and
dispatch. The order is then shipped and order status is changed to “Shipped”. The
customer can no longer modify their order at this stage.
5.8.2 Web Ordering Application Subsystems
The state diagrams modeling the different subsystems provide a more detailed
examination of Merkley’s system. Not all subsystems are modeled however, for the
reason that the omitted subsystems are not necessarily crucial within the overall system.
Login Subsystem
When a user accesses the website, he or she will be presented with a login screen
(refer to Figure I-2.1 under Appendix I-2: Web Ordering System). If the user does not
already have an account, he/she may create one (only if the user is a personal customer).
The user must enter a user ID and password and click on the Enter button. If a valid user
ID and password has been entered, the user will proceed to the Main Menu Screen. If an
incorrect user ID and password pair is entered, the text fields are cleared and the user is
prompted to try again. Upon three invalid login attempts, the user is directed to another
screen informing the user to contact customer support for assistance. If a user is a
personal customer, he or she may create an account (refer to Appendix Q: Functional
Requirements).
Main Menu Subsystem
Upon successfully logging into the ordering application, the user is presented with
the Main Menu screen with various menu options (refer to Figure I-2.2 under Appendix I2: Web Ordering System). Only a corporate customer has the option to create a customer
order (refer to Appendix Q: Functional Requirements). Choosing a particular option will
bring the user to another screen to perform specific operations (more detailed descriptions
in the following diagrams). Alternately, the user may choose to sign out of the session by
clicking the Sign Out button and return to the login screen.
Order Entry Subsystem
When a user selects the Order Entry option from the Main Menu, the user is
presented with the Order Entry screen (refer to Figure I-2.3 under Appendix I-2: Web
Ordering System). From here, the user can choose not to order any items and return to
the Main Menu or browse through the selection of products offered by the company. The
user can perform a search based on different criteria and click on a product to view more
information. The Product Information displays more detailed information about the
Merkley Headgear System Design
25
product in question and allows the user to add the item to the order. If the user has more
items to add to the order, he or she may return to the Order Entry screen to view more
products. If the user has no more products to order, he or she enters the required shipping
and payment information and confirms the order. From this point, the user may return to
the Main Menu or place another order.
Account Information Subsystem
When a user chooses to view his or her account information from the Main Menu
screen, the user proceeds to the Account Information screen. At this screen, the user can
view all the information associated with this account and choose to update information
(refer to Appendix Q: Functional Requirements). After the user has finished with this
application, he or she may return to the Main Menu.
5.8.3 Administration & Order Processing Application System
The Administration & Order Processing application system is modeled in
Appendix I-3: Administration & Order Processing Application. When a staff member
starts the Administration & Order Processing application on the local network, he or she
is prompted for a user ID and password. A valid user ID and password will allow the user
to proceed to the Main Menu. Three failed login attempts will direct the user to a page
advising him or her to contact the network administrator for assistance.
On the Main Menu screen the user has 4 options: view and update customer
accounts, update order and shipping status, configure products, and sign out of the user
session (fulfilling the Functional Requirements as described in Appendix Q: Functional
Requirements).
Selecting the Customer Accounts option will bring the user to a separate screen
listing all the customers. On this screen, the user can create new accounts or delete
accounts, update customer information, modify customer access levels, search for
specific customers, sort the list by different criteria, or return to the Main Menu.
Similarly, with the Orders and Product Configuration menu items, selecting one
will bring the user to the Orders screen and Production Configuration screens,
respectively. On these screens, the user may perform any functions allowed on the screen
and then may return to the Main Menu.
Merkley Headgear System Design
26
6 DATABASE DESIGN
The design of the database must match the operations of the system (refer to
Appendix Q: Functional Requirements), and since it specifies the relational schema to be
implemented, it must account for Merkley's inventory problems. The main data that need
to be accounted for when designing Merkley's database are as follows:
 The Corporate Customers- Merkley specializes to these customers through sports
and recreational events.
 The Orders are fundamental to the database design because we know that due to
the volume of orders, a database can slow down if not designed efficiently.
 Inventory must be kept up to date to prevent lose of sales, and customer orders
getting lost.
6.1 Database Design Criteria: Conforming to ACID
Our database design will also be based on the fact that Oracle is an ACID
compliant database. Thus the schemas will abide to ACID conditions (refer to Appendix
L: ACID Compliant Database) for more information on ACID. It is important to create a
relational schema with a minimal number of transactions (reads, and writes). This is
important in order to avoid any concurrency problems during simultaneous executions of
the program. By trying to reduce the number of reads and writes that are needed, our
relational schema, along with Oracle, will process queries and transactions quickly and
efficiently. A summary of the ACID compliant test is listed below:
1) Atomicity
Our relational schema must make sure that all elements of a given transaction take
place or none at all.
2) Consistency
The relational schema must ensure that each transaction transforms the database
from one valid state to another valid state.
3) Isolation
The relational schema must make sure that the effects of a transaction are not
visible to other transactions in the system until it is complete.
4) Durability
The relational schema must ensure that if a transaction has been committed, its
effects are permanent- even if the system crashes or if a disk dies.
Merkley Headgear System Design
27
6.2 Relational Schema Formation
We are to design a relational schema that reduces or eliminates (if possible) any
insertion, deletion or update anomalies. We also want to try to design a database such
that the following anomalies are avoided:
1) Insertion Anomalies
This occurs when it is not possible to insert attributes into a table without first
having information of another attribute. For example, if we insert product ID
alone we would have to make it possible to insert this attribute with its
corresponding tuples without knowing any other information like customer ID.
2) Deletion Anomalies
These occur when we delete an attribute from a table that causes extra loss of
information in another table.
3) Update Anomalies
These occur when multiple instances of a relation of attributes have to be
maintained.
The preliminary relational schema (before any normalization and removal of
redundancies) is given below based from the previous criteria. The first step to create a
Relational Schema and its corresponding ER diagram is to decide on the Main Identifiers.
6.2.1
Main Identifiers
The following identifiers require these Relations and Entities
Concept
Customer
Personal
Corporate
Orders
ProductForm
Production
Product
InventoryComposition
ShipsTo
Type
E
E
E
R
E
R
E
R
R
Identifiers
CustID
inherits from Customer (CustID)
CompName
CustID, OrderID
ProdID
WorkOrderID
ProdID
ProdID
Address
6.2.2 Constraints
There are no specific constraints for this database besides the basic functional
dependencies for each relation, which the identifiers will handle as keys.
Merkley Headgear System Design
28
6.2.3 Preliminary Relational Schema
The preliminary relational schema (before any removal of redundancies, and
normalizing) is a direct translation from the main identifiers we have and is a direct
translation from the ER diagram (refer to Appendix M: Preliminary Entity Relationship
Diagram).
Customer (Name, CustID, Password, BillingInfo, Payment, PhoneNumber)
Personal (HomeAddress)
Corporate (CompName, ShipToAddress)
Orders (CustID, OrderID)
ProductForm (CustID, OrderID, ProdID, OrderStatus, PaymentStatus)
Production (OrderStatus, WorkOrderID)
Product (ProdID, OrderID, Colour, Size, ProdName)
InventoryComposition (ProdID, Quantity)
ShipsTo (Address, ProdID, CustID)
6.3 Redundancy Analysis
We need to re-analyze the relational schema that we have created and examine if
there are any redundancies. For the relational schema, we will consider removing
generalizations, partitioning or merging entities, removing redundant entities and
relationships, and finally normalize our schema in the highest normal form.
6.3.1 Removing Generalizations
In the Customer entity, the generalization is not needed since the attributes
ShippingAddress in the Personal Customer entity and the ShipToAddress in the
Corporate Customer class are redundant since they repeat the same information. That is,
there are no relevant operations in the Personal or Corporate Child entities that are unique
to the Customer entity.
Therefore, we can delete the child entities of Personal and Corporate Customers
and add an attribute Type to the parent entity Customer.
6.3.2 Merging Concepts
The ProductForm entity is redundant because the attributes can be accessed from
other entities/tables and reduces both read and write operations.
Recall that the schema is:
ProductForm (CustID, OrderID, ProdID, OrderStatus, PaymentStatus)
-
CustID can be promoted to Orders (CustID, OrderID) and therefore this attribute
may be eliminated
Merkley Headgear System Design
29
-
ProdID can be promoted to Product (ProdID, OrderID, Colour, Size,
ProdName) since it also is a primary key in Product
OrderStatus can be promoted to Order (CustID, OrderID, OrderStatus) and thus
OrderID may be eliminated
PaymentStatus can be promoted to Order (CustID, OrderID, OrderStatus,
Payment Status) and thus Payment Status can be eliminated.
6.3.3 Removing Entity and Relation Redundancies
The Shipping Relationship can be removed since it contains redundant attributes
that can be pulled from other entities and relationships already defined.
a) ProductID can be found in the entity Product with attribute ProdID. Therefore
ProductID = ProdID is a redundancy.
b) ShippingAddress can be found in children entities of Customer as either
ShipToAddress or HomeAddress.
The redundancy is as follows:
Shipping.ShippingAddress
=
Personal.HomeAddress
=
Corporate.ShipToAddress
Thus we eliminate these attributes and have only one attribute Address that is
encompassed in the Customer entity. This will reduce the number of reads and
writes drastically. It will reduce the reads and writes from two tables (Shipping and
either Personal or Corporate tables).
c) ItemName is a redundant attribute because every Product is identified by ProductID
and this information is not important for Shipping and Ordering.
6.4 Schema Normalization
The relational schemas that we have defined require normalization to help produce a
schema that is not redundant.
6.4.1 Normalizing Relational Schemas in First Normal Form
Recall a relation is in First Normal Form (1 NF) if it does not include any multivalued attributes or any composite attributes. We have ensured that when designing our
relational schemas they are all at least in 1NF.
6.4.1.1 Relation Customer to be in First Normal Form
There is the only schema that is not in First Normal Form. The derivation of the
original relational schema had to undergo the removal of the Customer
Generalization. Below, will we will show the 1NF decomposition. That is, the
original Customer schema (before Generalization and 1NF) may have had
Merkley Headgear System Design
30
composite attributes from our Functional Requirements (refer to Appendix Q:
Functional Requirements). Consider the non-normalized schema:
Customer (UserID, Name, Billing Info, Phone Number, Password,
HomeAddress, Company , Ship to Address)
This is not in 1NF since HomeAddress, Company, and Ship to Address are multivalued attributes.
6.4.1.2 Decomposition Alternative One into 1NF
One option is to split the Customer entity such that the multi-valued attributes
such as HomeAddress, Company, Ship to Address (as part of the Customer
Entity) be promoted into relations into their own right to guarantee a 1NF
decomposition. But this can be avoided because we do not want the promotion to
lead to the schema:
Personal Customer (HomeAddress) and
Corporate Customer (Company, ShiptoAddress).
This is undesirable because attributes HomeAddress and ShiptoAddress give the
same information as previously mentioned (refer to Section 6.3.2: Removing
Generalizations).
6.4.1.3 Decomposition Alternative Two into 1NF
The other alternate is to apply the generalization that was indicated previously
(refer to Section 6.3.2: Removing Generalizations) by eliminating HomeAddress
and ShipToAddress, and to promote them as one value in the Customer Relational
schema to produce the final minimization to:
Customer (Name, Address, CustID, Password, PhoneNumber,
BillingInfo)
Note: The relational schema is still can be further normalized, and will be done
later.
6.4.1.4 Decomposition Selection
Clearly, Decomposition Alternative Two will be the best alternative to reduce
redundant attributes. At the same time, it will minimize the redundant children
tables of Customer, which will involve more read and write operations.
Merkley Headgear System Design
31
6.4.2 Normalizing Relational Schemas in Second Normal Form
A relation is in Second Normal Form (2NF) if it is in 1NF and all non-key
attributes depend on all elements of its key rather than a subset.
Customer is already in Second Normal Form (2NF) because it is in 1NF and the
non-key attributes Name, Address, Password, PhoneNumber, BillingInfo, and Type
depend on all elements of its key rather than a subset.
Customer (Name, Address, CustID, Password, PhoneNumber,
BillingInfo,Type)
Personal and the Corporate entities of Customer have been eliminated due to the
merging of HomeAddress, CompName, and ShipToAddress simply to preserve the 2NF
decomposition of Customer. Therefore these relational schemas are eliminated:
Personal (HomeAddress)
Corporate (CompName, ShipToAddress)
ProductForm, and Production are not in 2NF because not all their non-key
attributes depend on all elements of its key rather than a subset. For example in
ProductForm, the OrderStatus is not dependant on PaymentStatus, but only on OrderID.
Note also that Production will be eliminated if ProductForm is eliminated because
OrderStatus will not be accessible. Thus they need to be merged to Order to ensure 2NF
decomposition. These relations are eliminated due to redundant attributes and a violation
of 2NF:
ProductForm (CustID, OrderID, ProdID, OrderStatus, PaymentStatus)
Production (OrderStatus, WorkOrderID)
If we merge OrderStatus to Order, although it looks similar to ProductForm, we
can note that there are only 2 non-key attributes, PaymentStatus and OrderStatus, which
were already mentioned to be dependant with each other. All other attributes also depend
on each other so that all non-key attributes in Order Status depend on all elements of the
set.
Order (CustID, OrderID, ProdID, PaymentStatus, OrderStatus,
Inventory is already in 2NF because its only non-key attribute does depend on
ProdID.
InventoryComposition (ProdID, Quantity)
Merkley Headgear System Design
32
6.4.3 Normalizing Relational Schemas in Third Normal Form
Recall a relation is in Third Normal Form (3NF) if it is in 2NF and none of its
non-key attributes depends on any other non-key attribute. In other words for any
relationship R, where R (A, B, C, D, E, F) represents the schema and A, B, C are primary
keys, if there exists say D-> E, which is a non-key attribute, we have violated a 3NF
condition.
a) Customer is in 3NF because the non-key attributes Name, Address, Password,
Phone Number, BillingInfo, and Type do not functionally depend on each other in
the schema that we have designed. Thus the following is in 3NF:
Customer (Name, Address, CustID, Password,
PhoneNumber,BillingInfo,Type)
b) Also Order is in 3NF because the non-key attributes PaymentStatus, OrderStatus,
Quantity, and TotalPrice do not functionally depend on each other in the schema
that we have designed. Thus the following is in 3NF:
Order (CustID, OrderID, ProdID, PaymentStatus, OrderStatus,
Quantity,TotalPrice)
c) The entity Product is also in 3NF because the non-key attributes PaymentStatus,
OrderStatus, Quantity, and TotalPrice do not functionally depend on each other in
the schema that we have designed. Thus the following is in 3NF:
Product (ProdId, Colour, Size, ProdName)
d) The entity Product is also in 3NF because there exist only one non-key attribute,
which is Quantity (i.e. there does not exist any other non-key attributes that it can
depend on since ProdID is a key attribute). Thus the following is in 3NF:
InventoryComposition (ProdID, Quantity)
6.4.4 Optimized Relational Schema
Below is the optimized relational schema after all normalizations, generalizations,
and redundancy reductions have occurred.
Customer (Name, Address, CustID, Password, PhoneNumber, BillingInfo,Type)
Order (CustID, OrderID, ProdID, PaymentStatus, OrderStatus, Quantity, TotalPrice)
Product (ProdId, Colour, Size, ProdName)
InventoryComposition (ProdID, Quantity)
Merkley Headgear System Design
33
6.5 Entity Relationship Diagram and Design
The entity-relationship diagram modeled in Appendix N: Entity Relationship
Diagram and Design describes the structure of the information system. In the design of
the ER diagram (and the resulting translation to a relational schema) the motive was to
construct a situation where information is not only adequately encapsulated but also
properly indexed as to minimize redundancies and unnecessary trips to the disk.
Instead of broadly defining an entity-relationship diagram where the information
was simply represented, a little more careful attention was paid to modularity and
operational latency. Specifically, redundancies of key attributes within entities and
relationships were already employed (refer to Sections 6.3-6.4).
The problem in the non-normalized schema was created by awkward information
accessing procedures. For example, when a customer logs onto the system, his/her
information can be displayed for his/her scrutiny and modification if necessary. If a
customer wishes to pull up a list of all his/her orders, rather than have orderID’s in the
customer entity, (as a string perhaps, which repeatedly gets appended) the customers ID
should be made a key attribute in the orders relationship. This implies that when
customers query their orders, the orders may simply be pulled from the Orders table by
customer ID. As can be seen, this eliminates the need for a potentially long and awkward
attribute belonging to the customer entity (such was the case before normalization). It
also eliminates a parsing capability that would otherwise be needed to extract the
pertinent information.
Further design optimizations were made from the Requirements Analysis. Instead
of the proposed 6-table database architecture (refer to Appendix K: Database Table
Design), it has been reduced to four tables. The ordersToProcess and ordersToShip tables
may both be eliminated and dynamically generated by the main orders entity based on the
order’s present order status. Further redundancies such as redundant attributes in different
tables were eliminated. As mentioned above, the results of these optimizations can be
seen in the ER Diagram located in the Appendix N: Entity Relationship Diagram and
Design.
Merkley Headgear System Design
34
6.6 Workload Data and Cost Comparisons
The workload data consists of the relations and entities defined in our ER
diagram, along with their volumes, and operations. Supporting documentation for the
following information can be found in (refer to Appendix Q: Functional Requirements).
6.6.1 Table of Volumes
Concept
Type
Volume
Customer
Personal
Corporate
Orders
ProductForm
Production
Product
InventoryComposition
ShipsTo
E
E
E
R
E
R
E
R
R
200
50
150
400
400
400
150
5000
50
Table 6.6-1: Table of Volumes
6.6.2 Operational Requirements
There are 9 common operations that are performed. Details of the operations are
described in Appendix Q4: Details of Information Processing of the Functional
Requirements.
Operation 1: Adding a new Customer
Operation 2: Updating/Deleting a Customer Account
Operation 3: Checking an Order Status
Operation 4: Modifying an Order Status
Operation 5: Configuring a New Product for Inventory
Operation 6: Searching for a Product
Operation 7: Ordering a Product
Operation 8: Updating Product Inventory
Operation 9: Modifying/Deleting Product Information
Merkley Headgear System Design
35
Operation
Type
Frequency
Operation 1
Operation 2
Operation 3
Operation 4
Operation 5
Operation 6
Operation 7
Operation 8
Operation 9
Interactive
Interactive
Interactive
Interactive
Batch
Interactive
Interactive
Interactive
Interactive
100 per day
25 per day
10 per day
5 per day
250 per day
1000 per day
0.5 per day
0.15 per day (or once a week)
0.02 per day (or once every 2 months)
Table 6.6-2: Table of the most common operations
6.6.3 Cost Comparison Summary
This section presents a summary of the operation costs as calculated in Appendix
O: Operation Costs.
Operation 1: Adding a New Customer
Presence of Redundancies: (4 + 0) Accesses x 100/day = 400 accesses per day.
Absence of Redundancies: (2 + 0) Accesses x 100/day = 200 accesses per day.
Operation 2: Updating/Deleting a Customer Account
Presence of Redundancies: (4 + 2) Accesses x 25/day = 150 accesses per day.
Absence of Redundancies: (1 + 2) Accesses x 25/day = 75 accesses per day.
Operation 3: Checking an Order status
Presence of Redundancies: (0 + 4) Accesses x 10/day = 40 accesses per day.
Absence of Redundancies: (0+ 2) Accesses x 10/day = 20 accesses per day.
Operation 4: Modifying an Order Status
Presence of Redundancies: (6 + 4) Accesses x 5/day = 50 accesses per day.
Absence of Redundancies: (2+ 2) Accesses x 5/day = 20 accesses per day.
Operation 5: Configuring a New Product for Inventory
Presence of Redundancies: (6 + 4) Accesses x 250/day = 2500 accesses per day.
Absence of Redundancies: (2+ 2) Accesses x 250/day = 1000 accesses per day.
Operation 6: Searching for a Product
Presence of Redundancies: (0 + 4) Accesses x 1000/day = 4000 accesses per day.
Absence of Redundancies: (2+ 0) Accesses x 1000/day = 2000 accesses per day.
Operation 7: Ordering a Product
Presence of Redundancies: (0 + 3) Accesses x 0.5/day = 1.5 accesses per day.
Absence of Redundancies: (2 + 0) Accesses x 0.5/day = 1 access per day.
Merkley Headgear System Design
36
Operation 8: Updating Product Inventory
Presence of Redundancies: (2 + 2) Accesses x 0.15/day = 0.6 accesses per day.
Absence of Redundancies: (2 + 1) Accesses x 0.15/day = 0.45 access per day.
Operation 9: Modifying/Deleting Product Information
Presence of Redundancies: (2 + 2) Accesses x 0.02/day = 0.08 accesses per day.
Absence of Redundancies: (2 + 1) Accesses x 0.02/day = 0.06 access per day.
Total Cost (Presence of Redundancies) = 7142.18 total accesses per day.
Total Cost (Absence of Redundancies) = 3316.51 total accesses per day.
As the calculations done in the above point out, the total cost in the presence of
redundancies will total 7142.18 total accesses per day.
However, the absence of
redundancies will total 3316.51 total accesses per day. Clearly, the lack of redundancies
improves overall performance in our database.
6.7 Database Design Summary
The requirements for the database was to efficiently update and retrieve data, and
the other was to be able to collect enough data to ensure that inventory levels were
correct. Making most of the operations interactive enables fast retrievals and updates.
The relations were also normalized so that functional dependencies were constrained,
thereby, eliminating anomalies. In addition, data is needed to monitor customer
information, order information and product information. Consequently, this design for the
database meets relevant requirements as outlined in our requirements specification (refer
to Appendix Q: Functional Requirements).
7 INTERFACE DESIGN
The interface design of Merkley’s online web ordering application and
Administration & Order Processing application is simple and user-friendly for the reason
that the application is highly dependent on user interaction. The application interfaces are
geared toward novice users- it is assumed that users have experience with navigating the
World Wide Web and using every day Windows applications. The interfaces display only
the necessary options required by the user and simple text instructions for straightforward
user interaction with the system. The interface design for Merkley’s applications thus
fulfills the specified interface requirements (refer to Appendix R: Non-Functional
Requirements).
Merkley Headgear System Design
37
7.1 User Groups
There are basically 2 groups of users that will be interacting with Merkley’s
system: customers and employees. Customers interact with the online web ordering
system while the employees utilize a desktop application on an internal network
7.1.1 Customers
Customers log into the online ordering system accessible through the World Wide
Web and order products that are supplied and manufactured by Merkley Headgear. There
are two types of customers: corporate and personal customers.
7.1.1.1 Corporate Customers
Corporate customers belong to a company, which buys wholesale products from
Merkley to sell to their own customers. These types of customers may create
custom orders for hats tailored to the company’s requirements (e.g. they may
specify the use of the company’s colours and logo). Corporate customers may
also have multiple ship-to addresses as their business may have different branch
locations. Customers also have the option of checking the status of their custom
orders and track the progress of production.
7.1.1.2 Personal Customers
Personal customers refer to customers who are not purchasing merchandise on
behalf of a corporation. These customers buy a few items for their own personal
user and may not create custom orders (refer to Appendix Q: Functional
Requirements).
7.1.2 Employees
Employees deploy the shipping and production tracking system on their own
desktops. There are 3 types of employees that need to interact with the tracking system:
production clerks, shipping clerks, and sales representatives.
7.1.2.1 Production Clerks
The production department utilizes the system to check which orders need to be
put into production sends those orders to be manufactured. Production clerks may
only make updates to the status of orders- they may change a status to either “In
Production” or “Manufactured”.
7.1.2.2 Shipping Clerks
Shipping clerks employs the system to check which orders are ready to be
shipped. They may update a status of an order to “Shipped” and update the
inventory of products in the warehouse.
Merkley Headgear System Design
38
7.1.2.3 Sales Representatives
Sales representatives use the system to create new customer accounts, modify
existing account information or permissions, or delete expired accounts. They
also manage the product catalogue, which involves configuring a new line of
products, modifying existing product details (e.g. pricing and colours), and
remove discontinued products.
7.2 Online Ordering System Interface
The design for the website is simple, colourful, attractive and user-friendly. The
interface is user-friendly to maximize ease of navigation and usability. When a user
initially accesses the website, an introduction created using Macromedia Flash will play
on the screen in order to attract the customer’s attention. After a user logs onto the
system, he or she is presented with the Main Menu and all the options available to him or
her. By clicking on a Main Menu option, the user can navigate to other pages on the site.
Each application has a button “Home” that allows the user to return to the Main Menu to
choose another option or to log out of the system. The page layout and structure of the
site allows the user to easily navigate through the site and use each application quickly
and effortlessly.
Login Interface
When the login screen is displayed, the user can log into the ordering system on a
secure server using a unique user ID and password (refer to Figure P-1.1 under Appendix
P-1: Web Ordering System Application). If the user does not have an account, he or she
may create one. The user proceeds to the Main Menu when a valid user ID and password
are typed into the appropriate text fields. If an invalid user ID or password is entered, all
the fields are cleared and the user is prompted to try again. Upon 3 login failures, a page
is displayed indicating that the user has exceeded the maximum amount of login attempts
and must contact customer support for any assistance.
Main Menu Interface
Once the user is logged in, a Main Menu is loaded on the screen with different
menu options: My Account, Order Entry, Order Status, Custom Orders and View
Account Information (refer to Figure P-1.2 under Appendix P-1: Web Ordering System
Application). The Custom Orders option is only displayed for corporate customers, as
personal customers may not place a custom order (refer to Appendix Q-2: Functional
Requirements-Details of Output). Additionally, a button for signing out is available to
log the user out of the application session.
Merkley Headgear System Design
39
Order Entry and Product Information Interfaces
The Order Entry screen is loaded into the user’s browser and displays a list of
categories by which the products are sorted (refer to Figure P-1.3 under Appendix P-1:
Web Ordering System Application). Clicking on a category will display the thumbnail
pictures of all hats available in that category (refer to Figure P-1.4 under Appendix P-1:
Web Ordering System Application). A user can select a product to view more
information. This action brings up the Product Information screen, which displays
enlarged picture and product information, including price and availability (refer to Figure
P-1.5 under Appendix P-1: Web Ordering System Application). A drop down menu
listing available colours allows the user to view the product in a selected colour. The
user can specify the quantity that he or she wishes to order in a text field and can add the
item to the shopping cart by clicking the Add to Cart button. The Order Entry screen also
has an option to display a catalogue. A user can perform a search using various search
terms: by product number, description, or category (refer to Figure P-1.6 under Appendix
P-1: Web Ordering System Application). The search results are then displayed on the
screen in a similar fashion as if viewing products by category. After adding all desired
items in the shopping cart, the user can then proceed to the next screen to view all items
in the shopping cart (refer to Figure P-1.7 under Appendix P-1: Web Ordering System
Application). At this point, the user may remove items from the cart, cancel the entire
order, or confirm the order. When a use decides to complete an order, he/she must ensure
that the account and payment information are correct (refer to Figure P-1.8 under
Appendix P-1: Web Ordering System Application). When the user has confirmed the
order, the system provides the user with an order number, which allows the user to follow
up on that particular order.
Custom Orders Interface
The Custom Orders screen allows corporate customers to place custom orders
(refer to Figure P-1.9 under Appendix P-1: Web Ordering System Application). The user
must fill out a form with the hat specifications that he or she requires. The form consists
of drop down menus to choose material type, colours, and styles, and text fields to input
the amount required and any text to appear on the hat. If the customer would like a logo
to appear on the hat, then he or she may attach a small image to include in the form.
Upon completion of the specifications, the user then confirms the order and is given a
work order number as well as the order number. The work order number enables the user
to view the progress of the hat production.
Order Status Interface
The Order Status screen displays a list of all the orders placed by the user along
with the date that the order was place, the order number, and the order status (refer to
Figure P-1.10 under Appendix P-1: Web Ordering System Application). By clicking on
the order number link, the user can see all the items ordered, including the product
specifications (quantity, size, and colour), and the total price of the order. The link to
Merkley Headgear System Design
40
view the order status enables the user to track when and which items were shipped. If the
user is a corporate customer, he or she may also check the progress of the hat production.
Account Information Interface
On the My Account screen a user may check on his or her information, such as
ship to address and payment information (refer to Figure P-1.11 under Appendix P-1:
Web Ordering System Application). A user may also modify account information,
including the user’s account password.
7.3 Administration & Order Processing Application Interface
Employees may access the Administration & Order Processing application
through an application icon located on the terminal desktop. Upon starting the
application, a login screen is displayed and the employee must log in with his or her
unique user ID (composed of the first name initial and last name) and password. If an
invalid user ID or password are entered, all the fields are cleared and the user is prompted
to try again. Upon 3 login failures, a page is displayed indicating that the user has
exceeded the maximum amount of login attempts and must contact customer support for
any assistance. The login interface is similar that of the online web ordering application
displayed in Figure P-1.1 under Appendix P-1: Web Ordering System Application).
Main Menu Interface
The Main Menu is displayed on the screen showing appropriate menu options
according to the access level for the user account. From this point, the user may view all
orders in progress and update the status of orders and shipments, view customer accounts
and create or delete accounts, configure products (make price adjustments or add new
products), or sign out of the user session (refer to Figure P-2.1 under Appendix P-2:
Administration & Order Processing Application).
Customers Interface
On the Customers screen is a list of all customers. The user may list customers by
user ID, company name, customer name, or customer type. By clicking on a customer
from the list, the user may view all the details of the user account, such as user ID,
company information (name, address, phone number), past orders, and permissions. On a
side bar is a list of options the user may choose from: create new account, delete account,
update customer information, modify permission levels, or return to the Main Menu
(refer to Figure P-2.2 under Appendix P-2: Administration & Order Processing
Application).
Merkley Headgear System Design
41
Orders Interface
The Orders screen lists orders placed by customers from most recent to least
recent. The list of orders displays the order number, date on which the order was placed,
the customer that placed the order, order total, and status of the order; the list may be
sorted by any of these categories. By clicking on an order from the list, the employee may
view the order details, such as the items and the quantities ordered. Additionally, the user
has the option to change the status of the order or update the shipping status of the order
by means of a drop down menu. The user may also choose to return to the Main Menu
(refer to Figure P-2.3 under Appendix P-2: Administration & Order Processing
Application).
Product Configuration Interface
The Product Configuration screen organizes the catalogue products by category:
ski, golf, ball caps, etc. The user may view a list of the products by category or choose to
view them all. The list of products displays the product number and description. By
clicking on a product from the list, another screen is displayed, which shows the details
for the product. The product information shown on this screen is the information that the
customer sees when viewing the product details in the web ordering application. The
information includes the product number, product name, description, available sizes and
measurements, available colours, available stock, list price, material, image, and any
other customizable features allowed for the product. The information is displayed in
editable text fields, allowing the employee to update any details. The employee also has
the option to configure a new product or remove a product from the catalogue.
7.4 Input/Output Design
When the client receives input from a user it makes sure that all necessary fields in
the application are filled out and entered with the appropriate data type (e.g. integer for to
specify a quantity). The three-tier client server architecture described in Section 3.1.3
uses the processing tier to validate all the inputted data to make sure they are not corrupt
and to ensure that there are no suspicious orders (e.g. a personal customer placing an
order of 1 000 units).
7.4.1 Ordering Module
The Ordering Module describes the I/O interaction between customers and the
system. More specifically, user input is directed to the database and the user is presented
with data from the database.
7.4.1.1 Order a Product
Customers select the items they want to order and specify the quantity and colour
for each item. The system ensures that a valid input for quantity is entered and
that a colour has been selected. To complete an order, the customer must fill out
all relevant fields, including credit card information. After all user input is entered
Merkley Headgear System Design
42
into the database, the system returns a unique order number for the future
reference of the customer.
7.4.1.2 View Order Status
The database returns a list of all orders placed by the customer; the list includes
the order number, total price, the date the order was placed, and the order status.
The customer may view an order detail by clicking on an order number. The
database then returns a list of the products and product information for that
particular order.
7.4.1.3 Modify Account Information
When a customer modifies his/her account, he/she must make sure that no
required fields are made empty and that the fields are filled out with the correct
data format. If the customer wishes to change his/her password, he/she must type
in the old password, then type in the new password twice. The system verifies that
the old password entered matches the actual user password. If the entered
password is valid, then the system checks that the new password is a valid
password (not blank) and that both entries for the new password are identical.
Once all these conditions are fulfilled, the user record in the Customers table is
updated with the new password.
7.4.2 Order Tracking Module
The Order Tracking Module describes the I/O interaction between manufacturing/
shipping clerks and the system.
7.4.2.1 View Orders
As part of processing orders, manufacturing and shipping clerks must handle the
appropriate orders depending on the phase of the order with respect to the order
cycle. Both clerks pull up records according to their current status in order to
proceed in the next phase of order processing. Manufacturers handle orders that
are in the “Start Production” phase, while shipping clerks handle the orders that
have the status “Ready for Shipment”.
7.4.2.2 Update Order Status
Shipping and manufacturing clerks only have permission to update the status of
orders by selecting the status from a drop-down menu on the screen.
Manufacturing clerks my only modify a status to “In Production” and shipping
clerks may only modify a status to “Shipped”. The modified status is updated in
the database. In addition, when an order status is changed to “Shipped”, the
inventory numbers are also updated in the database.
7.4.3 Customer and Product Administration Module
The Customer and Product Administration Module describes the I/O interaction
between sales representatives and the system.
Merkley Headgear System Design
43
7.4.3.1 Add Customer Account
Sales reps collect customer information and input them into the system, which
adds a new customer record in the Customers table. The system then generates a
unique user ID for the user as well as a temporary password that will be encrypted
in the database for security purposes (refer to Appendix R-2: Performance
Requirements).
7.4.3.2 Modify Customer Information
Sales reps view user information and modify any user information or user
permissions. The system verifies that the modified data is legitimate before
updating the database with the new data (refer to Appendix Q: Functional
Requirements).
7.4.3.3 Delete Customer Account
When a sales representative deletes a customer account, the account is deactivated in the database (refer to Appendix Q-1: Details of Data Storage). An
account may only be de-activated if the user does not have any more open orders
to be processed. The system performs this check before allowing a sales rep. to
delete the account. The account de-activation signals to the database that the
account is to be deleted from the database. Only after a period of time when
closed orders are transferred from the database to another server are all deactivated accounts deleted from the Customers table.
7.4.3.4 Search Customer
Sales reps perform queries on the Customers table in the database. They may
view all existing customers or search customers by name, company or customer
type (see Appendix Q: Functional Requirements). Sales reps may or may not
enter a search string for the query. If a string is not entered, all record items in the
table matching the string is returned to the client. If no string is inputted then all
records in the table are returned.
Merkley Headgear System Design
44
8 CONCLUSION
A thorough description of the new system design has been documented to meet
and assess the ordering and inventory problems at Merkley Headgear. We discussed the
global system architectural, hardware, software and networking design specifications for
the new system to improve the data entry errors created through inspection and human
techniques.
By means of an efficient design, from a technical and monetary standpoint, the
design specifications presented give modularity and efficient answers to Merkley’s
business challenges. With a nice front-end ordering infrastructure in place, Merkley
positions itself to increase its customer base while at the same time serving its clients
better. As mentioned, the database interface design module guarantees simple real-time
order status and inventory information to be updated by its floor staff. Simplicity above
all other things, along with opportunities for unlimited growth, makes the design
specification easy to implement.
A meticulous system design has been presented, which describes all the
components required to build and successfully implement and initiate the new system
which we are confident will be more than satisfactory to John Kovacs, Head of
Operations and the Database Management Programming Staff.
Merkley Headgear System Design
45
Appendices
Merkley Headgear System Design
46
APPENDIX A: SYSTEM INFORMATION FLOW
Figure A.1: System information flow
The diagram above shows the general information system interactions. First the
client will use the web-based application to create an account and make and modify
orders. The web-based application will transact with the integrated database. The
Administration & Order processing application with also use the same integrated
database to facilitate the interaction made by manufacturing and shipping personnel, as
well as sales representatives, who may process and modify user and product information.
Merkley Headgear System Design
47
APPENDIX B: SOFTWARE ARCHITECTURE
Appendix B-1: Repository-Based Architecture
Figure B-1.1 Repository-based architecture for Merkley Headgear’s system
Merkley Headgear System Design
48
Appendix B-2: Model View Controller (MVC) Architecture
Figure B-2.1: Responsibilities of MVC components for Merkley Headgear’s system
Merkley Headgear System Design
49
Appendix B-3: Server Client Architecture
Appendix B-3.1: Two-Tier Server Client Architecture
Figure B-3.1.1: Logical representation of two-tier architecture
Figure B-3.1.2: Physical representation of two-tier architecture
Merkley Headgear System Design
50
Appendix B-3.2: Three-Tier Server Client Architecture
Figure B-3.2.1: Logical representation of three-tier architecture
Figure B-3.2.2: Physical representation of three-tier architecture
Merkley Headgear System Design
51
Appendix B-3.3: Comparison between Two-Tier and Three-Tier Architecture
Model
TwoTier
Development Time
Short
Scalability and Usage
Low
Maintenance Costs
Moderate




software vendor tools
available to simplify
development
of
applications for twotier model
little
modularity
required


ThreeTier
can service a low number
of simultaneous users
(100)
increased application logic
stored in the DBMS
depletes
processing
power, thus reduces the
number of simultaneous
users
that
can
be
accommodated
handles light transaction
loads
since business logic is
integrated in the server,
any code change will
also require changes to
the database
Long
High
Low



requires
proper
communication
between all three tiers
 requires
precise
module specifications
 separation
of user
interface logic, process
management logic and
data logic not always
easy to distinguish


high performance when
handling a high number of
simultaneous
users
(thousands)
each tier can be built and
executed on a separate
platform
each tier can be developed
in different languages

centralized process logic
allows for code changes
in middle tier without
needing to modify client
or server
modularity
makes
it
easier
to
identify
problem
areas
and
quickly resolve issues
Table 3.1.3-1: Client server architecture comparison summary
Merkley Headgear System Design
52
APPENDIX C: COMPUTER SYSTEM CONFIGURATION
This will be the configuration for both the servers that run the Oracle database and
the web application.
Manufacturer
CPU
RAM
OS
Model
Hard Drive
Network Card
CD-ROM Drive
Monitor
Dell
Intel Pentium III 933Mhz
PC 512MB SDRAM
Window 2000
Dell Poweredge 4600
10x36GB Hard Drive (10,000rpm)
D-Link DFE-550+TX
Creative Labs 40X IDE
Samsung 17' SVGA SyncMaster 763MB
Merkley Headgear System Design
53
APPENDIX D: USE CASES
Appendix D-1: General Use Case
Figure D.1: Use case for entire system
Merkley Headgear System Design
54
Appendix D-2: Customer Use Case
Figure D.2: Customer use case
Merkley Headgear System Design
55
Appendix D-3: Sales Representative Use Case
Figure D.3: Sales representative use case
Merkley Headgear System Design
56
Appendix D-4: Integrated Database Use Case
Figure D.4: Integrated database use case
Merkley Headgear System Design
57
APPENDIX E: SEQUENCE DIAGRAM
Figure E.1: Order processing sequence diagram
Merkley Headgear System Design
58
APPENDIX F: ACTIVITY DIAGRAM
Figure F.1: Customer ordering process activity diagram
Merkley Headgear System Design
59
APPENDIX G: CLASS DIAGRAMS
Appendix G-1: Class Diagram Overview (With Redundancies)
Figure G-1.1: Class diagram with redundancies
Merkley Headgear System Design
60
Description (With Redundancies)
There are two inheritance relationships in the diagram: class customer and class
record. The customer super class has two child or inheriting classes: corporate and
personal customers. Corporate customers generally have higher priority and are identified
by their company name. Personal customers are just regular customers. There is an
associative relationship between this class system and the web-based client application
class. This class system represents the customer’s interaction with Merkley’s information
system. The second inheritance relationship is that of the record class. The record super
class has three child or inheriting classes: customer, order and product record. A
customer record is the database object from which the customer’s table is constructed. It
contains each customer’s account profile and current order information. The order record
is the database object from which the orders table is constructed. It contains all
information about a given order, including its present status. The product record is the
database object from which the products table is constructed. It contains all information
about each product in Merkley’s catalogue. The record class system possesses an
aggregation relationship with the integrated database class of which they are a part.
The other two classes are the applications, which interface the integrated database
class: the web-based client application class and the application for order processing and
shipping class. As can be seen from the diagram each of these classes possesses an
associative relationship with the database class.
Minimizing Redundancies in the Class Diagram
There are many redundancies in the class diagram from the Requirements
Analysis. A drastic re-structuring and elimination of a few classes will need to occur.
First, the Corporate Customer class and Personal Customer class contains very similar
information and can be merged to Class Customer. By making this change, a new
attribute Type, must be added to identify the type of customer. Also, the Web-Based
Application and Integrated Database Class are also eliminated because they give extra
information that can be obtained by looking at some Order Class we propose to create.
Thus a new class entitled Order, which will incorporate the number of users by
associating an appropriate CustID to each user who logs on. We also do not need the
Record class for a similar reason. A Customer Record can be tracked by looking at the
Customer Class. An Order Record can be traced by looking in an Order Class that has
information about the CustomerID, OrderID, and ProductID. Trivially, this will in sum
eliminates a Product Record if we create a class Product. The changes reflect a much
more simplified version of the Class Diagram, and models the whole system. It is much
more difficult to create a Class Diagram with fewer entities that model the whole system,
opposed to creating a Class Diagram with many entities contain an abundant amount of
redundancies.
Merkley Headgear System Design
61
Appendix G-2: Finalized Class Diagram (Without Redundancies)
Figure G-2.1: Overview of entire system(with redundancies eliminated)
Description
The above class diagram models the whole system in terms of our design. There
can be 0 or more customers. Every customer that makes an order can create one or more
orders. The customer also can look up or search for a Product whose productID should
match the products in the Order they make. For each separate Order, there is exactly one
Product that has the same ProductID. For each order, a Product can be searched in
Merkley's inventory, which contains 0 or more products of that type. Lastly, Merkely's
inventory has products (explaining the aggregation), which corresponds to a customer's
order.
Merkley Headgear System Design
62
Appendix G-3: Data Dictionary
The following gives the description of the Entity Classes, which are the
fundamental classes that make up the overall system and is tied closely (but not exactly)
with our ER diagram in Appendix N: Final Relationship Entity Diagram and Design.
(Recall that an ER diagram is not necessarily a 1:1 mapping to a class Diagram). The
Boundary, Control, and Database Classes, are in the next section.
Class
Description
Attributes
Operations
Customer
The customer class
represents
the
customer in the
information system.
It
models
the
customer’s
interaction with the
system.
The
customer
can
perform an array of
different operations
once logged into the
online
client
application.
-custID
-name
-address
-phone
-creditCard
-expiryDate
-type
+login(usrname,pwd):Boolean
-The
customer logs into the system, by
entering unique username and password
+logout():Boolean-The customer logs out
of the system, and their session is closed
and any activity is saved by the system
+search(str):void - Allows the customer
to search the Merkeley catalogue of
available products
+fillForm():Boolean - The customer
completes the online order form to for
submission and order processing
+createAccount():Boolean
customer creates an
Merkeley’s system
- A new
account in
+createOrder():Boolean - A customer
creates a new order by filling out the
online order form
+modifyAccountInfo():Boolean - The
customer
modifies
their
account
information and submits it for update in
Merkeley’s system
+modifyOrderInfo(orderID):Boolean - The
customer modifies their order information
and submits it for update in Merkeley’s
system by providing the orderID
+checkOrderStatus(orderID):String - A
customer checks the status of their order
online by providing the orderID
Product
The product class
represents
a
product
from
Merkley’s catalogue
of products.
Merkley Headgear System Design
-prodID
-name
-size
-colour
63
Order
Inventory
The order class
represents an order
for product(s) made
by
a
specific
customer.
The inventory class
represents products
currently in stock at
Merkley
Manufacturing
facilities.
-orderID
-prodID
-custID
-quantity
-orderStatus
-prodID
-quantity
Appendix G-4: Additional Classes not included in Entity Class Diagram
The following is included in the overall system, and are omitted in the simplification
of the Entity Class Diagram (which is a simplification of the overall system that models
the entire system) because these do not model entities in the database. But for
completeness sake, here they are. They describe the Boundary, Control, and Database
Classes.
Appendix G-4.1 Class Web-based Client Application
Type: Boundary Class and Database Class (BCED)
The web-based client application class represents the client application that
interfaces the database. It models the application’s interaction with both the customer and
the database. It essentially acts as the middleware of the information system.
Attributes:
o -numLoggedInUsers – An integer value representing the number of concurrent
user sessions currently open in Merkley’s system
o –sessionList – A list of all current sessions presently logged into the online
system
Functions:
 +startSession():void – Creates a new session for the user once confirmed log in
has occurred
 +endSession():void – Closes the users current session and makes sure all new or
modified information has been saved in the system
 +timeout():void – Logs the user out of the application after 10 minutes of
inactivity
 +searchResults():void – Returns the results of a users search of Merkley’s product
catalogue
 +makeAccount():Boolean – Creates a new customer record and inserts it into the
customer’s table of the integrated database
 +makeOrder():Boolean – Creates a new order record and inserts it into the orders
table of the integrated database
Merkley Headgear System Design
64




+changeAccountInfo():Boolean – Updates the customer record with the changes
requested by the user
+changeOrderInfo():Boolean – Updates the order record with the changes
requested by the user
+returnOrderStatus():String – Returns the current status of an order
+validate():Boolean – Performs page validation on all forms submitted in the
application
Appendix G-4.2 Class Integrated Database
Type: Database Class (BCED)
The integrated database class represents the database itself, which stores all the
information contained within the entire information system. It models both the
information itself and the operations that must be performed to store, remove and update
existing information.
Attributes:
o -customer:Table – The table containing the customer records. Primary key:
customerID, foreign keys: ordered
o -order:Table – The table containing the order records. Primary key: orderID,
foreign keys: customerID, productID
o -ordersToProcess:Table – The table containing the order records to be processed.
Primary key: orderID, foreign keys: customerID, productID
o -itemsToShip:Table – The table containing the order records to be shipped.
Primary key: orderID, foreign keys: customerID, productID
o -inventories:Table – The table containing the inventory records. Primary key:
productID, foreign keys: orderID
o -products:Table– The table containing the product records. Primary key:
productID, foreign keys: none
Functions:
 +insert(values,Table):Boolean – Inserts the given values into the given table (i.e.
inserts a new record)
 +delete(values,Table):Boolean – Deletes the given values from the given table
(i.e. removes the record)
 +modify(values,Table):Boolean – Changes the old values with new values for the
given table (i.e. updates the record)
Merkley Headgear System Design
65
Appendix G-4.3 Manufacturing, Shipping Class and Record Class
Type: Control Classes (BCED)
The Record, Manufacturing and Shipping Classes are eliminated in the finalized
Class Diagram because all information that needs to be obtained here can be found in the
Order Class. For example orderComplete (orderID) and changeOrderStatus (orderID) are
equivalent to the Order Status attribute in Class Order. The subclasses in Record Class
(refer to Appendix G-1: Class Diagram (Without Redundancies)) are also omitted for the
same reason.
Having an Order Record, Customer Record, and Product Record is redundant
because we can identify these records by their appropriate ID, (i.e. CustID, OrderID, and
ProdID) and put these attributes in the Order class. Therefore, this the reason why we
simplified our previous class diagram. Please refer to the Appendix F: Data Dictionary
of Requirements Analysis for more details on the descriptions and specific attributes and
function of the Record, Manufacturing and Shipping Class.
Merkley Headgear System Design
66
APPENDIX H: COLLABORATION DIAGRAM
Figure H.1: Collaboration diagram for an order cycle
Merkley Headgear System Design
67
APPENDIX I: STATE DIAGRAMS
Appendix I-1: System Overview
Figure I-1.1: System Overview
Merkley Headgear System Design
68
Appendix I-2: Web Ordering System
Figure I-2.1: Login subsystem
Figure I-2.2: Main Menu subsystem
Merkley Headgear System Design
69
Figure I-2.3: Order Entry Subsystem
Figure I-2.4: Account Information Subsystem
Merkley Headgear System Design
70
Appendix I-3: Administration & Order Processing System
Figure I-3.1: Administration & order processing subsystem
Merkley Headgear System Design
71
APPENDIX J: OCL DESCRIPTIONS
The following constraints supplement the UML models that are included. We
have provided the following descriptions because there are some expressions such as post
and preconditions that we could not model through UML alone. Therefore the constraints
below only model the most crucial requirements in our system. Listed are the four main
OCL constraints we have.
Note: All OCL keywords and notation is in Bold.
Class: Customer
Constraint Based on: Order Creation
Description:
When a customer orders an item, they must have sufficient funds to purchase the
product. After the order is created, their balance decreases by that amount.
OCL Expression
Customer :: createOrder()
pre: self.paymentInfo > product.price
post : self.paymentInfo = self.balance - product.price
Class: Customer
Constraint Based on: Account Creation
Description:
When a customer creates an account, they are identified by a unique customerID. The
unique ID does not exist before the account is created.
OCL Expression
Customer :: createAccount()
pre: self.customerID = null
post: notEmpty ( self.createAccount( ) )
Merkley Headgear System Design
72
Class: Order
Constraint Based on: Attributes of the Order, after creation.
Description:
After an order is created, the orderID should be valid, and the productID must match a
product that is found in Class Product for a form to be valid. Also it makes no sense
ordering 0 products. There needs to be at least 1 product for an entry to be valid.
OCL Expression
self.notEmpty (orderID) implies
self.quantity ≥ 1 union
self.productID = Product.productID.
Class: Product
Constraint: Product ID
Description:
The Product ID must be valid. The condition is that it could be identified the ID can
be identified in Class Inventory or that the ProductID matches the ID found when
placing an order
OCL Expression
Either the ProductID is found in Inventory (If the productID is not empty) or the
ProductID is found in a valid Order. A valid Order means quantity ≥ 1
(self.notEmpty (productID) implies
self.productID = Inventory .productID).
union
(Order.notEmpty (orderID) implies
self.quantity ≥ 1 union
self.productID = Order.productID).
Merkley Headgear System Design
73
APPENDIX K: DATABASE TABLE DESIGN
Figure K.1: Original database table design before normalization
The above table shows the general layout and internals of the database. Within it
there are six tables. The three main tables are customer, order and product. These tables
correspond to a customer, order and product record respectively. Each had a primary key
corresponding to a unique ID of that type of record. The customer and order table each
contain a foreign key, which is the other's primary key. This is necessary for the efficient
retrieval of information needed for the proposed functionally of the system. The other
three tables are: ItemsToShip, orderToProcess and Inventories. The first two correspond
to more specific instances of the orders table but where in each table they only contain
orders in that phase of completion. The Inventories table stores quantities of product
records. It thus has the product ID in it as well.
Merkley Headgear System Design
74
APPENDIX L: ACID COMPLIANT DATABASE
The primary test for reliability of a database management system (DBMS) is the
ACID test. ACID-compliant systems possess certain properties that offer greater
protection to stored data in the event of an unexpected hardware or software failure, even
if the system crashes. The four ACID properties are atomicity, consistency, isolation and
durability.
Atomicity
When a transaction that updates the database occurs, either all of the update
occurs, or none of the update occurs, even if a hardware or software failure occurs during
the transaction.
Consistency
Any changes to the value of an instance are consistent with all other changes to
other values of that instance. An ACID-compliant DBMS provides the tools to enforce
consistency, usually in the form of rules checking. However, it is up to the designer to
implement consistency enforcement.
Isolation
Isolation prevents changes in concurrent transactions from conflicting with each
other. Isolation also allows multiple users to each use the database as if he or she were the
only user. Isolation is primarily accomplished through locking. To lock a table or record
prevents other transactions from reading or writing the data in that table or record until
the current transaction is finished. This process ensures that no transaction reads data,
which is no longer valid.
Durability
When a hardware or software failure occurs, the information in the database must
be accurate up to the last committed transaction before the failure. This durability is
required even if the failure causes the operating system to crash or the server to shut
down. The only exception is a hard disk failure, at which point the database is valid up to
the last successful backup made before the failure.
Note: All durable database management systems are atomic, but not all atomic database
management systems are durable.
References:
Daniel C. Silverstein. http://squishdot.org/989843029/index_html.
Merkley Headgear System Design
75
APPENDIX M: PRELIMINARY ENTITY RELATIONSHIP DIAGRAM
Figure M.1: The Entity Relationship Diagram (before normalization)
Merkley Headgear System Design
76
APPENDIX N: FINAL ENTITY RELATIONSHIP DIAGRAM AND DESIGN
Below is the optimized relational schema after normalizations, generalizations,
and reductions of all redundancies have occurred.
Customer (Name, Address, CustID, Password, PhoneNumber, BillingInfo,Type)
Order (CustID, OrderID, ProdID, PaymentStatus, OrderStatus, Quantity, TotalPrice)
Product (ProdId, Colour, Size, ProdName)
InventoryComposition (ProdID, Quantity)
Appendix N-1: Final Entity Relationship Diagram
Figure N-1.1: Final ER diagram
Merkley Headgear System Design
77
Appendix N-2 Data Dictionary for Final Relational Schema
Entities:
Customer (CustID, Name, Address, Phone, CreditCard, ExpiryDate, Type)







CustID: The unique ID of this customer (their login name to the system)
Name: The customer’s name
Address: The customer’s full address
Phone: The customer’s phone number
CreditCard: The customer’s credit card number
ExpiryDate: The expiry date of the customer’s credit card
Type: Whether it’s a corporate customer or personal customer (corporate
customer’s have the additional option to request custom orders
Product (ProdID, Name, Size, Color)




ProdID: The unique ID of this product
Name: The name of this product
Size: The dimensions of the product
Color: The color scheme of the product
Relationships:
Order (OrderID, ProdID, CustID, Quantity, OrderStatus)





OrderID: The unique ID of this order
ProdID: The unique ID of this product
CustID: The unique ID of this customer
Quantity: The quantity of the order
OrderStatus: The current status of this order
Inventories (ProdID, Quantity)


ProdID: The unique ID of this product
Quantity: The quantity of the product in stock
Redundancy Decision
After analyzing the above operations, it is clear that keeping redundant
information is beneficial since access to the database will be cut down a lot.
Merkley Headgear System Design
78
APPENDIX O: OPERATION COSTS
Cost Estimation of Operation 1: Adding a New Customer
Operation 1 With Redundancy
Concept
Type
Accesses
Type
Personal
Corporate
Entity
Entity
1
1
W
W
Accesses
Type
1
W
Operation 1 Without Redundancy
Concept
Type
Customer
Entity
Presence of Redundancies
Total Writes = 2W = 2W x 2 = 4 R
Total Reads = 0R = 0 R.
(4 + 0) Accesses x 100/day = 400 accesses per day.
Absence of Redundancies
Total Writes = 1W = 1W x 2 = 2 R
Total Reads = 0R = 0 R.
(2+ 0)Accesses x 100/day = 200 accesses per day.
Cost Estimation of Operation 2: Updating/Deleting a Customer Account
Operation 2 With Redundancy
Concept
Type
Personal
Corporate
Entity
Entity
Operation 2 Without Redundancy
Concept
Type
Customer
Entity
Accesses
Type
1
1
RW
RW
Accesses
Type
1
RW
Presence of Redundancies
Total Writes = 2W = 2W x 2 = 4 R
Total Reads = 2R = 2 R.
(4 + 2) Accesses x 25/day = 150 accesses per day.
Merkley Headgear System Design
79
Absence of Redundancies
Total Writes = 1W = 1W x 2 = 2 R
Total Reads = 1R = 1 R.
(1+ 2) Accesses x 25/day = 75 accesses per day.
Cost Estimation of Operation 3: Checking an Order Status
Operation 3 With Redundancy
Concept
Type
Personal
Corporate
Order
ProductForm
Entity
Entity
Relation
Relation
Operation 3 Without Redundancy
Concept
Type
Customer
Order
Entity
Entity
Accesses
Type
1
1
1
1
R
R
R
R
Accesses
Type
1
1
R
R
Presence of Redundancies
Total Writes = 0W
Total Reads = 4R = 4 R.
(0 + 4) Accesses x 10/day = 40 accesses per day.
Absence of Redundancies
Total Writes = 0W
Total Reads = 2R = 2 R.
(0+ 2) Accesses x 10/day = 20 accesses per day.
Cost Estimation of Operation 4: Modifying an Order Status
Operation 4 With Redundancy
Concept
Type
Personal
Corporate
Order
ProductForm
Production
Entity
Entity
Relation
Entity
Relation
Operation 4 Without Redundancy
Concept
Type
Customer
Order
Entity
Entity
Merkley Headgear System Design
Accesses
Type
1
1
1
1
1
RW
RW
R
R
RW
Accesses
Type
1
1
RW
R
80
Presence of Redundancies
Total Writes = 3W = 3W x 2 = 6R
Total Reads = 5R = 4 R.
(6 + 4) Accesses x 5/day = 50 accesses per day.
Absence of Redundancies
Total Writes = 1W = 1W x 2 = 2R
Total Reads = 2R = 2 R.
(2+ 2) Accesses x 5/day = 20 accesses per day.
Cost Estimation of Operation 5: Configuring a New Product for Inventory
Operation 5 With Redundancy
Concept
Type
ProductForm
Production
Product
InventoryComposition
Entity
Relation
Entity
Relation
Operation 5 Without Redundancy
Concept
Type
Product
InventoryComposition
Entity
Relation
Accesses
Type
1
1
1
1
R
R
RW
R
Accesses
Type
1
1
RW
R
Presence of Redundancies
Total Writes = 1W = 1W x 2 = 2R
Total Reads = 4R = 4 R.
(6 + 4) Accesses x 250/day = 2500 accesses per day.
Absence of Redundancies
Total Writes = 1W = 1W x 2 = 2R
Total Reads = 2R = 2 R.
(2+ 2) Accesses x 250/day = 1000 accesses per day.
Cost Estimation of Operation 6: Searching for a Product
Operation 6 With Redundancy
Concept
Type
ProductForm
Production
Product
InventoryComposition
Entity
Relation
Entity
Relation
Merkley Headgear System Design
Accesses
Type
1
1
1
1
R
R
R
R
81
Operation 6 Without Redundancy
Concept
Type
Product
InventoryComposition
Entity
Relation
Accesses
Type
1
1
R
R
Presence of Redundancies
Total Writes = 0 W
Total Reads = 4R = 4 R.
(0 + 4) Accesses x 1000/day = 4000 accesses per day.
Absence of Redundancies
Total Writes = 0 W
Total Reads = 2R = 2 R.
(2+ 0) Accesses x 1000/day = 2000 accesses per day.
Cost Estimation of Operation 7: Ordering a Product
Operation 7 With Redundancy
Concept
Type
Orders
ProductForm
Relation
Entity
Operation 7 Without Redundancy
Concept
Type
Order
Relation
Accesses
Type
1
1
RW
R
Accesses
Type
1
RW
Presence of Redundancies
Total Writes = 1/2 W = 1R (Since there is a 0.5 chance that changes are made)
Total Reads = 2R = 2 R.
(3 ) Accesses x 0.5/day = 1.5 accesses per day.
Absence of Redundancies
Total Writes = 1/2 W = 1 R (Since there is a 0.5 chance that changes are made)
Total Reads = 1R = 1 R.
(2 ) Accesses x 0.5/day = 1 access per day.
Cost Estimation of Operation 8: Updating Product Inventory
Operation 8 With Redundancy
Concept
Type
Accesses
Type
Production
Product
1
1
R
RW
Relation
Entity
Merkley Headgear System Design
82
Operation 8 Without Redundancy
Concept
Type
Product
Entity
Accesses
1
Type
RW
Presence of Redundancies
Total Writes = 1 W = 1W x 2 = 2 R
Total Reads = 2R = 2 R.
(2+ 2) Accesses x 0.15/day = 0.6 accesses per day.
Absence of Redundancies
Total Writes = 1 W = 1W x 2 = 2R
Total Reads = 1R = 1 R.
(2+ 1) Accesses x 0.15/day = 0.45 access per day.
Cost Estimation of Operation 9: Modifying /Deleting Product Information
Operation 9 With Redundancy
Concept
Type
Accesses
Type
Production
Product
Relation
Entity
1
1
R
RW
Accesses
Type
1
RW
Operation 9 Without Redundancy
Concept
Type
Product
Entity
Presence of Redundancies
Total Writes = 1 W = 1W x 2 = 2 R
Total Reads = 2R = 2 R.
(2+ 2) Accesses x 0.02/day = 0.08 accesses per day.
Absence of Redundancies
Total Writes = 1 W = 1W x 2 = 2R
Total Reads = 1R = 1 R.
(2+ 1) Accesses x 0.02/day = 0.06 access per day.
Merkley Headgear System Design
83
APPENDIX P: USER INTERFACE DESIGN
The user interface for both the Web Ordering system application and
Administration & Order Processing application are designed with simplicity, ease of
navigation and functionality in mind. The following sections describe each screen that a
customer or employee may interact with along with screen shots of what the design may
look like. The available screen images do not represent all the pages within the site, but
give a general overview of the look, feel, and functionality of the applications.
Appendix P-1: Web Ordering System Application
Figure P-1.1: Login interface
Merkley Headgear System Design
84
Figure P-1.2: Main Menu interface
Figure P-1.3: Order Entry interface
Merkley Headgear System Design
85
Figure P-1.4: Order Entry interface – browse catalogue
Figure P-1.5: Product Information interface
Merkley Headgear System Design
86
Figure P-1.6: Search interface
Figure P-1.7: Order Entry interface – shopping cart
Merkley Headgear System Design
87
Figure P-1.8: Order Entry interface – complete order
Merkley Headgear System Design
88
Merkley Headgear System Design
89
Appendix P-2: Administration & Order Processing Application
Figure P-2.1: Main Menu interface
Merkley Headgear System Design
90
Figure P-2.2: Customer Administration interface
Figure P-2.3: Orders interface
Merkley Headgear System Design
91
APPENDIX Q: FUNCTIONAL REQUIREMENTS
In this section, we will describe details that facilitate the functionality outlined in
both the application descriptions and user interface sections.
Appendix Q-1: Details of Data Storage
The system will need to store the following types information within the database
component:
-
Information pertaining to customer accounts and other customer information
Information about all products in the Merkley catalogue
Information about all orders currently in the processing pipeline
Information about employees
Information about product inventories
Additionally, when a customer account is to be deleted from the Customers table of
the database, it cannot be removed until all orders ordered by the customer is removed
from the database as well (because the order makes reference to the customer ID). After
a certain time interval, completed orders are removed from the database and backed up
on another server for record keeping. Until then, the customer account will be
deactivated until it is ready for deletion from the database.
Appendix Q-2: Details of Output
The output of the information system is defined by the user interfaces (refer to
Appendix P: User Interface Design). They are as follows:
Online Client Application






A customer will have a login screen asking them for a login name and password.
If he/she makes a mistake inputting either field they will be given an error
message and asked to try again. If they give incorrect input three times, they will
be told to contact customer support.
A personal customer may create a new account for himself/herself. If a corporate
customer needs a new account, a sales representative must create one for the
customer.
Once logged in a customer has an array of options. They can view their account
information by clicking “My Account”. This will display their account
information.
They may also create a new order by clicking “Order Entry”. They may check the
status of one of their orders by clicking “Order Status”.
If they have the sufficient privileges (i.e. a corporate customer), they may make a
custom order by clicking “Custom Order”.
A customer may also view the status of any placed orders.
Merkley Headgear System Design
92








Finally, they may logout by clicking “logout”
When a customer enters “Order Entry”, he/she is given a new screen, which
allows him/her to browse the catalogue and view thumbnails of the products.
At any time, the customer can return to the initial screen by clicking “Home”.
If the customer clicks on a thumbnail image of the product while browsing, this
will bring up a screen giving detailed information about the given product.
When done with order entry, a customer clicks “checkout”, which brings him/her
to a screen prompting for payment information.
Upon completing an order, the system returns an order number to the customer
enabling the customer to track the order.
A screen for custom orders is available to corporate customers who click “Custom
Order”.
A customer may view the status of any orders placed. Clicking on “Order Status”
will present the customer with a screen listing the customer’s orders and their
status. Order details may be viewed by clicking on a listed order number.
Administration and Order Processing Application








Employees may login in a similar fashion as customers; they have a login screen
as well.
Once logged in, employees have several options depending on permissions given
to the employee. Sales representatives can view customers, orders, as well as
products, while shipping and manufacturing employees only have access to the
orders menu option.
If they click “customers”, they will be brought to a new screen giving them
several options. They can create, modify or delete customer accounts, as well as
search the database for particular customers.
Similarly, they may view all the current orders in the database. They may change
the order status of any order at any time by changing the order status to a different
value from the drop-down menu.
Employees may view all the products in Merkley’s catalogue. They can add new
products, remove discontinued products, and modify product information.
Manufacturing personnel can generate a digital work order and this will also
change the order status automatically
Manufacturing personnel can signify the order is complete to the application and
the order status will change and inventory updated
Customer
Appendix Q-3: Details of Input
The system’s inputs consist only of customer inputs from the online client
application as well as employee inputs from the Administration & Order Processing
application. The only other inputs are manual changes made by system and database
administrators to the database.
Merkley Headgear System Design
93
Appendix Q-4: Details of Information Processing
This information system is very processing intensive. The following operations will
be supported:
Operation 1: Adding a New Customer – Add a new customer account to the database
either by a customer creating a new account in the online client application or by an sales
representative.
Operation 2: Updating/Deleting a Customer Account – Once logged in, a customer may
modify their user account with Merkley. An administrator may also modify or delete a
customer account if it is necessary.
Operation 3: Checking an Order Status – A customer will be able to check the current
real-time status of their order as it gets processed.
Operation 4: Modifying an Order Status – A shipping or manufacturing clerk may
modify the status of an order depending on order’s phase in processing.
Operation 5: Configuring a New Product for Inventory – When a product is introduced to
Merkley’s catalogue of products, a sales representative will be able to add it to the
database.
Operation 6: Searching for a Product – Customers and sales representative will be able
to browse Merkley’s catalogue of products on the online client application and
administration and order processing application, respectively.
Operation 7: Order a Product – A customer orders a product using the online order form
once logged into the online client web application.
Operation 8: Updating Product Inventory – A sales representative will be able to modify
inventory information if necessary. Ordinarily this will be automatically done by the
administration and order processing application after orders have been manufactured and
entered as complete or when shipped.
Operation 9: Modifying /Deleting Product Information – If details of a product change,
an administrator will be able to modify them or even delete the product if it is
discontinued.
Merkley Headgear System Design
94
APPENDIX R: NON-FUNCTIONAL REQUIREMENTS
In this section, we will describe aspects of the web ordering system that are
concerned with how well it supports the functional requirements. We will also define
global constraints on the software system such as performance, reliability, security
maintainability, portability, as well as physical constraints.
Appendix R-1: Interface Requirements
The users of either the web ordering system or the Administration & Order
Processing application are novice computer users and should not be inundated by
unnecessary information or functions. The interfaces of each system applications must
be simplistic yet highly functional, allowing the user to maximize his or her interaction
with Merkley’s system. In order to access the system, the user must log in with a user ID
and password. Once the user has been authenticated, he or she is presented with a Main
Menu from which menu options may be selected. Each main menu option then takes the
user to the respective application.
Appendix R-2: Performance Requirements
Time Bounds

Since transactions will be occurring daily, the web server shall not take more than
five seconds for each transaction to be placed.

As the system is using an Oracle database (see Appendix K of Requirements
Analysis), it shall be able to handle at least 100 concurrent user connections and
will be running 24 hours a day.
Space Bounds

The system must handle at least 200 transactions and 400 orders per day (see
Appendix K of Requirements Analysis), which would take about 200 KB for
storage space per server.

Merkley may require an additional server to back up their system in case they
experience any technical difficulties. Therefore, the estimated size of the database
tables and user logs will be approximately between 800 MB to 1000 MB in
several years.
Reliability
 The system shall be extremely reliable in production mode- the system uptime
must be 100% operational 99.5% of the time.
 The Rate of Failure Occurrence (ROCOF) shall be at most 1/500- at most one
failure is likely to occur within every 500 user sessions.
 No more than one bug per 10 000 lines of code may remain in the system after
delivery
Merkley Headgear System Design
95
Security
 The web application will run on a secure server using encryption, therefore the
system cannot be tampered with from outside sources.
 Each account shall be encrypted with an alphanumerical password and a unique
username that is generated by the system.
 Every client-based program and software shall require login with a username
password to protect system tampering by employees or the public. The
transactions between the system server and client programs will be encrypted with
a 256 key algorithm to ensure secure transactions.
 The Oracle database system will shut down upon detection of any fatal software
error that may have been caused by system tampering.
 The database system will record all transactions in a daily log, and the web server
will record all requests made in a daily log.
 A “Black Box” system shall be imposed to avoid outsiders such as hackers to
steal protected customer information. This system shall also protect Merkley
employees from tampering with the system.
Survivability
All information and records shall be backed up daily on a secondary server in the
event of a system failure. Log files and transaction records older than a certain period of
time shall be archived to another server.
Appendix R-3: Operating Requirements
Physical Constraints
There are no physical constraints for the system. The system will be running on
an existing server and employees accessing the system will use existing terminals located
on the current internal network.
Personnel Availability
Customer support specialists are to be on hand during regular business hours to
aid any customers encountering any problems. Any support requests outside of regular
business hours can be made through e-mail or voice mail for a support specialist to
receive the next business day. Problems are then routed to the appropriate person
(database administrator, technical support, etc) to aid in fixing the situation.
In the event that that the system fails, technical support specialists are on site to
fix any problems or repair the system. On a bi-monthly basis, they will perform
maintenance checks to ensure that the system is running smoothly or to detect any flaws
early on before they pose a greater threat to the operation of the system or the business.
Skill Level Considerations
End users should have minimal difficulty using the client application, navigating
through the site and its applications because of its user-friendly interface. The user must
simply be knowledgeable in using a browser to launch the website.
Merkley Headgear System Design
96
Employees using the employee application should also have no problem with the
application. Short training sessions would be given to all employees, which must
eventually use the system. The application will be running on a Windows operating
system, which is what was previously being used before the new system implementation,
thus employees are already familiar with its operation (see Appendix K of Requirements
Analysis).
Appendix R-4: Lifecycle Requirements
Quality of the design
 Maintainability- According to Oracle, the database shall exhibit a Mean Time to
Repair (MTTR) of no more than 3600 seconds (1 hour), which is the time required
to correct and restore the database in the case of system failure.
(Source: http://www.oracle/Articles/8i/RecoveryEnhancements8i.asp)
 Enhanceability- The system design shall allow for ease in system upgrades and
expandability.
 Portability- The system shall be running on a Windows platform and will not be
required to run on anything else. Therefore, there are no requirements for
portability.
 Lifespan- The system’s lifespan is expected to be at least 20 years; that is, the
system will still be fully operational and maintainable for a minimum of 20 years.
The system will age gracefully as modularity in design will allow for expandability
and upgrades.
 Efficiency- The system shall handle up to 10000 simultaneous terminals or users
accessing and performing transactions on the web-based or company order
processing and shipping applications without any performance degradation. In this
case, login time shall take no more than one second after the user sends login
information to the system. Any more users exceeding the maximum capacity shall
result in degraded system performance, where logging into an application shall take
between 5 and 10 seconds.
Limits on Development
There are no development time limits, nor limits on resource availability.
Appendix R-5: Economic Requirements
As determined in the Feasibility Study performed for Merkley Headgear, the
development of the system shall cost $16 000 and the maintenance of the system shall
cost an average of $200 000 per annum. To reduce costs, the system shall use an Oracle
database over IBM’s DB2 (see Appendix N of Requirements Analysis).
Merkley Headgear System Design
97
Appendix R-6: Server Requirements
Operating System
 The server shall be running Windows 2000 Server since this is the current operating
system that Merkley is currently using.
Memory
 The server shall be equipped with 512 MB for speed and reliability
Storage
 The server shall have 360 GB worth of storage in order to store and back up the
large amounts of data on Merkley’s system.
 The server shall also have a Tape Backup to perform weekly backups.
CPU

The server shall use an Intel Pentium III 933 MHz CPU to handle a high level
input/output procedures
Network
 A D-Link network shall be employed to provide a high bandwidth allowing
multiple users to access the database.
 Copper network cables with 100Mbps bandwidth utilized to facilitate intranetwork.
Appendix R-7: System Infrastructure
To facilitate the proposed system functionality the following system infrastructure
will be created:
-
An Oracle9i database will run on a dedicated server running Windows 2000
server
The client web application will run on another server acting as the web server,
which is also running Windows 2000 server
A network hub will support the interface between the machine running the Oracle
database and the host machine running the web server application
45 Dell networked workstations will run on intra-networked centralized at
database server
The choice of using Oracle based software is based upon several factors. First and
most importantly, Merkeley already uses Oracle databases and has licenses. Their
administrators are already familiar with the software and upgrading to 9i should not be a
problem. Oracle is also ACID compliant, a requirement of Merkeley. To scale to
Merleley’s present and future customer loads, it is projected they will have 5000 products
in inventory and an average of 200 online customer transactions occurring daily. Oracle
will scale to this requirement with technologies such as OLAP (Analytic Queries per
Merkley Headgear System Design
98
minute technology) with real application clusters for faster queries. It also accommodates
the RDA protocol for large data transfers.
The web application will be written using java servlet technology. The reason for
servlets over other server side technologies such as the CGI interface and ASP is that it is
faster and has cross-platform ability. SQL libraries from the Java API will be used to
query the Oracle database.
Merkley Headgear System Design
99
APPENDIX S: GLOSSARY OF TERMS
ERP - Enterprise Resource Planning, a business management system that integrates all
facets of the business, including planning, manufacturing, sales, and marketing
Please refer to http://www.cio.com/research/erp/edit/erpbasics.html for more details.
GUI - Graphical User Interface refers to a program interface that takes advantage of
the computer's graphics capabilities to make the program easier to use. Well-designed
graphical user interfaces can free the user from learning complex command languages.
Please refer to http://www.clienthelpdesk.com/dictionary/gui.html for more details
OWDS - Oracle Web Developer Suite is an integrated and flexible set of products for
creating scalable, high performance and robust enterprise class database applications for
server based and client/server deployment.
Please refer to http://www.oracle.com for more.
HTML - HyperText Markup Language, the authoring language used to create
documents on the World Wide Web. It defines the structure and layout of a Web
document by using a variety of tags and attributes
Please refer to http://www.w3.org/MarkUp/ for more details.
JDBC - JDBCTM technology is an API that lets you access virtually any tabular data
source from the JavaTM programming language. It provides cross-DBMS connectivity to a
wide range of SQL databases, and now, with the new JDBC API, it also provides access
to other tabular data sources, such as spreadsheets or flat files.
Please refer to http://java.sun.com/products/jdbc/ for more details.
JSP - JavaServer PagesTM technology allows web developers and designers to rapidly
develop and easily maintain, information-rich, dynamic web pages that leverage existing
business systems
Please refer to http://java.sun.com/products/jsp/ for more details
PHP - Hypertext Preprocessor, an open source, server-side, HTML embedded scripting
language used to create dynamic web pages. In an HTML document, PHP script is
enclosed within special PHP tags.
Please refer to http://www.php.net/ for more details.
SQL - Structured Query Language is a standard language for accessing databases.
Please refer to http://www.w3schools.com/sql/default.asp for more details
SSL - Secure Socket Layer has been universally accepted on the World Wide Web for
authenticated and encrypted communication between clients and servers.
Please refer to http://developer.netscape.com/docs/manuals/security/sslin/contents.htm
fore more details
Merkley Headgear System Design
100
APPENDIX T: TEAM MEETINGS
Team Meeting #1
Location : Bahen Centre, Room 2210
Date: March 23, 2003
 We met together to discuss the requirements specification of assignment 2. We
discussed possible design issues that we should discuss with the Merkley Staff,
and also a specialist in Oracle. We have decided that each of us will need to do
some research and contribute with collecting technical data.
 Since Michelle has contact with the Merkley Staff, she would be collect the data
for global system architecture. Leeor and Anthony would of collecting the data
from the existing computer networks.
Team Meeting #2
Location : Bahen Centre, Room 2210
Date: March 27, 2003
 By this time, we had enough information to begin the Design analysis. We began
defining the global system architecture, which consisted of the computer networks
that Anthony and Leeor found information for.
 We evenly divided the tasks, and began to develop key ideas that we could use in
the write up the report. Specifically, we wanted to finish the software platform
selections for the next meeting
Team Meeting #3
Location : Bahen Centre, Room 2210
Date: March 31, 2003
 We had finished writing the software selection platform. Now we had to select
the specific hardware, software, and networking that we needed for the new
system..
 We split the UML diagrams into three, such that every member was doing
roughly about three diagrams each. The diagrams, we had thought of using
included Use cases, Class diagrams, State diagrams, Collaboration Diagrams,
Sequence Diagrams, and Activity Diagrams.
Merkley Headgear System Design
101
Team Meeting #4
Location : Bahen Centre, Room 2210
Date: April 2, 2003
 When we assembled again, we re-examined our Use case, Class diagrams, State
diagrams, and Collaboration diagrams first.
 When we were satisfied these were correct, we began to define invariants for the
classes we have come up with - that is we started to begin the OCL aspect of the
assignment.
 Now we had to design the database schema for the database component of our
system. We accounted and discussed the workloads when we were working on
the relational database schema.
Team Meeting #5
Location : Bahen Centre, Room 2210
Date: April 5, 2003
 When we met again, we concentrated on the interaction diagrams, namely, the
Sequence diagram, and Activity diagrams, and finalizing the ER diagram and
doing the normalizations for the specific schemas.
 We begin to write up and design the I/O procedures and user interfaces. Each of
the subsystems that we thought should be incorporated was discussed. Each of us
wrote the description for at least one subsystem.
Team Meeting #6
Location : Bahen Centre, Room 2210
Date: April 12, 2003
 This last meeting was devoted to writing up the report in good, having a well
developed introduction, and scope so that the reader of the report has a good
understanding of not only the system, but a good assessment of the specific design
details.
 We've made sure that the Design decisions satisfied the Requirements and Nonfunctional requirements were consistent with our UML diagrams.
 Finally, we wrote the conclusion together, along with the Team report, and this
section.
Merkley Headgear System Design
102
APPENDIX U: TEAM REPORT FORM
Team Report Form
(must be submitted with assignment)
Description of roles and contributions of each team member:
The distribution of the work, was distributed evenly just like our first report. Again in
this report, all three team members took advantage of the ICQ Web technology to discuss
all report issues in real time. Contributions during the report write up were more or less
equal as we were able to provide our opinions and feedback to each other’s suggestions
without delay.
We each took our own time to make amendments to the report but they were saved in a
separate draft file and e-mailed to each other for review and approval.
Each team member dedicated an equally sufficient amount of time and effort to make this
report possible.
Name
% of team Effort
Signature
Leeor Engel
Leeor Engel
(991032538)
33
1/3%
Anthony Ku Ong
(991040119)
33
1/3%
Anthony Ku Ong
Michelle Li
(991015931)
33 1/3%
Michelle Li
Merkley Headgear System Design
103