Archive for the ‘Diseño’ Category

Blender

Viernes, Octubre 8th, 2010

Logo

En este post, he decidido hablaros de una herramienta llamada Blender, la cual ha sido el instrumento principal en la realización de mi PFC en la Universidad Politécnica de Madrid. El proyecto consistía en la simulación de efectos meteorológicos, tales como avalanchas o incendios, y a pesar de que en un principio la utilización de la herramienta es compleja y necesita mucho tiempo de investigación, finalmente me ayudo a conseguir un resultado óptimo.

Es un programa multiplataforma para modelar, animar y crear gráficos tridimensionales. Es de distribución libre y pese a que su interfaz es complicada y poco intuitiva, el programa tiene muchas ventajas sobre otros programas con la misma dedicación.

Interfaz

Entre las características mas relevantes tenemos:

* Tamaño de origen realmente pequeño comparado con otros paquetes de 3D.
* Gran variedad de primitivas geométricas, incluyendo curvas, mallas poligonales, vacíos, NURBS, metaballs.
* Incluye cinemática inversa, deformaciones por armadura o cuadrícula, vértices de carga y partículas estáticas y dinámicas.
* Edición de audio y sincronización de vídeo.
* Características interactivas para juegos.
* Renderizado interno versátil e integración externa con potentes trazadores de rayos.
* Lenguaje Python para automatizar o controlar varias tareas.
* Blender acepta formatos gráficos como TGA, JPG, Iris, SGI, o TIFF.
* Motor de juegos 3D integrado.
* Simulaciones dinámicas para softbodies, partículas y fluidos.

Actualmente, blender va por la versión 2.54 Beta, ha sido la principal herramienta usada en el largometraje “Plumíferos”, el cual es el primero realizado íntegramente con software libre, y fue usado en la producción de “Spider man 2″ para la previsualización de escenas.

Gracias.

Tags: , , ,
Posted in Diseño, Implementación, desarrollo, open source | No Comments »

Listado de características v/s Casos de Uso.

Viernes, Febrero 16th, 2007
Se supone que cuando empezamos en un desarrollo tenemos un listado de características con lo que debe hacer el sistema y luego hacemos nuestros Casos de Uso. El tema es ¿Cuál debo hacer?, ¿Es mejor cumplir una característica completa? o ¿enfocarnos en los casos de uso?, la respuesta es "depende".

Plantéo el siguiente escenario:

La aplicación debe :
  • Enviar un SMS que indique tiempo al cual se encuentra un Autobus desde un paradero al recibir un SMS con el siguiente formato: "Paradero LineadeAutoBus" Ej.: 105 591
Esto de "la aplicación debe" son nuestro Listado de Características.

Y como consecuencia de este Listado de Características obtenemos los famosos Casos de Uso, que serán nuestra compañía el resto del desarrollo.

Los Casos de Uso son:




¿Con que partimos para desarrollar?, pues tenemos las 2 alternativas:

  1. Realizar la Característica 1.
  2. Realizar un caso de uso.
Para decidir se considera el nivel de visibilidad comprometido, si el cliente tiene un poco de paciencia podemos partir por los casos de uso; si no partimos con la característica.

Estoy seguro que el desarrollo con casos de uso nos permitirá un diseño elegante desde un primer momento, pero que a lo mejor tardaremos un poco más en mostrar algo completo - recordemos que los clientes quieren resultados, no diagramas de Ingeniería que sólo nosotros entendemos - debemos hablarle en su lenguaje.

Si tenemos un poco más de tiempo conviene comenzar con los Casos de Uso, si no tratemos más "visual" el entregable y realizemos primero alguna de las características. Finalmente el producto tendrá la calidad de hacer lo que tiene que hacer, de haber aplicado principios de OO y la elegancia de los patrones de diseño.

Tags: , ,
Posted in Calidad, Casos de Uso, Diseño, Noticias internas, Requisitos | No Comments »

Cultura de Prototipos/Maquetas

Jueves, Febrero 15th, 2007
Como todos sabemos - pero nos cuesta aceptarlo - la única constante en Desarrollo de Software es el cambio.

El maldito cambio, simplemente debemos ser más inteligentes: Tener en la cabeza que las cosas cambian y que nuestra obsesión por implementar funcionalidad lo antes posible con classes perfectas nos lleve a codificar de más.

¡Pero un momento!, ¿codificar de más?, si - aunque me costó creerlo mientras antes se empieza a escribir código más tarde finalizaremos el proyecto.

¿Por qué?, por que nuestra obsesión no considera que los cambios ocurrirán y que el cliente simplemente quería otra cosa, o se ajustó esta regla de negocio y tal, y tal, y tal, y tal .......

