Construcción de Proyectos de Software

M.C. Juan Carlos Olivares Rojas

Introducción• La etapa de construcción se compone

básicamente de dos actividades: codificación y pruebas.

• La codificación consiste en pasar el modelo obtenido en la fase de modelado a elementos que puedan ser implantados en las computadoras a través de lenguajes de programación.

2

Introducción• Los nuevos IDEs (Integrated Development

Environments) disponen de nuevas herramientas que permiten trabajar en la fase de desarrollo de software de manera más fácil y productiva.

• Dentro de los nuevos agregados se encuentran: refactorización, navegación, profiling, pruebas de unidad, entre otros.

Profiling

• En antaño, el rendimiento de una aplicación se media a través de prueba y error con elementos como cronómetros, observar la cantidad de memoria, programas de benchmark o bien mediante la realización de programas de rendimiento.

• Esta nueva funcionalidad puede realizarse a través de herramientas de profiling.

Profiling• La mayoría de las herramientas de Profiling

permiten ver el rendimiento de las aplicaciones en tres rubros importantes: memoria, CPU y monitor de procesos.

• En la versión 6.0 de NetBeans el Profiling se encuentra de manera predeterminada en el IDE, en versiones anteriores se tendrá que instalar.

Profiling

• El primer paso en una herramienta de profiling es la calibración. Dicho proceso permite determinar los tiempos de la arquitectura de cómputo.

• Después se debe configurar cada uno de los apartados para que se puedan obtener estadísticas útiles. Dentro de cada herramienta se debe dar ejecutar para que se ejecute el programa con el profiling.

Profiling• De las características con la cual se cuenta es que

la información la maneja de forma gráfica.

• Se permite guardar instantáneas de la pruebas para compararlas con otras instantáneas y tener un mejor rendimiento de la aplicación.

Navegación

• Otras de las mejoras en los IDE’s vienen en la forma de desplazarse a través del código que ya no sólo se limita a ir a tal línea o a tal nombre. Muchos de estos cambios se deben a que los IDEs procesan múltiples tipos de documentos como páginas Web, XML, UML, etc.

• Se puede personalizar para ir a tipos de datos, funciones, variables, declaraciones, etc.

Actividad• Realizar el profiling de cada módulo que se vaya

obteniendo del desarrollo de proyecto para comprobar que efectivamente se está mejorando el rendimiento.

• Auxiliarse de los nuevos métodos de navegación en los IDEs (100%)

9

Refactorización• La refactorización es el proceso que consiste en

cambiar la estructura interna de un programa sin modificar su comportamiento externo.

• La refactorización es parte importante del proceso de reingeniería y puede enfocarse a la reestructuración de códigos

Refactorización

• Las herramientas actuales permiten más que simplemente buscar una cadena de texto y sustituirla por otra.

• Al hacer uso de la refactorización permiten una reestructuración más simple y menos propensa a errores.

• NetBeans desde su versión 5.0 soporta refactorización.

Refactorización• Las principales herramientas con las que se cuenta

son:

• Renombrado para cambiar de manera segura el nombre (si no se aplica a esto, un comando de sustituir todo puede ser perjudicial), mover, copiar, borrar, cambiar parámetros de los métodos, encapsular campos de una clase (crear métodos get/set).

Refactorización

• Se pueden extraer elementos para crear interfaces, se pueden introducir variables, constantes, métodos, atributos.

• En algunos casos es más tardado usar la herramienta que realizar la reestructuración de código a mano.

• En NetBeans y algunos otros IDEs se cuentan con herramientas para manipular el código fuente.

Refactorización

• Para dar formato (si es que el código no se creo en un IDE), eliminar espacios en blanco innecesarios, identar a la izquierda y a la derecha, subir, bajar líneas, duplicar líneas, completar, insertar código, etc.

• Estas herramientas pueden utilizarse para generar patrones repetitivos de código en funciones.

Refactorización• Para la reestructuración de códigos se pueden

seguir convenciones ya definidas las más importantes son la notación húngara y la notación de camello.

• La notación húngara fue creada por Charles Simonyi de Microsoft, el cual es húngaro y por eso recibió ese nombre.

Notación Húngara• Es un método ampliamente usado sobre todo para

convención de nombres de variables.

• Consiste en tener variables autodocumentadas agregando un prefijo de tres caracteres o menos para indicar su tipo.

