The Builder is (in this case) the abstract concept of adding a button to a page. A BuilderCall is a specific use of a Builder – for instance, add the "Click Me" button to the Page "Page1" in the Model "MyModel." The guts of a BuilderCall is really just the values of all the BuilderInputs (all of the values that you entered in the editor) and a reference to the Builder Definition.
Neither the Builder nor the BuilderCall is the Button. If we wanted to change the background color of the Button using the Attribute Setter Builder, we say that put an Attribute Setter targetted at the Button on the page. Note that the Attribute Setter doesn't care, or even know, how that button got there.
Parts of a Builder
There are two critical parts of a Builder: the Builder Definition file and the Builder class. There is a third piece, the Coordinator, which is optional.
Builder Definition (BDef) file.
This is an XML file which completely decribes the Builder. There are two different elements which need to see this description. The Generation engine needs to know what to do when it sees a BuilderCall; and the Designer needs to know how to construct an editor for a BuilderCall instance of this Builder.
For Generation, the most important value that it defines is the Builder class. The Generation Engine will know to create an instance of this class and call its doBuilderCall method. The other piece that it describes is which of the BuilderInputs is required. When the Generation Engine runs inside the Designer, every BuilderCall is analyzed to ensure that all required fields have values, and it won't even invoke the Builder if a required field is missing. On the server, for performance reasons, it doesn't bother to make this check unless the builder throws an exception.