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)


Comentarios