Curso en Universidad ORT: "Desarrollo de Sistemas Web con PHP 5" (4 meses)

Les comento que el día 16 de abril de 2007 (mes próximo) está iniciando mi curso (presencial ;-)) de "Desarrollo de Sistemas Orientados a Objetos con PHP5" en la Universidad ORT. Este curso se enmarca dentro del programa "Cursos de Actualización Profesional" dirigido a profesionales en el área de sistemas que deseen especializarse en el desarrollo de aplicaciones para Internet, a través de un enfoque más cercado a la Ingeniería de Software que al simple scripting y desarrollo estructurado que estamos acostumbrados a ver en PHP (bueno, ya creo que está casi de más decirlo si lees este blog ;-)).


Bajar el folleto (pdf)


Los horarios: Martes y Jueves de 19:30 a 22:30

Buscando en este blog por la etiqueta "ORT" podrán encontrar toda la información que desde el año pasado vengo compartiendo sobre el dictado del curso. Se desprende claramente de todo lo que he escrito sobre el tema:

[No es un curso tradicional de PHP]

Por lo pronto solo es para residentes en Uruguay, pero se escuchan ofertas para dar charlas especializadas sobre este tema, o dictados más extensos fuera de fronteras. ;-)

PD: curiosidad aparte, la semana que viene también estaré dictando la materia "Programación Web" (horario matutino) para las carreras Analista Programador y Analista en Tecnologías de la Información. En este caso más que Desarrollo de Sistemas y Orientación a Objetos vamos a concentrarnos en la Capa de Presentación y en RIA (Ajax, JSON, prototype y probablemente scriptaculous).

Solución Semana 3: "Cuestionario" (III/III)

Bueno, llegamos al final al cuestionario, donde debíamos responder algunas preguntas "macabras" (¿tan difícil es razonar? sí, lo es, porque hay que aplicar lo que se aprendió).

Cuestionario

Pregunta: ¿Cómo se representa en código PHP la existencia de una dependencia entre estos elementos?

Respuesta: Con cualquier sentencia de inclusión de fuentes: include, include_once, requiere, require_once. Es eso, nada más que eso, eso es lo que representan los diagramas UML. Cómo un fuente depende de otro, y si depende, es que lo usa de alguna forma, y en PHP es usando alguna de las funciones de inclusión (en los demás lenguajes es igual, solo cambiará la sintaxis. UML se aplica a cualquier lenguaje orientado a objetos).

Pregunta: ¿Analizando estas dependencias en sentido inverso, cómo se representa en código PHP?

Respuesta: Entendiendo el concepto, la pregunta *claramente* no tienen sentido. Si existe dependencia entre:

Presentación->Dominio->Persistencia

Significa claramente que Presentación ve solo a Dominio, Dominio ve solo a Persistencia, pero al revés ninguno puede verse, pues así queda representado en el diagrama. Los include/requiere van de arriba a abajo de los paquetes, en el sentido de las flechas. Si hubiera visibilidad en ambos sentidos habría que agregar un include/require de Persistencia->Dominio->Presentación (invertido) lo cual estaría mal, pues se puede deducir que:

• Del diagrama correcto: los cambios de persistencia solo afectan a dominio y tal vez a presentación si dominio se ve obligado a cambiar (el otro significado de las flechas, ver cómo el paquete que apunta a otro es dependiente de sus cambios).
  

• Del diagrama de "todos se ven a todos": cualquier cambio afecta a todos en cascada y en ciclos, lo que significa "sistema inestable y peligroso ante cualquier cambio".

Pregunta: ¿Cómo se verifica que existan cambios (y cuales fueron) en el repositorio SVN?

Respuesta: sobre el proyecto, menú contextual (botón derecho), Team->show history

Y mostrará el siguiente mensaje:

7/03/07 00:27 - enriqueplace
- cambia estética (css, templates)
- se agrega un campo nuevo "descripción"

¿No era tan difícil, o sí? ;-)

Solución Semana 3: "Consultas de Usuarios incompleta" (II/III)

Como decía anteriormente, "hacer un sistema es un tema de orden", entonces hagamos un "mapa" para saber donde estamos parados y hacia donde vamos.

Para hacer el formulario

ConsultarUsuario -> PresentaciónFachada

Una vez que ejecutamos el módulo correspondiente el formulario de consultas queda generado a partir del template contenido_consultar_usuario.tpl.html, esperando luego a que se ingrese información y presione el botón "consultar".

Ejecutar el formulario

Estando en el formulario, luego de ejecutar el botón "consultar", se invocarían a partir del template contenido_consultar_usuario.tpl.html:

MostrarUsuario -> PresentacionFachada -> DominioFachada -> PersistenciaFachada

Bien, el tema es el siguiente: ahora tenemos más de un parámetro que recibimos por $_REQUEST (que engloba a GET y POST), lo cual podemos usar varias estrategias:

• Agregar los parámetros que necesitamos en la firma del método ejecutar y en todos los métodos que lo necesiten, capa por capa (vamos a tener además del id y nombre, la descripción).
• Colocar un genérico $_REQUEST sin parámetros, que resultará en el array completo con lo que recibamos desde el formulario. También funcionaría $_GET o $_POST. (Nota: hay que tener en cuenta la seguridad de un sistema al recibir desde el "exterior" cualquier tipo de información).
  

Usemos esta última opción:

• DominioFachada::traerObjetoUsuario( $request )
• PersistenciaFachada::traerUsuario( $request );
  

Diagrama de Secuencia

Aprovechemos para conocer como trabaja un diagrama de secuencia y para qué nos puede servir. Lo ideal es que sea parte del diseño a "bajo nivel" antes de empezar codificar, como un plan para saber exactamente como trabajará nuestro sistema y como será implementado... todos los métodos estarán definidos de antemano con sus objetos y solo deberemos posteriormente programar su contenido. En este caso, lo usaremos al revés, definir un mapa a partir de lo que existe y validar que el diseño sea correcto (por ejemplo, respetar el correcto acceso a las 3 capas).


Este diagrama está dividido en dos etapas: cuando se ejecuta por primera vez y armar el formulario de consultas, y cuando se presiona le botón de "consultar" para generar todo el proceso de búsqueda de información en la base de datos.

En la primer etapa solo podemos documentar en este caso como se invoca el template, puesto que ahí quedamos a la espera de la acción del usuario. Cabe aclarar que no necesariamente deberíamos documentar el trabajo con el sistema de templates porque se puede dar por convenido que su funcionamiento se conoce y solo se necesita explicitar el resto de la lógica.

En la segunda etapa se parte del accionar del botón de búsqueda que genera la invocación en cascada de cada método de cada clase de cada paquete, hasta obtener el resultado buscado.

Varias salvedades para tener en cuenta:

• Las flechas que aparecen en el diagrama representan las llamadas a los métodos perteneciente a cada Clase, es decir, muestran claramente el concepto de que la interfaz de los objetos son sus métodos públicos y los clientes de esos servicios son los que los invocan.
• El nivel de profundidad en la documentación dependerá de nuestro contexto, y cada comentario (en UML es el dibujo que representa una "nota" con la punta doblada) puede aclarar la parte que se toma como obvia y que no aparece en el diagrama.
• Muchos autores sugieren que no es necesario mostrar una flecha de retorno de datos (de derecha a izquierda), y menos todas las veces que sucede esta acción, puesto que lo importante es marcar el camino para generar la comunicación entre los objetos. Perfectamente podría ir al final del segundo diagrama una flecha de retorno que volviera a cada capa documentando que retorna un array con el objeto Usuario encontrado, pero podría considerarse redundante porque se supone que esto sucede.
• De la misma forma que en la parte 1 -que no es necesario documentar el Template- en la parte 2 no es necesario documentar SentenciaSQL (framework).
  

Finalmente, ya lo hemos dicho con los Casos de Uso, los diagramas son "interpretativos" y están sujetos a un contexto y a la documentación que debe acompañar siempre. Nosotros documentamos lo que queremos y esto está sujeto a un contexto y a nuestro "público objetivo".

Dudas, preguntas, en los comentarios ;-)

Solución Semana 3: "Diseño en 3 capas" (I/III)

Bueno, voy a dar una solución al primer requerimiento del desafío de la "Semana 3" que no necesariamente ustedes debieron acercarse a la versión que voy a presentarles (trato de dar un paso más adelante).

Conceptualmente hablando

Desde nuestros "módulos" (index.php, listado_usuarios.php, consultar_usuario.php y mostrar_usuario.php), ubicados en la raíz del proyecto, debemos asegurarnos que la "dependencia" (flecha punteada) sea solo con el "paquete de presentación" y no con el resto de los paquetes (como se ve en el primer diagrama). Si nuestro sistema está organizado en 3 capas (siguiendo el segundo diagrama corregido, presentado a continuación) la forma de trabajo debería ser siempre:


"módulo" -> "presentación" -> "dominio" -> "persistencia"

