t16 Programación Orientada a Objetos

T16 - PROGRAMACIÓN ORIENTADA A OBJETOS.

1.

DISEÑO ORIENTADO A OBJETOS .............................................................................................................................. 3 1.1. 1.2.

2.

CONCEPTO................................................................................................................................................................. 3 ORIGENES E HISTORIA............................................................................................................................................ 3

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 OCULTACIÓN....................................................................................................................... 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 más natural........................................................................................................................................... 11 3.1.2. Abstracción......................................................................................................................................................... 12 3.1.3. Reutilización ....................................................................................................................................................... 12 3.1.4. Sistemas más robustos ........................................................................................................................................ 12 3.1.5. Menor acoplamiento........................................................................................................................................... 12 3.1.6. Mayor cohesión .................................................................................................................................................. 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 Actualizado en marzo de 2004

T16 Página 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 COLABORACIÓN................................................................................................................... 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. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7.

EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS .............................................................................................. 22 INTRODUCCION A CORBA.................................................................................................................................... 23 ELEMENTOS DEL MODELO DE REFERENCIA OMA (OBJECT MANAGEMENT ARCHITECTURE) ....................... 24 ORB (OBJECT REQUEST BROKER) .............................................................................................................................. 25 OBJETOS DE SERVICIO – CORBASERVICES ......................................................................................................... 26 IDL (INTERFACE DEFINITION LANGUAGE).................................................................................................................. 27 NUEVAS ESPECIFICACIONES DE CORBA.......................................................................................................... 27

7.

CONCLUSIÓN ................................................................................................................................................................. 28

8.

BIBLIOGRAFÍA .............................................................................................................................................................. 28

9.

ESQUEMA – RESUMEN ................................................................................................................................................ 29


T16 Página 2 de 31

1.

DISEÑO ORIENTADO A OBJETOS

1.1.

CONCEPTO

Desde hace ya un tiempo se habla de la revolución 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 aparición de las técnicas orientadas a objetos. El objetivo del diseño orientado a objetos, no es construir sistemas desarrollando módulos nuevos, sino ensamblando los ya existentes. Se persigue la máxima reutilización del código, a través de una mayor abstracción. La tecnología orientada a objetos pone el énfasis en los objetos y su comportamiento, abandonando el enfoque tradicional de procesos y datos. La Orientación a Objetos no es un concepto nuevo. Se introdujo hace ya más de 30 años. La repercusión que está teniendo en todas las facetas del desarrollo de aplicaciones es muy superior a la que ya tuvo en la década de los 70 la programación estructurada. Por otra parte, el enorme auge del fenómeno Internet hubiese sido imposible sin las tecnologías de orientación a objetos. Suele decirse que cada persona tiene una idea distinta de lo que es la orientación a objetos. Sin embargo, todo el mundo coincide en reconocer como principio básico de la orientación a objetos la encapsulación en un mismo ente de los dos elementos clásicos de los sistemas de información: los datos y los procesos. Este ente es el objeto. La orientación a objetos consiste en una visión 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 características comunes que podrán compartirse entre varias aplicaciones y reutilizarse todo lo posible. La creación 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 librerías para poder ser utilizados en los próximos sistemas. Por tanto, la orientación a objetos recoge premisas básicas del desarrollo del software: □

La propiedad fundamental de los sistemas de información actuales es la capacidad de adaptación.

□

El mayor grado de abstracción es la clave para la integración de sistemas heterogéneos.

Podemos terminar este punto diciendo que la orientación a objetos es, en esencia, una técnica de construcción y manipulación de abstracciones. Veamos ahora los orígenes y la historia del diseño orientado a objetos, así también podremos entender mejor en que consiste esta tecnología que ya ha revolucionado el desarrollo del software de aplicaciones.

1.2.

ORIGENES E HISTORIA

Las ideas básicas de la orientación a objetos nacen a principios de los años 60 en la universidad de Noruega. Un equipo dirigido por el Dr. Nygaard se dedicaba a desarrollar sistemas informáticos para realizar simulaciones de sistemas físicos 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 tenían que ser muy modificados. Este segundo punto era especialmente problemático, ya que la razón de ser de los programas era el cambio y no sólo se requerían varias iteraciones para obtener un producto con el rendimiento deseado, sino que muchas veces se quería obtener diversas alternativas viables cada una con sus ventajas e inconvenientes. La solución que idearon fue diseñar el programa paralelamente al objeto físico. Es decir, si el objeto físico tenía cien componentes, el programa también tendría cien módulos, uno por cada pieza. Partiendo el programa de esta manera, había una total correspondencia entre el sistema físico y el sistema informático. Así, cada pieza física tenía su abstracción informática en un módulo. De la misma manera que los sistemas físicos se comunican enviándose señales, los módulos informáticos se comunicarían enviándose mensajes. Este enfoque resolvió los


T16 Página 3 de 31

dos problemas planteados. Primeramente, ofrecía 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 utilizándose actualmente. Pero, poco a poco, fue obteniéndose otro beneficio muy importante, que es la razón principal por la que la industria informática se ha abocado a la orientación a objetos. Se trata de la reusabilidad. En el proceso de construcción de un programa se obtienen piezas para futuros programas. Avanzando algunas cifras, se puede indicar que los niveles de reutilización 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 años 70 en los Estados Unidos. Xerox tiene un centro de investigación en Palo Alto, donde trabajan en conceptos que puedan convertirse en productos industriales al cabo de 10 a 20 años. Así pues, en aquellos años contrataron a un joven llamado Alan Kay para que llevase a término las ideas que proponía en su tesis doctoral, la propuesta de construcción de un ordenador llamado Dynabook, adecuado para ser utilizado por niños. El ordenador no tenía teclado, la pantalla era sensible al tacto y la mayor parte de la comunicación era gráfica. Al desarrollar este proyecto se inventó el 'mouse' y los entornos gráficos. Al volver a encontrarse con una programación compleja y experimental, como en el caso de Nygaard, decidieron crear un entorno y lenguaje llamado Smalltalk. Smalltalk tuvo una gran difusión y cuando en los años 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 aparición de este último lenguaje supuso un espaldarazo tal que puede afirmarse que se debe al lenguaje C++ la gran extensión de los conceptos de la orientación a objetos. Conviene subrayar que el desarrollo que hemos descrito se refiere sólo a la evolución que ha tenido la orientación a objetos en el mundo de la ingeniería 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. 2.1.

ELEMENTOS: OBJETOS, CLASES, HERENCIA, METODOS 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 término más 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 percepción 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 implantación, entenderemos por objeto la encapsulación de una colección de datos relativos a una misma entidad y de las operaciones susceptibles de realizarse sobre ellos. Es decir, un objeto es una abstracción de un dato y su comportamiento. Otra definición más 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 deberían estar ocultos en el objeto, y las operaciones serían el interface del objeto con el exterior, con la particularidad de que estas operaciones están encapsuladas en "cajas negras", y por lo tanto no son visibles desde el exterior. Ahondaremos un poco más en la comprensión del concepto de objeto, cuando describamos los dos componentes fundamentales que acabamos de citar: los datos (atributos) y las operaciones (métodos).


T16 Página 4 de 31

Un objeto es designado con un nombre o un identificador. Por ejemplo: una factura, un coche, un contrato, una cuenta corriente, un equipo de fútbol, un partido de fútbol, etc. todos ellos referidos a elementos concretos.

2.1.1. NOTACION Taylor

Yourdon/Coad

Nombre Atributos

Métodos

Booch

