Modulo Original

MODULO DISEÑO Y REALIZACIÓN DE SERVICIOS DE PRESENTACIÓN EN ENTORNOS GRÁFICOS
MODULO
DISEÑO Y REALIZACION
DE SERVICIOS DE
PRESENTACION EN
ENTORNOS GRAFICOS
INDICE
UNIDAD 1:
Programación orientada a objetos en C++ y Windows
UNIDAD 2:
Programación Orientada a objetos en Visual Basic
UNIDAD 3:
Técnicas Profesionales avanzadas
UNIDAD 4
Introducción a los sistemas multimedia
UNIDAD 5
El sonido
UNIDAD 6
Las imágenes
UNIDAD 7
Hipertexto
UNIDAD 8
Sistemas Autor
UNIDAD 9
Interfaces gráficas estándar
UNIDAD 10
Diseño de pantallas para servicios multimedia
INTRODUCCIÓN
Cuando se escribe un programa en un lenguaje orientado a objetos, definimos una

plantilla o clase que describe las características y el comportamiento de un conjunto de
objetos similares. La clase automóvil describe las características comunes de todos los
automóviles: sus atributos y su comportamiento. Los atributos o propiedades se refieren
a la marca o fabricante, el color, las dimensiones, si tienen dos, tres, cuatro o más
puertas, la potencia, si utiliza como combustible la gasolina o gasoil, etc. El
comportamiento se refiere a la posibilidad de desplazarse por una carretera, frenar,
acelerar, cambiar de marcha, girar, etc.
Luego, tenemos automóviles concretos, por ejemplo el automóvil propio de una

determinada marca, color, potencia, etc., el automóvil del vecino de otra marca, de otro
color, etc., el automóvil de un amigo, etc.
Una clase es por tanto una plantilla implementada en software que describe un conjunto
de objetos con atributos y comportamiento similares.
Una instancia u objeto de una clase es una representación concreta y específica de una
clase y que reside en la memoria del ordenador.
La programación en un entorno gráfico está basada en la utilización de una herramienta

de diseño gráfico en la cual se diseña la ventana, el formulario, el entorno gráfico en el
que se va a diseñar el aspecto gráfico del programa que va a utilizar el usuario.
Este entorno gráfico cambiará de un lenguaje a otro, pero en definitivas cuentas se

compone de una serie de elementos gráficos que poseen unas características tales que
nos permiten crear un programa en el cual podamos solicitar y mostrar datos al usuario
de una manera estética más agradable e intuitiva que lo que permite el modo consola.
OBJETIVOS
Diseñar y realizar servicios de presentación que faciliten la explotación de aplicaciones
Definir los elementos de la programación en un entorno gráfico
Elaborar interfaces de usuario a partir del diseño de servicios de presentación y de

las especificaciones y requerimientos funcionales de la aplicación.
• Evaluar que los servicios de presentación implementados cumplen con las

necesidades definidas por el usuario, utilizando óptimamente los recursos del
sistema.
• Elaborar la documentación característica de los servicios de presentación

utilizados en la organización.
Diseñar servicios de presentación amigables en formato que faciliten la interacción

hombre-máquina.
􀀹 Realizar servicios de presentación que cumplan las directrices del diseño.
􀀹 Realizar pruebas de usuario que verifiquen la presentación, secuencias de

diálogo y enlace con aplicaciones de la <<interfaz>> desarrollada.
􀀹 Elaborar y mantener documentación sobre el diseño, desarrollo, prueba y

utilización de los servicios de presentación que faciliten el uso y el
mantenimiento del mismo.
CAPACIDADES TERMINALES Y / O COMPETENCIA
Conocer las funciones de una interfaz gráfica de usuario (IGU).
1.2. Conocer distintas interfaces gráficas existentes en el mercado.
1.3. Realizar el diseño de esquemas para plantillas y/o presentaciones de carácter

general.
1.4. Crear un servicio de presentación dependiendo de las características de la IGU

escogida.
1.5. Diseñar plantillas de carácter genérico con el fin de uniformar los servicios de
presentación y el estilo interfaz de una organización.
1.6. Analizar las necesidades y peticiones de usuarios establecidos.
1.7. Analizar el funcionamiento de los interfaces de usuario existentes en un

sistema.
1.8. Evaluar los problemas de un entorno gráfico establecido.
1.9. Establecer la interoperatividad entre interfaces gráficas y los S.G.B.D. más

usuales.
1.10. Analizar la información proveniente del diseño de los servicios de

presentación de una aplicación simulada o real.
1.11. Evaluar las ventajas e inconvenientes de la implementación de los servicios de

presentación de una aplicación en diferentes entornos gráficos.
1.12. Implementar el diseño de los servicios de presentación de una aplicación en

diferentes entornos gráficos.
1.13. Establecer los criterios de validación de los servicios de presentación.
1.14. Describir la forma de crear los objetos de acceso a datos.
1.15. Describir los métodos de acceso a datos.
1.16. Establecer relaciones entre las distintas tablas de una Base de Datos.
1.17. Realizar aplicaciones cliente-servidor.
ESTRUCTURA DE CONTENIDOS
Para alcanzar los objetivos descritos anteriormente, realizaremos la división del curso en
los temas más abajo expuestos, pudiendo modificarse la estructura en función de las
necesidades que aparezcan durante el curso.
Según esto podríamos estructurar el curso en 11 grandes temas (que se explicara en el

siguiente bloque), a través de los cuales se intentara, no solo alcanzar los objetivos
anteriores, sino acomodar la asignatura a las exigencias laborales del momento,
intentando facilitar una pronta incorporación a la vida laboral.
Para llevar a la práctica todos los objetivos se han dispuesto desde el Departamento de
Informática del Centro Santa María de los Apóstoles, que el lenguaje de programación
utilizado sea Visual Basic. Los motivos son sencillos y muy claros: A pesar de que no
es un lenguaje puramente orientado a objetos, conserva todas las propiedades de este
tipo de lenguajes pero permitiendo la creación de aplicaciones en un tiempo mínimo,
debido a la facilidad de aprendizaje y a la facilidad de manejo del compilador. Por si
fuera poco es uno de los lenguajes mas utilidades en todo el mundo (hasta el 2001 según
revistas del mundillo el más utilizado) al que solamente le ha empezado ha hacer
sombra lenguajes para el desarrollo de aplicaciones en Internet como JAVA. Teniendo
en cuenta que solo tenemos dos trimestres parece adecuado pensar que para asimilar los
conceptos de forma rápida, desde el departamento creemos que es el lenguaje más
acertado.
En el intento de mejorar el modulo, así como de acercarnos a los nuevos lenguajes de

programación actuales, para este nuevo curso que comienza se añade una nueva
herramienta muy potente para el desarrollo, VISUAL .NET. Es el último producto para
el desarrollo en entornos de Microsoft, y de ahí que se pretenda realizar una
aproximación.
Por último y teniendo encuentra el auge de la programación en Internet se ha incluido
un bloque dedicado a tal efecto, siempre supeditado al criterio del profesor, tiempo y a
la correcta finalización del resto de los módulos. En este punto se hace más bien un
análisis de algunas aplicaciones utilizadas para el desarrollo de páginas Web.
METODOLOGÍA y RECURSOS
Par obtener los objetivos expuestos y realizar los temas, se utiliza un entorno de
desarrollo flexible, fácil y a la vez potente como es Visual Basic, y un entorno
puramente orientado a objetos y de reciente aparición Visual Basic .NET, además como
herramientas complementarias para el desarrollo WEB se utilizaran los programas de
Macromedia Dreamweaber y Flash.
Se realizará una exposición teórica de cada uno de los temas, compaginando dicha
explicación con ejercicios teóricos o prácticos, estos últimos se harán sobre el ordenador
comprobándose así su correcto funcionamiento.
Como complemento a las exposiciones teóricas dispondrán de apuntes, fotocopias y
libros que favorecerán la comprensión de la metería del modulo, así como el acceso a
Internet para la obtención de manuales y puestas en común con otros desarrolladores.
CRITERIO DE EVALUACION
Todos los bloques se evalúan de la misma forma, Pruebas teóricas individuales:

consisten en exámenes relativos a la materia más recientemente impartida.
Principalmente, evalúan los conocimientos teóricos aunque también se presenta en ellos
la resolución de ciertos problemas.
También serán tenidos en cuenta trabajos sobre la materia, la participación activa en las
clases, la actitud y comportamiento, para que la nota final refleje no sólo conocimientos
sino también la capacitación global para integrarse en un puesto de trabajo con la mejor
disposición posible.
Las pruebas en grupo se realizaran una vez finalizada la explicación del tema, según la
complejidad podrá ser una o varias, seguidamente se realizara la prueba individual.
No se contempla la posibilidad de realizar examen final al finalizar la evaluación, ya
que esta es continua.
Las pruebas en grupo tendrán un porcentaje en la nota final de un 40%, siendo el resto
de la nota el porcentaje correspondiente a las pruebas individuales (prácticas y teóricas.)
UNIDAD N° 1
Objetivo de la Unidad: Repasar y profundizar en los contenidos básicos de la

programación orientadas a objetos.
LENGUAJE DE PROGRAMACIÓN
Introducción
el término de Programación Orientada a Objetos indica más una forma de diseño y una
metodología de desarrollo de software que un lenguaje de programación, ya que en
realidad se puede aplicar el Diseño Orientado a Objetos (En inglés abreviado OOD,
Object Oriented Design), a cualquier tipo de lenguaje de programación.
El desarrollo de la OOP empieza a destacar durante la década de los 80 tomando en

cuenta la programación estructurada, a la que engloba y dotando al programador de
nuevos elementos para el análisis y desarrollo de software.
El propósito de este trabajo es explicar el diseño orientado a objeto y no una explicación

de su programación, puesto que no nos alcanzaría todo el currículo para hacerlo.
Básicamente la OOP permite a los programadores escribir software, de forma que esté
organizado en la misma manera que el problema que trata de modernizar. Los lenguajes
de programación convencionales son poco más que una lista de acciones a realizar sobre
un conjunto de datos en una determinada secuencia. Si en algún punto del programa
modificamos la estructura de los datos o la acción realizada sobre ellos, el programa
cambia.
La OOP aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre

el que pivotan las operaciones. De esta forma, cualquier modificación de la estructura
de datos tiene efecto inmediato sobre las acciones a realizar sobre ella, siendo esta una
de las diferencias radicales respecto a la programación estructurada.
Para quienes no están familiarizados con la programación estructurada se dice que una
de las bases de esta escuela de programación parte del diseño arriba – abajo. En esta
forma de diseño se descomponen los requerimientos del programa paso a paso, hasta
llegar a un nivel que permite expresarlos mediante procedimientos y funciones. La OOP
estructura los datos en objetos que pueden almacenar, manipular y combinar
información.
En resumen, la programación estructurada presta atención al conjunto de acciones que

manipulan el flujo de datos (desde la situación inicial a la final), mientras que la
programación orientada a objetos presta atención a la interrelación que existe entre los
datos y las acciones a realizar con ellos.
Muchos habrán oído comentarios sobre la incidencia de la OOP sobre la programación

convencional. Se ha llegado a decir que el cambio introducido por la OOP es similar al
producido por la aparición del ensamblador sobre el código de máquina.
La OOP proporciona las siguientes ventajas sobre otros lenguajes de programación
CONCEPTOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A OBJETOS
Razones fundamentales que están influyendo en la importancia de la POO
Algunas de las causas que están influyendo considerablemente en el notable desarrollo

de las técnicas orientadas a objetos son:
 La OO (orientación a objetos) es especialmente adecuada para realizar

determinadas aplicaciones, sobre todo realización de prototipos y simulación de
programas
 Los mecanismos de encapsulación de POO soportan un alto grado de

reutilización de código, que se incrementa por sus mecanismos de herencia.
 En el entorno de la base de datos, la OO se adjunta bien a los modelos

semánticos de datos para solucionar las limitaciones de los modelos
tradicionales.
 Aumento espectacular de los lenguajes de programación orientados a objetos.
 Interfaces de usuarios gráficos (por iconos) y visuales. Las interfaces de usuarios

de una aplicación manipulan la entrada y salida del usuario. Por consiguiente, su
función principal es la comunicación con el usuario final. prototipos
OBJETOS (1)
Los objetos son entidades que se pueden distinguir de manera clara y definida, ejemplos
de un objeto pueden ser una persona, un libro, un botón de orden.
Características de los Objetos

Identidad del Objeto
 La identidad expresa que aunque dos objetos sean exactamente iguales en sus
atributos, son distintos entre sí. De esta forma incluso una serie de Objetos
coches, recién fabricados son distintos los unos de los otros.
 La afirmación anterior, aunque parece obvia, tiene importancia cuando
descendemos al nivel de programación. En este ámbito cada uno de los objetos
tiene un controlador pro el cual se identifica. Este puede ser una variable, una
estructura de datos, una cadena de caracteres, etc. El controlador será distinto
para cada uno de los objeto, aunque las referencias a éstos sean uniformes e
independientes del contenido, permitiendo crear agrupaciones de objetos con el
mismo tratamiento.
 Clasificación
 Con la clasificación comienza la verdadera programación orientada a objetos.
Ellos nos obliga a una abstracción del concepto de objeto denominada clase.
 Las clases permiten la agrupación de objetos que comparten las mismas
propiedades y comportamiento. Si bien clase y objeto suelen usarse como
sinónimos, no lo son.
 El esfuerzo del programador ante una aplicación orientada a objetos se centra en

la identificación de las clases, sus atributos y operaciones asociadas
 Las propiedades de cada clase deben cumplir una serie de premisas
 Las propiedades deber ser significativas dentro del entorno de la aplicación es
decir, deben servir para identificar claramente y de una manera única (y
univoca) a cada uno de los objetos
 El número de propiedades de un objeto debe ser el mínimo para realizar todas
las operaciones que requiera la aplicación.
 Definamos una clase rectángulo. Esta clase puede tener como atributos un punto
(x,y), la anchura (a) y la longitud (l). Las operaciones a realizar son: mover,
agrandar, reducir, et. ¿Es posible realizarlas con las propiedades de la clase?
 Un análisis posterior nos indica que es posible la realización de estas
operaciones con los atributos definidos. Pero si incluimos la operación girar ,
vemos que con las propiedades definidas para la clase esta operación no se
puede realizar. Para incluir esta nueva operación debemos redefinir las
propiedades del objeto, en este caso las coordenadas de los vértices.
Estructura interna de un objeto:
La estructura interna de un objeto está compuesta por tres elementos fundamentales

como son:
o Propiedades: Son las características observables de un objeto. Las

propiedades se reconocen porque describen un aspecto del objeto que
podemos medir con una escala establecida previamente. A cada
propiedad se le debe asignar un valor el cual permite identificar de
manera única al objeto.
o Métodos: Se define como un conjunto de acciones que un objeto puede

realizar para conseguir un propósito. Los métodos representan la parte
viva e interesante de un objeto y se emplean habitualmente para
modificar las propiedades del objeto. Al modificar cualquiera de las
propiedades del objeto se altera su apariencia y se genera un cambio que

el usuario de la aplicación puede percibir.
o Eventos: Todos los objetos se relacionan con el mundo que los rodea,
esto significa que ningún objeto está aislado y siempre recibe el influjo
de otros objetos. Los eventos son los estímulos que un objeto ejerce
sobre otro
Estado de un objeto:
El estado de un objeto es la apariencia que el objeto presenta al usuario, y depende del

valor que tenga sus propiedades. Un cambio de estado se logra alterando al menos una
de las propiedades del objeto.
Clases: (2)
Los objetos están organizados en familias claramente delimitadas. Una familia se

reconoce porque reúne un grupo de objetos que heredan elementos entre sí. El modelo
de programación visual, al igual que la naturaleza, organiza los objetos en clases
(familias), así una clase es el conjunto de objetos que pertenecen a una misma familia.
Por ejemplo Madonna, Michael Jackson, Prince y Dire Straits son objetos de una clase
cantantes de rock, sin embargo personas específicas con nombres específicos son
miembros de esa clase si poseen ciertas características comunes. El modelo de
programación visual permite así organizar las familias de objetos en un orden
jerárquico.
Herencia:
Un objeto es heredero de otro cuando posee todas sus propiedades y todos sus métodos
y reconoce todos sus eventos, aunque pueda disfrutar de propiedades, métodos y
eventos adicionales. Se define la herencia como la característica que tienen los objetos
de derivarse unos de otros. Por otra parte la herencia supone una clase base y una
jerarquía de clases que contienen las clases derivadas de la clase base, así las clases
derivadas pueden heredar las propiedades y métodos de una clase base, añadiendo sus
propios métodos y propiedades, incluso cambiar aquellos elementos de la clase base que
necesiten sean diferentes.
La herencia es la última de las propiedades relativas a la OOP, Consiste en la

propagación de los atributos y las operaciones a través de distintas sub-clases definidas
a partir de una clase común.
Introduce, por tanto, una posibilidad de refinamiento sucesivo del concepto de clase.
Nos permite definir una clase principal y, a través de sucesivas aproximaciones,
cualquier característica de los objetos. A partir de ahora definiremos como sub-clases
todas aquellas clases obtenidas mediante refinamiento de una (o varias) clases
principales.
La herencia nos permite crear estructuras jerárquicas de clases donde es posible la

creación de sub-clases que incluyan nuevas propiedades y atributos. Estas sub-clases
admiten la definición de nuevos atributos, así como crear, modificar o inhabilitar
propiedades.
Para pensarlo de manera más fácil podemos abstraernos al siguiente ejemplo.
Pensemos en los distintos sub-modelo s asociados a un modelo básico de automóvil. A

partir de este modelo básico, los fabricantes introducen distintas características (aire
acondicionado, ABS, distintas tapicerías, acabados, etc.) que crean sub – clases. Todas
estas sub-clases tienen en común la estructura básica (chasis , dirección , etc.) u varían
sólo en algunos de sus componentes.
Asociemos a este tipo básico una clase cuyos atributos representen las piezas que
componen el coche. Las sub-clases aportarán sus propios atributos (en el caso de
vehículos con aire acondicionado, todos aquellas piezas que lo componen), permitiendo
la definición de todos los posibles modelos.
Además, es posible que una sub-clase herede atributos y propiedades de más de una
clase. Este proceso se denomina herencia múltiple y lo veremos con más detalle en
capítulos posteriores.
La herencia es, sin duda alguna, una de las propiedades más importantes de la OOP, ya
que permite, a través de la definición de una clase básica, ir añadiendo propiedades a
medida que sean necesarias y, además, en el sub-conjunto de objetos que sea preciso.
La herencia permite que los objetos puedan compartir datos y comportamientos a través
de las diferentes sub-clases, sin incurrir en redundancia. Más importante que el ahorro
de código, es la claridad que aporta al identificar que las distintas operaciones sobre los
objetos es en realidad una misma cosa.
Tipos de Herencia:
Existen dos tipos de herencia
o Herencia Simple: En esta jerarquía cada clase tiene como máximo una
sola superclase. La herencia simple permite que una clase herede las
propiedades y métodos de su superclase en una cadena jerárquica.
o Herencia múltiple: Una malla o retícula consta de clases, cada una de las
cuales pueden tener dos o más superclases inmediatas. Una herencia
múltiple es aquella en la que cada clase puede heredar las propiedades y
métodos de cualquier número de clases.
Encapsulamiento:
Un objeto está separado del medio que lo rodea por algún tipo de envoltura. Esta
separación es la que determina la unidad del objeto, es decir, lo convierte en algo
independiente. La envoltura oculta los detalles relacionados con la construcción interior
del objeto, esto significa que sólo conocemos del objeto aquello que es revelado por sus
métodos. Se llama encapsulamiento a la propiedad que tienen los objetos de ocultar
detalles internos, así se permite asegurar que el contenido de la información de un
objeto este oculta al mundo exterior (Por ejemplo un objeto A no conoce lo que hace un
objeto B y viceversa). Por otra parte el programador que construye un objeto tiene
acceso a todas sus partes: propiedades, métodos y definición de eventos. El

programador que utiliza un objeto solamente tiene acceso a sus propiedades y métodos
(si estos son públicos) y a la programación de los eventos que han sido definidos para el
objeto.
Algunos métodos y propiedades en un objeto son privados, es decir, útiles únicamente

dentro del objeto y desconocidos por quien utiliza el objeto, los restantes métodos y
propiedades son públicos, t los programadores los emplean para cambiar el estado del
objeto.
Comunicación entre objetos (mensajes)
El mensaje es esencialmente una orden que se envía a un objeto para indicarle que
realice alguna acción. También se define mensaje como la información completa que un
objeto emisor transmite hacia un objeto receptor.
Un mensaje contiene tres elementos: el objeto receptor, el tipo de evento y los datos
necesarios para el receptor.
Mensaje
Cuando se produce un evento, el objeto receptor sabe cuál es el objeto emisor, qué
evento se produjo y el valor de los datos asociados con dicho evento.
Polimorfismo: (3)
El polimorfismo se presenta cuando se ha creado objetos que pertenecen a clases que

han sido derivadas de otras clases. En otras palabras, el polimorfismo aparece en las
clases derivadas.
También se dice que el polimorfismo es la propiedad que indica literalmente, la

posibilidad de que una entidad tome muchas formas, en términos prácticos el
polimorfismo permite referirse a objetos de clases distintas mediante el mismo elemento
de programa y realizar la misma operación de diferentes formas, según sea el objeto que
se referencia en ese momento. Por ejemplo cuando se describe la clase mamíferos se
puede observar que la operación comer es una operación fundamental en la vida de los
mamíferos, de modo que cada tipo de mamíferos debe poder realizar la operación o
función comer. Por otra parte, una vaca o una cabra que pasta en el campo, un niño que
se come un bombón o caramelo y un león que devora a otro animal, son diferentes
formas que utilizan los distintos mamíferos para realizar la misma función (comer).
El polimorfismo es una nueva característica aportada por la OOP. Esta propiedad indica
la posibilidad de definir varias operaciones con el mismo nombre, diferenciándolas
únicamente en los parámetros de entrada. Dependiendo del objeto que se introduzca
como parámetro de entrada, se elegirá automáticamente cual de las operaciones se va a
realizar.
Ya está habituado al operador <<suma>> que está presente en todos los lenguajes de
programación. Sin embargo, los operadores <<suma de fracciones>> y <<suma de
números complejos>> no existen en casi ningún lenguaje de programación.
Los lenguajes OOP permiten definir un operador <<suma>> tal que reconozca que tipo
de objeto se le está aplicando, a través de operaciones de objetos. Previamente deberá
definir la fracción y el número complejo como una clase y la operación suma como una
operación de una clase.
Definiendo adecuadamente las operaciones suma de fracciones y suma de números

