Objectives
The purpose of this assignment is to assess your progress towards attainment of a selection of the learning objectives as covered up to week 9, with an emphasis on topics of weeks 6 through 9.
On successful completion of this assignment you should have demonstrated that you are able to:
- Write a program consisting of multiple objects which interact with each other by following appropriate design practices
- Write a program that provides the requested functionality for the system
- Implement classes which have generalization relationships with other classes
- Utilise polymorphism and abstraction techniques
- Utilise appropriate collection classes from Java's Collections API in appropriate ways/places
- Read data from and write data to text files
- Handle exceptions by constructing try ... catch blocks for appropriate circumstances
Assessment Details
Context/Background Information (CI)
For this assignment, you will create a program that provides the user with access to a range of information about matters surrounding the management of an enterprise's computers. It is similar to the software used by the university on its main campuses (Federation University uses Microsoft's System Centre Configuration Manager).
The general idea is that a central coordinating server keeps track of the state of all the computers of the enterprise that have been registered with that server. The individual machines that people use at their desk have software installed on them which periodically perform some tasks according to settings/rules decided by the enterprise's system administrator that are stored on the central server. The actual work of these tasks is undertaken by software entities called ‘agents', each which are tasked with particular actions.
For example, one agent on a user's machine will contact the central server at regular intervals (e.g. once an hour) to ask if there are new ‘policies', which are rules about how the computer is meant to be set up. The agent will ‘enforce' the policies, which means that it makes sure the computer is following the rules that have been assigned to it by the administrator.
There are different types of policies that can be set up. One type is a security policy, specifying whether to close or open particular ports of the machine's internet connection. Another type of policy specifies rules about what software must be installed - it may be used for example to ensure that every machine has the latest version of Java or Flash Player installed. A variant of that is the type of policy that specifies a software that could be installed if the user chose to install it from the local network.
The policies are decided by the system administrator, and he enters them in to the central server, and designates which computers the policy are applicable to. (For example, some policies may only apply to computers running windows XP, others apply to computers running Windows 8. Or some may apply only to computers that are assigned to IT lecturers, and some apply to machines assigned
to student lab rooms). When an individual computer is turned on each day, it will contact the server to ask for the latest policies that are applicable to it; the server will respond with a list of all the relevant policies. The computer then checks its own list, and any that it had which are now obsolete are deleted (and stop being enforced - whatever action they may have enforced might be rolled- back); and for any that are new, the computer may need to enforce them, which could involve downloading an installer and running it automatically, or some changing some setting in the system registry or some other action.
Once the policies are enforced on a user's machine, the computer will send a message back to the server telling it so. Then the server will "know" that the machine is compliant or otherwise, with respect to all the policies assigned to it. Similarly, when various other tasks are completed (described soon), and information has been gathered about the task, these are sent to the server as well. The messages are all time-stamped, i.e. the time at which they were generated is recorded as part of the message, so that the server has an accurate understanding of the sequence in which things have occurred. It saves these messages into files called log files, which can be analysed - and these log files are basically what this assignment task is going to be focusing on.
The following is an extract (i.e. the middle) of what a log file on the server may look like:
...
11:32:01am Porcupine POLICY 419182 Applied 11:32:02am Eucalypt INVENTORY Software completed 11:32:04am Sassafras POLICY 419184 Applied 11:32:04am Sassafras POLICY 419186 Applied 11:32:05am Sassafras POLICY 418777 Unapplied 11:32:47am Boolarra INVENTORY Hardware completed
11:33:11am Jindabyne SOFTWAREUPDATES 223 Non-compliant 11:34:27am Alligator SOFTWAREUPDATES 223 Compliant 11:46:09am Turnip INVENTORY Software interrupted 11:47:45am Sassafras SOFTWAREUPDATES 223 Failed 12:10:04pm Jindabyne SOFTWAREUPDATES 223 Compliant 12:10:20pm Turnip SOFTWAREUPDATES 221 Failed 12:12:21pm Turnip SOFTWAREUPDATES 223 Compliant
...
Each line specifies one event that has occurred across the enterprise in relation to the management of the system. Each event has a time at which the event occurred, which is the first field. (We assume that the log files are for a specific day only - each day has separate log file).
Every machine in the university has a unique ‘name', which is used by the central server to identify each computer. This is the second item in each line of the log. For example, Porcupine, Boolarra and Alligator are machine names.
The next word of each line indicates the type of event that has occurred:
- Policy event - this specifies that a policy as set by the administrator, has been retrieved by the machine. Each policy has a unique number to identify it - a given policy can be applicable to one or more machines. Initially policies are set to be applied to a machine, but after a period they may be unapplied (no longer applicable to the machine, so the machine has to delete it.) The number in the log file shows the policy number of which policy is affected, and is followed by either ‘Applied' or ‘Unapplied' to indicate whether the policy was set active, or removed from being active on the machine,
- Inventory event - this specifies that the machine has had information collected about it. There are two types of inventories that can be performed. A Software inventory scans the computer to identify all the software that has been installed on the computer. A Hardware inventory gathers information about how much RAM, how much free disk space, and other physical traits about the hardware of the machine. The log file entry indicates which type of inventory has been attempted. If the inventory action completed, it will say ‘completed', but if the inventory is not completed on the machine, because the user turned it off before it could complete, then the next time the machine is turned on it will generate an event saying ‘interrupted' (as shown for the machine named ‘Turnip' above) and the machine will not re- attempt until it is next scheduled to do an inventory (e.g. the same day of the following week, or another hour later the same day).
- Software Updates - From time to time, Microsoft and other software companies release updates for the operating system or programs (e.g. Microsoft Office). The administrator can specify that particular software updates are to be installed on machines (but they might hold- off for some other software updates until a later time). A given set of updates, is given an identifier (to distinguish it from other sets). Once these have been decided by the administrator, the machines will perform a check to see whether they need any updates. If they do, the machines are considered ‘non-compliant' until they are installed. Some updates are not completely installed until the machine has been rebooted. The lines in the log file of the server indicate that a machine has performed a check of compliance for a given set of updates. There are three possible outcomes of the check. One is, that the machine is not compliant - it needs to install some or all of the updates. This is indicated by the log message that says ‘Non-Compliant', after the number identifying which set of updates is missing. The other outcome is that the updates are all completely installed, indicated by the log message that says ‘Compliant'. In the example log shown, you can see that at one point in time (11:33), the machine ‘Jindabyne' was not compliant - it needed the updates. But about half an hour later, the machine had installed the updates, and now was compliant. A third possibility is that the machine attempted to install the updates, but failed to install (the installation was unable to make the relevant corrections). For example, the ‘Sassafras' machine failed to install at least one of the updates in the set numbered as 223.
The purpose of the system you are to code, is to enable the log files to be untangled, so that we can both (1) get a clearer perspective of a single machine, and (2) analyse the state of affairs across all machines. It is also designed to enable you to apply the programming concepts you have covered in recent weeks. The log files all conform to the manner described above, and some example files are provided to you. The marker will use a different set of files to assess your work, but provided that you have adhered to the format described above in interpreting the lines of the log files, your program should work fine with these other files. (You may even like to vary the contents of the given files to check various things).
Required behaviour of the final system
This section outlines the functionality required to be provided by the program that you write for the assignment. Keep in mind that you need to address the criteria against which the work will be judged (the assessment criteria), when you implement the following behaviour of the system.
FR-1: Allow loading of a log file to populate the system with data
The program must allow the user to enter the name of a log file that it should interpret. If the file does not exist, you should tell the user and re-ask for a name.
If the file does exist, then it should be interpreted line by line loading data into appropriate objects and linking the objects appropriately so that the information can be accessed later (by other FRs). Note that the very first line of a log file is an integer specifying how many log events follow (on the subsequent lines of the file).
You should use a HashMap in order to store an object that represents the aggregation of events for a given machine.
FR-2: The program should provide a text-menu based user interaction interface
After a log file has been loaded, the system should repeatedly show the user a menu of possible actions they can perform (described more fully in other FRs).
FR-3: Allow the user to see a list of all machines that have reported any events
One menu option should allow the user to see a list of all the machines, who are mentioned by the log file that has been loaded. Note that some other FRs may also need to present the list, as well, but this FR is simply to display the list and then return back to the menu.
FR-4: Produce a text file reporting all the events for a nominated machine
When selected, this option should ask the user to choose a machine from the list of all machines that appeared in the log file. Then, for the selected machine, it will generate a file that contains only the log details about that machine (by accessing the relevant object in the HashMap). For example, selecting the ‘Sassafras' machine for the example log file given earlier, would produce a file with the following contents:
Events for machine 'Sassafras'
11:32:04am Sassafras POLICY 419184 Applied 11:32:04am Sassafras POLICY 419186 Applied 11:32:05am Sassafras POLICY 418777 Unapplied 11:47:45am Sassafras SOFTWAREUPDATES 223 Failed End of events.
The file should be named using the machine's name followed by a hyphen and the word report, with the extension of ‘txt', e.g. ‘Sassafras-report.txt'
FR-5: Produce a report of all events signifying ‘failed' situations across all machines
Failed situations are when a software update fails, or when an inventory action is interrupted and so doesn't complete. When the user selects the menu option for this functional requirement, generate a report to the screen showing just (a) the name of the machines and (b) the type of action that failed (Software Update, or Inventory). Do not show the time, or any other details about the event.
You are to group all the Software Update events together, before the Inventory events, in the output. However the order of output within each of these two groups is unimportant.
For example, given the example file extract from earlier, the following could be the output (the order of items could vary on your implementation):
Software Updates that failed: Turnip: update 221
Sassafras: update 223
Inventory Actions that failed to complete: Turnip: Software Inventory
Note that, this task gives a prime opportunity to utilise polymorphism - a method that can specifically return whether the event is about a failure, could be defined to behave appropriately (but differently) in each subclass.
You might also find that there is opportunity to use the Set type in this task, but it is not mandatory to use it.Additional Design
Requirements
The following are additional things which must be addressed in your solution, in order to meet the assessment's objectives.
ADR-1: Submit a MS-Word document addressing the following items
In the following few ADRs, you are told to write things in a Word document, which must be submitted to Moodle along with the code.
ADR-2: Solution must make use of Generalization/Specialization
Your solution is expected to employ the technique of making at least one subclass of some other class.
In the Word document, explain how you have made use of generalization/specialization and explain the reasons for deciding to use it in the places/ways that you have used it.
ADR-3: Solution must make use of a Map
You are expected to make use of some sort of Map collection class somewhere in your program. In the Word document, please explain how you decided where to use this mechanism.
ADR-4: Must include suitable exception handling mechanisms
You are expected to make the program robust against typical problems, by employing exception-handling techniques. Nothing about this needs to be described in the Word document.
ADR-5: Include evidence of testing
In the Word document, give a brief explanation of some of the ways you have tested your code to confirm it works as intended.
Tasks to Complete
Task-1: Plan your program
Consider the functional and additional design requirements, and determine which classes you will need to implement. In the Word document, write a short description of the role/purpose of each class that you have in your program - please sort them in alphabetic order by class name.
Task-2: Code a functioning program that addresses the behavioural and additional design requirements
Write the classes that you have determined are needed to make a functioning program. You should aim to write code following high quality coding practices that have been taught in this course this semester - including comments, catching checked and potential exceptions and exhibiting good design where code is separated into separate methods.
Task-3: Ensure all supplementary documentation is complete.
Go through your Word document and make sure that everything required to be included, has actually been included and is complete.
Attachment:- Assignment.rar