2.1.2. ATRIBUTOS A los datos definidos dentro de un objeto es a lo que llamamos atributos. También reciben el nombre de propiedades, campos o variables del objeto. A efectos prácticos, son similares a los atributos de una entidad de datos dentro del enfoque del modelo E/R. Siguiendo con los ejemplos anteriores, podríamos elegir como atributos del objeto coche: color, cilindrada, precio, grado de limpieza,...


T16 Página 5 de 31

2.1.3

METODOS

Los métodos 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 abstracción de objetos, es un conjunto de objetos con propiedades (atributos y/o métodos) 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 instanciación 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 definición de clases permite que los atributos y los métodos compartidos se definan una sola vez, en la clase, y no en cada uno de los objetos. Es importante comprender este planteamiento. Las clases sólo existen en tiempo de definición y compilación, y se almacenan en el dispositivo correspondiente. No tienen una vida fuera de ese contexto. Es un concepto estático. Los objetos, en cambio, solo existen en tiempo de ejecución. Se generan cuando se ejecuta la aplicación, y lo hacen en base a la definición que se ha hecho de la clase a la que pertenecen. Son entes dinámicos, 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 envío de un mensaje de construcción a la clase. Análogamente para la destrucción del objeto, la clase recibe un mensaje de destrucción. Un programa orientado a objetos se resume en 3 sucesos: □

Creación de objetos cuando se necesitan, mediante un mensaje de construcción a la clase.

□

Intercambio de mensajes entre objetos o entre usuario de objeto y objeto (diferencia fundamental entre lenguajes POO puros e híbridos).

□

Eliminación de objetos cuando no se necesitan, mediante un mensaje de destrucción a la clase.

2.2.1. EL CONCEPTO DE ABSTRACION ASOCIADO A LAS CLASES Al hablar del concepto de abstracción asociado a clases, entendemos que las clases son representaciones abstractas de los conceptos que nos interesan del mundo real. Hasta ahora, se habían considerado solamente los datos al diseñar la base de datos. Ahora deberemos hacerlo con todas las características de las entidades de nuestro modelo o dominio. Por ejemplo, si un cliente puede tener un descuento, deberemos asociar la rutina de cálculo al cliente y no a los programas de aplicación. Es decir, la clase 'cliente' estará descrita no sólo por unos datos (nombre, DNI, dirección,...) sino también por rutinas (cálculo del descuento, saldo,...). Desde el momento en que se realizan las abstracciones de esa forma, se están clasificando las entidades del dominio en clases. Es decir, la clase 'cliente' (la definición de la clase cliente) describe no solamente un cliente concreto sino a todos los clientes que cumplan unas características dadas. Podemos ver a 'cliente' como una fábrica 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 métodos, utilizando las reglas siguientes:


T16 Página 6 de 31

□

Todos los nombres del enunciado son objetos a tener en cuenta. à

Cosas tangibles ("coche")

à

Roles o papeles ("empleado")

à

Organizaciones ("empresa")

à

Incidentes o sucesos ("liquidación")

à

Interacciones o relaciones ("pedido")

□

Los atributos son las características individuales de cada objeto, que serán extraídos de los adjetivos y complementos del verbo que haya en el enunciado.

□

Los métodos serán los verbos del enunciado. Tipos de métodos: à

Constructor

à

Destructor

à

Modificadores del estado

à

