Estudio Comparativo de Lenguajes de Programación Orientados a Objetos Basado en las Facilidades para Implantar el Concepto de Objeto-Edición Única

PUBLICACIÓN DE TRABAJOS DE GRADO

Las Bibliotecas del Sistema Tecnológico de Monterrey son depositarias de los trabajos recepcionales y de

grado que generan sus egresados. De esta manera, con el objeto de preservarlos y salvaguardarlos como

parte del acervo bibliográfico del Tecnológico de Monterrey se ha generado una copia de las tesis en

versión electrónica del tradicional formato impreso, con base en la Ley Federal del Derecho de Autor

(LFDA).

Es importante señalar que las tesis no se divulgan ni están a disposición pública con fines de

comercialización o lucro y que su control y organización únicamente se realiza en los Campus de origen.

Cabe mencionar, que la Colección de

Documentos Tec,

donde se encuentran las tesis, tesinas y

disertaciones doctorales, únicamente pueden ser consultables en pantalla por la comunidad del

Tecnológico de Monterrey a través de Biblioteca Digital, cuyo acceso requiere cuenta y clave de acceso,

para asegurar el uso restringido de dicha comunidad.

El Tecnológico de Monterrey informa a través de este medio a todos los egresados que tengan alguna

inconformidad o comentario por la publicación de su trabajo de grado en la sección Colección de

Documentos Tec

del Tecnológico de Monterrey deberán notificarlo por escrito a

http://biblioteca.itesm.mx

Estudio Comparativo de Lenguajes de Programación Orientados

a Objetos Basado en las Facilidades para Implantar el Concepto

de Objeto-Edición Única

Title

Estudio Comparativo de Lenguajes de Programación

Orientados a Objetos Basado en las Facilidades para

Implantar el Concepto de Objeto-Edición Única

Authors

Juan Antonio Macías Guerrero

Affiliation

Tecnológico de Monterrey, Campus Monterrey

Issue Date

1994-05-01

Item type

Tesis

Rights

Open Access

Downloaded

18-Jan-2017 21:01:15

B A S A D O E N L A S FACILIDADES P A R A I M P L A N T A R

EL C O N C E P T O DE OBJETO

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

POR

TESIS

MAESTRÍA EN CIENCIAS

ESPECIALIDAD EN INGENIERÍA DE SISTEMAS

COMPUTACIONALES

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE

MONTERREY

POR

JUAN ANTONIO MACÍAS GUERRERO

PROGRAMA DE GRADUADOS EN INFORMÁTICA

Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Juan Antonio Macías Guerrero sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias, especialidad en:

INGENIERÍA DE SISTEMAS COMPUTACIONALES

Comité de tesis:

Mayo de 1994

Ing. Juan R. EsparzazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Martínez, M . C .

ASESOR P R I N C I P A L

Dr. José Ignacio Icaza Acereto.

SINODAL

Lic. Teresa Lucio Nieto, M . C . S I N O D A L

Dr. Ramón Brena Pinero

POR

JUAN ANTONIO MACÍAS GUERRERO

TESIS

Presentada a la División de Graduados e Investigación

Este Trabajo es Requisito Parcial para Obtener el Título de Maestro

en Ciencias

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE

MONTERREY

Esto es lo que aprendí: Comparte todo, juega limpio,

no golpees a las personas,

pon las cosas donde las encontraste, limpia tu tiradero,

no tomes lo que no te pertenece, pide perdón cuando hieras a alguien, lávete las manos antes de comer,

pan caliente y leche fría son buenos para ti. Vive una vida equilibrada:

Aprende algo, piensa algo, dibuja, pinta, canta, baila, juega,

trabaja cada día u n poco,

y duerme una siesta por las tardes.

Cuando salgas al mundo, pon atención, tómate de las manos y permanece unido.

Toma cualquiera de estos puntos y aplícalos al sofisticado mundo de los adultos y a tu vida familiar, a tu trabajo, al gobierno y al mundo y verás que sostiene la verdad clara y firme.

Piensa qué clase de mundo tendríamos si todos siguiéramos comportándonos así.

A DIOS

Gracias por la vida; por permitirme conocer gente tan bella; por

mostrarme cada día su voluntad y darme las fuerzas para cumplirla.

A MIS P A D R E S , A N T O N I O Y F R A N C I S C A

Gracias por su amor, apoyo y comprensión durante toda m i vida;

por guiarme con su ejemplo; nunca olviden que los amo.

A MIS H E R M A N O S , M I G U E L , S A N J U A N A , M A R I O , SERGIO, JESÚS Y A L E J A N D R O

Gracias por aceptarme; por brindarme su amor, aliento y

comprensión. Los amo y me siento orgulloso de cada uno.

A M I N O V I A , A L M A R O S A

Gracias por todo su amor, paciencia y confianza; por alentarme en

todo momento y por permitirme amarle.

A MIS A M I G O S , B E R T H A , BENJAMÍN, FELIPE Y LUIS

Gracias por su amistad y por toda la ayuda que desinteresadamente

Agradezco en primer lugar al Ing. Juan Raúl Esparza, quien concibió la idea original de la tesis. Además, gracias por todo su apoyo y aliento durante el desarrollo de la misma.

A la Lic. Teresa Lucio, gracias por su colaboración y sus acertadas correcciones. A l Dr. José Ignacio Icaza, gracias por su apoyo, conocimientos y por sus breves, pero muy atinadas observaciones.

A l Dr. Pérez, gracias por su ayuda y comentarios sobre este trabajo. A l Conacyt, gracias por su apoyo.

E n la actualidad ha emergido u n nuevo paradigma para el desarrollo de software, el cual es llamado Orientado a Objetos. Este paradigma ofrece nuevas perspectivas para los desarrolladores de software, tales como: permitir una modelación más cercana del mundo real; facilitar la extensibilidad de software y promover la reutilización de componentes del mismo.

Este paradigma no es nuevo, surgió a partir de los trabajos realizados en el lenguaje de programación Simula en la década de los sesenta y del trabajo realizado posteriormente por Xerox P A R C para el desarrollo del lenguaje Smalltalk. Sin embargo, es hasta la década pasada cuando este paradigma comenzó a utilizarse por u n mayor número de gentes y cuando se comenzaron a desarrollar metodologías de diseño y análisis.

Desafortunadamente, el paradigma de Orientación a Objetos adolece de una clara definición de sus características, lo cual ha hecho que una gran variedad de productos de software como: bases de datos, lenguajes de programación, ambientes de desarrollo, sistemas operativos, etc.; se aprovechen y en su propaganda digan que son Orientados a Objetos.

E n esta tesis, se ha hecho una investigación sobre el paradigma de Orientación a Objetos, la cual fue utilizada para definir las características esenciales que debe cubrir u n lenguaje de programación que aspire a ser considerado Orientado a Objetos.

Por otro lado, se diseñó una prueba que permite verificar si u n lenguaje de programación es Orientado a Objetos a partir de las características esenciales que se definieron para ello. Esta prueba fue aplicada a los lenguajes de programación Turbo C++, Smalltalk-80 y Turbo Pascal, los cuales en su publicidad decían ser Orientados a Objetos.

L a prueba ha sido diseñada de tal manera que puede aplicarse a cualquier lenguaje de programación que presuma ser Orientado a Objetos y así, determinar si puede ser considerado como tal o no.

Lista de FiguraszyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA xi

Lista de Tablas x i i

Capítulo 1

Introducción.

1.1 Antecedentes de la Orientación a Objetos 1 1.2 Objetivo de la Tesis e Importancia de la Investigación 2

1.3 Alcance y limitaciones de la tesis 3

1.4 Organización de la tesis 3

Capítulo 2

El paradigma de Orientación a Objetos.

2.1 Historia del paradigma de Orientación a Objetos 5

2.2 ¿ Qué es la Orientación a Objetos ? 5 2.3 Características del paradigma de Orientación a Objetos 7

2.3.1 ¿ Qué es u n Objeto ? 7 2.3.2 ¿ Qué es y qué no es una clase ? 9

