java代写/assignment代写: MovieTix
java代写/assignment代写: 这是一个通过java进行的class训练的题目
Introduction PayTex
MovieTix is, essentially, a hybrid debit/credit card for purchasing movie tickets. A MovieTix card can be pre-loaded with a particular number of tickets, can be used as a credit card, or can be used like a combination of the two. The prototype MovieTix system is being developed for university students and supports four plans with the following “default” properties (though the system must support other properties, as described below).
· Movie Plan – a plan with both pre-paid tickets and the ability to purchase tickets on credit. Any pre-paid tickets that are not used during the semester are lost (and the purchase price is not refunded).
· Tiered Plan – a plan with both pre-paid tickets and the ability to purchase tickets on credit. It differs from a Movie Plan in that the first group of “purchases” is at a different price from the subsequent “purchases”.
· Limited Plan – a plan with both pre-paid tickets and the ability to purchase a limited dollar amount of tickets on credit.
Existing Applications
Another PayTex employee has written two applications that will make use of your code when you complete it, and provided you with the source code.
· UsageSummarizer.java
· Planalyzer.java
The UsageSummarizer can be used to print a table of costs-per-movie for different amounts of usage (i.e., movies seen) for four different common plans. The Planalyzer
can be used to print a table that contains the best plan (of the same four common plans) for different amounts of usage.
System Design
The relationships between the components that encapsulate plans can be modeled using the following UML class diagram.
This diagram uses the convention that methods that are inherited by a derived class are not listed, but methods in a derived class that override a method in a base class are explicitly listed.
The supporting components can be modeled using the following UML class diagram.
The details of each class in this diagram are provided below. You may add public/protected methods but you must not override any existing methods that are not explicitly overridden in the UML diagram and you must not shadow any attributes.
Note that, in Java, the UML property modifier {readOnly} indicates that an attribute must be declared final.
The Interval Class
The Interval class is an encapsulation of an interval on the real line. Interval objects are used in several places.
Detailed Specifications
In addition to the other specifications included in the UML diagram, the Interval class must comply with the following specifications.
Attributes
The double attributes left and right contain the left and right bounds of the interval.
The boolean attribute leftClosed indicates whether left is in the interval (when true) or not (when false). Similarly, the boolean attribute rightClosed indicates whether right is in the interval or not.
Interval(char, double, double, char)
The four-parameter constructor is passed a char to indicate whether the interval is closed on the left (i.e., left is in the interval), the left and right bounds, and a char to indicate whether the interval is closed on the right. A leftSymbol of ‘[‘ indicates that the interval must be closed on the left and a rightSymbol of ‘]’ indicates that the interval must be closed on the right. Any other char indicates that the interval is open on that side (though the traditional characters are ‘(‘ and ‘)’.
This constructor must throw an IllegalArgumentException if left is greater than right.
Interval(Interval)
The one-parameter constructor is a copy constructor. You need not validate the parameter.
contains(double)
Must return true if the given value is contained in the interval and false otherwise. Note that this method does not use tolerances. Hence, it is not appropriate for some kinds of calculations.
closestTo(double)
Must return the value in the closure of the interval (i.e., the interval and its bounds, whether or not it is closed) that is closest to the given number. Note that this
method can, if the value is in the interval, return the value itself. (This operation is sometimes described as projecting the value onto the closure of the interval.)
For example, the closure of the open interval (3.00,8.00) is [3.00,8.00]. So, the point in the closure of the interval (3.00,8.00) that is closest to 5.30 is 5.30, and the point in the closure of the same interval that is closest to 100.50 is 8.00.
toString(String)
Must return a String representation of the interval that uses the String parameter to format the left and right bounds (i.e., uses the String parameter as the format specifier for the bounds). You need not validate the String parameter.
The result must contain a ‘[‘ or ‘(‘ as appropriate, followed by the left bound (formatted appropriately), followed by a ‘,’, followed by a space, followed by the right bound (formatted appropriately), followed by a ‘]’ or ‘)’ as appropriate.
toString()
Must return a String representation of the interval in which the left and right bounds are in a field of width 6 with 2 digits to the right of the decimal point.
The Category Enum
The Category enum encapsulates a predefined set of price categories.
Detailed Specifications
In addition to the other specifications included in the UML diagram, the Category enum must comply with the following specifications.
Elements
The Category enum must contain five elements: BARGAIN with a description of “Bargain”, a symbol of “$”, and an interval of [0.00,5.00,]; INEXPENSIVE
with attributes “Inexpensive”, “$$”, and (5.00,11.00]; MODERATE, with attributes “Moderate”, “$$$”, and (11.00,15.00]; EXPENSIVE, with attributes “Expensive”, “$$$$”, and (15.00,25.00]; and OUTRAGEOUS with attributes “Outrageous”, “$$$$$”, and (25.00,∞].
toString()
Must return a String containing the description, a single space, and the symbol (in parentheses). For example, BARGAIN.toString() must return the String literal “Bargain ($)”.
getCategoryFor(double)
Must return the Category object that contains the given price (or null if there is no corresponding Category).
The MoviePlan Class
The MoviePlan class encapsulates pre-paid movie plan with a fixed up-front cost and number of tickets.
Detailed Specifications
In addition to the other specifications included in the UML diagram, the MoviePlan class must comply with the following specifications.
Attributes
APPROVED_PLAN_COSTS contains the range of allowable plan costs (as determined by the copany PayTex). Valid plan costs must be in the interval [0.00,200.00]. Similarly, APPROVED_MOVIE_COSTS contains the range of allowable ticket costs (which, though not relevant for MoviePlan objects is relevant for other plans). Valid ticket costs must be in the interval [0.00,25.00].
The attributes prepaid and punches contain the number of prepaid tickets in the plan and the number used to-date (i.e., the number of movies seen) which must be 0 initially.
Constructors
The default constructor must initialize the attributes to the default values as follows: the name must be “Movie Plan”, the number of pre-paid tickets must be 5, the plan cost must be $50.00, and the cost per “extra” movie must be $15.00.
The explicit value constructor must initialize the attributes in the obvious way, with a few exceptions. The plan cost attribute must be assigned the value in APPROVED_PLAN_COSTS that is closest to the parameter planCost and the movie cost attribute must be assigned the value in APPROVED_MOVIE_COSTS that is closest to the parameter movieCost.
costOfPurchasedMovie()
Must return the cost of a purchased (i.e., not pre-paid) movie.
costToDate()
Must return the cost-to-date of the plan (i.e., the sum of the plan cost and the amount spent to-date on “purchased” movies).
getCategory()
Must return the current Category for the plan, based on the cost per movie (to-date). For example, if the cost per movie is currently $7.00, this method must return the INEXPENSIVE Category.
getCostOfNextMovie()
Must return a String representation of the cost of the next movie. If the plan still has punches then this method must return “Free”. Otherwise, it must return the cost of a purchased movie (preceded by a dollar sign, in a field of width 6, with 2 digits to the right of the decimal point).
getCostPerMovie()
If the number of movies seen to-date is 0 it must throw an IllegalStateException (since the cost per movie is undefined when no movies have been seen). Otherwise, it must return the cost-to-date divided by the number of movies seen to-date.
numberPurchased()
Must return the number of movies that have been purchased to-date (which does not include the number of pre-paid movies that have been seen).
numberSeen()
Must return the number of movies that have been seen (whether pre-paid or purchased) to-date.
remainingPrepaid()
Must return the number of unused pre-paid tickets.
spent()
Must return the amount of money that has been spent on purchased movies (which does not include the plan cost).
toString()
Must return a String representation of the plan. The String must be tab-delimited and include four items (in order): the name, the cost per movie (preceded by a dollar sign in a field of width 6, with 2 digits to the right of the decimal point), the String representation of the current Category, and the cost of the next movie (formatted as described above).
use()
The use() method is called when a user wants to “see” a movie. It must adjust the number of punches, the amount spent, and/or the number purchased (as appropriate, depending on whether there are or aren’t unused punches).
Since it is always possible to “see” a movie under this plan, it must always return true.
The LimitedPlan Class
The LimitedPlan class is a specialization of the MoviePlan class in which there is a limit on the amount of money that can be spent on credit.
Detailed Specifications
In addition to the other specifications included in the UML diagram, the LimitedPlan class must comply with the following specifications.
Attributes
The creditLimit attribute must contain the limit on the amount of money that can be spent on credit.
Constructors
The default constructor must initialize the name to “Limited Plan”, the number of pre-paid tickets to 5, the plan cost to $50.00, the cost of purchased tickets to $15.00, and the credit limit to $100.00
The 3-parameter constructor isused to construct “pre-paid only” plans. To that end, it must initialize the vost of purchased tickets to the maximum possible value, and the credit limit to $0.00.
getCostOfNextMovie()
Must return a String representation of the cost of the next movie. If the plan is unusable (i.e., has no available punches and insufficient credit to purchase a ticket) then it must return “N/A”. Otherwise, it must exhibit the same behavior as a MoviePlan.
use()
The use() method is called when a user wants to “see” a movie. It must return false if the plan is unusable (as described above). Otherwise, it must exhibit the same behavior as a MoviePlan.
The TieredPlan Class
The TieredPlan class encapsulates a specialization of a MoviePlan in which there is a special tier of purchases (at a different price from ordinary purchases).
Detailed Specifications
In addition to the other specifications included in the UML diagram, the TieredPlan class must comply with the following specifications.
Attributes
The tierLimit is the number of tickets in the initial group of tickets. The tierCost attribute must contain the cost of the initial group of purchased tickets.
Constructors
The default constructor must initialize the name to “Tiered Plan”, the numebr of pre-paid tickets to 5, the plan cost to $100.00, the normal purchase price to $10.00, the number of tickets in the initial group to 5, and the price of the initial purchases to $5.50.
The explicit value constructor must initialize the attributes in the obvious way, with a few exceptions. The plan cost attribute must be assigned the value in APPROVED_PLAN_COSTS that is closest to the parameter planCost, and the movie cost and tier cost attributes must be assigned the value in APPROVED_MOVIE_COSTS that are closest to the parameters movieCost and tierCost, respectively.
costOfPurchasedMovie()
Must return the cost of a purchased (i.e., not pre-paid) movie. Note that the value returned by this method will depend on the number of movies that have been purchased (because of the two “price tiers”).
The PlanUtilities Class
The PlanUtilities class is a utility class that can be used to perform operations on MoviePlan objects.
Detailed Specifications
In addition to the other specifications included in the UML diagram, the PlanUtilities class must comply with the following specifications.
findBestPlan()
Must return the least expensive MoviePlan (among those passed to it) based on its current cost-per-movie.
This method must account for several special situations:
1. In the event of a tie, it must return the MoviePlan that appears earliest in the argument list.
2. Any null parameters must be ignored.
3. It must return null if all of the parameters are null.
4. It must return null if there are 0 parameters.
5. It must ignore parameters that have an undefined cost-per-movie.
6. It must return null if all of the parameters have an undefined cost-per-movie.
Submission and Grading
You must submit complete implementations of all classes/enums, as well as JUnit tests for each.
For full credit your submission must satisfy three conditions:
· The classes/enums must pass all of the instructor-provided Web-CAT correctness tests.
· The classes/enums must pass all of the student-provided JUnit tests.
· The student-provided unit tests must achieve 100% method, statement and branch coverage of the classes/enums.
Submissions that fail to satisfy these three conditions will receive at most 50% of the possible credit for coverage and correctness.
Your JUnit test classes must have Javadocs for the class headers, but you are not required to provide Javadoc comments for each method.
Grading
Web-CAT Correctness and Test Coverage 70%
Checkstyle 10%
Instructor Style Points 20%
Your final grade will be reduced by one point for each submission beyond five.
Hints and Suggestions
In addition to the information above, you might find the following information helpful.
Recommended Process
You are strongly encouraged to use test-driven development (TDD) (i.e., to develop the tests for a class/method before developing the class/method itself). To facilitate that process, stubbed-out versions of all of the classes/enums are available in pa4-stubs.zip.
Whether or not you use TDD, you should work on the classes/enums one at a time, in the following order:
1. The Interval class and associated JUnit tests.
2. The Category class and associated JUnit tests.
3. The MoviePlan class and associated JUnit tests.
4. The LimitedPlan class and associated JUnit tests.
5. The TieredPlan class and associated JUnit tests.
6. The PlanUtilities class and associated JUnit tests.
After that, you should perform system testing using the UsageSummarizer and Planalyzer classes.
