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

Texto completo

(1)

(2) ESTUDIO C O M P A R A T I V O D E L E N G U A J E S D E PROGRAMACIÓN O R I E N T A D O S A OBJETOS B A S A D O E N L A S FACILIDADES P A R A IMPLANTAR EL C O N C E P T O D E OBJETO. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY POR J U A N A N T O N I O MACÍAS GUERRERO.

(3) ESTUDIO COMPARATIVO DE LENGUAJES DE PROGRAMACIÓN ORIENTADOS A OBJETOS BASADO EN LAS FACILIDADES PARA IMPLANTAR EL CONCEPTO DE OBJETO. 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. M A Y O 1994.

(4) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE GRADUADOS E INVESTIGACIÓN 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: Ing. Juan R. Esparza Martínez, M . C . ASESOR PRINCIPAL. Dr. José Ignacio Icaza Acereto.. SINODAL. Lic. Teresa Lucio Nieto, M . C . SINODAL. Dr. Ramón Brena Pinero Director de la Maestría de Sistemas Computacionales. Mayo de 1994.

(5) ESTUDIO COMPARATIVO DE LENGUAJES DE PROGRAMACIÓN ORIENTADOS A OBJETOS BASADO EN LAS FACILIDADES PARA IMPLANTAR EL CONCEPTO DE OBJETO. 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. M A Y O DE 1994.

(6) Todo lo que es necesario saber para vivir, "como hacer" y "como ser", lo aprendí en el jardín de niños. L a sabiduría no se encuentra al final de la maestría universitaria, sino en la pila de arena del jardín de niños. Esto es lo que aprendí: Comparte todo, juega limpio, no golpees a las personas, p o n las cosas donde las encontraste, limpia t u 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. V i v e 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 m u n d o , p o n atención, tómate de las manos y permanece unido. Toma cualquiera de estos puntos y aplícalos al sofisticado m u n d o 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í.. Robert Fulghum.

(7) v. DEDICATORIA. 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 M I S 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 ALEJANDRO Gracias por aceptarme; por brindarme su amor, comprensión. Los amo y me siento orgulloso de cada uno.. aliento. y. A M I NOVIA, A L M A ROSA 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 me han brindado en todo momento..

(8) RECONOCIMIENTOS. 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 D r . José Ignacio Icaza, gracias por su apoyo, conocimientos y por sus breves, pero m u y atinadas observaciones. A l D r . Pérez, gracias por su ayuda y comentarios sobre este trabajo. A l Conacyt, gracias por su apoyo.. vi.

(9) RESUMEN.. 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.. vii.

(10) Contenido. Lista de Figuras. xi. Lista de Tablas. xii. Capítulo 1 Introducción. 1.1. Antecedentes de la Orientación a Objetos. 1. 1.2 1.3 1.4. Objetivo de la Tesis e Importancia de la Investigación Alcance y limitaciones de la tesis Organización de la tesis. 2 3 3. Capítulo 2 El paradigma de Orientación a Objetos. 2.1. Historia del paradigma de Orientación a Objetos. 5. 2.2 2.3. ¿ Qué es la Orientación a Objetos ? Características del paradigma de Orientación a Objetos 2.3.1 ¿ Qué es u n Objeto ? 2.3.2 ¿ Qué es y qué no es una clase ? 2.3.3 Herencia 2.3.4 Polimorfismo 2.3.5 Abstracción 2.3.6 Operación, Método y Mensaje 2.3.7 Encapsulación Análisis Orientado a Objetos (AOO) Diseño Orientado a Objetos (DOO) Programación Orientada a Objetos (POO) Conclusiones acerca del paradigma de Orientación a Objetos. 5 7 7 9 10 13 13 14 15 16 17 19 21. 2.4 2.5 2.6 2.7. viii.

(11) ix. Capítulo 3 Los Lenguajes de Programación Orientados a Objetos (LPOO). 3.1 3.2 3.3 3.4 3.5 3.6. Lenguajes de programación historia y evolución Lenguajes de Programación Orientados a Objetos historia y evolución Características generales de u n buen lenguaje de Programación Características esenciales de u n Lenguaje de Programación Orientado a Objetos Características a evaluar de u n Lenguaje de Programación Orientado a Objetos Conclusiones sobre los Lenguajes de Programación Orientados a Objetos. 23 25 31 33 36 37. Capítulo 4 Definición e Implantación de la Prueba en los Lenguajes de Programación Orientados a Objetos (LPOO). 4.1 4.2 4.3 4.4. Terminología Empleada en los Lenguajes de Programación Orientados a Objetos (LPOO) Definición de la prueba para los Lenguajes de Programación Orientados a Objetos (LPOO) Definición de los L P O O seleccionados para aplicarles la prueba Descripción de cómo se aplicó la prueba a los L P O O 4.4.1 Descripción de la implantación de la prueba en Turbo C++ 4.4.1.1 Implantación del ejemplo de Herencia Múltiple en Turbo C++ 4.4.2 Descripción de la implantación de la prueba en Smalltalk80 4.4.3 Descripción de la implantación de la prueba en Turbo Pascal 4.5 Conclusiones acerca de la prueba aplicada a los Lenguajes de Programación Orientados a Objetos (LPOO). 39 40 45 45 46 52 62 68 75.

