BCIT COMP 7081 Assignment 2 by Wesley Kenzie March 2010

BCIT Computer Systems TechnologyCOMP 7081 Technical Issues in Software DevelopmentAssignment 2Author: Arthur (Wesley) Kenzie A00242330______________________________________________________________________________

March 22, 2010

This assignment builds on Assignment 1 and demonstrates the use of three additional software development concepts as they relate to the planned launch of a fictional “Blueberry” wireless device. These concepts are:

(1) high-level design ............................................... page 1(2) testing ............................................................. page 17(3) software configuration management (“SCM”) ........ page 19

PART 1 – High-Level Design

1. Interface between MMI module and Client module_______________________| MMI module ||_____________________ || (1) sendUserRequest(); || (2) getRequestStatus(); || (3) sendRequestStatus(); ||_____________________ |

// (1) sendUserRequest function// MMI module sends user request to Client module for processing// returns Request object created by Client module corresponding to this request// Server parameter identifies remote server (null = local storage)// RequestType parameter identifies type of request// string directoryName parameter identifies location of multimedia// string fileName parameter identifies name of multimedia file// long requestOptions parameter identifies options that may apply to this request// callbackFunctionPtr parameter specifies optional pointer to callback function Request MMI.sendUserRequest( Server, RequestType, string directoryName, string fileName, long requestOptions, *callbackFunctionPtr );

// (2) getRequestStatus function// MMI module sends request to Client module for status information on a previous Request

______________________________________________________________________________Copyright © 2010 Arthur (Wesley) Kenzie. All Rights Reserved. of 22


// returns Status object// Request requestObject parameter identifies previous RequestStatus MMI.getRequestStatus( Request );

// (3) sendRequestStatus function // MMI module sends status information to Client module because of user event or// because requested event has finished// Request parameter identifies previous Request// Status parameter contains status informationvoid MMI.sendRequestStatus( Request, Status );

__________________________________| Client module ||________________________________ || (1) sendConnectionStatus(); || (2) sendFileTransferStatus(); || (3) sendFileListingStatus(); || (4) startSongPlay(); || (5) pauseSongPlay(); || (6) restartSongPlay(); || (7) stopSongPlay(); || (8) startImageDisplay(); || (9) pauseImageDisplay(); || (10) restartImageDisplay(); || (11) stopImageDisplay(); ||________________________________ |

// (1) sendConnectionStatus function// Client module sends status information to MMI module regarding connection request// connectionRequest parameter identifies previous Request sent by MMI to Client // Status parameter contains status informationvoid Client.sendConnectionStatus( Request connectionRequest, Status );

// (2) sendFileTransferStatus function// Client module sends status information to MMI module regarding file transfer request// fileTransferRequest parameter identifies previous Request sent by MMI to Client // Status parameter contains status informationvoid Client.sendFileTransferStatus( Request fileTransferRequest, Status );

// (3) sendFileListingStatus function// Client module sends status information to MMI module regarding file listing request// fileListingRequest parameter identifies previous Request sent by MMI to Client // Status parameter contains status informationvoid Client.sendFileListingStatus( Request fileListingRequest, Status );



// (4) startSongPlay function // Client module sends audio MP3 file to MMI module to be played// getSongRequest parameter identifies previous Request sent by MMI to Client void Client.startSongPlay( Request getSongRequest );

// (5) pauseSongPlay function // Client module sends pause request to MMI module because of some non-user event// getSongRequest parameter identifies previous Request sent by MMI to Client void Client.pauseSongPlay( Request getSongRequest );

// (6) restartSongPlay function // Client module sends restart request to MMI module because of some non-user event// getSongRequest parameter identifies previous Request sent by MMI to Client void Client.restartSongPlay( Request getSongRequest );

// (7) stopSongPlay function // Client module sends stop request to MMI module because of some non-user event// getSongRequest parameter identifies previous Request sent by MMI to Client void Client.stopSongPlay( Request getSongRequest );

