UP: Construccin

1
UP Construcción

• M.C. Juan Carlos Olivares Rojas

jolivares_at_uvaq.edu.mx http//antares.itmorelia.edu
.mx/jcolivar 2009
2
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.

3
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.

4
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.

5
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.

6
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.

7
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.

8
Navegación

• Otras de las mejoras en los IDEs 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.

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

10
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.

11
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).

12
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.

13
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.

14
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.

15
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.

16
Notación Húngara
17
Notación húngara

• int nTest
• long lTemp
• char szString "Prueba"
• struct Rect srRect
• int nMiVariableEjemplo
• char szEjemploString
• int NNOMBREINVALIDO
• int nNombre_Incorrecto

18
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.

19
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.

20
Notación de Camello

• 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.

21
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.

22
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.

23
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.

24
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.

25
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.

26
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.

27
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.

28
Reuso

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

29
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.

30
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.

31
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.

32
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

33
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

34
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.

35
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.

36
Javadoc

• Las palabras clave inician con una arroba.
• Se puede incrustar cualquier etiqueta de HTML
  para hacer más visible la documentación.
• _at_author nombre_desarrollador
• _at_deprecated descripción //indica un método que no
  se utiliza su uso

37
Javadoc

• _at_param nombre descripción
• _at_return descripción //no se debe utilizar con
  métodos void.
• _at_see referencia //asocia con otro elemento el
  cual puede ser método() clasemétodo()
  paquetemétodo() paquete.clasemétodo().
• _at_throws clase descripcion
• _at_version versión

38
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.

39
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.
• _at_author unascribed
• _at_version 1.16, 02/02/00
• _at_see java.lang.IntegertoString()

40
Javadoc

• _at_since JDK1.0
• /
• public class NumberFormatException extends
  IllegalArgumentException
• /
• Constructs a ltcodegt NumberFormatException
  lt/codegt with no detail message.
• /
• public NumberFormatException () super()

41
Javadoc

• /
• Constructs a ltcodegt NumberFormatException
  lt/codegt with the
• specified detail message.
• _at_param s the detail message.
• /
• public NumberFormatException (String s) super
  (s)

42
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?

43
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.

44
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.

45
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.

46
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.

47
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.

48
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

49
Ofuscación
50
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.

51
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.

52
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.

53
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.

54
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.

55
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.

56
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.

57
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.

58
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.

59
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.

60
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.

61
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

62
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.

63
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.

64
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.

65
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.

66
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.

67
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.

68
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.

69
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.

70
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.

71
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.

72
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.

73
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

74
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.

75
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

76
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

77
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

78
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

79
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

80
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.

81
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)

82
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

83
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

84
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)

85
Plan de pruebas
86
Ejemplo
87
Referencias

• Myers, et al. (2004), The Art of Software
  Testing, Wiley, Estados Unidos, 2004, ISBN
  0-471-46912-2

88
Preguntas, dudas y comentarios?