UVM class hierarchy - type of relationship

In reply to verif_learner:

  1. uvm_report_object is derived from uvm_object

Yes report object provides a sort of interface to the UVM reporting facility. Users can configure what actions are taken and what are output for individual messages from a particular component or for all messages from all components in the environment. User can set ACTION for each of the messages like UVM_DISPLAY, UVM_COUNT etc. Refer uvm_report_object.svh description.

  1. uvm_component is derived from uvm_report_object

Correct. Components are basically those classes which will be instantiated and used throughout the simulation. Unlike transaction/sequence objects, the components are generally not created per packet.

  1. uvm_report_handler is derived from uvm_report_object

The report handler is the class which stores actions, verbosity and files that affect the way reports are handled. It contains print method which can be used by printer to format the output. Refer to uvm_report_handler.svh description.

Secondly, how uvm_report_object is utilized? Do testbench writers have to include this class before using it?
Same question applies for TLM classes also.

By importing uvm_pkg with wildcard, it will import all the UVM related files. So no need to include individual files. Usually we use the following to get all the UVM functionality:

import uvm_pkg::*; // All UVM related files
`include "uvm_macros.svh" // UVM macros file