The third party software will be provided by SecPay and will be hosted on an ITS server by the University of Durham ITS department. When a customer wishes to purchase an image they will input their details into the data capture. Once the user clicks ‘submit details’ they are forwarded to the SecPay system and their software will deal with the validation of the details and process the payment.
As the card processing is dealt with outside the scope of this project, references will only be made to the SecPay system and no details of that systems design will be included in this document. Image delivery will also not be covered within the scope of this document. Design diagrams will be drawn to show how to implement the system, and in the case of the user interface, prototype screenshots will be produced but because of time constraints the system will not by physically implemented.
S3G group designed and implemented the original system but did not include any non-functional requirements to help users of different nationalities or those users with disabilities. Therefore our system will take this into account by providing GUI translation facilities which will provide the option for users to change the Interface language. As well as this certain areas of the interface pages will vary in hue to help those users who are partially sighted differentiate between different areas.
As mentioned in section 1.1 of this document certain software aspects of the existing system will be removed (see section 1.5). Both the Messaging and the Games modules will be deleted, these modules fulfilled their original additional requirements to be able to send, store and compose a message and also to have a Jigsaw, Slide Puzzle and send an E-Card respectively, however their lack of relevance to the design brief of this system means they will be removed.
Definitions, Acronyms, Abbreviations
References
Harwood, Sam et al. 2003 Durham electronic photographic database project design
<> (Accessed 01.12.2004).
Mansfield, Paul et al. 2003 Electronic photo gallery
<> (Accessed 01.12.2004).
Gooch, Tom. 2000 What is UML?
<> (Accessed 01.12.2004).
Burd, Liz 2004. Software Engineering for the Internet notes
<> (Accessed 01.12.2004).
Changes to S3G Requirements
This section includes the alterations to the S3G group requirements for the original system and the requirements added for the new payment system.
The only changes to the original S3G group requirements were the removal of the following:
It was agreed that these requirements do not add to the functionality of the system in relation to the original project brief and were therefore removed from the requirements specification.
The following requirements were added for the new payment system. To see which components and classes these requirements were link to, please see section 2.1.5.
Overview
The design document is laid out in accordance with the ANSI/IEEE standard 1016-1998. The section headings are as follows:
Introduction
Within the introduction the purpose and the scope is defined as well as references and an explanation of the terminology used within the document.
Decomposition Descriptions
The decomposition description is where the system is divided into design entities, structure and purpose / function of each entity using UML and entity-relationship diagrams.
Dependency Descriptions
The dependency descriptions section is concerned with specific relationships between various entities including the type of relationship, shared information and order of execution.
Interface Description
The interface description deals with the user interaction with the system mainly to do with screenshots. The GUI screen design takes into account colour blindness and internationalisation.
Decomposition Descriptions
Module Decomposition
This design document aims to provide a detailed outline of what needs to be extended to the existing S3G system. The aim of the document is to outline what components need to be added in order to incorporate an e-Payment facility as mentioned in section 1.1 while maintaining the existing systems’ loose coupling and strong cohesiveness.
The Deployment diagram below is an adaptation on the Deployment diagram in Section 2 of the original SEG report (see Appendix A).
The diagram shows the breakdown of the system in component form and the distribution of these components over the physical machines.
Figure 1 Deployment Diagram
The user on a client machine connects to the system via a Web browser. The user can then either browse through the images that are stored in a MySQL Database on the Database server. Or, the user also has the option, if they require, to purchase an image using the new payment module.
The payment module, Payment, whose implementation will be explained in section 2.1.2 allows the user to input their card details and then connects them to a third party program from a company called SecPay , which is hosted on separate secure server, to process the payment.
Payment Component
The Payment component contains all the functionality required to process a users payment details when they wish to purchase an image.
The Payment component incorporates the Payment class, the Shopping Basket class, the User class and an Archive class.
When the user finds an image they wish to purchase they add it to their Shopping Basket. To do this the user clicks the “Add to Basket” button next to the desired image. The image ID and user ID are stored together as a pair in the Shopping Basket class thus making it possible run searches on this table to find what images a client has in their basket.
The Payment class then deals with taking all of the user’s card details and passing them onto the 3rd party SecPay database.
Figure 2 Payment Component
The activity diagram below shows the process of an image being selected, added to the basket, purchased using a credit/debit card and then the purchase data is then stored in an archive table.
Figure 3 Activity Diagram for Purchasing an Image using the payment component
Entity Relationship Diagram for the Payment Component
The images that are uploaded will be stored in the database since it would provide a security risk if images were kept in a publicly accessible place. Currently on the ITS systems it is not possible to write to files outside of the public web directory and so images must be kept inside the database for security reasons.
All of the information held on dynamic web pages throughout the system will be held in the database. This means that the data structures used inside the database will be used throughout the system for consistency. To show the database design, an over-view of the database will be given followed by details about the relationships, tables and variables.
Any fields highlighted in bold are primary keys.
Overview of Database Alterations
The following tables, Payment, Shopping Basket and Archive have been added to store data in the selection and the processing of payments for images. The Payment table below will record all the details of the card being used by the customer for purchasing.
The Shopping_Basket table below will record the images selected for purchasing.
The Archive table below will record details of past transactions, such as who bought what and how much they paid.
Links to Requirements Document
The table below links the requirements created for the new payment system to their individual components and the classes used to implement them. This allows user/client requirements to be traced through to the components and classes in the design document.
Dependency Descriptions
Inter-module Dependencies
Use Case Diagram of the Payment System
The purpose of this section is to show the main activities of the users in this payment system. Figure 6 describes the actor functionality and shows the two actions users will employ when buying images.
Member
Member
Figure 5 Member Functionality
Inter-process Dependencies
Sequence Diagrams
By using the Use Cases above it is possible to identify a number of potential sequence diagrams using UML.
Sequence diagrams represent time in a vertical direction which equates to the length of a process. A sequence diagram also consists of objects (rectangles) and messages (arrows). There are two types of sequence diagram these are ‘Instance’ and ‘Generic’. Instance sequence diagrams omit all other possible instances for clarity, focusing on a specific use case, whereas Generic sequence diagrams show a higher level overview of the system including all use cases.
The following Instance Sequence Diagrams describe the system interactions from the additional payment system use cases (see above).
Figure 6 Choose a Picture to Buy Instance Sequence Diagram
This diagram simply shows an image can be selected from a web page and added to a shopping basket, other images can be added from the database to the shopping basket which keeps a running total of the price. User details are then transferred from the database to the card details form where the user fills out the card details, these details are valid and the payment is finished.
The shopping basket class allows the users selection of images to be recorded i.e. Image ID, price and name. Also within the shopping basket class the total price of all images is calculated.
Figure 7 Fill in and Submit Card Details Instance Sequence Diagram
The details the user inputs to the card details form is checked in the Authentication process e.g. the card isn’t past the input expiry date and the correct amount of numbers have been input for the card number. The SecPay system checks that the card details link to an active account.
Analysis Model
This is a high-level analysis diagram showing a model for how all the components in the system work.
Figure 8 Analysis Model
The user searches for an image stored in MySQL database according to a criterion, the results are then returned to the user via the web browser. If the user decides to buy the image, all payment details must be sent to the SecPay database that confirms the card details for that user.
Interface Descriptions
Component Interface
Payment Component
This component is a new component for the system and thus provides new functionality. N.B. As stated in section 1.2 of this document the payment validation carried out by the 3rd party SecPay software is outside the scope of this design document and so its functionality is hidden.
4.1.2.1 Payment Class
This class will contain the data passed from the “Payment” data capture form. The form itself was downloaded from the SecPay site, altered to our particular design specifications and then embedded into the page.
Consequently there are no methods in this class because the process is dealt with on the SecPay server side.
The “Charge Card” button will POST the details of the form using SSL to SecPay’s secure server using SecPay’s servlett https://www.secpay.com/java-bin/ValCard.
4.1.2.2 Shopping Basket
4.1.2.3 User
This table forms part of the underlying S3G system. No changes have been made to the table so please see the design document in Appendix A for details of this table’s implementation.
4.1.2.4 Archive
The purpose of the archive table is to store all purchases made. The shopping basket for a particular user is emptied after they have made a purchase so a record needs to be kept of how many purchases they have made and how much the user has paid for auditing purposes. The table will not store the users credit card details it will simply store a record of when the purchase was made, how much is was for and what was purchased. The record will be stored in a central table along with the user ID of the user who made the purchase.
Process Interface
The following screenshots are prototypes of what the system will look like when implemented. The screens are divided into three sections, each with a separate colour scheme to make it easier for people with vision difficulties to view the page.
The screen shots are from the English version of the website.
Home Page Prototype
This is the home page for the website. It is structured into three main sections. The first section on the left is an interactive drop-down menu. Depending on what is selected in the menu section the main part of the web page will change appropriately. The far right column on the web page shows what items the user currently has in their shopping basket.
Figure 9 Home Page Interface Design Prototype
Checkout Prototype
Once the user has finished browsing for images and wishes to purchase their selection they click on the Checkout button in the shopping basket section of the homepage.
That page will bring the user to the Checkout page. This page allows the user to view all the details of the images they have in the Shopping basket and remove any images they don’t wish to purchase.
Figure 10 Shopping Basket Interface Design Prototype
Payment Prototype
When the user has confirmed that they which to purchase all the images in their shopping basket they click on the Checkout in Figure 10.
This page will appear and the drop-down menu on the left will be disabled so that the user cannot accidentally click on something while their card details are being processed causing an error.
Once the details have been entered the user clicks the “Charge Card” button and they are linked securely over a SSL to the SecPay server who will then charge the card.
Figure 11 Checkout Interface Design Prototype
Appendix
Appendix A – SEG 3 Group Document
For Appendix A please see the SEG 3 (S3G) group document at the following location.
Appendix B – SEG 4 Group Document
For Appendix B please see the SEG 4 group document at the following location.
This functionality will initially be limited to the following languages: Chinese, Hindi, Arabic and English.
http://www.secpay.com/ for more details
contains further details of the implementation.
