You are on page 1of 30

SISTEMA DESARROLLADO

CON MÉTODOS FORMALES
(Documento con preguntas tipo test)
GRUPO 14:
LEONARDO ANTELO OCCHI UZZI
CRI STI NA FERNÁNDEZ SAMPAYO
ALEJANDRO FOGLI A
ÍNDICE
Introducción
Objetivo de la investigación
Requisitos del Sistema de Control del Ascensor
Desarrollo realizado por el Grupo de Control
Desarrollo realizado por el Grupo de Métodos Desarrollo realizado por el Grupo de Métodos
Formales
Solución Formal Completa
Conclusiones
INTRODUCCIÓN
Estudio realizado con 2 grupos [GC y GMF] de
estudiantes de la Universidad de Miami en Ohio.
En el 3º año de estudios.
Un grupo OOD, y el otro OOD + Métodos formales.
Desarrollo del sistema de control de un ascensor,
para ver y comparar los resultados (IEEE-1987).
OBJETIVO DE LA INVESTIGACIÓN
Introducción de métodos formales en el inicio de la
formación?
Se mejora el desarrollo de sistemas?
REQUERIMIENTOS DEL SISTEMA
Estado del ascensor
(sentido=UP,DOWN,STOPPED;posición=1,2,etc.)
Atención de peticiones por parte del usuario
(pisoActual;dirección;pisoDestino).
Entorno gráfico, con menús y diálogos. Entorno gráfico, con menús y diálogos.
Atención concurrente a otras peticiones.
Uso de OOD, C++ y MS Foundation
Classes para los gráficos.
GRUPO DE CONTROL (1)
13 equipos de 2 personas.
Sin usar Métodos Formales.
Ninguna documentación Tampoco UML, aunque
se aconsejó.
Diseños fuertemente acoplados.
Ejemplos:
Poco eficientes bucle infinito.
Algoritmos complejos.
Solo atiende peticiones de pasajeros de dentro.
GRUPO DE CONTROL (2)
En 2 casos no había
ejecutable.
Duplicación de código.
3 implementaciones fallaron
en todos los casos de estudio.
Duplicación de código.
Una única función.
GRUPO DE MÉTODOS FORMALES (1)
Grupo Métodos Formales: 6 equipos de 2 personas cada
uno.
Realizaron 2 tipos de diseño:
1er tipo: Basado en diagramas UML. 3 equipos siguieron esta
orientación: orientación:
2 de ellos indicaron una abstracción lógica entre el sistema del
ascensor y la interfaz gráfica de usuario.
El tercer equipo produjo un diseño altamente acoplado.
2do tipo: Basado en pre-condiciones, post-condiciones e invariantes
escritas para funciones particulares. Los restantes 3 equipos
siguieron esta orientación.
GRUPO DE MÉTODOS FORMALES (2)
3 equipos especificaron funciones para decidir
cuándo y a donde mover el ascensor. A mayores
especificaron los siguientes tipos de funciones:
Actualizar lista de peticiones.
Comprobar petición actual en el sistema.
Movimiento del ascensor.
Actualizar gente y peticiones dentro del ascensor.
Cambiar dirección del ascensor.
GRUPO DE MÉTODOS FORMALES (3)
Ejemplo: Post-condición para la función de carga,
descarga y movimiento del ascensor que especificó
un equipo.
GRUPO DE MÉTODOS FORMALES (4)
El equipo tenía exactamente definidas que operaciones
deberían ocurrir (eliminar, añadir, cambiar el piso actual) y en
que estados.
Aunque la especificación usada no era muy correcta:
Deberían haber usado el cuantificador PARA TODO en vez del Deberían haber usado el cuantificador PARA TODO en vez del
EXISTE.
No deberían haber usado la ASIGNACIÓN e IGUALDAD.
Está especificación deja una parte del espacio de estados sin examinar.
Excepto este error, la especificación muestra el
comportamiento del ascensor bastante bien.
GRUPO DE MÉTODOS FORMALES (5)
Ejemplo: Especificación de otro equipo en términos
de piso objetivo de destino.
Este equipo usó el lenguaje de especificación
correctamente siendo claro y conciso.
COMPARACIONES (1)
Diseño:
Los diseños usados por los dos grupos no fueron
significativamente diferentes.
El grupo de control produjo un diseño más acoplado que el El grupo de control produjo un diseño más acoplado que el
grupo de métodos formales.
Los algoritmos propuestos por el grupo de métodos formales
son más eficientes y cumplen en mayor medida los requisitos.
Parece que formar al grupo de los métodos formales en
análisis formal ha incrementado su habilidad para diseñar
algoritmos.
COMPARACIONES (2)
Implementación
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 métodos formales. del grupo de métodos formales.
Esto es un claro ejemplo de cómo la formación en análisis
formal puede beneficiar a los programadores, incrementado
sus habilidades para crear programas funcionalmente
correctos.
SOLUCIÓN FORMAL COMPLETA (1)
Requerimientos: A parte de los requerimientos
especificados anteriormente se añadieron 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 ascensor: numero de piso en el cual está esperando un pasajero y
dirección pedida.
Parar cuando el ascensor no tiene más peticiones que atender.
Servir todas las peticiones realizadas fuera del ascensor dando
igual prioridad.
Servir todas las peticiones realizadas dentro del ascensor
secuencialmente según la dirección del ascensor.
Asegurar que las peticiones que se encuentran en la dirección del
ascensor se atienden a tiempo (maximizar el uso del ascensor).
SOLUCIÓN FORMAL COMPLETA (2)
Diseño:
Para el diseño se realizaron tanto diagramas UML como
especificaciones formales.
Diagramas UML:
Las principales clases del diagrama UML eran: Las principales clases del diagrama UML eran:
Elevator y ElevatorSystem
El principal método de la clase Elevator era
UpdateElevator. Estaba basado en el principio del
menor trabajo. Es decir, el ascensor no cambiaba de
dirección hasta que no había algún motivo para
continuar en la misma dirección.
SOLUCIÓN FORMAL COMPLETA (3)
Especificación formal:
Basada en lógica de primer orden.
Realizaron pruebas que les aseguraron que se seguía la especificación.
En este proceso de verificación encontraron errores principalmente
producidos por una especificación incompleta. Por ejemplo, un error
fue debido a que no se especificaba como el ascensor debería
reanudar el movimiento después de haber parado.
El tiempo que tardaron en realizar la especificación fue:
• 5 horas: especificación inicial
• 10 horas: revisar especificación (encontrar y corregir errores).
• 10 horas: realizar la verificación de la especificación.
En conclusión: gracias a los métodos formales, el equipo de
verificación descubrió todos los errores de la especificación antes de
la implementación.
El proceso de verificación produjo un buen diseño que no necesito
cambios basados en descubrimientos de la implementación o las
pruebas.
SOLUCIÓN FORMAL COMPLETA (4)
Implementación:
El equipo de verificación traslado su pseudocódigo en C++ casi
de manera directa:
Los predicados fueron traducidos como llamadas a funciones.
Las asignaciones múltiples se cambiaron a secuencias de
asignaciones simples. asignaciones simples.
El no determinismo se tradujo en clausulas if que se resolvían en
el orden en que aparecían en el pseudocódigo.
El equipo de verificación implemento un código
funcionalmente correcto. En su primera ejecución no se
detectaron errores.
En cuanto al estilo, fue mejor que el de los otros equipos.
En conclusión, el equipo de verificación realizo un excelente
trabajo de programación.
CONCLUSIONES…
La formación en métodos formales incrementa las
capacidades para analizar y diseñar software de los
desarrolladores de software.
Se puede conseguir software de mayor calidad si se Se puede conseguir software de mayor calidad si se
combinan métodos formales con métodos no
formales.
Se debería enseñar métodos formales a todos los
alumnos de titulaciones universitarias relacionadas
con el desarrollo de software.