• Las abreviaturas de los tipos de datos puede variar dependiendo del lenguaje de programación.

Notación Húngara

Descripción Abr

Carácter con signo c

Carácter sin signo b

Entero n

Palabra (entero sin signo)

w

Doble palabra (entero 32 bits)

dw

Largo l

Flotante f

Doble d

Cadena terminada en /0

sz

Estructura Abc sA

Descripción Abr

Objeto (parecido a las estructuras)

o*

Manejador (handler)

h

Puntero a entero de 16 bits

p

Puntero largo (32 bits)

lp

Enumeraciones e

Puntero largo a una cadena terminado en nulo

lpsz

Puntero largo a una función que devuelve un entero

lpfn

Descripción Abr

Formulario frm

CheckBox chk

Botón cmd

Imagen img

Etiqueta lbl

Menú mnu

PictureBox pic

TextBox txt

ComboBox cbo

Línea lin

Notación húngara• int nTest;• long lTemp;• char *szString = "Prueba";• struct Rect srRect;• int nMiVariableEjemplo;• char szEjemploString;• int NNOMBREINVALIDO;• int nNombre_Incorrecto;

Notación Húngara

• Las funciones o subrutinas no se les agrega abreviaciones, se recomiendan tengan un nombre descriptivo.

• Los nombres de las clases van en mayúsculas.

• Se pueden tener nuevos tipos de datos sólo se deben de poner las nuevas nomenclaturas.

Notación de Camello• Es la utilizada por Java y herramientas afines. Su

uso está creciendo en popularidad mientras que la notación húngara va en desuso.

• Su principal característica consiste en que no separa nombres de identificadores (variables, métodos, objetos) con “_” para palabras compuestas.

Notación de Cabello• Los identificadores tienen la forma de la joroba

de un camello. No se indican tipos de datos. Sigue respetando mucho de la Notación C.

• Los métodos inician en minúsculas y si hay una palabra compuesta esta inicia con mayúscula dando la apariencia de una joroba.

Notación Camello• Las clases inician con mayúscula siguiendo el

mismo método.

• Los métodos para acceder a atributos de las clases no públicos deben llamarse por convención set y get.

Actividad• De tu código del proyecto nombrar cada uno de

los identificadores en base a la notación húngara y/o notación de camello (50%).

• Los nombres de los nuevos identificadores deberán estar en Inglés (50%).

Reutilización• El reuso es una de las técnicas de resolución de

problemas que más utilizamos los humanos. De hecho es lo primero que verifica nuestro cerebro.

• El reuso en software nos ayuda a mejorar la producción y calidad del software al “no reinventar la rueda”.

Reuso

• El reuso nos permite afrontar los grandes proyectos de software sin mayores complicaciones. Desafortunadamente no todo se puede reutilizar.

• La reutilización es la propiedad de utilizar conocimiento, procesos, metodologías o componentes de software ya existente para adaptarlo a una nueva necesidad, incrementando significativamente la calidad y productividad del desarrollo.

Reutilización• La reutilización puede ser composicional,

generativa y adapativa.

• Es composicional cuando se orienta al reuso del producto. Puede ser de caja blanca (si nos interesa modificar el comportamiento), caja negra (cuando no se puede modificar el comportamiento) y adaptativo cuando es una mezcla de ambos.

Reutilización• La reutilización por generación se da cuando se

utilizan esfuerzos previos del desarrollo de software.

• Para que un objeto pueda ser reusable se necesita de un alto nivel de abstracción. Entre mayor es su nivel de abstracción, mayor es su nivel de reuso.

Reuso• Tipos de reuso:

• Código reciclado: utilizar parte del código definido en otros proyectos.

• Componentes de código: consiste en utilizar módulos, clases, APIs, etc.

• Esquemas: DFD, Diagramas UML.

Reuso• Frameworks: Solución integrada para la

resolución de problemas en un contexto particular. Se pueden utilizar patrones de diseño. Un ejemplo de Framework es .NET

• Las etapas del proceso de reuso son:

• Adquisición del requerimiento.

Reuso• Búsqueda y Recuperación– Recuperación por Palabras Claves– Recuperación Basada en la Estructura– Recuperación Enumerada

• Identificación• Adecuación

Reingeniería del Software• Sucede que si una aplicación necesita ser

modificada constantemente y no tiene una metodología de seguimiento del desarrollo del proyecto, la modificación del software se vuelve sumamente complicada.

