PHP Senior: semana2

Mostrando las entradas con la etiqueta semana2. Mostrar todas las entradas

Cerrada la Semana 2 del taller

Bueno, esta es otra de las cosas que se aprende cuando se hacen en la práctica y no solo en la teoría. Intenté hacer una segunda revisión de los trabajos pero se me hizo interminable, por lo que tuve que dejar por la mitad la escritura de comentarios individualizados (son 37 trabajos completos, con diagramas y respuestas a las encuestas).

Así que doy por cerrada esta evaluación aunque pudiera cometer alguna injusticia con algún punto sobre los trabajos, por lo cual les pedido a todos los que tengan dudas o lleguen a comparar con otros trabajos y vean diferencias en criterios, me avisan y con gusto trato individualmente de volver a evaluar ese punto.

No se olviden que los puntos, más que para valorizarlos a ustedes, son para evaluar donde ocurren los errores más frecuentes y armarme una guía de materiales a desarrollar para presentarles y solucionar sus dudas.

Resumen de mis explicaciones para cada punto de la Semana2

Desde ya siguen abiertos los comentarios en cada una de esas entradas, así poder seguir profundizando los conceptos y solucionando las dudas.

Bueno, y mañana empiezo con la evaluación de la Semana3 ;-)

PD: algunos alumnos se me están perdiendo por el camino, la Semana 2 se concluyó con 37 trabajos entregados y esta Semana 3 van hasta ahora 15...

Pregunta: ¿los estoy exigiendo mucho?

Si tienen comentarios o críticas, fundamentalmente las personas que no están llegando a esta entrega, me gustaría conocerlas.

Explicación de la Semana 2 - "Cuestionario"

Seguimos, la última parte: explicar las respuestas que se esperaban del cuestionario propuesto como parte del desafío de la Semana 2.

Letra del cuestionario

Contestar el siguiente cuestionario (en caso afirmativo indicar claramente en que parte del fuente, en caso negativo, justificarlo de forma detallada)

¿En qué parte del sistema se realiza "herencia"?
¿En alguna parte del sistema se usa "polimorfismo"?
¿Si tuviera que agregar otro tipo de usuario, como un Administrador, qué haría?
Obtenga un ejemplo de "encapsulamiento" y explíquelo detalladamente.

Respuestas esperadas

La idea era forzarlos a leer todo el sistema de arriba a abajo. Si contestaban algo genérico no estaba mal pero lo consideraba incompleto, y si nombraban un solo caso, también ;-). La respuesta esperada era en dos clases concretas, en TemplateSmarty y en Usuario.
Esto también les obligaba a recorrer todo el sistema, otra vez. Aquí es donde hubieron mayores fallos, lo que identifica claramente que hay un problema de conceptos y no se entendió que significa "polimorfimo" (ya armaré material extra sobre el tema). La respuesta era "no".
Hubo de todo aquí, pero repasemos el contexto: estamos buscando afirmar conceptos de POO, por lo tanto aunque hay muchas opciones válidas y aplicables en muchos contextos, aquí lo esperado era usar OO entonces la herramienta a utilizar era la herencia. Por lo tanto, para crear el Administrador podría heredar de la clase base Persona, o si la nueva clase es una especialización de Usuario, lo más probable que la herencia sea sobre esta última.
Aquí era meramente una pregunta conceptual y muy general. Existen de sobra ejemplos sobre el tema en el código. La respuesta esperada es "el encapsulamiento es utilizado para esconder detalles de la implementación que no necesitan conocer los objetos que son clientes de la clase que brinda sus servicios". Esto se hace a través del uso de atributos/métodos "públicos y privados" y el encapsulamiento se consigue a menudo mediante la ocultación de la información. Todo esto sirve para reducir la dependencia externa con la implementación interna de la clase. Cuanto menos se sepa de su interior, más reutilizable es porque solo dependemos de lo que hace y no cómo se hace.

Bien, terminadas todas las explicaciones... si hay alguna que duden o discrepen, bienvenidos sus aportes en los comentarios de esta entrada.

