CPSC 211  Term Project
Part 2: Designing a Music Library Application

DUE:  Tuesday, July 6 at 20:00

Contents


Assignment Overview

In part two of the project (aka assignment two), you will continue work towards building a music library application. In this part of the project, you will design the core parts of the application (we will give you the class breakdown). The objectives of part two of the project are to:

  • provide experience with designing the relationships between classes to form a specified system
  • provide experience with specifying the attributes and methods of those classes

As with part one of the project, you are encouraged, but not required, to work with a partner.

Requirements for the Music Library Application

The music library application will run on a single computer and will be accessible to a single user. There will only be a single Library of music.

All Songs contain a title, a path to the associated MP3 file on the disk (e.g., "C:\My MP3s\Ode to Joy.mp3"), and a track number. Songs are uniquely identifiable by MP3 file path; no two Songs can exist that reference the same MP3 file. Songs should be associated with Artists, Albums and the Library.

Artists have a name. No distinction will be made between individuals and groups (e.g., "Michael Jackson" and "The Jackson 5" are both valid Artists). Artists are uniquely identifiable by name. No two artists can have the same name.

Albums are a collection of Songs, ordered by track number (where each song on an album has a different track number) – and will store the album title. In addition, there will be at least one album in the system at all times (a "default" album) and every song must be associated with a single album. Any song for which the user has not entered an album will belong to the default album. Albums are uniquely identified by name.

There will be a single Library which contains collections of Albums, Songs, and Artists. A careful design of the associations between these four classes will be required in order to meet the following functional requirements. Your program must allow the user to:

  • View a list of all the songs in the library and see information about each song, including the album on which it appears and the artist(s) who performed it.
  • View a list of all the artists in the library.
  • View a list of all the albums in the library.
  • Edit any information in the library. This includes changing the title of songs and albums and changing the names of artists.
  • View a list of all the songs by a particular artist.
  • View a list of all the songs on a particular album.
  • Add songs to and remove them from the library.
  • Add artists to and remove them from songs.
  • Add songs to and remove them from albums.
You can certainly imagine additional features that would be useful in a music library management application. As long as you meet the above requirements, go ahead and add some more features!

For the design you are asked to complete, you will not be considering the user interface for the system (that will come in a later part of the project).  You will also not be considering the library that handles the playback of your MP3s. Focus on the attributes and methods that are needed to provide the functionality described above.

Deliverable: Design

Your deliverable for this part of the project is to complete a design for the system that provides the functionality described above. Your design will consist of the following parts:
  • A  UML class diagram which will show the classes and their relationships. You don't need to show the class components in this diagram. Just show the classes by their names and draw the relationships among them. For each relationship make sure you have indicated its direction (unidirectional or bidirectional) and its multiplicities (1 or *).
     
  • A document with the class descriptions. Each class description  should contain the following:
    • A statement in English that describes the purpose of the class (i.e., the concept this class represents)
    • The class invariants (if any) expressed in plain English.
    • The data components of the class. Each component should have a type and an indication about its visibility (private or public).
    • The public methods of the class.  For each method you should define the parameters, return values, exceptions, preconditions and postconditions.  You may use plain English to describe them.  You may also use the private components in describing pre and postconditions even though in the lectures we indicated that only public components should be used.


To draw the class diagram, you can use any program to do so as long as you can deliver the diagram in a standard format (i.e., TIF, JPG or PDF). One way to draw the diagram is to use MS Visio and its UML template; Visio should be available to you in the undergrad labs running Windows. You can even draw the diagram by hand and scan it in to submit it. In this case,  make sure that the final copy you submit is VERY CLEAR, otherwise the Marker may not be able to understand your design. 

You can write the class descriptions using any text formatting program you have available, but the document you'll submit should be in a format that the markers can open in a Unix  or in a Windows environment.  Therefore, make sure to translate your document to a HTML, PDF or plain text format before you submit it in.  Finally, it would be great if you can put the class diagram and the class descriptions in a single document which has one of the formats mentioned above, but this is not required. You can submit one file with the class diagram and another file with the class descriptions.  

If you like, you can use Eclipse and create a Javadoc document for your design.  In this case you can create an Eclipse project and create the classes their data components and their methods with empty bodies in it and add the invariants, per/post conditions  and exceptions using Jacadoc. When you finish you can use Eclipse (by right cliking on the project and  selecting Export, Javadoc) to create a Javadoc document for your classes.

To help you along with this design, here are four classes your design must include:
  • Library
  • Album
  • Song
  • Artist
You may also include additional classes in your design, if you think it is necessary, but you have to include the four classes listed above. Several other classes will be provided to you in the next assignment to handle MP3 playback. For this assignment, you can disregard playback functionality in your design and pretend that the application is for library management only.

Grading

The following criteria will be used to grade this assignment:

  • The completeness of your design. (Does the design meet the constraints specified for the functionality? Does the design support the major functions expected in the system?)
  • The clarity of the class descriptions. (Are the invariants, pre and post conditions clear? Can the marker understand your design given the diagram and the class descriptions?)

Handing in the Assignment

You should develop the assignment with your partner, but in the end only one of you will submit the final version for both of you.  Do not submit more than one copy for each group.  The person who will submit the project should do the following:

 If you have not done so, create a directory named  cs211 inside your home directory.  Inside cs211 create another directory named part2

Place the files you have created for this part ( either one html or pdf, file that contains the class diagram and the class descriptions or a file for the diagram and one for the descriptions) in the part2 directory.

Copy the cover page for this assignment in the directory part2 and fill it in. Make sure that your partner has also filled in his/her part in the cover page.

When you are ready to hand in your files, use:

handin cs211 part2

Now check that the handin process was successful with the command:

handin -c cs211 part2

You will see a list of all the files that were submitted. Check that you have submitted the necessary files and that you haven't submitted any extraneous files.