• "presentación": resuelve la interfaz, arma las pantallas, pero si necesita datos pasa a solicitarlos al dominio.
• "dominio": donde se encuentran todos los objetos que representan la lógica de nuestro universo, de nuestro problema, de nuestro negocio (por eso también se le dice "capa de lógica de negocio"). Por ejemplo, si queremos mostrar un usuario este estará representado como un objeto de tipo Usuario la información para crearlo está en esta capa.
  
• "persistencia": si necesitamos "persistir" la información para poder volver a recuperarla en un futuro, es decir, todas las operaciones conocidas: recuperar sus datos, grabar datos o modificar los existentes, eso representa acceder a la capa de "persistencia", quien se encarga de comunicarse con la herramienta de turno (una base de datos, un archivo plano, xml, webservices, etc).
  

Capas = Responsabilidades

Cada capa tienen su responsabilidad única, concreta, bien definida. De esta forma tenemos a nuestro sistema bien diseñado, dividiendo los problemas en partes diferenciadas. Si hay que modificar o agregar funcionalidades, hay que ir a una capa concreta y no tocar todos los fuentes de nuestro sistema. De la misma forma, si una capa hay que cambiarla por otra, se puede hacer intercambiándolas, o hasta usándolas ambas hasta que una sustituya a la otra, de forma casi transparente.

Si queremos cambiar la estética, solo se modifica la capa de presentación. Si queremos cambiar la lógica del funcionamiento del sistema, la capa de dominio, y si queremos hacer cambios en la forma de almacenar la información, la capa de persistencia.

Nota: no siempre es tan literal, puesto que si agregamos un "caso de uso" a nuestro sistema, deberemos crear la interfaz, reutilizar o crear parte de la lógica del dominio existente, y si no existe, agregar la funcionalidad para persistir el nuevo objeto.

Hay dos frases que entran en juego aquí:

• "Divide y conquistarás" (frase histórica)
  
• "Desarrollar un sistema es, fundamentalmente, un problema de orden" (mía ;-))
  

Dividir nuestro sistema en 3 o más capas, y cada una resuelva un problema, es justamente eso, trabajar de forma ordenada teniendo el control de lo que sucede.

Cambios a realizar

Claramente se detecta en el diagrama las clases que se está rompiendo el diseño de 3 capas y accediendo a cualquier capa sin ningún tipo de orden. Los fuentes involucrados son: listado_usuarios, consultar_usuario y mostrar_usuario.


Repasando: deberían entrar por la capa de presentación y luego esta capa -y solo esta- acceder a las demás capas.

index.php

• Siguiendo el diagrama, este módulo se convierte en una clase (así tratamos de transformar nuestro desarrollo híbrido en un sistema 100% Orientado a Objetos, objetos que se comunican con objetos), por lo que habría que encapsular todo en una clase (se obtiene la estructura interpretando el diagrama).
• La dependencia es correcta puesto que apuntaba únicamente al paquete de presentación.
• No cambiamos de nombre el fuente a Index.class.php porque romperíamos el estándar y nuestro servidor no encontraría el index.php, pero internamente sí la convertiremos en una clase (Nota: esto es una convención que se me ocurrió crear, no necesariamente encontrarán esta forma de trabajo explicada en ningún libro).
  

listado_usuarios.php

• Este es el primer fuente que muestra claramente la dependencia contra dos paquetes (presentación y dominio) cuando debería ser solo con el primero, y luego pasar de presentación a dominio. Esto se lee en PHP simplemente viendo la sentencia require, require_once, include o include_once (aquí ya estoy respondiendo la pregunta del cuestionario).
• Dijimos que todo iban a ser clases, entonces, creamos una clase ListadoUsuarios
• Mantenemos el mismo nombre, rompiendo la nomenclatura porque así lo necesitamos ahora para poder acceder desde http://localhost/surforce-proyectobase/listado_usuarios.php (no usamos ListadoUsuarios.class.php por la misma razón que no decidimos hacerlo con index.php).
• Debemos modificar PresentacionFachada::listarUsuarios del paquete presentación para que resuelva internamente las invocaciones a la capa de dominio. Simplemente evitamos tener que hacerlo en el módulo y estas se esconden dentro del paquete que corresponde.
  

presentación/PresentacionFachada.class.php

• El método listarUsuario deja de recibir por parámetros los usuarios y ahora internamente llama al dominio para solicitarlos. El módulo ni se entera (no debe) pues es una responsabilidad de la presentación obtener los datos del dominio, el módulo solo debe ejecutar la acción de la capa de presentación, el resto, un problema interno que no me corresponde enterarme. Es importantísimo entender esto para que nuestro sistema esté "desacoplado" y pueda ser "reutilizable".
  