(12) X. Capítulo 5 Conclusiones. 5.1 5.2 5.3. Conclusiones globales Aportación principal Trabajo para Futuras Investigaciones. 78 81 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. A . 2 Implantación del ejemplo que usa Herencia Múltiple en Turbo C++. 83 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. Vita. 104.

(13) xi. Lista de Figuras.. Capítulo 2 Figura Figura Figura Figura. 2.1 2.2 2.3 2.4. Objetos Clasificación Herencia y herencia múltiple (líneas punteadas) Envío de Mensaje. 8 10 12 15. Evolución de los Lenguajes Orientados a Objetos. 30. Clases que se definirán en la prueba a los L P O O Clases del ejemplo de Herencia Múltiple Ejemplo del uso (A) y no uso (B) de clase base virtual Jerarquía de clases para aplicaciones en Smalltalk 80. 42 54 60 63. Capítulo 3 Figura 3.1. Capítulo 4 Figura Figura Figura Figura. 4.1 4.2 4.3 4.4.

(14) xii. Lista de Tablas.. Capítulo 3 Tabla 3.1 Tabla 3.2 Tabla 3.3. Lenguajes y sus Orientaciones a Objetos Ejemplos de Lenguajes Orientados a Objetos Características deseables propuestas para u n L P O O por autor. 28 31. Control de acceso a la secciones de una clase Tabla comparativa de L P O O. 47 75. 35. Capítulo 4 Tabla 4.1 Tabla 4.2.

(15) Capítulo 1 Introducción.. 1.1. Antecedentes de la Orientación a Objetos.. E l 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 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.. ambiente. computacional usando. 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 objeto, lo cual es la base para que este paradigma sea entendido y aprovechado totalmente. Por otra parte, los primeros en aparecer dentro del m u n d o 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 1.

(16) 2. 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. E l objetivo de esta tesis es brindar u n panorama que permita ver comparativamente qué tanto u n 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 u n Lenguaje de Programación Orientado a Objetos. Y además, ayuda a aclarar cuales lenguajes son realmente Orientados a Objetos. Es de vital importancia para cualquier empresa o institución educativa conocer y entender el funcionamiento de las nuevas herramientas y metodologías; la tecnología Orientada a Objetos es u n nuevo enfoque en el desarrollo de software, el cual según algunos autores entre ellos Yourdon, llegará a ser de gran utilidad en.

(17) 3. muchas empresas, las cuales deberán ante todo tener u n cambio cultural más que tecnológico [YOUR,90]. E l 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 l a 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 I T E S M , campus Monterrey.. 1.4. Organización de l a tesis.. L a 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. E n el tercer capítulo se muestra cómo ha sido la evolución de los lenguajes de programación en general; cómo han evolucionado los Lenguajes de Programación Orientados a Objetos; se describen las características para el diseño de u n lenguaje.

(18) 4. 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. Por último, en los Apéndices A , B y C se tiene el código fuente de los programas realizados para la prueba en Turbo C++, Smalltalk-80 y Turbo Pascal respectivamente..

(19) Capítulo 2 El paradigma de Orientación a Objetos.. 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.. L a 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 C o x , quien dice: " L a 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: " L a 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: 5.

(20) 6. Orientación a Objetos. =. Tipos de datos abstractos. +. Herencia. +. Identidad de objetos.. Por otro lado, Rumbaugh dice: " E l 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 E d w a r d Yourdon, la Orientación a Objetos es u n término difícil, porque el término objeto ha sido usado de diversas maneras dentro de dos m u y 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 n la literatura consultada se pudo observar que la mayoría de las definiciones acerca del paradigma de Orientación a Objetos, hablan de u n nuevo enfoque o una nueva manera de pensar acerca de los problemas, usando modelos organizados alrededor de conceptos del mundo real. E l elemento fundamental en este nuevo enfoque es el objeto, el cual combina estructuras de datos y conducta en una entidad simple. Se destaca que la manera de analizar los problemas desde una perspectiva más cercana al mundo real, ayuda a que éstos sean expresados fácil y naturalmente..