2.3.3 Herencia 10 2.3.4 Polimorfismo 13 2.3.5 Abstracción 13 2.3.6 Operación, Método y Mensaje 14

2.3.7 Encapsulación 15 2.4 Análisis Orientado a Objetos (AOO) 16

2.5 Diseño Orientado a Objetos (DOO) 17 2.6 Programación Orientada a Objetos (POO) 19

2.7 Conclusiones acerca del paradigma de Orientación a Objetos 21

Capítulo 3

Los Lenguajes de Programación Orientados a Objetos (LPOO).

3.1 Lenguajes de programación historia y evolución 23 3.2 Lenguajes de Programación Orientados a Objetos historia y

evolución 25 3.3 Características generales de u n buen lenguaje de Programación 31

3.4 Características esenciales de u n Lenguaje de Programación

Orientado a Objetos 33 3.5 Características a evaluar de u n Lenguaje de Programación

Orientado a Objetos 36 3.6 Conclusiones sobre los Lenguajes de Programación Orientados a

Objetos 37

Capítulo 4

Definición e Implantación de la Prueba en los Lenguajes de Programación Orientados a Objetos (LPOO).

4.1 Terminología Empleada en los Lenguajes de Programación

Orientados a Objetos (LPOO) 39 4.2 Definición de la prueba para los Lenguajes de Programación

Orientados a Objetos (LPOO) 40 4.3 Definición de los L P O O seleccionados para aplicarles la prueba 45

4.4 Descripción de cómo se aplicó la prueba a los L P O O 45 4.4.1 Descripción de la implantación de la prueba en Turbo C++ 46

4.4.1.1 Implantación del ejemplo de Herencia Múltiple

en Turbo C++ 52 4.4.2 Descripción de la implantación de la prueba en

Smalltalk-80 62 4.4.3 Descripción de la implantación de la prueba en Turbo

Pascal 68 4.5 Conclusiones acerca de la prueba aplicada a los Lenguajes

Capítulo 5

Conclusiones.

5.1 Conclusiones globales 78 5.2 Aportación principal 81 5.3 Trabajo para Futuras Investigaciones 81

Apéndice A

Implantación de la Prueba para el Lenguaje Turbo C++ Versión 3.0

A . l Implantación de la prueba 83 A . 2 Implantación del ejemplo que usa Herencia Múltiple en Turbo

C++ 86

Apéndice B

Implantación de la Prueba para el Lenguaje Smalltalk80 Release 4.1

B. 1 Implantación de la prueba 90

Apéndice C

Implantación de la Prueba para el Lenguaje Turbo Pascal Versión 7.0

C. 1 Implantación de la prueba 95

Referencias Bibliográficas 100

Lista de Figuras.

Capítulo 2

Figura 2.1 Objetos 8 Figura 2.2 Clasificación 10 Figura 2.3 Herencia y herencia múltiple (líneas punteadas) 12

Figura 2.4 Envío de Mensaje 15

Capítulo 3

Figura 3.1 Evolución de los Lenguajes Orientados a Objetos 30

Capítulo 4

Figura 4.1 Clases que se definirán en la prueba a los L P O O 42

Figura 4.2 Clases del ejemplo de Herencia Múltiple 54 Figura 4.3 Ejemplo del uso (A) y no uso (B) de clase base virtual 60

Lista de Tablas.

Capítulo 3

Tabla 3.1 Lenguajes y sus Orientaciones a Objetos 28 Tabla 3.2 Ejemplos de Lenguajes Orientados a Objetos 31 Tabla 3.3 Características deseables propuestas para u n L P O O por

autor 35

Capítulo 4

Tabla 4.1 Control de acceso a la secciones de una clase 47

1.1 Antecedentes de la Orientación a Objetos.

El paradigma de modelación Orientado a Objetos según algunos autores tendrá una importancia significativa en la década de los 90's. Por ejemplo, se puede citar a Setrag Khoshafian que dijo: "La década de los 90's será indudablemente llamada la década de la Programación Orientada a Objetos" [KHOS,90].

Las predicciones que se hacen sobre los beneficios que traerá el empleo de la Orientación a Objetos, están basadas en las herramientas y ventajas que ésta proporciona, tales como:

* Modelación del mundo real de una manera más cercana a la perspectiva del usuario.

* Fácil interacción con el ambiente computacional usando metáforas familiares.

* Construcción de componentes reusables de software y de librerías de módulos de software fácilmente extensibles.

* Fácil modificación y extensión de implantaciones de componentes sin tener que recodificar todo partiendo desde cero.

Por otro lado, mientras que el paradigma de Orientación a Objetos está llegando a ser m u y popular, es fácil darse cuenta al leer bibliografía relacionada

con el tema, que no se ha llegado a establecer una clara definición del concepto de zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA

objeto, lo cual es la base para que este paradigma sea entendido y aprovechado

totalmente.

Por otra parte, los primeros en aparecer dentro del mundo de la Orientación a Objetos fueron los lenguajes de programación, tal es el caso de Smalltalk, C++, Eiffel, C L O S , por citar algunos. Varios años después, se empezaron a desarrollar técnicas formales de modelación Orientadas a Objetos (Análisis y Diseño).

Se ha propuesto que en general u n Lenguaje de Programación Orientado a Objetos (LPOO) debería soportar: objetos, clasificación polimorfismo y herencia [RUMB,91]. Pero, para poder conseguir una buena implantación del paradigma en u n Lenguaje de Programación Orientado a Objetos, es importante tener claros los

conceptos y términos básicos del paradigma de Orientación a Objetos, tales como: objeto, clase, herencia, polimorfismo, encapsulamiento, método, etc. U n a vez que se han comprendido los conceptos, su implantación en u n lenguaje no deberá ser complicada y aseguraría u n buen empleo y aprovechamiento del enfoque Orientado a Objetos; de lo contrario el uso de u n Lenguaje de Programación Orientado a Objetos estaría limitado.

1.2 Objetivo de la Tesis e Importancia de la Investigación.

E n la actualidad, muchos lenguajes están siendo lanzados al mercado bajo la aseveración de ser Orientados a Objetos; ante tal circunstancia es preciso definir que características debe tener u n lenguaje de programación para poder ser considerado Orientado a Objetos.

El objetivo de esta tesis es brindar u n panorama que permita ver comparativamente qué tanto un lenguaje de programación cumple con el paradigma de Orientación a Objetos.

Para conseguir el objetivo, se realizaron las siguientes actividades:

* Se establecieron a partir de la propuesta de Sánchez [SANC,94] las características esenciales que debe cubrir u n Lenguaje de Programación Orientado a Objetos.

* Se diseñó una prueba que muestra si u n lenguaje de programación es Orientado a Objetos y que además, muestra comparativamente cuáles son sus ventajas y desventajas con respecto a los demás lenguajes en la forma de implantar las características esenciales del paradigma de Orientación a Objetos. * Se aplicó la prueba a tres lenguajes que son considerados como

Orientados a Objetos.

E l producto final es la obtención de una tabla comparativa donde se presentan el lenguaje y las características esenciales de la Orientación a Objetos que cubre. Esta tabla sirve a personas interesadas en el paradigma a elegir un Lenguaje de Programación Orientado a Objetos. Y además, ayuda a aclarar cuales lenguajes son realmente Orientados a Objetos.

muchas empresas, las cuales deberán ante todo tener u n cambio cultural más que tecnológico [YOUR,90].

El interés por el desarrollo de esta tesis se basa principalmente en aclarar conceptos relacionados con los Lenguajes de Programación Orientados a Objetos y en comparar tales lenguajes en cuanto a funcionalidad y soporte de las características esenciales del paradigma de Orientación a Objetos.

1.3 Alcance y limitaciones de la tesis.

E l alcance y los elementos de la presente tesis son los siguientes:

1. Estudiar las características del paradigma de Orientación a Objetos. 2. Analizar las diferentes propuestas que se han realizado sobre cuáles son

