Ciencia y Sociedad, Vol. 25, No. 1, 2000 • ISSN: 0378-7680 • ISSN: 2613-8751 (en línea) • Sitio web: https://revistas.intec.edu.do/

OMT-Z: UNA METODOLOGIA HIBRIDA PARA ESPECIFICAR SISTEMAS DE INFORMACION

DOI: https://doi.org/10.22206/cys.2000.v25i1.pp70-107

*Departamento de Maestria en Computación, Instituto Tecnologico de Costa Rica.

INTEC Jurnals - Open Access

Cómo citar: Díaz, R. (2000). OMT-Z : una metodología híbrida para especificar sistemas de información. Ciencia Y Sociedad, 25(1), 70-107. https://doi.org/10.22206/cys.2000.v25i1.pp70-107

Resumen

Las metodologías de análisis y diseño de sistemas computarizados informales (como la Tecnica de Modelación de Objetos - Objetct .Modeling Tecnique ), adolecen en la mayor parte, de falta de precisión. Esta debilidad se debe a que los diagramas y lenguajes naturales utilizados por estas metodologías para describir un sistema, no tienen bases matemáticas, por lo que las especificaciones no pueden ser validadas antes de construir el producto.

Cuando utilizamos una metodología informal en el desarrollo de un sistema de información corregir problemas de análisis y diseño en la fase de implementación tiene un costo muy alto y conduce a la larga a problemas de aseguramiento de la calidad.

Metodologías como OMT, poseen herramientas gráficas para describir los componentes de software y pasos bien estructurados para guiar el desarrollo. Su desventaja es que no están sustentadas matemáticamente, por lo que pueden ocurrir ambiguedades en el diseño, que no son detectadas hasta en la face de implementación, (y en el peor de los casos son detectactas en la etapa de mantenimiento ).

Por otra parte, los métodos formales, como es el caso de Z, poseen una base matematica fuerte que nos permite verificar que el diseño generado es correcto. Un metodo de especificación formal asegura que nuestro dieseis lo cumpla con una serie de propiedades matemáticas que son fácilmente verificables (sin implementar en un computador la especificación ). Ademas, los métodos formales proveen a los analistas, diseñadores, usuarios, etc. de un lenguaje común que no se presta a ambiguedades.

Una de las desventajas de los metodos fonnales es: que los usuarios e ingenieros de software no estan relacionados con la base matematica que los soporta. Por otra parte, al especificar utilizando metodos fonnales debemos Ilegar a un nivel de detalle que rios obliga a pensar mas en las bases fonnales del sistema, hacienda del disefio una tarea mas compleja.

Por las razones anteriores estamos planteando una metodologia que utiliza un método formal (Z) y otro infonnal (OMT) para analizar y diseñar sistemas computarizados. Esta metodologia utiliza OMT para deseribir el sistema por media de objetos y relaciones entre estos, se utilizan las herramientas gráficas que provee OMT, y Z, para formalizar las especificaciones generadas por OMT.

OMT-Z es una metodologia que provce al analista de una notación grafica, con la cual exponer el sistema a usuarios n6 expertos y un soporte fonnal para comprobar la validez de la especificación.

En el resto de este articulo presentamos parte de la metodologia hibrida OMT­Z

Por razones de espacio solo se presenta la formalización del modelo de objetos.


Palabras clave: Sistemas computarizados, modelación, metodología OMT.

1. CONSTRUCCIÓN DE UN MÉTODO DE DISEÑO COMBINANDO Z CON OMT (OMT­Z)

OMT-Z es una metodologia de análisis y diseño de sistemas, que combina los metodos OMT y Z para especificar sistemas computarizados. OMT-Z utiliza la notación grafica de OMT coma son: el Modelo de Objeto, Modelo Dinamico y Modelo Funcional para diseribir las diferentes fases de un sistema. Estos modelos pertenecen a las notaciones que se conocen como informales, (debido a que no tienen una base matcmatica que las sustente). Los principales problemas de las notaciones informales son :

