t16 Programación Orientada A Objetos

T16 - PROGRAMACIN ORIENTADA A OBJETOS.
1. DISEO ORIENTADO A OBJETOS .............................................................................................................................. 3

1.1. CONCEPTO................................................................................................................................................................. 3
1.2. ORIGENES E HISTORIA............................................................................................................................................ 3
2. ELEMENTOS: OBJETOS, CLASES, HERENCIA, METODOS ................................................................................. 4
2.1. OBJETOS..................................................................................................................................................................... 4
2.1.1. NOTACION .......................................................................................................................................................... 5
2.1.2. ATRIBUTOS ......................................................................................................................................................... 5
2.1.3 METODOS ........................................................................................................................................................... 6
2.2. CLASES ....................................................................................................................................................................... 6
2.2.1. EL CONCEPTO DE ABSTRACION ASOCIADO A LAS CLASES....................................................................... 6
2.2.2. IDENTIFICACION DE CLASES .......................................................................................................................... 6
2.2.3. JERARQUIA DE CLASES .................................................................................................................................... 7
2.3. ENCAPSULACION Y OCULTACIN....................................................................................................................... 7
2.4. MENSAJES.................................................................................................................................................................. 8
2.5. HERENCIA.................................................................................................................................................................. 8
2.5.1. TIPOS DE HERENCIA......................................................................................................................................... 9
2.5.2. CARACTERISTICAS DE LA HERENCIA .......................................................................................................... 10
2.6. POLIMORFISMO...................................................................................................................................................... 11
3. VENTAJAS E INCONVENIENTES .............................................................................................................................. 11
3.1. VENTAJAS DE LA ORIENTACION A OBJETOS .................................................................................................. 11
3.1.1. Enfoque ms natural........................................................................................................................................... 11
3.1.2. Abstraccin......................................................................................................................................................... 12
3.1.3. Reutilizacin ....................................................................................................................................................... 12
3.1.4. Sistemas ms robustos ........................................................................................................................................ 12
3.1.5. Menor acoplamiento........................................................................................................................................... 12
3.1.6. Mayor cohesin .................................................................................................................................................. 12
3.1.7. Mayor capacidad funcional................................................................................................................................ 12
3.1.8. Cambio en nuestra forma de pensar................................................................................................................... 13
3.2. INCONVENIENTES DE LA ORIENTACION A OBJETOS ................................................................................... 13
4. LENGUAJES DE PROGRAMACION ORIENTADOS A OBJETOS (LPOO)......................................................... 13
4.1. CARACTERISTICAS QUE DEFINEN LOS LPOO.................................................................................................. 13
4.2. DESCRIPCION DE LOS PRINCIPALES LPOO ...................................................................................................... 14
4.2.1. Simula................................................................................................................................................................. 14
4.2.2. Smalltalk_80 ....................................................................................................................................................... 14
4.2.3. Ada_95................................................................................................................................................................ 14
4.2.4. C++ .................................................................................................................................................................... 15
4.2.5. Objective-C......................................................................................................................................................... 15
4.2.6. Object Pascal...................................................................................................................................................... 15
4.2.7. Eiffel ................................................................................................................................................................... 15
4.2.8. Spoke .................................................................................................................................................................. 15
4.2.9. Java .................................................................................................................................................................... 15
5. EL LENGUAJE DE MODELIZACION UNIFICADO (UML) ................................................................................... 16
5.1. INTRODUCCION AL UML ...................................................................................................................................... 16
5.1.1. VISION GENERAL DE UML ............................................................................................................................. 16
5.1.2. PARTES DEL UML ............................................................................................................................................ 17
5.2. VISTAS ...................................................................................................................................................................... 17
5.3. ELEMENTOS DEL MODELADO ............................................................................................................................ 17
5.3.1. ELEMENTOS ESTRUCTURALES ..................................................................................................................... 17
TEMARIO-TICC-mar04 T16
Actualizado en marzo de 2004 Pgina 1 de 31
5.3.2. ELEMENTOS DE COMPORTAMIENTO .......................................................................................................... 18
5.3.3. ELEMENTOS DE AGRUPACION ..................................................................................................................... 18
5.3.4. ELEMENTOS DE ANOTACION ........................................................................................................................ 18
5.3.5. REPRESENTACION GRAFICA DE LOS ELEMENTOS ................................................................................... 19
5.3.6. TIPOS DE RELACIONES ENTRE ELEMENTOS.............................................................................................. 19
5.4. DIAGRAMAS DEL UML.......................................................................................................................................... 21
5.4.1. DIAGRAMA DE CLASES ................................................................................................................................... 21
5.4.2. DIAGRAMA DE OBJETOS ................................................................................................................................ 21
5.4.3. DIAGRAMA DE CASOS DE USO...................................................................................................................... 21
5.4.4. DIAGRAMA DE SECUENCIAS ......................................................................................................................... 21
5.4.5. DIAGRAMA DE COLABORACIN................................................................................................................... 21
5.4.6. DIAGRAMA DE ESTADOS (statechart) ............................................................................................................ 22
5.4.7. DIAGRAMA DE ACTIVIDADES........................................................................................................................ 22
5.4.8. DIAGRAMA DE COMPONENTES. ................................................................................................................... 22
5.4.9. DIAGRAMA DE DESPLIEGUE......................................................................................................................... 22
5.5. MECANISMOS GENERALES ................................................................................................................................. 22
6. EL MODELO CORBA (COMMON OBJECT REQUEST BROKER ARCHITECTURE)..................................... 22
6.1. EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS .............................................................................................. 22
6.2. INTRODUCCION A CORBA.................................................................................................................................... 23
6.3. ELEMENTOS DEL MODELO DE REFERENCIA OMA (OBJECT MANAGEMENT ARCHITECTURE) ....................... 24
6.4. ORB (OBJECT REQUEST BROKER) .............................................................................................................................. 25
6.5. OBJETOS DE SERVICIO CORBASERVICES ......................................................................................................... 26
6.6. IDL (INTERFACE DEFINITION LANGUAGE).................................................................................................................. 27
6.7. NUEVAS ESPECIFICACIONES DE CORBA.......................................................................................................... 27
7. CONCLUSIN ................................................................................................................................................................. 28
8. BIBLIOGRAFA .............................................................................................................................................................. 28
9. ESQUEMA RESUMEN ................................................................................................................................................ 29
1. DISEO ORIENTADO A OBJETOS
1.1. CONCEPTO
Desde hace ya un tiempo se habla de la revolucin industrial del software, del paso de una etapa artesanal a una
fase industrial. Una de las causas principales que han motivado este cambio en el desarrollo del software ha sido
la aparicin de las tcnicas orientadas a objetos.
El objetivo del diseo orientado a objetos, no es construir sistemas desarrollando mdulos nuevos, sino
ensamblando los ya existentes. Se persigue la mxima reutilizacin del cdigo, a travs de una mayor
abstraccin. La tecnologa orientada a objetos pone el nfasis en los objetos y su comportamiento, abandonando
el enfoque tradicional de procesos y datos.
La Orientacin a Objetos no es un concepto nuevo. Se introdujo hace ya ms de 30 aos. La repercusin que

est teniendo en todas las facetas del desarrollo de aplicaciones es muy superior a la que ya tuvo en la dcada
de los 70 la programacin estructurada. Por otra parte, el enorme auge del fenmeno Internet hubiese sido
imposible sin las tecnologas de orientacin a objetos.
Suele decirse que cada persona tiene una idea distinta de lo que es la orientacin a objetos. Sin embargo, todo el
mundo coincide en reconocer como principio bsico de la orientacin a objetos la encapsulacin en un mismo
ente de los dos elementos clsicos de los sistemas de informacin: los datos y los procesos. Este ente es el
objeto. La orientacin a objetos consiste en una visin de los objetos como entidades activas que ejecutan
acciones sobre sus propios datos en respuesta a peticiones externas. No considera a unos y a otros (datos y
procesos) como realidades aisladas susceptibles de analizarse e implantarse por separado.
Los objetos tratan de abstraer caractersticas comunes que podrn compartirse entre varias aplicaciones y
reutilizarse todo lo posible. La creacin de un nuevo sistema consiste esencialmente en una labor de ensamblado
de objetos preexistentes, completada con el desarrollo de un porcentaje reducido de nuevos objetos, que a su vez
alimentaran las correspondientes libreras para poder ser utilizados en los prximos sistemas. Por tanto, la
orientacin a objetos recoge premisas bsicas del desarrollo del software:
La propiedad fundamental de los sistemas de informacin actuales es la capacidad de adaptacin.

