Clase 11. Análisis dinámico, 2ª parte.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Clase 11. Análisis dinámico, 2ª parte."

Transcripción

1 Clase 11. Análisis dinámico, 2ª parte. Continuamos con el mismo tema de la clase anterior, pero esta vez nos ocuparemos principalmente de la fase de prueba. Nos detendremos brevemente en algunas de las nociones básicas que subyacen en las actividades de prueba y analizaremos las técnicas más extendidas. Por último, recopilaremos algunas directrices prácticas para ayudarle en sus propias tareas de prueba Fase de prueba Si adopta un enfoque sistemático, la fase de prueba resultará mucho más efectiva y mucho menos complicada. Antes de empezar, considere los siguientes puntos: qué propiedades desea probar; qué módulos desea probar y en qué orden; cómo va a generar los casos de prueba; cómo va a comprobar los resultados; cómo sabrá si ha terminado. Para decidir qué propiedades desea probar es necesario conocer el dominio del problema, con el fin de saber qué clase de fallos son más importantes, así como el programa, para saber lo difícil que va a resultar descubrir los tipos de errores. La elección de módulos es más sencilla. Pruebe sobre todo los módulos que sean críticos, complejos o que estén escritos por el peor de sus programadores (o por el más aficionado a utilizar trucos brillantes dentro del código). O tal vez el módulo que se escribió a altas horas de la noche, o justo antes del lanzamiento El diagrama de dependencia modular sirve para determinar el orden. Si el módulo depende de otro que aún no está implementado, tendrá que escribir un stub (o esqueleto de un módulo) que hará el papel del módulo que está fallando durante la fase de prueba. El stub proporciona el rendimiento necesario para la prueba. Es posible, por ejemplo, buscar respuestas en una tabla en lugar de realizar la computación verdadera. La comprobación de los resultados puede resultar complicada. Algunos programas como el Foliotracker que va a construir en los ejercicios 5 y 6 ni siquiera tienen comportamiento repetitivo. En otros, los resultados son sólo la punta del iceberg y para comprobar que las cosas marchan bien, será necesario verificar las estructuras internas. Más adelante hablaremos de cómo generar casos de prueba y cómo saber cuando el trabajo está completo Pruebas de regresión Es muy importante ser capaz de volver a ejecutar las pruebas cuando se modifica el código.

2 Por esta razón, no es buena idea realizar pruebas específicas que no pueden ser repetidas. Puede parecer un trabajo arduo, pero a largo plazo, resulta menos laborioso construir un conjunto práctico de pruebas que pueden ser reejecutadas a partir de un archivo. Es lo que se denomina pruebas de regresión. Un enfoque de la fase de prueba que recibe el nombre de test first programming, y que es parte de la nueva doctrina de desarrollo denominada extreme programming, apuesta por la construcción de pruebas de regresión antes incluso de que se haya escrito el código de aplicación. JUnit, el marco de pruebas que ha utilizado, fue concebido para esto. La construcción de pruebas de regresión para un sistema grande es una empresa importante. Es posible que sólo la ejecución de los scripts dure una semana. Por lo tanto un área de investigación que es muy interesante actualmente es intentar determinar qué pruebas de regresión pueden omitirse. Si sabe qué casos de prueba aplicar a las partes del código, podrá determinar que un cambio local en una parte del código no exige que todos los casos sean reejecutados Criterios Para entender cómo se generan y evalúan las pruebas, podemos pensar de manera abstracta sobre la finalidad y la naturaleza de la fase de prueba. Suponga que tenemos un programa P que debe cumplir una especificación S. Asumiremos, para que sea más sencillo, que P es una función que transforma las entradas de datos en salida de datos, y S es una función que recibe una entrada de datos y una salida de datos y devuelve un tipo booleano. Nuestro objetivo al realizar las pruebas es encontrar un caso de prueba t tal que: S (t, P(t)) sea falso: esto es, P produce un resultado para la entrada t que no es permitido por S. Llamaremos a t un caso de prueba fallido, aunque en realidad es un caso de prueba con éxito, ya que nuestra finalidad es encontrar errores. Una suite de pruebas T es un conjunto de casos de prueba. Ahora nos hacemos la siguiente pregunta: cuándo una suite puede considerarse suficientemente buena? En lugar de intentar evaluar cada suite de forma que dependa de la situación, podemos aplicar criterios generales. Puede pensar en un criterio como una función: C: Suite, Program, Spec ~ Boolean que recibe una suite de pruebas, un programa y una especificación, y devuelve verdadero o falso de acuerdo con el hecho de que la suite sea suficientemente buena para el programa y la especificación dados, todo ello de forma sistemática. La mayoría de los criterios no incluyen ambos, el programa y la especificación. Si sólo se incluye el programa se denomina criterio basado en el programa. También se utilizan