• El mantenimiento de software en algunos casos puede llegar a ser del 60% del total de costos del proyecto.

Reingeniería del Software

• Aún cuando un software se haya desarrollado con la mejor metodología de software tendrá que ser modificado en un futuro por algún motivo, debido a que lo único constante es el cambio.

• Los tipos de mantenimiento de Software son: correctivo, adaptativo, mejoras o mantenimiento de perfeccionamiento, mantenimiento preventivo o reingeniería.

Reingeniería del Software

• El 80% del tiempo del desarrollo del software se ocupa en la adaptación del software a su ambiente externo.

• La reingeniería de software es costosa y consumidora de tiempo.

• La reingeniería es una actividad de reconstrucción, preferible de realizar antes de que se “derrumbe” la obra.

Reingeniería de Software

• Antes de derribar una casa, quizás se necesita corroborar que está mal.

• La reingeniería es un proceso que altera los elementos internos de toda obra, no es una sola remodelación de la fallada.

• Generalmente se siguen los siguientes pasos para aplicar reingeniería:

Reingeniería de Software• Análisis de Inventario• Reestructuración de Documentos• INGENIERÍA INVERSA• Reestructuración de Códigos• Reestructuración de Datos• Ingeniería directa

Ingeniería Inversa

• Se aplica para obtener un modelo detallado de análisis, ingeniería de requerimientos, diseño y en algunos casos implementación teniendo una solución, la cual es una actividad consumidora de tiempo.

• Tanto la Ingeniería Inversa como la Reingeniería en la mayoría de las licencias de Software se encuentran penadas por la ley.

Actividad• Realizar el proceso de Ingeniería inversa de los

siguientes modelos de avión.

• Se debe obtener como resultado un prototipo idéntico (30%) al dado así como su manual de diseño (70%).

Javadoc• Es el estándar para crear documentación para los

proyectos en Java.

• Es una herramienta estándar del JDK de Sun Microsystem. Crea documentación en HTML y casi cualquier IDE lo hace.

• Se deben utilizar los comentarios especiales /** …..*/ con algunas palabras clave para determinar la documentación.

Javadoc• Las palabras clave inician con una arroba.

• Se puede incrustar cualquier etiqueta de HTML para hacer más visible la documentación.

• @author nombre_desarrollador• @deprecated descripción //indica un método

que no se utiliza su uso

Javadoc• @param nombre descripción• @return descripción //no se debe utilizar con

métodos void.• @see referencia //asocia con otro elemento el

cual puede ser: #método(); clase#método(); paquete#método(); paquete.clase#método().

• @throws clase descripcion• @version versión

Javadoc• La documentación se crea de la siguiente forma:

javadoc archivo.java

• En NetBeans se puede encontrar la opción en el menú Build en la opción Generate JavaDoc for …

• Se recomienda realizar tanto el código como las clases en inglés.

Javadoc/** * Thrown to indicate that the application has attempted

to convert * a string to one of the numeric types, but that the string

does not * have the appropriate format. * * @author unascribed * @version 1.16, 02/02/00 * @see java.lang.Integer#toString()

Javadoc

* @since JDK1.0 */ public class NumberFormatException extends

IllegalArgumentException { /** * Constructs a <code> NumberFormatException

</code> with no detail message. */ public NumberFormatException () { super(); }

Javadoc

/** * Constructs a <code> NumberFormatException

</code> with the * specified detail message. * @param s the detail message. */ public NumberFormatException (String s) { super

(s); } }

Ofuscación

• La ofuscación es una técnica avanzada de refactorización que permite a un código mantenerle obscuro (es decir no muy legible) con diversos propósitos de optimización.

• ¿Para que se hace ofuscación?

• ¿No viola esto el principio de claridad en la implantación?

Ofuscación

• La ofuscación se realiza en muchas casos para hacer un código ilegible, también en muchos casos se puede reducir el tamaño del código fuente y del código binario realizado.

• Al realizar cualquier tipo de programa se puede aplicar técnicas de reingeniería como la ingeniería inversa para de un código binario tratar de obtener su código fuente.

Ofuscación

• En mucho tipos de aplicaciones como las aplicaciones móviles se ofusca el código objeto generado para obtener un código más pequeño.

