capitulo 1 Fundamentos de programacion orientada a...

Fundamentos de Programación Orientada a Objetos

Página 1 Ing. Isis Espinosa Salazar

I.- FUNDAMENTOS DE PROGRAMACIÓN ORIENTADA A OBJETOS 1.1 Evolución de la programación 1.2 Conceptos fundamentales de la Programación Orientada a Objetos

1.2.1 Los lenguajes orientados a objetos 1.3 Relaciones entre clases y objetos 1.4 El papel de clases y objetos en el análisis y el diseño



I.- FUNDAMENTOS DE PROGRAMACIÓN ORIENTADA A OBJETOS 1.1 Evolución de la programación 1.2 Conceptos fundamentales de la Programación Orientada a Objetos

1.2.1 Los lenguajes orientados a objetos 1.3 Relaciones entre clases y objetos 1.4 El papel de clases y objetos en el análisis y el diseño

1.1 Evolución de la programación • La evolución de la programación puede sintetizarse en tres modelos o paradigmas:

El significado de paradigma (paradigma en latín; paradeigma en griego) en su origen significaba un ejemplo ilustrativo; en particular, enunciado modelo que mostraba todas las inflexiones de una palabra. Un paradigma es una forma establecida de pensar acerca de cómo hacer algo. En el libro The Structure of Scientific Revolutions, el historiador Thomas Kuhn describía un paradigma como un conjunto de teorías, estándares y métodos que juntos representan un medio de organización del conocimien-to: es decir, un medio de visualizar el mundo.

La programación mediante procedimientos (procedural), La programación estructurada y La programación orientada a objetos

PROGRAMACION MEDIANTE PROCEDIMIENTOS [PROCEDURAL]

Programación y abstracción • La abstracción es el proceso de extraer las propiedades relevantes de un objeto al tiempo que se ignoran los detalles

no esenciales. Las propiedades extraídas definen una vista del objeto. En esencia, la abstracción supone la capaci-dad de encapsular y aislar, la información del diseño, de la ejecución.

• Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser y, a

continuación, utilizar esta descripción en un programa. • La abstracción es fundamental para gestionar la complejidad del diseño y escritura del software. La abstracción es la

clave para diseñar buen software. La abstracción es uno de los medios más importantes, mediante el cual nos enfren-tamos con la complejidad inherente al software.

• Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial

de un objeto de su implementación • Como describe Wulft: «Los humanos hemos desarrollado una técnica excepcionalmente potente para tratar la comple-

jidad: abstraemos de ella. Incapaces de dominar en su totalidad los objetos complejos, se ignora los detalles no esen-ciales, tratando en su lugar con el modelo ideal del objeto y centrándonos en el estudio de sus aspectos esenciales.»

• El proceso de abstracción fue evolucionando desde la aparición de los primeros lenguajes de programación. • La abstracción es esencial para el funcionamiento de una mente humana normal y es una herramienta muy potente

para tratar la complejidad. El método más idóneo para controlar la complejidad es aumentar los niveles de abstracción. • Las personas normalmente comprenden el mundo construyendo modelos mentales de partes del mismo; tratan de

comprender cosas con las que pueden interactuar. Un modelo mental es una vista simplificada de cómo funciona, de modo que se pueda interactuar con ella.

• En esencia, este proceso de construcción de modelos es lo mismo que el diseño de software, aunque el desarrollo de

software es único: el diseño de software produce el modelo que puede ser manipulado por una computadora. • Sin embargo, los modelos mentales deben ser más sencillos que el sistema al cual imitan, o en caso contrario serán

inútiles. Por ejemplo, consideremos un mapa como un modelo de su territorio. A fin de ser útil, el mapa debe ser más sencillo que el territorio que modela. Un mapa nos ayuda, ya que abstrae sólo aquellas características del territorio que deseamos modelar. Un mapa de carreteras modela cómo conducir mejor de una posición a otra. Un mapa topográfico modela el contorno de un territorio, quizá para planear un sistema de largos paseos o caminatas.



• De igual forma que un mapa debe ser más pequeño significativamente que su territorio e incluye sólo información seleccionada cuidadosamente, así los modelos mentales abstraen esas características de un sistema requerido para nuestra comprensión, mientras ignoran características irrelevantes. Este proceso de abstracción es psicológicamente necesario y natural: la abstracción es crucial para comprender este complejo mundo.

• Un conjunto se puede definir por abstracción como una colección no ordenada de elementos en el que no existen

duplicados. Utilizando esta definición, se puede especificar si sus elementos se almacenan en un arreglo, una lista en-lazada o cualquier otra estructura de datos.

• Un vendedor de coches podría ver un coche desde el punto de vista de sus características de venta. Propiedades

relevantes serían el precio, el color, el equipo opcional y la duración de la garantía. Por otro lado, un mecánico vería el coche desde el punto de vista de los sistemas que necesitan mantenimiento. Para él, propiedades relevantes serían el motor, sistema electrónico de encendido, tipo de aceite, el tamaño del filtro de aceite y el número y tipo de bujías. Las propiedades relevantes de un objeto vienen definidas por la forma en que se usa o manipula el objeto.

• Claramente las propiedades de un coche, importantes para un vendedor, son distintas de las de un mecánico. En-

focándose sobre las propiedades relevantes e ignorando los detalles irrelevantes, se puede reducir la complejidad de manejo de un objeto.

• Consideremos la tarea de encontrar un archivo en un disco y leer su contenido. Si tuviésemos que manejar todos los

detalles de bajo nivel para saber cómo encontrar un archivo concreto en el disco y cómo leer sus contenidos, sería una tarea bastante difícil. Deberíamos comprender cómo se almacenan los datos en los discos y todos los mandatos de ba-jo nivel que controlan las operaciones del manejador de disco. Afortunadamente, existe un sistema de archivos que proporciona una visión abstracta de la información en un disco, de forma que se pueden ignorar los detalles de bajo ni-vel. Se puede acceder al archivo sin más que proporcionar su nombre. El sistema de archivos maneja los detalles de bajo nivel para leer los datos en el disco y devolverlos al programa.

• El arte de la programación es el método por el que se describirá a una computadora (mediante un lenguaje de pro-

gramación) un fenómeno, una acción, un comportamiento o una idea. En general, un programa no es más que una descripción abstracta de un procedimiento o fenómeno que existe o sucede en el mundo real. Frecuentemente, un programa imita un comportamiento o acción humana; otras veces simula (es decir, reproduce) un fenómeno físico.

• Sin embargo, la relación entre abstracción y lenguaje de programación es doble: por un lado se utiliza el lenguaje de programación para escribir un programa que es una abstracción del mundo real; por otro lado se utiliza el lenguaje de programación para describir de un modo abstracto el comportamiento físico de la computadora que se está utilizando (por ejemplo, utilizando números decimales en lugar de números binarios, variables en lugar de celdas de memoria di-reccionadas explícitamente, etc.).

• En los primeros días de la informática, los programadores enviaban instrucciones binarias a una computadora, manipu-lando directamente interrupciones en sus paneles frontales.

• En la década de los cincuenta, los únicos mecanismos de abstracción eran el lenguaje de máquina y el lenguaje en-

samblador. El lenguaje ensamblador ofrecía la posibilidad de utilizar mnemónicos, que eran abstracciones diseñadas para evitar que los programadores tuvieran que recordar las secuencias de bits que componen las instrucciones de un programa. Ofrece también la posibilidad de utilizar nombres simbólicos para representar celdas de memoria.

• El siguiente nivel de abstracción se consigue agrupando instrucciones primitivas para formar macroinstrucciones. Un

conjunto de instrucciones realizadas por un usuario se pueden invocar por una macroinstrucción; una macroinstrucción instruye a la máquina para que realice muchas cosas.

• Tras los lenguajes de programación ensambladores aparecieron los lenguajes de programación de alto nivel, que

supusieron un nuevo nivel de abstracción. • Los lenguajes de programación de alto nivel permitieron a los programadores distanciarse de las características arqui-

tectónicas específicas de una máquina dada. Cada instrucción en un lenguaje de alto nivel puede invocar varias ins-trucciones máquina, dependiendo de la máquina específica donde se compila el programa. Esta abstracción permitía a los programadores escribir software para propósito genérico, sin preocuparse sobre qué máquina ejecutaría el progra-ma.

• Secuencias de sentencias de lenguajes de alto nivel se pueden agrupar en procedimientos y se invocan por una sen-

tencia. • El mundo en que vivimos se halla plagado de objetos: aviones, trenes, automóviles, teléfonos, libros, computadoras,

etcétera. Sin embargo, en esa época las técnicas de programación no reflejaban esto. Lo procedural [procedimientos] fue el paradigma principal de la programación, el cual define un programa como un algoritmo escrito en algún lenguaje de programación. Las razones de este énfasis son principalmente históricas.



• Desde la época de su desarrollo, durante los años cuarenta, las computadoras fueron utilizadas por los matemáticos con propósitos militares: el cálculo de trayectorias de bombas y la decodificación de transmisiones hecha por el enemi-go o por diplomáticos son algunos ejemplos de estos propósitos. Después de la segunda guerra mundial, las computa-doras todavía eran utilizadas, principalmente, por los matemáticos para resolver problemas con su disciplina. Este pa-norama se reflejó en el primer lenguaje de programación de alto nivel comercialmente disponible, el cual se introdujo en 1957. Este lenguaje fue FORTRAN, cuyas siglas son un acrónimo para FORmula TRANslation (traducción de fórmulas).

• Un reflejo adicional de este uso predominante es el hecho de que en los años sesenta casi todos los cursos de compu-

tación se impartían en los departamentos de ingeniería o matemáticas. El término de ciencia de la computación todavía no era de uso común y los departamentos de ciencia de la computación se encontraban en desarrollo.

• Esta situación sufrió un cambio drástico principalmente por dos razones. Una de las desventajas con los programas

orientados a procedimientos es el fracaso de los lenguajes tradicionales basado en procedimientos en proporcionar medios adecuados para limitar el costo del software, lo cual incluye todos los costos asociados al desarrollo inicial del programa y su mantenimiento subsecuente.

• La inversión en sofware contribuye en gran medida a los costos totales del proyecto porque están relacionados direc-

tamente con la productividad humana (son sensibles al esfuerzo laboral), mientras que el costo asociado al hardware se relaciona con la tecnología de fabricación. Por ejemplo, los microchips que se adquirían por más de 500 dólares hace diez años, ahora se pueden comprar por menos de un dólar.

• Es mucho más fácil, aumentar drásticamente la productividad de fabricación en un 1000% con la consecuente reduc-

ción en costo del hardware, que los programadores dupliquen la cantidad o la calidad del código que producen. Si bien los costos del hardware se desplomaron, la productividad de software y los costos relacionados con su desarrollo per-manecieron relativamente constantes.

• Otra de las desventajas de la programación basada en procedimientos fue la aparición de pantallas gráficas y el interes

subsecuente en las aplicaciones utilizando ventanas. El acceso a una interfaz gráfica de usuarios (GUI) donde un usuario puede moverse con facilidad alrededor de una sola ventana es un desafío cuando se intenta lograrlo con un código procedural. La programación múltiple y las posibles ventanas que se traslapan en una misma pantalla gráfica simplemente aumenta la enorme complejidad cuando se utiliza código procedural.

• Las razones anteriores movitaron la búsqueda de nuevas soluciones o mejoras a la programación mediante procedi-

mientos, lo que condujo a la programación estructurada.

PROGRAMACION ESTRUCTURADA

• Durante la década de los sesenta, muchos de los grandes esfuerzos para el desarrollo de software encontraron seve-ras dificultades:

Los tiempos del desarrollo de software generalmente se retrasaban Los costos rebasaban en gran medida a los presupuestos y Los productos terminados no eran confiables

• La gente comenzó a darse cuenta de que el desarrollo de software era una actividad mucho más compleja de lo que

habían imaginado. Las actividades de investigación en la década de los sesenta dieron como resultado la evolución de la programación mediante procedimientos a la programación estructurada, un método disciplinado para escribir pro-gramas que son:

Más claros Fáciles de probar y corregir y Más fáciles de modificar que los no estructurados

Estas mejoras de la programación mediante procedimientos condujeron a nuevos conceptos como son: Estructuras de control, funciones y módulos.

Estructuras de control

• Tal como los arquitectos diseñan edificios empleando la sabiduría colectiva de su profesión, así deberían los progra-madores diseñar sus programas. Nuestro campo es más joven que la arquitectura y nuestra sabiduría colectiva es considerablemente menor.



• Aprendimos que la programación estructurada produce programas que son más fáciles de entender, probar, corregir, modificar, e incluso comprobar en el sentido matemático, que los programas que no están estructurados.

• La figura 1.1 utiliza diagramas de actividad (o de flujo) para resumir las estructuras de control. • Los estados inicial y final indican la entrada y salida sencillas de cada estructura de control. • Conectar de manera arbitraria símbolos individuales en un diagrama de actividad puede provocar que los programas

no estén estructurados. • Por lo tanto, la profesión de computación eligió un conjunto limitado de estructuras de control que se pueden combinar

solamente de dos sencillas maneras para construir programas estructurados.

Figura 1.1. Estructuras de secuencia de entrada sencilla/salida sencilla, selección y repetición de C++.

• Por simplicidad, solamente se utilizan estructuras de entrada sencilla /salida sencilla; sólo existe una forma de entrar y

una forma de salir de cada estructura de control. • Conectar estructuras de control en secuencia para formar programas estructurados es sencillo, el estado final de una

estructura de control se conecta con el estado inicial de la siguiente estructura de control, esto es, las estructuras de control se colocan una sobre la otra en el programa. A esto le llamamos apilar estructuras de control.

• Las reglas para formar programas estructurados permiten, además, anidar estructuras de control. • La figura 1.2 muestra las reglas para formar programas estructurados. Además, las reglas suponen que comenzamos

con el diagrama de actividad más sencillo (figura 1.3), el cual consiste solamente en un estado inicial, un estado de ac-ción, un estado final y flechas de transición.



Reglas para formar programas estructurados

1. Comience con el diagrama de actividad más sencillo (figura 1.3). 2. Cualquier estado de acción se puede reemplazar por dos estados de acción en secuencia. 3. Cualquier estado de acción se puede representar mediante cualquier estructura de control (secuencia, if, if/else,

switch, while, do/while o for). 4. Las reglas 2 y 3 se pueden aplicar con la frecuencia que usted desee, en cualquier orden.

Figura 1.2. Reglas para formar programas estructurados.

Figura 1.3. Diagrama de actividad más sencillo.

• Aplicando las reglas de la figura 1.2 se produce un diagrama de actividad con la apariencia de una cuidadosa cons-trucción con bloques.

• Por ejemplo, al aplicar de manera repetida la regla 2 al diagrama de actividad más sencillo, provoca un diagrama de

actividad que contiene muchos estados de acción en secuencia (figura 1.4). • La regla 2 genera una pila de estructuras de control, de manera que llamaremos a la regla 2 la regla del apilado. • [Nota: Las líneas verticales punteadas de la figura 1.4 no son parte del UML. Las utilizamos para separar los cuatro

diagramas de actividad que muestran la aplicación de la regla 2 de la figura 1.2.]

Figura 1.4. Aplicación repetida de la regla 2 de la figura 1.2 al diagrama de actividad más sencillo.

• La regla 3 se llama regla de anidamiento. • Al aplicar de manera repetida la regla 3 al diagrama de actividad más sencillo, provoca un diagrama de actividad con

estructuras de control anidadas más pulcras. • Por ejemplo, en la figura 1.5 el estado de acción del diagrama de actividad más sencillo se reemplaza con una estruc-

tura de selección doble (if/else). • Entonces, la regla 3 se aplica de nuevo a los estados de acción en la estructura de selección doble, y reemplaza cada

uno de estos estados de acción con una estructura de selección doble. • Los símbolos punteados de estados de acción alrededor de cada una de las estructuras de selección doble represen-

tan el estado de acción que se reemplazó en el diagrama de actividad más simple original.



• [Nota: Las flechas punteadas y los símbolos de estados de acción punteados que aparecen en la figura 1.5 no son parte del UML. Aquí los utilizamos como ayudas pedagógicas para mostrar que cualquier estado de acción se puede representar mediante una estructura de control].

Figura 1.5. Aplicación repetida de la regla 3 de la figura 1.2 al diagrama de actividad más sencillo

• La regla 4 genera estructuras anidadas más grandes, más involucradas y más profundas. • Los diagramas que surgen de la aplicación de las reglas de la figura 1.2 constituyen un conjunto de todos los diagra-

mas de actividad posibles y, por lo tanto, el conjunto de todos los posibles programas estructurados. • La belleza del método estructurado es que utilizamos sólo siete estructuras de control de entrada sencilla/salida senci-

lla y las ensamblamos solamente de dos maneras posibles. • Si se siguen las reglas de la figura 1.2, no se puede escribir un diagrama de actividad con sintaxis incorrecta (tal como

el de la figura 1.6). • Si no está seguro de si un diagrama en particular es correcto, aplique las reglas de la figura 1.2 a la inversa, para

reducir el diagrama al diagrama de actividad más sencillo. Si el diagrama se reduce al diagrama de actividad más sen-cillo, el original está estructurado, de lo contrario, no lo está.



Figura 1.6. Diagrama de actividad con sintaxis no permitida.

Resumiendo

• Los resultados de Bohm y Jacopini indican que sólo se necesitan tres formas de estructuras de control:

Secuencia. Selección. Repetición.

• La estructura de secuencia es trivial. Simplemente liste las instrucciones a ejecutar, en el orden en el que se deben ejecutar:

• La selección se implementa en una de estas tres maneras:

Estructura if (selección simple). Estructura if/else (selección doble). Estructura switch (selección múltiple).

• De hecho, es bastante sencillo probar que la estructura if sencilla es suficiente para proporcionar cualquier forma de selección, todo lo que se puede hacer con la estructura if/else y la estructura switch se puede implementar mediante la combinación de estructuras if (aunque quizá no sea tan claro y eficiente).

