Applied Software Engineering Assignment

21004229

Applied Software Engineering Assignment

May 2010

Applied Software Engineering 21004229

2

Contents

Abstract .............................................................................................................................................................. 6

Introduction ........................................................................................................................................................ 6

1. Reverse Engineering and Software Design ................................................................................................... 6

2. Requirements Analysis .................................................................................................................................. 7

2.1 System Requirements .............................................................................................................................. 7

2.1.1 Start Game ........................................................................................................................................ 7

2.1.2 Purchase Property ............................................................................................................................. 7

2.1.3. Buy House ........................................................................................................................................ 7

2.1.4. Purchase Utility ................................................................................................................................. 7

2.1.5. Purchase Rail Road .......................................................................................................................... 7

2.1.6. Go to Jail ........................................................................................................................................... 8

2.1.7. Get Out of Jail ................................................................................................................................... 8

2.1.8. Free Parking ..................................................................................................................................... 8

2.1.9. Pass Go ............................................................................................................................................ 8

2.1.10. Draw Card ....................................................................................................................................... 8

2.1.11. Trade Purchase .............................................................................................................................. 8

2.1.12. Pay Rent ......................................................................................................................................... 8

2.1.13. Buy House ...................................................................................................................................... 9

2.2 Use Case Diagram ................................................................................................................................... 9

2.2.1 Use Case Diagram Design Rationale ................................................................................................ 9

2.3 Class Diagram ........................................................................................................................................ 10

2.3.1 Class Inheritance ............................................................................................................................. 11

2.4 State Diagram......................................................................................................................................... 13

3. Re-engineering Process .............................................................................................................................. 16

3.1 Test Driven Design ................................................................................................................................. 16

3.2 Test Plan ................................................................................................................................................ 16

3.3 Underlying Bug ....................................................................................................................................... 17

3.4 Incomplete Methods and Unit Tests ....................................................................................................... 17

3.4.1 RailRoad.java .................................................................................................................................. 17

3.4.2 DieTest.java ..................................................................................................................................... 18

3.4.2 CardTest.java .................................................................................................................................. 19

3.4.3 GameMasterTestManualProcess.java Incomplete Test .................................................................. 20

3.4.4 LoseMoneyCardTest.java ................................................................................................................ 22

3.4.5 PlayerTest.java ................................................................................................................................ 23

3.4.6 SquareInfoFormatterTest.java ......................................................................................................... 24

3.5 Acceptance Testing ................................................................................................................................ 25

4. Software Quality ........................................................................................................................................... 27


3

5. Critique ......................................................................................................................................................... 28

5.1 Effectiveness of Test Driven Development ............................................................................................ 28

5.2 Review .................................................................................................................................................... 28

5.3 Recommendations ................................................................................................................................. 30

References ....................................................................................................................................................... 31

Appendix .......................................................................................................................................................... 31

Figures

Figure 1: Use Case Diagram ............................................................................................................................. 9 Figure 2: Purchase Item Use Case .................................................................................................................. 10 Figure 3: Go To Jail.......................................................................................................................................... 10 Figure 4: Draw Card ......................................................................................................................................... 10 Figure 5: Class Diagram .................................................................................................................................. 11 Figure 6: Class Inheritance .............................................................................................................................. 12 Figure 7: Inheritance Source Code .................................................................................................................. 12 Figure 8: Inheritance Source Code .................................................................................................................. 13 Figure 9: Inheritance ........................................................................................................................................ 13 Figure 10: Sate Diagram .................................................................................................................................. 14 Figure 11: Underlying Bug ............................................................................................................................... 17 Figure 12: Die Unit Test ................................................................................................................................... 18 Figure 13: Test Failure ..................................................................................................................................... 18 Figure 14: Test Pass ........................................................................................................................................ 18 Figure 15: Test Fail .......................................................................................................................................... 19 Figure 16: Test Pass ........................................................................................................................................ 20 Figure 17: Test Fail .......................................................................................................................................... 21 Figure 18: Test Fail .......................................................................................................................................... 21 Figure 19: Test Pass ........................................................................................................................................ 22 Figure 20: Test Pass ........................................................................................................................................ 22 Figure 21: Test Fail .......................................................................................................................................... 23 Figure 22: Test Pass ........................................................................................................................................ 23 Figure 23 .......................................................................................................................................................... 24 Figure 24: Test Pass ........................................................................................................................................ 25 Figure 25: Purchase Property Error ................................................................................................................. 26 Figure 26 .......................................................................................................................................................... 26 Figure 27 .......................................................................................................................................................... 27 Figure 28 .......................................................................................................................................................... 29 Figure 29 .......................................................................................................................................................... 29


4


5


6

Abstract This document entails the reverse and re-engineering processes undertaken in the analysis of a Java application program based on the board game Monopoly.

Introduction Reverse engineering and re-engineering a piece of software involves a number of different processes; this document outlines some of the processes undertaken in this process related to the Java program created. The following document will include: Reverse engineering process:

• Eliciting of user requirements • Creation of a use case diagram based on the requirements identifying the actions a user goes

through in playing the Monopoly game: MiniMono • A class diagram outlining the overall system structure and interaction • A state diagram identifying the various states the system returns and system behaviour

Re-engineering process:

• Using Test Driven Design (TDD) techniques complete identified incomplete methods and unit tests within the application

• Production of a test plan for the complete application including black, white and grey box testing • Implementation of acceptance tests based on the Framework for Integrated Testing (FIT) framework

An analysis of all of the techniques identified above, a discussion of the metrics involved in monitoring the quality of the software produced and a personal critique of work completed in the report will be apparent in the document.

1. Reverse Engineering and Software Design According to Pressman (2005) reverse engineering was originally used in the business world to disassemble a piece of hardware that a competitor had produced in order to gain an understanding of how it worked based on the design specifications. Similarly with software reverse engineering, a program that is owned and therefore does not have a design specification, is analysed to produce a high level representation of the system rather than just the programming code itself; the process aims to gather data, system architecture and the procedures involved in designing the system (Pressman, 2005). Sommerville (2007, p502) indicates that reverse engineering aids in the documentation of how the software is organised and its functionality. The process aims to extract software design data from low level source code and at the abstraction level of the process, quality of the software designed and sophistication of the software is established using specific tools (Pressman, 2005). Pressman (2005) further iterates that at the abstraction level of the reverse engineering process high-level representation of the software designed can be produced. This will entail:

• Identification of software design procedures • The structure of the program produced • Object models • UML class, state and use case diagrams


7

In relating the information acquired to the MiniMono assignment, the reverse engineering process involved the identification of how the software was designed by ascertaining the original user requirements and representing them using a use case diagram, software structure using a class diagram and software procedures or behaviour using a state diagram. These procedures have all assisted in acquiring an idea of how the MiniMono system was originally designed, from purely looking at the low-level source coding and system interface.

2. Requirements Analysis In order to gain a perspective of what the user requires of a system prior to implementation it is necessary to formulate a requirements list from which user stories can be acquired.

2.1 System Requirements

Prior to producing a use case diagram related to the system it was necessary to produce a list of requirements representing exactly what the user required of the software. The following requirements were elicited after reverse engineering the MiniMono Java program.

2.1.1 Start Game

1.1 The user shall be able to enter the required number of players into the first input box Where t is the number of players entered in 1:

1.2 User t shall be able to enter their name in to the second input box Where n is the user name and p is property colour:

2.1.2 Purchase Property

2.1 User n shall be able to click ‘Roll Dice’ 2.2 User n shall be informed of the numbers that the die returned and then click OK 2.3 User n shall be able to purchase property p 2.4 User n shall be able to end turn

2.1.3. Buy House 3.1 User n shall be able to click ‘Roll Dice’ 3.2 Where n is the user name and u is utility purchased:

2.1.4. Purchase Utility

4.1 User n shall be able to click ‘Roll Dice’ 4.2 User n shall be informed of the numbers that the die returned and then click OK 4.3 User n shall be able to purchase utility u 4.4 User n shall be able to end turn

Where n is the user name and r is rail road purchased:

2.1.5. Purchase Rail Road

5.1 User n shall be able to click ‘Roll Dice’ 5.2 User n shall be informed of the numbers that the die returned and then click OK 5.3 User n shall be able to purchase rail road r


8

5.4 User n shall be able to end turn Where n is the user name:

2.1.6. Go to Jail

6.1 User n shall be able to click ‘Roll Dice’ 6.2 User n shall Go to Jail 6.3 User n shall be able to end turn

2.1.7. Get Out of Jail

7.1 User n shall be positioned on Jail square 7.2 User n shall be able to click Get Out of Jail 7.3 User n shall pay £50 7.4 User n shall be able to click ‘Roll Dice’

2.1.8. Free Parking

8.1 User n shall be able to click ‘Roll Dice’ 8.2 User n shall land on free parking square 8.3 User n shall be able to end turn

2.1.9. Pass Go

9.1 User n shall be able to click ‘Roll Dice’ 9.2 User n shall land on ‘Go’ square 9.3 User n shall receive £200 9.4 User n shall be able to click end turn

Where n is the user name and c is the card drawn:

2.1.10. Draw Card 10.1 User n shall be able to click ‘Roll Dice’ 10.2 User n shall draw c card 10.2.1 User n shall receive £50 10.2.2 User n shall lose £50 10.3 User n shall be able to end turn

Where n is the user name, £ is money received and i is the item purchased:

2.1.11. Trade Purchase 11.1 User n shall be able to click ‘Trade’ 11.2 User n1 shall be able to trade i with user n2 11.3 User n1 shall receive £ from user n2 11.4 User n shall be able to click ‘Roll Dice’ Where n is the user name and i is the item purchased:

2.1.12. Pay Rent

