system design proof of concept specification …jm/340s/01/asst/00/asst31.pdfcsc340s prof. john...

CSC340S

Prof. John Mylopoulos

April 9, 2000Tutor: Denilson Barbosa

System Design

Proof of Concept SpecificationCustomer Information ManagementSystem

Group Member: Michel GeeAntonio SayantharajahTommy Tam

CIMS Proof of Concept April 10, 2000

2

1. INTRODUCTION................................................................................................5

2. PROBLEM .........................................................................................................5

2.1. Vision............................................................................................................................................... 5

2.2. Overview ......................................................................................................................................... 5

2.3. Requirement Analysis.................................................................................................................... 5

2.4. Contacts .......................................................................................................................................... 5

3. GENERAL DESIGN...........................................................................................5

3.1. Architecture.................................................................................................................................... 53.1.1. Architecture Selection.............................................................................................................. 53.1.2. Recommendation ..................................................................................................................... 6

3.2. Features........................................................................................................................................... 73.2.1. Customer .................................................................................................................................. 73.2.2. Administrator ........................................................................................................................... 7

4. SELECTION.......................................................................................................8

4.1. Hardware ........................................................................................................................................ 84.1.1. Server ....................................................................................................................................... 8

4.2. Software .......................................................................................................................................... 84.2.1. OS ............................................................................................................................................ 84.2.2. Client........................................................................................................................................ 94.2.3. Database................................................................................................................................... 94.2.4. Language................................................................................................................................ 10

4.3. Network......................................................................................................................................... 12

4.4. Browser Capability ...................................................................................................................... 12

5. DETAILED DESIGN ........................................................................................125.1.1. Product Information Module.................................................................................................. 125.1.2. Transaction Module ............................................................................................................... 135.1.3. Customer Information Module .............................................................................................. 135.1.4. Inventory Module................................................................................................................... 14

5.2. Design Quality .............................................................................................................................. 155.2.1. Performance ........................................................................................................................... 155.2.2. Sizing ..................................................................................................................................... 155.2.3. Timing.................................................................................................................................... 165.2.4. Security and Control .............................................................................................................. 17

5.3. Database Design ........................................................................................................................... 195.3.1. ER Diagram ........................................................................................................................... 195.3.2. Schema................................................................................................................................... 19


3

5.3.3. Attributes Data Format (Refer to Appendix D1) ................................................................... 205.3.4. Check Constraints .................................................................................................................. 20

5.4. Interface Design ........................................................................................................................... 215.4.1. Requirement........................................................................................................................... 215.4.2. Web Interface - Customer (Refer to Appendix G1 ).............................................................. 215.4.3. PC Interface - Administrator (Refer to Appendix G2 ) ......................................................... 21

5.5. Quality Assurance........................................................................................................................ 225.5.1. Test Plan................................................................................................................................. 225.5.2. Stress Test .............................................................................................................................. 22

6. CONCLUSION .................................................................................................22

7. APPENDICES..................................................................................................22

Main Screen.................................................................................................................................................. 43

Menus ............................................................................................................................................................ 44User Menu Screen...................................................................................................................................... 44Product Menu Screen................................................................................................................................. 45Order Menu................................................................................................................................................ 46Address Menu ............................................................................................................................................ 46Credit Card Menu ...................................................................................................................................... 47

Product.......................................................................................................................................................... 48Product Search Screen ............................................................................................................................... 48Product Search Results .............................................................................................................................. 49Product Information Screen ....................................................................................................................... 50

User Menu..................................................................................................................................................... 51New User Registration Screen ................................................................................................................... 51Registration Success .................................................................................................................................. 52Login .......................................................................................................................................................... 53Login Success ............................................................................................................................................ 54

Credit Card Update ..................................................................................................................................... 55Credit Card View Screen ........................................................................................................................... 55

Address Menu............................................................................................................................................... 56Address Menu Main Screen....................................................................................................................... 56Address Delete/Update Screen .................................................................................................................. 57Add New Address Screen .......................................................................................................................... 58

Report Generation ....................................................................................................................................... 60

Change User Password................................................................................................................................ 63Change User Password Main Screen ......................................................................................................... 63Customer Search Screen ............................................................................................................................ 63Change Password Confirmation ................................................................................................................ 64

Change Order Status ................................................................................................................................... 64Change Order Status Main Screen............................................................................................................. 64Order Search .............................................................................................................................................. 65


4

Change Status............................................................................................................................................. 66Change Status Confirmation Screen .......................................................................................................... 66


5

1. IntroductionThis study will be an evaluation of hardware, software, and architectural alternatives in building theCustomer Information Management System as proposed by the Requirements Analysis Phase (seeAppendix Z). It will consider the requirements and solutions for a perfectly implemented system aswell as offering comparisons and criteria for all viable systems. Its purpose is to evaluate variousSystem Design alternatives and from that derive the optimal total solution. The study takes intoaccount constraints such as budgets, time frame and existing procedures.

2. Problem

2.1. VisionTo develop an e-commerce solution for Nexxis Enterprises, which not only simplifies theircurrent business model, but also generates increased revenues and introduces a new saleschannel to the organization.

2.2. OverviewThe CIMS proof of concept project will use the existing business model for determination ofthe system features and functions. CIMS, as an Internet application will have the advantagesof ease of deployment, ease of modification and ease of maintenance since the “code” willreside on the Web Server, rather than on the remote PCs. The ultimate goal is to provide astable, secure and functional customer application. This proof of concept application will beused to demonstrate CIMS functionality and allow Nexxis to evaluate a possible Productionquality version in the future.

