Main Report

1

1. System Introduction

Walmart is a very successful and internationally renowned chain of supermarkets

providing a shopping experience to their customers like none other. They have

identified that that primary target of customer segment is day-to-day consumers

interested in a personalized service for an affordable price. Walmart's key strength

comes from their ability to pay attention to the benefit of the society, from which they

earn their wealths, while generating revenue.

1.1 Walmart Corporate Office

Walmart.

702 SW 8th Street,

Bentonville, Arkansas.

72716-8611

1.2 Walmart Corporate Purpose

“If we work together, we'll lower the cost of living for everyone... we'll give the world

an opportunity to see what it's like to save and have a better life.” (Walmart Stores,

Unknown)

1.3 Walmart General Corporate Drive

• Community – Walmart is funding more than 350 local nonprofit organizations

that will help expand nutrition, learning and employment services for

elementary, middle and high school students through out the 2011.

• Opportunity – Walmart is playing a major role side by side with Sam's Club

University of Wales Institute, Cardiff. (BCO308)

2

Military Family Promise to deliver support services to families with members

who served their country with honor as part of a project initiated by the First

Lady of the United States of America, Michelle Obama and Dr. Jill Biden.

• Sustainability – Walmart has taken initiative to reduce the number of miles

driven by taking trucks off the roads as much as possible, and keeping track of

efficiency in delivery process while paying attention to alternate methods.

• Health and Wellness – Walmart strongly believes that everyone should have

access to fresh fruits and vegetables at an affordable price. Walmart has even

taken an initiative by committing to opening between 275 – 300 stores in

specifically selected food deserts.

Apart from these specific lines of corporate drive, Walmart is also taking a keen

interest in their customers as a driving force. Walmart understands that a happy

customer is a profit. But a delighted and retained customer is pure wealth. This

ideology is like the soul of Walmart that has become the bloodline for its integrated

marketing strategies.

1.4 Proposition for a New Computerized Sales Management System

It has been proposed that Walmart should take interest in computerizing their sales

process in supermarkets in order to provide a better service to their customers. It is

my understanding that Walmart is already utilizing sophisticated Point of Sales (PoS)

systems in their supermarket outlets. Further more they have their very own online

web based e-store for the customers who prefer to make their purchases online than in

person. But for the purpose of completing this assignment, we stand in a point of time

line where Walmart is still using manual filing based sales management system

without using any computers. This assumption leads us to understanding following

key objectives Walmart would have been trying to achieve by implementing a

computerized sales management system.


3

• Provide a better service to the customers - As it had been pointed out before,

the majority of the customers of Walmart are day-to-day consumers who are

interested in personalize, speedy and low cost services for their wants and

needs. By computerizing the sales management process, the sales assistants

can provide a faster service to the customers, not having to keep them waiting

in lines for hours on end so that the sales person can check out the price index

and add up the bill for one customer whith a number of small items.

• Increase customer delight and reduce customer frustration – A better service

with minimum service period possible not only makes the customer delighted,

it also reduces customer frustration. In a busy world, it is not justifiable to

keep customers idling in a shopping mall because of a new sales assistant who

cannot seem to remember the price index even vaguely. A computerized

system would eliminate this problem and reduce customer frustration.

• Improve sales tracking abilities – though a manual system can be helpful in

keeping all the sales transactions recorded, tracking them in order to identify

patterns of destructive and constructive nature would be close to almost

impossible. A computer can do a faster and better job at grinding through

piles of sales data in order to come up with just the thing you're looking for.

• Get better control over stocks – handling efficient control of stock is an

entirely different story compared to handling sales with a manual system. But

for a successful supermarket chain, it is imperative to have a good integration

between sales management and stock control. A computerized system can

help Walmart better integrate these two processes into one system, or two

components on a larger Enterprise Resource Planner (ERP) if they wish to

implement one later on as the business blooms.

• Improve the corporate image of Walmart as a whole – given the substantial

financial and business expenditure of computerizing the sales management

process, this will improve the corporate image of Walmart in the eyes of their

customers as well as competitors. A business that takes their business serious

will appeal more to the customer than a shop running on bare minimum.


4

The above given proposition will act as a rationale for continuing to computerize the

sales management process of Walmart supermarket chain with a new software based

solution. Within reasonable limits, this rationale will justify the costs over the

benefits of implementing a new software based sales management system for Walmart

supermarket chain to handle customers, sales, and stocks in whole.


5

2. Unified Software Development Process.

2.1 Introduction.

To simply put, Unified Software Development Process or just Unified Process (UP) is

one of the most popular software development frameworks used through out the

software development industry in an International scale. It is a culmination of both

iterative and incremental software development models brought together to provide a

flexible and adaptable framework for the software development process.

2.2 The Need for a Software Development Framework.

Software development and engineering is a complex and important task that deals

with real hard cash in a world where computers are core to almost all major business

processes. And because of this importance and complexities, there is a huge risk

factor involved in engaging in software development. Given that any complex task

can be easily overcome by breaking the task into a multiple of relatively simpler

tasks, the best approach is to breakdown the software development process into a set

of sub-processes, thus allowing the part takers to focus and excel in one area at a time.

To take down the software development Goliath, the software developer David can

easily use the Slingshot of Unified Process. Though this analogy stops at the face

value, the premise it presents is still in tact. What Unified Process offers to the

software developer is a framework which can be used, adapted or extended to his

particular project. Software development projects vary in a number of ways,

depending on the domain, the requirements dictated by the environment, standards

adhered to by the industry as well as technical advancements and application. Making

a boiler plate model to handle this varying set of processes in a herculean task very

much tend to fail at the face of it. The very next change brought to the industry will


6

render such a model obsolete, leading to the adaptation of another new model. In the

other hand, a framework that leave space for adaptation and extension much like the

Unified Process can just be the thing software development industry needs.

2.3 The Attributes of Unified Software Development Process.

• Iterative and Incremental – the phases of the process framework are lapsed

on a series of time slots in a repetitive iteration. As with every iteration, the

state of the system is incremented a step further. This allows the developer or

the development team to focus on an abstract subset of functionalities of the

software at one given iteration and incrementally add more and more functions

as suited.

• Use Case Driven – in the Unified Process framework, Use Cases assume an

