RESUMEN LABORATORIO DE PROGRAMACIN PARCIAL 1 TEMA 1: PARADIGMAS DE PROGRAMACIN

Paradigma de programacin - Una forma - Un modelo - Describe estilos

Un paradigma de programacin es una propuesta tecnolgica adoptada por una comunidad de programadores que trata de resolver uno o varios problemas claramente delimitados. La resolucin de estos problemas debe suponer un avance significativo en al menos un parmetro que afecte a la ingeniera de software. Un paradigma de programacin es una coleccin de modelos conceptuales que juntos modelan el proceso de diseo y determinan, al final, la estructura de un programa. Tipos de paradigmas: Imperativo (estructurado): C / Basic Orientado a Objetos: Smalltalk, java, C++ Lgico: Prolog Funcional: Scheme o Haskell Otros

Cada paradigma cuenta con: Una forma de analizar el problema Una forma de disear la solucin. o o Herramientas Modelos

IDEs (Entorno Integrado de Desarrollo). Mtricas. Forma de Documentar. Un LENGUAJE adecuado

Programacin estructurada
La programacin estructurada se basa en una metodologa de desarrollo de programas llamada refinamientos sucesivos: Se plantea una operacin como un todo y se divide en segmentos ms sencillos o de menor complejidad. Una vez terminado todos los segmentos del programa, se procede a unificar las aplicaciones realizadas por el pool de programadores. La programacin estructurada propone segregar los procesos en estructuras lo ms simple posibles, las cuales se conocen como secuencia, seleccin e interaccin. Combinando esquemas sencillos se pueden llegar a construir sistemas amplios y complejos pero de fcil entendimiento. Demuestra que todo programa puede escribirse utilizando nicamente las tres estructuras bsicas de control siguientes: Secuencia: instrucciones ejecutadas sucesivamente, una detrs de otra. Seleccin: bifurcacin condicional de una o ms operaciones. La instruccin condicional con doble alternativa, de la forma "if condicin then instruccin 1, else instruccin 2". Iteracin: el bucle condicional "while condicin do instruccin", ejecuta la instruccin repetidamente mientras la condicin se cumpla. Esta tcnica de programacin conlleva las siguientes ventajas: a) El coste de resolver varios subproblemas de forma aislada es con frecuencia menor que el de abordar el problema global. b) Facilita el trabajo simultneo en paralelo de distintos grupos de programadores. c) Posibilita en mayor grado la reutilizacin del cdigo en futuras aplicaciones.

PARADIGMA IMPERATIVO (filmina) Serie de instrucciones

La orientacin es hacia los estados. Elementos: abstraccin procedimental, asignacin, ciclos, Un cmputo se expresa mediante modificaciones implcitas a la memoria. Las variables sirven como abstraccin de celdas de memoria. Los resultados intermedios se almacenan en memoria. El control se basa en la iteracin.

result := 1; while n > 0 do result := result * m; n := n-1; end while

Caractersticas del paradigma imperativo: EFECTOS LATERALES: La existencia de estos efectos por una aparte, hacen que los programas no sean seguros puesto que cualquier posicin de memoria puede ser actualizada de forma no adecuada, y otra parte, el concepto de una nica memoria global actualizada de forma repetida por las instrucciones del programa dificulta la portabilidad y reusabilidad de cdigo. LIMITACION de APLICACIN: Su operativa se ajusta nicamente a aquellos problemas de naturaleza algortmica clsica, similares en ejecucin al de los clculos matemticos que no abordan con solvencia muchos problemas interesantes para resolver con la computadora. CELDA DE MEMORIA ("variable") para almacenar valores. El componente principal de la arquitectura es la memoria, compuesto por un gran nmero de celdas donde se almacenan los datos. Las celdas tienen nombre (concepto de variable) que las referencian, y sobre los que se producen efectos de lado y definiciones de alias. OPERACIONES DE ASIGNACIN: Estrechamente ligado a la arquitectura de la memoria, se encuentra la idea de que cada valor calculado debe ser "almacenado", es decir asignado a una celda. Esta es la razn de la importancia de la sentencia de asignacin en el paradigma imperativo. REPETICIN: Un programa imperativo, normalmente realiza su tarea ejecutando repetidamente una secuencia de pasos elementales, ya que en este modelo computacional la nica forma de ejecutar algo complejo es repitiendo una secuencia de instrucciones.

Lenguajes usados para programacin estructurada: COBOL, BASIC, C, PASCAL

Programacin Lgica (programacin declarativa) La programacin lgica, junto con la funcional, forma parte de lo que se conoce como programacin declarativa. La ecuacin de Robert Kowalski establece la idea esencial de la programacin lgica: algoritmos = lgica + control. Es decir, un algoritmo se construye especificando conocimiento en un lenguaje formal (lgica de primer orden), y el problema se resuelve mediante un mecanismo de inferencia (control) que acta sobre aqul. El lenguaje Prolog es el representante principal de este paradigma. Prolog cuenta con dos tipos de estructuras: trminos y sentencias. Los trminos pueden ser constantes, variables o functores: Constantes, representadas por una cadena de caracteres, pueden ser nmeros o cualquier cadena que comience en minscula. Variables, son cadenas que comienzan con una letra mayscula. Los functores, son identificadores que empiezan con minscula, seguidos de una lista de parmetros (trminos) entre parntesis, separados por comas.

Las sentencias son reglas o clusulas. Hay hechos y consultas. Un hecho establece una relacin entre objetos, y es la forma ms sencilla de sentencia. Una regla permite definir nuevas relaciones a partir de otras ya existentes.

PARADIGMA LOGICO (filmina)

Cmputo se expresa mediante la bsqueda de pruebas o por definicin de predicados recursivos y anidados. No hay memoria implcita Los resultados intermedios se pasan mediante unificacin. Control basado en recursin.

pot(M,0,1). pot(M,N,R) :- resta(N,1,N1), pot(M,N1,RT), prod(M,RT,R).

Caractersticas del paradigma lgico: Construidos nicamente por expresiones lgicas, puede tener un solo valor de verdad verdadero o falso. El orden de ejecucin de las instrucciones no tiene nada que ver con el orden en que fueron escritas, a diferencia de los lenguajes imperativos y funcionales como Lisp, en todos los mencionados, las instrucciones se ejecutan normalmente en orden secuencial. PROCESO DE INFERENCIA: Un lenguaje lgico usa dos tipos de elementos para inferir. Estos son: Hechos y reglas de inferencia, los dos son definidos en el programa lgico por el usuario. CAPACIDAD DE LOS LENGUAJES LGICOS: Un lenguaje lgico, como puede ser Prolog, permite contestar preguntas con respuestas S, No, o con elementos que satisfagan condiciones. UN LENGUAJE LGICO TIENE HECHOS, REGLAS DE INFERENCIA Y VARIABLES. Los hechos y reglas de inferencia se componen en general de proposiciones o predicados. Los predicados no se combinan de cualquier manera, sino que lo hacen como clausulas de Horn. Estas son un conjunto de predicados unidos por operadores lgicos OR, AND (o, y) que implican un solo predicado no negado.

Programacin Funcional Coleccin de funciones que se combinan mediante composicin de forma compleja para construir nuevas funciones. Un programa es declarativo: no importa el cmo sino el qu. La orientacin es hacia la evaluacin. Elementos de programacin: composicin, orden superior, recursin. Lenguajes: Impuros y estrictos. Puros y Perezosos. Un cmputo se expresa a travs de la aplicacin y composicin de funciones. No hay memoria implcita Los resultados intermedios se pasan directamente a otras funciones. Control basado en recursin.

pot m 0 = 1 pot m (n+1) = m * (pot m n)

Todo programa es visto como una funcin Las subrutinas tambin toman la forma de una funcin. Finalmente se ve toma la aplicacin como una composicin de funciones. Principales Lenguajes: LISP, HASKELL

Como se realiza el cmputo en el lenguaje funcional El Cmputo en el lenguaje Funcional se realiza por medio de funciones aritmticas que no maneja datos mutables o de estado. La diferencia con la programacin imperativa es que las funciones imperativas pueden tener efectos secundarios, al cambiar el valor de clculos realizados previamente. Por esta razn carecen de transparencia referencial, es decir, la misma expresin lingstica puede resultar en valores diferentes en diferentes momentos dependiendo del estado del programa siendo ejecutado. Con cdigo funcional, en contraste, el valor generado por una funcin depende exclusivamente de los argumentos alimentados a la funcin. Al eliminar los efectos secundarios se puede entender y predecir el comportamiento de un programa mucho ms fcilmente, y esta es una de las principales motivaciones para utilizar la programacin funcional. Los programas escritos en un lenguaje funcional estn constituidos nicamente por definiciones de funciones entendiendo stas como funciones puramente matemticas, en las que se verifican ciertas propiedades como la transparencia referencial y por tanto, la carencia total de efectos laterales.

Caractersticas de la programacin funcional Los programas escritos en un lenguaje funcional estn constituidos nicamente por definiciones de funciones, puramente matemticas. Posee transparencia referencial y carece de efectos laterales, esto quiere decir que no modifica el estado de su entorno y que una expresin puede ser reemplazada por su valor; esto requiere que la expresin no tenga efecto colateral y que sea pura, o sea, que siempre retorne el mismo resultado con la misma entrada. Inexistencia de asignaciones de variables y falta de construcciones estructuradas como la secuencia o la iteracin Permite definiciones simples. Facilita el estudio de aspectos computacionales. Su carcter formal facilita la demostracin de propiedades.

Programacin Orientada a objetos Coleccin de objetos que interactan intercambiando mensajes que transforman estados. Elementos de programacin: modelado de objetos, clases, herencia, encapsulamiento. Un cmputo se expresa mediante intercambio de mensajes entre objetos. Los objetos se agrupan en clases, las cuales se agrupan en jerarquas. Los resultados se pasan como parmetros a mensajes.