Components of the CIMS model include a Customer Information Module, a TransactionModule, a Product Information Module and an Inventory Module.

2.3. Requirement AnalysisRefer to Appendix Z.

2.4. ContactsRefer to Appendix Z.A3.

3. General DesignIn this section, we describe the general design and architecture selection alternatives for CIMS.

3.1. Architecture

3.1.1. Architecture Selection

There are 2 alternatives for the architecture: 3-tier model or 2-tier model.

3.1.1.1. 3-tier Design

The 3-tier Client/Server Architecture Design (refer to Appendix A1) allocates the CIMSapplications separately into 3 services: User Services, Business Services, and Data Services


6

Most of the application components are located in the business services tier, therefore changesor modifications within this tier will easy to handle amongst the entire application.Meanwhile, the time required for upgrade and deployment is expected to be smaller than the2-tier model.

There are 2 alternatives on implementing the 3-tier model: either both the business servicesand data services resides on the same server (refer to Appendix A4), or they will resideseparately on different servers (refer to Appendix A3).

In order to minimize the current cost of the CIMS proof of concept project, we recommendedthe business services and data services sits on a single server.

3.1.1.2. 2-tier Design

For the 2-tier Client/Server Design (refer to Appendix A2), the allocation of both the businessservices layer and user services layer will reside on the client side. The Data Services willremain on the server side. This architecture develops a thin-client, which, installed on theclient side, gives advantages of faster data access (assuming bandwidth is unaffected).

3.1.2. Recommendation

3.1.2.1. Criteria

Our recommendation of choosing the particular tiered model is dependent on the followingcriteria:

3.1.2.1.1. Upgrade Deployment Time (Long, Short)How much time is needed on deployment for future releases?

3.1.2.1.2. Client Upgrade Scalability (High Flexibility, Low Flexibility)Is it simple for upgrading the client side to handle potential future developments?

3.1.2.1.3. Support Cost (High, Medium, Low)Support cost includes the time involved in distributing new software, on-site supportresources, and time required for resolving bugs and related glitches.

3.1.2.2. Decision Table

Model UpgradeDeployment Time

Client UpgradeScalability

Support Cost

2-tier Long Low High3-tier Short High Medium

3.1.2.2.1. Upgrade Deployment Time (Long, Short)The upgrade deployment time for a 2-tier model is relatively longer than a 3-tier model.This is because 2-tier model requires a full testing and deployment of the software fromthe vendor (Nexxis) to the client. The time involve in building, for example an ActiveXClient, requires more time and testing in addition to an ActiveX Com object whichresides on the server.

3.1.2.2.2. Client Upgrade Scalability (High Flexibility, Low Flexibility)


7

On the client side, a 3-tier model doesn’t require it handle specific procedures forupgrades. However, in 2-tier design, the client is required to download a setup package orsimilar software to incorporate upgrades or changes.

3.1.2.2.3. Support Cost (High, Medium, Low)The support costs is minimized as all the business processes reside on the centralizedserver. There are no extra costs for on-site support when a 3-tier model is used.

3.1.2.3. Conclusion

The 3-tier model with a single server is considered the optimal choice for CIMS when takinginto account current resources, advantages in upgrades, and minimization of future supportcosts.

3.2. Features

3.2.1. Customer

1. Add user2. Login an user3. Add/remove/edit address4. Add/remove/edit credit card5. Add/cancel order6. Change email and/or password7. View Order History8. Product Search

3.2.2. Administrator

Administrator should have extra authority to change any information residing on the database.

3.2.2.1. All Customer Features

The administrator has the right to perform all customer features (Section 3.2.1).

3.2.2.2. Customer Password Modification

Although there are huge implications of the Administrator having such encompassing rightsto modifying customer’s attributes, Nexxis would like to bear all the risk in order to protectthemselves.

3.2.2.3. Change Status of Order

The status of each order needs to be changed on the database when the product is ready to beshipped, has been shipped, or has been cancelled.

3.2.2.4. Report Generation

Either batch mode or interactive mode report generation is required.

3.2.2.5. Data Mining

Data Mining allows Nexxis to track the behavioral trends of its customer. Time-seriesforecasting may apply for future prediction of Nexxis Sales, Nexxis Revenue, or evendetermining Nexxis most popular product. The underlying statistical theory would be hiddenaway from Nexsis, but the statistical analysis results would be very useful for futuremarketing and operating plans.


8

4. SelectionEach component in the selection process is closely related. Choosing the operating system involveschoosing the hardware and finally choosing the database.

4.1. Hardware

4.1.1. Server

One of the critical steps in the overall system, the hardware is the base layer upon which a solidfoundation for an effective solution can be built. There are many things to consider in theselection process, primarily price, reliability, availability and stability. Other things to considerare efficiency, quality, support and warranties and bundled software licenses.

In addition, the selection can be narrowed down between Intel and RISC based processor models,but with more operating systems offering support for either hardware platform, features offered oneach platform must be considered. As an example consider Sun Solaris 8. Although it is offeredon both the Intel and SPARC platform, the SPARC platform offers more features and hardwaremonitoring. These features are not due to limitations in the Intel hardware architecture, butbecause of Sun’s ownership of the SPARC architecture.

See Appendix C2 for a comparison of different hardware.

4.1.1.1. Recommendation

