Reutilización exitosa de código con desarrollo y modelaje basado en código

El modelaje es un paso esencial en el proceso de analizar el código existente para poder tomar decisiones acerca de qué utilizar. Una vez que se conoce la arquitectura general de un código, crear sus productos en un flujo de trabajo de PLE (ingeniería de línea de producto) se hace mucho más sencillo de hacer y mantener. Es necesario entender cómo se adapta el código, cómo hará mejor uso del mismo en el futuro y qué partes querrá modificar. Las principales razones para analizar el código son la documentación, la reutilización, la modificación o el mantenimiento. Este artículo explica los secretos de una reutilización exitosa y cómo reutilizar código combinando desarrollo basado en código con modelaje.

Joanne L. Scouler, Curriculum Architect, IBM

Author1 photoJoanne Scouler es arquitecta de planes de estudio en IBM, donde realiza planificación empresarial y desarrollo de cursos para software de ingeniería de sistemas. Durante los últimos seis años ella desarrolló y dio cursos de capacitación sobre la herramienta Rational Rhapsody. Su experiencia en capacitación sobre sistemas incorporados y modelaje de software consistió en trabajar con diversos clientes, entre los cuales se encuentran Raytheon, Draper Lab, Pratt & Whitney, Zoll Medical, y Kollmorgren. Antes de IBM, Joanne trabajó en Telelogic, Hewlett-Packard, 3Com Corporation, Symantec, y Addison-Wesley.



Martin R. Bakal, Rational Electronics Industry Offering Manager, IBM

Author1 photoMartin Bakal tiene 15 años de experiencia en el campo del software incorporado, incluyendo su trabajo como ingeniero de la aplicación Rational Rhapsody de IBM, como asesor y como instructor, además de otros varios roles. Es instructor experimentado de UML y SysML, así como también de proceso IBM Rational Harmony y de entorno MDD (model-driven development) IBM Rational Harmony. En el transcurso de su actividad de capacitación y asesoría sobre sistemas incorporados y modelaje de software trabajó con una amplia lista de clientes en todo el mundo, incluyendo Lockheed Martin, General Dynamics, GM, y Philips. Escribió una multiplicidad de artículos técnicos acerca de modelaje, reutilización y líneas de productos, además de diversos otros temas.



13-07-2012

Los proyectos de nuevo desarrollo suelen comenzar con un código fuente existente. Entender el código es esencial para reutilizar, lo cual no es tan simple como parece. Por ejemplo, puede suceder que el desarrollador original se haya mudado o se haya retirado. El código puede haber sido escrito por varios desarrolladores o puede provenir de múltiples fuentes. Es posible que el código exista como código que es propiedad de su empresa, código externo (por ejemplo, código abierto o estándar) o como bibliotecas. Es probable que haya cambiado y evolucionado a lo largo de muchos años. Cualquiera que sea la historia del código, usted necesita saber cómo interactúa el código fuente y qué contiene. Es necesario entender cómo se adapta el código, cómo hará mejor uso del mismo en el futuro y qué partes querrá modificar.

Razones para analizar el código

Las razones principales para analizar el código se pueden resumir en: documentación, reutilización, modificación o mantenimiento. Según la situación, los incentivos son:

  • Documentar el código para entenderlo mejor y para que esté preparado para la próxima vez que el desarrollador se retire o se mude ("documentar" implica la existencia de diagramas que explican el código)
  • Crear una línea de producto con funcionalidad en un producto que tal vez no necesite en otro
  • Revisar o actualizar la aplicación a una versión más reciente
  • Mantener su código existente

Todas estas razones son un buen fundamento para entender mejor su código. Este artículo se concentra en las razones de la reutilización y el análisis del código que es necesario para poder hacer la reutilización.


Riesgos de la reutilización

Hay riesgos potenciales en la reutilización; riesgos específicos de por qué puede fallar la reutilización. Uno de los desafíos en la justificación de la inversión es que algunos gestores no le permiten a un equipo dedicar tiempo a conocer el código antiguo. Otro riesgo potencial que puede causar la falla es la falta de conocimiento de los dominios y de los componentes del código. La parálisis del análisis es otro riesgo potencial.

