UNIVERSIDAD AUTONOMA DE CHIHUAHUA            FACULTAD DE INGENIERIA        Análisis de correctitud  Modelado y análisis de...
ContenidoObjetivo............................................................................................................
ObjetivoEl objetivo es indagar en los temas de la exposición la mayoría de la información seencuentra dentro de temas impo...
El analizador estático de código recibirá el código fuente de nuestro programa, loprocesará intentando averiguar qué es lo...
Las etapas implicadas en el análisis estático comprenden:   1.Análisis del flujo de control. Esta etapa identifica y resalta...
Análisis automatizadopuede ser realizado con una mayor periodicidad ya que no requiere de intervenciónhumana y, lo que es ...
Para recordar un poco de este ciclo colocamos lo siguiente, remarcando el tercerpunto:Ventajas:   ●Inclusión de de análisi...
PrototipadoHerramientas de gestión de prototipoLos prototipos son utilizados ampliamente en el desarrollo de aplicaciones,...
• La verificación no asegura el modelo:- Resuelve un problema importante- Cumple con un conjunto específico de requisitos de...
ReferenciasJintao Pan (1999) Software testing ece.cmu.edu/. Recuperado el 2 de Octubre del 2011http://www.ece.cmu.edu/~koo...
Upcoming SlideShare
Loading in …5
×

Software Correctness