SISTEMA DESARROLLADO CON
MÉTODOS FORMALES
Grupo 14


Leonardo Antelo Occhiuzzi
Cristina Fernández Sampayo
F. Alejandro Foglia





Sistema Desarrollado con Métodos Formales

2 | P á g i n a



Índice

1. Resumen ......................................................................................................................................... 3
2. Introducción .................................................................................................................................... 3
3. Requerimientos ................................................................................................................................ 3
4. Diseño ........................................................................................................................................... 4
4.1 Diseño del Grupo de Control ............................................................................................................ 4
4.2 Diseño del Grupo Formal ............................................................................................................... 4
4.3 Comparaciones ........................................................................................................................... 5
5. Implementación ................................................................................................................................ 6
5.1 Implementación del grupo de control ................................................................................................. 6
5.2 Implementación del grupo de métodos formales .................................................................................. 7
5.3 Comparaciones .......................................................................................................................... 7
6. UNA SOLUCIÓN FORMAL COMPLETA ......................................................................................................... 8
6.1 REQUERIMIENTOS ......................................................................................................................... 8
6.2DISEÑO ...................................................................................................................................... 8
6.3Implementación ........................................................................................................................... 8
7. Conclusiones ................................................................................................................................... 9
8. PREGUNTAS TIPO TEST (en verde las opciones correctas) ........................................................................... 10