// (8) startImageDisplay function // Client module sends image JPG file to MMI module to be displayed// getImageRequest parameter identifies previous Request sent by MMI to Client void Client.startImageDisplay( Request getImageRequest );

// (9) pauseImageDisplay function // Client module sends pause request to MMI module because of some non-user event// getImageRequest parameter identifies previous Request sent by MMI to Client void Client.pauseImageDisplay( Request getImageRequest );

// (10) restartImagePlay function // Client module sends restart request to MMI module because of some non-user event// getImageRequest parameter identifies previous Request sent by MMI to Client void Client.restartImageDisplay( Request getImageRequest );

// (11) stopImageDisplay function // Client module sends stop request to MMI module because of some non-user event// getImageRequest parameter identifies previous Request sent by MMI to Client void Client.stopImageDisplay( Request getImageRequest );



2(a). Interface between Client module and Blueberry m-TCP module

__________________________________| Client module ||________________________________ || (1) getConnection(); || (2) closeConnection(); || (3) pollConnection(); || (4) sendData(); || (5) getData(); || (6) ackRequestCloseConnection(); || (7) ackCloseConnection(); || (8) ackPollConnection(); ||________________________________ |

// (1) getConnection function // Client module sends connection request to m-TCP module to establish connection with server// returns Connection object// Server parameter identifies server to connect to// long connectionOptions parameter identifies options for connection // int port parameter identifies port number on Blueberry to use for connection // Login parameter and Password parameter identify identification/authentication information// to be used for connecting with the PCConnection Client.getConnection( Server, long connectionOptions, int port, Login, Password );

// (2) closeConnection function // Client module sends close connection request to m-TCP module// Connection parameter identifies previous connection establishedvoid Client.closeConnection( Connection );

// (3) pollConnection function // Client module sends request to m-TCP module (on server side) for status of connection// return current Status of connection// Connection parameter identifies open connection to be polledStatus Client.pollConnection( Connection );

// (4) sendData function // Client module sends data to m-TCP module for transmittal to server// Connection parameter identifies previous connection established// Data parameter identifies data object to be sent// callbackFunctionPtr parameter specifies optional pointer to callback functionvoid Client.sendData( Connection, Data, *callbackFunctionPtr );

// (5) getData function // Client module sends request to m-TCP module for Server data



// returns Data object// Connection parameter identifies previous connection established// callbackFunctionPtr parameter specifies optional pointer to callback functionData Client.getData( Connection, *callbackFunctionPtr );

// (6) ackRequestCloseConnection function // Client module sends acknowledgement to m-TCP module that CloseConnection request // has been received from Server// Connection parameter identifies connection to be closedvoid Client.ackRequestCloseConnection( Connection );

// (7) ackCloseConnection function // Client module sends acknowledgement to m-TCP module that connection has been closed// Connection parameter identifies connection now closedvoid Client.ackCloseConnection( Connection );

// (8) ackPollConnection function // Client module sends acknowledgement to m-TCP module that PollConnection request received// Connection parameter identifies connection being polled// Status parameter identifies current status of connectionvoid Client.ackPollConnection( Connection, Status );

__________________________________| m-TCP module (Blueberry) ||________________________________ || (1) sendConnectionStatus(); || (2) sendDataTransmitStatus(); || (3) forwardData(); || (4) ackRequestOpenConnection(); || (5) ackOpenConnection(); || (6) ackRequestCloseConnection(); || (7) ackCloseConnection(); || (8) requestData(); ||________________________________ |

// (1) sendConnectionStatus function // m-TCP module sends connection status information to Client module// Connection parameter identifies previous connection established// Status parameter contains status informationvoid m-TCP.sendConnectionStatus( Connection, Status );

// (2) sendDataTransmitStatus function // m-TCP module sends data transmit status information to Client module// Connection parameter identifies previous connection established