583 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
583
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Correctness

  1. 1. UNIVERSIDAD AUTONOMA DE CHIHUAHUA FACULTAD DE INGENIERIA Análisis de correctitud Modelado y análisis de requerimientos del software Equipo No. 4 225654 Canales Tarango Irving Manuel 225673 Najera Chavira Daniel Giovanni 225690 Ibarra Garcia Carlos Antonio Octubre - 2011El documento pretende describir y recordar temas anteriores que hemos visto durante lacarrera, en el documento usted observara diagramas, se dará una descripción y se daránreferencias para indagar mas en el tema.
  2. 2. ContenidoObjetivo.................................................................................................................................3!Introducción..........................................................................................................................3Desarrollo.............................................................................................................................3!! Análisis de correctitud................................................................................................3! !! ! Simulación y prototipado............................................................................................6! Verificación del modelo..............................................................................................8Conclusión............................................................................................................................9Recomendaciones................................................................................................................9Referencias.........................................................................................................................10 2
  3. 3. ObjetivoEl objetivo es indagar en los temas de la exposición la mayoría de la información seencuentra dentro de temas importantes que corresponden a la ingeniería de software, losapartados son sumamente precisos se recolecto un gran numero de información con elobjetivo de extraer y asociar lo mejor para que el interesado comprenda de una mejormanera los temas.IntroducciónAl momento en que analizamos inspeccionamos con la finalidad de entender laspropiedades y las capacidades de ese algo en el que indagamos.En términos de software el análisis caracteriza a un grupo de ejecución. También estábasado en un modelo del producto en lugar del propio producto, así abstrae elementosque podrían ser cruciales. DesarrolloAnalisis de correctitud (Correctness):Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación delas funciones (especificación de requerimientos funcionales) que debería proveer. Estadefinición de correctitud asume que existe una especificación de requerimientosfuncionales del sistema y que es posible determinar en forma no ambigua si las cumple ono. Se presentan diversas dificultades cuando no existe dicha especificación, o si existepero está escrita informalmente utilizando, por ejemplo, lenguaje natural por lo que esposible que contenga ambiguedades.La correctitud es una propiedad matemática que establece la equivalencia entre elsoftware y su especificación, por lo que cuanto más riguroso se haya sido en laespecificación, más precisa y sistemática podrá ser su evaluación. Posteriormente severá que la correctitud puede ser evaluada mediante diversos métodos, algunos deenfoque experimental como las pruebas, otros de enfoque analítico como verificaciónformal de la correctitud. Es de notar que esta definición de correctitud no toma enconsideración el que la especificación en sí misma puede ser incorrecta por contenerinconsistencias internas, o no corresponder de forma adecuada a las necesidades paralas que fue concebido el programa.Análisis Estático (Somerville, 2005)Un análisis estático es la examinación de un programa sin ejecutarlo. Las inspecciones amenudo están dirigidas por listas de comprobación de errores y heurísticas que identificanerrores comunes en diferentes lenguajes de programación.Por lo tanto, es una técnica que se aplica directamente sobre el código fuente tal cual, sintransformaciones previas ni cambios de ningún tipo. La idea es que, en base a ese códigofuente, podamos obtener información que nos permita mejorar la base de códigomanteniendo la semántica original. 3
  4. 4. El analizador estático de código recibirá el código fuente de nuestro programa, loprocesará intentando averiguar qué es lo que queremos que haga y nos dará sugerenciascon las que podamos mejorar ese código.Básicamente al realizar un análisis estático, se obtiene una facilidad de mantenimiento yde desarrollo, ya que su objetivo es minimizar la deuda técnica del proyecto.Algunas comprobaciones que se pueden detectar mediante análisis estático son:Encontrar partes de codigo que puedan ●Reducir el rendimiento. ●Provocar errores en el software. ●Complicar el flujo de datos. ●Tener una excesiva complejidad. ●Suponer un problema en la seguridad. Clase de defecto Comprobación del análisis estático Defectos de datos Variables utilizadas antes de su inicialización. Variables declaradas pero nunca utilizadas. Variables asignadas dos veces pero nunca utilizadas entre asignaciones. Posibles violaciones de los límites de los vectores. Variables no declaradas. Defectos de control Código no alcanzable. Saltos incondicionales en bucles. Defectos de entrada/salida Las variables salen dos veces sin intervenir ninguna asignación. Defectos de interfaz Inconsistencias en el tipo de parámetros. Inconsistencias en el número de parámetros. Los resultados de las funciones no se utilizan. Existen funciones y procedimientos a los que no se les llaman. Defectos de gestión de almacenamiento Punteros sin asignar. Aritmética de punteros. 4
  5. 5. Las etapas implicadas en el análisis estático comprenden: 1.Análisis del flujo de control. Esta etapa identifica y resalta bucles con múltiples salidas o puntos de entrada y código no alcanzable. El código no alcanzable es código que se salta con instrucciones goto no condicionales o que está en una rama de una sentencia condicional en la que la condición nunca es cierta. 2.Análisis del uso de los datos. Esta etapa revela cómo se utilizan las variables del programa. Detecta variables que se utilizan sin inicialización previa, variables que se asignan dos veces y no se utilizan entre asignaciones, y variables que se declaran pero nunca se utilizan. El análisis del uso de los datos también descubre pruebas inútiles cuando la condición de prueba es redundante. Las condiciones redundantes son condiciones que son siempre ciertas o siempre falsas. 3.Análisis de interfaces. Este análisis comprueba la consisitencia de las declaraciones de funciones y procedimientos y su utilización. No es necesario si se utiliza para la implementación un lenguaje fuertemente tipado como Java, ya que el compilador lleva a cabo estas comprobaciones. El análisis de interfaces puede detectar errores de tipos en lenguajes débilmente tipados como C. El análisis de interfaces también puede detectar funciones y procedimientos que se declaran y nunca son llamados o resultados de funciones que nunca se utilizan. 4.Análisis del flujo de información. Esta fase del análisis identifica las dependencias entre las variables de entrada y salida. Mientras no detecte anomalías, muestra cómo se deriva el valor de cada variable del programa a partir de otros valores de variables. Con esta información, una inspección de código debería ser capaz de encontrar valores que han sido calculados erróneamente. El análisis de flujo de información puede tambien mostrar las condiciones que afectan al valor de una variable. 5.Análisis de caminos. Esta fase del análisis semántico identifica todos los posibles caminos en el programa y muestra las sentencias ejecutadas en dicho camino. Esencialmente desenreda el control del programa y permite que cada posible predicado sea analizado individualmente.Los analizadores estáticos son particularmente valiosos cuando se utiliza un lenguaje deprogramación como C. Este lenguaje no tiene reglas de tipo estrictas, y la comprobaciónque puede hacer el compilador es limitada. Por lo tanto, es fácil para los programadorescometer errorres, y la herramienta de análisis estático puede automáticamente descubrirun gran numero de errores potenciales y reducir los costes de prueba de formasignificativa.Por otro lado los lenguajes de programación modernos como Java han eliminado algunascaracterísticas propensas a error. Todas las variables deben ser inicializadas; no haysentencias goto, y la gestion de almacenamiento es automática.Esta aproximación paraevitar errores en llugar de detectarlos es mas efectiva a la hora de mejorar la fiabilidad delprograma.Análisis manualDeberíamos tratar de realizar el análisis manual cada vez que vayamos a crear una nuevafuncionalidad en nuestro software, preguntándonos en este caso si la arquitectura actualnos permite implementarla con facilidad, si disponemos de las librerías adecuadas o sipodemos modificar la base de nuestro código para facilitar el desarrollo de esta nuevafuncionalidad. Es decir, lo reservaremos para situaciones concretas. 5
  6. 6. Análisis automatizadopuede ser realizado con una mayor periodicidad ya que no requiere de intervenciónhumana y, lo que es mejor, puede ser programado y repetido tantas veces como seanecesario. Además obra con objetividad, siempre nos va a devolver la misma respuestaante el mismo código fuente de entrada. (Exposito, 2010)Simulación y prototipadoLas herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero delsoftware la capacidad de predecir el comportamiento de un sistema en tiempo real antesde llegar a construirlo. Además, capacitan al ingeniero del software para desarrollarsimulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca desu funcionamiento, comportamiento y respuesta antes de la verdadera implementación.Debemos ubicarnos en el ciclo de vida en espiral, a en la siguiente pagina remarcamosdonde nos encontramos como ingenieros de software: 6
  7. 7. Para recordar un poco de este ciclo colocamos lo siguiente, remarcando el tercerpunto:Ventajas: ●Inclusión de de análisis de riesgos a lo largo del proceso ●Desarrollo de software = proceso evolutivo ●Uso de prototipos, uso de simulaciones ●El cliente ve evolucionar el proyecto ●Tratamiento del mantenimiento al mismo nivel que el desarrollo (se trata de otra espiral más)Problemas: ●Difícil de convencer al cliente de su utilidad (hay que realizar muchos tests y esto cuesta dinero) ●Implantación muy compleja ●Necesita gran habilidad en la valoración de riesgos ●Método muy nuevo 7
  8. 8. PrototipadoHerramientas de gestión de prototipoLos prototipos son utilizados ampliamente en el desarrollo de aplicaciones, para laevaluación de especificaciones de un sistema de información, o para un mejorentendimiento de cómo los requisitos de un sistema de información se ajustan a losobjetivos perseguidos.Ciclo de vida con prototipadoVentaja ●Mejora la comunicación analista - cliente ●Mejor identificación de los requerimientos del cliente ●Satisface la curiosidad del cliente (en seguida puede ver cosas)Problemas ●Identificación del prototipo con el producto final ●Prototipo no reaprovechable ●Técnicas inapropiadas con el fin de prototipar más rápidamenteVerificacion del modeloUno de los mayores retos de a los que se enfrentan los proyectos de ingeneria es elcreciente tamano y la complejidad de los sistemas.La verificación se hace para asegurar que:- El modelo está programado correctamente- Los algoritmos se han implementado correctamente- El modelo no contiene errores, omisiones o errores• La verificación asegura que la especificación es completa y que los errores no se hanimplementado en la aplicación del modelo 8
  9. 9. • La verificación no asegura el modelo:- Resuelve un problema importante- Cumple con un conjunto específico de requisitos del modelo- Refleja correctamente el funcionamiento del mundo real.Verificacion formal y metodos formalesLa verificación formal evalúa la exactitud de los algoritmos que se basa el sistema.Verificación de software evalúa qué tan bien software satisface los requisitos definidos y laverificación de los modelos evalúa la correctitud de los modelos. Los metodos formales sebasan en representaciones matematicas del software, normalmente como unaespecificacion formal.Los metodos formales requieren un análisis muy detallado de las especificacion delsistema y del programa, y su uso consume a menudo tiempo y resulta caro.Estos metodos formales se ocupan principalmente del analisis matematico de laespecificacion; de transformar la especificacion a una representacion mas detalladasemanticamente equivalente o de verificar formalmente que una representacion delsistema es semanticamente equivalente a otra representacion.Los metodos formales pueden utilizarse en diferentes etapas en el proceso V&V: 1.Puede desarrollarse una especficacion formal del sistema y analizarse matematicamente para buscar inconsistencias. Esta tecnica es efectiva para descrubir errores y omisiones de especificacion. 2.Puede verificarse formalmente, utilizando argumentos matematicos, que el codigo de sistema software es consistente con su especificacion. Esto requiere una especificacion formal y es efectiva para descubrir algunos errores de diseno y programacion.El objetivo final de la verificacion del modelo es que proporciona informacion precisa,informacion sobre el sistema que se modela y hace que el sistema se utilice.ConclusiónEl equipo logro recordar procesos de la ingeniería de software que estudiamos ensemestres anteriores, indagamos de una manera mas profunda en procesos masespecíficos y nos dimos cuenta de que el buen modelado es parte fundamental para la elproceso de desarrollo de software.RecomendacionesQueremos hacer la invitación a que vean la siguiente presentación http://webdiis.unizar.es/~zarazaga/workPage/docencia/ingSoft1/trasparencias/is1_01.pdf y asítener una mejor noción del por que de la materia y en que parte o mas bien dicho fasenos estudiando la ingeniería de software. 9
  10. 10. ReferenciasJintao Pan (1999) Software testing ece.cmu.edu/. Recuperado el 2 de Octubre del 2011http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/Monzon Diaz, J.L Fernandez Sanchez (2006) Decimo congreso internacional de ingenieriade proyectos ppooa.com.es/ Recuperado el 2 de Octubre del 2011 http://www.ppooa.com.es/vmis.pdfSomerville, I. (2005). INGENIERÍA DEL SOFTWARE. Séptima edición. Madrid: PEARSONEDUCACIÓN.Exposito, R. (2010). RaulExposito.com. Recuperado el 4 de Octubre del 2011, de http://raulexposito.com/files/documentos/AnalisisEstaticoCodigo.pdfE-Clases (2004) eclases.tripod.com/ Recuperado el 3 de octubre del 2011 http://eclases.tripod.com/id12.htmlF. Javier Zarazaga Soria y Javier Nogueras Iso (2008) Introduccion a la ingenieria desoftware http://webdiis.unizar.es/ Recuperado el 3 de Octubre del 2011 http://webdiis.unizar.es/~zarazaga/workPage/docencia/ingSoft1/trasparencias/is1_01.pdf 10

×