imaginarios, el operador suma devolverá, en el caso que los operando sean fracciones,
una fracción y, en el caso de los números imaginarios, otros número imaginario.
Es posible extender el concepto e incluso definir operaciones como suma de bases de

datos
El operador suma de base de datos. Aunque a primera vista la expresión C= A+B,

siendo A y B bases de datos, nos pudiera parecer una extraordinaria simplificación, nos
conduce a la pregunta: ¿Qué es la suma de una base d datos?
Consideremos varias posibilidades:
Introducción de registros: Lo que exige que A y B tengan la misma estructura.
Unión de campos: Aquellos campos que aparezcan en B pero no en A serán añadidos a

C
¿Alguna de estas dos opciones es verdaderamente una suma? Es decir ¿Cumple las
propiedades conmutativa, asociativa, de elemento neutro, etc.? ¿Qué ocurre si sumo dos
bases de datos con estructuras distintas?
Como puede observar, la definición de un operador sobre un tipo complejo de datos,

intentando utilizar identificadores de operadores de datos simples, puede tener
resultados impredecibles.
Una de las ventajas más importantes, sin entrar en la redefinición de operadores es

permitir la realización de las clases que definen un programa de forma totalmente
independiente al programa donde se utilizan. Gracias a la encapsulación y el
polimorfismo, aunque se utilicen los mismos nombres con las operaciones en dos clases
distintas, el programa reconoce a que clase se aplica durante la ejecución.
Como se podrá observar el polimorfismo y la encapsulación de datos están íntimamente

ligados y nos permiten un mayor grado de mantenibilidad y reusabilidad que los
lenguajes tradicionales Esta es precisamente una de las causas de la revolución que ha
supuesto la introducción de los lenguajes orientados a objetos dentro de la
programación.
Objetos compuestos: (4)
Una de las características que hacen a los objetos ser muy potentes es que pueden
contener otros objetos. Los objetos que contienen otros objetos se denominan objetos
compuestos. Esta característica ofrece dos ventajas importantes:
o Los objetos contenidos pueden cambiar en tamaño y composición, sin

afectar al objeto compuesto que los contiene, esto hace que el
mantenimiento de sistemas complejos de objetos anidados sea más
sencillo.
o Los objetos contenidos están libres para participar en cualquier número

de objetos compuestos, en lugar de estar bloqueados en un único objeto
compuesto.
12. Reutilización con orientación a objetos:
Reutilización o reutilizabilidad es la propiedad por la que software desarrollado puede

ser utilizado cuantas veces sea necesario en más de un programa. Así por ejemplo, si se
necesita una función que calcule el cuadrado o el cubo de un número, se puede crear
una función que realice la tarea que el programa necesite. Las ventajas de la
reutilización son evidentes, el ahorro de tiempo es sin duda una de las ventajas más
considerables y otra es la facilidad para intercambiar software desarrollado por
diferentes programadores.
13. Objetos y reutilización:
La programación orientada a objeto proporciona el marco idóneo para la reutilización de

las clases. Los conceptos de encapsulamiento y herencia son las bases que facilitan la
reutilización. Un programador puede utilizar una clase existente y sin modificarla,
añadirle nuevas características y datos. Esta operación se consigue derivando una clase
a partir de la clase base existente, la nueva clase hereda las propiedades de la antigua,
pero se pueden añadir nuevas propiedades. Por ejemplo, suponga que se escribe una
clase Menú que crea una sistema menú (barras de desplazamiento, cuadros de diálogos,
botones, etc.), con el tiempo, aunque la clase funciona bien, se observa que sería
interesante que las leyendas de las opciones de los menús parpadearán o cambiarán el
color. Para realizar esta tarea se diseña una clase derivada de menú que añada las nuevas
propiedades de parpadeo o cambio de color
La facilidad para reutilizar clases y en consecuencia objetos es una de las propiedades

fundamentales que justifican el uso de la programación orientada a objeto. Por esta
razón los sistemas y en particular los lenguajes orientados a objetos suelen venir
provistos de un conjunto (biblioteca) de clases predefinidas que permiten ahorrar tiempo

y esfuerzo en el desarrollo de cualquier aplicación.
14. Constructor:
Los constructores son métodos o funciones que existen dentro de todos los objetos, y
que se activan solamente en el momento de la creación del objeto. Los constructores
sirven para definir los valores iníciales de las propiedades del objeto. También se dice
que un constructor es una operación que crea un objeto y/o inicializa su estado.
15. Destructor:
El destructor es un método que se activa cuando el objeto desaparece. El destructor es

único y sirve para que un objeto ejecute una acción (o grupo de acciones) antes de
terminar su ciclo vital. Normalmente loa objetos dejan de existir cuando salen de su
ámbito (entorno) en donde fueron creados. Los destructores son importantes porque se
activas automáticamente, y eximen al programador de la tarea de liberar los recursos
tomados por el objeto, ya que normalmente esta es la tarea ejecutada por el destructor
Uniformidad. Ya que la representación de los objetos lleva implica tanto el análisis

como el diseño y la codificación de los mismos.
Comprensión. Tanto los datos que componen los objetos, como los procedimientos que
los manipulan, están agrupados en clases, que se corresponden con las estructuras de
información que el programa trata.
Flexibilidad. Al tener relacionados los procedimientos que manipulan los datos con los
datos a tratar, cualquier cambio que se realice sobre ellos quedará reflejado
automáticamente en cualquier lugar donde estos datos aparezcan.
Estabilidad. Dado que permite un tratamiento diferenciado de aquellos objetos que

permanecen constantes en el tiempo sobre aquellos que cambian con frecuencia permite
aislar las partes del programa que permanecen inalterables en el tiempo.
Reusabilidad. La noción de objeto permite que programas que traten las mismas
estructuras de información reutilicen las definiciones de objetos empleadas en otros
programas e incluso los procedimientos que los manipulan. De esta forma, el desarrollo
de un programa puede llegar a ser una simple combinación de objetos ya definidos
donde estos están relacionados de una manera particular.
Uno de los puntos clave a remarcar en esta introducción es que la programación

orientada a objetos no sustituye a ninguna metodología ni lenguaje de programación
anterior. Todos los programas que se realizan según OOD se pueden realizar igualmente
mediante programación estructurada. Su uso en la actualidad se justifica porque el
desarrollo de todas las nuevas herramientas basadas en un interface de usuario gráfico
como Windows, OS/2, x-Windows, etc. Es mucho más sencillo
Cualidad que nos indica que partes del programa (en este caso objetos) pueden ser
reutilizados en la confección de otros programas. Ello implica que los objetos definidos
en un programa pueden ser extraídos del mismo e implantados en otro sin tener que
realizar modificaciones importantes en el código del objeto. El objeto final es que el
programador construya una librería de objetos que le permita realizar programas
basándose en la técnica de cortar y pegar. Esta extrae (corta) código de otras
aplicaciones ya realizadas y las implementa (pega) en la aplicación a realizar donde, tras
algunos retoques, la nueva aplicación estará lista para funcionar. Como podrá observar
el concepto de reusabilidad, permite reducir el tiempo de realización, ganando en
claridad, mantenibilidad y productividad.
La encapsulación de datos se muestra como una herramienta poderosa que nos permite
ganar en tiempo de desarrollo y claridad, con el único coste adicional de definir con
precisión las entradas y salida de nuestras operaciones.
Encapsulación y ocultación de datos
La capacidad de presentación de información dentro de un objeto se divide en dos partes

bien diferenciadas:
Interna: La información que necesita el objeto para operar y que es innecesaria para los
demás objetos de la aplicación. Estos atributos se denominada privados y tienen como
marco de aplicación únicamente a las operaciones asociadas al objeto.
Externa La que necesitan el resto de los objetos para interactuar con el objeto que
definimos. Estas propiedades se denominan públicas y corresponde a la información que
necesitan conocer los restantes objetos de la aplicación respecto del objeto definido para
poder operar.
Podemos imaginarla encapsulación como introducir el objeto dentro de una caja negra
donde existen dos ranuras denominadas entrada y salida. Si introducimos datos por la
entrada automáticamente obtendrá un resultado en la salida. No necesita conocer ningún
detalle del funcionamiento interno de la caja.
El término encapsulación indica l capacidad que tienen los objetos de construir una
cápsula a su alrededor, ocultando la información que contienen (aquélla que es
necesaria para su funcionamiento interno, pero innecesaria para los demás objetos) a las
otras clases que componen la aplicación.
Aunque a primera vista la encapsulación puede parecer superflua, tengamos en cuenta

que existen muchas variables utilizadas de forma temporal: contadores y variables que
contienen resultados intermedios, etc. D no ser por la encapsulación estas variables
ocuparían memoria y podrían interferir en el funcionamiento del resto de los objetos.
La encapsulación no es exclusiva de los lenguajes de programación orientados a

objetos. Aparece en los lenguajes basados en procedimientos (PASCAL, C, COBOL,
ETC) como una forma de proteger los datos que se manipulan dentro de las funciones.
Los lenguajes OOP incorporan la posibilidad de encapsular también las estructuras de

datos que sirven como base a las funciones. Aportan por tanto un nivel superior en
cuanto a protección de información.
La encapsulación nos permite el uso de librerías de objetos para el desarrollo de

nuestros programas. Recordemos que las librerías son definiciones de objetos de
propósito general que se incorporan a los programas. Al ser el objeto parcialmente
independiente en su funcionamiento del programa en donde está definido, ya que
contiene y define todo lo que necesita para poder funcionar, es fácil utilizarlo en los más
variados tipos de aplicaciones. Si aseguramos, depurando las propiedades y las
operaciones dentro de la clase que el objeto función bien dentro de una aplicación, con
una correcta encapsulación el objeto podrá funcionar en cualquier otra.
Otra de las ventajas de la encapsulación es que, al definir el objeto como una caja negra
con entradas y salida asociadas, en cualquier momento podemos cambiar el contenido
de las operaciones del objeto, de manera que no afecte al funcionamiento general del
programa.
La encapsulación está en el núcleo de dos grandes pilares de la construcción de

sistemas; mantenibilidad y reusabilidad.
Mantenibilidad
Cualidad que indica que un programa o sistema debe ser fácilmente modificable. Es
decir que los cambios en las condiciones externas (como la definición de una nueva
variable) implicarán modificaciones pequeñas en el programa / sistema. El concepto de
mantenibilidad implica que un programa, al igual que un ser vivo debe ser capaz de
adaptarse a un medio ambiente siempre cambiante.
Conclusión.
Identidad, clasificación, polimorfismo y herencia caracterizan a los lenguajes orientados

a objetos. Cada uno de estos conceptos puede utilizarse aisladamente, incluso aparecen
en otras metodologías de programación, pero juntos se complementan en una relación

sinérgica. Los beneficios de la programación orientada a objetos son más que los que
pueden verse a simple vista. El énfasis en las propiedades esenciales de un objeto,
fuerza al desarrollador a pensar cuidadosamente que es un objeto y que es lo que hace
con el resultado de que el sistema es normalmente más preciso, general y robusto que si
pusiéramos el énfasis en los procedimientos y los datos por separado
Construcción de clases
Tal como hemos definido con anterioridad, una clase de objeto describe a un grupo de
objetos con similares:
 Propiedades (atributos)
 Comportamientos (operaciones)
 Relaciones con otros objetos
La abreviatura clase es utilizada en lugar de clase de objetos. Los objetos difieren en los
valores asociados a sus atributos definidos dentro de la clase. Cada objeto <<conoce>>
cuál es su clase. La mayoría de los lenguajes orientados a objetos pueden determinar a
que clase pertenece un objeto durante la ejecución del programa.
A continuación expondremos una serie de pasos para definir una clase.
Identificar los objetos.
Para ello examine la aplicación e identifique las distintas estructuras de datos, algunos
tips a tener en cuenta son los siguientes:
 El nombre de la aplicación a veces nos da la del nombre del objeto principal

 Los objetos software pueden imitar el mundo real, modelizando las propiedades
de los objetos a través de variables Cualquier propiedad de un objeto puede ser
identificada dentro del objeto correspondiente a través de variables.
 Los objetos no se han de corresponder siempre con objetos físicos, sino que
también pueden ser entidades que se utilizan dentro de la construcción del
programa.
 Piense en el objeto en <<primera persona>>. Este truco nos puede identificar
claramente los atributos y sus operaciones asociadas: <<Soy un cuadrado y me
muevo, giro, agrando y reduzco. Las partes que me componen son los puntos de
mis vértices>>.
 Una clase es un tipo de dato que puede ser usado para declarar objetos, de la
misma forma que una estructura es un tipo definido por el usuario que puede
utilizarse para declarar variables.
Definir las operaciones
Defina las operaciones a partir de los objetos, examinando las distintas operaciones
asociadas a un conjunto de datos. Los atributos del objeto se deben definir de tal manera
que éstos satisfagan todos los requerimientos de cada una de las operaciones.
A estas operaciones añada dos más: Crear y Destruir. Estas operaciones nos servirán
para inicializar y borrar el objeto dentro de la aplicación.
A partir de la definición de las propiedades, un objeto siempre debe ser capaz de

responder a estas tres preguntas: ¿Qué soy ?, ¿Qué hago? ¿Qué dejo ver al resto del
mundo?
Algunas de las operaciones sólo se aplicarán a determinados objetos pertenecientes a las

clases. Hemos visto que a través de la herencia podemos <<especializar>> un sub
conjunto de objetos creando una sub-clase.
Únicamente aquellas operaciones que sean comunes a todos los objetos de la clase
deben incluirse dentro de las operaciones de la clase. El resto, que corresponden a las
operaciones de sub-Grupos de objetos, se deben definir dentro de la especializaciones
de la clase.
Definir los atributos de los objetos
Una vez identificados los objetos, defina los atributos de la clase. Un atributo es un
valor almacenado en los objetos de la clase.
Aplicaciones orientadas a objetos
A lo largo de la historia de la programación, los lenguajes y las metodologías han

pasado de una relativa simplicidad a una complejidad creciente. Los lenguajes de
programación orientados a objetos pretenden aportar simplicidad a la tarea de
programación de grandes aplicaciones.
Cuando se crearon las primeras computadoras todavía no existían los lenguajes de

programación, tal como ahora los entendemos. El lenguaje ensamblador puede
considerarse como el primer lenguaje de programación propiamente dicho. Permitía al
usuario un diálogo más fluido con la máquina a través de instrucciones que tenían
relación directa con el conjunto de operaciones que la máquina podía realizar.
A partir de este momento empezó la evolución de los lenguajes de programación. _cada

uno tenía su entorno definido y aunque en realidad todos los lenguajes son polivalentes
(en teoría, con cualquiera de ellos se puede desarrollar cualquier programa de gestión o
científico). Pronto apareció la especialización funcional. Así, COBOL (Common
Business Orientated Language) se introdujo como lenguaje mainframe para el diseño de
aplicaciones de gestión.; FORTRAN (Formula Translator) para el diseño de
aplicaciones científicas; APL (A Programming Language) para el cálculo matemático,
etc.
A medida que el software tomaba importancia, aparecieron los primeros problemas

relacionados con la programación. Al tiempo que aumenta el volumen de un programa,
disminuye el control del mismo por parte del programador y la capacidad de este de dar
mantenimiento.
En un intento de solucionar estos problemas aparecen las metodologías de

programación. Una metodología es un conjunto de reglas destinadas a simplificar las
tareas de diseño, estimación de costes, desarrollo y mantenimiento de un sistema
informático. A menudo se ven acompañadas con unas herramientas (CASE: Computer
Aided Software Engeneering) que permiten la elaboración estructurada y documentada
de los sistemas informáticos.
DISEÑO DE APLICACIONES Y ELECCIÓN DE ENTORNO.
En entorno de programación implica tanto el lenguaje de programación como al empleo

de una determinada metodología.
Los lenguajes de programación no se producen por generación espontánea y se ven

influidos en gran manera por la forma en la que los profesionales piensan que se debe
programar. De esta manera se crea un conjunto de reglas para simplificar la tarea de
programación. Generalizadas y codificadas, se convierten en <<principios>> de los que
surgen los lenguajes de programación en un afán por darles soporte.
Estos <<principios>> son modelos que proporcionan técnicas que, a su vez, deben
aplicarse en el diseño e implementación de los programas. Estas técnicas nos indican la
forma de resolver los distintos problemas que surgen a la hora de programar.
Decimos que un lenguaje de programación <<soporta>> un conjunto de <<principios>>

si el lenguaje simplifica la aplicación de estas técnicas. A estos <<principios>> se les
denomina metodologías de programación.
Las metodologías de programación son modelos sobre como diseñar e implementar los
programas. Diferentes modelos tienen como resultado diferentes técnicas. Que cada
técnica sea distinta no implica que una sea la verdadera y que las demás falsas. Por el
contrario, las metodologías se complementan entre sí. Lo que todas las metodologías
tienen en común es la premisa de que hay que partir de abstracciones que corresponden
a elementos del problema a resolver, y que la implementación de la solución se debe
realizar mediante un conjunto de módulos preferiblemente reutilizables.
Las metodologías orientadas a objetos se centran en las estructuras de datos que sin
embargo se relegan a un segundo plano en los modelos procedurales. La base de esta
metodología es que una estructura de datos debe contener las operaciones que los
modifican. La técnica que se utiliza para obtener esta <<abstracción de datos>> es la
encapsulación de los mismos en una estructura conocida como clase.
El acceso a los datos contenidos en la clase se realiza mediante las operaciones que la
propia clase define. Por tanto, la metodología orientada a objetos complementa el punto
de vista procedural de operaciones realizadas sobre un flujo de datos, al asociar a cada
dato el conjunto de operaciones que lo modifican. Como podrá ver, ambos enfoques son
complementarios.
Para ilustrar las diferencias entre las aproximaciones orientadas a procedimientos y las
orientadas a objetos, considere el diseño de un <<compilador>>
El compilador es un programa que a partir de un conjunto de fichero fuente (programa)

construye el código objeto que posteriormente se convierte en programa. Para realizar
su trabajo, el compilador lee el fichero fuente y separa de él las variables y las
instrucciones. Las variables constituyen la tabla de símbolos del programa, mientras que
las instrucciones se organizan en un árbol sintáctico donde se plasman todas las
referencias que realizan los mandatos y funciones entre sí.
El modelo mejor establecido es el basado en funciones (procedural) que trata de la

construcción de un programa como una colección de funciones. Las metodologías
proporcionan una gruía sobre cómo diseñar, organizar e implementar las funciones que
componen un programa. El método de diseño es la descomposición funcional que
identifica las funciones como los pasos a seguir en la resolución de un problema. La
organización en archivos permite que las funciones se agrupen módulos separados,
mientras que las técnicas de programación estructurada permiten que las

implementaciones de las funciones sean fáciles de consultar y mantener.
La programación orientada a objetos está basada en un modelo de construcciones de

programas como un conjunto de clases. El diseño orientado a objetos identifica los tipos
que representan los distintos objetos en el programa. Las operaciones a realizar con cada
uno de los objetos son, al igual que en el modelo procedural, los pasos destinados a
solucionar el problema. El objeto sirve además de módulo que puede reutilizarse para la
solución de un problema de similares características en otro programa.
Ninguna metodología resuelve con acierto todos los tipos de problemas. La

programación requiere una especialización como la que se produce en la ingeniería pero
todavía no es posible identificarla como una ciencia. Las técnicas a emplear se han de
utilizar con exquisito cuidado, sin perder de vista el objetivo de resolver un determinado
problema.
Actualmente existe la tendencia de identificar la programación con una disciplina como

la ingeniería. Sin embargo, debe considerarse más como un arte como la arquitectura,
donde se unen la inspiración y el dominio de la técnica.
Para la elección de un determinado entorno debemos fijar los criterios necesarios, como
los que describimos a continuación:
Tamaño de la aplicación
Cuanto mayor sea el volumen de información a procesar, mas necesidad habrá de

estructurar dicha información de forma que se fácil su manipulación.
Complejidad
Podemos dividir el problema de la complejidad en dos grandes apartados.
Datos: La complejidad viene reflejada por el tipo de datos a tratar, por las relaciones que
puedan tener los datos entre si, etc.
Funciones: El método para la obtención de nuevos datos es complicado o requiere un

esfuerzo de programación importante.
Aunque tratados como grupos independientes, ambos están generalmente

interrelacionados. De esta forma una estructura de datos compleja suele ir acompañada
de un conjunto de funciones de diseño complejo.
Asimismo, una mayor abstracción se traduce en unas instrucciones más potentes y un

soporte de estructuras de datos más complejas. Esto a menudo se traduce en que el
compilador (programa que traduce el programa introducido por el usuario en código
ejecutable por la máquina) ha de introducir una cantidad grande de código auxiliar para
poder ejecutar el código fuente.
Si ha programado en C o en Turbo Pascal, habrá observado que los ejecutables son en

general de pequeño tamaño. Un simple programa <<Hola mundo>>, clásico de
programación. Nunca es mayor de seis líneas de código y su ejecutable es siempre
inferior a 10 Kbytes. Si tomamos Clipper el programa no ocupa más de una línea pero
más de 200 Kbytes.
Rapidez
En algunos problemas la rapidez de respuesta es crítica. Este factor depende mucho de

soporte hardware y lentamente va asumiendo menos importancia.
Portabilidad
La portabilidad es la capacidad que ha de tener el programa para funcionar en distintos

entornos operativos. La realización de un programa portable , en general, depende de la
elección de un lenguaje de programación , así como del alejamiento de las ventajas e
inconvenientes que proporciona el soporte hardware y el sistema operativo. La creación
de un programa portable a menudo incide negativamente en los apartados de tamaño y
rapidez, ya que un alejamiento de la plataforma hardware y del sistema operativo, a
menudo se consigue emulando sus características. Esto conlleva un aumento del tamaño
y la complejidad del programa, así como un incremento en el tiempo de ejecución.
Gestión de recursos
Este factor indica las exigencias que hace nuestro lenguaje de los recursos disponibles
por el ordenado. El más limitado, aun más que el espacio en disco, es la memoria. Un
programa grande que gestione de manera incorrecta la memoria pronto agotará todos los
recursos del sistema.
Interface de usuario.
Aunque no se puede contar como un factor a considerar, la importancia que el interface