las características esenciales de u n Lenguaje de Programación Orientado a Objetos.

3. Proponer las características que se consideran esenciales en u n Lenguaje de Programación Orientado a Objetos.

4. Diseñar y aplicar una prueba (transportable a cualquier lenguaje), que muestre si u n lenguaje de programación es Orientado a Objetos o no. Esta tesis debido a la cantidad de tiempo que se dispone para desarrollarla, fue planeada para que la prueba que se diseñará se aplique sólo a una muestra de lenguajes de programación que son considerados como Orientados a Objetos, dicha muestra se elegirá de los lenguajes disponibles en el ITESM, campus Monterrey.

1.4 Organización de la tesis.

La tesis está dividida en cinco capítulos y tres apéndices, los cuales se describen brevemente a continuación.

E n el segundo capítulo se describen los conceptos generales de la Orientación a Objetos y se muestra también lo que este nuevo enfoque significa desde la perspectiva del análisis, diseño y programación.

de programación y se establecen las características esenciales de u n Lenguaje de Programación Orientado a Objetos, las cuales son utilizadas para la aplicación de la prueba que muestra si u n lenguaje es Orientado a Objetos o no.

Posteriormente, en el capítulo cuatro se definen algunos conceptos relacionados con los Lenguajes de Programación Orientados a Objetos (LPOO); se diseña la prueba que se aplicará a los L P O O ; se define la muestra de lenguajes a los que se les aplicará la prueba diseñada; se describe la aplicación de la prueba y se muestran los resultados que se obtuvieron de dicha aplicación.

Por otra parte, en el capítulo cinco se presentan las conclusiones globales de esta tesis, así como también se exponen los trabajos de futuras investigaciones.

E l propósito de este capítulo es establecer el marco teórico del paradigma de Orientación a Objetos, para ello se describirán los conceptos básicos que lo hacen "el nuevo enfoque en boga"; además se hablará u n poco acerca de la forma cómo el paradigma ha ido evolucionando.

2.1 Historia del paradigma de Orientación a Objetos.

La Programación Orientada a Objetos fue abordada primeramente a finales de los 60 's por el trabajo desarrollado en el lenguaje S I M U L A . Para los 70's este lenguaje tuvo una influencia importante en el lenguaje Smalltalk desarrollado por Xerox P A R C . Mientras tanto, el resto del mundo tropezaba con lenguajes como C O B O L y F O R T R A N , y usaba métodos de descomposición funcional para abordar los problemas de diseño e implantación. Poco, o casi nada, se discutía sobre el Diseño Orientado a Objetos, y virtualmente nada sobre Análisis Orientado a Objetos [YOUR,90].

E n la década pasada y en la década de los 90's, el paradigma de Orientación a Objetos ha tenido varios avances; los lenguajes han evolucionado para abordar problemas como paralelismo, concurrencia y sistemas distribuidos. Por otro lado, se ha dado mayor énfasis al desarrollo de metodologías de Análisis y Diseño Orientados a Objetos. E n la actualidad el uso de la metodología no es tan amplio, pero se espera que el uso aumente debido a las ventajas que la metodología ofrece.

Algunos autores piensan que el paradigma de Orientación a Objetos puede ser la salvación de la crisis en el desarrollo de software. Tal es el caso de Cox, quien dice: "La revolución industrial del software basada en partes reusables e intercambiables alterará el universo del software" [COX, 90]. Este comentario se apoya en la facilidad que brinda la metodología a la creación de componentes reusables.

2.2 ¿ Qué es la Orientación a Objetos ?

Según Khoshafian [KHOS,90], la Orientación a Objetos puede ser descrita vagamente como: "La modelación de software y disciplinas de desarrollo (ingeniería) que hacen fácil la construcción de sistemas complejos a través de componentes individuales". Además, dice que puede ser definida como sigue:

Orientación a Objetos = Tipos de datos abstractos + Herencia

+ Identidad de objetos.

Por otro lado, Rumbaugh dice: "El término Orientación a Objetos significa que nosotros organizamos el software como una colección de objetos discretos que incorporan estructuras de datos y conducta." [RUMB,91]

Para Edward Yourdon, la Orientación a Objetos es u n término difícil, porque el términozyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA objeto ha sido usado de diversas maneras dentro de dos muy diferentes

disciplinas:

* Dentro de la modelación de información, significa la representación

de alguna cosa del mundo real, y algún número de ocurrencias de esa cosa.

* Dentro de los Lenguajes de Programación Orientados a Objetos,

significa una instancia en tiempo de ejecución de algún procesamiento y valor, definido por una descripción estática llamada "clase".

Según Yourdon, una ecuación para reconocer una propuesta de Orientación a Objetos es:

Orientación a Objetos = Clases y objetos + Herencia

+ Comunicación con mensajes.

C o n esta ecuación según Yourdon, uno puede ver en diferentes lenguajes, ambientes, métodos y libros para preguntarse: "¿ Están realmente Orientados a Objetos ?". Desafortunadamente, muchas veces la respuesta es "no"; la Orientación a Objetos sufre al ser una frase de mercadeo fácil de recordar, algunas veces usada para significar "La mejor en su género." [YOUR,90]

E l atractivo de la Orientación a Objetos, es que ésta provee mejores conceptos y herramientas para modelar y representar el mundo real tan de cerca como sea posible. Se ha encontrado que existen algunas disputas sobre exactamente qué características son requeridas por la metodología de Orientación a Objetos, pero en la mayoría de las propuestas se incluye los siguientes aspectos: identidad (objeto), clasificación, polimorfismo, herencia y comunicación con mensajes.

2.3 Características del paradigma de Orientación a Objetos.

Las siguientes características del paradigma de Orientación a Objetos son esenciales: objeto (identidad), clase (clasificación), herencia y polimorfismo. Por otro lado, la abstracción, la comunicación con mensajes, las operaciones o servicios y la encapsulación; son herramientas de enorme importancia y de gran ayuda para el paradigma [SANC,94]. Los párrafos siguientes definirán cada uno de los conceptos anteriores.

2.3.1 ¿ Qué es un Objeto ?

Como parte importante dentro de la metodología de Orientación a Objetos, está el entender lo que significa u n objeto.

E n primera instancia, el diccionario Webster's dice: " U n objeto es una persona o cosa para la cual una acción, u n pensamiento o u n sentimiento están dirigidos. Algo visible o tangible; u n producto material o sustancia." [WEBS,91]

Para Yourdon, u n objeto es: "UnazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA abstracción de algo en el dominio del

problema, reflejando la capacidades de u n sistema para guardar información sobre él, interactuar con él, o ambas; una encapsulación de valores de atributos y sus servicios exclusivos, (sinónimo: instancia.)" [YOUR,90]

Por su parte, Booch dice: " U n objeto tiene estado, conducta e identidad; la estructura y conducta de objetos similares está definida en su clase común; los términos instancia y objeto son intercambiables." [BOOC,91]

E n cambio, Rumbaugh define a u n objeto como: " U n concepto, abstracción o cosa con límites y significados claros para el problema que se está manejado; una instancia de una clase." [RUMB,91]

A l buscar describir el concepto de objeto (instancia) en el paradigma de Orientación a Objetos, se puede decir basado en la literatura consultada que éste es: una abstracción de alguna entidad dentro del dominio del problema que se está tratando en la cual, se encapsulan atributos (datos) y operaciones o servicios (conducta); la siguiente figura refleja ejemplos de objetos.

2.3.2 ¿ Qué es y qué no es una clase ?

Otro término dentro del paradigma de Orientación a Objetos que es necesario describir, es el de clase o clasificación.

Se podría comenzar con esta definición de clase. " U n número de personas o cosas agrupadas en conjunto por cierta semejanza o rasgos comunes" [WEBS,91].

Por su parte, Booch comenta: "Una clase es u n conjunto de objetos que comparten una estructura y conducta comunes." [BOOC,91]

Para Yourdon, una clase es: "Una descripción de uno o más objetos con u n conjunto uniforme de atributos y servicios, incluyendo una descripción de cómo crear nuevos objetos en la clase." [YOUR,90]

