Description
P2 exercises your understanding of containment, composition and class maintenance
Additionally, you are required to use ProgrammingByContract.
P2’s goal is to design and implement the C# classes needed to implement a comparative data set, as described below.
ProgrammingByContract will be covered in class on Wednesday 1/13/16
Part I: Class design
Design and implement two classes, each of which encapsulate distinct debtStats objects.
The first type, studentStats, allows a student to track debt from different degrees.
Different degree program may have different lengths, grant availability, etc.,
Additional functionality should include, minimally, the ability to pull out the most burdensome degree, the number of deactivations, etc.
The second type, cohortStats, supports the tracking of all students matriculating at a given time.
Additional functionality should include, minimally, the ability to pull out the largest/smallest loans, and the number of deactitvated.
Reuse your debtStats class from P1, with or without modification: the version number should increase if you modify your reused code.
Clearly, many details are missing.
• Make reasonable design decisions so that your classes satisfy the stated goal, communicate assumptions and use, and yield clear and maintainable software.
• Use ProgrammingByContract to specify pre and post conditions; interface, implementation and class invariants.
• Relationships should be noted in the appropriate invariants.
Part II: Driver
Design a driver to demonstrate the program requirements: clearly specify the intent and structure of your driver. You should have collections of distinct objects, initialized appropriately, that is, randomly but distinctly. Do not skimp on your driver’s design.
Use C#. Comments from previous assignment hold, including:
1) Several details in this assignment have been left unspecified.
CLEARLY DOCUMENT all design decision you make.
Design as consistently and cleanly as possible.
2) User interface is essential.
Anyone should be able to use and understand the purpose of your program.
DO NOT assume that the user has read this assignment specification.
Make your output readable but not exceedingly lengthy.
3) Run your program sufficiently to demonstrate its capabilities
Submit results displaying the output.
4) Upload your files (p2.cs, studentStat, cohortStat.cs, debtStat.cs) to Canvas
Defensive Programming – assumes application programmer will not consistently track object state and hence may invoke operations that are inappropriate to current state
Class methods check arguments and object state for validity => No preconditions
• overhead of error checking falls on all applications
• ok for infrequent calls; expensive for repetitive requests
• may be unnecessary in serial or chained requests
• safe
Programming by Contract – assumes application programmer consistently tracks object state and hence will invoke only appropriate operations
Preconditions
To ensure function operates correctly, identify legal state(s) of object
Postconditions
Identifies any change(s) in object state after function execution
Class invariants
identify relationships or salient details about data members that are of interest to both application programmer and class designer
Interface invariants
Enumerate restrictions on use or application of objects
Implementation invariants
Record design decisions, choices made in implementation, relationships or state conditions needed for consistency
• assumptions about arguments and object state remove need for internal (class-based) testing
• permits skipping of external (application) testing (reasonable with serial or chained requests)
• efficient
• risky, dependent on application programmer fulfilling contract