de usuario está tomando en los últimos años hace que lo consideremos por separado. El
diseño del interface de usuario aporta una complejidad propia al desarrollo de
aplicaciones. De hecho, se considera que en un principio este apartado ocupaba apenas
entre el 10 y el 30 por ciento del esfuerzo de programación, para llegar a absorber entre
el 50 y 70 por ciento de dicho esfuerzo en la actualidad.
La aparición de interfaces gráficos de usuario estándar (Windows, os2, X-Windows,

etc.) ha hecho que factores como la rapidez o el tamaño vuelvan a tomarse en cuenta,
después de que el consumo de recursos de la parte del interface de usuario creciera de
forma espectacular.
APLICACIONES ORIENTADAS A OBJETOS
Cómo afectan los requerimientos anteriores para la elección de un lenguaje orientado a

objetos como herramienta para el desarrollo de nuestros programas?
Claridad
Al ligar de forma evidente la estructura de la información con los procedimientos que la

manipulan, los programas ganan en claridad a la hora de desarrollarlos y mantenerlos.
Esto supone una ventaja frente a los lenguajes procedurales , aunque éstos podrían
suplir esta deficiencia mediante una correcta elección de los nombres de las variables y
funciones, lo que se denomina una <<oportuna codificación>>.
Complejidad
Cuando la complejidad de un problema es abarcable por una sola persona, resolverlo

con una herramienta u otra no aporta grandes ventajas. Pero cuando este desarrollo la
tiene que realizar un equipo grande, debe existir una forma para aislar partes de
problema.
Uno de los problemas más comunes, y a su vez más simples de solucionar en el diseño
de grandes sistemas, es el nombre que se da a las funciones y qué tipo de datos
manipulan éstas.
En la realización de un sistema informático se utiliza un equipo de varias personas. El

trabajo se divide en tres áreas funcionales: una parte del equipo se encarga del interface
de usuario, otra de la manipulación de datos y, la última del diseño de salidas impresas.
Cada quipo utiliza funciones y datos suministrados por los otros miembros del equipo y
a su vez diseña funciones para su uso interno y para el uso del resto de los grupos. Si no
se realiza la división del trabajo de forma adecuada puede producirse el caos. He aquí
una pequeña enumeración de los problemas que se pueden encontrar.
 Las funciones desarrolladas por cada uno de los grupos no encajan con las
necesidades de los demás.
 Otros grupos han elegido nombres de variables y funciones similares a los
elegidos por nuestro grupo. Estas funciones y variables son prácticamente
iguales a las desarrolladas por nosotros, pero varían ligeramente en el
tratamiento de la información, por lo que no podemos sustituir nuestras
funciones. Ambas deben coexistir aumentando la complejidad del programa de
manera innecesaria.
 El resto de los grupos sólo cubren determinados aspectos de la información a
tratar, pero no proporcionan toda la información necesaria para que el programa
funcione. El resto de información debe suministrarse suplantando parte de la
funcionalidad destinada a otros grupos.
 Algunas de las modificaciones que realizamos sobre variables locales o globales
producen resultados imprevistos en el resto de los módulos.

 Tamaño
Las aplicaciones orientadas a objetos son ideales para la realización de programas de

gran tamaño. Las facilidades de encapsulación y asociación de las funciones a los datos
que manipulan, simplifican el proceso de desarrollo. De hecho las bases de datos
orientadas a objetos suponen un gran adelanto, ya que aúnan la flexibilidad en la
manipulación de los OOP con la capacidad de consulta de un DBMS (Data Base

Management System)
Relación entre Datos
Por el mismo motivo se verán beneficiados aquellos programas que impliquen una
relación compleja entre los datos. Este tipo de complejidad permite la utilización de
todas las ventajas de los lenguajes de programación orientados a objetos. Propiedades
como la herencia (donde los objetos pueden heredar estructura y operaciones de objetos
predecesores), la encapsulación, etc. Muestran en este tipo de programas todas sus
ventajas.
Rapidez
En este aspecto, los lenguajes orientados a objetos muestran una clara desventaja frente
a otros lenguajes que se acercan más a las especificaciones de la máquina. Si la rapidez
es crítica, puede elegir un lenguaje de programación como C++, que aporta toda la
funcionalidad de los lenguajes orientados a objetos con la rapidez y la compatibilidad de
C.
Gestión de recursos
Las aplicaciones orientadas a objetos demandan normalmente más recursos del sistema
que las aplicaciones procedurales. La creación dinámica de objetos, que ocupa un lugar
en la memoria del ordenador, puede acarrear graves problemas. Una de las soluciones,
que incluye alguno de los lenguajes OOP, es liberar a menudo el espacio que los objetos
dejan de utilizar. Este procedimiento de optimización como garbage collection
(recolección de basura, implementado en java), minimiza los efecto de la creación
dinámica de objetos.
Interface de usuario.
El interface de usuario es uno de los aspectos más importantes en la programación

actual. La aparición de sistemas de explotación que soportan un interface gráfico de
usuario como Windows, X-Windows o Presentation Manager hace que la mayoría de
los usuarios prefieran que sus programas corran bajo este tipo de interface. Este es uno
de los puntos fuertes para la elección de un lenguaje OOP. La mayoría de los interfaces
gráficos actuales han sido diseñados o rediseñados en base a la OOP. Existen en el
mercado librerías de clases que soportan todos los dispositivos de control de ventanas
como menús, combo box, listas, barras de herramientas, etc.
Lenguajes orientados a objetos
Los lenguajes OOP implementan de manera distinta los conceptos de programación

orientada a objetos. No existe el lenguaje perfecto capaz de satisfacer todas las
necesidades y que se adapte a todos los estilos
A Continuación unos consejos que nos facilitarán la elección del lenguaje de

programación adecuado:
 Si los programas se van a sentar en una cualidad concreta de los OOP como
herencia, elija el que mejor soporte le dé.
 Los lenguajes interpretados sirven para realizar un desarrollo rápido o para
aquellos programas que necesiten una actualización constante. Si el programa
necesita rapidez o es crítico respecto al tamaño, considere el uso de lenguajes
que incorporen compilador.
 No <<reinvente la rueda>>. Si el lenguaje le proporciona una librería de clases
no intente reescribrlas de nuevo, use las que le ofrece el sistema. Es más tome
como factor de elección las librerías de clases que el compilador incorpora o que
estén disponibles en el mercado.
 Si necesita mejorar la calidad del programa previniendo errores, utilice un
lenguaje que le permita definir las variables con sus tipos asociados.
 Si la memoria del sistema es limitada, utilice lenguajes que permitan la creación
y destrucción automática de clases dependiendo de su utilización.
CARACTERÍSTICAS DE LOS LENGUAJES OOP
Herencia múltiple
Esta característica suele ser común a la mayoría de los lenguajes OOP, aunque introduce
un problema al existir la posibilidad de que el objeto sucesor herede el mismo atributo,
aunque con distinto tipo y valor, de más de un predecesor. Alguno de los lenguajes de
programación soluciona este problema de forma automática, aunque los más populares
generan un error en el tiempo de compilación. Recomendamos que se examinen con
cuidado las clases para evitar en lo posible estos errores.
Eficiencia.
Los lenguajes OOP arrastraron en un principio la reputación de ser ineficaces. Esto se

debía en gran medida a que los primeros lenguajes (como Smalltalk) eran interpretados
y no compilados. La existencia de compiladores permite a los desarrolladores ganar
rapidez. Actualmente, usando un buen lenguaje orientado a objetos como C++, Java,
etc. Junto con las librerías apropiadas para la realización de un programa, puede que se
ejecute más rápidamente que el mismo programa compilado con un lenguaje procedural.
Asignación de tipos.
Los lenguajes orientados a objetos varían de forma sustancial la forma por la que se
aproximan a la asignación de tipos.
Por asignación de tipos entendemos que cada variable sea identificada como
perteneciente a una clase (asignación fuerte) o sea simplemente un objeto indeterminado
(asignación débil). Eiffel y C son dos lenguajes basados en la asignación fuerte, frente a
Smalltalk, en el que todas las variables definidas pertenecen a una clase indeterminada.
La asignación fuerte sirve a dos propósitos. Por una parte para que el desarrollador
pueda identificar a que clase pertenece cada operación. De forma concreta, en aquellos
lenguajes donde está implementado el operator overloading (refefinición de operador),
el compilador puede reconocer a través de las clases que entran como parámetros en la
operación que operación tiene que utilizar.
Por otra, este tipo de declaración permite al compilador un mayor grado de

optimización, ya que conoce en todo momento el espacio que ha de asignar.
Manejo de memoria.
Los OOP son lenguajes que utilizan de manera intensiva la memoria de la computadora.
Hay dos tipos de aproximación a la gestión de memoria.

El sistema en tiempo de ejecución libera la memoria automáticamente a medida que los

objetos dejan de utilizarse.
El sistema tiene instrucciones concretas para liberar l memoria explícitamente. Este el

enfoque adoptado por lenguajes como C++, que aportan dos operadores: crear y
destruir. El primero reserva automáticamente memoria, mientras que el segundo la
libera.
PANORAMICA DE LOS LENGUAJES OOP
A continuación, una pequeña panorámica de los lenguajes orientados a objetos
SMALLTALK
Fue el primer lenguaje de programación orientado a objetos. Desarrollado en el Xerox

PARC, en sus primeras implementaciones no ofrece solamente un intérprete, sino que es
mucho más ambicioso, integrando intérprete on-line y otros aspectos que le convierten
en un <<pseudo>> sistema operativo. Es el primero en aportar la arquitectura de
Modelo/Visor/Controlador. El interface de usuario se divide en una definición sobre la
que se aplican determinado número de vistas gestionadas por un controlador. El MVC
permite al desarrollador concentrarse en la parte esencial de la aplicación (el modelo) y
añadir interfaces de usuarios ( las vistas y controles) de forma independiente.
Ventajas
 Smalltalk es un lenguaje puro orientado a objetos

 La implementación a través de un intérprete facilita la labor de desarrollo de
programas. Las clases son añadidas, corregidas y depuradas de forma
interactiva.
 Tiene una sintaxis simple, donde las variables y los atributos no necesitan tener
un tipo asociado. Todo está definido en principio como objeto, incluyendo las
propias clases.
Inconvenientes
 Es un lenguaje interpretado, lo que reduce su rendimiento y dificulta su

comercialización.
 Al proporcionar su propio entorno operativo, interactúa mal con otro tipo de

software o hardware
Eiffel
Es un lenguaje de programación escrito por Bertrand Meyer. Al contrario que Smalltalk,

incluye un preprocesador que permite la traducción de código Eiffel a Lenguaje C. Es
ideal para la ingeniería de software, que permite la encapsulación, control de acceso y
ámbito de las modificaciones. Como lenguaje orientado a objetos <<puro>>, es
presumiblemente el mejor por sus capacidades técnicas.
Los programas consisten en la declaración de colecciones de clases que incluyen

métodos. El punto primordial de un programa Eiffel es la declaración de clases, que
asocia atributos. Ambos, clases y atributos, son accesibles a partir de la implementación
de un concepto llamado característica. Una característica es, por tanto, una agrupación
de datos y unas formas típicas de tratarlos.
En Eiffel una declaración de clases puede incluir:
 Una lista de características exportables.

 Una lista de las clases antecesora: clases de la que ésta es una derivación
 Una lista de declaraciones de características.
Ventajas
 Es un lenguaje orientado a objetos <<puro>>

 Eiffel es un lenguaje de programación orientado hacia el diseño de grandes
aplicaciones. Las propiedades anteriores le hacen ideal para el diseño de
aplicaciones en grupos de trabajo.
 El paso intermedio a código C se puede considerar como una ventaja y no como
un inconveniente, ya que aquellas secciones que sean difíciles de tratar con
Eiffel pueden elaborarse a partir de código C. Su compatibilidad con C asegura
también su portabilidad hacia otros sistemas operativos
Desventajas
 El manejo de la memoria, un punto delicado en todos los lenguajes orientados a

objetos no es transparente como en el caso de Smalltalk.
 Las librerías de clases son reducidas
 El rendimiento es mayor que el de Smalltalk, pero al tener que incluir un módulo
Run-time dentro del ejecutable, su tamaño crece y su rendimiento baja.
C++
Es un lenguaje de uso general que deriva del C.
Añade a su predecesor una serie de características que le convierten en un lenguaje

orientado a objetos. Dentro de estas características debemos resaltar:
 La abstracción de datos
 La programación orientada a objetos, ya que permite asociar a los datos las
funciones que los manipulan
C++ conserva todas las capacidades de su predecesor C. De hecho, el código C puede

tratarse con compiladores C++ y ejecutarse sin ningún problema. En un principio C++
era traducido a código C a través de una utilidad llamada precompilador.
También es cierto que se pueden utilizar algunas de las ventajas de C++ (como C
mejorado) para escribir código no orientado a objetos.
Enumeramos los aspectos más importantes que hacen del C++ un lenguaje orientado a
objetos:
 La mayor contribución que realiza C++ al C es la introducción del tipo clase.

Las clases permiten definir conjunto de datos y las funciones que los manipulan.
 La ocultación de datos es el mecanismo para implementar la abstracción de
datos. La abstracción de datos permite al programador <<olvidar>> el
funcionamiento interno de una clase, ya que sabe que su funcionamiento no va a
alterar anómalamente el funcionamiento de otras clases. Una vez definida la
clase es transparente para el desarrollador y permite operar con ella como si
fuera un tipo básico.
 La herencia extiende el concepto de abstracción de datos al permitir la

construcción de clases a partir de otras (sus antecesores)
 Los operadores definidos por el usuario permiten un tratamiento homogéneo
entre los tipos predefinidos por el lenguaje y los desarrollados por el
programado.
Otras características no relativas a la programación orientada a objetos, simplifican el

diseño y desarrollo.
 Optimización de explotación de memorias, que permite la creación de

estructuras de datos dinámicas.
 Implementación del solapamiento de funciones. Esta técnica permite definir
varias funciones con el mismo nombre pero distintos parámetros de entrada.
Dependiendo de los parámetros que acompañen la llamada de la función, será
ejecutada una u otra.
BASES DE DATOS ORIENTADAS A OBJETOS
La programación orientada a objetos es muy versátil. No se restringe únicamente al

diseño de programas, sino que es posible aplicar los mismos conceptos al diseño de
bases de datos. El uso de una técnica orientada a objetos trasciende a la elección de la
base de datos.
El uso de esta técnica en el diseño de bases de datos aporta las cualidades de esta
metodología a nuestro diseño. Eficiencia, coherencia y un menor coste a la hora de
actualizar la estructura de las bases de datos son los principales beneficios que aporta.
Como valor añadido, el uso de una misma técnica en el diseño, tanto de los programas
como de las bases de datos proporciona coherencia a nuestro sistema.
Las bases de datos orientadas a objetos unen dos tecnologías:
La de las bases de datos y la de los lenguajes orientados a objetos. Los Lenguajes OOP
aportan gran capacidad en la manipulación de datos, pero no implementan el
almacenamiento y consulta de grandes volúmenes de datos.
Por el contrario, las bases de datos convencionales aportan un dominio de las técnicas
de almacenamiento y consulta de grandes volúmenes de datos, aunque su capacidad de
manipulación es limitada.
Las bases de datos orientadas a objetos pretenden unir la capacidad de manipulación de

datos de los OPP con la capacidad de almacenamiento y consulta de los DBMS.
Las aplicaciones convencionales que agrupan programas y bases de datos, separan

ambos entornos de manera clara.
El desarrollador usa técnicas procedurales para la descomposición de problemas y su

codificación en funciones. Posteriormente se emplean técnicas como las de Entidad –
Relación para el diseño de la base de datos.
Su codificación suele realizarse en un lenguaje de alto nivel como C, que lleva

embebido código SQL. El término embebido describe la inclusión de un módulo escrito
bajo otro lenguaje de programación dentro del código fuente. El compilador incorpora
durante la fase de enlace el Run-Time correspondiente para que pueda funcionar el
código embebido.
Como podrá observar, esta técnica presenta defectos evidentes:
Por una parte, se utilizan diferentes técnicas para el desarrollo de ambos apartados, por
lo que la tarea de diseño no se puede considerara como un todo único
Por otra y en gran medida debida a la primera, los lenguajes que se utilizan para la
implementación difieren, dificultando las labores de mantenimiento.
Ejemplos
Como habrá podido observar a lo largo de esta monografía, nuestro propósito no ha siso
el de enseñar una metodología ni la enseñanza de un determinado lenguaje de
programación.
El objetivo es por el contrario dar una panorámica de los conceptos de la programación

orientada a objetos, de las metodologías y de las técnicas de desarrollo de aplicaciones.
En este apartado nos centraremos en lo aspectos más importantes en el desarrollo de

aplicaciones bajo OOP: identificación de objetos y análisis de asociaciones.
OBJETOS Y ASOCIACIONES.
La parte más importante de todo diseño es el punto de entrada de la definición de

requerimientos. En la observación atenta de los requerimientos se pueden hallar la
mayoría de los objetos pertenecientes a nuestra aplicación.
En este ejemplo nos centraremos en la identificación de objetos a partir de los

requerimientos básicos de la aplicación.
Este análisis es el primero que debe hacerse dentro de OOP y es también útil para
cualquier otra técnica de programación.
Analicemos la siguiente definición de requerimientos:
El <<sistema de tratamiento de información documental>> es un gestor de

<<documentos>>, de tal manera que puedan clasificar en uno o varios <<índices>>,
recuperar para su modificación, visualizar, para su consulta, reclasificar, archivar y
destruir. El <<sistema>> procesa la petición del <<usuario>>, devolviendo un mensaje
e indicando el éxito o el fracaso de la petición.
De una manera general hemos indicado entre comillas los sustantivos y en cursiva los
verbos. De esta forma hemos identificado los objetos principales de la aplicación y las
operaciones asociadas a cada uno de los objetos.
Observe el siguiente diagrama.

Hemos traducido los requerimientos a un conjunto de objetos.
Estos están inconexos entre sí, pero aplicando la <<lógica>> podemos ver las relaciones
que existen entre ellos. Sin salirnos de las especificaciones de la aplicación, vemos que
existen las asociaciones que aparecen en la siguiente figura:
Como podemos observar, algunas asociaciones cíclicas como Índice <-> Documento.
Estas asociaciones pueden simplificarse. También existen otras implícitas que
examinaremos más adelante, como Usuario->Documento->Índice.
Observemos gráficamente las asociaciones que mantienen los objetos entre sí en la

siguiente figura
Como puede verse hay dos asociaciones sospechosas, ya que no son verbos sino los
sustantivos <<petición>> y <<mensaje>>. Estas dos asociaciones se pueden
<<objetivar>> de tal manera que reúnan las condiciones de un objeto. Para ello
debemos volver a las especificaciones iníciales.
Cuando se archiva un documento se debe indicar el nombre del documento así como los
índices a los que se va a asociar. Las peticiones de recuperación deben incluir un índice
y el nombre del archivo. Las consultas a los índices deben incluir el nombre del indice y
una condición.
A partir de este análisis se puede depurar con HERENCIA y posteriormente realizar un

<<ajuste fino>>
LA RELACION DE HERENCIA.
A continuación vamos a centrarnos en la relación de herencia.
Como ya sabemos ésta puede agrupar objeto son similares característica o bien
especializar objetos a partir de una genérico. Observemos nuevamente los
requerimientos de nuestro sistema:
2. INTRODUCCIÓN - ¿QUE ES VISUAL C++ ?
Como sabemos, Windows es el entorno más popular de interfaz gráfico de usuario

(GUI). Desde este punto de vista, Windows es un entorno multitarea basado en
ventanas, que representan programas, y que permite ejecución concurrente.
Para desarrollar programas, Windows provee una librería de rutinas y funciones (SDK -
Kit de desarrollo de software) que permiten gestionar componentes como menús,
diálogos, ventanas, etc.
Visual C++ es un entorno integrado de desarrollo que permite la programación

orientada a objetos (POO) conjuntamente con el sistema de desarrollo SDK (también
denominado API) de Windows. Al ser un entorno integrado Visual C++ incluye, entre
otras, las siguientes herramientas de desarrollo:
 Editor de texto
 Compilador/Enlazador
 Depurador
 Visor de datos y dependencias (Browser)
Pero si desde el punto de vista del usuario Windows es un sistema amigable, desde el
punto de vista del desarrollador observaremos todo lo contrario. El SDK de Windows
no es mas que un complejo conjunto de funciones que añade además numerosas
definiciones de tipos de datos nuevos para cualquier programador de C/C++ para DOS.
Para solucionar este problema, Visual C++ incluye la librería de clases MFC (Microsoft
Foundation Classes) que permite crear y gestionar de manera intuitiva componentes
típicos de Windows. Esto es, la MFC es una implementación que utiliza el API
encapsulando todas las estructuras y llamadas a funciones en objetos fáciles de utilizar.
Basándose en la potencia de la MFC, Visual C++ se convierte en un generador de
programas C++ para Windows.
El objetivo del presente curso es conocer el modelo de programación para Windows

basado en la librería de clases MFC. En este documento se destacarán ideas, conceptos
y tratamientos generales, en ningún momento pretende ser un manual completo de
programación con MFC.
1.
1. Como todos sabemos, "C" es un lenguaje de alto nivel, basado en
funciones, que permite desarrollos estructurados. Entre otras muchas
características contempla la definición de estructuras de datos,
recursividad o indirecciones a datos o código (punteros).
"C ++", por su parte, es un superconjunto de "C", al que recubre con una
capa de soporte a la POO. Permite por tanto la definición, creación y
manipulación de objetos.
2. ¿Que es C ++ ?
3. ¿Que es la Programación Orientada a Objetos ?
2. CONCEPTOS PRELIMINARES
La POO es una nueva filosofía de programación que se basa en la utilización de objetos.

El objetivo de la POO no es sino la meta de cualquier modelo de programación
estructurada convencional: "imponer" una serie de normas de desarrollo que aseguren y
faciliten la mantenibilidad y reusabilidad del código.
Los mecanismos básicos de la POO son: objetos, mensajes, métodos y clases.
 Objetos. Un objeto es una entidad que tiene unos atributos particulares (datos) y
unas formas de operar sobre ellos (los métodos o funciones miembro). Es decir,
un objeto incluye, por una parte una serie de operaciones que definen su
comportamiento, y una serie de variables manipuladas por esas funciones que
definen su estado. Por ejemplo, una ventana Windows contendrá operaciones
como "maximizar" y variables como "ancho" y "alto" de la ventana.

 Mensajes. En C++, un mensaje se corresponde con el nombre de uno de los