Sistema Desarrollado con Métodos Formales

3 | P á g i n a


1. Resumen
• Se presenta el desarrollo realizado por estudiantes de un sistema de programación 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 método formal basado en lógica de primer orden.
o El otro grupo no uso análisis formal.
• En el artículo se comparan las soluciones de los dos grupos atendiendo a los siguientes parámetros: corrección,
concisión y complejidad.
• Se presta especial atención al grupo que utilizo métodos formales ya que verificó completamente su implementación.
• Se comparan los resultados con otras soluciones.
• Se concluye que la solución propuesta por el grupo que empleo métodos formales es mejor (más correcta) que la del
otro grupo.
2. Introducción
Equipo 1 (Grupo Métodos Formales): 6 equipos de 2 personas= 12 personas
Aprobaron el 100% de los test de estándares
Produjeron mejor diseño e implementación que el equipo 2.
Equipo 2 (Grupo de Control): 13 equipos de 2 personas: 26 personas
Aprobaron el 45.5% de los test de estándares
3. Requerimientos
o Crear un programa que permita manejar un ascensor.
o El usuario podrá realizar peticiones. Una petición contendrá el piso en el cual es echa dicha petición y el piso al que
desea ir el usuario.
o Se mostrarán menús y diálogos.
o Se deberá mostrar gráficamente, la petición actual, el piso actual y el estado del ascensor (parado, subiendo o
bajando).
o Mientras el ascensor está procesando una petición el usuario podrá realizar otras peticiones.
o El algoritmo debe examinar concurrentemente todas las peticiones realizadas y determinar cuál es el siguiente piso
o dirección.
Otros requerimientos: usar diseño orientado a objetos, el lenguaje de programación C++ y Microsoft Fundation Clases
para la interfaz gráfica.

Sistema Desarrollado con Métodos Formales

4 | P á g i n a


4. Diseño
4.1 Diseño del Grupo de Control
• A los estudiantes del grupo de control no se les exigió usar un diseño específico. Ningún equipo presentó diagramas
UML aunque se les aconsejó hacerlo.
• Los 13 equipos presentaron un ejecutable 9 de ellos presentaron también el código fuente.
• El código fuente destacaba por:
o Diseños fuertemente acoplados.
o Mezcla de funcionalidades.
• 4 de los equipos que presentaron el código fuente presentaron también seudocódigo de los algoritmos.
o 1er algoritmo: cumplía 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 dirección cuando le
resultaba infructuoso seguir en la dirección actual. El algoritmo era muy complejo y se basaba
principalmente en el análisis del estado del sistema.
o 3er algoritmo: el ascensor solo atendía la petición más reciente.
o 4º algoritmo: Estaba descrito incompletamente, realizaba todas las peticiones hechas por las personas
que iban dentro del ascensor, pero no atendía a nuevas llamadas.
4.2 Diseño del Grupo Formal
• Realizaron 2 tipos de diseño:
o 1er tipo: Basado en diagramas UML. 3 equipos siguieron esta orientación:
2 de ellos indicaron una abstracción lógica entre el sistema y la librería de interfaz con la cual
sería implementado. Es decir, las clases fueron diseñadas independientemente de la interfaz
gráfica. Esto es una buena práctica ya que reduce el acoplamiento.
El tercer equipo produjo un diseño altamente acoplado: Los módulos que controlaban el estado
del ascensor estaban mezclados con los de visualización.
o 2º tipo: Basado en precondiciones, pos condiciones e invariantes escritas para funciones del diseño.
• 3 equipos especificaron funciones para decidir cuándo y a donde mover el ascensor. A mayores especificaron los
siguientes tipos de funciones:
o Actualizar la lista de peticiones.
o Comprobar la petición actual en el sistema.
o Movimiento del ascensor.
o Actualizar la gente y peticiones dentro del ascensor.
o Cambiar el ascensor de dirección.
Ejemplo de un equipo que especifico la carga, descarga y movimiento del ascensor. La post condición para la función q
realizaba esta operación era:
Sistema Desarrollado con Métodos Formales

