BCIT COMP 7081 Assignment 2 by Wesley Kenzie March 2010

BCIT Computer Systems Technology
COMP 7081 Technical Issues in Software Development

Assignment 2
Author: 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. Page 1 of 22
Assignment 2
______________________________________________________________________________
// returns Status object

// Request requestObject parameter identifies previous Request
Status 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 information
void 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
void 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
void 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
void Client.sendFileListingStatus( Request fileListingRequest, Status );
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
// (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
void Client.pauseSongPlay( Request getSongRequest );
// (6) restartSongPlay function

// Client module sends restart request to MMI module because of some non-user event
void Client.restartSongPlay( Request getSongRequest );
// (7) stopSongPlay function

// Client module sends stop request to MMI module because of some non-user event
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
void Client.pauseImageDisplay( Request getImageRequest );
// (10) restartImagePlay function

// Client module sends restart request to MMI module because of some non-user event
void Client.restartImageDisplay( Request getImageRequest );
// (11) stopImageDisplay function

// Client module sends stop request to MMI module because of some non-user event
void Client.stopImageDisplay( Request getImageRequest );
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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 PC
Connection 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 established
void 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 polled
Status Client.pollConnection( Connection );
// (4) sendData function

// Client module sends data to m-TCP module for transmittal to server
// Data parameter identifies data object to be sent
void Client.sendData( Connection, Data, *callbackFunctionPtr );
// (5) getData function

// Client module sends request to m-TCP module for Server data
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
// returns Data object

Data 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 closed
void Client.ackRequestCloseConnection( Connection );
// (7) ackCloseConnection function

// Client module sends acknowledgement to m-TCP module that connection has been closed
// Connection parameter identifies connection now closed
void 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 connection
void Client.ackPollConnection( Connection, Status );
__________________________________
| m-TCP module (Blueberry) |
|___________________________ _____ |
| (2) sendDataTransmitStatus(); |
| (3) forwardData(); |
| (4) ackRequestOpenConnection(); |
| (5) ackOpenConnection(); |
| (8) requestData(); |
|________________________________ |

// m-TCP module sends connection status information to Client module
void m-TCP.sendConnectionStatus( Connection, Status );
// (2) sendDataTransmitStatus function

// m-TCP module sends data transmit status information to Client module
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
// Data parameter identifies data being sent

void m-TCP.sendDataTransmitStatus( Connection, Data, Status );
// (3) forwardData function

// m-TCP module forwards server data to Client module
// Data parameter identifies data being forwarded
void 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



// (8) requestData function

// m-TCP module sends request for data to Client module in response to Server getData
// Connection parameter identifies client connection this request originated from
Data m-TCP.requestData( Connection );
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
2(b). Interface between PC m-TCP module and Server module
__________________________________
| m-TCP module (PC) |
|________________________________ |
| (2) sendDataTransmitStatus(); |
| (3) forwardData(); |
| (4) requestOpenConnection(); |
| (5) openConnection(); |
| (6) requestCloseConnection(); |
| (8) requestData(); |
|________________________________ |

// m-TCP module sends connection status information to Server module
void m-TCP.sendConnectionStatus( Connection, Status );
// (2) sendDataTransmitStatus function

// m-TCP module sends data transmit status information to Server module
// Data parameter identifies data being sent
void m-TCP.sendDataTransmitStatus( Connection, Data, Status );
// (3) forwardData function

// m-TCP module forwards client data to Server module
// Data parameter identifies data being forwarded
void 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
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
// (6) requestCloseConnection function

// m-TCP module forwards this request to Server module to request closing connection

// m-TCP module forwards this request to Server module to close connection
// (8) requestData function