Due to the limited budget and limited initial anticipated hits, the recommended solution is tooperate the site from one dedicated physical server. On this server will reside the firewall,web server and database. However, this option must be scalable and should accommodateseamless future integration of additional servers as the need grows. To meet this end,Compaq’s DS20 Alpha Server is the recommended choice. This server meets the cost,scalability, reliability and availability requirements. Also as the company grows, a DS10Alpha Server can be added to handle firewall protection and eventually a second DS20 AlphaServer can be added to handle increased database management. This way the system willgrow as the user database grows and performance will not vary much in the perception of thecustomers.

4.2. Software

4.2.1. OS

Choosing the right operating system is an important step in building a system. The operatingsystem is the middle layer between the hardware and the applications. The OS controls criticalfile handling operations and memory management tasks so complete compatibility with thehardware is essential to maintain a smooth error free system. The OS should maintain controlover the entire system at all times. Included tools should be easy to use, should integrateseamlessly with the interface and be accessible by all applications.

The CPU architecture varies between x86 (i.e. Intel, AMD, etc.) and RISC systems. Operatingsystems are customized to specific CPU types and exploit the features of the CPU they aredesigned for. While most versions of UNIX operate on x86 based CPUs, they are better suited forSPARC based CPUs. Linux is generally ported on most platforms, even on Macintosh systems.Microsoft’s Windows 2000 OS on the other hand is designed to run on x86 hardware only, butprovides a wider array of support for third party hardware.


9

See Appendix C1 for the advantages and disadvantages associated with each OS.

4.2.1.1. Quick comparison

OperatingSystem

Stability Reliability Maturity GUIEase of

use

StartingPrice

Windows 2000 GOOD GOOD 6.5 YEARS(NT)

Good $6000 US

Solaris 8 VERY GOOD EXCELLENT 8 YEARS Average Free licence*

Linux EXCELLENT EXCELLENT 8.5 YEARS Varies***

Free**

Tru64 Unix 5.0 VERY GOOD EXCELLENT 5+ YEARS Average Bundled /w HW* for up to 8 CPUs (cost of media / shipping extra)** price charged for most versions is minimal, based on added components, but the kernel source remains free*** depends on the release version and releaser


Based on the criteria of a good OS, Linux is the best choice. It was initially designed for theIntel 386 architecture, however being free it has been openly modified and re-distributed sinceits initial 0.01 release in mid 1991. Linux offers the most cost effective and flexible solution.Being free entitles the users to enhance and customize any part of the OS to suite their needs.It has versions that support most of today’s hardware platforms available.

4.2.2. Client

4.2.2.1. Web Interface

The system can operate on any client OS, as the client is independent of the server.

4.2.2.2. PC Interface

The PC interface will reside on the server, as the server will not be initially configured withan internal network. Therefore all operations will take place on the server.

4.2.3. Database

There are several different vendors who provide quality database applications. Among the leadersare Oracle, Sybase, DB2 and Microsoft’s SQL server. Each database application has its strengthsand weaknesses, including ease of use, reliability, scalability and cost. Other factors must beconsidered as well, such as, compatible operating systems, hardware costs and the independenceof the database with the interface. A general overview of the databases follows.

4.2.3.1. General Overview

4.2.3.1.1. Oracle

Oracle is a relational database management system. It is trusted, widely used databasesoftware. It is supported on the Windows (Intel) based platform, the Linux platform andon Unix (RISC) platforms. The current list of operating systems that support Oracle


10

includes Microsoft Windows NT (Windows 2000 = Windows NT 5.0), Sun Solaris,Linux, Compaq Tru64 Unix and HP-UX.

Oracle is scalable, reliable and secure. It allows data of varying forms to be stored andretrieved in the database. These types of data include video, sound, spatial data, text andgraphics. These provide an advantage when consumers request pictures of the items theywish to purchase; they will be available as a field in the corresponding records. Also itallows for future growth and expansion. While ease of use and functionality areimportant aspects of Oracle, Oracle’s availability is not as high as some of the otherdatabase applications.

Oracle also offers a suite of other applications that can integrate with the database toprovide a seamless e-commerce solution.

4.2.3.1.2. IBM DB2

IBM’s DB2 is a trusted name in the market place. Offering functionality and stability, itis gaining ground in the market place. It’s availability and compatibility with quite a fewplatforms makes it a good contender in today’s environment. Current implementations ofDB2 include Microsoft Windows 95/98/NT, Sun Solaris, HP-UX, OS/2, AIX, SCOUnixWare, AS/400, OS/390, etc. DB2 also has a version for hand held devices, so datacan be accessed remotely from a universal server.

In terms of availability, DB2 is more available than any other database, with the lowestfrequency and duration of downtimes. DB2 is scalable, reliable and secure. Beingbacked by IBM makes DB2 one of he most supported databases available, with numberone rated service levels.

4.2.3.1.3. MS SQL Server

Microsoft’s SQL server is cost-effective, reliable and fast. However, it’s restricted to theWindows platform. SQL is said to have “unlimited” scalability by Microsoft. It isrelatively easy to use and has a very good average uptime of 99.95% when used on theWindows 2000 Advanced Server platform.

Total Cost of Ownership for SQL is also rated as one of the lowest in the industry fordatabases.


DB2 is the recommended choice for the database. It is highly available, reliable and scalable,exceeding all the requirements of a good database. In comparison to other similar databases,DB2 is cost effective and requires low maintenance. Also its support on multiple platformsmakes it a good choice for future upgrading.

