TEMA 3

1. CASO DE PRUEBA (CAJA BLANCA Y CAJA NEGRA)

   
   

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados. Para llevar a cabo un caso de prueba tenemos que definir condiciones, seleccionar unos valores de entrada y conocer el comportamiento que tendría que tener el sistema ante esos valores. Una vez ejecutado el caso de prueba se analiza el comportamiento y se comparan los resultados con lo que se esperaba para determinar si el sistema ha pasado o no la prueba.

Nuestra validación deberá incluir dos tipos de pruebas:

➢ De caja blanca

Todas las sentencias se ejecutan al menos una vez.

Todas las condiciones se ejecutan en su parte verdadera y en su parte falsa.

 Los bucles se ejecutan en sus límites.

Todas las estructuras de datos se usan para asegurar su validez.

Resumen: Se comprueba lo de dentro del código si cada línea y función esta bien

➢ De caja negra:
(o de comportamiento) Sólo se comprueba la funcionalidad, es decir, si la salida es adecuada en función de los datos de entrada, sin fijarse

en el funcionamiento interno.

Resumen: Si furula o no

2. Secuencias de pruebas

La prueba requiere los siguientes pasos:

• Prueba de unidad: Se centra en cada unidad de software, en cada módulo del código fuente
• Prueba de integración: A partir de los módulos probados individualmente, se prueba el funcionamiento. Hay dos enfoques:

• Big bang: consiste en ser estrictos en el orden de probar todos los módulos por separado antes de pasar a conjunto
• Integración incrementas: se van incorporando módulos poco a poco y probando su integración.

• Prueba de validación: en el entorno real de trabajo y con intervención del usuario final

• Alfa: con el usuario final en el lugar de desarrollo
• Beta: con el usuario final en su propio lugar de trabajo

• Prueba del sistema: Para verificar funcionalidad y redimiento

• Prueba de recuperación: se fuerza el fallo del software y se comprueba que la recuperación es satisfactoria
• Prueba de seguridad: se intenta verificar que el sistema está protegido contra accesos ilegales
• Prueba de resistencia: enfrenta al sistema con situaciones que

• demandan gran cantidad de recursos

TEMA 4

UML

UML (Unified Modeling Languaje – Lenguaje de Modelado Unificado) es un lenguaje basado en diagramas para representar modelos de la realidad siguiendo el paradigma de la orientación a objetos.

UML define 13 tipos de diagramas divididos en tres categorías:

➢ Diagramas de estructura (parte estática del modelo): Se centran en los elementos que deben existir en el modelo.

-Diagramas de clases: Muestran las clases del sistema y relaciones entre ellas.

-Diagramas de objetos: Representan objetos y sus relaciones. Muestra una serie de objetos y sus relaciones en un momento particular de la ejecución del sistema. Son útiles para la comprensión de los diagramas de clases.

-Diagramas de paquetes: Reflejan la organización de paquetes y sus elementos. El uso más común es organizar diagramas de clases y diagramas de casos de uso, aunque no se limita a eso.

-Diagramas de despliegue: Especifica el hardware físico sobre el que el sistema se ejecutará y como el software se despliega en el.

              -Diagramas de estructuras compuestas.

-Diagramas de componentes.

➢ Diagramas de comportamiento (parte dinámicas del modelo): Se centran en lo que debe suceder en el sistema.

-Diagramas de estado: Para analizar los cambios de estado de los objetos. Se suele usar un círculo relleno para el estado inicial, un círculo relleno dentro de otro círculo para el estado final, rectángulos para el resto de estados y flechas para las transiciones.

-Diagramas de actividad: Muestran el flujo detallando las decisiones que surgen.

-Diagramas de casos de uso: Se utiliza para entender el uso del sistema

-Diagramas de interacción:

.Diagramas de secuencia: Son una representación temporal de los objetos y sus relaciones.

.Diagrama resumen de interacción.

.Diagrama de comunicación.

.Diagrama de tiempo.

HERENCIA

La herencia asocia clases con atributos y operaciones comunes. Las superclases contienen los atributos y operaciones más generales (generalización) y las

subclases son más especificas (especialización). La herencia se representa con un flecha con punta en triángulo hueco para diferenciarlas de la asociación (que tiene una flecha con punta en ángulo). El extremo de la flecha en la herencia apunta a la superclase.

Asociación

La asociación se indica con una línea que une las clases asociadas. Sobre la línea se escribe el nombre de la asociación y, si fuera necesario, el papel que juega cada una de las clases en la relación. La asociación es el mismo concepto que la relación en el modelo E/R. A través de la asociación podemos enlazar a los Alumnos con sus Asignaturas, a los Clientes con los Artículos, etc.

Composición

Un objeto puede estar compuesto de otros objetos. En este caso hablamos de una asociación de composición, que asocia a un objeto complejo con los objetos simples que lo componen, es decir, sus componentes. En la composición fuerte los componentes de un objeto no pueden formar parte de otros objetos, por tanto, la cardinalidad es 1 y la eliminación del objeto compuesto implica la eliminación de los componentes. Se representa con una línea que tiene un rombo relleno en el extremo del objeto compuesto.

AGRGACION

En la agregación (también conocida como composición débil) los componentes pueden ser compartidos por varios compuestos y la destrucción del compuesto no implica la destrucción de los componentes. Se representa con una línea que tiene un rombo hueco en

el extremo del compuesto. En la agregación puede existir cualquier cardinalidad.