3 términos como whitebox, clearbox, glassbox, o pruebas estructurales para describir fases de prueba que utilizan criterios basados en programas. Un criterio que sólo incluye la especificación se denomina criterio basado en la especificación. El término blackbox se utiliza en asociación con este criterio, para dar a entender que las pruebas se juzgan sin que se pueda analizar la parte interna del programa. También se utiliza el término pruebas funcionales Subdominios Los criterios prácticos se inclinan por una estructura y propiedades singulares. Por ejemplo, pueden aceptar una suite de casos T y sin embargo rechazar una suite T que es igual que T pero con algunos casos adicionales. También tienden a no ser sensibles en lo que se refiere a las combinaciones de los casos de prueba escogidas. Estas características no son, necesariamente, buenas propiedades; simplemente surgen del modo sencillo en que la mayoría de los criterios se definen. El dominio de los datos de entrada se divide en subregiones, algunas de las cuales se denominan subdominios, y cada una contiene un conjunto de datos de entrada. Los subdominios juntos engloban todos los dominios de los datos de entrada: esto es, toda entrada está en por lo menos un subdominio. Una división del dominio de datos de entrada en subdominios define un criterio implícito: que define que deba existir al menos un caso de prueba para cada subdominio. Por lo general los subdominios no son inconexos, por lo tanto, un único caso de prueba puede estar en todos los subdominios. La idea que subyace tras el subdominio tiene dos aspectos. En primer lugar, es fácil (al menos conceptualmente) determinar si una suite de pruebas es suficientemente buena. En segundo lugar, esperamos que al exigir un caso de prueba de cada subdominio haremos que las pruebas se orienten a regiones de datos más propensas a revelar fallos. De forma intuitiva, cada subdominio representa un conjunto de casos de prueba similares; deseamos maximizar el beneficio de la actividad de prueba escogiendo casos de prueba que no sean similares; es decir, casos de prueba que provengan de subdominios diferentes. En el mejor de los casos, un subdominio es revelador, lo que significa que cada caso de prueba que contiene hace que el programa falle o tenga éxito. Así, el subdominio agrupa casos verdaderamente equivalentes. Si todos los dominios son reveladores, una suite de pruebas que satisfaga el criterio será completa, ya que tendremos la garantía de que encontrará cualquier fallo. En la práctica, sin embargo, resulta bastante difícil obtener subdominios reveladores, pero escogiendo con cuidado los subdominios es posible tener al menos algún subdominio cuya tasa de error la proporción de entradas que conducen a salidas de datos erróneas sea mucho mayor que la tasa de error media del dominio de datos de entrada como un todo Criterios de subdominio El criterio ordinario y más ampliamente utilizado en las pruebas basadas en programa es la

