COMP 2404 Fall 2019 Assignment 4
Due Wed Dec 4 by 10:00pm in Culearn.
Assignment Submissions Instructions: Assignments must be submitted via culearn by the due date and time. Late assignments will not be accepted. See the Development Process Requirements below for what exactly to submit and how.
You may work on assignments in pairs if you want, in which case only one copy should be submitted with both your names on the files and in the ReadMe.txt file. If neither submits (because, for example, they thought the other one would) both get a mark of 0.
Revisions:
Rev 1 [Nov 21] fixed typo in FR4.2:
follow -u userid -playlist_name -f stop
Should this be:
follow -u userid -p playlist_name -f stop
Categorization of Assignment Requirements
All assignments in this course will be based on itemized and categorized requirements. There will be four categories of requirements: Process Requirements, Functional Requirements, System Requirements, and Domain Requirements.
Process requirements (aka Software Engineering Requirements, Development Process Requirements, Good Practice Requirements) are requirements imposed by the software development process that is being followed by the developers. Here they include the requirements on how to submit your assignments successfully and have them marked. They do not have anything to do with the specific application being developed but rather pertain to the development process that is being used. They include the requirements that reflect how your assignment will be tested and marked. In assignments you will not get marks for meeting process requirements, instead you lose marks if they are not met -in some cases ALL of your marks.
Functional, System, and Domain requirements all pertain to the actual application being developed. Collectively these are referred to as the Design Requirements. In assignments you will get marks for those design requirements that are met. So the number of these requirements determine what the assignment will be marked out of.
Functional Requirements (aka User Requirements) pertain to what the user wants to do with the app and how it is to be operated. If a functional requirement is not met one would expect a user or client to notice that. The wording of functional requirements should make sense to the intended user or client. They should not contain references to “objects” in the object-oriented programming sense.
System Requirements (aka Constraints) are requirements imposed on the developer to make the development profitable (or evolvable, or resuable, …). If a system requirement is not met the user, or client, of the app would likely not be aware of that. For example, the user of your app is not aware of whether you used objects to implement it or not. System requirements can make reference to “objects” in the object-oriented programming sense because the developers understand that.
Domain Requirements (aka Legal Requirements) are requirements imposed by the domain, or demographic, in which your app is intended to operate. For example, if you are making a PG13 movie about object-oriented development then the requirements that must be met for a movie to be considered PG13 are domain requirements. (Treating people as objects might be considered inappropriate for a young audience; treating objects as people will likey garner an R-rating.)
It will be an ongoing challenge in the course to fit requirements into one of the four categories or determine if there is an important missing category. In real life there are often many more requirement catagories.
Marking: This assignment is based on 13 design requirements numbered FR4.1…SR4.13 for a total of 26 marks.
Marks are awarded, or deducted, based on formalized requirements as follows:
Req Type
Assignment Grading
R0.x
Critical Submission and Intent Requirements (Process Requirements). Assignment gets 0 if any critical submission
requirement (shown in red) is not met.
R0.x
Good Practice Requirements (Process Requirements). You lose 2 marks for each good practice
requirement (shown in amber) not met.
Rx.x
Design Requirements. You earn 2 marks for each design requirement (green) satisfied and well implemented; 1 mark if it’s partly met or met but not well implemented; and 0 if it’s not met or attempted.
Rx.x
Out of Scope Requirements. Requirements that are not coloured pertain to the project as a whole be are not being evaluted in this scope (assignment).
Development Process Requirements
The following requirements will pertain to all your assignments regardless of what your application is supposed to do (i.e. regardless of the design requirements). These requirements are intended to ensure that your code is readable and maintainable by other programmers (or markable by TA’s in our case), robust (it does not crash from bad pointer references or memory allocation problems), and follows good object-oriented programming practice. You will lose 2 marks from your total assignment mark for each of the following requirements that is not satisfied. However if you do not satisfy requirement PR0.1, PR0.2 or PR0.3 you will get zero for the assignment mark.
PR0.1 [Assignment mark = 0 if not met] UNIQUENESS REQUIREMENT. The solution and code you submit MUST be unique. That is, it cannot be a copy of, or be too similar to, someone else’s assignment, or code found elsewhere. A mark of 0 will be assigned to any assignment that is judged by the instructors or the TA’s not to be unique.
You are, however, free to use any code posted on our course web (e.g. notes, sample code, tutorial demo code and answers) as part of you assignment solutions.
PR0.2 [Assignment mark = 0 if not met] CODE SUBMISSION REQUIRMENTS: For the purposes of assignments your code and supporting documents must be submitted to culearn and comply with the following.
1) You should submit C++ source code file and any supporting script files, documentation files required and, when appropriate the associated make file to assist the compilation. Your name and student number should be at the top of each file. There should always be a ReadMe.txt file with your assignment. If you are working with a partner, both names and student numbers must appear on the files and only submit one copy of the assignment to culearn.
2) COMPRESSION If your assignment files are compressed we will accept only .tar, .tar.gz, or .zip format compatible with one of the following three linux commands for extraction:
tar -xvf filename.tar
tar -xvf filename.tar.gz
unzip filename.zip
3)ReadMe.txt: Your assignment must be accompanied by a ReadMe.txt file in which the following should appear:
-Which extraction command should be used to uncompress your assignment files.
-Which g++ compiler command should be executed to compile your code.
-Instructions on what script, or scripts to run to demonstrate your testing.
4) In general you should provide a testing script, or main program that runs appropriate test cases to demonstrate that the design requirements are being met. (Not all requirements can be demonstrated like that, but functional requirements usually can be -especially if we are building command line applications.)
PR0.3 [Assignment mark = 0 if not met] CODE COMPILATION and TESTING:
The TA must be able to compile your code using the g++ compiler installed in our 2401-F19.ova virtual box linux image. (A current gcc installation should be compatible with that, but you should check.). The TA will run the g++ command specified in your ReadMe.txt file and when compiling is complete run your exectuable to begin verifying the assignment requirements. If your code cannot be compiled as described the assignment mark will be zero. (The TA’s will not debug your code in an effort to get it to compile.)
PR0.4 CODE ORGANIZATION: Your code files should contain only one .cpp file containing the substring “main” in the title and that file should have the int main() entry point function for your code. Your object-oriented classes should each be represented in two files classname.h and classname.cpp. The .h header files should contain only type declarations and not executable code (method bodies).
PR0.5 VARIABLE AND FUNCTION NAMES: All of your variables, methods and classes should have meaningful names that reflect their purpose. Do not follow the convention in math courses where they say things like: “let x be the number of customers and let y be the number of products…”. Instead call your variables numberOfCustomers or numberOfProducts. Your program should not have any variables called “x” unless there is a good reason for them to be called “x”. (One exception: it’s OK to call simple for-loop counters i,j and k etc. when the context is clear and VERY localized.)
PR0.6 MEANINGFUL CONSTANT NAMES: Constant values should have meaningful names and not just be represented as numbers or strings in expressions. For example don’t say: cin.getline(input, 80); rather say: cin.getline(input, MAX_INPUT_LENGTH);
PR0.7 VARIABLES: All instance variables in your classes should be private, unless a specific design requirements asks for them to be public (which is unlikely). It is good programming practice to design objects that provide services to others through their public methods. How they store their variables is their own private business. C or C++ unbounded arrays should not be used as public data structures. They should be encapsulated in a class which takes care of their length or number of elements. Also methods used soley by a class for its own housekeeping, and which are not considered part of the public inteface, should be in the private section of a class.
Your code should not be coupled through global variables. That is, objects should not communicate through the existance of global variables. Instead pass appropriate objects through constructor parameters.
PR0.8 ROBUSTNESS REQUIREMENTS: Your program should not crash when the TA is marking it because of a bad pointer dereferences, out of bounds error memory access, or memory leaks or double deletions. We get especially annoyed by out of bounds “off by one” errors! Your code should not have any memory leaks or double deletions. Moreover the heap memory should be empty when your procedure main() returns. That is, all heap objects should be properly deleted before the program exits.
PR0.9 COMMENTING REQUIREMENTS: Comments in your code must coincide with what the code actually does. It is a common bug for people to modify code and forget to modify the comments and so you end up with comments that say one thing and code that actually does another. Don’t use comments to clarify poor variable or method names -instead choose good variable names and method names that makes the code more “self-commenting”.
PR0.10 OUTPUT LABELING REQUIREMENTS: Your programs output must have sufficient comments or remarks so that the output can understood. Don’t have your program just write out a bunch of integers with no indication of what they mean or what the test they supposedly demonstrate. The TA’s should be able to read and understand your output WITHOUT having to look at your code to see what the output means. It is a good idea to refer specifically to the numbered design requirements in your output to help indicate which requirement you are demonstrating.
VERY IMPORTANT:
Requirements tend to make sense to the person who wrote them because that person knows what they were trying to say. You don’t know what they were trying to say, only what they actually did say. So you need to ask lots of questions when things are not clear. A picture is worth a thousand words and a requirement fix is worth a thousand programing fixes.
Any sample code fragments provided with assignments might have bugs (although none are put there intentionally). It is part of your job to identify errors in the code and in the requirements and seek clarification.
Assignment 4: Synchronized Behaviour Based on Gamma Patterns
Please be aware of the following relationship between Refactoring, Design Patterns and Design Experience. Design Patterns can be thought of as Refactorings, that is, better ways to solve problems that were being solved in other ways. Once learned however, these refactorings become the way you might solve the problem in the first place -it becomes part of your design experience. These days the Gamma patterns, like the Observer Pattern, are used to solve the problem in the first place. The refactorings have become part of the experience passed down to others. So refactoring is how we discover better ways so solve problems and then by documenting them as patterns they become part of our catalog of design techniques much the way that algorithms and data structures passed on experience to procedure-oriented designers.
Scope
A new client has seen the prototypes you have built, especially the Assignment 2 version. They are interested in having you adapt the product to their requirements. Here is a their scenario:
A client representing group of musicians wants you to adapt your prototype so they can use it to manage setlists during rehearsals and performances. Setlists are lists of songs that are meant to be performed together in the order they are listed. They want to use our playlists as their setlists. (From here on we will use the terms setlist and playlist interchangeably.)
They want us to add a new functional capability to the code developed so far and we will base our solution on the Gamma Observer Pattern. You can base your solution on any code base: your A2 or A3 solution or solutions we might post for A2 or A3. Your solution for this assignment need NOT include the persistent storage of database -but can use it if you prefer. That is, we are forking a new product for a new client and it can be forked from either the Assignment 2 or Assignment 3 state of the current product.
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 band 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 follow the changes made to another member’s setlist. They’ve requested we add commands that lets band members have their setlists follow the contents of another member’s setlist. Specifically, they want you to implement the following new command:
follow -u userid -p playlist_name -f userid2
for example:
follow -u ajones -p brass_monkey_set1 -f cindy
In which case ajones’s brass_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 brass_monkey_set1 setlist ajones’s setlist of the same name will automagically update to be the same. Changes would pertain to adding, removing tracks and reordering tracks. For setlists it is necessary that tracks be in a particular orderd.
The command
follow -u ajones -p brass_monkey_set1 -f stop
Should cause ajones’s brass_monkey_set1 setlist to stop following that of another user.
By the way there are several iPad apps (Forscore, Newzic 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
You must provide a testing script that the TA’s can run (i.e .read) that demostrates all of the requirements. You will only get marks for those requirements tested in your script but the TA’s will interact with your application through the command line interface as well to run additional tests. Your README.txt file must tell us how to run your script.
FR4.1) The application should provide the command:
follow -u userid -p playlist_name -f userid2
Which should cause userid’s playlist playlist_name to have exactly the same contents as a similarly named playlist of userid2. The users must still have their own separate setlists -that is, you cannot just “point” both users to the same list.
FR4.2) The application should provided the command:
follow -u userid -p playlist_name -f stop
It should cause userid’s playlist playlist_name to stop following changes of another user. The users must still have their own separate setlists -that is, you cannot just “point” both users to the same list.
FR4.3) If changes are made to a playlist this is being followed then those changes should be reflected right away in playlists that are followers. The followers must have their own setlists -that is, you cannot just “point” followers to another user’s setlist.
FR4.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.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.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.7) Users should be able to follow more than one playlist. That is, several of their playlists could be following playlists of other users. (But each playlist can only follow one other list though.)
FR4.8) Playists should be able to have more than one follower.
FR4.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.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.11) The implementation of the follow command should be based on the Gamma Observer Pattern.
SR4.12) The implementation should make use of Subject and Observer abstract superclasses and make use of methods with names that correspond as closely as possible to the method protocol of the Gamma et al Observer pattern.
SR4.13) The implementation should maintain separate playlists for each user. That is, that ability of a user to follows the setlist of another should not be implemented by simply having several user objects point at the same setlist. The user objects should still have their own copies of setlists. (A long term goal is to have the users setlists be on different devices and have the observer pattern operate over a wifi or bluetooth network.)
Reviews
There are no reviews yet.