• Un programa puede ser fácilmente decompilable, por este motivo se ofusca con la premisa de que si esto llegará ocurrir, el que lo hiciera le costaría mucho trabajo entender el programa y modificarlo.

Ofuscación• En el caso de programas ejecutables (.exe) es

mucho más difícil obtener un código en lenguaje de alto nivel, dado que el proceso de decompilación deja sus resultados en ensamblador y por lo tanto es necesario saber como el compilador ensambla cada línea de código. Por este motivo muchas empresas grandes del sector informático realizan sus proyectos en sus propios compiladores.

Ofuscación

• Actualmente la ofuscación se emplea más en la ofuscación de código dinámico, dado que aquí es muy importante tanto el tamaño del código como la legibilidad de este, tal es el caso de HTML.

• La ofuscación si bien es cierto viola principios de buena prácticas de Ing. de Software, se realiza con un propósito específico hasta el final del proceso.

Ofuscación• En algunos casos la ofuscación se logra

simplemente refactorizando el nombre de las variables pero en muchos casos esto no sirve.

• Para lograr la ofuscación se deberá modificar el flujo del programa de tal forma que menos instrucciones o en algunos casos más instrucciones deben de realizar el mismo programa.

Ofuscación

• En algunos casos resulta que ofuscar el código puede ser que el tamaño del código fuente y del programa aumente, debido a que es común que las variables tengan nombres muy grandes o bien se incluyan instrucciones extras, se descompongan ciclos, se cambien y mapeen estructuras, etc.

• Existen concursos de ofuscación de código

Ofuscación

Actividad

• De un programa en Java o C/C++ realizar ofuscación al código de manera manual de tal forma que tengan dos versiones del código:

• Una versión de programa optimizada que ocupa menos tamaño su código fuente (30%).

• Una versión del programa cuyo código es no legible (mayor su tamaño fuente) (30%).

Actividad• Se deberá calcular el % de disminución y de

aumento del tamaño del código fuente y objeto.

• Una vez creados las nuevas modificaciones, se distribuirán los códigos de otros compañeros para que intenten deducir que realiza el programa.

Actividad

• Se deberá tomar el tiempo que tardarán en realizar la clarificación del programa (30%).

• Se deberá entregar el código en claro y una explicación en notación de diseño (cualquiera que gusten) de lo que el programa realiza. Posteriormente se realizará la comprobación del diseño de sus otros compañeros (estas actividades son en otra sesión de clases).

Pruebas y depuración• La fase de prueba se realiza una vez integrado

cada uno de los módulos del sistema.

• La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración• Una vez identificado los errores en la fase de

pruebas, se procede a corregirlos. A esta fase se le llama depuración.

• En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Pruebas y depuración• La fase de prueba se realiza una vez integrado

cada uno de los módulos del sistema.

• La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración• Una vez identificado los errores en la fase de

pruebas, se procede a corregirlos. A esta fase se le llama depuración.

• En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Depuración• Es la detección, corrección y eliminación de

errores de software.

• El tener un plan de pruebas ayuda a clarificar el proceso de depuración.

• El plan de pruebas debe de estar mucho antes de la construcción del software.

Depuración• Existen muchos tipos de pruebas dependiendo de la

labor y características de cada una de ellas.

• Pruebas Alfa: se realizan por el usuario final en un ambiente controlado.

• Pruebas Beta: se realizan por el usuario sin controlar el ambiente.

Depuración• A continuación se mencionan algunas características

deseables que deben contener los planes de prueba:

• Diseñar un caso de prueba para cada funcionalidad del software.

• Establecer como mínimo un caso de prueba de datos correcto.

Depuración• Establecer como mínimo un caso de prueba de

datos incorrecto.

• Ejemplo: Caso de Prueba de un módulo de raíz cuadrada.

• Qué el usuario ingrese un número mayor que 0.

Depuración• Qué el usuario ingrese un número 0

• Qué el usuario ingrese un número menor que 0.

• Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.

Depuración• Al realizar la depuración de un programa existe la

posibilidad de un 50% de cometer otro error.

• Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.

Depuración• Se recomienda probar lo antes posible cualquier

fragmento de código.

• Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.

Depuración• Las pruebas de caja blanca también llamadas

transparentes se concentran en lo que es el código fuente.

• No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos

Depuración• Las pruebas de segmentos son bloques de

instrucciones.

• Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.

Depuración• Son pruebas funcionales y no interesa como se realizan