12.1 User n shall be able to click ‘Role Dice’ 12.2 User n1 shall land on n2 owned square 12.3 User n1 shall pay n2 rent 12.4 User n2 shall receive rent from user n1


9

12.5 User n shall be able to end turn

2.1.13. Buy House 13.1 User n shall buy house for owned property square 13.2 User n shall be able to click ‘Role Dice’

2.2 Use Case Diagram

Use cases are utilised to provide a scenario-based representation of the requirements that have been elicited in relation to a proposed project, and according to Sommerville (2007) use cases portray the interactions between users and the system; in this case the interactions between the player and the MiniMono Java program. Each use case is a symbol of a specific interaction between the system and its user (Sommerville, 2007, p155). Using the requirements in 2.1 the following use case diagram was produced. Each requirement symbolises a use case in the diagram and the subsequent interactions:

Figure 1: Use Case Diagram

2.2.1 Use Case Diagram Design Rationale

As mentioned in 2.2, each use case represents a requirement formulated in 2.1, and each use case represents an interaction between the user and the system. For example the use case Enter Info includes two use cases which are Num Players and Enter Name; this interaction enables the game to start. Figure 1 displays direct interaction of the player with the system when a few interactions are concerned i.e. Enter Info, Buy House, Draw Card and Start Game. The Start Game use case, however, is the focal point of the system due to all interactions subsequently occurring after this use case has been completed; this is demonstrated by the Extends use cases in Figure 1. After the Start Game interaction has occurred the player can then take a turn and subsequently purchase an item, pass go, go to jail and so on.


10

A number of the extends use cases also have extended interactions of their own i.e. the Purchase Item use case leads to the purchase of either a Rail Road, Utility or Property, and these use cases then result in the user interaction of trading the item that has been purchased, represented by the extended use case Trade Purchase.

Figure 2: Purchase Item Use Case

This is similar for the Go To Jail use case; the Go To Jail use case then results in the interaction of the user with the system to get out of jail, which includes the user having to pay a fine of £50, symbolised by the extended use case Get Out Of Jail and the use case Pay £50 that has been included.

Figure 3: Go To Jail

This is likewise similar for Draw Card which demonstrates that when a card is drawn i.e. Community Chest or Chance card the player either loses or receives £50 according to the card that has been drawn, as displayed in Figure *:

Figure 4: Draw Card

2.3 Class Diagram

According to Sun and Wong (2005) class diagrams describe the relationships, inheritance, associations and general dependancies between the classes within a piece of software of program. Sun and Wong (2005) further iterate the fact that in identifying the aforementioned criteria a representation of the static structure of a system can be achieved and assist in the modelling and overall understanding of a system when producing a class diagram in the reverse engineering process. Figure 5 is the class diagram produced in the reverse engineering process relating to the MiniMono Java program:


11

Figure 5: Class Diagram

The class diagram was produced by analysing the source code of the entire MiniMono application and identifying all the classes created, attributes within in each class, methods that each class was involved in and relationships between classes. Each class in the diagram represents a class identified in the source code.

2.3.1 Class Inheritance

For example the class Square is an example of an abstract class that contains abstract methods; abstract methods are empty and therefore Square requires subclasses to implement the methods for it. This is signified by the class Square inheriting the subclasses as displayed in Figure *


12

= Inheritance

Figure 6: Class Inheritance

The source code identified relating to Figure 1 is a follows :

Class: Square

public abstract class Square { private boolean available = true;

private String name; protected Player owner;

public String getName() { return name; }

public Player getOwner() { return owner; }

public int getPrice() { return 0; }

public boolean isAvailable() { return available; }

} ...continue for all abstract methods in the class Square

Figure 7: Inheritance Source Code

It is possible to see in Figure * that the class has methods that are not doing anything. The code in Figure * shows how the Square class and Property sub-class displayed in Figure * are associated:


13

Class: Property

public class PropertySquare extends Square { }

Class: Go

public class GoSquare extends Square { }

Class: RailRoad

public class RailRoadSquare extends Square { }

Class: Jail

public class JailSquare extends Square { }

...continue for all inherited subclasses according to Figure *

Figure 8: Inheritance Source Code

It is possible to see that the two are linked via the ‘extends Square‘ part of the coding linking the two classes together therefore enabling the inheritance represented in the class diagram. This applies to all of the Square classes i.e. GoToJailSquare etc and the coding is the same. The same applies for the Card class as represented in Figure *

Figure 9: Inheritance

2.4 State Diagram

According to Pressman (2007) a state diagram is a behavioural model that represents the transition between different states and the triggers that initiate the changes of state. Figure * is the state diagram produced for the MiniMono project and it displays a player turn in which the player decides to buy something on the Monopoly board. Each state is represented by a yellow box and an arrow represents the transition from one state to another and upon each arrow is the trigger that initiates the transition (Pressman, 2007, p250).


14

Figure 10: Sate Diagram

From the diagram it is possible to see that the following state transitions and subsequent triggers have taken place:

State 1: Before Move Player Trigger: Player t is idle