PD: tal vez por el cansancio extremo puedo haber cometido un error sin darme cuenta, así que los que saben del tema no tengan reparos en corregirme ;-)

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

Bien, seguimos con la parte de los diagramas de clases correspondiente al desafío de la Semana 2.

Empecemos con algunas puntualizaciones:

Igual que con los casos de uso, según quién sea el usuario objetivo de la documentación UML esta tendrá más o menos detalle.
Los "get / set" no son necesarios documentar, lo mismo con toString y el constructor (aunque este último puede documentarse si representa alguna información importante como en el caso del patrón de diseño Singleton)

Tratando de mantener un perfil "pragmático" ("simple y sencillo") los diagramas de clases los presento por paquete y no todos juntos (a los efectos es lo mismo, pero aporta un poco más de claridad).

Para el paquete "Presentación"

Básicamente es eso lo que hay en la capa presentación, una clase Fachada que se encarga de recibir todas las peticiones del exterior y derivarla luego a la clase correspondiente (esta estrategia se aplica en todas las capas), así se evita acceder desde fuera del paquete a cada clase que lo compone (un tema de orden y simplificación, de lo contrario sería una enredadera con invocaciones de todos lados).

Nota: como en java, el "void" representa que ese método no devuelve valor alguno.

Para el paquete "Dominio"

El DominioFachada tiene una flecha punteada que representa la dependencia ("relación de uso") con la clase Usuario, lo cual significa que en algún momento o recibe la clase por parámetro o la crea dentro de algún método (en este caso es la última opción).

Nota: aparece una nueva representación de UML, una "nota" (el dibujo representa una hoja con la punta superior derecha doblada), donde se puede agregar comentarios con respecto al diagrama o a partes del mismo (se suele agregar una flecha que va desde la nota al elemento del diagrama que se está comentando). Conviene usarlo para clarificar el diagrama o hasta para poner pequeños trozos de código a modo de ejemplo para guiar la futura implementación.

Para el paquete "Persistencia"

Se ven dos métodos, uno que no tiene parámetros pero como resultado retorna un Array (o "vector") con datos y el segundo recibe un parámetro de tipo Array y retorna un Array de datos.

En este caso se usa la "nota" para evitar tener que representar la clase del framework en este diagrama y dejar esta representación para otro diagrama exclusivo. Hacer lo contrario tampoco quiere decir que está mal, es un criterio adoptado.

Respuesta esperada: lo más parecido a las clases representadas aquí, no teniendo en cuenta si se mostraban las mínimas necesarias o todas las que hay en el sistema, se evaluó fundamentalmente la construcción de las clases y sus relaciones.

Dudas sobre este tema, en los comentarios en esta entrada ;-)

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

Explicación de la Semana 2 - "Casos de Uso" (I/IV)

Esta es la explicación complementaria para la parte "casos de uso" del desafío de la Semana 2. Quiero aclarar que no me voy a limitar a decir solo lo que se esperaba como respuesta del desafío, buscaré ahora reforzar algunos conceptos sobre el tema.

En el gráfico dos opciones posibles. Una más descriptiva que la otra, pero ninguna comete el error de entrar a descomponer las funcionalidades del sistema como si estuviéramos ya desarrollando.

¿Cual de las dos opciones es correcta? Ambas lo son, pues describen la realidad pero toda documentación se deben ajustar a un contexto: ¿quién es el público objetivo de la documentación?. Si son los clientes del proyecto se podría usar la versión 1, pero si son desarrolladores (con más razón si cuentan con poca experiencia) tal vez se podría usar la versión 2 que explica con un poco más de detalle la funcionalidad que tendrá el sistema.

Algunas puntualizaciones sobre el tema de los diagramas de casos de uso:

Para qué se usan: Los Casos de Uso son empleados para descubrir y capturar requerimientos de los clientes en una forma que sea accesible para todos los participantes del proyecto, tanto desarrolladores como clientes.
Qué deben comunicar: Un Caso de Uso describe QUÉ hace el sistema sin decir CÓMO lo hace.
Qué representan: una o varias funcionalidades de nuestro sistema que ofrecen valor al usuario del mismo. Si lo que estamos documentando ("el globo") no devuelve ningún valor al usuario, no debe considerarse un caso de uso.
Flecha"include": es cuando un caso de uso incluye otro caso de uso. El caso base incorpora explícitamente el comportamiento del otro. En ambos casos el sistema lista ("listar usuarios") o consulta ("consultar usuario") para llegar a mostrar finalmente toda la información del usuario como si fuera una ficha ("mostrar usuario") que en nuestro caso se hace dos veces (se llega por dos caminos distintos a la ficha del usuario).
Los nombres de los casos de uso: preferiblemente que sean descriptivos de la acción o el valor que generan al actor del sistema. En vez de usar términos como "Listado de Usuarios" se usa una expresión más genérica que describa la acción o uso en el contexto del sistema: "listar usuarios".

Esto es lo básico de los Casos de Uso, pero hay algunos detalles más. Por ejemplo, la documentación que debe acompañar a cada caso es tan importante como el propio diagrama. Debe describir con palabras el comportamiento del caso de uso, su curso básico y sus cursos alternativos.

Por ejemplo, para el caso de uso "consultar usuario":

Curso Básico

El usuario ingresa el id o el nombre del usuario
El sistema lo encuentra y muestra la ficha del usuario

Cursos alternativos

Si el usuario no ingresa ni id ni el nombre el sistema envía un mensaje de error
Si el sistema no encuentra el usuario envía un mensaje de ayuda y posibilita volver a intentar la consulta.

Todo esto es parte de la documentación de una "Especificación de Requerimientos" o "ESRE" que se origina luego de una entrevista con nuestro cliente y este nos cuenta qué desea que haga el sistema (existen muchos templates para usarlos como ejemplos).

Relación entre Casos de Uso y los "módulos" de nuestro sistema

Podemos hacer un paralelismo en nuestro contexto: cada caso de uso puede convertirse literalmente en un "módulo" de nuestra aplicación:

Caso de Uso "Listar Usuarios" -> listado_usuarios.php
Caso de Uso "Consultar Usuario" -> consultar_usuario.php
Caso de Uso "Mostrar Usuario" -> mostrar_usuario.php

Detalle final

En muchos casos pude ver trabajos que incluían el "index" como un caso de uso. A pesar de que nuestro sistema siempre tendrá uno, no necesariamente hay que representarlo (cuanto más minimalista el diagrama, mejor). Lo más realista sería que si nuestro "index" ofrece algo más que información estática (como sucede en el "proyecto base") se podría considerar que ofrece "valor" al usuario. Por ejemplo, si la página principal fuera un sistema de noticias, ordenadas cronológicamente, con posibilidad de comentarios, etc, sí lo agregaría como un caso de uso y lo nombraría "mostrar noticias" (no necesariamente "index", estoy contando la funcionalidad, no cómo la voy a implementar ni en donde).

Espero haber aportado un poco más sobre el tema y haber despejado algunas dudas. Cualquier otra consulta está disponible la sección de comentarios de esta entrada ;-)

Taller PHP5: Borrador con los resultados de la Semana 2

Porque soy histérico y detallista, y por un tema de respeto hacia ustedes, estos resultados deben considerarse un "borrador" de la nota final. Recuerden que la idea no era "hacer todo bien", la primer exigencia era el "compromiso" y entregar el trabajo con lo poco o mucho que pudieran haber entendido de los materiales que leyeron.

Posteriormente, en los próximos días, revisaré nuevamente los trabajos y les haré comentarios sobre cada uno de -en mi opinión- los errores que cometieron en base a lo que se esperaba.

Agregué una columna que se llama "Cerrado" (en rojo) donde al colocar una fecha estaré confirmando que fue nuevamente verificado el trabajo, los puntajes corregidos (si corresponde) y que ahora el enlace al documento tiene los comentarios pertinentes (así pueden aprender de los errores y entender qué les estoy tratando de enseñar).