El mayor grado de abstraccin es la clave para la integracin de sistemas heterogneos.
Podemos terminar este punto diciendo que la orientacin a objetos es, en esencia, una tcnica de construccin y
manipulacin de abstracciones.
Veamos ahora los orgenes y la historia del diseo orientado a objetos, as tambin podremos entender mejor en
que consiste esta tecnologa que ya ha revolucionado el desarrollo del software de aplicaciones.
1.2. ORIGENES E HISTORIA
Las ideas bsicas de la orientacin a objetos nacen a principios de los aos 60 en la universidad de Noruega. Un
equipo dirigido por el Dr. Nygaard se dedicaba a desarrollar sistemas informticos para realizar simulaciones de
sistemas fsicos como simular el funcionamiento y obtener el rendimiento de un motor. La dificultad en la que se
encontraban era doble. Por un lado los programas eran muy complejos y, por otro, forzosamente tenan que ser
muy modificados. Este segundo punto era especialmente problemtico, ya que la razn de ser de los programas
era el cambio y no slo se requeran varias iteraciones para obtener un producto con el rendimiento deseado, sino
que muchas veces se quera obtener diversas alternativas viables cada una con sus ventajas e inconvenientes.
La solucin que idearon fue disear el programa paralelamente al objeto fsico. Es decir, si el objeto fsico tena
cien componentes, el programa tambin tendra cien mdulos, uno por cada pieza. Partiendo el programa de esta
manera, haba una total correspondencia entre el sistema fsico y el sistema informtico. As, cada pieza fsica
tena su abstraccin informtica en un mdulo. De la misma manera que los sistemas fsicos se comunican
envindose seales, los mdulos informticos se comunicaran envindose mensajes. Este enfoque resolvi los
dos problemas planteados. Primeramente, ofreca una forma natural de partir un programa muy complejo y, en
segundo lugar, el mantenimiento pasaba a ser controlable.
Para implementar estas ideas lo que se hizo fue crear un lenguaje para darle soporte, Simula-67, que continua
utilizndose actualmente.
Pero, poco a poco, fue obtenindose otro beneficio muy importante, que es la razn principal por la que la
industria informtica se ha abocado a la orientacin a objetos. Se trata de la reusabilidad. En el proceso de
construccin de un programa se obtienen piezas para futuros programas. Avanzando algunas cifras, se puede
indicar que los niveles de reutilizacin de software pasan del 5-15% en centros no orientados a objetos, a niveles
por encima del 80%.
El siguiente paso se da en los aos 70 en los Estados Unidos. Xerox tiene un centro de investigacin en Palo
Alto, donde trabajan en conceptos que puedan convertirse en productos industriales al cabo de 10 a 20 aos. As
pues, en aquellos aos contrataron a un joven llamado Alan Kay para que llevase a trmino las ideas que
propona en su tesis doctoral, la propuesta de construccin de un ordenador llamado Dynabook, adecuado para
ser utilizado por nios. El ordenador no tena teclado, la pantalla era sensible al tacto y la mayor parte de la
comunicacin era grfica. Al desarrollar este proyecto se invent el 'mouse' y los entornos grficos. Al volver a
encontrarse con una programacin compleja y experimental, como en el caso de Nygaard, decidieron crear un
entorno y lenguaje llamado Smalltalk.
Smalltalk tuvo una gran difusin y cuando en los aos 80 en ATT-Bell quisieron crear un sucesor al lenguaje C,
incorporaron las principales ideas de Smalltalk y de Simula, creando el lenguaje C++. La aparicin de este ltimo
lenguaje supuso un espaldarazo tal que puede afirmarse que se debe al lenguaje C++ la gran extensin de los
conceptos de la orientacin a objetos.
Conviene subrayar que el desarrollo que hemos descrito se refiere slo a la evolucin que ha tenido la orientacin
a objetos en el mundo de la ingeniera del software. Ha existido un desarrollo paralelo de los mismos conceptos
en el mundo de la inteligencia artificial, donde el lenguaje CLOS, una variante de Lisp orientada a objetos, est
enormemente extendido.
2. ELEMENTOS: OBJETOS, CLASES, HERENCIA, METODOS
2.1. OBJETOS
En primer lugar podemos decir que informalmente un objeto es todo aquello que en el mundo real consideramos
un objeto. Se dice que es un trmino ms sencillo de comprender que de definir.
A nivel conceptual, un objeto es cualquier cosa, real o abstracta, acerca de la cual tenemos un concepto, es decir,
una percepcin de su individualidad. No obstante, no nos van a interesar todos los objetos, sino solo aquellos que
son relevantes dentro del entorno en el que estamos. Bajo este enfoque de implantacin, entenderemos por
objeto la encapsulacin de una coleccin de datos relativos a una misma entidad y de las operaciones
susceptibles de realizarse sobre ellos. Es decir, un objeto es una abstraccin de un dato y su comportamiento.
Otra definicin ms seria, un objeto es una entidad que contiene los atributos que describen el estado de un
objeto del mundo real y las acciones que se asocian con el objeto del mundo real.
Por lo tanto: OBJETO = DATOS + OPERACIONES
Los datos deberan estar ocultos en el objeto, y las operaciones seran el interface del objeto con el exterior, con
la particularidad de que estas operaciones estn encapsuladas en "cajas negras", y por lo tanto no son visibles
desde el exterior.
Ahondaremos un poco ms en la comprensin del concepto de objeto, cuando describamos los dos componentes
fundamentales que acabamos de citar: los datos (atributos) y las operaciones (mtodos).
Un objeto es designado con un nombre o un identificador. Por ejemplo: una factura, un coche, un contrato, una
cuenta corriente, un equipo de ftbol, un partido de ftbol, etc. todos ellos referidos a elementos concretos.
2.1.1. NOTACION
Taylor
Yourdon/Coad
Nombre
Atributos
Mtodos
Booch
2.1.2. ATRIBUTOS
A los datos definidos dentro de un objeto es a lo que llamamos atributos. Tambin reciben el nombre de
propiedades, campos o variables del objeto. A efectos prcticos, son similares a los atributos de una entidad de
datos dentro del enfoque del modelo E/R. Siguiendo con los ejemplos anteriores, podramos elegir como atributos
del objeto coche: color, cilindrada, precio, grado de limpieza,...
2.1.3 METODOS
Los mtodos son el conjunto de instrucciones que gestionan los datos de un objeto. Constituyen el
comportamiento del objeto. Hacen referencia, nicamente, a los datos internos del objeto, no pudiendo acceder,
idealmente a los datos de otro objeto.
2.2. CLASES
Una clase es una abstraccin de objetos, es un conjunto de objetos con propiedades (atributos y/o mtodos)
comunes. Por lo tanto, una clase muestra el comportamiento general de un grupo de objetos.
Clase y Objeto son conceptos muy interdependientes. Un objeto pertenece a una clase, y una clase contiene
objetos. La pertenencia de un objeto a una clase se dice que es una instanciacin de dicha clase en ese objeto.
Todos los objetos instanciados en una clase son similares, y difieren en los valores que toman sus atributos. La
definicin de clases permite que los atributos y los mtodos compartidos se definan una sola vez, en la clase, y no
en cada uno de los objetos.
Es importante comprender este planteamiento. Las clases slo existen en tiempo de definicin y compilacin, y se
almacenan en el dispositivo correspondiente. No tienen una vida fuera de ese contexto. Es un concepto esttico.
Los objetos, en cambio, solo existen en tiempo de ejecucin. Se generan cuando se ejecuta la aplicacin, y lo
hacen en base a la definicin que se ha hecho de la clase a la que pertenecen. Son entes dinmicos, que ocupan
memoria, y que deben eliminarse cuando ya no se les referencia. Por lo tanto queda claro que: DISTINTOS
OBJETOS no es igual que DISTINTAS CLASES.
Un objeto se crea mediante el envo de un mensaje de construccin a la clase. Anlogamente para la destruccin
del objeto, la clase recibe un mensaje de destruccin.
Un programa orientado a objetos se resume en 3 sucesos:
Creacin de objetos cuando se necesitan, mediante un mensaje de construccin a la clase.