• La repetición se implementa en una de estas tres formas:

estructura while. estructura do/while. estructura for.

• Es sencillo probar que la estructura while es suficiente para proporcionar cualquier forma de repetición. Todo lo que se puede hacer con una estructura do/while y con la estructura for, se puede hacer con la estructura while (aunque quizá no de manera sencilla).

• La combinación de estos resultados muestra que cualquier forma de control necesaria en un programa en C++ se

puede expresar en términos de las siguientes estructuras de control:

secuencia. estructura if (selección). estructura while (repetición).

• Estas estructuras de control se pueden combinar solamente de dos maneras, apiladas o anidadas. En realidad, la programación estructurada promueve la simplicidad. La programación estructurada alienta el uso de abstracciones de control, tales como ciclos, sentencias if-then, que se han incorporado en lenguajes de alto nivel. Estas sentencias de control permitieron a los programadores abstraer las condiciones comunes para cambiar la secuencia de ejecución.

• Nuestro objetivo es explicar cómo crear programas a partir de estructuras de control que contienen estados de acción y

decisión. • Veremos a continuación otra unidad de programación estructurada llamada función. Aprenderemos a crear programas

grandes mediante la combinación de funciones que, a su vez, están compuestas por estructuras de control. • También explicaremos cómo es que las funciones promueven la reutilización del software.



Funciones • Las funciones o procedimientos fueron uno de los primeros mecanismos de abstracción que se utilizaron amplia-

mente en los lenguajes de programación. • Las funciones permiten realizar tareas que se ejecutaban repetidamente, o son ejecutadas con ligeras variaciones,

que se reunen en una entidad y se reutilizan, en lugar de duplicar el código varias veces. • Por otra parte, el concepto de función proporcionó la primera posibilidad de ocultamiento de la información. Un pro-

gramador puede escribir un procedimiento o conjunto de procedimientos que utilizan otros programadores. Estos pro-gramadores no necesitaban conocer con exactitud los detalles de la implementación; sólo necesitaban el interfaz ne-cesario.

• Sin embargo, las funciones no resuelven todos los problemas. En particular, no es un mecanismo efectivo para ocultar

la información, tampoco resuelve el problema que se produce al trabajar múltiples programadores con nombres de procedimientos idénticos.

• Para resolver este problema se ha desarrollado un mecanismo de estructuración diferente.

Módulos

• La modularidad se refiere al proceso de dividir un objeto en piezas más pequeñas, o módulos, para que algún objetivo sea más fácil de conseguir. Por ejemplo, se podría dividir un sistema complejo en componentes, de forma que cada componente pueda ser probado de forma individual. Cuando se monta un automóvil, sus distintos componentes, tales como el motor, la transmisión y el radio, han sido ya probados individualmente. La modularidad reduce el tiempo para probar el coche y la probabilidad de que un coche sea montado con un defecto.

• La mayoría de los sistemas complejos son modulares. Están construidos combinando componentes o paquetes, de

funcionamiento más sencillo. Una adecuada modularización de un sistema complejo también ayuda a manejar su complejidad. Dividir las cosas en piezas más pequeñas y más sencillas de entender hace que un sistema grande sea más sencillo de comprender.

• Como se verá la modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de módu-

los cohesivos y débilmente acoplados. • En computación la modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas (lla-

madas módulos), cada una de ellas debe ser tan independiente como sea posible de la aplicación en sí y de las res-tantes partes.

• La modularización, como indica Liskov, consiste en dividir un programa en módulos que se puedan compilar por

separado, pero que tienen conexiones con otros módulos. • Un módulo es una técnica que proporciona la posibilidad de dividir sus datos y procedimientos en una parte privada -

sólo accesible dentro del módulo- y parte pública -accesible fuera del módulo-. Se pueden definir tipos, datos (variables y procedimientos) en cualquiera de las dos partes.

• El criterio a seguir en la construcción de un módulo es que si no se necesita algún tipo de información, no se debe

tener acceso a ella. Este criterio es el ocultamiento de la información. • Una clasificación de objetos basada en alguna relación entre ellos es una jerarquía. Las jerarquías también ayudan a

comprender sistemas y organizaciones complejas. La figura 1.7 incluye un diagrama de organización de una compañ-ía típica. El diagrama muestra la jerarquía de empleados basándose en la relación de quién informa a quién. La jerar-quía de la compañía ayuda a los empleados a comprender la estructura de su compañía y su relación dentro de ella.



Figura 1.7. Diagrama de la organización de una compañía

• Los científicos han usado esta técnica desde hace mucho tiempo para identificar y clasificar especies del reino animal

y vegetal. Un orden jerárquico basado en las relaciones de la naturaleza se denomina taxonomía. Tal jerarquía hace que las abstracciones sean más fáciles de entender porque expone la relación entre características y comportamientos comunes.

• Un concepto importante introducido con la programación estructurada, ya comentado anteriormente, es el de abstrac-

ción, que se puede definir como la capacidad para examinar algo sin preocuparse de sus datos internos. • Una forma de ordenar abstracciones similares, en sistemas complejos compuestos de abstracciones, es ir del concep-

to más general al menos general. • La técnica top-down, descendente, o refinamiento sucesivo comienza descomponiendo el programa en piezas mane-

jables más pequeñas, conocidas como funciones (subrutinas, subprogramas o procedimientos), que realizan tareas menos complejas.

• En un programa estructurado es suficiente conocer que un procedimiento dado realiza una tarea específica. El cómo

se realiza esta tarea no es importante, sino conocer cómo se utiliza correctamente la función y lo que hace.

Figura 1.8. Programa estructurado. • Un programa estructurado se construye rompiendo el programa en funciones. Esta división permite escribir código más

claro y mantener el control sobre cada función.

Director

Director de ventas

Tesorero Director de investigación

Director de operaciones

Gerente ventas zona

Gerente de ventas zona

Gerente ventas zona

Gerente ventas zona

Jefe científico Gerente de patentes

Desarrollo de lenguajes de

programación

Desarrollo sistema

Desarrollo de aplicaciones

Investigación de patentes

Aplicación de patentes

Funciones

Función1 Función2 Función3 Función4

Función11 Función21 Función22 Función31 Función41 Función42

Fun-ción221

Fun-ción311

Fun-ción411



• Los módulos resuelven algunos problemas, pero no todos los problemas del desarrollo de software. • Por ejemplo, los módulos permitirán a nuestros programadores ocultar los detalles de la implementación de su pila,

pero ¿qué sucede si otros usuarios desean tener dos o más pilas? • Supongamos que un programador ha desarrollado un tipo de dato complejo o (representación de un número comple-

jo) y ha definido las operaciones aritméticas sobre números complejos -suma, resta, multiplicación y división-; asimis-mo ha definido rutinas para convertir números convencionales a complejos. Se presenta un problema: sólo puede ma-nipular un número complejo. El sistema de números complejos no será útil con esta restricción, pero es la situación en que se encuentra el programador con módulos simples.

• Los módulos proporcionan un método efectivo de ocultamiento de la información, pero no permiten realizar instancia-

ción, que es la capacidad de hacer múltiples copias de las zonas de datos.

• A medida que la complejidad de un programa crece, también crece su independencia de los tipos de datos fundamen-tales que procesa.

• En un programa estructurado, las estructuras de datos de un programa son tan importantes como las operaciones realizadas sobre ellas. Esto se hace más evidente a medida que crece un programa en tamaño.

• Los tipos de datos se procesan en muchas funciones dentro de un programa estructurado, y cuando se producen cambios en esos tipos de datos, las modificaciones se deben hacer en cada sentencia que actúa sobre esos tipos de datos dentro del programa.

• Esta tarea puede ser frustrante y consumir un tiempo considerable en programas con millones de líneas de código y miles de funciones.

• En un programa estructurado, los datos locales se ocultan dentro de funciones y los datos compartidos se pasan como argumentos (Fig. 1.9).

Accesibles, por cualquier función

Accesible sólo por función A Accesible sólo por función B

Figura 1.9. Variables globales y locales.

• Dado que muchas funciones acceden a los mismos datos, el medio en que se almacenan los datos se hace más críti-co.

• La disposición de los datos no se puede cambiar sin modificar todas las funciones que accedan a ellos. Si, por ejem-plo, se añaden nuevos datos, se necesitará modificar todas las funciones que accedan a los datos, de modo que ellos puedan también acceder a esos elementos.

Variables globales

Función A

Función B

Variables locales Variables locales



Figura 1.10. Descomposición de un programa en módulos (funciones)

Resumiendo

• La programación estructurada se emplea desde el principio de la década de los setenta y es uno de los métodos más utilizados en el campo de la programación.

• Uno de los resultados más tangibles de esta investigación fue el desarrollo del lenguaje de programación estructurado

Pascal por Niklaus Wirth, en 1971. Pascal, cuyo nombre se debe al aniversario de los setecientos años del nacimiento del filósofo y matemático Blas Pascal, fue diseñado para la enseñanza de la programación estructurada en ambientes académicos; convirtiéndose en el lenguaje de programación favorito en varias universidades.

• Desafortunadamente, el lenguaje carecía de muchas de las características necesarias para poder utilizarse en aplica-

ciones comerciales, industriales y gubernamentales, de manera que no ha sido muy aceptado fuera de las universida-des.

Desventajas de la programación estructurada

• Los programas basados en funciones son difíciles de diseñar. El problema es que sus componentes principales -funciones y estructuras de datos- no modelan bien el mundo real.

• Por ejemplo, supongamos que se está escribiendo un programa para crear los elementos de un interfaz gráfico de

usuario: menús, ventanas, cuadros de diálogo, etc. ¿Qué funciones se necesitarán? ¿Qué estructuras de datos? • La solución sería más aproximada si hubiera una correspondencia lo más estrecha posible entre los menús y ventanas

y sus correspondientes elementos de programa. • Cuando diferentes programadores trabajan en equipo para diseñar una aplicación, a cada programador se le asigna la

construcción de un conjunto específico de funciones y tipos de datos. Dado que los diferentes programadores manipu-lan funciones independientes que relacionan a tipos de datos compartidos mutuamente, los cambios que un programa-dor hace a los datos se deben reflejar en el trabajo del resto del equipo.

• Aunque los programas estructurados son más fáciles de diseñar en grupo, los errores de comunicación entre miem-

bros de equipos pueden conducir a gastar tiempo en reescrituración. • Por otra parte, los lenguajes tradicionales presentan dificultad en la creación de nuevos tipos de datos. Los lengua-

jes de programación típicamente tienen tipos de datos incorporados: enteros, punto flotante, caracteres, etc. ¿Cómo crear sus propios tipos de datos?

• Los tipos definidos por el usuario y la facilidad para crear tipos abstractos de datos en determinados lenguajes es la

propiedad conocida como extensibilidad. Los lenguajes tradicionales normalmente no son extensibles, y eso hace que los programas tradicionales sean más complejos de escribir y mantener.

• En resumen, con los métodos tradicionales, un programa se divide en dos componentes: procedimientos y datos.

Cada procedimiento actúa como una caja negra. Esto es, es un componente que realiza una tarea específica, tal como convertir un conjunto de números o visualizar una ventana. Este procedimiento permite empaquetar código programa en funciones, pero ¿qué sucede con los datos?

• Las estructuras de datos utilizadas en programas son con frecuencia globales o se pasan explícitamente como pará-

metros. • Una forma para aumentar significativamente la productividad del programador consiste en crear un código que se

Datos globales

Datos globales

Datos globales

Función1 Función2 Función3 Función4



pueda reutilizar sin realizar una revisión extensiva y sin volver a probarlo y evaluarlo. La incapacidad del código estruc-turado en base a procedimientos, para proporcionar su reutilización condujo a la búsqueda de otros enfoques de soft-ware.

PROGRAMACION ORIENTADA A OBJETOS

• Para entender mejor la programación orientada a objetos, haremos un breve estudio sobre las causas fundamentales

que llevaron a cabo la creación de la misma. Podemos resumir como causas principales las siguientes:

La complejidad inherente al software La crisis del software Los Factores de la calidad del software

La complejidad inherente al software

• A medida que las computadoras se han vuelto más rápidas, baratas y más potentes, se han convertido en herramien-

tas indispensables para científicos e ingenieros. • Quizá lo más importante es que se han vuelto parte de nuestra vida. Sin embargo, tener computadoras rápidas y bara-

tas es sólo la mitad de la ecuación. Aunque ha habido tremendos avances en el campo del hardware, no han existido avances de la misma magnitud en el diseño de software.

• Parte del problema es que las expectativas para el software han crecido considerablemente. La figura 1.11 muestra lo

que se conoce como paradoja de la complejidad: la complejidad del sistema crece a medida que se intenta hacer más fácil su uso.

Alta

Complejidad total del software Complejidad Sencillez para el usuario Baja

Figura 1.11. A medida que el software es más fácil de usar, se incrementa su complejidad interna. • Por ejemplo, los primeros sistemas gráficos necesitaban que los usuarios especificaran detalles de cómo debería verse

el gráfico, dando información tan variada como los puntos finales del gráfico, la escala, cómo y dónde habría que colo-car las etiquetas.

• Esencialmente, el usuario tenía que hacer la mayor parte del trabajo. Actualmente las nuevas herramientas para hojas

de cálculo contienen sistemas expertos, que analizan los datos y producen un gráfico de forma automática. Tales sis-temas de representación automática son mucho más fáciles de usar, pero esta facilidad tiene un precio, el incremento de la complejidad del software.

• Se dice que la complejidad del software es una propiedad esencial no accidental (¡si hay software, hay complejidad!). • Esta complejidad se deriva de dos elementos:

La complejidad del dominio del problema La dificultad de gestionar el proceso de desarrollo (la interacción entre componentes)



La complejidad del dominio del problema

• Los problemas a resolver mediante software implican normalmente elementos ineludibles de complejidad, en la que se encuentran una gran cantidad de requisitos, en muchas ocasiones contradictorios.

• Esta complejidad se produce por:

Las difíciles interacciones entre los usuarios de un sistema y sus desarrolladores.

Los usuarios encuentran generalmente muy difícil precisar sus necesidades de forma que los desarrolladores

puedan comprender. En casos extremos los usuarios suelen tener sólo ideas vagas de lo que desean que haga el sistema.

Los usuarios y desarrolladores tienen diferentes perspectivas de la naturaleza del problema y hacen suposicio-

nes diferentes sobre la naturaleza de la solución. El medio común de expresar los requisitos hoy en día es utili-zar un gran volumen de textos, en ocasiones acompañados por esquemas y dibujos. Tales documentos son difíci-les de comprender, están abiertos a diferentes interpretaciones y con frecuencia contienen elementos que son di-seños en lugar de requisitos esenciales.

Los requisitos de un sistema de software cambian durante su desarrollo. Esto supone que un sistema grande

tiende a evolucionar con el tiempo y el mantenimiento del software en ocasiones es un término que no siempre está bien acuñado.

Para ser más preciso, existen diferentes términos a definir: El mantenimiento que busca errores; la evolución

que responde a cambios de requisitos y la conservación cuando se utilizan medios para mantener piezas de software en funcionamiento. Desgraciadamente, la realidad sugiere que un porcentaje alto de los recursos de de-sarrollo de software se gastan en la conservación del software.

La dificultad de gestionar el proceso de desarrollo

• El tamaño de un programa no es una gran virtud en un sistema de software. Sin embargo, la elaboración de un pro-

grama de gran dimensión requiere la escritura de grandes cantidades de nuevo software y la reutilización del software existente.

• Recordemos que hace dos o tres décadas los programas en lenguaje ensamblador se construían a base de centena-

res de líneas. Hoy es usual encontrar sistemas en funcionamiento cuyo tamaño se mide en cientos de miles o incluso millones de líneas de código.

• Esta característica se facilita descomponiendo nuestras implementación en centenares y a veces millones de módulos

independientes. • No es inusual que los programas de aplicación, tales como las hojas de cálculo, procesadores de texto y programas de

dibujo, consten de cientos de miles de líneas de código. • Otro factor que incrementa la complejidad es la interacción entre componentes. Por ejemplo, un procesador de texto

puede contener un componente para corrección ortográfica y otro que proporcione servicios de diccionario de sinóni-mos.

• Consideremos el corrector ortográfico. Cuando se detecta un posible error de ortografía, el corrector debe notificarlo al

usuario. Por lo tanto, el corrector ortográfico, debe relacionarse con el componente de la aplicación que crea una ven-tana o caja de diálogo, de forma que el posible error pueda mostrarse en pantalla y que se pueda preguntar al usuario acerca de la acción a ejecutar, si se debe hacer algo. Si el usuario está de acuerdo en que hay un error ortográfico, el corrector puede corregirlo. Para hacer la corrección, el corrector debe interaccionar con el componente del procesador de texto responsable de reemplazar texto en el documento. Obviamente, a medida que el número de componentes crece, el número de interacciones entre componentes crece rápidamente.



Ingeniería de Software • La Ingeniería de Software es el área de la computación que tiene que ver con las técnicas de construcción de softwa-

re de gran tamaño. El objetivo de un Ingeniero de Software es producir un software que sea:

Fiable. Comprensible. Rentable. Adaptable. Reutilizable.

Examinemos cada una de estas propiedades. • Un software debería ser fiable, es decir, debería funcionar correctamente y sin fallas. • Imagine que ha pasado varias horas escribiendo un texto para un curso en un procesador de textos y, cuando lo tiene

casi terminado, el procesador de textos falla de forma inesperada. Se pierde todo su trabajo. Sin duda, estaría muy en-fadado y tendría todo el derecho a estarlo.

• Aunque la falla de un procesador de textos es molesta, la pérdida es insignificante comparada con la pérdida potencial

cuando falla un sistema crítico: las vidas humanas. • Un sistema de seguridad crítico es aquel en el que una falla podría significar la pérdida de una vida humana. Ejem-

plos de este tipo de sistemas son los aviones militares y civiles, las máquinas de terapia radioactiva y los marcapasos. Una falla del software en cualquiera de estos sistemas podría tener consecuencias desastrosas.