Selectores (obtienen el estado del objeto: "visualizar"

à

Mezcladores (Ej. "sumar 2 números complejos")

à

Cálculos o procesamientos

2.2.3. JERARQUIA DE CLASES Las clases en el diseño 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: □

Generalización: es la relación entre una clase origen, llamada subclase, y una clase más general, llamada superclase. Corresponde al concepto de “es un”. Cada objeto de una subclase “es un” objeto de la superclase.

□

Especialización: es la relación inversa de la generalización. Es la asociación de una clase con las subclases para las cuales es una superclase. Permite añadir propiedades (atributos y métodos) específicos de la subclase, es decir, especializarla.

Para aclarar los conceptos, ambas (Generalización y Especialización) son relaciones entre clases, mientras que la instanciación es la relación entre un objeto y la clase a la cual pertenece. La jerarquía de clases permite el funcionamiento de dos de las propiedades más importantes de la orientación a objetos: la herencia y el polimorfismo, que estudiaremos en los apartados siguientes. A través de la existencia de este orden jerárquico 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 OCULTACIÓN

Veamos ahora estas dos propiedades, que son características del diseño orientado a objetos y que están muy ligadas con el concepto de clase. En una primera aproximación, la encapsulación significa agrupar en una solo entidad (“caja”) datos y operaciones sobre esos datos. El principio de encapsulación establece que los atributos de una clase no sean accesibles desde el exterior sino a través del intercambio de mensajes establecido, es decir, que sólo sean modificados, o simplemente consultados, a través de los métodos de la propia clase.


T16 Página 7 de 31

La principal ventaja de la encapsulación es que evita la corrupción de los datos. Si un mismo dato es accesible desde numerosos módulos es mucho más 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 encapsulación, permitiendo que algunos objetos o módulos 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 ejecución del programa, aun al precio de incurrir en las mismas debilidades que la programación estructurada: cualquier modificación en la estructura de los datos, afecta a muchos más objetos que a aquél en la que está incluida. Asociado al concepto de encapsulación está el de ocultación. El concepto de ocultación de la información se refiere a que cada componente sabe lo mínimo posible de los otros y proporciona la mínima información posible sobre sí mismo. Por ejemplo, si en una aplicación 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. Sólo debe conocer como pedirle al cliente su saldo y no como está representado internamente. Desde hace muchos años, estos principios han estado disponibles en los lenguajes de programación, aunque su uso era optativo. La diferencia es que los lenguajes orientados a objetos dan soporte sintáctico 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 orientación a objetos, una aplicación es un conjunto de objetos que interactúan, que se comunican entre si mediante mensajes. Los mensajes son, por tanto, el medio a través del cual los objetos interaccionan. También se les llama peticiones. La estructura de mensaje es siempre la misma: nombre del objeto receptor. nombre del método a ejecutar, y una lista de argumentos o parámetros del mensaje. Pudiera parecer que el envío de mensajes entre objetos es similar a la llamada a un procedimiento o función en la programación estructurada. En el enfoque tradicional el programa que llama controla en cierta medida la ejecución del que es llamado, mientras que en la orientación a objetos es el propio objeto receptor el responsable de la ejecución del método y depende de la definición de su clase para encontrar las acciones a ejecutar. Ahora, podemos entender con mayor claridad la ejecución de una aplicación orientada a objetos, en la que se suceden los siguientes tipos de sucesos: □

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

□

Se crea otro objeto con las características de esa clase, tomando como valores propios los correspondientes a los parámetros transmitidos y a los calculados a partir de esos parámetros y de la ejecución del método solicitado.

□

Se borran los objetos que se van ejecutando.

Por lo tanto, un objeto se crea cuando se envía 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 más que envía el primer mensaje. Es en ella donde se inicia el ciclo de ejecución.

2.5.

HERENCIA

Veamos ahora unos de los conceptos más importantes en le diseño orientado a objetos: la herencia. Volviendo al ejemplo del punto 2.2.1: la clase 'cliente' estará descrita no sólo por unos datos (nombre, DNI, dirección,...) sino también por rutinas (cálculo del descuento, saldo,...). Además pueden tenerse diferentes tipos de clientes (mayoristas, minoristas, etc.) que serán solo parcialmente diferentes. Es decir, todos tendrán nombre,


T16 Página 8 de 31

DNI, dirección, etc.; pero la rutina de cálculo de descuento será diferente según el tipo de cliente y además, cada cliente tendrá una información adicional necesaria para calcular el descuento diferente según el tipo de cliente. Cuando esto sucede, se puede definir un cliente abstracto como lo que tienen en común todos los clientes para definir posteriormente, en cada uno de los tipos de clientes que se tienen, sólo aquello que le es particular. Es decir, cliente mayorista 'heredará' toda la descripción de cliente abstracto y le añadirá algunas de las características adicionales. La herencia permite entonces describir entidades (clases) por diferencia entre ellas; por eso, se dice que programar con orientación a objetos es programar para diferenciar. La herencia es la propiedad por la cual las subclases asumen como propios los atributos y métodos definidos en las superclases. O dicho de otra forma, herencia es la capacidad de un objeto (clase) para utilizar las estructuras y los métodos existentes en antepasados o ascendientes. Tiene una importancia extraordinaria: basta con declarar que una clase es hija de otra para que inmediatamente estén disponibles todas las estructuras de datos y los algoritmos diseñados en esta última. Además supone un excelente mecanismo para propagar los cambios en los niveles altos a través de todo el sistema. Cuando usamos herencia decimos que hacemos programación por herencia, es decir, definición de nuevos tipos a partir de otros con los que comparten algún tipo de característica. La herencia es sin duda la característica más significativa de la Orientación a Objetos, la que más se distancia de las metodológicas tradicionales. La utilidad de la herencia es múltiple. Es el elemento medular para conseguir la mayor reutilización de código. En efecto, no es preciso volver a programar ni especificar los procedimientos que se definieron en las clases superiores. Llegado el momento de su ejecución, 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, diseñar, codificar y poner a punto menos, ya que en cuanto se tiene un concepto definido, jamás 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 utilización de la nueva entidad, seguro que el error está en lo que se ha añadido porque lo que se ha heredado ya se había probado. Entendido el concepto de herencia, vamos ahora a estudiar los dos tipos de herencia más significativos: la herencia simple y la herencia múltiple

2.5.1. TIPOS DE HERENCIA Hay diferentes tipos de herencia, pero nos vamos a centrar en los más importantes que son: simple y múltiple. Con esto se quiere decir que, al contrario de la herencia biológica donde siempre se hereda de dos padres, en la orientación a objetos se puede heredar de uno, dos o más padres. La definición de cliente minorista a partir de cliente es un ejemplo de herencia simple. En otro ejemplo, se podría definir un vehículo anfibio como una herencia (una subclase) de otras dos clases: coche y barco, en este caso la herencia es múltiple. Más 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

Rectángulo


Triángulo

T16 Página 9 de 31

□

Herencia múltiple: una clase tiene más de una ascendiente inmediato.

Persona

Profesor

Investigador

Profesor universitario

La herencia múltiple puede plantear diversos tipos de problemas: □

La herencia repetida: Ej. : "profesor universitario hereda 2 veces los atributos de persona"

□

Produce ambigüedad respecto a los atributos o los métodos. En la clase base pueden haber atributos que se llamen igual:

EscalaResolución-

-Escala Sonido

Gráficos

-Resolución

Multimedia

□

Por lo tanto, presenta problemas de colisión cuando las superclases tienen las mismas propiedades. En esos casos no está plenamente definida la posición a adoptar. Existen varias soluciones. La más 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 cualificación del nombre de la propiedad anteponiéndole como prefijo el de la superclase. Y también es posible establecer una prelación entre las diferentes clases que colisionan, para que el sistema pueda resolver el conflicto.

Sólo hay 2 lenguajes que incorporan herencia múltiple: Eiffel y C++

2.5.2. CARACTERISTICAS DE LA HERENCIA Terminamos el estudio del concepto de herencia definiendo tres de sus características principales: □

Anulación o sustitución: cuando se redefine un método heredado en la subclase, se dice que estoy anulando o sustituyendo dicho método. Sería deseable una "herencia selectiva", es decir, seleccionar lo que se requiere heredar es la mejor forma de anulación.

□

Sobrecarga: Propiedad que puede darse también sin herencia. Esta es una capacidad de los lenguajes orientados a objetos, de permitir que una función o un operador puedan tener varios significados.

□

Polimorfismo (sobrecarga con anulación): es la forma de invocar a distintos métodos utilizando el mismo elemento de programa. Lo veremos con más detalle en el punto siguiente.


T16 Página 10 de 31

2.6.

POLIMORFISMO

Definimos Polimorfismo como la capacidad de referirse a objetos de clases distintas en una jerarquía utilizando el mismo elemento de programa para realizar la misma operación, pero de formas distintas. Las subclases pueden incorporar características propias (atributos y métodos), que las distingan y especialicen respecto de las clases padres. Esas características 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 características heredadas para que se comporten de una forma ligeramente distinta. En la mayoría de los lenguajes ello es posible. A tal fenómeno se le llama polimorfismo. En el ejemplo anterior de los clientes se podría forzar que toda subclase de cliente tuviera una operación ('servicio' o 'método') de cálculo-descuento, definiendo una operación 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 (cálculo-descuento). En caso de que esto suceda, podríamos garantizar que todo cliente tendría una operación 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 más el ejemplo, si quisiéramos hacer un programa de listar facturas a partir de unos albaranes, podríamos ir leyendo secuencialmente los albaranes a medida que los fuésemos emparejando con clientes. En cada emparejamiento imprimiríamos una factura tras calcular el descuento aplicable. Como sabemos que descuento es algo que está definido en 'cliente', podríamos enviar a cliente el mensaje 'calculo_descuento' (pedirle que ejecute la rutina) con el albarán como parámetro. La instrucción sería algo parecido a: descuento := cliente.calculo_descuento (albarán) Esta instrucción es única para todos los clientes sean del tipo que sean. Por tanto, con un mismo mensaje y según sea el receptor, se ejecutan diferentes rutinas (diferentes formas para un mismo mensaje = polimorfismo). Además y mientras se continúe cumpliendo que todo cliente tiene una operación 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 sería poco útil si no dispusiéramos de un mecanismo por medio del cual pudiéramos controlarla. Esa herramienta es el polimorfismo. En relación con el polimorfismo está el tipo de enlace (binding) del objeto: entendiendo por enlace la vinculación entre el nombre de un servicio y su implantación. Aquellos lenguajes que incorporan enlace dinámico permiten que la selección del método a emplear se haga en tiempo de ejecución, en función 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 estáticos se resuelven, en cambio, en la fase de compilación.

3.

VENTAJAS E INCONVENIENTES

Tras conocer las características esenciales de la orientación a objetos podemos enumerar las principales ventajas y desventajas que aporta en comparación con el planteamiento tradicional.

3.1.

VENTAJAS DE LA ORIENTACION A OBJETOS

3.1.1. Enfoque más 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 más fácil pensar en términos de objetos, y la comunicación entre ambos es más fluida.



3.1.2. Abstracción La orientación a objetos consiste en aplicar diferentes capas de abstracción en la modelización de una realidad, identificando sucesivamente los conceptos de objeto, clase y superclase en sus diferentes grados de iteración. Algunas metodológicas hablan incluso de metaclase, entendiendo por tal una clase en la cual sus objetos son a su vez clases. Este mayor grado de abstracción es el principio fundamental del que parten casi todas las demás ventajas del modelo.

3.1.3. Reutilización Debido a ese proceso de abstracción, las clases se diseñan para que puedan reutilizarse en muchos sistemas. Ya hemos comentado que construir una nueva aplicación es fundamentalmente un proceso de montaje de componentes ya previamente desarrollados. En este sentido es fundamental el concepto de librerías o bibliotecas de clases. En ellas se almacenan todas las clases disponibles. Un objetivo básico del desarrollo es ir incrementando el número y tamaño de esas bibliotecas. De hecho, es habitual distinguir dos tipos de perfiles en el personal de desarrollo: aquellos que se dedican más específicamente a construir clases de propósito general, y aquellos otros que construyen aplicaciones a partir del montaje de dichas clases. En aquellas empresas que utilizan una mentalidad de orientación a objetos, es habitual conseguir porcentaje de reutilización de código superior al 80%. La mayor reutilización del software, implica por lo tanto, desarrollo de aplicaciones: más rápidos, más baratos y de mayor calidad. Es decir: □

Menor tiempo de desarrollo: consecuencia inmediata de este planteamiento es una reducción muy significativa en el tiempo necesario para entregar una nueva aplicación.

□

Menor volumen de líneas de código: reutilizar componentes significa menos líneas de código nuevo.

□

Mayor fiabilidad: Menor código significa menor posibilidad de error. Además, los módulos reutilizables ya están adecuadamente probados antes de incorporarlos a un nuevo sistema.

3.1.4. Sistemas más robustos Se entiende por robustez de un sistema la capacidad que tiene dicho sistema para funcionar adecuadamente más allá de las especificaciones para las que fue diseñado. Tiene mucho que ver con la adaptabilidad. Los sistemas basados en orientación a objetos son más fácilmente adaptables, son más robustos.

3.1.5. Menor acoplamiento Las aplicaciones de orientación a objetos tienen un bajo nivel de acoplamiento, debido a la propiedad de encapsulación que tiene los objetos. Ello hace que las modificaciones de un objeto no afecten a los demás.

3.1.6. Mayor cohesión Los objetos presentan una alta cohesión, justamente porque integran una colección de datos muy relacionados y los procesos susceptibles de acometerse sobre ellos.

3.1.7. Mayor capacidad funcional El bajo acoplamiento y la alta cohesión de los objetos hacen factible que un sistema inicialmente complejo, con especificaciones funcionales complicadas, pueda ser descompuesto más fácilmente en diferentes capas de



clases y subclases, cada una con un grado de complejidad menor. Es posible desarrollar aplicaciones muy avanzadas conceptualmente, pero técnicamente sencillas.

3.1.8. Cambio en nuestra forma de pensar James Martín señala que el beneficio más importante a largo plazo que proporciona la orientación 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 orientación a objetos pretende que sean los ordenadores los que piensen como nosotros.

3.2.

INCONVENIENTES DE LA ORIENTACION A OBJETOS

Aunque las ventajas del diseño orientado a objetos son muchas e importantes, se pueden también señalar algunos inconvenientes, que debemos tener presentes a la hora de valorar el salto que supone apostar por este nuevo tipo de diseño. Estos inconvenientes son:

4.

□

Es una tecnología nueva

□

El diseño de módulos reusables añade coste al proyecto.

□

Todavía no existen librerías comerciales orientadas a objetos.

□

La reusabilidad se ve seriamente comprometida si los errores no se arreglan correctamente.

□

La mayoría de los lenguajes de programación 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 ejecución del programa. Los lenguajes híbridos son más eficientes, pero comprometen los principios OO.

□

Se pueden generar diseños tan malos en lenguajes OO como en cualquier otro lenguaje.

□

Es muy difícil rastrear el comportamiento de sistemas OO para depurarlos.

□

La implementación de tecnología OO puede ser muy costosa, ya que requiere nuevo HW (fabricado con nuevas funciones dirigidas expresamente a mejorar la eficiencia en ejecución de los programas OO), NUEVO SW y la formación de los desarrolladores en las tecnologías 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 diseño OO.

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 años, vamos a definir una serie de características que puede tener un Lenguaje de Programación 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 □

Distinción entre lenguajes puramente orientados a objetos ( Smalltalk, Eiffel, Spoke, ... ) y lenguajes con extensión orientada a objetos (C++ , Object Pascal, ... )

□

Tipado estático o dinámico o Tipificación fuerte o débil: à

Los de tipado estático determinan el tipo de una variable en la compilación, y por tanto no puede variar posteriormente (proporciona mayor control sobre el desarrollo y permite una implementación más eficiente).

à

Al contrario, los de tipado dinámico, lo hacen en tiempo de ejecución.



□

4.2.

Se entiende por enlace la selección del método a ejecutar tras la recepción de un mensaje por parte del objeto. à

Enlace estático: se realiza en tiempo de compilación.

à

Enlace dinámico: se realiza en tiempo de ejecución. El polimorfismo está basado en el enlace dinámico. En el enlace existe un procedimiento especial, llamado lookup, que recorre la jerarquía de clases del objeto receptor en busca del código de método a ejecutar. En este orden de búsqueda se ejecutará el primer método encontrado con ese nombre.

□

Asignación de una zona de memoria e inicialización de los atributos, cuando se crea un objeto.

□

Destrucción de los objetos cuando ya no son necesarios o recogida de basura. Puede realizarse de forma manual o automática. En la destrucción automática un objeto se borra cuando ya no es referenciado.

□

Lenguaje compilado o interpretado.

□

Soporte de herencia múltiple o simple.

□

Encapsulación rígida o no. Es decir, no se permite o se permite el acceso a los datos de un objeto, sin utilizar los métodos definidos en el objeto.

□

Incorporación de un sistema de excepciones, que permite tener un mayor control sobre los errores que se producen en los programas. Esto implica la creación de sistemas cada vez mas seguros.

□

Se admite concurrencia: "el mundo real es concurrente".

DESCRIPCION DE LOS PRINCIPALES LPOO

4.2.1. Simula Fue el primer lenguaje orientado a objetos. Tenía una sintaxis parecida a la del lenguaje Algol. Es un lenguaje compilado, y de tipado estático. No tiene herencia múltiple. El enlace es estático, pero a través de un mecanismo de funciones virtuales proporciona las características de los enlaces dinámicos. La destrucción de objetos se realiza de forma automática.

4.2.2. Smalltalk_80 Es un lenguaje autónomo, es decir, no es extensión de ningún otro. Es el primer lenguaje creado ex proceso que implantaba la mayor parte de los conceptos de orientación a objetos. Es semicompilado: genera un código intermedio que posteriormente es interpretado por una máquina virtual. Posee un polimorfismo completo, lo cual permite que tanto el enlace como el tipado sean dinámicos. No se puede vulnerar la encapsulación de los datos. La destrucción de objetos no referenciados es automática. Soporta herencia simple y concurrencia, pero pobre. Se comercializa con un conjunto de bibliotecas de clases predefinidas, agrupadas en categorías o jerarquías (E/S, etc...). Existe una versión, Smalltalk V para ordenadores IBM. C++ y CLOS se han apoyado en características de Smalltalk.

4.2.3. Ada_95 Ada_83 ya era casi un LPOO. Ada_95 sólo añade herencia y enlace dinámico (polimorfismo). Es un lenguaje compilado. El tipado es estático y no existe recuperación automática de la memoria, lo que significa que la destrucción de los objetos cuando no son necesarios no es automática.



4.2.4. C++ C++ es una extensión del lenguaje C, realizada a principios de los años 80. Incorpora los conceptos de jerarquía de clases, polimorfismo y herencia, esta última, además, puede ser múltiple. El enlace es dinámico, aunque implementado a través de funciones virtuales. El tipado es estático. A través de clases amigas es posible eludir la encapsulación, y acceder directamente a los atributos de un objeto.

4.2.5. Objective-C Se trata de otra extensión del lenguaje C para dotarle de capacidades de orientación a objetos. En su creación, se utilizó como modelo el Smalltalk. Es un lenguaje compilado, aunque el tipado es dinámico. No permite violar la encapsulación y la herencia es simple.

4.2.6. Object Pascal Pascal ha sido el prototipo de lenguaje estructurado. Object Pascal es una extensión de él para permitir la orientación a objetos. Se trata de un lenguaje compilado. Incorpora los mecanismos de herencia (simple) y polimorfismo. El enlace es dinámico y el tipado estático. No existe destrucción dinámica de objetos.

4.2.7. Eiffel Es un lenguaje desarrollado en C, inspirado en SIMULA con características añadidas de Smalltalk y Ada. Se destina a aplicaciones de bases de datos e inteligencia artificial. Por su diseño, es bueno para la ingeniería de software. Dispone de casi todas las propiedades de la orientación a objetos: jerarquía de clases, encapsulación, polimorfismo, herencia múltiple,.... Incorpora además un tratamiento de excepciones, mediante el cual es posible ejecutar una clase especial, “rescue”, cuando ocurre una excepción. El tipado es estático y el enlace dinámico. 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 dinámica es gestionada por el entorno y no por el sistema operativo: incorpora recogida automática de basura.

4.2.8. Spoke Es un lenguaje expresamente desarrollado para incorporar casi toda la filosofía de orientación a objetos. Suele emplearse para entorno de soporte a la decisión. Al igual que Eiffel, también gestiona excepciones, la herencia múltiple, y la destrucción de objetos automática.

4.2.9. Java Java es un lenguaje de programación orientado a objetos, surgido a partir del propio C++, pero eliminando algunos de sus aspectos más cuestionados, como la gestión 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 más utilizado para aplicaciones en Internet. Características más significativas del lenguaje: □

Semicompilado: a partir del código abstracto genera un código máquina virtual llamado “bytecode”.

□

Portable: a cualquier sistema operativo que implemente la máquina virtual Java (JVM).



5.

□

Es simple, robusto y seguro

□

Tiene capacidad de multiproceso o multihilo.

□

Enlace dinámico.

□

Garbage collection: Java libera de manera automática la memoria asignada a las variables u objetos que caen fuera de ámbito.

□

No admite herencia múltiple.

□

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 ejecución de un programa, a través de las excepciones.

□

Para facilitar la programación, Java proporciona unas clases organizadas en una serie de paquetes.

EL LENGUAJE DE MODELIZACION UNIFICADO (UML)

5.1.

INTRODUCCION AL UML

Los diagramas entidad-relación ayudan a modelar el componente de representación de datos de un sistema software. La representación de los datos, sin embargo, solo forma parte de un diseño completo de un sistema. Otros componentes son modelos de interacción del usuario con el sistema, especificación de módulos funcionales del sistema y su interacción, etc. El Lenguaje de Modelado Unificado (Unified Modeling Language, UML), es un lenguaje estándar de modelado propuesto para la creación de especificaciones de varios componentes de un sistema de software que permite la representación conceptual y física de dicho sistema. UML surge como fusión entre una variedad de técnicas de modelado de sistemas orientados a objetos. Pretende construir un lenguaje común para la definición y transmisión de modelos. Cuando modelamos un sistema informático, 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 características son: □

Es un lenguaje: Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema, por lo tanto, es un lenguaje estándar para los diversos pasos del software.

□

Es un lenguaje para visualizar: UML es algo más que un simple conjunto de símbolos gráficos, en cada símbolo hay una semántica definida.

□

Es un lenguaje para especificar: Especificar, significa construir modelos precisos, no complejos. UML cubre las especificaciones de todas las decisiones de análisis, diseño e implantación 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 programación, esta correspondencia permite ingeniería directa: la generación de código a partir de un modelo UML en un lenguaje de programación.

□

Es un lenguaje para documentar: Una organización de software que trabaje bien produce: Requisitos, Arquitectura, Diseño, Código fuente, Planificación de proyectos, Pruebas, Prototipos, Versiones. UML cubre la documentación de la arquitectura y proporciona requisitos y pruebas y las actividades de planificación 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. Gráficos 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 información extra.

En los siguientes apartados vamos a estudiar con más 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 información necesaria para describir un sistema. Cada vista se describe con un número de diagramas que contienen información que destaca un aspecto particular del sistema. Un diagrama en una vista en particular debe ser lo suficientemente simple como para ser fácilmente 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.

□

Lógica. Muestra como se diseña una determinada funcionalidad dentro del sistema.

□

Componente. Descripción de la implementación de los módulos y sus dependencias.

□

Concurrencia. División del sistema en procesos y procesadores.

□

Despliegue. Disposición física 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 agrupación y de anotación.

5.3.1. ELEMENTOS ESTRUCTURALES Son la parte estática de un modelo y representan cosas que son conceptuales, hay 7 elementos principales: □

Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica; implementa una o más interfaces.

□

Una interfaz es una colección 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 colaboración define una interacción entre diversos elementos. Las colaboraciones tienen dimensión tanto estructural como de comportamiento, y representan la implantación de patrones que forman un sistema. Una clase puede participar en varias colaboraciones.

□

Un caso de uso es una descripción de un conjunto de secuencias de acciones que produce un resultado observable de interés para un actor en particular. Es realizado por una colaboración. Es un tipo de vista.

□

Una clase activa, es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución 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 física y reemplazable de un sistema que se conforma con un conjunto de interfaces y proporciona la implantación de dicho conjunto. Representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones.

□

Un Nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que por lo general dispone de memoria y capacidad de procesamiento.

Los siete elementos anteriores son los estructurales básicos que se puede incluir en un modelo UML. También existen variaciones de estos siete elementos, tales como actores, objetos, señales, utilidades, procesos e hilos, aplicaciones, documentos, archivos, bibliotecas, páginas y tablas.

5.3.2. ELEMENTOS DE COMPORTAMIENTO Son las partes dinámicas 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. Comunicación entre objetos. La recepción de un mensaje se considera normalmente un evento. Los mensajes pueden ser señales, llamadas a métodos o similares. Se representan de tres formas distintas según muestra la figura:

□

Una máquina de estados es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos. El comportamiento de una clase individual o una colaboración de clases pueden especificarse con una máquina de estados.

Estos dos elementos básicos están 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 agrupación es el paquete que consiste en un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento e incluso otros elementos de agrupación 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 anotación es la Nota que es simplemente un símbolo para mostrar las restricciones y comentarios junto a un elemento o una colección de elementos.

5.3.5. REPRESENTACION GRAFICA DE LOS ELEMENTOS

5.3.6. TIPOS DE RELACIONES ENTRE ELEMENTOS □

Dependencia. Es una relación semántica entre dos elementos del modelado, un elemento independiente y otro dependiente, en la cual un cambio a un elemento independiente puede afectar a la semántica del otro elemento dependiente. Línea discontinua con flecha en uno de sus extremos apuntando al elemento independiente. Ejemplo:

□

Asociación. Es una relación estructural que especifica que los objetos de un elemento están conectados con los objetos de otro. Pueden llevar un nombre, frecuentemente un verbo, y una fecha abierta si la visibilidad es en una sola dirección. Las asociaciones se utilizan cuando se quieran representar relaciones estructurales. Características y ejemplo: à

Dada una relación 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 asociación estén conectados a la misma clase. Esto significa que, dado un objeto de la clase, se puede conectar con otros objetos de la misma clase.



□

Agregación. Una asociación normal entre dos clases representa una relación estructural entre iguales, ambas clases están al mismo nivel, sin ser ninguna más importante que la otra. Una agregación es un tipo especial de asociación, en que representa una relación estructural entre un todo y sus partes, es decir, una asociación no simétrica 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

1

* parte

D epartam ento

□

Composición. Los atributos son un caso particular de agregación: son físicamente contenidos por el agregado. Rombo negro.

□

Generalización. Es una relación de especialización / generalización 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. Características 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 añadir atributos y operaciones a los que hereda de sus padres.

à

Una clase puede tener ninguno, uno o más padres.

à

Una clase sin padre y uno o más hijos se llama clase raíz o clase base.

à

Una clase sin hijos se llama clase hoja.

à

La herencia es una generalización. Figura

C lase base

origen M over cam biarTam año() dibujar()

generalización

R ectángulo

C irculo

P olígono

Esquina:Punto

R adio:Float

Puntos:Lista

cuadrado

C lase hoja

□

Realización. Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización 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 representación gráfica de un conjunto de elementos, visualizado la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones).

