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
8/18/2019 Sistema de hoare
2/30
8/18/2019 Sistema de hoare
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
8/18/2019 Sistema de hoare
4/30
OBJETIVO DE LA INVESTIG
Introducción de métodos formales en el iformación?
Se mejora el desarrollo de sistemas?
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
7/30
GRUPO DE CONTROL (
En 2 casos nejecutable.
Du licación
3 implementaciones fallaronen todos los casos de estudio.
Una única f
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
10/30
GRUPO DE MÉTODOS FORMA
Ejemplo: Post-condición para la funcióndescarga y movimiento del ascensor queun equipo.
8/18/2019 Sistema de hoare
11/30
GRUPO DE MÉTODOS FORMA
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.
8/18/2019 Sistema de hoare
12/30
GRUPO DE MÉTODOS FORMA
Ejemplo: Especificación de otro equipo de piso objetivo de destino.
Este equipo usó el lenguaje de especificcorrectamente siendo claro y conciso.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
14/30
8/18/2019 Sistema de hoare
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
8/18/2019 Sistema de hoare
16/30
SOLUCIÓN FORMAL COMPL
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.
8/18/2019 Sistema de hoare
17/30
SOLUCIÓN FORMAL COMPL
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.
8/18/2019 Sistema de hoare
18/30
SOLUCIÓN FORMAL COMPL
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.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
20/30
SISTEMA DESARROLLADO CON
MÉTODOS FORMALES Grupo 14
Leonardo Antelo OcchiuzziCristina Fernández Sampayo
F. Alejandro Foglia
8/18/2019 Sistema de hoare
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)
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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:
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
26/30
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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.
8/18/2019 Sistema de hoare
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
8/18/2019 Sistema de hoare
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.
Top Related