Lenguajes usados para programacin orientada a objetos: C++, VB.NET, JAVA, SMALLTALK, ADA Caractersticas de la programacin orientada a objetos ABSTRACCIN: Extraer las propiedades esenciales de un objeto que lo distinguen de los dems tipos de objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador. Es la capacidad para encapsular y aislar la informacin de diseo y ejecucin. ENCAPSULAMIENTO: Es el proceso de almacenar en un mismo compartimiento (una caja negra) los elementos de una abstraccin (toda la informacin relacionada con un objeto) que constituyen su estructura y su comportamiento. Esta informacin permanece oculta tanto para los usuarios como para otros objetos y puede ser accedida solo mediante la ejecucin de los mtodos adecuados. HERENCIA: Es la propiedad que permite a los objetos construirse a partir de otros objetos. La clase base contiene todas las caractersticas comunes. Las sub-clases contienen las caractersticas de la clase base ms las caractersticas particulares de la sub-clase. Si la sub-clase hereda caractersticas de una clase base, se trata de herencia simple. Si hereda de dos o ms clases base, herencia mltiple. POLIMORFISMO: Literalmente significa "cualidad de tener ms de una forma". En poo, se refiere al hecho que una misma operacin puede tener diferente comportamiento en diferentes objetos. En otras palabras, diferentes objetos reaccionan al mismo mensaje de modo diferente.

LENGUAJE DE PROGRAMACIN Un lenguaje de programacin" es un lenguaje diseado para describir el conjunto de acciones consecutivas que un equipo debe ejecutar. Por lo tanto, un lenguaje de programacin es un modo prctico para que los seres humanos puedan dar instrucciones a un equipo. El lenguaje utilizado por el procesador se denomina lenguaje mquina. Se trata de datos tal como llegan al procesador, que consisten en una serie de 0 y 1 (datos binarios). El lenguaje mquina, por lo tanto, no es comprensible para los seres humanos, razn por la cual se han desarrollado lenguajes intermediarios comprensibles para el hombre. El cdigo escrito en este tipo de lenguaje se transforma en cdigo mquina para que el procesador pueda procesarlo. El ensamblador fue el primer lenguaje de programacin utilizado. Es muy similar al lenguaje mquina, pero los desarrolladores pueden comprenderlo. No obstante, este lenguaje se parece tanto al lenguaje mquina que depende estrictamente del tipo de procesador utilizado (cada tipo de procesador puede tener su propio lenguaje mquina). As, un programa desarrollado para un equipo no puede ser portado a otro tipo de equipo. El trmino "portabilidad" describe la capacidad de usar un programa de software en diferentes tipos de equipos. Para poder utilizar un programa de software escrito en un cdigo ensamblador en otro tipo de equipo, a veces ser necesario volver a escribir todo el programa. La ejecucin de un programa con compilador requiere de dos etapas: 1) Traducir el programa simblico a cdigo mquina 2) Ejecucin y procesamiento de los datos. Otros lenguajes de programacin utilizan un programa intrprete o traductor, el cual analiza directamente la descripcin simblica del programa fuente y realiza las instrucciones dadas. El intrprete en los lenguajes de programacin simula una mquina virtual, donde el lenguaje de mquina es similar al lenguaje fuente.

La ventaja del proceso interprete es que no necesita de dos fases para ejecutar el programa, sin embargo su inconveniente es que la velocidad de ejecucin es ms lenta ya que debe analizar e interpretar las instrucciones contenidas en el programa fuente. Por lo tanto, un lenguaje de programacin tiene varias ventajas: * es mucho ms fcil de comprender que un lenguaje mquina. * permite mayor portabilidad, es decir que puede adaptarse fcilmente para ejecutarse en diferentes tipos de equipos.

Principales formas de control en programacin lgica, orientada a objetos y secuencial (imperativa) Secuenciales: instrucciones secuenciales, bifurcacin condicional if y la iteracin - while Objetos: paso de mensajes entre objetos Lgica: Hechos y reglas.

Sintaxis de un lenguaje Un programa en cualquier lenguaje se puede concebir como un string de caracteres escogidos de algn conjunto o alfabeto de caracteres. Las reglas que determinan si un string es un programa vlido o no, constituyen la sintaxis de un lenguaje. Sintaxis: descripcin del conjunto de cadenas de smbolos que seran considerados programas vlidos. Semntica de un lenguaje Las reglas que determina el significado de los programas constituyen la semntica de los lenguajes de programacin. Un lenguaje de mquina tiene su semntica definida por el computador. Un programa en lenguaje de mquina "significa" exactamente lo que el computador hace cuando el programa "corre" o se ejecuta. Sin embargo, con un lenguaje de alto nivel no se puede dejar que el computador defina la semntica del lenguaje, puesto que no es posible "correr programas y ver" hasta que se tenga un compilador. No se puede tener un compilador y saber qu es correcto hasta haber definido lo que los programas significan. Este enfoque interpretativo para definir la semntica de los lenguajes de programacin consiste en postular una mquina abstracta y proveer reglas para la ejecucin de programas sobre esta mquina abstracta. As, estas reglas definen el significado de los programas. Usualmente, la mquina abstracta se caracteriza por un estado consistente de todos los objetos datos, sus valores, y los programas con sus contadores de programa. Las reglas semnticas especifican cmo el estado es transformado por las diversas construcciones de los lenguajes de programacin. Semntica: descripcin del significado de instrucciones y expresiones del lenguaje.

QUE ASPECTOS SE TIENEN EN CUENTA PARA ELEGIR UN PARADIGMA DE PROGRAMACION Los aspectos que hay que tener en cuenta son inherentes al problema o producto especfico que debamos responder. Depende de distintos factores como lo es el tipo de programa que queremos realizar, la plataforma para la cual queremos que sirvan nuestros programas, incluso siendo poco objetivos tambin entra el gusto por un lenguaje en especifico o por la compaa detrs del lenguaje. Hay lenguajes que fueron pensados para resolver problemas ms especficos, y que tienen en teora un uso ms acotado. Ejemplo de esto es el lenguaje MATLAB, que tiene un soporte especfico en las operaciones de vectores y matrices que son fundamentales para la ingeniera y los problemas cientficos. Por otro lado, lenguajes de alto nivel como C le aseguran al programador una respuesta ms rpida para el proceso de informacin que el lenguaje JAVA, pero la portabilidad que ofrece JAVA supera las posibilidades multiplataforma de C, ya que con slo tener la mquina virtual de java instalada en el sistema el mismo programa va a correr sin problemas, mientras que C necesita estar compilado para cada SO. Bsicamente hay que plantear las caractersticas del producto y analizar el tipo de desarrollo que se va a llevar a cabo.

EJEMPLOS ASe necesita un programa que obtenga las races de una ecuacin de segundo grado. Por ejemplo:

Paradigma: Estructurado Lenguaje de programacin: C Plataforma: SO Linux.

Caractersticas computadora: PC, SEMPRON 140 2.7 GHz

B-

Almacene las fichas de inscripcin de los socios de un club.

Paradigma: Orientada a Objetos Lenguaje: PHP, porque sirve para la realizacin de sitios web dinmicos Base de datos: Mysql CUn programa que juegue a las damas

Paradigma: Lgico Lenguaje: Prolog Caractersticas computador: PC, SEMPRON 140 2.7 GHz

D- Un programa que multiplique matrices

Paradigma: Imperativo Lenguaje: C EMantener la historia clnica de pacientes de un hospital

Paradigma: Orientado a Objetos Lenguaje: Java Computadora: PC, AMD SEMPRON 140. SO: Linux Base de datos: MYSQL. Servidor: Intel XEON SO: SUSE Linux Enterprise Server

F- Un cliente nos solicita un programa para la carga de informacin, donde sus clientes llenarn una ficha para actualizar sus
datos (domicilio, datos filiatorios, gustos sobre los productos que consume, etc). Cantidad de clientes: 1262. Paradigma de programacin: Orientado a Objetos Lenguaje propuesto: Java Base de datos: MySql. Necesitamos la base de datos para almacenar la informacin y en el caso que el cliente tenga ms de una computadora para registrar la informacin esto no nos limite.

G-

Un gelogo nos solicita un programa que debe invertir una matriz que l mismo nos provee a travs de un fichero de texto. Actualmente realiza esta operacin utilizando una planilla de clculos, pero el proceso demora demasiado tiempo. El resultado servir como entrada a otra aplicacin. Cantidad aproximada de elementos de la matriz: 55000.

Lenguaje de programacin: C Paradigma: Estructurado

H-

Un ingeniero estudia la transferencia de calor sobre una placa metlica. Este proceso implica la resolucin de un sistema de ecuaciones lineales de grandes dimensiones. Por otro lado, el ingeniero quiere ver los resultados de la distribucin del calor en forma grfica sobre un dibujo coloreado.

Paradigma estructurado Se propone para resolver este problema MATLAB porque esta aplicacin est orientada al clculo cientfico tcnico y permite resolver numerosos problemas aplicados y mostrar los resultados grficamente con poco esfuerzo de programacin, por lo que es un estndar en el desarrollo de aplicaciones de clculo en ingeniera. Est disponible para las plataformas Unix, Windows y Apple Mac OS X

TEMA 2: FICHERO O ARCHIVO DE DATOS

Definicin de FICHERO Un archivo o fichero informtico es un conjunto de bits almacenado en un dispositivo. Un archivo es identificado por un nombre y la descripcin de la carpeta o directorio que lo contiene. Es una manera de organizar los recursos usados para almacenar permanentemente datos en un sistema informtico. Un fichero es un conjunto de datos estructurados que pueden estar almacenados en un soporte de datos de forma que puedan ser tratados o utilizados de forma individual o global. Cada fichero se tiene que identificar con un nombre. Los elementos que forman un fichero se llaman registros y dichos registros se definen como la unidad mnima de informacin completa de un fichero. CARACTERSTICAS DE LOS ARCHIVOS Independencia de la informacin respecto de los programas La informacin almacenada es permanente Un archivo puede ser accedido por distintos programas en distintos momentos o al mismo tiempo Gran capacidad de almacenamiento.