□

gráficos que muestran a los elementos de modelado (símbolos), 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-relación. Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones, incluyendo las clases activas. O dicho de otra forma, muestra la estructura estática de clases en el sistema.

5.4.2. DIAGRAMA DE OBJETOS Un diagrama de objetos muestra un conjunto de objetos y sus relaciones, representando instantáneas de instancias de los elementos encontrados en los diagramas de clase. Son una variante de un diagrama de clases y utilizan casi una notación idéntica, con dos excepciones: el nombre de los objetos se escribe subrayado y se muestran todas las instancias en la relación. La diferencia entre un diagrama de clases y uno de objetos radica en que este último muestra un determinado número 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 interacción 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 número de actores externos y sus relaciones. Estos tres diagramas vistos hasta ahora son especialmente importantes en el modelado y organización del comportamiento de un sistema.

5.4.4. DIAGRAMA DE SECUENCIAS Los diagramas de secuencias son diagramas de interacciones que resaltan la ordenación temporal de los mensajes. Por lo tanto muestran una relación dinámica entre cierto número de objetos que interactúan. Es importante mencionar que los diagramas de interacción entre un conjunto de objetos y sus relaciones, incluyen los mensajes que pueden ser enviados entre ellos.

5.4.5. DIAGRAMA DE COLABORACIÓN Los diagramas de colaboración son diagramas de interacción que resaltan la organización estructural de los objetos que envían y reciben mensajes. Un diagrama de este tipo muestra una colaboración dinámica como un diagrama de secuencia. Pero como contrapartida éstos se centran más en la estructura espacial estática que permite la colaboración de un grupo de objetos y no tanto las interacciones entre objetos desde un punto de vista temporal. Un diagrama de colaboración se representa como un diagrama de objetos, donde aparece un determinado número de objetos y sus relaciones.