important and leading role in driving the software development process in the

right direction at right phase. Use Cases are used to capture requirements in

both business level as well as system level. The primary focus at this phase is

given to system level use cases which basically define functional requirements

of the proposed system and identify the area to be covered in each iteration of

the process phases. Use case can also help break down the tasks in an

incremental manner.

• Architecture Centric – the Unified Process puts the architecture of the

system in the center of the development process. Given than no single

architecture or model would be able to successfully support all given software

development project, Unified Process is flexible enough to support multiple

architectural models as well. Loosely defined, an architectural model is a

conceptual model that maps functional requirements to the software and

hardware platforms with a variety of tools, compilers, interpreters, supportive

software code, and etc.

• Risk Focused – as it is already mentioned before, there is a significant level of


7

risk involved with software development projects that can have a measurable

financial impact if not handled carefully. The Unified Process strongly

encourages developer or the development team to charge in an handle the

highest risks first. Usually risks are categorized as “high impact – high

probability”, “high impact – low probability”, “low impact – high

probability”, and “low impact – low probability”. Usually it is advised that

“high impact – high probability” risks are handled within the first few

iterations, so that the project can incrementally proceed to handle lower risks

through the rest of the project.

2.4 Phases of a Unified Process Project Life Cycle.

1. Inception Phase: This is the shortest phase of a Unified Process project life

cycle. In this phase, a justifiable business case or a rationale is established to

proceed with the rest of the software development project. It gives the

development and analysis teams to establish a scope and a set of boundaries

for the prospective system. Identifying risks, categorizing them, and laying

out risk handling procedures are also done at this phase.

2. Elaboration Phase: Arguably this is the most important phase of a Unified

Process Project Life Cycle. A majority of the system requirements are

captured and put into one design specification in this phase. Further, most of

the risks are handled at this stage as much as possible. Complete system use

case diagrams, basic class diagrams, package hierarchies and architectural

outlines are all put to draft at this phase. Much of the rest of the life cycle

builds up on the foundational architecture laid at this phase.

3. Construction Phase: This is the longest phase of a Unified Process project

life cycle. It also is where most of the iterations are taken place, most

incremental work is done, and notably the heaviest load of work is carried out.

Computer language programmers play a major role at this phase than system

analysts and such. The designs developed from the elaboration phase are put


8

to implementation in short bursts of time slots each incrementally adding a

feature or two to the already implemented set of functions. Rigorous testing is

carried out through out the phase in order to assure that the outcomes are met

with the system requirements laid out by the system use cases.

4. Transition Phase: This is the final phase of a usual software development

project. It encompasses tasks such as deployment of the system, handing over

deliverables, user training, data and system conversions, etc. If proper care is

taken at the prior stages of the life cycle to address all potential risks and

identify the requirements of the final system, this transition can be achieved

with minimum resistance.

2.5 Adaptation of Unified Process for Walmart Project.

In a professional discipline such as software development where theory is of no good

if it cannot be put to practice, mere discussion of the Unified Process would not have

done much good if we were not going to actually implement it for the project at

discussion. It is understandable that the Unified Process seems like an over

complication of a task that could have been achieved so easily with the integration of

a Software Development Life Cycle (SDLC) model such as the “Waterfall Model”. It

in fact is simpler and much more suitable for a small scale project as this one. But the

practice we gain by adhering to this new discipline is more important in this learning

process than to actually get the assignment over with by any means.

The beauty of the Unified Process is that it can be as simpler or complex as you want

it to be. As the applicant, you are at complete liberty to adapt this framework to your

project the way you find it suits. You are free to bend it, twist it and extend it the way

you want so that it suits your requirements better. This is one of the major reasons

why many industry giants as well as emergent software firms find Unified Process to

be of much use in small, to medium to large scare software development projects.

Because of this very reason, I have also adapted Unified Process software


9

development framework in a simpler, yet effective manner into this assignment in

developing Walmart Sales Management System as well.

Much of the Inception Phase is already covered for me by the assignment

specification provided to me as part of my course material. I have a well defined case

scenario outlining a number of key system requirements which must be addressed in

the system I am supposed to develop. Through the case scenario I easily managed to

identify the key requirements and the scope. After a bit of brain storming time, I

managed to isolate the limitations and layout a boundary for the project as well.

In the Elaboration Phase of the project, I started off by completing the System Use

Case Diagram which gave me a clear understanding of how I should break down

functions in various parts of the proposed system. Also I used these use cases to lay

out a basic test plan for the system. Then using the use cases, I designed the basic

layout of the classes that would interact within the system. One I got their

interrelations worked out, I refined them further by adding more and more details and

finally completing the Class Diagram. A hierarchy of classes was also prepared to

keep things in perspective.

Through the Construction Phase of the project, I started off by coding basic skeletal of

the the classes by simply dummy procedures, coupled with simple accessors and

mutators. I kept all attributes encapsulated from the very beginning as a good practice

that would prove helpful in providing me with well defined interfaces to get the

fundamental interactions working. A simple sequence diagram was used to keep track

of the order of interactions and messages passed between various entities of the

system. But much of the work was put to Class Diagram than the Sequence Diagram

since most of the interactions and messages being passed were designed in a way that

would make them look self apparent.

The Transition Phase is almost redundant in this particular project since this project is

not going to be implemented for real. But I used my imagination to understand how it


10

would be like having to actually implement this system and came up with a list of

recommendations for the implementation phase.

As an additional part of this assignment work I have given my own conclusion to the

project along with future recommendations and improvements. Some of them were

too complex to be implemented at my level of knowledge, some of them would

require a larger time span with specialized expertise with a stiff learning curve, and

some of them are purely for the sake of betterment of the system to bring it to the

level of industry strength.


11

3. Requirements Analysis.

3.1 Functional Requirements of Walmart Sales Management System.

I have identified three (3) primary actors who are directly interacting with the

proposed sales management system.

1. System Administrators – these are the users of the system who work on a

higher level, having more control over important aspects of the system such as

adding more users, giving them proper authorization levels and making sure

that the system runs as smoothly as expected.

2. Branch Managers – these are working on a higher level of the organizational

hierarchy of the Walmart, who has more decision making power than a usual