Se tiene que para Rumbaugh, una clase es: "Una descripción de u n grupo de objetos con propiedades similares, conducta, relaciones y semántica comunes."

[RUMB,91]

Por otro lado, Bourne se refiere al término clase de la siguiente manera: "...una descripción de uno o más objetos similares." [BOUR,92]

Finalmente por lo que se ha visto se puede decir que una clase es: u n conjunto o agrupamiento de objetos, los cuales comparten atributos y conductas similares. Una clase representa una abstracción de las características esenciales de u n grupo de objetos.

Pero, ¿ qué no es una clase ?; por u n lado, u n simple objeto es una instancia de una clase. Sin embargo, un objeto no es una clase, aunque, curiosamente una clase puede ser u n objeto. Objetos que no comparten una estructura y conducta común no pueden ser agrupados en una clase, porque por definición, no están relacionados, excepto por su naturaleza general como objetos. [BOOC,91]

Dentro de este concepto surgen otros conceptos relacionados que es importante anotarlos. Estos conceptos son: clase abstracta, clase concreta y metaclase.

UnazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA clase abstracta es una clase que no puede tener instancias directas, pero

cuyos descendientes si pueden tener instancias. Por otro lado, una clase concreta es

una clase que puede tener instancias directas. Por último, una metaclase es una

clase describiendo a otras clases.

Figura 2.2 Clasificación. [RUMB,91]

2.3.3 Herencia.

A l igual que con los conceptos anteriores, se presentarán las definiciones que proponen algunos autores para la herencia, y finalmente se expresará una conclusión con base a dichas definiciones.

E n primer término, se tiene que para Yourdon la herencia es: " U n mecanismo para expresar la similitud entre clases, simplificando la definición de clases similares a una o unas previamente definidas. Esto representa la generalización y especialización, haciendo comunes atributos y servicios explícitos dentro de una jerarquía de clases." [YOUR,90]

Por otro lado, para Bourne la herencia es: "La capacidad de una clase para usar estados locales (variables) y conductas (métodos) de las clases más abstractas." [BOUR,92]

jerárquicas. U n a clase puede ser definida de una manera muy general y entonces

clarificarla sucesivamente en clases más finas. CadazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA subclase incorpora o hereda,

todas las propiedades de la superclase y agrega sus propiedades únicas. Las

propiedades de la superclase no necesitan ser repetidas en cada subclase." [RUMB,91]

Para Booch, es u n tipo de jerarquía y un elemento esencial de los sistemas Orientados a Objetos y la define de la siguiente manera: "La herencia define una relación entre clases, donde una clase comparte la estructura o conducta definidas en una o más clases (llamadas herencia simple y herencia múltiple respectivamente). L a herencia representa así una jerarquía de abstracción en la cual, una subclase hereda de una o más superclases. Típicamente una subclase aumenta o redefine la estructura y conducta existentes en esas superclases."

[BOOC,91]

2.3.4 Polimorfismo.

E n esta sección se buscará aclarar el significado del concepto de polimorfismo desde la perspectiva del paradigma de Orientación a Objetos. Utilizando para ello las definiciones dadas por algunos autores.

Como primer punto, se tiene que el significado general de polimorfismo se refiere a tener muchas partes o formas.

Para Bourne, el polimorfismo es: "La capacidad de diferentes objetos para responder en una manera apropiada al mismo mensaje." [BOUR,92]

Por otro lado, para Rumbaugh este término significa: "La propiedad mediante la cual una operación puede comportarse diferentemente sobre diferentes clases." [RUMB,91]

Para Booch en cambio, el polimorfismo es: " U n concepto en la teoría de tipos, de acuerdo al cual u n nombre (tal como una declaración de variable) puede denotar objetos de muy diversas clases que están relacionados por alguna superclase en común; así cualquier objeto denotado por este nombre es capaz de responder a u n conjunto común de operaciones en diferentes maneras." [BOOC,91] Basado en la literatura consultada se podría decir que el polimorfismo es la propiedad en la cual, una misma operación puede tener u n comportamiento

distinto en clases diferentes. Por ejemplo, la operaciónzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA cerrar tendrá u n

comportamiento diferente para la clase ventana que para la clase válvula.

2.3.5 Abstracción.

E l concepto de abstracción es usado ampliamente en el proceso de modelación. E n esta sección se buscará describir el concepto de abstracción basado en la perspectiva del paradigma de Orientación a Objetos. Para ello, se utilizará las definiciones que dan algunos autores.

E n primer lugar, se tiene la definición propuesta por Booch que dice lo siguiente: "La abstracción denota las características esenciales de u n objeto, que lo distinguen de todos los otros tipos de objetos y así proporcionar límites conceptuales definidos, relativos a la perspectiva del observador." [BOOC,91]

Por último, se tiene la siguiente definición: "La abstracción es el principio de ignorar aquellos aspectos de u n tema que no son relevantes para el propósito actual, y así, concentrarse más detalladamente en aquellos que sí lo son." [OXFO,86]

Basado en las definiciones anteriores, se puede decir que la abstracción es u n proceso mental que permite enfocarse en las características esenciales de u n objeto, las cuales lo distinguen de los demás objetos e ignorar sus aspectos accidentales.

2.3.6 Operación, Método y Mensaje.

Durante el desarrollo de la investigación se encontró que existe una cierta confusión acerca del significado de los conceptos de operación, método y mensaje dentro del paradigma de Orientación a Objetos. E n esta sección se mostrará como para algunos autores, tales conceptos significan lo mismo y se buscará aclarar sus significados.

E n primer lugar, para Booch método significa lo siguiente: "Una operación sobre u n objeto, definida como parte de la declaración de una clase; todos los métodos son operaciones, pero no todas las operaciones son métodos. Los términoszyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA mensaje, método y operación son usualmente intercambiados. E n algunos

lenguajes, u n método no puede ser redefinido, pero sirve como parte de la implantación de una función genérica o de una función virtual, ambas de las cuales pueden ser redefinidas en una subclase." [BOOC,91]

Por otro lado, para Rumbaugh una operación es: "Una acción o transformación que u n objeto realiza o a la que está sujeto"; mientras que u n método es: "La implantación de una operación para una clase específica"; y u n mensaje es: "La invocación de una operación sobre u n objeto, la cual comprende el nombre de la operación y una lista de los valores de los argumentos." [RUMB,91]

Por su parte, Yourdon define la operación como u n servicio y lo hace de la siguiente manera: "Servicio es una conducta específica de la que u n objeto es responsable por exhibirla". Por otro lado, u n mensaje es el medio comunicación a través del cual, el emisor solicita al receptor que u n procesamiento sea hecho.

[YOUR, 90]

E n base a la literatura consultada, se observó que u n método es una operación

que ya fue implantada en u n clase, pero que puede ser redefinida en alguna subclase; se encontró también que existe una diferencia entre mensaje y método, aunque existen mensajes y métodos con el mismo nombre, el mensaje es la

método los cuales, son vistos por algunos autores como iguales; unazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA operación es

una función o transformación que puede ser aplicada a o por u n objeto en una clase, mientras que, u n método es la implantación de la operación para una clase.

Cabe hacer notar que, la única forma de comunicación entre objetos es mediante mensajes (figura 2.4), los cuales son vistos como disparadores de la ejecución del método con el mismo nombre. [BOUR,92]

Figura 2.4 Envío de Mensaje. [YOUR,90]

2.3.7 Encapsulación.

Por último, se tiene el concepto de encapsulación. Para este concepto, al igual que como se hizo con los conceptos anteriores, se buscará presentar su significado visto desde el enfoque del paradigma de Orientación a Objetos.

E n primer término, se tiene que para Booch la encapsulación es: " E l proceso de ocultar todos los detalles de u n objeto que no son características esenciales." [BOOC,91]

Por otra lado, Cox define la encapsulación de la siguiente manera: "La encapsulación significa que el cliente ve sólo los servicios que están disponibles de un objeto, pero no cómo estos servicios son realizados." [COX,86]

