SISTEMA DESARROLLADO

CON MTODOS FORMALES

GRUPO 14:
LEONARDO ANTELO OCCHIUZZI
CRISTINA FERNNDEZ SAMPAYO
ALEJANDRO FOGLIA

(Documento con preguntas tipo test)

NDICE

Introduccin

Objetivo de la investigacin

Requisitos del Sistema de Control del Ascensor

Desarrollo realizado por el Grupo de Control

Desarrollo realizado por el Grupo de Mtodos

Formales

Solucin Formal Completa

Conclusiones

INTRODUCCIN

Estudio realizado con 2 grupos [GC y GMF] de

estudiantes de la Universidad de Miami en Ohio.

En el 3 ao de estudios.

Un grupo OOD, y el otro OOD + Mtodos formales.

Desarrollo del sistema de control de un ascensor,

para ver y comparar los resultados (IEEE-1987).

OBJETIVO DE LA INVESTIGACIN

Introduccin de mtodos formales en el inicio de la

formacin?

Se mejora el desarrollo de sistemas?

REQUERIMIENTOS DEL SISTEMA

Estado del ascensor

(sentido=UP,DOWN,STOPPED;posicin=1,2,etc.)

Atencin de peticiones por parte del usuario
(pisoActual;direccin;pisoDestino).

Entorno grfico, con mens y dilogos.

Atencin concurrente a otras peticiones.

Uso de OOD, C++ y MS Foundation

Classes para los grficos.

GRUPO DE CONTROL (1)

13 equipos de 2 personas.

Sin usar Mtodos Formales.

Ninguna documentacin
Tampoco UML, aunque

se aconsej.

Diseos fuertemente acoplados.

Ejemplos:

Poco eficientes
bucle infinito.
Algoritmos complejos.
Solo atiende peticiones de pasajeros de dentro.

GRUPO DE CONTROL (2)

3 implementaciones fallaron
en todos los casos de estudio.

En 2 casos no haba
ejecutable.

Duplicacin de cdigo.

Una nica funcin.

GRUPO DE MTODOS FORMALES (1)

Grupo Mtodos Formales: 6 equipos de 2 personas cada

uno.

Realizaron 2 tipos de diseo:

1er tipo: Basado en diagramas UML. 3 equipos siguieron esta

orientacin:
2

de ellos indicaron una abstraccin lgica entre el sistema del

ascensor y la interfaz grfica de usuario.
El tercer equipo produjo un diseo altamente acoplado.

2do tipo: Basado en pre-condiciones, post-condiciones e invariantes

escritas para funciones particulares. Los restantes 3 equipos
siguieron esta orientacin.

GRUPO DE MTODOS FORMALES (2)

3 equipos especificaron funciones para decidir

cundo y a donde mover el ascensor. A mayores

especificaron los siguientes tipos de funciones:

Actualizar lista de peticiones.

Comprobar peticin actual en el sistema.
Movimiento del ascensor.
Actualizar gente y peticiones dentro del ascensor.
Cambiar direccin del ascensor.

GRUPO DE MTODOS FORMALES (3)

Ejemplo: Post-condicin para la funcin de carga,

descarga y movimiento del ascensor que especific

un equipo.

GRUPO DE MTODOS FORMALES (4)

El equipo tena exactamente definidas que operaciones

deberan ocurrir (eliminar, aadir, cambiar el piso actual) y en

que estados.

Aunque la especificacin usada no era muy correcta:

Deberan haber usado el cuantificador PARA TODO en vez del

EXISTE.
No deberan haber usado la ASIGNACIN e IGUALDAD.
Est especificacin deja una parte del espacio de estados sin examinar.

Excepto este error, la especificacin muestra el

comportamiento del ascensor bastante bien.

GRUPO DE MTODOS FORMALES (5)

Ejemplo: Especificacin de otro equipo en trminos

de piso objetivo de destino.

Este equipo us el lenguaje de especificacin

correctamente siendo claro y conciso.

COMPARACIONES (1)

Diseo:

Los diseos usados por los dos grupos no fueron
significativamente diferentes.

El grupo de control produjo un diseo ms acoplado que el
grupo de mtodos formales.

Los algoritmos propuestos por el grupo de mtodos formales
son ms eficientes y cumplen en mayor medida los requisitos.

Parece que formar al grupo de los mtodos formales en
anlisis formal ha incrementado su habilidad para disear
algoritmos.

COMPARACIONES (2)

Implementacin

Solo un 45.5% de las implementaciones del grupo de control
superaron las pruebas a las que fue sometidas frente al 100%
del grupo de mtodos formales.