employee. They are responsible for doing day-to-day maintenance of the

system that allows smoother operation of the system.

3. Sales Assistants – these users put the system into heavy use. They spend more

time with the system than any other user, since they are the ones handle sales

transactions, which add up to be a majority of system's collective operations.

They play a major role in the long term where system's true benefits can be

visible. Their actions could lead to catastrophe as well as to the success of the

system.

Apart from these primary actors, there are two (2) other auxiliary actors who do not

interact directly with the system, but through a primary actor.

1. Suppliers – these are the people who supply products to Walmart so that they

can resell them to their customers. The system requires that suppliers be kept

track of so that they can be paid off for the amount of goods purchased.

2. Customers – the key to any business, still they interact with this system

through the Sales Assistants. Customers are kept track of and provided with a

reward point scheme as well.


12

Given that the primary users of the system are System Administrators, Branch

Managers, and Sales Assistants, I have identified following system requirements.

1. System Administrators

• Sign in to the system with proper credentials.

• Sign off of the the system when done working with it.

• Add new branches to the supermarket chain.

• Remove a branch from the supermarket chain.

• Update the information of a branch of the supermarket chain.

• Add users to the system and provide them proper permission.

• Remove users from the system and remove their permission.

• Update user information and alter permission levels.

• Change passwords of the users.

• Add new suppliers to the supermarket chain.

• Remove suppliers from the supermarket chain.

• Update supplier information when required.

• Add new brands to the branches.

• Remove brands from the branches.

• Update brand details when requied.

2. Branch Managers

• Sing in to the system with proper credentials.


• Add new sections to a branch.

• Remove a section from a branch.

• Update the section details when required.

• Add new products to sections.

• Remove products from a section.

• Update product information as required.


13

3. Sale Assistants

• Sing in to the system with proper credentials.


• Add new customers to the supermarket chain.

• Remove customer details from the supermarket chain as required.

• Update customer information when required.

• Add sales transactions on behalf of the customers.

• Remove sales transactions when deemed necessary.

• Update sales transactions data when required.

Even though at a first glance the Systems Administrator seems to have more tasks to

do with the system, the recurrence of these tasks is very low. In the other hand, Sales

Assistants have a few number of tasks that tend recur many times over a short time

period.

After identifying the above list of requirements for the proposed system, I prepared a

System Use Case diagram using the standard UML notations.


14

3.2 System Use Cases Diagram of Walmat Sales System.

Diagram 1. Use Case Diagram. This diagram depicts the finalized Use Case Diagram with primary

Actors and their interactions with various Use Cases.


15

4. System Design Specifications.

4.1 Class Diagram with Basic Notation.

Diagram 2. Basic Class Diagram. This diagram depicts the Class Diagram with the basic notation.

The extensive notation of attributes and methods has been postponed until the finalized for of the same

diagram presented later.


16

4.2 Complete Class Diagram with Full Notation.

Diagram 3. Complete Class Diagram. This is the complete Class Diagram finalized with attributes

and methods. All the mutators and accessors are included as well. The DBAccess interface was

removed as it does not hold a significance in the system design point of view.


17

4.3 Complete Package – Class Hierarchy.

Diagram 4. Complete Class – Package Hierarchy. This is the complete hierarchy of Classes,

Interfaces and Abstract Classes being used for this assignment. I have omitted the UI generating

classes since most of the entire Swing package is being used for this purpose.


18

4.4 Database Structure.

Branch [ Branch_ID [PK] Branch_Location Branch_Phone ]

Section[ Section_ID [PK] Section_Name Section_Description Section_Branch_ID [FK: Branch -> Branch_ID] ]

Staff [ Staff_ID [PK] Staff_First_Name Staff_Last_Name Staff_Address Staff_Phone Staff_Mobile Staff_Section_ID [FK: Section -> Section_ID] ]

Supplier [ Supplier_ID [PK] Supplier_Name Supplier_Address Supplier_Phone Supplier_Mobile ]

Brand [ Brand_ID [PK] Brand_Name Brand_Supplier_ID [FK: Supplier -> Supplier_ID]]


19

Item [ Item_ID [PK] Item_Name Item_Description Item_Section_ID [FK: Section -> Section_ID] Item_Cost_Price Item_Sales_Price Item_Stock Item_Reorder_Level Item_Return_Period Item_Comment Item_Brand_ID [FK: Brand -> Brand_ID]]

Customer[ Customer_ID [PK] Customer_Name Customer_Address Customer_Phone Customer_Mobile Customer_Points_Earned Customer_Points_Spent]

Receipt[ Receipt_ID [PK] Receipt_Customer_ID [FK: Customer -> Customer_ID] Receipt_Payment_Mode Receipt_Timestamp Receipt_Value Receipt_Points_Reduced ]

Sale [ Sale_ID [PK] Sale_Item_ID [FK: Item -> Item_ID] Sale_Quantity Sale_Value Sale_Receipt_ID [FK: Receipt -> Receipt_ID] Sale_Status ]


20

User[ User_ID [PK] User_Username User_Password User_Staff_ID [FK: Staff -> Staff_ID] User_Access_Level User_Status]

Given above is the generic basic structure of the database I have used for this

particular assignment. I used the Pseudo Code notation to design the database as I

find it faster as well as easier to work with. Further, this could have easily been fed to

a SQL Code Generator program to generate the SQL commands to implement this

table structure in a database with minimum alterations and effort.

The actual Structured Query Language instructions used to create the database in a

MySQL database server that runs on my personal computer are also included in the

companion CD.


21

4.5 Object Sequence Diagrams.

Diagram 5. Sign In Sequence. This is the sequence diagram for signing in to the system with a

Username, Password, and Access Level.


22

Diagram 6. Sign-Out Sequence. This is the sequence diagram for signing out of the system.


23

Diagram 7. Manipulation of Staff Members Sequence. This is the sequence diagram for the

manipulation of Staff Member records. It shows adding, removing and viewing of these records.


24

Diagram 8. Manipulation of User Accounts Sequence. This is the sequence diagram for the

manipulation of System User records.


25

Diagram 9. Manipulation of Supplier Information Sequence. This is the sequence diagram of the

operations involving the manipulation of the Suppliers.


