Programación OO vs Programación clásica:

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: cripedpe@inf.upv.es, dapasser@inf.upv.es
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