Al igual que sucedía con la parte de la lógica, la presentación también estará dividida en 
dos proyectos, por un lado el API y por otro la implementación.

- org.gvsig.visor.swing.api

- org.gvsig.visor.swing.impl

De forma similar a como sucedía con la lógica en la presentación, en el proyecto del
API sólo tenemos los interfaces y clases abstractas que definen nuestro API. El API
de la parte de presentación está formado por el interface del *manager* junto con
una serie de clases abstractas que definen el API público de nuestros componentes,
generalmente componentes que extenderán al componente de swing JPanel. Son clases
abstractas y no interfaces debido a que swing no presenta un modelo de interfaces
para sus componentes. En nuestro ejemplo, el único componente que tendremos es el
componente visual asociado a una manzana, el *JVisorBlockPanel*,que extiende de
*JPanel* añadiéndole a nivel de API un único método que nos permita obtener el
componente lógico *VisorBlock* que tiene asociado en un momento dado.

En la parte de implementación nos encontraremos con la clase *DefaultJVisorBlockPanel*
que recibe en su constructor la instancia de *VisorBlock* de la que debe presentar
sus datos. En general la parte de presentación no tiene una complicación mas allá
de la propia que pueda tener el manejo de swing. Lo único a resaltar
es que la parte de presentación no debería usar nada que no este expuesto en el API
de nuestra librería de lógica.