Esto es un claro ejemplo de cmo la formacin en anlisis
formal puede beneficiar a los programadores, incrementado
sus habilidades para crear programas funcionalmente
correctos.

SOLUCIN FORMAL COMPLETA (1)

Requerimientos: A parte de los requerimientos

especificados anteriormente se aadieron los siguientes :

Mantener el conjunto de botones que han sido pulsados dentro del

ascensor.
Mantener el conjunto de botones que han sido pulsados fuera del
ascensor: numero de piso en el cual est esperando un pasajero y
direccin pedida.
Parar cuando el ascensor no tiene ms peticiones que atender.
Servir todas las peticiones realizadas fuera del ascensor dando
igual prioridad.
Servir todas las peticiones realizadas dentro del ascensor
secuencialmente segn la direccin del ascensor.
Asegurar que las peticiones que se encuentran en la direccin del
ascensor se atienden a tiempo (maximizar el uso del ascensor).

SOLUCIN FORMAL COMPLETA (2)

Diseo:

Para el diseo se realizaron tanto diagramas UML como
especificaciones formales.
 Diagramas UML:
 Las principales clases del diagrama UML eran:
Elevator y ElevatorSystem
 El principal mtodo de la clase Elevator era
UpdateElevator. Estaba basado en el principio del
menor trabajo. Es decir, el ascensor no cambiaba de
direccin hasta que no haba algn motivo para
continuar en la misma direccin.

SOLUCIN FORMAL COMPLETA (3)



Especificacin formal:
 Basada en lgica de primer orden.
 Realizaron pruebas que les aseguraron que se segua la especificacin.
En este proceso de verificacin encontraron errores principalmente
producidos por una especificacin incompleta. Por ejemplo, un error
fue debido a que no se especificaba como el ascensor debera
reanudar el movimiento despus de haber parado.
 El tiempo que tardaron en realizar la especificacin fue:
5 horas: especificacin inicial
10 horas: revisar especificacin (encontrar y corregir errores).
10 horas: realizar la verificacin de la especificacin.

En conclusin: gracias a los mtodos formales, el equipo de

verificacin descubri todos los errores de la especificacin antes de
la implementacin.
 El proceso de verificacin produjo un buen diseo que no necesito
cambios basados en descubrimientos de la implementacin o las
pruebas.


SOLUCIN FORMAL COMPLETA (4)

Implementacin:

El equipo de verificacin traslado su pseudocdigo en C++ casi

de manera directa:
Los predicados fueron traducidos como llamadas a funciones.
 Las asignaciones mltiples se cambiaron a secuencias de
asignaciones simples.
 El no determinismo se tradujo en clausulas if que se resolvan en
el orden en que aparecan en el pseudocdigo.


El equipo de verificacin implemento un cdigo

funcionalmente correcto. En su primera ejecucin no se
detectaron errores.
En cuanto al estilo, fue mejor que el de los otros equipos.
En conclusin, el equipo de verificacin realizo un excelente
trabajo de programacin.

CONCLUSIONES

La formacin en mtodos formales incrementa las

capacidades para analizar y disear software de los

desarrolladores de software.

Se puede conseguir software de mayor calidad si se
combinan mtodos formales con mtodos no
formales.

Se debera ensear mtodos formales a todos los
alumnos de titulaciones universitarias relacionadas
con el desarrollo de software.

SISTEMA DESARROLLADO CON

MTODOS FORMALES
Grupo 14
Leonardo Antelo Occhiuzzi
Cristina Fernndez Sampayo
F. Alejandro Foglia

Sistema Desarrollado con Mtodos Formales

ndice
1. Resumen ......................................................................................................................................... 3
2. Introduccin .................................................................................................................................... 3
3. Requerimientos ................................................................................................................................ 3
4. Diseo ........................................................................................................................................... 4
4.1 Diseo del Grupo de Control ............................................................................................................ 4
4.2 Diseo del Grupo Formal ............................................................................................................... 4
4.3 Comparaciones........................................................................................................................... 5
5. Implementacin ................................................................................................................................ 6
5.1 Implementacin del grupo de control ................................................................................................. 6
5.2 Implementacin del grupo de mtodos formales .................................................................................. 7
5.3 Comparaciones .......................................................................................................................... 7
6. UNA SOLUCIN FORMAL COMPLETA ......................................................................................................... 8
6.1 REQUERIMIENTOS ......................................................................................................................... 8
6.2DISEO...................................................................................................................................... 8
6.3Implementacin ........................................................................................................................... 8
7. Conclusiones ................................................................................................................................... 9
8. PREGUNTAS TIPO TEST (en verde las opciones correctas)........................................................................... 10

