You should commit and push your code to GitHub after completion of each task, if not more frequently. By pushing your code to GitHub you are effectively making a backup of your work which you’ll be able to retrieve if anything happens to the code on your laptop.
All code must be appropriately documented:
each class should have a class-level comment (that appears just before the class declaration) to describe the information that the class represents every method must be documented with requires, modifies and effects clauses, as appropriate (note that simple setter and getter methods, and test methods, do not have to be documented)
While marks are not awarded for documentation, penalties of up to 10% will be applied at each phase of the term project for missing documentation.
In Phase 4 you will continue to work with the same repository that was provided to you for Phase 1.
If you have not done so already, please ensure that you have committed your Phase 3 code, pushed it to GitHub and requested a grade from AutoTest for your Phase 3 deliverables. We then have a record of the work that you completed during Phase 3, so that you may start work on Phase 4.
It’s often useful to be able to log events that occur in an application. In the context of your particular application, we may want to log whenever an X is added to Y or removed from Y, or perhaps whenever the Y is cleared (if that operation is supported).
In this task, you will add event logging to your application. To do so, you must re-use the Event and EventLog classes from the Alarm System application seen earlier in the term. You must add these classes to your model package and must not modify them in any way. Take time to understand how they are used in the context of the Alarm System before attempting to use them in your application. In particular, note that the EventLog constructor is private. So, rather than constructing an instance of EventLog your application must make use of the getInstance method. This is an application of the Singleton design pattern which ensures that only one instance of a class is constructed and that that instance is globally accessible. The application of this pattern is appropriate in this case, as we want all events to be added to the same log (so we want to ensure that only one instance of the event log can be constructed) and we want the event log to be accessible from all parts of the application.
For this task you must:
make calls to the logEvent method of the EventLog class from code in your model package but from nowhere else. In particular, you must not call this method from anywhere in your ui package.
log all events that are related to your X’s and Y – e.g., when an event is added, removed or when the Y is cleared. Be sure to use a description that accurately conveys the event that has occurred – so “todo item added to todo list” rather than “an event has occurred”.
when the user quits your application, print to the console all the events that have been logged since the application started.
copy and paste a representative sample of the events that occur when your program runs and add it to a section entitled “Phase 4: Task 2” at the end of your README.md file. If no events are logged when your program runs, you must include one or two paragraphs to explain why you believe this is happening. If it is helpful to do so, you may wish to refer to the UML class
diagram that we ask you to draw in Task 3.
Note that EventLog implements the Iterable interface. We’ll be looking into this in more detail during our last module at the end of term. For now, note that this allows client code to use a for-each loop to iterate over the events in an EventLog object. See the printLog method of the ScreenPrinter class in the Alarm System application for an example of how this is done.
本网站支持淘宝 支付宝 微信支付 paypal等等交易。如果不放心可以用淘宝交易！
E-mail: email@example.com 微信:itcsdx