Incoherencias: La interpretación de la computación en estas metodologias es bastante subjetiva. La mayor parte de estas utilizan lenguaje natural para deseribir los procesos, por lo que las especificaciones pueden estar inconclusas, pueden contradecirse con la deseripción de otros procesos o pueden interpretarsc equivocadamente.

Incompletitud: Al especificar los procesos y estado del sistema no se describe claramente cuál es el estado del sistema, luego de ejecutar un proceso o los estados válidos del sistema en su vida útil.

2. MODELOS DE OMT AGREGANDO Z

A continuación se deseriben los cambios a realizar a cada modelo de OMT:

Modelo de Objeto: Para cada clase de objeto se agrega un esquema que deseriba sus atributos y los invariantes de estos atributos.

Modelo Dinámico: Para cada evento y/o acción especificar un esquema que deseriba el proceso realizado y el estado en que queda el objeto.

Modelo Funcional: Para cada proceso del diagrama especificar un esquema que deseriba el proceso realizado y el estado de las entidades involueradas resultantes. En este documento solo se definen las tecnicas utlizadas para formalizar el diagrama de objeto.

2.1 Modelo de Objetos en OMT Z

En OMT-Z se especifican formalmente las limitaciones e invariantes que debe mantener cada objeto como entidad individual y el sistema como un todo. A continuación se presentan los pasos a seguir para fomializar el diagrama de objetos de OMT:

  1. Construir esquemas genericos que especi fiquen para cada clase de objetos el conjunto que lo conforma, la relación de integridad entre los atributos del objeto y su identificación y los predicados que restringcion la relación cntre la clase de objeto y sus instancias.

  2. Contruir esquemas genericos para cada tipo de relación entre los objetos a modelar.

  3. Para cada clase de objeto construir un esquema que defina sus atributos. Cada tributo debe ser definido previamente utilizando los tipos de datos validos en Z.

  4. Para cada clase de objeto instanciar el esquema generico que define objetos. Los parametros de la instanciación son ObjectoID (Identificación del Objeto) y Atributos Objecto (Atributos del objeto).

  5. Instanciar los esquemas genericos de relación con cada una de las relaciones entre objetos. Los parametros de la instanciación son: Objeto MaestroID (identificación del objeto maestro) y ObejtoDetalleID (Identificación de los objetos detalles).
  6. Los nombres tanto de las clases de objeto como las asociaciones, se podran eseribir con mayuscula. El nombre del registro sera en singular y el nombre del conjunto de instancias en plural.

3. CASO DE ESTUDIO

3.1 Deseripcion del Sistema

Es un sistema de seguridad controlado a traves de una Alarma, una Central de Alarmas, una Linea Telefonica y un Computador.

La alarma se encuentra instalada donde el cliente, con sus respectivos dispositivos de activación (cables, bocinas, etc.). La central de alarmas se encuentra en las instalaciones de la compañia que presta el servicio de seguridad, y a la cual estan conectadas las alarmas de los clientes, (por medio de lineas telefónicas ). A su vez la central esta conectada a un computador. Este computador monitorea los eventos recibidos por la central.

El objetivo del sistema es controlar los eventos ocurridos en cada instalación, dando un servicio eficiente de aviso a: autoridades militares y a clientes en caso de emergeneia.

Como objetivo secundario: la empresa logra aumentar sus ingresos cobrando una tarifa por llamadas hechas a sus abonados (clientes).

A continuación deseribimos elfuncionamiento del sistema:

El cliente mantiene la alarma en estado de encendido o apagado. Si la alarma esta en estado de encendido y se interrumpe el alambrado de seguridad se activa el dispositivo de sonado y este envia una senal de inicio de ruido a la Sirena (bocina). Si la alarma esta sonando y un usuario preciona el bot6n de apagado, esta pregunta la clave de autorización, si el usuario esta autorizado, la alarma pasa al estado de apagado. Una vez que se resuelve el dano en el alambrado de seguridad el usuario puede encenderla.