E n cambio, para Rumbaugh la encapsulación queda definida de la siguiente forma: "La encapsulación consiste en la separación de los aspectos externos de u n objeto, los cuales son accesibles a otros objetos; de los detalles de implantación internos del objeto, los cuales están ocultos para otros objetos (también llamada: ocultamiento de información.)" [RUMB,91]

Basándose en las definiciones dadas, se podría decir que la encapsulación u ocultamiento de información, consiste en mostrar sólo los aspectos externos del objeto(parte pública), aquellos que son accesibles a otros objetos y ocultar los detalles de implantación, aspectos internos del objeto(parte privada).

Según Rumbaugh, la encapsulación no es única para los lenguajes de Orientación a Objetos, pero la capacidad para combinar estructuras de datos y conducta en una simple entidad hace a la encapsulación más clara y poderosa que en los lenguajes que separan las estructuras de datos y la conducta. [RUMB,91]

2.4 Análisis Orientado a Objetos (AOO).

Se podría comenzar con la definición general de análisis, para así, comprender lo que significa el Análisis Orientado a Objetos.

Análisis es definido en u n diccionario de la siguiente manera: "La separación de una entidad material o abstracta en sus elementos constituyentes." [WESB,91]

Después de haber mostrado la definición general, se tiene que según Bourne, el propósito inicial del análisis de u n problema es proporcionar una estructura o marco organizado en el cual, el problema puede ser comprendido y descompuesto en mayor grado. E n general, el proceso identifica todos los objetos en el problema y sus conductas. [BOUR,92]

Por otro lado, Booch dice :" E l Análisis Orientado a Objetos es u n método de análisis que examina requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario del dominio del problema". [BOOC,91]

pequeños detalles para después. U n modelo de análisis exitoso declarazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA qué debe

ser realizado, sin restringir cómo esto es realizado, y evita decisiones de

implantación. E l resultado del análisis debe ser la comprensión del problema como una preparación para el diseño." [RUMB,91]

Por último, para Yourdon, el enfoque de Análisis Orientado a Objetos consiste de cinco actividades principales, que son:

* L a búsqueda de clases y objetos. * La identificación de estructuras. * L a identificación de temas o tópicos. * La definición de atributos.

* L a definición de servicios.

Y comenta: "Estas son verdaderas actividades, no pasos secuenciales. Las actividades guían al analista desde altos niveles de abstracción (por ejemplo; clases y objetos en el dominio del problema) a gradualmente los más bajos niveles de abstracción (estructuras, atributos y servicios.)" [YOUR,90]

Basado en la investigación, se podría decir entonces que el Análisis Orientado a Objetos es una actividad que pretende modelar los sistemas del mundo real, para ello se realiza una búsqueda de objetos/clases, atributos y comportamientos. L a parte esencial consistirá en la modelación de qué debe ser realizado por el sistema;

y no de cómo esto deberá ser realizado. E l Análisis Orientado a Objetos (AOO)

enfatiza en la creación de modelos del mundo real, usando una perspectiva Orientada a Objetos del mundo.

Es importante resaltar que, el análisis es u n componente clave para el diseño, normalmente precede la creación de nuevos diseños. Orientado a Objetos o no, el diseño requiere análisis como precursor. Ahora, el siguiente paso será definir el significado de Diseño Orientado a Objetos.

2.5 Diseño Orientado a Objetos (DOO).

Después de haber analizado u n problema , se debe decidir cómo se abordará el

diseño. Durante el análisis, el enfoque es sobre qué necesita ser realizado, durante

el diseño, las decisiones son hechas acerca de cómo el problema será resuelto,

Según Cox, las personas que están muy relacionadas con ambientes de ingeniería o científicos, tienden en el diseño a descomponer los problemas de acuerdo a las acciones que deben ser desempeñadas; mientras que, la gente relacionada con el procesamiento de datos, tiende a descomponer los problemas

primero en entidades. E l primero es u n punto de vistazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA centrado en los procesos y el

segundo está centrado en los datos. E l Diseño Orientado a Objetos introduce una

tercera posibilidad en la cual, datos y procedimientos son tratados simultáneamente como ideas subordinadas dentro de u n concepto superior, el

objeto. [COX,86]

Por su parte, Rumbaugh propone el diseño del sistema como la primera etapa de

diseño, en la cual el enfoque básico para resolver el problema es seleccionado. Durante el diseño del sistema se decide la estructura total del sistema y su estilo. Propone la arquitectura del sistema que es: la organización total del sistema en

componentes llamados subsistemas. Según él, esta arquitectura proporciona el

contexto en el cual, decisiones más detalladas son hechas en etapas posteriores de diseño.

Sugiere además, que el diseñador del sistema deberá hacer las siguientes decisiones:

* Organizar el sistema en subsistemas.

* Identificar la concurrencia inherente en el problema. * Asignar subsistemas a procesos y tareas.

* Elegir u n enfoque para la administración del almacenamiento de datos.

* Manejar el acceso a los recursos globales.

* Elegir la implantación de controles en software. * Manejar las condiciones límite.

* Establecer las prioridades de beneficio.

A menudo la arquitectura total de u n sistema puede ser elegida basada en su similitud con sistemas previos. Cierto tipo de arquitecturas de sistema son útiles para resolver una amplia variedad de clases de sistemas. [RUMB,91]

computadora, incluyendo en ello la interacción humana, la administración de tareas y los detalles de administración de datos." [YOUR,91]

E l Diseño Orientado a Objetos según Booch, queda definido de la siguiente manera: "Es u n método de diseño que comprende el proceso de descomposición Orientado a Objetos y una notación para la representación de los modelos lógico y físico; así como, los modelos estático y dinámico del sistema bajo diseño." [BOOC,91]

Booch, identifica dos partes importantes en el Diseño Orientado a Objetos que él propone: primero, el Diseño Orientado a Objetos conduce a una descomposición Orientada a Objetos; y segundo, usa diferentes notaciones para expresar los diferentes modelos del diseño lógico (estructuras de clases y objetos), y físico (arquitectura de módulos y procesos) de u n sistema.

Agrega que, el apoyo de la descomposición Orientada a Objetos es lo que hace al Diseño Orientado a Objetos totalmente diferente del diseño estructurado: el primero usa la abstracción de clases y objetos para sistemas lógicamente estructurados; y el segundo usa abstracciones algorítmicas. [BOOC,91]

Por último, se cita la definición de Meyer, la cual dice: " E l Diseño Orientado a Objetos es la construcción de sistemas de software como colecciones estructuradas de implantaciones de tipos de datos abstractos." [MEYE,87]

C o n base en la investigación realizada, se podría definir el Diseño Orientado a Objetos como u n técnica que propone hacer una descomposición de u n sistema en clases y objetos (diseño lógico); y en módulos y procesos (diseño físico). E l fin del D O O es crear una representación del dominio del problema que pueda ser

transformada en software; para ello, se toma en cuentazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA cómo el problema será

resuelto.

2.6 Programación Orientada a Objetos (POO).

Así como ha sido difícil definir el término Orientado a Objetos, se presenta ahora la dificultad de definir qué es la Programación Orientada a Objetos. Algunos autores más que dar una definición, citan las características que la describen, tal es el caso de las siguientes definiciones:

Booch:

clase, y cuyas clases son miembros todas de una jerarquía de clases unidas vía relaciones de herencia".

Dentro de su definición, Booch remarca que existen tres partes importantes dentro de la Programación Orientada a Objetos:

* E l uso dezyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA objetos, no de algoritmos, como su fundamental

construcción lógica de bloques.

* Cada objeto es una instancia de alguna clase.

* Las clases están relacionadas unas a otras vía relaciones de

herencia.

Además agrega: " U n programa puede parecer Orientado a Objetos, pero si alguno de esos elementos es olvidado, éste no será u n programa Orientado a Objetos. Específicamente, programar sin herencia es claramente no Orientado a Objetos; podría llamarse programación con tipos de datos abstractos." [BOOC,91]

