Merkley Headgear - home.ipoline.comhome.ipoline.com/~alirwin/school/csc340/A3_FINAL_REPORT.pdf ·...

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

Merkley Headgear System Design 2

Table of Contents

System Design

1 Introduction............................................................................................................... 7

1.1 Objective ............................................................................................................. 7

1.2 The Organization ................................................................................................ 7

2 System Overview....................................................................................................... 7

2.1 The Current System............................................................................................. 7

2.2 The Problem........................................................................................................ 8

2.3 The Proposed System .......................................................................................... 8

3 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

3.2 Computer Network Specification ...................................................................... 11

3.3 Web Application Server Specification .............................................................. 12

4 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

4.4.1.1 Reasons for Using SQL ........................................................................ 15 4.4.1.2 The Use of SQL .................................................................................... 16 4.4.1.3 Advantages of Embedded SQL............................................................. 16 4.4.1.4 Reasons for Embedded SQL with Java................................................. 17

4.5 Web Programming Technologies...................................................................... 17

5 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 6.4.3 Normalizing Relational Schemas in Third Normal Form......................... 33 6.4.4 Optimized Relational Schema................................................................... 33

6.5 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 Database Design Summary............................................................................... 37

7 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

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


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


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 6000-7000 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


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


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


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


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


host machine, which will run the web server application (refer to Appendix R: Non-Functional 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


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 large-scale 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.

http://www.db2mag.com:8080/db_area/archives/2002/q3/lynch.shtml


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: Non-Functional 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)

http://www.databasejournal.com/features/mssql/article.php/2170201


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

http://www.oracle.com/


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++.


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.


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


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.


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.


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.


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


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.


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


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 I-2: 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


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.


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.


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 Type Identifiers Customer E CustID Personal E inherits from Customer (CustID) Corporate E CompName Orders R CustID, OrderID ProductForm E ProdID Production R WorkOrderID Product E ProdID InventoryComposition R ProdID ShipsTo R 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.


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


- 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 multi-valued 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


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 multi-valued 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.


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)


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)


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.


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 E 200 Personal E 50 Corporate E 150 Orders R 400 ProductForm E 400 Production R 400 Product E 150 InventoryComposition R 5000 ShipsTo R 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


Operation Type Frequency Operation 1 Interactive 100 per day Operation 2 Interactive 25 per day Operation 3 Interactive 10 per day Operation 4 Interactive 5 per day Operation 5 Batch 250 per day Operation 6 Interactive 1000 per day Operation 7 Interactive 0.5 per day Operation 8 Interactive 0.15 per day (or once a week) Operation 9 Interactive 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.


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).


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.


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.


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


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).


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


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.


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 de-activated 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 de-activated 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.


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.


Appendices


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.


APPENDIX B: SOFTWARE ARCHITECTURE

Appendix B-1: Repository-Based Architecture

Figure B-1.1 Repository-based architecture for Merkley Headgear’s system


Appendix B-2: Model View Controller (MVC) Architecture

Figure B-2.1: Responsibilities of MVC components for Merkley Headgear’s system


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


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


Appendix B-3.3: Comparison between Two-Tier and Three-Tier Architecture

Model Development Time Scalability and Usage Maintenance Costs Two-Tier

Short• software vendor tools

available to simplify development of applications for two-tier model

• little modularity required

Low• 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

Moderate• since business logic is

integrated in the server, any code change will also require changes to the database

Three-Tier

Long• 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• 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

Low• 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


APPENDIX C: COMPUTER SYSTEM CONFIGURATION

This will be the configuration for both the servers that run the Oracle database and the web application. Manufacturer Dell CPU Intel Pentium III 933Mhz RAM PC 512MB SDRAM OS Window 2000 Model Dell Poweredge 4600 Hard Drive 10x36GB Hard Drive (10,000rpm) Network Card D-Link DFE-550+TX CD-ROM Drive Creative Labs 40X IDE Monitor Samsung 17' SVGA SyncMaster 763MB


APPENDIX D: USE CASES

Appendix D-1: General Use Case

Figure D.1: Use case for entire system


Appendix D-2: Customer Use Case

Figure D.2: Customer use case


Appendix D-3: Sales Representative Use Case

Figure D.3: Sales representative use case


Appendix D-4: Integrated Database Use Case

Figure D.4: Integrated database use case


APPENDIX E: SEQUENCE DIAGRAM

Figure E.1: Order processing sequence diagram


APPENDIX F: ACTIVITY DIAGRAM

Figure F.1: Customer ordering process activity diagram


APPENDIX G: CLASS DIAGRAMS

Appendix G-1: Class Diagram Overview (With Redundancies)

Figure G-1.1: Class diagram with redundancies


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.


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.


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 - A new customer creates an account in Merkeley’s system

