3.3 CONSTRUCCIÓN DEL SISTEMA. La construcción del sistema es un proceso de crear un sistema ejecutable y completo al compilar y vincular los componentes del sistema, librerías externas, archivos de configuración, etcétera. Las herramientas de este y las de gestión diversiones deben comunicarse, puesto que el proceso de construcción implica extraer versiones del componente del repositorio administrado por el sistema de gestión de versiones. La descripción de configuración que se usa para identificar una línea base utiliza también la herramienta de construcción del sistema. La construcción es un proceso complejo, donde suelen ocurrir errores, ya que hay tres diferentes plataformas de sistema que pueden estar implicadas:
Sistema de desarrollo: incluye herramientas de desarrollo, como los compiladores, editores de código fuente, etcétera. Los desarrolladores sacan código del sistema de gestión de versiones hacia un espacio de trabajo privado mucho antes de hacer cambios al sistema. Tal vez quieran construir una versión del sistema para probarla en su entorno de desarrollo antes de aplicar los cambios que hicieron ante el sistema de gestión de versiones. Esto supone usar herramientas de construcción locales que usan versiones de componentes sacadas en el espacio de trabajo privado . 2. Servidor de construcción: usado para construir versiones ejecutables definitivas del sistema. Éste interactúa estrechamente con el sistema de gestión de versiones. Los desarrolladores ingresan código a este sistema antes de que se construya. La elaboración del sistema puede depender de librerías externas que no se incluyen en el sistema de gestión 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 construcción. Sin embargo, para sistemas embebidos y de tiempo real, el entorno objetivo con frecuencia es más pequeño 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 1.
máquinas desarrollo. En ambos casos, no es posible construir y probar el sistema en la computadora de desarrollo o en el servidor de construcción. Para sistemas embebidos puede instalarse un entorno de simulación en el entorno de desarrollo para pruebas, en vez de usar la plataforma de sistema embebido real. Dichos simuladores pueden ofrecer mejor soporte de depuración que el disponible en un sistema embebido. Sin embargo, es muy difícil 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 construcción del sistema implica ensamblar una gran cantidad de información acerca del software y su entorno operacional. Entonces, para cualquier sistema aparte de los pequeños, siempre tiene sentido usar una herramienta de construcción automatizada para crear una construcción del sistema.
Puede observar que no sólo necesita los archivos del codigo fuente implicado en la construcción, sino tal vez se deban vincular dichos archivos, archivos de datos (como un archivo de mensajes de error) y archivos de configuración proporcionados externamente que definan la instalación objetivo. Existe una gran cantidad de herramientas de construcción disponibles, y un sistema de construcción ofrece algunas características o todas ellas: 1. Generación de rutinas (scripts) de construcción: Si es necesario, el sistema de construcción debe analizar el programa en construcción, identificar los componentes dependientes y generar automáticamente una rutina de construcción (llamado algunas veces archivo de configuración). 2. Integración del sistema de gestión de versiones: El sistema de construcción debe sacar las versiones de componentes requeridas del sistema de gestión de versiones. 3. Recopilación mínima: El sistema de construcción debe establecer qué código fuente necesita volver a compilarse y establecer las compilaciones si así se requiere.
4. Creación de sistema ejecutable: El sistema de construcción debe vincular los archivos de código de objeto compilado entre sí y con otros archivos requeridos, como las librerías y los archivos de configuración, para crear un sistema ejecutable. 5. Automatización de pruebas: Algunos sistemas de construcción pueden efectuar pruebas automatizadas utilizando herramientas de automatización de pruebas como JUnit. Éstas comprueban que la construcción no se haya “roto” por los cambios. 6. Informes: El sistema de construcción debe ofrecer informes sobre el éxito o fracaso de la construcción y las pruebas que se efectuaron. 7. Generación de documentación: El sistema de construcción puede generar notas referentes a las páginas de ayuda de la construcción y del sistema. La rutina de construcción incluye la especificación de la configuración, de manera que el lenguaje de escritura de rutinas utilizado generalmente es el mismo que el lenguaje de descripción de la configuración. El lenguaje de configuración incluye sentencias para describir los componentes del sistema a incluir en la construcción y sus dependencias. Puesto que la compilación es un proceso de cómputo intensivo, las herramientas para soportar la construcción de sistemas se diseñan por lo general para minimizar la cantidad de compilación que se requiere. Esto se hace comprobando si está disponible una versión 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 código fuente. El código objeto correspondiente, que se compiló a partir del código fuente, tiene una firma relacionada que identifica cada versión del código fuente y cambia cuando éste se edita. Al comparar las firmas en los archivos de código fuente y objeto, es posible decidir si el componente del código fuente se usó para generar el componente de código objeto. Hay dos tipos de firmas que pueden usarse: 1. Modificación de marca de tiempo (timestamp0:) La firma en el archivo del código fuente es la fecha y hora de cuándo éste se modificó. Si el archivo del código fuente de un componente se modifica después del archivo del código objeto relacionado, entonces el sistema supone que se requiere “recopilación” para crear un nuevo archivo del código objeto. 2. Sumas de verificación (checksums) de código fuente: La firma en el archivo del código fuente es una suma de verificación calculada a partir de datos en el archivo. Una función checksum calcula un número único usando el texto fuente como entrada. Si se modifica el código fuente (incluso por un carácter), esto generará una suma diferente. La suma de verificación se asigna al código fuente justo antes de la compilación e identifica de manera exclusiva el archivo fuente. Entonces el sistema de construcción etiqueta el archivo de código objeto generado con la firma checksum. Si no hay archivo
de código objeto con la misma firma que el archivo de código fuente a incluir en un sistema, entonces es necesario recompilar el código fuente. El enfoque checksum tiene la ventaja de permitir muchas versiones diferentes del código objeto de un componente para mantenerse al mismo tiempo. La firma es el vínculo entre el código fuente y objeto. Los archivos de código fuente y de código objeto tienen la misma firma. Por lo tanto, cuando se recompila un componente, no sobrescribe el código objeto, como sería normalmente el caso cuando se usa timestamp. En vez de ello, genera un nuevo archivo de código objeto y lo etiqueta con la firma del código fuente. Los métodos á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 integración continua:
Pasos de la integración continua: 1. Sacar la línea principal del sistema de gestión de versiones hacia el espacio de trabajo privado del desarrollador. 2. Construir el sistema y efectúe pruebas automatizadas para garantizar que el sistema construido pasa todas las pruebas. Si no lo hace, la construcción se descompone y hay que informar a quienquiera que ingrese al último sistema línea 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, continúe la edición. 5. Una vez que el sistema pasa sus pruebas, ingresar en el sistema de construcción, pero no confirme como una línea base nueva del sistema.
6. Construir el sistema en el servidor de construcción y efectúe 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 edítelo de modo que las pruebas pasen en su espacio de trabajo privado. 7. Si el sistema pasa sus pruebas en el sistema de construcción, confirmar entonces los cambios que hizo como una nueva línea base en la línea principal del sistema. El sistema más reciente en la línea principal es el sistema funcional definitivo. Sin embargo, aunque la integración continua es una buena idea, no siempre es posible implementar este enfoque a la construcción 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 práctico construir muchas veces al día 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 más tiempo para probar el sistema. Para sistemas grandes o sistemas donde la plataforma de ejecución no es la misma que la plataforma de desarrollo, la integración continua quizá no sea práctica. Ante tales circunstancias se puede usar un sistema que se construya diariamente. Características de esto: 1. La organización 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 básica que pueda ponerse a prueba. 2. A partir de dichos componentes se crea una nueva versión 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 todavía trabajan en sus componentes, añaden 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 versión 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: ingeniería de software 9 edicion. Ian Sommerville Libro: Ingernieria de software Sexta edición. Roger. Pressman