2|Pgina

Sistema Desarrollado con Mtodos Formales

1. Resumen

Se presenta el desarrollo realizado por estudiantes de un sistema de programacin para un ascensor.

El desarrollo fue llevado a cabo por 40 alumnos (20 equipos de 2 alumnos) divididos en 2 grupos.
o Un grupo realiz las especificaciones utilizando un mtodo formal basado en lgica de primer orden.
o El otro grupo no uso anlisis formal.
En el artculo se comparan las soluciones de los dos grupos atendiendo a los siguientes parmetros: correccin,
concisin y complejidad.
Se presta especial atencin al grupo que utilizo mtodos formales ya que verific completamente su implementacin.
Se comparan los resultados con otras soluciones.
Se concluye que la solucin propuesta por el grupo que empleo mtodos formales es mejor (ms correcta) que la del
otro grupo.

2. Introduccin
Equipo 1 (Grupo Mtodos Formales): 6 equipos de 2 personas= 12 personas
Aprobaron el 100% de los test de estndares
Produjeron mejor diseo e implementacin que el equipo 2.
Equipo 2 (Grupo de Control): 13 equipos de 2 personas: 26 personas
Aprobaron el 45.5% de los test de estndares

3. Requerimientos
o
o
o
o
o
o

Crear un programa que permita manejar un ascensor.

El usuario podr realizar peticiones. Una peticin contendr el piso en el cual es echa dicha peticin y el piso al que
desea ir el usuario.
Se mostrarn mens y dilogos.
Se deber mostrar grficamente, la peticin actual, el piso actual y el estado del ascensor (parado, subiendo o
bajando).
Mientras el ascensor est procesando una peticin el usuario podr realizar otras peticiones.
El algoritmo debe examinar concurrentemente todas las peticiones realizadas y determinar cul es el siguiente piso
o direccin.

Otros requerimientos: usar diseo orientado a objetos, el lenguaje de programacin C++ y Microsoft Fundation Clases
para la interfaz grfica.

3|Pgina

Sistema Desarrollado con Mtodos Formales

4. Diseo
4.1 Diseo del Grupo de Control

A los estudiantes del grupo de control no se les exigi usar un diseo especfico. Ningn equipo present diagramas
UML aunque se les aconsej hacerlo.
Los 13 equipos presentaron un ejecutable 9 de ellos presentaron tambin el cdigo fuente.
El cdigo fuente destacaba por:
o Diseos fuertemente acoplados.
o Mezcla de funcionalidades.
4 de los equipos que presentaron el cdigo fuente presentaron tambin seudocdigo de los algoritmos.
o 1er algoritmo: cumpla los requisitos pero no era eficiente. El ascensor estaba programado para viajar en
un ciclo: subir del primero al ltimo piso y volver a bajar de nuevo, as continuamente.
o 2 algoritmo: basado en el principio del menor trabajo. El ascensor solo cambiaba de direccin cuando le
resultaba infructuoso seguir en la direccin actual. El algoritmo era muy complejo y se basaba
principalmente en el anlisis del estado del sistema.
o 3er algoritmo: el ascensor solo atenda la peticin ms reciente.
o 4 algoritmo: Estaba descrito incompletamente, realizaba todas las peticiones hechas por las personas
que iban dentro del ascensor, pero no atenda a nuevas llamadas.

4.2 Diseo del Grupo Formal

Realizaron 2 tipos de diseo:

o 1er tipo: Basado en diagramas UML. 3 equipos siguieron esta orientacin:

2 de ellos indicaron una abstraccin lgica entre el sistema y la librera de interfaz con la cual
sera implementado. Es decir, las clases fueron diseadas independientemente de la interfaz
grfica. Esto es una buena prctica ya que reduce el acoplamiento.

El tercer equipo produjo un diseo altamente acoplado: Los mdulos que controlaban el estado
del ascensor estaban mezclados con los de visualizacin.
o 2 tipo: Basado en precondiciones, pos condiciones e invariantes escritas para funciones del diseo.
3 equipos especificaron funciones para decidir cundo y a donde mover el ascensor. A mayores especificaron los
siguientes tipos de funciones:
o Actualizar la lista de peticiones.
o Comprobar la peticin actual en el sistema.
o Movimiento del ascensor.
o Actualizar la gente y peticiones dentro del ascensor.
o Cambiar el ascensor de direccin.