CLASIFICACION DE LOS ARCHIVOS Permanentes o Maestros: Estos contienen informacin que varia poco. En algunos casos es preciso actualizarlos peridicamente. De Movimientos: Se acercan para actualizar los archivos maestros. Sus registros son de tres tipos: alta, bajas y modificaciones. De Maniobra o Trabajo: Tienen una vida limitada, normalmente menor que la duracin de la ejecucin de un programa. Su utilizan como auxiliares de los anteriores.

SEGN SU FUNCION. a. Archivos Permanentes: Son aquellos cuyo registros sufren pocas o ninguna variacin a lo largo del tiempo, se dividen en: Constantes: Estn formados por registros que contienen campos fijos y campos de baja frecuencia de variacin en el tiempo. De Situacin: Son los que en cada momento contienen informacin actualizada. Histricos: Contienen informacin acumulada a lo largo del tiempo de archivos que han sufridos procesos de actualizacin o bien acumulan datos de variacin peridica en el tiempo. Ejemplo: Fichero que guarda los movimientos que se produjeron en las cuentas de un banco en 1.991. Almacena datos del usuario de un banco (nombre, apellido, dni, nmero de cuenta, registros de la cuenta del cliente, transacciones, operaciones realizadas extracciones, depsitos etc.) Accede a esos datos a travs de un servidor, tanto el cliente de un banco como sus empleados. Archivos de Movimiento: Son aquellos que se utilizan conjuntamente con los maestros (constantes), y contienen algn campo comn en sus registros con aquellos, para el procesamiento de las modificaciones experimentados por los mismos. Archivo de Maniobra o Transitorio: Son los archivos creados auxiliares creados durante la ejecucin del programa y borrados habitualmente al terminar el mismo.

b. c.

SEGN SUS ELEMENTOS. a. b. c. Archivo de Entrada: Una coleccin de datos localizados en un dispositivo de entrada. Archivo de Salida: Una coleccin de informacin visualizada por la computadora. Constantes: estn formados por registros que contienen campos fijos y campos de baja frecuencia de variacin en el tiempo.

Fichero Maestro Contienen informaciones que estn variando con frecuencia y es necesario mantener al da permanentemente. La frecuencia de actualizacin o puesta al da de estos ficheros es elevada. Ejemplo: Fichero que contiene informacin del estado de las cuentas de los clientes de un banco. Ejemplo: Inventario de una biblioteca. Almacena datos de socios (nombre y apellido, dni, direccin, nmero de socio, telfono, email, fecha de egreso, fecha de devolucin), datos de libros (ttulo, nmero, gnero, autor, editorial). Estos datos son accedidos por el bibliotecario a travs de una base de datos.

Fichero de Maniobra Son ficheros auxiliares creados durante la ejecucin de programas o aplicaciones. El fin de estos ficheros es el de obtener cierta informacin que posteriormente ser procesada para conseguir unos resultados esperados o calculados. Su perodo de vida es an ms corto que el de los ficheros de movimiento o transicin, pues son destruidos antes de que el programa o la aplicacin correspondiente finalicen su ejecucin y el usuario no puede verlos. Por ejemplo un fichero auxiliar que contiene la clasificacin de un fichero de inventario para hacer un listado estadstico anual. Finalizado el proceso de listado, es destruido. Se utilizan para almacenar provisionalmente resultados intermedios que sern utilizados posteriormente en el mismo proceso, o en un proceso diferente. La vida de estos ficheros termina en el momento en que finaliza, el proceso para el que fueron creados. Ejemplo: Tratamiento fotogrfico de una imagen. Almacena modificaciones sobre la imagen original, ya sea cambios de colores, transparencias, recortes, redimensiones, etc. Accede a esos datos Photoshop por ejemplo. Medio de almacenamientos Datos de una matriz con nmeros flotantes: Archivo de texto plano Una planilla de alumnos conteniendo nombre y documento: Base de datos, archivo delimitado Una planilla de artculos conteniendo nombre, precio, nombre del proveedor, nivel de stock: Planilla de clculos Datos que genera nuestro programa para que otro usuario en Internet los utilice: Socket Las temperaturas promedio de toda la semana: Archivo de texto plano, archivo delimitado Las temperaturas promedio del mes para cada uno de los departamentos de la provincia: Archivo de texto plano, archivo delimitado La ficha de clientes de nuestra empresa: nombre, nombres de los hijos, antigedad, cargo: Base de datos, archivo delimitado Datos generados por nuestro programa, pero que van a ser explotados por un segundo programa: Socket Acceso a los archivos Se refiere al mtodo utilizado para acceder a los registros de un archivo prescindiendo de su organizacin. Acceso secuencial: La forma ms simple de estructura de archivo es el archivo secuencial. En este tipo de archivo, los registros se sitan fsicamente en el dispositivo en el orden en el que se van escribiendo, uno tras otro y sin dejar huecos entre s. El acceso a los registros tambin debe hacerse en orden, de modo que para acceder al registro N es necesario pasar primero por el registro 1, luego por el 2, luego por el 3, y as hasta llegar al registro N. Si el programa necesita acceder a registros individuales y no consecutivos, el acceso secuencial ofrece un rendimiento pobre y es preferible el acceso directo, que luego veremos. Los archivos secuenciales (sobreentindase archivos de acceso secuencial) tienen un indicador de posicin (o cursor) que seala qu registro fue el ltimo que se accedi. Al abrir el archivo, el indicador se sita en el primer campo del primer registro. Cada acceso sobre el archivo desplazar el indicador de posicin hacia el siguiente registro, hasta que ya no haya ms registros que leer. Cuando un archivo secuencial se abre para escribir datos en l, el indicador de posicin se sita justo despus del ltimo byte del mismo, de manera que los datos slo se pueden aadir al final. La organizacin secuencial cuenta con varias ventajas: Es la ms sencilla de manejar para el programador. Si hay que acceder a un conjunto de registros consecutivos, o a todo el archivo, es el mtodo ms rpido. No deja espacios entre registro y registro, por lo que se optimiza el uso del espacio en la memoria secundaria.

Pero tambin tiene algunos inconvenientes serios, como: Para consultar datos individuales, hay que recorrer todo el archivo desde el principio. Es decir, el acceso a registros individuales es, en general, lento.

Las operaciones de insercin y eliminacin de registros solo pueden hacerse al final del archivo. Hacerlas con registros intermedios representa mover grandes bloques de informacin y, por lo tanto, consumir mucho tiempo.

Cantidad de bsquedas = N Acceso directo o relativo: Explotan la capacidad de los discos para acceder directamente a cualquier bloque de direccin conocida. Como en los archivos secuenciales y secuenciales indexados, se requiere un campo clave en cada registro. Sin embargo, aqu no hay concepto de ordenamiento secuencial. Cuando uno de los archivos contiene un nmero reducido de lneas resulta ms eficiente emplear archivos de acceso directo, porque permiten reunir la informacin sin tener que visitar el archivo completo. Un archivo se accesa directamente cuando el programa que lo utiliza especifica directamente la posicin dentro del archivo que se accesar. Por ejemplo el programa puede leer la lnea nmero 200, luego la lnea 50000 y ms tarde la lnea 1. En un archivo relativo existe una relacin predecible entre la llave usada para identificar un registro y su localizacin dentro del archivo. Sin embargo es importante comprender que el ordenamiento lgico de los registros no necesita tener ninguna relacin con su secuencia fsica. Los registros no necesariamente aparecen fsicamente ordenados de acuerdo al valor de sus llaves. Cada registro puede leerse / escribirse de forma directa solo con expresar su direccin en el fichero por l numero relativo del registro o por transformaciones de la clave de registro en l numero relativo del registro a acceder. Acceso por ndice: El archivo secuencial indexado mantiene las caractersticas bsicas de los archivos secuenciales: los registros estn organizados en una secuencia basada en un campo. Dos caractersticas se aaden: un ndice del archivo para soportar los accesos aleatorios y un archivo de desbordamiento (overflow). El ndice provee una capacidad de bsqueda para llegar rpidamente a las proximidades de un registro deseado. El archivo de desbordamiento (overflow) es similar al archivo de registro usado en un archivo secuencial, pero est integrado de forma que los registros del archivo de desbordamiento se ubican en la direccin de un puntero desde el registro precedente. En la estructura secuencial indexada ms simple, se usa un solo nivel de indexacin. El ndice, en este caso, es un archivo secuencial simple. Cada registro del archivo ndice tiene dos campos: un campo clave, que es el mismo que el campo clave del archivo principal y un puntero al archivo principal. Para encontrar un campo especfico se busca en el ndice hasta encontrar el valor mayor de la clave que es igual o precede al valor deseado de la clave. La bsqueda contina en el archivo principal a partir de la posicin indicada por el puntero. Acceso dinmico: es cuando se accede a un archivo de cualquiera de las formas descriptas, acceso secuencial, directo o indexado. BUSQUEDA BINARIA Es necesario poder hacer bsquedas de registros en los archivos, siguiendo algn criterio o patrn. Cuando hacemos una bsqueda de algn registro, sta se hace principalmente a travs de las llaves primarias. Como se mencion en la seccin 5.4 se pueden realizar bsquedas secuenciales o de acceso directo. Las bsquedas secuenciales son demasiado lentas ya que tienen que recorrer todo o casi todo el archivo; an cuando se encuentre algn resultado podramos saber de antemano que existe la posibilidad de encontrar ms registros que cumplan con el criterio de bsqueda, de ah que se deba continuar recorriendo todo el archivo. Por otro lado las bsquedas por acceso directo son extremadamente rpidas, ya que podemos ir al "offset" deseado dentro del archivo, desafortunadamente esto requiere un mtodo o frmula para saber ubicar donde se encuentra un registro en el archivo. De manera que si buscamos el registro de la persona con ID 35 sabremos que es el registro 35 del archivo y solo habra que multiplicarlo por su longitud (para el caso de registros de longitud fija) para obtener el desplazamiento que debemos hacer para leer del disco dicho registro. Pero desafortunadamente este "mtodo" no es muy adecuado en todos lo casos ya que no hay muchas maneras de garantizar que cada registro tendr una posicin nica. Ej. Si queremos hacer bsquedas de registros que no tienen nmeros y solo texto (nombre, direccin, ciudad), la manera de relacionarlos con el lugar que ocupan en disco puede volverse demasiado complicado, aunque sigue siendo una opcin.