Pinson:

Por su parte, Pinson da la siguiente definición: "La Programación Orientada a Objetos es definida en su más puro sentido como la programación implantada mediante el envío de mensajes a objetos." Según él, la solución de problemas mediante el uso de los principios de Programación Orientada a Objetos, consiste en identificar los objetos, mensajes y las secuencias objeto-mensaje para efectuar la solución. [PINS,88]

Riñe:

Por otro lado, para Riñe la Programación Orientada a Objetos es: " U n método de desarrollo Orientado a Objetos que conduce a sistemas de software basados en los objetos que cada sistema/subsistema manipula, en vez de la función que estos pretende asegurar." [RINE,92]

Cox:

Para Cox, la Programación Orientada a Objetos es una propuesta revolucionaria en la cual, las características primarias están resumidas en dos palabras: la encapsulación y la herencia. [COX,86]

Lafore:

programas, no en los detalles de operadores individuales. E n particular, los programas en P O O son organizados alrededor de objetos, los cuales contienen datos y funciones que actúan sobre estos datos." [LAFO,92]

Budd:

Por último, se tiene la definición de Budd, la cual dice: "La Programación Orientada a Objetos es más que una simple colección de lenguajes de programación. L a Programación Orientada a Objetos es una nueva manera de pensar acerca de lo que ésta significa para la computación, acerca de cómo podemos estructurar la información dentro de la computadora." Y agrega: "La Programación Orientada a Objetos no es simplemente unas cuantas nuevas características agregadas a los lenguajes de programación. Es algo más que esto, es una manera de pensar acerca de los procesos de descomposición de los problemas y el desarrollo de soluciones mediante la programación."

Comenta que la Programación Orientada a Objetos ve los programas como una colección de una gran cantidad de agentes autónomos, llamados objetos. Y por último, agrega que la Programación Orientada a Objetos es tomada también como u n nuevo paradigma, y observa que desde el punto de vista de la definición dada

sobre el significado de paradigma en el LibrozyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA The Structure of Scientific Revolutions

por Thomas K u h n , "Paradigma es u n conjunto de teorías, estándares y métodos que juntos representan una manera de organizar el conocimiento"; la Programación Orientada a Objetos es efectivamente u n nuevo paradigma. [BUDD,91]

Después de observar las definiciones anteriores, se podría definir la Programación Orientada a Objetos como u n nuevo paradigma que propone la implantación de programas como colecciones cooperativas de objetos, haciendo énfasis en el empleo de clases, herencia, polimorfismo, comunicación entre objetos mediante mensajes y encapsulamiento. Cabe hacer notar que si la programación sólo se centra en el uso de objetos no puede ser llamada Orientada a Objetos, sino basada en ellos. Las características deseables que debería soportar la P O O serían: objeto, clase, herencia, polimorfismo comunicación con mensajes y encapsulamiento.

2.7 Conclusiones acerca del paradigma de Orientación a Objetos.

de datos y procedimientos. E n el paradigma se destaca el empleo de conceptos como:

* Clasificación. * Herencia. * Polimorfismo. * Abstracción. * Operación. * Método.

* Comunicación entre objetos con mensajes. * Encapsulación.

Por otra parte, el inicio de la Orientación a Objetos se ubica en el desarrollo de lenguajes de programación que incorporaron algunos de los conceptos anteriores; tal es el caso de Simula que es considerado como el precursor de algunos de ellos.

Por último, se han tenido avances en el desarrollo de metodologías de Análisis y Diseño Orientados a Objetos. Además, se han propuesto las características que la Programación Orientada a Objetos deberá soportar, dentro de las cuales están:

* Objeto. * Clase. * Herencia.

* Comunicación con mensajes. * Encapsulación.

* Polimorfismo.

Como parte importante del paradigma de Orientación a Objetos están los lenguajes de programación. A continuación se expondrá la evolución de los lenguajes de programación en general y la de los lenguajes de Programación Orientados a Objetos (de las siglas LPOO); en seguida, se mostrarán las características que debe reunir u n buen lenguaje de programación; se señalarán y comentarán las características de u n buen L P O O y por último se definirán las características que se evaluarán de los L P O O para el propósito de esta tesis.

3.1 Lenguajes de programación historia y evolución.

L a información que a continuación se expondrá está contenida en [BOUR,92] y [SAND,83].

E l primer intento de comunicación con la computadora a través de u n lenguaje se realizó víazyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA lenguaje máquina, que consiste de una serie de números binarios y es

lo único que el C P U entiende directamente. Cada instrucción en lenguaje máquina consta de al menos dos partes. L a primera parte es el comando u operación y le dice a la computadora cuál es la función que realizará. L a segunda parte es el operando y le dice a la computadora dónde encontrar o almacenar los datos u otras instrucciones que van a ser manejadas.

Para aliviar la carga del programador, a comienzos de los años cincuenta se desarrollaron códigos mnemónicos de operación y direcciones simbólicas; esto dio

origen a los lenguajes ensambladores. Este tipo de lenguajes tienen varias ventajas sobre los lenguajes de máquina. Por ejemplo, ahorran tiempo, se cometen menos errores que en los lenguajes máquina y en caso de cometerlos es más fácil encontrarlos.

U n o de los primeros lenguajes de alto nivel (llamados así porque ya no dependían de la arquitectura de la computadora) fue F O R T R A N . John Backus de I B M y tres asociados son acreditados como los creadores de la especificación para F O R T R A N en 1954. F O R T R A N (FORmula TRANslator) ha sido muy popular para la producción de programas y es aún ampliamente usado aunque, su popularidad ha decrecido en la última década.

Otro de los primeros lenguajes en aparecer fue C O B O L . Tal como su nombre lo indica, C O B O L (COmmon Business Oriented Language) fue diseñado

específicamente para el procesamiento de datos de tipo comercial. Actualmente es el lenguaje más ampliamente utilizado para grandes aplicaciones de negocios. E l grupo que proyectó e implantó este lenguaje se reunió en el Pentágono en mayo de 1959 con la tutela oficial del Departamento de Defensa de Estados Unidos. De junio a diciembre de 1959, el comité trabajó en las especificaciones del lenguaje y su informe final fue aprobado en enero de 1960. Desde 1961 se han preparado compiladores para casi todos los procesadores.

Debido a que F O R T R A N estaba totalmente orientado a lo científico y C O B O L a los negocios, surgió la idea a mediados de los años sesenta por parte de I B M y u n comité de usuarios de la familia IBM/360 de crear u n "lenguaje universal". Este lenguaje P L /1 (Programming Language/1), fue puesto en marcha a mediados de la década de los sesenta para resolver todo tipo de problemas tanto de negocios como científicos.

Por otro lado, en los comienzos de 1958, fue diseñado A L G O L (ALGOrithmic Language) como una respuesta para crear u n lenguaje de programación universal. Simple, elegante y general, A L G O L es u n lenguaje con fuerte representación de tiposzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA (Strongly typed: esto significa que el tipo de cualquier expresión en el lenguaje

puede ser determinado) que fue diseñado para cálculos científicos. A L G O L usa construcciones declarativas e imperativas como F O R T R A N .

Otro de los lenguajes de alto nivel es Lisp (List Processing), el cual fue diseñado a finales de los años cincuenta para apoyar la programación simbólica en aplicaciones de inteligencia artificial. Lisp es u n lenguaje aplicativo en contraste a los lenguajes imperativos descritos previamente. L a meta principal de Lisp fue permitir la manipulación de símbolos, a menudo representados como listas.

Por otra parte, el lenguaje Pascal (que fue nombrado así en honor a Blaise Pascal), es u n sucesor de las ideas de F O R T R A N y A L G O L . Pascal fue explícitamente diseñado para enseñar programación por Nicklaus Wirth. Iniciado en 1968, Pascal permanece como el principal lenguaje para enseñar a programar a los estudiantes de preparatoria y universidad.

