ELABORADO POR TODOS
MENOS
*JOSE LUIS GOMEZ PERALTA
*ROBERTO MENDOZA
MENOS
*JOSE LUIS GOMEZ PERALTA
*ROBERTO MENDOZA
SOFTWARE ANALYSIS: A ROADMAP
ABSTRACT
A lo largo del artículo se habla del ‘analisis’ como la información referente al comportamiento del software, representado como un modelo abstracto o código.
ANALISIS VS DESCRIPTION
Con respecto al análisis de los modelos de sistemas, nos dice que es recomendable aplicar el análisis, que desarrollar simplemente el sistema, ya que realizar un análisis, antes de introducir el código, nos sirve para detectar problemas que podrían causarnos dificultades y costarnos mucho más si no se descubren en ese momento.
Los investigadores que trabajan sobre modelos abstractos se pueden dividir en 2, unos son los desarrolladores de Z, quienes se centran en la forma de el modelo y consideran al análisis como algo secundario; por otro lado están los desarrolladores de la revisión del modelo simbólico, que se centran en el análisis y prestan menos atención a la manera en la que se expresa el modelo.
Por su parte los exponentes del análisis argumentan que la motivación principal para tomar decisiones sobre el diseño es explorando sus consecuencias por medio del análisis, diseñar un lenguaje sin un análisis en mente es como diseñar un lenguaje de programación que no puede ser compilado. Por otra parte los exponentes de la descripción o forma del modelo, dicen que en el desarrollo del software el obstáculo principal no es encontrar los fallos ocultos, si no más bien definir los pasos del desarrollo, con notas que expresen con precisión las intenciones del desarrollador y sólo eso.
GLOBAL VS LOCAL
Por lo regular nos encontraremos con que el método orientado a objetos se refiere a modelados de objetos que nos muestran qué objetos existen y cómo se encuentran relacionados y declaran diagramas de transición, que muestran los estados de los objetos y las transiciones entre ellos .
Existen 2 tipos de modelos que dominan la descripción abstracta del software.
El primer tipo de modelo nos dice que el modelado de objetos es estático y los diagramas de transición son dinámicos. El modelado de objetos, regularmente no es más que diagramas de clases, mostrando las clases, las subclases y las relaciones entre ellas. Un diagrama de clases es una representación parcial de la estructura sintáctica del código, y en ese sentido es estático en comparación a un diagrama de transición que describe estados de tiempo de ejecución.
El otro tipo de modelo dice que los modelados de objetos son ‘información intensiva’ y los diagramas de transición son ‘control intensivo.
Los 2 tipos de modelos anteriores también podrían ser vistos como ‘global’ y ‘local’.
El modelado de objetos, describe las relaciones de forma global entre los elementos del sistema, sus estados son las configuraciones globales de objetos y sus transiciones son los cambios globales que resultan de los objetos que vienen y van, así como de las relaciones que son cambiadas. Por otro lado el diagrama de transición describe los estados de un objeto individual y el protocolo de interacciones entre objetos.
En un modelo global, el estado del sistema, como un todo, es directamente expresado, en un modelo local, el estado global surge de las definiciones de los estados locales.
SIMULATION VS CHEKCING
El chequeo o comprobación de un modelo es mucho más efectivo que una simulación en la exposición de errores sutiles. Sin embargo la simulación es demasiado útil. Construyendo un modelo incrementalmente, es fácil cometer errores que la simulación expone fácilmente.
La mayor parte de los programadores, tienen más confianza en su código cuando han visto algunos ejemplos de ejecución, esto es un fenómeno muy común. La experiencia nos dice que un modelo que ha sido simulado tiene menos posibilidades se contener errores notorios.
Uno de los motivos por los que la simulación ha sido subvalorada es que la comprobación tiene mejores resultados. Los inventores de herramientas para la comprobación de modelos están obligados a exponer por lo menos un ejemplo de un error sutil que fue detectado en un sistema real.
La comprobación será crucial, no sólo asegurar que el modelo está correcto, si no también establecer una correspondencia entre el código y su modelo abstracto
VERIFICATION VS REFUTATION
Debido a que la comprobación raras veces puede ser automatizada, existen 2 opciones: verificación o refutación.
La verificación consiste en un análisis intentando encontrar una prueba para la propiedad dada. Si no se encuentra ninguna prueba, la propiedad aun puede ser válida, pero dichos análisis muy poco probablemente fallan, de modo que permiten al usuario determinar si es la estrategia de prueba o el modelo en si, lo que está fallando.
La refutación consiste en un análisis intentando refutar la propiedad dada encontrando un contraejemplo. Tales análisis por lo general emplean alguna forma de búsqueda en un espacio que ha sido artificialmente limitado. Si ningún contraejemplo es encontrado, entonces el límite era inapropiado (esto es, existen contraejemplos fuera del espacio buscado), o la propiedad no es válida.
DECLARATIVE VS OPERATIONAL STYLE
La mayor parte de lenguajes para modelos globales como Z, VDM y Larch son declarativos. En un lenguaje declarativo, constantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, como Statecharts y Promela, tienden a ser más operacionales, definiendo transiciones de una manera programática.
Los lenguajes operacionales corren el riesgo de las tendencias de ejecución, pero los modelos locales rara vez sufren de ello. La división del sistema como un todo en componentes que se comunican, es desde luego un paso de diseño intencional.
Los lenguajes declarativos traen varias ventajas a los modelos globales, para empezar, el modelo no tiene que determinar el comportamiento del sistema completamente. Para sistemas reactivos, esta forma a veces es vista como una deficiencia, pero en otros modelos es a menudo apropiado.
SOUND VS UNSOUND
Los análisis sólidos (sound) estáticos producen información que es garantizada para aguantar todas las ejecuciones de programas, los análisis sólidos dinámicos producen información que es garantizada para aguantar solamente la ejecución analizada.
Los análisis poco sólidos (unsound) no proporcionan tales garantías.
Un análisis sólido, para determinar los valores potenciales de las variables globales, por ejemplo, podría usar un análisis indicador para asegurar que modela correctamente el efecto de las asignaciones indirectas que ocurren vía indicadores de variables globales.
Un análisis poco sólido simplemente podría explorar el programa para localizar y analizar sólo las tareas que usan la variable global directamente, por nombre. Puesto que tal análisis ignora el efecto de tareas indirectas, puede fallar en calcular todos los valores potenciales de variables globales.
La solidez de un análisis puede depender de las características del lenguaje de programación, si el programa usa ciertas características o no.
Las ventajas más importantes de los análisis poco sólidos son la facilidad con que pueden ser puestos en práctica, así como su eficacia. Un análisis poco sólido puede ser capaz de analizar programas que simplemente van más allá del alcance de un análisis sólido, y puede ser implementado en poco tiempo y esfuerzo en comparación de un análisis sólido.
SPEED VS PRECISION
FLOW-SENSITIVE VS FLOW INSENTIVE
Los análisis sensibles a flujo (flow-sensitive) toman en cuenta la orden de ejecución de las declaraciones del programa. Normalmente usan alguna forma de análisis de flujo de datos iterativo para producir un resultado de análisis potencialmente diferente para cada punto de programa.
Los análisis insensibles a flujo (flor-insentive) no toman en cuenta la orden de ejecución de las declaraciones del programa y son por tanto incapaces de extraer cualquier propiedad que dependa de esta orden. Regularmente usan alguna forma de análisis de tipo basada en producir un resultado de análisis que es válido para el programa entero.
A la larga, se espera que los análisis sensibles a flujo, en combinación con la información de diseño, jueguen el papel principal en el análisis de sistemas de software infraestructurales. Considerando su eficiencia y la facilidad relativa de uso, los análisis insensibles a flujo serán destacados en contextos donde el ingeniero debe confiar principalmente o exclusivamente en el código.
CONTEXT-SENSITIVE VS CONTEXT-INSENTIVE
Un análisis de contexto insensible (context-insentive) produce un solo resultado que es usado directamente en todos los contextos. Un análisis de contexto sensible (sensitive-context) produce un resultado diferente para cada contexto de análisis diferente.
La sensibilidad del contexto es esencial para analizar programas modernos en los cuales las abstracciones son penetrantes. Por lo tanto la futura investigación en el campo, probablemente se enfoque en los análisis de contexto sensible.
MULTITHREADED VS. SINGLETHREADED
En un programa multithreaded (con múltiples hilos), las corrientes de instrucción de varios hilos se pueden intercalar de maneras diferentes. Los algoritmos de análisis de flujo de datos clásicos simplemente no fueron diseñados para este modelo de cómputo.
Considerando la importancia de los hilos (threads) en los lenguajes modernos, se cree que el análisis de programas con múltiples hilos (multithreaded) se hará un área de investigación activa. También se cree que los lenguajes de modelado jugaran un papel importante en este campo y preverá el desarrollo de lenguajes de diseño para expresar propiedades importantes de los programas multithreaded, como la política de sincronización y el compartir las propiedades de objetos y datos.
MODEL-DRIVEN CODE ANALYSIS
El análisis estático puede ayudar al modelado, el valor de los modelos será enormemente sostenido si su correspondencia al código puede ser firmemente establecida. Los modelos pueden ayudar al análisis estático también. Existe un tercer elemento crucial en este acercamiento, más allá del modelado y el análisis: trazar un mapa para conectar los 2.
MODULAR ANALYSIS BY INDUCTION
En vez de analizar el programa entero como una unidad monolítica, el análisis modular analizará el programa en la granualidad (extensión) de sus componentes.
El modelado de lenguajes se volverá una forma popular para los ingenieros para especificar las propiedades requeridas para análisis modulares. En vez de especificar las propiedades relevantes en un lenguaje lógico de uso general, los ingenieros usarán lenguajes de modelado con un destino especial que son optimizados para expresar aspectos específicos del diseño total del programa así como las relaciones referentes entre objetos o la secuencia del programa de acciones externamente visibles.
GIVING ENGINEERS CONTROL
Los ingenieros necesitan diferentes grados de precisión en distintas situaciones, en diferentes puntos en un programa y para estructuras de datos diferentes. La aplicación de un solo análisis a través de todo el programa es por lo tanto contra productivo. En cambio, los investigadores se moverán en la dirección de análisis que acepten dirección del ingeniero vía lenguaje modelado en cuanto al nivel requerido de precisión.
CONCLUSIONS
En la década pasada, una apreciación para la rentabilidad ha causado que los investigadores identifiquen más cuidadosamente la información que los ingenieros necesitan y encontrar el medio más eficaz para obtenerlo.
Análisis exactos y sólidos se han estado cayendo, ya que sus precios son altos y sus escalas suelen ser pobres. En el futuro varios factores pueden traer tales análisis a la delantera otra vez: la demanda del software confiable, la disponibilidad de bastos recursos computacionales y quizás mas considerablemente, la explotación de modelos abstractos, para enfocar el esfuerzo del análisis donde la rentabilidad sea mayor y permitir el razonamiento modular sobre una gran escala.
ABSTRACT
A lo largo del artículo se habla del ‘analisis’ como la información referente al comportamiento del software, representado como un modelo abstracto o código.
ANALISIS VS DESCRIPTION
Con respecto al análisis de los modelos de sistemas, nos dice que es recomendable aplicar el análisis, que desarrollar simplemente el sistema, ya que realizar un análisis, antes de introducir el código, nos sirve para detectar problemas que podrían causarnos dificultades y costarnos mucho más si no se descubren en ese momento.
Los investigadores que trabajan sobre modelos abstractos se pueden dividir en 2, unos son los desarrolladores de Z, quienes se centran en la forma de el modelo y consideran al análisis como algo secundario; por otro lado están los desarrolladores de la revisión del modelo simbólico, que se centran en el análisis y prestan menos atención a la manera en la que se expresa el modelo.
Por su parte los exponentes del análisis argumentan que la motivación principal para tomar decisiones sobre el diseño es explorando sus consecuencias por medio del análisis, diseñar un lenguaje sin un análisis en mente es como diseñar un lenguaje de programación que no puede ser compilado. Por otra parte los exponentes de la descripción o forma del modelo, dicen que en el desarrollo del software el obstáculo principal no es encontrar los fallos ocultos, si no más bien definir los pasos del desarrollo, con notas que expresen con precisión las intenciones del desarrollador y sólo eso.
GLOBAL VS LOCAL
Por lo regular nos encontraremos con que el método orientado a objetos se refiere a modelados de objetos que nos muestran qué objetos existen y cómo se encuentran relacionados y declaran diagramas de transición, que muestran los estados de los objetos y las transiciones entre ellos .
Existen 2 tipos de modelos que dominan la descripción abstracta del software.
El primer tipo de modelo nos dice que el modelado de objetos es estático y los diagramas de transición son dinámicos. El modelado de objetos, regularmente no es más que diagramas de clases, mostrando las clases, las subclases y las relaciones entre ellas. Un diagrama de clases es una representación parcial de la estructura sintáctica del código, y en ese sentido es estático en comparación a un diagrama de transición que describe estados de tiempo de ejecución.
El otro tipo de modelo dice que los modelados de objetos son ‘información intensiva’ y los diagramas de transición son ‘control intensivo.
Los 2 tipos de modelos anteriores también podrían ser vistos como ‘global’ y ‘local’.
El modelado de objetos, describe las relaciones de forma global entre los elementos del sistema, sus estados son las configuraciones globales de objetos y sus transiciones son los cambios globales que resultan de los objetos que vienen y van, así como de las relaciones que son cambiadas. Por otro lado el diagrama de transición describe los estados de un objeto individual y el protocolo de interacciones entre objetos.
En un modelo global, el estado del sistema, como un todo, es directamente expresado, en un modelo local, el estado global surge de las definiciones de los estados locales.
SIMULATION VS CHEKCING
El chequeo o comprobación de un modelo es mucho más efectivo que una simulación en la exposición de errores sutiles. Sin embargo la simulación es demasiado útil. Construyendo un modelo incrementalmente, es fácil cometer errores que la simulación expone fácilmente.
La mayor parte de los programadores, tienen más confianza en su código cuando han visto algunos ejemplos de ejecución, esto es un fenómeno muy común. La experiencia nos dice que un modelo que ha sido simulado tiene menos posibilidades se contener errores notorios.
Uno de los motivos por los que la simulación ha sido subvalorada es que la comprobación tiene mejores resultados. Los inventores de herramientas para la comprobación de modelos están obligados a exponer por lo menos un ejemplo de un error sutil que fue detectado en un sistema real.
La comprobación será crucial, no sólo asegurar que el modelo está correcto, si no también establecer una correspondencia entre el código y su modelo abstracto
VERIFICATION VS REFUTATION
Debido a que la comprobación raras veces puede ser automatizada, existen 2 opciones: verificación o refutación.
La verificación consiste en un análisis intentando encontrar una prueba para la propiedad dada. Si no se encuentra ninguna prueba, la propiedad aun puede ser válida, pero dichos análisis muy poco probablemente fallan, de modo que permiten al usuario determinar si es la estrategia de prueba o el modelo en si, lo que está fallando.
La refutación consiste en un análisis intentando refutar la propiedad dada encontrando un contraejemplo. Tales análisis por lo general emplean alguna forma de búsqueda en un espacio que ha sido artificialmente limitado. Si ningún contraejemplo es encontrado, entonces el límite era inapropiado (esto es, existen contraejemplos fuera del espacio buscado), o la propiedad no es válida.
DECLARATIVE VS OPERATIONAL STYLE
La mayor parte de lenguajes para modelos globales como Z, VDM y Larch son declarativos. En un lenguaje declarativo, constantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, como Statecharts y Promela, tienden a ser más operacionales, definiendo transiciones de una manera programática.
Los lenguajes operacionales corren el riesgo de las tendencias de ejecución, pero los modelos locales rara vez sufren de ello. La división del sistema como un todo en componentes que se comunican, es desde luego un paso de diseño intencional.
Los lenguajes declarativos traen varias ventajas a los modelos globales, para empezar, el modelo no tiene que determinar el comportamiento del sistema completamente. Para sistemas reactivos, esta forma a veces es vista como una deficiencia, pero en otros modelos es a menudo apropiado.
SOUND VS UNSOUND
Los análisis sólidos (sound) estáticos producen información que es garantizada para aguantar todas las ejecuciones de programas, los análisis sólidos dinámicos producen información que es garantizada para aguantar solamente la ejecución analizada.
Los análisis poco sólidos (unsound) no proporcionan tales garantías.
Un análisis sólido, para determinar los valores potenciales de las variables globales, por ejemplo, podría usar un análisis indicador para asegurar que modela correctamente el efecto de las asignaciones indirectas que ocurren vía indicadores de variables globales.
Un análisis poco sólido simplemente podría explorar el programa para localizar y analizar sólo las tareas que usan la variable global directamente, por nombre. Puesto que tal análisis ignora el efecto de tareas indirectas, puede fallar en calcular todos los valores potenciales de variables globales.
La solidez de un análisis puede depender de las características del lenguaje de programación, si el programa usa ciertas características o no.
Las ventajas más importantes de los análisis poco sólidos son la facilidad con que pueden ser puestos en práctica, así como su eficacia. Un análisis poco sólido puede ser capaz de analizar programas que simplemente van más allá del alcance de un análisis sólido, y puede ser implementado en poco tiempo y esfuerzo en comparación de un análisis sólido.
SPEED VS PRECISION
FLOW-SENSITIVE VS FLOW INSENTIVE
Los análisis sensibles a flujo (flow-sensitive) toman en cuenta la orden de ejecución de las declaraciones del programa. Normalmente usan alguna forma de análisis de flujo de datos iterativo para producir un resultado de análisis potencialmente diferente para cada punto de programa.
Los análisis insensibles a flujo (flor-insentive) no toman en cuenta la orden de ejecución de las declaraciones del programa y son por tanto incapaces de extraer cualquier propiedad que dependa de esta orden. Regularmente usan alguna forma de análisis de tipo basada en producir un resultado de análisis que es válido para el programa entero.
A la larga, se espera que los análisis sensibles a flujo, en combinación con la información de diseño, jueguen el papel principal en el análisis de sistemas de software infraestructurales. Considerando su eficiencia y la facilidad relativa de uso, los análisis insensibles a flujo serán destacados en contextos donde el ingeniero debe confiar principalmente o exclusivamente en el código.
CONTEXT-SENSITIVE VS CONTEXT-INSENTIVE
Un análisis de contexto insensible (context-insentive) produce un solo resultado que es usado directamente en todos los contextos. Un análisis de contexto sensible (sensitive-context) produce un resultado diferente para cada contexto de análisis diferente.
La sensibilidad del contexto es esencial para analizar programas modernos en los cuales las abstracciones son penetrantes. Por lo tanto la futura investigación en el campo, probablemente se enfoque en los análisis de contexto sensible.
MULTITHREADED VS. SINGLETHREADED
En un programa multithreaded (con múltiples hilos), las corrientes de instrucción de varios hilos se pueden intercalar de maneras diferentes. Los algoritmos de análisis de flujo de datos clásicos simplemente no fueron diseñados para este modelo de cómputo.
Considerando la importancia de los hilos (threads) en los lenguajes modernos, se cree que el análisis de programas con múltiples hilos (multithreaded) se hará un área de investigación activa. También se cree que los lenguajes de modelado jugaran un papel importante en este campo y preverá el desarrollo de lenguajes de diseño para expresar propiedades importantes de los programas multithreaded, como la política de sincronización y el compartir las propiedades de objetos y datos.
MODEL-DRIVEN CODE ANALYSIS
El análisis estático puede ayudar al modelado, el valor de los modelos será enormemente sostenido si su correspondencia al código puede ser firmemente establecida. Los modelos pueden ayudar al análisis estático también. Existe un tercer elemento crucial en este acercamiento, más allá del modelado y el análisis: trazar un mapa para conectar los 2.
MODULAR ANALYSIS BY INDUCTION
En vez de analizar el programa entero como una unidad monolítica, el análisis modular analizará el programa en la granualidad (extensión) de sus componentes.
El modelado de lenguajes se volverá una forma popular para los ingenieros para especificar las propiedades requeridas para análisis modulares. En vez de especificar las propiedades relevantes en un lenguaje lógico de uso general, los ingenieros usarán lenguajes de modelado con un destino especial que son optimizados para expresar aspectos específicos del diseño total del programa así como las relaciones referentes entre objetos o la secuencia del programa de acciones externamente visibles.
GIVING ENGINEERS CONTROL
Los ingenieros necesitan diferentes grados de precisión en distintas situaciones, en diferentes puntos en un programa y para estructuras de datos diferentes. La aplicación de un solo análisis a través de todo el programa es por lo tanto contra productivo. En cambio, los investigadores se moverán en la dirección de análisis que acepten dirección del ingeniero vía lenguaje modelado en cuanto al nivel requerido de precisión.
CONCLUSIONS
En la década pasada, una apreciación para la rentabilidad ha causado que los investigadores identifiquen más cuidadosamente la información que los ingenieros necesitan y encontrar el medio más eficaz para obtenerlo.
Análisis exactos y sólidos se han estado cayendo, ya que sus precios son altos y sus escalas suelen ser pobres. En el futuro varios factores pueden traer tales análisis a la delantera otra vez: la demanda del software confiable, la disponibilidad de bastos recursos computacionales y quizás mas considerablemente, la explotación de modelos abstractos, para enfocar el esfuerzo del análisis donde la rentabilidad sea mayor y permitir el razonamiento modular sobre una gran escala.
No hay comentarios:
Publicar un comentario