Intercambio de mensajes entre objetos o entre usuario de objeto y objeto (diferencia fundamental entre
lenguajes POO puros e hbridos).
Eliminacin de objetos cuando no se necesitan, mediante un mensaje de destruccin a la clase.
2.2.1. EL CONCEPTO DE ABSTRACION ASOCIADO A LAS CLASES
Al hablar del concepto de abstraccin asociado a clases, entendemos que las clases son representaciones
abstractas de los conceptos que nos interesan del mundo real.
Hasta ahora, se haban considerado solamente los datos al disear la base de datos. Ahora deberemos hacerlo
con todas las caractersticas de las entidades de nuestro modelo o dominio. Por ejemplo, si un cliente puede tener
un descuento, deberemos asociar la rutina de clculo al cliente y no a los programas de aplicacin. Es decir, la
clase 'cliente' estar descrita no slo por unos datos (nombre, DNI, direccin,...) sino tambin por rutinas (clculo
del descuento, saldo,...).
Desde el momento en que se realizan las abstracciones de esa forma, se estn clasificando las entidades del
dominio en clases. Es decir, la clase 'cliente' (la definicin de la clase cliente) describe no solamente un cliente
concreto sino a todos los clientes que cumplan unas caractersticas dadas. Podemos ver a 'cliente' como una
fbrica de clientes, donde cada cliente concreto ser una 'instancia' (un objeto) de una clase cliente.
2.2.2. IDENTIFICACION DE CLASES
Para identificar una clase, partiendo del enunciado de un problema, podemos identificar los objetos, atributos y
mtodos, utilizando las reglas siguientes:
Todos los nombres del enunciado son objetos a tener en cuenta.
Cosas tangibles ("coche")
Roles o papeles ("empleado")
Organizaciones ("empresa")
Incidentes o sucesos ("liquidacin")
Interacciones o relaciones ("pedido")
Los atributos son las caractersticas individuales de cada objeto, que sern extrados de los adjetivos y
complementos del verbo que haya en el enunciado.
Los mtodos sern los verbos del enunciado. Tipos de mtodos:
Constructor
Destructor
Modificadores del estado
Selectores (obtienen el estado del objeto: "visualizar"
Mezcladores (Ej. "sumar 2 nmeros complejos")
Clculos o procesamientos
2.2.3. JERARQUIA DE CLASES
Las clases en el diseo orientado a objetos, al igual que las entidades en el modelo E/R, se pueden estructurar
definiendo relaciones entre ellas. Existen dos tipos de relaciones entre las clases:
Generalizacin: es la relacin entre una clase origen, llamada subclase, y una clase ms general, llamada
superclase. Corresponde al concepto de es un. Cada objeto de una subclase es un objeto de la
superclase.
Especializacin: es la relacin inversa de la generalizacin. Es la asociacin de una clase con las
subclases para las cuales es una superclase. Permite aadir propiedades (atributos y mtodos)
especficos de la subclase, es decir, especializarla.
Para aclarar los conceptos, ambas (Generalizacin y Especializacin) son relaciones entre clases, mientras que
la instanciacin es la relacin entre un objeto y la clase a la cual pertenece.
La jerarqua de clases permite el funcionamiento de dos de las propiedades ms importantes de la orientacin a

objetos: la herencia y el polimorfismo, que estudiaremos en los apartados siguientes.
A travs de la existencia de este orden jerrquico es posible definir clases de las cuales nicamente nos interesen
su papel como superclase, es decir, sin que vayan a existir objetos reales que se instancien a partir de ellas. A
tales clases se les llama clases virtuales o abstractas.
2.3. ENCAPSULACION Y OCULTACIN
Veamos ahora estas dos propiedades, que son caractersticas del diseo orientado a objetos y que estn muy
ligadas con el concepto de clase.
En una primera aproximacin, la encapsulacin significa agrupar en una solo entidad (caja) datos y operaciones
sobre esos datos. El principio de encapsulacin establece que los atributos de una clase no sean accesibles
desde el exterior sino a travs del intercambio de mensajes establecido, es decir, que slo sean modificados, o
simplemente consultados, a travs de los mtodos de la propia clase.
La principal ventaja de la encapsulacin es que evita la corrupcin de los datos. Si un mismo dato es accesible
desde numerosos mdulos es mucho ms probable que alguno de ellos pueda alterarlo inadecuadamente. El
encapsulado preserva a los datos de un uso arbitrario y no pretendido.
Existen algunos lenguajes que permiten violar, parcialmente, el principio de encapsulacin, permitiendo que
algunos objetos o mdulos puedan acceder a los datos de otro objeto al margen del interfaz de mensaje definido
sobre l. Con ello se persigue conseguir mayor eficiencia en la ejecucin del programa, aun al precio de incurrir
en las mismas debilidades que la programacin estructurada: cualquier modificacin en la estructura de los datos,
afecta a muchos ms objetos que a aqul en la que est incluida.
Asociado al concepto de encapsulacin est el de ocultacin. El concepto de ocultacin de la informacin se

refiere a que cada componente sabe lo mnimo posible de los otros y proporciona la mnima informacin posible
sobre s mismo. Por ejemplo, si en una aplicacin se puede acceder al saldo de un cliente, es innecesario saber si
el saldo est almacenado como un entero o un real o si se ha de ejecutar una rutina para obtenerlo. Slo debe
conocer como pedirle al cliente su saldo y no como est representado internamente.
Desde hace muchos aos, estos principios han estado disponibles en los lenguajes de programacin, aunque su
uso era optativo. La diferencia es que los lenguajes orientados a objetos dan soporte sintctico a los dos
conceptos, y que su uso es obligado en muchos lenguajes puros orientados a objetos.
2.4. MENSAJES
En el paradigma de la orientacin a objetos, una aplicacin es un conjunto de objetos que interactan, que se
comunican entre si mediante mensajes. Los mensajes son, por tanto, el medio a travs del cual los objetos
interaccionan. Tambin se les llama peticiones. La estructura de mensaje es siempre la misma:
nombre del objeto receptor. nombre del mtodo a ejecutar, y una lista de argumentos o parmetros del mensaje.
Pudiera parecer que el envo de mensajes entre objetos es similar a la llamada a un procedimiento o funcin en la
programacin estructurada. En el enfoque tradicional el programa que llama controla en cierta medida la
ejecucin del que es llamado, mientras que en la orientacin a objetos es el propio objeto receptor el responsable
de la ejecucin del mtodo y depende de la definicin de su clase para encontrar las acciones a ejecutar.
Ahora, podemos entender con mayor claridad la ejecucin de una aplicacin orientada a objetos, en la que se
suceden los siguientes tipos de sucesos:
Un objeto, en su ejecucin, genera un mensaje dirigido a objetos de una clase determinada.

Se crea otro objeto con las caractersticas de esa clase, tomando como valores propios los
correspondientes a los parmetros transmitidos y a los calculados a partir de esos parmetros y de la
ejecucin del mtodo solicitado.
Se borran los objetos que se van ejecutando.
Por lo tanto, un objeto se crea cuando se enva un mensaje por otro objeto, que a su vez, se habr creado cuando
se haya enviado otro mensaje por otro objeto, que a su vez... Este bucle se rompe considerando a las entidades
externas, y entre ellas, al propio usuario, como un objeto ms que enva el primer mensaje. Es en ella donde se
inicia el ciclo de ejecucin.
2.5. HERENCIA
Veamos ahora unos de los conceptos ms importantes en le diseo orientado a objetos: la herencia.
Volviendo al ejemplo del punto 2.2.1: la clase 'cliente' estar descrita no slo por unos datos (nombre, DNI,
direccin,...) sino tambin por rutinas (clculo del descuento, saldo,...). Adems pueden tenerse diferentes tipos
de clientes (mayoristas, minoristas, etc.) que sern solo parcialmente diferentes. Es decir, todos tendrn nombre,
DNI, direccin, etc.; pero la rutina de clculo de descuento ser diferente segn el tipo de cliente y adems, cada
cliente tendr una informacin adicional necesaria para calcular el descuento diferente segn el tipo de cliente.
Cuando esto sucede, se puede definir un cliente abstracto como lo que tienen en comn todos los clientes para
definir posteriormente, en cada uno de los tipos de clientes que se tienen, slo aquello que le es particular. Es
decir, cliente mayorista 'heredar' toda la descripcin de cliente abstracto y le aadir algunas de las
caractersticas adicionales.
La herencia permite entonces describir entidades (clases) por diferencia entre ellas; por eso, se dice que
programar con orientacin a objetos es programar para diferenciar. La herencia es la propiedad por la cual las
subclases asumen como propios los atributos y mtodos definidos en las superclases. O dicho de otra forma,
herencia es la capacidad de un objeto (clase) para utilizar las estructuras y los mtodos existentes en
antepasados o ascendientes.
Tiene una importancia extraordinaria: basta con declarar que una clase es hija de otra para que inmediatamente
estn disponibles todas las estructuras de datos y los algoritmos diseados en esta ltima. Adems supone un
excelente mecanismo para propagar los cambios en los niveles altos a travs de todo el sistema.
Cuando usamos herencia decimos que hacemos programacin por herencia, es decir, definicin de nuevos tipos
a partir de otros con los que comparten algn tipo de caracterstica. La herencia es sin duda la caracterstica ms
significativa de la Orientacin a Objetos, la que ms se distancia de las metodolgicas tradicionales.
La utilidad de la herencia es mltiple. Es el elemento medular para conseguir la mayor reutilizacin de cdigo. En
efecto, no es preciso volver a programar ni especificar los procedimientos que se definieron en las clases
superiores. Llegado el momento de su ejecucin, el sistema ser capaz de localizarlos e invocarlos como si
expresamente se hubieran construido en el interior de la subclase. En segundo lugar hay que analizar, disear,
codificar y poner a punto menos, ya que en cuanto se tiene un concepto definido, jams lo repetimos. Como
mucho, si el concepto nuevo es muy parecido a uno anterior, se define el nuevo como la diferencia respecto al
anterior. Si surge un error en la utilizacin de la nueva entidad, seguro que el error est en lo que se ha aadido
porque lo que se ha heredado ya se haba probado.
Entendido el concepto de herencia, vamos ahora a estudiar los dos tipos de herencia ms significativos: la
herencia simple y la herencia mltiple
2.5.1. TIPOS DE HERENCIA
Hay diferentes tipos de herencia, pero nos vamos a centrar en los ms importantes que son: simple y mltiple.
Con esto se quiere decir que, al contrario de la herencia biolgica donde siempre se hereda de dos padres, en la
orientacin a objetos se puede heredar de uno, dos o ms padres. La definicin de cliente minorista a partir de
cliente es un ejemplo de herencia simple. En otro ejemplo, se podra definir un vehculo anfibio como una
herencia (una subclase) de otras dos clases: coche y barco, en este caso la herencia es mltiple.
Ms formalmente podemos definir los dos tipos de herencia, como sigue:
Herencia simple: un tipo derivado se crea a partir de una nica clase base.
Figura
Rectngulo Tringulo
Herencia mltiple: una clase tiene ms de una ascendiente inmediato.
Persona
Profesor Investigador
Profesor
universitario
La herencia mltiple puede plantear diversos tipos de problemas:
La herencia repetida: Ej. : "profesor universitario hereda 2 veces los atributos de persona"
Produce ambigedad respecto a los atributos o los mtodos. En la clase base pueden haber atributos que
se llamen igual:
Escala- -Escala
Sonido Grficos
Resolucin- -Resolucin
Multimedia
Por lo tanto, presenta problemas de colisin cuando las superclases tienen las mismas propiedades. En
esos casos no est plenamente definida la posicin a adoptar. Existen varias soluciones. La ms sencilla
consiste en que el compilador nos detecte los conflictos de nombres, para que el programador los
modifique, es decir, prohibir que puedan tener el mismo nombre. Otra alternativa es la cualificacin del
nombre de la propiedad anteponindole como prefijo el de la superclase. Y tambin es posible establecer
una prelacin entre las diferentes clases que colisionan, para que el sistema pueda resolver el conflicto.
Slo hay 2 lenguajes que incorporan herencia mltiple: Eiffel y C++
2.5.2. CARACTERISTICAS DE LA HERENCIA
Terminamos el estudio del concepto de herencia definiendo tres de sus caractersticas principales:
Anulacin o sustitucin: cuando se redefine un mtodo heredado en la subclase, se dice que estoy
anulando o sustituyendo dicho mtodo. Sera deseable una "herencia selectiva", es decir, seleccionar lo
que se requiere heredar es la mejor forma de anulacin.
Sobrecarga: Propiedad que puede darse tambin sin herencia. Esta es una capacidad de los lenguajes
orientados a objetos, de permitir que una funcin o un operador puedan tener varios significados.
Polimorfismo (sobrecarga con anulacin): es la forma de invocar a distintos mtodos utilizando el mismo
elemento de programa. Lo veremos con ms detalle en el punto siguiente.
2.6. POLIMORFISMO
Definimos Polimorfismo como la capacidad de referirse a objetos de clases distintas en una jerarqua utilizando el
mismo elemento de programa para realizar la misma operacin, pero de formas distintas.
Las subclases pueden incorporar caractersticas propias (atributos y mtodos), que las distingan y especialicen
respecto de las clases padres. Esas caractersticas complementan a las que ya asumen de las entidades padre
mediante el mecanismo de herencia. Sin embargo, en muchas ocasiones es necesario redefinir las propias
caractersticas heredadas para que se comporten de una forma ligeramente distinta. En la mayora de los
lenguajes ello es posible. A tal fenmeno se le llama polimorfismo.
En el ejemplo anterior de los clientes se podra forzar que toda subclase de cliente tuviera una operacin
('servicio' o 'mtodo') de clculo-descuento, definiendo una operacin diferida (o virtual) en la clase abstracta
cliente. Es decir, que cliente pasa a ser una especie de plantilla de todos los clientes donde hay algunas cosas
definidas (nombre, DNI) y otras pendientes a definir en cada subclase (clculo-descuento). En caso de que esto
suceda, podramos garantizar que todo cliente tendra una operacin de 'calcular descuento' asociada, sea el tipo
que sea de cliente. Esto es polimorfismo, que simplifica mucho los programas y los hace extensibles a nuevos
tipos sin necesidad siquiera de recompilar.
Ampliando ms el ejemplo, si quisiramos hacer un programa de listar facturas a partir de unos albaranes,
podramos ir leyendo secuencialmente los albaranes a medida que los fusemos emparejando con clientes. En
cada emparejamiento imprimiramos una factura tras calcular el descuento aplicable. Como sabemos que
descuento es algo que est definido en 'cliente', podramos enviar a cliente el mensaje 'calculo_descuento'
(pedirle que ejecute la rutina) con el albarn como parmetro. La instruccin sera algo parecido a:
descuento := cliente.calculo_descuento (albarn)
Esta instruccin es nica para todos los clientes sean del tipo que sean. Por tanto, con un mismo mensaje y
segn sea el receptor, se ejecutan diferentes rutinas (diferentes formas para un mismo mensaje = polimorfismo).
Adems y mientras se contine cumpliendo que todo cliente tiene una operacin asociada de calculo_descuento,
podremos crear nuevos tipos de clientes sin necesidad de recompilar el programa de facturas.
Se puede afirmar que el polimorfismo completa a la herencia. Esta sera poco til si no dispusiramos de un
mecanismo por medio del cual pudiramos controlarla. Esa herramienta es el polimorfismo.
En relacin con el polimorfismo est el tipo de enlace (binding) del objeto: entendiendo por enlace la vinculacin
entre el nombre de un servicio y su implantacin. Aquellos lenguajes que incorporan enlace dinmico permiten
que la seleccin del mtodo a emplear se haga en tiempo de ejecucin, en funcin de la clase efectiva a la que
pertenezca el objeto receptor del mensaje, lo cual proporciona mayor flexibilidad, y facilita el mantenimiento de los
programas. Los enlaces estticos se resuelven, en cambio, en la fase de compilacin.
3. VENTAJAS E INCONVENIENTES
Tras conocer las caractersticas esenciales de la orientacin a objetos podemos enumerar las principales ventajas
y desventajas que aporta en comparacin con el planteamiento tradicional.
3.1. VENTAJAS DE LA ORIENTACION A OBJETOS
3.1.1. Enfoque ms natural
El concepto de objeto es natural e intuitivo. El mundo est compuesto de objetos. Ya desde una edad temprana,
todas las personas se familiarizan con ellos. Tanto para el desarrollador como para el propio usuario es ms fcil
pensar en trminos de objetos, y la comunicacin entre ambos es ms fluida.
3.1.2. Abstraccin
La orientacin a objetos consiste en aplicar diferentes capas de abstraccin en la modelizacin de una realidad,
identificando sucesivamente los conceptos de objeto, clase y superclase en sus diferentes grados de iteracin.
Algunas metodolgicas hablan incluso de metaclase, entendiendo por tal una clase en la cual sus objetos son a
su vez clases. Este mayor grado de abstraccin es el principio fundamental del que parten casi todas las dems
ventajas del modelo.
3.1.3. Reutilizacin
Debido a ese proceso de abstraccin, las clases se disean para que puedan reutilizarse en muchos sistemas. Ya
hemos comentado que construir una nueva aplicacin es fundamentalmente un proceso de montaje de
componentes ya previamente desarrollados.
En este sentido es fundamental el concepto de libreras o bibliotecas de clases. En ellas se almacenan todas las
clases disponibles. Un objetivo bsico del desarrollo es ir incrementando el nmero y tamao de esas bibliotecas.
De hecho, es habitual distinguir dos tipos de perfiles en el personal de desarrollo: aquellos que se dedican ms
especficamente a construir clases de propsito general, y aquellos otros que construyen aplicaciones a partir del
montaje de dichas clases.
En aquellas empresas que utilizan una mentalidad de orientacin a objetos, es habitual conseguir porcentaje de
reutilizacin de cdigo superior al 80%. La mayor reutilizacin del software, implica por lo tanto, desarrollo de
aplicaciones: ms rpidos, ms baratos y de mayor calidad. Es decir:
Menor tiempo de desarrollo: consecuencia inmediata de este planteamiento es una reduccin muy
significativa en el tiempo necesario para entregar una nueva aplicacin.
Menor volumen de lneas de cdigo: reutilizar componentes significa menos lneas de cdigo nuevo.
Mayor fiabilidad: Menor cdigo significa menor posibilidad de error. Adems, los mdulos reutilizables ya
estn adecuadamente probados antes de incorporarlos a un nuevo sistema.
3.1.4. Sistemas ms robustos
Se entiende por robustez de un sistema la capacidad que tiene dicho sistema para funcionar adecuadamente ms
all de las especificaciones para las que fue diseado. Tiene mucho que ver con la adaptabilidad. Los sistemas
basados en orientacin a objetos son ms fcilmente adaptables, son ms robustos.
3.1.5. Menor acoplamiento
Las aplicaciones de orientacin a objetos tienen un bajo nivel de acoplamiento, debido a la propiedad de
encapsulacin que tiene los objetos. Ello hace que las modificaciones de un objeto no afecten a los dems.
3.1.6. Mayor cohesin
Los objetos presentan una alta cohesin, justamente porque integran una coleccin de datos muy relacionados y
los procesos susceptibles de acometerse sobre ellos.
3.1.7. Mayor capacidad funcional
El bajo acoplamiento y la alta cohesin de los objetos hacen factible que un sistema inicialmente complejo, con
especificaciones funcionales complicadas, pueda ser descompuesto ms fcilmente en diferentes capas de
clases y subclases, cada una con un grado de complejidad menor. Es posible desarrollar aplicaciones muy
avanzadas conceptualmente, pero tcnicamente sencillas.
3.1.8. Cambio en nuestra forma de pensar
James Martn seala que el beneficio ms importante a largo plazo que proporciona la orientacin a objetos es el
cambio en nuestra forma de pensar. Para programar ordenadores, nos hemos acostumbrado a pensar como
ellos. Esto representa un techo en cuanto al tipo de software que podemos desarrollar. La orientacin a objetos
pretende que sean los ordenadores los que piensen como nosotros.
3.2. INCONVENIENTES DE LA ORIENTACION A OBJETOS
Aunque las ventajas del diseo orientado a objetos son muchas e importantes, se pueden tambin sealar
algunos inconvenientes, que debemos tener presentes a la hora de valorar el salto que supone apostar por este
nuevo tipo de diseo. Estos inconvenientes son:
Es una tecnologa nueva

El diseo de mdulos reusables aade coste al proyecto.
Todava no existen libreras comerciales orientadas a objetos.
La reusabilidad se ve seriamente comprometida si los errores no se arreglan correctamente.
La mayora de los lenguajes de programacin no soportan objetos persistentes (aquellos que
almacenados en disco, no cambian entre ejecuciones)
Los lenguajes OO son poco eficientes, ya que algunas de sus principales propiedades obligan a realizar
un mayor esfuerzo en tiempo de ejecucin del programa. Los lenguajes hbridos son ms eficientes, pero
comprometen los principios OO.
Se pueden generar diseos tan malos en lenguajes OO como en cualquier otro lenguaje.
Es muy difcil rastrear el comportamiento de sistemas OO para depurarlos.
La implementacin de tecnologa OO puede ser muy costosa, ya que requiere nuevo HW (fabricado con
nuevas funciones dirigidas expresamente a mejorar la eficiencia en ejecucin de los programas OO),
NUEVO SW y la formacin de los desarrolladores en las tecnologas de OO.
En general, los administradores de proyectos pagan por terminar trabajos a tiempo, y no por hacerlos
reusables. Esto genera un problema cultural para el xito del diseo OO.
4. LENGUAJES DE PROGRAMACION ORIENTADOS A OBJETOS (LPOO)

Antes de hacer un repaso a los diversos lenguajes que han ido apareciendo a lo largo de los ltimos aos, vamos
a definir una serie de caractersticas que puede tener un Lenguaje de Programacin Orientado a objetos, y que
son en las que posteriormente nos vamos a apoyar para ver las diferencias entre unos y otros.
4.1. CARACTERISTICAS QUE DEFINEN LOS LPOO
Distincin entre lenguajes puramente orientados a objetos ( Smalltalk, Eiffel, Spoke, ... ) y lenguajes con
extensin orientada a objetos (C++ , Object Pascal, ... )
Tipado esttico o dinmico o Tipificacin fuerte o dbil:
Los de tipado esttico determinan el tipo de una variable en la compilacin, y por tanto no puede
variar posteriormente (proporciona mayor control sobre el desarrollo y permite una implementacin
ms eficiente).
Al contrario, los de tipado dinmico, lo hacen en tiempo de ejecucin.
Se entiende por enlace la seleccin del mtodo a ejecutar tras la recepcin de un mensaje por parte del
objeto.
Enlace esttico: se realiza en tiempo de compilacin.
Enlace dinmico: se realiza en tiempo de ejecucin. El polimorfismo est basado en el enlace
dinmico. En el enlace existe un procedimiento especial, llamado lookup, que recorre la jerarqua de
clases del objeto receptor en busca del cdigo de mtodo a ejecutar. En este orden de bsqueda se
ejecutar el primer mtodo encontrado con ese nombre.
Asignacin de una zona de memoria e inicializacin de los atributos, cuando se crea un objeto.
Destruccin de los objetos cuando ya no son necesarios o recogida de basura. Puede realizarse de forma
manual o automtica. En la destruccin automtica un objeto se borra cuando ya no es referenciado.
Lenguaje compilado o interpretado.
Soporte de herencia mltiple o simple.
Encapsulacin rgida o no. Es decir, no se permite o se permite el acceso a los datos de un objeto, sin
utilizar los mtodos definidos en el objeto.
Incorporacin de un sistema de excepciones, que permite tener un mayor control sobre los errores que se
producen en los programas. Esto implica la creacin de sistemas cada vez mas seguros.
Se admite concurrencia: "el mundo real es concurrente".
4.2. DESCRIPCION DE LOS PRINCIPALES LPOO
4.2.1. Simula
Fue el primer lenguaje orientado a objetos. Tena una sintaxis parecida a la del lenguaje Algol.
Es un lenguaje compilado, y de tipado esttico. No tiene herencia mltiple. El enlace es esttico, pero a travs de
un mecanismo de funciones virtuales proporciona las caractersticas de los enlaces dinmicos. La destruccin de
objetos se realiza de forma automtica.
4.2.2. Smalltalk_80
Es un lenguaje autnomo, es decir, no es extensin de ningn otro. Es el primer lenguaje creado ex proceso que
implantaba la mayor parte de los conceptos de orientacin a objetos.
Es semicompilado: genera un cdigo intermedio que posteriormente es interpretado por una mquina virtual.
Posee un polimorfismo completo, lo cual permite que tanto el enlace como el tipado sean dinmicos. No se puede
vulnerar la encapsulacin de los datos. La destruccin de objetos no referenciados es automtica.
Soporta herencia simple y concurrencia, pero pobre. Se comercializa con un conjunto de bibliotecas de clases
predefinidas, agrupadas en categoras o jerarquas (E/S, etc...). Existe una versin, Smalltalk V para ordenadores
IBM. C++ y CLOS se han apoyado en caractersticas de Smalltalk.
4.2.3. Ada_95
Ada_83 ya era casi un LPOO. Ada_95 slo aade herencia y enlace dinmico (polimorfismo).
Es un lenguaje compilado. El tipado es esttico y no existe recuperacin automtica de la memoria, lo que

significa que la destruccin de los objetos cuando no son necesarios no es automtica.
4.2.4. C++
C++ es una extensin del lenguaje C, realizada a principios de los aos 80. Incorpora los conceptos de jerarqua
de clases, polimorfismo y herencia, esta ltima, adems, puede ser mltiple. El enlace es dinmico, aunque
implementado a travs de funciones virtuales. El tipado es esttico. A travs de clases amigas es posible eludir la
encapsulacin, y acceder directamente a los atributos de un objeto.
4.2.5. Objective-C
Se trata de otra extensin del lenguaje C para dotarle de capacidades de orientacin a objetos. En su creacin, se
utiliz como modelo el Smalltalk. Es un lenguaje compilado, aunque el tipado es dinmico. No permite violar la
encapsulacin y la herencia es simple.
4.2.6. Object Pascal
Pascal ha sido el prototipo de lenguaje estructurado. Object Pascal es una extensin de l para permitir la
orientacin a objetos. Se trata de un lenguaje compilado. Incorpora los mecanismos de herencia (simple) y
polimorfismo. El enlace es dinmico y el tipado esttico. No existe destruccin dinmica de objetos.
4.2.7. Eiffel
Es un lenguaje desarrollado en C, inspirado en SIMULA con caractersticas aadidas de Smalltalk y Ada. Se

destina a aplicaciones de bases de datos e inteligencia artificial. Por su diseo, es bueno para la ingeniera de
software.
Dispone de casi todas las propiedades de la orientacin a objetos: jerarqua de clases, encapsulacin,
polimorfismo, herencia mltiple,.... Incorpora adems un tratamiento de excepciones, mediante el cual es posible
ejecutar una clase especial, rescue, cuando ocurre una excepcin. El tipado es esttico y el enlace dinmico.
Se ha empezado a implantar concurrencia y persistencia de objetos. Proporciona una biblioteca de clases

predefinidas: Estructuras de datos, E/S, E/S XWindow. La memoria dinmica es gestionada por el entorno y no
por el sistema operativo: incorpora recogida automtica de basura.
4.2.8. Spoke
Es un lenguaje expresamente desarrollado para incorporar casi toda la filosofa de orientacin a objetos. Suele
emplearse para entorno de soporte a la decisin. Al igual que Eiffel, tambin gestiona excepciones, la herencia
mltiple, y la destruccin de objetos automtica.
4.2.9. Java
Java es un lenguaje de programacin orientado a objetos, surgido a partir del propio C++, pero eliminando
algunos de sus aspectos ms cuestionados, como la gestin de punteros o plantillas. Lo redise Sun
Microsystems partiendo de un lenguaje suyo anterior, Oak, que tuvo un xito relativo. A pesar del escaso tiempo
desde su lanzamiento, Java es hoy, el lenguaje orientado a objetos por excelencia, y ms utilizado para
aplicaciones en Internet.
Caractersticas ms significativas del lenguaje:
Semicompilado: a partir del cdigo abstracto genera un cdigo mquina virtual llamado bytecode.
Portable: a cualquier sistema operativo que implemente la mquina virtual Java (JVM).
Es simple, robusto y seguro
Tiene capacidad de multiproceso o multihilo.
Enlace dinmico.
Garbage collection: Java libera de manera automtica la memoria asignada a las variables u objetos que
caen fuera de mbito.
No admite herencia mltiple.
Todo el Java forma parte de una clase, es una clase o describe como funciona una clase.
Java proporciona una manera clara de tratar los errores que se pueden producir durante la ejecucin de
un programa, a travs de las excepciones.
Para facilitar la programacin, Java proporciona unas clases organizadas en una serie de paquetes.
5. EL LENGUAJE DE MODELIZACION UNIFICADO (UML)
5.1. INTRODUCCION AL UML
Los diagramas entidad-relacin ayudan a modelar el componente de representacin de datos de un sistema

software. La representacin de los datos, sin embargo, solo forma parte de un diseo completo de un sistema.
Otros componentes son modelos de interaccin del usuario con el sistema, especificacin de mdulos funcionales
del sistema y su interaccin, etc. El Lenguaje de Modelado Unificado (Unified Modeling Language, UML), es un
lenguaje estndar de modelado propuesto para la creacin de especificaciones de varios componentes de un
sistema de software que permite la representacin conceptual y fsica de dicho sistema.
UML surge como fusin entre una variedad de tcnicas de modelado de sistemas orientados a objetos. Pretende
construir un lenguaje comn para la definicin y transmisin de modelos. Cuando modelamos un sistema
informtico, utilizamos UML y as podemos entendernos con otras personas ya conocen este lenguaje.
5.1.1. VISION GENERAL DE UML
UML es un lenguaje para: Visualizar, Especificar, Construir y Documentar. Sus caractersticas son:
Es un lenguaje: Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la

representacin conceptual y fsica de un sistema, por lo tanto, es un lenguaje estndar para los diversos
pasos del software.
Es un lenguaje para visualizar: UML es algo ms que un simple conjunto de smbolos grficos, en cada
smbolo hay una semntica definida.
Es un lenguaje para especificar: Especificar, significa construir modelos precisos, no complejos. UML
cubre las especificaciones de todas las decisiones de anlisis, diseo e implantacin que deben
realizarse al desarrollar un sistema software.
Es un lenguaje para construir: En UML, sus modelos pueden conectarse de forma directa a gran variedad
de lenguajes de programacin, esta correspondencia permite ingeniera directa: la generacin de cdigo
a partir de un modelo UML en un lenguaje de programacin.
Es un lenguaje para documentar: Una organizacin de software que trabaje bien produce: Requisitos,
Arquitectura, Diseo, Cdigo fuente, Planificacin de proyectos, Pruebas, Prototipos, Versiones. UML
cubre la documentacin de la arquitectura y proporciona requisitos y pruebas y las actividades de
planificacin de proyectos.
5.1.2. PARTES DEL UML
Vistas. Muestran un aspecto de un sistema. Cada vista est compuesta por un conjunto de diagramas.
Elementos de modelado. Los diagramas se componen de elementos que representan clases, objetos,
interfaces, etc.
Diagramas. Grficos que describen el contenido de una vista. En UML se distinguen 9 tipos de diagramas
que adecuadamente combinados proveen todas las vistas del sistema.
Mecanismos generales. Los mecanismos generales proveen comentarios o informacin extra.
En los siguientes apartados vamos a estudiar con ms detalle cada una de las partes del UML.
5.2. VISTAS
Las vistas surgen por el hecho de no poder definir de manera simple toda la informacin necesaria para describir
un sistema. Cada vista se describe con un nmero de diagramas que contienen informacin que destaca un
aspecto particular del sistema. Un diagrama en una vista en particular debe ser lo suficientemente simple como
para ser fcilmente comprensible.
Se distinguen los siguientes tipos de vistas:
Casos de uso. Muestra la funcionalidad del sistema desde el punto de vista de un usuario externo.
Lgica. Muestra como se disea una determinada funcionalidad dentro del sistema.
Componente. Descripcin de la implementacin de los mdulos y sus dependencias.
Concurrencia. Divisin del sistema en procesos y procesadores.
Despliegue. Disposicin fsica del sistema.
5.3. ELEMENTOS DEL MODELADO
Los elementos son abstracciones. Son los primeros que se definen en un modelo. Tenemos elementos de varios
tipos: estructurales, de comportamiento, de agrupacin y de anotacin.
5.3.1. ELEMENTOS ESTRUCTURALES
Son la parte esttica de un modelo y representan cosas que son conceptuales, hay 7 elementos principales:
Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semntica; implementa una o ms interfaces.
Una interfaz es una coleccin de operaciones que especifican un servicio de una clase o componente,
esta describe el comportamiento visible externamente de ese elemento, puede representar el
comportamiento completo de una clase o componente.
Una colaboracin define una interaccin entre diversos elementos. Las colaboraciones tienen dimensin
tanto estructural como de comportamiento, y representan la implantacin de patrones que forman un
sistema. Una clase puede participar en varias colaboraciones.
Un caso de uso es una descripcin de un conjunto de secuencias de acciones que produce un resultado
observable de inters para un actor en particular. Es realizado por una colaboracin. Es un tipo de vista.
Una clase activa, es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin y, por lo
tanto, pueden dar origen a actividades de control, es decir, presentan elementos cuyo comportamiento es
concurrente con otros.
Un componente es una parte fsica y reemplazable de un sistema que se conforma con un conjunto de
interfaces y proporciona la implantacin de dicho conjunto. Representa tpicamente el empaquetamiento
fsico de diferentes elementos lgicos, como clases, interfaces y colaboraciones.
Un Nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional
que por lo general dispone de memoria y capacidad de procesamiento.
Los siete elementos anteriores son los estructurales bsicos que se puede incluir en un modelo UML. Tambin
existen variaciones de estos siete elementos, tales como actores, objetos, seales, utilidades, procesos e hilos,
aplicaciones, documentos, archivos, bibliotecas, pginas y tablas.
5.3.2. ELEMENTOS DE COMPORTAMIENTO
Son las partes dinmicas de los modelos, son los verbos y representan el comportamiento en el tiempo y el
espacio. Hay dos tipos principales de elementos de comportamiento:
El Mensaje. Comunicacin entre objetos. La recepcin de un mensaje se considera normalmente un

evento. Los mensajes pueden ser seales, llamadas a mtodos o similares. Se representan de tres
formas distintas segn muestra la figura:
Una mquina de estados es un comportamiento que especifica las secuencias de estados por las que
pasa un objeto o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a
estos eventos. El comportamiento de una clase individual o una colaboracin de clases pueden
especificarse con una mquina de estados.
Estos dos elementos bsicos estn conectados normalmente a diversos elementos estructurales, principalmente
clases, colaboraciones y objetos.
5.3.3. ELEMENTOS DE AGRUPACION
Son las partes organizativas de los modelos, son las cajas en las que puede descomponerse un modelo.
Un ejemplo de elemento de agrupacin es el paquete que consiste en un mecanismo de propsito general para
organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros
elementos de agrupacin pueden incluirse en un paquete.
5.3.4. ELEMENTOS DE ANOTACION
Son las partes explicativas de los modelos, se pueden aplicar para describir, clarificar y hacer observaciones
sobre cualquier elemento de un modelo.
Un ejemplo de elemento de anotacin es la Nota que es simplemente un smbolo para mostrar las restricciones y
comentarios junto a un elemento o una coleccin de elementos.
5.3.5. REPRESENTACION GRAFICA DE LOS ELEMENTOS
5.3.6. TIPOS DE RELACIONES ENTRE ELEMENTOS
Dependencia. Es una relacin semntica entre dos elementos del modelado, un elemento independiente
y otro dependiente, en la cual un cambio a un elemento independiente puede afectar a la semntica del
otro elemento dependiente. Lnea discontinua con flecha en uno de sus extremos apuntando al elemento
independiente. Ejemplo:
Asociacin. Es una relacin estructural que especifica que los objetos de un elemento estn conectados
con los objetos de otro. Pueden llevar un nombre, frecuentemente un verbo, y una fecha abierta si la
visibilidad es en una sola direccin. Las asociaciones se utilizan cuando se quieran representar relaciones
estructurales. Caractersticas y ejemplo:
Dada una relacin entre dos clases, se puede navegar desde un objeto de una clase hasta un objeto
de la otra clase, y viceversa.
Es posible que ambos extremos de una asociacin estn conectados a la misma clase. Esto significa
que, dado un objeto de la clase, se puede conectar con otros objetos de la misma clase.
Agregacin. Una asociacin normal entre dos clases representa una relacin estructural entre iguales,
ambas clases estn al mismo nivel, sin ser ninguna ms importante que la otra. Una agregacin es un
tipo especial de asociacin, en que representa una relacin estructural entre un todo y sus partes, es
decir, una asociacin no simtrica en la que uno de los extremos cumple un papel predominante respecto
del otro. Rombo del lado del agregado, del todo. Ejemplo:
todo Em presa
*
parte D epartam ento
Composicin. Los atributos son un caso particular de agregacin: son fsicamente contenidos por el
agregado. Rombo negro.
Generalizacin. Es una relacin de especializacin / generalizacin en la cual los objetos del elemento
especializado (hijo) pueden sustituir a los objetos del elemento general (padre). De esta forma, el hijo
comparte la estructura y el comportamiento del padre. Caractersticas y ejemplo:
Los objetos hijos se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la
inversa.
El hijo puede sustituir al padre, una clase hijos hereda las propiedades de sus clases padres.
El hijo puede aadir atributos y operaciones a los que hereda de sus padres.
Una clase puede tener ninguno, uno o ms padres.
Una clase sin padre y uno o ms hijos se llama clase raz o clase base.
Una clase sin hijos se llama clase hoja.
La herencia es una generalizacin.
Figura
C lase base
origen
M over
cam biarTam ao()
dibujar()
generalizacin
R ectngulo C irculo P olgono

Esquina:Punto R adio:Float Puntos:Lista
cuadrado
C lase hoja
Realizacin. Es una relacin semntica entre clasificadores, en donde un clasificador especifica un
contrato que otro clasificador garantiza que cumplir. Se pueden encontrar relaciones de realizacin en
dos sitios: entre interfaces y las clases y componentes que las realizan, entre los casos de uso y las
colaboraciones que los realizan.
5.4. DIAGRAMAS DEL UML
En UML hay 9 diagramas y podemos definirlos como:
la representacin grfica de un conjunto de elementos, visualizado la mayora de las veces como un grafo
conexo de nodos (elementos) y arcos (relaciones).
grficos que muestran a los elementos de modelado (smbolos), ordenados para ilustrar una determinada
parte o aspecto del sistema.
una parte especifica de una vista, aunque un mismo diagrama puede ser parte de varias vistas
dependiendo de sus contenidos.
5.4.1. DIAGRAMA DE CLASES
Un diagrama de clases es similar a un diagrama entidad-relacin. Muestra un conjunto de clases, interfaces y

colaboraciones, as como sus relaciones, incluyendo las clases activas. O dicho de otra forma, muestra la
estructura esttica de clases en el sistema.
5.4.2. DIAGRAMA DE OBJETOS
Un diagrama de objetos muestra un conjunto de objetos y sus relaciones, representando instantneas de

instancias de los elementos encontrados en los diagramas de clase.
Son una variante de un diagrama de clases y utilizan casi una notacin idntica, con dos excepciones: el nombre
de los objetos se escribe subrayado y se muestran todas las instancias en la relacin. La diferencia entre un
diagrama de clases y uno de objetos radica en que este ltimo muestra un determinado nmero de objetos que
son instancias de clases, no clases en s mismo.
5.4.3. DIAGRAMA DE CASOS DE USO
Los diagramas de casos de uso muestran la interaccin entre los usuarios y el sistema, y en particular los pasos
de las tareas que realiza el usuario. Es decir, muestran un conjunto de casos de uso, un nmero de actores
externos y sus relaciones. Estos tres diagramas vistos hasta ahora son especialmente importantes en el
modelado y organizacin del comportamiento de un sistema.
5.4.4. DIAGRAMA DE SECUENCIAS
Los diagramas de secuencias son diagramas de interacciones que resaltan la ordenacin temporal de los
mensajes. Por lo tanto muestran una relacin dinmica entre cierto nmero de objetos que interactan. Es
importante mencionar que los diagramas de interaccin entre un conjunto de objetos y sus relaciones, incluyen
los mensajes que pueden ser enviados entre ellos.
5.4.5. DIAGRAMA DE COLABORACIN
Los diagramas de colaboracin son diagramas de interaccin que resaltan la organizacin estructural de los
objetos que envan y reciben mensajes.
Un diagrama de este tipo muestra una colaboracin dinmica como un diagrama de secuencia. Pero como
contrapartida stos se centran ms en la estructura espacial esttica que permite la colaboracin de un grupo de
objetos y no tanto las interacciones entre objetos desde un punto de vista temporal. Un diagrama de colaboracin
se representa como un diagrama de objetos, donde aparece un determinado nmero de objetos y sus relaciones.
5.4.6. DIAGRAMA DE ESTADOS (statechart)
Los diagramas de estados muestran una mquina de estados, que consta de estados, transiciones, eventos y
actividades. En estos diagramas se muestran los posibles estados que un objeto de esa clase puede tener, y los
eventos que causan un cambio de estado. Cubren la vista dinmica de un sistema y el comportamiento de una
interfaz, una clase o una colaboracin y resaltan el comportamiento dirigido por eventos de un objeto.
5.4.7. DIAGRAMA DE ACTIVIDADES
Los diagramas de actividad describen el flujo de tareas entre varios componentes del sistema. Estos diagramas
cubren la vista dinmica, modelan el funcionamiento de un sistema y resaltan el flujo de control de objetos.
5.4.8. DIAGRAMA DE COMPONENTES.
Los diagramas de componentes describen los componentes software y sus dependencias, representando de esta
manera la estructura del cdigo. Estos diagramas cubren la vista de implantacin esttica, se relacionan con
diagramas de clase en que un componente se corresponde con una o ms clases, interfaces o colaboraciones.
5.4.9. DIAGRAMA DE DESPLIEGUE
Los diagramas de despliegue representan la arquitectura en tiempo de ejecucin, en l aparecen los procesos,
dispositivos (nodos) y componentes software que se ejecutan en esta arquitectura. Por lo tanto, muestra la
configuracin de nodos de procesamiento en tiempo de ejecucin y los componentes que residen en ellos.
5.5. MECANISMOS GENERALES
Notas. Suelen unirse a algn elemento del diagrama a travs de una lnea discontinua, especificando que
elemento es explicado o detallado.
Etiquetas. Elemento del tipo (parmetro, valor) que describe una propiedad de un elemento de modelado.
Restricciones. Relacin semntica cualquiera entre elementos de modelado que limita su uso o el
significado del elemento.
Estereotipos. Mecanismo de extensin que define un nuevo tipo de elemento de modelado que est
basado en uno ya existente.
6. EL MODELO CORBA (Common Object Request Broker Architecture)
6.1. EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS
Los recientes avances en las tecnologas de microprocesadores y las redes de telecomunicaciones han motivado
el desarrollo cada vez mayor de aplicaciones distribuidas.
El modelo de procesamiento distribuido ha pasado por varias etapas de evolucin:
servidores de ficheros
servidores de bases de datos (asociado popularmente como desarrollo cliente/servidor)
servidores de transacciones
y ms recientemente servidores Internet/Web y servidores de objetos distribuidos
Como es lgico, esta evolucin ha tenido su impacto en el desarrollo del software el cual tpicamente estaba
asociado al diseo estructurado y lenguajes procedurales, migrando rpidamente a la adopcin de diseo y
programacin orientada a objetos en ambientes distribuidos.
El desarrollo de aplicaciones distribuidas actualmente est siendo conducido por una combinacin de tecnologas
clave entre las que se encuentran:
Internet TCP/IP Web

Tecnologas de Objetos Distribuidos
Java
Como una evolucin de los mecanismos procedurales distribuidos como DCE (Distributed Computing
Environment) y ONC/RPC (Open Network Computing / Remote Procedure Call) han surgido las arquitecturas de
objetos distribuidos, principalmente representadas por CORBA, DCOM/COM+ (Distributed Component Object
Model) y RMI (Remote Method Invocation) entre otras.
DCOM/COM+ es una arquitectura propuesta por Microsoft y la cual posee amplia difusin, debido a que viene
incluida en sus sistemas operativos Windows 9x y Windows NT/2000. A pesar de esto, se considera una
plataforma propietaria ya que slo se puede implantar en un ambiente Microsoft.
Por el otro lado, CORBA de OMG ha sido planteado como una arquitectura abierta, independiente de la
plataforma hardware o software que se emplee y en la cual forman parte en su proceso de desarrollo gran
cantidad de empresas, universidades y centros de investigacin en todo el mundo.
En medio del enfrentamiento entre los dos grandes lderes, OMG y Microsoft, surge JavaSoft, una filial de Sun
Microsystems. JavaSoft ha diseado RMI que es una especificacin de objetos distribuidos presuponiendo que
todos ellos estn escritos en lenguaje Java (Java Beans). RMI permite el acceso transparente a objetos remotos.
6.2. INTRODUCCION A CORBA
CORBA es un middleware o marco de trabajo estndar y abierto de objetos distribuidos que permite a los
componentes en la red interoperar en un ambiente comn sin importar el lenguaje de desarrollo, sistema
operativo, tipo de red, etc. En esta arquitectura, los mtodos de un objeto remoto pueden ser invocados
transparentemente en un ambiente distribuido y heterogneo a travs de un ORB (Object Request Broker).
Adems del objetivo bsico de ejecutar simplemente mtodos en objetos remotos, CORBA aade un conjunto de
servicios que amplan las potencialidades de estos objetos y conforman una infraestructura slida para el
desarrollo de aplicaciones crticas de negocio.
CORBA es la respuesta del Grupo de Gestin de Objetos (Object Management Group OMG) a la necesidad de
interoperabilidad ante la gran proliferacin de productos hardware y software, es decir permitir a una aplicacin
comunicarse con otra sin importar el tipo de red, protocolo, sistema operativo o lenguaje de desarrollo. La OMG
fue fundada en abril de 1989 por 11 compaas. En octubre de 1989, la OMG comenz a realizar operaciones
independientes como una entidad sin nimo de lucro. A travs de sus comits, la OMG desarrolla
especificaciones independientes de cualquier proveedor para la industria del software. Actualmente, el consorcio
tiene ms de 800 miembros. La OMG se est moviendo a establecer a CORBA como el middleware que est en
todas partes a travs de sus especificaciones: CORBA/IIOP, servicios de objetos, facilidades de Internet y
especificaciones de dominio entre otras.
En CORBA, cada implementacin de un objeto, define su interface a travs un lenguaje conocido como Interface
Definition Language (IDL) o lenguaje de definicin de interfaces, a travs del cual en forma esttica (en el
momento de compilacin) o en forma dinmica (en el momento de ejecucin) un cliente que requiera el servicio
de dicha implementacin de objeto, puede ser ejecutado. Las invocaciones a mtodos remotos son enviadas por
los clientes llamando a objetos locales llamados stubs (generados por un compilador de IDL en modo esttico), el
cual intercepta dichas invocaciones y continua el proceso de llevar y retornar automticamente dicha invocacin.
La implantacin del objeto, no tiene que conocer el mecanismo por el cual un cliente le ha invocado un servicio.
Cuando el cliente y una implementacin de un objeto estn distribuidos por una red, ellos usan el protocolo
GIOP/IIOP suministrado por la arquitectura para lograr la comunicacin:
El GIOP (General Inter-ORB Protocol). Es el protocolo base, que permite la interaccin entre dos ORBs.
El IIOP (Internet Inter-ORB Protocol). Especifica como los mensajes GIOP son intercambiados sobre
TCP/IP. Esto hace posible tambin usar Internet para comunicar ORBs.
CORBA est soportado en dos modelos: Un modelo de objetos, el cual agrega todas las caractersticas de la
orientacin a objetos como tipos de datos, abstraccin, polimorfismo y herencia y un modelo de referencia o
arquitectura conocida como OMA (Object Management Architecture). Veamos los elementos de este modelo.
6.3. ELEMENTOS DEL MODELO DE REFERENCIA OMA (Object Management Architecture)
Object Request Broker ORB: representa el medio o bus de objetos a travs del cual se comunican
todos los objetos participantes en el sistema. El ORB es el corazn de las comunicaciones del estndar.
ORB es referido comercialmente como CORBA. Provee una infraestructura que permite a objetos
comunicarse, independiente de la plataforma especfica y de las tcnicas usadas para implementar el
objeto direccionado. El ORB garantiza la portabilidad y la interoperabilidad de objetos sobre una red de
sistemas heterogneos.
Objetos de servicio - CORBAServices: Son un conjunto de objetos genricos, que son usados por
muchos programas distribuidos, como soporte a tareas muy comunes. Actualmente se tienen definidos
los siguientes objetos de servicio: nombres, ciclo de vida, persistencia, seguridad, consulta, propiedades,
transacciones, eventos, tiempo y negociador entre otros.
Objetos de dominio CORBADomain: Son un conjunto de objetos que son comunes y estndares dentro
de un sector o mercado de aplicacin, se cuentan con dominios como telecomunicaciones, finanzas,
comercio electrnico, medicina, transportes, fabricacin, etc.
Facilidades comunes - CORBAFacilities: Son un conjunto de objetos orientados hacia las aplicaciones de
usuario final como administracin de datos, interfaces de usuario, etc.
Objetos de aplicacin: Son los objetos de aplicacin desarrollados por el programador.
Objetos de Objetos de Facilidades

Aplicacin Dominio comunes
ORB
Objetos de Servicio
nombres, persistencia, eventos, seguridad, ciclo de vida,
Pasamos ahora a estudiar los elementos principales de la arquitectura OMA: ORB y CORBAServices.
6.4. ORB (Object Request Broker)
El Object Request Broker (ORB) es el middleware que establece las relaciones cliente/servidor entre objetos.
Usando un ORB, un cliente puede transparentemente invocar un mtodo sobre un objeto remoto. El ORB
intercepta la llamada y es responsable de encontrar el objeto que implementa el requerimiento, pasar los
parmetros, invocar el mtodo y retornar el resultado. El cliente no se preocupa de donde est el objeto, su
lenguaje de programacin o sistema operativo entre otros aspectos. De esta forma el ORB provee la
interoperabilidad entre aplicaciones sobre diferentes mquinas en un ambiente heterogneo distribuido.
El ORB ofrece una amplia gama de interfaces de servicios distribuidos. Existen bastantes caractersticas del ORB
de CORBA que hacen este producto mejor que otras aplicaciones existentes, entre otras, ofrece varios mtodos
estticos y dinmicos para solicitar servicios a la red, puede trabajar con cualquier lenguaje de programacin que
se escoja y la comunicacin con estos objetos es factible gracias a un lenguaje interface neutral denominado IDL.
Es decir, ORB permite integrar aplicaciones existentes, simplemente describiendo sus interfaces en IDL. Por lo
tanto, lo que permite en el ORB la interoperabilidad e independencia, es la definicin de los objetos en IDL
(estudiaremos este lenguaje en el apartado 6.6).
Adems, el ORB de CORBA trata con conceptos de seguridad y facilidades de transmisin de datos haciendo
fiable y segura su utilizacin. En resumen, ORB es la columna vertebral de CORBA, todas las comunicaciones
entre objetos son mantenidas por el ORB, que conoce donde se encuentra situado cada uno de ellos.
Los elementos de la arquitectura de un ORB son los siguientes:
Implementacin del objeto: Realizado por el programador. Implementa las operaciones especificadas en
la definicin IDL. La implantacin puede ser escrita en lenguajes como C, C++, Java, SmallTalk, Ada, etc.
Cliente: Entidad que invoca una operacin en una implementacin de un objeto remoto. De igual forma
puede ser desarrollado en varios lenguajes y es realizado por un programador de aplicaciones.
Ncleo ORB: Provee mecanismos para transparentemente transportar requerimientos de clientes hacia
implementaciones de objeto remotos. Es responsable de interceptar todas las llamadas del cliente,
localizar el objeto, codificar y enviar el requerimiento, esperar la respuesta, la cual es retornada al cliente.
Interface ORB: Consiste en una coleccin de APIs, localizados en el servidor y en el cliente, muy tiles
cuando debemos comunicar y almacenar referencias de objetos en las peticiones al sistema. Cabe
remarcar que los clientes pueden llamar estticamente o dinmicamente a los objetos pero los servidores
no notan la diferencia. En ambos casos, el ORB localiza el correspondiente adaptador de objeto,
transmite los parmetros y transfiere el control a la implementacin del objeto a travs de la interfaz IDL.
Stubs y Skeleton IDL: Los stubs y skeleton sirven como una conexin cliente-ORB y servidor-ORB. Son
estticos y generados en tiempo de compilacin por un compilador IDL que transforma interfaces IDL al
lenguaje de desarrollo, reduciendo los posibles errores al generar automticamente los stubs y skeleton.
Interface de invocacin dinmica (DII): Esta interface permite a un cliente construir dinmicamente un
requerimiento sin tener un stub, esto es, los requerimientos se construyen en tiempo de ejecucin.
Interface Skeleton dinmica (DSI): Cumple las mismas funciones de DII pero en el lado del servidor.
Permite que el ORB realice llamadas a una implementacin de objeto cuya interfase no se conoce.
Adaptador de objetos: Un adaptador de objeto es la forma principal para acceder los servicios de una
implementacin de objeto provistos por el ORB. Los servicios provistos por el ORB a travs de un
adaptador de objetos incluye: generacin e interpretacin de referencia de objetos, invocacin de
mtodos, seguridad de interacciones, activacin y desactivacin de objetos e implementaciones, mapeo
de referencias de objeto a implementaciones y registro de implementaciones. Un adaptador de objetos
exporta una interfaz pblica a la implementacin del objeto y una privada al skeleton. Actualmente se
tienen definidos dos tipos de adaptadores: BOA (Basic Object Adaptor) y POA (Portable Object Adaptor).
La siguiente figura muestra la arquitectura interna de un ORB:
CLIENTE OBJETO
IDL DSI
skeleton
IDL DII Interface

stub ORB Adaptador de Objetos
GIOP/IIOP Ncleo ORB
6.5. OBJETOS DE SERVICIO CORBAServices
Los CORBAServices especifican servicios bsicos que casi todos los objetos necesitan.
Para cada componente de OMA, la OMG provee una especificacin formal descrita en IDL (como invocar cada
operacin dentro de un objeto) y su semntica (que hace cada operacin y las reglas de comportamiento).
Los CORBAServices proveen servicios a nivel de aplicacin fundamentales para las aplicaciones orientadas a
objetos y componentes en entornos distribuidos. La OMG ha definido alrededor de 15 servicios de objetos:
Nombres: Permite a componentes descubrir otros componentes en un ambiente distribuido, bsicamente

es un servicio de localizacin que asocia identificadores a manejadores que proveen una forma de
contactar el componente deseado en un sistema distribuidos.
Ciclo de vida: Bsicamente es un servicio de configuracin, define servicios y convenciones para crear,
borrar, copiar y mover componentes en un sistema distribuido.
Eventos: Implementa un modelo de comunicacin desacoplado, basado en el paradigma
publicacin/suscripcin. En este modelo, uno o ms publicadores pueden enviar mensajes relacionados
con un tpico especfico, mientras que un grupo de suscriptores reciben los mensajes asncronamente.
Transacciones: gestiona interacciones entre objetos distribuidos estableciendo puntos de acuerdo y
delimitacin de transacciones. Este servicio soporta varios modelos y permite interoperabilidad entre
diferentes arquitecturas de red y modelos de programacin.
Seguridad: Controla la identificacin de los elementos del sistema distribuido (usuarios, objetos,
componentes, etc.) que permite verificar que un cliente est autorizado a acceder los servicios de una
implementacin remota. Adicionalmente permite la comunicacin segura sobre enlaces de comunicacin
inseguros, ofreciendo confidencialidad e integridad de la informacin transmitida.
Tiempo: Suministra informacin del tiempo y permite la definicin de llamadas peridicas.
Licenciamiento: Controla la utilizacin de objetos especficos, inhibiendo uso inadecuado de derechos y
propiedad intelectual.
Propiedades: provee la habilidad de asociar dinmicamente propiedades a objetos que pueden ser
consultados o modificados por otros elementos.
Relaciones: Permite la definicin del papel ejecutado por objetos CORBA en una relacin.
Consulta: Permite a los usuarios y objetos invocar operaciones de consulta sobre colecciones de objetos.
Persistencia: provee mecanismos para retener y mantener el estado de objetos persistentes.
Concurrencia: permite la coordinacin de mltiples accesos a recursos compartidos y permite resolucin
flexible de conflictos.
Externalizacin: define convenciones y protocolos para representar el estado de informacin relacionado
a un objeto en la forma de una secuencia de datos, permitiendo a esta informacin ser almacenada o
transferida a otras localizaciones.
6.6. IDL (Interface Definition Language)
IDL es un producto de la OMG, creado para escribir las interfaces de objetos. CORBA se caracteriza,
principalmente, por su agilidad, compatibilidad y carcter auto descriptivo. Todas estas caractersticas son
posibles gracias al interfaz IDL. La especificacin IDL provee una forma estndar de definir las interfaces a los
objetos CORBA.
Cada uno de los objetos CORBA invocados es bien conocido gracias al IR (interface repository), un archivo donde
el objeto es almacenado y sus parmetros son referenciados. La informacin guardada en el IR es creada
automticamente mediante un precompilador IDL.
Cada componente debe estar descrito con su correspondiente interfaz IDL. Aunque parezca ser inicialmente un
trabajo extra, ahorraremos mucha energa y se convertir en ventajas que sern necesarias para crear y apoyar
una arquitectura cliente/servidor como CORBA. Por medio de su interfaz, un componente se describe, como lo
hacen todos los otros componentes en el sistema. As, el entendimiento entre todos los componentes integrados
es posible. En pocas palabras, las interfaces IDL permiten una total interoperatividad.
No importa con que lenguaje de programacin est escrito un componente ya que IDL no est condicionado por
esto. El enlace entre la interfaz y su componente est hecho con enlaces de lenguaje estandarizados. La OMG ha
estandarizado enlaces para C, C++, Smalltalk y Java, pero cualquier lenguaje puede ser usado creando enlaces
adecuados. Obviamente puede haber problemas cuando el lenguaje a enlazar no ofrece todas las posibilidades
que son proporcionadas por IDL.
IDL es un lenguaje declarativo puro (no se necesita implementacin en la interfaz). Las rdenes de IDL son una
subcoleccin de C++ con rdenes adicionales para soportar objetos distribuidos. El IDL para CORBA es completo
y conciso: la OMG slo ha necesitado 36 hojas para describirlo.
6.7. NUEVAS ESPECIFICACIONES DE CORBA
Despus que fue terminada y normalizada la versin 2.0 en 1996, la OMG continuo trabajando en la incorporacin
de aspectos importantes que deben ser tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de
objetos para incorporar aspectos como: mltiples interfaces por objeto, paso de objetos por valor, modelo de
componentes, soporte para tiempo real y tolerancia a fallos entre otros. CORBA 3.0 se refiere a una serie de
nuevas especificaciones que unidas dan una nueva dimensin a CORBA. Estas nuevas especificaciones estn
divididas en tres categoras:
Integracin con Internet.

Control de calidad de servicio.
Arquitectura de componentes CORBA.
7. CONCLUSIN
El diseo orientado a objetos ha motivado un cambio muy importante en el desarrollo del software. Ha producido
lo que desde hace tiempo se conoce como la revolucin industrial del software. Con esta forma de disear se
persigue la mxima reutilizacin del cdigo, a travs de una mayor abstraccin.
Despus de ver los orgenes y la historia, hemos estudiado con detenimiento los elementos fundamentales de
este tipo de diseo: los objetos formados por atributos y mtodos, las clases como una abstraccin de los objetos
y sus relaciones de generalizacin y especializacin, la encapsulacin y ocultacin en las clases, los mensajes
que comunican unos objetos con otros, la herencia entre clases (superclase y subclase) y el polimorfismo.
Aunque las ventajas del diseo orientado a objetos son evidentes, destacando la abstraccin y la reutilizacin,
hay que tener presentes algunos de los inconvenientes, antes de tomar la decisin de comenzar a desarrollar
aplicaciones bajo esta nueva forma de diseo.
En cuanto a los lenguajes de programacin orientados a objetos (LPOO), actualmente destaca por encima de
todos, Java. Gracias a su portabilidad, robustez y seguridad se ha convertido en el dueo de los objetos internet,
cada vez ms aplicaciones web son desarrolladas con java.
Para la construccin de sistemas orientados a objetos, los lenguajes de modelado de dichos sistemas, tienen un
papel fundamental. El Lenguaje de Modelizacin Unificado, UML (Unified Modeling Language), surge como fusin
de una variedad de tcnicas de modelado de estos sistemas.
Terminamos este tema con el estudio del modelo CORBA. Modelo fundamental en la evolucin que actualmente
tienen los sistemas distribuidos. El modelo CORBA de OMG es una arquitectura de objetos distribuidos, abierta e
independiente de la plataforma software o hardware que se emplee.
8. BIBLIOGRAFA
A. Amescua: ANALISIS Y DISEO ESTRUCTURADO Y ORIENTADO A OBJETOS DE SISTEMAS
INFORMATICOS. MacGraw Hill
Grady Booch: ANALISIS DE DISEO ORIENTADO A OBJETOS CON APLICACIONES (2 ED.)
Bertrand Meyer: "Object Oriented Software Construction" 2nd Edition. Prentice-Hall, 1997.
A. Addison-Wesley: "The CORBA Reference Guide". POPE, 1998.
LPEZ GMEZ, G., SALAS BLANCO, M., SILES PELEZ, R. Y SORIANO CAMINO: Arquitectura de
Objetos Distribuidos CORBA", F. Servicio de Publicaciones de la Facultad de Informtica (U.P.M.), 2000.
9. ESQUEMA RESUMEN
El objetivo del diseo orientado a objetos, no es construir sistemas desarrollando mdulos nuevos, sino
ensamblando los ya existentes. Se persigue la mxima reutilizacin del cdigo, a travs de una mayor
abstraccin. La tecnologa orientada a objetos pone el nfasis en los objetos y su comportamiento, abandonando
el enfoque tradicional de procesos y datos.
Un principio bsico de la orientacin a objetos es la encapsulacin en un mismo ente de los dos elementos
clsicos de los sistemas de informacin: los datos y los procesos. Este ente es el objeto.
Los elementos y conceptos fundamentales del diseo orientado a objetos son:
Objeto: A nivel conceptual, un objeto es cualquier cosa, real o abstracta, acerca de la cual tenemos un
concepto, es decir, una percepcin de su individualidad. Es decir, un objeto es una abstraccin de un dato
y de su comportamiento. Por tanto: OBJETO = DATOS + OPERACIONES
Atributos: A los datos definidos dentro de un objeto es a lo que llamamos atributos. Tambin reciben el
nombre de propiedades, campos o variables del objeto.
Mtodos: Los mtodos son el conjunto de instrucciones que gestionan los datos de un objeto.
Constituyen lo que se llama el comportamiento del objeto
Clases: Una clase es una abstraccin de objetos, es un conjunto de objetos con propiedades (atributos
y/o mtodos) comunes. Por lo tanto, una clase muestra el comportamiento general de un grupo de
objetos. Al hablar del concepto de abstraccin asociado a clases, entendemos que las clases son
representaciones abstractas de los conceptos que nos interesan del mundo real. Existen dos tipos de
relaciones entre clases:
Generalizacin: es la relacin entre una clase origen, llamada subclase, y una clase ms general,
llamada superclase.
Especializacin: es la relacin inversa de la generalizacin. Es la asociacin de una clase con las
subclases para las cuales es una superclase.
Encapsulacin: El principio de encapsulacin establece que los atributos de una clase no sean
accesibles desde el exterior sino a travs del intercambio de mensajes establecido, es decir, que slo
sean modificados, o simplemente consultados, a travs de los mtodos de la propia clase.
Ocultacin: El concepto de ocultacin de la informacin se refiere a que cada componente sabe lo
mnimo posible de los otros y proporciona la mnima informacin posible sobre s mismo.
Mensajes: Son el medio a travs del cual los objetos interaccionan.
Herencia: La herencia es la propiedad por la cual las subclases asumen como propios los atributos y
mtodos definidos en las superclases. O dicho de otra forma, herencia es la capacidad de un objeto
(clase) para utilizar las estructuras y los mtodos existentes en antepasados o ascendientes. Tiene una
importancia extraordinaria. En virtud de ella, basta con declarar que una clase es hija de otra para que
inmediatamente estn disponibles todas las estructuras de datos y los algoritmos diseados en esta
ltima. Se definen dos tipos de herencia:
Herencia simple: un tipo derivado se crea a partir de una nica clase base.
Herencia mltiple: una clase tiene ms de un ascendiente inmediato.
Polimorfismo: Capacidad de referirse a objetos de clases distintas en una jerarqua utilizando el mismo
elemento de programa para realizar la misma operacin, pero de formas distintas.
Las principales ventajas de la orientacin a objetos son:
El enfoque es ms natural e intuitivo, gracias al concepto de objeto.

Se aplica diferentes capas de abstraccin en la modelizacin de la realidad.
Las clases se disean para que puedan reutilizarse en muchos sistemas.
Favorece el desarrollo de sistemas robustos, es decir, sistemas adaptables.
Las aplicaciones tienen un bajo nivel de acoplamiento y un alto grado de cohesin. La modificacin de un
objeto no afecta a los dems.
Un sistema complejo, puede descomponerse fcilmente en diferentes capas de clases y subclases.
Ayuda a un cambio en nuestra forma de pensar. Los ordenadores deben pensar como nosotros.
El Lenguaje de Modelado Unificado (Unified Modeling Language, UML), es un lenguaje estndar de modelado
propuesto para la creacin de especificaciones de varios componentes de un sistema de software que permite la
representacin conceptual y fsica de dicho sistema.
UML es un lenguaje para: Visualizar, Especificar, Construir y Documentar. Las partes del UML son:
Vistas. Muestran un aspecto de un sistema. Cada vista est compuesta por un conjunto de diagramas.
Tipos de vistas:
Casos de uso. Muestra la funcionalidad del sistema desde el punto de vista de un usuario externo.
Lgica. Muestra como se disea una determinada funcionalidad dentro del sistema.
Componente. Descripcin de la implementacin de los mdulos y sus dependencias.
Concurrencia. Divisin del sistema en procesos y procesadores.
Despliegue. Disposicin fsica del sistema.
Elementos de modelado. Los diagramas se componen de elementos que representan clases, objetos,
interfaces, etc. Hay cuatro tipos:
Elementos estructurales: son la parte esttica de un modelo y representan cosas que son
conceptuales, hay 7 elementos principales: una clase, una interfaz, una colaboracin, un caso de
uso, una clase activa, un componente y un nodo.
Elementos de comportamiento: Son las partes dinmicas de los modelos, son los verbos y
representan el comportamiento en el tiempo y el espacio. Hay dos tipos principales: el mensaje y la
mquina de estados.
Elementos de agrupacin: Son las partes organizativas de los modelos, son las cajas en las que
puede descomponerse un modelo.
Elementos de anotacin: Son las partes explicativas de los modelos, se pueden aplicar para describir,
clarificar y hacer observaciones sobre cualquier elemento de un modelo.
Diagramas. Grficos que describen el contenido de una vista. En UML hay 9 tipos de diagramas que
combinados proveen todas las vistas del sistema. Son los Diagramas: de clases, de objetos, de casos de
uso, de secuencias, de colaboracin, de estados, de actividades, de componentes y de despliegue.
Mecanismos generales. Los mecanismos generales proveen comentarios o informacin extra. Son los
siguientes: Notas, Etiquetas, Restricciones y Estereotipos.
CORBA es un middleware o marco de trabajo estndar y abierto de objetos distribuidos que permite a los
componentes en la red interoperar en un ambiente comn sin importar el lenguaje de desarrollo, sistema
operativo, tipo de red, etc. En esta arquitectura, los mtodos de un objeto remoto pueden ser invocados
transparentemente en un ambiente distribuido y heterogneo a travs de un ORB (Object Request Broker).
CORBA est soportado en dos modelos: Un modelo de objetos, el cual agrega todas las caractersticas de la
orientacin a objetos como tipos de datos, abstraccin, polimorfismo y herencia y un modelo de referencia o
arquitectura conocida como OMA (Object Management Architecture). Veamos los elementos de este modelo:
Object Request Broker ORB: representa el medio o bus de objetos a travs del cual se comunican
todos los objetos participantes en el sistema. El ORB es el corazn de las comunicaciones del estndar.
Los elementos de la arquitectura de un ORB son: Implementacin del objeto, Cliente, Ncleo ORB,
Interface ORB, Stubs y Skeleton IDL, Interface de invocacin dinmica (DII), Interface Skeleton dinmica
y adaptador de objetos.
Objetos de servicio - CORBAServices: Son un conjunto de objetos genricos, que son usados por
muchos programas distribuidos, como soporte a tareas muy comunes. Actualmente se tienen definidos
los siguientes objetos de servicio: nombres, ciclo de vida, persistencia, seguridad, consulta, propiedades,
transacciones, eventos, tiempo y negociador entre otros.
Objetos de dominio CORBADomain: Son un conjunto de objetos que son comunes y estndares
dentro de un sector o mercado de aplicacin, se cuentan con dominios como telecomunicaciones,
finanzas, comercio electrnico, medicina, transportes, fabricacin, etc.
Facilidades comunes - CORBAFacilities: Son un conjunto de objetos orientados hacia las aplicaciones
de usuario final como administracin de datos, interfaces de usuario, etc.
Objetos de aplicacin: Son los objetos de aplicacin desarrollados por el programador.
El Lenguaje de Definicin de Interface (IDL, Interface Definition Language) es un producto de la OMG, creado
para escribir las interfaces de objetos. CORBA se caracteriza, principalmente, por su agilidad, compatibilidad y
carcter auto descriptivo. Todas estas caractersticas son posibles gracias al interfaz IDL. Por lo tanto, la
especificacin IDL provee una forma estndar de definir las interfaces a los objetos CORBA.
IDL no est condicionado por el lenguaje de programacin en que est escrito un componente. El enlace entre la
interfaz y su componente est hecho con enlaces de lenguaje estandarizados. La OMG ha estandarizado enlaces
para C, C++, Smalltalk y Java, pero se puede usar cualquier lenguaje creando enlaces adecuados.

t16 Programación Orientada A Objetos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

t16 Programación Orientada A Objetos

Uploaded by

Copyright:

Available Formats

T16 - PROGRAMACIN ORIENTADA A OBJETOS.

1. DISEO ORIENTADO A OBJETOS .............................................................................................................................. 3

La Orientacin a Objetos no es un concepto nuevo. Se introdujo hace ya ms de 30 aos. La repercusin que

La propiedad fundamental de los sistemas de informacin actuales es la capacidad de adaptacin.

1.2. ORIGENES E HISTORIA

2. ELEMENTOS: OBJETOS, CLASES, HERENCIA, METODOS

Por lo tanto: OBJETO = DATOS + OPERACIONES

Un programa orientado a objetos se resume en 3 sucesos:

Creacin de objetos cuando se necesitan, mediante un mensaje de construccin a la clase.

2.2.1. EL CONCEPTO DE ABSTRACION ASOCIADO A LAS CLASES

2.2.2. IDENTIFICACION DE CLASES

2.2.3. JERARQUIA DE CLASES

La jerarqua de clases permite el funcionamiento de dos de las propiedades ms importantes de la orientacin a

2.3. ENCAPSULACION Y OCULTACIN

Asociado al concepto de encapsulacin est el de ocultacin. El concepto de ocultacin de la informacin se

Un objeto, en su ejecucin, genera un mensaje dirigido a objetos de una clase determinada.

2.5.1. TIPOS DE HERENCIA

Ms formalmente podemos definir los dos tipos de herencia, como sigue:

La herencia mltiple puede plantear diversos tipos de problemas:

Slo hay 2 lenguajes que incorporan herencia mltiple: Eiffel y C++

2.5.2. CARACTERISTICAS DE LA HERENCIA

3.1. VENTAJAS DE LA ORIENTACION A OBJETOS

3.1.1. Enfoque ms natural

3.1.4. Sistemas ms robustos

3.1.5. Menor acoplamiento

3.1.6. Mayor cohesin

3.1.7. Mayor capacidad funcional

3.1.8. Cambio en nuestra forma de pensar

3.2. INCONVENIENTES DE LA ORIENTACION A OBJETOS

Es una tecnologa nueva

4. LENGUAJES DE PROGRAMACION ORIENTADOS A OBJETOS (LPOO)

4.1. CARACTERISTICAS QUE DEFINEN LOS LPOO

4.2. DESCRIPCION DE LOS PRINCIPALES LPOO

Es un lenguaje compilado. El tipado es esttico y no existe recuperacin automtica de la memoria, lo que

4.2.6. Object Pascal

Es un lenguaje desarrollado en C, inspirado en SIMULA con caractersticas aadidas de Smalltalk y Ada. Se

Se ha empezado a implantar concurrencia y persistencia de objetos. Proporciona una biblioteca de clases

Caractersticas ms significativas del lenguaje:

5. EL LENGUAJE DE MODELIZACION UNIFICADO (UML)

5.1. INTRODUCCION AL UML

Los diagramas entidad-relacin ayudan a modelar el componente de representacin de datos de un sistema

5.1.1. VISION GENERAL DE UML

Es un lenguaje: Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la

Se distinguen los siguientes tipos de vistas:

5.3. ELEMENTOS DEL MODELADO

5.3.1. ELEMENTOS ESTRUCTURALES

5.3.2. ELEMENTOS DE COMPORTAMIENTO

El Mensaje. Comunicacin entre objetos. La recepcin de un mensaje se considera normalmente un

5.3.3. ELEMENTOS DE AGRUPACION

5.3.4. ELEMENTOS DE ANOTACION

5.3.5. REPRESENTACION GRAFICA DE LOS ELEMENTOS

5.3.6. TIPOS DE RELACIONES ENTRE ELEMENTOS

R ectngulo C irculo P olgono

En UML hay 9 diagramas y podemos definirlos como:

5.4.1. DIAGRAMA DE CLASES

Un diagrama de clases es similar a un diagrama entidad-relacin. Muestra un conjunto de clases, interfaces y

5.4.2. DIAGRAMA DE OBJETOS

Un diagrama de objetos muestra un conjunto de objetos y sus relaciones, representando instantneas de

5.4.3. DIAGRAMA DE CASOS DE USO

5.4.4. DIAGRAMA DE SECUENCIAS

5.4.5. DIAGRAMA DE COLABORACIN

5.4.7. DIAGRAMA DE ACTIVIDADES

5.4.8. DIAGRAMA DE COMPONENTES.