PDF de programación - Programa de Visual Basic 5.0

PROGRAMA DE VISUAL BASIC 5.0

CAPITULO I INTRODUCCION

I.1 El Paradigma de la Orientación a Objetos

El tema de la orientación a objetos no es nuevo. Sin embargo, en los últimos años
ha tenido un impacto tan grande en diferentes áreas de la computación que se hace
obligatorio el manejo de los conceptos involucrados para cualquier persona relacionada
con esta disciplina. De la misma forma ha surgido una proliferación de definiciones e
interpretaciones que conducen, primero a confusión, y luego a malas interpretaciones y
abusos de los términos. En este primer capítulo se presenta una breve reseña de algunos
acontecimientos que han reforzado las bases de este paradigma a través del tiempo, así
como una exposición de la mayor parte de los términos que giran alrededor de esta
filosofía.

I.2 Perspectiva histórica

Cuando Fortran apareció en 1957 como una forma de automatizar la labor de aquellos
que programaban en lenguaje máquina y en ensamblador, hubo mucho escepticismo.
Había que probar que un proceso automático de traducción podía competir con la
eficiencia y el ingenio que aplicaban aquellos programadores para poder ahorrar un
microsegundo o una unidad de almacenamiento; y así fue.

Este primer paso es sólo un ejemplo de la aplicación de un concepto clave en
cualquier desarrollo computacional: abstracción. Ese concepto se sigue aplicando y es
posible rastrearlo a lo largo de la historia de los lenguajes de programación.

Los lenguajes de la primera generación como Fortran I y Algol 58 estaban
orientados a facilitar la manipulación de expresiones matemáticas y liberar a los
programadores de los incómodos detalles que involucra (y más en ese entonces) el lidiar
con la máquina en forma directa. Aunque manejaban el concepto de subprograma, este
era aplicado más que todo para reutilización. Además, los programas eran relativamente
planos, en el sentido de que consistían de una serie de subprogramas que referenciaban
datos globales. Es fácil deducir que en programas de no necesariamente gran
complejidad, empezarán a darse problemas serios si un sólo subprograma no funciona
correctamente.

Para 1960, la popularización del transistor y la tecnología de circuitos integrados
hicieron posible que los costos del computador disminuyeran y al mismo tiempo fuera
posible aumentar su capacidad. Surgieron entonces lenguajes como Cobol y Algol 60,
enmarcados dentro de la segunda generación. A diferencia de sus antecesores, éstos
empezaron a dar mayor importancia al concepto de subprograma como un medio para
realizar funciones abstractas. Es decir, al afrontar un problema se idealizaba un conjunto
de acciones macro para solucionarlo, y estas a su vez serían atacadas como nuevos
problemas, hasta llegar a completar la solución final. Lo anterior condujo al añidamiento
de subprogramas, y al desarrollo de teorías referentes a estructuras de control, y a

alcance y visibilidad de variables. Es decir, se construyeron las bases de la programación
estructurada, aplicando una abstracción de los procedimientos requeridos.

Posteriormente, en la tercera generación se incluyó el concepto de módulo, como una
forma de satisfacer la necesidad de manejar partes independientes de la solución que
eran atacadas por diferentes personas, dado que los programas eran cada vez más
complejos y más voluminosos.

Sin embargo, aunque ya se había trabajado bastante en la abstracción al nivel de
módulos y de procedimientos, no se había hecho mucho en lo que se refería a la
abstracción al nivel de datos. Aunque lenguajes como Cobol daban mucha importancia a
los datos dentro de las aplicaciones, existía una separación clara entre datos y
procedimientos. La solución era trazada con base en funciones, no en los datos mismos.

Incluso, al aplicar una metodología clásica de análisis y diseño estructurado, es
posible tomar dos enfoques: 1) realizar primero el estudio y la especificación de las
funciones requeridas y 2) luego formular el diagrama de datos, o al contrario, iniciar
primero con el diseño del diagrama de los datos que se requerirán y las relaciones entre
ellos, para luego deducir cuáles son los procesos necesarios que permitirán que los datos
se mantengan actualizados y evolucionen para brindar la información última que se desee
en el sistema.

Según Shankar, el punto es que la construcción de procedimientos funciona bien
en la conceptualización de funciones abstractas, pero no necesariamente en la
conceptualización de datos abstractos, y dado que la complejidad de los datos contribuye
substancialmente a la complejidad del problema, la abstracción de procedimientos podría
traer serios inconvenientes. Afirmaciones como la anterior llevaron al desarrollo de
métodos de diseño basados en los datos, y a teorías referentes al concepto de tipo, que
eventualmente se reflejaron en lenguajes como Pascal.