// Data parameter identifies data being sent// Status parameter contains status informationvoid m-TCP.sendDataTransmitStatus( Connection, Data, Status );

// (3) forwardData function // m-TCP module forwards server data to Client module// Connection parameter identifies previous connection established// Data parameter identifies data being forwarded// callbackFunctionPtr parameter specifies optional pointer to callback functionvoid m-TCP.forwardData( Connection, Data, *callbackFunctionPtr );

// (4) ackRequestOpenConnection function // m-TCP module forwards this packet to Client module that originates from the Server module// see PC m-TCP module interface for specification

// (5) ackOpenConnection function // m-TCP module forwards this packet to Client module that originates from the Server module// see PC m-TCP module interface for specification

// (6) ackRequestCloseConnection function // m-TCP module forwards this packet to Client module that originates from the Server module// see PC m-TCP module interface for specification

// (7) ackCloseConnection function // m-TCP module forwards this packet to Client module that originates from the Server module// see PC m-TCP module interface for specification

// (8) requestData function // m-TCP module sends request for data to Client module in response to Server getData// returns Data object// Connection parameter identifies client connection this request originated fromData m-TCP.requestData( Connection );



2(b). Interface between PC m-TCP module and Server module

__________________________________| m-TCP module (PC) ||________________________________ || (1) sendConnectionStatus(); || (2) sendDataTransmitStatus(); || (3) forwardData(); || (4) requestOpenConnection(); || (5) openConnection(); || (6) requestCloseConnection(); || (7) closeConnection(); || (8) requestData(); ||________________________________ |

// (1) sendConnectionStatus function // m-TCP module sends connection status information to Server module// Connection parameter identifies previous connection established// Status parameter contains status informationvoid m-TCP.sendConnectionStatus( Connection, Status );

// (2) sendDataTransmitStatus function // m-TCP module sends data transmit status information to Server module// Connection parameter identifies previous connection established// Data parameter identifies data being sent// Status parameter contains status informationvoid m-TCP.sendDataTransmitStatus( Connection, Data, Status );

// (3) forwardData function // m-TCP module forwards client data to Server module// Connection parameter identifies previous connection established// Data parameter identifies data being forwarded// callbackFunctionPtr parameter specifies optional pointer to callback functionvoid m-TCP.forwardData( Connection, Data, *callbackFunctionPtr );

// (4) requestOpenConnection function // m-TCP module forwards this request to Server module to request open connection // after receiving it from Blueberry m-TCP module// see Blueberry m-TCP module for specification

// (5) openConnection function // m-TCP module forwards this request to Server module to open connection // after receiving it from Blueberry m-TCP module// see Blueberry m-TCP module for specification



// (6) requestCloseConnection function // m-TCP module forwards this request to Server module to request closing connection // after receiving it from Blueberry m-TCP module// see Blueberry m-TCP module for specification

// (7) closeConnection function // m-TCP module forwards this request to Server module to close connection // after receiving it from Blueberry m-TCP module// see Blueberry m-TCP module for specification

// (8) requestData function // m-TCP module sends request for data to Server module in response to Client getData// returns Data object// Connection parameter identifies client connection this request originated fromData m-TCP.requestData( Connection );

__________________________________| Server module ||________________________________ || (1) ackRequestOpenConnection(); || (2) ackOpenConnection(); || (3) ackRequestCloseConnection(); || (4) ackCloseConnection(); || (5) ackPollConnection(); || (6) requestCloseConnection(); || (7) closeConnection(); || (8) sendData(); || (9) getData(); || (10) pollConnection(); ||________________________________ |

// (1) ackRequestOpenConnection function // Server module sends acknowledgement to m-TCP module that requestOpenConnection request// has been received// Status parameter identifies availability status of connection // long connectionOptions parameter identifies actual connection options server can use// Sequence parameter identifies starting sequence number for connection// Login parameter identifies account identification/name to be used for authentication// with the Blueberry// Password parameter identifies account authentication/password to be used for authentication// with the Blueberryvoid Server.ackRequestOpenConnection( Status, long connectionOptions, Sequence, Login, Password );



