Apuntes Final DCA

Ortogonalidad: número de programadores afectados al realizar un cambio en el proyecto. Depende del proyecto, del diseño y de las personas con las que contamos.

Para tener un sistema ortogonal hay que separar la infraestructura de la aplicación, y cada componente de la infraestructura que lo gestione un subequipo.

• Paradigma cerrado: similar a centralizado controlado
• Paradigma aleatorio: de manera libre mediante iniciativa individual (innovación)
• Paradigma abierto: mezcla de cerrado + aleatorio (muy buena comunicación) (problemas complejos)
• Paradigma sincronizado: partes del problema sirven para organizar (poca comunicación entre equipos

• Linus Torvalds: Linux
• Guido van Rossum: Python
• Larry Wall: Perl
• Alexandre Julliard: Wine

No tiene por qué ser vitalicio

• Uniformidad a la hora de que los equipos se comuniquen de cara al exterior
• Evitar repeticiones
• análisis, diseño, codificación y testeo no se debe hacer de forma aislada
• Automatizarlo todo, da consistencia al trabajo

No tiene que ver con SCV

La rama representa la línea principal de desarrollo de un proyecto software antes de ser distribuido.

• Gestión por solo una persona
• Deben aceptarse
  • Añadidos
  • Borrados
  • Modificaciones

Contiene código estable e inestable, el integrador es el que decide cuando es estable.

Siempre tiene las últimas modificaciones, puede no funcionar bien.

• El concepto de la rama máster puede aplicarse a subproyectos del proyecto también

Si tenemos la versión estable v1.0.0 podemos ir teniendo nuevas propuestas en desarrollo o trunk o master.

Dan información útil para usuarios y desarrolladores.

En la mayoría suelen ser números pero pueden ser letras también o fechas o números de compilación.

• menor par: rama estable
• menor impar: rama inestable

• Conocer que avisos son reales y cuáles no
• Ver el estado de tratamiento de un error en un instante
• Ver como etán respondiendo los desarrolladores a los avisos

Github, etc integran su propio sistema de seguimiento de fallos.

Es el Tape ARchiver, ``junta’’ archivos y directorios en uno «por decir». Soporta almacenar fechas de archivo, permisos, propietario y tiene soporte para enlaces duros y simbólicos.

NO realiza compresión de ficheros.

Tiene carencias para usarse como empaquetado para sofrware, no puede gestionar las dependencias del software, ejecutar acciones, etc.

Es un fichero ar que contiene:

• debian-binary (versión del formato .deb usado)
• control.tar.gz (metainformación del paquete)
• data.tar (el paquete)

Es similar a .deb usado en RedHat, Fedora, Suse…

Se ejecuta con administrador

Permite convertir entre formatos

sudo alien -[t,d,r] ../.deb

Además tiene la opción -c para intentar convertir los scripts que se ejecutan

Make es una herramienta de construcción de proyectos basada en marcas de tiempo

• -k continua ejecutando aún con errores
• -d printea lo que hace
• podemos cambiar variables de entorno make CC=clang

Solo funciona con gcc o similar

Se trata de una herramienta que cachea los resultados del compilador. Se guardan en /.ccache/ en una tabla hash con MD4. Soporta:

• C/C++

• Objective C/C++

  Funcionalidades:

  • Estadísticas
  • Soporta enlaces duros para evitar copias
  • Opcionalmente comprime la caché

  • Cachea compilaciones con warnings

    Algunas opciones de gcc no están soportadas, si sucede ccache lo detecta e invoca al compilador real.

Está pensado para gcc pero funciona con los compiladores de intel y oracle. Es importante tener la misma versión del compilador el todas las máquinas, por la ABI.

Se compone de distcc (cliente) y distccd (servidor)

Compila:

• C/C++

• Objective C/C++

  Funciona sobre TCP y sobre SSH.

  Se ejecuta con el -j N de make, como regla sencilla usamos el doble de CPUs de la red

Autotools consta de tres componentes: autoconf, automake y libtool.

Funciona en los tres SO tipo unix y en windows bajo cygwin

Para funcionar no necesita tener instalado autotools, genera guiones de shell Posix compatible.

Comandos imprescindibles para autoconf:

autoscan autoreconf autoupdate

Comienza a desarrollarse en 1999 como parte del Insight Toolkit.

Se comporta como Autoconf y Automake juntos

Dispone de herramientas como CPack CTest y CDash

Muy nuevo, escrito en python3 para Linux/OSX/Windows.

Se configura con un meson.build

Usa ninja por defecto (hay vs o xcode), no tiene soporte para makefiles

Solo permite out of source

El propósito es demostrar que en nuestro software existen fallos, NO demostrar su ausencia

Comprobar un programa consiste en ver si su comportamiento es correcto para cualquier posible entrada (esto es imposible, necesitamos heurísticas). A este conjunto de entradas es lo que se le llama test suite, hemos de procurar que no tarden mucho tiempo en ejecutarse.

Para obtener una buena test suite es recomendable particionar un conjunto de datos de entrada en subcojuntos, de manera que cada elemento del conjunto original pertenezca exactamente a uno de estos subconjuntos. Esto es imposible así que hemos de emplear heurísticas, como usar una entrada de cada uno de los subconjuntos.

• Tests unitarios
• Tests de integración (integración de módulos)
• Tests de sistema (sistema al completo)
• Tests de rendimiento
• Tests de usabilidad

• Tests de regresión (no debe estropear lo que funcionaba)
• Tests de datos (datos reales y sintéticos)
• Tests de UI
• Tests de los tests

Es el término empleado para describir una serie de herramientas de test que se comportan de manera similar. Surge de SUnit para Smalltalk, posteriormente se portó a JUnit, .NET NUnit, C++ cxxtest, etc.

• Es un entorno de testeo tipo xUnit.
• Soporta el descubrimiento de tests, no es necesario registrarlos
• Se definen en los .h, cxxtestgen genera los .c

• Puede convertirse en el marco de test estandar para C++
• Los tests van en un .cpp

• Librería GLib pensada para desarrollar en C
• Adaptaciones de GLib nos pueden dar acceso a otros lenguajes a esta librería
• Permite crear test individuales y test suites

Es lo que hace que funcione la internacionalización. Consta de una serie de parámetros culturales escritos en un archivo en una variante de un idioma hablado en un territorio.

Internacionalizar es preparar un proyecto para que soporte multitud de idiomas, localización es tomar dicho proyecto internacionalizado y proporcionarle la suficiente información para que se adapte al idioma y configuración del usuario.

Repositorio: Es la copia maestra

Copia de trabajo: La copia de los ficheros del proyecto que podemos modificar. Cada desarrollador tiene la suya propia.

Check out/Clone: Obtener una copia de trabajo desde el repositorio

Check in/Commit: La acción para llevar los cambios hechos en la copia de trabajo a la copia local del repositorio.

Push: Traslada contenidos de copia local a copia maestra

Update/Pull/Fetch+Merge/Rebase: Actualiza nuestra copia local del repositorio a partir de la copia maestra, además actualiza la copia de trabajo.

Conflicto: Cuando 2 desarrolladores hacen un commit con cambios en la misma región del mismo fichero.

Rama: Representa una línea de evolución de nuestro software, una es especial, master.

• Largo recorrido
• Ramas puntuales

• Merge (mezcla)

  master:   A--B--C
  topic:    A--B--C
                   \
                    X--Y--Z         1
  
  El tiempo pasa: A--B--C--D--E--F  2
                         \
                          X--Y--Z
  
  mezcla: A--B--C--D--E--F--M       3
                 \         /
                   X--Y--Z
  

• Rebase (rebasamiento)

  master:   A--B--C
  
  topic:    A--B--C
                   \
                    X--Y--Z          1
  
  El tiempo pasa: A--B--C--D--E--F   2
                         \
                          X--Y--Z
  
  mezcla: A--B--C--D--E--F           3
                          \
                           X'--Y'--Z'
  

Linux usaba BitKeeper hasta 2005 hasta que Linus Torvalds creó Git. Gitusa SHA1 y recientemente SHA256

• Es barato trabajar con ramas

• SCV distribuido disponible en OSX, windows y Linux.
• Surge a la vez que git
• Escrito en python + C
• Además de un SHA-1 associa un changeset
• Distingue entre dos tipos de ramas:
  • Ramas con nombre
  • Clones de repositorios
• Admite extensiones
  • Ayuda para repos git
  • Ayuda para subversion

• SCV distribuido
• Las ramas viven en su propio directorio (son directorios)