In addition to attributes, Simics configuration objects can have interfaces, which are named groups of methods. In fact, an attribute can be viewed as a very simple interface with two methods (get and set).
A Simics configuration consists of a number of interacting configuration objects; for example, the machine vacuum consists of a clock, a memory space, and a RAM. (The clock acts as a pseudo-CPU and is needed to drive the execution.) Each of these is represented as a separate configuration object, and the interaction between the objects is done through interfaces.
To take a concrete example: when a CPU wants to make a memory access, it will call the access method that is part of the memory_space interface implemented by the memory space object. If the memory space then finds some object (e.g., our device) mapped at the accessed address, it will call the operation method in the io_memory interface implemented by the mapped object. (If the mapped object was our DML device, and we had included the standard library file io-memory.dml, the device will automatically contain an implementation of the io_memory interface, which uses the function number of the mapping to pass on the operation to the access method of the correct register bank in the DML program.)
A very basic question in this context is "how does one object find another object?" Usually, objects are connected through attributes; e.g., a CPU object could have an attribute that holds a reference to a memory space object, and the memory space object has an attribute that contains mapping information (which includes references to the mapped objects), and so on. Such bindings are typically set up in the configuration scripts for a simulated machine, and are not changed after the initialization is done.
DML has built-in support both for letting your device implement any number of interfaces, and for connecting other objects to your device that implement particular interfaces.