3.3 CONSTRUCCIN DEL SISTEMA.

La construccin del sistema es un proceso de crear un sistema ejecutable y

completo al compilar y vincular los componentes del sistema, libreras externas,
archivos de configuracin, etctera.
Las herramientas de este y las de gestin diversiones deben comunicarse, puesto
que el proceso de construccin implica extraer versiones del componente del
repositorio administrado por el sistema de gestin de versiones. La descripcin de
configuracin que se usa para identificar una lnea base utiliza tambin la
herramienta de construccin del sistema.

La construccin es un proceso complejo, donde suelen ocurrir errores, ya que hay

tres diferentes plataformas de sistema que pueden estar implicadas:

1. Sistema de desarrollo: incluye herramientas de desarrollo, como los

compiladores, editores de cdigo fuente, etctera. Los desarrolladores sacan
cdigo del sistema de gestin de versiones hacia un espacio de trabajo
privado mucho antes de hacer cambios al sistema. Tal vez quieran construir
una versin del sistema para probarla en su entorno de desarrollo antes de
aplicar los cambios que hicieron ante el sistema de gestin de versiones.
Esto supone usar herramientas de construccin locales que usan versiones
de componentes sacadas en el espacio de trabajo privado.
2. Servidor de construccin: usado para construir versiones ejecutables
definitivas del sistema. ste interacta estrechamente con el sistema de
gestin de versiones. Los desarrolladores ingresan cdigo a este sistema
antes de que se construya. La elaboracin del sistema puede depender de
libreras externas que no se incluyen en el sistema de gestin de versiones.
3. Entorno objetivo: plataforma donde se ejecuta el sistema. ste puede ser
el mismo tipo de computadora que se us para los sistemas de desarrollo y
construccin. Sin embargo, para sistemas embebidos y de tiempo real, el
entorno objetivo con frecuencia es ms pequeo y sencillo que el entorno de
desarrollo. Para sistemas grandes, el entorno objetivo puede incluir bases de
datos y otros sistemas COTS que no pueden instalarse en mquinas
 desarrollo. En ambos casos, no es posible construir y probar el sistema en la
computadora de desarrollo o en el servidor de construccin.

Para sistemas embebidos puede instalarse un entorno de simulacin en el entorno

de desarrollo para pruebas, en vez de usar la plataforma de sistema embebido real.
Dichos simuladores pueden ofrecer mejor soporte de depuracin que el disponible
en un sistema embebido. Sin embargo, es muy difcil simular el comportamiento de
un sistema embebido en todos los aspectos. Por lo tanto, las pruebas del sistema
se deben realizar en la plataforma real donde se ejecutar el sistema, as como en
el simulador del sistema.

La construccin del sistema implica ensamblar una gran cantidad de informacin

acerca del software y su entorno operacional. Entonces, para cualquier sistema
aparte de los pequeos, siempre tiene sentido usar una herramienta de construccin
automatizada para crear una construccin del sistema.

Puede observar que no slo necesita los archivos del codigo fuente implicado
en la construccin, sino tal vez se deban vincular dichos archivos, archivos
de datos (como un archivo de mensajes de error) y archivos de configuracin
proporcionados externamente que definan la instalacin objetivo.

Existe una gran cantidad de herramientas de construccin disponibles, y un sistema

de construccin ofrece algunas caractersticas o todas ellas:

1. Generacin de rutinas (scripts) de construccin: Si es necesario, el

sistema de construccin debe analizar el programa en construccin,
identificar los componentes dependientes y generar automticamente una
rutina de construccin (llamado algunas veces archivo de configuracin).
2. Integracin del sistema de gestin de versiones: El sistema de
construccin debe sacar las versiones de componentes requeridas del
sistema de gestin de versiones.
3. Recopilacin mnima: El sistema de construccin debe establecer qu
cdigo fuente necesita volver a compilarse y establecer las compilaciones si
as se requiere.
4. Creacin de sistema ejecutable: El sistema de construccin debe vincular
los archivos de cdigo de objeto compilado entre s y con otros archivos
 requeridos, como las libreras y los archivos de configuracin, para crear un
sistema ejecutable.
5. Automatizacin de pruebas: Algunos sistemas de construccin pueden
efectuar pruebas automatizadas utilizando herramientas de automatizacin
de pruebas como JUnit. stas comprueban que la construccin no se haya
roto por los cambios.
6. Informes: El sistema de construccin debe ofrecer informes sobre el xito o
fracaso de la construccin y las pruebas que se efectuaron.
7. Generacin de documentacin: El sistema de construccin puede generar
notas referentes a las pginas de ayuda de la construccin y del sistema.

La rutina de construccin incluye la especificacin de la configuracin, de manera

que el lenguaje de escritura de rutinas utilizado generalmente es el mismo que el
lenguaje de descripcin de la configuracin. El lenguaje de configuracin incluye
sentencias para describir los componentes del sistema a incluir en la construccin
y sus dependencias.
Puesto que la compilacin es un proceso de cmputo intensivo, las herramientas
para soportar la construccin de sistemas se disean por lo general para minimizar
la cantidad de compilacin que se requiere. Esto se hace comprobando si est
disponible una versin compilada de un componente. De ser as, no hay necesidad
de volver a compilar dicho componente.
La forma en que se hace esto es asociar una firma nica con cada archivo donde
se almacene un componente del cdigo fuente. El cdigo objeto correspondiente,
que se compil a partir del cdigo fuente, tiene una firma relacionada que identifica
cada versin del cdigo fuente y cambia cuando ste se edita. Al comparar las
firmas en los archivos de cdigo fuente y objeto, es posible decidir si el componente
del cdigo fuente se us para generar el componente de cdigo objeto.