5.4.6. DIAGRAMA DE ESTADOS (statechart) Los diagramas de estados muestran una máquina 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 dinámica de un sistema y el comportamiento de una interfaz, una clase o una colaboración 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 dinámica, 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 código. Estos diagramas cubren la vista de implantación estática, se relacionan con diagramas de clase en que un componente se corresponde con una o más clases, interfaces o colaboraciones.

5.4.9. DIAGRAMA DE DESPLIEGUE Los diagramas de despliegue representan la arquitectura en tiempo de ejecución, en él aparecen los procesos, dispositivos (nodos) y componentes software que se ejecutan en esta arquitectura. Por lo tanto, muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.

5.5.

6.

MECANISMOS GENERALES □

Notas. Suelen unirse a algún elemento del diagrama a través de una línea discontinua, especificando que elemento es explicado o detallado.

□

Etiquetas. Elemento del tipo (parámetro, valor) que describe una propiedad de un elemento de modelado.

□

Restricciones. Relación semántica cualquiera entre elementos de modelado que limita su uso o el significado del elemento.

□

Estereotipos. Mecanismo de extensión que define un nuevo tipo de elemento de modelado que está basado en uno ya existente.

EL MODELO CORBA (Common Object Request Broker Architecture)

6.1.

EVOLUCION DE LOS SISTEMAS DISTRIBUIDOS