Por otro lado cuando se habla de bsquedas en memoria primaria, donde los accesos son mucho ms rapidos, se han desarrollado algoritmos que garantizan el encontrar registros gilmente. Tal es el caso de la Bsqueda Binaria cuyo tiempo de bsqueda es de O(log2 n). El algoritmo de Bsqueda Binaria se basa en la metodologa "divide y vencers", de manera que dado un arreglo de registros "ordenados" podemos buscar rpidamente alguno partiendo el arreglo a la mitad y viendo en que mitad podra estar dicho registro, y a su vez esa mitad es dividida en 2 y as sucesivamente hasta encontrar el registro. Para el caso de un archivo este algoritmo sera de gran utilidad: Si por ejemplo tenemos un archivo de 2000 registros y quisiramos hacer una bsqueda secuencial, sta nos tomara en promedio: Para una bsqueda secuencial 1/2 n = 1000 comparaciones Para una bsqueda binaria 1 + log2 2000 = 11 comparaciones A simple vista luce mucho ms atractiva la bsqueda binaria, pero hay un "precio" que pagar, el tener que ordenar el archivo. Nota: recordemos que no es lo mismo ordenar un arreglo en memoria, que un conjunto de registros en disco, lo segundo es considerablemente ms lento. Diferencia entre planilla de clculos y base de datos Ejemplos: aplicacin administrativa y aplicacin financiera. Si bien el concepto es bsicamente el mismo, la organizacin de datos en tablas y campos, ambas aplicaciones podran almacenar sus datos tanto en una planilla de clculo como en una base de datos sta ltima ofrece mayores ventajas. En las hojas de clculo te permiten ingresar datos, manejarlos y hacer que ella misma realice clculos mediante un software especifico, mientras que las bases de datos por lo general utilizan un intrprete o motor de bases de datos que permite a otros lenguajes acceder a ellas mediante instrucciones como SQL y poder interactuar con ellas de forma externa. En una base de datos es mucho ms sencillo encontrar la informacin. Puede preguntar a la base de datos (por ejemplo, cuntas personas han aceptado venir a mi evento o qu cliente compr qu producto) y obtener una respuesta inmediatamente. Las bases de datos no slo almacenan informacin, tambin solucionan problemas, responden a preguntas y toman decisiones. Puede crear frmulas y clculos para analizar la informacin y, de esta forma, crear informes rpidos que mejorarn la forma de compartir sus opiniones. Otra ventaja de las bases de datos es la impresin flexible. Las bases de datos permiten crear de manera ms sencilla etiquetas de correo, informes, facturas, identificaciones para eventos y formularios de entrada de datos. La base de datos a diferencia de la planilla de clculo permite trabajar a multiusuarios permitiendo proveer servicio y procesamiento a mltiples usuarios simultneamente. Ventajas de una base de datos frente a una planilla de clculos - Independencia lgica y fsica de los datos. - Redundancia mnima. - Acceso concurrente por parte de mltiples usuarios. - Integridad de los datos. - Consultas complejas optimizadas. - Seguridad de acceso y auditoria. - Respaldo y recuperacin. - Acceso a travs de lenguajes de programacin estndar. Control sobre la redundancia de datos:

Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, adems de provocar la falta de consistencia de datos. En los sistemas de bases de datos todos estos ficheros estn integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos. Consistencia de datos:

10

Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato est almacenado una sola vez, cualquier actualizacin se debe realizar slo una vez, y est disponible para todos los usuarios inmediatamente. Si un dato est duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes. Comparticin de datos:

En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estn autorizados. Mantenimiento de estndares:

Gracias a la integracin es ms fcil respetar los estndares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estndares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estndares de documentacin, procedimientos de actualizacin y tambin reglas de acceso. Mejora en la integridad de datos:

La integridad de la base de datos se refiere a la validez y la consistencia de los datos almacenados. Normalmente, la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD (sistema de gestin de base de datos) quien se debe encargar de mantenerlas. Mejora en la seguridad:

La seguridad de la base de datos es la proteccin de la base de datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integracin de datos en los sistemas de bases de datos hace que stos sean ms vulnerables que en los sistemas de ficheros. Mejora en la accesibilidad a los datos:

Muchos SGBD proporcionan lenguajes de consultas o generadores de informes que permiten al usuario hacer cualquier tipo de consulta sobre los datos, sin que sea necesario que un programador escriba una aplicacin que realice tal tarea. Mejora en la productividad:

El SGBD proporciona muchas de las funciones estndar que el programador necesita escribir en un sistema de ficheros. A nivel bsico, el SGBD proporciona todas las rutinas de manejo de ficheros tpicas de los programas de aplicacin. El hecho de disponer de estas funciones permite al programador centrarse mejor en la funcin especfica requerida por los usuarios, sin tener que preocuparse de los detalles de implementacin de bajo nivel. Mejora en el mantenimiento:

En los sistemas de ficheros, las descripciones de los datos se encuentran inmersas en los programas de aplicacin que los manejan. Esto hace que los programas sean dependientes de los datos, de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en disco, requiere cambios importantes en los programas cuyos datos se ven afectados. Sin embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo que se conoce como independencia de datos, gracias a la cual se simplifica el mantenimiento de las aplicaciones que acceden a la base de datos. Aumento de la concurrencia:

En algunos sistemas de ficheros, si hay varios usuarios que pueden acceder simultneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de modo que se pierda informacin o se pierda la integridad. La mayora de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que no ocurran problemas de este tipo. Mejora en los servicios de copias de seguridad:

Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen que hacer copias de seguridad cada da, y si se produce algn fallo, utilizar estas copias para restaurarlos. En este caso, todo el trabajo realizado sobre los datos desde que se hizo la ltima copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando se produce un fallo.

11

TEMA 3: SOFTWARE FACTORY

Software factory: Es una empresa que hace anlisis y desarrollo de aplicaciones en mltiples plataformas tecnolgicas. Outsourcing de software: es el proceso en el cual una firma identifica una porcin de su proceso de negocio que podra ser desempeada ms eficientemente por otra corporacin, la cual es contratada para desarrollar esa porcin de negocio. Arquitectura de mltiples capas: la arquitectura cliente/servidor tiene 2 tipos de nodos en la red: cliente y servidores. Algunas redes disponen de 3 redes: clientes que interactan con los usuarios finales, servidores de aplicacin que procesan los datos para los clientes y servidores de la base de datos que almacenan los datos para los servidores de aplicacin. La ventaja de la arquitectura de n-capas es que separa hacia fuera el proceso, eso ocurre para mejorar el balance de la carga en los diversos servidores. La desventaja es que pone ms carga en la red, debido a una mayor cantidad de trfico de la red. Es mucho ms difcil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse ms dispositivos para terminar la transaccin de un usuario. Arquitectura orientada a servicios: Es un concepto de arquitectura de software que define la utilizacin de servicios para dar soporte a los requisitos del negocio. Brinda una forma de invocacin de servicios (comnmente web) que facilita la interaccion entre diferentes sistemas propios o de terceros. Proyecto de software: es el proceso de gestin para la creacin de un sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin. La estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena ingeniera de sistemas. Al estimar se tiene en cuenta los procedimientos tcnicos, los recursos, los costos y planificacin. Los primeros tems a tener en cuenta en el diseo de un proyecto es: -Identificacin de necesidades -Estudio de viabilidad: econmica, tcnica y legal -Anlisis econmico y tcnico -Modelado de la arquitectura del sistema -Especificaciones del sistema Principales recursos a tener en cuenta al disear el proyecto -Recursos humanos: son seleccionados segn la evaluacin del mbito del software y las habilidades que tengan para ser participes del desarrollo. El nmero de personas se determina segn la estimacin del esfuerzo del proyecto. -Reutilizacin de los recursos de software, componentes, es importante para minimizar costos y tiempo de desarrollo. -El entorno que soporta un proyecto software incorpora hardware y software. El hardware proporciona una plataforma para soportar las herramientas de software utilizadas para desarrollar los productos de trabajo. Estudio de factibilidad Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados. Generalmente la factibilidad se determina sobre un proyecto. El estudio de factibilidad, es una de las primeras etapas del desarrollo de un sistema informtico.

12

El estudio incluye los objetivos, alcances y restricciones sobre el sistema, adems de un modelo lgico de alto nivel del sistema actual (si existe). A partir de esto, se crean soluciones alternativas para el nuevo sistema, analizando para cada una de stas, diferentes tipos de factibilidades. Los tipos de factibilidades bsicamente son: * Factibilidad tcnica: si existe o est al alcance la tecnologa necesaria para el sistema. * Factibilidad econmica: relacin beneficio costo. * Factibilidad operacional u organizacional: si el sistema puede funcionar en la organizacin. Para cada solucin factible, se presenta una planificacin preliminar de su implementacin. Estos resultados se entregan a la gerencia, quienes son los que aprueban la realizacin del sistema informtico. El estudio de factibilidad, es una tarea que suele estar organizada y realizada por los analistas de sistemas. El estudio consume aproximadamente entre un 5% y un 10% del costo estimado total del proyecto, y el perodo de elaboracin del mismo vara dependiendo del tamao y tipo de sistema a desarrollar. Una evaluacin de los costos de desarrollo, comparado con los ingresos netos o beneficios obtenidos del producto o sistema desarrollado. Viabilidad econmica: un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. Viabilidad tcnica Viabilidad legal: determinar cualquier posibilidad de infraccion, violacin o responsabilidad legal en que se podra incurrir al desarrollar el sistema. Alternativas: una evaluacin de los enfoques alternativos del desarrollo del producto o sistema. El estudio de viabilidad puede documentarse como un informe aparte para el alta de gerencia. Ciclo de vida de desarrollo de un sistema. Relacin con cada uno de los responsables de un proyecto. 1Identificar problemas, oportunidades y objetivos:

Responsables: Analista, Cliente, Lder del Proyecto 2Determinar informacin y requerimientos:

Mtodos interactivos, mtodos no intrusivos, preguntas (quien, que, donde, cuando y como), se confirma la idea que se tiene de la organizacin y sus objetivos. Responsables: Analista, Cliente, Lder del Proyecto, trabajadores y gerentes del rea de operaciones 3Analizar necesidades del sistema

Crear los diagramas de flujo de datos, diagramas de procesos, desarrollar un diccionario de datos, analizar las decisiones estructuradas que se hayan tomado, preparar y presentar la propuesta del sistema. Responsables: Analista, Cliente, Lder del Proyecto 4Disear el sistema recomendado

Disear la interfaz del usuario, diseo de salidas, diseo de entradas, diseo de controles del sistema, disear archivos y/o base de datos del sistema, especificaciones de archivos y detalles de procedimiento, arboles o tablas de la decisin del producto. Responsables: Analista, Cliente, Lder del Proyecto, diseador, operadores 5Desarrollar y documentar el software

13

Disear y documentar el software usando diagramas de estructura, pseudo cdigo, giagramas Nassi-Schneiderman; comunicar al programador lo que se requiere programar. 6Testear y mantener el sistema

Probar y eliminar errores de los programas antes de que se entregue a los usuarios; probar el sistema informtico con datos de muestra y luego con datos reales; gran parte del trabajo del programador consiste en el mantenimiento. Responsables: Analista, Lder del Proyecto, diseador de sistema, programadores 7Implementar y evaluar el sistema

Capacitar a los usuarios en el manejo del sistema; conversin gradual del sistema anterior al actual; comprar e instalar los equipos necesarios; convertir los archivos del formato antiguo al nuevo; instalar el sistema; puesta en produccin del nuevo sistema Responsables: Analista, Lder del Proyecto, diseador, programadores, operadores, cliente

En la carpeta tengo la siguiente lista de roles: Analista de sistemas, ingeniero de sistemas, programador, diseador, tester, tcnicos, redes, DBA, cliente, perito, asesor legal, QA, asesor contable, consultora, gerente de la empresa. Roles y responsabilidades Administrador del proyecto: administra y controla los recursos asignados a un proyecto, con el propsito de que se cumplan correctamente los planes definidos. Los recursos asignados pueden ser: recursos humanos, econmicos, tecnolgicos, etc. El administrador puede dirigir ms de un proyecto. El foco de una buena administracin est en el control y la coordinacin de los diferentes eventos y actividades de un proyecto. Analistas: se encarga del anlisis de un proyecto de software, descomponiendo el problema en subproblemas de menor complejidad. Como el experto del problema es el cliente se hace necesario trabajar junto con el cliente para realizar el anlisis y especificacin del sistema a construir. Para que el trabajo del analista tenga sentido para todos los integrantes del grupo se hace necesario ponerse de acuerdo en la forma como se realizara la especificacin, as como la forma en que el grupo la entender. Esto sugiere el uso de un estndar en la etapa de anlisis. Una de las razone ms frecuentes del fracaso de un desarrollo es la de realizar un anlisis pobre. Debido al insuficiente esfuerzo dedicado a conocer y especificar el sistema que desea el cliente, los desarrolladores construyen sistemas que no cuentan con las caractersticas que el cliente desea. Diseadores: Es el encargado de realizar el diseo del sistema. Entre sus funciones esta: Generar el diseo arquitectnico y diseo detallado del sistema Generar prototipos rpidos del sistema Generar el documento de diseo arquitectnico de software y mantenerlo actualizado durante el proyecto Velar porque el producto final se ajuste al diseo realizado

El propsito del diseo es la construccin de un sistema que cumpla con los requisitos: satisfaga una especificacin funcional dada, cumpla con las limitaciones del medio receptor y uso de recursos, cumpla los requisitos implcitos y explcitos de rendimiento y uso de recursos, satisfaga criterios de diseo implcitos y explcitos en la forma del artefacto construido. Programadores: Deben construir la especificacin del sistema en cdigo fuente ejecutable utilizando uno o ms lenguajes de programacin, as como las herramientas de software de apoyo a la programacin. Tester: su objetivo es detectar y eliminar los errores y defectos del sistema en construccin. Es el encargado de asegurar la calidad de un producto. Entre sus tareas estn:

14

Construir y aplicar los planes de prueba unitarios, de modulo, de sistema y aceptacin parcial, mantenindolos actualizados durante el proyecto. Velar por la completitud y exactitud de todos los documentos del proyecto. Coordinar las inspecciones Velar por la adhesin al estndar aportado para el desarrollo Velar por la calidad del producto final

Aseguradores de calidad: Los factores dominantes en la administracin de proyectos de software son los tiempos y costos de desarrollo, existiendo peligro en esto ya que al crecer la presin por cumplir con las fechas y reducir los costos es la calidad del producto el que sufre. Cuando se acelera el desarrollo del sistema generalmente se acorta lo considerado no esencial usualmente son las actividades de verificacin y testeo, resultando un producto de calidad reducida. Para evitar esto debe haber un convencimiento de considerar la calidad como una meta final dentro del cumplimiento de los plazos y costos. La calidad es un atributo a cumplir por el desarrollador. Administrador de configuracin: Es una disciplina que se aplica tradicionalmente al desarrollo de sistemas de hardware, al desarrollo de elementos de hardware o sistemas de hardware/software. Su aplicacin en conjunto con otras disciplinas lleva el desarrollo de sistemas en forma ordenada y estructurada. Aplica vigilancia a: Identificar y documentar caractersticas funcionales y fsicas de tems de configuracin Auditar los tems de configuracin para verificar cumplimiento de las especificaciones, control de interfaces y documentos Controlar cambios a los tems Registrar y reportar informacin necesaria para administrar tems de configuracin Mantener el repositorio del proyecto actualizado con las ltimas versiones de todos los entregables del proyecto. Administrar el software utilizado para el control de versiones Definir y controlar perfiles de acceso a los archivos del proyecto Velar por la completitud y exactitud del repositorio del proyecto

Ingeniero de validacin y verificacin: Una de las metas necesarias en el desarrollo del proyecto es garantizar que el software que evoluciona contine satisfaciendo las expectativas de los usuarios durante dicho proceso. Para lograr esta meta es necesario aplicar prcticas de ingeniera de software durante la evolucin del producto. La mayora de estas prcticas tratan de crear y modificar software para maximizar la probabilidad de satisfacer las expectativas de sus usuarios. Otras prcticas tratan de asegurar que el producto cumplir con las expectativas de dichos usuarios, conocidas como validacin y verificacin del software. Validacin se refiere al proceso de evaluacin del software al final de su proceso de desarrollo para asegurar que est libre de fallas y cumple con sus requisitos. Una falla se define como un comportamiento incorrecto. V&V es una ayuda para determinar que los requisitos del usuario han sido implementados correctamente. El objetivo principal es analizar y testear el software en forma completa durante el desarrollo para determinar que el software ejecuta sus funcionalidades correctamente, que no ejecute funciones no definidas, y proveer informacin sobre su calidad y confiabilidad. En conclusin las personas que hacen el V&V deben evaluar que tan bien el software est cumpliendo con sus requisitos tcnicos y sus objetivos de seguridad y confiabilidad. Las tareas del V&V son analizar, revisar, demostrar y testear todas las salidas del desarrollo del software. Documentador: Durante el proceso de desarrollo del software se genera una gran cantidad de documentacin, dicha documentacin debe ser almacenada en el repositorio del proyecto. La documentacin sirve, entre otras cosas, para conocer la historia del proyecto, estos no se escriben al final del proyecto, se van generando junto con las diferentes fases del proyecto. A medida que avanza los documentos deben ir siendo modificados para mantener el estado de los documentos a la par del proyecto, los documentos van evolucionando para mostrar el estado ms reciente del desarrollo del proyecto. Sin embargo el objetivo principal de la documentacin es actuar como medio de comunicacin entre los miembros del equipo, incluyendo al cliente, adems tambin sirve para reducir la distorsin de ideas, ayudar al control del proyecto, almacenar la lgica de las decisiones y hacer visibles tanto las capacidades como las limitaciones del sistema. Ingeniero de manutencin: La manutencin es la ltima fase del proceso de desarrollo, sin embargo toma una parte importante del presupuesto destinado al desarrollo. A medida que se desarrollan ms programas, la cantidad de esfuerzo y recursos dedicados a la manutencin crecer. Al final algunas empresas pueden llegar a encontrarse con la barrera de la manutencin, no pudiendo abordar nuevos proyectos debido a que todos sus recursos estn dedicados a mantener programas antiguos.

15

Solo el 20% del trabajo de manutencin es usado arreglando errores. El 80% restante se utiliza adaptando sistemas existentes a cambios en su ambiente externo, realizando mejoras pedidas por usuarios y realizando reingeniera del sistema para usos futuros. Se pueden distinguir distintos tipos de documentacin segn el pblico objetivo y el tipo de contenido: Documentacin de arquitectura y diseo: proporcionan una visin general de cmo se va a desarrollar el proyecto y porque se hace de ese modo, se suelen generar en las fases iniciales y deben ser revisados al producirse cambios. La idea es disponer de una descripcin del sistema donde se enumeran los componentes, la justificacin de su eleccin, la funcionalidad esperada y las relaciones entre ellos. Documentacin tcnica: documenta el cdigo, algoritmos, interfaces, etc. Es ms detallada y es escrita mientras se implementa; usualmente lo ms cmodo es mantenerla junto al cdigo fuente. Documentacin de usuario final: es una documentacin que se entrega al usuario final, tanto usuarios avanzados como no. No suele tener relacin con el cdigo fuente, solo describe cmo usar los programas producidos, por lo que puede ser redactado por personas que no hayan estado involucradas en el desarrollo del sistema.

