In reply to janudeep3:
In the future, a new question should should be posted in a new topic, especially one that has already been marked as solved.
The uvm_component class builds the hierarchy and will provide a cryptic unique name for your object if you don’t provide a name. So it’s better to provide a name that makes sense to you for reporting and debugging. Debugging with a UVM-aware tool becomes a lot easier if the component name matches the class variable name that holds the component handle. Also, then names of all the child classes under the same parent must be unique, just like all the class variables in a single object must be, so you should be using the same naming scheme.
The reason the UVM has to manage the hierarchy is that the SystemVerilog Object-Oriented Programming model does not have a static class instance concept, like module instances in Verilog. There is no such thing as a parent/child class unless you have a methodology to add class properties to your object that represent that relationship. A class variable can only hold a reference to another class object - it is up to the methodology to distinguish whether that object “belongs” to it or not.
UVM sequences can also have parent/child relationships, but the class variable names of sequence and sequence items are usually the same or similar (req). So it would help to provide more meaningful names.
The names of other classes derived from uvm_object are not as important, but it helps to use the same convention of using the same names of the class variable the object handle is stored in as the string name of the object.