// m-TCP module sends request for data to Server module in response to Client getData
// Connection parameter identifies client connection this request originated from
Data m-TCP.requestData( Connection );
__________________________________
| Server module |
|________________________________ |
| (1) ackRequestOpenConnection(); |
| (2) ackOpenConnection(); |
| (5) ackPollConnection(); |
| (6) requestCloseConnection(); |
| (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 Blueberry
void Server.ackRequestOpenConnection( Status, long connectionOptions, Sequence, Login,
Password );
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
// (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 );

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

// Server module sends acknowledgement to m-TCP module that connection has been closed
// Connection parameter identifies connection now closed
void 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 connection
void 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 closed
Sequence Server.requestCloseConnection( Connection );

// Server module sends close connection request to m-TCP module
void Server.closeConnection( Connection );
// (8) sendData function

// Server module sends data to m-TCP module for transmittal to client
// Data parameter identifies data object to be sent
void Server.sendData( Connection, Data, *callbackFunctionPtr );
// (9) getData function

// Server module sends request to m-TCP module for Client data
______________________________________________________________________________
Assignment 2
______________________________________________________________________________

Data 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 polled
Status Server.pollConnection( Connection );
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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;
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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;
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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;
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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;
test specifies the name of a “kind” of “extension” being created (there are other kinds of
(ii)
extensions besides “test” such as “resource”, “target”, “database”, “host”, “suite”, and others);
descriptor is the qualified name of an existing or new test class along with zero or more
(iii)
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
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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;
explicit_suite.ExplicitSuite( ... ) specifies the built-in class used to identify all the test id's and
(iii)
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.
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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.
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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.
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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.
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
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:
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
(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;
______________________________________________________________________________
Assignment 2
______________________________________________________________________________
(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

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BCIT COMP 7081 Assignment 2 by Wesley Kenzie March 2010

Diunggah oleh

Hak Cipta:

Format Tersedia

BCIT Computer Systems Technology

COMP 7081 Technical Issues in Software Development

March 22, 2010

This assignment builds on Assignment 1 and demonstrates the use of

(1) high-level design ............................................... page 1

PART 1 – High-Level Design

1. Interface between MMI module and Client module

// (1) sendUserRequest function

// (2) getRequestStatus function

// returns Status object

// (3) sendRequestStatus function

// (1) sendConnectionStatus function

// (2) sendFileTransferStatus function

// (3) sendFileListingStatus function

// (4) startSongPlay function

// (5) pauseSongPlay function

// (6) restartSongPlay function

// (7) stopSongPlay function

// (8) startImageDisplay function

// (9) pauseImageDisplay function

// (10) restartImagePlay function

// (11) stopImageDisplay function

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

// (1) getConnection function

// (2) closeConnection function

// (3) pollConnection function

// (4) sendData function

// (5) getData function

// returns Data object

// (6) ackRequestCloseConnection function

// (7) ackCloseConnection function

// (8) ackPollConnection function

// (1) sendConnectionStatus function

// (2) sendDataTransmitStatus function

// Data parameter identifies data being sent

// (3) forwardData function

// (4) ackRequestOpenConnection function

// (5) ackOpenConnection function

// (6) ackRequestCloseConnection function

// (7) ackCloseConnection function

// (8) requestData function

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

// (1) sendConnectionStatus function

// (2) sendDataTransmitStatus function

// (3) forwardData function

// (4) requestOpenConnection function

// (5) openConnection function

// (6) requestCloseConnection function

// (7) closeConnection function

// (8) requestData function

// (1) ackRequestOpenConnection function

// (2) ackOpenConnection function

// (3) ackRequestCloseConnection function

// (4) ackCloseConnection function

// (5) ackPollConnection function

// (6) requestCloseConnection function

// (7) closeConnection function

// (8) sendData function

// (9) getData function

// Connection parameter identifies previous connection established

// (10) pollConnection function

3. Custom protocol between Client module and Server module

Step 7: if Blueberry m-TCP module receives ackRequestOpenConnection reply from PC m-TCP

Step 27: Blueberry m-TCP module sends requestCloseConnection packet to PC in response to