Cliente: cliente, usuario y usuario final suelen ser utilizados como sinnimos. Un cliente es aquella persona responsable de llevar a cabo el buen desempeo del proyecto, por parte de la empresa que contrata el desarrollo. El cliente debe representar los derechos y asumir los deberes de dicha empresa ante el equipo de desarrollo. Por lo tanto debe estar presente en todas las fases del desarrollo del producto y realizar todas las actividades que se esperan de l, aceptacin provisional y final. Por otro lado los usuarios corresponden a las personas que estn operando da a da un sistema de software. Es la persona que conoce el problema y utiliza la herramienta. Un cliente y un usuario no siempre son lo mismo, ya que el cliente puede que no opere el sistema. Un usuario final se refiere a aquella persona que utiliza el sistema, pero que es desconocida y no identificable. Paso esto en sistemas de informacin de uso masivo, como atencin bancaria por internet, apoyo al comercio electrnico, etc. En el desarrollo de software tener clientes comprometidos es vital para el xito del proyecto, quien participe en todas las etapas y compartiendo deberes y responsabilidades. Herramientas de un IDE durante el ciclo de vida de un sistema Testeo del producto: JUnit, proporciona informacin sobre la calidad del producto bajo prueba, permitiendo a la empresa conocer y comprender los riesgos de implementacin del software. Estas pruebas pueden implementar en cualquier momento del proceso de desarrollo. Sin embargo la mayora de los test se producen despus de que los requisitos han sido definidos y el proceso de codificacin se ha completado. El encargado de estas tareas es el QA. Documentacin del producto: Es el texto escrito que acompaa al software en un proyecto. Algunas herramientas: doxygen, robodoc o naturaldocs (para multiples lenguajes) o epydoc, javadoc, perlpod (para lenguajes especficos). Refactorizacin del cdigo: Se usa a menudo para describir la modificacin del cdigo fuente sin cambiar su comportamiento, lo que se conoce como limpiar el cdigo. Se realiza a menudo como parte del proceso de desarrollo del software: los desarrolladores alternan la insercin de nuevas funcionalidades y casos de prueba con la refactorizacin del cdigo para mejorar su consistencia interna y su claridad. Es la parte del mantenimiento del cdigo que no arregla errores ni aade funcionalidad. El objetivo, es mejorar la facilidad de compresin del cdigo o cambiar su estructura y diseo y eliminar cdigo muerto, para facilitar el mantenimiento en un futuro. Netbeans trae consigo la herramienta Refactor ubicada en el men principal o en el men secundario, facilitando mover campos, mtodos o clases en todo sin romper cosas.

16

TEMA 4: DEBUGGING
Debugging (depuracin) Es el proceso metodolgico para encontrar y reducir errores o defectos en un programa informtico o en una pieza de hardware. La tarea de depuracin de un error de software, suele requerir los siguientes pasos. Reconocer que ese error existe (un programa puede contener errores que jams sern detectados). Aislar la fuente del error. Identificar la causa del error. Determinar una solucin para el error. Aplicar la solucin. Probar el programa.

Los programas para la depuracin son llamados depuradores o debugger, permiten ejecutar un programa, hacer pausas, volver a comenzarlo, ejecutarlo por partes, ver o cambiar los valores de las variables, etc. Breakpoint (punto de parada) Es una pausa intencional y controlada durante la ejecucin de un programa. Pausar la ejecucin de un programa permite conocer ms acerca de su comportamiento, especialmente en ese instante que fue pausado. En el estado de pausa se pueden comprobar el estado de la memoria, las variables, los archivos, etc. relacionados al programa, permitiendo descubrir errores o comprender su comportamiento. Un punto de interrupcin se puede hacer inmediatamente antes de que un comando especfico se ejecute, o inmediatamente despus, o cuando se lee, escribe o modifica una ubicacin especfica en la memoria, tambin cuando se cumple un tiempo especfico, cuando se presiona una determinada tecla o cuando ocurre un evento determinado. Algunos programas depuradores permiten crear fcilmente puntos de interrupcin, permitindonos ver el estado de las variables, entre otros datos, en el preciso momento que se realiza la pausa. Los puntos de interrupcin son uno de los conceptos ms importantes en la depuracin. Representan marcadores en el cdigo en el que desea la ejecucin del programa se detenga. Tipo de Breakpoints: Class: Permite detener la ejecucin del programa cuando una clase se carga o descarga de la mquina virtual de Java. Cuando se agrega un punto de interrupcin de clases, se aplica a cualquier cdigo que se ejecuta durante la depuracin. Exception: Permite detener la ejecucin del programa cuando se detecta una excepcin, o simplemente se encuentran en el cdigo que se ejecuta en la mquina JavaVirtual. Method: Permite detener el programa cuando la ejecucin del mismo entre o salga de uno o ms mtodos de una clase especfica. - Method Entry - Method Exit - Method Entry or Exit Thread: Este tipo de punto de interrupcin se puede configurar para detener la ejecucin del programa si se inicia un subproceso o acabados. Esto puede ser extremadamente til en la programacin de aplicaciones cliente-servidor o servidores de multiproceso. Field: Puede configurar este tipo de punto de interrupcin para detener la ejecucin del programa cuando acceda a un mtodo, a un atributo o a ambos.

17

Paso a paso Step over: (F8) Corre el programa lnea por lnea para inspeccionar las variables, con la excepcin de que si ve una llamada a un mtodo no pasa por dicho mtodo siguiendo a la siguiente lnea. Step into: (F7) Corre el programa lnea por lnea metindose dentro de cada mtodo. Step out: (Ctrl + F7) Si estaba ejecutando paso a paso y ha sido trasladado dentro de un mtodo con Step Out se puede volver al procedimiento que se llam. Test Unitario (Ejemplo Junit) Un test unitario es un trozo de cdigo desarrollado con el nico objetivo de verificar que una rutina o funcin de nuestro cdigo est funcionando segn esperamos. En definitiva, lo que Unit Test pretende es tener trozos de cdigo que se encargarn de testear por separado y de forma independiente cada uno de los mtodos de las distintas clases que compongan el programa desarrollado, para que cuando se haga alguna modificacin en el cdigo, posibles errores derivados de esa modificacin puedan ser identificados y corregidos de manera rpida y eficaz. La idea general que se destila de los tests unitarios es que si todas las partes de un cdigo funcionan por separado, lo ms probable es que el global que componen tambin funcione. Igualmente, siempre ser necesario realizar un testeo general (o pruebas de integracin) de la aplicacin para comprobar que el todo que hemos compuesto funciona correctamente. Algunas ventajas de usar Test Unitarios son: Facilita los cambios en la aplicacin ya que las pruebas nos asegurarn que los nuevos cambios no han introducido errores. Simplifica la integracin permitiendo llegar a la fase de integracin con un grado alto de seguridad de que el cdigo est funcionando correctamente. Documenta el cdigo. Las propias pruebas son un libro abierto sobre el funcionamiento de la funcin y los resultados esperados. Separacin de la interfaz y la implementacin. Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro. Los errores estn ms acotados y son ms fciles de localizar: dado que prepara un test para cada funcin que puede desenmascararlo. Aceleran el desarrollo del software debido a que ayuda a tener un cdigo desacoplado, cada una de las funciones estn pensadas para devolver un resultado que podr ser testeado.

Traza y Asercin Ambas son tcnicas bsicas de depuracin. Luego que detectamos un comportamiento incorrecto, tenemos que determinar el punto exacto del error. Para facilitar dicha tarea se pueden utilizar tcnicas llamadas programacin defensiva y que son: Aserciones Trazas de valores Trazas de flujo de ejecucin

La utilizacin de trazas y aserciones, en conjunto con la utilizacin de programas especialmente diseados para depurar cdigo (llamados Debuggers), facilitan la tediosa tarea de la localizacin y reparacin del fallo. Aserciones: La tcnica de las aserciones (o afirmaciones) consiste en sembrar el cdigo de chequeos de condiciones que suponemos deben cumplirse, de forma que si algo no es normal, lo detectemos lo antes posible, por s mismo, en vez de tener que estar trazando marcha atrs las causas que han llevado a un fallo. Por ejemplo, puede controlarse que un puntero no valga NULL al inicio de una funcin que asume el puntero inicializado como precondicin. Cuando una variable toma un valor inesperado (errneo en definitiva), el cdigo de asercin despliega un mensaje indicando el problema y se detiene la ejecucin del problema. De este modo, las consecuencias se pueden apreciar inmediatamente evitando que el programa arrastre el error durante un tiempo antes que se aprecie un fallo de ejecucin o entregue un resultado final equivocado.

18

Las aserciones suponen un trabajo extra para el programador, trabajo que se compensa durante el desarrollo y las pruebas; pero que parece redundante cuando el programa ha sido exhaustivamente probado y simplemente queremos que produzca resultados a la mayor velocidad posible. En otras palabras, queremos eliminar las aserciones cuando entremos en produccin. No obstante, si teniendo un programa en produccin se detecta una situacin de fallo, conviene reactivar las aserciones para poder afinar rpidamente dnde est el origen del problema. En resumen, las aserciones deberan poder activarse y desactivarse con comodidad para afrontar con el mismo cdigo las situaciones de depuracin de errores y de produccin. Trazas de valores: Son los listados que se generan cuando ejecutamos el cdigo y nos van informando los valores que van tomando las variables. Por supuesto que ac tambin el programador tiene que escribirlas y determinar qu variables quiere examinar. Trazas de flujos de ejecucin: Al igual que las anteriores, stas producen listados con marcas que nos indican por donde o que secciones del cdigo se han ejecutado. Tambin aqu es conveniente determinar qu secciones del cdigo son relevantes pues no resulta muy razonable dejar trazas para cada lnea de programa. Ejemplo //Asercin: una pregunta que nosotros esperamos que sea verdadera //La desventaja es que ensucia el cdigo //JUnit limpia esto, porque se escribe en la clase hermana if (valorObtenido == valorEsperado) System.out.println("Correcto"); //Impresin de una traza