4.2.4. Language

The language used for CIMS development is actually based on the OS Selection. If the OS isSolaris based, then CGI technology will be the best alternative for implementation. Otherwise, ifthe OS is window based, then ASP technology is the best alternative.


11

4.2.4.1. Server

ASP and CGI both allow the business services reside on the web server. They both providetechnology that can obtain information from the data services and return HTTP responses.

4.2.4.1.1. Common Gateway Interface – CGIThe language to implement CGI will be Perl 5.005. The module DBD and DBI allow Perlscript accesses to the DB2 database, when the Client Application Enabler (CAE) isconfigured probably.

The advantage of CGI is that it is a very simple language. The time for development canbe shrunk and, as a result, the resources spent on developing the code can be minimized.

The disadvantage about CGI is that it gives a relatively slower performance than ASP.An inexperience programmer can easily develop unreadable code, which increases thedifficulty of improving and upgrading the application.

4.2.4.1.2. Active Server Pages – ASPThe advantage of using ASP is that ASP has relatively faster performance than CGI. Thetime and resources spend on developing, configuring, and customizing the server is alsorelatively faster than UNIX-based applications.

However, Microsoft Components (COM) object and Transaction Server (MTS) introducemore complications in developing ASP-based applications. The resources spent ondeveloping this application are more expensive than developing CGI.

4.2.4.2. Client

On the client side, we can choose to use VB script, Java Script, or a combination of both.

4.2.4.2.1. VB ScriptVB Script runs only on Microsoft-based browser, e.g. Internet Explorer (IE). Thereforethe biggest disadvantage is that many other browsers cannot run VB script. Although,there is a plug-in for other browsers that are available for users to install on the client, itis still a problem of asking the client to install a plug-in.

However, VB Script offers many good interfaces and simple operational use. It alsomakes implementing DHTML easier and faster. Meanwhile, if MTS is used inimplementing CIMS, VB script will be very helping in providing error message,confirming database atomicity and maintaining database concurrency.

4.2.4.2.2. Java ScriptJava Script offers many operations and functions that are useful to CIMS. This analysisfound no disadvantages about Javascript, except that there are browsers which are unableto run Java Script. However, studies show that 90% of all Internet users use webbrowsers that are able to run Java Script. Java Script also allows many interestinginterfaces and animations to occur in the browser.


In the previous section, the OS has been chosen to be Linux, therefore, the server language isthe best chosen to be CGI.

On the client side, Java Script will be used. VB Script will not be used but will be consideredfor future upgrades when necessary.


12

4.3. NetworkNo plan for Network Implementation at the current time. It is however very important to note all theimplications of Network implementation when it is necessary.

Since there will be no network, all operations not relating to consumer transactions will have to behandled directly on the server. However, for future implementation, the following must be considered.The network will have to offer remote access and an internal Intranet as the primary means of access tothe database. Also software related maintenance tasks must be attainable from anywhere within thenetwork.

The organization currently consists of one main office with stand-alone clients. For futureimplementation a local area network connected via 10/100 MB Ethernet copper would initially suffice,as this is the basic network configuration supported by most servers.

Other costs and items will be required for this configuration including routers and hubs.

4.4. Browser CapabilityBrowser Capability plays a significant role in designing CIMS application. Previous discussions withNexxis staff has made it understood that CIM should be capable of running on most browsers on anyOS.

5. Detailed designUsing Structured Design concepts developed by Yourdon and Constantine, the mapping of CIMSapplication programs onto structure charts are achieved by using ‘transaction’ and ‘transform’ analysis.Transaction analysis identifies clusters of processes that ‘work together’ and are distinct of each other toconstitute transaction centres. Each transaction centre is mapped onto a module. Transform analysisclassifies modules into input, process, and output submodules. The analysis developed for CIMS hasresulted in highly cohesive module coupling in the sense that they contain components which work togetherto perform a specific task. The data and common coupling involves modules exchanging only dataamongst themselves and uses 2-4 immediate subordinates’ fan-out quality of design. The design qualitychosen ensures that the procedural (and in some cases functional) cohesion – all components of a modulemake up a single control sequence (subprocedure, flow of control) – is maintained for each structure chart.

A description of the structure design implementation (transaction and transform analysis) to satisfy thesoftware requirements for the four modules of CIMS, namely Product Information (Section 9 ofRequirements Analysis – Appendix Z), Transaction (Section 8 of Req. Analysis – Appendix Z), CustomerInformation (Sec. 7 of Req. Analysis – Appendix Z) and Inventory (Section 10 of Req. Analysis –Appendix Z), follows.

5.1.1. Product Information Module

The Product Information Module will be responsible in managing all the information about thesuppliers and would automatically update that information by periodically checking the supplier’sweb site. It is also responsible for fulfilling user requests for product price (quote) and productinformation.

5.1.1.1. Customer

The customer or user requests a product quote or product information, which necessitates auser interface in order to retrieve the product ID that the user in interested in.


13

5.1.1.1.1. Product Quote and InformationThe transaction begins by retrieving the product ID specified by the user and verifying ifit is the correct format and if it exists in the current database. Inventory is also verifiedto see if any stock is available per chance the user wishes to purchase. The productdetails are displayed to the user along with the current timestamp since updates can occurasynchronously by the administrator, sales staff, and/or vendor. The resulting structurechart can be found in Appendix E1.

