El paradigma de la programación orientada a objetos

El modelo de objetos
La tecnología orientada a objetos se basa en en los sólidos fundamentos de ingeniería, cuyos elementos
reciben el nombre global modelo de objetos. El modelo de objetos abarca los principios de abstracción,
encapsulación, modularidad, jerarquía, mecanografía, concurrencia y persistencia. Por sí mismos,
ninguno de estos principios son nuevos. ¿Qué es importante sobre el modelo de objetos es que estos
elementos es presentada juntos de una manera sinérgica. Que no haya duda de que el diseño orientado a
objetos es fundamentalmente diferente a los enfoques tradicionales de diseño estructurado: Se requiere
una forma diferente de pensar acerca de la descomposición, y produce arquitecturas de software que
están alejadas de diseño estructurado.

La evolución del modelo de objetos

Con respecto a las generaciones de los lenguajes de programación, Wegner ha clasificado algunos de
los lenguajes de programación de alto nivel más populares en generaciones, dispuestas de acuerdo con
las características que tales lenguajes fueron pioneros en presentar:

#########################################################################
• Primera generación de lenguajes(1954-1958)

FORTRAN 1 Expresiones Matemáticas

ALGOL 58 Expresiones Matemáticas
Flowmatric Expresiones Matemáticas
IPL V Expresiones Matemáticas
• Segunda generación de lenguajes( 1959-1961)

FORTRAN II Sub-rutinas, compilación separada

ALGOL 60 Estructura de Bloque, tipos de datos
COBOL Descripción de datos, manejo de archivos
List Procesamiento, apuntadores, recolección de basura
• Tercera generación de lenguajes(1962-1970)

PL/1 FORTRAN + ALGOL + COBOL

ALGOL 68 Riguroso sucesor a ALGOL 60
Pascal Simple sucesor a ALGOL 60
Simula Clases, Abstracción de datos
• La brecha generacional
Muchos diferentes lenguajes fueron inventados, pero pocos perduraron. sin embargo vale la pena
mencionar los siguientes:
C Eficiente, pequeños ejecutables
FORTRAN 77 Estandarización
• El auge orientado a objetos(1980-1990, pero algunos lenguajes sobrevivieron)

Smalltalk 80 Orientado a objetos puro

C++ Derivado de C y Simula
Ada83 Escritura fuerte: fuerte influencia de Pascal
Eiffel Derivado de Ada y Simula
• El surgimiento de Frameworks(1990-ahora)

Mucha actividad de lenguaje, revisiones y estandarización ha ocurrido, llevándonos a los Frameworks

Visual Basic Fail desarrollo de interfaces gráficas(GUI) para Aplicaciones de Windows

Java Sucesor de Oak: designado para la portabilidad
Python Lenguaje de script orientado a objetos
J2EE Basado en el framework de Java para informática empresarial
.NET Framework orientado a objetos de Microsoft
Visual C# Competidor de Java para el Microsoft .NET Framework
Visual Basic .NET Visual Basic para el Microsoft .NET Framework

#########################################################################

Esta primera genera generación de lenguaje de alto nivel representó por lo tanto un paso de
acercamiento al espacio del problema, y un paso de alejamiento de la máquina que había debajo.
Nuestro gran interés es en los lenguajes basados en objetos y en los orientados a objetos, que desde
1990 pocos lenguajes han emergido en esta categoría, entre ellos están Java, C++

Fundamentos del modelo objetos

Los métodos de diseño estructurado surgieron para guiar a los desarrolladores que intentaban construir
sistemas complejos utilizando los algoritmos como bloques fundamentales para su construcción.
Análogamente, los métodos de diseño orientados a objetos han surgido para ayudar a los
desarrolladores a explotar la potencia expresiva de los lenguajes de programación basados en objetos y
orientados a objetos, utilizando las clases y los objetos como bloques básicos de construcción. En
realidad, el modelo de objetos ha recibido la influencia de una serie de factores. no sólo de la
programación orientada a objetos.
POO, DOO y AOO

En ocasiones se da cierta confusión de conceptos cuando nos referimos

al tema orientado a objetos. Revisemos los más significativos. Formalmente un objeto es como una
entidad tangible que muestra algún comportamiento bien definido. Stefik y Bobrow definen los objetos
como «entidades que combinan las propiedades de los Procedimientos y los datos en el sentido de que
realizan computaciones y conservan el estado local»

• Programación orientada a objetos

La programación orientada a objetos es un método de implementación en el que los programas se

organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de
alguna clase y cuyas clases son , todas ellas, miembros de una jerarquía de clases unidas mediante
relaciones de herencia.

• Diseño orientado a objetos

El diseño orientado a objetos es un método de diseño que abarca el proceso de descomposición