mostrar_usuario.php

• Similar al caso anterior, creo una clase, saco el código del dominio del módulo y lo muevo a la capa de presentación, y me quedo solo con llamadas a la capa de presentación.
• En presentación modifico para que invoque ahora al dominio (como decía anteriormente, simplemente es pasar la lógica del módulo al paquete presentación).
  

Hasta aquí solucionamos el problema de "las 3 capas rotas", ahora, terminemos de corregir para que cada módulo sea una clase:

consultar_usuario.php

• Similar a los casos anteriores, encapsulo todo en una clase y luego invocamos el método que inicia la acción (método ejecutar).

Fin de la parte 1 del desafío "Semana 3"

Pronto, un poco más, un poco menos, es lo que se esperaba de la "parte 1".

Dudas y consultas, en los comentarios de esta entrada. ;-)

Desafío Semana 4: "Modularizar el sistema" (actualizado 23/3/2007)

Nuevamente el Gerente de Proyectos, receptivo a los trabajos entregados y a todos los comentarios de sus subordinados, comprende que aún le falta hacer cambios en el diseño del sistema base entregado, por lo tanto decide solicitar un informe explicando las siguientes mejoras:

• Sistema modular: centralizar las invocaciones que puedan venir únicamente a través del index.php y no del resto del sistema. Solo se ingresa por index.php y luego a los módulos correspondientes. Evitar el acceso por cualquier ruta distinta a index (concepto "web modular").
• Eliminar los módulos por invocaciones a clases: eliminar los archivos que hoy día representan a los módulos de nuestro sistema (por ej. listado_usuarios.php) y desde el punto de entrada único (index.php) hacer invocaciones a las clases correspondientes que ofrecen esos servicios (por ej. ListadoUsuarios). Las clases no pueden estar definidas dentro de index.php y deberán crearse archivos para cada clase respetando la nomenclatura aprendida hasta el momento. Se solicita actualizar el diagrama de paquetes que represente todos estos cambios.
  
• Clases Abstractas: hacer una lista de todas las clases que no son necesarias instanciarlas en el sistema y que deban ser "abstractas". Explicar la implementación, justificar la selección y la razón de esta decisión.
• Mejorar la búsqueda: corregir la búsqueda por nombre y descripción para que pueda obtener más de una coincidencia (actualmente solo trae una).
• Seguridad: el sistema actual confía de los datos que recibe, lo cual puede convertirse en un problema de seguridad a través de un ataque del tipo "sql injection". Proponer una solución a este problema.

Versión del Sistema Base

Deberán esperar a que se actualice la última versión del sistema, que estará disponible en las próximas horas y tendrá todos los cambios realizados para la entrega "Semana 3".

Forma y límite de la entrega

• Seguiremos manejando un período de 1 semana, la entrega se hará el lunes 26/3/07.
  
• Documento "compartido" (que permita modificarlo) con el siguiente nombre "semana4-[idDeUsuario]".
• Quién no cumpla con los requerimientos es automáticamente pasado al estado "deshabilitado" dentro del taller, lo cual queda fuera de las evaluaciones de los trabajos y de una futura asignación a un equipo de desarrollo en SurForce.
• Se penalizarán todos los errores: cualquier detalle mencionado en esta entrada, más las faltas de ortografía, no uso de las herramientas oficiales, faltantes en las entregas, etc.
  

PD: dudas sobre los requerimientos, en los comentarios de esta entrada.

Actualizaciones

• 23/03/2007 - se corrige redacción punto 2.
  

Inicio corrección de la "Semana 3" del taller

Algunos usuarios me han enviado correos preguntando si estaba vivo o si me había desmotivado, pero ya les confirmo que estoy bastante lejos de claudicar ;-)

Tirado en el piso, cansado. Mi hija mayor (3 años) me insiste en sacarme una foto con el celular (hasta que lo logra)

Como anuncié desde el principio de la creación de este "taller piloto", mi objetivo es , además de tratar de transmitirles conocimientos que permitan subir el nivel de nuestros desarrollos en PHP, que aprendamos todos de la experiencia general, así poder sacar nuestras propias conclusiones y contar a futuro con mejores herramientas para aplicarlas en proyectos que involucren todas estas disciplinas (educación a distancia, gestión, diseño, desarrollo, teletrabajo, screencasts, blogging, etc).

Una de las tantas cosas que estoy aprendiendo (gracias por todos sus comentarios respondiendo mis preguntas) es que un desafío por semana puede ser muy exigente tanto para quién lo crea como para quién debe cumplirlo. Además de recibir todos vuestros trabajos, debo corregirlos, y a su vez, quiero basarme en sus errores para ajustar el desafío siguiente (es la esencia de la didáctica que estoy usando).