5.1.1.1.2. Admin/Sales/VendorProduct updates, which can range from new product profiles to changes in product andsupplier information, can only be conducted by authorized users such as theadministrator or sales staff (who find new products or better deals from other suppliers).User interface is required to obtain the updated information for database inclusion.Automatic updates by vendor are done via supplier web site referencing to ensure thelatest changes are updated on the database.

5.1.1.1.3. Product UpdateAfter verifying authorized user update is being performed, product details are obtainedfrom either the user or from the supplier web site. These product details are eitherupdated in the product profiles or new profiles are created. The databases are thenupdated to reflect the current changes made. The resulting structure chart can be foundin Appendix E2.

5.1.2. Transaction Module

The transaction module maintains a record of all items ordered per user per request at the specifiedtime of order. Maintains a record of order history for every member as well as paymentinformation. It is responsible for requesting credit card authorization to allow the transaction to beprocessed.

5.1.2.1. Customer

A user interface is required to allow the user to place the order and input required informationfor the transaction.

5.1.2.1.1. Product OrderSince only valid members are allowed to place orders, user login is verified first beforeproceeding. Once verified, the order details are read in and checked for format errors.The member and order details are then processed to ensure that the correct address forshipment is used and that the member credit is still in good standing. Finally, thedatabases are updated to show the changes as a result of the order including the user orderhistory and inventory information store. The resulting structure chart can be found inAppendix E3.

5.1.3. Customer Information Module

The Customer Information Module provides registration processes for new users, update userinformation processes for active users, and manages customer information. It also represents thepoint of access for members to place, check and change status or product requests.

5.1.3.1. Admin

The Administrator should have encompassing ability to verify, edit and update customerinformation, product information, inventory information, order information for all members.


14

This will allow for the generation of reports, of summaries to observe the trends andbehaviours of clients and the marketplace. Although, all four modules of CIMS can be lookedat by the Administrative Summary Transaction, only the Customer Module will be addressedin detail here.

5.1.3.1.1. Customer Information SummaryIn terms of Customer Information, the Administrator can generate summaries on, forexample, specific member’s orders, and edit the member profile if required to. Theyshould be able to verify order histories, invoices and add/delete users is they so wish.Since only the Administrator is allowed to perform these requests, a login is verifiedbefore proceeding. The customer details are then retrieved from the database andedited/verified/updated to the discretion of the Admin and these details can besummarized for future in-depth analysis. The structure chart can be found in Appendix F.

5.1.3.2. Customer

Users who request membership must provide credit card information in addition to personalinfo in order to create a member profile. Once a member, the user can perform a variety ofrequests including editing one’s address, credit card information, email or password, checkstatus of order, and of course placing an order.

5.1.3.2.1. Customer Information ManagementAfter a member’s login is validated, the user request is read and verified to be a validrequest. The request is then processed in which case databases are read and updatedaccordingly. The results of the request are then outputted to the screen for the user alongwith a thank you/verification message. The resulting structure chart can be found inAppendix D2.

5.1.3.2.2. User membershipTo become a member, a variety of information is required from the user. User detailsinclude name, address, credit card information, email and password. These details areread in checked for format errors. They are then processed to determine if the credit cardinformation is valid and if the login name (email) has not been already assigned toanother member. Once these verifications are passed, a member profile is created andupdated in the database. The resulting structure chart can be found in Appendix D3.

5.1.4. Inventory Module

The Inventory Module not only provides inventory management, but also prints the invoices foreach order as well as the email verification to the client. The Inventory Module not only providesinventory management, but also prints the invoices for each order as well as the email verificationto the client.

5.1.4.1. Admin/Sales

Product availability is verified before the transaction can be processed and this was handled inthe Product Order Transaction Module. Updates can be made by authorized users such as theAdministrator or Sales Staff. This is handled via the Product Update Transaction Module.

5.1.4.1.1. Inventory updateThe software requirements for the Inventory module of CIMS is handled in combinationof both the Product Order Transaction Module and the Product Update TransactionModule. Please refer to section 5.1.1.1 for descriptions.


15

5.2. Design Quality

5.2.1. Performance

5.2.1.1. System Reliability

The 1980 ARPAnet collapse and the 1989 AT&T system runaway demonstrated the possibledisasters when a system fails. Reliability becomes the most important requirement for CIMSimplementation. Current IEC-65108 and ISO-9001 provides framework for software systemreliability improvement.

5.2.1.2. Requirements

1. The system should maintain an acceptable level of performance availability to the user.2. The hardware and software associated with CIMS must provide a sustained 95%

availability. This reliability includes all portions of the associated hardware such as CPU,memory and disk drives. Reliability may be accomplished through the hardwarearchitecture or by adding duplicate or redundant hardware. Vendors should provide arecommended environment for proposed systems to meet this reliability.

3. The system should be operationally available to users 24 hours per day, and 365 days peryear. There may be instances where the system must go offline to perform maintenance,upgrade, and/or backup activities that require various components to be taken out ofservice. In these circumstances, efforts should be made to ensure that offline activity iskept a minimum so that CIMS can be back to operation as soon as possible.

4. The maximum downtown for the system, whether caused by hardware or software relatedproblems, will be dependent on the specific circumstances of the originating issues.

5. Vendors should provide relevant information pertaining to hardware reliability, such asMean Time between Failures and average system down time, etc.

