Reference no: EM131731401

Part I - Scope

For Part I we want you to add a new functional capability to the code developed so far and base your solution on the Gamma Observer Pattern. You can base your solution on any code base: your A2 or A3 solution or our solutions for A2 or A3. Your solution for this assignment need NOT include the refactoring done in assignment #3 (That is, you can go back to your assignment A2 code if you want.)

Here is a the scenario:

A group of musicians have seen our playlist app and want to use it to manage their setlists during rehearsals and performances. Setlists are lists of songs that are meant to be performed together. They intend use our playlists as their setlists. (From here on we will use the terms setlist and playlist interchangeably.)

The musicians often have a situation where one band member makes changes to a setlist that must be reflected in the same setlist of other members. In this scenario each musician (user) has their own copy of a setlist. So they want the application to be modified so that band members can have their setlists following the changes made to another member's setlist. The new feature that they have requested is a command and behaviour that lets band members have their setlists follow the contents of another member's setlist. They want you to implement the following new command (or your version of the command based on your applications language).

follow -u userid -p playlist name -f userid2 for example:

follow -u ajones -p brass monkey setl -f cindy

In which case ajones's bras s_monkey_set1 setlist would be updated to reflect the contents of a similiarly named setlist owned by cindy. Whenever user cindy makes a change to her setlist ajones's setlist will automagically update to be the same. Changes would pertain to adding and removing tracks.

The command

follow -u ajones -p brass monkey setl -f stop

Should cause aj ones's brass_monkey_seti setlist to stop following that of another user.

By the way there are several iPad apps (Forscore, Newzip for example) that lets orchestras have lists of pdf scores and have the feature that a users can have their score follow that of the orchestra conductor. These apps also seem to be using the "follower" protocol for keeping scores in synch.

Functional and System Requirements for Part I -

You must provide a testing script that the TA's can run that demostrates all of the requirements. You will only get marks for those requirements tested in your script. Your README.txt file must tell them how to run the script.

FR4.1.1) The application should support a command similar to:

follow -u userid -p playlist name -f userid2

Which should cause useridIS playlist playlist_name to have exactly the same contents as a similarly named playlist of userid2.

FR4.1.2) A command similar to

follow -u userid -playlist name -f stop

Should cause useridIS playlist playlist_name to stop following changes of another user.

FR4.1.3) If changes are made to a playlist being followed then the changes should be reflected right away in playlists that are followers.

FR4.1.4) The code should withstand users trying to mutually follow each others similarly titled playlists. Withstand means you must either accommodate it or prevent it from happening. The code should not crash because two users tried to mutually follow each other's playlists of the same name.

FR4.1.5) The code should withstand a user trying to follow their own playlist. Withstand means you must either accommodate it or prevent it from happening. The code should not crash because a user tried to follow one of their own playlists.

FR4.1.6) The code should withstand a user trying to follow a non existing playlist. Withstand means you must either accommodate it or prevent it from happening. The code should not crash because a user tried to follow another user who does not have a playlist of the right name.

FR4.1.7) Users should be able to follow more than one playlist. That is, several of their playlists could be following playlists of other users.

FR4.1.8) Playists should be able to have more than one follower.

FR4.1.9) If a user's playlist is deleted then followers of that list must not be left "dangling". They must be properly deregistered as followers.

FR4.1.10) If a user's playlist is deleted then it must be deregistered from any list it is following. The list being followed must not be left "thinking" that it still has the follower.

SR4.1.1) The implementation of the follow command should be based on the Gamma Observer Pattern.

SR4.1.2) The implementation should make use of subject and observer abstract superclasses and make use of methods with names that correspond as closely as possible with the method protocol of the Gamma observer pattern.

SR4.1.3) The implementation should maintain separate playlists for each user. That is, if a user follows the playlist of another that should not be implemented by simply having several user objects point at the same playlist object. The user objects should still have their own copies of playlists. (A long term goal is to have the users playlists be on different devices and this observer pattern would operate over a wifi or bluetooth network.)

Part II -

In Part II you have a opportunity to analyse a scenario and express it in terms of functional, system or domain requirements and then implement it. You are asked to capture the scenario in eight requirements and then implement those requirements. To get the marks you have to actually implement the requirements, just writing the requirements will not count for any marks.

For any scenario below write 8 requirements in such a way that you think best captures what is needed and then implement them. You will be judged on your selection on requirements and how well they are chosen to reflect the scenario. You should categorize your requirements as either Functional, System or Domain requirements (use FR, SR, DR numbering scheme.)

Persistent Database Store

For this scenario we want the app to connect to and initialize itself from the beatles.db sqlite database. Any changes made by users should be communicated and reflected in the actual sqlite database itself. When the app is relaunched it should initialize from the current state of the sqlite database. That is, the database will persistently keep the state of the application.

Changes made by users should be reflected in the database right away, not just when the app exits. So this programming exercise is to have your c++ code talk to the sqlite database through its c++ programming interface. We will likely do some examples in class for programming this.

Searching for Songs, Tracks etc.

Any application with a lot of string based data (e.g. song titles) should have a search capability. In this scenario we want you to build a search capability into the app that would let you search for any data items that have titles (e.g. songs). The search features should have the following properties:

Search should not be case sensitive.

Search should ignore punctuations (e.g. Take the "A" Train should match Take the A Train)

Search should allow "*" to represent 0 or more arbitrary characaters. "*Girl * Ip*" should match "The Girl From Ipanema"

Search should allow "I" character. ("Ipanema I Girl I From " should match any title that has those three words in any order)

Ordering Playlist Tracks

The tracks that appear on playlists are meant to be ordered. In this scenario we want you to provide the capability (commands) that would allow a user to order the tracks on their playlists. Users are not likely going to want alphabetical order rather they will want to manually order the tracks in any order they like. This is especially important for the scenario in Part I where the playlists are being used for performance setlists. Manual ordering using a command line interface will be a challenge because that style of interface does not lend itself to, say, dragging things to there desired position. Come up with something you think will work well and not be awkward to use.

Attachment:- Assignment Files.rar