The yellow modules represent the core VCL modules
The blue and green modules represent auxiliary modules
Core modules that should not need to be changed regardless of the auxiliary modules being used
The core modules provide many functions to the auxiliary modules including:
- default constructors
- data access
- module initialization
- access to other auxiliary modules where appropriate

Explain:

abstract and concrete classes - abstract are not instantiated
classes can be empty, contain no subs, but act as a placeholder in case it's decided later on that a sub would be useful
more about benefits of inheritance
give OS example and include diagram
- Windows - Desktop - XP - Vista
- implement subs as high up as possible so child classes inherit them
- child classes can override an inherited sub if it doesn't fit its needs
- use example of firewalls in Windows. Windows.pm implements a firewall sub which works for everything but Vista. Vista.pm can implement a sub with the same name and it will override the one in Windows.pm, yet Vista.pm still enjoys everthing else Windows.pm offers.

Core Modules

Explain:

only core modules should ever change the request state/laststate/computer state
only core modules should change anything in the request and rsvp tables
provide state flow
provide data access
provide utility functions
database and data structure are abstracted from auxiliary modules
ongoing - should not contain code specific to something that can be modularized such as "if windows... else linux..."

Explain:

...

OS modules should inherit from VCL::Module::OS
Modules which are a subclass of VCL::Module::OS also receive the functionality provided by VCL::Module through inheritance
VCL::Module::OS provides OS modules with access to the provisioning object created for the reservation
- This is useful if the OS needs to perform a task such as power cycling the computer if a reboot fails

...

Implementation Details

...