La Linea Telefonica: Sirve como conección de la alarma y la central de alarmas. Si la alarma intenta comunicarse con la central de alarmas, y la linea telefón ica esta ocupada, automaticamente esta sigue intentado, hasta que la comunicación se logre.

La Central de Alarma: A ctua como un codificador y decodificador de los mensajes. Su función es "recibir" mensajes de la alarma y decodificarlo en una notación entendible por el computador. De manera similar, recibe mensajes del computador y los codifica en una notación entendida por la alarma.

El computador: Recibe mensajes de la central de alarma y las despliega en la pantallas del computador de acuerdo a la prioridad de la senal. Otras de sus funciones es calcular el cargo por llamadas a clientes y mantener la infomiación de estas.

Las figuras 1 y 2 muestran el digrama de objetos del sistema y un grafico explicativo respectivamente.

3.2 Identificación de Objetos y Clases

Se identifican las siguientes clases potenciales:

  1. Alarma
  2. Central de Alarmas
  3. Cliente
  4. Computador
  5. Linea Telefonica
  6. Eventos
  7. Tipos de Señales
  8. Operador
  9. Factura de Cargo
  10. Mensajes

3.3. Diccionario de Datos

Alarma:

Dispositivo instalado donde el cliente, esta controla el cableado de seguridad y emite señales adecuadas a la central de alarma.

Central de Alarma:

Dispositivo instalado en la empresa proveedora del sevicio de seguridad, que recibc las señales desde las alarmas de los clientes y las codifica en una notación entendida por el computador.

Cliente:

Persona a quien se le brinda el servicio de seguridad.

Computador:

Dispositivo que monitorea las señales recibidas y calcula el cobra de llamadas a clientes.

Linea Telefonica:

Dispositivo por media del cual se comunican las alarmas y la central de alarmas.

Eventos:

Mensajes emitidos por las alarmas, o la central de alarma indicando la ocurrencia de un evento especifico.

Operador:

Persona que recibe los mensajes desplegados por el computador y ejecuta acciones correctivas.

Factura de Cargo:

Documento enviado al cliente para el cobro de aranceles por llamadas de aviso.

Mensaje:

Señales emitidas por la linea telefónica.

4.4. ldentificar Asociaciones

Una alarma tiene un cliente

Un cliente tiene nmchas alarmas

Una alarma tiene una linea telefónica

Una linea telefónica tiene una alarma

Una central de alarmas tiene muchas alarmas

Una alarma tiene una central de alarmas

El computador tiene una central de alarmas

La central de alarmas tiene un computador

Un tipo de señal tiene muchos eventos

Un evento tiene un tipo de senal

Un cliente tiene muchas llamadas de aviso Una Hamada de aviso tiene un cliente

Una alarma tiene muchas senales Una señal es de una alarma

4. MODELO DE 0BJETO EXPRESADO EN Z

4.1 Definición de Tipos de Atributos

A continuación se define el tipo para las atributos que apare- cen en cada clase de objeto dentro del digrama de objetos.

4.2 Definición de Atributos de Objetos y Clases de Objetos

A continuación se define cada clase de objeto. Primera se definen sus atributos en un esquema separado y luego otro esquema con la clase en si misma.

Este esquema define las atributos que posce todo objeto de la clase alarma.

Este esquema instancia el esquema generico "Objeto" con los parametros AlarmaId y AtributoAlarma. Se renombra el conjunto conocidosClase por conocidosClaseAlarma y la función objetosdeClase con el nombre objetosdeClaseAlam 1a. Esto retorna la entidad ObjetosClaseAlarma heredando los predicados del esquema generico "Objeto".

Si expandimos el esquema se veria como sigue:

En lo que resta de este articulo, por razones de espacio, se omite la explosion y documentación de esquemas parametrizados para creación de clases de objetos.

4.3 Definición de Relaciones entre objetos

Una vez hemos defini do los esquemas de las clases de objetos y sus atributos, podemos especificar los esquemas de las relaeiones entre las clases de objetos.