// (2) ackOpenConnection function // Server module sends acknowledgement to m-TCP module that connection is now open// Connection parameter identifies connection opened// Sequence parameter identifies next transmission sequence number// int port parameter identifies port number to use on PC for connection void Server.ackOpenConnection( Connection, Sequence, int port );

// (3) ackRequestCloseConnection function // Server module sends acknowledgement to m-TCP module that CloseConnection request // has been received from Client// Connection parameter identifies connection to be closedvoid Server.ackRequestCloseConnection( Connection );

// (4) ackCloseConnection function // Server module sends acknowledgement to m-TCP module that connection has been closed// Connection parameter identifies connection now closedvoid Server.ackCloseConnection( Connection );

// (5) ackPollConnection function // Server module sends acknowledgement to m-TCP module that PollConnection request received// Connection parameter identifies connection being polled// Status parameter identifies current status of connectionvoid Server.ackPollConnection( Connection, Status );

// (6) requestCloseConnection function // Server module sends request to m-TCP module to close connection // returns Sequence object from client// Connection parameter identifies previous connection to be closedSequence Server.requestCloseConnection( Connection );

// (7) closeConnection function // Server module sends close connection request to m-TCP module// Connection parameter identifies previous connection establishedvoid Server.closeConnection( Connection );

// (8) sendData function // Server module sends data to m-TCP module for transmittal to client// Connection parameter identifies previous connection established// Data parameter identifies data object to be sent// callbackFunctionPtr parameter specifies optional pointer to callback functionvoid Server.sendData( Connection, Data, *callbackFunctionPtr );

// (9) getData function // Server module sends request to m-TCP module for Client data// returns Data object



// Connection parameter identifies previous connection established// callbackFunctionPtr parameter specifies optional pointer to callback functionData Server.getData( Connection, *callbackFunctionPtr );

// (10) pollConnection function // Server module sends request to m-TCP module (on client side) for status of connection// return current Status of connection// Connection parameter identifies open connection to be polledStatus Server.pollConnection( Connection );



3. Custom protocol between Client module and Server module

Step 1: Client module sends repeated getConnection packets to Blueberry m-TCP module as long as Blueberry device is powered on and no connection is currently established with Server module; Server module does not, and cannot request a getConnection from the PC side; getConnection packets contain identification and authentication information to be relayed to the Server module for processing, as well as IP address of the Blueberry device and the port number to be used on the Blueberry;

Step 2: Blueberry m-TCP module opens the port specified by the Client module, and sends a requestOpenConnection packet from this port, to port 909 on any nearby device/IP address every time it receives a getConnection packet from the Client module;

Step 3: when and if the PC m-TCP module receives a requestOpenConnection packet on port 909 it forwards it to the Server module for processing;

Step 4: when and if the Server module receives the requestOpenConnection packet from the PC m-TCP module, it determines whether a connection can be made with the requesting Blueberry device, and sends an ackRequestOpenConnection packet back to the PC m-TCP module in reply, including availability of connection, IP address of PC, and identification and authentication information pertaining to the PC;

Step 5: the PC m-TCP module forwards the Server module ackRequestOpenConnection packet to the originating port on the Blueberry from port 909 on the PC;

Step 6: if Blueberry m-TCP module does not receive reply to its requestOpenConnection then it sends sendConnectionStatus message to Client module indicating Server not found;

Step 7: if Blueberry m-TCP module receives ackRequestOpenConnection reply from PC m-TCP module, then it forwards this packet to the Client module for processing;

Step 8: when and if the Client module receives the ackRequestOpenConnection packet from the Blueberry m-TCP module, it determines whether it wants to make this connection to the PC, and if so sends an openConnection packet to the Blueberry m-TCP module;

