Artículos | Informáticas | Programaci�n

El embedded C se ha vuelto uno de los lenguajes de programación más utilizados en la industria electrónica dado el auge de los sistemas embebidos en los modernos dispositivos tecnológicos.

No obstante, bajo el criterio de la mayoría de los ingenieros programadores esta plataforma no se exonera de la rigurosa y ardua tarea de depuración, pues también es vulnerable a los ‘bugs’ y cuellos de botella.

La fase de depuración consume gran tiempo en el desarrollo de un proyecto y representa para el ingeniero un complicado ciclo de inversión de recursos, pero todo a favor de elevar la calidad del funcionamiento de los sistemas y eliminar todos los posibles bugs que pudieran ocasionar fallas una vez terminado el trabajo.

A la fecha expertos programadores han desarrollado sus propios modelos personalizados de trabajo con embedded C, y como resultado han logrado descubrir nuevos métodos que simplifican la etapa de depuración en este lenguaje de programación.

Uno de estos especialistas es James W. Grenning, fundador de la compañía Renaissance Software Consulting, quien escribió un artículo técnico titulado "Test-Driven Development for Embedded C: Why Debug?" en el cual Grenning comparte sugerencias interesantes para llevar a cabo la depuración del código en embedded C de una manera simple, además, la importancia de evitar contrariedades en las líneas creadas.

A manera de retórica el especialista cuestiona el por qué del surgimiento de los bugs y responde que simplemente son puestos involuntariamente por la naturaleza de la informática y también por la inexperiencia de los programadores.

En este sentido expone lo siguiente:

- "En el TDD (Test-Driven Development) o Desarrollo Dirigido a Pruebas, tú desarrollas pruebas y produces código concurrentemente en una curva de retroalimentación limitada."

- "El TDD debería ayudarte para prevenir vergonzosos bugs del tipo Zune."
- "Los cuellos de botella en hardware se presentan en varias formas, y se puede usar el TDD para evitar dichos cuellos de botella durante la retroalimentación del TDD."

- "El TDD te ayuda asegurar que el código realice las funciones que planeaste. ¿Cómo puedes construir un sistema confiable si el propio sistema no lo es?"

- "Un TDD encuentra pequeños y hasta grandes errores lógicos, previniendo y ultimando hasta los más imperceptibles bugs." "Tú escribes código y entonces haces hasta lo imposible por que esto funcione. Los creas y entonces lo arreglas. La fase de pruebas es en lo último en que piensas –algo que haces ya cuando terminas de escribir el código-.", menciona Grenning de manera textual en su artículo. "Inviertes aproximadamente la mitad de tiempo en actividades impredecibles de depuración en forma de pruebas e integración.", agrega el experto, al tiempo que refiere que tal etapa es incierta para el programador, pues no sabe si al resolver un bug inmediatamente aparezca otro y otro, o bien una cascada de bugs.

El también profesor y capacitador de herramientas tecnológicas para el diseño electrónico, reconoció que el aparecimiento de bugs en la fase de depuración es de lo más normal, incluso para quienes poseen una gran trayectoria en la rama.

"Cuando se realizan las pruebas, encontrarás defectos. Tú cometes errores cuando desarrollas; la función de las pruebas es precisamente hallar tales errores. Si estás muy bien preparado en tareas de análisis, encontrarás bugs.", apuntó Grenning.

Grenning señala que un procedimiento habitual es la depuración posterior a la generación del código, no obstante esto conlleva a elevar el riesgo de problemas o fallas.

De acuerdo a la siguiente ilustración, cuando se incrementa el tiempo de búsqueda de bugs (Td) también se eleva el tiempo para encontrar la causa o raíz (Tfind) de una forma dramática y esto puede originar otros errores simultáneos.

Si se encuentran defectos fuera de la etapa de desarrollo, entonces se deben administrar. El documento refiere que en el caso de algunos bugs, su tiempo de identificación no afecta el tiempo de resolución (Tfix), pero en el caso de otros dependerá en demasía del tipo de error, en el peor de los casos, al tratar de eliminar un bug se producirá un efecto dominó y aparecerán más y más, lo cual se traducirá en más tiempo y complejidad para el ingeniero.

Una de las propuestas lanzadas por Grenning es ejecutar TDD en microciclos, donde se escriba una prueba y no esté compilado, se haga aparte la compilación, se resuelva el desorden del código y se repita el proceso hasta que se haya terminado.

"La escritura de código y su análisis, son procesos que están integrados. Si cometes un error y una nueva prueba no pasa, inmediatamente sabrás cómo solucionar el bug.", indica el experto. "Conectas una prueba automatizada a la unidad de pruebas y vuelves a correr las pruebas libremente".

Grenning sostiene que a diferencia de la depuración manual al término de la generación del código o por su expresión inglesa "Debug-Later Programming", el TDD no incluye tantos riesgos relativos a la búsqueda y resolución de errores.

Bajo el criterio del especialista, cuando se genera un error la identificación es obvia, y si este proceso indica un período de cero en factor tiempo para encontrar un error, será el mismo valor para hallar la causa o raíz de dicho bug.

El método por TDD permite una pronta identificación, pues el sistema arroja notificaciones inmediatas al ingeniero en turno para que éste los elimine al momento y no al terminar el código.

Publicado originalmente en Electronicos ()