+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.

-prodID -name -size -colour


Order The order class represents an order for product(s) made by a specific customer.

-orderID -prodID -custID -quantity -orderStatus

Inventory The inventory class represents products currently in stock at Merkley Manufacturing facilities.

-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


� +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)


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.


APPENDIX H: COLLABORATION DIAGRAM

Figure H.1: Collaboration diagram for an order cycle


APPENDIX I: STATE DIAGRAMS

Appendix I-1: System Overview

Figure I-1.1: System Overview


Appendix I-2: Web Ordering System

Figure I-2.1: Login subsystem

Figure I-2.2: Main Menu subsystem


Figure I-2.3: Order Entry Subsystem

Figure I-2.4: Account Information Subsystem


Appendix I-3: Administration & Order Processing System

Figure I-3.1: Administration & order processing subsystem


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( ) )


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).


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.


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.

mailto:[email protected]


APPENDIX M: PRELIMINARY ENTITY RELATIONSHIP DIAGRAM

Figure M.1: The Entity Relationship Diagram (before normalization)


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


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.


APPENDIX O: OPERATION COSTS

Cost Estimation of Operation 1: Adding a New Customer

Operation 1 With Redundancy Concept Type Accesses Type Personal Entity 1 WCorporate Entity 1 W

Operation 1 Without Redundancy Concept Type Accesses Type Customer Entity 1 W

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 Accesses Type Personal Entity 1 RW Corporate Entity 1 RW

Operation 2 Without Redundancy Concept Type Accesses Type Customer Entity 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.


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 Accesses Type Personal Entity 1 RCorporate Entity 1 ROrder Relation 1 RProductForm Relation 1 R

Operation 3 Without Redundancy Concept Type Accesses Type Customer Entity 1 ROrder Entity 1 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 Accesses Type Personal Entity 1 RW Corporate Entity 1 RW Order Relation 1 RProductForm Entity 1 RProduction Relation 1 RW

Operation 4 Without Redundancy Concept Type Accesses Type Customer Entity 1 RW Order Entity 1 R


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 Accesses Type ProductForm Entity 1 RProduction Relation 1 RProduct Entity 1 RW InventoryComposition Relation 1 R

Operation 5 Without Redundancy Concept Type Accesses Type Product Entity 1 RW InventoryComposition Relation 1 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 Accesses Type ProductForm Entity 1 RProduction Relation 1 RProduct Entity 1 RInventoryComposition Relation 1 R


Operation 6 Without Redundancy Concept Type Accesses Type Product Entity 1 RInventoryComposition Relation 1 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 Accesses Type Orders Relation 1 RW ProductForm Entity 1 R

Operation 7 Without Redundancy Concept Type Accesses Type Order Relation 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 Relation 1 RProduct Entity 1 RW


Operation 8 Without Redundancy Concept Type Accesses Type Product Entity 1 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 Relation 1 RProduct Entity 1 RW

Operation 9 Without Redundancy Concept Type Accesses Type Product Entity 1 RW

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.


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


Figure P-1.2: Main Menu interface

Figure P-1.3: Order Entry interface


Figure P-1.4: Order Entry interface – browse catalogue

Figure P-1.5: Product Information interface


Figure P-1.6: Search interface

Figure P-1.7: Order Entry interface – shopping cart


Figure P-1.8: Order Entry interface – complete order


Appendix P-2: Administration & Order Processing Application

Figure P-2.1: Main Menu interface


Figure P-2.2: Customer Administration interface

Figure P-2.3: Orders interface


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.


• 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.


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.


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


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.


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).

http://www.oracle/Articles/9i/RecoveryEnhancements9i.asp


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 intra-

network.

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


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.


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.htmfore more details

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

http://www.w3schools.com/sql/default.asp

http://www.php.net/

http://java.sun.com/products/jsp/

http://java.sun.com/products/jdbc/

http://www.w3.org/MarkUp/

http://www.oracle.com/

http://www.clienthelpdesk.com/dictionary/gui.html

http://www.cio.com/research/erp/edit/erpbasics.html


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.


� 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


� 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.


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.


� 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.


� 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 Non-functional requirements were consistent with our UML diagrams.

� Finally, we wrote the conclusion together, along with the Team report, and this section.


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 33 1/3% Leeor Engel (991032538)

Anthony Ku Ong 33 1/3% Anthony Ku Ong (991040119)

Michelle Li 33 1/3% Michelle Li (991015931)

Merkley Headgear - home.ipoline.comhome.ipoline.com/~alirwin/school/csc340/A3_FINAL_REPORT.pdf ·...

Documents

Transcript of Merkley Headgear - home.ipoline.comhome.ipoline.com/~alirwin/school/csc340/A3_FINAL_REPORT.pdf ·...