State 2: Move Player Trigger: Player rolls dice and moves player

State 3: End Turn Trigger: Player decides not to purchase a property

Precondition: Player is not bankrupt State 4.1: Has Money


15

Precondition: The utility is available to buy State 4.2: Buy Utility

Trigger: Player purchases utility

Precondition: The property is available to buy State 4.3: Buy Property

Trigger: Player purchases property

Precondition: The rail road is available to buy State 4.4: Buy RailRoad

Trigger: Player purchases Rail Road

Precondition: Player has purchased a property State 5: Buy House

Trigger: Player purchases a house for a property bought

State 6: End Turn Trigger 6.1: Utility is purchased

Trigger 6.2: Property is purchased Trigger 6.3: RailRoad is purchased Trigger 6.4: House is purchased


16

3. Re-engineering Process

3.1 Test Driven Design Mattu and Shankar (2007) indicate that the Test Driven Design (TDD) approach involves writing tests before any code has been written and the testing phase is employed at the start of the project instead of at the end. It is an iterative process in which small tests are created for small pieces of functional code; the code is rapidly fixed according to the tests that have been produced in a process that is known as refactoring (Mattu and Shankar, 2007). Essentially, a test is produced, a piece of code is written and the test is then used to verify if the code works or not. This cycle continues until the code is written and tested to completion.

According to Mattu and Fraser (2007) the TDD approach produces unit tests according to a set of requirements that have been established prior to implementation, similar to the requirements found in 2.1. The requirements are turned into use cases (2.2) that symbolise small units of system functionality and each use case represents a user requirement; each requirement or functional unit has a unit test created for it before programming begins, and if the unit test meets the original requirement of the user the coding can begin (Mattu and Fraser, 2007). Section 2 displays the user requirements that have been been formulated and 3.4 displays the unit tests that have been written for the requirements established. The name of the unit test is displayed accompanied by the requirement it is testing.

3.2 Test Plan Prior to testing it was necessary to implement a testing plan which demonstrates the use of white, black and grey box testing. According to Sommerville (2007, p424) white-box testing is a low-level testing of components in order to produce test cases for each component. Black-box testing is performed at the high interface level of a system testing behaviour and functional requirements with a number of user inputs to the system in the form of test cases. Black-box testing may address error such as:

• Missing functions • Interface errors • Database connection issues • Performance problems • Start-up and shut-down errors

Sommerville (2007, p434) Grey-box testing is a mixture of both white and black box testing. It involves test cases based on the internal structure of a system (white-box) but the tests are performed at a user level (black-box); it is different from white-box testing because the internal composition of the system is not known in the testing process i.e. at the interface level (Davis, 2009). Refer to the appendix for the Test Plan.


17

3.3 Underlying Bug

Before implementing the incomplete methods it was necessary to address a major bug in the source code that was realised when the MiniMono game was played. The bug was that when the dice were rolled there was an anomaly in that a zero value was returned. This element satisfies the roll dice element of the majority of requirements but it has a bug:

Figure 11: Underlying Bug

The code for this could be found in the file die.java:

public int getRoll() { return (int)(Math.random() * 6); }

The anomaly was fixed by changing the code slightly:

return (int)(Math.random() * 6) +1; In adding the +1 at the end of the line of code a zero value is not returned. This in turn fixes the DieTest.java bug that intermittently returns a failing unit test which will be discussed in 3.3.2.

3.4 Incomplete Methods and Unit Tests

Within the source code there are a number of incomplete methods that have to be completed and implemented within the code.

3.4.1 RailRoad.java Requirement: 2.1.12 Pay Rent The RailRoad.java file has a test that needs to be completed. The test is supposed to check whether or not rent is paid to the specified user if a player lands on a RailRoad square and currently it does not. The original code was:

public void playAction() { Player currentPlayer = null; if(!isAvailable()) { currentPlayer = GameMaster.instance().getCurrentPlayer(); if(owner != currentPlayer) {

} By adding the following line of code the test is made complete:

currentPlayer.payRentTo(owner, getRent());

The variable currentPlayer contains all the data in Player; payRentTo is a method within Player.java and the variable owner is present within the Square.java file which RailRoad.java extends. The line of code above

0 returned


18

uses the create variable to call the action payRentTo from Player,java and verifies that the owner receives rent.

3.4.2 DieTest.java Requirement: all tests other than 2.1.1 Start Game Refer to 3.2 for the underlying bug error. The following alterations displayed in the list of figures show the test failing and passing.

Figure 12: Die Unit Test

And the unit test has failed...

Figure 13: Test Failure

When the code for Die.java is altered as displayed in 3.2.1 the unit test passes consistently due to a number being returned that is between 1 and 6. The test was run 50 times. Figure 14 displays the test working:

Figure 14: Test Pass

The value 0 is returned to the console when running the unit test for DieTest.java


19

3.4.2 CardTest.java Requirement: 2.1.10 Draw Card In CardTest.java there are a number of tests that have not been completed; tests have been set up for the community chest and chance card but the methods have not been implemented. In testing each card type it was necessary to test whether the user had won or lost £50 according to the card specification. The variable ccCard is declared in the public void setUp() which contained the community chest details: ccCard = new MoneyCard("Get 50 pounds", 50, Card.CARD_TYPE_COMMUNITYCHEST); And the variable chanceCard is also declared in the public void setUp() which contained the chance card details: chanceCard = new MoneyCard("Lose 50 pounds", -50, Card.CARD_TYPE_CHANCE); The following code displays how the card is drawn and tested to see if what is returned is the details contained within the ccCard variable.

public void testCCCardType() { CardFeatures CardType = gameMaster.drawCCCard(); assertEquals(CardType.getCardType(), chanceCard.getCardType()); } This code should return a failed test because the variable CardType is attempting to draw the community chest card and when using the assertEquals method a Boolean response is required stating whether what is returned is what was expected. It will not work because the code is essentially stating that the expected card returned is the ccCard and what is actually returned is the chanceCard. So the test fails:

Figure 15: Test Fail

Test passed once the code has been altered to ccCard...

testCCCardType failure


20


The same has been implemented for the testChanceCardType as shown above and the test also passes. The coding is as follows:

public void testChanceCardType() { CardFeatures CardType = gameMaster.drawChanceCard(); assertEquals(CardType.getCardType(), chanceCard.getCardType()); }

3.4.3 GameMasterTestManualProcess.java Incomplete Test Requirement: Error (refer to Critique) The problem here is an incomplete unit test. A bug is apparent in this test because the variable p2 is never read according to the Eclipse IDE notation. This means that the variable is not doing anything; it is not being used within the method and is therefore returning the warning. The code appears as follows:

Player p1 = gameMaster.getPlayer(0); Player p2 = gameMaster.getPlayer(1); gameMaster.movePlayer(p1, 1);

If the following line of code is entered the variable p2 is given an action within the method and the problem is rectified:

gameMaster.moveplayer(p2, 2);

For this test there are also extra tests that are required to be implemented. It was decided that two extra test would be implemented, a test that affirms whether the number of players is 2 and whether the names returned are specified as according to the variables created. For example, the two variable created contain the following information (numbers and names of the original program have been changed):

gameMaster.setNumberOfPlayers(4); gameMaster.getPlayer(0).setName("Thom"); gameMaster.getPlayer(1).setName("Bob"); So on test was created to ascertain whether the number of players was...

public void testNumPlayers() { int players = gameMaster.getNumberOfPlayers(); assertSame(players, 4); } And a test was created to test for the player names Thom and Bob...

Code changed to ccCard


21

public void testPlayerName() { String name = gameMaster.getPlayer(0).getName(); assertSame(name, "Thom"); name = gameMaster.getPlayer(1).getName(); assertSame(name, "Bob"); } Failed test for testNumPlayers...


Failed test for testPlayerName...


Test pass for testNumPlayers...

1 entered instead of the required 4

Unexpected names entered


22


Test pass for testPlayerName...


3.4.4 LoseMoneyCardTest.java Requirement: 2.1.10 Draw Card This again is an incomplete that requires finishing; the variable origMoney is never read which again means that it is not doing anything in the method. Insert the following line of code to give origMoney a function...

assertEquals(origMoney, 20000);

This line of code is attempting to state that the original amount of money a player has is 20000. Eclipse should therefore return a failing unit test because the original amount of money each player possesses is 1500. LoseMoneyCardTest.java failing test (refer to page 22):

Required number 4 entered

Required names “Thom” and “Bob” entered


23


By viewing figure 21 above it is possible to see that Eclipse is stating that the value 20000 was received instead of the value 1500 which returns a failed test. The original amount of money each player has is 1500 so this is inserted instead. Figure 22 displays the test now working:


3.4.5 PlayerTest.java Requirement: 2.1.7 Get Out Of Jail An extra test is to be implemented for this test but problems have been encountered in the implementation of it. An attempt has been made to test whether or not a use is in jail but the implementation of it has proven difficult (refer to Critique). The following unit test has been created but the validity of it is uncertain. The code is: public void testInJailSquare() { gameMaster.setNumberOfPlayers(2); gameMaster.movePlayer(0, 3);

Original amount of money: 1500 Amount of money entered: 20000


24

Player player = gameMaster.getPlayer(0); player.isInJail(); } The test passes...


But whether or not the test accomplishes anything is unclear.

3.4.6 SquareInfoFormatterTest.java This test has a variable that is never read: propertyLabel, which means that the variable is not doing anything in the method. As result it was decided that a change had to be made in the class PropertySquare.java in the source code. In the specified class a string variable name propertyLabel was declared:

private String propertyLabel; And a new string object named PropertyLabel is initialised which returns the private string propertyLabel created as above...

public String getPropertyLabel() { return propertyLabel; }

Create a variable named setLabel containing propertyLabel that the square formatter test can utilise...

public void setLabel(String propertyLabel) { this.propertyLabel = propertyLabel; }

Then in SquareInfoFormatterTest.java set the property label variable...

Square.setLabel(propertyLabel);

The test result...


25


Again it is uncertain as to whether or not this test achieves anything but it does stops the variable propertyLabel from being never read.

3.5 Acceptance Testing Acceptance testing is used to verify that all parts of system functionality are achieved in accordance to what was originally required of the system as stipulated by the requirement specification; acceptance testing is a high-level testing procedure that adopts the black-box testing theory (Yi Yu et al., 1999). Pressman (2007, p113) enhances this concept by stating that the acceptance tests themselves are approved by the user and they focus on the system as a whole and the functions that the user can actually view and review. Acceptance tests have been utilised in the MiniMono program to ensure that the overall requirements as specified in section 2 have been met successfully. Issues were raised in implementing the acceptance tests (refer to the Critique); in theory the following tests could have been completed: 1. Test that only numbers between 2 and 8 can be inputted in the number of players’ dialogue box 2. Test that a property, RailRoad or utility can be purchased and the bank receives money accordingly 3. Test that a player collects $200 when they pass Go 4. Test that when a player lands on the Go To Jail square the player gets put in Jail 5. Test that when a player gets out of jail the player pays a $50 fine 6. Test that when player t lands on an owned square, player t receives rent 7. Test that when a player lands on community chest they receive $50 8. Test that when a player lands on chance square they lose $50 9. Test that a player can trade a purchased item


26

Attempts were made to create the Pass Go acceptance test: Attempts were made to create the Purchase Property acceptance test but when running the code the following error was returned:

Figure 25: Purchase Property Error

Figure 26 displays that the acceptance test is being tested using a new pakage named miniMono.thom:

Figure 26: Correct Test

When running the test using FIT the following message in the console is being returned (Figure 27):

Correct testing path but failed test


27

Figure 27: Exception

It is stating that 1 exception has happened, but attempting to find out what has happened proved unsuccessful. The exception is supposed to be displayed in the HTML page related to the test i.e. purchaseProperty.html, but it could not be found. This was similar for all of the tests that were attempted. The other tests attempted were TestPassGo and TestPlayerInfo, with related HTML pages passGo.html and playerInfo.html. These tests were deemed major pieces of functionality of the system that required user acceptance.

4. Software Quality Once the software has been produced quality can be measured using metrics. Metrics can be used to measure both interface design and source code quality; metrics merely measure the quality of a system (Pressman, 2007). There are a number of differing levels that quality can be measured and the interface is a high level metric that can be assessed. An interface can be monitored by using metrics such as layout of objects i.e. appearance: graphics, text, fonts; positioning of icons, menus and windows all relating to the ease of user transition from one entity to another (Preesman, 2007, p488). This can be achieved by measuring user cohesion speeds, how quickly a user moves from one action to the next and how long it takes a particular user to complete a specified operation or recover from an error. In relation to the MiniMono application this could be how long it takes a user to register that they have to pay rent, how long does it take for a dialog box to be produced and the length of time it takes the user to complete the action. Assessing this area would improve the external performance of the system because optimum levels of user interaction could be ascertained and operability will improve. Metrics also relate to low level measurements, metrics for source code for example. Pressman (2007, p490) refers to the metrics Halstead suggests in the measurement of program length, program size in bits, how complex the software is, how much time and effort it has taken to develop the system, and even a metric for the amount of faults there are in the application. He proposes that the measurements are:

• N1 = the number of distinct operators in a program • N2 = the number of distinct operands in a program • N1 = the total number of operator occurrences • N2 = the total number of operand occurrences

Pressman (2007, p490) Pressman states that Halstead formulises these values into two equations that can assist in measuring the aforementioned source code metrics. The equations are: Program Length


28

N = n1 log2 n1 + n2 log2 n2

Program Volume V = N log2 (n1 + n2) Pressman (2007, p490) This equation could assist in ascertaining the size and error projection for the MiniMono application and assist in the monitoring of it an assist in improving the quality of the system. If the amount of errors are known and identified they can be addressed or removed and potentially improve the quality of the software. Cutting down the size of the system could also be a benefit because the less space used the quicker the response time of the application.

5. Critique

5.1 Effectiveness of Test Driven Development The TDD approach is ideal for this application. The process involves formulating tests for the system based on the requirements of the system prior to implementation. Each requirement becomes a use case and in turn has a test written for it. The requirements will be both functional and non-functional and the application entails a high and low level specification. Essentially, the application has an interface and it lies upon numerous components that make it function. TDD incorporates black, grey and white box testing in which both the internal architecture and external interface are designed. The MiniMono application is comprised of numerous components and functional elements and the TDD approach is an iterative, incremental method of producing an application. TDD is essential in that it incorporates user requirements and testing of components and coding based on the requirements that have been created. It tests all levels of an application and is useful for an application like this because of its external interface and numerous components that require testing. It is ideal because the process ensures a component is working efficiently before the next phase is started; if it does not work then it is refactored, the process continues and the application is only accepted if the user requirements are met.

5.2 Review When reverse engineering the user requirements it would have been useful to incorporate a user story for move player because a use case was not created for this aspect and subsequently the use case diagram was difficult to construct. The use case diagram instead had a use case named start game at the focal point of the diagram from which the other use case extended. The requirement for Start Game was the entry of player information into the system and not a player movement.


29

Figure 28: Create Use Case

If a use case for move player was created then the use case Start Game could have functioned how it was supposed to in the diagram i.e. instead of having a Start Game use case an Enter Info use case could have been created. This fact resulted in the test plan not having a specified test for the requirement of Move Player also.

The state diagram on reflection also has a fault and related to the fact that the state Has Money is not really a state the system finds itself in, it is not behaviour of the system. Has Money is merely a a return of the function getMoney(); if a player is not bankrupt then they have money. This supposed state is not required merely a transition from Move Player to one of the Buy states may have been sufficient.

Figure 29: Not Required

Also a few of the required Unit tests were not completed entirely and the functionality of a one is questionable. For example PlayerTest.java has the following test written for it:

public void testInJailSquare() { gameMaster.setNumberOfPlayers(2); gameMaster.movePlayer(0, 3); Player player = gameMaster.getPlayer(0); player.isInJail(); } The test passes but whether or not it is actually doing anything is unsure because a failing test has not been written for. A missing test is apparent for the CardTest.java unit test. Two of the methods have been completed in this test but the compatibility method has not been completed: public void testJailSquareCompatibility() { }

Troubles were encountered with acceptance testing in that none of the tests implemented appeared to work. Details of this are in section 3, but if more time had been allotted to complete this element of the assignment a working test may have been completed. A matter of bad time management resulted in very little time to experiment with the acceptance tests and poor performance in this area resulted.

Wrong use case

‘State’ not required


30

Also adherence to the test plan created could have been better. In the testing process no real method was assumed and tests did not follow a strict guidelines.

5.3 Recommendations Below is a list of recommendations:

• Create a Move Player requirement and in turn use case and incorporate it into the test plan • Remove the the Has Money state from the state diagram • Complete the acceptance tests • Configure the application so that the Draw Card square works and the MiniMono game can be

played fully • Monitor the quality of the software by utilising metrics to measure operation size, operation

complexity, bugs returned in order to improve the software in future development • Currently the application is run on the Eclipse IDE; the creation an Ant build file for the application

so that the source code can stand alone on any computer would be beneficial


31

References Pressman, R.S. (2005). Software Engineering: A Practitioners Approach. 6th ed. McGraw-Hill International Edition. Sommerville, I. (2007). Software Engineering. 8th ed. Addison-Wesley. Sun, D. & Wong, K. (2005). IWPC 2005, Proceedings, 13th International Workshop on Program Comprehension: On evaluating the layout of UMLclass diagrams for program completion. pp317-326. Mattu, B.S. & Shankar. R. (2007). Test Driven Design Methodology for Component-Based System. Systems Conference, 2007 1st Annual IEEE, pp1-7. Fraser, J. & Mattu, B.S. (2007). Test Driven Design Challenges for Faster Product Development. Systems Conference, 2007 1st Annual IEEE, pp1-5. Davis, P. (2009). What is gray box testing? Retrieved May 15th, 2010, from http://www.robdavispe.com/free2/software-qa-testing-test-tester-2210.html Yi Yu. & Fangme, Wu. (1999). VLSI, 1999. Proceedings. Ninth Great Lakes Symposium on: A software acceptance testing technique based on knowledge accumulation. pp296-299.

Appendix

http://www.robdavispe.com/free2/software-qa-testing-test-tester-2210.html


32

Test Plan Start Game Test ID Test Inputs Expected Results Result

enterInfo1 Precondition: Game is idle, GameBoard loaded, Start Game Players: 2 Player Name: Thom Player Name: Bob Thom presses Cancel

Exit game Exit game

enterInfo2 Precondition: Game is idle, GameBoard loaded, Start Game Players: 11

Game returns max 8 players allowed

Please input a number between 2 and 8

enterInfo3 Precondition: Game is idle, GameBoard loaded, Start Game Players: 2 Player Name: Thom Player Name: Bob Click OK

Monopoly board game loads

Monopoly game loads with current player names play can begin

Purchase Property Test ID Test Inputs Expected Results Result

purchaseProperty1 Precondition: GameBoard loaded, Start Game, Player has money Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 1, 4 Click Purchase Property

Property bought, minus amount of cash

Blue 2 bought Thom has $1400 left

purchaseProperty2

Precondition: Bob has $20, GameBoard loaded, querySquareIndex(“Blue 1”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 5, 1 Click Purchase Property

Player does not have enough money cannot purchase the property

Cannot test – game freezes before this stage can be reached


33

Purchase Utility Test ID Test Inputs Expected Result Result

purchaseUtility1 Precondition: GameBoard loaded, Start Game, Player has money querySquareIndex(“Utility 2”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 3, 1 Click Purchase Property

Utility bought, minus amount of cash

Blue 2 bought Bob has $1000 left

purchaseUtility2

Precondition: Thom has $20, GameBoard loaded, querySquareIndex(“Utility1”) Tests: UtilitySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 5, 1 Click Purchase Property

Player does not have enough money cannot purchase the utility


Purchase RailRoad Test ID Test Inputs Expected Results Result

purchaseRailRoad1 Precondition: GameBoard loaded, Start Game, Player has money Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 1, 4 Click Purchase Property

Property bought, minus amount of cash

Blue 2 bought Thom has $1400 left

purchaseRailRoad2

Precondition: Bob has $20, GameBoard loaded, querySquareIndex(“RailRoad A”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 5, 1

Player does not have enough money cannot purchase the rail road



34

Click Purchase Property Go To Jail Test ID Test Inputs Expected Results Result

goToJail1 Precondition: GameBoard loaded, land on JailSquare Tests: testJailCardAction() querySquare(“Jail”) Input: Players: 2 Player Name: Thom Rolls: 1, 1

Player goes to jail Thom is located in the jail

Get Out Of Jail Test ID Test Inputs Expected Results Result

getOutOfJai1 Precondition: GameBoard is loaded, Player is inJail() Tests: JailSquare(“Jail”), BAIL = 50 Input: Players: 2 Player Name: Bob Ends Turn

Player is in jail and pays $50 to get out of jail

Player gets out of jail, players is minus $50, player has $1450

getOutOfJail2

Precondition: GameBoard is loaded, Player is inJail() Player has $40 Tests: JailSquare(“Jail”), BAIL = 50 Input: Players: 2 Player Name: Bob Ends Turn

Player cannot afford the $50 fine, isBankrupt and the game ends. Thom wins the game

Cannot assess – game freezes before this stage can be reached

Free Parking Test ID Test Inputs Expected Results Result

freeParking1 Precondition: GameBoard loaded, Lands on FreeParkingSquare, game starts Tests: setName(“Free Parking”) Input: Players: 2

Player lands on Free Parking, has $1500

Thom lands on Free Parking has $1500


35

Player Name: Thom Rolls: 2,6 Ends turn

Pass Go Test ID Test Inputs Expected Results Result

passGo1 Precondition: GameBoard is loaded, player lands on Go Tests: setName(“Go”) Input: Players: 2 Player Name: Bob Rolls: 5,3 Ends turn

Player passes Go and receives $200 Player has $1700

Player receives $200 and has $1700 overall

Draw Card Test ID Test Inputs Expected Results Result

drawCard1 Precondition: GameBoard loaded, Player lands on Community Chest Tests: getCardType() CARD_TYPE_COMMUNITY = 2 Input: Players: 2 Player Name: Thom Rolls: 3,3 End Turn

Player is on community chest square, receives $50 and now has $1550

Cannot be assessed -game freezes

drawCard2

Precondition: GameBoard loaded, Player lands on Chance Tests: getCardType() CARD_TYPE_CHANCE = 1 Input: Players: 2 Player Name: Bob Rolls: 5,3 End Turn

Player is on Chance Card square, loses $50 and now has $1450

Cannot be assessed -game freezes

Trade Purchase Test ID Test Inputs Expected Results Result

tradeBuy Precondition: GameBoard loaded, Start game Tests:

Bob sells a property and receives $100, and now has $1600. Thom loses $100 and is $1400

Thom loses $100 and is on $1400, Bob receives $100 and is on $1600


36

setName(“Buyer”) Input: Players: 2 Player Name: Thom Purchase: Property Price: $100 Bob accepts

tradeSell

Precondition: GameBoard loaded, player has square purchase Tests: setName(“Seller) Input: Players: 2 Player Name: Bob Selling: Property Price: $100 Thom buys

Thom buys a property form Bob, Thom is minus $100 and has $1400. Bob receives $100 and is on $1600

Bob receives $100, has $1600 and Thom loses $100, is on $1400

Pay Rent Test ID Test Inputs Expected Results Result

rent1 Precondition: GameBoard loaded, Player lands on owned square. querySquareIndex() Tests: querySquareIndex(“rent”) payRent() Input: Players: 2 Player Name: Bob Owned Square: Blue 1 Rent: $30 Ends Turn

Thom + $30 Bob - $30 Thom now has $1530 Bob now has $1470

Thom $1530 Bob $1470

Buy House Test ID Test Inputs Expected Results Result

buyHouse1 Precondition: GameBoard loaded, Player owns a property Blue 2 Tests: getHousePrice() getNumHouses() getPropertyLabel() Input: Players: 2 Player Name: Thom Owned Property: Blue 2 House Price: $50 Rolls Dice

Thom owns Blue 2 House is now on Blue 2, Thom - $50 Thom now has $1450

Blue 2 has house, Thom has $1450

Applied Software Engineering Assignment

Documents