Sistema de hoare

8/18/2019 Sistema de hoare

1/30

SISTEMA DESARROLLCON MÉTODOS FORMA

(Docu

G R U P O 1 4 :

L E O N A R D O A N T E L O O C C H I U Z ZI

C R I S T I N A F E R N Á N D E Z S A M P A Y O A L E J A N D R O F O G L I A


2/30


3/30

INTRODUCCIÓN

Estudio realizado con 2 grupos [GC y GMF] destudiantes de la Universidad de Miami e

En el 3º año de estudios.

Un grupo OOD, y el otro OOD + Métodos

Desarrollo del sistema de control de un apara ver y comparar los resultados (IEEE


4/30

OBJETIVO DE LA INVESTIG

Introducción de métodos formales en el iformación?

Se mejora el desarrollo de sistemas?


5/30

REQUERIMIENTOS DEL SIS

Estado del ascensor(sentido=UP,DOWN,STOPPED;posición

Atención de peticiones por parte del usua(pisoActual;dirección;pisoDestino).

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.


6/30

GRUPO DE CONTROL (

13 equipos de 2 personas. Sin usar Métodos Formales. Ninguna documentación Tampoco UM

se aconsejó. Diseños fuertemente acoplados.

Ejemplos:

Poco eficientes bucle infinito. Algoritmos complejos.

Solo atiende peticiones de pasajeros de dentro.


7/30

GRUPO DE CONTROL (

En 2 casos nejecutable.

Du licación

3 implementaciones fallaronen todos los casos de estudio.

Una única f


8/30

GRUPO DE MÉTODOS FORM

Grupo Métodos Formales: 6 equipos de 2 puno.

Realizaron 2 tipos de diseño: 1er tipo: Basado en diagramas UML. 3 equipos sigu

2 de ellos indicaron una abstracción lógica entre elascensor y la interfaz gráfica de usuario.El tercer equipo produjo un diseño altamente acop

2do tipo: Basado en pre-condiciones, post-condicionescritas para funciones particulares. Los restantes 3siguieron esta orientación.


9/30

GRUPO DE MÉTODOS FORMA

3 equipos especificaron funciones paracuándo y a donde mover el ascensor. Aespecificaron los siguientes tipos de fu Actualizar lista de peticiones.

Comprobar petición actual en el sistema.

Movimiento del ascensor.

Actualizar gente y peticiones dentro del ascens

Cambiar dirección del ascensor.


10/30


Ejemplo: Post-condición para la funcióndescarga y movimiento del ascensor queun equipo.


11/30


El equipo tenía exactamente definidas que operdeberían ocurrir (eliminar, añadir, cambiar el pisque estados.

Aunque la especificación usada no era muy cor e er an a er usa o e cuan ca or en

EXISTE. No deberían haber usado la ASIGNACIÓN e IGUALDA Está especificación deja una parte del espacio de estad

Excepto este error, la especificación muestra elcomportamiento del ascensor bastante bien.


12/30


Ejemplo: Especificación de otro equipo de piso objetivo de destino.

Este equipo usó el lenguaje de especificcorrectamente siendo claro y conciso.


13/30

COMPARACIONES (1

Diseño: Los diseños usados por los dos grupos no fuero

significativamente diferentes.

grupo e con ro pro u o un se o m s acopgrupo de métodos formales.

Los algoritmos propuestos por el grupo de métoson más eficientes y cumplen en mayor medida

Parece que formar al grupo de los métodos form

análisis formal ha incrementado su habilidad paalgoritmos.


14/30


15/30

SOLUCIÓN FORMAL COMPL

Requerimientos: A parte de los requerimieespecificados anteriormente se añadieron l Mantener el conjunto de botones que han sido pul

ascensor.

Mantener el conjunto de botones que han sido pu

dirección pedida.

Parar cuando el ascensor no tiene más peticiones

Servir todas las peticiones realizadas fuera del ascigual prioridad .

Servir todas las peticiones realizadas dentro del assecuencialmente según la dirección del ascensor.

Asegurar que las peticiones que se encuentran en lascensor se atienden a tiempo (maximizar el uso d


16/30


Diseño:

Para el diseño se realizaron tanto diagramasespecificaciones formales.

Diagramas UML:

Elevator y ElevatorSystem

El principal método de la clase ElevatorUpdateElevator. Estaba basado en el prmenor trabajo. Es decir, el ascensor no

dirección hasta que no había algún moticontinuar en la misma dirección.


17/30


Especificación formal: Basada en lógica de primer orden.

Realizaron pruebas que les aseguraron que se seguEn este proceso de verificación encontraron erroreproducidos por una especificación incompleta. Porfue debido a que no se especificaba como el ascen

reanudar el movimiento después de haber parado. El tiempo que tardaron en realizar la especificació

• 5 horas: especificación inicial

• 10 horas: revisar especificación (encontrar y corregir

• 10 horas: realizar la verificación de la especificación.

En conclusión: gracias a los métodos formales, el e verificación descubrió todos los errores de la especla implementación.

El proceso de verificación produjo un buen diseñocambios basados en descubrimientos de la implempruebas.


18/30


Implementación: El equipo de verificación traslado su pseudocód

de manera directa:

Los predicados fueron traducidos como llamadas

Las asignaciones múltiples se cambiaron a secuen

. El no determinismo se tradujo en clausulas if que

el orden en que aparecían en el pseudocódigo.

El equipo de verificación implemento un códigofuncionalmente correcto. En su primera ejecuciódetectaron errores.

En cuanto al estilo, fue mejor que el de los otros

En conclusión, el equipo de verificación realizo utrabajo de programación.


19/30

CONCLUSIONES…

La formación en métodos formales incremcapacidades para analizar y diseñar softwdesarrolladores de software.

Se uede conse uir software de ma or cacombinan métodos formales con métodoformales.

Se debería enseñar métodos formales a toalumnos de titulaciones universitarias re

con el desarrollo de software.


20/30

SISTEMA DESARROLLADO CON

MÉTODOS FORMALES Grupo 14

Leonardo Antelo OcchiuzziCristina Fernández Sampayo

F. Alejandro Foglia


21/30

1. Resumen

2. Introducción

3. Requerimientos

4. Diseño

4.1 Diseño del Grupo de Control

4.2 Diseño del Grupo Formal

4.3 Comparaciones

5. Implementación

5.1 Implementación del grupo de control

5.2 Implementación del grupo de métodos formales

5.3 Comparaciones

6. UNA SOLUCIÓN FORMAL COMPLETA

6.1 REQUERIMIENTOS

6.2DISEÑO

6.3Implementación

7. Conclusiones

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


22/30

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ónEquipo 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. Requerimientoso 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 Clasespara la interfaz gráfica.


23/30

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 leresultaba infructuoso seguir en la dirección actual. El algoritmo era muy complejo y se basabaprincipalmente 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 s iguieron esta orientación:

2 de ellos indicaron una abstracción lógica entre el sistema y la librería de interfaz con la cualsería implementado. Es decir, las clases fueron diseñadas independientemente de la interfazgrá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 estadodel 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 qrealizaba esta operación era:


24/30

Esto demuestra q el equipo tenía exactamente definidas que operaciones podrían ocurrir (eliminar, añadir, cambiar el pisoactual) y en que estados deberían ocurrir. Aunque la especificación usada no era muy correcta. Deberían haber usado elcuantificador PARA TODO en vez del EXISTE. Tampoco deberían usar las asignaciones := ya que su uso no es apropiado enlógica de primer orden. Por último está especificación deja una parte del espacio de estados sin examinar: si el ascensorestá subiendo o bajando pero de repente para, de acuerdo con la especificación nunca se volverá a mover. Excepto esteerror, 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.


25/30

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.


26/30


27/30

6. UNA SOLUCIÓN FORMAL COMPLETARealizada 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 semaximice 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 ElevatorSystemo 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 enla 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 errorfue debido a que no se especificaba como el ascensor debería reanudar el movimiento después de haberparado.

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 laespecificación antes de la implementación.

o El proceso de verificación produjo un buen diseño que no necesito cambios basados en descubrimientos dela 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.


28/30

• El equipo de verificación implemento un código funcionalmente correcto. En su primera ejecución no se detectaronerrores.

• 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 eldesarrollo de software.


29/30

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


30/30

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ándentro 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 propiospasajeros.

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 ellasocasionarían.

b) Es incorrecta, debido a que con los métodos formales si se pueden reducir los errores como consecuencia por ejemplode 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 erroresque 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.

Sistema de hoare

Documents