• Una forma de conseguir que el software sea más fiable es hacerlo más fácil de comprender o comprensible. Es

decir, lograr que la operación y el diseño del sistema sean fácilmente entendibles por otros profesionales del software. • La comprensibilidad es muy importante porque los software de gran tamaño son construidos por muchas personas

agrupadas en equipos de trabajo. • La construcción del software irá mejor y con menos errores si todo el mundo que trabaja en la aplicación entiende la

operatividad global del sistema y sus componentes. • La comprensibilidad es también muy importante debido a la larga vida del software. Un producto de software suele

evolucionar con el tiempo y a menudo Ingenieros del Software, que no tienen nada que ver con el producto original, son los que se encargan de introducir mejoras y arreglar los errores del producto.

• Este proceso se llama mantenimiento del software. Si la próxima generación de Ingenieros del Software comprende cómo funciona, las modificaciones de los sistemas complejos, aunque difíciles, se podrán llevar a cabo.

• Por el contrario, es extremadamente difícil hacer modificaciones o correcciones para un sistema pobremente diseñado.

A menudo, es más económico reconstruir el sistema desde el principio. • Como medida de la dificultad del mantenimiento del software, los expertos estiman que el 67% del costo de desarrollo

del software se dedica al mantenimiento. Este costo puede reducirse cuando el diseño y el funcionamiento del sistema son comprensibles.

• Por la discusión previa, se puede ver que un software debería ser rentable. Es decir, el costo de desarrollo y manteni-

miento del software no debería exceder el beneficio esperado por la venta del producto. Muchas compañías de softwa-re han ido a la bancarrota por haber subestimado los costos de desarrollo de un sistema.

• Un componente muy relacionado con el costo es el tiempo que se necesita para diseñar y construir el software. Ser el

primero en introducir un producto en el mercado da a una compañía una decidida ventaja sobre sus competidores. Re-ducir el tiempo para desarrollar un producto puede reducir costos y por lo tanto, incrementar los beneficios.

• Debido a la larga vida del software, el software debería ser adaptable. A menudo, es difícil predecir qué características

y capacidades pueden querer los clientes del software. El mantenimiento adaptativo involucra cambios y añadiduras al software que mejoran la efectividad o competitividad del producto.

• Diseñando software al que puedan añadir fácilmente en el futuro nuevas características y capacidades, el Ingeniero del

Software puede reducir los costos de mantenimiento global. • Por el alto costo de desarrollo, el software debería ser reutilizable. Si se ha de gastar muchos millones de dólares en

un software, tiene sentido hacer sus componentes flexibles de forma que puedan ser reutilizados cuando se desarrolle



un nuevo sistema. Esta estrategia es ciertamente una práctica frecuente en otros negocios. La reutilización puede me-jorar la fiabilidad, reducir los costos de desarrollo y mejorar el mantenimiento.

• La cantidad de trabajo que conlleva exige el uso de un equipo de desarrolladores, aunque se trata por todos los me-

dios de que este equipo sea lo más pequeño posible. Ahora bien, a medida que hay mas desarrolladores, se producen comunicaciones entre ellos mas complejas, e incluso con coordinación difícil entre ellos, particularmente si el equipo está disperso geográficamente, como suele ser el caso de proyectos grandes.

• La descomposición de una aplicación en entidades y relaciones que son significativas a los usuarios es un análisis

convencional con técnicas de diseño. • Con la programación orientada a objetos, este proceso de descomposición se extiende a la fase de implementación. • Es más fácil diseñar e implementar aplicaciones orientadas a objetos, ya que los objetos en el dominio de la aplicación

se corresponden directamente con los objetos en el dominio del software. • Los Ingenieros del Software han desarrollado un cierto número de principios de diseño que ayudan a llevar a cabo

los objetivos marcados en la sección anterior gestionando la inevitable complejidad del software de sistemas grandes, estos principios son: Principios de diseño en Ingeniería de Software

Abstracción. Modularidad. Encapsulamiento u ocultamiento de la información.

Estos principios de diseño de la Ingeniería de Software ya han sido tratados en otra parte de estas notas, sin embargo, es conveniente comprender que los tipos abstractos de datos es uno de los conceptos más interesantes de la abstracción; el principio de encapsulamiento u ocultamiento de la información tiene características mucho más poderosas que las que se realizan en la programación estructurada, aclaremos un poco más estos conceptos. • Un Tipo Abstracto de Dato (TAD) es un tipo de dato definido por el programador que se puede manipular de un modo

similar a los tipos de datos definidos por el sistema. • Al igual que los tipos definidos por el sistema, un tipo abstracto de dato corresponde a un conjunto (puede ser de

tamaño indefinido) de valores legales de datos y un número de operaciones primitivas que se pueden realizar sobre esos valores.

• Los usuarios pueden crear variables con valores que están en el rango de valores legales y pueden operar sobre esos

valores utilizando las operaciones definidas. • Por ejemplo, en el caso de una pila se puede definir dicha pila como un tipo abstracto de datos y las operaciones sobre

la pila como las únicas operaciones legales que están permitidas para ser realizadas sobre instancias de la pila. • Los módulos se utilizan frecuentemente como una técnica de implementación para tipos abstractos de datos. El tipo

abstracto de datos es un concepto más teórico. Para construir un tipo abstracto de datos se debe poder:

Exponer una definición del tipo. Hacer disponible un conjunto de operaciones que se puedan utilizar para manipular instancias de ese

tipo. Proteger los datos asociados con el tipo de modo que sólo se pueda actuar sobre ellos con las rutinas

proporcionadas. Permitir instancias múltiples del tipo.

• Los módulos son mecanismos de ocultamiento de información y no cumplen básicamente más que los apartados 1 y 2. • El encapsulamiento u ocultamiento de la información, es el proceso de separar los aspectos de un objeto en exter-

nos e internos. Los aspectos externos de un objeto deben ser visibles o conocidos, para otros objetos del sistema. Los aspectos internos son detalles que no deberían afectar a otras partes del sistema. Ocultar ciertos aspectos de un obje-to permite modificarlos sin afectar a otras partes del sistema. Por ejemplo, los aspectos externos del radio de un coche son los controles y los tipos de conexiones necesarios para conectar el radio al sistema eléctrico, los altavoces y la an-tena. Los aspectos internos son los detalles del funcionamiento del radio. Para instalar y usar el radio en un coche, no se necesita conocer nada de ingeniería eléctrica. Esencialmente, el radio puede verse como una caja negra con boto-nes y cables.



• El encapsulamiento es la propiedad que permite asegurar que el contenido de la información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B y viceversa.

• El encapsulamiento (también se conoce como ocultamiento de la información), en esencia, es el proceso de ocultar

todos los secretos de un objeto que no contribuyen a sus características esenciales. • El encapsulamiento permite la división de un programa en módulos. Estos módulos se implementan mediante clases,

de forma que una clase representa el encapsulamiento de una abstracción. • En la práctica, esto significa que cada clase debe tener dos partes: un interfaz y una implementación. • El interfaz de una clase captura sólo su vista externa y la implementación contiene la representación de la abstracción,

así como los mecanismos que realizan el comportamiento deseado. • Un gran beneficio del ocultamiento de información es que ayuda a hacer cambios en sistemas complejos. Se puede

reemplazar la radio de un coche por un reproductor de CD sin afectar a otros componentes del vehículo. Debido a que el manejo de la radio ha sido encapsulado y su vista externa está definida mediante controles y conectores, se puede quitar el radio viejo, insertar el nuevo y conectarlo.

• Cuando se aplica al diseño de sistemas de software, el encapsulamiento permite que se pueda cambiar el comporta-

miento interno de un componente software sin afectar a otros aspectos del sistema. • Por ejemplo, si el principio de encapsulamiento ha sido aplicado correctamente a un sistema automático de correo de

voz, debería ser capaz de cambiar el componente que se encarga de almacenar los mensajes sin afectar a otras par-tes del sistema. Se podría incrementar el número de mensajes que un usuario puede almacenar. Si el sistema de al-macenamiento de mensajes ha sido debidamente ocultado y aislado, este cambio no debería afectar a la forma en que los usuarios acceden al sistema y dictan o leen mensajes.

La crisis del software

• En 1968 una conferencia sobre software, patrocinada por la OTAN, asumió los términos ingeniería del software y

crisis del software. Con estos términos se quería expresar que el software era caro, poco fiable y escaso. • Las metodologías y técnicas estructuradas que han reinado en la década de los setenta y ochenta no han eliminado el

problema, de hecho la crisis del software continúa hoy en día. • Pese a las muchas herramientas y métodos utilizados, los problemas del diseño descendentes permanecen igual,

posiblemente debido a que la complejidad del problema ha crecido considerablemente. • Entre las diferentes fases del ciclo de vida del software (Figura 1.12), el mantenimiento, aunque en otro tiempo fue

despreciada su importancia, se considera actualmente como uno de los problemas más graves en el desarrollo del software. Muchos investigadores sugieren que los costos del mantenimiento requieren más de la mitad de los costos y recursos globales del desarrollo total del software.

Figura 1.12. Ciclo de vida del software

Análisis

Diseño

Implementación

Depuración

Mantenimiento



Figura 1.13. Costos de las diferentes fases del ciclo de vida de un proyecto software. • Los cambios realizados en la evolución de un programa son el punto débil de los métodos tradicionales de desarrollo

de software, siendo paradójicamente uno de los puntos fuertes de los métodos de desarrollo de software orientado a objetos.

• En 1986, Fredrick P. Brooks, en un famoso artículo, apuntaba que en los últimos diez años no se había producido

ningún progreso significativo en el desarrollo de software, y analizaba críticamente todas las tecnologías más pro-metedoras. Aunque él confesaba que tenía más confianza en la programación orientada a objetos que en cualquier otra tecnología, mantenía dudas sobre sus ventajas efectivas.

• Recientemente, las propuestas de reusabilidad o reutilización, de componentes software, se consideran como bloques iniciales para la construcción del programa, de modo similar a la construcción de cualquier objeto complejo (tal como un automóvil) que se construye ensamblando sus partes.

• En respuesta al artículo de Brooks, Brad Cox, el inventor de Objective-C, publicó un artículo en el que esencialmente

rebatía las tesis de Brooks:

Existe una bala de plata. Es un arma tremendamente potente, impulsada por vastas fuerzas económi-cas a la que nuevos obstáculos técnicos sólo pueden resistir brevemente. La bala de plata es un cambio cultural en lugar de un cambio tecnológico. Es un nuevo paradigma; una revolución industrial basada en partes reutilizables e intercambiables que modificarán el universo del software, de igual modo que la revolución industrial cambió la fabricación.

• Por consiguiente, la POO (Programación Orientada a Objetos) no sólo son nuevos lenguajes de programación, sino un nuevo modo de pensar y diseñar aplicaciones que pueden ayudar a resolver problemas que afectan al desarrollo del software.

• Sin embargo, el lenguaje debe ser capaz de soportar el nuevo paradigma, siendo por consiguiente una parte esencial

de esta revolución.

Diseño 5%

Análisis 6%

Implementación7 %

Depuración15 %

Mantenimiento 67%



Los factores de la calidad del software

La construcción de software de calidad requiere el cumplimiento de numerosas características. Entre ellas se destacan las siguientes:

• Eficiencia La eficiencia del software es su capacidad para hacer un buen uso de los recursos que manipula.

• Transportabilidad (portabilidad) La transportabilidad o portabilidad es la facilidad con la que un software puede ser transportado sobre diferentes siste-mas físicos o lógicos.

• Verificabilidad La verificabilidad es facilidad de verificación de un software; es su capacidad para soportar los procedimientos de valida-ción y de aceptar juegos de pruebas o ensayos de programas.

• Integridad La integridad es la capacidad de un software para proteger sus propios componentes contra los procesos que no tengan derecho de acceso.

• Fácil de utilizar Un software es fácil de utilizar si se puede comunicar con él de manera cómoda.

• Corrección Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.

• Robustez Capacidad de los productos software de funcionar incluso en situaciones anormales.

• Extensibilidad Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales pa-ra conseguir esto:

diseño simple descentralización

• Reutilización Capacidad de los productos para ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.

• Compatibilidad Facilidad de los productos para ser combinados con otros.



Para poder enfrentar todos los problemas anteriores, así como cumplir con los requerimientos de Inge-niería de sofware y los factores de calidad, se hace necesario el desarrollo de una nueva forma de pensar y de desarrollar programas, esto se logra con la programación orientada a objetos.

En un determinado sentido, las técnicas orientadas a objetos pueden verse como un producto natural de

una larga progresión histórica que va desde las estructuras de control, pasando por las funciones o procedi-mientos, los módulos, los tipos abstractos de datos y los objetos ( este último concepto se verá más adelante ).

• La década de los noventa fué, sin lugar a dudas, la década de la programación orientada a objetos. Como Rentsch

predijo, la programación orientada a objetos será en los ochenta lo que la programación estructurada fue en la década de los setenta.

• En la actualidad la programación orientada a objetos se ha hecho enormemente popular. Escritores y diseñadores

de software, junto a compañías importantes en el campo del software, se dedican de modo continuo a producir compi-ladores de lenguajes, sistemas operativos, bases de datos, etc., orientados a objetos.

¿Qué es la programación orientada a objetos? ¿Por qué es tan popular?

• La programación orientada a objetos es algo más que una colección de lenguajes de programación, tales como Small-

talk, Object Pascal, C++, etc. Se podría decir que este tipo de programación es un nuevo modo de pensar sobre lo que significa computar (computarizar), es decir, cómo se puede estructurar información en una computadora.

• Grady Booch, autor del méto Booch de diseño orientado a objetos muy popular en la década de los noventa, creador de la empresa Racional – fabricante de la herramienta Rose para ingeniería de software orientada a objetos - e impul-sor del lenguaje unificado de modelado UML, define la programación orientada a objetos (POO) como:

Un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representan una

instancia de alguna clase, y cuyas clases son todas miembros de una jerarquía de clases unidas mediante relaciones de herencia. • Existen tres importantes partes en la definición: la programación orientada a objeteos 1) utiliza objetos, no algoritmos,

como bloques de construcción lógicos (jerarquía de objetos); 2) cada objeto es una instancia de una clase, y 3) las cla-ses se relacionan unas con otras por medio de relaciones de herencia.

• Algunos autores de libros aún recuerdan la gran frustración que sentían las empresas de desarrollo de software, espe-cialmente aquellas que desarrollaban proyectos a gran escala, como por ejemplo, el desarrollo de sistemas operativos con tiempo compartido y memoria virtual. La realidad llegaba cuando la empresa decidía producir de manera comercial el sistema en el que cientos de personas habían trabajado durante muchos años. Era difícil poner a punto este softwa-re. El software es un asunto complejo.

• Las mejoras a la tecnología de software comenzaron a aparecer con los beneficios de la denominada programación

estructurada (y las disciplinas relacionadas como el análisis y diseño de sistemas estructurados) que se realizaba en la década de los setenta.

• Pero no fue hasta que la tecnología de la programación orientada a objetos se hizo popular en la década de los

noventa, que los desarrolladores de software sintieron que tenían las herramientas necesarias para realizar mayores adelantos en el proceso de desarrollo de software.

• Antes de la aparición de los lenguajes orientados a objetos, los lenguajes de programación (tales como FORTRAN,

Pascal, Basic y C) se basaban en acciones (verbos), en lugar de cosas u objetos (sustantivos). • Los programadores, que viven en un mundo de objetos, programan primordialmente mediante el uso de verbos. Este

cambio de paradigma complicó la escritura de programas. Ahora, con la disponibilidad de los lenguajes orientados a objetos tales como Java y C++, los programadores siguen viviendo en un mundo orientado a objetos y pueden pro-gramar de una manera orientada a objetos.

• Éste es un proceso más natural de programación y ha dado como resultado un mayor grado de productividad. • Un problema fundamental con la programación basada en procedimientos es que las unidades de programación no

reflejan de manera fácil y efectiva a las entidades del mundo real; así, estas unidades no son particularmente reutiliza-bles.

• Con gran frecuencia los programadores deben comenzar de nuevo cada nuevo proyecto y escribir código similar desde

cero: esto significa gasto de tiempo y de dinero, ya que tiene que reinventar las cosas repetidamente. • Mediante la tecnología de objetos, las entidades de software creadas (llamadas clases), si se diseñan apropiadamente

tienden a ser mucho más reutilizables en proyectos futuros.



• Con las bibliotecas de componentes reutilizables, tales como la MFC (Microsoft Foundation Classes) y las creadas por Rogue Wave y muchas otras empresas desarrolladoras de software, se puede reducir la cantidad del esfuerzo requeri-do para implementar ciertas clases de sistemas (comparadas con el esfuerzo que se hubiera requerido para reinventar estas capacidades en nuevos proyectos).

• Algunas empresas indican que la reutilización de software no es, de hecho, el principal beneficio que obtienen de la

programación orientada a objetos. Más bien, mencionan que la programación orientada a objetos tiende a producir software que es más comprensible, mejor organizado y fácil de mantener, modificar y corregir.

• Esto puede ser importante debido a que se estima que el 80% de los costos de software no están asociados con los esfuerzos originales para el desarrollo de software, están asociados con la continua evolución y mantenimiento de ese software durante su vida útil.

• Cualesquiera que sean los beneficios que se perciban de la programación orientada a objetos, es claro que ésta será

la metodología clave de la programación para las siguientes décadas. • La desventaja es el tiempo y esfuerzos que implica el diseño e implementación de nuevo código. • La orientación a objetos fuerza a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa reali-

zar computación y sobre cómo se estructura la información dentro de la computadora. • Jenkins y Glasgow observan que «la mayoría de los programadores trabajan en un lenguaje y utilizan sólo un estilo de

programación. Ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a métodos alternativos de resolución de un problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo más apropiado al problema a manejar».

• Bobrow y Stefik definen un estilo de programación como «un medio de organización de programas sobre la base de