orientado a objetos y una notación para describir los modelos lógico y físico, así como los modelos
estático y dinámico del sistema que se diseña.
• Análisis orientado a objetos

El análisis orientado a objetos es un método de análisis que examina los requisitos desde la perspectiva
de las clases y objetos que se encuentran en el vocabulario del dominio del problema

Elementos del modelo objetos

Anteriormente vimos la definición de la programación orientada a objetos, a continuación se tratará el
paradigma de la programación orientada a objetos. En la definición de programación orientada a
objetos vimos que esta enfoca en la identificación de entidades, su estructura, clasificación y
comportamiento dentro del sistema. Teniendo esto presente, tras hacer un modelado de un sistema
utilizando este paradigma el analista deberá identificar los objetos y las clases.

Objetos
Los objetos son cosas reales dentro de un sistema que ocupan un lugar y espacio determinado, son
entidades tangibles. Los objetos llegan a ser aquellas entidades que se mencionan al principio. Los
objetos “un papel bien definido en el dominio del problema.

Clases
Las clases son un conjunto de reglas bajos que hacen las veces de dominios (o campo de actividad)
para un objeto. En otras palabras las clases están compuestas por objetos de las mismas características.
Las clases como tales no existen, solo nos aportan los datos de cuáles son los métodos que pueden
implementar los objetos que se contienen en ella, cual es su comportamiento y cual relación poseen con
otros objetos.
Sin embargo el paradigma no se limita a identificarlos, hay otros elementos que intervienen en este
proceso entre ellos están la abstracción, encapsulación, modularidad, jerarquía, tipos, concurrencia y
persistencia.

Abstracción
El significado de la abstracción. La abstracción es una de las vías fundamentales por la que los
humanos combatimos la complejidad. Hoare sugiere que «la abstracción surge de un reconocimiento de
las similitudes entre ciertos objetos, situaciones o procesos del mundo real, y la decisión de
concentrarse en esas similitudes e ignorar por el momento las diferencias». Shaw define una
abstracción como «una descripción simplificada o especificación de un sistema que enfatiza algunos de
los detalles o propiedades del mismo mientras suprime otros. Una buena abstracción es aquella que
enfatiza detalles significativos al lector o usuario y suprime detalles que son, al menos por el momento,
irrelevantes o causa de distracción». Berzins, Gray y Naumann recomiendan que «un concepto merece
el calificativo de abstracción sólo si se puede describir, comprender y analizar independientemente del
mecanismo que vaya a utilizarse eventualmente para realizarlo». Combinando estos diferentes puntos
de vista. Se define una abstracción del modo siguiente: Una abstracción denota !as características
esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona así fronteras
conceptúales nítidamente definidas respecto a la perspectiva del observador.

Encapsulamiento
El significado del encapsularniento. Aunque anteriormente se describió la abstracción de la clase
Plancultivo como un esquema tiempo/acción, su implantación no es necesariamente una tabla en
sentido literal o una estructura de datos con forma de esquema. En realidad, se elija la representación
que se elija, será indiferente al contrato del cliente con esa clase, siempre y cuando la representación
apoye el contrato. Dicho sencillamente, la abstracción de un objeto debería preceder a las decisiones
sobre su implementación. Una vez que se ha seleccionado una implantación, debe tratarse como un
secreto de la abstracción, oculto para la mayoría de los clientes. Como sugiere sabiamente Ingalls,
«ninguna parte de un sistema complejo debe depender de los detalles internos de otras partes».
Mientras la abstracción «ayuda a las personas a pensar sobre lo que están haciendo», el
encapsulamiento «permite que los cambios hechos en los programas sean fiables con el menor
esfuerzo».
El encapsulamiento proporciona barreras explicitas entre abstracciones diferentes y por tanto conduce a
una clara separación de intereses. Por ejemplo, considérese una vez más la estructura de una planta.
Para comprender cómo funciona la fotosíntesis a un nivel alto de abstracción, se pueden ignorar
detalles como los cometidos de las raíces de la planta o la química de las paredes de las células.
Análogamente. al diseñar una aplicación de bases de datos, es práctica común el escribir programas de
forma que no se preocupen de la representación física de los datos, sino que dependan solo de un
esquema que denota la vista lógica de los mismos. En ambos casos, los objetos a un nivel de
abstracción están protegidos de los detalles de implementación a niveles mas bajos de abstracción. Para
resumir, se define el encapsulamiento como sigue: El encapsulamiento es el proceso de almacenar en
un mismo compartimento los elementos de una abstracción que constituyen su estructura y su
comportamiento; sirve para separar el interfaz contractual de una abstracción y su implantación. Britton
y Parnas llaman a esos elementos encapsulados los «secretos» de una abstracción.