métodos de un objeto. Cuando se pasa un mensaje a un objeto, este responde
ejecutando el código de la función asociada.

 Método. Un método (función miembro) se implementa dentro de un objeto y

determina como tiene que actuar el objeto cuando se produce el mensaje
asociado. En C++ un método se corresponde con la definición de la función
miembro del objeto. La estructura más interna de un objeto está oculta, de tal
manera que la única conexión con el exterior son los mensajes

 Clases. Una clase es la definición de un tipo de objetos. De esta manera, una

clase "Empleado" representaría todos los empleados de una empresa, mientras
que un objeto de esa clase (también denominado instancia) representaría a uno
de esos empleados en particular.
Las principales características de la POO son: abstracción, encapsulamiento, herencia y

polimorfismo:
 Abstracción. Es el mecanismo de diseño en la POO. Nos permite extraer de un

conjunto de entidades datos y comportamientos comunes para almacenarlos en
clases.

 Encapsulamiento. Mediante esta técnica conseguiremos que cada clase sea una
caja negra, de tal manera que los objetos de esa clase se puedan manipular como
unidades básicas. Los detalles de la implementación se encuentran dentro de la
clase, mientras que desde el exterior, un objeto será simplemente una entidad
que responde a una serie de mensajes públicos (también denominados interfaz
de la clase).

 Herencia. Es el mecanismo que nos permite crear clases derivadas

(especialización) a partir de clases bases (generalización). Es decir, podríamos
tener la clase "Empleado" (clase base) y la clase "Vendedor" derivando de la
anterior. Una librería de clases (como la MFC) no es más que un conjunto de
definiciones de clases interconectadas por múltiples relaciones de herencia.

 Polimorfismo. Esta característica nos permite disponer de múltiples

implementaciones de un mismo método de clase, dependiendo de la clase en la
que se realice. Es decir, podemos acceder a una variedad de métodos distintos
(con el mismo nombre) mediante el mismo mecanismo de acceso. En C++ el
polimorfismo se consigue mediante la definición de clases derivadas, funciones
virtuales y el uso de punteros a objetos.
Otros dos conceptos muy importantes en la POO son relativos a la creación y

destrucción de objetos. En lenguajes estructurados convencionales, cuando se define
una variable se le reserva espacio en memoria y, si no se inicializa expresamente, se
hace por defecto (por ejemplo, en C una variable global siempre se inicializa a 0, pero
una automática no, por lo que si no se inicializa expresamente su contenido inicial será
basura); por otra parte, cuando se destruye una variable (por que se abandona el ámbito
de su definición - scope -) se libera la memoria que estaba ocupando. Si ahora hacemos
el paralelismo obligado entre variables y objetos para los lenguajes POO nos daremos
cuenta de que deben existir procedimientos especiales de construcción y destrucción de
objetos. En concreto, cada clase tiene dos funciones miembro especiales denominadas
constructor y destructor.
 Constructor -> Función miembro que es automáticamente invocada cada vez

que se define un objeto, su objetivo es la inicialización del mismo. Toma el
mismo nombre que la clase, puede recibir parámetros y podemos tener varios
constructores definidos.

 Destructor -> Función miembro invocada automáticamente cada vez que se

destruye un objeto. Su objetivo es realizar operaciones como liberación de
memoria, cerrar ficheros abiertos, etc. Toma el mismo nombre de la clase
comenzado primero por el carácter "~", no toma parámetros y no admite la
sobrecarga (sólo puede existir uno en cada clase).
En muchos casos, para las clases mas sencillas, podemos encontrar clases que no tiene
constructor o destructor, ó ninguno de los dos. En C++, siempre existen constructores y
destructores por defecto que realizan una inicialización/liberación estándar.
1. El modelo de programación Windows
El modelo de programación propuesto por Windows es totalmente diferente al modelo

de ejecución secuencial de DOS. Al ser Windows un entorno multitarea los programas
tienen que estar preparados para compartir los recursos de la maquina (procesador,
memoria, teclado, ratón …). Esto supone que Windows ha de disponer de métodos que
permitan suspender tareas para activar otras en función de las circunstancias del
momento (por ejemplo, por acción del usuario).
Pero por parte de las aplicaciones, este hecho supone que han de cooperar en la
compartición de esos recursos. Las aplicaciones Windows se limitan a "esperar"
mensajes procedentes del sistema, procesarlos y volver al estado de espera. Este modelo
de programación se conoce como "orientado al evento".
 Mensaje. Es una notificación a la aplicación de que ha ocurrido algo de interés y

que por lo tanto debe de realizarse alguna acción específica. El origen del
mensaje puede ser el usuario (haciendo click con el ratón dentro e una ventana),
la propia aplicación (mandándose un mensaje a si misma) o Windows (pidiendo,
por ejemplo, que se repinte la ventana tras ocultarse otra que tuviese delante).
Dado que la unidad mínima de ejecución en Windows es una ventana, los
mensajes van realmente dirigidos a ellas.

 Ventana y procedimiento de ventana. En Windows, una aplicación se

representa físicamente por su ventana principal (aunque después pueda
desplegar diversas ventanas hijas). Cada una de esas ventanas dispone de una
serie de propiedades y un código asociado (lo que concuerda con el principio de
la POO, en el concepto de objeto). Al código asociado a cada ventana se le
denomina procedimiento de ventana. Es una función que recibe los mensajes, los
procesa y devuelve el control a Windows para quedar en espera.
Otra de las características específicas de Windows frente a DOS es el uso de recursos

por parte de las aplicaciones, como son iconos, menús, mapas de bits, cursores,
plantillas de diálogos, etc. Las aplicaciones Windows disponen por tanto de recursos
(gráficos generalmente) propios almacenados en lo que se llama el fichero de recursos).
El proceso de construcción de programas en Windows incorpora una fase adicional al
compilado y enlazado de los módulos objeto y las librerías. Hay un proceso final de
compilación y de enlazado (bind) del fichero de recursos.
3. EL ENTORNO DE DESARROLLO - INTRODUCCIÓN.

El entorno de desarrollo viene representado por el icono "Developer Studio". En él se

integran entre otras las siguientes herramientas:
 Editor orientado a la codificación C/C++ (resaltando palabras claves …)

 Compilador/Enlazador incremental, que acelera el proceso de construcción de
los programas.
 Depurador visual, que permite visualizar y modificar el contenido de variables y
áreas de memoria.
 Visor de datos (browser) que permite fácilmente controlar dependencias y
referencias a funciones, datos, clases, etc. Además permite visualizar la jerarquía
de las clases utilizadas en los programas.
 Herramientas complementarias como un analizador de ventanas (Spy ++) o un
trazador de funciones MFC.
1. En Visual C++ la construcción de cualquier tipo de programa se inscribe dentro

del concepto de proyecto (workspace). Un proyecto define los pasos a seguir
para alcanzar la construcción de un objetivo (un programa, una DLL, etc.), en
realidad es un concepto análogo a lo que se conoce como "makefile" en otros
entornos típicos de desarrollo en C. En realidad, Visual C++ genera para cada
proyecto dos ficheros que lo definen, el fichero de workspace (con extensión
wsp) y un makefile (con extensión mak) estándar que permitiría la utilización
del mismo proyecto en otro entorno distinto.
Desde el punto de vista funcional, el proyecto contiene referencias a cada uno de

los ficheros fuentes (C/C++, con extensiones c y cpp respectivamente), objetos,
librerías o ficheros de recursos (extensión rc) que se deben utilizar para construir
el objetivo final del proyecto.
En definitiva, para crear cualquier programa con Visual C++ debemos comenzar
creando un proyecto para él, codificando y añadiendo los módulos necesarios a
dicho proyecto, y definiendo los recursos asociados.
2. El concepto de proyecto (workspace)

3. Posibilidades de programación
Cuando se crea un nuevo proyecto (desde la opción "Nuevo" del menú "Fichero"
aparece un diálogo que nos permite especificar que se cree un nuevo workspace), lo
primero que solicita el sistema es determinar el tipo de objetivo que se persigue con este
proyecto. Destacar las siguientes posibilidades:
 Aplicación (.EXE) basada en la MFC (MFC AppWizard)

 Librería de enlace dinámico (.DLL) basada en la MFC. (MFC AppWizard)
 Aplicación (.EXE) estándar para Windows (basada en el SDK)
 Librería de enlace dinámico (.DLL) (basada en el SDK)
 Aplicación (.EXE) modelo DOS (Console application)
 Librería estática (.LIB)
Como ya hemos destacado anteriormente, el objetivo del presente curso es el manejo de

la librería MFC, por lo que nos centraremos básicamente en el primer punto (la
construcción de una DLL con MFC es totalmente similar).
1. EL GENERADOR DE APLICACIONES.
Ya sabemos que Visual C++, apoyado en la potencia de la MFC, es capaz de convertirse

en un generador de aplicaciones. Para ello dispone de dos herramientas integradas
complementarias:
 AppWizard, que es el generador de aplicaciones propiamente dicho. Con él

podremos generar esqueletos de programas para Windows basados en la MFC.

 ClassWizard, herramienta de mantenimiento de los programas generados con la

anterior. Permite añadir o eliminar clases, modificar los comportamientos de las
mismas, etc.
Pero el código generado mediante este método presenta una complejidad añadida a la
natural de cualquier programa; junto con el código C/C++ y el de la MFC aparecen
líneas (generalmente entre comentarios) que son totalmente necesarias para el
funcionamiento de las dos herramientas anteriores, modificar cualquiera de esas líneas
de código dará muchos problemas a la hora de utilizar ClassWizard para modificarlo.
De todas maneras, este "defecto" es bastante popular entre los usuarios de cualquier
generador de código, para cualquier lenguaje.
El formato general de los proyectos generados con estas herramientas suele tener las
siguientes características:
 Cada clase de nuestro programa dispondrá de dos ficheros: Un fichero de

cabecera (extensiones .h o .hpp) y un fichero de implementación (.cpp). El
fichero de cabecera contiene la definición de la clase (definiciones de sus
miembros datos y funciones - los mensajes -), mientras que el fichero fuente
contiene la implementación de esas funciones miembro (los métodos de la
clase).
 Un fichero de recursos (extensión .rc), aunque éste es opcional.
 Módulos objetos (.obj) y librerías estáticas (.lib) necesarias para crear nuestro
programa
1. CONSTRUCCIÓN DE UNA APLICACIÓN BÁSICA
Seguiremos los siguientes pasos:
1. Crear un nuevo proyecto. Desde el menú "Fichero", en la opción "Nuevo".
1. Seleccionar objetivo del proyecto. Seleccionaremos "aplicación basada en MFC"
1. Nombrar el proyecto. Visual C++ organiza los proyectos de manera que crea un
subdirectorio nuevo con el nombre de cada proyecto. Aunque esta "regla"
siempre puede modificarse, puede ser una buena forma de control de proyectos.
En estos momentos aparecerá la secuencia de diálogos del generador ClassWizard.

Veamos cuales serían los pasos a seguir para crear una aplicación sencilla:
1.
2. Paso 1. Permite identificar el modelo de ventana principal de nuestra aplicación:
SDI, MDI o basada en diálogo. Nosotros elegiremos SDI.
1. Paso 2. Permite incorporar soporte a Bases de Datos en la aplicación. Esto lo

veremos más adelante. Seleccionaremos la opción sin soporte a bases de datos.
1. Paso 3. Relativo al soporte OLE. Igual que en el caso anterior.

1. Paso 4. Otras características de la aplicación (barra de botones, barra de estado,

controles 3D …)
1. Paso 5. Generación de comentarios en el código (si/no) y usos posibles de las

MFC (como DLL o como LIB). Se recomienda la opción DLL en cuanto al
tamaño y modularidad del programa, pero deberemos asegurarnos de distribuir
la DLL junto con nuestro programa para que funcione correctamente.
1. Paso 6. Permite modificar el nombre de las clases MFC que se van a generar,
además de especificar los ficheros en los que se implementa y la clase base de la
que derivan. Los nombres generados por AppWizard suelen ser bastantes
significativos.
A partir de este momento da comienzo la generación del código definido antes. Como
se habrá observado, el nombre por defecto de las clases generadas tiene mucho que ver
con el nombre que le hayamos dado al proyecto. De esta manera, si hubiésemos llamado
"curso1" al proyecto tendríamos la siguiente situación:
 Clase CCurso1App (módulos curso1.h y curso1.cpp) que representa una

aplicación Windows.
 Clase CMainFrame (ficheros mainfrm.h y mainfrm.cpp) que representan la
ventana principal de la aplicación.
 Clases CCurso1Doc y CCurso1View (ficheros curso1doc.h/curso1doc.cpp y
curso1view.h/curso1view.cpp respectivamente), representantes de lo que se
conoce en el mundo Windows como interfaz "Documento/Vista" y que
trataremos en adelante.
 Clase CAboutDlg que representa el típico diálogo de "Acerca de …" y que ha
sido generado automáticamente por AppWizard, esta clase (rompiendo la norma
habitual de la MFC) aparece definida e implementada dentro los mismos
ficheros que la clase aplicación (módulos curso1.h y curso1.cpp). En el futuro
evitaremos este tipo de construcciones.
Cada una de estas clases se revisará con detalles en capítulos sucesivos.
1. EL ENTORNO DE DESARROLLO - VISOR DE PROYECTOS

El Visor de Proyectos es una ventana a través de la que podemos visualizar el contenido

de los proyectos, accedemos a la misma desde el menú "Ver" y la opción "Proyecto".
Está formada por 3 carpetas que nos permiten visualizarlos desde distintos puntos de
vista:
 ClassView, o Visor de clases, representa el proyecto con las clases que lo

componen. Desde aquí podremos añadir miembros datos o funciones fácilmente.
 ResourceView, o Visor de recursos, que permite añadir/modificar/eliminar
recursos de la aplicación.
 FileView, o Visor de ficheros, que representa el proyecto mediante la lista de
ficheros fuente que lo componen.
Por último aparece también la carpeta InfoView que permite un rápido acceso a la
ayuda en línea.
Cada una de estas funcionalidades se utilizarán en función de la tarea a realizar. La

gestión y tratamiento de los recursos sólo se puede hacer mediante ResourceView,
mientras que ClassView y FileView son casi similares en cuanto a su objetivo último: el
mantenimiento del código del programa.
1. Las clases básicas para interfaz de usuario.
Representa una aplicación Windows. Cada programa debe tener un objeto global o
estático (es decir, que exista durante todo el programa) de una clase propia derivada de
CWinApp. De hecho, otra característica de la programación basada en MFC es que el
código carece de programa principal (punto inicial de ejecución como la función "main"
de C/C++ para DOS, UNIX, etc.), la ejecución comienza con la creación del objeto
CWinApp.
En realidad, es la MFC la que provee una función principal estándar WinMain (este es
el nombre que toma para las aplicaciones Windows) que utilizarán todos los programas.
Los pasos básicos que sigue son tres: inicialización del programa, entrada en el bucle de
mensajes y finalización del programa. Veámoslo más en detalle.
 Inicialización del programa. Se obtiene en dos fases distintas: inicialización de la

aplicación e inicialización de la instancia de la aplicación. Para entender esto
tenemos que tener en cuenta que los programas Windows pueden ser "multi-
instanciables", podemos tener varios ejemplares del mismo programa
ejecutándose a la misma vez. Los ejemplos mas claros son aplicaciones como el
bloc de notas (notepad) o cualquier utilidad de conexión remota (telnet). En
definitiva, si queremos obtener programas multi-instanciables tenemos que
distinguir operaciones de inicialización que servirían a todos los ejemplares y
que por tanto se deberían realizar una sola vez, de aquellas que son específicas a
cada ejemplar (como crear cada ejemplar su ventana principal).
 Bucle de mensajes. Es la parte central de la ejecución, no finaliza hasta que no
se cierra la ventana principal.
 Finalización de la instancia. Permitirá liberar recursos, cerrar ficheros de trabajo,
confirmar operaciones, etc.
Los detalles mas importantes de la clase CWinApp son los siguientes:
1. Miembros datos públicos -> Destacar:
 m_pszAppName, contiene el nombre de la aplicación.

 m_pMainWnd, contiene un puntero (referencia) a la ventana principal de la
aplicación.
 m_hInstance, identificador de la instancia del programa que se está ejecutando.
 m_hPrevInstance, identificador de la instancia previa del programa (0 si no hay
instancia previa). Sirve para saber si se deben realizar tareas de "inicialización
de aplicación" (ver arriba).
 m_lpCmdLine, línea de comando con la que se llamó al programa (argumentos).
1. Constructor CWinApp -> Recibe un sólo parámetro con el nombre de la

aplicación (por defecto llevará NULL, nulo).
1. Miembros funciones públicos -> La funcionalidad de esta clase, como siempre,

reside en funciones virtuales que se pueden redefinir; destacan las siguientes:
 InitApplication -> Invocada por el sistema automáticamente cuando se ejecuta la

primera instancia de un programa (cuando no existe instancia previa).
 InitInstance -> Invocada por el sistema para cualquier instancia del programa. Se
suelen realizar operaciones como la de creación de la ventana principal, etc.
 Run -> Que realiza el bucle de mensajes por defecto. En la mayoría de los casos
este bucle es suficiente, con lo que no tendremos por que redefinirlo.
 ExitInstance -> Invocada por el sistema después de cerrarse su ventana
principal.
Comparando el código generado para nuestra primera aplicación con lo expuesto en este
punto podemos comenzar a entender como funcionan las cosas en el mundo MFC.
2. 2 El interfaz Documento/Vista
El estándar Documento/Vista es una manera de enfocar el desarrollo de aplicaciones

para Windows. Se basa en los siguientes conceptos:
1. Documento, cualquier tipo de información que se presenta sobre una ventana,

podría ser tanto una hoja de cálculo, como una base de datos o algún tipo de
gráfico.
1. Vista (view), ventana que presenta el documento. Cada vista presenta un único
documento.
1. Ventana marco (frame window), que contiene a la ventana vista en su área

cliente.
Figura 1.- Interfaz documento/vista
De esta manera, cualquier tipo de información se puede interpretar como un documento,

que se presenta al usuario mediante una vista, que se inscribe dentro de una ventana
marco. Mientras la vista se ocupa solamente de representar el documento, la ventana

marco se puede ocupar del tratamiento del menú.
AppWizard genera todo su código basándose en este estándar. Una aplicación SDI sólo
podrá tener abierto un documento (la ventana principal es también la ventana marco),
mientras que una MDI podrá tener varios abiertos simultáneamente (aquí la ventana
principal puede contener varias marcos con vistas). Sin embargo este enfoque no es el
mas idóneo para un buen número de aplicaciones Windows SDI donde la ventana
principal no sirve sino como contenedor del menú, y la representación o el manejo de
los datos de la aplicación se suele realizar a través de diálogos. Si es sin embargo mas
útil en el caso de las aplicaciones MDI donde si que las ventanas marcos se utilizan
como formularios usuales, es decir, como ventanas para presentación de datos.
Figura 2.- Detalle de aplicación MDI
Observando la figura basada en el entorno de desarrollo de Visual C++, vemos que la

ventana principal contiene dos ventanas marcos, la primera representa en su vista el
contenido del workspace que tenemos abierto, mientras la segunda está representando
un fichero de código fuente CPP.
Las clases MFC en las que se apoya el interfaz Documento/Vista son las siguientes:
1. Clase CDocument-> funcionalidad básica para documentos de usuario. Un

documento es un objeto que almacena cualquier tipo de datos. Es una clase
abstracta de la que tendremos que derivar nuestros propios documentos.
1. Clase CView -> Ventana vista que presenta un documento. Es una ventana
"especial" que no contiene ni bordes ni título ni barra de menú, orientada a
circunscribirse dentro de otra ventana marco. Existen otras clases derivadas de
ésta que presentan mayor especialización:
 CScrollView, es una vista con soporte a las barras de scroll.

 CFormView, vista formulario, con controles al estilo de los diálogos.
 CEditView, vista orientada a la edición de textos.
 CRecordView, vista orientada a la visualización de bases de datos.
1. Clase CDocTemplate -> Clase abstracta que aporta la funcionalidad básica para
plantillas SDI o MDI. Al ser una clase abstracta no la podremos utilizar
directamente, tendremos que utilizar sus clases derivadas: CSingleDocTemplate
y CMultiDocTemplate.
1. Clase CSingleDocTemplate -> derivada de CDocTemplate representa la plantilla

de interfaz SDI. Define la relación existente entre un documento (CDocument),
una vista (CView, …) y una ventana marco que será la ventana principal.
1. Clase CMultiDocTemplate-> derivada de CDocTemplate representa la plantilla

para interfaz MDI. Define la relación entre un documento, su vista y la ventana
marco que ventana MDI hija.
Toda aplicación que se base en el Documento/Vista debe registrar en el sistema las

plantillas de documento que soporta antes de poder utilizarlas, lo que se realiza a través
de la función CWinApp::AddDocTemplate. Así, una aplicación SDI, que debe soportar
una única plantilla de documento, debe crear un objeto CSingleDocTemplate (donde se
define la relación entre documento, vista y ventana marco) y registrarlo mediante el
método anterior. Una vez realizado esto bastará con invocar la función
CDocTemplate::OpenDocumentFile() del objeto recién creado para conseguir que se
visualice la ventana principal de la aplicación, con su vista presentando el documento
especificado (el enfoque en aplicaciones MDI es algo distinto y se revisará
posteriormente). Estas operaciones se introducirán dentro del InitInstance de la
aplicación.
De todas maneras, en contra de lo que hemos dicho antes, no es difícil adaptar cualquier
aplicación al protocolo requerido por el interfaz documento vista, sin mucho impacto en
la misma, gracias a que la mayoría de las funcionalidades están predefinidas por
defecto.
7. 2. 3. La ventana básica CWnd
Es una de las clases más importantes de la MFC ya que contiene las funcionalidades
básicas de todas las clases de ventanas Windows. Como siempre, al ser una abstracción,
no está muy orientada a la utilización directa, mas bien siempre tenderemos a utilizar
alguna de sus clases derivadas, mas especializadas, como CFrameWindow (ventana
principal de aplicación) o CDialog (para ventanas de diálogo).
Pero su principal interés reside en que es la clase responsable del funcionamiento del
mecanismo de paso de mensajes de Windows. Éste queda oculto por lo que se llama en
la MFC mapa de mensajes. El mapa de mensajes de una clase de ventana recoge la
asociación entre el mensaje recibido del sistema y la función que se ejecutará como
respuesta. Todas estas funciones de respuesta (métodos de clase) son funciones virtuales
que por tanto se pueden redefinir en todas las clases derivadas.
Supongamos que estamos construyendo una aplicación la cual queremos que antes de
finalizar descargue cierto contenido de memoria en un fichero. Para ello deberíamos ser
capaces de contestar adecuadamente al mensaje WM_CLOSE que el sistema manda a la
ventana principal cuando se tiene que cerrar. El mapa de mensajes de la clase CWnd
especifica que la función de respuesta será CWnd::OnClose(). Bastará entonces con que
en nuestra clase ventana principal redefinamos una nueva versión de esa función
heredada. No hace falta que conozcamos de memoria todo el mapa de mensajes por
defecto de CWnd (nombres de las funciones de respuesta, etc.), la utilización de
AppWizard automatiza todo este complejo tratamiento.
Los miembros datos y miembros funciones de esta clase son muy numerosos y variados,
los iremos comentando según los vayamos utilizando.
7. 2. 4. Una ventana principal - CFrameWnd