Los recientes avances en las tecnologías 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 evolución: □

servidores de ficheros

□

servidores de bases de datos (asociado popularmente como desarrollo cliente/servidor)

□

servidores de transacciones

□

y más recientemente servidores Internet/Web y servidores de objetos distribuidos



Como es lógico, esta evolución ha tenido su impacto en el desarrollo del software el cual típicamente estaba asociado al diseño estructurado y lenguajes procedurales, migrando rápidamente a la adopción de diseño y programación orientada a objetos en ambientes distribuidos. El desarrollo de aplicaciones distribuidas actualmente está siendo conducido por una combinación de tecnologías clave entre las que se encuentran: □

Internet – TCP/IP – Web

□

Tecnologías de Objetos Distribuidos

□

Java

Como una evolución 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 difusión, 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 sólo 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 investigación en todo el mundo. En medio del enfrentamiento entre los dos grandes líderes, OMG y Microsoft, surge JavaSoft, una filial de Sun Microsystems. JavaSoft ha diseñado RMI que es una especificación de objetos distribuidos presuponiendo que todos ellos están 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 estándar y abierto de objetos distribuidos que permite a los componentes en la red interoperar en un ambiente común sin importar el lenguaje de desarrollo, sistema operativo, tipo de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser invocados “transparentemente” en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker). Además del objetivo básico de ejecutar simplemente métodos en objetos remotos, CORBA añade un conjunto de servicios que amplían las potencialidades de estos objetos y conforman una infraestructura sólida para el desarrollo de aplicaciones críticas de negocio. CORBA es la respuesta del Grupo de Gestión de Objetos (Object Management Group – OMG) a la necesidad de interoperabilidad ante la gran proliferación de productos hardware y software, es decir permitir a una aplicación 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 compañías. En octubre de 1989, la OMG comenzó a realizar operaciones independientes como una entidad sin ánimo de lucro. A través de sus comités, la OMG desarrolla especificaciones independientes de cualquier proveedor para la industria del software. Actualmente, el consorcio tiene más de 800 miembros. La OMG se está moviendo a establecer a CORBA como el middleware que está en todas partes a través de sus especificaciones: CORBA/IIOP, servicios de objetos, facilidades de Internet y especificaciones de dominio entre otras. En CORBA, cada implementación de un objeto, define su interface a través un lenguaje conocido como Interface Definition Language (IDL) o lenguaje de definición de interfaces, a través del cual en forma estática (en el momento de compilación) o en forma dinámica (en el momento de ejecución) un cliente que requiera el servicio de dicha implementación de objeto, puede ser ejecutado. Las invocaciones a métodos remotos son enviadas por los clientes llamando a objetos locales llamados stubs (generados por un compilador de IDL en modo estático), el



cual intercepta dichas invocaciones y continua el proceso de llevar y retornar automáticamente dicha invocación. La implantación del objeto, no tiene que conocer el mecanismo por el cual un cliente le ha invocado un servicio. Cuando el cliente y una implementación de un objeto están distribuidos por una red, ellos usan el protocolo GIOP/IIOP suministrado por la arquitectura para lograr la comunicación: □

El GIOP (General Inter-ORB Protocol). Es el protocolo base, que permite la interacción entre dos ORBs.

□

El IIOP (Internet Inter-ORB Protocol). Especifica como los mensajes GIOP son intercambiados sobre TCP/IP. Esto hace posible también usar Internet para comunicar ORBs.