Este esquema instancia uno de los csq ucmas genericos de relación (ver fi), primitivos en OMT-Z. El esquema generico de "relación uno a mas uno" es instanciado para formar la relación de Clientes a Alarmas, ( ver fiama de objeto ). La instanciación renorn bra los conjuntos del esquema generico conocidosOjeto Detalle y conocidosObjeto Detalle por conocidosClaseCliente y conocidosClaseAlarma respectivamente.

Si expandirnos el esquerna anterior se veria como sigue:

Las primeras dos lineas del esquema definen los conjuntos de clientes y alarmas conocidos. Luego se define la relación "RelaciónClienteAlarma" , que asocia el cliente a sus alarmas. Luego se restringe la relación con los siguientes predicados:

  1. El dominio de la relación cliente-alarma es igual a los clientes conocidos (cs decir, todo cliente conoci do por el sistema debc tener alarma).

  2. El rango del a relacion es un sub conjunto de las. alarmas conocidas por el sistema.

  3. Para todo el cliente conocido por el sistema el numero de alarmas rcgistradas debc ser por lo menos una, es decir todo cliente debe tcner al menos una alarma.

  4. La relacion invertida resulta en una funcion total de Alarmas a Clientes. Este ultimo predicado restringe el segundo al decir que toda alarma debe tener un cliente asociado, en otras palabras todo el conjunto alarma entra en la relacion. Las siguientes relaciones no seran expandidas por razones de espacio.

5. DIAGRAMA DINAMICO

5.1 Clase de Alarma

Escenarios:

  1. El usuario enciende la alarma.

  2. En Este mornento se verifica si hay interrupción en la linea de seguridad:

    • Si esta interrumpida se dispara el dispositivo de activación de la sirena y la alarma pasa a estado sonando e interrumpida.

    • Si no, la alarma pasa a estado encendida, continua y callada.

  3. Si la alarma esta sonando e interrumpida el usuario pucde apagarla hasta resolver el dano, a la acción de apagado la alarma responde solicitando la clave de autorización al usuario:
  4. Si la clave es valida se pasa al estado interrumpida, sonando, apagada (no genera nido).

    Si la clave no es valida, la alarma no responde nada.

  5. Si la alarma esta encendida (en estado continuacallada) y se interrumpe la red de seguri dad, se pasa a estado interrumpida- sonando. Se genera un mensaje a la sirena para que empicce a sonar.

  6. Para cada evento (apagar, interrumpir, sonar, encender, etc.) se genera una Hamada a la central de alarmas con un código que identifica el evento. La llamada se hace al numcro registrado en la alarma, donde pueden ocurrir dos acciones:

    • Número ocupado (o fuera de servicio), la alarma sigue intentando llamada.

    • Número desocupado, se genera la llamada de aviso a la central de alanna.

  7. Apagar la alarma, si esta sonando ver paso (3), sino apagarla. Apagar la alarma es equivalente a pasar elinterruptor de enccndido a apagado.

5.2 Linea Telefonica

Escenario:

  1. La alarma solicita tono de marcado a la linea telefónica.

  2. La linca telefónica rcsponde con tono disponible.

  3. La alarma marca el numero telef6nico a llamar.

  4. El numero marcado comi enza a timbrar (en la Central de alarmas).

-La señal de timbrado aparece en la alarma .

-La central de alarma responde.

-La señal de timbrado cesa en el numero de llamada (Central de alarma).

-La señal de timbrado cesa en la alarma.

-Las lineas se conectan ( Envio de Mensaje).

-La alarma corta la comunicación.

-Se desconectan los telefonos.

-La central de alarmas libera la linca telefonica.

5.3. Central de Alarmas

Escenarios:

1 Recibe un evento desde la alarma.

Codifica el evento en un lenguaje establccido (entendido por el computador).

Envia el mensaje al computador.

6. DIAGRAMA FUNCIONAL

El sistema de control de alarmas tiene dos procesos que procesan datos, estos son:

Enviar: Proceso por el cual la central de alarma envia los datos al computador. El computador debe validar los datos recibidos, si son validos son almacenados, de lo contrario se envia un mensaje de retrasmisión a la alarma.