algún modelo conceptual de programación y un lenguaje apropiado para hacer programas en un estilo claro». Sugieren que existen cuatro clases de estilos de programación:

Orientados a procedimientos Algoritmos Orientados a objetos Clases y objetos Orientados a lógica Expresado en cálculo de predicados Orientados a reglas Reglas If-then

• No existe ningún estilo de programación idóneo para todas las clases de programación. La orientación a objetos se acopla a la simulación de situaciones del mundo real.

¿Qué son los objetos y por qué son tan especiales?

• En realidad, la tecnología de objetos es un esquema de compactación que permite crear unidades útiles de software. • Existen objetos de datos, de tiempo, de cheques, de facturas, de audio, vídeo, de archivo, de registro, y otros más. De

hecho, casi cualquier sustantivo puede representarse razonablemente como un objeto. • Vivimos en un mundo de objetos. Sólo mire a su alrededor. Existen automóviles, aviones, gente, animales, edificios,

semáforos, elevadores, y otras cosas. • Desde el enfoque de un TAD, un objeto es, sencillamente, un tipo abstracto de dato al que se añaden importantes

innovaciones en lo referente a compartir código y la reutilización. Los objetos son tipos de datos que encapsulan con el mismo nombre estructuras de datos y las operaciones o algoritmos que manipulan esos datos.

• Los mecanismos básicos de orientación a objetos son: objetos, mensajes y métodos, clases e instancias, heren-

cia y persistencia.

• Una idea fundamental es la comunicación de los objetos a través de paso de mensajes. • Además de esta idea se añaden los mecanismos de herencia y polimorfismo. • La herencia permite diferentes tipos de datos para compartir el mismo código, permitiendo una reducción en el tamaño

del código y un incremento en la funcionalidad. • El polimorfismo permite que un mismo mensaje pueda actuar sobre objetos diferentes y comportarse de modo distinto. • La persistencia se refiere a la permanencia de un objeto, esto es, la cantidad de tiempo para el cual se asigna espa-

cio y permanece accesible en la memoria del computador.



Figura 1.9. Principios básicos de la orientación a objetos.

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

• Algunas de las causas que están influyendo considerablemente en el notable desarrollo de las técnicas orientadas a objetos son:

La POO (Orientación a Objetos) es especialmente adecuada para realizar determinadas aplicaciones, sobre todo realización de prototipos y programas de simulación.

Los mecanismos de encapsulamiento de la POO soportan un alto grado de reutilización de código, que se incre-

menta por sus mecanismos de herencia.

En el entorno de las bases de datos, la POO se adjunta bien a los modelos semánticos de datos para solucionar las limitaciones de los modelos tradicionales, incluido el modelo relacional.

Aumento espectacular de LPOO (Lenguajes de Programación Orientada a Objetos).

Interfaces de usuario gráficos (por iconos) y visuales. Los interfaces de usuario de una aplicación manipulan la

entrada y salida del usuario. Por consiguiente, su función principal es la comunicación con el usuario final. La en-trada al sistema se puede controlar a través de líneas de órdenes (enfoque utilizado por DOS y UNIX), o alterna-tivamente el usuario puede interactuar con el sistema, con construcciones de programación visuales, tales como iconos de menús, Windows, Macintosh, etc.

• Estas razones hacen fundamentalmente que dentro de las tendencias actuales de la ingeniería de software, el marco

de POO se revela como el más adecuado para la elaboración del diseño y desarrollo de aplicaciones. • Esté marco se caracteriza por la utilización del diseño modular OO y la reutilización del software. • Los TAD (Tipo Abstracto de Dato) han aumentado la capacidad para definir nuevos tipos (clases) de objetos, cuyo

significado se definirá abstractamente, sin necesidad de especificar los detalles de implementación, tales como la es-tructura de datos a utilizar para la representación de los objetos definidos.

• Los objetos pasan a ser los elementos fundamentales en este nuevo marco, en detrimento de los subprogramas que lo

han sido en los marcos tradicionales.

• Introduciremos también otras unidades de programación estructurada llamadas clases. Después, crearemos objetos a partir de clases y procederemos con nuestra explicación acerca de la programación orientada a objetos.

Conceptos clave

Abstracción Encapsulación Persistencia

Herencia Polimorfismo Genericidad

Entidades básicas

Objeto Mensajes, Métodos

Clases, Instancias

Herencia, Jerarquía



1.2 Conceptos fundamentales de la Programación Orientada a Objetos

• Comenzaremos nuestra introducción a la orientación a objetos. Veremos que la orientación a objetos es una manera natural de pensar acerca del mundo real y de escribir programas de cómputo.

• En esta sección introduciremos los conceptos básicos, es decir, pensar en objetos y la terminología, es decir, hablar

de objetos. • Comenzaremos nuestra introducción a la programación orientada a objetos con la terminología clave de ésta. • Mire a su alrededor en el mundo real. Por donde quiera que voltee los puede ver, ¡objetos!, gente, animales, plantas,

automóviles, edificios, computadoras, etcétera. • Los humanos pensamos en términos de objetos. Tenemos la maravillosa habilidad de abstracción que nos permite

ver imágenes en pantalla como objetos tales como gente, aviones, árboles y montañas, en lugar de puntos individuales de color. Podemos, si lo deseamos, pensar en términos de playas en vez de granos de arena, bosques en vez de árbo-les y casas en lugar de ladrillos.

• Quizá nos inclinemos a dividir los objetos en dos categorías: objetos animados y objetos inanimados. Los objetos

animados están vivos de alguna manera. Se mueven y hacen cosa. Los objetos inanimados, como las toallas, parecen no hacer nada en absoluto. Parecen que sólo están ahí.

• Sin embargo, todos los objetos tienen algo en común, todos tienen atributos, como tamaño, forma, color, peso, etcéte-

ra, que los describen. • Todos exhiben un comportamiento, o realizan operaciones (por ejemplo, una bola rueda, rebota, se infla y se desin-

fla; un bebé llora, duerme, gatea, camina y parpadea; un automóvil acelera, frena y gira; una toalla absorbe agua, etcé-tera) que especifican lo que hacen.

• Los humanos aprendemos de los objetos al estudiar sus atributos y al observar su comportamiento. • Objetos diferentes pueden tener atributos similares y comportamiento similares. Por ejemplo, se pueden hacer compa-

raciones entre bebés y adulto, y entre humanos y chimpancés. Los automóviles, camiones, vagones y patinetas tienen mucho en común.

• La programación orientada a objetos (POO) toma como modelo a los objetos reales para elaborar su contraparte en

software. • Toma ventaja de las relaciones entre clases, en donde objetos de cierta clase, tal como una clase de vehículos, tiene

atributos y operaciones similares. • Toma ventaja de las relaciones de herencia e incluso de las relaciones de herencia múltiple, en donde las nuevas

clases de objetos creadas se derivan mediante la absorción de atributos y operaciones de clases existentes y mediante la adición de sus propias características únicas.

• Un objeto de la clase convertible ciertamente tiene las características de la clase más general automóvil, pero el

techo del convertible puede quitarse o ponerse. • La programación orientada a objetos nos brinda una forma natural de ver el proceso de programación, a saber, me-

diante el modelado de objetos reales, sus atributos y comportamiento. La programación orientada a objetos proporcio-na también comunicación entre los objetos. Tal como las personas se envían mensajes entre sí (por ejemplo, un sar-gento que le ordena a un soldado que se coloque en posición de firmes), los objetos también se comunican mediante mensajes.

• La programación orientada a objetos encapsula datos (atributos) y funciones (operaciones) en paquetes llamados

objetos; los datos y las funciones de un objeto están íntimamente ligados. • Los objetos tienen la propiedad de ocultar información. Esto significa que aunque los objetos pueden saber cómo

comunicarse con otros a través de interfaces bien definidas, por lo general, los objetos no saben cómo se implemen-tan otros objetos, los detalles de implementación se ocultan dentro de los mismos objetos. Con seguridad, es posible manejar un automóvil de manera efectiva sin tener que conocer a fondo los detalles de cómo funcionan internamente los sistemas del motor y la transmisión.



• También, veremos por qué el ocultamiento de información es crucial para la buena ingeniería de software. • En C y otros lenguajes de programación por procedimientos, la programación tiende a ser orientada a acciones;

mientras que en C++, la programación tiende a ser orientada a objetos. • En C, la unidad de programación es la función. En C++, la unidad de programación es la clase, a través de la cual se

obtienen las instancias. • En C++, las clases contienen funciones que implementan el comportamiento y datos que implementan los atributos de

la clase. • Los programadores de C se concentran en escribir funciones. Los programadores agrupan acciones dentro de funcio-

nes que realizan alguna tarea común y agrupan funciones para formar programas. • Ciertamente, los datos son importantes en C, pero la idea es que los datos existen primordialmente para apoyar las

acciones que realizan las funciones. • Los verbos en una especificación de sistema ayudan al programador en C a determinar un conjunto de funciones que

trabajan juntas para implementar el sistema. • Los programadores en C++ se concentran en crear sus propios tipos definidos por el usuario llamados clases y com-

ponentes. • Cada clase contiene datos, así como un conjunto de funciones que manipulan esos datos. • En C++, a los componentes de datos de una clase se les llama dato miembro. • En C++, a las funciones que componen una clase se les llama funciones miembro (por lo general, en otros lenguajes

de programación orientados a objetos, como Java, se les denomina métodos). • Tal como a una instancia de un tipo predefinido como int se le llama variable, a una instancia de un tipo definido por el

usuario (es decir, una clase) se le llama objeto. • El programador utiliza tipos predefinidos (y otros tipos definidos por el usuario) como bloques de construcción, para

construir tipos definidos por el usuario (clases). • El foco de atención en C++ se centra en las clases (desde las que se crean los objetos) en vez de funciones. Los

sustantivos en una especificación de sistema ayudan al programador en C++ a determinar el conjunto de clases des-de el que se crean los objetos que trabajan juntos para implementar un sistema.

• Las clases son a los objetos lo que los planos son a las casas. Podemos construir muchas casas a partir de un plano, y

podemos crear instancias de muchos objetos a partir de una clase. Además, las clases pueden tener relación con otras clases.

• Por ejemplo, en el diseño orientado a objetos de un banco, la clase CajeroBanco necesita relacionarse con la clase

CuentaBanco. La más simple de estas relaciones se denomina asociación. • Veremos que el software empaquetado como clases puede reutilizarse en futuros sistemas de software. A menudo,

grupos de clases relacionadas se empaquetan como componentes reutilizables. • La orientación a objetos puede describirse como el conjunto de disciplinas (ingeniería) que desarrollan y mode-

lan software que facilitan la construcción de sistemas complejos a partir de componentes. • El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se mo-

dela y representa el mundo real tan fielmente como sea posible. • Las ventajas de la orientación a objetos son muchas en programación y modelado de datos. Como apuntaban Ledbet-

ter y Cox (1985):

La programación orientada a objetos permite una representación más directa del modelo de mundo real en el código. El resultado es que la radicalmente transformación normalmente llevada a cabo de los requisitos del sistema (defini-do en términos de usuario) a la especificación del sistema (definido en términos de computadora) se reduce considera-blemente.



• La Figura 1.15 ilustra el problema. Utilizando técnicas convencionales, el código generado para un problema del mun-do real consta de una primera codificación del problema y, a continuación, la transformación del problema en términos de un lenguaje de computadora Von Newmann.

• Las disciplinas y técnicas orientadas a objetos manipulan la transformación automáticamente, de modo que el volumen de código del problema y la transformación se minimiza. De hecho, cuando se compara con estilos de programación convencionales (procedimentales, o por procedimientos), las reducciones de código van desde un 40% hasta un orden de magnitud elevado cuando se adopta un estilo de programación orientado a objetos.

Transformación de Von Newmann

Programa

Codificación del programa

Figura 1.15. Construcción de software • Los conceptos y herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real

sean expresados de modo fácil y natural. • Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir sistemas de software complejos

a partir de unidades de software modularizado y reutilizable. • Se necesita un nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de mani-

pular tanto sistemas grandes como pequeños y debe crear sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades de cambio.

• La tecnología orientada a objetos puede cubrir estos cambios y algunos otros más en el futuro. • La orientación a objetos trata de cumplir las necesidades de los usuarios finales, así como las propias de los desarro-

lladores de productos software. Estas tareas se realizan mediante la modelización del mundo real. El soporte funda-mental es el modelo objeto. Las propiedades más importantes de este modelo son:

Abstracción Encapsulamiento Modularidad Jerarquía Polimorfismo Otras propiedades: concurrencia (multitarea), persistencia, genericidad, manejo de excepciones.

• Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos.

Como algunos de estos temas ya han sido tratados (abstracción, encapsulamiento, modularidad, jerarquía ), no lo haremos aquí, salvo que se quisiera agregar algun comentario extra.

Problemas del mundo real



Jerarquía

• La jerarquía es una propiedad que permite una ordenación de las abstracciones. • Las dos jerarquías más importantes de un sistema complejo son: estructura de clases (jerarquía «es-un» (is-a):

generalización/especialización) y estructura de objetos (jerarquía «parte-de» (part-of): agregación). • No se debe confundir clases y objetos de la misma clase: un coche rojo y un coche azul no son objetos de clases

diferentes, sino objetos de la misma clase con un atributo diferente. • Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la herencia define una

relación entre clases, en donde una clase comparte la estructura o comportamiento definido en una o más clases (herencia simple y herencia múltiple, respectivamente).

• La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas lógicamente. Así, un

camión se compone de ruedas, motor, sistema de transmisión y chasis; en consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de camión.

Polimorfismo

• La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el polimorfismo. Esta

propiedad no suele ser considerada como fundamental en los diferentes modelos de objetos propuestos, pero dada su importancia, no tiene sentido considerar un modelo objeto que no soporte esta propiedad.

• Polimorfismo es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. • En términos prácticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento

de programa y realizar la misma operación de diferentes formas, según sea el objeto que se referencia en ese momen-to.

• Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación comer es una operación

fundamental en la vida de los mamíferos, de modo que cada tipo de mamífero debe poder realizar la operación o fun-ción comer. Por otra parte, una vaca o una cabra que pastan en un campo, un niño que se come un bombón o cara-melo y un león que devora a otro animal, son diferentes formas que utilizan los distintos mamíferos para realizar la misma función (comer).

• El polimorfismo implica la posibilidad de tomar un objeto de un tipo (mamífero, por ejemplo) e indicarle que ejecute

comer; esta acción se ejecutará de diferente forma, según sea el objeto mamífero sobre el que se aplica. • Clases, herencia y polimorfismo son aspectos claves en la programación orientada a objetos y se reconocen a estos

elementos como esenciales en la misma. • El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir, cuando se obtiene

una clase a partir de una clase ya existente, mediante la propiedad de derivación de clases o herencia. • Así, por ejemplo, si se dispone de una figura que represente figuras genéricas, se puede enviar cualquier mensaje,

tanto a un tipo derivado (elipse, círculo, cuadrado, etc.) como al tipo base. Por ejemplo, una clase figura puede aceptar los mensajes dibujar, borrar y mover. Cualquier tipo derivado de una figura es un tipo de figura y puede recibir el mismo mensaje.

• Cuando se envía un mensaje, por ejemplo dibujar, esta tarea será distinta según que la clase sea un triángulo, un

cuadrado o una elipse. Esta propiedad es el polimorfismo, que permite que una misma función se comporte de dife-rente forma según sea la clase sobre la que se aplica.

• La función dibujar se aplica igualmente a un círculo, a un cuadrado o a un triángulo y el objeto ejecutará el código

apropiado dependiendo del tipo específico. • El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto sólo se puede producir

en lenguajes de programación orientados a objetos. • Los lenguajes no orientados a objetos soportan ligadura temprana o anterior; esto significa que el compilador genera

una llamada a un nombre específico de función y el enlazador (linker) resuelve la llamada a la dirección absoluta del código que se ha de ejecutar.



• En POO, el programa no puede determinar la dirección del código hasta el momento de la ejecución; para resolver este concepto, los lenguajes orientados a objetos utilizan el concepto de ligadura tardía.

• Cuando se envía un mensaje a un objeto, el código que se llama no se determina hasta el momento de la ejecución. El

compilador asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de retorno, pero no conoce el código exacto a ejecutar.

• Para realizar la ligadura tardía, el compilador inserta un segmento especial de código en lugar de la llamada absoluta. • Este código calcula la dirección del cuerpo de la función para ejecutar en tiempo de ejecución utilizando información

almacenada en el propio objeto. Por consiguiente, cada objeto se puede comportar de modo diferente de acuerdo al contenido de ese puntero. Cuando se envía un mensaje a un objeto, éste sabe qué ha de hacer con ese mensaje.

Otras propiedades

• El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas, sino que es conveniente que soporte, además, estas otras propiedades:

Concurrencia (multitarea). Persistencia Genericidad Manejo de excepciones

• Algunos lenguajes soportan todas estas propiedades y otros sólo algunas de ellas. Así, por ejemplo, Ada soporta concurrencia y Ada y C++ soportan genericidad y manejo de excepciones.

• La persistencia o propiedad de que las variables -y por extensión los objetos- existan entre las invocaciones de un

programa es posiblemente la propiedad menos implantada en los LPOO, aunque ya es posible considerar la persisten-cia en lenguajes tales como Smalltalk y C++, lo que facilitará el advenimiento de las bases de datos orientadas a obje-tos, como así está sucediendo.

REUTILlZACIÓN DE SOFTWARE

• Cuando se construye un automóvil, un edificio o un dispositivo electrónico, se ensamblan una serie de piezas indepen-dientes, de modo que estos componentes se reutilicen, en vez de fabricarlos cada vez que se necesita construir un automóvil o un edificio.

• En la construcción de software, esta pregunta es continua. ¿Por qué no se utilizan programas ya construidos para

formar programas más grandes? Es decir, si en electrónica los computadores y sus periféricos se forman esencialmen-te con el ensamblado de circuitos integrados, ¿existe algún método que permita realizar grandes programas a partir de la utilización de otros programas ya realizados? ¿Es posible reutilizar estos componentes de software?