Continuando con la evolución de los lenguajes de programación surge P R O L O G ; el cual es u n lenguaje basado en la programación lógica desarrollada en Francia a inicios de los años setenta. P R O L O G (PROgramming i n LOGic) ha sido ampliamente aceptado en Francia y Japón, pero ha tenido u n éxito limitado en los Estados Unidos. Aunque alguna vez se pensó por algunas personas que P R O L O G podría suplantar a Lisp como el líder en los trabajos de Inteligencia Artificial, esta promesa no ha sido materializada. P R O L O G es u n lenguaje declarativo en el cual, las declaraciones lógicas son hechas de acuerdo a una sintaxis específica.

siguientes en uno de los lenguajes de programación de propósito general más populares. E l lenguaje de programación C es u n lenguaje nativo usado en las implantaciones del sistema operativo U N I X . Algunas de las características de C son: es u n lenguaje relativamente pequeño, es conciso, modular y portable.

Por último, se comentará acerca del lenguaje A D A . A mediados de los años setenta, el Departamento de Defensa de los Estados Unidos apoyó el desarrollo de u n lenguaje de programación de la nueva generación, el cual podría ayudar en el diseño arriba-abajozyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA (Top-Dozvn) de software. L a preocupación primaria fue

proporcionar modularidad y ocultamiento de información con el propósito de reducir la cantidad de tiempo necesario para crear grandes sistemas de software. E l nombre de A D A fue dado en honor de Augusta A d a , condesa de Lovelace, nombrada como la primer programadora en el mundo.

3.2 Lenguajes de Programación Orientados a Objetos historia y evolución.

La información que a continuación se expondrá está contenida en [BOUR,92] y [KHOS,90].

Los primeros lenguajes en introducir representación simbólica para entender las instrucciones máquina fueron los ensambladores. Pero, el primer evento importante en la programación de alto nivel fue indudablemente el desarrollo de F O R T R A N . [KHOS,90]

F O R T R A N introdujo varios conceptos importantes para los lenguajes de programación incluyendo variables, arreglos y estructuras de control (iteración y condicionales de bifurcación). F O R T R A N es aún uno de los más populares lenguajes de programación. E l lenguaje tiene u n comité de estandarización ANSI(American National Standards Institute) activo que periódicamente libera mejoras substanciales y extensiones al lenguaje.

N o obstante, a finales de la década de los cincuenta, u n problema que se encontraba cuando se desarrollaban grandes programas en F O R T R A N era que, los nombres de variables podrían tener conflicto en diferentes partes de u n programa. Este problema se presentó en los lenguajes de programación de alto nivel que sucedieron a F O R T R A N , incluidos P L /1 , C O B O L y A L G O L . Los diseñadores del lenguaje A L G O L decidieron proveer barreras para separar los nombres de variables dentro de los segmentos de programa. Esto dio nacimiento a los bloques

Begin_End en A L G O L 60. Puesto que los nombres de variables aparecen dentro de

primer intento para proporcionar protección ozyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA encapsulación dentro de los

lenguajes de programación.

A principios de la década de los sesenta, los diseñadores del lenguaje Simula-67 tomaron el concepto de bloque de A L G O L con mayor extensión e introdujeron el concepto de objeto. Aunque las raíces de Simula estuvieron en A L G O L , Simula

fue principalmente proyectado como u n lenguaje de simulación. Así, los objetos en Simula tenían "una existencia propia" y podían (de alguna manera) comunicarse con otros objetos durante la simulación. Conceptualmente, u n objeto contenía datos y operaciones que manipulaban sus datos. Las operaciones fueron llamadas

métodos. Simula también incorporó la noción de clases, la cual era usada para

describir la estructura y comportamiento de u n conjunto de objetos. L a herencia de clase fue también soportada por Simula. Simula puso los fundamentos de los lenguajes Orientados a Objetos y alguna de la terminología de Orientación a Objetos.

A principios de la década de los setenta, el concepto de abstracción de datos fue

estudiado por u n gran número de diseñadores de lenguajes con el propósito de manejar grandes programas. Existen dos aspectos fundamentales de los tipos de datos abstractos. E l primero es agrupar la estructura del tipo con las operaciones definidas para el tipo. Y el segundo aspecto de los tipos de datos abstractos es el

ocultamiento de información, donde los detalles de implantación y representación de

los objetos están ocultos y no pueden ser directamente accesados a través de los usuarios del objeto.

Uno de los más importantes lenguajes de programación que soportaron los tipos de datos abstractos fue A D A . E L Departamento de la Defensa (DoD) de los Estados Unidos comisionó el diseño de A D A para reducir y controlar el costo del desarrollo de software. E l D o D proyectó A D A para ser el lenguaje seleccionado en el desarrollo de nuevos sistemas integrados.

Durante la década de los ochenta, los conceptos de Orientación a Objetos de Smalltalk, Simula y otros lenguajes de Orientación a Objetos comenzaron a surgir y dar nacimiento a nuevos lenguajes Orientados a Objetos con extensiones y dialectos. Se puede ver que, según autores como Khoshafian [KHOS,90] y Bourne [BOUR,92], los lenguajes Orientados a Objetos pueden clasificarse de la siguiente forma:

* Extensiones, dialectos y versiones de Smalltalk.

* Extensiones Orientadas a Objetos a lenguajes convencionales. (Ver tabla 3.1)

* Extensiones de Lisp Orientadas a Objetos. * Otros lenguajes Orientados a Objetos.

Dentro de la primera clasificación ha habido varias propuestas y prototipos para extender Smalltalk con representación de tipos, con herencia múltiple (los dialectos originales de Smalltalk permitían a una clase heredar sólo de u n padre o superclase) o con construcciones de programación concurrente.

En la actualidad, se tienen dos compañías que producen Smalltalk. Por u n lado, se encuentra ParcPlace con el Smalltalk-80; y por el otro, se tiene a Digitalk con Smalltalk/V (la V significa Virtual).

Por otro lado, dentro de la segunda clasificación, se tienen al lenguaje C++, el cual es uno de los lenguajes más populares. Este lenguaje fue diseñado por Bjarne Stroustrup en A T & T a principios de la década de los ochenta. L a primera implantación del lenguaje C++ fue liberada como u n preprocesador para compiladores de C. C++ proporciona dos constructores para definiciones de clases.

El primer método es una extensión del constructorzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA struct y el otro, a través del

nuevo constructor class.

Otro lenguaje popular de C es Objetive-C. Este lenguaje fue creado en 1983 por Productivity Products International (PPI), ahora la Stepstone Company. Este lenguaje es u n superconjunto de C incorporando características de Orientación a Objetos de Smalltalk; para ello usa una versión modificada de la sintaxis de Smalltalk. Tal como Smalltalk, viene con una gran colección de clases predefinidas para simplificar el proceso de desarrollo de software.

las computadoras personales de I B M . Object Pascal fue diseñado por Nicklaus Wirth y u n grupo de ingenieros de la Apple Computer.

Lenguaje Año de

Creación Características primarias

Extensiones hacia Objetos

Fortran 1954 Programación de aplicaciones científicas; implantaciones eficientes.

Ninguna.

Algol 1958 Notación similar a la de Fortran;

fuerte representación de tipos. Ninguna.

Lisp 1958 Notación funcional; ambiente

extenso y rico. Flavors, CLOS, Common Loops

Pascal 1968 Sintaxis simple; fuerte

representación de tipos. Object Pascal, Turbo Pascal.

Smalltalk 1971 Orientado a Objetos; ambiente extenso.

C 1972 Propósito general; débil

representación de tipos. C++, Objective-C.

Prolog 1972 Basado en lógica; declarativo.

Ada 1979 Fuerte representación de tipos;

rico, complejo y extenso. InnovAda.

Tabla 3.1 Lenguajes y sus Orientaciones a Objetos. [BOUR,92]

