lunes, 22 de octubre de 2012

Origen: El sueño de la reutilización


La reutilización supone no reinventar la rueda, es decir apoyarse de soluciones, componentes, o desarrollos ya implementados. Este concepto, que se ha convertido en estratégico en el ámbito de la ingeniería del SW, equipara su construcción a otras ingenierías industriales basadas en ensamblar componentes previamente diseñados.

Hay ventajas claras en su aplicación como, por ejemplo, la reducción del tiempo de desarrollo al no tener que implementar desde cero, o la capacidad para poder diseñar o abordar problemas cada vez más complejos. Si no se aprovecha nada de lo ya realizado no sería posible enfrentarse cada vez a problemas más difíciles. Si bien hay que tener en cuenta que reutilizar no siempre es posible, o al menos la mejor de las soluciones, como comenté en este artículo.


La reutilización se puede abordar a distintos niveles de detalle o granularidad. De este modo y, elaborando un símil con la película “Origen”, en donde se describían los distintos niveles del sueño, voy a sumergirme en los modos de implantar la reutilización. Así, de mayor a menor nivel de abstracción podríamos tener:

1.- A nivel de aplicación
2.- A nivel de servicio
3- A nivel de componente
4- A nivel de código de un desarrollo

1.- En el nivel de aplicación pueden ocurrir los siguientes casos:
  • Uso directo de una aplicación existente. El usuario necesita apoyarse en una aplicación para una determinada gestión, pero ya existe una que cubre sus necesidades. En vez de construir una nueva se hace uso de lo ya existente. Este tipo constituye la máxima reutilización posible, ya que no hay que desarrollar absolutamente nada nuevo. Para su adecuado éxito es necesario que se adapte completamente a lo que el usuario necesita, si no se quiere perder versatilidad. Además, debe existir un directorio de aplicaciones con información de las mismas, para que se conozcan todos los servicios disponibles en el ámbito de trabajo. En el de la Administración Pública supondría potenciar el centro de transferencia tecnológica (CTT) y la forja de proyectos.

  • Adaptación de una aplicación ya existente. El usuario necesita una aplicación pero existe una que cubre en parte sus necesidades. En vez de construir una nueva desde cero se modifica lo existente. Típica solución en la que se obtiene el código fuente cedido por el responsable del aplicativo para poder evolucionarlo al gusto y conforme a las necesidades propias. La decisión de acometer o no esta solución pasa por verificar que el coste de la modificación del código existente no supera el importe del desarrollo a medida. No hay que obviar en esta estimación que mantener código no desarrollado internamente es siempre más costoso.

2. – En el nivel de servicio se dan los siguientes tipos:
  • Uso de servicios externos. En el desarrollo de una aplicación hay que implementar una funcionalidad que ya se ofrece como servicio externo. Por tanto, en vez de implementarse en el aplicativo se invoca al servicio existente. Algunos ejemplos en el ámbito de la Administración Pública son @firma o los Servicios de Intermediación como el de validación de datos de identidad.

    Así como en otros tipos se plantean dudas sobre la conveniencia de la reutilización, en este caso suele ser muy recomendable. La razón fundamental es porque los servicios externos están desarrollados para tal fin y por tanto ofrecen unas garantías muy contrastadas.

    La solución tecnológica más empleada actualmente en este modelo es el uso de Servicios Web, y un modelo que se está extendiendo para darles cobertura es la nube.
  • Utilización de servicios internos. Similar al modelo anterior, pero en este caso el servicio es interno, es decir construido por la propia unidad. Para ello, previamente la organización ha tenido que analizar aquellos más utilizados en su ámbito de trabajo y ha implementado una capa de servicios comunes.

    A diferencia del tipo anterior, su ámbito se reduce a la organización y por ello no son ofrecidos como servicios externos. Ejemplos de este tipo son la gestión de perfiles en las aplicaciones o la generación de CVE (Códigos de Verificación Electrónica).

    La reutilización de este modelo también es recomendable. Como en los externos, los servicios están desarrollados para tal fin. Sin embargo, es importante que el área que los dé soporte esté dedicada a ellos exclusivamente y no tenga en su negocio aplicaciones verticales que mantener. De lo contrario el mantenimiento se puede deteriorar y se podría cumplir la frase “ser más educado con los de fuera que con los de tu propia casa”.

    La solución tecnológica más empleada actualmente en este modelo es el uso de Servicios Web.
  • Uso de un Framework. Supone una evolución del anterior tipo e implica que ante la necesidad de acometer un nuevo desarrollo, en vez de empezar de cero, se pueda utilizar un framework que abstraiga de los detalles que no estén exclusivamente centrados en la lógica de negocio.

    Resuelve temas como conectividad con LDAP, Interfaces, Gestión de perfiles, seguridad, etc. Como principal ventaja de uso es la aceleración de la puesta en marcha inicial de las aplicaciones (disminución del tiempo de construcción del primer prototipo).

    Es recomendable su uso para programas sencillos y estándar. Por ejemplo para aplicaciones Intranet de gestión a modo de inventario (Altas, bajas, modificaciones, búsquedas).

    En aplicaciones con mayor lógica de negocio o con destinatario el ciudadano, el uso de Framework dificulta el mantenimiento, ya que introduce código directamente, sin que el programador intervenga. Por tanto hay que dominar bien el framework para no llevarse sorpresas desagradables.

    Otro aspecto a tener en cuenta es que debe estar bien documentado para facilitar la transición entre equipos de desarrolladores.