6. All CIMS modules, and the DBMS, must be capable of sustaining a virtual 100%operational availability rate. Errors or lockups, which may affect a single user, must notcause the entire system to “lock up”.

7. The system must incorporate methods of resolving “deadlocks” which may occur withinthe database.

5.2.1.3. Method to increase reliability

The standard method of increasing hardware reliability is to introduce redundancy (Sub-Appendix Z.N). Software reliability can be improved via more precise system testing andsystem life cycle. The testing acceptance criteria and testing procedures are attached in Sub-Appendices Z.L and Z.L2.

5.2.2. Sizing

The size constraints of the entire CIMS application should be less than 50MB. However, as moreusers register into the database, the size of CIMS will increase at a steady pace. The CustomerInformation Module will automatically extract and delete outdated user member profileinformation. The outdated information will be stored on CD, for future references if necessary.

5.2.2.1. Data Quantities


16

The data and transaction quantities expected have been estimated based on certainassumptions discussed later. These estimates are based on preliminary information obtainedfrom the Internet, such as statistics of operating within an online mall. The full systemestimates could be lower than actual if the popularity of the system leads to a significantincrease in the number of transactions made by the system.

Initial Project Full Project Project Completion

Number of Customer 5000 10000 200000Databases 1 2 1

Average Customer Information Storage (Bytes) 1024 2048 2048

Average Customer Credit Card Info Storage (Bytes) 512 512 512Total Customer Information Storage (MB) 7.32421875 48.828125 488.28125

Number of Product 800 2000 1500Product Information Storage (Bytes) 4096 4096 4096Total Product Information Storage (MB) 3.125 7.8125 5.859375

Inventory Information Storage (MB) 1 2 1

Database size (MB) 22 340 600

Programme size (MB) {assumned} 50 50 50

Total Storage Require (MB) 83.44921875 448.640625 1145.140625

5.2.2.2. Transaction Quantities

The following estimates are based solely on our anticipated use of the system. Changes tothese estimates, if used to develop the hardware configuration, should be clearly identified.

Type of Transaction Number per day Time of DayCustomer Information Update/Register 30 70% 7pm-12pm; 30% otherwiseTransaction 2 80% 7pm-12pm; 20% otherwisePrice Quotation 200ª 80% 7pm-12pm; 20% otherwiseBrowse the site 300 80% 7pm-12pm; 20% otherwise

ª Since the quotation is made by client Java script.

5.2.3. Timing

5.2.3.1. Web-based interface

The performance of CIMS under a Web-based interface is , in part, dependent on the client’sbandwidth. Suppose a user uses 28.8K modem, CIMS should perform and respond between 2to 8 seconds for each user request. A time consuming system is inappropriate and may resultin loss of popularity.

1. When a user is performing a query on CIMS Database, the response time of the systemshould not be longer than the time generally accepted for that operation. Nexxis realizes


17

that response time is dependent on client’s bandwidth, but targets have been set forresponse time expected on typical operation as shown below:

Transaction/Operation Target Response Time1. Customer or product information input and validity

checks when adding/modifying customer attribute dataVirtually instantaneous

2. Adding a new record for customer or supplier or product Less than 3 seconds to either accept record or response witherror message

3. Viewing a product information Less than 8 seconds4. Verify Customer Creditability Less than 20 seconds with appropriate response5. Customer search for product with criteria Less than 15 seconds6. On line quotation Less than 8 seconds

2. When a user is performing an online quotation or transaction, a “**% complete”indication should appear at the status bar of the browser.

3. The system should not “hang” the session if a user request or operation aborts forwhatever reason. There should be a “timeout” feature, which will display a message tothe user and terminate the session. For example, a message saying “Unable to completerequest” is significantly better than being left with a flashing cursor or blank screen.

5.2.4. Security and Control

5.2.4.1. Security

Since there is no way to eliminate computer crime, CIMS strongly recommends Nexxis buyinsurance which covers and protects Nexxis from any computer crime and fraud.

128 bit secure HTTP services should provide sufficient security for the Transaction Module.However, there is no simple mechanism in proving the user is using his/her credit card, i.e.computer crime or fraud may occur. The best thing is that Nexxis maintains no responsibilityof eliminating computer crime. And if there’s any computer crime against Nexxis, theinsurance should cover any and all loss of any form.

From the user viewpoint, a LOCKED icon on their browser indicates it is safe for them toshop at CIMS, and therefore, the popularity of the site will not decease even if there is ahacker who finds a way to hack into CIMS.

Independent Vendors and Verifications (IV&V) are also recommended if Nexxis hassufficient resources.

5.2.4.2. Safety

There are no safety requirements for CIMS by considering it as commercial software. Theprobability of CIMS endangering a person physically is as low as 10-7 – 10-9.

5.2.4.3. Failure contingencies

5.2.4.3.1. BackupBackup concerns the facilities to copy the CIMS database and files to a secondary on-lineor off-line storage.


18

5.2.4.3.1.1. Requirements1. The system must provide backup facilities for all data contained within the

system.2. The system must provide incremental backup facilities (only those files which

have changed since the last backup) and universal backup facilities (entire filebackup).

3. The system must be capable of performing incremental or universal backupoperations in a batch mode at a pre-specified time.

4. The system should be capable of backing up to magnetic tape, optical disk oroptical tape.

5.2.4.3.2. RollbackRollback concerns the ability of the system to avoid contamination of the data’s integrityby utilizing a facility which guarantees “all or nothing” execution of each transaction.

