Programación OO vs Programación clásica:
Anuncio
Programación OO vs Programación clásica: Proyecto Posicionamiento 2d en PowerBuilder. Pedraza C. y Pascual D. Facultad de informática - Universidad Politécnica de Valencia. email: [email protected], [email protected] Resumen. La presenta memoria analiza la adaptación de un software creado bajo las guías del diseño estructurado de la ingeniería del software y de carácter secuencial, a un nuevo sistema apoyado en los estándares actuales de programación visual, orientada a objetos y basada en eventos interfaz-usuario. Para ello, se ha seguido de manera secuencial, el esquema de ciclo de vida clásico, seccionando la memoria en las tres fases que incluyen prácticamente todas las metodologías de ingeniería del Sw, análisis, diseño, e implementación. Por último, se señalan las principales conclusiones del trabajo llevado a cabo: las ventajas de la utilización de metodologías en el desarrollo de software. Introducción. La complejidad creciente del software obligan desde hace décadas a la utilización de metodología de análisis, diseño y codificación que garanticen la obtención de un software de calidad. Éste compendio de métodos se recogen en la disciplina llamada Ingeniería del Software, y como el software evoluciona rápidamente, también lo hace ésta ciencia. La aparición de un nuevo compilador, de nuevos lenguajes visuales que se programan o funcionan por el disparo por eventos, las aplicaciones para sistemas distribuidos e Internet, los últimos adelantos en generación automática de código, hacen que la disciplina tenga que evolucionar rápidamente en las fases finales del ciclo de vida del Sw, el diseño y la codificación, por el contrario, el análisis (la fase más importante en proyectos de mediana y gran envergadura), permanece mucho más estable a la aparición de lenguajes o técnicas de programación. En la presente memoria, nos centramos en la resolución de uno de estos "pequeños" problemas, la migración de un Sw realizado bajo las pautas de un correcto diseño estructurado, que dio como fruto un programa basado en la 1 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia programación clásica o secuencial, a un entorno gráfico para el usuario como es el sistema operativo MS - Windows. Para ello no tendremos más que seguir el ciclo de vida y las correspondientes fases de ingeniería del Sw del proyecto original1 y utilizar todo, parte o nada del proyecto original2. Análisis Diseño Codificación Integración Figura 1 Ciclo de vida clásico 1. Análisis. Como la ingeniería del Sw pone de manifiesto, es la fase que menos cambios soporta por la incorporación de nuevas tecnologías al proceso de creación del Sw. Es además la fase de mayor importancia, ya que determina QUE es lo que se quiere obtener, QUE problema debe resolver el Sw. Observando el análisis efectuado para el proyecto original en [1], vemos que es un análisis correcto aún para la programación que vamos a llevar a cabo. Se emplean Diagramas de Flujos de Datos (DFD's), y se consigue captar y comprender la función del software, por lo que la fase es totalmente equivalente y podría entregarse la misma documentación. 2. Diseño. Recordemos, el diseño es el proceso por el cual se traducen las especificaciones de requerimientos en una representación del Software, es un puente entre el análisis y la solución de un problema, es decir la implementación. En esta fase comienzan a acentuarse las diferencias en el proceso de modelado entre el diseño estructurado y las técnicas actuales, como puede ser el UML. Los herramientas utilizadas por el diseño estructurado en la fase de diseño son distintas a las actuales, los diagramas de estructuras pierden gran parte de su utilidad, pues la fase que sigue al diseño (la codificación o implementación) es radicalmente distinta entre un lenguaje OO, visual y dirigido por eventos como PowerBuilder, Delphi, etc... y un lenguaje de carácter secuencial como C o Pascal entre otros. Así, 1 Véase el capítulo 10 Un caso práctico de diseño estructurado. de la referencia [1] La figura corresponde al ciclo de vida clásico, opción poco realista en el diseño del software, pero válida para nuestro propósito que no es otro que establecer la validez de las técnicas del diseño estructurado con la programación actual. 2 2 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia el sistema no puede "fraccionarse" de la misma forma, pues la comunicación entre módulos no será siempre entre variables, sino por paso de mensajes, acceso a objetos, métodos, propiedades, disparo de eventos etc. Etapas o módulos de importancia en la rama aferente del DE original, pierden por competo su sentido, un claro ejemplo son los módulos de edición o validación. Recordemos, según las guías de diseño estructurado, se debía validar la sintaxis (formato) antes que la semántica (significado), validar lo sencillo antes que lo cruzado y validar lo interno antes que lo externo. El razonamiento sigue siendo válido, pero al utilizar un lenguaje visual, lo sencillo pasa a ser sencillísimo, casi automático, tal y como se verá en el siguiente apartado, el de la implementación. A pesar de que parte del diseño recogido en [1] resulta innecesario, también existe una parte que resulta de utilidad. El diseño original viene documentado por un diagrama de estructuras (DE), la especificación interface-función y la especificación por pseudocódigo de algunos módulos (los de mayor "complejidad") cosas que siguen siendo muy útiles, pues además de ofrecer el acercamiento a una posible solución (la de programación secuencial), clarifican el sistema como un todo, y permite conocer mejor el problema al que nos enfrentamos y elaborar soluciones más acorde a nuestro objetivo, destacando sobretodo la especificación por pseudocódigo, que obviando detalles del lenguaje de programación, nos ahorrará tremendo trabajo de implementación, pues aunque no se traduzcan en funciones, pueden formar parte de los métodos de algún objeto. 3. Implementación. Como era de suponer, ésta es la fase que cambia radicalmente del acercamiento original a nuestra versión visual, como el lenguaje elegido en [1] para la implementación es C, no sirve NADA del código original (no más de lo que sirve el pseudocódigo o incluso menos, pues tiene en cuenta particularidades del lenguaje). En esta fase entra como principal protagonista el nuevo lenguaje elegido, el PowerBuilder, y se ponen de manifiesto las tremendas diferencias entre los nuevos lenguajes visuales y los lenguajes como C, que fue el elegido en [1] para implementar la primera versión de Posicionamiento 2D. Veamos un simple ejemplo, la interfaz gráfica: 3 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia Figura 2 Pantalla principal. Como puede observarse, la nueva versión del programa, mantiene una interfaz con el usuario radicalmente distinta, gráfica, y basada en el empleo del ratón, menús, y todas las particularidades de los nuevos sistemas. Inevitablemente, los cambios en la interfaz con el usuario provocan cambios drásticos en la manera de obtener los datos, por lo que la validación de esos datos de entrada proporcionados por el usuario es distinta. En la primera versión, el usuario debía introducir una cadena, con un formato determinado, indicando el número de pasos y la dirección, algo así como: Introduzca pasos y dirección: 15N En un primer paso, el sistema leía la cadena, validaba el formato: dos números, y un carácter del conjunto {N, S,E,O, ..} y comprobaba que los dos números fueran menores que 19, detengámonos ahí. ¿Es necesario este tipo de validaciones en esta aplicación?. La respuesta es sencilla, sí, pero no las lleva a cabo el programador, o las hace de manera asistida. Expliquémoslo sobre la imagen. 4 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia "Spin-Buttom" Campo de edición controlado por máscara numérica. Lista desplegable para seleccionar la dirección Figura 3 Toma de datos Como se observa, nos servimos de un campo para que el usuario introduzca el número de pasos con dos "spin-buttoms" que permiten incrementar o decrementar el número de pasos sin hacer uso del teclado (sólo del ratón), además si el usuario prefiere hacer uso del teclado, el campo tiene asignada una máscara que sólo permite la introducción de caracteres numéricos. En cuanto a la dirección a elegir, el método se simplifica más aún utilizando una lista desplegable sin posibilidad de edición, por lo que nos ahorramos la comprobación del campo. Por otro lado, la complejidad en el tratamiento de ficheros también se simplifica al uso de seis primitivas ofrecidas por PowerBuilder3, además se ofrecen los menús de apertura y salvado de ficheros estándar de Windows con una implementación sencilla. En cuanto al funcionamiento o comportamiento, ofrece una solución válida al problema original pero con un comportamiento distinto, basado en los eventos. Así, el mapa no se actualiza a través de la orden explícita de usuario como en la primera versión (la opción del menú "imprimir mapa"), sino que a medida que se introducen los movimientos se ven reflejados en el mapa. El mapa, no consiste en una pantalla 3 FileOpen(...), FileClose(..), FileDelete(...), FileExist(...), FileRead(...), FileWrite(..) 5 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia como en la primera versión, sino que ha mutado a un componente visual totalmente independiente, que puede compilarse en una dll y ser utilizado por otras aplicaciones a través de la interfaz de la que le hemos dotado. Conclusiones. Las conclusiones a las que llegamos son sencillas, a medida que avanzamos del análisis hacia la implementación, el grado de reusabilidad de la primera versión disminuye de forma no lineal. Este efecto es el que trata de explicar la gráfica siguiente. Análisis Diseño Implementación Figura 4 Grado de similitud en relación a las fases A pesar de las dificultades que hemos expuesto a lo largo de la presente memoria, cabe significar que el seguir una metodología en la creación de software, garantiza unos factores de calidad elevados, entre los que está como hemos visto la reusabilidad. 3 Referencias. [1] Molina A., Letelier P., Sánchez P., Sánchez J., Metodología y Tecnología de la programación. Servicio de publicaciones de la U.P.V - 97.498, 1997. 6 Laboratorio de Sistemas de Información Facultad de Informática Universidad Politécnica de Valencia