Step 9: the Blueberry m-TCP module forwards the Client module openConnection packet to port 909 on the PC;

Step 10: when and if the PC m-TCP module receives an openConnection packet on port 909 it checks first that it is related to a previous set of requestOpenConnection and ackRequestOpenConnection packets, and if so, forwards the openConnection packet to the Server module for further processing;

Step 11: when and if the Server module receives the openConnection packet from the PC m-TCP



module, it determines whether a connection can be made with the requesting Blueberry device, and sends an ackOpenConnection packet back to the PC m-TCP module in reply, including availability of connection, and port number to be used on the PC side;

Step 12: the PC m-TCP module opens the port number specified by the Server module, and forwards the ackOpenConnection packet from this port to the port number on the Blueberry;

Step 13: when and if the Blueberry m-TCP module receives the ackOpenConnection packet, it checks first that it is related to a previous set of requestOpenConnection, ackRequestOpenConnection, and openConnection packets, and if so, advises Client module of either successful or failed connection with sendConnectionStatus packet;

Step 14(a): if Client module needs data from Server module, then it sends getData message to Blueberry m-TCP module for forwarding to the Server module;Step 14(b): if Server module needs data from Client module, then it sends getData message to PC m-TCP module for forwarding to the Client module;

Step 15: if and when either m-TCP module receives a getData message, it forwards it over the open connection to the corresponding m-TCP module on the other end of the connection;

Step 16: if and when either m-TCP module receives a getData packet over the open connection, it forwards it to the corresponding Client or Server module for processing;

Step 17(a): if Client module has data to send to Server module, then it sends sendData message to Blueberry m-TCP module with data to be sent to server over open connection; Step 17(b): if Server module has data to send to Client module, then it sends sendData message to PC m-TCP module with data to be sent to client over open connection;

Step 18(a): Blueberry m-TCP module issues pollConnection to PC m-TCP module at regular intervals to determine state of open connection;Step 18(b): PC m-TCP module issues pollConnection to Blueberry m-TCP module at regular intervals to determine state of open connection;

Step 19: both PC m-TCP and Blueberry m-TCP modules reply, if possible, to all pollConnection packets they receive, with ackPollConnection packets indicating the current state of the connection;

Step 20: if either PC m-TCP or Blueberry m-TCP module do not receive a response from the pollConnection packets they send out, of if they receive ackPollConnection replies indicating any problems with the connection, they send a sendConnectionStatus message back to their corresponding Server or Client module indicating data cannot be transmitted from that moment forward until the connection is re-established successfully;

Step 21(a): Blueberry m-TCP module begins loop of sending one or more sendDataPacket packets to PC corresponding to Client sendData message;



Step 21(b): PC m-TCP module begins loop of sending one or more sendDataPacket packets to Blueberry corresponding to Server sendData message;

Step 22: both Blueberry and PC m-TCP modules reply with ackDataPacket packets to each sendDataPacket packet received;

Step 23: as long as ackDataPacket indicates success, loop back to Step 21 until all requested data has been sent;

Step 24(a): Blueberry m-TCP module sends sendDataTransmitStatus to Client module to indicate either successful or failed transmission of data to PC;Step 24(b): PC m-TCP module sends sendDataTransmitStatus to Server module to indicate either successful or failed transmission of data to Blueberry;

Step 25: if more data is to be transmitted, then loop back to Step 17;

Step 26(a): if Client module is finished with connection to Server, then it sends closeConnection message to Blueberry m-TCP module;Step 26(b): if Server module is finished with connection to Client, it leaves it unchanged;

Step 27: Blueberry m-TCP module sends requestCloseConnection packet to PC in response to receiving closeConnection message from Client module;

Step 28: when and if the PC m-TCP module receives a requestCloseConnection packet it forwards it to the Server module for processing;