3.- El nivel de desarrollo SW basado en componentes aparece cuando se está desarrollando una funcionalidad en un aplicativo. Para facilitar su implementación se hace uso de un conjunto de componentes disponibles para ser usados.

Previamente, el área de desarrollo de la organización debe analizar aquellas funciones que se utilizan con más asiduidad para definir los componentes genéricos. Algunos ejemplos pueden ser manejo de fechas, conversión de formatos, etc

Mediante el uso de componentes, en vez de tener que implementar estas funciones, se reutilizan en el código que se está realizando, agilizando los desarrollos. No es otra cosa que aplicar el concepto de ensamblado de componentes de la ingeniería industrial.

Es preciso que exista un directorio documentado con información de los componentes para que realmente se haga uso de ellos.

4.- En el nivel de código, la reutilización aparece cuando en la programación se detecta que un código determinado se repite en distintas partes del programa. Para evitar la duplicidad, se implementa una función que encapsule el código. Si a su vez se detecta que dicha función es válida para poder ser usada en otros proyectos entraríamos en el nivel anterior de los componentes.

Esta práctica es vital para limpieza y futuro mantenimiento de código. De hecho existen herramientas específicas para detectar duplicidades. Un programador no debe ser perezoso y debe modular tanto como sea necesario.

En resumen, se han analizado distintos niveles de abstracción donde se puede aplicar reutilización. Unos de ellos afectan más al responsable del proyecto mientras que otros afectan directamente a las tareas diarias del programador. Gran parte de estos niveles son compatibles entre si, como por ejemplo el uso de Framework, Servicios Externos e internos, desarrollos basados en componentes y código modularizado. Sin duda aplicar convenientemente la reutilización, redunda en incrementar considerablemente la calidad del SW.

2 comentarios:

  1. Una buena descripción de los conceptos básicos relacionados con la reutilización de las aplicaciones. Algo así tomamos como punto de partida hace poco más de un año, cuando empezamos a trabajar en la tramitación del Decreto 159/2012, de 24 de Julio, que regula la Apertura y Reutilización de las Aplicaciones Informáticas de la Administración Pública de la Comunidad Autónoma del País Vasco. Para ello dimos un primer paso que ahora hemos expuesto en el Blog del PIP (http://pip.blog.euskadi.net/?p=3903) y que quizá te pueda interesar para abrir boca antes de irte directamente al citado Decreto o al Borrador del Real Decreto que sobre la misma temática me consta que están preparando en el MinHAP, pues la colaboración con ellos ha sido y es muy estrecha.

    ResponderEliminar
  2. Gracias por comentar Serafín.

    Si la idea del artículo es hablar de la reutilización a distintos niveles. Las referencias que comentas están más basado en los dos primeros niveles del artículo. De hecho en la administración está cada vez más presente todo el tema de la reutilización en primer y segundo nivel lo cual es una buena noticia. Pero no hay que descuidar el tercer y cuarto nivel que son fundamentales para hacer un SW de calidad. Estos niveles afectan más a nivel de programador pero es que la programación es una parte esencial aunque desgraciadamente en este país (no sólo en el ámbito de la Admon Pública) no se le da la importancia que se merece.

    Te felicito por el gran trabajo que estáis haciendo con todo este tema de la reutilización y te agradecería que me fueras informando que tal va implantándose el Decreto y si ya va dando sus primeros frutos.

    ResponderEliminar