Estas ideas se vieron plasmadas por primera vez en el lenguaje Simula, un
lenguaje para programar simulaciones en el computador en donde los objetos de una
simulación eran modelados en forma directa como objetos de software. Simula es el
antecesor de lenguajes como Smalltalk, Object Pascal, C++, Clos, y Ada, que se puede
decir que son de desarrollo reciente. Estos lenguajes son llamados orientados a
objetos. En ellos, un módulo es una colección de objetos, que son cápsulas que
contemplan tanto un comportamiento (función) como un estado (datos), conformando una
unidad donde los datos son el fundamento y estos pueden realizar "por sí mismos" un
conjunto de acciones determinadas, tratando de simular el comportamiento de los objetos
del mundo real (se entrará en detalles más adelante).

Las metodologías de análisis y diseño orientadas a objetos tratan de establecer
normas para definir esas cápsulas y las relaciones con las demás de forma que se
maximicen una serie de criterios deseables previamente establecidos para lograr un
producto de calidad.

I.3 Elementos de un modelo de objetos

Según Booch, el modelo de objetos está basado en cuatro elementos principales:

• Abstracción
• Encapsulamiento
• Modularidad
•

Jerarquía

Es importante entender esos elementos antes de entrar al estudio de términos más
específicos, pues son ellos los que determinan las características comunes de cualquier
aplicación que se denomine "orientada a objetos".

I.1.1 Abstracción

Existen muchas definiciones de este término que pueden ayudar a comprenderlo.
Según Hoare: "una abstracción surge del reconocimiento de similitudes entre diferentes
objetos, situaciones, o procesos en el mundo real, y de la decisión de concentrarse en
esas similitudes e ignorar por un momento las diferencias".

Shaw define el concepto como "una descripción simplificada de un sistema, que
enfatiza algunos de los detalles o propiedades del mismo, pero que también omite otros.
Una buena abstracción es una que enfatiza detalles que son significativos al lector y que
suprime otros detalles que son, por el momento, irrelevantes".

Berzins, Gray, y Naumann apuntan que "un concepto califica como abstracción
sólo si puede ser descrito, comprendido, y analizado independientemente del mecanismo
que será utilizado eventualmente para realizarlo".

Booch concluye que "una abstracción denota las características esenciales de un
objeto que lo distinguen de todas las otras clases de objetos, y entonces provee límites
conceptuales claramente definidos, relativos a la perspectiva del observador".

Cada una de las definiciones anteriores coincide en el hecho de que una
abstracción es un medio que permite un mejor manejo de la complejidad del problema, al
permitir suprimir o posponer detalles irrelevantes en cierto momento, y concentrarse más
bien, en detalles verdaderamente esenciales. El reconocer similitudes entre diferentes
objetos también permite simplificar el dominio en estudio pues hace posible enunciar
comportamientos o características generales que los describen, sin importar detalles que
podrían no ser importantes.

Las abstracciones pueden ser de muchos tipos. Por ejemplo, pueden describir
objetos que constituyen un modelo útil dentro del dominio del problema, u objetos que se
conciben para agrupar acciones necesarias en la solución (objetos virtuales que son
necesarios para controlar la interacción de los objetos entre sí).

Una abstracción debe tener límites conceptuales bien definidos que permitan la
independencia funcional entre unas y otras. Así mismo, esos límites deberán esclarecer
la forma en que la abstracción será utilizada para resolver y modelar el problema en

cuestión. Es decir, al abstraer un objeto, debe quedar claro cuál es su función y su
relación con los demás objetos.

Una abstracción es algo que no necesariamente existe en el dominio real de la
aplicación pero que su existencia resultaría tan útil para el analista que termina siendo
representada e incorporada en la solución computacional al problema.

Además, como apuntan Berzins y demás, debe ser independiente de la forma en
que finalmente se lleve a cabo. Por ejemplo, la abstracción de una lista considera tanto
las acciones que se permitirán realizar sobre ella, así como ciertas variables que
mantienen el estado de la misma, pero no especifica que una lista debe ser realizada
como un arreglo o mediante el uso de punteros. Esos son detalles que no vale la pena
mencionar mientras se está introducien