las cosas sólo que el resultado obtenido sea el correcto.

• Se recomienda que sean los usuarios quienes las realicen.

• Existen diversas filosofías de pruebas como la programación defensiva.

Depuración• La programación defensiva es una técnica de

probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás.

• Se codifica el esqueleto de la aplicación.

• Se realizan pruebas.

Depuración• Se corrigen los errores y se vuelven a hacer

pruebas.

• Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.

Depuración• Existen otros tipos de prueba como:

• Pruebas de unidad: se encargan de un módulo de software en particular.

• Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.

Depuración• Existen otro tipos de prueba como las de

aceptación que están más involucradas en el concepto en sí que en el desarrollo.

• También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.

Depuración• La mayoría de los IDEs modernos presentan

frameworks para la depuración desde el clásico step by step o step over sobre cada uno de los módulos hasta la realización de pruebas de unidad.

• Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.

Guía para la Prueba de Programas• Se necesita especificar las salidas o resultados

esperados.

• Un programador debe de evitar probar sus propios programas.

• Una organización no debe de probar sus propios programas. 75

Guía para la Prueba de Programas• Inspeccionar los resultados obtenidos de cada

prueba.

• Los casos de prueba deben escribirse con condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas.

76

Guía para la Prueba de Programas• Examinar un programa para verificar que hace lo

que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer.

• No realizar planeaciones asumiendo que no se encontrarán errores.

77

Guía para la Prueba de Programas• La probabilidad de la existencia de mas errores en

una sección de un programa es proporcional al número de errores encontrados en esa sección.

• La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora.

78

Guía para la Prueba de Programas• Se debe de realizar una lista de verificación para

inspecciones de prueba que contenga los siguientes puntos:

• Datos• Declaración de datos• Errores computacionales• Errores de comparación 79

Guía para la Prueba de Programas• Errores de control de flujo• Errores de Interface• Errores de Entrada/Salida

• Se pueden utilizar métodos deductivos e inductivos para la prueba de software.

80

Depuración por Inducción

• Se siguen los siguientes pasos:

• Localizar los datos pertinentes• Organizar los datos• Estudiar las relaciones• Divisar las hipótesis• Probar las hipótesis• Corregir el error

81

Depuración por Deducción• Enumerar las posibles causas• Usar procedimientos de eliminación• Refinar las hipótesis restantes• Probar las hipótesis restantes• Si no se pueden probar las hipótesis entonces

coleccionar más datos y repetir el proceso• En caso contrario corregir el error

82

XP eXtreme Programming

• Se tienen doce principios básicos:

• Planeación y requerimientos• Entregas pequeñas e incrementales• Metáforas de Sistemas• Diseños simples• Pruebas continuas• Refactorización

83

XP eXtreme Programming• Programación en pares• Propiedad colectiva del código• Integración Continua• Semanas de 40 horas• Clientes como miembros del equipo• Codificar con estándares

84

Extreme Testing• Las programación extrema tienen las siguientes

ventajas en lo que respecta al proceso de pruebas:

• Se gana confianza ya que el código debe cumplir las especificaciones.

• Se tiene el resultado final del código antes de codificar

85

Extreme Testing• Se entiende mucho mejor las especificaciones y

requerimientos de la aplicación.

• Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones.

86

Plan de Pruebas• Se recomienda utilizar la metodología y formatos

del estándar IEEE 829 para documentación de pruebas de software:

• Pasos que incluye:

• Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas)

87

Plan de Pruebas• Introducción (en que consiste las pruebas del

sistema)• Elementos a probar• Características a ser probadas• Características que no se probarán• Enfoque• Criterio de fallo o aceptación de los elementos

88

Plan de Pruebas• Criterio de Suspensión y Reanudación de

requerimientos• Entregables de las pruebas• Tareas de las pruebas• Necesidades del entorno• Responsabilidades• Equipo y necesidades de capacitación• Agenda 89

Plan de Pruebas• Riesgos y contingencias• Acuerdos

• A las pruebas se les ha empezado a llamar de manera formal verificación y validación.

• Existen metodologías más robustas como el TMMI (Test Maturity Model) 90

Plan de pruebas91

Ejemplo92

Referencias• Myers, et al. (2004), “The Art of Software

Testing”, Wiley, Estados Unidos, 2004, ISBN: 0-471-46912-2

93

¿Preguntas, dudas y comentarios?