Desarrollo de los casos de uso
Programa en S7 Escenario:
Se ha proseguido el trabajo en la correcta estructuraci´on de las clases que conformaran el universo S7, para ello se han a˜nadido las clases Operator y Direction, para lograr un nivel a´un m´as bajo que el de Instruction.
As´ı mismo, se a˜naden dos vectores de entradas y salidas para lograr conectar la l´ogica de S7 con lo visualizado en Windows Forms, para tratar de lograr una primera conexi´on entre ambos elementos. Se puede comprobar que el programa responde correctamente a la programaci´on de instrucciones sencillas.
Simular Escenario y Manipular E/S:
En relaci´on con lo anteriormente visto, se han a˜nadido entradas y salidas, creando diversos Check- box en el Form1.h con su nombre simb´olico para probar la funci´on Change Names y la lectura co- rrecta de los nombres simb´olicos. Esto ir´a conectado a los vectores creados para lograr la conexi´on anteriormente mencionada, por tanto se crearan tantos CheckBox como E/S se han contemplado (7 y 7 en principio).
Se ha introducido tambi´en un timer y se ha a˜nadido una funci´on (Check-in) para comprobar el estado de las entradas en cada comienzo de ciclo y actualizar el estado de las salidas al final de cada ciclo.
Comprobaci´on del c´odigo en S7:
Para lograr una mejor estructuraci´on del Parser y ayudar a simplificarlo, se han creado unas clases de referencia de instrucciones v´alidas.
Adem´as, se comprueba que los hasta 4 TextBox creados se validen correctamente, y almacenen su informaci´on en el Segmento esperado, a fin de que el bloque quede almacenado en el orden esperado, algo vital de cara a poder relacionar cada instrucci´on en su segmento, y cada segmento en su bloque.
Por ´ultimo, para gestionar el comportamiento de las funciones de una manera organizada, se ha creado la clase logic, en la que se ir´an a˜nadiendo las instrucciones que se deseen contemplar en cada versi´on y har´a las veces de biblioteca de funciones.
Diagrama de clases
Como se puede apreciar a continuaci´on, se ha estructurado con m´as detalle las clases relacionadas con el universo de Step 7, para lograr una sencillez que haga m´as claro y legible el c´odigo.
Ahora las instrucciones se fragmentan a un nivel a´un m´as bajo, con las nuevas clases Operator y Direction, adem´as de dar la posibilidad de que sean contadores.
La clase operator servir´a para poder realizar las comprobaciones pertinentes con la instrucci´on introducida por el usuario y los operadores habilitados en la base de datos. De manera an´aloga, la clase direction tendr´a un comportamiento similar, con la salvedad de que comprobar´a la base de datos de direcciones v´alidas.
Tambi´en se ha creado la clase counter, para dar una primera versi´on de los contadores en esta versi´on, para realizar pruebas de funciones de mayor complejidad.
3.5. CICLOS DE DESARROLLO 43
La clase logic ser´a la encargada de comprobar lo anteriormente descrito, con la biblioteca de funciones de STEP7 contempladas en la aplicaci´on. Bastar´a as´ı con ir a˜nadiendo nuevas funciones y su comportamiento para ampliar el espectro de operadores registrados en la aplicaci´on.
En cuanto a las clases relacionadas con la comparaci´on del c´odigo introducido por el usuario, se ha incluido la clase references, que es en la que est´an incluidas las direcciones v´alidas que puede usar el usuario en su c´odigo.
Figura 3.8: Diagrama de clases: Comparator: Ciclo 2
Interfaz de usuario
Esta versi´on deja de lado la ventana de visualizaci´on del entorno, para ´unicamente trabajar y organizar la versi´on de la programaci´on de c´odigo en S7, por tanto se busca crear los vectores creados en el interfaz, manteniendo el panel de los distintos segmentos y la tecla de cambiar los nombres simb´olicos.
3.5. CICLOS DE DESARROLLO 45
Pruebas
En este segundo ciclo las pruebas se han basado comprobar el correcto funcionamiento de las primeras instrucciones contempladas.
Para ello se han realizado pruebas de c´odigo en los diferentes segmentos, se ha valido y visto que aparecen como c´odigo v´alido (en color verde) y que las E/S mostradas reaccionaban seg´un lo programado.
As´ı mismo, al introducirse c´odigo no v´alido, no pasa a simular y resalta en rojo los segmentos con fallos.
3.5.3.
Ciclo 3
Desarrollo de los casos de uso
Programa en S7 Escenario:
Tanto el ER y RLO se incluyen dentro de Block en vez de en Logic, lo cual tiene bastante m´as sentido y va a resultar m´as sencillo a la hora de operar con la l´ogica del bloque. As´ı, cada vez que se inicie un bloque ambos valores se podr´an iniciar al valor deseado con independencia de lo que se vaya comprobando en la clase Logic.
Esto representa un cambio bastante significativo, ya que los bits ER y RLO son la base de S7, y por tanto su correcta manipulaci´on y entendimiento supondr´a un factor vital de cara a crear funciones m´as avanzadas de una manera compleja y sencilla, haciendo el c´odigo m´as comprensible para el usuario.
Adem´as, en el block se recoger´an las direcciones de memoria contempladas en la soluci´on final, siendo sobre este mismo sobre el que se podr´an a˜nadir o eliminar las direcciones necesarias (con cuidado de no sobrecargar la capacidad del sistema operativo).
Simular Escenario y Manipular E/S:
Se a˜nade tanto un temporizador como un contador a las entradas/salidas anteriormente contem- pladas, para pasar a realizar comprobaciones del correcto funcionamiento de ambos.
Se basan en un textbox solo de lectura en el que se visualiza el valor que tienen en todo momento ambos, adem´as de otro textbox que es la direcci´on del elemento (Z o T).
Comprobaci´on del c´odigo en S7:
Se a˜naden las funciones FR, ZV, ZR, L y SE, de cara a poder manejar correctamente los tempo- rizadores y dotar al programa de las principales funciones de manipulaci´on de los mismos.
Con esto se pretende lograr una versi´on m´as rica en la que comenzar a realizar pruebas de c´odigos con cierta complejidad, para analizar la estabilidad de las funciones introducidas hasta esta version.
Adem´as, se a˜nadir´an una lista de instrucciones y una lista de direcciones.
La lista de instrucciones servir´a para ver si la direcci´on es v´alida, mientras que la lista de direc- ciones ser´a sobre la que se opere cada instrucci´on, de cara a lograr un comportamiento estable del programa. Es decir, una la usaremos como medida de lectura de c´odigo y otra se empleara a la hora de simular.
Diagrama de clases
En este caso, las clases son similares a las del Ciclo 2, con la salvedad de que se ha creado la clase Names, para realizar la gesti´on de los nombres y nombres simb´olicos que tendr´an las diferentes direcciones de memoria del programa.
Se ha decidido crear esta clase debido a la multitud de veces que aparece a lo largo del c´odigo la necesidad de realizar comprobaciones o asignaciones con nombres, as´ı como crear las funciones de asignaci´on dentro de la misma clase.
Interfaz de usuario
3.5. CICLOS DE DESARROLLO 47
Figura 3.10: Clase Names: Ciclo 3
ciclo, con el a˜nadido de la distribuci´on de Entradas y Salidas creadas en el ciclo 2, y el a˜nadido del temporizador y contador en pruebas.
Figura 3.11: Interfaz modo programar: Ciclo 3
En cuanto a la simulaci´on, se vuelve al cambio de color para hacer representativo el cambio de ventanas, de cara a preparar el salto en la siguiente versi´on de la ventana de visualizaci´on en 3D.
Aspectos t´ecnicos
Lo m´as importante de esta iteraci´on es como se han desarrollado las funciones de l´ogica del pro- grama, que ser´an las traductoras entre S7-C++.
La clase Logic contiene todas las instrucciones de S7 reconocidas en el programa, por lo que ser´a importante que todo funcione adecuadamente. Es decir, ser´a la librer´ıa de funciones S7 recogidas en la aplicaci´on e interpretables.
Se han tratado de programar todas las funciones ah´ı recogidas de una manera similar, para que cualquier usuario que quiera a˜nadir una funci´on no tenga m´as que observar la estructura de una existente y modificar los aspectos a los que afecta la nueva instrucci´on a a˜nadir a la librer´ıa.
Cada l´ınea de c´odigo ir´a pasando por esta clase a la hora de simular de manera ordenada, de forma que la simulaci´on sea fiel a lo programado.
Figura 3.12: Interfaz modo simular: Ciclo 3
Pruebas
Se ha comprobado que el cambio de color representativo al modo en el que se encuentra el programa (simular o programar) se refleja correctamente.
As´ı mismo, se han realizado pruebas con los contadores y temporizadores, para ver que funcionan seg´un lo esperado y tienen un comportamiento adecuado.
Estas pruebas se han realizando tratando de crear c´odigos algo m´as complejos, con el fin de com- probar si los funciones de la clase Logic funcionan de manera adecuada.
3.5. CICLOS DE DESARROLLO 49
3.5.4.
Ciclo 4
Desarrollo de los casos de uso
Escoge escenario:
Se realiza un primer men´u en el que se define un escenario, de cara a probar el futuro men´u de elecci´on de opciones.
Adem´as se a˜nade una funci´on b´asica de carga de escenario en funci´on de un par´ametro que indica el n´umero de escenario, aunque como en este ciclo ´unicamente se va a contemplar uno, no se entrar´a en m´as detalle en ello, siempre se cargar´a el escenario por defecto.
Programa en S7 Escenario:
En esta versi´on se proceder´a a crear un escenario compuesto de: suelo, cinta/s, caja/s, sensor/es.
El suelo es un elemento est´atico con car´acter decorativo para que el acabado de la ventana de OpenGL sea m´as visual. Por tanto, es un objeto bastante simple. Con la adici´on de suelos creamos la lista de suelos, que compondr´a la base de nuestro escenario.
Las cintas son la composici´on de 5 tramos de cinta, y tiene un car´acter activo en la aplicaci´on. Si esta activa mueve todos sus tramos y todo lo que haya sostenido encima de ellos. Si esta inactiva debe tener a los objetos en contacto est´aticos. Por ello, creamos interacciones con las cajas para programar funciones que hagan que las cintas en contacto con cualquier cinta se mueven si la cinta est´a en movimiento. Son actuadores, por tanto ser´an reconocidos como salidas del programa.
Las cajas con un elemento no programable por el usuario, que tienen interacciones con todos los elementos del escenario. Es el objeto dise˜nado para tratar de llevarlo al final del escenario, y a pesar de su comportamiento pasivo, ser´a la palanca para activar ciertos elementos (sensores).
Los sensores (de barrera ´optica en esta aplicaci´on) son una entrada no manipulable por el usuario, pero si programable, es decir, estar´a activo cuando algo interfiera en su rango l´aser. Este estado de activo/inactivo podr´a ser usado por el usuario para programar eventos.
Todos los elementos anteriormente descritos se han agrupado en listas de elementos de su tipo, con el fin de simplificar cualquier clase de interacci´on entre diferentes objetos, as´ı como tener un mejor control de la creaci´on y asignaci´on de escenarios.
El Mundo se basar´a en crear todas las listas de elementos y a˜nadir las interacciones entre todos, con lo cual ser´a una clase lo m´as sencilla posible a fin de que sea f´acilmente comprensible y modificable, ya que ser´a el motor para realizar cualquier adici´on de elementos.
Por tanto, en el Form se programar´a un enlace entre ambos apartados mediante funciones que conectan estados activos/inactivos de los elementos simulados con estados de activos/inactivos de los diferentes vectores de entradas y salidas definidos.
Este enlace ser´a din´amico en funci´on del escenario cargado, ya que comprueba los elementos que hay disponibles en cada escenario y los asigna autom´aticamente en orden en el vector de entradas y salidas, asign´andoles adem´as el nombre simb´olico sugerido.
Simular Escenario y Manipular E/S:
Tras realizar una serie de comprobaci´on externas al programa, se a˜nade la ventana de la visua- lizaci´on en 3D del entorno de simulaci´on, en las que se puede comprobar de una manera m´as representativa lo programado en el c´odigo y el correcto funcionamiento de toda la l´ogica progra-
mada.
Para ello se recurrir´a a a˜nadir una ventana de OpenGL en un Panel, que estar´a oculto en el modo programar c´odigo y se mostrar´a en el modo ejecuci´on.
Para poder representar el escenario, este Panel se apoyar´a en la clase Glut, ya que no se busca una perfecci´on de gr´aficos si no una sencillez y utilidad grandes.
Con estos elementos ya se podr´a empezar a visualizar un entorno compuesto de cintas, sensores, cajas y bombillas.
Diagrama de clases
La estructura b´asica de clases del programa es similar a las versiones anteriores, con el a˜nadido de todo lo relacionado con el escenario (clases contenidas en la carpeta Mundo).
Esta carpeta tiene una serie de clases sobre las que se apoya para todo el tema de la visualizaci´on de los elementos (carpeta dibujo), que ser´an las clases de OpenGL y todas las Glut incluidas.
Con todo ello, el diagrama general de clases quedar´a reflejado a continuaci´on.
Figura 3.13: Diagrama de clases: Ciclo 4
Es por ello que conviene presentar las clases incluidas en Mundo, para ver los atributos y funciones principales de las mismas.
Los elementos creados se guardan en una lista de elementos de su tipo, que ser´an las que conformen el mundo virtual creado en cada escenario.
Todos los elementos tienes una posici´on de referencia y unas dimensiones, adem´as de una funci´on Dibuja() que es la encargada de mostrar en el escenario los diferentes elementos.
Adem´as, algunos objetos tienes la funci´on Move() que se basa en desplazar a aquellos objetos m´oviles en los casos en que sea necesario.
El atributo active indica aquellos objetos que pueden estar activos o no, que ser´an los programables en el entorno.
As´ı mismo, se incluye la clase interact, la cual es usada para analizar las posibles interacciones entre los distintos elementos que componen el mundo.
3.5. CICLOS DE DESARROLLO 51
Interfaz de usuario
En cuanto al interfaz de usuario, en esta versi´on ya se empieza a trabajar en el men´u principal de programa, en el cual el usuario podr´a escoger entre varias opciones, y se empezar´a a buscar un resultado algo m´as visual.
Figura 3.15: Interfaz modo menu: Ciclo 4
La ventana de programaci´on de c´odigo del escenario no presenta ninguna variaci´on respecto a la versi´on anterior salvo el bot´on de Go to Menu, para poder ir cambiando entre las 3 ventanas de visualizaci´on.
3.5. CICLOS DE DESARROLLO 53
En cuanto a la ventana de ejecuci´on, se comienza a visualizar el escenario definido, compuesto de 2 cintas, 2 sensores y 1 caja, elementos que se rigen seg´un lo programado en la ventana de programaci´on de c´odigo.
Figura 3.17: Interfaz modo simular: Ciclo 4
Aspectos t´ecnicos
En este ciclo se realiza probablemente la implementaci´on m´as complicada del programa, teniendo que a˜nadir una ventana de OpenGL al interfaz de Windows Forms.
Para lograr ello, por un lado emplearemos una clase OpenGL especialmente dise˜nada para trabajar como elemento NativeWindow. Su constructor tendr´a como par´ametro un panel, por tanto, al a˜nadir un panel al Form1.h y usarlo para construir en ´el una ventana de OpenGL, tendremos una primera ventana de visualizaci´on.
Para poder dibujar en el panel los elementos, se emplearan las diversas funciones que ofrece la librer´ıa de visualizaci´on de OpenGl Glut, que adem´as usando la librer´ıa adaptada usada en las pr´acticas de la ETSIDI, lograremos cargar ciertas texturas con las funciones auxiliares recogidas.
Esto se consigue con la clase auxiliar textures, que sirve para cargar todos los par´ametros necesarios para la realizaci´on de la carga de texturas y su dibujado en los elementos, en esta aplicaci´on en forma de cuadrados de mayor o menos tama˜no que representar´an cada v´ertice de la imagen.
Pruebas
Las nuevas funciones han sido probadas en esta versi´on. No obstante, el mayor cambio lo ha supuesto la aparici´on del mundo y el escenario simulado.
Por ello, en cada objeto que se ha creado ha sido importante ver su visualizaci´on en el escenario para ir retocando cualquier error o imperfecci´on a corregir. Adem´as, para ver el comportamiento de los objetos en el escenario se ha tenido cuidado de comprobar distintos c´odigos.
Otra parte primordial de las pruebas es que las interacciones entre objetos fuesen adecuadas, siendo los contactos caja-cinta y caja-sensor las necesarias de perfeccionar.
Una vez logrado que todo esto fuera seg´un lo esperado, se han realizado pruebas de la uni´on realizada entre las E/S representadas por botones en el programa con el escenario simulado, a fin de que el nexo entre mundos que se esperaba lograr fuera el adecuado.
En este ciclo se han ido puliendo las diferentes funciones de asignaci´on de elementos a botones, asignaci´on de estado de las entradas cada ciclo y de actualizaci´on de salidas al final de los mismos, para lograr la meta de este ciclo, llegar a una versi´on casi definitiva de este primer prototipo del programa.
3.5. CICLOS DE DESARROLLO 55
3.5.5.
Ciclo 5
Este ciclo supondr´a el ´ultimo ciclo de desarrollo contemplado en este prototipo del programa, pudiendo surgir nuevos ciclos e iteraciones en desarrollos futuros.
Desarrollo de los casos de uso
Escoge escenario:
Se han a˜nadido 3 escenarios adicionales, hasta conformar un entorno de 4 escenarios que son totalmente seleccionables. Para poder lograr esto, se ha modificado la clase Mundo a˜nadiendo una funci´on (Inicializa(int)) que seg´un el par´ametro que se le pase, carga uno u otro escenario.
As´ı mismo, se ha configurado que lo primero que se cargue al seleccionar un escenario sea el entorno en s´ı y no la ventana de programaci´on de c´odigo, a fin de que el usuario pueda tener una primera imagen visual de los elementos que componen el escenario.
Programa en S7 Escenario:
Se han a˜nadido algunos elementos al mundo simulado, ellos son las bombillas y las paredes.
Las paredes tienen una funci´on simplemente est´etica como lo es el suelo, y es para dotar al escenario del mayor realismo posible.
En cuanto a las bombillas, son un elemento activo del escenario, y seg´un se haya programado el c´odigo, pueden encenderse (que el estado activo sea true) o apagarse (lo inverso), todo ello representado con un cambio de color en las mismas (o color verde en encendido, o rojo cuando se encuentran desactivadas).
Diagrama de clases
La adicion de las clases bombilla, pared, lista bombillas y lista pared es muy similar a las clases a˜nadidas en el ciclo 4 de desarrollo.
En este caso, se comprueba que la clase bombilla tiene la diferencia de que no tiene la funci´on