ModelViewPresenter(TM) is a derivative of the ModelViewController Pattern. Its aim is to provide a cleaner implementation of the Observer connection between Application Model and view.

This Pattern was devised by Taligent; the original paper is at
http://www-128.ibm.com/developerworks/java/library/j-mvp.html. 

(The above http/html link has rotted.  Even the old Wayback Machine link, http://web.archive.org/web/20010709040218/www-106.ibm.com/developerworks/library/mvp.html , fails to provide a working link to grab the article.)

You can download the above paper directly at http://www.wildcrest.com/Potel/Portfolio/mvp.pdf

It is used in the DolphinSmalltalk System and they have a lot of good documentation on it. http://www.object-arts.com/EducationCentre/Overviews/ModelViewPresenter.htm is an introduction and http://www.object-arts.com/EducationCentre/Overviews/MVC.htm relates ModelViewPresenter to ModelViewController.

It's also interesting to constrast this discussion with the DocumentView Architecture, and FourLayerArchitecture.

For a lengthy explanation with Java examples, see http://www.martinfowler.com/eaaDev/ModelViewPresenter.html , though it's not a typical pure MVP.
----
MVP actually names more than 3 classes. In summary, they are:
* Presenter - represents and coordinates the application. It creates and/or wires together the other objects. The presenter is an instance of the MediatorPattern.
** Interactor - maps (eg) keyboard or mouse events onto Commands and/or Selections.
* Model - the domain data.
** Selection - specifies a subset of the Model (eg to be manipulated by a Command).
** Command - something that has an effect on the Model (same as CommandPattern).
* View - displays (part of) the model.

Breaking an application down in this way tends to give a good SeparationOfConcerns, and hence good reuse of the various pieces.*

----
A variant of MVP is PresenterFirst approach.
----
The Presenter is NOT an instance of the MediatorPattern. This is also true of ModelViewController. In MVC and MVP, the GUI/View , Presenter/Controller, and Model are drawn as a triad. While the Model is loosely coupled to the View (it only knows the View as an Observer type), the View, however is more tighly coupled with the Model in order to be able to pull values from it. To reduce this coupling, you could create a Facade of the Model that only exposes methods to obtain values that the View requires (and hide methods that modify the Model, as that is the Controller's job), but it is still somewhat tightly coupled. 

See http://www.dossier-andreas.net/software_architecture/pac.html for a description of the PresentationAbstractionControl that uses the MediatorPattern. In PAC, the View and Model and completely decoupled (at least in this particular description).

If I have learned anything though, it's that one paper, article or book's idea of MVC, PAC or MVP differs from the next. Everyone has a different idea of how they should work and which objects may access what, and how.