Análisis y modelado de software

Analisis de software

Analisis de software
El modelado de software puede contribuir más en el futuro ya que últimamente se está invirtiendo mucho en el análisis de software, pues así se pueden evitar errores después de la realización del código que pueden ser muy costosos.

Análisis de modelados abstractos y código

El análisis de modelos

La producción de líneas de código es una medida de desarrollo de productividad común, pero es caro. El código solo sirve si es correcto, por eso, un modelo puede ser estructurado de mejor manera y más efiiente. Esto conlleva a que cualquier posibilidad de analizar el sistema antes de hacerlo debería tomarse en cuenta, especialmente en la temprana edad del mismo, ya que puede exponer errores del sistema que en caso de haberse realizado de ese modo, el error pudo haber costado mucho.

Análisis VS Descripción

Los investigadores que trabajan con modelos abstractos se dividen en dos campos:

-Los que se han enfocado principalmente en el formulario de modelo y han tratado el análisis como secundario, quienes favorecen el razonamiento sobre la amenabilidad hacia la automatización.

-Los que se enfocan más en el análisis y prestan menor atención a la manera en el que el modelo se expresa.


Modelos globales VS Modelos locales.

-El método orientado a objetos, quemuestra que objetos existen y como se relacionan.

-Los diagramas de estado y transición, que muestra el estado de los objetos y la transición entre ellos.

Se dice que el modelado de objetos es "estático" y la transición de diagramas son "dinámicas". Los modelos de objetos son casi siempre diagrmas de clase, mostrando clases, sus campos y las relaciones entre clases. Un diagrama de clase es una representación parcial de la estructura sintáctica del código en comparación con un diagrama de transición.

En un modelo global, el estaod del sistema como un todo es expresado directamente; en un modelo local, el estado global emerge de las definiciones de los estados locales.

Simulación VS Comprobación

La simulación siempre ha se visto con sospecha por los académicos. Es mejor checar una propiedad exhaustivamente que analizar solo un pequeño espacio. Por eso el modelado de comprobación es más efectivo que la simulación en exponer errores sutiles.

Pero en la otra mano, la simulación es muy útil, cuando se construye un modelo muy grande, es más fácil cometer erores que la simulación de inmediato expone.

Verificación VS Refutación

La comprobación rara vez es totalmente automatizada, desde que los lenguajes de modelado son cada vez más efectivos, por eso hay dos acercamientos: la verificación y la refutación.

El acercamiento de la verificación tiene el intento del análisis a encontrar una prueba para la propiedad dada. Si no se encunetra tal prueba, la propiedad puede aguantar, pero tales análisis rara vez fallan de una manera que permite al usuario determinarsi es la prueba de la estrategia o el modelo en sí que está fallando.

El acercamiento de la refutación tiene el intento del análisis a refutar la propiedad dada para encontrar un contra ejemplo. Estos análisis emplean algunos formularios de búsqueda en un espacio que ha sido artificialmente relacionado. Si no se encuentra un contraejemplo o la relación es inapropieda o en realidad la propiedad se mantiene..

Declarativo VS Estilo Operacional

En un lenguaje declarativo para modelos globales, las invariantes y operaciones son escritas como fórmulas lógicas. Lenguajes para modelos locales, tienden a ser más operacionales, definiendo transiciones en una manera programadora.

Las descripciones operacionales corren el riego de cometer tendencias de implementación, pero los modelos locales raramente sufren de ello.

Análisis de código

Los actuales lenguajes de modelado tienen un talón de Aquiles: la falta de cualquier correspondencia hecha con la actual implementación. Un diseñador o ingeniero no puede confiar en el modelo para reflejar exactamente de el comportamiento del programa será entendiblemente reluctante usar el modelo como razón para entender el comportamiento del sistema. De hehco, un modelo incorrecto puede serpeor que si no hubiera un modelo en absoluto, si este desorienta al ingeniero o al diseñador hacia una manera incorrecta de comprender las causas del comportamiento del sistema.
El resultado práctico de la falta de correspondencia hecha entre el modelo y la implementación, es que el modelos se convierte menos útil durante el proceso de desarrollo de software, al punto donde es descartado como una fuente útil de información en las últimas etapas de desarrollo y mantenimiento.

Estático VS Dinámico

Los análisis estáticos analizan el programa para obtener información que es válida para todas las ejecuciones posibles. Los análisis dinámicos utilizan el programa para recolectar información mientras está corriendo.
Los análisis dinámicos tienen una ventaja que detallan información sobre una sola ejecución, así es más fácil de obtener que detallando información que es válida para todas la s ejecuciones.

Sonido VS Sin sonido

Los análisis estáticos de sonido producen información que está garantizada para mantener todos los programas en ejecución; los análisis dinámicos de sonido producen información que está garantizada para esperar la ejecución analizada. Los análisis sin sonido no tienen tal garantía.

Velocidad VS Precisión

Los típicos análisis estáticos exhiben un análisis tiempo vs intercambio de precisión. Se ilustra este intercambio discutiendo 2 distinciones fundamentales: La distinción entre análisis de flujo sensible y análisis de fljo insensible, y también la distinción entre el análisis de contexto sensible y el de contexto insensible.

Los análisis de flujo sensible toman la orden de ejecución de las declaraciones del programa en cuenta. Ellos normalmente utilizan alguna forma iterativa de análisis de flujo de información para producir un resultado de análisis potencialmente diferente para cada punto del programa.
Los análisis de flujo insensible no toman la orden de ejecución de las declaraciones del programa en cuenta, y por eso son incapaces de extraer cualquier propiedad que dependa de esta orden. Ellos usan una forma de análisis de contra-base para producir resultados de análisis simples que son válidos para todo el programa.

Un análisis de contexto sensible produce resultados diferentes para cada análisis de contexto diferente.
Un análisis de contexto insensible produce un solo resultado que es usado directamente por todos los contextos.