Que se debe considerar para depurar un programa en JAVA Para poder realizar la depuracin en java se debe tener activado Generate Debugging Info en las propiedades del proyecto. Sin esta opcin activada cuando se quiera generar un breakpoint sobre el cdigo el IDE va a mostrar un error Invalid LineBreakpoint DebugNotEnabled.java : 23. Programas de depuracin JDebugTool JSwat Omniscient Debugging Xdebug PHP debugger and profiler (configurable en Netbeans) VB Watch Debugger debugger for Visual Basic 6.0 SoftICE: debugger para Windows (corre en modo kernel sin que Windows lo detecte). Debugger for MySQL Programa de debugger que usa NetBeans por defecto Java Platform Debugger Architecture (JPDA) es una coleccin de APIs que proporciona una infraestructura para depurar aplicaciones de J2SE. Incluye tres APIs: Java Debug Interface (JDI): Interfaz Java de alto nivel que incluye soporte de depuracin remota. Java Debug Wire Protocol (JDWP): Define el formato de la informacin y las solicitudes transferidas entre el proceso que se est depurando y el front-end del depurador. Java Virtual Machine Tools Interface (JVM TI): Una interfaz nativa que define los servicios de una mquina virtual Java. Proporciona herramientas tales como depuradores y profilers. JVM TI se introdujo en J2SE 5.0 y sustituye JVMDI y JVMPI. JVMDI fue eliminado en Java SE 6 y JVMPI ser eliminado en Java SE 7.

NetBeans Debugging Variables: La ventana Variables locales permite realizar el seguimiento del valor de todas las variables y objetos durante una sesin de depuracin. Ser capaz de realizar el seguimiento del valor de todas las variables y objetos puede resultar muy valioso en la depuracin permitiendo controlar los valores a medida que se crean y modifican a lo largo de todas las clases y mtodos. Watches: Es una caracterstica de depuracin que le permite especificar una declaracin Java y seguimiento de su valor durante una sesin de depuracin. Puede seguir los campos, objetos o expresiones en una ventana llamada la ventana Watches. Los relojes persisten a travs de sesiones de depuracin, por lo que no tiene que reiniciar ellos cada vez que los necesite. Esto puede ayudar en la depuracin de los problemas persistentes en el.

19

Call Stack: En la pila de llamadas se almacenan los mtodos que son llamadas durante la depuracin del programa y la lnea donde se encuentra posicionado el punto de interrupcin dentro del mtodo. Loaded Classes: muestra una lista de todas las clases utilizadas en el programa. Breakpoint: En la ventana de puntos de interrupcin se enumeran los puntos de interrupcin en la actualidad fijados en todos los proyectos abiertos. La columna muestra una casilla de verificacin para cada punto de interrupcin. Si se selecciona, a continuacin, el punto de interrupcin estar habilitado, de lo contrario se desactivar. Session: Se puede utilizar la ventana de sesiones para ver y detener todas las sesiones de depuracin activa. La ventana de sesiones mostrar una lista de las sesiones de depuracin actual. La ventana de sesin muestra el nombre de cada sesin, el estado actual que se encuentra, y la codificacin del lenguaje. Thread:

Sources: muestra la ruta donde se encuentra ubicado el proyecto y el JDK. La ruta de los archivos en uso durante la ejecucin de la depuracin del programa. Debugging: Proporciona informacin sobre el punto de interrupcin durante la depuracin. La clase que est ejecutando, el mtodo que est llamando, la lnea donde se encuentra ubicado el Breakpoint.

TEMA 5: TESTING
Testing El desarrollo de sistemas de software implica una serie de actividades de produccin en las que las posibilidades de que aparezca el fallo humano son enormes. Los errores pueden empezar a darse desde el primer momento del proceso, en el que los objetivos pueden estar especificados de forma errnea o imperfecta, as en posteriores pasos de diseo y desarrollo. Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo de software ha de ir acompaado de una actividad que garantice la calidad. Las pruebas del software son un elemento crtico para la garanta de calidad del software y representa una revisin final de las especificaciones, del diseo y de la codificacin. Una vez generado el cdigo fuente, el software debe ser probado para descubrir y corregir el mximo de errores posibles antes de su entrega al cliente. El objetivo es disear una serie de casos de prueba que tengan una alta probabilidad de encontrar errores. Las pruebas de software facilitan una gua sistemtica para disear pruebas que comprueben la lgica interna de los componentes del software y verifiquen los dominios de entrada y salida del programa para descubrir errores en la funcionalidad, el comportamiento y rendimiento. El software debe probarse desde dos perspectivas diferentes: 12La lgica interna del programa se comprueba utilizando tcnicas de diseo de casos de prueba de caja blanca. Los requisitos del software se comprueba utilizando tcnicas de diseo de casos de prueba de caja negra.

En ambos casos se intenta encontrar el mayor nmero de errores con la menor cantidad de esfuerzo y tiempo. Que se obtiene? Se documenta un conjunto de casos de prueba, diseador para comprobar la lgica interna y los requisitos externos. Se determinan los resultados esperados y se guardan los resultados obtenidos. Los casos de prueba deben abarcar todo el desarrollo.

1. La prueba es el proceso de ejecucin de un programa con la intencin de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. 3. Una prueba tiene xito si descubre un error no detectado hasta entonces.

20

Estrategias de prueba De Caja Blanca De Caja Negra Descendente Ascendente Incremental Prueba de Estrs Principios del testing En general, es imprctico, y a menudo imposible encontrar todos los defectos en un programa, ya que habra que probar todas las combinaciones de entrada, correctas e incorrectas, dadas en general por el nmero infinito de casos de prueba. Por otro lado habra que probar todos los caminos posibles dentro de un programa, que pueden contener lazos (en general el nmero de casos de prueba no es infinito, pero usualmente puede considerarse como tal). Testing es una tarea extremadamente creativa e intelectualmente desafiante. Desde un punto de vista econmico es imposible probar un programa para encontrar todos los defectos. Ni siquiera para los programas ms triviales. Evitar casos de prueba espontneos y que no dejan registro, de hacerlo as solo se pierde el tiempo. No planificar un caso de prueba bajo el supuesto tcito que no se encontrarn defectos. La probabilidad de existencia de ms defectos en una seccin de un programa es proporcional al nmero de defectos ya detectados en dicha seccin. Objetivos de las pruebas Encontrar defectos en el software Una prueba tiene xito si descubre un defecto Una prueba fracasa si hay defectos pero no los descubre Organizacin para las pruebas de software Especificar requerimientos del producto en forma cuantificable antes de comenzar el testing. Establecer explcitamente los objetivos del testing. Comprender a los usuarios y desarrollar un perfil para cada categora. Desarrollar un plan que enfatice pruebas de ciclo rpido. Construir software robusto que se disee para probarse a s mismo. Usar revisiones tcnicas formales. Desarrollar un enfoque de mejoramiento continuo para el proceso de testing. Cada prueba debe Dejar claro qu tipo de propiedades se quieren probar (correccin, robustez, fiabilidad, amigabilidad, etc.). Dejar claro cmo se mide el resultado. Especificar en qu consiste la prueba (hasta el ltimo detalle de cmo se ejecuta). Definir cul es el resultado que se espera (identificacin, tolerancia,...). Cmo se decide que el resultado es acorde con lo esperado? Las pruebas angelicales carecen de utilidad, tanto si no se sabe exactamente lo que se quiere probar, o si no est claro cmo se prueba, o si el anlisis del resultado se hace a ojo. Tipos Pruebas de Verificacin o Ver si cumple las especificaciones de diseo Pruebas de Validacin o Ver si cumple los requisitos del anlisis

Prueba de caja negra Se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. O sea, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa (por ejemplo, archivos de datos) se mantiene. Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lgica interna del software.

21

La prueba de caja negra permite al ingeniero del software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa. La prueba de caja negra no es una alternativa a las tcnicas de prueba de caja blanca. Ms bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de caja blanca. La prueba de caja negra intenta encontrar errores de las siguientes categoras: (1) funciones incorrectas o ausentes, (2) errores de interfaz, (3) errores en estructuras de datos o en accesos a bases de datos externas, (4) errores de rendimiento y (5) errores de inicializacin y de terminacin. Concepto y terminologa Pruebas en que se conoce slo la interfaz Caja negra (black box: caja opaca) Se procura ejercitar cada elemento de la interfaz

Algunas clases de pruebas Cubrimiento invocar todas las funciones (100%) Clases de equivalencia de datos Pruebas de valores lmite

Prueba de caja blanca La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado. Concepto y terminologa Pruebas en que se conoce el cdigo a probar Caja blanca (clear box: caja clara o transparente) Se procura ejercitar cada elemento del cdigo

Algunas clases de pruebas Pruebas de cubrimiento Pruebas de condiciones Pruebas de bucles

Pruebas de cubrimiento Ejecutar al menos una vez cada sentencia Se necesitan varios casos de prueba o Determinar posibles caminos independientes o Cada condicin debe cumplirse en un caso y en otro no. En general, se necesitan tantos casos como condiciones, ms uno (nmero ciclomtico) Puede ser imposible cubrir el 100% o Cdigo que nunca se ejecuta: condiciones imposibles o Ejemplo: deteccin y notificacin de errores internos en un cdigo sin errores