Step 29: when and if the Server module receives the requestCloseConnection packet from the PC m-TCP module, it determines whether the connection with the requesting Blueberry device can be closed, and sends an ackRequestCloseConnection packet back to the PC m-TCP module in reply;

Step 30: the PC m-TCP module forwards the Server module ackRequestCloseConnection packet to the originating port on the Blueberry;

Step 31: if Blueberry m-TCP module does not receive reply to its requestCloseConnection then it sends sendConnectionStatus message to Client module indicating connection cannot be closed;

Step 32: if Blueberry m-TCP module receives ackRequestCloseConnection reply from PC m-TCP module, then it forwards this packet to the Client module for processing;

Step 33: when and if the Client module receives the ackRequestCloseConnection packet from the Blueberry m-TCP module, it determines whether it still wants to close this connection to the PC, and if so sends a closeConnection packet to the Blueberry m-TCP module;

Step 34: the Blueberry m-TCP module forwards the Client module closeConnection packet to the PC m-TCP module;



Step 35: when and if the PC m-TCP module receives a closeConnection packet it checks first that it is related to a previous set of requestCloseConnection and ackRequestCloseConnection packets, and if so, forwards the closeConnection packet to the Server module for further processing;

Step 36: when and if the Server module receives the closeConnection packet from the PC m-TCP module, it determines whether the connection with the requesting Blueberry device can still be closed, and sends an ackCloseConnection packet back to the PC m-TCP module in reply;

Step 37: the PC m-TCP module forwards the ackCloseConnection packet from this port to the Blueberry, and then closes the port number on the PC for this connection;

Step 38: when and if the Blueberry m-TCP module receives the ackCloseConnection packet from the PC, it checks first that it is related to a previous set of requestCloseConnection, ackRequestCloseConnection, and closeConnection packets, and if so, closes the port number on the Blueberry, and then sends sendConnectionStatus message to Client module advising it of either successful or failed closing of connection;



4. Test case interfaces required by QMTest framework

The QMTest framework allows for new test cases to be added as new instances of existing test classes through use of the “create” command. In addition, the framework allows new test classes to be created as derived classes of the pre-defined set of test classes if needed.

Creating new instances of existing test classes is done by using the create command as follows:

> qmtest create [ option ... ] test descriptor(i) (ii) (iii)

where:(i) [ option ... ] specifies one or more create command options, as follows:

--id=x where x is the qualified name of the new test to be added to the test database; x is a qualified name means that a hierarchical naming scheme can be used to organize tests into implicit “suites” of tests that can easily be run together if needed; each level of the hierarchy is indicated by use of a “.” (dot) character to separate one level from the next, as in bb.m-tcp where “bb” is a hierarchical level that contains the “m-tcp” test;

--attribute a=b where a is the name of an attribute that is part of the test class, and b is the value to be used for this attribute in this test;

(ii) test specifies the name of a “kind” of “extension” being created (there are other kinds of extensions besides “test” such as “resource”, “target”, “database”, “host”, “suite”, and others);

(iii) descriptor is the qualified name of an existing or new test class along with zero or more attributes associated with it, in the form module.class( attr1=”val”, attr2=”val2” ... ); if the descriptor specifies an existing test class name, then the –attributes and –id options will need to specify new values to identify this new test, such as the following, where a new test named m-tcp is created in the “bb” test hierarchy, as an instance of the command.ExecTest test class, to test execution of the program m-tcp.exe:

> qmtest create –id=bb.m-tcp –attribute program=m-tcp.exe test command.ExecTest

The above example descriptor is command.ExecTest, which references the “ExecTest” test class in the “command” module. It is shown with no parameters, since the –attribute option is used in this case to specify the “program=m-tcp.exe” parameter. This command could have been run in the following way with the same effect:

> qmtest create –id=bb.m-tcp test command.ExecTest( program=”m-tcp.exe” )

The qmtest create command returns the value 0 if successful, or 2 if unsuccessful. After being created, the “run” command is used to execute/run the test, as follows:

> qmtest run bb.m-tcp



Running all tests in the “bb” test hierarchy would be done as follows:

> qmtest run bb.

If a specific “suite” of tests was to be run that included tests from multiple test hierarchies, then that test suite would need to be created using the following “create” command format:

> qmtest create –id=nightly suite explicit_suite.ExplicitSuite( ... )(i) (ii) (iii)

where:(i) --id=nightly is the name assigned to this test suite;

(ii) suite specifies what is being created;

(iii) explicit_suite.ExplicitSuite( ... ) specifies the built-in class used to identify all the test id's and suite id's that are to be pulled together into this suite;

The ... optional parameters used would be as follows:The test_ids parameter specifies a list of zero or more test id's to be included in this suite, as for example: test_ids=“['bb.client.m-tcp', 'bb.server.m-tcp']”;

The suite_ids parameter specifies a list of zero or more suite id's to be included in this suite, as for example: suite_ids=“['bb.mmi']”;

Running such a test suite would be done as follows:

> qmtest run nightly

Note: The QMTest framework also includes an optional graphical user interface, that can be used instead of the command line interface shown above.



PART 2 – Testing

1. Test Cases for Two Functional Requirements

(a) Testing Functional Requirement: “The software shall be able to download a MP3 file from the PC and play it back for preview.”

Step 1: Establish WiFi connection from Blueberry to PC.Step 2: Maintain same proximity to PC during course of this test.Step 3: Ensure no other Blueberry device users are connected to the PC during course of this test.Step 4: Select “Browse” menu item on the Blueberry screen.Step 5: Select MP3 file name from list of files shown on Blueberry screen.Step 6: Select “Preview” menu item on the Blueberry screen.Step 7: Wait for MP3 file to begin downloading to Blueberry.Step 8: Wait for MP3 file to automatically start to play.

Expected Results:The MP3 file will start to play, as evidenced by the audio signal coming from the Blueberry into the ear buds plugged into the “audio out” jack.Also, the MP3 file will play until completion of “preview” session.

(b) Testing Functional Requirement: “The software shall complete saving a picture to memory in under 1 second.”

Step 1: Have JPEG image displayed on Blueberry screen.Step 2: Select “Save” menu item on Blueberry screen.Step 3: Specify location on Blueberry storage file system where image file is to be saved.Step 4: Start timer to mark beginning of file save.Step 5: Wait for file to be saved.Step 6: Stop timer to mark ending of file save.

Expected Results:Timer will show less than 1 second to complete saving of file.



2. Test Case for MP3 Playback Use Case Scenario

Testing MP3 Playback Use Case Scenario.

Step 1: Select “Play” menu on the Blueberry screen.Step 2: Wait for Play application to fetch list of song files stored on Blueberry.Step 3: Wait for list of songs to show on Blueberry screen.Step 4: Select entry from list of songs shown on Blueberry screen.Step 5: Wait for song file to be retrieved from Blueberry database.Step 6: Wait for “in-progress” display to appear on the Blueberry screen.Step 7: Listen to audio coming from Blueberry “audio out” jack.Step 8: Wait for finish of audio signal.Step 9: Look for “in-progress” display to be removed from the Blueberry screen.Step 10: Look for Blueberry screen to show main menu.

Expected Results:The selected MP3 file will be played, from start to completion, as evidenced by the audio signal coming from the Blueberry into the ear buds plugged into the “audio out” jack.Also, the “in-progress” display will be shown on the Blueberry screen while the MP3 file is playing, but not after the song has finished playing.



PART 3 – Software Configuration Management (“SCM”)

1. Subversion command to add a new configuration item into the archive, the command to check out the item, and the command to check in the item:

(a) “svn import” is the Subversion command used to add a new configuration item into the archive. It is typically used with just 2 parameters as follows:

> svn import abc xyz(i) (ii)