Derivando de CWnd, proporciona las funcionalidades básicas de cualquier ventana

principal de aplicación. Incluye soporte de menús, barras de estado y barra de
herramientas. Las aplicaciones SDI derivarán de esta clase sus ventanas principales.
Entre sus características incluye título, menú de sistema y borde redimensionable.
De sus miembros funciones destacan:
 Create -> Función que permite crear una ventana física y asociarla con el objeto
recién creado.
7. 2. 5. Las clases Vista
Como ya hemos comentado, la clase CView proporciona la funcionalidad básica para

ventanas que se asocian a plantillas de documentos y que realizan tareas de
intermediarias entre el documento y el usuario. Es la responsable de presentar la imagen
del documento y de interpretar las acciones del usuario sobre el mismo (modificaciones,
etc.). Entre estas funcionalidades cabe destacar:
Las vistas mas especializadas se encuentran entre las siguientes clases derivadas:
 CEditView, donde la vista es una ventana de edición de texto.

 CListView, donde la vista es una lista.
 CFormView, donde la vista utiliza una plantilla de diálogo de los recursos de la
aplicación (al estilo de los formularios tradicionales).
 CRecordView, derivando de CFormView implementa además soporte para
bases de datos, permitiendo asociar estáticamente campos de tablas con
controles de la plantilla de diálogo que utiliza.
7. 3 Clases básicas de propósito general.
Presentaremos a continuación algunas de las clases de propósito general mas

importantes y utilizadas de la MFC.
7. 3. 1 La clase CString
La clase CString representa un string de caracteres. Cualquier programador de C/C++

sabe lo tedioso que puede ser el manejo de este tipo de dato ya que no está reconocido
como tal en el núcleo de C. Mientras que en otros lenguajes de alto nivel el string de
caracteres es un tipo de dato autónomo que dispone de sus propios operadores
(asignación, concatenación, comparación, etc.), en C/C++ el string se representa como
una colección (array) de caracteres (que el tipo de dato básico), esto supone que
cualquier operación sobre ellos se debe realizar mediante funciones de la librería
estándar de C (strcpy, strcat, strcmp, etc.).
La principal virtud de CString es precisamente esa, facilita el manejo de strings de

caracteres automatizando todo el tratamiento óptimo de la memoria. Destacan las
siguientes funcionalidades:
 Función CString::GetLength, que permite conocer el número de caracteres que

contiene.
 Funciones CString::GetAt/CString::SetAt, que permiten acceder y modificar
respectivamente el carácter del string que aparece en una posición dada.
 Funciones CString::MakeUpper/CString::MakeLower, que permiten convertir a
mayúsculas/minúsculas respectivamente.
 Función CString::Find, que permite conocer si un determinado string o carácter
aparece dentro de otro string.
Pero además, la clase CString tiene sobrecargados algunos de los operadores de C/C++
lo que permite un manejo intuitivo de esta clase, son los siguientes: asignación
(mediante =), concatenación (mediante + y +=) y comparación (operadores ==, <, <=,
etc.).
8. 2. Objetos capaces de gestionar mensajes de comando de menú.
En la MFC tanto el objeto aplicación CWinApp como cualquier ventana (objetos

CWnd y derivados) es capaz de recibir mensajes de comando procedentes del
menú de la aplicación. Aunque de alguna forma lo mas "real" es que la ventana
sea la encargada de gestionarlos (ya que es la propietaria del menú y además en
la programación SDK de Windows, la aplicación no tiene entidad como tal y son
solamente las ventanas los elementos capaces de recibir mensajes del sistema,
mediante su ya conocido procedimiento de ventana) si que es verdad que la
elección siempre depende del programador. Todo esto quiere decir que mediante
ClassWizard podemos asociar un comando del menú con una función miembro
de un objeto aplicación.
De cualquier manera lo que siempre es una práctica aconsejable es centralizar

todas las funciones de respuesta (también conocidas como manejadores de
mensajes) dentro de una misma clase.
7. 1. Gestión de mensajes de comandos del menú.

8. GESTIÓN DE DIÁLOGOS
Las ventanas de diálogos son uno de los elementos mas utilizados para la interacción
con el usuario. De manera general un diálogo es una ventana especial que contiene en su
interior ventanas hijas que son controles (botones, listas, cajas de edición, listas
desplegables, …) identificados por un número único, además, cuando un diálogo se
despliega, se convierte en una ventana exclusiva en el sentido de que deja inhabilitada
cualquier operación con el resto de la aplicación (este efecto se conoce realmente con el
nombre de diálogos modales, aunque existe la posibilidad de crear también diálogos no
modales). Las plantillas de estos diálogos pueden diseñarse mediante herramientas
integradas en el entorno de desarrollo como es el ya conocido ResourceView (también
conocido como taller de recursos).
Es la clase CDialog, derivada de CWnd, la responsable de proporcionar las

funcionalidades básicas de esta ventana especializada.
 El constructor de la clase CDialog::CDialog, requiere dos parámetros: el nombre

de la plantilla de diálogo que utilizará (la que hayamos diseñado en los recursos)
y una referencia a la ventana padre del diálogo (casi siempre es la ventana que
pide que se visualice). También existe un constructor por defecto (sin
parámetros) orientado a la creación de diálogos no modales.
 La función CDialog::DoModal, aplicada sobre un objeto construido previamente
permite visualizarlo en modo modal. Esta función es síncrona en el sentido de
que no devuelve el control a la función llamante hasta que no se cierre el
diálogo. Devuelve un valor que podemos utilizar para indicar distintas opciones
de cierre del diálogo (por ejemplo podemos devolver TRUE para indicar que se
presionó OK o FALSE para Cancelar).
 La función CDialog::EndDialog permite finalizar un diálogo modal, recibe un
parámetro que se corresponderá con el valor que devuelva DoModal.
 La función CDialog::Create, aplicada sobre un objeto construido previamente,
permite crear diálogos no modales. Los diálogos no modales no se finalizan con
EndDialog sino que utilizaremos la función estándar heredada de CWnd
DestroyWindow.
 Función CDialog::OnInitDialog, para inicializar el diálogo.
 Funciones CDialog::OnOk/CDialog::OnCancel que permiten realizar las
operaciones de confirmación o cancelación del objetivo del diálogo.
Pero CDialog es una clase abstracta, por lo que no la podremos utilizar directamente (no
se pueden crear objetos CDialog). El programador deberá derivar sus propias clases
desde CDialog para crear sus propios diálogos.
1. Creación de diálogos
Los pasos para crear una ventana de diálogo son los siguientes:
1. Crear la plantilla de diálogo que se va a utilizar en el fichero de recursos. Para

ello utilizaremos ResourceView y las herramientas de diseño de diálogos. El
diálogo se podrá completar con los controles necesarios (cajas de edición, listas,
botones, etc.). Cada uno de los controles deberá llevar un identificador único.
1. Asignar un identificador a la plantilla de diálogo que se haya diseñado.
1. Invocar ClassWizard
1. Seleccionar botón "Añadir clase nueva"
1. Definir la nueva clase. Para ello le daremos un nombre y seleccionaremos la

clase base más adecuada. En este caso seleccionaremos la clase CDialog. El
sistema automáticamente asignará un nombre a los ficheros de cabecera e
implementación donde se codificará la clase (estos nombres los podemos
cambiar). Aparece una lista desplegable donde seleccionaremos el identificador

de la plantilla de diálogo asociado (especificado en el paso 2).
El sistema genera entonces el esqueleto de la nueva clase, en los ficheros especificados,

añadiéndolos al proyecto. Bastará con completar el código generado e introducir una
llamada al diálogo en algún punto del programa (mediante la función
CDialog::DoModal por ejemplo).
1. Tratamiento de los controles de diálogos.
La librería MFC aporta también clases representativas de los controles típicos de

Windows. Esto nos permite crearlos de manera dinámica (mediante código) o
manejarlos adecuadamente. De entre estas clases, destacan:
 CButton, representa cualquier tipo de botones (pushbuttons, radio buttons o

check boxes).
 CComboBox, representa listas desplegables.
 CListBox, representa listas.
 CEdit, representando cajas de edición.
 CStatic, representando texto estáticos.
Cada una de estas clases deriva de CWnd (no en vano son todas ventanas
especializadas) e incorpora funciones específicas que facilitan su tratamiento (así por
ejemplo las listas aportan funciones que permiten saber el elemento que tiene
seleccionado en cada momento).
Aunque un control puede aparecer dentro de cualquier ventana (se dice que el control es
una ventana hija) es en los diálogos donde mas se utilizan. De manera general, la
ventana padre debe ser capaz de manejar los controles que la forman (rellenando una
lista con las opciones disponibles, presentando el DNI del empleado seleccionado en la
caja de edición al efecto, etc.). Para conseguir esto disponemos de dos métodos:
1. Asociación estática de controles. Este método consiste en la creación de

objetos miembros de la clase de la ventana padre (el diálogo) y su asociación
con cada uno de los controles. Es decir, existe una variable miembro dentro del
diálogo que representa cada uno de los controles. De manera general no se
"mapearán" todos los controles a variables sino sólo aquellos que necesitemos
(aquellos que vayamos a manejar en el programa). Este trabajo se realiza
mediante ClassWizard dentro de su "subcarpeta" marcada como "Variables". Así
un botón se mapea a un objeto CButton, una lista a un objeto CListBox, etc.
1. Asociación dinámica de controles. Mediante este método se consiguen

referencias a los controles durante la ejecución del programa. No existen
variables miembro que se asocien a controles de manera estática (constante) sino
que conseguimos el mismo efecto cuando lo necesitamos. Para ello disponemos
de la función de ventana CWnd::GetDlgItem que recibe como parámetro el
identificador del control del que queremos obtener una referencia. Hay que
destacar que esta función es de la ventana básica CWnd, lo que significa que
cualquier ventana puede acceder a sus ventanas hijas (controles generalmente)
de la misma manera (abstracción). Además, mediante esa función obtenemos
referencias a objetos de distintas clases en función del tipo de control que
queramos, es decir, utilizamos la misma función para acceder a botones, listas o
cajas de edición. En realidad la función GetDlgItem devuelve referencias a
ventanas genéricas (devuelve punteros a CWnd *) o lo que es lo mismo,
devuelve referencias a cualquier tipo de ventana (no tiene por que ser controles).
1. De manera análoga a lo que comentamos con los items de menú, los controles
informan a las ventanas padres de las acciones que el usuario realiza sobre ellos.
Así los botones informan de que se hizo "click" sobre ellos o las cajas de edición
lo hacen de que se modificó su contenido. El mecanismo utilizado es también el
mensaje de comando WM_COMMAND aunque aquí tiene un enfoque
adicional.
Mientras los elementos de menú sólo informan de que han sido seleccionados
los controles pueden informar de distintos eventos (dependiendo del tipo de
control), así siempre es distinto realizar un click sobre una lista que un doble
click. En definitiva, los mensajes de comando de los controles de diálogos
incorporan una nueva información que se conoce como notificación. Las
notificaciones recogidas por cada tipo de control son distintas, dependiendo de
su naturaleza.
La forma de añadir funciones manejadoras de mensajes de controles a los

diálogos es análoga a la que se describió para los comandos de menú. Lo
realizaremos mediante ClassWizard, pero además de seleccionar el identificador
del control tendremos que seleccionar también la notificación a la que queremos
añadir el nuevo manejador.
2. Mensajes de comando de controles de diálogos.
Una vez que hemos visto como obtener un vínculo con los controles que forman
un diálogo hemos de conocer como inicializarlo para que presente al usuario el
aspecto seleccionado. El momento de inicialización del diálogo viene marcado
por la llegada del mensaje WM_INITDIALOG, cuyo manejador virtual es
CDialog::OnInitDialog. En nuestra clase de ventana de diálogo redefiniremos
esta función virtual para definir nuestra propia inicialización.
Estos diálogos están compuestos por una serie de páginas (subcarpetas), que vienen
representadas en la MFC mediante la clase CPropertySheet. Cada una de estas páginas
es básicamente un diálogo de estilos especiales, pero cuentan con su plantilla
correspondiente en el fichero de recursos del proyecto.
Para construir diálogos de este tipo seguiremos los siguientes pasos:
1. Generar las páginas necesarias. Para ello necesitamos diseñar las plantillas de
cada una de ellas en los recursos, y añadir una clase derivada de CPropertyPage
que las represente (de manera análoga a como se vio en el punto 9.1)
1. Añadir una clase derivada de CPropertySheet al proyecto mediante ClassWizard.
1. Asociar a esta clase las páginas correspondientes. Se realiza mediante la función

miembro CPropertySheet::AddPage, que recibe como parámetro una referencia
a la clase CPropertyPage a añadir. Estas operaciones se suelen realizar dentro
del constructor del propio objeto.
1. Crear un objeto de esa clase e invocar la función CPropertySheet::DoModal

7. EL INTERFAZ MDI
El interfaz de documento múltiple es sensiblemente distinto al ya conocido de

documento simple (SDI) en el que nos hemos basada en las exposiciones previas. Las
aplicaciones MDI pueden tener abiertas simultáneamente varias ventanas marco,
conteniendo vistas que visualizan documentos. Las diferencias principales son las
siguientes:
 La ventana principal de la aplicación derivará de CMDIFrameWnd, y su

objetivo principal no es contener una vista como ventana cliente (según el
modelo SDI) sino controlar y gestionar las ventanas marcos existentes.
 Como ventana cliente de la ventana principal aparece la clase de ventana
MDICLIENT. Esta es la verdadera ventana padre de las sucesivas ventanas
marco que se vayan abriendo. La MFC no contempla ninguna clase que
represente este tipo de ventanas ya que su comportamiento por defecto es
totalmente suficiente y estándar. De hecho, a primera vista puede quedar oculta
la existencia de esta ventana cliente ya que en ningún momento necesitamos
crearla (la crean las funciones por defecto).
 Las ventanas marcos derivarán de CMDIChildWnd y son "hijas" de la ventana
MDICLIENT de la ventana principal de la aplicación (recordar que en el modelo
SDI la ventana principal era a su vez ventana marco de documento).
La utilización del modelo SDI o MDI dependerá siempre de los requisitos de nuestra
aplicación, de todas maneras el funcionamiento de ambos modelos es muy similar en su
concepción y tratamiento gracias a las abstracciones prestadas por la MFC.
7. CLASES ORIENTADAS A ACCESO A BASES DE DATOS
La MFC proporciona clases que proveen un interfaz de alto nivel para el tratamiento de
bases de datos. Para ello se basa en dos mecanismos distintos pero de funcionamiento y
tratamiento muy similar:
1. El término ODBC (Open Data Base Conectivity) indica que su objetivo es

conseguir un tratamiento estándar para distintos sistemas gestores de bases de
datos (SGBD). Su funcionamiento se basa en el uso de drivers. Estos drivers

proveen un interfaz estándar de programación, ocultando los detalles internos de
funcionamiento de cada SGBD. El estándar ODBC está muy extendido, proveen
una librería de funciones C (el API o SDK de ODBC) que se basa en un SQL
estándar como lenguaje de consulta utilizado, de manera que podemos acceder
con el mismo método a tablas dBase, Oracle o Informix (…) sin mas que
disponer del driver ODBC apropiado para cada SGBD.
Para utilizar una base de datos mediante ODBC entra en juego lo que se
denomina Origen de datos (DSN - Data source name). Un origen de datos es una
entidad identificada por su nombre que especifica una base de datos concreta,
mediante ese DSN podremos acceder a cualquier tabla de dicha base de datos.
La definición de los DSN se consigue gracias al Administrador ODBC que se
suele encontrar dentro del Panel de Control de Windows (puede que
encontremos instalaciones en las que no aparezca referencias al ODBC ya que es
una extensión de Windows no estándar, aunque en la actualidad es instalado por
la mayoría de los SGBD mas comerciales).
2. Tratamiento mediante ODBC
El modelo DAO (Data Access Object) es una extensión del ODBC que está
especializada y optimizada para el acceso a bases de datos de Microsoft Access.
DAO ha sido incorporado a la MFC en la última versión comercializada, ya que
antes el tratamiento de bases de datos Access estaba integrado dentro del propio
ODBC.
Dado que el funcionamiento es totalmente análogo (aunque las clases DAO

tienen tratamientos y capacidades específicas) pero siendo ODBC un método
mucho mas general, nos centraremos en el uso de este último para el desarrollo
de este capítulo, realizando el paralelismo oportuno con el modelo DAO cuando
sea necesario.
3. Tratamiento mediante DAO
Dos son los conceptos que se utilizan en el tratamiento de bases de datos

mediante MFC: la base de datos (conjunto de tablas) y el recordset (conjunto de
registros de una tabla). Son representados mediante las clases CDatabase y
CRecordset.
En la mayoría de los casos el trabajo se realizará sin la necesidad de trabajar al nivel de

CDatabase, ya que la mayoría de las aplicaciones se limitan a consultar y modificar
registros de tablas, operaciones que se realizan al nivel de CRecordset. Sólo en el caso
de que nuestra aplicación tenga requisitos de mantenimiento de la base de datos
(añadir/modificar/borrar tablas, gestión de permisos, usuarios…) necesitaremos trabajar
al nivel de CDatabase, en cuyo caso bastará con crear un objeto de esa clase, abrirlo,
operar sobre él y cerrarlo; en ningún caso necesitaremos derivar de CDatabase nuestras
propias clases para bases de datos.
El análogo de CDatabase en el mundo DAO es CDaoDatabase.
La creación de los recordsets necesarios se realizará mediante ClassWizard. Para ello

procederemos a añadir una nueva clase al proyecto, en el momento de especificar la
clase base seleccionaremos CRecordset. Tras confirmar la operación el sistema nos
pedirá que seleccionemos el DSN del origen de datos ODBC (para lo que debe haber
sido definido previamente en el administrador de ODBC). Una vez realizado esto
aparecerá una lista con el nombre de todas las tablas que forman la base de datos
asociada al DSN seleccionado. Escogeremos una de ellas que se asociará al nuevo
objeto recordset. El sistema como siempre crea un esqueleto de la nueva clase que
incluye, entre otras cosas, un constructor por defecto y la definición de la conexión a la
tabla (en la función CRecordset::GetDefaultConnect). Además, esta clase incorpora un
miembro dato por cada uno de los campos de la tabla asociada, datos que serviremos
para almacenar los valores del registro actual en cada momento. Estas variables se
mapean a cada campo, relación que se define en el cuerpo de la función
CRecordset::DoFieldExchange. Esta función es implementada por ClassWizard y solo
en algunos casos tendremos que modificarla (los veremos a continuación). Podemos
destacar dos tipos de recordsets distintos:
 Tipo Snapshot, donde el recordset es una vista estática del contenido de la tabla
en el momento de su apertura. Cualquier modificación sobre la misma no se
reflejaría en el recordset hasta que no volviese a abrirse.
 Tipo Dynaset, donde se representa una visión dinámica de las tablas. Es más
utilizado aplicaciones que trabajan sobre bases de datos multiusuario o
compartidas, donde otras aplicaciones pueden realizar modificaciones.
Para utilizar un determinado recordset bastará con crear un objeto de esa clase, rellenar
la información de la consulta en m_strFilter (si no va relleno se recuperarían todos los
registros de la tabla), la información de ordenación en m_strSort (opcional) y llamar a la
función Open que realiza la consulta apropiada. Cuando el recordset haya dejado de
utilizarse invocaremos la función Close que libera los recursos de la conexión ODBC.
1. Manejo de excepciones mediante CDBException
Cuando trabajamos con bases de datos se pueden producir situaciones anómalas que
provocan errores de ejecución de las aplicaciones. Por ejemplo, el intento de abrir una
determinada tabla que ha sido abierta previamente por otro usuario de modo exclusivo,
o invocar la función de pasar al siguiente registro cuando ya se ha alcanzado el último
del recordset, son casos que provocarán una finalización anómala del programa.
El concepto de excepción permite capturar estas situaciones especiales antes de que se

produzca el error fatal, avisar al usuario y continuar con la ejecución del programa
dentro de lo posible.
De manera general, una excepción se puede producir dentro del ámbito de cualquier
función sin necesidad de que se estén manejando en ella recordsets o bases de datos. La
clase abstracta CException, representa este concepto.
Cada una de estas clases incorpora funcionalidades propias, pero su utilización es muy
similar, por lo que nos centraremos sobre CDBException que nos ocupa ahora.
La forma de utilizar las excepciones es como sigue: tenemos que encapsular la

operación que pueda producir la excepción dentro de un bloque TRY/CATCH, que de
manera general tiene el siguiente formato.
TRY
Operación que puede producir excepción…
CATCH(Clase de excepción a capturar, objeto asociado)
Operaciones de recuperación de la excepción …
La rama donde se encuentran las operaciones de recuperación de la excepción sólo se

ejecutará en el caso de que se produzca una excepción de la clase especificada en la
sentencia CATCH, entonces el objeto que le acompaña tomará los valores que
identifican dicha excepción. Más en concreto, para el caso de CDBException, el
ejemplo sería algo así:
CEmpleadosSet e;
e.m_strFilter = "DEPARTAMENTO = ‘VENTAS’";
TRY
e.Open();
CATCH(CDBException, e)
END_CATCH
Los objetos
Para crear un objeto de una clase se usa la palabra reservada new.
Por ejemplo,
Rectangulo rect1=new Rectangulo(10, 20, 40, 80);
new reserva espacio en memoria para los miembros dato y devuelve una referencia que
se guarda en la variable rect1 del tipo Rectangulo que denominamos ahora objeto.
Dicha sentencia, crea un objeto denominado rect1 de la clase Rectangulo llamando al
segundo constructor en el listado. El rectángulo estará situado en el punto de
coordenadas x=10, y=20; tendrá una anchura de ancho=40 y una altura de alto=80.
Rectangulo rect2=new Rectangulo(40, 80);
Crea un objeto denominado rect2 de la clase Rectangulo llamando al tercer constructor,