5 | P á g i n a


Esto demuestra q el equipo tenía exactamente definidas que operaciones podrían ocurrir (eliminar, añadir, cambiar el piso
actual) y en que estados deberían ocurrir. Aunque la especificación usada no era muy correcta. Deberían haber usado el
cuantificador PARA TODO en vez del EXISTE. Tampoco deberían usar las asignaciones := ya que su uso no es apropiado en
lógica de primer orden. Por último está especificación deja una parte del espacio de estados sin examinar: si el ascensor
está subiendo o bajando pero de repente para, de acuerdo con la especificación nunca se volverá a mover. Excepto este
error, la especificación muestra el comportamiento del ascensor bastante bien.
Ejemplo de otra especificación:

Este equipo uso el lenguaje de especificación correctamente siendo claro y conciso.
4.3 Comparaciones
• Los diseños usados por los dos grupos no fueron significativamente diferentes.
• El grupo de control produjo un diseño más acoplado que el grupo de métodos formales.
• Los algoritmos propuestos por el grupo de métodos formales son más eficientes y cumplen en mayor medida los
requisitos.
• Parece que formar al grupo de los métodos formales en análisis formal ha incrementado su habilidad para diseñar
algoritmos.
Sistema Desarrollado con Métodos Formales

6 | P á g i n a


5. Implementación
5.1 Implementación del grupo de control
• El grupo de control no programo correctamente: su código era extremadamente incorrecto, su estilo de
programación era pobre.
• Solamente 5 de las 11 implementaciones eran correctas. (45.5%)
• La implementación mostraba q los estudiantes carecían de habilidad para programar bien.







Sistema Desarrollado con Métodos Formales

7 | P á g i n a


5.2 Implementación del grupo de métodos formales
• Todas las implementaciones eran funcionalmente correctas. (100%)
• Su código no era demasiado conciso, en algunos casos los niveles de complejidad eran demasiado elevados.
• En cuanto al estilo, algunos grupos tenían buen estilo mientras otros no.
• En conclusión las implementaciones eran bastante buenas aunque se podrían 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 métodos formales.
Esto es un claro ejemplo de cómo la formación en análisis formal puede beneficiar a los programadores, incrementado
sus habilidades para crear programas funcionalmente correctos.


Sistema Desarrollado con Métodos Formales

8 | P á g i n a