Solución: Cultura de Prototipo.
  1. Conversamos con el cliente.
  2. Formalizamos lo conversado en una Lista de Características.
  3. Revisamos con el cliente esta lista.
  4. Especificamos los requisitos de las características que tienen mayor prioridad.
  5. Hacemos un protipo - sin funcionalidad.
  6. Revisamos con el cliente el Prototipo/Maqueta (que tardamos a lo más 2 horas en hacerlo con HTML o drag&drop), revisamos la Lista de Características y así nos aseguramos que vamos bien con el cliente.
  7. Repetimos en cada iteración que sea necesario.
  8. Continuamos con los paso habituales de Desarrollo Iterativo e Incremental.
Se ve muy simplista, estoy de acuerdo, lo importante es que ya estamos listos para:

  1. Asegurar que el sistema hará lo que el cliente quiere.
  2. Aplicar principios de OO.
  3. Aplicar patrones de Diseño y le damos caracter de Ingeniería a la obra de arte.
En ese orden, funciona créanme!.

Con un gran amigo aprendimos que no hay que mostrar los diagramas de classes, ni nada parecido al cliente. Le mostramos los artefactos en su propio lenguaje: Un listado de características en el cual identifique cláramente lo que quería.

A pesar de todo esto siempre surgirán nuevos cambios, pero ya tendremos una arquitectura extensible y no hemos perdido horas de trabajo de implementación - No existen malos equipos, sólo malos líderes.

¿Si, te parece que eso lo implementemos en la próxima versión?

Tags: , ,
Posted in Calidad, Diseño, Noticias internas | No Comments »

Como tener Log en PHP5 y no morir en el intento

Jueves, Febrero 15th, 2007
Log?,

/**
* Classe: Log
* Responsabilidades: Escribe los Logs de usuario en la carpeta log/
* Colaboradores: No tiene.
* Patron: Singleton.
* Uso Principal: Log::getInstance()->addEntry('Mensaje','Classe que invoca','Metodo que invoca',$editMode);
*
* @author Leo Barrientos C. leobarrientos@opendesarrollo.cl
* @copyright GNU
*/

Esta classe genera un log por día en la carpeta log y en modo testMode=true guarda el archivo añadiéndole un .test al final.

Además usa un patrón singletón por lo que la llamada es con el famoso "::" y muy simple:

include_once("Log.class.php");
Log::getInstance()->addEntry('Test','No class','No Method', false);

El diagrama de Classes es el siguiente:


Puedes descargar el archivo haciendo click(Con el mouse) aqui.

Tags: , ,
Posted in Catch, Diseño, Implementación, Noticias internas, Patrones, Try, php5 | No Comments »

Principio de Single Responsibility

Jueves, Febrero 15th, 2007
¿Qué sucede cuando tenemos alguna classe y unos de sus métodos no "suena bien"?, pues es tiempo de aplicar los principios de la orientación a objetos.

En esta oportunidad mostraré un ejemplo del Principio de Single Responsability(SRP).

Supongamos que tenemos una classe Almacen de un sistema de Inventario de Productos, el diagrama de Classes inicial se muestra en la figura 1.


Figura 1: Diagrama de Clases Rev 1.

Pues bien, vamos a aplicar "elegancia" al Diagrama de Classes aplicando el SRP llenando la siguiente tabla:

Classe: Almacén

El almacén __________________

En el espacio vamos agregando los métodos y acomodando el lenguage a ver si tiene sentido en las reglas del negocio de nuestra aplicación.

Classe: Almacén
  • En el almacén se puede agregar un Item.
  • Del almacén se puede remover un Item.
  • El almacén imprime el Inventario.
  • El almacén puede despachar envíos.

¿Hay alguna frase que no tenga sentido con lo que entendemos que hace un almacén? Claro que si:

  1. El almacén no imprime un inventario, lo que hace es devolver la información de todos los items que están en él o sea el Inventario; o mejor aún una lista de Items(List, Collection o array, lo que sea.).
  2. El almacén no despacha envíos, lo que si despacha envíos es un Despachador que solicita ciertos items al almacén.
Con esto, reconocemos los sustantivos y acciones y actualizamos nuestro Diagrama.

Figura 2: Diagrama de Clases Rev 2.

Bueno, ahora revisemos si esto tiene sentido:

Classe: Almacén
  • En el almacén se puede agregar un Item.
  • Del almacén se puede remover un Item.
Classe: Despachador
  • El despachador puede despachar envíos.
Classe: Inventario
  • El Inventario se imprime.

Si, tiene sentido!.

Ahora pseudo codifiquemos un test para ver si funciona:

Caso de Prueba: Imprimir el Inventario actual.

inventario = new Inventario();
inventario.imprimirInventario();
inventario = null;

Si funcionará , pues con UML definimos que el método imprimirInventario depende del método getItems del Almacén y recibirá correctamente el contenido actual del almacén.

¿Comentarios?.

Tags: , ,
Posted in Diseño, Noticias internas, Orientación a objetos, Principios | No Comments »