CORBA está soportado en dos modelos: Un modelo de objetos, el cual agrega todas las características de la orientación a objetos como tipos de datos, abstracción, 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 través del cual se comunican todos los objetos participantes en el sistema. El ORB es el corazón de las comunicaciones del estándar. ORB es referido comercialmente como CORBA. Provee una infraestructura que permite a objetos comunicarse, independiente de la plataforma específica y de las técnicas usadas para implementar el objeto direccionado. El ORB garantiza la portabilidad y la interoperabilidad de objetos sobre una red de sistemas heterogéneos.

□

Objetos de servicio - CORBAServices: Son un conjunto de objetos genéricos, 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 estándares dentro de un sector o mercado de aplicación, se cuentan con dominios como telecomunicaciones, finanzas, comercio electrónico, medicina, transportes, fabricación, etc.

□

Facilidades comunes - CORBAFacilities: Son un conjunto de objetos orientados hacia las aplicaciones de usuario final como administración de datos, interfaces de usuario, etc.

□

Objetos de aplicación: Son los objetos de aplicación desarrollados por el programador.

Objetos de Aplicación

Objetos de Dominio

Facilidades 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 método sobre un objeto remoto. El ORB intercepta la llamada y es responsable de encontrar el objeto que implementa el requerimiento, pasar los parámetros, invocar el método y retornar el resultado. El cliente no se preocupa de donde está el objeto, su lenguaje de programación o sistema operativo entre otros aspectos. De esta forma el ORB provee la interoperabilidad entre aplicaciones sobre diferentes máquinas en un ambiente heterogéneo distribuido. El ORB ofrece una amplia gama de interfaces de servicios distribuidos. Existen bastantes características del ORB de CORBA que hacen este producto mejor que otras aplicaciones existentes, entre otras, ofrece varios métodos estáticos y dinámicos para solicitar servicios a la red, puede trabajar con cualquier lenguaje de programación que se escoja y la comunicación 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 definición de los objetos en IDL (estudiaremos este lenguaje en el apartado 6.6). Además, el ORB de CORBA trata con conceptos de seguridad y facilidades de transmisión de datos haciendo fiable y segura su utilización. 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: □

Implementación del objeto: Realizado por el programador. Implementa las operaciones especificadas en la definición IDL. La implantación puede ser escrita en lenguajes como C, C++, Java, SmallTalk, Ada, etc.

□

Cliente: Entidad que invoca una operación en una implementación de un objeto remoto. De igual forma puede ser desarrollado en varios lenguajes y es realizado por un programador de aplicaciones.

□

Núcleo 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 colección 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 estáticamente o dinámicamente a los objetos pero los servidores no notan la diferencia. En ambos casos, el ORB localiza el correspondiente adaptador de objeto, transmite los parámetros y transfiere el control a la implementación del objeto a través de la interfaz IDL.

□

Stubs y Skeleton IDL: Los stubs y skeleton sirven como una conexión cliente-ORB y servidor-ORB. Son estáticos y generados en tiempo de compilación por un compilador IDL que transforma interfaces IDL al lenguaje de desarrollo, reduciendo los posibles errores al generar automáticamente los stubs y skeleton.

□

Interface de invocación dinámica (DII): Esta interface permite a un cliente construir dinámicamente un requerimiento sin tener un stub, esto es, los requerimientos se construyen en tiempo de ejecución.

□

Interface Skeleton dinámica (DSI): Cumple las mismas funciones de DII pero en el lado del servidor. Permite que el ORB realice llamadas a una implementación de objeto cuya interfase no se conoce.

□

Adaptador de objetos: Un adaptador de objeto es la forma principal para acceder los servicios de una implementación de objeto provistos por el ORB. Los servicios provistos por el ORB a través de un adaptador de objetos incluye: generación e interpretación de referencia de objetos, invocación de métodos, seguridad de interacciones, activación y desactivación de objetos e implementaciones, mapeo de referencias de objeto a implementaciones y registro de implementaciones. Un adaptador de objetos exporta una interfaz pública a la implementación 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:

OBJETO

CLIENTE

IDL skeleton IDL stub

DII

Interface ORB

GIOP/IIOP

6.5.

DSI

Adaptador de Objetos

Núcleo ORB

OBJETOS DE SERVICIO – CORBAServices

Los CORBAServices especifican servicios básicos que casi todos los objetos necesitan. Para cada componente de OMA, la OMG provee una especificación formal descrita en IDL (como invocar cada operación dentro de un objeto) y su semántica (que hace cada operación y las reglas de comportamiento). Los CORBAServices proveen servicios a nivel de aplicación 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, básicamente es un servicio de localización que asocia identificadores a manejadores que proveen una forma de contactar el componente deseado en un sistema distribuidos.

□

Ciclo de vida: Básicamente es un servicio de configuración, define servicios y convenciones para crear, borrar, copiar y mover componentes en un sistema distribuido.

□

Eventos: Implementa un modelo de comunicación desacoplado, basado en el paradigma publicación/suscripción. En este modelo, uno o más publicadores pueden enviar mensajes relacionados con un tópico específico, mientras que un grupo de suscriptores reciben los mensajes asíncronamente.

□

Transacciones: gestiona interacciones entre objetos distribuidos estableciendo puntos de acuerdo y delimitación de transacciones. Este servicio soporta varios modelos y permite interoperabilidad entre diferentes arquitecturas de red y modelos de programación.

□

Seguridad: Controla la identificación de los elementos del sistema distribuido (usuarios, objetos, componentes, etc.) que permite verificar que un cliente está autorizado a acceder los servicios de una implementación remota. Adicionalmente permite la comunicación segura sobre enlaces de comunicación inseguros, ofreciendo confidencialidad e integridad de la información transmitida.

□

Tiempo: Suministra información del tiempo y permite la definición de llamadas periódicas.

□

Licenciamiento: Controla la utilización de objetos específicos, inhibiendo uso inadecuado de derechos y propiedad intelectual.

□

Propiedades: provee la habilidad de asociar dinámicamente propiedades a objetos que pueden ser consultados o modificados por otros elementos.

□

Relaciones: Permite la definición del papel ejecutado por objetos CORBA en una relación.

□

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 coordinación de múltiples accesos a recursos compartidos y permite resolución flexible de conflictos.

□

Externalización: define convenciones y protocolos para representar el estado de información relacionado a un objeto en la forma de una secuencia de datos, permitiendo a esta información 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 carácter auto descriptivo. Todas estas características son posibles gracias al interfaz IDL. La especificación IDL provee una forma estándar 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 parámetros son referenciados. La información guardada en el IR es creada automáticamente mediante un precompilador IDL. Cada componente debe estar descrito con su correspondiente interfaz IDL. Aunque parezca ser inicialmente un trabajo extra, ahorraremos mucha energía y se convertirá en ventajas que serán 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 programación 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 implementación en la interfaz). Las órdenes de IDL son una subcolección de C++ con órdenes adicionales para soportar objetos distribuidos. El IDL para CORBA es completo y conciso: la OMG sólo ha necesitado 36 hojas para describirlo.

6.7.

NUEVAS ESPECIFICACIONES DE CORBA

Después que fue terminada y normalizada la versión 2.0 en 1996, la OMG continuo trabajando en la incorporación de aspectos importantes que deben ser tenidos en cuenta en un sistema distribuido y ha ampliado su modelo de objetos para incorporar aspectos como: múltiples 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 dimensión a CORBA. Estas nuevas especificaciones están divididas en tres categorías: □

Integración con Internet.

□

Control de calidad de servicio.

□

