Resumen

PROBLEMA DE INVESTIGACION: La construcción de un sistema de software debe ser precedida por la construcción de un modelo, tal como ocurre en otros sistemas ingenieriles. El modelo de un sistema es una representación conceptual obtenida a partir de la identificación, clasificación y abstracción de los elementos que constituyen el problema y su posterior organización en una estructura formal. De esta forma, el modelo de un sistema actúa como una especificación de los requerimientos que el sistema debe satisfacer, proveyendo un medio de comunicación y negociación entre usuarios, analistas y desarrolladores, así como también un documento de referencia durante la corrección de errores y durante la evolución del producto. Se ha observado que la construcción de modelos es una técnica muy efectiva para detectar y resolver discrepancias entre los divergentes puntos de vista de los usuarios acerca de sus requerimientos, brindando así bases firmes para las siguientes etapas del proceso de desarrollo. Actualmente todos los métodos de desarrollo de software han adoptado esta filosofía. Lo que varía de un método a otro es la clase de modelos que deben construirse, la forma de crearlos y organizarlos y el lenguaje en el cual expresarlos. El modelo del sistema se expresa utilizando un lenguaje de modelado (que puede variar desde lenguaje natural o diagramas hasta fórmulas matemáticas). Un modelo se califica como informal cuando está expresado mediante lenguaje natural, figuras, tablas u otras notaciones. Por otra parte, nos referimos a modelos formales cuando la notación empleada es un formalismo, es decir posee una sintaxis y semántica precisamente definidos. Existen estilos de modelado intermedios llamados semi-formales, ya que en la práctica los ingenieros de software frecuentemente usan una notación cuya sintaxis y semántica están parcialmente formalizadas. El éxito de los lenguajes gráficos de modelado propuestos por metodologías tales como Object Oriented Analysis (Coad y Yourdon, 1991), Object Oriented System Analysis (Schlaer y Mellor, 1988), Object Modeling Technique (Rumbaugh et al., 1991), Booch’s design method (Booch, 1994) y el Rational Unified Process (Jacobson et al., 1999), se basa principalmente en el uso de construcciones gráficas que transmiten un significado intuitivo. Estos lenguajes resultan atractivos para los usuarios ya que aparentemente son fáciles de entender y aplicar. Sin embargo, la falta de precisión en la definición de su semántica puede originar diversos problemas, como se enumera a continuación: - Malas interpretaciones de los modelos: la especificación del lenguaje contiene ambigüedades que permiten que un mismo modelo sea interpretado de diferentes formas. La interpretación que realiza el usuario que lee el modelo puede no coincidir con la interpretación que realizó el creador del modelo. - Inconsistencia entre los diferentes modelos del sistema: la relación existente entre los diferentes sub-modelos (por ejemplo, modelos de la estructura estática, modelos dinámicos, etc.) que componen el modelo de un sistema no está precisamente especificada. Por lo tanto, no es posible analizar la consistencia de la integración. - Discusiones acerca del significado del lenguaje: dado que el significado de algunas construcciones del lenguaje no está precisamente definido, las personas involucradas en el proyecto suelen perder tiempo discutiendo las diferentes posibles interpretaciones que pueden asignarse al lenguaje. - Conflictos de evolución: cuando un modelo es modificado pueden producirse efectos colaterales no previstos sobre otros modelos dependientes. Por otro lado, los lenguajes formales de modelado, tales como Z (Spivey, 1992), VDM (Jones, 1990), F-Logic (Kifer y Lausen, 1990), DS-Logic (Wieringa y Broersen, 1998) poseen una sintaxis y semántica bien definidas. Sin embargo, su uso en la industria es poco frecuente. Esto se debe a la complejidad de sus formalismos matemáticos que son difíciles de entender y comunicar. En la mayoría de los casos los expertos en el dominio del sistema que deciden utilizar una notación formal centran su esfuerzo sobre el manejo del formalismo en lugar de hacerlo sobre el modelo en sí. Esto conduce a la creación de modelos formales que no reflejan adecuadamente al sistema real, lo cual da como resultado la construcción de sistemas de software que no satisfacen las necesidades de sus usuarios.