Ejemplo de un equipo que especifico la carga, descarga y movimiento del ascensor. La post condicin para la funcin q
realizaba esta operacin era:

4|Pgina

Sistema Desarrollado con Mtodos Formales

Esto demuestra q el equipo tena exactamente definidas que operaciones podran ocurrir (eliminar, aadir, cambiar el piso
actual) y en que estados deberan ocurrir. Aunque la especificacin usada no era muy correcta. Deberan haber usado el
cuantificador PARA TODO en vez del EXISTE. Tampoco deberan usar las asignaciones := ya que su uso no es apropiado en
lgica de primer orden. Por ltimo est especificacin deja una parte del espacio de estados sin examinar: si el ascensor
est subiendo o bajando pero de repente para, de acuerdo con la especificacin nunca se volver a mover. Excepto este
error, la especificacin muestra el comportamiento del ascensor bastante bien.

Ejemplo de otra especificacin:

Este equipo uso el lenguaje de especificacin correctamente siendo claro y conciso.

4.3 Comparaciones

Los diseos usados por los dos grupos no fueron significativamente diferentes.
El grupo de control produjo un diseo ms acoplado que el grupo de mtodos formales.
Los algoritmos propuestos por el grupo de mtodos formales son ms eficientes y cumplen en mayor medida los
requisitos.
Parece que formar al grupo de los mtodos formales en anlisis formal ha incrementado su habilidad para disear
algoritmos.

5|Pgina

Sistema Desarrollado con Mtodos Formales

5. Implementacin
5.1 Implementacin del grupo de control

El grupo de control no programo correctamente: su cdigo era extremadamente incorrecto, su estilo de

programacin era pobre.
Solamente 5 de las 11 implementaciones eran correctas. (45.5%)
La implementacin mostraba q los estudiantes carecan de habilidad para programar bien.

6|Pgina

Sistema Desarrollado con Mtodos Formales

5.2 Implementacin del grupo de mtodos formales

Todas las implementaciones eran funcionalmente correctas. (100%)

Su cdigo no era demasiado conciso, en algunos casos los niveles de complejidad eran demasiado elevados.
En cuanto al estilo, algunos grupos tenan buen estilo mientras otros no.
En conclusin las implementaciones eran bastante buenas aunque se podran mejorar.

5.3 Comparaciones
Solo un 45.5% de las implementaciones del grupo de control superaron las pruebas a las que fue sometidas frente al
100% del grupo de mtodos formales.
Esto es un claro ejemplo de cmo la formacin en anlisis formal puede beneficiar a los programadores, incrementado
sus habilidades para crear programas funcionalmente correctos.

7|Pgina

Sistema Desarrollado con Mtodos Formales

6. UNA SOLUCIN FORMAL COMPLETA

Realizada por el equipo de verificacin.

6.1 REQUERIMIENTOS
A parte de los requerimientos especificados anteriormente se aadieron los siguientes:

Mantener el conjunto de botones que han sido pulsados dentro del ascensor.
Mantener el conjunto de botones que han sido pulsados fuera del ascensor: numero de piso en el cual est
esperando un pasajero y direccin pedida.
Parar cuando el ascensor no tiene ms peticiones que atender.
Servir todas las peticiones realizadas fuera del ascensor dando igual prioridad.
Servir todas las peticiones realizadas dentro del ascensor secuencialmente segn la direccin del ascensor.
Asegurar que las peticiones que se encuentran en la direccin del ascensor se atienden a tiempo de manera que se
maximice el uso del ascensor.

6.2DISEO

Para el diseo se realizaron tanto diagramas UML como especificaciones formales.

Diagramas UML:
o Las principales clases del diagrama UML eran: Elevator y ElevatorSystem
o El principal mtodo de la clase Elevator era UpdateElevator. Estaba basado en el principio del menor
trabajo. Es decir, el ascensor no cambiaba de direccin hasta que no haba algn motivo para continuar en
la misma direccin.
Especificacin formal:
o Basada en lgica de primer orden.
o Realizaron pruebas que les aseguraron que se segua la especificacin. En este proceso de verificacin
encontraron errores principalmente producidos por una especificacin incompleta. Por ejemplo, un error
fue debido a que no se especificaba como el ascensor debera reanudar el movimiento despus de haber
parado.
o El tiempo que tardaron en realizar la especificacin fue:

5 horas: especificacin inicial

10 horas: revisar especificacin (encontrar y corregir errores).