dicho rectángulo estará situado en el punto de coordenadas x=0, y=0; y tendrá una
anchura de ancho=40 y una altura de alto=80.
Rectangulo rect3=new Rectangulo();
Crea un objeto denominado rect3 de la clase Rectangulo llamando al primer

constructor, dicho rectángulo estará situado en el punto de coordenadas x=0, y=0; y
tendrá una anchura de ancho=0 y una altura de alto=0.
Acceso a los miembros
Desde un objeto se puede acceder a los miembros mediante la siguiente sintaxis
objeto.miembro;
Por ejemplo, podemos acceder al miembro dato ancho, para cambiar la anchura de un
objeto rectángulo.
rect1.ancho=100;
El rectángulo rect1 que tenía inicialmente una anchura de 40, mediante esta sentencia se
la cambiamos a 100.
Desde un objeto llamamos a la función miembro para realizar una determinada tarea.
Por ejemplo, desde el rectángulo rect1 llamamos a la función calcularArea para calcular
el área de dicho rectángulo.
La clase
Para crear una clase se utiliza la palabra reservada class y a continuación el nombre de
la clase. La definición de la clase se pone entre las llaves de apertura y cierre. El nombre
de la clase empieza por letra mayúscula.
class Rectangulo{
//miembros dato
//funciones miembro
Los miembros dato
Los valores de los atributos se guardan en los miembros dato o variables de instancia.
Los nombres de dichas variables comienzan por letra minúscula.
Vamos a crear una clase denominada Rectangulo, que describa las características
comunes a estas figuras planas que son las siguientes:
 El origen del rectángulo: el origen o posición de la esquina superior izquierda

del rectángulo en el plano determinado por dos números enteros x e y.
 Las dimensiones del rectángulo: ancho y alto, otros dos números enteros.
Las funciones miembro
En el lenguaje C++ la función miembro se declaran, se definen y se llaman. En el

lenguaje Java la función miembro o métodos solamente se definen y se llaman.
El nombre de las funciones miembro o métodos comieza por letra minúscula y deben
sugerir acciones (mover, calcular, etc.). La definición de una función tiene el siguiente
formato:
tipo nombreFuncion(tipo parm1, tipo parm2, tipo parm3){
//...sentencias
Entre las llaves de apertura y cierre se coloca la definición de la función. tipo indica el
tipo de dato que puede ser predefinido int, double, etc, o definido por el usuario, una
clase cualquiera.
Para llamar a un función miembro o método se escribe
retorno=objeto.nombreFuncion(arg1, arg2, arg3);
Cuando se llama a la función, los argumentos arg1, arg2, arg3 se copian en los
parámetros parm1, parm2, parm3 y se ejecutan las sentencias dentro de la función. La
función finaliza cuando se llega al final de su bloque de definición o cuando encuentra
una sentencia return.
Cuando se llama a la función, el valor devuelto mediante la sentencia return se asigna a

la variable retorno.
Cuando una función no devuelve nada se dice de tipo void. Para llamar a la función, se
escribe
objeto.nombreFuncion(arg1, arg2, arg3);
Estudiaremos más adelante con más detalle cómo se definen las funciones.
Una función suele finalizar cuando llega al final del bloque de su definición
void funcion(....){
//sentencias...
Una función puede finalizar antes del llegar al final de su definición
Una función puede devolver un valor (un tipo de dato primitivo o un objeto).
double funcion(....){
double suma=0.0;
//sentencias...
return suma;
//...
La función que determina si un punto está o no en el interior del rectángulo, devolverá

true si el punto se encuentra en el interior del rectángulo y devolverá false si no se
encuentra, es decir, será una función del tipo boolean. La función necesitará conocer las
coordenadas de dicho punto. Para que un punto de coordenadas x1 e y1 esté dentro de
un rectángulo cuyo origen es x e y, y cuyas dimensiones son ancho y alto, se deberá
cumplir a la vez cuatro condiciones
x1>x y a la vez x1<x+ancho
También se debe cumplir
y1>y y a la vez y1<y+alto
Como se tienen que cumplir las cuatro condiciones a la vez, se unen mediante el
operador lógico AND simbolizado por &&.
En el lenguaje Java, si la primera condición es falsa no se evalúan las restantes

expresiones ya que el resultado es false. Ahora bien, si la primera es verdadera true, se
pasa a evaluar la segunda, si ésta el falsa el resultado es false, y así sucesivamente.
Los constructores
Un objeto de una clase se crea llamando a una función especial denominada constructor
de la clase. El constructor se llama de forma automática cuando se crea un objeto, para
situarlo en memoria e inicializar los miembros dato declarados en la clase. El
constructor tiene el mismo nombre que la clase. Lo específico del constructor es que no
tiene tipo de retorno.
El constructor recibe cuatro números que guardan los parámetros x1, y1, w y h, y con
ellos inicializa los miembros dato x, y, ancho y alto.
Una clase puede tener más de un constructor. Por ejemplo, el siguiente constructor crea
un rectángulo cuyo origen está en el punto (0, 0).
Con estas porciones de código definimos la clase, y la guardamos en un archivo que

tenga el mismo nombre que la clase Rectangulo y con extensión .java.
La vida de un objeto
En el lenguaje C++, los objetos que se crean con new se han de eliminar con delete.
new reserva espacio en memoria para el objeto y delete libera dicha memoria. En el
lenguaje Java no es necesario liberar la memoria reservada, el recolector de basura
(garbage collector) se encarga de hacerlo por nosotros, liberando al programador de una
de las tareas que más quebraderos de cabeza le producen, olvidarse de liberar la
memoria reservada.
Veamos un ejemplo
public class UnaClase {
public static void main(String[] args) {
Image granImagen=creaImagen();
mostrar(graImagen);
while(condicion){
calcular();
El objeto granImagen, continua en memoria hasta que se alcanza el final de la función

main, aunque solamente es necesario hasta el bucle while. En C o en C++
eliminariamos dicho objeto liberando la memoria que ocupa mediante delete
Identificadores
Cómo se escriben los nombres de las variables, de las clases, de las funciones, etc., es
un asunto muy importante de cara a la comprensión y el mantenimiento de código. En la
introducción a los fundamentos del lenguaje Java hemos tratado ya de los
identificadores.
El código debe de ser tanto más fácil de leer y de entender como sea posible. Alguien
que lea el código, incluso después de cierto tiempo, debe ser capaz de entender lo que
hace a primera vista, aunque los detalles internos, es decir, cómo lo hace, precise un
estudio detallado.
Las abreviaciones empleadas solamente tienen significado para el programador en el

momento de escribir el código, ya que puede olvidarse de su significado con el tiempo.
Otros programadores del grupo tienen que descifrar el significado del nombre de cada
variable o de cada función. El tiempo extra que se gasta en escribir con claridad el
nombre de los diversos elementos que entran en el programa, se ahorra más adelante
durante su desarrollo, depuración, y mejora, es decir, durante todo el ciclo de vida del
programa.
public class CuentaBancaria{
private int balance;
CuentaBancaria(int balance){
this.balance=balance;
public void depositar(int cantidad){
balance+=cantidad;
}
public boolean retirar(int cantidad){
if(balance>=cantidad){
balance-=cantidad;
return true;
return false;
public int obtenerBalance(){
return balance;
Este es un programa sencillo de una cuenta bancaria. El tipo de dato puede ser entero
(int o long), si la unidad monetaria tiene poco valor como la peseta, o un número
decimal (double) si la unidad monetaria es de gran valor como el Euro y el Dólar.
El código de las funciones miembro es muy sencillo y su significado se hace evidente al

leer el programa. La función retirar es de tipo boolean, ya que no (false) estamos
autorizados a retirar una cantidad mayor que la existente en ese momento en el banco.
Sin embargo, si (true) estamos autorizados a retirar una cantidad menor que la que
tenemos en la cuenta.
Atributos
Los atributos son las características individuales que diferencian un objeto de otro y
determinan su apariencia, estado u otras cualidades. Los atributos se guardan en
variables denominadas de instancia, y cada objeto particular puede tener valores
distintos para estas variables.
Las variables de instancia también denominados miembros dato, son declaradas en la

clase pero sus valores son fijados y cambiados en el objeto.
Además de las variables de instancia hay variables de clase, las cuales se aplican a la
clase y a todas sus instancias. Por ejemplo, el número de ruedas de un automóvil es el
mismo cuatro, para todos los automóviles.
Comportamiento
El comportamiento de los objetos de una clase se implementa mediante funciones

miembro o métodos. Un método es un conjunto de instrucciones que realizan una
determinada tarea y son similares a las funciones de los lenguajes estructurados.
Del mismo modo que hay variables de instancia y de clase, también hay métodos de
instancia y de clase. En el primer caso, un objeto llama a un método para realizar una
determinada tarea, en el segundo, el método se llama desde la propia clase.
UNIDAD N° 2
PROGRAMACION ORIENTADA A OBJETOS EN VISUAL BASIC
OBJETIVO; Adquirir destrezas básicas en el manejo de este lenguaje
¿Qué es Visual Basic?
Es un programa que es en sí mismo un Lenguaje de Programación de alto nivel, con el

cual se pueden desarrollar aplicaciones para cualquier necesidad, ya sea de un usuario o
de una empresa.
 Curso de Programacion VB6 Curso con Certificado Universitario de

Programacion en Visual Basic 6
www.Aprender21.com/Visual_BasicEnlaces patrocinados
Inicio de Visual Basic

Cómo empezar a trabajar con Microsoft Visual Basic:
1. Haz clic en el botón Inicio.
2. Señala Programas.
3. Haz clic en Microsoft Visual Studio 6.0, Microsoft Visual Basic 6.0.
Después de unos segundos de carga y una pantalla de presentación se presentará la

pantalla de opciones de proyecto.
De manera predeterminada viene seleccionado el icono Standard EXE, haz clic en

Abrir.
Enseguida podemos ver el área de trabajo de Visual Basic.
Los componentes principales son:
Menús (listas de acciones que puedes hacer en Visual Basic) Barras de herramientas
(para realizar las mismas acciones en menos tiempo)
Formulario (son las ventanas principales de toda aplicación creada con Visual Basic)
Explorador del Proyecto (desde aquí se puede acceder a los componentes del proyecto)
Ventana de Propiedades (de cada control podemos definir sus atributos o propiedades
particulares que determinan su apariencia y comportamiento)
Caja de herramientas (aquí aparecen los diversos controles que se pueden usar)
Para colocar un control en el formulario
Haz clic sobre el control que deseas colocar en el formulario. Colócate sobre el
formulario en donde colocarás el control. Presiona el botón izquierdo del ratón y dibuja
sobre el formulario el control hasta que obtenga la forma y el tamaño que prefieras,
entonces suelta el botón.
Abstract
El diseño de interfaces de usuario es una tarea que ha adquirido relevancia en el

desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los
motivos que conduzca a un sistema al éxito o al fracaso. Los principios que se presentan
son de utilidad para creación de interfaces funcionales y de fácil operación. A pesar de
no ser capaces de resolver todos los aspectos propios del contexto con el que se esté
trabajando, pueden ser combinados con la prototipación y la aplicación de heurísticas de
evaluación para facilitar el proceso de diseño. El presente artículo se centra en los
componentes de software de las interfaces de usuario, quedando fuera del alcance de
mismo otros aspectos, como hardware y documentación. Lo anteriormente expuesto se
complementa con un caso práctico de diseño de interfaces de usuario, producto de
realizar la actividad de "Definición de Interfaces de Usuario" (EFS 4) de la metodología
Métrica Versión 2.
Key words: evaluation, heuristics, principles, prototypes, user interfaces.
1. Conceptos Generales
La Interfaz de Usuario, en adelante IU, de un programa es un conjunto de elementos

hardware y software de una computadora que presentan información al usuario y le
permiten interactuar con la información y con el computadora. También se puede
considerar parte de la IU la documentación (manuales, ayuda, referencia, tutoriales) que
acompaña al hardware y al software.
Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si

no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a
culparse a sí mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos, desde
principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los
usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de
interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los
programas y sistemas operativos ofrecen varias formas de interacción al usuario.
Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el
del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo
mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la
misma, desarrollados a través de su experiencia.
El modelo permite explicar o predecir comportamientos del sistema y tomar las

decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción
con las computadoras, de ahí su importancia.
Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que éste
se comporte de una cierta forma. Se puede conocer el modelo del usuario estudiándolo,
ya sea realizando tests de usabilidad, entrevistas, o a través de una realimentación. Una
interfaz debe facilitar el proceso de crear un modelo mental efectivo.
Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya
conocido por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la
mayoría de las interfaces gráficas actuales.
Modelo del diseñador: El diseñador mezcla las necesidades, ideas, deseos del usuario y
los materiales de que dispone el programador para diseñar un producto de software. Es
un intermediario entre ambos.
El modelo del diseñador describe los objetos que utiliza el usuario, su presentación al
mismo y las técnicas de interacción para su manipulación. Consta de tres partes:
presentación, interacción y relaciones entre los objetos (Figura 1).
La presentación es lo que primero capta la atención del usuario, pero más tarde pasa a
un segundo plano, y adquiere más importancia la interacción con el producto para poder
satisfacer sus expectativas. La presentación no es lo más relevante y un abuso en la
misma (por ejemplo, en el color) puede ser contraproducente, distrayendo al usuario.
La segunda parte del modelo define las técnicas de interacción del usuario, a través de
diversos dispositivos.
La tercera es la más importante, y es donde el diseñador determina la metáfora

adecuada que encaja con el modelo mental del usuario. El modelo debe comenzar por
esta parte e ir hacia arriba. Una vez definida la metáfora y los objetos del interfaz, los
aspectos visuales saldrán de una manera lógica y fácil.
Figura 1. Representación del modelo del diseñador: el look-and-feel iceberg, de IBM

(1992)
Estos modelos deben estar claros para los participantes en el desarrollo de un producto,
de forma que se consiga una interfaz atractiva y a la vez efectiva para el trabajo con el
programa.
Una interfaz no es simplemente una cara bonita; esto puede impresionar a primera vista
pero decepcionar a la larga. Lo importante es que el programa se adapte bien al modelo
del usuario, cosa que se puede comprobar utilizando el programa más allá de la primera
impresión.
Modelo del programador: Es el más fácil de visualizar, al poderse especificar

formalmente. Está constituido por los objetos que manipula el programador, distintos de
los que trata el usuario (ejemplo: el programador llama base de datos a lo que el usuario
podría llamar agenda). Estos objetos deben esconderse del usuario.
Los conocimientos del programador incluyen la plataforma de desarrollo, el sistema

operativo, las herramientas de desarrollo y especificaciones. Sin embargo, esto no
significa necesariamente que tenga la habilidad de proporcionar al usuario los modelos
y metáforas más adecuadas. Muchos no consideran el modelo del usuario del programa,
y sí sus propias expectativas acerca de cómo trabajar con la computadora.
2. Principios para el Diseño de Interfaces de Usuario
Existen principios relevantes para el diseño e implementación de IU, ya sea para las IU
gráficas, como para la Web.
Anticipación
Las aplicaciones deberían intentar anticiparse a las necesidades del usuario y no esperar
a que el usuario tenga que buscar la información, recopilarla o invocar las herramientas
que va a utilizar.
Para ver esta imagen deberá descargar el archivo de Word que se encuentra en la opción
"Bajar trabajo" ubicado en la parte superior de este documento
En la Figura 2 se ilustra como el procesador de texto se anticipa a las necesidades del

usuario, proporcionando las características del texto seleccionado -fuente, tamaño,
alineación, etc.- permitiendo que el usuario pueda modificarlas ágilmente.
Autonomía
La computadora, la IU y el entorno de trabajo deben estar a disposición del usuario. Se

debe dar al usuario el ambiente flexible para que pueda aprender rápidamente a usar la
aplicación. Sin embargo, está comprobado que el entorno de trabajo debe tener ciertas
cotas, es decir, ser explorable pero no azaroso.
En la Figura 3 se visualiza un diseño incorrecto de interfaz de usuario. La cantidad de

opciones propuestas propone un grado de complejidad que no permite que el usuario
pueda aprender a utilizar el sistema en forma progresiva.
Es importante utilizar mecanismos indicadores de estado del sistema que mantengan a

los usuarios alertas e informados. No puede existir autonomía en ausencia de control, y
el control no puede ser ejercido sin información suficiente. Además, se debe mantener
información del estado del sistema en ubicaciones fáciles de visualizar.
En la Figura 4 se ejemplifica una incorrecta disposición de componentes en la IU. El

reloj no debe ser incorporado en el menú del sistema ya que aporta confusión al usuario.
Para mantenerlo informado sería mas adecuado colocarlo en la barra de estado del
sistema.
Percepción del Color
Aunque se utilicen convenciones de color en la IU, se deberían usar otros mecanismos

secundarios para proveer la información a aquellos usuarios con problemas en la
visualización de colores
En la Figura 5 se representa un mecanismo secundario muy utilizado para ejecución de

comandos: los comandos abreviados (shortcut-keys). Sin embargo la aplicación presenta
un problema de inconsistencia ya que define combinaciones de teclas que difieren a lo
esperado por el usuario, por ejemplo Alt+< en lugar de Alt+B.
Valores por Defecto
No se debe utilizar la palabra "Defecto" en una aplicación o servicio. Puede ser

reemplazada por "Estándar" o "Definida por el Usuario", "Restaurar Valores Iniciales" o
algún otro término especifico que describa lo que está sucediendo. Los valores por
defecto deberían ser opciones inteligentes y sensatas. Además, los mismos tienen que
ser fáciles de modificar.
Consistencia
Para lograr una mayor consistencia en la IU se requiere profundizar en diferentes

aspectos que están catalogados en niveles. Se realiza un ordenamiento de mayor a
menor consistencia:
1.
2. Interpretación del comportamiento del usuario: la IU debe comprender el

significado que le atribuye un usuario a cada requerimiento. Ejemplo: mantener
el significado de las los comandos abreviados (shortcut-keys) definidos por el
usuario.
3. Estructuras invisibles: se requiere una definición clara de las mismas, ya que
sino el usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de
ventanas mediante la extensión de sus bordes.
4. Pequeñas estructuras visibles: se puede establecer un conjunto de objetos
visibles capaces de ser controlados por el usuario, que permitan ahorrar tiempo
en la ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión.
5. Una sola aplicación o servicio: la IU permite visualizar a la aplicación o
servicio utilizado como un componente único. Ejemplo: La IU despliega un
único menú, pudiendo además acceder al mismo mediante comandos
abreviados.
6. Un conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o
servicio utilizado como un conjunto de componentes. Ejemplo: La IU se
presenta como un conjunto de barras de comandos desplegadas en diferentes
lugares de la pantalla, pudiendo ser desactivadas en forma independiente.
7. Consistencia del ambiente: la IU se mantiene en concordancia con el ambiente
de trabajo. Ejemplo: La IU utiliza objetos de control como menúes, botones de
comandos de manera análoga a otras IU que se usen en el ambiente de trabajo.
8. Consistencia de la plataforma: La IU es concordante con la plataforma.
Ejemplo: La IU tiene un esquema basado en ventanas, el cual es acorde al
manejo del sistema operativo Windows.
En la Figura 6 puede observarse la mejora en la consistencia de las pequeñas

estructuras visibles (3.) para los sistemas gráficos basados en ventanas. La inclusión de
la opción X para cerrar la ventana –operación comunmente utilizada en estas
aplicaciones- simplifica la operatividad del mismo.
La inconsistencia en el comportamiento de componentes de la IU debe ser fácil de

visualizar. Se debe evitar la uniformidad en los componentes de la IU. Los objetos
deben ser consistentes con su comportamiento. Si dos objetos actúan en forma diferente,
deben lucir diferentes. La única forma de verificar si la IU satisface las expectativas del
usuario es mediante testeo.
Eficiencia del Usuario
Se debe considerar la productividad del usuario antes que la productividad de la

máquina. Si el usuario debe esperar la respuesta del sistema por un período prolongado,
estas pérdidas de tiempo se pueden convertir en pérdidas económicas para la
organización. Los mensajes de ayuda deben ser sencillos y proveer respuestas a los
problemas. Los menúes y etiquetas de botones deberían tener las palabras claves del
proceso.
"Bajar trabajo" ubicado en la parte superior de este documento.
En la Figura 7 se demuestra como una incorrecta definición de las palabras clave de las
etiquetas de los botones de comando puede confundir al usuario. Los botones OK y
Apply aparentan realizar el mismo proceso. Esto puede solucionarse suprimiendo uno
de ellos si realizan la misma tarea o etiquetándolos con los nombres de los procesos
específicos que ejecutan.
Ley de Fitt
El tiempo para alcanzar un objetivo es una función de la distancia y tamaño del

objetivo. Es por ello, que es conveniente usar objetos grandes para las funciones
importantes.
En la Figura 8 se puede apreciar la relación entre los elementos de diseño de pantalla y

su percepción visual. El número de elementos visuales que perciben son: en el caso a) 1
(el fondo); en b) 3 (la línea, lo que está encima y lo que está debajo); en c) son 5 (el
espacio fuera del recuadro, el recuadro, la línea y el espacio encima y debajo de ésta);
finalmente, en d) el número se eleva a 35, siguiendo el mismo criterio. Conclusión: cada

elemento nuevo que se añade influye más de lo que se piensa en el usuario.
Interfaces Explorables
Siempre que sea posible se debe permitir que el usuario pueda salir ágilmente de la IU,
dejando una marca del estado de avance de su trabajo, para que pueda continuarlo en
otra oportunidad.
Para aquellos usuarios que sean noveles en el uso de la aplicación, se deberá proveer de
guías para realizar tareas que no sean habituales.
Es conveniente que el usuario pueda incorporar elementos visuales estables que

permitan, no solamente un desplazamiento rápido a ciertos puntos del trabajo que esté
realizando, sino también un sentido de "casa" o punto de partida.
La IU debe poder realizar la inversa de cualquier acción que pueda llegar a ser de
riesgo, de esta forma se apoya al usuario a explorar el sistema sin temores.
Siempre se debe contar con un comando "Deshacer". Este suprimirá la necesidad de

tener que contar con diálogos de confirmación para cada acción que realice en sistema.
El usuario debe sentirse seguro de poder salir del sistema cuando lo desee. Es por ello
que la IU debe tener un objeto fácil de accionar con el cual poder finalizar la aplicación.
Objetos de Interfaz Humana
Los objetos de interfaz humana no son necesariamente los objetos que se encuentran en
los sistemas orientados a objetos. Estos pueden ser vistos, escuchados, tocados o
percibidos de alguna forma. Además, estos objetos deberían ser entendibles,
consistentes y estables.
En la Figura 9 se presentan barras de controles que simplifican la operación de un

sistema. A través de las ilustraciones que poseen los mismos, el usuario puede aprender
fácilmente su uso. Si se mantienen para estos botones las mismas asignaciones de
procesos en diferentes sistemas, la comprensión del funcionamiento de los mismos se
hace mas sencilla.
Uso de Metáforas
Las buenas metáforas crean figuras mentales fáciles de recordar. La IU puede contener
objetos asociados al modelo conceptual en forma visual, con sonido u otra característica
perceptible por el usuario que ayude a simplificar el uso del sistema.
En la Figura 10 se compara la aplicación de metáforas en el desarrollo de una IU. En el

primer caso, se utiliza incorrectamente la metáfora de una cámara de video para
representar el procesamiento de un documento por una impresora. Se puede observar
que el botón << carece de sentido, ya que no se puede volver atrás un trabajo que ya ha
sido impreso. En el segundo caso, la metáfora de la agenda es utilizada correctamente
para la implementación de una agenda electrónica.
Curva de Aprendizaje
El aprendizaje de un producto y su usabilidad no son mutuamente excluyentes. El ideal

es que la curva de aprendizaje sea nula, y que el usuario principiante pueda alcanzar el
dominio total de la aplicación sin esfuerzo.
Reducción de Latencia
Siempre que sea posible, el uso de tramas (multi-threading) permite colocar la latencia
en segundo plano (background). Las técnicas de trabajo multitarea posibilitan el trabajo
ininterrumpido del usuario, realizando las tareas de transmisión y computación de datos

en segundo plano.
Protección del Trabajo
Se debe poder asegurar que el usuario nunca pierda su trabajo, ya sea por error de su
parte, problemas de transmisión de datos, de energía, o alguna otra razón inevitable.
Auditoría del Sistema
La mayoría de los navegadores de Internet (browsers), no mantienen información acerca

de la situación del usuario en el entorno, pero para cualquier aplicación es conveniente
conocer un conjunto de características tales como: hora de acceso al sistema, ubicación
del usuario en el sistema y lugares a los que ha accedido, entre otros. Además, el
usuario debería poder salir del sistema y al volver a ingresar continuar trabajando en
lugar dónde había dejado.
Legibilidad
Para que la IU favorezca la usabilidad del sistema de software, la información que se

exhiba en ella debe ser fácil de ubicar y leer. Para lograr obtener este resultado se deben
tener en cuenta alguna como: el texto que aparezca en la IU debería tener un alto
contraste, se debe utilizar combinaciones de colores como el texto en negro sobre fondo
blanco o amarillo suave. El tamaño de las fuentes tiene que ser lo suficientemente
grande como para poder ser leído en monitores estándar. Es importante hacer clara la
presentación visual (colocación/agrupación de objetos, evitar la presentación de
excesiva información.
En la Figura 11 se describe una comparación de disposición de los objetos en pantalla.

La figura de la izquierda, combina una disposición asimétrica de la información con un
conjunto de colores que no facilita la lectura. La figura de la derecha realiza la
presentación de la información utilizando una gama de colores homogénea y una
alineación del texto que favorece a la legibilidad del mismo.
Interfaces Visibles
El uso de Internet, ha favorecido la implementación de interfaces invisibles. Esto

significa que el usuario siempre ve una página específica, pero nunca puede conocer la
totalidad del espacio de páginas de Internet. La navegación en las aplicaciones debe ser
reducida a la mínima expresión. El usuario debe sentir que se mantiene en un único
lugar y que el que va variando es su trabajo. Esto no solamente elimina la necesidad de
mantener mapas u otras ayudas de navegación, sino que además brindan al usuario una
sensación de autonomía.
3. Utilización de Prototipos en la Implementación de IU
Niveles de Prototipado
Se puede hacer una clasificación de los principales tipos de prototipos, variando su

grado de complejidad, de acuerdo a las características que consideren y a su
operabilidad para realizar simulaciones.
 Prototipos Estáticos: son aquellos que no permiten la alteración de sus

componentes, pero sirven para identificar y resolver problemas de diseño. En
esta categoría se incluyen las presentaciones sobre reproductores, papel u otro
medio de visualización.

 Prototipos Dinámicos: permiten la evaluación de un modelo del sistema sobre

una estación de trabajo o una terminal. Estos prototipos involucran aspectos de
diseño mas detallados que los prototipos estáticos, incluyendo la validación del
diseño del sistema en términos de requerimientos no funcionales, por ejemplo de
performance.

 Prototipos Robustos: deben ser relativamente completos en la simulación de las

características dinámicas de la interfaz (presentación de mensajes de error,
entrada y edición de datos, etc.). Esta categoría puede ser utilizada para validar
los objetivos de diseño.
El nivel de sofisticación del prototipo debería incrementarse a lo largo del proceso de

diseño de interfaces de usuario. La información recolectada durante las tareas de
análisis del sistema y la especificación de los requisitos del usuario constituyen los
datos clave para el proceso de prototipación.
4. Heurísticas para la Evaluación de IU
Las heurísticas ayudan a poder analizar las IU y localizar problemas que afecten la
utilización de las mismas.
Algunas pautas para evaluar una IU son:
 Visibilidad del estado del sistema

 Semejanza del sistema al mundo real
 Control y libertad por parte del usuario
 Consistencia y estandarización
 Prevención de Errores
 Reconocimiento de acciones y opciones
 Flexibilidad y eficiencia en el uso
 Estética y diseño minimalista
 Reconocimiento de errores, diagnóstico y recuperación
 Ayuda y documentación
Para establecer medidas que indiquen la severidad de los problemas en el uso de las
interfaces, se deben conocer los factores que determinan el grado de un problema:
 La frecuencia de ocurrencia.
 El impacto que causa la ocurrencia del problema.
 La persistencia del problema.
 El impacto en el mercado.
Medidas de severidad de un problema en la IU:
0: No puede llegar a considerarse un problema.
1: Es un problema "cosmético" que no necesita ser corregido a menos que se disponga

tiempo extra en el proyecto.
2: Es un problema menor y su corrección puede tener baja prioridad.

3: Es un problema mayor y su corrección debería tener alta prioridad.
4: Es una catástrofe para la utilización de la aplicación y es imperativo corregir el error.
Para la evaluación de los problemas en las IU es conveniente que contar con más de un
evaluador; de esta forma los resultados son más confiables.
Descripción de componentes
Barra de Título: se utiliza para desplegar el título de la pantalla desplegada. Si la

ventana está activa, la barra de titulo tendrá un color diferente al resto de las ventanas
desplegadas.
Menú Principal: contiene un conjunto de botones que permiten desplegar la totalidad de

las pantallas del sistema.
Usuario del Sistema: indica el nombre del usuario que está utilizando el sistema, el cual
ha sido previamente ingresado con una contraseña como requisito para acceder al
sistema.
Reloj del Sistema: indica la hora actual del sistema.
Area de Trabajo: es el lugar donde se despliegan las pantallas que son activadas a través
del Menú Principal.
Maximizar/Restaurar Ventana: botón que se utiliza para ampliar o reducir el tamaño de

la pantalla.
Minimizar Ventana: control que se utiliza para quitar de primer plano de trabajo una
ventana, sin cerrarla.
Cerrar Ventana: control que se usa para cerrar una ventana.
Puede utilizarse para la descripción de las pantallas, las operaciones que se especifican
en los diagramas de la Historia de Vida de las Entidades del sistema anteriormente
presentado (AGA 2000). Cada operación representa una pantalla diferente, por lo que se
expondrán algunas de ellas (Figuras 13 y 14) con el objeto de ilustrar el diseño de las
mismas.
Opciones de Menú Operaciones
Avería Alta avería, Actualización período Avería,

Borrado de avería.
Cliente Alta cliente, Modificar dirección, Emisión

tarjeta, Cancelación tarjeta, Renovación
tarjeta.
Entrega Alta entrega, Borrar Entrega
Entrega/Vehículo Alta entrega / vehículo, Borrar entrega /

vehículo
Fabricante Alta fabricante, Actualizar datos
Factura Fabricante Alta factura fabricante, Borrar factura

fabricante
Modelo Alta modelo, Borrar modelo
Modelo/Pedido Alta modelo/pedido, Borrar modelo/pedido
Oficina Alta oficina, Borrar oficina
Pago Cliente Alta pago cliente, Borrar pago cliente
Pago Fabricante Alta pago fabricante, Borrar pago

fabricante
Pedido Alta pedido, Borrar pedido
Reserva vehículo Alta reserva vehículo, Borrar reserva

vehículo
Seguro Alta seguro, Modificar porcentaje seguro,

Borrar seguro
Ejemplos de pantalla para la operación de Alta de Fabricante y Alta de Pedidos

El encadenamiento de las pantallas está determinado a partir de la pantalla principal del

sistema, permitiendo desplegar cualquiera de las pantallas utilizadas para las
operaciones anteriormente descriptas. Dichas pantallas pueden ser activadas o cerradas
en forma independiente.
6. Conclusiones
Las integración de los principios, prototipos y heurísticas de evaluación durante el

proceso de diseño de IU permite la creación de interfaces que satisfacen las expectativas
del Modelo del Usuario, el cual es el punto de vista mas importante para garantizar la
aceptación de un sistema.
Entre las características que contribuyen a construir una interfaz sencilla de utilizar,
sobresale la utilización de metáforas como ayuda para simplificar al usuario en la
operación del sistema.
La prototipación es un proceso de uso frecuente durante el diseño de IU. A través

diferentes niveles evolutivos de prototipos se pueden lograr simulaciones del sistema a
construir con un alto grado de detalle, pudiendo validar los requisitos de diseño que se
hayan propuesto.
Las heurísticas de evaluación de IU permiten identificar problemas que interfieran en la

operación del sistema, resultando de ellas un diagnóstico que puede ser utilizado como
retroalimentación para una nueva versión optimizada de la interfaz de usuario.
UNIDAD N° 4
INTRODUCCION A LOS SISTEMAS MULTIMEDIA PC
OBJETIVO; Introducir los elementos básicos que pueden formar un sistema

multimedia.
El término multimedia se utiliza para referirse a cualquier objeto o sistema que utiliza
múltiples medios de expresión (físicos o digitales) para presentar o comunicar
información. De allí la expresión «multimedios». Los medios pueden ser variados,
desde texto e imágenes, hasta animación, sonido, video, etc. También se puede calificar
como multimedia a los medios electrónicos (u otros medios) que permiten almacenar y
presentar contenido multimedia. Multimedia es similar al empleo tradicional de medios
mixtos en las artes plásticas, pero con un alcance más amplio.
Se habla de multimedia interactiva cuando el usuario tiene libre control sobre la

presentación de los contenidos, acerca de qué es lo que desea ver y cuando; a diferencia
de una presentación lineal, en la que es forzado a visualizar contenido en un orden
predeterminado.
Hipermedia podría considerarse como una forma especial de multimedia interactiva que
emplea estructuras de navegación más complejas que aumentan el control del usuario
sobre el flujo de la información. El término "hiper" se refiere a "navegación", de allí los
conceptos de "hipertexto" (navegación entre textos) e "hipermedia" (navegación entre
medios).
El concepto de multimedia es tan antiguo como la comunicación humana ya que al

expresarnos en una charla normal hablamos (sonido), escribimos (texto), observamos a
nuestro interlocutor (video) y accionamos con gestos y movimientos de las manos
(animación). Con el auge de las aplicaciones multimedia para computador este vocablo
entró a formar parte del lenguaje habitual.
Cuando un programa de computador, un documento o una presentación combina

adecuadamente los medios, se mejora notablemente la atención, la comprensión y el
aprendizaje, ya que se acercará algo más a la manera habitual en que los seres humanos
nos comunicamos, cuando empleamos varios sentidos para comprender un mismo
objeto e informarnos sobre él.
Características
Las presentaciones multimedia pueden verse en un

escenario, proyectarse, transmitirse, o reproducirse
localmente en un dispositivo por medio de un reproductor
multimedia. Una transmisión puede ser una presentación Grabado Transmitido
multimedia en vivo o grabada. Las transmisiones pueden localmente en línea
usar tecnología tanto analógica como digital. Multimedia
digital en línea puede descargarse o transmitirse en flujo (usando streaming).
Multimedia en flujo puede estar disponible en vivo o por demanda.
Los juegos y simulaciones multimedia pueden usarse en ambientes físicos con efectos
especiales, con varios usuarios conectados en red, o localmente con un computador sin
acceso a una red, un sistema de videojuegos, o un simulador. En el mercado
informático, existen variados softwares de autoría y programación de software
multimedia, entre los que destacan Adobe Director y Flash.
Los diferentes formatos de multimedia analógica o digital tienen la intención de mejorar

la experiencia de los usuarios, por ejemplo para que la comunicación de la información
sea más fácil y rápida. O en el entretenimiento y el arte, para trascender la experiencia
común.
Un espectáculo láser es un evento multimedia en vivo.
Los niveles mejorados de interactividad son posibles gracias a la combinación de

diferentes formas de contenido. Multimedia en línea se convierte cada vez más en una
tecnología orientada a objetos e impulsada por datos, permitiendo la existencia de
aplicaciones con innovaciones en el nivel de colaboración y la personalización de las
distintas formas de contenido. Ejemplos de esto van desde las galerías de fotos que
combinan tanto imágenes como texto actualizados por el usuario, hasta simulaciones
cuyos coeficientes, eventos, ilustraciones, animaciones o videos se pueden modificar,
permitiendo alterar la "experiencia" multimedia sin tener que programar.
Además de ver y escuchar, la tecnología háptica permite sentir objetos virtuales. Las
tecnologías emergentes que involucran la ilusión de sabor y olor también puede mejorar
la experiencia multimedia.
La multimedia encuentra su uso en varias áreas incluyendo pero no limitado : arte,

educación, entretenimiento, ingeniería, medicina, matemáticas, negocio, y la
investigación científica. En la educación, la multimedia se utiliza para producir los
cursos de aprendizaje computarizado (popularmente llamados CBT) y los libros de
consulta como enciclopedia y almanaques. Un CBT deja al usuario pasar con una serie
de presentaciones, de texto sobre un asunto particular, y de ilustraciones asociadas en
varios formatos de información. El sistema de la mensajería de la multimedia, o MMS,
es un uso que permite que uno envíe y que reciba los mensajes que contienen la
multimedia - contenido relacionado. MMS es una característica común de la mayoría de
los teléfonos celulares. Una enciclopedia electrónica multimedia puede presentar la
información de maneras mejores que la enciclopedia tradicional, así que el usuario tiene
más diversión y aprende más rápidamente. Por ejemplo, un artículo sobre la segunda
guerra mundial puede incluir hyperlinks (hiperligas o hiperenlaces) a los artículos sobre
los países implicados en la guerra. Cuando los usuarios hayan encendido un hyperlink,
los vuelven a dirigir a un artículo detallado acerca de ese país. Además, puede incluir un
vídeo de la campaña pacífica. Puede también presentar los mapas pertinentes a los
hyperlinks de la segunda guerra mundial. Esto puede acelerar la comprensión y mejorar
la experiencia del usuario, cuando está agregada a los elementos múltiples tales como
cuadros, fotografías, audio y vídeo. (También se dice que alguna gente aprende mejor
viendo que leyendo, y algunos escuchando).
La multimedia es muy usada en la industria del entretenimiento, para desarrollar

especialmente efectos especiales en películas y la animación para los personajes de
caricaturas. Los juegos de la multimedia son un pasatiempo popular y son programas
del software como CD-ROMs o disponibles en línea. Algunos juegos de vídeo también
utilizan características de la multimedia. Los usos de la multimedia permiten que los
usuarios participen activamente en vez de estar sentados llamados recipientes pasivos de
la información, la multimedia es interactiva.
Tipos de información multimedia:
 Texto: sin formatear, formateado, lineal e hipertexto.

 Gráficos: utilizados para representar esquemas, planos, dibujos lineales...
 Imágenes: son documentos formados por píxeles. Pueden generarse por copia
del entorno (escaneado, fotografía digital) y tienden a ser ficheros muy
voluminosos.
 Animación: presentación de un número de gráficos por segundo que genera en
el observador la sensación de movimiento.
 Vídeo: Presentación de un número de imágenes por segundo, que crean en el
observador la sensación de movimiento. Pueden ser sintetizadas o captadas.
 Sonido: puede ser habla, música u otros sonidos.
El trabajo multimedia está actualmente a la orden del día y un buen profesional debe
seguir unos determinados pasos para elaborar el producto.
 Definir el mensaje clave. Saber qué se quiere decir. Para eso es necesario
conocer al cliente y pensar en su mensaje comunicacional. Es el propio cliente el
primer agente de esta fase comunicacional.
 Conocer al público. Buscar qué le puede gustar al público para que interactúe
con el mensaje. Aquí hay que formular una estrategia de ataque fuerte. Se
trabaja con el cliente, pero es la agencia de comunicación la que tiene el
protagonismo. En esta fase se crea un documento que los profesionales del
multimedia denominan "ficha técnica", "concepto" o "ficha de producto". Este
documento se basa en 5 ítems: necesidad, objetivo de la comunicación, público,
concepto y tratamiento.
 Desarrollo o guion. Es el momento de la definición de la Game-play:

funcionalidades, herramientas para llegar a ese concepto. En esta etapa sólo
interviene la agencia que es la especialista.
 Creación de un prototipo. En multimedia es muy importante la creación de un
prototipo que no es sino una pequeña parte o una selección para testear la
aplicación. De esta manera el cliente ve, ojea, interactúa... Tiene que contener
las principales opciones de navegación.
Ahora ya se está trabajando con digital, un desarrollo que permite la interactividad. Es

en este momento cuando el cliente, si está conforme, da a la empresa el dinero para
continuar con el proyecto. En relación al funcionamiento de la propia empresa, está
puede presuponer el presupuesto que va a ser necesario, la gente que va a trabajar en el
proyecto (lista de colaboradores). En definitiva, estructura la empresa. El prototipo es
un elemento muy importante en la creación y siempre va a ser testeado (público objetivo
y encargados de comprobar que todo funciona)
 Creación del producto. En función de los resultados del testeo del prototipo, se
hace una redefinición y se crea el producto definitivo, el esquema del
multimedia.
UNIDAD N° 3
TÉCNICAS PROFESIONALES AVANZADAS
OBJETIVO; Profundizar en las técnicas avanzadas comunes a los entornos gráficos

de las unidades anteriores.
PROGRAMACIÓN EN UN ENTORNO GRÁFICO (I)
43.1. Preliminares.
Los conceptos de programación pueden dividirse en tres grandes apartados.
Las estructuras de programación.

Las estructuras de datos.
El entorno en el que se ejecutará el programa.
Las estructuras de programación son los elementos comentados anteriormente.
Variables
Estructuras repetitivas
Estructuras condicionales
Estructuras secuenciales
Procedimientos
Funciones
Clases.
Las estructuras de datos son
Tipos de usuario
Arrays
Archivos
Bases de datos
El entorno de ejecución del programa podemos distinguir tres apartados
Los “programas”, en realidad clases, rutinas o librerías, como deseemos llamarlos, que
se ejecutarán como parte de un programa y que posiblemente no incorporen ningún
elemento interactivo con el usuario.
43.2. Objetivos del tema.
Definir los elementos de la programación en un entorno gráfico.
43.3. Introducción.
Las herramientas de programación se han visto en su totalidad en los temas anteriores,

sin embargo los programas que de ellas se podían obtener eran algo pobres
estéticamente, aunque si disponíamos de todo el potencial para realizar un buen
programa.
Estos objetos dado que tienen que mostrarse con una serie de características que
permitirá su forma agradable a la vista, disponen de una serie de propiedades que
permite que se le pueda asignar colores, tamaños, posición adecuados dentro del
componente o ventana en el que lo mostraremos al usuario.
A su vez como necesitamos saber cuales son

las intenciones de quien está usando el
programa con respecto al objeto en cuestión,
dichos objetos disponen de una serie de
eventos que nos permite saber si el usuario
usa el teclado, el ratón, o algún otro evento
que pueda ser necesario para dicho objeto.
Además también podemos necesitar que

dichos objetos nos faciliten algún tipo de
acción propia del mismo, por lo que en la
mayoría de los casos estos objetos incorporan los métodos adecuados al destino para el
cual están diseñados.
Estos objetos pueden agruparse en los que podríamos

llamar básicos, y especializados.
Los elementos básicos son los que en un principio se

crearon en las primeras versiones de programación
para un entorno gráfico, básicamente son los que se
pueden ver en las imágenes del entorno de VB y de
NetBeans que se ven en el documento.
Después se han ido creando una serie de elementos

más especializados y que han facilitado en gran
medida la creación de nuevos y mejores programas.
Son objetos que podrían ser prescindibles en algunos casos, pero que sin embargo su
aparición se agradece en gran medida en la creación de nuevos programas.
Por otro lado existe la posibilidad de crear nuestros propios objetos para el uso en
nuestros programas.
Propiedades.
Cada uno de los objetos que usaremos en nuestros programas disponen de propiedades
que nos van a permitir definir Cómo reaccionará el objeto ante las acciones del usuario.
Como se mostrará el objeto en la ventana, colores, fuentes tamaño, ubicación.
La información que mostrará en algunos casos.
De esta forma se podrá personalizar cada objeto a las necesidades del programa.
Ejemplos de propiedades pueden ser:
Nombre del objeto
Color de fondo
Tipo de fuente
Tamaño de fuente
Coordenada vertical y horizontal
Tamaño en altura y anchura
43.5. Eventos.
Se activan a medida que se produce alguna acción en el objeto en cuestión.
Muchos de los procedimientos y métodos que se escriban en nuestro programa tendrán

como punto de inicio la activación de un evento.
Los eventos existentes están relacionados con
El teclado
El ratón
Los producidos por el sistema.
Si observamos los elementos que son capaces de producir los eventos, veremos que son
precisamente los elementos que permiten comunicarnos con la interface del programa.
Ejemplos de eventos pueden ser:
Pulsar tecla
Tecla abajo
Tecla arriba
Clic con el ratón
Doble clic con el ratón

43.6. Métodos.
Los métodos son la forma que tiene un objeto de poder realizar algún tipo de acción
propia del mismo, como puede ser el provocar que pase al fondo del orden de
visualización, o pase a un primer plano.
43.7. Objetos.
Son los elementos con los cuales vamos a poder realizar el diseño gráfico de nuestro
programa.
Podemos clasificarlos en varios tipos.
Mostrar información
Etiquetas
Grupos de objetos
Visualizar imágenes
Introducción de datos.
Cajas de texto
Grid, rejillas
Ordenes.
Botones para activar la acción a realizar por el usuario.
Opciones.
Para seleccionar una opción entre varias
Activar una opción en concreto
Selección de datos
Cajas desplegables
Listas de datos
Pero hay más, ya especializados en realizar tareas determinadas.
Impresión
Conexión con bases de datos
Menús y barras
43.8. Tipos de ventanas, formularios.
Podemos hablar de cómo mínimo tres tipos de ventanas.
Contenedoras.
Contenidas.
Independientes.
Las contenedoras son aquellas que habitualmente contienen el menú de la aplicación y

desde la cual se van cargando el resto de ventanas que componen la aplicación.
Las contenidas son las ventanas, programas que se van ejecutando desde el menú de la
aplicación.
Las ventanas independientes, son las que se ejecutan sin estar contenidas en ninguna
otra.
43.9. Crear un programa.
La creación de un programa en un entorno gráfico pasa por varias etapas.
Crear la interface.
Escribir la llamada al código que se ha de ejecutar por cada uno de los eventos que
deseemos utilizar.
Escribir el programa propiamente dicho:
Control de la introducción de datos.
Validación de los mismos.
Acciones propias del programa que unas se inician en los eventos de los objetos del
formulario y otras como consecuencia de la activación de un botón de órdenes.
Fases de un programa.
Un programa en un entorno gráfico tiene varias fases.
Carga.
Activación.
Ejecución.
Finalización
1 Carga.
La carga dispone de eventos en los cuales podemos ejecutar aquellos pasos previos a la
ejecución, como pueda ser la configuración de los objetos y su ubicación en la ventana,
apertura de archivos y conexiones con bases de datos.
2 Activación.
Una vez finalizada la fase de carga pasamos a la activación de la ventana, el programa a

partir de ahí estará disponible para las acciones del usuario.
La activación se produce cuando el formulario toma el foco, el sistema le presta

atención.
En esta fase se puede actualizar el contenido de aquellos objetos que se cargan desde
archivos, bases de datos por si han sufrido cambios, y cualquier otro objeto susceptible
de haber sufrido cambios en el tiempo que no ha estado activo.
El contenido de un formulario, programa, durante el periodo que pierde la atención del

sistema, el foco, puede haber sufrido variaciones, de ahí la necesidad o posibilidad de
realizar la recarga de determinados objetos y actualizar sus contenidos.
La desactivación se produce cuando sin salir del programa, pasamos a la ejecución de

otro programa, la ventana queda abierta pero no hacemos nada en ella.
Cuando volvemos se vuelve a activar.

3 Ejecución.
Es el periodo que transcurre desde que se inicia hasta que se finaliza, descarga el
formulario, es el periodo en el que se producirán todas las acciones para las cuales ha
sido diseñado el programa, y que en la mayoría de los casos arrancarán desde alguno de
los eventos de los objetos que componen la ventana, formulario.
4 Finalización.
Cerraremos archivos, conexiones con bases de datos.
En esta fase se dispone de la posibilidad de cancelar la acción de salida.
La finalización pasa por distintas fases, de tal forma que podemos cancelar la salida del
programa si no se dan las condiciones adecuadas, datos pendientes de guardar.
¿Cómo se hace un programa? (I)
44.1. Objetivos del tema.
Conocer la forma en la cual se crea un programa, y la forma de abordarlo.
Intentar explicar como hacer un programa es algo harto complicado, ya que es una tarea
muy personal de cada cual, y a cada uno le gustará hacerlo de una forma o de otra, pero
al menos vamos a intentar explicar una forma de hacerlo.
Por otro lado el ejemplo que se muestra es un programa de mantenimiento, es una visión
de cómo se puede plantear el mismo, y claro está que ni la mejor, ni la única.
Pero es un ejemplo válido de cómo se ha de enfocar un programa, y de cual es el punto

de partida de las cosas que queremos hacer en el mismo, así como de las distintas etapas
a cubrir.
44.2. Introducción.
En un entorno gráfico se tiende a que cada uno de los programas esté compuesto por un
formulario, aunque no es una regla, pero es bastante habitual.
Por lo tanto cada una de las opciones que tenga una aplicación se puede asociar a un
formulario, ventana.
Para crear un formulario, para crear un programa en un entorno gráfico, podemos partir
de los siguientes criterios.
Un programa se compone de varios elementos:
El que se comunica con el usuario, la interfaz.
El que recibe esa información y la trata en función del destino de la misma, y de sus
características.
El que se encarga, si procede, de grabar y recuperar información de un soporte de datos,

dígase sistema clásico de archivos, base de datos, etc.
A partir de aquí podemos empezar a crear los programas siguiendo esas premisas es
decir, Crear el elemento de:
Comunicación con el usuario, interfaz.
Que trata los datos que en esa interfaz se muestran o se recogen.
De recuperación y grabación de los datos, si procede.
Después existe una serie de programas cuya interfaz es una simple pregunta de si se
desea o no realzar un proceso, o los de capturar una serie de datos para llegar a una
conclusión o realizar un proceso basado en ellos, los denominados asistentes.
44.3. Interfaz de usuario.
Con los objetos que hemos descrito anteriormente podemos crear una interfaz de
usuario para cualquiera de las necesidades que nos puedan surgir, otro tema es que haya
en el mercado objetos más sofisticados que nos permitan resultados más llamativos o de
mejores prestaciones, todo es cuestión de gustos y de necesidades.
Recordemos los objetos vistos.

Mostrar información.
Etiquetas
Grupos de objetos
Visualizar imágenes
Introducción de datos.
Cajas de texto
Grid, rejillas
Ordenes.
Botones para activar la acción a realizar por el usuario.
Opciones.
Para seleccionar una opción entre varias
Activar una opción en concreto
Selección de datos.
Cajas desplegables
Listas de datos
Especializados.
Impresión
Conexión con bases de datos
Menús y barras
Lo que hay que hacer ahora es pensar

cómo queremos que sea nuestra
ventana y pensar cuales de estos
objetos vamos a utilizar.
La fase de análisis y de diseño nunca es un tiempo perdido, suele ser al revés, una
inversión en tiempo.
Siempre es interesante dedicar un tiempo adecuado hasta obtener ese diseño que nos
gusta, de forma que podamos a partir de él obtener nuevos programas o simplemente ya
no tengamos que pensar en como hacerlos y podamos progresar más rápidamente en su
creación.
Tenemos que pensar que en una aplicación siempre vamos a tener distintos tipos de
programas y debemos buscar una forma de diseño que nos permita crear interfaces lo
más homogéneas y agradables posibles para facilitar su posterior utilización y
aprendizaje.
44.4. Diseñar la interfaz.
Primer paso es pensar que tipo de

datos vamos a utilizar en el mismo,
pues de ellos va a depender el tipo de
objetos que vamos a utilizar.
Normalmente se pueden abordar los

diseños de varias formas, por lo tanto
no hemos de conformarnos con el
primero, podemos intentar otros y elegir el que más nos guste.
La ventana anterior está creada con los objetos sin asignarle estilo, es decir colores,
fuentes, etc...Después hay que darle forma con un estilo que nos resulte agradable.
Hay que cuidar los espacios, la distribución, los colores a utilizar y cómo será el texto a
utilizar, tamaño y color.
Las ayudas que vamos a incorporar y su ubicación.
La estética es muy importante, de nuestros programas lo primero que se ve es la parte

visual, por lo tanto hay que cuidar esa primera impresión. La ergonomía también:
Hay que crear las ventanas desde el centro del monitor hacia el exterior, de tal forma
que el ojo del usuario deba moverse lo menos posible, lo cual reduce el cansancio.
Los colores fosforescentes son inadecuados.
Los contrastes entre los colores han de permitir que se puedan ver adecuadamente los
contenidos, fondo negro y texto rojo no es correcto.
La intermitencia con determinados colores es peligrosa para algunas personas.
También se puede, o se debe, crear sistemas que permitan al usuario personalizar la

aplicación.
Cuando tengamos acabada la parte de diseño de la interfaz, tendremos un espacio

ocupado en el monitor, el que ocupa la ventana, si este tamaño a una resolución habitual
es suficiente no será necesario que el usuario maximice la ventana, por lo tanto
podemos evitar poniendo a false la propiedad maximizebox, el que se use ese botón de
la ventana, lo cual evitará que se destroce el diseño que hemos realizado.
También podemos evotar que modifiquen el tamaño de la ventana arrastrando desde las
esquinas, asignando a la ventana en la propiedad FormBorderStyle el valor de
fixedsingle.
Y por último para que la ventana quede centrada en la pantalla o en la ventana que la
contenga del menú, podemos asignar a la propiedad StartPosition el valor de
centerscreen.
De esta forma conseguimos que no se pueda cambiar el diseño realizado por nosotros.
Pero no hay que olvidar que también se tiene que cuidar la parte ejecutiva.
UNIDAD N° 5
EL SONIDO
OBJETIVO; Conocer las características más comunes de los elementos que

constituyen un sistema de audio.
UNIDAD N° 6
LAS IMÁGENES
OBJETIVO; Conocer las características más comunes de los elementos que

constituyen un sistema con elementos gráficos e imágenes.
Entornos gráficos
El entorno gráfico de usuario (GUI) son los recursos visuales que presentan la
información y procesos que se pueden ejecutar en un programa o un sistema operativo
Estamos tan acostumbrados a trabajar con los entornos gráficos que, para la mayoría de
los usuarios, éstos constituyen la única experiencia que tienen con sus ordenadores. Sin
embargo, las 'carpetas' y 'ventanas' no son, ni mucho menos, el lenguaje innato de un
ordenador.
El entorno de escritorio (en inglés, 'desktop environment') es el conjunto de iconos,

barras de herramientas, fondo de pantalla y habilidades específicas que llamamos
'escritorio' en el sistema operativo. La información se manipula directamente sobre las
representaciones gráficas con ayuda del puntero y el ratón.
La metáfora frente a la línea de comandos
El ordenador es una máquina que procesa y almacena información en código binario.

Antes de que existieran los dispositivos de almacenamiento, los programadores tenían
que escribir, línea por línea, los comandos necesarios para conseguir ejecutar el proceso
deseado.
Gracias a los discos duros y los compiladores, los ordenadores de hoy no se programan
sino que se utilizan: cada vez que el usuario abre una aplicación está convocando un
proceso que alguien ha programado de antemano. El sistema operativo es el conjunto de
programas que permiten gestionar dichas aplicaciones y, el entorno gráfico, la

representación metafórica de dicho sistema.
Antes de que existieran los dispositivos de almacenamiento, los programadores tenían

que escribir línea por línea los comandos necesarios para conseguir ejecutar el proceso
deseado
Los ordenadores modernos tienen unas orejas para escuchar al usuario (generalmente,
un teclado y un ratón) y una boca para contestarle (un monitor o pantalla). En los
entornos e interfaces de texto o de Línea de Comandos (CLI), el usuario 'habla' con el
ordenador mediante una serie de expresiones llamadas comandos, que son reconocidas
por el sistema. Si la orden es correcta, la respuesta del ordenador es la ejecución del
proceso. Si no lo es, la pantalla despliega un mensaje de error.
En los interfaces gráficos, el usuario habla y escucha a través de metáforas, un lenguaje

visual que representa comandos, procesos y programas en forma de carpetas, iconos y
barras de herramientas. Los más conocidos son los escritorios de Windows (Microsoft)
y Mac OSX (Apple). En los entornos de software libre, los más populares son GTK+
(Gnome) y Qt (KDE).
Pros y contras del GUI
Los entornos gráficos han sido determinantes a la hora de extender el uso de

ordenadores a la población no especializada. Permiten arrastrar documentos, manipular
la información o agregar datos en el sistema de manera rápida e intuitiva (es más fácil
recordar un proceso asociado a una imagen que recordar el nombre de dicho proceso, a
veces un poco abstracto y normalmente en inglés).
El margen de error es más pequeño, porque hay posibilidades de confundir un comando

o deletrearlo mal. Sus detractores, sin embargo, critican su efectividad por dos motivos
fundamentales: crean dependencias del usuario a programas y sistemas operativos
concretos y obstaculizan el aprendizaje.
El usuario que depende de un entorno gráfico sabe mucho acerca de cómo funciona su
interfaz; aquellos que prescinden de la metáfora, aprenden cómo funciona su ordenador
Aunque la tendencia habitual entre los diseñadores de entornos gráficos es imitar los
entornos más populares para cada sistema operativo o programas especializados, la
interfaz gráfica obliga al usuario a aprender una manera específica de manejar su
ordenador y le resulta difícil probar nuevos sistemas y programas, porque tiene que
desaprender lo aprendido y empezar otra vez. La línea de comandos es la misma en
todos los sistemas, los entornos gráficos varían de un sistema a otro, de un programa a
otro.
Además, hay quien considera que la interfaz es un muro artificial entre la computadora
y su usuario, que obstaculiza en lugar de facilitar la relación entre ambos. El usuario que
depende de un entorno gráfico sabe mucho acerca de cómo funciona su interfaz.
Aquellos que prescinden de la metáfora, aprenden cómo funciona su ordenador.
Entorno de escritorio
Un entorno de escritorio es un conjunto de software para ofrecer al usuario de una

computadora una interacción amigable y cómoda. El software es una solución completa
de interfaz gráfica de usuario ofrece iconos, barras de herramientas, e integración entre
aplicaciones con habilidades como, arrastrar y soltar
En general cada entorno de escritorio se distingue por su aspecto y comportamiento

particulares, aunque algunos tienden a imitar características de escritorios ya existentes.
El primer entorno moderno de escritorio que se comercializó fue desarrollado por Xerox
en los años 80. Actualmente el entorno más conocido es el ofrecido por la familia
Windows aunque existen otros como los de Macintosh (Classic y Cocoa) y de código
abierto (o software libre) como GNOME, KDE, CDE, Xfce o LXDE.
Galería
GNOME 2.20 KDE 4.4 XFCE 4.4.0
The Mezzo Desktop en Symphony OS KDE 3.5 Gcoex
LXDE
Entornos gráficos de escritorio
Existen además de los WM mostrados anteriormente entornos de escritorios, los cuales

proveen un WM, utilidades varias y un framework de desarrollo que nos permitirán
desarrollar aplicaciones que se integren al entorno perfectamente, compartiendo el
look&feel del mismo y aprovechando servicios como arrastrar y soltar, servicio de
impresión centralizado, un portapapeles común, etc. Algunos de estos entornos son
KDE, Gnome, GNUStep y CDE. Hablaremos solamente de los dos primeros que son,
sin lugar a dudas, los más populares. El tercero es un esfuerzo por reimplementar las
especificaciones OPENStep de NeXT, y parece haber quedado estancado. El último
nombrado fué durante muchos años el rey en los ambientes UNIX corporativos, pero ha
quedado desfasado respecto a los dos primeros, además de no ser libre.
Un mejor entorno de escritorio
Aún más mejoras en la interfaz de escritorio Plasma, que hacen que organizar su
espacio de trabajo sea más fácil. Miniaplicaciones nuevas y mejoradas, como un
lanzador rápido, información metereológica, fuentes de noticias, tiras cómicas,

compartición rápida de ficheros por medio de servicios de tipo pastebin. Las
miniaplicaciones de Plasma se pueden usar ahora encima del salvapantallas, por
ejemplo para dejar una nota mientras el usuario está ausente. Plasma actúa
opcionalmente como un escritorio tradicional, al estilo de un gestor de ficheros. Se han
añadido previsualizaciones para los iconos de fichero y la ubicación persistente de los
iconos.
El panel de Plasma agrupa ahora las tareas y las muestra en varias filas. La bandeja
del sistema mejorada ahora sigue la pista de las tareas que toman más tiempo, como
las descargas. Las notificaciones del sistema y de las aplicaciones se muestran de modo
unificado por medio de la bandeja del sistema. Para ahorrar espacio, se pueden ocultar
los iconos de la bandeja del sistema. Además, el panel se puede ocultar
automáticamente para liberar espacio en pantalla. Los elementos gráficos se pueden
mostrar tanto en paneles
Como el escritorio KWin ofrece una gestión de ventana fluida y eficiente. En KDE 4.2
emplea física del movimiento para dar dar un aire natural a viejos y nuevos efectos
tales como el «Cubo» y la «Lámpara maravillosa». KWin sólo habilita los efectos de
escritorio en la configuración predeterminada en aquellos equipos que sean capaces de
manejarlos. Una configuración más fácil permite al usuario seleccionar distintos
efectos como intercambiador de ventanas, haciendo que cambiar de ventanas sea más
eficiente.
Las herramientas nuevas y mejoradas del espacio de trabajo aumentan la productividad.

PowerDevil facilita la vida móvil ofreciendo una gestión de energía moderna y discreta
para portátiles y dispositivos móviles. Ark ofrece creación y extracción inteligente de
archivos, y las nuevas herramientas del sistema de impresión permiten al usuario
gestionar impresoras y trabajos de impresión fácilmente.
UNIDAD N° 7
HIPERTEXTO
OBJETIVO; Adquirir el concepto de hipertexto

Modulo Original

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulo Original

Uploaded by

Copyright:

Available Formats

MODULO DISEÑO Y REALIZACIÓN DE SERVICIOS DE PRESENTACIÓN EN ENTORNOS GRÁFICOS

Cuando se escribe un programa en un lenguaje orientado a objetos, definimos una

Luego, tenemos automóviles concretos, por ejemplo el automóvil propio de una

La programación en un entorno gráfico está basada en la utilización de una herramienta

Este entorno gráfico cambiará de un lenguaje a otro, pero en definitivas cuentas se

Definir los elementos de la programación en un entorno gráfico

Elaborar interfaces de usuario a partir del diseño de servicios de presentación y de

• Evaluar que los servicios de presentación implementados cumplen con las

• Elaborar la documentación característica de los servicios de presentación

Diseñar servicios de presentación amigables en formato que faciliten la interacción

􀀹 Realizar servicios de presentación que cumplan las directrices del diseño.

􀀹 Realizar pruebas de usuario que verifiquen la presentación, secuencias de

􀀹 Elaborar y mantener documentación sobre el diseño, desarrollo, prueba y

CAPACIDADES TERMINALES Y / O COMPETENCIA

Conocer las funciones de una interfaz gráfica de usuario (IGU).

1.2. Conocer distintas interfaces gráficas existentes en el mercado.

1.3. Realizar el diseño de esquemas para plantillas y/o presentaciones de carácter

1.4. Crear un servicio de presentación dependiendo de las características de la IGU

1.6. Analizar las necesidades y peticiones de usuarios establecidos.

1.7. Analizar el funcionamiento de los interfaces de usuario existentes en un

1.8. Evaluar los problemas de un entorno gráfico establecido.

1.9. Establecer la interoperatividad entre interfaces gráficas y los S.G.B.D. más

1.10. Analizar la información proveniente del diseño de los servicios de

1.11. Evaluar las ventajas e inconvenientes de la implementación de los servicios de

1.12. Implementar el diseño de los servicios de presentación de una aplicación en

1.13. Establecer los criterios de validación de los servicios de presentación.

1.14. Describir la forma de crear los objetos de acceso a datos.

1.15. Describir los métodos de acceso a datos.

1.17. Realizar aplicaciones cliente-servidor.

Según esto podríamos estructurar el curso en 11 grandes temas (que se explicara en el

En el intento de mejorar el modulo, así como de acercarnos a los nuevos lenguajes de

Todos los bloques se evalúan de la misma forma, Pruebas teóricas individuales:

Objetivo de la Unidad: Repasar y profundizar en los contenidos básicos de la

El desarrollo de la OOP empieza a destacar durante la década de los 80 tomando en

El propósito de este trabajo es explicar el diseño orientado a objeto y no una explicación

La OOP aporta un enfoque nuevo, convirtiendo la estructura de datos en el centro sobre

En resumen, la programación estructurada presta atención al conjunto de acciones que

Muchos habrán oído comentarios sobre la incidencia de la OOP sobre la programación

La OOP proporciona las siguientes ventajas sobre otros lenguajes de programación

CONCEPTOS BÁSICOS DE PROGRAMACIÓN ORIENTADA A OBJETOS

Razones fundamentales que están influyendo en la importancia de la POO

Algunas de las causas que están influyendo considerablemente en el notable desarrollo

 La OO (orientación a objetos) es especialmente adecuada para realizar

 Los mecanismos de encapsulación de POO soportan un alto grado de

 En el entorno de la base de datos, la OO se adjunta bien a los modelos

 Aumento espectacular de los lenguajes de programación orientados a objetos.

 Interfaces de usuarios gráficos (por iconos) y visuales. Las interfaces de usuarios

Características de los Objetos

 El esfuerzo del programador ante una aplicación orientada a objetos se centra en

Estructura interna de un objeto:

La estructura interna de un objeto está compuesta por tres elementos fundamentales

o Propiedades: Son las características observables de un objeto. Las

o Métodos: Se define como un conjunto de acciones que un objeto puede

propiedades del objeto se altera su apariencia y se genera un cambio que

El estado de un objeto es la apariencia que el objeto presenta al usuario, y depende del

Los objetos están organizados en familias claramente delimitadas. Una familia se

La herencia es la última de las propiedades relativas a la OOP, Consiste en la

La herencia nos permite crear estructuras jerárquicas de clases donde es posible la

Para pensarlo de manera más fácil podemos abstraernos al siguiente ejemplo.

Pensemos en los distintos sub-modelo s asociados a un modelo básico de automóvil. A

Existen dos tipos de herencia

acceso a todas sus partes: propiedades, métodos y definición de eventos. El

Algunos métodos y propiedades en un objeto son privados, es decir, útiles únicamente