Registrar Avisos y Computar Cargos: Este proceso recibe los avisos y computa los cargos a los clientes.

A continuación se muestran lo diagramas funcionales para estos procesos.

7. ESQUEMAS GENERICOS DE OMT-Z

A continuación se deseriben los esquemas genericos utilizados en este articulo.

Este esquema generico es instanciado con una identificación de clase de objeto y los atributos de la clase de objeto a crcar y nos retorna una nueva clase de objcto. Dentro del esquema primero se define un conjunto, conocidosClase de tipo Objetold (del tipo de la clase de objeto a instanciar), luego se define una función parcial de Objetold a los atributos del Objeto, es parcialindicando que no todos los Objetol d del uni versfinen atributos asociados. Final mente, se define un predicado que asegura que todo objeto conocido por el sistema ticne atributos asociados.

Este es un esquema de relación abstracto que sera utilizado por las rel aciones entrc objeto. Este csq ucma rec ibe como parametro el ObjEto MaestroId y ObjctoDetaleId a entrar en la relación . Dentro del csq u cm a se de fi n en l os conjuntos conocidosObjetoMaestro y ObjetoDetalle del tipo ObjetoMaestroOd y ObjetoDetalleld respectivamente. Luego se define una relación abstracta (lo mas general posibl e) que sera restringida posteriomiente por los esquemas rcales que utilicen el esquema relacion. Se incluyen dos predicados que restri ngen el dom y ran de la relacion a objetos conocidos por el sistema.

Todos las esquemas que definen relaciones incluyen el esquema abstracto Relacion.

Esquema utilizado para modelar relaciones de uno a uno opcional. Dentro del esquema se define la RelacionMaestroDetalle coma una funcion parcial, ya que la funcion de objctoMaestrol d a ObjetoDetalleId es opcional (0 o 1). Luego se restringe la funcion a que existan uno o cero pares ordenados, cuyo pri mer componente sea igual, esto es una propiedad de las funciones por lo que ya esta dicho. Ademas, se espccifica la funcion inversa coma una funcion total de ObjetoDetallald a ObjctoMaestroId, esta es total ya que para cada elemento del rango se relaciona exactamente un elemento del rango.

Esquema utilizado para modelar relaciones de uno a muchos (cero o mas). El esquema define una relacion que alinvertirla es una funcion total de ObjetosDetallelId a ObjetoMaestroId (porque cada elemento del rango se relaciona cxactamente con un clemento del dominio).

Esquema utilizado para modelar relaciones de uno a mas de uno. El esquema define una rel ación restringida a que: 1. Todos los elementos del dominio entran en la relacion, 2. Cada elemento del dominio debe tener mas de un elemento imagen en el rango, 3. La relación invertida define una relación total (ya que cada elemento del rango debe relacionarsc cxactamente con un elemento en el dominio).

Esquema utilizado para modelar relaciones de uno a un conjunto de posiblcs numero de elementos imagenes. El esquema define una relación restringida a que: 1 . El numero de imagenes de cada elemento del dominio debe estar en el conjunto de imagenes pemitidos, 2. La relación inversa es una función total. El conjunto de imagenes pcrmi tidas debe ser dado al esquema como un dato de entrada.

Esquema utilizado para rnodelar relaciones de muchos a muchos.

Esquerna utilizado para rnodelar relaciones de uno opcional a muchos. El esquema defi ne una relacion restringida a que: 1 . La relacion invertida es una funcion parcial de ObjetoDetalleId a ObjetoMaestroid, es parcial por que puede ser O o 1 , 2. El segundo predicado es redundante ya que definir la relacion invertida como una funcion asegura que cada elemento solo se relaciona con O o 1 elemento del rango.

Esquema utilizado para model ar rel aciones de m uchos a mas de uno. El esquema define una relacion restringida a que: 1 . Cada elemento del dominio debe relacionarse con mas de un elemento en el rango.

Esquema utilizado para modelar relaciones de uno opcional a uno opcional. El esquema define una función restringida a que:

Es parcial de ObjetoMaestroId a Objcto Detalleld, dcbido a la opcionalidad, 2. Es inyccti va ya que cada clemen to d istinto del dominio se relacion a con cero o con un elemento del rango.

Esquema utilizado para modelar relaciones de uno a mas de uno. El esquema define una relación restringida a que: 1. Todos los elementos del dominio entran en la relación, 2. Cada elemento del dominio debe tener mas de un elemento imagen en el rango, 3. La relación invertida define una función parcial, ya que cada elemento de su dominio puede estar asociado con uno o ningun elemento del rango.

Esquema utilizado para modelar relac iones de uno opcional a conjunto. E l esquema define una relación restringida a que: 1 . Todos los elementos del dominio tiene un numero de imagenes que estan dentro del conjunto permisible, 2. La relación in vertida define una función parcial , debido a la opcionalidad permitida.

Esquema utilizado para modelar relaciones de uno mas a uno mas. El esquema define una relacion restri ngida a que: I . Todos las elementos del dominio tiene mas de una imagen, 2. La relación invertida resulta en una relacion en la que todos las clementos del dominio tienen mas de una imagen, 3. la relacion es total en ambos lados.

Esquema utilizado para modelar relaciones de conjunto a conjunto. El esquema define una relacion restringida a que: l. El numero de imagenes de cada elemento del dominio debe estar en el conjunto dado ( igual para la relacion inversa).

Esquema utilizado para modelar rel aciones de conjunto a conjunto. El esquema define una rel acion restringida a que: 1 . El numero de imagenes de cada elemento del dominio debe estar en el conjunto dado, 2. La relacion invertida resulta en una relacion en la cual el numero de imagenes de cada elemento del dominio debe ser mas de uno.

Esquema utilizado para modelar relaciones de uno a uno. El esquema define una función restringida a que: 1. Es parcial de ObjetoMaestrold a ObjetoDctallcld, 2. Es inyectiva porque cada elemento distinto del rango es imagen de un elemento distinto en el dominio. Además, el dominio de la función es igual al conjunto de ObjetosMaestro conocidos por el sistema.

Para definir la relación ternaria se divide el problema en dos partes: 1. Primero se define una relación uno a uno entre las dos primeras clases de objeto que entran en la relación, y 2. Se agrega un predicado que asegure que todo primer componente de la primera relación se asocia a un componente de la clase de objeto tres (como la relación es de uno­a­uno, total entre las tres clases esto asegura que existe una terna única de forma ObjetoUnoIdObjetoDosId­ObjetoTresId).

Nota: El esquema genérico presupone que las clases de objetos que entra en la relación tienen un atributo identificado con el nombre del objeto en si, que este identificador está en la primera posición del récord y que este idcntificador es la llave de acceso al objeto.

El esquema ternario eventualmente puede ser redefinido por el usuario para permitir otro tipo de relaciones, por ejemplo, asociaciones múltiples entre las clases de objetos.

Para definir la relación ternaria se divide el problcma en dos partes: l. Primera se define una relación uno a uno cntrc las dos primeras clases de objcto que entran en la relación, y 2. Se agrcga un predicado que asegurc que todo primer componente de la primera relación se asocia a un componente de la clase de objcto tres (como la relación es de uno-a-uno, total cntrc las trcs clases esto asegura que existe una terna unica de forma Objcto U noldObjetoDosld-ObjctoTresld).

Nota: El esquema generico presupone que las clases de objetos que entra en la relación ticnen un atributo identificado con el nombre del objcto en si, que este identificador esta en la primera posición del record y que este identificador es la llave de acceso al objeto.

El esquema ternario cvcntualmente pucde ser redefinido por el usuario para pemiitir otro tipo de relaciones, por cjemplo, asociaciones multiples entre las clases de objetos.

Para definir la relación con atributos en la liga se relizan los pasos siguientes: 1. Se invoca el esquema generico con los Identificadores de las dos clases que entran en la relación, elidentificador de la clase de objcto que se crea en la liga y el esquema que contiene sus atributos. 2. Se define una función parcial para la liga. Esta muestra que todo identificador en la liga ticne un conjunto de atributos asociados. 3. Todo pri mer componente delidentificador de objeto liga, debe existir entre los conocidos de la prirnera clase de la relación. De la misma manera todo segundo componente debe cxistir cntrc los conocidos de la segunda clase de la liga.