5.2.4.3.2.1. Requirements1. The system must utilize a form of transaction control on the database, which will

avoid conditions such as simultaneous writing to fields and record “deadlock”.The transaction control feature must guarantee data integrity by not makingmodifications to any data tables until a transaction has actually been“committed”.

2. In the event that any of the relevant fields have been modified between the startof a transaction and the time it is committed, the system must not make anymodifications to the data, but must abort the transaction and display a suitablemessage to the user.

5.2.4.3.3. Recovery and RestartRecovery and restart concerns the ability of the system to re-establish the IMCSdatabases to their current status after a system crash.

5.2.4.3.3.1. Requirements

Restart:The system must have the ability to store all transactions in progress in order torecover from a system failure. If there is a system crash between the time atransaction is committed and changes are actually made to the data, the system willcomplete these outstanding transactions upon restart of the system. Transactions,which are in progress but not yet committed when the system goes down, will beaborted upon restart.

Recovery:The system must have the ability to maintain a log of all transactions made to thedatabase since the last backup of the database. In the event of a total loss of thedatabase, such as a disk crash, the system could reload the latest backup of thedatabase and recreate the current status of the database by replaying the transactionsfrom the log. The log must be automatically deleted when the database is backedup. Since a disk crash can potentially harm all files on the disk, the system mustalso be capable of storing the log file on a different physical disk drive than thedatabase itself.


19

5.2.4.4. Restart

Before shutting down the server, administrator should ensure there is no user currently usingthe system. Apache and IIS both provide user connection information before shut down. Theadministrator should verify that no user is using the system right before shut down.

5.2.4.5. Maintenance

In case of accidental shut down, the server backup system will automatically redirect the newuser to a “temporary out of service” web page, and inform the user that the system is notworking properly.

5.2.4.6. Backup

CIMS will automatically create a monthly report, and request the administrator to backupsystem regularly. In addition, CIMS will request a backup when the content size becomeslarge enough to indicate a decrease in performance. The proposed backup should updatecustomer information on a regular basis. A monthly backup protocol will significantlyimprove the reliability of the system.

5.3. Database Design

5.3.1. ER Diagram

Refer to Appendix.The ER diagram shown includes all entities and relations utilized in CIMS.

5.3.2. Schema

5.3.2.1. Tables

The following is a list of all the relations and entities created for CIMS:

1. customer (c_id, c_first_name, c_last_name, c_login, c_password)c_login is the email address of the customer. It is unique, since there exists no 2 identicalemail address for a single individual.

2. address (a_line1, a_line2, a_city, a_province, a_postal_code, a_type, a_phone, c_id)Note that the address itself is the key. The c_id allow us to identify which customermaintains which addresses. Each customer will have one billing address and possiblymultiple shipping addresses and a default shipping address is maintained for eachcustomer. The phone number in this table allows multiple phone numbers for onecustomer at one address.

3. credit_card (cc_id, cc_name, cc_type, cc_expiry_date, c_default, c_id)Note that the cc_id and cc_name combine to form the key in credit card table. This isbecause one family usually shares the same credit card number, using a different name toidentify each individual in a family. The c_default attribute identifies whether eachparticular credit card is the default card for a particular user. This allows CIMS tomaintain multiple credit cards for single user.

4. product (p_id, p_type, p_name, p_distributor, p_manufacturer, p_description, p_price)The product table stores information of all products, with their type (SOFTWARE,HARDWARE, COMPENENT, SYSTEM or MISC), title, publisher, author, descriptionand price.


20

5. order (o_id, o_shipping_method, o_time, a_line1, a_city, a_province, a_postal, cc_id,cc_name, c_id) The order table stores the information of an order, who placed the order,who to bill to, where to ship to, which credit card to bill, how it is shipped, and what isthe order status(shipped, awaiting shipment, back order, cancelled)

6. details (d_quantity, d_price, d_status, d_status_info, o_id, p_id)Since each order may have more than one product shipping to more than one address, thedetails table stores information on every detail of each order.

7. inventory (p_id, i_quantity, i_status_info)The inventory table stores information about the inventory of each product currentlyavailable in Nexxis. The status info will store information concerning immediateavailability or date available.

5.3.2.2. View

The following virtual tables are generated via VIEW. These VIEWs are very useful foradministrator and CIMS in utilizing all the features.

1. send_invoice(a_line1, a_line2, a_city, a_province, a_postal_code, a_type, a_phone,c_id, o_id) Given a customer ID, we can determine where to send the invoice.

2. ship_to(a_line1, a_line2, a_city, a_province, a_postal_code, a_type, a_phone, c_id,o_id) Given a customer ID or order ID, we can determine where to send the product(s).

3. lives_in (a_line1, a_line2, a_city, a_province, a_postal_code, a_type, a_phone, c_id)Given a customer ID, we can determine where is the living address of the customer.

4. mail_to (a_line1, a_line2, a_city, a_province, a_postal_code, a_type, a_phone, c_id)Given a customer ID, we can determine where is(are) the shipping address(es) of thecustomer.

5.3.3. Attributes Data Format (Refer to Appendix D1)

In this section we describe all the data format of all the entities and attributes.

5.3.4. Check Constraints

CIMS provides the following check constraints to ensure consistency on our database.

5.3.4.1. product table

1. Check for p_price ( > 0) Ensures there is no negative value placed on a product.

