Explicación de la Semana 2 - "Paquetes" (IV/IV)

Luego de comentar sobre el tema Casos de Uso y la respuesta que se esperaba para el desafío de la Semana 2, prosigo con la explicación sobre el tema de la representación de "paquetes" en UML.

Antes de empezar cabe aclarar que cada paquete a su vez representa una "capa" o nivel de nuestro sistema. Se dice entonces que nuestro sistema "está dividido en 3 capas", cada una con una responsabilidad bien definida.

Aquí podemos apreciar 3 posibles diagramas de paquetes. La figura 1 representa el diagrama clásico cuando se quiere representar un sistema dividido en 3 capas:

  • Capa de Presentación: sección donde tiene la responsabilidad de recibir datos y presentarlos o de armar interfaces para interactuar con el usuario. No importa en qué esté hecho, si en PHP o en un sistema de Templates como Smarty, lo que importa es que cumpla con una sola responsabilidad, representar los datos (nada de ir hacia la base de datos ni resolver problemas del sistema; recibe datos y los muestra).
  • Capa de Dominio: al existir una línea punteada entre la capa de presentación y la de dominio estamos definiendo por diseño que una capa "usa/necesita/se comunica" con la capa de más abajo. La capa de dominio es la también llamada "lógica de negocio", donde verdaderamente se resuelven los problemas de nuestro sistema. Esta es la capa más importante, pues en un futuro podemos cambiar el sistema de representación de los datos y sacaremos el paquete actual de presentación y lo cambiaremos por otro, pero el dominio seguirá existiendo como hasta ahora, pues ahí se resuelve el verdadero funcionamiento de nuestro sistema.
  • Capa de Persistencia: cuando la capa de dominio necesita los datos de un usuario, a pesar que cuente con la definición de la clase Usuario, necesita pedirle a una nueva capa que se conecte con el dispositivo de turno y retorne los datos para luego armar el objeto. Esta capa es la especializada en esa tarea, de la misma forma que la de presentación, puede ser una capa muy volátil y pasible de ser sustituida por otra (un paquete que soporta solo mysql es cambiado por otro que soporta postgres o un conjunto mayor de bases de datos).
Comentario al margen: a pesar que este es el diagrama tradicional para representar las 3 capas (los sistemas pueden tener perfectamente n-capas, no solo 3) la capa de persistencia debería apuntar a dominio y no al revés. Aquí se va evidenciando claramente la importancia del significado del sentido de las flechas. Como está ahora el diagrama, cualquier cambio que se haga en el paquete de persistencia afectará al paquete de dominio, como ya dijimos, el más importante del sistema (grueso error).

Acercándonos más a nuestro entorno

En la figura 2 represento el archivo index.php (como ya dijimos, estándar y necesario que exista) como ejemplo de por donde debería iniciarse la invocación de nuestro sistema. Nuestra clase inicial recibe la invocación del usuario y pasa su petición a la capa de presentación para solicitarle que arme la interfaz correspondiente, luego, si esta capa necesita representar una lista de usuarios deberá solicitarle a la capa de dominio esta información, y finalmente, la capa de dominio le deberá pedir a la capa de persistencia los datos almacenados en el sistema correspondiente. Luego de hacer este "pasamano" entre capas, todos retornarán "mensajes" hacia la capa superior, generando finalmente una respuesta desde el archivo "index.php".

Nota: como en PHP no todo son objetos, no podemos usar la nomenclatura para los nombres de archivos de objetos: Index.class.php, debemos seguir usando index.php o el servidor no encontrará la página inicial. De todas formas podemos seguir la convención de que internamente y a pesar de no respetar el nombre, existe una clase Index (evitando código estructurado).

Algunas puntualizaciones conceptuales
  • Un paquete es un elemento para agrupar otros elementos: una clase, una interfaz, otros paquetes.
  • Un paquete = un directorio: En lenguajes como PHP y Java la traducción de "paquete uml" se representa como un subdirectorio, la esencia es la misma: "contenedor de otros elementos", permitiendo un almacenamiento recursivo (un paquete puede contener otros paquetes dentro).
  • El nombre del paquete: El nombre siempre va en minúsculas y las flechas de relación siempre son de "uso" (punteadas).
  • La flecha punteada: representa que hay una relación de uso (en un solo sentido) entre los paquetes (paquete "presentación" usa al paquete "dominio", etc).
Definir una convención para nuestro contexto
  • Como en Java todo es un objeto, es natural ver a diestra y siniestra representación de clases en un diagrama UML. PHP no es un lenguaje 100% OO, pero podemos intentar hacerlo y convenir que absolutamente "todo son clases" y no permitir que exista ninguna línea fuera de una clase, pero:
    • El index.php siempre debe existir: Si fuera Index.class.php nuestro servidor no encontraría esta página por defecto.
    • Se puede agregar al diagrama todos los "módulos" como clases: pues internamente estarán implementados de ahora en más como una clase pero usando el nombre habitual de los archivos PHP: nombre_nombre.php. En nuestro sistema de ejemplo podemos ver listado_usuarios.php, consultar_usuario.php, mostrar_usuario.php, etc.
Solución esperada: la figura 1 sin la flecha entre presentación y dominio, o algo similar a la figura 3. En el sistema entregado (surforce-proyectobase) no existe -intencionalmente- la comunicación entre capa de presentación y la capa de dominio.

Todas las dudas serán respondidas en los comentarios de esta entrada ;-)

Más información

2 comentarios:

Ernesto dijo...

No importa lo que digan, no importa lo que haga, si por lo menos exista un persona que asimile o aprenda de tus conocimientos, date por satisfecho ya que los esfuerzos que realiza no son en vano.

enrique_place dijo...

Estimado Ernesto:

Primero, tuteame, no soy un veterano ni un gurú ;-)

> No importa lo que digan, no importa
> lo que haga, si por lo menos exista un
> persona que asimile o aprenda de tus
> conocimientos, date por satisfecho ya
> que los esfuerzos que realiza no son en
> vano.

Estoy tratando de "permear" algún conocimiento en un área donde la mayoría somos ignorantes en estos temas. Con solo darle una hojeada al mundo Java las distancias se vuelven "años luz".

Esto lo comentaba en Los "Desarrolladores PHP" debemos profesionalizarnos o quedaremos descartados por obsoletos

Solo que con esto estoy tratando de no quedarme en la queja e intentar pasar a los hechos ;-)

Entradas populares