10 horas: realizar la verificacin de la especificacin.
o En conclusin: gracias a los mtodos formales, el equipo de verificacin descubri todos los errores de la
especificacin antes de la implementacin.
o El proceso de verificacin produjo un buen diseo que no necesito cambios basados en descubrimientos de
la implementacin o las pruebas.

6.3Implementacin

El equipo de verificacin traslado su pseudocdigo en C++ casi de manera directa:

o Los predicados fueron traducidos como llamadas a funciones.
o Las asignaciones mltiples se cambiaron a secuencias de asignaciones simples.
o El no determinismo se tradujo en clausulas if que se resolvan en el orden en que aparecan en el
pseudocdigo.

8|Pgina

Sistema Desarrollado con Mtodos Formales

El equipo de verificacin implemento un cdigo funcionalmente correcto. En su primera ejecucin no se detectaron

errores.
En cuanto al estilo, fue mejor que el de los otros equipos.
En conclusin, el equipo de verificacin realizo un excelente trabajo de programacin.

7. Conclusiones

La formacin en mtodos formales incrementa las capacidades para analizar y disear software de los
desarrolladores de software.

Se puede conseguir software de mayor calidad si se combinan mtodos formales con mtodos no formales.

Se debera ensear mtodos formales a todos los alumnos de titulaciones universitarias relacionadas con el
desarrollo de software.

9|Pgina

Sistema Desarrollado con Mtodos Formales

8. PREGUNTAS TIPO TEST (en verde las opciones correctas)

1. Segn el siguiente trozo de cdigo de especificacin:

( p : Person | OnFloor(elevator,p) equal(elevator.direction,p.direction) :AddPerson(p) )

Qu funcionalidad del ascensor se est especificando?
a) Cuando se cambia la direccin del ascensor
b) Cuando se atiende a la llamada del ascensor
c) Cuando se hace una parada de emergencia
d) Cuando se detecta que el ascensor est lleno
2. Segn el siguiente trozo de cdigo de especificacin:

( (GoingDown(elevator) elevator.current_floor := elevator.current_floor -1) (GoingUp(elevator)

elevator.current_floor := elevator.current_floor +1) )
Qu funcionalidad del ascensor se est especificando?
a) La actualizacin de la posicin del ascensor
b) Cuando se atiende a la llamada del ascensor
c) Que hace cuando no tiene peticiones
d) Cuando cambiar de sentido
3. El uso de los mtodos formales reduce el nmero de errores en los sistemas?
a) Por norma general si
b) No, en ningn caso
c) Dependiendo de los requisitos del sistema
d) Si pero solo si se realizan pruebas formales
4. Para qu podemos utilizar mtodos formales?
a) Solo para especificar requerimientos
b) Para verificar las especificaciones, nicamente.
c) En todos los casos anteriores
d) Ninguna de los anteriores

10 | P g i n a

Sistema Desarrollado con Mtodos Formales

JUSTIFICACIONES
1.
a) Es incorrecta ya que en ningn momento se hace referencia al movimiento del mismo.
b) Es correcta ya que se est definiendo la situacin en la que se agrega a una persona a la lista de personas que estn
dentro del ascensor y en eso consiste la atencin a la llamada (pulsacin del botn) del ascensor.
c) Incorrecta debido a que en ningn momento se hace referencia a la parada del mismo.
d) Incorrecta porque no hay ningn predicado que haga referencia a ello.
2.
a) Es correcta porque se est modificando la posicin actual del ascensor.
b) Es incorrecta ya que no se est haciendo referencia a ninguna llamada por parte de pasajeros. Ni de los propios
pasajeros.
c) Es incorrecta debido a que no se especifica ninguna condicin que evale si se tienen o no peticiones.
d) Es incorrecta porque no se hace referencia al sentido.
3.
a) Si debido a que al utilizarse con un lenguaje que evita ambigedades se evitan de por s los errores que ellas
ocasionaran.
b) Es incorrecta, debido a que con los mtodos formales si se pueden reducir los errores como consecuencia por ejemplo
de utilizar un lenguaje con un menor nmero de obviedades al especificar los requisitos.
c) Es incorrecta, ya que estos no influyen en el nmero de errores, porque si se han recogido bien, ya se omitirn errores
que sean consecuencia de ellos.
d) Las pruebas formales ayudan a detectar errores, no a impedirlos, como toda prueba.
4.
a) Correcta, pero no nicamente.
b) Correcta, pero al igual que en la anterior no es en lo nico que se puede utilizar
c) Correcta, ya que en los dos casos anteriores se puede utilizar.
d) Incorrecta ya que la opcin c) es la correcta.

11 | P g i n a