2. Check for p_type (SOFTWARE, HARDWARE, COMPENENT, SYSTEM, MISC)3. Product type can only be SOFTWARE, HARDWARE, COMPENENT, SYSTEM or

MISC

5.3.4.2. address table

1. Check for a_type (B, S) Each customer will have one billing address and possibly multiple shipping addresses. Ifa_type = “B” then, that is the billing/living address. Else, they are shipping address witha_type = “S”.


21

5.3.4.3. credit card table

1. Check for cc_type (V, M, A, D) cc_type stores “V” for visa card, “A” for American Express, “M” for matercard, “D” forDynasty and etc.

2. Check for cc_default (Y, N) Customer may have multiple credit cards, therefore c_default = “Y” implies it is thedefault credit card for that particular user. c_defauly = “N” , otherwise.

3. Check for cc_expiry_date (to current date) Nexxis doesn’t want any expired card stored in the database.

5.3.4.4. order table

1. Check for o_shipping_method (A, S, I, T,) o_shipping_method stores “I” for immediatecourier, “A” for airplane courier, for “T” for truck courier, and “S” for standard postalservice and etc.

5.3.4.5. details table

1. Check for d_price is ( 0 < d_price <=10000) The company would like to manually audit any transaction that is higher than $10000.

2. Check for d_status (W, S, O, L) d_status stores “W” for awaiting, “S” for shipped, “O” for out of stock, and “L” standsfor lost.

5.4. Interface Design

5.4.1. Requirement

The interface design requires the user to be able to use the application easily without specifictraining. The most applicable reasoning is that the system interface can be easily accustomed toduring its usage. There are 2 interfaces for CIMS, the Web Interface and the PC Interface.

The Web Interface is mainly for the Customer, and the PC Interface is only used by Nexxis Staff.Note that the PC interface resides on the server, and has no network or remote capabilities. It ishowever, the Web Interface that can be viewed from most any browser on any OS of the client.

In general, both interfaces focus on the issues of Feedback, Affordance, Forcing Function,Consistence and Automatic Learning. All details will be discussed in the following sections.

5.4.2. Web Interface - Customer (Refer to Appendix G1 )

5.4.3. PC Interface - Administrator (Refer to Appendix G2 )


22

5.5. Quality Assurance

5.5.1. Test Plan

The test plan will be written in full details. All boundary cases and real cases should be testedbefore the application runs in production mode. The implication of not having sufficiently testedbefore production may result in lost in popularity of the site, as well as lost of customers.

The test plan would include the following.

5.5.2. Stress Test

5.5.2.1. MS

Microsoft Web Application Stress (WAS) tools would be used under a black-box scenario.http://webtool.rte.microsoft.com/

5.5.2.2. Unix

If we are choosing Unix as our application platform, there are currently no such packagedtools for stress tests. Perl, on the other hand, should be able to simulate the stress on the serveritself. However, writing code for simulation requires significant amount of effort.

Another alternative -- Nexxis may want to obtain an additional small and cheap NT server(Windows 2000 Server) to perform the stress test using WAS. The disadvantage in this is thatthe extra budget (~$2000) incurred to buy the server and the software.

In order to satisfy the testing requirements described in Requirement Analysis, stress test isone of the main components to be passed for CIMS to be placed in production mode.

6. ConclusionThese design recommendations ensure an efficient, reliable system within the monetary and timeconstraints given. Beyond efficiency and ease of use, this implementation adds a new viable sales channel,which has been proven as an effective method of generating revenues. This study also addresses hardwareissues for future growth and the considerations for scalability as budgets increase. Additionally, thesoftware solutions outlined will accommodate new hardware and will adapt as the needs change.

7. AppendicesAppendix A1. 3-tier DesignAppendix A2. 2-tier DesignAppendix A3. Physical Representation of 3-tier Architecture (with separate servers)Appendix A4. Physical Representation of 3-tier Architecture (with single servers)Appendix B. Physic Representation of System ArchitectureAppendix C1. Operating System ComparisonsAppendix C2. Server ComparisonsAppendix D1. Database Data FormatAppendix D2. Customer Information Structure ChartAppendix D3. User Membership StructureAppendix E1. Product Quote Structure ChartAppendix E2. Product Update Structure ChartAppendix E3. Product Order Structure Chart


23

Appendix F. Admin Summary ChartAppendix G1. Web User InterfaceAppendix G2. PC User InterfaceAppendix Z. Requirements Analysis

Appendix A1. Logical Representation of three-tiersystem architecture

An animation of the 3-tier model can be seen on:http://www.scar.utoronto.ca/~96tamtom/cims/3-tier.html

Figure 1 Logical Representation of three-tier system

Figure 2 Physical Representation of three-tier system

Figure 2 published inMicrosoft Mastering Web Application Development Using Visual InterDev v1.0 CD.1999 Microsoft Press.

InternetDatabase

Web Browser Web/ApplicationSever

Oracle

UserServices

BusinessServices

DataServices


24

Appendix A2. Logical Representation of 2-tier systemarchitecture

Figure 1 Logical Representation of three-tier system

7.1.1.1.1.

7.1.1.1.2.

Figure 2 Physical Representation of three-tier system

Figure 2 published inMicrosoft Mastering Web Application Development Using Visual InterDev v1.0 CD.1999 Microsoft Press.

Internet Database

Web Browser Oracle

UserServices

BusinessServices

DataServices

system design proof of concept specification …jm/340s/01/asst/00/asst31.pdfcsc340s prof. john...

Documents