(21) 7. 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 ?. C o m o 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. A l g o visible o tangible; u n producto material o sustancia." [WEBS,91] Para Yourdon, u n objeto es: "Una 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] Por otro lado, según Bourne, los objetos pueden representar abstracciones de cosas materiales o aun conceptos abstractos. [BOUR,92].

(22) 8. 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.. Figura 2.1 Objetos..

(23) 9. 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. U n a 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, u n 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. U n a 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. L a figura 2.2 muestra la clase polígono; algunas instancias u objetos de dicha clase; y los atributos y operaciones de la clase..

(24) 10. 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] Por su parte, Rumbaugh define la herencia de la siguiente manera: "La herencia es la compartición de atributos y operaciones entre clases basado en relaciones.

(25) 11. jerárquicas. U n a clase puede ser definida de una manera m u y general y entonces clarificarla sucesivamente en clases más finas. Cada 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 u n elemento esencial de los sistemas Orientados a Objetos y la define de la siguiente manera: " L a 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] Finalmente, como resultado de las definiciones anteriores, se puede decir que la herencia permite compartir atributos y conductas de una o más clases previamente definidas, con una nueva clase; todo esto dentro de una jerarquía de clases. Las subclases pueden cambiar o agregar las estructuras y conductas heredadas de la o las superclases (herencia simple y múltiple respectivamente). Esta facilidad ayuda al reuso, que es una de las características que hace al paradigma de Orientación a Objetos superior a los paradigmas tradicionales, según algunos autores. E n la figura 2.3 se muestra u n ejemplo de herencia..

(26) 12. Figura 2.3 Herencia y herencia múltiple (líneas punteadas) [BOUR,92]..

(27) 13. 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: " L a capacidad de diferentes objetos para responder en una manera apropiada al mismo mensaje." [BOUR,92] Por otro lado, para Rumbaugh este término significa: " L a 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 m u y 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ón 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: " L a 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] Mientras que, Rumbaugh dice: "La abstracción es una facilidad mental que permite a los humanos ver los problemas del mundo real con una variación en los grados de detalle dependiendo del contexto actual del problema. Consiste en enfocarse sobre lo esencial, aspectos inherentes de una entidad e ignorar las propiedades accidentales." [RUMB,91].

(28) 14. 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érminos 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: " L a implantación de una operación para una clase específica"; y u n mensaje es: " L a 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 invocación de una operación y está constituido por el nombre de la operación y una lista de valores argumentos. Además, existe una diferencia entre operación y.

(29) 15. método los cuales, son vistos por algunos autores como iguales; una 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] Otra definición dice así: "Encapsulación (ocultamiento de información). Es u n principio usado cuando se está desarrollando la estructura total de u n programa, de este modo, cada componente de u n programa debe encapsular u ocultar una simple decisión de diseño ...La inferíase para cada módulo está definida de tal manera que revela tan poco como sea posible su trabajo interno." [OXFO,86].

(30) 16. Por otra lado, Cox define la encapsulación de la siguiente manera: " L a encapsulación significa que el cliente ve sólo los servicios que están disponibles de u n 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: " L a 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] Por su parte, para Rumbaugh, el propósito del Análisis Orientado a Objetos es: "Modelar los sistemas del mundo real y así, éstos puedan ser comprendidos. Para hacer la modelación, se debe examinar los requerimientos, analizar sus implicaciones y reenunciar los requerimientos rigurosamente. Primeramente, se debe abstraer las características importantes del mundo real y aplazar los.

(31) 17. pequeños detalles para después. U n modelo de análisis exitoso declara 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.. *. L a identificación de estructuras.. *. L a identificación de temas o tópicos.. *. L a 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 m u n d o 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. A h o r a , 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, primero en u n nivel alto, y entonces incrementalmente detallando niveles..

(32) 18. Según C o x , las personas que están m u y 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 vista 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] Por otro lado, Yourdon define al Diseño Orientado a Objetos de la siguiente manera: " L a práctica de tomar las especificaciones de una conducta externamente observable y agregar los detalles necesarios para la implantación en u n sistema de.

(33) 19. 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 f i n del D O O es crear una representación del dominio del problema que pueda ser transformada en software; para ello, se toma en cuenta 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: L a Programación Orientada a Objetos es definida por Booch como: " U n método de implantación en el cual, los programas son organizados como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna.