26

Diagram 10. Manipulation of Branches Sequence. This is the sequence diagram for the actions

involving the manipulation of the Branch records.


27

Diagram 11. Manipulation of the Staff Members Sequence. This is the sequence of manipulation

of the Staff Members by a Branch Manager.


28

Diagram 12. Manipulation of Sections Sequence. This is the sequence diagram of activities

involving the manipulation of the Sections by a Branch Manager.


29

Diagram 13. Manipulation of Product Items Sequence. This is the sequence diagram of the

activities involving the manipulation of Product Items by a Branch Manager.


30

Diagram 14. Manipulation of Customer Records Sequence. This is the sequence diagram of the

activities involving the manipulation of the Customer records by a Sales Assistant.


31

Diagram 15. Sale Transactions Sequence. This is the sequence diagram for the Sale transactions. It

starts off by creating a Receipt and adding only one Sale.


32

4.6 System Design Rationale.

4.6.1 Class Diagram Design.

In designing Class diagrams for this system, I have taken the approach of first

designing the classes with the basic notation. This makes it easier to get all the

classes in one screen and see their relationships and how they are formed. Once the

relationships are identified and added to the classes, the classes can be extended with

the extensive and troublesome details.

The complete and detailed design in the other hand if based on the basis found in the

previous basic diagram, only this time with added attributes, and methods to classes.

Every attribute is encapsulated with an accessor and a mutator. This gives universal

interfaces to the classes, leaving the internal structure open for tinkering.

Every class hoping to use the database to map themselves to a record in the database

can implement the interface DBAccess which is nothing but a collection of constant

variables providing the database Driver, URL, Username and Password that can be

used by the classes. This makes it easier to change the Database at will.

Every class that must be read or written to the database are provided with a common

set of four methods, one for adding a new record, one for loading a record from the

database and mapping it to the class attributes, one for updating the database record

by mapping attributes back to data items, and finally allowing a record to be removed

from the database. These methods make it very much easier in handling objects and

mapping them back and forth with their respective database records.

The classes are also categorized into two different package levels. The common

“com.uwic.walmart” package is used to put the entire code base of this application. A

sub-package of this “com.uwic.walmart.ui” is used to put in the few User Interface

template classes that are instantiated for UI generation.


33

4.6.2 Sequence Diagram Design.

The design of the sequence diagrams is carried out parallel to the design of the Class

diagram as well as the database structure. Though ideologically I could have drawn

each at their own time, I realized that to do them together is the best way to get the

little pieces of the system work perfectly well together to complete the system.

You may notice that most of the data manipulation sequence diagrams resemble each

other in a significant manner. In fact this is no coincidence since I intentionally made

sure that a consistent class structure would be used. This gives them all the same set

of methods that can be invoked the same way, thus making it easier for the developers

to use them classes later on without having to learn how each class would work. They

only have to learn one, and then apply to the rest of the classes the same sequence.

For the sales, I have used a transaction based entry, giving it a level of sophistication

that is useful in a actual sales management system. This was more like an

experimental feature that gave me an opportunity to try out something I haven't tried

before.

4.6.3 Database Structure Design.

Instead of using the boiler plated Entity-Relationship (ER) diagram for this purpose, I

took advantage of the flexibility of the Unified Process and took the opportunity to

explore a Pseudo Code based approach to structuring the database. I have in almost

all cases, a table in the database matching a class one-to-one. By using this methods,

I could easily change my design to suit the changes done in the Class level. This

flexibility was important since I was designing the Class diagrams, sequence diagrams

and the database incrementally and parallel to each other.


34

5. Test Plan and Test Reports.

5.1 Planned Test Cases.

Table 1. Test Cases. This table has 50 test cases that I have identified spreading over about 11 test

classes selected by analyzing the Use Cases. There is no end to what kind of tests could have been

performed over this system. This is just to demonstrate my understanding and approach to the task.

CaseID#

Test Case Test Data Expected Results

Class 1: Testing User Access Authentication.

01

Test if a user with a valid username and a password can sign-in to the system with proper access level.

Username {valid}

Password {valid}

Access Level {valid}

Complete the authentication process and sign-in to the system.

02

Test if a user with a valid username and an invalid password can sign-in to the system with proper access level.

Username {valid}

Password {invalid}


A sing-in error dialog must be displayed.

03

Test if a user with a valid username and a valid password can sign-in to the system with an improper access level.

Username {valid}

Password {valid}

Access Level {Invalid}

A sign-in error dialog must be displayed.

04

Test if a user with an invalid username and a valid password can sign-in to the system with a proper access level.

Username {invalid}

Password {valid}



05

Test if a user providing no username and no password can sign-in to the system with any access level.

Username {empty}

Password {empty}

Access Level {random}


Class 2: Testing Access Privileges During Sign-In Process.

06

Test if a user signed-in to the Administrator level is given administration level.

Username {valid}

Password {valid}

Access Level {admin}

User will be redirected to the administration main window.

07 Test if a user signed-in to the Manager level is given manager level.

Username {valid} User will be redirected to the manager main


35

Password {valid}

Access Level {manager}

window.

08

Test if a user signed-in to the Sales Assistant level is given sales assistant level.

Username {valid}

Password {valid}

Access Level {user}

User will be redirected to the sales main window.

Class 3: Testing Administration of Staff Members.

09 Test if a staff member record is properly displayed when the Staff ID is selected.

Staff ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the staff member of whom the Staff ID was used for the test.

10

Test if a staff member record is properly updated when the Staff ID is selected and valid data are provided and asked to update.

Staff ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Staff ID.

11

Test if a staff member record is actually removed when the Staff ID is selected as asked to be deleted.

Staff ID {valid}

Remove Button {click}

The record of the staff member referred to by the Staff ID should no longer be available.

12

Test if a new staff member can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Staff ID must be available in the Staff ID list.

13

Test if a new staff member can be added with invalid data.

New Button {click}

Some Fields {invalid}

Save Button {click}

The record should not be entered into the database and available with a Staff ID in the list.

Class 4: Testing Administration of System Users.

14

Test if a system user record is properly displayed when the User ID is selected.

User ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the user of whom the User ID was used for the test.

15