Nota: El esquema generico presupone que el record de la cntidad creada en la liga posee un identificador en forma de tupl a. El primer componente de esta tupla es de tipo identificador de la primera clase a relacionar, el segundo es de tipo identificador de la segunda clase a ligar.

Este tipo de cualificador es utilizado para convertir relaciones de muchos-a-uno, a relaciones de uno-a-uno. Para hacer esto se le agrega un identificador (cualificador) a la clase donde se da la relación de muchos.

El esquema generico creado para modelar este tipo de relaciones tiene los siguicntes componentes: 1 . Recibe como parametros elidentificador del objeto maestro y detal l c, elidentificador que cualifica la relación (que debc existir dentro de los atributos del objeto maestro) y el esquema que rcpresenta el conjunto de atributos de la clase de objeto maestro, 2. Se define una relación entre los objetos maestro y detalle, 3. Se restringe el esquema con dos predicados, el primero asegura que todo cualificador contenido en la clase maestra tiene su imagen en la clase detallc (para cada valor del cualificador en la clase maestra existe un objeto en la clase dctalle identificado con Este valor), segundo se define la inversfila relación que resulta en una función total.

8. CONCLUSION v RECOMENDACIONES

Consideramos que la utilización de metodos formates en la ingenieria del software podria ser una de las solueiones a los problemas de calidad del software. Construir sistemas con una base matematica formal nos permi te verificar y asegurar la calidad de los mismos.

Utilizando metodos hibridos aprovechamos las fortalezas de cada planteamiento y desechamos sus debi lidades.

Los metodos formates adolecen de complejidad de utilización y falta de estructura. Sin embargo utilizan notaciones que nos permiten razonar acerca de la corrección de nuestras especificaciones sin necesidad de implementarlas.

Por otro lado, los metodos informa les son mas estructurados y utilizan notaciones graficas que proveen un entendimiento de los conceptos del diseño mas facilmente. Pero estan pobremente formalizados y en su mayoria se prestan a interpretaciones subjetivas.

Nosotros como ingenieros de software abogamos por metodologias de analisis y disefio de sistemas que provean: una base formal sólida que nos permita encontrar los errores en nuestras especificaciones antes de que se conviertan en errores reales en nuestros sistemas de información. Esta base formal debe ser dotada de herramientas informales que faciliten nuestra interacción con usuarios y personas no familiarizadas con las notaciones formales. Nuestro objetivo es buscar metodologías alternas que combinen las existentes. No estamos de acuerdo con que se creen nuevos planteamientos de desarrollo de software, por el contrario creemos que los existentes son suficientes para mejorar el estado actual de incertidumbre en materia de sistemas de información. Debemos relacionar las fortalezas de los métodos y metodologías actuates con el objetivo de obtener verdaderas metodologias que resuelvan los problemas de calidad del software y de esta forma guíen el desarrollo de sistemas por el camino del exito y la satisfación total de las necesidades de nuestros clientes.

OMT-Z es una metodologia hibrida de analisis y diseno de sistemas que combina un plantearniento formal (Z), con uno infomial (Object Modeling Tecnifique), con el propósito to de lograr flexibilidad al especi ficar notaciones gra ficas con las cuales se pueda conceptualizar el diseno y el poder analítico del calculo de predicado y algebra relacional.

Nuestra experiencia con OMT-Z ha sido satisfactoria. Utilizamos la parte informal de OMT-Z para levantar las requerirnientos del sistema, deseribir su estructura in icial y veri ficar que todos los requerimicntos estaban cubiertos par el diseno. U na vez que obtuvirnos la especificación infonnal, la forrnalizarnos utilizando la parte formal de OMTZ. Formalizar la especilicación nos permitió descubrir y corregir inconsistencias en esta.