• Las técnicas orientadas a objetos proporcionan un mecanismo para construir componentes de software reutilizables

que posteriormente puedan ser interconectados entre sí y formar grandes proyectos de software. • En los sistemas de programación tradicionales y en particular en los basados en lenguajes de programación estructu-

radas (tales como FORTRAN, C, etc.), existen las bibliotecas de funciones, que contienen funciones (o procedimientos, según el lenguaje) que pueden ser incorporados en diferentes programas.

• En sistemas orientados a objetos se pueden construir componentes de software reutilizables, al estilo de las bibliote-

cas de funciones, normalmente denominados bibliotecas de software o paquetes de software reutilizables. • Ejemplos de componentes reutilizables comercialmente disponibles son: Turbo Visión de Turbo Pascal, OLE 2.0 de

C++, jerarquía de clases Smalltalk, clases MacApp para desarrollo de interfaces gráficos de usuario en Object Pascal, disponibles en Apple, la colección de clases de Objective-C, etc.

• En el futuro inmediato, los ingenieros de software dispondrán de catálogos de paquetes de software reutilizable, al

igual que sucede con los catálogos de circuitos integrados electrónicos, como les ocurre a los ingenieros de hardware. • Las técnicas orientadas a objetos ofrecen una alternativa de escribir el mismo programa una y otra vez. El programa-

dor orientado a objetos modifica una funcionalidad del programa sustituyendo elementos antiguos u objetos por nuevos objetos, o bien conectando simplemente nuevos objetos en la aplicación.



• La reutilización de código en programación tradicional se puede realizar copiando y editando, mientras que en pro-gramación orientada a objetos se puede reutilizar el código, creando automáticamente una subclase y anulando algu-no de sus métodos.

• Muchos lenguajes orientados a objetos fomentan la reutilización mediante el uso de bibliotecas robustas de clases

preconstruidas, así como otras herramientas, como hojeadores (browser), para localizar clases de interés y depu-radores interactivos para ayudar al programador.



1.2.1 Los lenguajes orientados a objetos

La evolución de los LPOO • Al principio de la década de los sesenta, Kristen Nygaard y Ole-Johan Dhal desarrollaron Simula en el Norwegian

Computer Center (NCC), un lenguaje que soportaba modelado por simulación de procesos industriales y científicos. Fue un lenguaje de propósito general que ofrecía capacidad de simulación de sistemas. Sin embargo, sus usuarios descubrieron pronto que Simula proporcionaba nuevas y poderosas posibilidades para fines distintos de la simulación, como la elaboración de prototipos y el diseño de aplicaciones.

• Las sucesivas versiones de Simula fueron mejorándose hasta llegar a Simula-67 (aparición en diciembre de 1966).

Simula-67 se derivaba de Algol 60, donde tiene sus raíces, y se diseñó fundamentalmente como un lenguaje de pro-gramación de diseño; tomó de Algol el concepto de bloque e introdujo el concepto de objeto.

• Los objetos de Simula tenían su propia existencia y podían comunicarse entre sí durante un proceso de simulación.

Conceptualmente, un objeto contenía tanto datos como las operaciones que manipulaban esos datos. Las operaciones se llamaron métodos. Simula incorporaba también la noción de clases, que se utilizaron para describir la estructura y comportamiento de un conjunto de objetos. La herencia de clases fue también soportada por Simula. La herencia or-ganiza las clases en jerarquías, permitiendo compartir implementación y estructura.

• En esencia, Simula sentó la base de los lenguajes orientados a objetos y definió algunos de los conceptos clave de la

orientación a objetos. Además, Simula era un lenguaje fuertemente tipificado. Esto significa que el tipo de cada va-riable se conoce en tiempo de compilación, de modo que los errores que implican tipos se encuentran en esta etapa y no cuando el programa se ejecuta.

• Simula-67 fue el primer lenguaje de programación que incorporó mecanismos para soportar los conceptos orientados

a objetos más sobresalientes:

Encapsulamiento y objetos, que agrupan juntos atributos de datos y acciones (métodos) que procesen esos datos. Verificación estática de tipos, que se realiza durante el proceso de compilación para proporcionar seguridad en tiem-

po de ejecución para la manipulación externa de los atributos de los objetos. Clases, como plantillas o patrones de objetos. Herencia, como medio de agrupar clases con propiedades comunes. Ligadura dinámica (polimorfismo), para permitir a las clases de objetos que tengan interfaces idénticos y propiedades

que se puedan intercambiar. • La Figura 1.16 muestra la evolución (genealogía) de los lenguajes de programación orientados a objetos (LPOO). En

esta figura se muestra que Simula-67 (Simula) inspiró el desarrollo de Smalltalk, que es el verdadero primer lenguaje de programación orientado a objetos.



Figura 16. Genealogía de los lenguajes de objetos según Sebesta



• Alan Kay creó Smalltalk-80 en Xerox PARC (Xerox Palo Alto Research Park) con Adele Goldberg, que previamente había trabajado con una implementación de Simula. Smalltalk es un lenguaje orientado a objetos puro, «todos es un objeto» de una clase y todas las clases heredan de una única clase base denominada Object. Smalltalk afirmó el término «método» para describir las acciones realizadas por un objeto y el concepto de «paso de mensajes» como el medio para activar «métodos». Es también un lenguaje tipificado dinámicamente, que liga (enlaza) un método a un mensaje en tiempo de ejecución.

• Smalltalk ha sido, a su vez, el inspirador de un gran número de lenguajes OO. Entre ellos destaquemos Eiffel, Small-

talk-80, Smalltalk/V, C++, Actor, Objective-C y CLOS, así como extensiones OO de lenguajes tradicionales, tales como Object Pascal, Object COBOL, etc.

• Bertran Meyer, el diseñador de Eiffel, fue también un usuario de Simula, e incluso llegó a ser presidente de la Asocia-

ción de Usuarios de Simula. • Jean Ichbiah, el diseñador jefe de Ada-83, dirigió un equipo que implementó un subconjunto de Simula, y Bjarne

Stroustrup, el diseñador de C++, utilizó Simula y siempre ha agradecido su influencia en el diseño de C++. • Existen varias versiones y dialectos de Smalltalk: Smalltalk- 72, -74, -76, -78, -80 y más recientemente -y segura-

mente la más popular- Smalltalk/V de Digitalk. • Smalltalk no es un lenguaje tipificado. Smalltalk es extraordinariamente rico en conceptos orientados a objetos. En

Smalltalk todo es un objeto, incluyendo clases base y tipo base. Esto significa que la potencia de Smalltalk, como un entorno de programación completo, se fundamenta en el envío de mensajes a objetos.

• Otra característica fundamental que diferencia a Smalltalk es su capacidad de concurrencia. La concurrencia es un

aspecto del mundo real. Por ejemplo, en un entorno de oficina, secretarias, administrativos, gerentes y otros emplea-dos funcionan simultánea e independientemente. Se comunican entre sí, a través de conversaciones, informes, correo electrónico, etc. Smalltalk empleó la construcción denominada proceso para soportar concurrencia.

• Durante la década de los ochenta, los conceptos orientados a objetos (tipos abstractos de datos, herencia, identidad

de objetos y concurrencia), Smalltalk, Simula y otros lenguajes comenzaron a mezclarse y producir nuevos lenguajes orientados a objetos, así como extensiones y dialectos. El desarrollo de lenguajes de orientación a objetos en esa década se muestra en la siguiente clasificación:

Extensiones, dialectos y versiones de Smalltalk. Xerox y Textronix incorporaron en sus máquinas, a principios de los

ochenta, la versión Smalltalk-80, que posteriormente se fue incorporando a otras muchas plataformas. Digitalk lanzó Smalltalk/V para computadoras personales IBM y compatibles.

Extensiones orientadas a objetos de lenguajes convencionales. Uno de los lenguajes orientados a objetos más popula-

res es C++. Este lenguaje fue diseñado por Bjarne Stroustrup en AT &T al principio de los ochenta [Stroustrup, 1986]. La primera implementación del lenguaje C++ se lanzó como un preprocesador a los compiladores C. C++ pro-porcionó dos construcciones para definiciones de clases. El primer método es una extensión de la construcción struct (estructura de C) y la otra nueva construcción class (clase). C++ incorporó jerarquía de clases y permitía subclases que podían acceder a métodos y variables instancias de otras clases de su jerarquía. El lenguaje C++ permitía la li-gadura dinámica y el polimorfismo, así como sobrecarga de funciones y operaciones. Sin embargo, al contrario que Smalltalk, las primeras versiones de C++ no comercializaban bibliotecas grandes de clases predefinidas.

Otro dialecto importante de C++, con propiedades orientadas a objetos, es Objective-C [Cox 1987]. Este lenguaje es

un superconjunto de C, que incorpora características orientadas a objetos de Smalltalk. Al igual que Smalltalk, Objective-C incluía una gran colección de clases predefinidas que permitía simplificar el pro-

ceso de desarrollo. Objective-C soportaba tipos abstractos de datos, herencia y sobrecarga de operadores. Sin embar-go, al contrario que C++, no ampliaba la definición de construcciones existentes en lenguajes, y diseñó nuevas cons-trucciones y operadores para realizar tareas tales como definición de clases y paso de mensajes. Las computadoras NEXT, cuyo éxito no pasó de unos años, eligieron Objective-C como su principal lenguaje de desarrollo.

Niklaus Wirth y un grupo de ingenieros informáticos de Apple Computer diseñaron Object Pascal [Schmucker,

1986]. Extendió el lenguaje Pascal con soporte para tipos abstractos de datos, métodos y herencia. Incluyó el con-cepto de tipo de objeto y definición de clases.

Los nuevos lenguajes Ada-95 y Java son totalmente orientados a objetos.



Lenguajes orientados a objetos fuertemente tipificados. Simula fue uno de los lenguajes orientados a objetos que se desarrollaron en la década de los ochenta y que fueron implementados en diversas plataformas.

Otros lenguajes han emergido en la década de los ochenta, con características fuertemente tipificadas (con verifica-

ción estricta de tipos). Un lenguaje disponible comercialmente y muy interesante es Eiffel [Meyer, 1988] de Interac-tive Software Engineering, Inc. Además de encapsulamiento y herencia, Eiffel incorpora muchas características orientadas a objetos, tales como tipos paramétricos y pre y post-condiciones para métodos. Otro lenguaje fuertemente tipificado que soporta conceptos orientados a objetos (abstracción, objetos, tipos paramétricos) es Ada, aunque la versión Ada-83 presenta el inconveniente de no soportar herencia.

Extensiones orientadas a objetos de LlSP. Existen diferentes versiones de LISP, aunque la más conocida y notable

es CLOS (Common List Object System). CLOS es un lenguaje OO que introduce notables mejoras y tiene garantiza-da larga vida, especialmente desde la creación del comité X3J13 de ANSI para la estandarización del lenguaje.

Estado de los lenguajes orientados a objetos en la década de los noventa

• La década de los ochenta lanzó la orientación a objetos como base de la futura ingeniería de software orientada a objetos de la década de los noventa. En 1982 se predijo que la programación orientada a objetos sería en la década de los ochenta lo que la programación estructurada fue en los setenta (Rentsch, 1982). La profecía se cumplió y la década de los ochenta se consagró como el origen de la explosión de la orientación a objetos que se produciría en la década de los noventa.

• Sin duda, el desarrollo de conferencias internacionales sobre orientación a objetos y, en especial, OOPSLA (Object-

Oriented Programming Systems and LAnguages) han sido los detonantes de la explosión de la OO en la década de los noventa. La primera conferencia se celebró en el año 1986.

• Otros hechos que han influido considerablemente en el enorme desarrollo de los LPOO han sido la aparición de dife-

rentes publicaciones periódicas exclusivamente dedicadas a orientación a objetos. En 1988 apareció la primera revista de prestigio: The Journal of Object-Oriented Programming.

• En la década de los noventa, los lenguajes, técnicas, interfaces gráficos y bases de datos se hicieron muy populares.

Sin duda, los noventa fué la década de la proliferación de tecnologías y lenguajes orientados a objetos. Microsoft, IBM, Borland, Sun, AT &T, Digitalk, Symantec y otras grandes compañías lanzaron productos orientados a objetos de modo continuo y progresivo.

• Los lenguajes más implantados en la actualidad son Smalltalk y Eiffel, junto con C++, Object Pascal (Turbo/Borland

Pascal especialmente), Visual BASIC y Object Visual como lenguajes híbridos, y Java como un híbrido propio de Sun -su fabricante- que reúne propiedades de C++, Ada-95, Object Pascal, Smalltalk, etc., diseñado para Internet con pro-piedades de objetos.

• C++ es, sin lugar a dudas, el lenguaje más popular, aunque Smalltalk está ganando adeptos día a día. Tanto C++

como Smalltalk han sido implementados en diferentes plataformas: DOS, UNIX, OS/2, Windows e incluso en sistemas grandes; su importancia reside en la gran cantidad de desarrolladores y vendedores que comercializan estos lengua-jes.

Clasificación de lenguajes orientados a objetos

• Como ya se ha comentado anteriormente, los lenguajes de programación orientados a objetos son: Eiffel, Lisp, Prolog, Simula, Smalltalk, C++, Object Pascal, etc. Se entienden por lenguajes orientados a objetos aquellos que soportan las características de orientación a objetos. Otros lenguajes de programación, tales como Ada, C, Clipper, pueden imple-mentar algunas características orientadas a objetos, utilizando ciertas técnicas de programación, pero no se conside-ran orientados a objetos.

• Los principales lenguajes de programación utilizados actualmente para sistemas de tiempo real son C y Ada. Ada fue

diseñado específicamente para la implementación de sistemas en tiempo real, especialmente empotrados. Aunque Ada (Ada-83) no cumple las propiedades importantes de un LPOO (por ejemplo herencia y ligadura dinámica), soporta un enfoque de diseño orientado a objetos y se le conoce usualmente como basado en objetos [Wegner, 87]. Ada-95, ya estandarizado por ISO y ANSI, soporta herencia y ligadura dinámica; en consecuencia, aunque todavía con restric-ciones, se considera orientado a objetos.

Taxonomía de lenguajes orientados a objetos

• Una taxonomía de lenguajes de programación con propiedades de orientación a objetos fue creada por Wegner. La clasificación incluye los siguientes grupos:



Basado en objetos. Un lenguaje de programación es basado en objetos si su sintaxis y semántica soportan la creación de objetos que tienen las propiedades descritas en temas anteriores.

Basado en clases. Si un lenguaje de programación es basado en objetos y soporta además la creación de clases, se

considera basado en clases.

Orientación a objetos. Un lenguaje de programación orientado a objetos es un lenguaje basado en clases que so-porta también herencia.

Objetos + clases

Ada-83 Actor + herencia Clipper 5.x

Clu

C++ Eiffel Simula Smalltalk Turbo Borland Pascal Delphi Visual Object Object COBOL Ada-95

Figura 1.17. Taxonomía de lenguajes OO de Wegner

• Esta taxonomía de orientación a objetos proporciona una definición estricta de los lenguajes de programación orienta-dos a objetos, que ha prevalecido en la época actual. Según esta taxonomía, no es suficiente que un lenguaje soporte la creación de objetos; para ser considerado orientado a objetos, es necesario que existan construcciones de creación de clases y que soporten herencia adecuadamente.

• C++ soporta la creación de objetos y clases, así como herencia, y es por consiguiente totalmente orientado a objetos.

Ada-83 soporta la creación de objetos mediante paquetes (tipos abstractos de datos). Un paquete en Ada no es una definición de tipos como la clase C++, y en consecuencia Ada es un lenguaje basado en objetos. Ada-95 soporta, además de las propiedades de Ada-83, clases y herencia, y se puede considerar orientado a objetos.

• De acuerdo a la taxonomía de Wegner, se podría actualizar la clasificación de los lenguajes pensando en la segunda

década de los noventa:

Lenguajes basados en objetos Ada-83, Actor, Clipper 5.2, Visual Basic 4/5/6. Lenguajes basados en clases Clu. Lenguajes orientados a objetos C++, Objective-C, Java, Object Pascal, Delphi, Visual Object, Object COBOL,

Oyeron, Eiffel, Smalltalk, Simula, Prolog++, CLOS, Ada-95. Características de los lenguajes orientados a objetos

• Además de las características citadas anteriormente de objetos, clases y herencia, los LPOO deberán tener algunas, o

todas, las características que se citan a continuación:

Basado en objetos

Basado en clases

Orientada a objetos



Tipificación estricta (fuerte). Tipificación es el proceso de declarar el tipo de información que puede contener una va-riable. Los errores de programación relacionados con el número de parámetros, tipos de parámetros e interfaces de módulos, se detectan durante las fases de diseño e implementación, en lugar de en tiempos de ejecución.

Encapsulamiento. Es deseable que el lenguaje soporte ocultamiento de la información, mediante partes independien-

tes, para la especificación y la implementación. Esta característica proporciona un diseño débilmente acoplado que cumple con rigor el principio básico de la inferencia de software: acoplamiento débil y fuerte cohesión entre los módulos de un programa.

Compilación incremental. Característica en el desarrollo de sistemas grandes, en los que las porciones del sistema se

crean e implementan de un modo sistemático (poco a poco, etapa a etapa). Esta característica complementa la carac-terística de tipificación estricta, que soporta partes independientes de implementación y específica.

Genericidad. Las clases parametrizadas (mediante plantillas -templates- o unidades genéricas) sirven para soportar

un alto grado de reusabilidad (reutilización). Estos elementos genéricos se diseñan con parámetros formales, que se instanciarán con parámetros reales, para crear instancias de módulos que se compilan y enlazan, y ejecutan pos-teriormente.

Paso de mensajes. El lenguaje es conveniente que soporte paso bidimensional de mensajes entre módulos, lo que im-

plicará módulos débilmente acoplados y diseños flexibles. Esto significa que se deben poder pasar señales entre módulos, sin necesidad de tener que pasar realmente ningún dato.