where:(i) abc is the name of the configuration item to be added to the archive, such as filename.cpp or /home/src/blueberry

(ii) xyz is the URL associated with the (pre-existing) archive, such as file:///home/svn/project_blueberry or https://sub.domain.com/svn/project_blueberry or svn+ssh://sub.domain.com/svn/project_blueberry

(b) “svn checkout” is the Subversion command used to check out the item. It is typically used in order to checkout the latest revision of the entire archive, to a local working copy, as follows:

> svn checkout xyz abc(i) (ii)

where:(i) xyz is the same as the second parameter in the svn import command, specifying the URL associated with the archive;

(ii) abc is the location/directory of the local working copy;

(c) “svn commit” is the Subversion command used to check in the item. It is typically used as follows:

> svn commit

This updates the archive with any changes that have been made to the local working copy. Conflicts that may exist at the time of the commit are highlighted to ensure integrity of the archive.


https://sub.domain.com/svn/project_blueberry


2. Subversion main commands used by developers to work in parallel on the same project and files:

(a) “svn checkout” is the Subversion command used by each developer to create a local working copy of the project files. It is typically used in order to checkout the latest revision of the entire archive as follows:

> svn checkout xyz abc(i) (ii)

where:(i) xyz is the URL associated with the archive;

(ii) abc is the location/directory of the local working copy;

(b) “svn status” is the Subversion command used by each developer to list the status of any changes they have made to their local working copies:

> svn status -u -v

The -u parameter ensures that the status information also includes information about the archive, and not just about the local working copy. In this case, if a file in the archive has been changed by someone else, this will also be shown. The -v parameter provides more verbose output.

(c) “svn diff” is the Subversion command used by each developer to produce a “unified diff” format listing of any and all changes they have made to their local working copies:

> svn diff

(d) “svn add” is the Subversion command used by each developer to add a new file or directory to their local working copy:

> svn add abc(i)

where:(i) abc specifies the name of the new file or directory;

(e) “svn move” is the Subversion command used by each developer to move a file or directory in their local working directory to a new location:

> svn move abc def (i) (ii)

where:



(i) abc specifies the name of the source file or directory to be moved;

(ii) def specifies the name of the destination file or directory;

(f) “svn copy” is the Subversion command used by each developer to copy a file or directory in their local working directory to a new location:

> svn copy abc def (i) (ii)

where:(i) abc specifies the name of the source file or directory to be copied;

(ii) def specifies the name of the destination file or directory;

(g) “svn delete” is the Subversion command used by each developer to delete a file or directory from their local working copy:

> svn delete abc(i)

where:(i) abc specifies the name of the deleted file or directory;

(h) “svn update” is the Subversion command used by each developer to update their local working copies with the latest revision from the archive. This ensures that each developer is working with the latest revisions of files that have been committed to the archive by other developers. It also ensures that changes committed by other developers to the same files as those in the local working directory are automatically merged into the local working copies as much as possible. Any conflicts between local working copy changes and other developers' changes are automatically flagged for resolution when they cannot be resolved automatically:

> svn update

(i) “svn resolve” is the Subversion command used by each developer to resolve conflicts between the archive and their local working copy. Commits will not be allowed as long as their are conflicts:

> svn resolve --accept x abc(i) (ii)

where:(i) --accept x specifies which of the conflicting files should be accepted over the other;

(ii) abc specifies the name of the conflicting file;



(j) “svn revert” is the Subversion command used by each developer to abandon any changes they have made to their local working copy of a file. Once “reverted” there would be no need to “resolve” the file:

> svn revert abc(i)

where:(i) abc specifies the name of the file to be reverted;

(k) “svn commit” is the Subversion command used by each developer to merge changes they have made to their local working copies back into the archive:

> svn commit


BCIT COMP 7081 Assignment 2 by Wesley Kenzie March 2010

Documents

Transcript of BCIT COMP 7081 Assignment 2 by Wesley Kenzie March 2010