(34) 20. 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 de 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: L a definición dada por Lafore a la Programación Orientada a Objetos es la siguiente: " L a Programación Orientada a Objetos es una forma de organizar los programas. E l énfasis se hace sobre la manera en que son diseñados los.

(35) 21. 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 B u d d , la cual dice: " L a 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 Libro 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.. Como se ha podido observar, el paradigma de Orientación a Objetos es algo más que una nueva característica en el desarrollo de sistemas de software; es u n cambio de pensamiento en la manera de desarrollar software mediante el uso de modelos organizados alrededor de conceptos del mundo real. E l elemento esencial del paradigma es el concepto de objeto, dentro del cual se incorporan estructuras.

(36) 22. 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.. Estas características son propuestas por algunos autores, en el siguiente capítulo se abordarán con más detalle los Lenguajes de Programación Orientados a Objetos, y se buscará establecer las características esenciales que deberán ser soportadas por cualquier lenguaje para poder ser considerado como Orientados a Objetos. C o n base en tales características, se diseñará y aplicará una prueba para la muestra de lenguajes seleccionados; con los resultados que arroje la aplicación de la prueba se elaborará la tabla comparativa..

(37) Capítulo 3 Los Lenguajes de Programación Orientados a Objetos (LPOO).. C o m o 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 L P O O ) ; 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ía 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 m u y 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. 23.

(38) 24. 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 tipos (Stronglytyped: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. A principio de la década de los setenta fue desarrollado el lenguaje C por Dermis Ritchie en los Laboratorios Bell; el cual se ha convertido en las décadas.

(39) 25. 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-abajo (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 evolución.. de. Programación. Orientados. a. Objetos. historia. y. L a 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 u n bloque son conocidos sólo para este bloque, su uso no creará conflicto con el uso de] mismo nombre de variable en otros bloques del programa. Este fue el.

(40) 26. primer intento para proporcionar protección o encapsulación dentro de los lenguajes de programación. A principios de la década de los sesenta, los diseñadores del lenguaje Simula67 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. U n o 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 los años setenta y ochenta, los conceptos de Orientación a Objetos de Simula y de otros de los primeros prototipos, fueron incorporados en uno de los lenguajes Orientados a Objetos más influyentes: Smalltalk. Smalltalk fue inicialmente u n proyecto de investigación en Xerox Palo A l t o Research Center (Xerox P A R C ) . Durante los años setenta, u n grupo de investigadores de Xerox P A R C fueron revolucionando el futuro de la industria de la computación. Los investigadores de Xerox P A R C inventaron o solidificaron muchas tecnologías ahora reconocidas como Orientadas a Objetos, en el dominio de los lenguajes y las interfases de usuario. E l lenguaje Smalltalk incorpora muchas de las características de Orientación a Objetos de Simula, incluyendo clases, herencia y el soporte de identidad de objeto..

(41) 27. 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. E n 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 S m a l l t a l k / 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. E l primer método es una extensión del constructor 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. Por otro lado, las extensiones Orientadas a Objetos de Pascal incluyen: Object Pascal para la Macintosh de la A p p l e Computer y Turbo Pascal de Borland para.

(42) 28. las computadoras personales de I B M . Object Pascal fue diseñado por Nicklaus W i r t h y u n grupo de ingenieros de la A p p l e 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; Ninguna. fuerte representación de tipos.. 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.. Prolog. 1972. Basado en lógica; declarativo.. Ada. 1979. Fuerte representación de tipos; rico, complejo y extenso.. C++, Objective-C.. 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, C o m m o n 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. Existe u n cierto número de lenguajes Orientados a Objetos que no fácilmente entran en alguna de las tres categorías anteriormente listadas. Por ejemplo, Eiffel.

(43) 29. desarrollado por Meyer es una lenguaje Orientado a Objetos que se caracteriza por tener fuerte representación de tipos (Stronglytyped),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] L a figura 3.1 muestra la evolución de los Lenguajes de Programación Orientados a Objetos..

(44) 30. Figura 3.1 Evolución de los Lenguajes Orientados a Objetos [BOOC,91].. Por último, la tabla 3.2 muestra algunos de los Lenguajes de Programación Orientados a Objetos, las plataformas bajo las cuales trabajan y la compañía que los produce..

(45) 31. 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 el principio de ortogonalidad; y comenta: " E l término ortogonalidad se refiere a aquello que debería mejor ser llamado 'concepto de independencia': Conceptos distintos deberían siempre estar claramente separados, nunca.