Continuando con la tercera clasificación, ha habido varias extensiones a Lisp. Algunas de las más notables incluyen a Flavors, el cual es desarrollado por Symbolics; CommonLoops desarrollado por Xerox, Common Objects y C L O S (Common Lisp Object System). Flavors es simplemente una extensión de Lisp que agrega funciones que permite la definición y manejo de objetos. Por su parte, C L O S difiere de Flavors en que está mejor desarrollado y en que contiene numerosas características que Flavors no tiene.

desarrollado por Meyer es una lenguaje Orientado a Objetos que se caracteriza por

tener fuerte representación de tiposzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA (Strongly typed), dicha representación tiene el

propósito de ayudar a los programadores a asegurar la exactitud y robustez de su software. Eiffel corre sobre varias versiones de U N I X y usa C como código intermedio, lo cual hace a Eiffel potencialmente portable a cualquier máquina que ejecute C. Por otro lado, Actor es u n producto de software desarrollado por The Whitewater Group que corre en máquinas de la clase P C y tiene muchos de los atributos de Smalltalk en u n ambiente de computadora personal.

Los lenguajes citados aparecieron antes de la década de los noventa. Pero, ¿ qué podría esperarse para la década de los noventa y para las décadas siguientes ? E n 1982 Rentsch predijo que: "La Programación Orientada a Objetos será en los ochenta lo que la programación estructurada fue en los años setenta" [RENT,82]. Por otro lado, Khoshafian observa que la década de los ochenta se conocerá como: "La década en que fue iniciada en la computación la era de la Orientación a Objetos". Además, agrega que en los noventa los lenguajes, las técnicas, bases de datos e interfases de usuario, llegarán a ser más populares y que mucho del desarrollo de software será afectado por la Orientación a Objetos de una u otra forma. [KHOS,90]

Figura 3.1 Evolución de los Lenguajes Orientados a Objetos [BOOC,91].

Nombre Descripción

Smalltalk-80 Sistema comercial Orientado a Objetos para estaciones de trabajo, PC, Macintosh. De ParcPlace System.

Smalltalk/V Sistema comercial Orientado a Objetos para PC y Macintosh. De Digitalk.

Objetive-C Extensión de C Orientada a Objetos con varias librerías de clases. De Stepstone Corporation.

C++ Es un incremento de C Orientado a Objetos. De AT&T y otros.

Flavors Primitivo desarrollo en el MIT como una extensión Orientada a Objetos de Lisp. Por Weinreb y Monn en 1980.

CLOS Common Lisp Object System - una extensión a Common Lisp. De Franz, Inc., Lucid, Inc. y otros.

Eiffel Lenguaje Orientado a Objetos que enfatiza estructuras de clase. De Interactive Software Engineering.

Actor Un sistema Orientado a Objetos basado en PC con fuertes similitudes a Smalltalk. De The Whitewater Group.

Tabla 3.2 Ejemplos de Lenguajes Orientados a Objetos. [BOUR,92]

3.3 Características generales de un buen lenguaje de Programación.

"Muchos de los lenguajes son demasiado grandes e intelectualmente no manejables. Los problemas aparecen en parte porque el lenguaje es m u y restrictivo; el número de reglas necesarias para definir u n lenguaje se incrementa cuando una regla general tiene reglas adicionales inherentes a restricciones que ésta usa en ciertos casos. (Irónicamente, estas reglas adicionales usualmente hacen al lenguaje menos poderoso.) _ E l principio guía deberá ser: Poder a través de simplicidad, simplicidad a través de generalidad." [MORR,81]

Según Date, este principio guía es frecuentemente referido en los círculos de

diseño de lenguaje como elzyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA principio de ortogonalidad; y comenta: " E l término ortogonalidad se refiere a aquello que debería mejor ser llamado 'concepto de

juntos." Agrega que, la ventaja de la ortogonalidad es que conduce a lenguajes

coherentes; donde u n lenguaje coherente es uno que posee simpleza, limpieza y una

estructura consistente (sintáctica y semántica), una estructura que es fácil de comprender para el usuario.

Para Date, u n lenguaje de programación deberá poseer una rigurosa definición formal que sea independiente de cualquier implantación particular. E l propósito de esta definición es:

1. Proporcionar respuestas precisas y definitivas a preguntas técnicas y por supuesto actuar como arbitro en alguna disputa. 2. Intentar prevenir la posibilidad de implantaciones divergentes e

incompatibles.

3. Servir generalmente como la fuente de referencia para usuarios, escritores de manuales, profesores, implantadores y cualquier otro que esté relacionado con los detalles del lenguaje en alguna ocasión. [DATE,86]

Por otro lado, Horowitz presenta una lista con los 12 criterios mediante los cuales, el diseño de u n lenguaje de programación puede ser evaluado. Esta lista fue dada por Barbara Liskov del M I T y es la siguiente:

1. U n a descripción sintáctica y semántica definida formalmente. 2. Debe ser confiable. Diseñado de tal manera que los errores

lógicos y sintácticos sean evitados y fáciles de descubrir.

3. Rápida interpretación o análisis por el compilador o por el programador.

4. Generación eficiente de código objeto.

5. Ortogonalidad. U n lenguaje debe tener sólo unas cuantas características básicas, cada una de las cuales es comprendida en forma separada y libre de interacciones cuando ellas son combinadas.

6. Independiente de la máquina.

7. Que pueda ser demostrable bajo una verificación formal.

9. Consistencia con las notaciones comúnmente usadas.

10. Tendrá subconjuntos. N o deberá ser entendido todo el lenguaje para usar una parte de él.

11. Uniformidad. Cosas similares deberán tener resultados similares. 12. Extensibilidad. Capacidad para definir estructuras de datos y

operadores adicionales. [HORO,84]

Como se puede observar, los puntos sugeridos por Date están contenidos en la lista dada por Horowitz sobre las características deseables para el diseño de u n buen lenguaje; a estos se podría agregar dos puntos que serían deseables observar:

* E l número de conceptos deberá ser pequeño, para que el lenguaje sea fácil de describir, aprender, implantar y usar.

* E l lenguaje deberá mostrar eficiencia, esto incluye: una verificación estática de tipos, u n analizador independiente de tipos, una compilación independiente, u n ciclo de optimización y el soporte a la representación de conjuntos de caracteres múltiples.

3.4 Características esenciales de u n Lenguaje de Programación Orientado a Objetos.

Los Lenguajes de Programación Orientados a Objetos han llegado a ser muy populares durante los años recientes y pueden encontrarse diferentes variedades de ellos. Además, se puede observar como ha surgido controversia sobre cuáles son las características esenciales que debería soportar u n lenguaje de programación

que aspire a ser llamado:zyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA Orientado a Objetos.

Por otro lado, se puede ver que algunos autores han clasificado los L P O O , entre ellos se puede citar a Wegner quien comenta: "Lenguajes que soportan sólo

objetos son llamadoszyxwvutsrqponmlkjihgfedcbaZYXWVUTSRQPONMLKJIHGFEDCBA basados en objetos, mientras que, los lenguajes que

adicionalmente soportan clases y herencia son llamados Orientados a Objetos."

[WEGN,92]

Otros autores, han definido las características que debe cubrir u n L P O O , a continuación se citan algunos de ellos.

Pinson señala: " U n Lenguaje Orientado a Objetos ha sido definido como u n lenguaje que soporta las cuatro propiedades de objeto: abstracción, encapsulamiento, herencia y polimorfismo." [PINS,88]

Por su parte, Pascoe dice: " U n lenguaje debe tener cuatro elementos para soportar la Programación Orientada a Objetos: ocultamiento de información, abstracción de datos, ligamiento dinámico (dynamic binding) y herencia. (Algunos

lenguajes que tienen una o dos de estos elementos han sido llamados inapropiadamente Orientados a Objetos.)" [PASC,86]

Por otro lado, Meyer [MEYE,88] comenta que u n verdadero Lenguaje de Programación Orientado a Objetos debe cumplir las siguientes características:

* Estructura modular basada en Objetos. * Abstracción de datos.

* Administración automática de memoria. * Clases.

* Herencia.

* Polimorfismo y ligamiento dinámico (dynamic binding).

* Herencia múltiple y repetible.