En una entrada anterior yo estube hablando un poco sobre la industria del soft, y sobre los componentes, hoy en día, pensar una industria que no trabaje basando su desarrollo en componentes, por las evidentes razones que mensioné en la entrada anterior.
En casos conocidos, podemos apreciar como windows a partir de 98 tiene su modelo de componentes bien formado, y empieza a basar todo su sistema en componentes, empaquetados en archivos conocidos como dlls.
Podemos apreciar sus ventajas con las actualizaciones automáticas, donde gracias a estas dlls es posible implementar extensibilidad en su correcta expresión, de modo que modificar una dll para que haga una tarea bastante diferente y reemplazar una vieja sin tener que modificar el programa es muy simple.
Antes de ayer asistí a una charla en un Instituto de Formación Técnica Superior, que daba Gabriel Pimentel, donde demostró la simplicidad y utilidad de las dlls, creó un programa que utilizaba una dll que también creó para fines demostrativos (todo ésto en c++) cargó la dll y la utilizó en su programa original, compiló el programa, y luego cambió completamente la dll para que hasta cambie de ser modo consola a modo visual creando una ventanita, reemplazó la dll anterior por la nueva, y el programa original la utilizó sin inconvenientes utilizando las nuevas funciones de dicha dll.
Lo interesante de la cuestión es como separó de una forma muy impresionante la dll que emulaba un sensor y el programa que usaba dicho sensor, creó un pequeño modelo de componentes para demostrar la funcionalidad de ésto, luego simplemente cambió el código de la dll, lo compiló, y reemplazó la anterior, y como por "arte de magia" todo su modelo de componentes "comprendió" que estaba ante una nueva versión que incluía una ventana entre otras cosas, para notificar que había llegado al máximo el sensor.
Sin tirar ningún error utilizó dicha dll con la nueva funcionalidad.
Notarán en éste ejemplo algo muy interesante, nos permite pensar a los componentes y a los que usan componentes como lineas separadas de producción, como en una cadena de fabricación de autos, hay una linea de creación de puertas, una linea que fabrica carrosería, y luego se pueden comprar las ruedas a otra empresa, todo esto pasa por una linea de ensamblaje y llega al producto final.
Es muy parecido a lo que es una industria cualquiera, se puede crear un componente y evolucionar por forma propia independientemente de cómo y para qué lo use quien lo use, y si el que usa dicho componente cambia, no va a haber problemas. porque todo se ensambla, además se puede comprar nuevos componentes a otros fabricantes y aquí empieza la industria del software.
Y aquí aparece calidad, uno no puede desarrollar un componente que no cumpla con los criterios de calidad, porque solo generaría un monton de inconvenientes, lo mismo pasa en general, si programas aunque no estés basado en componentes, sin calidad, tu código te dará muchos problemas a la hora de evolucionar, ampliarse o cambiar de contexto.
Programar sin calidad, es como hacer malabares con granadas sin tener el seguro puesto, y es una fábrica de monsters (puede ver la referencia aquí para saber de que hablo cuando comento esto).
Hay dos tipos de criterios de calidad, los criterios externos e internos, es una mera forma de clasificarlos para que se den una idea, los externos son aquellos criterios que el usuario del sistema ve, tales como si tiene una interfaz buena y simple que no vuelva loco al usuario, si responde a las necesidades del usuario, etc. Pero estos criterios en realidad no son los que definimos, ya que no tienen mucho sentido.
Los importantes son los criterios de calidad que nosotros vemos, si nosotros armamos un código sin calidad o con calidad, los únicos que apreciaremos esto somos nosotros.
Hay muchos modelos de criterios de calidad, pero en resumen y juntando todo lo más importante podemos definir los siguientes 7:
Corrección
Robustez
Extensibilidad
Reusabilidad
Compatibilidad
Eficiencia
Otros factores.
Cada uno de ellos serán explicados en futuras publicaciones.
Saludos y espero que haya sido de agrado la introducción al tema.
Podemos apreciar sus ventajas con las actualizaciones automáticas, donde gracias a estas dlls es posible implementar extensibilidad en su correcta expresión, de modo que modificar una dll para que haga una tarea bastante diferente y reemplazar una vieja sin tener que modificar el programa es muy simple.
Antes de ayer asistí a una charla en un Instituto de Formación Técnica Superior, que daba Gabriel Pimentel, donde demostró la simplicidad y utilidad de las dlls, creó un programa que utilizaba una dll que también creó para fines demostrativos (todo ésto en c++) cargó la dll y la utilizó en su programa original, compiló el programa, y luego cambió completamente la dll para que hasta cambie de ser modo consola a modo visual creando una ventanita, reemplazó la dll anterior por la nueva, y el programa original la utilizó sin inconvenientes utilizando las nuevas funciones de dicha dll.
Lo interesante de la cuestión es como separó de una forma muy impresionante la dll que emulaba un sensor y el programa que usaba dicho sensor, creó un pequeño modelo de componentes para demostrar la funcionalidad de ésto, luego simplemente cambió el código de la dll, lo compiló, y reemplazó la anterior, y como por "arte de magia" todo su modelo de componentes "comprendió" que estaba ante una nueva versión que incluía una ventana entre otras cosas, para notificar que había llegado al máximo el sensor.
Sin tirar ningún error utilizó dicha dll con la nueva funcionalidad.
Notarán en éste ejemplo algo muy interesante, nos permite pensar a los componentes y a los que usan componentes como lineas separadas de producción, como en una cadena de fabricación de autos, hay una linea de creación de puertas, una linea que fabrica carrosería, y luego se pueden comprar las ruedas a otra empresa, todo esto pasa por una linea de ensamblaje y llega al producto final.
Es muy parecido a lo que es una industria cualquiera, se puede crear un componente y evolucionar por forma propia independientemente de cómo y para qué lo use quien lo use, y si el que usa dicho componente cambia, no va a haber problemas. porque todo se ensambla, además se puede comprar nuevos componentes a otros fabricantes y aquí empieza la industria del software.
Y aquí aparece calidad, uno no puede desarrollar un componente que no cumpla con los criterios de calidad, porque solo generaría un monton de inconvenientes, lo mismo pasa en general, si programas aunque no estés basado en componentes, sin calidad, tu código te dará muchos problemas a la hora de evolucionar, ampliarse o cambiar de contexto.
Programar sin calidad, es como hacer malabares con granadas sin tener el seguro puesto, y es una fábrica de monsters (puede ver la referencia aquí para saber de que hablo cuando comento esto).
Hay dos tipos de criterios de calidad, los criterios externos e internos, es una mera forma de clasificarlos para que se den una idea, los externos son aquellos criterios que el usuario del sistema ve, tales como si tiene una interfaz buena y simple que no vuelva loco al usuario, si responde a las necesidades del usuario, etc. Pero estos criterios en realidad no son los que definimos, ya que no tienen mucho sentido.
Los importantes son los criterios de calidad que nosotros vemos, si nosotros armamos un código sin calidad o con calidad, los únicos que apreciaremos esto somos nosotros.
Hay muchos modelos de criterios de calidad, pero en resumen y juntando todo lo más importante podemos definir los siguientes 7:
Corrección
Robustez
Extensibilidad
Reusabilidad
Compatibilidad
Eficiencia
Otros factores.
Cada uno de ellos serán explicados en futuras publicaciones.
Saludos y espero que haya sido de agrado la introducción al tema.
0 comentarios:
Publicar un comentario