Todos los documentos son copia del original que me han compartido, así tenemos una versión "congelada" y nadie pueda modificar lo ya entregado (intencional o por accidente, no importa). También he dejado público los trabajos para seguir compartiendo información con los demás interesados que no necesariamente quieran o puedan seguir el taller, o para que ustedes mismos vean lo que sus colegas hicieron. El otro tema aquí es acostumbrarnos a compartir información y a recibir críticas logrando canalizarlas a nuestro favor.

Me imagino que muchos podrán discrepar con algunos criterios que he usado para evaluarlos, pero la idea de esta tarea es que me sirva como guía para saber qué temas debemos trabajar más y crear material extra para solucionar las dudas (constructivismo). Por ejemplo, viendo rápidamente los resultados globales podemos casi aceptar que el tema "herencia" es algo que todos entendieron no así el polimorfismo. Sobre UML vamos a tener que trabajarlo un poco más y darles ejemplos específicos de como los aplico en desarrollos que involucren Web y PHP.

Estos puntos no representan vuestro nivel o escala jerárquica dentro del taller, solo es para guiar mi camino.

Bueno, para los "impacientes de siempre", aquí está el borrador de la planilla con los resultados y los trabajos recibidos.

Desde ya felicitaciones por el esfuerzo y el compromiso ;-)

Comentario al margen: mi evaluación ya estaba pronta el mismo lunes, pero tuve que esperar a casi 10 usuarios que en vez de "compartirme" el documento como "editor", solo estaba como "lector" del mismo, impidiéndome hacer una copia del trabajo. En esta entrega fui bastante flexible (aunque muchos no lo crean así), y comprendí que las herramientas son en general nuevas para ustedes... algo que no va a pasar en las próximas entregas (tengo que irles soltando la mano progresivamente para que aprendan a caminar solos).

Taller PHP5: "Semana 2 - Ingeniería Inversa"

Esta es la letra de la Semana2 del Taller sobre PHP5:

La "empresa" SurForce, entendiendo que el postulante ha estudiado cabalmente el material que se le sugirió como base, solicita que se apliquen los conceptos aprendidos y resuelva los siguientes requerimientos:

Preparar el entorno de trabajo

Bajar el "proyecto base" desde el repositorio SVN: usando las herramientas instaladas obtener los fuentes del proyecto que se encuentra actualmente alojado en el servicio Google Code.
Reconstruir la base de datos que necesita el sistema (subdirectorio "sql").
Probar todas las opciones del sistema

Documentar el sistema

Se necesita hacer "ingeniería inversa", es decir, usted recibe un sistema que desconoce y que no cuenta con documentación. Se le solicita que analice el sistema y presente una documentación que contenga los siguientes diagramas UML.

Diagrama de "Casos de Uso"
Diagrama de "Paquetes" (presentación, dominio y persistencia)
Diagrama de "Clases" de cada paquete.

Cuestionario

Contestar el siguiente cuestionario (en caso afirmativo indicar claramente en que parte del fuente, en caso negativo, justificarlo de forma detallada)

¿En qué parte del sistema se realiza "herencia"?
¿En alguna parte del sistema se usa "polimorfismo"?
¿Si tuviera que agregar otro tipo de usuario, como un Administrador, qué haría?
Obtenga un ejemplo de "encapsulamiento" y explíquelo detalladamente.

Forma y límite de la entrega

Tienen una semana para investigar, experimentar, y aplicar los conocimientos. El plazo de entrega es el próximo lunes sin prórroga.

Para la documentación deberá usar las siguientes herramientas:

Google Docs - deberá realizar un documento "formal" con toda la información que se le solicita. Luego de finalizado, deberá compartir el documento con el Gerente de Proyectos. El documento deberá llamarse "semana2-nombredeusuario".
Gliffy - se usará para hacer todos los diagramas UML, que luego deberá grabarlos en un archivo gráfico y agregarlos al documento base (punto anterior).

IMPORTANTE: El desarrollador que exceda de esta fecha límite (lunes 5 de marzo) o que en la documentación falte alguno de los requerimientos, será descartado del taller.

PD: todas las dudas sobre los requerimientos podrán hacerse en los comentarios de esta entrada.