Test if a user record is properly updated when the User ID is selected and valid data are provided and asked to update.

User ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the User ID.

16 Test if a user record is actually removed when the User ID is selected as asked to be deleted.

User ID {valid}


The record of the user referred to by the User ID should no longer be


36

available.

17

Test if a new user can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new User ID must be available in the User ID list.

18

Test if a new user can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a User ID in the list.

Class 5: Testing Administration of Suppliers.

19

Test if a supplier record is properly displayed when the Supplier ID is selected.

Supplier ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the supplier of whom the Supplier ID was used for the test.

20

Test if a supplier record is properly updated when the Supplier ID is selected and valid data are provided and asked to update.

Supplier ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Supplier ID.

21

Test if a supplier record is actually removed when the Supplier ID is selected as asked to be deleted.

Supplier ID {valid}


The record of the supplier referred to by the Supplier ID should no longer be available.

22

Test if a new supplier can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Supplier ID must be available in the Supplier ID list.

23

Test if a new supplier can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Supplier ID in the list.

Class 6: Testing Administration of Branches.

24

Test if a branch record is properly displayed when the Branch ID is selected.

Branch ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the branch of which the Branch ID was used for the test.

25

Test if a branch record is properly updated when the Branch ID is selected and valid data are provided and asked to update.

Branch ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Branch ID.

26 Test if a branch record is actually removed when the Branch ID is selected

Branch ID {valid} The record of the branch referred to by


37

as asked to be deleted. Remove Button {click} the Branch ID should no longer be available.

27

Test if a new branch can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Branch ID must be available in the Branch ID list.

28

Test if a new branch can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Branch ID in the list.

Class 7: Testing Administration of Sections in Branches.

29

Test if a section record is properly displayed when the Section ID is selected.

Section ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the section of which the Section ID was used for the test.

30

Test if a section record is properly updated when the Section ID is selected and valid data are provided and asked to update.

Section ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Section ID.

31

Test if a section record is actually removed when the Section ID is selected as asked to be deleted.

Section ID {valid}


The record of the section referred to by the Section ID should no longer be available.

32

Test if a new section can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Section ID must be available in the Section ID list.

33

Test if a new section can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Section ID in the list.

Class 8: Testing Administration of Product Items available for Sale.

34

Test if a product record is properly displayed when the Item ID is selected.

Item ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the product of which the Item ID was used for the test.

35

Test if a product record is properly updated when the Item ID is selected and valid data are provided and asked to update.

Item ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Item ID.

36 Test if a product record is actually Item ID {valid} The record of the


38

removed when the Item ID is selected as asked to be deleted. Remove Button {click}

product referred to by the Item ID should no longer be available.

37

Test if a new product can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Item ID must be available in the Item ID list.

38

Test if a new product can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Item ID in the list.

Class 9: Testing Administration of Customer Records.

39

Test if a customer record is properly displayed when the Customer ID is selected.

Customer ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the customer of which the Customer ID was used for the test.

40

Test if a customer record is properly updated when the Customer ID is selected and valid data are provided and asked to update.

Customer ID {valid}

All Fields {valid}

Save Button {click}

The new values in the fields will be stored updating the record referred to by the Customer ID.

41

Test if a customer record is actually removed when the Customer ID is selected as asked to be deleted.

Customer ID {valid}


The record of the customer referred to by the Customer ID should no longer be available.

42

Test if a new customer can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Customer ID must be available in the Customer ID list.

43

Test if a new customer can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Customer ID in the list.

Class 10: Testing Administration of the Sales Transactions.

44

Test if a transaction record is properly displayed when the Transaction ID is selected.

Transaction ID {valid}

View Button {click}

The fields on the screen must be populated with the data of the transaction of which the Transaction ID was used for the test.

45 Test if a transaction record is properly updated when the Transaction ID is selected and valid data are provided and asked to update.


All Fields {valid}

The new values in the fields will be stored updating the record referred to by the


39

Save Button {click} Transaction ID.

46

Test if a transaction record is actually removed when the Transaction ID is selected as asked to be deleted.



The record of the transaction referred to by the Transaction ID should no longer be available.

47

Test if a new transaction can be added with valid data.

New Button {click}

All Fields {valid}

Save Button {click}

A new record with a new Transaction ID must be available in the Transaction table list.

48

Test if a new transaction can be added with invalid data.

New Button {click}


Save Button {click}

The record should not be entered into the database and available with a Transaction ID in the list.

Class 11: Testing of the User Interfaces.

49Test if all the command buttons respond to mouse clicks.

All Buttons {click} The buttons should respond by carrying out the intended tasks.

50

Test if the menu items in the menu bar respond properly to mouse clicks.

Menu Items {click} The menu items should respond properly carrying out the intended tasks.

5.2 Testing Rationale.

The beauty of the Unified Process is that it not only focuses on risks, it also takes an

approach of testing software with rigor through out the development process. I have

the following testing methods to ensure that the software I am developing is of

standard and can be used to cover the assignment specification.

1. Testing of the Use Cases – after the identification of the use cases by reading

the assignment specification provided to me, I realized that it is best if I put

my uses cases to a simple test. I took assistance of an individual who has no

idea about this assignment, not that much thorough with the software

development processes, but has a general understanding of how to use a


40

computer software to get some routine work done. This person could provide

the intellectual balance needed in this task. The test was simple. All that was

done was allowing that person to read the assignment a few times. Then I

used by Use Cases to explain what they system does. He compared his

understanding of the scenario with what I explained to see if there are any

mismatches. This early heads on approach helped me find out some missing

edges on my Use Cases and complete them.

2. Testing of the Conceptual Diagrams – after completion of the class diagrams

and sequence diagrams checking up continuously with the use cases

generated, I have run a number of imaginary sequences using rough paper and

pencils to see how each and every class would interact, how and when objects

will be created, destroyed, how alternate paths can be used and their effect

compared to the effects predicted by the sequence diagrams. These exercises

proved to be more useful than I expected them to be. Though I could not find

any substantial errors that needed to be corrected, I was able to integrate these

conceptual items in a number of ways to see which fits best together and

which does not. This understanding allowed me to proceed to the

development phase with a better understanding of the system as well as the

design.

