Programación Visual & Arquitectura en Tres Capas

1. Programación Visual & Arquitectura en Tres Capas Tecnología de la Programación Javier Nieves Acedo

2. Una imagen vale más que mil palabras

3. La superación de una persona llega a límites inimginables. Gente que no puede andar consigue desplazarse de formas alternativas. Gente que no puede oír consigue comunicarse de formas alternativas.

4. La superación humana llega a límites inimaginables

5. De lo más antiguo pasamos a…

6. … a algo más moderno y amigable

7. Pero conozcamos como empezó todo…

8. Un poco de historia • GUI – GraficalUser Interface • Datan de los años 70 • Xerox PARC pioneros • Popularizado por Apple Computer • Lisa – Macintosh (1984) • Después llegó Microsoft

9. Y ¿cómo funciona la programación visual?

10. Conceptos y Razonamiento de GUI (1) • Actualmente se utiliza la “metáfora del escritorio” • Los programas en Windows no acceden directamente a los dispositivos. • Para eso están los Drivers • Cada aplicación que se ejecuta es una tarea • Tarea en proceso vs Tarea ejecutándose vs Tarea Activa

11. Conceptos y Razonamiento de GUI (y 2) • Multitarea gracias a administración de memoria • Memoria Real – Memoria Virtual • Además se puede compartir código • DLLs – Librería de Enlace Dinámico • Se proporciona el sistema para insertar este código y comenzar a utilizarlo.

12. Pero los afectados lo visualizan de formas diferentes

13. Perspectiva de Programador (1) • Cuando se programan GUIs se puede hacer con LOO. • Ventanas: • Usuario • Ve las ventanas • Interacciona con las ventanas • Programador • Entradas y comunicaciones en forma de “mensajes”

14. Perspectiva de Programador (2) Barra de Título Menús Desplazamiento Barra de Estado

15. Perspectiva de Programador (3) • Programas en Consola • Ejecución secuencial • Programa controla al usuario • Programas de Ventanas • Ejecución dirigida por eventos • El usuario controla el programa • Realiza la secuencia de pasos según le parece

16. Perspectiva de Programador (4) • Programación Orientada por Eventos • Basada en la generación y procesamiento de mensajes. • Mensaje: • “Información de que ha ocurrido un evento” • Debido a que el usuario controla el flujo de ejecución debemos tener más cuidado en nuestro programas

17. Perspectiva de Programador (y 5) • El núcleo de la programación en Windows son las API (ApplicationProgram Interface) • Tiene diversas funciones: • Ejemplo: CreateWindow() • Declaradas en Windows.h • Utilización similar a string.h (strcpy()) • .EXE actuales se basan en enlaces dinámicos

18. … y se basa en una arquitecturaya desarrollada

19. Arquitectura Gestionada por Mensajes (1) • Cuando se modifica el tamaño de una ventana: • Se reformatea el texto para acoplarlo al tamaño • Parece que el Sistema Operativo se encarga de ello • ¿Cómo sabemos que ha pasado algo en nuestra ventana? • SO manda un mensaje a la ventana

20. Arquitectura Gestionada por Mensajes (2) • La comunicación es gracias al sistema de mensajes • Para una aplicación el mensaje es una notificación de que un evento ha sucedido • Cuando la aplicación recibe un mensaje se le cede el procesador para que lo atienda

21. Arquitectura Gestionada por Mensajes(3)

22. Arquitectura Gestionada por Mensajes (4) • Todos los mensajes pasan a través de Windows • El Origen de los Mensajes: • Usuario: teclas, botones… • Windows: restaurar aplicación minimizada… • Aplicación: cambia el estado y se necesita el redibujado,… • Otras aplicaciones: intercambio dinámico de datos entre aplicaciones,…

23. Arquitectura Gestionada por Mensajes (5) • Una aplicación recibe todos los mensajes posibles • Windows envía todos porque no puede conocer cuáles le interesa a la aplicación • La aplicación ignorará todos los que no sean relevantes para ella

24. Arquitectura Gestionada por Mensajes (6) • La prioridad de los mensajes (1): • Normalmente Windows los sitúa en la cola de aplicación en el orden en el que son generados • Otros se mantienen en la cola mientras queden otros mensajes (timer, paint y quit) • Mensajes que se manda la aplicación o a otra se colocan al principio de la cola

25. Arquitectura Gestionada por Mensajes(y 7) • La prioridad de los mensajes (y 2): • ¿Si hay mensajes pendientes en varias aplicaciones? • Windows cede el procesador a la que tenga más prioridad • Comienza en 0 y puede cambiar de [-15, 15] • Si tienen la misma, se cede a la que tiene mayores mensajes

26. … y para programarlo …

27. Entornos de Desarrollo en C++ (1) • Diferentes bibliotecas de clases • Object Windows Library (OWL) • De Borland • Usada en Borland C++ 3.0 • La versión 5.0 encapsula muchos controles de Win32 • Compleja para iniciarse en su uso