DEPENDENCIA

La dependencia se da cuando una clase usa a otra, pero no como atributo, sino como un parámetro de método o instanciándola en una variable local o, haciendo uso de sus miembros estáticos.

Es la asociación que existe entre dos clases, tales que una usa a la otra. Se representa con una flecha de ángulo y línea discontinua. La flecha apunta a la clase utilizada. Un cambio en la clase utilizada (servidor o proveedor) puede afectar a la utilizadora (cliente), pero no al contrario.

TEMA 5

1. Documentación

Distinguimos 4 apartados:

• Documentación de las especificaciones: se trata de conseguir que el desarrollador y cliente tenga la misma idea sobre lo que hace el programa:

• Introducción
• Descripción de la información
• Descripción funcional
• Descripción del comportamiento
• Criterios de validación

• Documentación del diseño: información sobre estructuras de datos, implementación …
• Documentación del código fuente: son los comentarios que se incluyen en el código para clarificarlo

• Documentación de usuario final:  es la documentación que se entrega al usuario describiendo como se usa

2. Refactorización

La refactorización es una técnica para optimizar código haciendo cambios en la estructura interna sin alterar el comportamiento externo

3. 1. Los malos olores

Los síntomas son los siguientes:

• Código duplicado
• Métodos muy largos
• Clases muy grandes
• Lista de parámetros extensa
• Cambio de divergente
• Cirugía a tiro pistola
• Envidia de funcionalidad
• Clase de solo datos
• Legado rechazado

4. Control de versiones

Cuando se desarrolla software es necesario mantener simultáneamente versiones distintas de un mismo programa. La que esta en producción, las nuevas versiones y las modificaciones entre unas y otras

Gestionar esta tarea es muy complicado y por eso surgen herramientas para el control de versiones que facilitan el trabajo colaborativo y el mantenimiento del software libre en múltiples estados simultáneamente

5. 2. Terminología

La terminología puede variar de sistema en sistema

emoto cuando así se solicite.

• Repositorio
• Modulo
• Importación
• Copia de trabajo
• Desplegar
• Rama
• Tronco
• Publicar
• Actualización
• Integración
• Conflicto
• Revisión
• Rotular
• Congelar
• Exportación

6. 3. Formas de colaborar

Para colaborar en un proyecto usando un sistema de control de versiones lo primero que hay que hacer es crearse una copia local obteniendo un repositorio.

Existen dos esquemas básicos:

• Exclusiva: para poder realizar un cambio es necesario comunicar al repositorio el elemento que se desea modificar y el sistema se encargará de impedir que otro usuario pueda modificar dicho elemento
• Colaborativa:  En este esquema cada usuario modifica la copia local y cuando el usuario decide combatir los cambios el sistema automáticamente intentar combinar las diversas modificaciones

ARQUITECTURAS DE ALMACENAMIENTO

Podemos clasificar los sistemas de control de versiones atendiendo a la arquitectura utilizada para el almacenamiento del código:

➢ Centralizados:
existe un repositorio centralizado de todo el código, del cual es responsable un único usuario. Se facilitan las tareas administrativas a cambio de reducir flexibilidad, pues todas las decisiones fuertes necesitan la aprobación del responsable. Algunos ejemplos son CVS y Subversión.

Los sistemas centralizados permiten un mayor control sobre los proyectos.

➢ Distribuidos:
Cada usuario tiene su propio repositorio. Los distintos repositorios pueden intercambiar y mezclar revisiones entre ellos. Es frecuente el uso de un repositorio, que está normalmente disponible, que sirve de punto de sincronización de los distintos repositorios locales. Ejemplos: Git y Mercurial.

Los sistemas distribuidos son más rápidos y autónomos, permiten trabajar offline y son más tolerantes a fallos porque la información está muy replicada.

GIT

El sistema distribuido de Git permite varios repositorios externos. La mayoría de las operaciones son locales (más rápido) y la instalación y configuración es más sencilla. Por contra la curva de aprendizaje es más alta y la comunicación entre colaboradores más compleja.

Github es un hosting para repositorios git y ofrece el

servicio web de control de versiones. Estos repositorios pueden ser públicos o privados. En la versión gratuita de Github puedes tener ilimitados repositorios públicos con ilimitados colaboradores. También puedes tener ilimitados repositorios privados. En Github aparecen los proyectos (projects) como conjuntos de listas de tareas.

trabaja de forma distribuida. Cada colaborador tiene un repositorio local que puede, en cualquier momento actualizar con los repositorios del resto de colaboradores. No obstante, tendremos un repositorio remoto, principal, situado en un servidor, para facilitar todos los intercambios. Cada usuario solamente tendrá que actualizar hacia y desde este repositorio remoto principal.

 Un repositorio tiene el aspecto de una carpeta cualquiera. Si listamos su contenido muestra solo los ficheros actuales, pero se trata de una carpeta especial porque es capaz de volver su contenido a estados anteriores, siempre a través de comandos git. Dentro del repositorio podemos distinguir tres áreas:

➢ La copia de trabajo  que contiene la versión actual de los ficheros. Es lo que veremos si listamos el contenido de la carpeta.

➢ El área de staging, que contiene solo algunos ficheros de la copia de trabajo: aquellos que se encuentran preparados para ser confirmados en sus modificaciones.

➢ El repositorio propiamente dicho (HEAD local)
Que contiene la copia local del proyecto, lista para ser mezclada con el repositorio r