3. Unit Testing of the System – given that this is an object oriented program

developed using Java as the programming language, the word “unit” can refer

to both classes as well as methods. In either case, methods provide the

functionalities of a class. Therefore to test methods of a class is to test the

class itself as a unit. Through out the development process, methods have

been tested with an approach of certain rigor by making sure that all known

exceptional situations are handled properly. In the case of possible unseen

exceptional situations, and exceptions that have almost zero probability, they

have been handled at least not to crash the system. All parameters are tested to

validity before being either used or assigned to internal calculations of a class.

All arguments passed are suspected of invalidity at all times and kept on a

tight leash to make sure that no mishaps happen. All attributes are kept private


41

to the classes, and accessors and mutators are used to manipulate them.

Except for a selected set of public interfaces in the form of methods, the rest of

the workings of the class are always kept encapsulated behind the class scope.

4. Integrated Testing of the Components – the components of this program can

be classes, their objects, or methods when they are being called upon for

service. I have started integration testing from the design phase itself by

putting sequence diagrams into role play to see how they fit and interact. Since

public interfaces of the classes participating in this program are well identified

and designed to be consistent through out the application, integration testing at

the coding level has also not been that difficult. In fact, the OOP concepts

facilitate conducting integrated testing to a certain extent with public

interfaces without having to fully implement all units. Ass long as messages

are available to be passed, lest they be pseudo or dummy, it would still be

useful in conducting testing. I simply started with a skeletal structure of the

entire class hierarchy with dummy procedures and dummy messages, and then

put the whole system to work together. Then one by one at a time, I kept on

implementing each unit at a time, letting them test themselves through the

integration. As incremental iterations continued, at one step I ended up

actually implementing all units of the system.

5. System Level Testing – this usually is the most popular and tangible form of

testing that can be carried out on software. I have taken the black box

approach though I am the developer, to assume the role of external tester. The

above test plan with 50 selected test cases spanning through out 11 classes of

tests is prepared for this purpose. All above classes were carefully selected to

reflect the requirements specified in the assignment and as identified and

documented in the Use Cases. But the test cases can be numerous and there is

no way all of them can be covered within the given constraints. Therefore the

following test report randomly picks 10 out of the above 50 test cases to

demonstrate my understanding of carrying out a test procedure and

documenting it.


42

5.3 Selection of Test Data.

Table 2. Test Data Set. These are the test data sets used to conduct testing procedures for a selected

set of Use Cases out of the above 50 use cases in the test plan.

CaseID#

Test Data Set

02Username = “sandeep”Password = “pa55”Access Level = “Manager”

03Username = “rajiv”Password = “123”Access Level = “Sales Assistant”

09 Staff ID = “1”

17

Username = “dilu”Password = “ab123”Confirm Password = “ab123”Staff ID = “1”Access Level = “Manager”Authorized = checked

21 Supplier ID = “3”

34 Item ID = “2”

37

Product Name = “Prod XYZ”Description = “A testing product of XYZ”Purchase Price = “450.00”Sales Price = “500.00”Stock = “1000”Reorder Level = “100”Return Allowed = checkedPeriod = “3”Section ID = “2”Brand ID = “4”Comment = “Not much of a useful comment!”

43

Name = “Mythily Bala”Address = “Wellawatta, Colombo 6.”Phone = “+94114738928”Mobile = “+947747383g8”Points Earned = “1000”Points Spent = “100”

44 Transaction ID = “1”

47

Customer ID = “1”Payment Method = “Cash”Item Code = “2”Quantity = “100”Item Code = “3”Quantity = “5”


43

5.4 System Test Case Results.

Table 3. Test Result – Case ID #02

Case ID # 02

Test Class 01: Testing User Access Authentication.

Test Case Test if a user with a valid username and an invalid password can sign-in to the system with proper access level.

Description Providing proper authentication procedures is a key to the requirements of this system. We have identified even during the Use Case generation that Sign-In and Sign-Out features must be provided for the proposed system. In most cases users may remember their username, but easily forget their password. In such as case, the user must be restrained from using the system until a new password is assigned by an administrator. This will ensure that no unauthorized user will be able to gain access to the system to cause any kind of harm.

Test Data Username = “sandeep”Password = “pa55”Access Level = “Manager”

Prerequisites The application should be running and no other user is already signed in to the system.

Steps 1. Enter the “sandeep” as the Username to the text field.2. Enter “pa55” as the Password to the password field.3. Select “manager” as the Access Level from the combo box.4. Click “Sign In” button.

Expected Result A Sign In Error Dialog must be displayed.

Actual Result A Sign In Error Dialog was displayed.

Status SUCCESSFUL

Screen Grab


44


Case ID # 03

Test Class 01: Testing User Access Authentication.

Test Case Test if a user with a valid username and a valid password can sign-in to the system with an improper access level.

Description The access levels play a major role in an information based system. In this system, some users such as administrators have higher control over system compared to the general sales assistant staff. It is important that a user is never granted a higher level of access than that which is granted to him. It would reduce the risk factors involving data corruption and unfortunate accidents by a significant ratio.

Test Data Username = “rajiv”Password = “123”Access Level = “Sales Assistant”

Prerequisites The application must be running and no other user must be signed in already.

Steps 1. Enter “rajiv” as the Username in the text field.2. Enter “123” as the Password in the password field.3. Select “Sales Assistant” as the Access Level from the combo box.4. Click “Sign In” button.

Expected Result A Sign In Error Dialog must be displayed.

Actual Result A Sign In Error Dialog was displayed.

Status SUCCESSFUL

Screen Grab


45


Case ID # 09

Test Class 01: Testing Administration of Staff Members.

Test Case Test if a staff member record is properly displayed when the Staff ID is selected.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Staff Members in important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Staff Members, but also on other classes that rely on the same set of operations.

Test Data Staff ID = “1”

Prerequisites The system should already be running with someone signed in as the administrator. A record for the user ID should be availabe in the database.

Steps 1. Select “1” as the Staff ID from the combo box.2. Click “View” button.

Expected Result The fields on the screen must be populated with the data of the staff member of whom the Staff ID was used for the test.

Actual Result The fields on the screen were populated with the data of the staff member of whom the Staff ID was used for the test.