Procurar entender todo el código puede ser una tarea descomunal - es importante desglosarlo para identificar el código principal a reutilizar. Dedíquese desde el comienzo a evaluar qué componentes del código se deben reutilizar. En algunos casos es posible que sea necesario documentar todo lo que hay en su código – por ejemplo, por razones reglamentarias- sin embargo, tratar de reutilizar y documentar todo el código no suele ser eficaz. La mayoría de las veces la meta es actuar de forma inteligente al decidir qué partes del código documentar y qué partes reutilizar.


Los cuatro secretos del éxito

Para lograr el éxito, los secretos son:

  1. Entender la arquitectura del código original para identificar los componentes, los límites y las interfaces
  2. Determinar qué es potencialmente reutilizable
  3. Estimar el tiempo de reutilización versus la reconstrucción de los componentes
  4. Tomar una decisión por cada componente acerca de qué reutilizar y cómo reutilizar -sin cambio, actualización menor, actualización general

Clarificar el código de software dentro del Unified Modeling Language

Cuando sea que quiera lograr entender claramente su código, el lenguaje Unified Modeling language (UML) es una excelente forma de hacerlo. UML es un lenguaje gráfico estándar de representación de código. Permite ilustrar qué está haciendo realmente el código, lo cual a su vez brinda la posibilidad de ver un plano general del diseño de los componentes. Brinda la posibilidad de entender la arquitectura del código original para identificar los componentes, los límites y las interfaces. UML clarifica cómo se funciona el código. El UML se usa para analizar el código. El primer paso antes de documentar el código existente es analizar.

Combinar desarrollo basado en código con modelaje UML

Uno de los cuatro secretos del éxito mencionados al comienzo de este artículo es tomar una decisión por cada componente acerca de qué reutilizar y cómo reutilizarlo. Si desea mantener su código existente y documentarlo, puede continuar con el desarrollo basado en código de la misma forma en que siempre lo hace, pero combinándolo con modelaje. Tal vez no necesite generar código en el modelo pero sí querrá comunicarse mejor y aprender cómo funciona el código existente. Esto se puede hacer combinando el desarrollo basado en código con el modelaje.

Si desea entender el código de software existente para poder reutilizarlo para crear nuevos productos o mantener múltiples productos existentes, el desarrollo orientado a modelos puede ser la mejor solución. Al realizar desarrollo basado en código en combinación con desarrollo orientado a modelos, se puede identificar qué parte del código querrá mantener y qué parte reutilizar.

Definiciones de terminología

Basado en modelos
El modelo no sólo orienta la arquitectura sino también su código de aplicación final.
 
Basado en código
El código se importa a un modelo como referencia para la visualización. Esto significa que el modelo se utiliza para ayudar a mostrar la arquitectura pero ello nunca cambia el código. Para actualizar el diseño se necesita actualizar el código y luego traerlo de vuelta al modelo.
 
Dynamic Model Code Associativity (DMCA)
En el software de modelaje IBM® Rational® Rhapsody® esto se refiere a la dirección de las actualizaciones. Se puede ir de modelo a código, de código a modelo y se pueden hacer actualizaciones automáticas bidireccionales. Round-tripping es el proceso de traer actualizaciones del código al modelo.
 

Distintos tipos de usuarios prefieren ciertos escenarios de desarrollo a otros. Los usuarios que trabajan en modelos son llamados "usuarios basados en modelos" mientras que los usuarios basados en código prefieren hacer todo en el código. El resto están entre unos y otros. Usted puede acomodar los variados tipos de usuarios con el tipo de reutilización de código y modelaje que elija. Los distintos tipos de usuarios pueden colaborar y trabajar en conjunto coherentemente con una combinación de codificación tradicional y desarrollo orientado a modelo.

Las definiciones de tecnología pueden ser correlacionadas en los tres escenarios diferentes descriptos en la sección siguiente.

Nota:
Éstos se pueden utilizar por componente, es decir, un componente de una aplicación puede estar basado en modelo mientras que otro puede estar basado en código.

Escenarios para combinar desarrollo basado en código y orientado a modelo