4 cobertura de sentencias: esto es, que cada sentencia o segmento de un programa deba ejecutarse al menos una vez. Por la definición, se entiende por qué se trata de un criterio de subdominio: defina para cada sentencia del programa el conjunto de entregas que hacen que se ejecute y escoja al menos un caso de prueba para cada subdominio. Desde luego, el subdominio nunca se construye explícitamente; es una noción conceptual. En vez de eso, lo que ocurre es que se ejecuta una versión instrumental del programa que registra cada sentencia ejecutada. Debe continuar añadiendo casos de prueba hasta que todas las sentencias sean ejecutadas. Existen más criterios aparte de la cobertura de sentencias. El denominado cobertura de decisión o de condición requiere que se ejecuten todas las aristas del gráfico de flujo de control del programa: es como exigir que todas las ramas de un programa sean ejecutadas. No está tan clara la razón por la que este enfoque está considerado más riguroso que la cobertura de sentencias. Piense en la posibilidad de aplicar este criterio a un procedimiento que devuelva el menor de dos valores: static int minimum (int a, int b) { if (a b) return a; else return b; Para este código, la cobertura de sentencias requerirá entradas con a menor que b y viceversa. Sin embargo, para el código: static int minimum (int a, int b) { int result = b; if (b a) result = b; return result; un único caso de prueba con b menor que a satisfará el criterio de la cobertura de sentencias, y el fallo se pasará por alto. La cobertura de decisión requeriría un caso en el que el comando if no sea ejecutado, exponiendo de esta forma el fallo. Hay muchas formas de cobertura de condición que exigen, de diversas formas, que las expresiones booleanas probadas como condición sean evaluadas tanto para verdadero (true) como para falso (false). Una forma específica de cobertura de condición, conocida como MCDC, es exigida por una norma denominada DoD específica para software de seguridad crítica, como los de aviación. Esta norma, DO-178B, clasifica los fallos en tres niveles y exige un diferente nivel de cobertura para cada uno: Nivel C: el fallo reduce el margen de seguridad Ejemplo: link de datos vía radio Requiere: cobertura de sentencia Nivel B: el fallo reduce la capacidad de la nave o de la tripulación Ejemplo: GPS

5 Requiere: cobertura de decisión Nivel A: el fallo provoca la pérdida de la nave Ejemplo: sistema de gestión de vuelo Requiere: cobertura MCDC Otra forma común de criterio de subdominio de tipo basada en programa es la que se utiliza en las pruebas de casos límite. Esto requiere la evaluación de los casos límite de cada condición. Por ejemplo, si su programa prueba x < n, serían necesarios casos de prueba que produjeran x = n, x = n-1, y x=n+1. Los criterios basados en especificación también se presentan en términos de subdominios. Como las especificaciones son por lo general informales esto es, no están escritas en ninguna notación precisa los criterios tienden a ser más vagos. El planteamiento más común es definir los subdominios de acuerdo con la estructura de la especificación y los valores de los tipos de datos subyacentes. Por ejemplo, los subdominios para un método que inserte un elemento en un conjunto pueden ser: el conjunto está vacío el conjunto no está vacío y el elemento no está en el conjunto el conjunto no está vacío y el elemento está en el conjunto También puede, en la especificación, utilizar cualquier estructura condicional para guiar la división en subdominios. Es más, en la práctica, los encargados de realizar las pruebas utilizan sus conocimientos al respecto de los tipos de error que muchas veces surgen en los códigos. Por ejemplo, si está probando un procedimiento que encuentra un elemento en un array, probablemente colocará el elemento al principio, en el medio y al final, simplemente porque estos casos son propensos a ser manipulados de forma diferente en el código Viabilidad La cobertura total es raramente posible. De hecho, incluso logrando una cobertura de sentencias del 100% es imposible alcanzar la cobertura total. Esta imposibilidad ocurre en razón del código de programación defensiva, código que, en gran parte, nunca se debería ejecutar. Las operaciones de un tipo abstracto de datos, que no tienen ningún cliente, no se ejecutarán mediante casos de prueba independientemente del rigor aplicado, aunque se pueden ejecutar por pruebas de unidad. Se dice que un criterio es factible si es posible satisfacerlo. En la práctica, los criterios no suelen ser factibles. En términos de subdominio, contienen subdominios vacíos. La cuestión práctica es determinar si un subdominio esta vacío o no; si está vacío, no hay razón para tratar de encontrar un caso de prueba que lo satisfaga. Por regla general, cuanto más elaborado sea el criterio, más difícil llega a ser su

6 determinación. Por ejemplo, la cobertura de caminos requiere que todos los caminos del programa sean ejecutados. Suponga que tengamos el siguiente programa: if C1 then S1; if C2 then S2; Entonces, para determinar si el camino S1;S2 es factible, necesitamos determinar si las condiciones C1 y C2 pueden ambas ser verdaderas. Para un programa complejo, no se trata de una tarea trivial y, en el peor de los casos, no es más fácil que determinar la corrección del programa mediante razonamiento. A pesar de estos problemas, la idea de cobertura es muy importante en la práctica. Si existen partes importantes del programa que nunca han sido ejecutadas, más vale que no confíe demasiado en su exactitud! 11.7 Directrices prácticas Ha de quedar claro por qué ni los criterios basados en programas, ni los basados en especificaciones son, por sí solos, suficientes. Si sólo se fija en el programa, pasará por alto errores de omisión. Si sólo observa la especificación, no detectará errores que surgen de problemas de implementación, como, por ejemplo, cuando se alcanzan los límites de un recurso computacional, caso en que se necesita un procedimiento de compensación. En la implementación de la clase ArrayList de Java, por ejemplo, el array de la representación se sustituye cuando está lleno. Para probar este comportamiento, será necesario insertar elementos suficientes en la ArrayList para que el array quede lleno. La experiencia sugiere que el mejor modo de realizar una suite de pruebas es utilizar el criterio basado en la especificación para guiar el desarrollo de la suite y, para evaluar la suite, es mejor que se utilicen los criterios basados en el programa. De este modo, podrá examinar la especificación y definir subdominios de entrada. Basándose en estas premisas, usted puede escribir los casos de prueba. A continuación, se ejecutan los casos y se mide la cobertura de las pruebas en relación con el código. Si la cobertura es inadecuada, bastaría con añadir nuevos casos de prueba. En un entorno profesional, se utilizaría una herramienta especial para medir la cobertura. En este curso, no exigiremos que aprenda a utilizar otra herramienta. En vez de eso, deberá escoger casos de prueba suficientemente elaborados para que pueda argumentar que ha alcanzado una cobertura considerable del código. Las certificaciones en tiempo de ejecución, sobre todo las que representan comprobaciones de invariante, aumentarán de manera espectacular la fuerza de sus pruebas, esto es, podrá hallar más fallos con menos casos y será capaz de solucionarlos más fácilmente.

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba Pruebas Pruebas en el PUD Las pruebas del software Diseño de casos de prueba Tipos de prueba Estrategias de prueba 1 2 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos

Más detalles

Técnicas Avanzadas de Testing Automático

Técnicas Avanzadas de Testing Automático Técnicas Avanzadas de Testing Automático Marcelo Frias ITBA - Buenos Aires, Argentina CONICET Preliminares: Calidad Validación y Verificación Especificaciones y V&V Análisis estático y dinámico Inspecciones

Más detalles

Técnicas Avanzadas de Testing Automatizado

Técnicas Avanzadas de Testing Automatizado Técnicas Avanzadas de Testing Automatizado Criterios de cobertura: Caja blanca/caja negra Clases de Equivalencia Valores de borde Cobertura basada en flujo de control CodeCover Mutación Jumble Criterios

Más detalles

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE Técnicas de prueba El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de

Más detalles

Pruebas de Programas. Introducción Errores de software. Julio Villena Román. Un error en un programa puede ser algo muy serio

Pruebas de Programas. Introducción Errores de software. Julio Villena Román. Un error en un programa puede ser algo muy serio Laboratorio de Programación Pruebas de Programas Julio Villena Román jvillena@it.uc3m.es Introducción Errores de software Un error en un programa puede ser algo muy serio http://www.wired.com/software/coolapps/news/2005/11/69355?currentpage=all

Más detalles

CLASE # 5 TÉCNICAS DE CAJA BLANCA

CLASE # 5 TÉCNICAS DE CAJA BLANCA CLASE # 5 TÉCNICAS DE CAJA BLANCA 750105M - TÉCNICAS DE PRUEBAS DE SOFTWARE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN UNIVERSIDAD DEL VALLE SEMESTRE 2013A - DOCENTE BEATRIZ FLORIAN GAVIRIA Basado Parcialmente

Más detalles

Límites. Definición de derivada.

Límites. Definición de derivada. Capítulo 4 Límites. Definición de derivada. 4.1. Límites e indeterminaciones Hemos visto en el capítulo anterior que para resolver el problema de la recta tangente tenemos que enfrentarnos a expresiones

Más detalles

Servicio de administración de pautas publicitarias en Internet

Servicio de administración de pautas publicitarias en Internet Servicio de administración de pautas publicitarias en Internet Resumen Ejecutivo Es habitual que la publicidad en Internet sea un apéndice de la publicidad en otros medios. Como no se conocen los resultados,

Más detalles

1.1 Las pruebas en el desarrollo de software tradicional

1.1 Las pruebas en el desarrollo de software tradicional software Introducción La prueba del software es un proceso que se realiza por diversos motivos, concientemente o de manera casual, pero que se reduce a unos cuantos pasos: se ejecuta el programa (o parte

Más detalles

Aproximación local. Plano tangente. Derivadas parciales.

Aproximación local. Plano tangente. Derivadas parciales. Univ. de Alcalá de Henares Ingeniería de Telecomunicación Cálculo. Segundo parcial. Curso 004-005 Aproximación local. Plano tangente. Derivadas parciales. 1. Plano tangente 1.1. El problema de la aproximación

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

Refactorizar (v) Reestructurar el software aplicando una secuencia de refactorizaciones.

Refactorizar (v) Reestructurar el software aplicando una secuencia de refactorizaciones. Refactorización Definición Refactorización (n) Cambio realizado a la estructura interna del software para hacerlo más fácil de comprender y más fácil de modificar sin cambiar su comportamiento observable.

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Sistemas de Programas Universidad Simón Bolívar

Sistemas de Programas Universidad Simón Bolívar Pruebas en sistemas orientados a objetos Sistemas de Programas Universidad Simón Bolívar Agenda 2 Introducción Qué es probar software? Por qué necesitamos probar el software? Terminología de Pruebas Black

Más detalles

1 Agencia de viajes: enunciado

1 Agencia de viajes: enunciado 1 AGENCIA DE VIAJES: ENUNCIADO 1 1 Agencia de viajes: enunciado Una agencia de viajes mantiene una base de datos con exactamente N clientes y M destinos turísticos. En una situación real, estos valores

Más detalles

MANTENIMIENTO DE SOFTWARE

MANTENIMIENTO DE SOFTWARE MANTENIMIENTO DE SOFTWARE Definición de Mantenimiento El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como la modificación de un producto software después de haber sido entregado

Más detalles

2 Métodos combinatorios

2 Métodos combinatorios 2 Métodos combinatorios Las pruebas pueden aplicarse de muchas maneras, es decir, existen diferentes formas de preparar casos de prueba. En este capítulo se presentan dos formas de prueba muy fáciles de

Más detalles

Ingeniería de Software Avanzada

Ingeniería de Software Avanzada Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Conceptos básicos de testing Una falla (failure) ocurre cuando un programa

Más detalles

construcción de programas Prof. Eliana Guzmán U.

construcción de programas Prof. Eliana Guzmán U. Unidad II. Metodología para la construcción de programas Prof. Eliana Guzmán U. Semestre: A-2015 Introducción Resolver un problema con una computadora conduce a la escritura de un programa y a su ejecución.

Más detalles

Nota 2. Luis Sierra. Marzo del 2010

Nota 2. Luis Sierra. Marzo del 2010 Nota 2 Luis Sierra Marzo del 2010 Cada mecanismo de definición de conjuntos que hemos comentado sugiere mecanismos para definir funciones y probar propiedades. Recordemos brevemente qué son las funciones

Más detalles

Clase 6: Invariantes de representación y funciones de abstracción

Clase 6: Invariantes de representación y funciones de abstracción Clase 6: Invariantes de representación y funciones de abstracción 6.1 Introducción En esta clase, vamos a describir dos herramientas utilizadas para la comprensión de tipos de datos abstractos: los invariantes

Más detalles

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA

TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA TEMA 3. EL PROCESO DE COMPILACIÓN, DEL CÓDIGO FUENTE AL CÓDIGO MÁQUINA Programa: Algoritmo (secuencia no ambigua, finita y ordenada de instrucciones para la resolución de un determinado problema) traducido

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Capitulo 3. Test Driven Development

Capitulo 3. Test Driven Development Capitulo 3. Test Driven Development 3.1 Uso de JUnit como framework para realizar pruebas unitarias Como ya se mencionó en el marco teórico Test Driven Development es una técnica de programación extrema

Más detalles

ICP 14: Medidas Preventivas y Correctivas de Supervisión Nota al Profesor

ICP 14: Medidas Preventivas y Correctivas de Supervisión Nota al Profesor ICP 14: Medidas Preventivas y Correctivas de Supervisión Nota al Profesor Copyright 2006 International Association of Insurance Supervisors (IAIS). Todos los derechos reservados. El material en este módulo

Más detalles

1. Ejemplo de clase : La clase Cuenta 2. Uso de la clase Cuenta. 3. Métodos y objetos receptores de mensajes (Importante)

1. Ejemplo de clase : La clase Cuenta 2. Uso de la clase Cuenta. 3. Métodos y objetos receptores de mensajes (Importante) 1. : La clase Cuenta. Uso de la clase Cuenta 3. Métodos y objetos receptores de mensajes (Importante) 1 Una clase para cuentas de un banco Vamos a modelar con una clase, un nuevo tipo de datos, donde los

Más detalles

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática

Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática Fundamentos de la informática 2. Algoritmos, diagramas de flujo y pseudocódigo Contenido Algoritmos Diagramas de flujo

Más detalles

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS 4.1 Antecedentes históricos El lenguaje de programación BASIC (Beginner's All purpose Symbolic Instruction Code)

Más detalles

Ejemplos de conversión de reales a enteros

Ejemplos de conversión de reales a enteros Ejemplos de conversión de reales a enteros Con el siguiente programa se pueden apreciar las diferencias entre las cuatro funciones para convertir de reales a enteros: program convertir_real_a_entero print

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

Ingeniería Software. Verificación y Validación

Ingeniería Software. Verificación y Validación Ingeniería Software Ingeniería software 4º 4º de Físicas Verificación y Validación José M. Drake y Patricia López Computadores y Tiempo Real Ingeniería de Programación 2009 1 Ingeniería de Programación

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases

Programación Avanzada para Sistemas de Telecomunicación. Objetos y clases. J.C. Cruellas. Objetos y clases Programación Avanzada para Sistemas de Telecomunicación Objetos y clases Juan Carlos Cruellas cruellas@ac.upc.es Objetos y clases Concepto de objeto. Concepto de clase. Clases, objetos y programas. Clases

Más detalles

Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción

Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción Tema 8 Procesadores Superescalares: Paralelismo Explícito a Nivel de Instrucción IA-64 es una arquitectura de 64 bits desarrollada conjuntamente por Intel y HP (Hewlett- Packard). Está basado en una tecnología

Más detalles

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007 Enunciado Se desea efectuar el testing funcional de un programa que ejecuta transferencias entre cuentas bancarias. El programa recibe como parámetros la cuenta de origen, la de cuenta de destino y el

Más detalles

Definición de clases: Herencia, polimorfismo, ligadura dinámica

Definición de clases: Herencia, polimorfismo, ligadura dinámica Tema 7 Definición de clases: Herencia, polimorfismo, ligadura dinámica Con alguna frecuencia es necesario definir clases de objetos entre las cuales hay elementos comunes. En una aplicación en la cual

Más detalles

6.170 Repaso de la prueba. Desacoplamiento. Desacoplamiento Clase 2: Usos, dependencias, especificaciones, MDDs (Diagrama de dependencia de módulos).

6.170 Repaso de la prueba. Desacoplamiento. Desacoplamiento Clase 2: Usos, dependencias, especificaciones, MDDs (Diagrama de dependencia de módulos). 6.170 Repaso de la prueba Clases: 1. Desacoplamiento. 2.. 3. Funciones de abstracción e invariantes de representación. 4. Abstracción de iteración e iteradores. 5. Modelos de objeto e invariantes. 6. Igualdad,

Más detalles

Nociones Básicas de Sémantica: Semántica Denotacional

Nociones Básicas de Sémantica: Semántica Denotacional Nociones Básicas de Sémantica: Semántica Denotacional Análisis de Lenguajes de Programación Mauro Jaskelioff 21/08/2015 Acerca de la Semántica Operacional En la semántica operacional el significado de

Más detalles

SIS 301 Operación y mantenimiento 15 minutos

SIS 301 Operación y mantenimiento 15 minutos SIS 301 Operación y mantenimiento 15 minutos O Generalidades 1 Planificación 2 Procedimientos 3 Responsabilidades del personal de operación 4 Responsabilidades del personal de mantenimiento 5 Mantenimiento

Más detalles

EXCEPCIONES EN JAVA. Las sentencias que tratan las excepciones son try y catch. La sintaxis es:

EXCEPCIONES EN JAVA. Las sentencias que tratan las excepciones son try y catch. La sintaxis es: EXCEPCIONES EN JAVA Uno de los problemas más importantes al escribir aplicaciones es el tratamiento de los errores. Errores no previstos que distorsionan la ejecución del programa. Las excepciones de Java

Más detalles

TEMA 2: DESARROLLO DEL SOFTWARE

TEMA 2: DESARROLLO DEL SOFTWARE TEMA 2: DESARROLLO DEL SOFTWARE EDI I Curso 2007/08 Escuela Politécnica Superior Universidad Autónoma de Madrid TEMA 2: DESARROLLO DEL SOFTWARE 2.1. Ciclo de vida del Software 2.2. Corrección de errores

Más detalles

LA TAXONOMÍA DE BLOOM Y EL PENSAMIENTO CRÍTICO

LA TAXONOMÍA DE BLOOM Y EL PENSAMIENTO CRÍTICO LA TAXONOMÍA DE BLOOM Y EL PENSAMIENTO CRÍTICO Extraído de Bárbara Fowler Especialista en Aprendizaje - Longview Community College Missouri, Estados Unidos LA TAXONOMÍA DE BLOOM Y EL PENSAMIENTO CRÍTICO

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Propiedad Colectiva del Código y Estándares de Codificación.

Propiedad Colectiva del Código y Estándares de Codificación. Propiedad Colectiva del Código y Estándares de Codificación. Carlos R. Becerra Castro. Ing. Civil Informática UTFSM. Introducción. n. En este trabajo se presentan específicamente dos prácticas de XP: Collective

Más detalles

Este es un ejemplo muy sencillo, un esquema de empleados que trabajan en proyectos, en una relación muchos a muchos.

Este es un ejemplo muy sencillo, un esquema de empleados que trabajan en proyectos, en una relación muchos a muchos. 28/04/2012 La teoría de la normalización va perdiendo peso con el paso de los años como herramienta de diseño de bases de datos relacionales en favor de modelos de datos más ricos en su representación,

Más detalles

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

Más detalles

Fundamentos de Ingeniería de Software

Fundamentos de Ingeniería de Software Fundamentos de Ingeniería de Software Marcello Visconti y Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María {visconti,hernan} at inf.utfsm.cl Fundamentos de Ingeniería

Más detalles

Optimización de consultas Resumen del capítulo 14

Optimización de consultas Resumen del capítulo 14 Optimización de consultas Resumen del capítulo 14 Libro: Fundamentos de Bases de Datos Silberschatz et al. 5ed. Dr. Víctor J. Sosa Agenda 1. Visión general 2. Estimación de las estadísticas de los resultados

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Programación Avanzada. Análisis Modelado del Dominio

Programación Avanzada. Análisis Modelado del Dominio Programación Avanzada Análisis Modelado del Dominio Contenido Introducción Modelo de Dominio Conceptos Asociaciones Atributos Generalizaciones Otros elementos Restricciones Programación Avanzada Análisis:

Más detalles

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008 INTRODUCCIÓN Estructura de Datos Tipos Abstractos de Datos (TAD S) Para poder obtener un programa que resuelva un problema dado, son necesarios varios pasos : La formulación y especificación del problema

Más detalles

Parte 1 Múltiple Opción

Parte 1 Múltiple Opción Cada pregunta de la parte múltiple opción contestada correctamente tiene un valor de 1,5 puntos. Cada pregunta incorrecta de la múltiple opción resta 0,5 puntos. Esta parte consta de 25 preguntas por lo

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Estructuras de Control - Diagrama de Flujo

Estructuras de Control - Diagrama de Flujo RESOLUCIÓN DE PROBLEMAS Y ALGORITMOS Ingeniería en Computación Ingeniería en Informática UNIVERSIDAD NACIONAL DE SAN LUIS DEPARTAMENTO DE INFORMÁTICA AÑO 2015 Índice 1. Programación estructurada 2 1.1.

Más detalles

GENERALIDADES DE BASES DE DATOS

GENERALIDADES DE BASES DE DATOS GENERALIDADES DE BASES DE DATOS A fin de evitar que idénticos datos se encuentren repetidos en múltiples archivos, parece necesario que los comunes se almacenen en un archivo único y que este archivo sea

Más detalles

Práctica de Evaluación de Cortafuegos personales

Práctica de Evaluación de Cortafuegos personales Práctica de Evaluación de Cortafuegos personales Objetivo El objetivo de esta práctica es que el alumno aprenda a configurar y evaluar cuál es la mejor opción de producto en relación a los cortafuegos

Más detalles

Gestión de Configuración del Software

Gestión de Configuración del Software Gestión de Configuración del Software Facultad de Informática, ciencias de la Comunicación y Técnicas Especiales Herramientas y Procesos de Software Gestión de Configuración de SW Cuando se construye software

Más detalles

A partir de este capítulo se introducen términos, probablemente nuevos para el

A partir de este capítulo se introducen términos, probablemente nuevos para el CAPITULO 3. PSP 0 Y PSP 0.1 A partir de este capítulo se introducen términos, probablemente nuevos para el lector que tienen que ver en su totalidad con PSP. También se dan a conocer los formatos, "scripts

Más detalles

Modulo 1 El lenguaje Java

Modulo 1 El lenguaje Java Modulo 1 El lenguaje Java 13 - Codificación en Java Una de las grandes diferencias entre Java y Pascal en cuando a la codificación es que Java se trata de un lenguaje de los llamados case sensitive Esto

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

Más detalles

Tema 1. Introducción a los TAD

Tema 1. Introducción a los TAD Tema 1. Introducción a los TAD Objetivos En este tema nos ocupamos inicialmente del concepto de abstracción, dedicando la mayor atención a la abstracción de datos, estudiando aspectos relacionados con

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Estructura de Datos [Tipos de datos concretos y tipos de datos abstractos]

Estructura de Datos [Tipos de datos concretos y tipos de datos abstractos] Estructura de Datos [Tipos de datos concretos y tipos de datos abstractos] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 14-O Sergio Luis Pérez (UAM CUAJIMALPA) Curso de Estructura

Más detalles

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación Sistemática de Layout, SLP por sus siglas en inglés. Se hará uso de la simulación para comparar el

Más detalles

6.4 ESTRATEGIAS DE PRUEBA

6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro

Más detalles

BETA. Sacándole Partido a JUnit. Mocking. www.iwt2.org formacion@iwt2.org

BETA. Sacándole Partido a JUnit. Mocking. www.iwt2.org formacion@iwt2.org BETA Sacándole Partido a JUnit Mocking www.iwt2.org formacion@iwt2.org 03. Mocking Aprender qué es el mocking y para qué sirve. Desarrollar el tipo de pruebas en las que es necesario un mock. Conocer librerías

Más detalles

TUTORIAL DE PHP. M. en C. Erika Vilches. Parte 2. http://www.erikavilches.com

TUTORIAL DE PHP. M. en C. Erika Vilches. Parte 2. http://www.erikavilches.com TUTORIAL DE PHP M. en C. Erika Vilches Parte 2 http://www.erikavilches.com Enunciados Condicionales Inicia con la palabra clave if seguida de una condición entre paréntesis $number = 5; if ($number < 10)

Más detalles

Diferenciabilidad. Definición 1 (Función diferenciable). Cálculo. Segundo parcial. Curso 2004-2005

Diferenciabilidad. Definición 1 (Función diferenciable). Cálculo. Segundo parcial. Curso 2004-2005 Univ. de Alcalá de Henares Ingeniería de Telecomunicación Cálculo. Segundo parcial. Curso 2004-2005 Diferenciabilidad. 1. Definición de función diferenciable Después del estudio de los ites de funciones

Más detalles

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos

Mejores prácticas para el éxito de un sistema de información. Uno de los problemas de información dentro de las empresas es contar con datos ANEXO VI. Mejores prácticas para el éxito de un sistema de información Uno de los problemas de información dentro de las empresas es contar con datos importantes del negocio y que éstos estén aislados

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Tema 3. Test Driven Development

Tema 3. Test Driven Development Tema 3. Test Driven Development Ejercicios Resueltos Ejercicio 01. Desarrolle mediante TDD una implementación del algoritmo de la Criba de Eratóstenes para calcular la lista de los números primos desde

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificación

Más detalles

(volver a Tabla de Contenidos)

(volver a Tabla de Contenidos) Para escribir, compilar y ejecutar un programa en Java lo único que realmente se necesita y no viene incluido con el sistema operativo es el kit de desarrollo de Java, denominado SDK (Software Development

Más detalles

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010 SSTQB Nivel Fundamentos Examen ejemplo Página 1 de 12 Fecha publicación: 28 - octubre - 2015 Índice Preguntas... 3 Respuestas... 12 Página 2 de 12 Fecha publicación: 28 - octubre - 2015 Preguntas 1 2 Una

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

www.fundibeq.org Además se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión.

www.fundibeq.org Además se recomienda su uso como herramienta de trabajo dentro de las actividades habituales de gestión. DIAGRAMA CAUSA EFECTO 1.- INTRODUCCIÓN Este documento describe el proceso de construcción de una de las herramientas más útiles para la ordenación de ideas, mediante el criterio de sus relaciones de causalidad,

Más detalles

Segmentación Recursiva de Proyectos Software para la Estimación del Esfuerzo de Desarrollo Software

Segmentación Recursiva de Proyectos Software para la Estimación del Esfuerzo de Desarrollo Software Segmentación Recursiva de Proyectos Software para la Estimación del Esfuerzo de Desarrollo Software J. Cuadrado Gallego 1, Miguel Ángel Sicilia 1, Miguel Garre Rubio 1 1 Dpto de Ciencias de la Computación,

Más detalles

IMPORTANCIA DEL ADMINISTRADOR FINANCIERO EN LA EMPRESA

IMPORTANCIA DEL ADMINISTRADOR FINANCIERO EN LA EMPRESA IMPORTANCIA DEL ADMINISTRADOR FINANCIERO EN LA EMPRESA Autor: Jesús Arturo Núñez Gamas Gestión financiera 20-11-2014 Resumen El administrador financiero de una empresa es un miembro cuya responsabilidad

Más detalles

Objetivo de aprendizaje del tema

Objetivo de aprendizaje del tema Computación II Tema 3. Identificadores, palabras clave y tipos de datos Objetivo de aprendizaje del tema Al finalizar el tema serás capaz de: Distinguir i entre modificadores d válidos y no válidos. Enumerar

Más detalles

Interacción y manejo de documentos XML.

Interacción y manejo de documentos XML. Interacción y manejo de documentos XML. Como último miembro de la familia XML, nos planteamos la tecnología por la cual una aplicación externa, escrita en no importa que lenguaje de programación, puede

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Ecuaciones de primer grado con dos incógnitas

Ecuaciones de primer grado con dos incógnitas Ecuaciones de primer grado con dos incógnitas Si decimos: "las edades de mis padres suman 120 años", podemos expresar esta frase algebraicamente de la siguiente forma: Entonces, Denominamos x a la edad

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Automatizador de Procesos

Automatizador de Procesos Automatizador de Procesos Más que un workflow, esta aplicación es un BPM (Business Process Management), una completa plataforma de automatización de procesos, diseñada para apoyar la transformación empresarial;

Más detalles

FACULTAD DE INGENIERÍA

FACULTAD DE INGENIERÍA NOMBRE DEL PROFESOR: Ing. Héctor Manuel Quej Cosgaya NOMBRE DE LA PRÁCTICA: Operadores y Expresiones PRÁCTICA NÚM. [ 3 ] LABORATORIO: MATERIA: UNIDAD: TIEMPO: Centro de Ingeniería Computacional Lenguaje

Más detalles

Tipos Abstractos de Datos y Diseño por Contrato

Tipos Abstractos de Datos y Diseño por Contrato Tipos Abstractos de Datos y Diseño por Contrato 1.- Motivación de los tipos abstractos de datos Nuestro objetivo es obtener descripciones apropiadas de los objetos, para lo cual se necesita un método que

Más detalles

5/10/2007 PCPM PRUEBAS DE SOFTWARE. Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL PCPM

5/10/2007 PCPM PRUEBAS DE SOFTWARE. Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL PCPM 1 PRUEBAS DE SOFTWARE Por: Paola Constanza Peña Melo Ingeniería de Software Mayo de 2007 AGENDA GENERAL 2 1 AGENDA 3 QUE SON LAS PRUEBAS DE SOFTWARE? Proceso de análisis de un sistema. Detectar diferencias.

Más detalles

Normalización. El diseño que hemos recibido está compuesto de estas dos relaciones:

Normalización. El diseño que hemos recibido está compuesto de estas dos relaciones: Normalización 1. Introducción Nuestro departamento de informática ha recibido el encargo de diseñar una base de datos para llevar el control de las piezas, proveedores y proyectos que realiza nuestra empresa.

Más detalles

Diseño orientado al flujo de datos

Diseño orientado al flujo de datos Diseño orientado al flujo de datos Recordemos que el diseño es una actividad que consta de una serie de pasos, en los que partiendo de la especificación del sistema (de los propios requerimientos), obtenemos

Más detalles

VERIFICACIÓN, TEST Y DEBUGGING

VERIFICACIÓN, TEST Y DEBUGGING ESTRUCTURAS DE DATOS Y ALGORITMOS TECNÓLOGO EN INFORMÁTICA VERIFICACIÓN, TEST Y DEBUGGING ESTRUCTURAS DE DATOS Y ALGORITMOS - TECNÓLOGO EN INFORMÁTICA 1 1. INTRODUCCIÓN Podemos decir que un programa funciona

Más detalles

Reporte inicial. Metodología

Reporte inicial. Metodología Reporte inicial Este reporte inicial expondrá las decisiones que tomamos al momento de selección de metodología, plantillas y métodos de recabado de evidencia y por qué tomamos dichas decisiones. Metodología

Más detalles

ANÁLISIS SEMÁNTICO. Especificación formal: Semántica Operacional, semántica denotacional, semántica Axiomática, Gramáticas con Atributos.

ANÁLISIS SEMÁNTICO. Especificación formal: Semántica Operacional, semántica denotacional, semántica Axiomática, Gramáticas con Atributos. ANÁLISIS SEMÁNTICO El análisis semántico dota de un significado coherente a lo que hemos hecho en el análisis sintáctico. El chequeo semántico se encarga de que los tipos que intervienen en las expresiones

Más detalles

Árboles AVL. Laboratorio de Programación II

Árboles AVL. Laboratorio de Programación II Árboles AVL Laboratorio de Programación II Definición Un árbol AVL es un árbol binario de búsqueda que cumple con la condición de que la diferencia entre las alturas de los subárboles de cada uno de sus

Más detalles

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra

Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra Hoy, la caja negra Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Niveles y Caja Negra Blanca A. Vargas Govea vargasgovea@itesm.mx Marzo 1, 2013 Contenido Tipos y niveles de

Más detalles

Este documento proporciona la secuencia de pasos necesarios para la construcción de un Diagrama de Flujo. www.fundibeq.org

Este documento proporciona la secuencia de pasos necesarios para la construcción de un Diagrama de Flujo. www.fundibeq.org DIAGRAMA DE FLUJO 1.- INTRODUCCIÓN Este documento proporciona la secuencia de pasos necesarios para la construcción de un Diagrama de Flujo. Muestra la importancia de dos aspectos clave en este proceso:

Más detalles

Pruebas de unidad con JUnit

Pruebas de unidad con JUnit Pruebas de unidad con JUnit Cuando se implementa software, resulta recomendable comprobar que el código que hemos escrito funciona correctamente. Para ello, implementamos pruebas que verifican que nuestro

Más detalles

PREPROCESADO DE DATOS PARA MINERIA DE DATOS

PREPROCESADO DE DATOS PARA MINERIA DE DATOS Ó 10.1007/978-3-319-02738-8-2. PREPROCESADO DE DATOS PARA MINERIA DE DATOS Miguel Cárdenas-Montes Frecuentemente las actividades de minería de datos suelen prestar poca atención a las actividades de procesado

Más detalles