Status SUCCESSFUL

Screen Grab


46


Case ID # 17

Test Class 01: Testing Administration of System Users.

Test Case Test if a new user can be added with valid data.

Description Once again, not only having authentication is going to be enough if we cannot grant them properly. This is ensured by management of user accounts, with usernames and passwords. We are going to insert some valid data and see if we can actually create these permitted users.

Test Data Username = “dilu”Password = “ab123”Confirm Password = “ab123”Staff ID = “1”Access Level = “Manager”Authorized = checked

Prerequisites The system should already be running with someone signed in as the administrator. A record for the user ID should be availabe in the database.

Steps 1. Click “New” button.2. Enter “dilu” as the Username in the text field.3. Enter “ab123” as the Password in the password field.4. Enter “ab123” as the Confirm Password in the the password field.5. Enter “1” as the Staff ID in the text field.6. Select “Manager” as Access Level from the combo box.7. Set Authorization to check.8. Click “Save” button.9. Select the newly added User ID from the combo box.10. Click “View” to confirm that the record was added successfully.

Expected Result A new record with a new User ID must be available in the User ID list.

Actual Result A new record with a new User ID was available in the User ID list.

Status SUCCESSFUL

Screen Grab


47


Case ID # 21

Test Class 01: Testing Administration of Suppliers.

Test Case Test if a supplier record is actually removed when the Supplier ID is selected and asked to be deleted.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Suppliers is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Suppliers, but also on other classes that rely on the same set of operations.

Test Data Supplier ID = “3”

Prerequisites The system should already be running with someone signed in as the administrator. A record for the supplier ID should be available in the database.

Steps 1. Select “3” as the Supplier ID from the combo box.2. Click “View” button.3. If the right one is found, click “Remove” button.

Expected Result The record of the supplier referred to by the Supplier ID should no longer be available.

Actual Result The record of the supplier referred to by the Supplier ID was no longer available.

Status SUCCESSFUL

Screen Grab N/A


48


Case ID # 34

Test Class 01: Testing Administration of Product Items.

Test Case Test if a product record is properly displayed when the Item ID is selected.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Product Items is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Product Items, but also on other classes that rely on the same set of operations.

Test Data Item ID = “2”

Prerequisites The system should already be running with someone signed in as the manager. A record for the Item ID should be available in the database.

Steps 1. Select “2” as the Item ID from the combo box.2. Click “View” button.

Expected Result The fields on the screen must be populated with the data of the product of which the Item ID was used for the test.

Actual Result The fields on the screen were populated with the data of the product of which the Item ID was used for the test.

Status SUCCESSFUL

Screen Grab


49


Case ID # 37

Test Class 01: Testing Administration of Product Items.

Test Case Test if a new product can be added with valid data.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Product Items is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Product Items, but also on other classes that rely on the same set of operations.

Test Data Product Name = “Prod XYZ”Description = “A testing product of XYZ”Purchase Price = “450.00”Sales Price = “500.00”Stock = “1000”Reorder Level = “100”Return Allowed = checkedPeriod = “3”Section ID = “2”Brand ID = “4”Comment = “Not much of a useful comment!”

Prerequisites The system should already be running with someone signed in as the manager. A record for the Item ID should be available in the database.

Steps 1. Click “New” button.2. Enter the test data into relevant input fields.3. Click “Save” button.4. Select the new Item ID from the combo box.5. Click “View” to confirm.

Expected Result A new record with a new Item ID must be available in the Item ID list.

Actual Result A new record with a new Item ID was available in the Item ID list.

Status SUCCESSFUL

Screen Grab


50


Case ID # 43

Test Class 01: Testing Administration of Customers.

Test Case Test if a new customer can be added with invalid data.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Customers is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Customers, but also on other classes that rely on the same set of operations.

Test Data Name = “Mythily Bala”Address = “Wellawatta, Colombo 6.”Phone = “+94114738928”Mobile = “+947747383g8”Points Earned = “1000”Points Spent = “100”

Prerequisites The system should already be running with someone signed in as the sales assistant.

Steps 1. Click “New” button.2. Enter test data into relevant input fields.3. Click “Save” button.

Expected Result The record should not be entered into the database and available with a Customer ID in the list.

Actual Result The record was not entered into the database and available with a Customer ID in the list.

Status SUCCESSFUL

Screen Grab N/A


51


Case ID # 44

Test Class Testing Administration of Sales Transactions.

Test Case Test if a transaction record is properly displayed when the Transaction ID is selected.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Transaction is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Transaction, but also on other classes that rely on the same set of operations.

Test Data Transaction ID = “1”

Prerequisites The system should already be running with someone signed in as the sales assistant. A record with the Transaction ID set to “1” must also be availabe in the database.

Steps 1. Select the row with the Transaction ID “1” from the table.2. Click “View” button.

Expected Result The fields on the screen must be populated with the data of the transaction of which the Transaction ID was used for the test.

Actual Result The fields on the screen were populated with the data of the transaction of which the Transaction ID was used for the test.

Status SUCCESSFUL

Screen Grab


52


Case ID # 47

Test Class Testing Administration of Sales Transactions.

Test Case Test if a new transaction can be added with valid data.

Description As we have identified during the Use Case generation and requirements analysis, maintenance and manipulation of the data related to Transaction is important. All classes in this application use the same pattern of interfaces to manipulate themselves. Therefore this is not just a test on Transaction, but also on other classes that rely on the same set of operations.

Test Data Customer ID = “1”Payment Method = “Cash”Item Code = “2”Quantity = “100”Item Code = “3”Quantity = “5”

Prerequisites The system should already be running with someone signed in as the sales assistant.

Steps 1. Click “Transaction” button.2. Enter test data into proper input fields.3. Click “Complete” Button.4. Check the new Transaction from the Transactions Table.

Expected Result A new record with a new Transaction ID must be available in the Transaction table list.

Actual Result A new record with a new Transaction ID was available in the Transaction table list.

Status SUCCESSFUL

Screen Grab Prior to Completion.


53

Post Completion.

5.5 Test Result Summary.

Table 13. Test Result Summary. This is a summary of the results gained after conducting tests to

check the validity of the system developed.

CaseID#

Status Note

02 SUCCESSFUL N/A