6. UNA SOLUCIÓN FORMAL COMPLETA
Realizada por el equipo de verificación.
6.1 REQUERIMIENTOS
A parte de los requerimientos especificados anteriormente se añadieron 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 dirección pedida.
• Parar cuando el ascensor no tiene más peticiones que atender.
• Servir todas las peticiones realizadas fuera del ascensor dando igual prioridad.
• Servir todas las peticiones realizadas dentro del ascensor secuencialmente según la dirección del ascensor.
• Asegurar que las peticiones que se encuentran en la dirección del ascensor se atienden a tiempo de manera que se
maximice el uso del ascensor.
6.2DISEÑO
• Para el diseño se realizaron tanto diagramas UML como especificaciones formales.
• Diagramas UML:
o Las principales clases del diagrama UML eran: Elevator y ElevatorSystem
o El principal método de la clase Elevator era UpdateElevator. Estaba basado en el principio del menor
trabajo. Es decir, el ascensor no cambiaba de dirección hasta que no había algún motivo para continuar en
la misma dirección.
• Especificación formal:
o Basada en lógica de primer orden.
o Realizaron pruebas que les aseguraron que se seguía la especificación. En este proceso de verificación
encontraron errores principalmente producidos por una especificación incompleta. Por ejemplo, un error
fue debido a que no se especificaba como el ascensor debería reanudar el movimiento después de haber
parado.
o El tiempo que tardaron en realizar la especificación fue:
5 horas: especificación inicial
10 horas: revisar especificación (encontrar y corregir errores).
10 horas: realizar la verificación de la especificación.
o En conclusión: gracias a los métodos formales, el equipo de verificación descubrió todos los errores de la
especificación antes de la implementación.
o El proceso de verificación produjo un buen diseño que no necesito cambios basados en descubrimientos de
la implementación o las pruebas.
6.3Implementación
• El equipo de verificación traslado su pseudocódigo en C++ casi de manera directa:
o Los predicados fueron traducidos como llamadas a funciones.
o Las asignaciones múltiples se cambiaron a secuencias de asignaciones simples.
o El no determinismo se tradujo en clausulas if que se resolvían en el orden en que aparecían en el
pseudocódigo.
Sistema Desarrollado con Métodos Formales

9 | P á g i n a

• El equipo de verificación implemento un código funcionalmente correcto. En su primera ejecución no se detectaron
errores.
• En cuanto al estilo, fue mejor que el de los otros equipos.
• En conclusión, el equipo de verificación realizo un excelente trabajo de programación.
7. Conclusiones
La formación en métodos formales incrementa las capacidades para analizar y diseñar software de los
desarrolladores de software.
Se puede conseguir software de mayor calidad si se combinan métodos formales con métodos no formales.
Se debería enseñar métodos formales a todos los alumnos de titulaciones universitarias relacionadas con el
desarrollo de software.
Sistema Desarrollado con Métodos Formales

10 | P á g i n a


8. PREGUNTAS TIPO TEST (en verde las opciones correctas)
1. Según el siguiente trozo de código de especificación:
( ∀p : Person | OnFloor(elevator,p) ∩ equal(elevator.direction,p.direction) :AddPerson(p) )
¿Qué funcionalidad del ascensor se está especificando?
a) Cuando se cambia la dirección 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. Según el siguiente trozo de código de especificación:
( (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 actualización de la posición 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 métodos formales reduce el número de errores en los sistemas?
a) Por norma general si
b) No, en ningún caso
c) Dependiendo de los requisitos del sistema
d) Si pero solo si se realizan pruebas formales
4. ¿Para qué podemos utilizar métodos formales?
a) Solo para especificar requerimientos
b) Para verificar las especificaciones, únicamente.
c) En todos los casos anteriores
d) Ninguna de los anteriores
Sistema Desarrollado con Métodos Formales

11 | P á g i n a


JUSTIFICACIONES
1.
a) Es incorrecta ya que en ningún momento se hace referencia al movimiento del mismo.
b) Es correcta ya que se está definiendo la situación en la que se agrega a una persona a la lista de personas que están
dentro del ascensor y en eso consiste la atención a la llamada (pulsación del botón) del ascensor.
c) Incorrecta debido a que en ningún momento se hace referencia a la parada del mismo.
d) Incorrecta porque no hay ningún predicado que haga referencia a ello.
2.
a) Es correcta porque se está modificando la posición 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 condición que evalúe 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 ambigüedades se evitan de por sí los errores que ellas
ocasionarían.
b) Es incorrecta, debido a que con los métodos formales si se pueden reducir los errores como consecuencia por ejemplo
de utilizar un lenguaje con un menor número de obviedades al especificar los requisitos.
c) Es incorrecta, ya que estos no influyen en el número de errores, porque si se han recogido bien, ya se omitirán 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 opción c) es la correcta.