Polimorfismo. Los lenguajes deben permitir que existan operaciones con igual nombre, que se utilicen para manejar

objetos de tipos diferentes en tiempo de ejecución. El polimorfismo se implementa, normalmente, en unión con la herencia.

Excepciones. Se deben poder detectar, informar y manejar condiciones excepcionales utilizando construcciones del

lenguaje. Esta propiedad añadida al soporte de tolerancia a fallos del software permitirá una estrategia de diseño eficiente.

Concurrencia. Es conveniente que el lenguaje soporte la creación de procesos paralelos independientes del sistema

operativo. Esta propiedad simplificará la transportabilidad de un sistema de tiempo real de una plataforma a otra.

Persistencia. Los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer después de la eje-cución del programa.

Datos compartidos. Los módulos se deben poder comunicar mediante memoria compartida, además del paso de men-

sajes.

• Los lenguajes de programación disponibles actualmente no cumplen todas las características citadas anteriormente. En general, los lenguajes orientados a objetos no soportan concurrencia; este es el caso de C++, aunque las versiones de C++ que siguen el futuro estándar 4.0 comienzan a incorporar propiedades de concurrencia e incluso persistencia. Asimismo, Ada-95, además de concurrencia, soporta ya herencia y polimorfismo.

Puros frente a híbridos

• Existe un profundo debate entre los usuarios y desarrolladores de OO sobre la decisión del lenguaje a emplear. Este debate no es reciente, aunque sí es en la actualidad cuando este debate se ha acrecentado y ha comenzado a ser de-cisivo en el desarrollo de la OO.

• Un LPOO puro es un lenguaje diseñado para soportar únicamente el paradigma orientado a objetos, en el que todo

consta de objetos, métodos y clases. Los LPOO más populares son Smalltalk y Eiffel. Un LPOO híbrido, por otra parte, soporta otros paradigmas de programación (tales como el tradicional -estructurado-, funcional, etc.), además del para-digma orientado a objetos. Los lenguajes híbridos se construyen a partir de otros lenguajes existentes, tales como C o Pascal, de los cuales se derivan; es posible utilizar el LPOO de un modo no orientado a objetos y también como orien-tado a objetos utilizando objetos, clases y métodos.



Figura 1.18. Lenguajes OO puros/híbridos

• Cada tipo de lenguaje tiene sus ventajas e inconvenientes. Los lenguajes puros, tales como Smalltalk o Eiffel, pueden

ser más potentes, ya que utilizan todas las ventajas de la tecnología. Proporcionan su máxima flexibilidad para cambiar los aspectos esenciales del lenguaje. Dado que todo en el lenguaje se construye sobre la base de los objetos, se pue-den realizar cambios profundos si son necesarios.

• Existe un precio, sin embargo, a la potencia y flexibilidad de los lenguajes puros. La mayoría de los lenguajes puros no

son tan rápidos como los híbridos y son difíciles de codificar en toda clase de operaciones fundamentales. Esto les hace perder eficiencia en tiempo de ejecución.

• En contraste, los lenguajes híbridos pierden con frecuencia alguna de las características de los lenguajes puros y

normalmente no permiten modificar características de construcción del lenguaje base; aunque, como ya se ha comen-tado, son normalmente más rápidos para operaciones construidas en el lenguaje base.

• Los lenguajes puros e híbridos difieren también en la facilidad de aprendizaje, si bien esta facilidad dependerá del nivel

de cada persona. Así, para un programador la enseñanza de un lenguaje puro normalmente es más fácil, ya que es más sencillo: sólo ha de aprenderse un lenguaje y no dos, como en el caso de un lenguaje híbrido. Sin embargo, para un programador experimentado, el movimiento o emigración hacia un lenguaje híbrido puede ser más fácil si está ya familiarizado con el lenguaje base, pues entonces sólo necesita dominar las extensiones orientadas a objetos.

• En la actualidad, C++ es el lenguaje más popular y utilizado; sin embargo, Smalltalk está ganando día a día en acepta-

ción, debido esencialmente a estar soportado por las plataformas DOS, UNIX y Windows. El hecho de que en 1994 IBM lanzase versiones de Smalltalk para sus sistemas OS/2 y AIX hizo crecer el número de usuarios de este lenguaje. Por otra parte, Java se está configurando como un nuevo estándar para programación orientada a objetos.

Tipificación estática frente a dinámica

• Tipificación o tipado (typing) es el proceso de declarar cuál es el tipo de información que puede contener una variable. Por ejemplo, una variable se puede tipificar para contener un único carácter, una cadena de caracteres, un número en-tero o un número de punto flotante. Una vez que se ha declarado el tipo (tipificado), la variable está restringida a con-tener esa clase de datos. Cualquier intento de situar otra clase de datos en la variable producirá un mensaje de error.

• Algunos lenguajes de objetos requieren que a todas las variables se les asigne un tipo antes de que se pueda utilizar.

Otros lenguajes no requieren esos requisitos, permitiendo que las variables puedan tomar sus tipos adecuados en cualquier instante dado. Estas dos opciones se denominan tipificación fuerte, estricta o estática, y tipificación débil, no estricta o dinámica.

• La tipificación fuerte o sistemas de tipos estáticos exige que el programador asocie explícitamente un tipo con cada

nombre declarado en un programa, de modo que el compilador del lenguaje puede verificar que los nombres y expre-siones compuestas de estos nombres se refieren siempre a los objetos del tipo especificado. El tipo de cada objeto se ha de determinar y comprobar antes que se ejecute el programa. Lenguajes con sistemas de tipos estáticos son los tradicionales FORTRAN, COBOL y PASCAL. La tipificación fuerte es menos flexible pero más segura, ya que el len-guaje puede realizar comprobaciones de rutinas para asegurar que los parámetros de los mensajes sean de tipo co-rrecto.

• Las ventajas de un lenguaje tipificado estáticamente son que los errores relativos a tipos se capturan (detectan) duran-

te la compilación, antes de que se ejecute el programa, y el programa se puede ejecutar más eficientemente, dado que

Lenguajes puros Lenguajes híbridos

+

Objetos Mensajes

Clases

Objetos Mensajes

Clases

Lenguajes base tradicional



no hay necesidad de hacer ninguna verificación de tipos en tiempo de ejecución. • Los lenguajes con un sistema de tipos dinámicos (lenguajes de tipificación débil) no exigen que el programador especi-

fique el tipo de objeto que puedan contener las variables cuando se escribe el programa. Cada objeto conoce su propio tipo cuando se crea durante la ejecución. Las ventajas de los lenguajes con un sistema de tipos dinámicos son que los programas son más flexibles y puede disponer de nuevos tipos de objetos que no fueron previstos cuando se escribió el programa. Esta flexibilidad se hace a costa de una pérdida de eficiencia durante la ejecución del programa, debido a la necesidad de mantener y comprobar el tipo de todos los objetos durante la ejecución.

• Los lenguajes de objetos puros normalmente utilizan tipificación débil, ya que este enfoque les proporciona máxima

flexibilidad, especialmente durante el desarrollo, cuando se crean nuevos tipos objetos. Los lenguajes híbridos, en con-traste, tienden a construirse como lenguajes fuertemente tipificados. Es posible especificar el tipo de un argumento, de modo que haya flexibilidad en tiempo de ejecución, pero esta tarea requiere esfuerzos especiales.

*prueba = definir( int idPar )

Devuelve un apuntador Método Requiere un parámetro al objeto prueba definir entero

Figura 1.19. Tipificación de un mensaje

Ligadura estática frente a dinámica

• Ligadura es el proceso de asociar un atributo a un nombre. En el caso de funciones, el término ligadura (binding) se

refiere a la conexión o enlace entre una llamada a la función y el código real ejecutado como resultado de la llamada. • La ligadura se clasifica en dos categorías: ligadura estática y ligadura dinámica. La ligadura estática se conoce

también como ligadura temprana o anticipada y se realiza en tiempo de compilación. La ligadura dinámica se conoce también como ligadura retardada o postergada y se realiza en tiempo de ejecución.

• Normalmente, los lenguajes funcionales y orientados a objetos presentan ligadura dinámica, al contrario que los len-

guajes imperativos, que suelen presentar ligadura estática. Desde el punto de vista de la estructura del lenguaje, los intérpretes por definición realizan todos ligadura dinámica, mientras que los compiladores realizan normalmente ligadu-ra estática.

• Como ejemplo de ligadura estática, considere las declaraciones:

const n = 3; var x : integer;

• el valor 3 se enlaza estáticamente al nombre n, mientras que el tipo de dato integer se enlaza al nombre x. Por otra

parte, consideremos la sentencia de asignación x := 3; en este caso, se enlaza 3 dinámicamente a x cuando se ejecuta la sentencia de asignación. Y la sentencia

new( y ) ;

enlaza dinámicamente una posición de almacenamiento a y y asigna a esa posición el valor de y.

Ejemplo de ligadura estática

• Se desea procesar una determinada función, según sea un determinado carácter (código). Mediante una sentencia

switch se podría realizar el programa correspondiente en C++:

#include <ctype.h> #include <iostream.h> / / .. . static void salir( ), funcl( ) , func2( ); char car; //;



//car, contiene el código de carácter int codigo = toupper( car ); switch ( codigo )

{

case ' S' : salir ( ) ; case 'P' : funcl( ); break;

case '*' : func2( ); break; default : cout << "Código desconocido: " << car << endl;

}

• En este caso, la función invocada en respuesta a cada orden se conoce cuando el programa se está compilando, ya que cada función se llama explícitamente por el nombre.

• En el caso de propiedades orientadas a objetos, la ligadura se considera como el proceso mediante el cual se determi-

na el receptor de un mensaje. En lenguajes que requieren ligadura estática, la identidad del receptor se debe especifi-car cuando se crea el programa. Si un lenguaje soporta ligadura dinámica, la identidad del receptor se puede dejar in-determinada hasta que se envía realmente el mensaje en tiempo de ejecución.

• La ligadura dinámica permite la implementación de una de las características más sobresalientes de la orientación a

objetos: el polimorfismo.

Revisión de lenguajes orientados a objetos

• Los dos lenguajes más utilizados en el desarrollo OO y más introducidos en el mercado son Eiffel, Smalltalk (en sus versiones 80 y V), C++, Actor, Objective-C, CLOS, Object Pascal (especialmente Turbo Pascal) y Visual BASIC.

• El lenguaje Ada se suele considerar por muchos autores como basado en objetos, debido esencialmente a que soporta

el concepto de abstracción de datos mediante el paquete y la genericidad mediante unidades genéricas; también es considerado basado en objetos, debido a que Grady Booch, autor del famoso método de diseño Booch, se apoyó en dicho lenguaje en su primera versión del método; la metodología HOOD también se apoya en Ada como lenguaje fun-damental. La nueva versión Ada-95 ya es totalmente orientada a objetos.

• El lenguaje Eiffel se examina brevemente, debido a que fue diseñado para soportar totalmente la orientación a objetos

y otras características de ingeniería de software. El uso de precondiciones, poscondiciones e invariantes mejoran signi-ficativamente la robustez y documentación de programas desarrollados en Eiffel.

• Smalltalk, como heredero directo de Simula, es el prototipo de lenguaje de programación orientado a objetos puro. • Por la importancia del lenguaje C++ y dado que es el lenguaje utilizado en este curso para la implementación de los

conceptos orientados a objetos, se dedicarán capítulos específicos para enseñar la escritura y sintaxis del lenguaje, así como reglas y consejos para mejorar el estilo de programación y reglas y consejos para la depuración de programas.

• De cualquier forma, Meyer, creador del lenguaje Eiffel, proporciona unos criterios para considerar la bondad de un

lenguaje orientado a objetos, cuyos complementos configuran, de hecho, una nueva clasificación. En este sentido, los criterios recogidos son los siguientes:

La modularización de los sistemas ha de realizarse mediante estructuras de datos apropiadas. Los objetos se describen como la implementación de tipos abstractos de datos. La memoria se gestiona (administra) automáticamente. Existe una correspondencia entre tipos de datos no elementales y clases. Las clases se pueden definir como extensiones o restricciones de otras clases ya existentes mediante herencia. Soportan polimorfismo y ligadura dinámica. Existe herencia múltiple y repetida.

• De acuerdo con los criterios de Meyer, recogemos en la Tabla 1 el cumplimiento de dichos criterios en los lenguajes

OO y basados en objetos más populares.



Tabla 1. Criterios de Meyer en lenguajes OO y basados en objetos

Criterios Ada-83 Ada-95 C++ Eiffel Smalltalk Java 1. Modularización Sí Sí Sí Sí Sí Sí 2. Tipos abstractos de datos Sí Sí Sí Sí Sí Sí 3. Gestión automática de memo-

ria Sí Sí En parte Sí Sí Sí

4. Sólo clases Sí Sí En parte Sí Sí Sí 5. Herencia No Sí Sí Sí Sí Sí 6. Polimorfismo (y ligadura

dinámica) No Sí Sí Sí Sí Sí

7. Herencia múltiple y repetida No No Sí Sí No No



1.3 Relación entre clases y objetos

• Un objeto es un simple elemento, no importa lo complejo que pueda ser. Ciertamente, las cosas físicas son objetos. Un balón, un archivero, una agenda, un árbol y una computadora son todos objetos. ¿Qué pasa con cosas como un núme-ro, una palabra, una cuenta bancaria o una nota musical? No son objetos físicos, pero son objetos porque tienen pro-piedades, o atributos, y podemos llevar a cabo acciones sobre ellos. Un número tiene un valor, y se pueden sumar dos números. Una palabra tiene longitud y si estamos hablando de un procesador de textos, se puede borrar o insertar en un documento. Una nota musical tiene tono, duración y volumen. Casi siempre, algo es un objeto si tiene:

Un nombre. Propiedades asociadas al mismo. Mensajes que puede entender.

• Cuando un objeto recibe un mensaje, se produce la ejecución de una acción o cambia una propiedad del objeto como

consecuencia de dicho mensaje. En el caso del control de un televisor, cuando el televisor recibe el mensaje “cambió de canal” desde el control, cambia de canal.

• Una clase, por el contrario, describe una familia de elementos similares. En la práctica, una clase es como un molde o

plantilla que se utiliza para definir o crear objetos. • A partir de una clase se puede definir un número determinado de objetos. Cada uno de estos objetos generalmente

tendrá un estado particular propio (una pluma estilográfica puede estar llena, otra puede estar medio llena y otra total-mente vacía) y otras características (como su color), aunque compartan algunas operaciones comunes ( como escribir o llenar su depósito de tinta ). Los objetos tienen las siguientes características:

Se agrupan en tipos llamados clases. Tienen datos internos que definen su estado actual. Soportan ocultamiento de los datos. Pueden heredar propiedades de otros objetos. Pueden comunicarse con otros objetos pasando mensajes. Tienen métodos que definen su comportamiento.

• Una clase es un tipo definido que determina las estructuras de datos y operaciones asociadas con ese tipo. Las clases son como plantillas que describen cómo están construidos ciertos tipos de objetos. Cada vez que se construye un obje-to de una clase estamos creando lo que se llama una instancia (modelo o ejemplar) de una clase y la operación co-rrespondiente se llama instanciación (creación de instancias). Por consiguiente, los objetos no som más que instancias de clases. En general, los términos objeto e instancia de una clase se pueden utilizar indistintamente.

Un objeto es una instancia de una clase. Una clase puede tener muchas instancias y cada una es un objeto independiente. Una clase es una plantilla que se utiliza para describir uno o más objetos de un mismo tipo.

• La idea fundamental en los lenguajes orientados a objetos es combinar en una sola unidad datos y funciones que

operan sobre esos datos. Tal unidad se denomina objeto. Por consiguiente, dentro de los objetos residen los datos de los lenguajes de programación tradicionales, tales como números, arreglos, cadenas y registros, así como funciones o subrutinas que operan sobre ellos.