03 SUCCESSFUL N/A

09 SUCCESSFUL N/A

17 SUCCESSFUL N/A

21 SUCCESSFUL N/A

34 SUCCESSFUL N/A

37 SUCCESSFUL N/A

43 SUCCESSFUL N/A


54

44 SUCCESSFUL N/A

47 SUCCESSFUL N/A

Summary

The system reached a 100% success rate on the tests conducted, which is simply impossible if it was tested more rigorously. Since these tests were conducted to demonstrate the level of understanding on how tests can be conducted, I will leave this result as it is.

5.6 Test Conclusion.

I laid out about 50 test cases, which is a mere fraction of the test cases that can be

identified for this software application. I broke them down to the most obvious 11

test classes, which once again could have been an extensive. If I were to at least

conduct all these 50 tests and insert the results in this document, the report would

have been as twice as heavier and bulkier. Therefore I made a judgment and picked

10 prominent test cases spread among the identified test classes to demonstrate my

knowledge and understanding of carrying out testing and putting them in a document

properly. The results turned out to be 100% successful which is not a possibility in a

real world application. In my opinion, the cases were the most obvious ones and

hence they were considerably weak. But once again I believe that this level is suffice

to convince my understanding of the process of software development.


55

6. Future Recommendations.

There are a number areas in which this software application can be improved. I have

left some of these to a future version because some of them would consume more

time and effort than what its worth. Some of them will require specific technical

knowledge in implementation process. I have give them as bellow.

1. Remove access level field from the sign-in form and automatically select the

appropriate level of access granted with the aid of the user account

information.

2. Allow the user to select the location of the database server instead of always

using the local server run on localhost.

3. Integrate better response dialog methods to indicate errors and system

anomalies rather than ignoring them.

4. Maintain a log of every event taken place within the system, thus allowing a

full traceback in case of an emergency.

5. Enforce a security policy for valid usernames and passwords rather than

allowing any username or password that is not empty to be used.

6. Refine the User Interface to give the system a more appealing look and feel as

well as the make the use of the system effective, such as auto focusing the

most appropriate input fields.

7. Only if deemed necessary, adapt a new color scheme for the application to

increase user satisfaction.

8. Provide a context sensitive help facility to aid users when ever they need

within the system itself.

9. More testing should be carried out to rigorously check for the errors in the

system.

10. Instead of ignoring most of the Exceptional situations, they must be handled in

a graceful manner.


56

7. Conclusion.

This module, as well as this assignment had been a wonderful learning experience. I

gained a lot of knowledge about the Unified Process, and how it can be adapted to a

small scale software development project. I found out that sometimes applying theory

in to practice as issues, and to over come them is to learn something new with the

experience. In conclusion, I have developed a software based Sales management

application for the Walmart Supermarket Chain. The system may need a lot of

refinements and tweaks to even remotely resemble an industry strength application.

Instead this was an attempt to understand and learn the concepts of Object Oriented

Programming and software development, and I think I succeeded in that regard.


57

8. References.

Japenga, R., Unknown. How to Write a Great Software Test Plan. [online] Available

at: <http://www.microtoolsinc.com/howstp.php> [Accessed 18 August 2011].

Oracle, Unknown. How to Use Tables. [online] Available at:

<http://download.oracle.com/javase/tutorial/uiswing/components/table.html>

[Accessed 10 August 2011].

Regular-Expressions, 2009. Regular Expression Basic Syntax Reference. [online]

Available at: <http://www.regular-expressions.info/reference.html> [Accessed 10

August 2011]

MySQL, Unknown. SQL Statement Syntax. [online] Available at:

<http://dev.mysql.com/doc/refman/5.5/en/sql-syntax.html> [Accessed 12 August

2011]

Robbins, J., Unknown. Test Case Format. [online] Available at:

<http://readyset.tigris.org/nonav/templates/test-case-format.html> [Accessed 11

August 2011]

Sommerville, I., 2008. The Structure of a Test Plan. [online] Available at:

<http://www.cs.st-

andrews.ac.uk/~ifs/Books/SE9/Web/Testing/TestPlanStructure.html> [Accessed 15

August 2011]

EDraw Soft, Unknown. UML Package Diagrams. [online] Available at:

<http://www.edrawsoft.com/uml-package.php> [Accessed 10 August 2011]


http://www.microtoolsinc.com/howstp.php

http://www.edrawsoft.com/uml-package.php

http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/Testing/TestPlanStructure.html

http://www.cs.st-andrews.ac.uk/~ifs/Books/SE9/Web/Testing/TestPlanStructure.html

http://readyset.tigris.org/nonav/templates/test-case-format.html

http://dev.mysql.com/doc/refman/5.5/en/sql-syntax.html

http://www.regular-expressions.info/reference.html

http://download.oracle.com/javase/tutorial/uiswing/components/table.html

58

Agile Modeling, 2009. UML 2 Sequence Diagramming Guidelines. [online] Available

at: <http://www.agilemodeling.com/style/sequenceDiagram.htm> [Accessed 10

August 2011]

Agile Modeling, 2010. UML 2 Class Diagrams. [online] Available at:

<http://www.agilemodeling.com/artifacts/classDiagram.htm> [Accessed 10 August

2011]

Agile Modeling, 2009. UML 2 Use Case Diagramming Guidelines. [online] Available

at: <http://www.agilemodeling.com/style/useCaseDiagram.htm> [Accessed 10 August

2011]

Java2S, 2009. JDBC Transaction. [online] Available at:

<http://www.java2s.com/Code/Java/Database-SQL-JDBC/JDBCTransaction.htm>

[Accessed 15 August 2011]

JavaDB, 2011. Using a Database Transaction with JDBC. [online] Available at:

<http://www.javadb.com/using-database-transaction-with-jdbc> [Accessed 16 August

2011]


http://www.javadb.com/using-database-transaction-with-jdbc

http://www.java2s.com/Code/Java/Database-SQL-JDBC/JDBCTransaction.htm

http://www.agilemodeling.com/style/useCaseDiagram.htm

http://www.agilemodeling.com/artifacts/classDiagram.htm

http://www.agilemodeling.com/style/sequenceDiagram.htm

Documents

Main Report