Hay varias formas de combinar reutilización de código tradicional con modelaje. El espectro de opciones se puede describir, a un nivel superior, en uno de estos cuatro escenarios:

  • La visualización de código externo (sólo visualización) es un proceso basado en código. El código externo permanece externo a su herramienta visual de modelaje. Usted puede referenciar el código externo en la herramienta de modelaje para utilizarla y probarla.
  • Codificación continua con documentación actualizada es un proceso basado en código con soporte para enviar actualizaciones al modelo. Se puede visualizar el código en un modelo pero nunca se puede cambiar el modelo.
  • Desarrollo basado en código con algunos cambios realizados en el modelo que son generados para el código. El código es el maestro.
  • Modernizar código utilizando desarrollo orientado a modelo, donde el modelo es el maestro. Una porción del código externo es identificada para reutilizar y es traída directamente al modelo.

Visualización de código externo

Visualización implica tener diagramas que ayudan a entender el diseño, la estructura del código y las relaciones entre los objetos (como las clases y los archivos). Como usuario, usted también puede tener la capacidad de crear nuevos diagramas basados en los elementos del modelo, agregar comentarios en los diagramas y conectar elementos de modelos a los requisitos. Una descripción de los elementos que llegaron desde el código se mantiene en el modelo y se puede generar a informe haciendo un informe del modelo. Hay cambios que se pueden hacer más fácilmente en un modelo, como por ejemplo, agregar elementos que se pueden incluir en un diagrama, copiar elementos en un diagrama, herencia y más.

Con visualización de código, las actualizaciones al código se pueden hacer en el código fuera de la herramienta de modelaje. La visualización del código externo se hace para mostrar las relaciones que tiene el código con un modelo. Por ejemplo, es posible que quiera referenciar una biblioteca externa C y mostrar la referencia en un diagrama. La relación que tiene la biblioteca en otras partes del modelo se visualiza y se documenta de esta manera. Las pruebas orientadas a modelos de la biblioteca se pueden hacer dentro del modelo. Con el desarrollo orientado a modelo no sólo se puede visualizar el código sino que también se puede ejecutar el modelo para verificarlo y probarlo.

Codificación continua con documentación actualizada

En el segundo escenario, cuando se hacen cambios en el código externo, se puede hacer round-tripping para enviar los cambios del código al modelo. Esto trae el código cambiado desde el código externo, actualizando de esta manera la documentación. Si elige la opción de visualizar y actualizar el código, usted puede continuar desarrollando el código en el modelo o en el código externo y mantener ambos sincronizados.

Desarrollo basado en código

Como mencionamos antes en el escenario 3, usted puede modernizar el código usando el desarrollo orientado a modelo generando código en Rational Rhapsody y actualizando el código externo con los cambios. La generación de código se puede realizar en la herramienta de modelaje preservando las directivas del código en los archivos fuente originales. La opción de ejecutar la generación de código es útil para traer los cambios del modelo de vuelta al código. La animación de modelo se puede usar para mostrar el comportamiento del código. En este escenario, el código es el maestro.

Modernizar código utilizando desarrollo orientado a modelo

Usted puede optar por mantener el código en el modelo. Esto es la base del escenario 4. El criterio fundamental a utilizar para determinar si desea visualizar código como se hace en el escenario 1-3 ó mantenerlo directamente en el modelo para hacer desarrollo orientado a modelo, reside en decidir si desea generar código estrictamente en el modelo, o no. Si mantiene el código en el modelo, hacer cambios adicionales de diseño y mejoras se hacen más eficientemente. El modelo es el maestro.

Rational Rhapsody ahora muestra un ejemplo simple de cómo UML permite reutilizar el código existente. Este es ejemplo de un usuario que crea una nueva caja registradora con base en hardware existente. El primer diagrama se llama diagrama Package. Provee una vista de alto nivel de los paquetes del sistema. Los paquetes son CashRegister, el paquete de hardware, y un enlace entre ellos a través del paquete Interfaces. El paquete Interface permite una sencilla reutilización del hardware, además de la capacidad de cambiar hardware existente por hardware nuevo, según sea necesario.

Figura 1. Diagrama Package
Diagrama Package

El siguiente diagrama de clase muestra cómo la Caja Registradora hereda desde la interfaz IBarcodeReader. Esto permite que la clase CashRegister implemente la interfaz y reciba comunicación desde la clase BarcodeReader, la cual vino desde el paquete de hardware externo. La clase BarcodeReader no se necesita mostrar en el diagrama, a pesar de que la interfaz Barcode Reader se muestre (Figura 2), porque CashRegister necesita implementar únicamente la interfaz para obtener el comportamiento deseado.