• Las funciones dentro del objeto (funciones miembro en C++, métodos en Object Pascal, Java y C#) son el único medio

de acceder a los datos privados de un objeto. Si se desea leer un elemento datos de un objeto se llama a la función miembro del objeto. Se lee el elemento y se devuelva el valor. No se puede acceder a los datos directamente. Los da-tos están ocultos, y eso asegura que no se pueden modificar accidentalmente por funciones externas al objeto.

• Los datos y las funciones (procedimientos en Object Pascal) asociados se dicen que están encapsulados en una única

entidad o módulo. La encapsulación de datos y ocultamiento de datos son términos importantes en la descripción de lenguajes orientados a objetos.

• Si se desea modificar los datos de un objeto, se conoce exactamente cuáles son las funciones que interactúan con el

mismo. Ninguna otra función puede acceder a los datos. Esta característica simplifica la escritura, depuración y mante-nimiento del programa.

• Una clase es la descripción de un conjunto de objetos; consta de métodos y datos que resumen características comu-

nes de un conjunto de objetos. Se puede definir muchos objetos de la misma clase. Dicho de otro modo, una clase es la declaración de un tipo objeto.

• Las clases son similares a los tipos de datos y equivalen a modelos o plantillas que describen cómo se construyen

ciertos tipos de objetos. Cada vez que se construye un objeto a partir de una clase estamos creando lo que se llama



una instancia de esa clase. Una instancia es una variable de tipo objeto.

En Poo un objeto es una instancia de una clase. Los objetos son miembros de una clase. • Cada vez que se construye un objeto de una clase se crea una instancia de esa clase. Los objetos se crean cuando un

mensaje de petición de creación se recibe por la clase. • Una clase es una colección de objetos similares. • Los objetos y las clases se comparan a variables y tipos en lenguajes de programación convencional. Una variable es

una instancia de un tipo, al igual que un objeto es una instancia de una clase; sin embargo, una clase es más expresi-va que un tipo. Expresa la estructura y todos los procedimientos y funciones que se pueden aplicar a una de sus ins-tancias.

• En un lenguaje estructurado, un tipo int, por ejemplo, define la estructura de una variable entera, por ejemplo, una secuencia de 16 bits y los procedimientos y funciones que se pueden realizar sobre enteros. De acuerdo a nuestra de-finición de clase, el tipo int será una clase. Sin embargo, en estos lenguajes de programación no es posible agrupar nuevos tipos y sus correspondientes nuevas funciones y procedimientos en una única unidad. En un lenguaje orienta-do a objetos una clase proporciona este servicio.

• La clase es la construcción del lenguaje utilizada más frecuentemente para definir los tipos abstractos de datos en

lenguajes de programación orientada a objetos. • Generalmente, una clase se puede definir como una descripción abstracta de un grupo de objetos, cada uno de los

cuales se diferencia por un estado específico y es capaz de realizar una serie de operaciones. Por ejemplo, una pluma estilográfica es un objeto que tiene un estado (llena de tinta o vacía) que puede realizar algunas operaciones (por ejemplo, escribir, poner/quitar la tapadera, rellenar si está vacía).

• En programación, una clase es una estructura que contiene datos y procedimientos (o funciones) que son capaces de

operar sobre esos datos. Una clase pluma estilográfica puede tener, por ejemplo, una variable que indica si está llena o vacía; otra variable puede contener la cantidad de tinta cargada realmente. La clase contendrá algunas funciones que operan o utilizan esas variables. Dentro de un programa, las clases tienen dos propósitos principales: definir abs-tracciones y favorecer la modularidad.

• ¿Cuál es la diferencia entre una clase y un objeto, con independencia de su complejidad? Una clase verdaderamente

describe una familia de elementos similares. En realidad, una clase es una plantilla para un tipo particular de objetos. Si se tienen muchos objetos del mismo tipo, solo se tienen que definir las características generales de ese tipo una vez, en lugar de en cada objeto.

• En resumen un objeto es una instancia de una clase.



1.4 El papel de clases y objetos en el análisis y el diseño • Una de las tarea en el análisis y el diseño de sistemas es la identificación de las clases dentro del sistema. Primero,

revisamos el enunciado del problema y localizamos todos los sustantivos; con gran similitud, éstos representan a la mayoría de las clases (o instancias de las clases) necesarias para la implementación del sistema. Normalmente estos nombres o sustantivos y sus sinónimos se suelen escribir en una tabla de la que luego se deducirán los objetos reales.

• Los objetos, según Shlaer, Mellor y Coad/Yourdon, pueden caer dentro de las siguientes categorías:

Cosas tangibles: avión, reactor nuclear, fuente de alimentación, televisor, libro, automóvil, etc. Roles o papeles jugados o representados por personas: gerente, cliente, empleado, médico, paciente, ingeniero. Organizaciones: empresa, división, equipo, etc. Incidentes que representan un suceso, evento u ocurrencia: vuelo, accidente, suceso, llamada a un servicio de

asistencia técnica, etc. Interacciones que implican generalmente una transacción o contrato y que relacionan dos o más objetos del mo-

delo: compras – comprador, vendedor – artículo, matrimonio – esposo – esposa – fecha de boda. Especificaciones que muestran aplicaciones de inventario o fabricación: refrigerador, nevera, etc. Lugares: sala de embarque, muelle de carga, etc.

• Se modelan las clases del sistema y sus relaciones, mediante diagramas de clases. • Se modelan los objetos del sistema y sus vínculos. Los vínculos son relaciones sencillas entre los objetos, las asocia-

ciones son a las clases como los vínculos son a los objetos. • Se identifican los atributos de las clases y se elabora un diagrama de estados. Los estados describen la condición de

un objeto (por ejemplo, los valores de los atributos de un objeto) en un determinado punto en el tiempo. Los diagramas de estado nos brindan una forma de expresar cómo y bajo que condiciones el objeto de un sistema cambia de estado.

• Se elabora el diagrama de actividad. El diagrama de actividad se centra en las acciones que realiza un objeto; en otras

palabras, el diagrama de actividad modela lo que hace un objeto durante su vida útil. • Se identifican las operaciones de una clase y con ella se elaboran los diagramas de secuencia. El diagrama de se-

cuencia se enfoca en la manera en que se envían los mensajes entre los objetos en el tiempo. • Se elaboran los diagramas de colaboración. Una colaboración consiste en una colección de objetos que trabajan juntos

para llevar a cabo una tarea. Los diagramas de colaboración y los diagramas de secuencia proporcionan información acerca de la manera en que interactúan los objetos, pero cada diagrama hace en información diferente. Los diagramas de secuencia hacen énfasis en cuándo ocurren las interacciones. Los diagramas de colaboración hacen énfasis en cuáles objetos participan en las interacciones y en las relaciones entre dichos objetos.

• Dicho en pocas palabras, la participación de los objetos y las clases en la POO es de suma importancia.

DESARROLLO TRADICIONAL FRENTE A ORIENTADO A OBJETOS • El sistema tradicional del desarrollo del software para un determinado sistema es la subdivisión del mismo en módulos,

a la cual deben aplicarse criterios específicos de descomposición, los cuales se incluyen en metodologías de diseño. Estos módulos se refieren a la fase de construcción de un programa, que en el modelo clásico sigue a la definición de los requisitos (fase de análisis).

• El modelo clásico del ciclo de vida del software no es el único modelo posible, dado que es posible desarrollar código

de un modo evolutivo, por refinamiento y prototipos sucesivos. Existen numerosos lenguajes de programación y meto-dologías que se han desarrollado en paralelo a los mismos, aunque normalmente con independencia de ellos.

• Nos centraremos en la metodología más utilizada, denominada desarrollo estructurado, que se apoya esencialmente

en el diseño descendente y en la programación estructurada. • La programación estructurada es un estilo disciplinado de programación según los lenguajes procedimentales (por

procedimientos), tales como FORTRAN, BASIC, COBOL y recientemente C y C++. • Las metodologías del diseño descendente (o descomposición funcional) se centran en operaciones y tienden a descui-

dar la importancia de las estructuras de datos. Se basan en la célebre ecuación de Wirth:

Datos + Algoritmos = Programas

• La idea clave del diseño descendente es romper un programa grande en tareas más pequeñas, más manejables. Si una de estas tareas es demasiado grande, se divide en tareas más pequeñas. Se continúa con este proceso hasta que



el programa se compartimentaliza en módulos más pequeños que se programan fácilmente. Los subprogramas facili-tan el enfoque estructurado, y en el caso de lenguajes como C, estas unidades de programas, llamadas funciones, re-presentan las citadas tareas o módulos individuales. Las técnicas de programación estructuradas reflejan, en esencia, un modo de resolver un programa en términos de las acciones que realiza.

• Para comprender mejor las relaciones entre los algoritmos (funciones) y los datos, consideremos una comparación con

el lenguaje natural (por ejemplo, español o inglés), que se compone de muchos elementos, pero que reflejará poca ex-presividad si sólo se utilizan nombres y verbos. Una metodología que se basa sólo en datos o sólo en procedimientos es similar a un lenguaje en el que sólo se utilizan nombres o verbos. Sólo enlazando nombres o verbos correctos (si-guiendo las reglas semánticas), las expresiones tomarán formas inteligibles y su proceso será más fácil.

• Las metodologías tradicionales se vuelven poco prácticas cuando han de aplicarse a proyectos de gran tamaño. El

diseño orientado a objetos se apoya en lenguajes orientados a objetos que se sustentan, fundamentalmente, en los ti-pos de datos y operaciones que se pueden realizar sobre los tipos de datos. Los datos no fluyen abiertamente en un sistema, como ocurre en las técnicas estructuradas, sino que están protegidos de modificaciones accidentales. En pro-gramación orientada a objetos, los mensajes (en vez de los datos) se mueven por el sistema. En lugar del enfoque funcional (invocar una función con unos datos), en un lenguaje orientado a objetos, se envía un mensaje a un objeto.

• De acuerdo con Meyer, el diseño orientado a objetos es el método que conduce a arquitecturas de software basadas

en objetos que cada sistema o subsistema evalúa. • Recordemos ¿qué son los objetos? Un objeto es una entidad cuyo comportamiento se caracteriza por las acciones

que realiza. Con más precisión, un objeto se define como una entidad caracterizada por un estado; su comportamiento se define por las operaciones que puede realizar; es una instancia de una clase; se identifica por un nombre; tiene una visibilidad limitada para otros objetos; se define el objeto mediante su especificación y su implementación.

• Una definición muy elaborada se debe a Meyer: «Diseño orientado a objetos es la construcción de sistemas de softwa-

re como colecciones estructuradas de implementaciones de tipos de datos abstractos.» • La construcción de un sistema se suele realizar mediante el ensamblado ascendente (abajo-arriba) de clases ya exis-

tentes. Las clases de un sistema pueden tener entre sí, como se verá en los siguientes temas, relaciones de uso (clien-te), relaciones de derivación (herencia) o relaciones de agregación (composición) o incluso sólo relaciones de asocia-ción. Así, por ejemplo, con una relación de cliente, una clase puede utilizar los objetos de otra clase; con una relación de herencia, una clase puede heredar o derivar sus propiedades definidas en otra clase.

• El hardware se ensambla a partir de componentes electrónicos, tales como circuitos integrados (chips), que se pueden

utilizar repetidamente para diseñar y construir conjuntos mucho más grandes, que son totalmente reutilizables. La cali-dad de cada nivel de diseño se asegura mediante componentes del sistema que han sido probados previamente a su utilización. El ensamblado de componentes electrónicos se garantiza mediante interfaces adecuados.

• Estos conceptos se aplican también con tecnologías de objetos. Las clases (tipos de objetos) son como los chips de

hardware, Cox les llamó chips de software, que no sólo se pueden enlazar (ensamblar) entre sí, sino que también se pueden reutilizar (volver a utilizar). Las clases se agruparán normalmente en bibliotecas de clases, que son componen-tes reutilizables, fácilmente legibles.

• En la actualidad existe gran cantidad de software convencional, en su mayoría escrito normalmente para resolver

problemas específicos; por esta razón, a veces es más fácil escribir nuevos sistemas que convertir los existentes. • Los objetos, al reflejar entidades del mundo real, permiten desarrollar aplicaciones, creando nuevas clases y en-

samblándolas con otras ya existentes. Normalmente, los desarrolladores experimentados gastan un porcentaje alto de su tiempo (20 al 40%) en crear nuevas clases y el tiempo restante en ensamblar componentes probados de sistemas, construyendo sistemas potentes y fiables.

Beneficios de las Tecnologías de objetos (TO)

• Una pregunta que hoy día se hacen muchos informáticos es: ¿ Cuál es la razón para introducir métodos de TO en los

procesos de desarrollo? La principal razón, sin lugar a dudas, son los beneficios de dichas TO: aumento de la fiabilidad y productividad del desarrollador. La fiabilidad se puede mejorar, debido a que cada objeto es simplemente «una caja negra» con respecto a objetos externos con los que debe comunicarse. Las estructuras de datos internos y métodos se pueden refinar sin afectar a otras partes de un sistema (Figura 1.20).



Objeto

Figura 1.20. El objeto como caja negra

• Los sistemas tradicionales, por otra parte, presentan con frecuencia efectos laterales no deseados. Las tecnologías de

objetos ayudan a los desarrolladores a tratar la complejidad en el desarrollo del sistema. • La productividad del desarrollador se puede mejorar, debido a que las clases de objetos se pueden hacer reutilizables

de modo que cada subclase o instancia de un objeto puede utilizar el mismo código de programa para la clase. Por otra parte, esta productividad también aumenta, debido a que existe una asociación más natural entre objetos del sis-tema y objetos del mundo real.

Figura 1.21. Proceso tradicional de datos

• Taylor considera que los beneficios del modelado y desarrollo de objetos son:

Desarrollo más rápido. Calidad más alta. Mantenimiento más fácil. Costo reducido. Incremento en escalabilidad. Mejores estructuras de información. Incremento de adaptabilidad.

• Sin embargo, Taylor también considera algunos inconvenientes, aunque algunos de ellos ya han sido superados o al menos reducido su impacto.

Inmadurez de la tecnología (hoy día ya no se puede considerar así). Necesidades de estándares ( el grupo OMG es una realidad). Necesidad de mejores herramientas. Velocidad de ejecución. Disponibilidad de personal calificado. Costo de conversión. Soporte para modularidad a gran escala.

• A continuación se muestran los beneficios genéricos de las tecnologías de objetos.

Reutilización. Las clases se construyen a partir de otras clases. Sistemas más fiables. Proceso de desarrollo más rápido. Desarrollo más flexible. Modelos que reflejan mejor la realidad. Mejor independencia e interoperatividad de la tecnología. Mejor informática distribuida y cliente-servidor.

Métodos

Datos



Bibliotecas de clases comerciales disponibles. Mejores relaciones con los clientes. Mejora la calidad del producto software terminado.

DISEÑO ORIENTADO A OBJETOS • Para sustentar los principios descritos anteriormente, se han desarrollado distintas metodologías de diseño y progra-

mación. Recientemente, un enfoque: el diseño y la programación orientada a objetos, se ha mostrado particular-mente prometedor para ayudar a los desarrolladores de software a lograr los objetivos de fiabilidad, rendimiento, adap-tabilidad, comprensibilidad y reutilidad.

• El diseño de software orientado a objetos elabora el software como un modelo muy próximo a la forma en que

pensamos e interactuamos en el mundo real. A temprana edad, aprendemos acerca de los objetos y de cómo se ma-nipulan. Los bebés, por ejemplo, aprenden que si mueven un sonajero hará ruido. A medida que desarrollan sus capa-cidades cognoscitivas, son conscientes de que los objetos tienen propiedades y empiezan a pensar en ellos de forma abstracta. El bebé pronto se dará cuenta de que hacer ruido es una capacidad de todos los sonajeros.

• Para ilustrar como la visión del mundo, como un conjunto de objetos, facilita el manejo de su complejidad, considere-

mos una actividad que muchos de nosotros hacemos: ver la televisión. Mirando la televisión recuerda que su programa favorito empezará pronto en un canal distinto. Toma el control, oprime el botón y cambia al canal deseado.

• Analicemos esta actividad. Primero, tomó el control, que es un objeto físico. Dicho objeto tiene propiedades, tales

como peso y tamaño, y además puede hacer algo: enviar mensajes a la televisión. No está claro de cómo lo hace o cómo están codificados los mensajes, pero no es necesario saberlo. Sólo necesita saber cómo se oprimen los botones adecuados. Los botones son la interfaz del control. Si se conoce la interfaz de un objeto, se puede usar dicho objeto para hacer algo, aunque no se sepa cómo funciona. Cuando oprimió los botones adecuados hizo que el control envia-se algunos mensajes al televisor. El televisor es también un objeto físico con varias propiedades. Al recibir el mensaje del control, el televisor cambió al canal deseado.

• Estas interacciones son tan rutinarias que es fácil no darse cuenta de lo sorprendente de esta actividad. Ha sido capaz

de hacer que dos objetos interaccionen y ejecuten una actividad compleja sin comprender el funcionamiento interno de ninguno de ellos. Fue capaz de hacerlo así porque disponía de las abstracciones apropiadas para ambos objetos. Además, su abstracción mental del control implica que puede ir a casa de un amigo y ser capaz de usar su control y su televisor, incluso aunque tengan una marca de televisor distinta. Objetos similares muestran un comportamiento simi-lar.

• Esta forma de afrontar nuestro mundo puede ser aplicada al diseño y a la programación de software. Un paso clave en

el desarrollo de un sistema complejo usando diseño orientado a objetos es determinar los objetos que constituyen el sistema. Creando cuidadosamente abstracciones de estos objetos y separando su implementación interna de su comportamiento externo, se puede manejar la complejidad de un sistema de software de gran tamaño.

• Si vamos a adoptar un enfoque orientado a objetos para desarrollar software, tiene sentido usar un lenguaje de pro-

gramación que sustente esta forma de pensar y permita implementar soluciones en términos de objetos. Un lenguaje que tiene esas características es un lenguaje de programación orientada a objetos. Observe que se ha tenido cuidado de incluir la frase implementar un diseño orientado a objetos. Ya que se puede usar un lenguaje orientado a objetos, pero no pensar en términos de objetos.

• Algunos lenguajes orientados a objetos populares actualmente son Smalltalk y C++. Las características que incluyen

para manejar objetos son, en su mayor parte, idénticas. Difieren principalmente en la terminología usada para referirse a los objetos y en la sintaxis del lenguaje.



RESUMEN

La orientación a objetos es una manera natural de pensar acerca del mundo y de escribir programas de computadora.

Los objetos tienen atributos (como tamaño, forma, color, peso y aspecto) y exhiben un comportamiento.

Los humanos aprendemos acerca de los objetos mediante el estudio de sus atributos y la observación de

su comportamiento.

Objetos distintos pueden tener muchos atributos iguales y exhibir un comportamiento similar.

La programación orientada a objetos (POO) modela objetos del mundo real con contrapartes en software. Toma ventaja de las relaciones entre clases, en donde los objetos de cierta clase tiene las mismas carac-terísticas y comportamientos. Aprovecha las relaciones de herencia e incluso las relaciones de herencia múltiple, en donde las clases recién creadas se derivan mediante la herencia de las características de cla-ses existentes, aunque contiene características únicas propias.

La programación orientada a objetos proporciona una manera intuitiva de ver el proceso de programa-

ción, a saber, mediante el modelado de objetos reales, sus atributos y sus comportamientos.

La POO también modela la comunicación entre objetos mediante mensajes.

La POO encapsula los datos (atributos) y las funciones (comportamiento) dentro de los objetos.

Los objetos tienen la propiedad de ocultar información. Aunque los objetos pueden saber como comuni-carse entre sí a través de interfaces bien definidas, los objetos por lo general no están autorizados para sa-ber los detalles de la implementación de otros objetos (para eliminar dependencias innecesarias).

El ocultamiento de información es crucial para una buena ingeniería de software.

En C y en otros lenguajes de programación por procedimientos, la programación tiende a ser orientada a

acciones. En realidad, los datos son importantes en C, pero la visión es que los datos existen primordial-mente para permitir las acciones que realizan las funciones.

Los programadores en C++ se concentran en la creación de sus propios tipos definidos denominados

clases. Cada clase contiene datos, así como el conjunto de funciones que manipulan los datos. Los com-ponentes de datos de una clase se denominan datos miembro. Los componentes de función de una clase se denominan funciones miembro o métodos.



EJERCICIOS

1) Llene el espacio vacío con el término de objetos correcto de cada una de las siguientes oraciones:

a) Los humanos podemos ver hacia la pantalla del televisor y ver puntos de colores, o podemos retroceder y ver a tres personas sentadas en una mesa de conferencias, éste es un ejemplo de una capacidad llamada __________________.

b) Si vemos un automóvil como un objeto, el hecho de que sea convertible es un atributo/comportamiento (elija uno) _________________ del automóvil

c) El hecho de que un automóvil pueda acelerar o desacelerar, dar vuelta a la izquierda o a la derecha, o ir hacia delan-te y hacia atrás es un ejemplo de _____________ del automóvil.

d) Cuando una nueva clase hereda las características de distintas clases diferentes, a esto se le denomina herencia _____________________.

e) Los objetos se comunican entre sí enviándose ____________________. f) Los objetos se comunican entre sí mediante el uso de __________________ bien definidas. g) Por lo general, a un objeto no se le permite saber cómo están implementados otros objetos; a esta propiedad se le lla-

ma ______________________. h) Los _______________ en una especificación de sistema ayuda al programador de C++ a determinar las clases que

se requerirán para implementar el sistema. i) Los componentes de datos de una clase se llaman ____________ y a los componentes de función de una clase se

les llama _________________________. j) A una instancia de un tipo definido por el usuario se le llama _________________.

2) Responda de manera breve cada una de las siguientes preguntas pensando en objetos:

a) ¿Por qué se prefiere explicar primero y con detalle la programación estructurada, antes de explicar a fondo la pro-gramación orientada a objetos?

b) ¿Cuáles son los pasos típicos de un proceso de diseño orientado a objetos? c) ¿Cómo se puede mostrar la herencia múltiple en los seres humanos? d) ¿Qué tipo de mensajes se envía la gente entre sí? e) Los objetos se envían mensajes entre sí a través de interfaces bien definidas. ¿Qué tipos de interfaces presenta el ra-

dio de un automóvil (objeto) a su usuario (objeto persona)? 3) Probablemente porta en su muñeca uno de los objetos más comunes en el mundo, un reloj. Explique cómo cada uno

de los siguientes términos y conceptos se pueden aplicar a la noción de un reloj: objeto, atributo, comportamiento, cla-se, herencia (por ejemplo, considere un reloj de alarma), abstracción, modelado, mensajes, encapsulado, interfaz, in-formación, ocultamiento, datos miembro y funciones miembro.

4) Considere un cajero automático en un banco. ¿Cuáles son algunas de las propiedades relevantes del cajero para las

siguientes persona? a) Un usuario. b) Una persona de mantenimiento. c) Un empleado del banco. d) El presidente del banco.

5) Dé un ejemplo de encapsulamiento en el funcionamiento de un contestador automático telefónico. 6) La mayor parte de los sistemas son modulares. Nombre algunos de los componentes/módulos de los siguientes siste-

mas:

a) Equipo de música. b) Televisor. c) Lavadora. d) Video. e) Bicicleta.

7) La mayoría de las organizaciones tienen una estructura jerárquica. Elija una organización a la que pertenezca y dibuje

un diagrama que ilustre su jerarquía.



8) ¿Son los siguientes elementos objetos? Justifique su respuesta.

a) Belleza. b) Tiempo. c) Celos. d) Arbol. e) Bosque.

9) Casi todos los dispositivos electrónicos han sido diseñados siguiendo el principio de modularidad, que hace que los dispositivos sean más fáciles de fabricar y reparar. Nombre los principales componentes de los siguientes dispositivos:

a) Televisor. b) Video. c) Horno de microondas. d) Equipo de música. e) Radio. f) Teléfono.

10) ¿Por qué se presta tanta atención hoy día a la programación orientada a objetos en general y a C++ en particular?



EJEMPLO DE DISEÑO ORIENTADA A OBJETOS • Para mostrar algunas características de un lenguaje orientado a objetos, se va a hacer un esbozo de diseño de un

sencillo juego de computadora llamado CAZA DE LA PULGA. El propósito de este juego, más que nada es ayudar a la gente a desarrollar su coordinación cuando usa un ratón de computadora. El juego funciona de la manera siguiente:

El juego CAZA DE LA PULGA está formado por una ventana con la imagen de una pulga. La pulga

cambia de direcciones aleatoriamente dentro de la ventana (ver figura 1.22).

El objetivo del juego es eliminar a la pulga. Una pulga es eliminada aplastándola, es decir oprimiendo el botón del ratón cuando la pulga está debajo. Son pulgas duras y hay que aplastarlas varias veces hasta matarlas.

Hay dos tipos de pulgas: lentas y rápidas. Obviamente, una pulga lenta se mueve más despacio que una rápida. Cuando se elimina la primera pulga, una más rápida toma su lugar.

Si se falla (es decir, se oprime el botón del ratón cuando la pulga no está debajo), el jugador pierde. Un jugador gana cuando elimina las pulgas lentas y rápidas sin fallar.

Los dos tipos de pulgas se mueven de forma distinta. Cuando una pulga lenta llega al borde de la ven-tana, cambia de dirección como si hubiera chocado con una pared.

Cuando una pulga rápida alcanza el borde de la ventana, la atraviesa y aparece por el lado opuesto de la ventana.

Figura 1.22. El juego Caza de la pulga • Los pasos sugeridos en el diseño orientado a objetos son los siguientes:

Paso 1. Determinar los objetos que se definen en el problema. Paso 2. Para cada objeto determinar sus atributos (propiedades) y sus acciones.

• De la definición del problema, se pueden extraer algunos objetos identificando los nombres. Los objetos nombrados en la definición del problema son: ventana, ratón y pulga.

• Para mostrar las características disponibles en un lenguaje orientado a objetos, nos centraremos en el diseño de los

dos objetos pulga. El diseño de los objetos ventana y ratón son similares. • Para cada pulga, es necesario determinar las propiedades asociadas con ella y las acciones que pueden realizar.

Según el problema, una pulga tiene las siguientes propiedades o atributos:

Movimientos posibles de la pulga Dirección actual

Caza de la Pulga

PULGA



Una Posición en la ventana. Una imagen. Velocidad. Dirección. Resistencia (es decir, el número de golpes necesarios para eliminar la pulga).

• Una pulga debe ser capaz de manejar los siguientes mensajes o mandatos:

Dibujar. Mover (es decir, actualizar su posición). Cambiar la dirección en que se mueve. Golpear (es decir, decir a la pulga que ha sido aplastada). Matar (decir a la pulga que debe morir). estaApuntandoA (pregunta a la pulga si el cursor del ratón está sobre ella).

• Estas propiedades y mensajes forman la abstracción de las pulgas del juego.

• Los lenguajes orientados a objetos proporcionan una forma de definir una abstracción mediante la encapsulación de

sus propiedades y mensajes en un único concepto, denominado clase. • Cuando un conjunto de propiedades y mensajes están encapsulados en una clase, se dice que son miembros de la

clase. Los miembros que definen las propiedades de una clase se denominan miembros de datos, porque contienen información. Los mensajes que una clase puede manejar se denominan métodos o miembros de función.

• La diferencia entre clase y objeto es sutil, pero importante. Mientras una clase es un concepto abstracto, un objeto es

una entidad concreta. Por ejemplo, el concepto de automóvil es una clase, pero un Ford Taunus con interior de piel y motor V-6 es un objeto. En términos prácticos, se puede pensar en una clase como una plantilla para un objeto. A par-tir de la clase, se pueden crear o instanciar objetos con propiedades específicas.

• La noción de instanciar un objeto concreto a partir de una clase abstracta se muestra en la figura 1.23. En ella se

instancian tres pulgas distintas, cada una con su propia posición, imagen, velocidad, dirección y resistencia, a partir de la clase pulga. En esencia, una clase define las propiedades y mensajes de un objeto. La instanciación crea un ob-jeto con valores específicos para cada una de las propiedades.



Figura 1.23. Instanciación de tres objetos pulga a partir de la clase pulga • Se puede pensar en crear una clase por cada tipo de pulga (lenta y rápida) e instanciar tipos distintos de pulga según

se requiriera. Sin embargo, una característica importante de los lenguajes orientados a objetos es que permiten al pro-gramador explotar la similitud de los objetos. Si piensa acerca de ello, una pulga rápida y una pulga lenta tienen mu-chas características en común. Tanto si una pulga es rápida como si es lenta, tiene posición, imagen, velocidad, direc-ción y resistencia. De hecho, la única característica que distingue a ambas pulgas es cómo se mueven. Una pulga len-ta da la vuelta cuando llega al borde de la ventana, mientras que una rápida la atraviesa y reaparece por el borde opuesto de la ventana. Por lo tanto, se puede pensar en crear una pulga básica que capture los atributos y comporta-mientos que todas las pulgas tienen en común y usarla para crear dos tipos esenciales de pulgas, pulgaLenta y pul-gaRapida, que se comportan de forma distinta cuando llegan al borde de la ventana. Así, ambas pulgas son tipos es-peciales de pulga. Estas relaciones, definen una jerarquía como se muestra en la figura 1.24.

MENSAJES

PROPIEDADES

PULGA

Posición Imagen Velocidad Dirección Resistencia

Dibujar Mover FijarDireccion Golpear Matar estarApuntandoA

La clase pulga

Posición: 1, 2 Imagen Velocidad: 3 Dirección: arriba Resistencia: 3 Pulga


Posición: 12, 2.2 Imagen Velocidad: 4 Dirección: izquierda Resistencia: 4


Pulga Posición: 5, 3.8 Imagen Velocidad: 2 Dirección: derecha Resistencia: 2


Pulga

Objetos pulga con propiedades particulares



PROPIEDADES MENSAJES

Es una Es una

Figura 1.24. Abstracción y herencia de pulgas con diferente comportamiento

• En la parte alta del diagrama está la clase Pulga. Esta clase, la más general, se denomina a veces clase base o superclase.

• Debajo de la clase base están las subclases o clases derivadas. Las clases derivadas heredan mensajes y propie-

dades de sus ancestros. • Por lo tanto la PulgaRapida y la PulgaLenta tienen como propiedades su posición, Imagen, Velocidad, Dirección y

Resistencia. De forma similar, una PulgaRapida y una PulgaLenta entienden los siguientes mensajes o mandatos: Di-bujar, Mover, FijarDireccion, Golpear, Matar y EstarApuntandoA. La noción de herencia es una característica que defi-ne a los lenguajes orientados a objetos.

• La habilidad de una clase para heredar propiedades y funciones miembro de un ancestro sustenta el principio de reuti-

lización. Ambos tipos de pulgas comparten las funciones miembro para Dibujar, Mover, FijarDireccion, Golpear, Matar y EstaApuntandoA. Estas funciones sólo se implementan una vez.

Pulga

Posición

Imagen

Velocidad

Dirección

Resistencia

Dibujar

Mover

FijarDireccion

Golpear

Matar

EstarApuntandoA

Propiedades Mensajes

PulgaLenta

Mover

Propiedades Mensajes

PulgaRapida

Mover

Mensaje específico de pulgaLenta Mensaje específico de pulgaRapida



• La jerarquía para la clase Pulga ilustra otra característica de los lenguajes orientados a objetos: el polimorfismo. El polimorfismo es la capacidad de asumir diferentes formas. En un lenguaje orientado a objeto, el polimorfismo es la propiedad que permite que un mensaje pueda significar distintas cosas dependiendo del objeto que lo reciba.

• El mensaje Mover significa una cosa distinta si se envía a un objeto PulgaLenta o a una de tipo PulgaRapida. Una

pulga lenta da la vuelta cuando llega al borde de la ventana, mientras que una pulga rápida hace un túnel hasta el otro lado. Este uso del polimorfismo se ilustra en la figura 1.18 mediante la inclusión del mensaje Mover para los objetos: PulgaLenta y PulgaRapida.

• El polimorfismo es un concepto natural que se aplica bien a los objetos. Objetos similares aceptan a menudo los mis-

mos mensajes, pero hacen cosas distintas. Por ejemplo, considere la interfaz gráfica de una computadora. Los objetos son iconos que representan archivos. Se usa el ratón para enviar mensajes a estos objetos. Un mensaje típico es una doble pulsación, que se envía al objeto colocando el ratón sobre su icono y pulsando el ratón dos veces. Para un ar-chivo ejecutable, ese mensaje significa que debe ejecutar el archivo, mientras que para un archivo de texto, la pulsa-ción doble indica que debe arrancar el editor de texto y abrir el archivo para editarlo.

• El desarrollo de la jerarquía de Pulga ilustra mucha de las características disponibles en un lenguaje orientado a obje-

tos. Sin embargo, para demostrar completamente la potencia del diseño y la programación orientada a objetos, es ne-cesario discutir cómo se puede crear un sistema completo a partir de un conjunto de objetos. Se hará mediante el di-seño esquemático de alto nivel del juego CAZA DE LA PULGA.

• Recuerde que, de la descripción previa que se hizo del juego, los otros objetos mencionados fueron el ratón y la venta-

na. Ciertamente, es necesario desarrollar estos objetos. Sin embargo, en la descripción se menciona otro objeto muy importante: ¡el mismo juego! Es fácil de olvidar, porque la definición del problema es una descripción de este objeto. Si lo piensa un momento, tiene sentido pensar en el juego como en un objeto. Desde un punto de vista abstracto, el obje-to juego es el elemento que coordina las actividades de otros objetos y asegura el cumplimiento de las reglas del jue-go. Se llamará a este objeto, que es el juego, ControladorDeJuego.

• Ahora ya se puede completar el diseño de alto nivel del juego. Como se mencionó, se necesitan los objetos ventana y

ratón. Por ahora, se ignorará el objeto ventana. Aunque es necesaria para la realización del juego, la creación y el con-trol de la ventana no tienen un papel fundamental en la operación del juego. El ratón, por otro lado, es un componente fundamental del juego, ya que gran parte de la acción del juego se centra en las actividades del ratón. La visión abs-tracta del ratón, Raton, es la de un objeto que envía mensajes al ControladorDeJuego. El raton envía un mensaje al ControladorDeJuego cada vez que se pulsa un botón. El mensaje contiene la posición en la pantalla del cursor.

• Con las abstracciones Raton y Pulga, el diseño y manejo del juego es bastante sencillo. El manejo global se ilustra en

la figura 1.25. Cuando se pulsa una tecla del ratón, el Ratón envía el mensaje PulsacionRaton al ControladorDe-Juego. Este extrae la posición del ratón del mensaje y envía un mensaje EstaApuntandoA, que incluye la posición del ratón, a la pulga de la pantalla. La pulga determina si la posición en el mensaje está dentro de ella. Si el ratón apunta a la pulga, responde sí al mensaje; en caso contrario, responde no. Si el ControladorDeJuego recibe una respuesta afirmativa, envía un mensaje de La pulga fue golpeada. Si se ha sobrepasado la resistencia de la pulga, la pulga res-ponde al mensaje diciendo que no tiene más resistencia. Si se recibe esta respuesta, el ControladorDeJuego mata a la pulga. Si la pulga era lenta, el controlador crea una PulgaRapida y el juego continúa. Las interacciones entre el ControladorDeJuego y la Pulga se muestran en la figura 1.25.

PulsacionRaton pulsacionRaton

Figura 1.25. Interacción entre el controlador del juego, el ratón y la pulga.

Respuesta: si o no ¿estaApuntandoA?

Caza de la pulga

pulga

controlador-DeJuego

raton



• Si la pulga responde que no, el ratón no está apuntando sobre ella; en ese caso, el ControladorDeJuego crea una nueva ventana y muestra un mensaje diciendo al jugador que ha perdido el juego. Si se ha eliminado a todas las pul-gas sin errores, el controlador muestra un mensaje felicitando al jugador por su habilidad con el ratón. Por supuesto, quedan muchos detalles que perfilar para completar la implementación del juego. Sin embargo, el diseño de alto nivel está resuelto.

EJERCICIOS

1. Esboce el diseño de la clase Ventana para el juego CAZA DE LA PULGA. Asegúrese de incluir los

atributos (es decir, miembros de datos) y las acciones (es decir, miembros de función) que la clase debe tener.

2. Esboce el diseño de la clase Ratón para el juego CAZA DE LA PULGA. Asegúrese de incluir los atribu-

tos (es decir, miembros de datos) y las acciones (es decir, miembros de función) que la clase debe tener. 3. Esboce el diseño de la clase ControladorDeJuego para el juego CAZA DE LA PULGA. Asegúrese de

incluir los atributos (es decir, miembros de datos) y las acciones (es decir, miembros de función) que la clase debe tener.

4. Usando los diseños de los problemas 1 y 3, dibuje un diagrama que muestre cómo podrían interactuar las

distintas clases entre sí. 5. Esboce un diseño orientado a objetos de una máquina despachadora de refrescos. ¿Cuáles son los objetos

clave? ¿Cuáles son los atributos y comportamientos de los objetos? ¿Cómo interaccionan los objetos? 6. El ejemplo herencia en la figura 1.24 ignora algunos detalles. Considere los siguientes temas:

a) La posición es una propiedad de todas las pulgas. ¿Cómo se podría especificar la posición? b) Trace las acciones que una pulga ejecuta cuando recibe un mensaje Matar.

7. Extienda la jerarquía de la clase de la figura 1.24 para incluir una clase PulgaEspectro. Una PulgaEspec-

tro desaparece ocasionalmente y reaparece en una nueva posición. ¿Es necesario cambiar las propiedades de Pulga?

capitulo 1 Fundamentos de programacion orientada a...

Documents

Transcript of capitulo 1 Fundamentos de programacion orientada a...