PDF de programación - ESPECIFICACIÓN DE MÓDULOS CON EJEMPLOS Y CASOS DE PRUEBA

ESPECIFICACIÓN DE MÓDULOS CON EJEMPLOS Y CASOS DE

PRUEBA

MODULE SPECIFICATION USING EXAMPLES AND TEST CASES

Adolfo Di Mare

Universidad de Costa Rica, Escuela de Ciencias de la Computación e Informática, Costa Rica

[email protected]

RESUMEN

Se plantea cómo aprovechar la formación del
programador para que construya, por lo menos
parcialmente, la especificación de sus módulos,
incorporando en cada implementación datos de
prueba que sean ejemplos de uso de cada rutina,
con el fin de mejorar la reutilización de los módulos.



Palabras Clave: especificación, prueba unitaria de
programas, ingeniería de sistemas, construcción de
programas, implementación de programas.



ABSTRACT

It is explained how to take advantage of each
programmer’s education to have them construct, at
least in part, module specifications, incorporating in
each implementation test data that serve as usage
examples for each routine, in order to improve
module reuse.



KeyWords: specification, unit
engineering,
implementation.


program

testing, software
program

construction,

1. INTRODUCCIÓN

lograr

Especificar módulos para
reutilizarlos
debiera ser el quehacer diario de todo programador
[McConnell-2004]. A menos que el programa sea
construido para ser ejecutado solo una vez, cada
programador enfrenta la necesidad de dejar traza
de su trabajo para que otros puedan modificar y
[Myers-2004].
mejorar
Desafortunadamente,
que
desarrollan los programadores no calzan con el
trabajo de documentación que deben realizar para
convertir cada módulo en un componente
reutilizable. ¿Qué se puede hacer para remediar
este problema? Una solución es contratar otras
personas quienes se encarguen de escribir la

habilidades

creó

las

lo

que

[VH-2005] o Javadoc

documentación, anotando el código fuente con
comentarios para que luego una herramienta como
Doxygen
[Javadoc-2010]
extraiga la firma, encabezado o prototipo de cada
módulo y lo use para generar las páginas de
documentación. Esta solución aumenta el costo de
la construcción de los programas pues recurre a
incrementar el rubro más caro en el desarrollo de
sistemas: la planilla del equipo de programación. Es
fácil argumentar que no hay otra solución, pues ya
es difícil y caro entrenar programadores, por lo que
obligar a que cada programador también tenga la
capacidad de escribir especificaciones disminuiría la
cantidad de programadores disponibles pues
muchos no podrían adquirir las habilidades que les
permitan redactar especificaciones,
lo que en
la cantidad
consecuencia haría más escasa
disponible de programadores con el consecuente
aumento de costo.

idea principal es aprovechar

La solución que en este trabajo se plantea es
diferente. La
la
formación del programador para que construya, por
lo menos parcialmente, la especificación de sus
módulos, incorporando en cada implementación
datos de prueba que sean ejemplos de uso de cada
rutina, con el fin de mejorar la reutilización de los
módulos.



2. REUTILIZACIÓN

Reutilizar significa no inventar de nuevo la rueda,
aprovechando lo que otros hicieron para construir
nuevas soluciones. No es un concepto nuevo, pues
desde hace décadas se sabe cómo reutilizar
componentes de programación [Kru-1992]:

1) Para que una técnica de reutilización sea
efectiva debe reducir la distancia cognoscitiva
entre el concepto inicial de un sistema y su
implementación ejecutable final.

Di Mare | “Especificación de Módulos con Ejemplos y Casos de Prueba”



2) Para que una técnica de reutilización sea
efectiva debe ser más
los
artefactos que desarrollarlos de nuevo desde el
principio.

fácil reutilizar

3) Para seleccionar un artefacto a ser reutilizado,

es necesario saber qué es lo que hace.

4) Para reutilizar un artefacto de programación
efectivamente es necesario encontrarlo más
de
rápidamente
tardaría
reconstruyéndolo.

que

lo

se

los diccionarios map<> de

La red Internet facilita mucho encontrar módulos
en las bibliotecas. Por ejemplo, para saber cómo se
usan
la biblioteca
estándar STL de C++ [Musser-2001], cualquiera de
estas búsquedas produce
la documentación
requerida rápidamente:



{ 1 } template< class T>

void list<T>::insert(
list<T>::iterator p,
const value_type & v
)

• http://search.yahoo.com/search?n=100&p=c%2B%2B+map
• http://www.google.com/search?num=100&q=c%2B%2B+map


la documentación