Hay dos tipos de firmas que pueden usarse:

1. Modificacin de marca de tiempo (timestamp0:) La firma en el archivo del
cdigo fuente es la fecha y hora de cundo ste se modific. Si el archivo del
cdigo fuente de un componente se modifica despus del archivo del cdigo
objeto relacionado, entonces el sistema supone que se requiere
recopilacin para crear un nuevo archivo del cdigo objeto.
2. Sumas de verificacin (checksums) de cdigo fuente: La firma en el
archivo del cdigo fuente es una suma de verificacin calculada a partir de
datos en el archivo. Una funcin checksum calcula un nmero nico usando
el texto fuente como entrada. Si se modifica el cdigo fuente (incluso por un
carcter), esto generar una suma diferente. La suma de verificacin se
asigna al cdigo fuente justo antes de la compilacin e identifica de manera
exclusiva el archivo fuente. Entonces el sistema de construccin etiqueta el
archivo de cdigo objeto generado con la firma checksum. Si no hay archivo
de cdigo objeto con la misma firma que el archivo de cdigo fuente a incluir
en un sistema, entonces es necesario recompilar el cdigo fuente.

El enfoque checksum tiene la ventaja de permitir muchas versiones diferentes del

cdigo objeto de un componente para mantenerse al mismo tiempo. La firma es el
vnculo entre el cdigo fuente y objeto. Los archivos de cdigo fuente y de cdigo
objeto tienen la misma firma. Por lo tanto, cuando se recompila un componente, no
sobrescribe el cdigo objeto, como sera normalmente el caso cuando se usa
timestamp. En vez de ello, genera un nuevo archivo de cdigo objeto y lo etiqueta
con la firma del cdigo fuente.

Los mtodos giles recomiendan que los componentes de sistema muy frecuentes
deben realizarse con pruebas automatizadas (pruebas de humo) para descubrir
problemas del software. Los componentes frecuentes pueden ser parte de un
proceso de integracin continua:

Pasos de la integracin continua:

1. Sacar la lnea principal del sistema de gestin de versiones hacia el espacio

de trabajo privado del desarrollador.
2. Construir el sistema y efecte pruebas automatizadas para garantizar que el
sistema construido pasa todas las pruebas. Si no lo hace, la construccin se
descompone y hay que informar a quienquiera que ingrese al ltimo sistema
lnea base (baseline). Ellos son responsables de reparar el problema.
3. Realizar los cambios a los componentes del sistema.
4. Construir el sistema en el espacio de trabajo privado y vuelva a efectuar las
pruebas del sistema. Si las pruebas fallan, contine la edicin.
5. Una vez que el sistema pasa sus pruebas, ingresar en el sistema de
construccin, pero no confirme como una lnea base nueva del sistema.
6. Construir el sistema en el servidor de construccin y efecte las pruebas.
Necesita hacer esto en caso de que otros hayan modificado componentes
luego de que usted los sac del sistema. Si ste es el caso, saque el
componente que fall y edtelo de modo que las pruebas pasen en su espacio
de trabajo privado.
 7. Si el sistema pasa sus pruebas en el sistema de construccin, confirmar
entonces los cambios que hizo como una nueva lnea base en la lnea
principal del sistema.

El sistema ms reciente en la lnea principal es el sistema funcional definitivo. Sin

embargo, aunque la integracin continua es una buena idea, no siempre es posible
implementar este enfoque a la construccin del sistema.

Las razones para esto son:

1. Si el sistema es muy grande, puede tardar mucho tiempo construir y probar.

Por lo tanto, no es prctico construir muchas veces al da dicho sistema.
2. Si la plataforma de desarrollo es diferente de la plataforma objetivo, tal vez
no sea posible efectuar pruebas del sistema en el espacio de trabajo privado.
Puede haber diferencias en el hardware, el sistema operativo o el software
instalado. Por consiguiente, se requiere ms tiempo para probar el sistema.

Para sistemas grandes o sistemas donde la plataforma de ejecucin no es la misma

que la plataforma de desarrollo, la integracin continua quiz no sea prctica. Ante
tales circunstancias se puede usar un sistema que se construya diariamente.

Caractersticas de esto:
1. La organizacin de desarrollo establece un tiempo de entrega (por ejemplo,
2 P.M.) para los componentes del sistema. Si los desarrolladores tienen
nuevas versiones de los componentes que escriben, deben entregarlas en
ese plazo. Los componentes pueden estar incompletos, pero deben ofrecer
alguna funcionalidad bsica que pueda ponerse a prueba.
2. A partir de dichos componentes se crea una nueva versin del sistema al
compilarlos y vincularlos para formar un sistema completo.
3. Entonces este sistema se entrega al equipo de pruebas, que realiza un
conjunto de pruebas de sistema predefinidas. Al mismo tiempo, los
desarrolladores todava trabajan en sus componentes, aaden funcionalidad
y reparan las fallas descubiertas en pruebas anteriores.
4. Las fallas que se descubren durante las pruebas del sistema se documentan
y regresan a los desarrolladores del sistema, quienes reparan dichas fallas
en una versin posterior del componente.

Las ventajas de usar componentes frecuentes de software son que aumentan las
posibilidades de descubrir de manera oportuna durante el proceso los problemas
que surgen a partir de las interacciones de los componentes.

Libro: ingeniera de software 9 edicion. Ian Sommerville

Libro: Ingernieria de software Sexta edicin. Roger. Pressman