Perspectivas

La aplicación PetrA ha alcanzado un grado de operatividad y estabilidad adecuados, sin embargo, aún hay mucho trabajo que hacer. En esta sección se enumeran las mejoras que deben realizarsele a PetrA para que obtenga mejor desempeño y presentación. Ahora sólo se espera que este sea el inicio de una herramienta de modelado más poderoza.

Por otro lado, se confía en que la plataforma de desarrollo (Mac OS X), junto con sus herramientas y bibliotecas de objetos-- continúe en uso y desarrollo para que PetrA siga vigente y permita su portabilidad a plataformas futuras.

Las tareas inmediatas o de mediano plazo que se le deben incorporar son:

• Incorporar el uso de las bibliotecas de objetos que ha desarrollado Apple para el manejo de aplicaciones orientadas a documentos, lo cual facilitará el desarrollo posterior de la aplicación. Esto implica la desaparición de la clase Controller, el cambio en algunas clases como PNController (la cual pasaría a ser una clase DocumentController) y de PNView (la cual pasaría a ser una clase Document), y la aparición de dos clases de control PNToolsController y PNPreferencesController (clases de objetos de control para los paneles Tools y Preferences, respectivamente, ya que originalmente el objeto de la clase Controller se encarga de su manejo.

• Incorporarle mecanismo de análisis. Este es el trabajo que más debe tenerse en consideración, lamentablemente el tiempo que se dedicó al desarrollo de PetrA, no nos alcanzó para incorporar algún tipo de técnica. Sin embargo, quedan claras dos cosas: primero debe incorporarse como un hilo de ejecución extra, u otra tarea, ya que las técnicas de análisis de redes de Petri grandes consumen grandes cantidades de tiempo de CPU y memoria. Segundo, como los mecanísmos de análsis varían se debe contemplar que los mecanismos para el análisis sean delegados del objetos PNMatrix, lo que permite flexibilidad de selección las muy diferentes técnicas de análisis que hay con los distintos tipos de redes de Petri.

• Reconsiderar el uso de los NSThread para el manejo dinámico de las transiciones, ya que el manejo de estos objetos es muy limitado para el usuario (pues solo tiene metodos para dar de alta el hilo, dormirlo por un determinado tiempo, y para terminarlo, y hace falta mensajes como yield, para dormir un hilo de manera indeterminada y permitir que otro hilo se ejecute) y, además, se ha observado que el rendimiento decae. Se podría considerar la incorporación de un objeto NSTimedScreen, sin embaro esto complicaría la implantación de las redes de Petri estocásticas. Se puede incorporar alguna de estas soluciones:

  1.

  Utilizar los hilos de Posix, ya que la documentación indica que los NSThread están implantados sobre los hilos de Posix.

  2.

  Crear una clase Thread que permita al usuario un mayor control sobre estas unidades dinámicas.

• Incorporar mejores directivas a PNMatrix para el controlar el despliegue de los objetos gráficos en el PNView, ya que se siguen utilizando arreglos para organizar la lista de objetos desplegados y de objetos seleccionados. Este punto debe tratarse con cuidado, ya que se podría pensar en erradicar el uso de los objetos PNMatrix, sin embargo debe recordarse que estos objetos fueron diseñados para incorporar el uso de redes de Petri jerárquicas.

• Mejorar el manejo del área de dibujo de PetrA, para que el usuario pueda tener mayor control en el diseño de sus modelos. Por el momento sólo nos hemos dedicado al manejo de un tamaño estático, lo cual puede ser un grave inconveniente, pues es bien sabido que si el modelo con redes de Petri de un sistema, es muy complicado, el tamaño de la red crece.

• Incorporar mecanísmos para realizar una distribución automática de la red (distribución topológica). Esta opción será de gran utilidad si se incorporan el manejo de un formato ASCII para representar a una red de Petri. Evidentemente, este formato deberá ser en forma de una matriz de conectividad.

• Incorporar al Inpector opciones para modificar el tamaño de los objetos de la red de Petri, así, como su orientación. Lo cual dará al usuario distintas opciones de trabajar con modelos amplios.

• Permitir al usuario un manejo de conecciones más flexibles, esto es, permitirle al usuario integrarle puntos de control para que las coneccione se representen como curvas. De esta forma, se facilitaría la visualización de modelos complejos.

Entre las implantaciones que se deben realizar a largo plazo en PetrA se encuentrán:

• Incorporar el manejo de distintas redes de Petri, como se ha mencionado en el capítulo 4 de este trabajo de tesis. Como son: redes de Petri con capacidad finita, redes de Petri con tiempo, jerárquicas y coloreadas.

• Incorporar una jerarquía de clases para el permitir distintos métodos de análisis, y los cuales no choquen entre las distintas redes de Petri que se pretenden manejar.

• Incorporar el manejo de distintos iconos para representar lugares, ya que muchas extensiones de redes de Petri representan a los lugares con diferentes figuras, lo que ayuda al usuario a entender mejor el modelo del sistema.

• Incorporar el uso de un lenguaje de modelación, que en este caso puede ser REC, como parte del lenguaje asociado a un arco.