Modularidad
Liskov establece que «la modularización consiste en dividir un programa en módulos que pueden
compilarse separadamente, pero que tienen conexiones con otros módulos. Utilizaremos la definición
de Parnas: "Las conexiones entre módulos son las suposiciones que cada módulo hace acerca de todos
los demás"». . La mayoría de los lenguajes que soportan el módulo como un concepto adicional
distinguen también entre el interfaz de un modulo y su implementación Así, es correcto decir que la
modularidad el encapsulamiento van de la mano. Como en el encapsulamienio, los lenguajes concretos
soportan la modularidad de formas diversas Por ejemplo, los módulos en C++ no son más que ficheros
compilados separadamente. Resumiendo la moduluridad se define como: La modularidad es la
propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y
débilmente acoplados.

Jerarquía
El significado de la jerarquía. La abstracción es algo bueno, pero excepto en las aplicaciones más
triviales, puede haber muchas más abstracciones diferentes de las que se pueden comprender
simultáneamente. El encapsulamiento ayuda a manejar esta complejidad ocultando la visión interna de
las abstracciones. La modularidad también ayuda, ofreciendo una vía para agrupar abstracciones
relacionadas lógicamente. Esto sigue sin ser suficiente. Frecuentemente un conjunto de abstracciones
forma una jerarquía, y la identificación de esas jerarquías en el diseño simplifica en gran medida la
comprensión del problema. Se define la jerarquía como sigue: La jerarquía es una clasificación u
ordenación de abstracciones. Las dos jerarquías más importantes en un sistema complejo son su
estructura de clases (la jerarquía «de clases») y su estructura de objetos (la jerarquía «de parte»).

Tipos (tipificación)
El significado de los tipos. El concepto de tipo se deriva en primer lugar de las teorías sobre los tipos
abstractos de datos. Como sugiere Deutsch, «un tipo es una caracterización precisa de propiedades
estructurales o de comportamiento que comparten una serie de entidades» Para nuestros propósitos, se
utilizarán los términos tipo y clase de manera intercambiable. Aunque los conceptos de clase y tipo son
similares, se incluyen los tipos como elemento separado del modelo de objetos porque el concepto de
tipo pone énfasis en el significado de la abstracción en un sentido muy distinto. En concreto, se
establece lo siguiente: Los tipos son la puesta en vigor de la clase de los objetos, de modo que los
objetos de tipos distintos no pueden intercambiarse solo de formas muy restringidas.

Concurrencia
El significado de la concurrencia. Para ciertos tipos de problema, un sistema autorizado puede tener
que manejar muchos eventos diferentes simultáneamente. Otros problemas pueden implicar tantos
cálculos que excedan la capacidad de cualquier procesador individual. En ambos casos, es natural
considerar el uso de Un conjunto distribuidos de computadores para la implantación que se Persigue o
utilizar procesadores capaces de realizar multitarea. Un solo proceso -denominado hilo de control- es la
raíz a partir de la cual se producen acciones dinámicas independientes dentro del sistema. Todo
programa tiene al menos un hilo de control, pero un sistema que implique concurrencia puede tener
muchos de tales hilos: algunos son transitorios, y otros permanecen durante todo e! ciclo de vida de la
ejecución del sistema. Los sistemas que se ejecutan en múltiples CPUs permiten hilos de control
verdaderamente concurrentes, mientras que los sistemas que se ejecutan en una sola CPU sólo pueden
conseguir la ilusión de hilos concurrentes de control, normalmente mediante algún algoritmo de tiempo
compartido. La concurrencia se define: La concurrencia es la propiedad que distingue un objeto activo
de uno que no esta activo.

Persistencia
Un objeto de software ocupa una cierta cantidad de espacio, y existe durante una cierta cantidad de
tiempo. Atkiston et al. Sugieren que hay un espacio continuo de existencia del objeto, que va desde los
objetos transitorios que surgen en la evaluación de una expresión hasta los objetos de una base de datos
que sobreviven a la ejecución de un único programa. Este espectro de persistencia de objetos abarca lo
siguiente:
• «Resultados transitorios en la evaluación de expresiones.
• Variables locales en la activación de procedimientos.
• Variables propias [como en ALGOL 60], variables globales y elementos del montículo (heap)*
cuya duración difiere de
• Datos que existen entre ejecuciones de un programa. Datos que existen en varias versiones de
un programa.
• Datos que sobreviven al programa.

La persistencia se define como: La persistencia es la propiedad de un objeto por la que sus existencia
trasciende el tiempo (es decir, el objeto continúa existiendo después de que su creador deja de existir)
y/o el espacio (es decir la posición del objeto varía con respecto al espacio de direcciones en el que fue
creado)