Arquitectura de componentes CORBA.



7.

CONCLUSIÓN

El diseño 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 revolución industrial del software. Con esta forma de diseñar se persigue la máxima reutilización del código, a través de una mayor abstracción. Después de ver los orígenes y la historia, hemos estudiado con detenimiento los elementos fundamentales de este tipo de diseño: los objetos formados por atributos y métodos, las clases como una abstracción de los objetos y sus relaciones de generalización y especialización, la encapsulación y ocultación 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 diseño orientado a objetos son evidentes, destacando la abstracción y la reutilización, hay que tener presentes algunos de los inconvenientes, antes de tomar la decisión de comenzar a desarrollar aplicaciones bajo esta nueva forma de diseño. En cuanto a los lenguajes de programación orientados a objetos (LPOO), actualmente destaca por encima de todos, Java. Gracias a su portabilidad, robustez y seguridad se ha convertido en el dueño de los objetos internet, cada vez más aplicaciones web son desarrolladas con java. Para la construcción de sistemas orientados a objetos, los lenguajes de modelado de dichos sistemas, tienen un papel fundamental. El Lenguaje de Modelización Unificado, UML (Unified Modeling Language), surge como fusión de una variedad de técnicas de modelado de estos sistemas. Terminamos este tema con el estudio del modelo CORBA. Modelo fundamental en la evolución 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.

BIBLIOGRAFÍA □

A. Amescua: ANALISIS Y DISEÑO ESTRUCTURADO Y ORIENTADO A OBJETOS DE SISTEMAS INFORMATICOS. MacGraw Hill

□

Grady Booch: ANALISIS DE DISEÑO 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.

□

LÓPEZ GÓMEZ, G., SALAS BLANCO, M., SILES PELÁEZ, R. Y SORIANO CAMINO: Arquitectura de Objetos Distribuidos CORBA", F. Servicio de Publicaciones de la Facultad de Informática (U.P.M.), 2000.



9.

ESQUEMA – RESUMEN

El objetivo del diseño orientado a objetos, no es construir sistemas desarrollando módulos nuevos, sino ensamblando los ya existentes. Se persigue la máxima reutilización del código, a través de una mayor abstracción. La tecnología orientada a objetos pone el énfasis en los objetos y su comportamiento, abandonando el enfoque tradicional de procesos y datos. Un principio básico de la orientación a objetos es la encapsulación en un mismo ente de los dos elementos clásicos de los sistemas de información: los datos y los procesos. Este ente es el objeto. Los elementos y conceptos fundamentales del diseño 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 percepción de su individualidad. Es decir, un objeto es una abstracción 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. También reciben el nombre de propiedades, campos o variables del objeto.

□

Métodos: Los métodos 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 abstracción de objetos, es un conjunto de objetos con propiedades (atributos y/o métodos) comunes. Por lo tanto, una clase muestra el comportamiento general de un grupo de objetos. Al hablar del concepto de abstracción 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: à

Generalización: es la relación entre una clase origen, llamada subclase, y una clase más general, llamada superclase.

à

Especialización: es la relación inversa de la generalización. Es la asociación de una clase con las subclases para las cuales es una superclase.

□

Encapsulación: El principio de encapsulación establece que los atributos de una clase no sean accesibles desde el exterior sino a través del intercambio de mensajes establecido, es decir, que sólo sean modificados, o simplemente consultados, a través de los métodos de la propia clase.

□

Ocultación: El concepto de ocultación de la información se refiere a que cada componente sabe lo mínimo posible de los otros y proporciona la mínima información posible sobre sí mismo.

□

Mensajes: Son el medio a través del cual los objetos interaccionan.

□

Herencia: La herencia es la propiedad por la cual las subclases asumen como propios los atributos y métodos definidos en las superclases. O dicho de otra forma, herencia es la capacidad de un objeto (clase) para utilizar las estructuras y los métodos 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 estén disponibles todas las estructuras de datos y los algoritmos diseñados en esta última. Se definen dos tipos de herencia:

□

à

Herencia simple: un tipo derivado se crea a partir de una única clase base.

à

Herencia múltiple: una clase tiene más de un ascendiente inmediato.

Polimorfismo: Capacidad de referirse a objetos de clases distintas en una jerarquía utilizando el mismo elemento de programa para realizar la misma operación, pero de formas distintas.

Las principales ventajas de la orientación a objetos son: □

El enfoque es más natural e intuitivo, gracias al concepto de objeto.

□

Se aplica diferentes capas de abstracción en la modelización de la realidad.

□

Las clases se diseñan 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 cohesión. La modificación de un objeto no afecta a los demás.

□

Un sistema complejo, puede descomponerse fácilmente 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 estándar de modelado propuesto para la creación de especificaciones de varios componentes de un sistema de software que permite la representación conceptual y física 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.

à

Lógica. Muestra como se diseña una determinada funcionalidad dentro del sistema.

à

Componente. Descripción de la implementación de los módulos y sus dependencias.

à

Concurrencia. División del sistema en procesos y procesadores.

à

Despliegue. Disposición física 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 estática de un modelo y representan cosas que son conceptuales, hay 7 elementos principales: una clase, una interfaz, una colaboración, un caso de uso, una clase activa, un componente y un nodo.

à

Elementos de comportamiento: Son las partes dinámicas de los modelos, son los verbos y representan el comportamiento en el tiempo y el espacio. Hay dos tipos principales: el mensaje y la máquina de estados.

à

Elementos de agrupación: Son las partes organizativas de los modelos, son las cajas en las que puede descomponerse un modelo.

à

Elementos de anotación: Son las partes explicativas de los modelos, se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo.

□

Diagramas. Gráficos 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 colaboración, de estados, de actividades, de componentes y de despliegue.

□

Mecanismos generales. Los mecanismos generales proveen comentarios o información extra. Son los siguientes: Notas, Etiquetas, Restricciones y Estereotipos.

CORBA es un middleware o marco de trabajo estándar y abierto de objetos distribuidos que permite a los componentes en la red interoperar en un ambiente común sin importar el lenguaje de desarrollo, sistema operativo, tipo de red, etc. En esta arquitectura, los métodos de un objeto remoto pueden ser invocados “transparentemente” en un ambiente distribuido y heterogéneo a través de un ORB (Object Request Broker). CORBA está soportado en dos modelos: Un modelo de objetos, el cual agrega todas las características de la orientación a objetos como tipos de datos, abstracción, 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 través del cual se comunican todos los objetos participantes en el sistema. El ORB es el corazón de las comunicaciones del estándar. Los elementos de la arquitectura de un ORB son: Implementación del objeto, Cliente, Núcleo ORB,



Interface ORB, Stubs y Skeleton IDL, Interface de invocación dinámica (DII), Interface Skeleton dinámica y adaptador de objetos. □

Objetos de servicio - CORBAServices: Son un conjunto de objetos genéricos, 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 estándares dentro de un sector o mercado de aplicación, se cuentan con dominios como telecomunicaciones, finanzas, comercio electrónico, medicina, transportes, fabricación, etc.

□

Facilidades comunes - CORBAFacilities: Son un conjunto de objetos orientados hacia las aplicaciones de usuario final como administración de datos, interfaces de usuario, etc.

□

Objetos de aplicación: Son los objetos de aplicación desarrollados por el programador.

El Lenguaje de Definición 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 carácter auto descriptivo. Todas estas características son posibles gracias al interfaz IDL. Por lo tanto, la especificación IDL provee una forma estándar de definir las interfaces a los objetos CORBA. IDL no está condicionado por el lenguaje de programación 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

Recommend Documents