Esta forma de acceso también se obtiene si se
usa una biblioteca que no es de uso público, pues
ya existen motores de búsqueda local que permiten
encontrar
relevante a un
problema específico en un gran repositorio (esta
tecnología también tiene rato de haber sido puesta
en práctica:
[MBK-1991]). Estos motores de
búsqueda e indexación ya están disponibles: lo que
falta en muchos casos es la especificación de
módulos, pues esta
los
proyectos para recortar costos.

labor se elimina de



{ 2 } Agrega una copia del valor "v" al contenedor.
{ 3 } • El valor agregado queda antes de la posición "p" en el contenedor.

• Si p==this->end() el valor queda al final de la lista.
Precondición: <<< no tiene >>>
Complejidad: O ( this->size() )

{ 4 } {{ // test::insert()

list<long> L = makeList_long( "(3)" );

L.push_front( 2 ); assertTrue( L == makeList_long( "(2 3)" ) );
L.push_front( 1 ); assertTrue( L == makeList_long( "(1 2 3)" ) );
L.push_back( 4 ); assertTrue( L == makeList_long( "(1 2 3 4)" ) );
L.push_back( 5 ); assertTrue( L == makeList_long( "(1 2 3 4 5)" ) );

L.insert( L.begin() , 0 );
L.insert( L.end() , 6 );
assertTrue( L == makeList_long( "(0 1 2 3 4 5 6)" ) );

typename list<long>::iterator it = L.begin();
while ( it != L.end() && (*it != 4) ) { ++it; }
L.insert(it,4);
assertTrue( L == makeList_long( "(0 1 2 3 4 4 5 6)" ) );
}}



Figura 1: list<T>::insert()



Di Mare | “Especificación de Módulos con Ejemplos y Casos de Prueba”



3. ESPECIFICACIÓN

Dice un conocido adagio que quien no sabe
adónde va llega a otro lado. También es bien sabido
que es necesario apuntar antes de disparar. ¿Cómo
se puede construir programas sin especificarlos
primero? Sin
la especificación, no es posible
asegurar que se ha obtenido lo que se necesita. En
la práctica se recurre al método de prueba y error
para determinar si la funcionalidad de una pieza de
programación es adecuada. Aunque esta estrategia
pospone la etapa de documentación de los módulos
construidos, muchas veces no sirve para lograr
producir sus especificaciones correctas y completas
porque al
recorta el
presupuesto para documentar el código [Boehm-
1981].

final del proyecto se

La especificación puede verse como un contrato
en el que están definidos todos los servicios que la
implementación del módulo es capaz de dar. La
firma o prototipo del módulo siempre forma parte de
la especificación, pues si no se definen los tipos y
parámetros con que trabaja el módulo es imposible
compilarlo o reutilizarlo. Algunos autores consideran
que una especificación correcta debe estar escrita
en un lenguaje formal, matemático. Pero otros sólo
requieren de la especificación un alto rigor, con
estas tres cualidades:
• Completa: debe decirse todo lo que hay que

decir.

• Correcta: debe omitirse lo que no hay que decir.
• No ambigua

En pocas palabras, en la especificación no debe
sobrar ni faltar nada. Debe estar toda la información
esencial para implementar un módulo, y también
para usarlo. Además, es conveniente que
la
especificación sea clara y sencilla de entender, de
forma que para usarla el programador no requiera
hacer un esfuerzo intelectual más grande de lo
necesario [DiM-1999].

En la Figura 1 está una especificación bastante
completa
que
generalmente forman parte de un buen sistema de
documentación:

{ 1 } Encabezado, firma o prototipo.
{ 2 } Descripción corta de la funcionalidad.
{ 3 } Descripción detallada.
{ 4 } Ejemplo de uso.

porque

partes

incluye

las

{ 1 } El encabezado, firma o prototipo de un
módulo contiene la información que necesita el
compilador para traducir el programa. Incluye: (1) el
tipo del valor retornado, (2) el tipo de los parámetros
y (3) el nombre calificado del módulo. En el ejemplo
de la Figura 1 el nombre calificado de la rutina es
list<T>::insert() por lo que el compilador
deduce que insert() es un método de la clase
parametrizada list<T>. Como el valor retornado
por insert() es void el compilador reconoce que
este método no retorna ningún valor, que recibe una
copia del objeto list::iterator<T> pero que,
aunque recibe por referencia el parámetro "v", no
puede modificarlo porque "v" es un parámetro
const. El nombre calificado del tipo "value_type"
es list<T>::value_type pues el lenguaje C++
permite usar abreviaciones en muchos contextos.

{ 2 } La descripción corta de la funcionalidad del
módulo generalmente cabe en un solo renglón y
dice qué hace el módulo (es un error decir cómo lo
hace, pues eso es parte de la implementación).
Usualmente con esta descripción se define o refleja
la abstracción o esencia del componente de
programación, pero debido a que es una
descripción concisa usualmente no es suficientes
para reutilizarlo. En el ejemplo de la Figura