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)
ALGOL 58 Expresiones Matemáticas
Flowmatric Expresiones Matemáticas
IPL V Expresiones Matemáticas
- Segunda generación de lenguajes( 1959-1961)
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)
ALGOL 68 Riguroso sucesor a ALGOL 60
Pascal Simple sucesor a ALGOL 60
Simula Clases, Abstracción de datos
- La brecha generacional
C Eficiente, pequeños ejecutables
FORTRAN 77 Estandarización
- El auge orientado a objetos(1980-1990, pero algunos lenguajes sobrevivieron)
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)
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

- Programación orientada a objetos
- Diseño orientado a objetos
- Análisis orientado a objetos
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.

Comentarios
Publicar un comentario