Homework #4
MIS 120
In this homework assignment, we will develop several classes in order to create an organizational
hierarchy. This will use inheritance and interfaces so that the classes can use polymorphism in order to
minimize the amount of code that is rewritten.
This exercise provides an opportunity to work with:
• Inheritance
• Polymorphism
• Interfaces
SCENARIO:
You have been asked to write several classes to help organize a management hierarchy in a technology
development firm. This organizes the various company units to help track projects, assignments, and
esponsibility on a unit level.
There are two types of business units that we will be dealing with – regular organization units
(OrgUnit) which generally actually develop technology, as well as units that are focused more on
managing other units (ManagementUnit). A ManagementUnit is built on an OrgUnit and enhances it
for this task.
Our firm also concerns itself with government projects that may be considered classified or secret in
some other manner. We need to enhance these units in such a way that they can store and process
additional information, such as the level of clearance required.
For this assignment, we are using a common practice in software engineering – the use of drivers.
Drivers are not, in this context, the pieces of software that allow hardware to function. Drivers, in
software testing, are used to “run” a class so that it can be tested without writing the entire program. As
such, a driver is being provided by the instructor. You are expected to include this in your submission,
and use it for testing. This also means that no user input needs to be gathered, since the driver produces
all the input for your classes.
CLASS: OrgUnit
The OrgUnit class serves as the basis of the other organizational unit classes in the program. It is also
useful by itself. An OrgUnit keeps track of the following:
• The name of the unit (String)
• The cu
ent main project of the unit (String)
• The number of employees cu
ently assigned to the unit (int)
• The amount of cash the unit cu
ently has direct access to (double)
The constructor for OrgUnit must accept a parameter for each one of these and initialize its instance
variables with these parameters. Each instance variable must have a co
esponding instance variable,
as well as a co
esponding getter method, named getUnitName(), getMainProject(), getCashAvailable()
and getNumEmployees(), as appropriate.
As in most organizations, OrgUnits can change, sometimes substantially. As such, we need functions
that will alter or process the data stored within an OrgUnit.
The most frequent change will be the level of cash. As such we have two methods – addCash() and
educeCash(). Both of these accept a double-type value as a parameter (the amount of money to add or
emove), and return a boolean to indicate if the operation succeeded or failed.
educeCash() first checks to make certain that the amount passed by parameter is non-negative, so we
cannot accidentally add cash when we are reducing it. We also check that the subtraction does not send
the cash balance into the negative, e.g. if you try to reduce the cash by $20 and you only have $10, then
it will not work. If both of these conditions are satisfied, then the parameter is subtracted from the
cu
ent amount of cash, and reduceCash() returns true. If not, the calculation is not completed and
educeCash() returns false.
addCash() is a little simpler; it checks to make certain that the amount passed by the parameter is non-
negative. If it is negative, addCash() returns false. Otherwise, the amount is added to the cu
ent cash
amount and addCash() returns true.
The number of employees are also subject to change, and are changed in a manner extremely similar to
educeCash() and addCash(). It uses methods named addEmployees() and removeEmployees(), both of
which accept an int parameter (the number of employees to add or remove), and return a boolean value
that reports whether the operation succeeded or failed.
Similar to addCash(), addEmployees() checks to make sure that the parameter to be added is non-
negative; if the parameter is non-negative, then the parameter is added to the cu
ent number of
employees, and addEmployees() returns true. If the parameter is negative, addEmployees() returns
false. Similar to reduceCash(), removeEmployees() checks to make sure the parameter specifying the
number of employees to be removed is non-negative, and that the subtraction would not send the
number of employees into the negative. If the parameter is non-negative, and the subtraction would not
esult in a negative number of employees, then the calculation is performed on the instance variable
and the function returns true. Otherwise, the function returns false.
The OrgUnit class also has a simple setter, setMainProject(), which accepts a String as a parameter and
sets the main project instance variable to that parameter. This method is void type, so it returns
nothing.
Finally, the OrgUnit ove
ides toString(). It makes toString() return a single String, listing the unit
name, number of employees, amount of cash, and main project name, IN THAT ORDER. The
toString() method ABSOLUTELY MUST use the object’s getter methods, or else it will not work
properly for what we have planned. Do NOT directly reference the instance variables from toString().
CLASS: ManagementUnit
ManagementUnit builds on OrgUnit. However, it does something OrgUnit cannot do – it keeps track
of OTHER OrgUnits. It is built on OrgUnit in an inheritance relationship. ManagementUnit is the
subclass of OrgUnit, because it is a specialized version of OrgUnit. Using inheritance in this
assignment is absolutely required for credit.
As ManagementUnits are responsible for keeping track of other OrgUnits, it needs a way to store that.
This is done with an A
ayList named ‘unit’, which ca
ies instances of OrgUnit. This list should be
initialized in the constructor, although at this point it is an empty list. The constructor should also run
the constructor for the superclass.
ManagementUnit should have a method, addSupervisedUnit(), which takes an OrgUnit as its
parameter. It then adds it to the A
ayList holding instances of OrgUnit.
The OrgUnits that a ManagementUnit keeps track of must occasionally be reported to the user. As
such, there is a method, getSupervisedUnits(), which returns a String and accepts no parameters. This
function iterates through the A
ayList. It then reports, each on its own separate line, the name of every
OrgUnit in the A
ayList, and (on the same line) its main project. It should note which is the unit name
and which is the project name. It should return the resulting String that has compiled all of these
details.
A method, getNumManaged(), should return the number of units that are cu
ently in the A
ayList, as
an int. It accepts no parameters.
Displaying ALL the information a ManagementUnit has, along with all the information of its
co
esponding OrgUnit instances, will require a new method. As such, we will write the
getAllManagedDetails() method, which accepts no parameters and returns a String. This will start by
printing out a String that gives the name of the ManagementUnit (using getUnitName()), and then notes
that it is responsible for the units that follow. It then puts out a newline. From that point, it then
iterates through the entire A
ayList structure, adding in the output of the toString() method for each
and every OrgUnit in the A
ayList. These should have sufficient spacing to make it readable (see the
sample output).
The getUnitName() method from OrgUnit must be ove
idden to append the string
“(MANAGEMENT)” to the getUnitName() located in the superclass. As such, any attempt to output a
ManagementUnit will result in it being marked as a management unit.
INTERFACE: GovernmentUnit
The GovernmentUnit interface is designed to allow you to specify a specialized version of an OrgUnit
that is capable of working on specialized government projects. The GovernmentUnit interface adds the
following:
• A series of constants denoting four levels of classification – normal (0), classified (1), secret (2),
and top secret (3). These are all ints.
• A method, getClearance(), which returns an int and accepts no parameters. This should not
have a body for the method. The body should be implemented by the class that implements
GovernmentUnit. This method is intended to return the clearance level of the unit.
• A method, getAgency(), which returns a String and accepts no parameters. This also should not
include a body for the method. The body should be implemented by the class that implements
GovernmentUnit. This method is intended to return the agency the unit will work for.
• A method, setClearance(), which returns a boolean and accepts an int parameter. This method is
intended to set the clearance level. The int parameter is the clearance level you want for the
particular object you are working with. It should be one of the constants declared in the
interface. SetClearance returns true if successful and false if not.
• A static method, isValidClearance, which takes an int and returns a boolean. Static
methods/functions in an interface must have their code included as part of the interface. As
such, you must provide a body for this one. It should check to make sure that the parameter is
one of the constants that represent clearance levels. If it is, then the clearance level from the
parameter is considered valid, so the return value is true. If not, then the clearance level is NOT
valid so the return value is false.
• A default method, getClearanceLevelName(), which accepts no parameters and returns a String.
Because it is a default method it is possible to ove
ide it, but in the absence of an ove
ide, the
default code is used. The default code is included as a body for the method if it is not
ove
idden by the implementing class. The default method uses the getClearance() method to
get the cu
ent clearance level of the cu
ent object. It then compares the cu
ent clearance level
against the constants, and returns “Top Secret” if it is consistent with the Top Secret constant,
“Secret” if it is