28. Entornos de Desarrollo en C++ (2) • Microsoft FundationClass (MFC) • Apareció entre las versiones 1 y 2 de OWL • Existen versiones para diferentes compiladoresMuy relacionada con las API s de Windows • No tiene programación orientada a objetos

29. Entornos de Desarrollo en C++ (3) • Visual Component Library (VCL) • Desarrollo rápido basado en componentes • Componentes llevados a un formulario y modificados a través de propiedades y métodos • No se parece a nada anterior • Programada en Object Pascal pero se puede utilizar desde C++

30. Entornos de Desarrollo en C++ (4) • Microsoft Visual Studio .Net • Permite múltiples lenguajes (C++, C#) • Nueva biblioteca de componentes (WinForms) • Tiene la misma potencia que VLC y permite construir aplicaciones con la misma facilidad y atractivo.

31. Entornos de Desarrollo en C++ (y 4) • QT Creator • Aplicación multiplataforma • Dispone de sus propias librerías con portabilidad entre Sistemas Operativos • Desarrollada por Tolltrech • Adquirida por Nokia

32. … pero los componentes se basan en…

33. El Modelo Propiedad-Método-Evento (1) • La base de las aplicaciones con C++ Builder • Se utilizan componentes software • Tienen • Propiedades que definen su estado • Métodos que permiten manipularlo • Los cambios de estado disparan un evento al que la aplicación puede asignarle una acción

34. El Modelo Propiedad-Método-Evento(2) • VCL permite hacer visualmente lo que antes se realizaba mediante la codificación de clases. • Java estándar no dispone de está facilidad. Hay que ir a aplicaciones de terceros para que den está facilidad.

35. El Modelo Propiedad-Método-Evento (y 3) • Los programadores no tienen que crearse o manipular estos componentes mediante código fuente. • Todos los componentes están ya en la VCL

36. Componentes vs Clases

37. Componentes vs Clases (1) • Son parecidos pero hay diferencias (I1): • Todos los componentes descienden de la clase Tcomponent • Normalmente se utilizan como están, no son utilizados como una clase base. Si se hereda es porque se quiere añadir algo de código a funciones miembro que gestionan un evento

38. Componentes vs Clases (y 2) • Son parecidos pero hay diferencias (y 2): • Los objetos creados a partir de la VCL solo pueden crearse en memoria dinámica (new) • Se pueden crear controles nuevos y añadirlos a las paletas de los ya existentes

39. Analicemos un poco más a fondo los componentes

40. Componentes (1) • Componentes VCL son objetos que ejecutan una tarea específica de programación

41. Componentes (2) • Propiedades: • Controlan como opera el componente • Muchos tienen propiedades comunes • La ventana ObjectInspector muestra las propiedades del componente en orden alfabético.

42. Componentes (3) • Propiedades: • Pueden ser modificadas en tiempo de diseño y de ejecución • No todas la propiedades tienen efectos visibles asociados • En tiempo de ejecución se modifican los valores haciendo una asignación del nuevo valor

43. Componentes (4) • Propiedades: • Al cambiar una propiedad se llamarán a los métodos asociados o necesarios • Las propiedades pueden tener dos especificadores de acceso (read / writespecifier) • Los especificadores son llamados de forma automática • Algunas propiedades solo pueden ser leídas y otras solo escritas

44. Componentes (5) • Propiedades: • Una propiedad puede ser un objeto de otra clase VCL • Otras son grupos de propiedades (Font) en el ObjectInspector tiene un + • Otras pueden ser enumeraciones (lista de posibles opciones). En el ObjectInspector tienen un desplegable

45. Componentes (6) • Métodos: • Son funciones que pueden ser llamadas para que un componente ejecute ciertas acciones • Ejemplo: • Ventana->Show(); // Visualiza en pantalla • Ventana->Hide(); // Oculta en pantalla • Como forman parte de una clase pueden ser públicos, privados o protegidos

46. Componentes (8) • Eventos: • Cada componente VCL está diseñado para responder a ciertos eventos • Si se responde a un evento se dice que se dispone de un handle. • Las funciones a las que se llama son handlers

47. Componentes (8) • Eventos: • Los eventos de un componente se ven en el ObjectInspector • Si no se da respuesta el mensaje es ignorado o se ejecuta un handler por defecto de la VCL

48. Componentes (9) • Eventos: • Todos los eventos tienen preparada su función a ejecutar. • El programador tiene que rellenarla con el código necesario. • Los argumentos que se reciben dependen del evento y nos dan la información relevante de lo sucedido

49. Componentes (10) • Al arrastrar los elementos se genera el código de creación automáticamente • Pero si generamos componentes en tiempo de ejecución deben ser creados en memoria dinámica • No tienen constructores sobrecargados • No tienen funciones con parámetros por defecto • No soportan herencia múltiple

50. Componentes (11)