Applied Software Engineering Assignment

725 views

Published on

3rd year software enginnering project in which i reverse and re-engineered a piece of software.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
725
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Applied Software Engineering Assignment

  1. 1. 21004229Applied SoftwareEngineering AssignmentMay 2010
  2. 2. Applied Software Engineering 21004229ContentsAbstract .............................................................................................................................................................. 6Introduction ........................................................................................................................................................ 61. Reverse Engineering and Software Design ................................................................................................... 62. 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......................................................................................................................................... 133. 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 ................................................................................................................................ 254. Software Quality ........................................................................................................................................... 27 2
  3. 3. Applied Software Engineering 210042295. Critique ......................................................................................................................................................... 28 5.1 Effectiveness of Test Driven Development ............................................................................................ 28 5.2 Review .................................................................................................................................................... 28 5.3 Recommendations ................................................................................................................................. 30References ....................................................................................................................................................... 31Appendix .......................................................................................................................................................... 31FiguresFigure 1: Use Case Diagram ............................................................................................................................. 9Figure 2: Purchase Item Use Case .................................................................................................................. 10Figure 3: Go To Jail.......................................................................................................................................... 10Figure 4: Draw Card ......................................................................................................................................... 10Figure 5: Class Diagram .................................................................................................................................. 11Figure 6: Class Inheritance .............................................................................................................................. 12Figure 7: Inheritance Source Code .................................................................................................................. 12Figure 8: Inheritance Source Code .................................................................................................................. 13Figure 9: Inheritance ........................................................................................................................................ 13Figure 10: Sate Diagram .................................................................................................................................. 14Figure 11: Underlying Bug ............................................................................................................................... 17Figure 12: Die Unit Test ................................................................................................................................... 18Figure 13: Test Failure ..................................................................................................................................... 18Figure 14: Test Pass ........................................................................................................................................ 18Figure 15: Test Fail .......................................................................................................................................... 19Figure 16: Test Pass ........................................................................................................................................ 20Figure 17: Test Fail .......................................................................................................................................... 21Figure 18: Test Fail .......................................................................................................................................... 21Figure 19: Test Pass ........................................................................................................................................ 22Figure 20: Test Pass ........................................................................................................................................ 22Figure 21: Test Fail .......................................................................................................................................... 23Figure 22: Test Pass ........................................................................................................................................ 23Figure 23 .......................................................................................................................................................... 24Figure 24: Test Pass ........................................................................................................................................ 25Figure 25: Purchase Property Error ................................................................................................................. 26Figure 26 .......................................................................................................................................................... 26Figure 27 .......................................................................................................................................................... 27Figure 28 .......................................................................................................................................................... 29Figure 29 .......................................................................................................................................................... 29 3
  4. 4. Applied Software Engineering 21004229 4
  5. 5. Applied Software Engineering 21004229 5
  6. 6. Applied Software Engineering 21004229AbstractThis document entails the reverse and re-engineering processes undertaken in the analysis of a Javaapplication program based on the board game Monopoly.IntroductionReverse engineering and re-engineering a piece of software involves a number of different processes; thisdocument 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 behaviourRe-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) frameworkAn analysis of all of the techniques identified above, a discussion of the metrics involved in monitoring thequality of the software produced and a personal critique of work completed in the report will be apparent inthe document.1. Reverse Engineering and Software DesignAccording to Pressman (2005) reverse engineering was originally used in the business world to disassemblea piece of hardware that a competitor had produced in order to gain an understanding of how it workedbased on the design specifications. Similarly with software reverse engineering, a program that is owned andtherefore does not have a design specification, is analysed to produce a high level representation of thesystem rather than just the programming code itself; the process aims to gather data, system architectureand the procedures involved in designing the system (Pressman, 2005). Sommerville (2007, p502) indicatesthat 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 ofthe process, quality of the software designed and sophistication of the software is established using specifictools (Pressman, 2005). Pressman (2005) further iterates that at the abstraction level of the reverseengineering 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 6
  7. 7. Applied Software Engineering 21004229In relating the information acquired to the MiniMono assignment, the reverse engineering process involvedthe identification of how the software was designed by ascertaining the original user requirements andrepresenting them using a use case diagram, software structure using a class diagram and softwareprocedures or behaviour using a state diagram. These procedures have all assisted in acquiring an idea ofhow the MiniMono system was originally designed, from purely looking at the low-level source coding andsystem interface.2. Requirements AnalysisIn order to gain a perspective of what the user requires of a system prior to implementation it is necessary toformulate a requirements list from which user stories can be acquired.2.1 System RequirementsPrior to producing a use case diagram related to the system it was necessary to produce a list ofrequirements representing exactly what the user required of the software. The following requirements wereelicited 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 boxWhere 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 boxWhere 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 turn2.1.3. Buy House 3.1 User n shall be able to click ‘Roll Dice’ 3.2Where 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 turnWhere 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 7
  8. 8. Applied Software Engineering 21004229 5.4 User n shall be able to end turnWhere 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 turn2.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 turn2.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 turnWhere 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 turnWhere 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 8
  9. 9. Applied Software Engineering 21004229 12.5 User n shall be able to end turn2.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 DiagramUse cases are utilised to provide a scenario-based representation of the requirements that have beenelicited in relation to a proposed project, and according to Sommerville (2007) use cases portray theinteractions between users and the system; in this case the interactions between the player and theMiniMono 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 ause case in the diagram and the subsequent interactions: Figure 1: Use Case Diagram2.2.1 Use Case Diagram Design RationaleAs mentioned in 2.2, each use case represents a requirement formulated in 2.1, and each use caserepresents an interaction between the user and the system. For example the use case Enter Info includestwo use cases which are Num Players and Enter Name; this interaction enables the game to start. Figure 1displays 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 systemdue to all interactions subsequently occurring after this use case has been completed; this is demonstratedby the Extends use cases in Figure 1. After the Start Game interaction has occurred the player can then takea turn and subsequently purchase an item, pass go, go to jail and so on. 9
  10. 10. Applied Software Engineering 21004229A number of the extends use cases also have extended interactions of their own i.e. the Purchase Item usecase leads to the purchase of either a Rail Road, Utility or Property, and these use cases then result in theuser interaction of trading the item that has been purchased, represented by the extended use case TradePurchase. Figure 2: Purchase Item Use CaseThis is similar for the Go To Jail use case; the Go To Jail use case then results in the interaction of the userwith the system to get out of jail, which includes the user having to pay a fine of £50, symbolised by theextended use case Get Out Of Jail and the use case Pay £50 that has been included. Figure 3: Go To JailThis is likewise similar for Draw Card which demonstrates that when a card is drawn i.e. Community Chest orChance card the player either loses or receives £50 according to the card that has been drawn, as displayedin Figure *: Figure 4: Draw Card2.3 Class DiagramAccording to Sun and Wong (2005) class diagrams describe the relationships, inheritance, associations andgeneral 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 ofa system can be achieved and assist in the modelling and overall understanding of a system when producinga class diagram in the reverse engineering process.Figure 5 is the class diagram produced in the reverse engineering process relating to the MiniMono Javaprogram: 10
  11. 11. Applied Software Engineering 21004229 Figure 5: Class DiagramThe class diagram was produced by analysing the source code of the entire MiniMono application andidentifying all the classes created, attributes within in each class, methods that each class was involved inand relationships between classes. Each class in the diagram represents a class identified in the sourcecode.2.3.1 Class InheritanceFor example the class Square is an example of an abstract class that contains abstract methods; abstractmethods are empty and therefore Square requires subclasses to implement the methods for it. This issignified by the class Square inheriting the subclasses as displayed in Figure * 11
  12. 12. Applied Software Engineering 21004229 = Inheritance Figure 6: Class InheritanceThe source code identified relating to Figure 1 is a follows :Class: Squarepublic 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 CodeIt 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: 12
  13. 13. Applied Software Engineering 21004229 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 CodeIt is possible to see that the two are linked via the ‘extends Square‘ part of the coding linking the twoclasses together therefore enabling the inheritance represented in the class diagram. This applies to all ofthe Square classes i.e. GoToJailSquare etc and the coding is the same. The same applies for the Card classas represented in Figure * Figure 9: Inheritance2.4 State DiagramAccording to Pressman (2007) a state diagram is a behavioural model that represents the transition betweendifferent states and the triggers that initiate the changes of state. Figure * is the state diagram produced forthe MiniMono project and it displays a player turn in which the player decides to buy something on theMonopoly board. Each state is represented by a yellow box and an arrow represents the transition from onestate to another and upon each arrow is the trigger that initiates the transition (Pressman, 2007, p250). 13
  14. 14. Applied Software Engineering 21004229 Figure 10: Sate DiagramFrom the diagram it is possible to see that the following state transitions and subsequent triggers have takenplace: 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 14
  15. 15. Applied Software Engineering 21004229 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 HouseTrigger: 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 15
  16. 16. Applied Software Engineering 210042293. Re-engineering Process3.1 Test Driven DesignMattu and Shankar (2007) indicate that the Test Driven Design (TDD) approach involves writing tests beforeany 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 israpidly fixed according to the tests that have been produced in a process that is known as refactoring (Mattuand Shankar, 2007). Essentially, a test is produced, a piece of code is written and the test is then used toverify 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 ofrequirements 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 eachuse case represents a user requirement; each requirement or functional unit has a unit test created for itbefore programming begins, and if the unit test meets the original requirement of the user the coding canbegin (Mattu and Fraser, 2007). Section 2 displays the user requirements that have been been formulatedand 3.4 displays the unit tests that have been written for the requirements established. The name of the unittest is displayed accompanied by the requirement it is testing.3.2 Test PlanPrior to testing it was necessary to implement a testing plan which demonstrates the use of white, black andgrey box testing. According to Sommerville (2007, p424) white-box testing is a low-level testing ofcomponents in order to produce test cases for each component. Black-box testing is performed at the highinterface level of a system testing behaviour and functional requirements with a number of user inputs to thesystem 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 errorsSommerville (2007, p434)Grey-box testing is a mixture of both white and black box testing. It involves test cases based on the internalstructure of a system (white-box) but the tests are performed at a user level (black-box); it is different fromwhite-box testing because the internal composition of the system is not known in the testing process i.e. atthe interface level (Davis, 2009). Refer to the appendix for the Test Plan. 16
  17. 17. Applied Software Engineering 210042293.3 Underlying BugBefore implementing the incomplete methods it was necessary to address a major bug in the source codethat was realised when the MiniMono game was played. The bug was that when the dice were rolled therewas an anomaly in that a zero value was returned. This element satisfies the roll dice element of the majorityof requirements but it has a bug: 0 returned Figure 11: Underlying BugThe 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.javabug that intermittently returns a failing unit test which will be discussed in 3.3.2.3.4 Incomplete Methods and Unit TestsWithin the source code there are a number of incomplete methods that have to be completed andimplemented within the code.3.4.1 RailRoad.javaRequirement: 2.1.12 Pay RentThe RailRoad.java file has a test that needs to be completed. The test is supposed to check whether or notrent is paid to the specified user if a player lands on a RailRoad square and currently it does not. The originalcode 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 thevariable owner is present within the Square.java file which RailRoad.java extends. The line of code above 17
  18. 18. Applied Software Engineering 21004229uses the create variable to call the action payRentTo from Player,java and verifies that the owner receivesrent.3.4.2 DieTest.javaRequirement: all tests other than 2.1.1 Start GameRefer to 3.2 for the underlying bug error. The following alterations displayed in the list of figures show the testfailing and passing. The value 0 is returned to the console when running the unit test for DieTest.java Figure 12: Die Unit TestAnd the unit test has failed... Figure 13: Test FailureWhen the code for Die.java is altered as displayed in 3.2.1 the unit test passes consistently due to a numberbeing returned that is between 1 and 6. The test was run 50 times. Figure 14 displays the test working: Figure 14: Test Pass 18
  19. 19. Applied Software Engineering 210042293.4.2 CardTest.javaRequirement: 2.1.10 Draw CardIn CardTest.java there are a number of tests that have not been completed; tests have been set up for thecommunity chest and chance card but the methods have not been implemented. In testing each card type itwas 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 carddetails: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 detailscontained 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 communitychest card and when using the assertEquals method a Boolean response is required stating whether what isreturned is what was expected. It will not work because the code is essentially stating that the expected cardreturned is the ccCard and what is actually returned is the chanceCard. So the test fails: Figure 15: Test Fail testCCCardType failureTest passed once the code has been altered to ccCard... 19
  20. 20. Applied Software Engineering 21004229 Figure 16: Test Pass Code changed to ccCardThe 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 TestRequirement: Error (refer to Critique)The problem here is an incomplete unit test. A bug is apparent in this test because the variable p2 is neverread according to the Eclipse IDE notation. This means that the variable is not doing anything; it is not beingused 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 isrectified:gameMaster.moveplayer(p2, 2);For this test there are also extra tests that are required to be implemented. It was decided that two extra testwould be implemented, a test that affirms whether the number of players is 2 and whether the namesreturned are specified as according to the variables created. For example, the two variable created containthe 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... 20
  21. 21. Applied Software Engineering 21004229public void testPlayerName() { String name = gameMaster.getPlayer(0).getName(); assertSame(name, "Thom"); name = gameMaster.getPlayer(1).getName(); assertSame(name, "Bob"); }Failed test for testNumPlayers... Figure 17: Test Fail 1 entered instead of the required 4Failed test for testPlayerName... Figure 18: Test Fail Unexpected names enteredTest pass for testNumPlayers... 21
  22. 22. Applied Software Engineering 21004229 Figure 19: Test Pass Required number 4 enteredTest pass for testPlayerName... Figure 20: Test Pass Required names “Thom” and “Bob” entered3.4.4 LoseMoneyCardTest.javaRequirement: 2.1.10 Draw CardThis again is an incomplete that requires finishing; the variable origMoney is never read which again meansthat 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. Eclipseshould therefore return a failing unit test because the original amount of money each player possesses is1500. LoseMoneyCardTest.java failing test (refer to page 22): 22
  23. 23. Applied Software Engineering 21004229 Figure 21: Test Fail Amount of money entered: 20000 Original amount of money: 1500By viewing figure 21 above it is possible to see that Eclipse is stating that the value 20000 was receivedinstead of the value 1500 which returns a failed test. The original amount of money each player has is 1500so this is inserted instead. Figure 22 displays the test now working: Figure 22: Test Pass3.4.5 PlayerTest.javaRequirement: 2.1.7 Get Out Of JailAn extra test is to be implemented for this test but problems have been encountered in the implementation ofit. An attempt has been made to test whether or not a use is in jail but the implementation of it has provendifficult (refer to Critique). The following unit test has been created but the validity of it is uncertain. The codeis:public void testInJailSquare() { gameMaster.setNumberOfPlayers(2); gameMaster.movePlayer(0, 3); 23
  24. 24. Applied Software Engineering 21004229 Player player = gameMaster.getPlayer(0); player.isInJail(); }The test passes... Figure 23: Test PassBut whether or not the test accomplishes anything is unclear.3.4.6 SquareInfoFormatterTest.javaThis test has a variable that is never read: propertyLabel, which means that the variable is not doing anythingin the method. As result it was decided that a change had to be made in the class PropertySquare.java in thesource 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 propertyLabelcreated 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... 24
  25. 25. Applied Software Engineering 21004229 Figure 24: Test PassAgain it is uncertain as to whether or not this test achieves anything but it does stops the variablepropertyLabel from being never read.3.5 Acceptance TestingAcceptance testing is used to verify that all parts of system functionality are achieved in accordance to whatwas originally required of the system as stipulated by the requirement specification; acceptance testing is ahigh-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 andthey 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 asspecified 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 box2. Test that a property, RailRoad or utility can be purchased and the bank receives money accordingly3. Test that a player collects $200 when they pass Go4. Test that when a player lands on the Go To Jail square the player gets put in Jail5. Test that when a player gets out of jail the player pays a $50 fine6. Test that when player t lands on an owned square, player t receives rent7. Test that when a player lands on community chest they receive $508. Test that when a player lands on chance square they lose $509. Test that a player can trade a purchased item 25
  26. 26. Applied Software Engineering 21004229Attempts were made to create the Pass Go acceptance test:Attempts were made to create the Purchase Property acceptance test but when running the code thefollowing error was returned: Figure 25: Purchase Property ErrorFigure 26 displays that the acceptance test is being tested using a new pakage named miniMono.thom: Figure 26: Correct Test Correct testing path but failed testWhen running the test using FIT the following message in the console is being returned (Figure 27): 26
  27. 27. Applied Software Engineering 21004229 Figure 27: ExceptionIt is stating that 1 exception has happened, but attempting to find out what has happened provedunsuccessful. 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 andplayerInfo.html. These tests were deemed major pieces of functionality of the system that required useracceptance.4. Software QualityOnce the software has been produced quality can be measured using metrics. Metrics can be used tomeasure 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 ahigh level metric that can be assessed. An interface can be monitored by using metrics such as layout ofobjects i.e. appearance: graphics, text, fonts; positioning of icons, menus and windows all relating to theease 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 thenext and how long it takes a particular user to complete a specified operation or recover from an error. Inrelation to the MiniMono application this could be how long it takes a user to register that they have to payrent, how long does it take for a dialog box to be produced and the length of time it takes the user tocomplete the action. Assessing this area would improve the external performance of the system becauseoptimum 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, howcomplex the software is, how much time and effort it has taken to develop the system, and even a metric forthe 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 occurrencesPressman (2007, p490)Pressman states that Halstead formulises these values into two equations that can assist in measuring theaforementioned source code metrics. The equations are:Program Length 27
  28. 28. Applied Software Engineering 21004229N = n1 log2 n1 + n2 log2 n2Program VolumeV = N log2 (n1 + n2)Pressman (2007, p490)This equation could assist in ascertaining the size and error projection for the MiniMono application andassist in the monitoring of it an assist in improving the quality of the system. If the amount of errors areknown 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 theresponse time of the application.5. Critique5.1 Effectiveness of Test Driven DevelopmentThe TDD approach is ideal for this application. The process involves formulating tests for the system basedon the requirements of the system prior to implementation. Each requirement becomes a use case and inturn has a test written for it. The requirements will be both functional and non-functional and the applicationentails a high and low level specification. Essentially, the application has an interface and it lies uponnumerous components that make it function. TDD incorporates black, grey and white box testing in whichboth the internal architecture and external interface are designed. The MiniMono application is comprised ofnumerous components and functional elements and the TDD approach is an iterative, incremental method ofproducing an application.TDD is essential in that it incorporates user requirements and testing of components and coding based onthe requirements that have been created. It tests all levels of an application and is useful for an applicationlike this because of its external interface and numerous components that require testing. It is ideal becausethe process ensures a component is working efficiently before the next phase is started; if it does not workthen it is refactored, the process continues and the application is only accepted if the user requirements aremet.5.2 ReviewWhen reverse engineering the user requirements it would have been useful to incorporate a user story formove player because a use case was not created for this aspect and subsequently the use case diagramwas difficult to construct. The use case diagram instead had a use case named start game at the focal pointof the diagram from which the other use case extended. The requirement for Start Game was the entry ofplayer information into the system and not a player movement. 28
  29. 29. Applied Software Engineering 21004229 Wrong use case Figure 28: Create Use CaseIf a use case for move player was created then the use case Start Game could have functioned how it wassupposed to in the diagram i.e. instead of having a Start Game use case an Enter Info use case could havebeen created. This fact resulted in the test plan not having a specified test for the requirement of MovePlayer also.The state diagram on reflection also has a fault and related to the fact that the state Has Money is not reallya state the system finds itself in, it is not behaviour of the system. Has Money is merely a a return of thefunction getMoney(); if a player is not bankrupt then they have money. This supposed state is not requiredmerely a transition from Move Player to one of the Buy states may have been sufficient. ‘State’ not required Figure 29: Not RequiredAlso a few of the required Unit tests were not completed entirely and the functionality of a one isquestionable. 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 beenwritten for. A missing test is apparent for the CardTest.java unit test. Two of the methods have beencompleted 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 assignmenta working test may have been completed. A matter of bad time management resulted in very little time toexperiment with the acceptance tests and poor performance in this area resulted. 29
  30. 30. Applied Software Engineering 21004229Also adherence to the test plan created could have been better. In the testing process no real method wasassumed and tests did not follow a strict guidelines.5.3 RecommendationsBelow 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 30
  31. 31. Applied Software Engineering 21004229References thPressman, R.S. (2005). Software Engineering: A Practitioners Approach. 6 ed. McGraw-HillInternational Edition. thSommerville, I. (2007). Software Engineering. 8 ed. Addison-Wesley. thSun, D. & Wong, K. (2005). IWPC 2005, Proceedings, 13 International Workshop on ProgramComprehension: 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. stSystems Conference, 2007 1 Annual IEEE, pp1-7.Fraser, J. & Mattu, B.S. (2007). Test Driven Design Challenges for Faster Product Development. stSystems Conference, 2007 1 Annual IEEE, pp1-5. thDavis, P. (2009). What is gray box testing? Retrieved May 15 , 2010, fromhttp://www.robdavispe.com/free2/software-qa-testing-test-tester-2210.htmlYi Yu. & Fangme, Wu. (1999). VLSI, 1999. Proceedings. Ninth Great Lakes Symposium on: A softwareacceptance testing technique based on knowledge accumulation. pp296-299.Appendix 31
  32. 32. Applied Software Engineering 21004229Test PlanStart GameTest ID Test Inputs Expected Results ResultenterInfo1 Precondition: Game is Exit game Exit game idle, GameBoard loaded, Start Game Players: 2 Player Name: Thom Player Name: Bob Thom presses CancelenterInfo2 Precondition: Game is Game returns max 8 Please input a number idle, GameBoard loaded, players allowed between 2 and 8 Start Game Players: 11enterInfo3 Precondition: Game is Monopoly board game Monopoly game loads idle, GameBoard loaded, loads with current player Start Game names play can begin Players: 2 Player Name: Thom Player Name: Bob Click OKPurchase PropertyTest ID Test Inputs Expected Results ResultpurchaseProperty1 Precondition: Property bought, minus Blue 2 bought GameBoard loaded, amount of cash Thom has $1400 left Start Game, Player has money Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 1, 4 Click Purchase PropertypurchaseProperty2 Precondition: Player does not have Cannot test – game Bob has $20, enough money cannot freezes before this stage GameBoard loaded, purchase the property can be reached querySquareIndex(“Blue 1”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 5, 1 Click Purchase Property 32
  33. 33. Applied Software Engineering 21004229Purchase UtilityTest ID Test Inputs Expected Result ResultpurchaseUtility1 Precondition: GameBoard Utility bought, minus Blue 2 bought loaded, Start Game, amount of cash Bob has $1000 left Player has money querySquareIndex(“Utility 2”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 3, 1 Click Purchase PropertypurchaseUtility2 Precondition: Player does not have Cannot test – game Thom has $20, GameBoard enough money cannot freezes before this loaded, purchase the utility stage can be reached querySquareIndex(“Utility1”) Tests: UtilitySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 5, 1 Click Purchase PropertyPurchase RailRoadTest ID Test Inputs Expected Results ResultpurchaseRailRoad1 Precondition: GameBoard Property bought, minus Blue 2 bought loaded, Start Game, amount of cash Thom has $1400 left Player has money Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Thom Rolls: 1, 4 Click Purchase PropertypurchaseRailRoad2 Precondition: Player does not have Cannot test – game Bob has $20, GameBoard enough money cannot freezes before this loaded, purchase the rail road stage can be reached querySquareIndex(“RailRoad A”) Tests: PropertySquareTest.java getPlayer(); getMoney() Input: Players: 2 Player Name: Bob Rolls: 5, 1 33
  34. 34. Applied Software Engineering 21004229 Click Purchase PropertyGo To JailTest ID Test Inputs Expected Results ResultgoToJail1 Precondition: Player goes to jail Thom is located in the GameBoard loaded, land jail on JailSquare Tests: testJailCardAction() querySquare(“Jail”) Input: Players: 2 Player Name: Thom Rolls: 1, 1Get Out Of JailTest ID Test Inputs Expected Results ResultgetOutOfJai1 Precondition: Player is in jail and pays Player gets out of jail, GameBoard is loaded, $50 to get out of jail players is minus $50, Player is inJail() player has $1450 Tests: JailSquare(“Jail”), BAIL = 50 Input: Players: 2 Player Name: Bob Ends TurngetOutOfJail2 Precondition: Player cannot afford the Cannot assess – game GameBoard is loaded, $50 fine, isBankrupt and freezes before this stage Player is inJail() the game ends. Thom can be reached Player has $40 wins the game Tests: JailSquare(“Jail”), BAIL = 50 Input: Players: 2 Player Name: Bob Ends TurnFree ParkingTest ID Test Inputs Expected Results ResultfreeParking1 Precondition: Player lands on Free Thom lands on Free GameBoard loaded, Parking, has $1500 Parking has $1500 Lands on FreeParkingSquare, game starts Tests: setName(“Free Parking”) Input: Players: 2 34
  35. 35. Applied Software Engineering 21004229 Player Name: Thom Rolls: 2,6 Ends turnPass GoTest ID Test Inputs Expected Results ResultpassGo1 Precondition: Player passes Go and Player receives $200 GameBoard is loaded, receives $200 and has $1700 overall player lands on Go Player has $1700 Tests: setName(“Go”) Input: Players: 2 Player Name: Bob Rolls: 5,3 Ends turnDraw CardTest ID Test Inputs Expected Results ResultdrawCard1 Precondition: Player is on community Cannot be assessed - GameBoard loaded, chest square, receives game freezes Player lands on Community $50 and now has $1550 Chest Tests: getCardType() CARD_TYPE_COMMUNITY =2 Input: Players: 2 Player Name: Thom Rolls: 3,3 End TurndrawCard2 Precondition: Player is on Chance Cannot be assessed - GameBoard loaded, Card square, loses $50 game freezes Player lands on Chance and now has $1450 Tests: getCardType() CARD_TYPE_CHANCE = 1 Input: Players: 2 Player Name: Bob Rolls: 5,3 End TurnTrade PurchaseTest ID Test Inputs Expected Results ResulttradeBuy Precondition: Bob sells a property and Thom loses $100 and is GameBoard loaded, receives $100, and now on $1400, Bob receives Start game has $1600. Thom loses $100 and is on $1600 Tests: $100 and is $1400 35
  36. 36. Applied Software Engineering 21004229 setName(“Buyer”) Input: Players: 2 Player Name: Thom Purchase: Property Price: $100 Bob acceptstradeSell Precondition: Thom buys a property Bob receives $100, has GameBoard loaded, form Bob, Thom is minus $1600 and Thom loses player has square $100 and has $1400. $100, is on $1400 purchase Bob receives $100 and is Tests: on $1600 setName(“Seller) Input: Players: 2 Player Name: Bob Selling: Property Price: $100 Thom buysPay RentTest ID Test Inputs Expected Results Resultrent1 Precondition: Thom + $30 Thom $1530 GameBoard loaded, Bob - $30 Bob $1470 Player lands on owned Thom now has $1530 square. Bob now has $1470 querySquareIndex() Tests: querySquareIndex(“rent”) payRent() Input: Players: 2 Player Name: Bob Owned Square: Blue 1 Rent: $30 Ends TurnBuy HouseTest ID Test Inputs Expected Results ResultbuyHouse1 Precondition: Thom owns Blue 2 Blue 2 has house, Thom GameBoard loaded, House is now on Blue 2, has $1450 Player owns a property Thom - $50 Blue 2 Thom now has $1450 Tests: getHousePrice() getNumHouses() getPropertyLabel() Input: Players: 2 Player Name: Thom Owned Property: Blue 2 House Price: $50 Rolls Dice 36

×