Figura 2. Diagrama de clase
Diagrama de clase

El diagrama de clase de la Figura 3 muestra cómo la clase Tester hace una inclusión de un archivo de origen C desde una fuente externa. La fuente externa se visualiza para mostrar las operaciones y variables desde el archivo point_of_sale para que la clase Tester puede determinar qué puede llamar.

Figura 3. Clase Tester incluyendo un archivo de origen C de una fuente externa
Clase Tester incluyendo un archivo de origen C de una fuente externa

En la Figura 4, un diagrama de secuencia animada muestra una clase CashRegister escaneando códigos de barra en los productos y agregando los productos en la factura del cliente.

Figura 4. Diagrama de secuencia animada
Diagrama de secuencia animada

La animación permite ejecutar una aplicación, ya fuere en un huésped o en un objetivo, y luego visualizar los resultados en el diseño con Rational Rhapsody. Ésta es una herramienta de importancia para visualizar comportamiento de código y depurar código, lo cual es importante para reutilizar código. Visualizar código estático muestra sólo las rutas potenciales al mismo. Un diagrama de secuencia como el de la Figura 4 muestra cómo la ruta hacia la aplicación responde realmente al estímulo externo. Por consiguiente, usted puede ver qué ruta se ejecuta en el ciclo de vida real de una aplicación. Por lo tanto, animar un modelo es una forma de probar y verificar el comportamiento de su código reutilizable.


Reutilización e ingeniería de línea de producto, o PLE

El Santo Grial de la reutilización es algo llamado PLE (ingeniería de línea de producto). Es la práctica de identificar recursos en su aplicación que variarán según el producto, y de hacer la correlación de esos recursos con las variaciones específicas de cada producto de modo que, finalmente, usted tenga un conjunto de códigos que soporte múltiples productos. Esto es un Santo Grial porque la meta principal de la reutilización es reutilizar en el próximo producto que salga. Esto también es el objetivo de PLE.

Las otras opciones para crear múltiples productos son clonar y reconocer o utilizar ifdefs.

  • Clonar y reconocer crea un conjunto de cuestiones tales como cuando uno encuentra un error en un producto y se pregunta ¿existe también en otros productos? ¿Qué sucede cuando uno quiere propagar un recurso por los productos? Esto puede volverse una pesadilla cuando se busca cambios en los clones.
  • Ifdefs hacen que el código sea ilegible y muy difícil de navegar cuando se intenta trabajar en un producto específico.

El modelaje ayuda a resolver este dilema al agregar un nivel de abstracción por encima del código. Se puede identificar un elemento de modelo específico (una clase, una función o cualquier otra cosa) que correlaciona con un recurso y luego agregar etiquetas para las diferencias específicas de producto. Como es gráfico, las etiquetas pueden ser enlaces que se pueden investigar como sea necesario. Además, cuando usted genera el código desde el modelo, éste utiliza sólo las etiquetas para el producto específico, por lo tanto usted obtiene código personalizado para cada producto. Luego, usted realiza los cambios en el modelo, y cada producto que tiene ese recurso recibe esos cambios. No hay necesidad de propagar los cambios de producto en producto.


Resumen

En resumen, dado que los plazos son cortos, la reutilización es esencial para cumplir con las fechas de entrega. El secreto es cómo crear reutilización efectiva en lo que usted hace. Primero, asegúrese de entender su arquitectura y luego profundice en los componentes que desea reutilizar. El modelaje es valioso en este proceso porque ayuda a analizar el código y a tomar decisiones acerca de qué se reutiliza. Una vez que se conoce la arquitectura general, crear sus productos en un flujo de trabajo de PLE se hace mucho más sencillo de hacer y mantener.

Recursos

Aprender

Obtener los productos y tecnologías

  • Descargue Rational Rhapsody Developer y pruébelo gratis por 30 días.
  • Evalúe software IBM de la manera que le convenga: Descárguelo para probarlo, pruébelo online, utilícelo en un entorno de nube, o pase un par de horas en el SOA Sandbox aprendiendo cómo implementar eficientemente la arquitectura orientada al servicio.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Rational
ArticleID=825101
ArticleTitle=Reutilización exitosa de código con desarrollo y modelaje basado en código
publish-date=07132012