A model is typically a domain level object, perhaps sometimes known as a business object. A model holds application data and provides methods to consistently access it. Typical model classes might be InsurancePolicy or PersonalAccount. It is not necessary for a model class to support a predefined protocol of messages so it is not therefore necessary to subclass a model from a particular superclass. However, the Dolphin class hierarchy provides class Model as a suitable parent (mainly for ease of recognition) if you choose to use it.
As an example, take a look at SmalltalkSystem which is a model class used by Dolphin to represent the development system itself. It contains methods to perform many of the operations that the development tools require and most of the tools use the singleton instance of this class as their model.
A model should have no association with user interface issues. This allows it to be reused in new situations which may have completely different UI requirements from those first envisaged. Consequently, a model has no direct knowledge of the existence of either the view or the presenter in the triad.
Effectively what this means to the programmer is that you should never have an instance variable in a model that holds a reference to a presenter or view.