Pruebas de condiciones Cumplir o no cada parte de cada condicin Se necesitan varios casos de prueba o Determinar expresiones simples en las condiciones o Una por cada operando lgico o comparacin o Cada expresin simple debe cumplirse en un caso y en otro no, siendo decisiva en el resultado Puede ser imposible cubrir el 100% o Expresiones simples no independientes

Pruebas de bucles Conseguir nmeros de repeticiones especiales

22

Bucles simples o Repetir cero, una y dos veces o Repetir un nmero medio (tpico) de veces o Repetir el mximo-1, mximo y mximo +1! Bucles anidados o Repetir un nmero medio (tpico) los bucles internos, el mnimo los externos, y variar las repeticiones del bucle intermedio ensayado. o Ensayarlo con cada nivel de anidamiento

PRUEBAS INTEGRALES Un nefito del mundo del software podra, una vez que se les ha hecho la prueba de unidad a todos los mdulos, cuestionar de forma aparentemente legtima lo siguiente: Si todos funcionan bien por separado, por qu dudar de que funcionen todos juntos? Por supuesto, el problema es ponerlos juntos (interaccin). Los datos se pueden perder en una interfaz; un mdulo puede tener un efecto adverso e inadvertido sobre otro; las subfunciones, cuando se combinan, pueden no producir la funcin principal deseada; la imprecisin aceptada individualmente puede crecer hasta niveles inaceptables; y las estructuras de datos globales pueden presentar problemas. La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interaccin. El objetivo es coger los mdulos probados mediante la prueba de unidad y construir una estructura de programa que est de acuerdo con lo que dicta el diseo. A menudo hay una tendencia a intentar una integracin no incremental; es decir, a construir el programa mediante un enfoque de big bang. Se combinan todos los mdulos por anticipado. Se prueba todo el programa en conjunto. Normalmente se llega al caos! Se encuentran un gran conjunto de errores. La correccin se hace difcil, puesto que es complicado aislar las causas al tener delante el programa entero en toda su extensin. La integracin incremental es la anttesis del enfoque del big bang. El programa se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y de corregir, es ms probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemtica. En las siguientes secciones se tratan varias estrategias de integracin incremental diferentes. Pruebas integrales descendentes

Se integran los mdulos movindose hacia abajo por la jerarqua de control, comenzando por el mdulo de control principal (programa principal). Los mdulos subordinados (subordinados de cualquier modo) al mdulo de control principal se van incorporando en la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura. Pruebas integrales ascendentes

La prueba de la integracin ascendente, como su nombre indica, empieza la construccin y la prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos. PRUEBA DE ESTRS (RESISTENCIA) Durante los pasos de prueba anteriores, las tcnicas de caja blanca y de caja negra daban como resultado la evaluacin del funcionamiento y rendimiento normales del programa. Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones anormales. La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo: (1) disear pruebas especiales que generen diez interrupciones por segundo, cuando las normales son una o dos; (2) incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada; ( 3 ) ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos; (4) disear casos de prueba que puedan dar problemas en un sistema operativo virtual o (5) disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el programa. TEST UNITARIO La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del software: el componente software o mdulo.

23

Consideraciones sobre la prueba de unidad: Se prueba la interfaz del mdulo para asegurar que la informacin fluye de forma adecuada hacia y desde la unidad de programa que est siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecucin del algoritmo. Se prueban las condiciones lmite para asegurar que el mdulo funciona correctamente en los lmites establecidos como restricciones de procesamiento. Se ejercitan todos los caminos independientes (caminos bsicos) de la estructura de control con el fin de asegurar que todas las sentencias del mdulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores. Adems de las estructuras de datos locales, durante la prueba de unidad se debe comprobar (en la medida de lo posible) el impacto de los datos globales sobre el mdulo. Las pruebas del camino bsico y de bucles son tcnicas muy efectivas para descubrir una gran cantidad de errores en los caminos. En programacin, una prueba unitaria es una forma de probar el correcto funcionamiento de un mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione correctamente por separado. Luego, con las Pruebas de Integracin, se podr asegurar el correcto funcionamiento del sistema o subsistema en cuestin. La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo de forma que cada caso sea independiente del resto. Caractersticas: Ventajas El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas bsicas: Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el cdigo para mejorar su estructura (lo que se ha dado en llamar refactorizacin), puesto que permiten hacer pruebas sobre los cambios y as asegurarse de que los nuevos cambios no han introducido errores. Simplifica la integracin: Puesto que permiten llegar a la fase de integracin con un grado alto de seguridad de que el cdigo est funcionando correctamente. De esta manera se facilitan las pruebas de integracin. Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto que ah se puede ver cmo utilizarlo. Separacin de la interfaz y la implementacin: Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos. Automatizable: no debera requerirse una intervencin manual. Esto es especialmente til para integracin continua. Completas: deben cubrir la mayor cantidad de cdigo. Repetibles o Reutilizables: no se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til para integracin continua. Independientes: la ejecucin de una prueba no debe afectar a la ejecucin de otra. Profesionales: las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad, documentacin, etc.

Limitaciones Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del cdigo. Por definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn errores de integracin, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Herramientas o JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se encuentra basado en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje Smalltalk.

24

o o o o o o o o

TestNG: Creado para suplir algunas deficiencias en JUnit. JTiger: Basado en anotaciones, como TestNG. SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP. PHPUnit: framework para realizar pruebas unitarias en PHP. CPPUnit: Versin del framework para lenguajes C/C++. NUnit: Versin del framework para la plataforma.NET. FoxUnit: framework OpenSource de pruebas unitarias para Microsoft Visual FoxPro MOQ : Framework para la creacin dinmica de objetos simuladores (mocks).

PRUEBAS DE VALIDACIN La validacin puede definirse de muchas formas, pero una simple (aunque vulgar) definicin es que la validacin se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente. Las expectativas razonables estn definidas en la Especificacin de Requisitos del Software -un documento que describe todos los atributos del software visibles para el usuario. La especificacin contiene una seccin denominada-. Criterios de validacin . La informacin contenida en esa seccin forma la base del enfoque a la prueba de validacin. Criterios de validacin: La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requisitos. Un plan de prueba traza la clase de pruebas que se han de llevar a cabo, y un procedimiento de prueba define los casos de prueba especficos en un intento por descubrir errores de acuerdo con los requisitos. Tanto el plan como el procedimiento estarn diseados para asegurar que se satisfacen todos los requisitos funcionales, que se alcanzan todos los requisitos de rendimiento, que la documentacin es correcta e inteligible y que se alcanzan otros requisitos (por ejemplo, portabilidad, compatibilidad, recuperacin de errores, facilidad de mantenimiento). Una vez que se procede con cada caso de prueba de validacin, puede darse una de las dos condiciones siguientes: (1) las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las especificaciones y son aceptables; o (2)se descubre una desviacin de las especificaciones y se crea una lista de deficiencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de la terminacin planificada. A menudo es necesario negociar con el cliente un mtodo para resolver las deficiencias. Prueba alfa y beta La prueba alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. Como resultado de los problemas informados durante la prueba beta, el desarrollador del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la clase de clientes. Caractersticas: Comprobar que se satisfacen los requisitos Se usan la mismas tcnicas, pero con otro objetivo No hay programas de prueba, sino slo el cdigo final de la aplicacin Se prueba el programa completo Uno o varios casos de prueba por cada requisito o caso de uso especificado Se prueba tambin rendimiento, capacidad, etc. (y no slo resultados correctos) Pruebas alfa (desarrolladores) y beta (usuarios)

PRUEBAS DE VERIFICACIN La verificacin se refiere al conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.

25

PRUEBA DE REGRESIN Cada vez que se aade un nuevo mdulo como parte de una prueba de integracin, el software cambia. Se establecen nuevos caminos de flujo de datos, pueden ocurrir nuevas E/S y se invoca una nueva lgica de control. Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. En el contexto de una estrategia de prueba de integracin, la prueba de regresin es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. Repetir las pruebas tras cada modificacin o Repetir slo pruebas de verificacin Pruebas de unidades Pruebas de integracin o Conservar y actualizar los programas de prueba o Usar herramientas de ejecucin automtica de las pruebas

MOCK OBJECT En la programacin orientada a objetos se llaman objetos simulados (pseudoobjetos, mock object, objetos de pega) a los objetos que imitan el comportamiento de objetos reales de una forma controlada. Se usan para probar a otros objetos en pruebas de unidad que esperan mensajes de una clase en particular para sus mtodos. En los test de unidad, los objetos simulados se usan para simular el comportamiento de objetos complejos cuando es imposible o impracticable usar al objeto real en la prueba. De paso resuelve el problema del caso de objetos interdependientes, que para probar el primero debe ser usado un objeto no probado an, lo que invalida la prueba: los objetos simulados son muy simples de construir y devuelven un resultado determinado y de implementacin directa, independientemente de los complejos procesos o interacciones que el objeto real pueda tener. Los objetos simulados se usan en lugar de objetos reales que tengan algunas de estas caractersticas: o o o o o Devuelven resultados no determinsticos (por ejemplo la hora o la temperatura) Su estado es difcil de crear o reproducir (por ejemplo errores de conexin) Es lento (por ejemplo el resultado de un clculo intensivo o una bsqueda en una BBDD) El objeto todava no existe o su comportamiento puede cambiar. Debera incluir atributos o mtodos exclusivamente para el testeo.

Los objetos simulados para imitar al objeto real deben imitar su misma interfaz. Esto es til cuando quieres probar una clase que usa otras clases. En lugar de emplear las clases reales, utilizamos sus simulaciones. De este modo, nos evitamos las posibles interferencias de su funcionamiento sobre los resultados del test y garantizamos que slo probamos el cdigo de la clase en cuestin. Ejemplo: probar un Controller que usa un Component. Lo que tenemos que hacer son bsicamente dos cosas: Crear una simulacin o Mock del Component Asociar el Component simulado al Controller

26