Aunque parece una foto montada, es real. Mi hija preguntando "¿qué es esto?", lo cual le respondo "la representación del 'paquete de dominio', la 'lógica de negocio', ¿se entiende?" (espero que ustedes ahora también ;-))

Por lo tanto me tomé unos días para que ustedes y yo descansemos, y recién hoy estoy empezando a corregir sus trabajos (Semana3). Asumo que me llevará todo el día y en base a las conclusiones que saque a última hora les estaré publicando el desafío de la "Semana 4" (estimo que en la madrugada del domingo lo publicaré, acorde al ritmo de vida de todo vampiro ;-)).

Empezamos con 100 inscriptos, en la semana 2 entregaron trabajos 37 y en esta semana 19. Veremos con cuantos terminamos ;-)

Aquí está la planilla donde me pueden ver trabajar, durante el correr de todo el día verán cambios (la hoja de cálculo permite configurar para que cada 5 minutos se actualice su vista pública), por consiguiente, pueden quedarse junto a mi para conocer los trabajos de sus colegas y ver cuando yo les evalúe. ;-)

Si ven que la nota sube y baja, no se preocupen, hasta que no ponga la fecha de cierre la nota es provisoria ;-)

Dentro de horas más novedades.

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

1. Desafío Semana 2 - Ingeniería Inversa
   
2. Comentarios sobre la evaluación
3. Solución - Diagrama de Casos de Uso (I/IV)
   
4. Solución - Diagrama de Paquetes (II/IV)
   
5. Solución - Diagramas de Clases (III/IV)
   
6. Solución - Cuestionarios (IV/IV)
   

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.

Están llegando los primeros trabajos correspondientes a la "Semana3"

Bien, esto me pone muy contento ;-). Desde el día 11 estoy recibiendo los trabajos correspondientes al desafío de la "Semana 3 ", que justamente finaliza hoy.

Siguiendo con los experimentos (creo que debo ser el resultado de uno, no lo sé) dejé disponible una planilla que actualizo regularmente para que sirva de confirmación que recibí vuestros trabajos.

Recomendaciones

• No voy a corregir ningún trabajo hasta mañana, cuando oficialmente cierre la fecha de entrega. Luego, copio la versión original, y trabajaré sobre un nuevo documento donde yo seré el único editor. Resumiendo, todavía pueden hacer correcciones de último momento. Nota: si alguien se le ocurre un servicio para recomendar del estilo "hora centralizada en Internet", me avise (sé que existen proyectos para sincronizar reuniones con personas distribuidas geográficamente, pero no he encontrado ninguno que parezca confiable).


• El nombre del documento debe ser "semana3-[idUsuario]", lo que se debe traducir como "semana3-23". Si se equivocaron pueden cambiar de nombre sin problemas, pues inteligentemente Google usa un link único y este no cambia una vez creado el contenido. También pueden poner sus datos personales dentro del documento, en el cabezal del mismo (nombre, usuario de gmail, país, etc), como se estila en documentos formales.


• No comentan errores de ortografía, ni de redacción, sean concisos. De ahora en más voy a penalizar esas equivocaciones. Para las respuestas sean breves, pues sucedió en las entregas de la Semana 2 que la primer frase era correcta pero luego se iban por las nubes y se equivocaban en tonterías, tal vez, por simple distracción.

Con respecto a la revisión y cierre de la Semana 2, por un tema de tiempos y compromisos (sí, tengo vida fuera de Internet ;-)) estoy un poco demorado, pero debería concluir hoy.

Próxima apertura de los grupos de trabajo

Como novedad les confirmo, el mes próximo empezamos a abrir los grupos de desarrollo para seguir con los trabajos de forma real y práctica. Sus desafíos personales se volverán desafíos grupales, donde deberán aportar cumpliendo sus tareas. En este momento solo participarán los que han entregado los trabajos de la Semana 2 y Semana 3, y los restantes desafíos que seguiré publicando durante el mes de marzo. Posteriormente, se volverá a abrir el registro de usuarios y cambiaremos la forma de integrarlos a los equipos de trabajo existentes. Muy probablemente se les solicitará una tarea puntual que resumirá todo el proceso de desafíos y si la aprueban quedarán clasificados para participar como desarrolladores o líderes.

Dentro de poco más novedades ;-)

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)

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

Respuestas esperadas

1. 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.
2. 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".
   
3. 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.
4. 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 ;-)