Programacin Orientada a Objetos o

Laura M. Castro Souto Primer Cuatrimestre Curso 2000/2001

 Indice de cuadros
4.1. Tabla resumen de la evolucin de la Orientacin a Objetos . . . . . . . . . 34 o o

INDICE DE CUADROS

Cap tulo 1 Evolucin de los lenguajes de o programacin o

La programacin ha ido evolucionando desde sus or o genes, donde los lenguajes eran de muy bajo nivel y las posibilidades reducidas, renndose cada vez ms hasta alcanzar a a el alto nivel y relativa sencillez actuales. Veremos a grandes rasgos cmo se ha desarrollado este proceso. o

1.1.

Programacin no estructurada o

En sus primeros momentos, decimos que la programacin llevada a cabo en lenguajes o como el basic es no estructurada. Los programas eran una serie de l neas de cdigo con o saltos (instruccines tipo goto) y en un unico bloque (sin posibilidad de subrutinas; o basic cuenta unicamente con la instruccin gosub <direccion>). o

1.2.

Programacin procedimental o

Con la aparicin de lenguajes como Pascal, surge la posibilidad del empleo de subrutio nas (funciones y procedimientos), lo que da nombre a esta etapa en que la programacin o se dice procedimental.

1.3.

Programacin estructurada o

La necesidad de dar claridad y legibilidad al cdigo provoca que se reconozcan una serie o de principios o reglas a la hora de estructurar un programa. Surge as la programacin o estructurada, cuyas directivas son: Estructura jerrquica top-down. a Diseo modular. n Salidas y entradas claramente denidas. Unico punto de entrada y unico punto de salida (tambin aplicable a funciones). e Constructores de programacin estructurada: secuencia, seleccin, iteracin y llao o o madas a procedimientos. 5

CAP ITULO 1. EVOLUCION DE LOS LENGUAJES DE PROGRAMACION

Existe una analog entre este modo programacin, esta forma de programar, propuga o nada por la programacin estructurada y el llamado dise o mediante renamiento o n progresivo. Se afronta el problema desde la cima y se va analizando de forma que se delimitan sucesiva y claramente las partes y funciones que realizarn cada una de las a cuales, hasta llegar a las ms sencillas, directamente implementables de una manera fcil. a a

1.4.

Programacin modular o

El siguiente paso consisti en la divisin de los largos programas, compuestos de l o o neas y l neas de cdigo en secuencia sin interrupcin en diferentes mdulos, en los que, por o o o ejemplo, pod trabajar simultneamente los diferentes integrantes de un grupo deparan a o tamento. Los mdulos, sin embargo, no permiten la instanciacin ni la exportacin de tipos. o o o Este iba a ser el siguiente peldao en la escalera de la evolucin de los lenguajes de n o programacin. o

1.5.

TADs

Los Tipos Abstractos de Datos cuentan con una serie de caracter sticas que exponemos a continuacin: o Exportan una denicin de tipo. o Hacen disponibles operaciones para manipular instancias del tipo (interfaz ). El interfaz es el unico mecanismo de acceso a la estructura del TAD. Es posible crear mltiples instancias del tipo (algo que no era posible en programau cin modular). o El segundo y tercer puntos son comunes a los mdulos. Son los otros dos los que o marcan la diferencia. La losof consiste en que creamos nuevos tipos y los usamos como si fuesen predea nidos. Es el paso previo a la orientacin a objetos. o

1.6.
1

Programacin Orientada a Objetos o

Clases y objetos sern para nosotros conceptos similares a tipos y variables. Es decir, a la relacin que existe entre un objeto y la clase a la que pertenece (la clase de la que es o una instancia 2 .) es anloga a la que hay entre una variable y el tipo del que es declarada. a Una clase es un TAD con una caracter stica aadida: permite la herencia. n clase = TAD + herencia
simula 67 es el primer lenguaje que se puede considerar que soporta P.O.O. Realmente la palabra instancia no existe en espaol; deber usarse ejemplo, ejemplicacin o conn a o crecin o
2 1

1.7. RESUMEN

Se dene as un nuevo paradigma de programacin, en el que podemos tener diferentes o jerarqu y/o especializaciones, en forma de subclases y superclases, habilitando al as mismo tiempo el polimorsmo. El renamiento progresivo usado hasta ahora era un renamiento orientado al ujo de datos, que no favorece la reutilizacin de cdigo. Con la programacin orientada a objetos, o o o en cambio, las clases ms generales pueden servirnos siempre para nuevos usos que las a requieran. Los programas en P.O.O. manejan objetos que se comunican unos con otros mediante el intercambio de mensajes. El diseo en P.O.O. no es ya, pues, top-down sino bottom-up; en lugar de ir de lo n principal a lo espec co se hace al contrario. De aqu la gran importancia de una correcta identicacin de los objetos que vayan a participar en nuestro proyecto. o

1.7.

Resumen

El concepto de Orientacin a Objetos surge en torno a 1970 de mano de Alan Ray. o Xerox PARC fue una de los primeros interesados en lo que se quer imponer como un a nuevo paradigma de programacin. o El primer lenguaje totalmente orientado a objetos fue Smalltalk, creado por Dyrabook. El unico fallo que le fue achacado fue la falta de una interface WIMP3 . Parec que esta nueva concepcin iba a cercarse alrededor de la IA y sus redes semntia o a cas (los objetos parec adaptarse a sus directivas es parte de y es un) y marcos an (frames). No obstante, pronto los dems lenguajes comenzaron a crear extensiones de s mismos a intentando incorporar las caracter sticas que se den fundamentales para la O.O.: B. an Stroustrup, de los laboratorios Bell, construy a partir de C un lenguaje C con clases, que o ms tarde sera conocido como C++4 . a o Pero no slo C tuvo su extensin, tambin Lisp, con CLOS (Common Lisp Object o o e System) y muchos otros. Tambin se crearon lenguajes totalmente orientados a objetos como Java5 , que ine corpor los hoy tan populares applets, el garbage collector y sobre todo su caracter o stica multiplataforma (bytecode). Ahora mismo, est a punto de ver la luz la versin que Microsoft ha hecho del lenguaje a o Java, que se llamar C# (pronunciado C sharp). Este lenguaje compila el cdigo fuente a a o un cdigo interno (Intermediate Language, similar al bytecode) y posteriormente a cdigo o o mquina. a Hoy en d los lenguajes O.O. tienen la supremac en el campo de la RAD (Rapid a a Application Development), con ejemplos como Delphi, aunque algunos de los que se usan no cumplen todos los requisitos (p. ej. Visual Basic), que se consideran slo o basados en objetos.
Windows Icons Mice Pointers. Existe una ancdota sobre el nombre del lenguaje C++: C surge de la evoluc de B, un lenguaje e on construido a partir de BCPL (Basic cpl), a su vez hijo de CPL (Combined Programming Languaje). Despus de tener un B y un C, se hicieron apuestas sobre si el siguiente en la saga ser D (por e a orden alfabtico) o P (por BCPL). Stroustrup evit el compromiso aadiendo el operador sucesivo a la e o n letra C, C++. 5 Los creadores de Java en principio le llamaron Oak (roble), pero como el nombre ya estaba registrado, le pusieron lo que en ingls americano signica coloquialmente caf. Adems, sus componentes se e e a denominan Java Beans, que no signica otra cosa que granos de caf. e
4 3

CAP ITULO 1. EVOLUCION DE LOS LENGUAJES DE PROGRAMACION

Diferencia entre lenguajes orientados a y basados en objetos Los Lenguajes Basados en Objetos poseen una sintaxis y una semntica que pera miten la creacin de objetos, pero no poseen todas las caracter o sticas necesarias para ser considerados plenamente orientados a objetos. La caracter stica ms comnmente noa u soportada suele ser la posibilidad de herencia (fallo de VB). Dentro de los Lenguajes Orientados a Objetos se hace una distincin entre L.O.O. o puros (como Smalltalk, Eiel, Java,. . . ), que aunque por ser ms abstractos son ms fcia a a les de manejar pero ms lentos, no permiten otra forma de hacer las cosas salvo la correcta, a mientras que los llamados L.O.O. h bridos (C++, Object Pascal, CLOS, Prolog++,. . . ) mezclan la O.O. con otro paradigma (programacin estructurada / funcional / lgica,. . . ) o o y a pesar de poder ser ms fciles de aprender, si se conocen aqullos de los que derivan, a a e proclamarse ms rpidos y ecientes, y ofrecer otro tipo de soluciones cuando la O.O. no a a es lo ms adecuado, no ofrecen toda la versatilidad y potencia de una completa O.O. a

Cap tulo 2 Elementos bsicos de la Orientacin a o a Objetos

En un programa, tenemos objetos que se comunican entre s que tienen un determinado , estado interno, que pertenecen a una clase,. . . Pero qu signican todos estos trminos? e e Eso es lo que deniremos en este tema.

2.1.

Clases

Ya comentamos en el tema anterior que la relacin clase - objeto era equiparable o a la relacin tipo - variable (pgina 6). o a A grandes rasgos, podemos decir que una clase es una plantilla que dene cmo han o de ser los objetos que pertenezcan a ella. Se denen una serie de mtodos, entre ellos e constructores, que permiten instanciar crear objetos de esa clase y manejarlos. o La denicin formal de clase abarca dos aspectos: o Denicin estructural: se dene el estado y comportamiento de los objetos de o esa clase (atributos y mtodos). e Propsito de creacin de nuevos objetos: la propia clase ha de denir mtodos o o e para crear sus objetos1 . En Java: [MODIFICADORES] class Nombre [extends clase] ----------[implements interface,...] ---------{ \\ Atributos \\ Mtodos e }
1

Estos mtodos especiales se denominan mtodos constructores, como ya hemos comentado. e e

10

CAP ITULO 2. ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS Donde los modicadores pueden ser: public clases que son accesibles desde fuera del paquete (mdulo2 ) en que est deo a nida. abstract clases que no pueden instanciarse, slo se denen para ser extendidas. o nal clases que no pueden extenderse con subclases.

Los interfaces son clases especiales que pueden contener nombres de funciones pero nunca sus implementaciones. Si una clase implementa un interfaz, le da cuerpo a esas funciones. Ejemplo: public class Caja { // Atributos private int value; // Mtodos e public Caja() { value = 0; } public void setValue(int v) { value = v; } public int getValue() { return value; } } Cuando no se utiliza la clusula extends es como si pusisemos: a e class Caja extends Object -----Todas las clases heredan de la clase Object. Convenios: Puesto que Java distingue maysculas y minsculas, se siguen las siguientes pautas: u u Los nombres de clases van con maysculas. u Los nombres de atributos, con minsculas. u Los nombres de funciones empiezan con minscula, y si contienen ms de una u a palabra, las dems empiezan con una mayscula, sin dejar espacios ni poner otro a u tipo de caracteres intermedios delimitadores o similares.
2

Agrupacin de clases. o

2.2. OBJETOS

11

Los mtodos constructores se denen con el nombre de la clase. No son obligatorios, e pues aunque no se pongan existe uno por defecto que inicializa todos los atributos a 0 a o NULL.

2.2.
2.2.1.

Objetos
Creacin de objetos o

Se hace de la siguiente manera: Caja x; x = new Caja(); --x.setValue(7);

2.2.2.

Denicin o

Un objeto puede denirse como: Coleccin de operaciones que comparten un estado (todas referidas al mismo). o Encapsulacin de un conjunto de operaciones y mtodos que pueden ser invocados o e externamente y que recuerdan el estado.

2.2.3.

Caracter sticas principales

Un objeto ha de tener: Identidad: debe ser identicable, uno y distinto de otros, aunque objetos de las mismas caracter sticas se agrupen bajo la misma clase. Caracter sticas declarativas: usadas para determinar el estado (atributos y su valor). Caracter sticas procedimentales: que modelan el comportamiento (mtodos). e Caracter sticas estructurales: que organizan los objetos unos con respecto a otros (relaciones de herencia, agregacin3 ,. . . ). o Identidad La identidad es la propiedad de un objeto que lo distingue de todos los dems. Se cona sigue a travs de un OID (Object Identifier, Identicador de Objeto) independiente e del estado (valor de los atributos) del objeto. Es algo interno que genera y gestiona el sistema y que no se puede ver ni modicar. Suele basarse en punteros y direcciones; de hecho, los propios objetos son siempre punteros por razones de asignacin dinmica en tiempo de ejecucin de espacio de memoria en o a o
3

Un objeto puede contener a otros.

12

CAP ITULO 2. ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS

la pila (stack) y el montculo (heap); en la primera se almacenan, por bloques de activa cin, los punteros a los objetos y as pueden usarse osets (desplazamientos) para acceder o ms rpidamente, (en tiempo de compilacin no podr hacerse con los objetos en s sin a a o a conocer qu tamanho tienen) mientras que en el segundo se almacenan los propios objetos. e A la hora de comparar dos objetos distinguimos dos situaciones: Identidad: dos objetos son idnticos si son el mismo objeto, es decir, OID1 = OID2 . e Igualdad: dos objetos son iguales si tienen el mismo estado (los mismos valores de sus atributos)4 , pero OID1 = OID2 . Idnticos e
(Si cambiamos el valor de x, cambia el valor de y efecto colateral-)

Iguales
(Aqu no)

Ahora bien, qu ocurre cuando queremos copiar un objeto? Existen dos tipos de e copias: la copia supercial y la copia profunda, que deniremos a continuacin. En o ambos casos se trata siempre de objetos iguales. Dos objetos son supercialmente iguales si los atributos de los objetos son iguales. Esta denicin no es recursiva. o La copia supercial est implementada en el mtodo sobreescribible clone de la clase a e Object a la que pertenecen todos los objetos. Dos objetos son profundamente iguales si sus atributos son recursivamente iguales, en todos los niveles. Caracter sticas declarativas Se usan los llamados modicadores de acceso para calicar los mtodos y atributos e 5 que determinarn el estado del objeto: public, private, protected y package6 . a Otros modicadores son tambin static, usado con atributos que no pertenecen a un e objeto particular sino a la clase, y nal, usado para constantes.
Suponemos, obviamente, que hablamos de objetos de la misma clase. Un mtodo o atributo protected es visible desde las subclases y tambin desde las dems clases e e a pertenecientes al mismo paquete. 6 Opcin por defecto. o
5 4

2.2. OBJETOS Caracter sticas procedimentales (comportamiento) Siempre se dice que en POO se busca tener una determinada serie de objetos que se comunican mediante mensajes; un mensaje se interpreta como una llamada a uno de los procedimientos del objeto pues, como hemos comentado, sus mtodos e determinan su comportamiento, son su interfaz para interactuar con l. e Los mtodos constan de: e rma o cabecera, compuesta a su vez por: nombre tipo y nombre de parmetros, siempre pasados por valor, salvo en a el caso de los objetos, que al ser, como hemos hecho notar, punteros, son realmente referencias. tipo de resultado, un unico tipo de retorno permitido; en caso de de volver ms cosas se utilizan o bien array o bien objetos que engloben a en sus atributos todo lo que se requiera. implementacin o cdigo del procedimiento o o

13

Los mtodos (y atributos) de clase tienen en realidad ms utilidad de la que pueda e a parecer en teor pero depende del caso particular que estemos tratando. a, En cuanto a los mtodos constructores, siempre existe uno por defecto, no tenemos e por qu denirlo nosotros, pero es habitual sobrecargarlos 7 . e En Java no hay mtodos destructores, ya que su funcin es realizada en la mayor de e o a los casos por el Garbage Collector8 . En caso de que no sea as siempre se puede recurrir a la sobreescritura del mtodo nalize, declarado en la clase Object. e El mtodo main ha de ser static porque puede llamarse para ejecutarse sin que est creae e do el objeto.

7 Sobrecargar un mtodo consiste en denir varios procedimientos con el mismo nombre pero con e parmetros distintos. a 8 La unica pega de esta caracter stica de Java es que el Garbage Collector es as ncrono, se ejecuta cuando quiere.

14

CAP ITULO 2. ELEMENTOS BASICOS DE LA ORIENTACION A OBJETOS

Cap tulo 3 Propiedades bsicas de la a Orientacin a Objetos o

Tradicionalmente se han tomado como propiedades bsicas de la Orientacin a Objetos a o 1 las caractersticas de Booch , que son bsicamente cuatro: a Abstraccin. o Encapsulamiento o encapsulacin. o Modularidad. Jerarqu a. Adems, se aaden: a n Polimorsmo2 . Tipicacin y ligadura3 . o

3.1.

Abstraccin o

Denicin o Representacin de las caractersticas fundamentales de algo sin incluir anteo cedentes detalles irrelevantes. o La abstraccin es fundamental para enfrentarse a la complejidad del software. La o Programacin Orientada a Objetos fomenta el uso de abstracciones (clases, mtodos, o e especicadores de acceso privacidad. . . ). Elemento clave: la clase, plantilla para crear objetos, especicar su estado y mtodos para modicarlo). e
1 2

Fue uno de los diseadores de UML. n En esta propiedad es donde reside realmente la potencia de la O.O. 3 Ms bien caracter a sticas de los lenguajes.

15

16

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS

3.2.

Encapsulamiento

Denicin o Proceso de almacenamiento en un mismo compartimiento de los elementos de una abstraccin que constituyen su estructura y comportamiento. o Abstraccin y encapsulamiento son complementarios: la primera se centra en el o comportamiento observable del objeto y el segundo en la implementacin (mtodos, atrio e butos). Contribuye a la ocultacin de la informacin: parte pblica (interfaz ) y parte o o u privada (implementacin). o Ventajas Permite un razonamiento ms eciente al eliminar los detalles de bajo nivel. a Permite que cambios en el diseo slo afecten de forma local. n o En Java se materializa mediante los especicadores de acceso aplicados en las clases, que limitan la visibilidad de mtodos y atributos. e

3.3.

Modularidad

Denicin o Propiedad que tiene un sistema que ha sido descompuesto en un conjunto de mdulos que han de ser cohesivos y dbilmente acoplados. o e Que dos mdulos sean cohesivos signica que agrupan abstracciones que guardan alguo na relacin lgica. Que sean dbilmente acoplados indica que se minimiza la dependencia o o e 4 entre ellos . Ventajas La fragmentacin disminuye la complejidad. o Crea fronteras bien denidas y documentadas dentro de un programa, lo que tambin contribuye a una menor complejidad y tambin a una mayor comprensin del e e o programa, mejor estructuracin. . . o Existe relacin entre la abstraccin, el encapsulamiento y la modularidad, son o o conceptos sinrgicos, persiguen el mismo n. e encapsulacion Un objeto denido alrededor de una abstraccin modularidad o Encapsulamiento y modularidad son barreras alrededor de esa abstraccin para proo tegerla.
4

Estos conceptos no son exclusivos de la POO.

3.3. MODULARIDAD

17

3.3.1.
5

Criterios de Modularidad de Meyer

Son una serie de directivas que denen lo que se admite como una correcta modularizacin en un programa. o 1) Descomposicin: el software debe ser descompuesto en un nmero de subproblemas o u menos complejos que estn interconectados mediante una estructura sencilla y que e sean independientes (lo suciente como para poder trabajar por separado en ellos, dbil acoplamiento). e 2) Composicin: propiedad de que los mdulos se combinen libremente para producir o o nuevos sistemas, con la posibilidad de ser completamente ajenos a aqul en que se e desarroll el mdulo. o o 3) Comprensibilidad: mdulos comprensibles sin necesidad de examinar aqullos otros o e con los que interactan, comprensibles en s mismos, o en el peor caso analizando u el menos nmero posible de ellos. u 4) Continuidad: pequeos cambios en las especicaciones del problema han de provocar n pocos cambios en pocos mdulos. o 5) Proteccin: cuando se produce un error o situacin anormal o no prevista en un o o mdulo debe quedar connado en l o bien propagarse slo a los mdulos vecinos, o e o o no a todos. Para que estos criterios se vean satisfechos debe atenderse a los siguientes principios de diseo: n Correspondencia directa: La estructura modular (del sistema) software tiene que ser compatible con cualquier otra estructura modular que hayamos obtenido en el proceso de modelado. o u o Pocas interfaces: Cada mdulo debe comunicarse con el menor nmero de mdulos posible, con el n de evitar la propagacin de errores. o Interfaces pequeas: La cantidad de informacin que se pasa ha de ser lo ms pen o a quea posible. n Interfaces expl ctias y legibles: Se deben especicar claramente los datos y procedimientos que se muestran o no al exterior. o e Ocultacin de informacin: Slo se muestra la parte del mtodo que se necesita o o mostrar.

Meyer fue el creador de Eiel.

18

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS En Java: clases Son el primer paso de la modularidad, encapsulan mtodos y atributos e y permiten ocultar informacin (private, protected, public,. . . ). o paquetes Son el segundo paso de la modularidad; constituyen una ordenacin lgica, puesto que hacen lo mismo con las clases que stas con sus o o e componentes. cheros Con extensin .java, se usan bsicamente como unidades de como a pilacin, constituyen la ordenacin f o o sica. Slo puede haber una clase o pblica por chero, y el nombre de ste ha de coincidir con el de aqulla. u e e Si no contiene ninguna, el nombre puede ser cualquiera. Al compilar, se genera un .class por cada clase que est presente en el chero. e

3.3.2.

Objetivos de los paquetes

Son dispositivos de modularidad de nivel superior a las clases. Agrupan clases con funcionalidades similares, lo cual: Favorece la comunicacin entre las clases. o Facilita la localizacin. o Favorece que se vea claramente que estn relacionadas. a Previene conictos de nombre (nombrepaquete.nombreclase), lo que favorece la reutilizacin6 . o Organizan los cheros fuente.

3.4.

Jerarqu a

Denicin o Una jerarqu es una ordenacin o clasicacin de las abstracciones. a o o Existen dos tipos de jerarqu as: Generalizacin / especializacin: herencia es un . o o Agregacin (objetos que contienen otros objetos): es parte de . o
6

Tambin suelen usarse los dominios de Internet al revs: com.borland.. . . e e

3.4. JERARQU IA

19

3.4.1.

Herencia

La herencia es un tipo de jerarqu de abstracciones en la que existen una serie de a subclases (abstracciones especializadas) que van a heredar caracter sticas de una o varias superclases (abstracciones generalizadas). El objetivo fundamental de la herencia es, como el de la POO en general, la econom a de expresin (reutilizacin). o o La herencia dene una estructura en forma de rbol. En muchos lenguajes existe un a nodo ra comn (clase Object de Java, Visual Basic,. . . ). z u No obstante, la herencia presenta un conicto con la encapsulacin, puesto que la o viola sobre todo a travs de la caracter e stica protected. Existe un principio, el principio abierto-cerrado que dice que los mdulos han de ser abiertos y cerrados a la vez. Esto que o puede parecer una contradiccin, no lo es en realidad porque se reere a cosas distintas: o Un mdulo es abierto si est disponible para ser extendido con facilidad. o a Un mtodo es cerrado si su interfaz es estable y est bien denido. e a Es decir, una vez creado, se pretende que sea modicado lo menos posible; est abierto, a 7 sin embargo, a ser modicado mediante la extensin . o Ventajas Favorece la reutilizacin de cdigo al extender clases que ya existen. o o Incrementa la abilidad del mismo cdigo al extender clases ya probadas. o Permite la comparticin de cdigo fuente. o o Permite la consistencia entre las interfaces. Favorece el desarrollo de librer de componentes (RAD, rapid application developas ment). Permite y favorece el polimorsmo. Inconvenientes Debemos recordar siempre que medida que se aaden complejidades, tanto a los n lenguajes como a nuestras propias aplicaciones) disminuye la velocidad de ejecucin. o Al incluir librer enteras, metemos en realidad ms cdigo del que realmente neas a o cesitamos, con lo cual aumenta el tamao del nuestro. n Aumenta la complejidad de comprensin: problema del yo-y (uso excesivo). o o

Extensin implica tanto denicin de ms mtodos como redenicin de mtodos. o o a e o e

20

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS

La herencia puede ser simple (desciende de una unica superclase) o m ltiple (des u ciende de varias superclases). Cuando se tiene herencia mltiple la estructura deja de ser en rbol y pasa a ser un u a grafo dirigido acclico (GDA). Entre las ventajas de la herencia mltiple tenemos que es un mecanismo muy potente u que nos proporciona mucha ms exibilidad. a Entre sus inconvenientes, los conictos que genera su utilizacin, que da ms problemas o a que soluciones: el cdigo se vuelve ms confuso. o a

Qu mtodo usar? En el caso de la izquierda suele sobreescribirse uno por otro; en e e el de la derecha, o bien se escoge uno arbitrario en el orden en que se indican, o se le pregunta al usuario, o se heredan ambos mtodos y se renombra uno de ellos. e El problema en realidad no es que haya conictos, sino que cada lenguaje los resuelve a su manera8 ; por ello lenguajes como Object Pascal, Java, C# (surgidos de C++) han eliminado la herencia mltiple y simplemente la simulan mediante implementacin (y u o comparticin) de interfaces. o Clases abstractas e interfaces La caracter stica principal de una clase abstracta es, como ya sabemos, que no puede ser instanciada, de modo que su unico objetivo es ser extendida por la herencia.

Un interfaz supone un paso ms, una clase abstracta total. Sus caracter a sticas son que incluye una serie de mtodos que por defecto son pblicos y abstractos. Las variae u bles son impl citamente static y nal, es decir, contantes de clase. Siguen entre ellos una jerarqu paralela a las clases, pero permitiendo en esta caso la herencia mltiple. a u

Minimizan los conictos, pues ahora se hereda la cabecera de modo que los problemas que analizbamos antes desaparecen (salvo si devuelven tipos distintos). a Se permite una conexin entre ambas jerarqu (una clase puede extender una supero as clase y al mismo tiempo implementar algn intefaz): u
8

Java no soporta herencia mltiple. u

3.4. JERARQU IA class A extends B implements IX, IM { ... }

21

Adems, al no introducir cdigo alguno, los interfaces son utilizables en ms mbitos: a o a a Para capturar similitudes sin forzar relaciones de clases. Para revelar la interfaz de un objeto (mtodos de acceso) sin revelar la clase. e Para denicin de nuevos tipos de datos. Spase que de un interfaz no se pueden o e crear objetos, aunque s puede haber objetos que los implementen:

interface Celda... { } class Imagen implements Celda { } ... Celda [][] = matriz; matriz [0][0] = new Imagen(); Se pueden usar como marcadores de clase (interfaces vac os); en el API de Java tenemos el ejemplo: class MiClase implements Serializable { } ... MiClase x = new MiClase(); if (x instance of Serializable) ... Se puede usar como contenedores de constantes globales: interface Constantes { public double PI=3.1416; public int NUMFILAS = 15; ... } Tipos de herencia La herencia lleva impl cito el principio de sustitucin: el tipo indicado en la deo claracin de una variable puede no coincidir con el tipo que contiene la variable en el o momento actual (se puede declarar como de la clase y luego ser de la subclase, donde ahora va un tipo luego puede ir otro). Hay que diferenciar:

22

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS subtipo: relacin de tipos que reconocen expl o citamente el principio de sustitucin . Para que esto se cumpla, para poder decir que B es subtipo o de A son necesarias dos condiciones: 1. Una instancia de B puede ser legalmente asignada a una variable de tipo A. 2. Una instancia de B asignada legalmente a una variable de tipo A puede ser utilizada por la variable de tipo A sin un cambio observable en su conducta. subclase: B es subclase de A si la extiende a travs de la herencia (de los e supuestos anteriores slo se cumple el primero). o

La mayor de las veces las subclases son subtipos, aunque no estn obligadas. Los a a lenguajes de POO suelen entender subclase = subtipo y permiten por tanto el principio de sustitucin. o Herencia de Especializacion Es el tipo ms comn de herencia; en ella, las subclases son versiones especializadas a u de las superclases. Herencia de Especificacion Una superclase declara unos mtodos (abstract) que son implementados por las sube clases. Herencia de Construccion No existe relacin lgica entre subclases y superclases (no existe relacin de tipo es un), o o o pero en las subclases se aprovechan funcionalidades de las superclases. Ejemplo t pico: class Stack extends Vector { public Object push (Object item) { addElement(item); return item; } public Object pop () { Object obj = peek(); removeElementAt(size()-1); return obj; } public Object peek () { return elementAt(size()-1); } }

3.4. JERARQU IA

23

No se puede decir, empero, que una pila sea un subtipo de Vector, no es lgico que o donde tenemos un vector podamos meter una pila, podr hacerse y no fallar pero dea a, jar de respetarse las directivas que hacen de la pila lo que es (por ejemplo, eliminar un an elemento del medio). No cumple, por tanto, el principio de sustitucin. o Herencia de Limitacion La conducta de la subclase es ms restrictiva que la de la superclase. a En el ejemplo anterior, podr usarse, por ejemplo, para evitar efectos no deseados del a tipo: ... public int elementAt (int index) throws IllegalOperation { throw new IllegalOperation(elementAt); } ... class IllegalOption extends Exception { IllegalOperation (String str) { super(str); } }

Aunque soluciona las pegas de la herencia de construccin, esta tctica no es muy eo a ciente, pues imaginemos que hubiese que hacer esto para casi cada uno de los mtodos e de la superclase. Nos plantea si realmente se deber estar usando la herencia o no. a Herencia de Combinacion Consiste en heredar de ms de una superclase (herencia mltiple). a u Java y otros lenguajes, como hemos dicho, lo simulan con interfaces, aunque realmente no es lo mismo porque no heredamos cdigo. o Herencia de Extension Se da cuando se hereda de una superclase pero no se redene nada, slo se aaden o n mtodos. Es un caso particular de la herencia de especializacin. e o

3.4.2.

Alternativas a la herencia: la Composicin o

En los casos en los que la herencia no parece la solucin ms adecuada, puede opo a tarse por emplear la composicin, que implementa la losof es parte de, aunque o a

24

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS

a la distincin entre sta y la es un no est demasiado clara9 . Aparece cuando un objeto o e est compuesto o agrega (jerarqua de agregacin) varios objetos. a o Por ejemplo: class Stack { private Vector datos; public Stack () { datos = new Vector(); } public boolean isEmpty() { return datos.isEmpty(); } public void push (Object nuevoValor) { datos.addElement(nuevoValor); } public Object peek(){ return datos.lastElement(); } public Object pop() { Object resultado = datos.lastElement(); datos.removeElementAt(datos.size()-1); return resultado; } }

De este modo se utiliza lo que se quiere de la superclase y no se heredan mtodos o e atributos innecesarios. Ventajas de la herencia sobre la composicin o El principio de sustitucin a veces no es deseado, pero en otras ocasiones se requiere; o con la composicin no es posible nunca. o Con la herencia tenemos menos cdigo que mantener, ya que no hay mtodos de o e enlace, es decir, mtodos del estilo: e public boolean isEmpty() { return datos.isEmpty(); } En relacin con lo anterior, la herencia evita tener que llamar a dos funciones (deo legacin). o Los elementos protegidos no pueden usarse si se utiliza la composicin10 . o
9 10

Una Stack no es ni tampoco es parte de un Vector. En Java s siempre que estn en el mismo paquete. , e

3.5. POLIMORFISMO Ventajas de la composicin sobre la herencia o

25

Puesto que componiendo no se heredan mtodos no deseados, se indican con claridad e las operaciones a utilizar. Con la composicin se puede reimplementar la clase para utilizar otro mecanismo o de almacenamiento11 . La composicin, al no cumplir el principio de sustitucin, impide polimorsmos no o o deseados12 (lo cual, como ya vimos, es tambin un inconveniente). e La composicin permite simular la herencia mltiple mediante varios objetos privao u dos internos. Lo determinante para decidir entre herencia y composicin ser, como podemos deduo a cir, si queremos consentir o no el mencionado principio de sustitucin. o

3.5.

Polimorsmo

El polimorsmo es, como su propio nombre indica, la caracter stica de algo que puede adoptar o tiene varias formas. El problema es que agrupa varios conceptos. Generalmente suele aplicarse a funciones que aceptan parmetros de diferentes tipos, variables a que pueden contener valores de distintos tipos,. . . Distinguimos algunas variantes que exponemos a continuacin clasicadas segn la o u Divisin de Cardelli y Wegner : o Parametrico Universal o Verdadero De Inclusion Polimorfismo Sobrecarga Ad-Hoc o Aparente Coaccion En el Polimorsmo Universal existen valores (atributos) con distintos tipos (es decir, pueden tener un tipo declarado y almacenar otro) y se utiliza el mismo cdigo para o 13 todos . El Polimorsmo Ad-Hoc se llama tambin Aparente (y en contraposicin el Unie o versal es Verdadero) porque da la impresin que lo hay pero en realidad no es as Se utiliza o . distinto cdigo para tratar los distintos tipos, de modo que una funcin que pueda parecer o o polimrca en realidad estar implementada a travs de varias funciones monomrcas. o a e o

3.5.1.

Polimorsmo Universal Paramtrico e

Este tipo de polimorsmo es propio de los lenguajes funcionales (Lisp, Ml,. . . )14 y consiste en denir una funcin pero no el tipo de sus parmetros, de suerte que se puede o a aplicar sobre diferentes tipos. En C++ se le llama generidad genericidad y est basado o a en la denicin de plantillas: o
Por ejemplo, en el caso particular de las pilas, utilizar otro elemento que no fuese un Vector. Que sobre la pila puedan aplicarse mtodos de la clase Vector. e 13 Ejemplo: Clase Perro, subclase de Animal, con mtodo getNombre que si no se redene es el mismo e para ambos. 14 No existe en Java.
12 11

26

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS template <classT> class Box { ... } Box <int> a_Box(5); Box <shape> a_Box(circle);

3.5.2.

Polimorsmo Universal de Inclusin o

Este tipo de polimorsmo es el que se consigue a travs de la herencia, t e pico y ms a comn en los L.O.O.15 , que permite que una instancia sea asignada a una variable declau rada de otro tipo.

3.5.3.

Sobrecarga

La Sobrecarga consiste en utilizar el mismo nombre para funciones distintas. Tambin e 16 es posible la sobrecarga entre clases . La ventaja de usar nombres iguales para hacer los mismo sobre diferentes clases de objetos es la coherencia, aunque no siempre pueden querer signicar lo mismo17 . Sobrecarga Paramtrica e Dentro de una misma clase pueden existir varios mtodos con el mismo nombre pero e con distinto nmero de parmetros o parmetros de distintos tipos. El caso ms usual es u a a a el de los constructores: public public public public Esfera Esfera Esfera Esfera () { ... } (double x, double y) { ... } (int x, double y) { ... } (double y, int x) { ... }

Lo que nunca puede ser igual es el tipo de retorno, no pueden existir dos mtodos con e el mismo nombre, nmero y orden de parmetros, que devuelvan dos tipos diferentes: u a int abrirFichero (); void abrirFichero();

Si el resultado no se recoge en una variable cul usamos? a Existen lenguajes no orientados a objetos que permiten este tipo de polimorsmo, que suele ser corriente fundamentalmente en sobrecarga de operadores.
Y por tanto tambin en Java. e Las clases Hashtable, Vector,. . . tienen un mtodo isEmpty(), cul ha de ejecutarse cuando se le e a llama? Se sabe por el objeto que hace la llamada. 17 Si tenemos un metodo isEmpty() sobre un Rectangle, qu quiere decir? e
16 15

3.5. POLIMORFISMO Sobreescritura

27

Es un caso particular de sobrecarga que se da cuando se sobrecarga un mtodo que e est en la superclase, siempre que los parmetros sean iguales, ya que si son distintos se a a considera simplemente sobrecarga. La sobreescritura se puede clasicar a su vez en: de Reemplazo Se sustituye el mtodo de la superclase por otro. e de Renamiento Se rena el comportamiento del mtodo de la superclase. e Veamos un ejemplo de cada una: abstract class Personal { protected long base; protected long a~os; n long sueldo() { return (base+10000*a~os); n } } class A extends Personal { long numProyectos; long sueldo() { return (10000*numProyectos); } } class B extends Personal { long extra; long sueldo() { return (super.sueldo()+extra); } }

Siempre que hay sobreescritura hay sobrecarga (entre clases). Lo contrario no siempre es cierto. La sobrecarga se decide en tiempo de compilacin; la sobreescritura, en tiempo de o ejecucin: o Personal P = new A(); P.sueldo();

En tiempo de ejecucin se mira qu tipo hay en P y ejecuta el mtodo correspondiente. o e e A esto se le llama ligadura dinmica y lo veremos en la seccin siguiente (3.6, pgina 28). a o a

28

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS

3.5.4.

Coaccin o

La coaccin18 es, bsicamente, una conversin impl o a o cita de tipos que se da en casos como: real x; int i; x=i+8.3;

Lo que se hace es en primer lugar convertir i a real y luego realizar la operacin. o No obstante, a veces no se sabe distinguir si lo que hay es sobrecarga o coaccin: o 3+4 3.0+4 3+4.0 3.0+4.0

Es esto un operador sobrecargado 4 veces? O son dos funciones, suma de enteros y suma de reales, combinadas con la coaccin de enteros si hay reales presentes? O hay o slo una funcin suma y siempre coaccin de enteros a reales? o o o

3.6.

Tipicacin y ligadura o

Las ultimas caracter sticas que nos quedan por ver es la tipicacin y la ligadura. o Cada lenguaje las interpreta y presenta de forma particular y espec ca, pero deniremos unos rasgos generales.

3.6.1.

Tipicacin o

Un tipo es una caracterizacin precisa de las propiedades estructurales o de o comportamiento (atributos, mtodos) que comparten una serie de entidades. e Con los tipos se consiguen 3 objetivos: Un mecanismo de abstraccin, pues las entidades de un tipo se agrupan segn o u sus propiedades y conducta. Un mecanismo de proteccin, que evita errores y garantiza correccin. o o Un mecanismo de composicin, pues a partir de los tipos existentes se pueden o crear tipos nuevos. Lo que se persigue con los tipos es una idea de congruencia. Qu relacin hay entre tipos y clases? Los lenguajes O.O. hacen (por sencillez) que no e o haya prcticamente ninguna diferencia, no obstante, formalmente, la diferenciacin que a o se suele hacer subraya que un tipo especica una semntica y una estructura y una clase a es una implementacin concreta de un tipo: o
18

Del ingls, coercion. e

 3.6. TIPIFICACION Y LIGADURA PilaArray | |--> push() |--> pop() |--> peek() PilaLista | |--> push() |--> pop() |--> peek()

29

PilaArray y PilaLista son dos clases distintas pero son el mismo tipo (pila). En los L.O.O. las clases suelen denir un tipo, y a parte existen los tipos bsicos, que a no son ni se implementan a travs de clases (int, boolean, char,. . . ). En Java, para que e podamos tratarlos como clases cuando lo necesitamos (por ejemplo, para poder meterlos donde se requiere un Object), se denen clases contenedoras (del ingls wrapped classes): e Integer, Boolean, Character,. . . class Integer { private int i; ... Object getValue(); void setValue(); ... }

Comprobacin de tipos o Hay varias forma de hacerlo: Forma Esttica a Forma Estricta o Fuerte Forma Dinmica o Dbil a e Aunque en ocasiones las dos primeras se agrupan bajo el segundo nombre. Comprobacin de tipos Esttica o a El tipo exacto se determina en tiempo de compilacin. Es bastante restrictivo, o y es la que se lleva a cabo siempre en los lenguajes no orientados a objetos. Comprobacin de tipos Estricta o Fuerte o Requiere que todas las expresiones de tipos sean consistentes en tiempo de compilacin. La consistencia exige que se cumplan 3 restricciones: o Restriccin de Declaracin: Todas las entidades del lenguaje han de tener o o un tipo declarado, las funciones y sus parmetros tambin. a e

30

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS Restriccin de Compatibilidad : En una llamada x=y o func(x) donde se o pase y en lugar de x, se requiere que y sea compatible con x (y es compatible con x a travs de la herencia; en otros lenguajes, siempre que sean e subtipos). Restriccin de llamada a caracterstica: Para que sea posible hacer una o llamada x.f (x clase; f mtodo, atributo, caracter e stica o variable) el mtoe do f ha de estar denido en x o en alguno de sus antecesores. Esta comprobacin es ms exible que la esttica y es la que tienen Java, o a a C++, Object Pascal,. . . . En caso de duda, aplica el pesimismo: Personal P = new A(); P.numProyect();

En realidad esto podr funcionar, puesto que P contiene un objeto de tipo a A, que posee el atributo numProyect, pero si no lo tuviese (suponer que la asignacin a P estuviese en un if o algo as ser un error, de modo que Java o ), a exige una conversin explcita: o ((A) P.)numProyect();

Comprobacin de tipos Dinmica o Dbil o a e Todas las comprobaciones de tipos se hacen en tiempo de ejecucin (se dan, o por tanto, un mayor nmero de excepciones). Es decir, la exibilidad es mucho u mayor, pero nos topamos con muchos ms problemas a la hora de ejecutar. a Ejemplo: Smalltalk. Ventajas de la tipicacin o Las ventajas de ser estrictos con los tipos son: Fiabilidad, pues al detectar los errores en tiempo de compilacin se corrigen antes. o Legibilidad, ya que proporciona cierta documentacin al cdigo. o o Eciencia, pueden hacerse optimizaciones.

3.6.2.

Ligadura

En ocasiones puede confundirse con la tipicacin, pero la ligardura consiste en ligar o o relacionar la llamada de un mtodo con el cuerpo del mtodo. e e Se da en casos de sobreescritura:

 3.6. TIPIFICACION Y LIGADURA Personal P; if ... P = new A(); else P = new B(); ... P.sueldo();

31

Podr optarse por una solucin esttica y ejecutar el mtodo sueldo() de la clase a o a e Personal, pero probablemente no ser lo deseado, de modo que se escoge en tiempo de a ejecucin (en base al tipo actual, no al tipo declarado), por eso recibe el nombre de o ligadura dinmica19 . a No todos los mtodos permiten ligadura dinmica. Por ejemplo, en Java, los mtodos e a e nal, que no permiten ser sobreescritos, usan siempre ligadura esttica. Igual situacin se a o da con los mtodos privados. Recordemos que si una clase es nal, todos sus mtodos lo e e son. El resto de los mtodos en Java emplean ligadura dinmica por defecto. En otros e a lenguajes, como C++ u Object Pascal, se necesita denir los mtodos como virtual para e que empleen esta tcnica (por razones de eciencia, ya que lgicamente la ejecucin es e o o ms lenta), pues lo predeterminado es que se liguen estticamente20 . a a Todos los objetos tienen una tabla de mtodos virtuales (VMT, virtual method e table). Para decidir qu cdigo se utiliza ante una determinada llamada, se siguen los e o pasos: Se comprueba el tipo actual correspondiente al objeto que solicita la ejecucin del o procedimiento. Se estudia la VMT de los objetos de dicho tipo y se localiza la entrada correspondiente al mtodo. Es importante hacer notar que el orden de stos en dicha tabla e e en una jerarqu no vara a. Se sigue el puntero y se ejecuta el cdigo al que apunta. o El principal problema que se le achaca a la ligadura dinmica, como ya hemos dejado a entrever, es la eciencia21 , aunque la penalizacin que sta impone es constante, no o e depende del nivel de una jerarqu en que se encuentre,. . . a Hay compiladores que incluyen llamadas inline, lo que consiste en incluir el cdigo o de un mtodo en el lugar de la llamada (slo con procedimientos pequeos), algo que evita e o n el paso de parmetros por la pila, . . . a No obstante, la ligadura esttica tambin tiene inconvenientes, ya que no permite la a e reutilizacin e incumple el principio abierto-cerrado. o La ligadura esttica es vlida si produce los mismos a a resultados que la ligadura dinmica. a Esto puede hacernos pensar que quizs lo mejor fuese que todo lo decidiese el compia lador.
En contraposicin con la ligadura esttica, que se decide en tiempo de compilacin. o a o Debe tenerse especial cuidado en no confundir la ligadura dinmica con la comprobacin de tipos. a o 21 Es el motivo de que otros lenguajes intenten eludirla.
20 19

32

CAP ITULO 3. PROPIEDADES BASICAS DE LA ORIENTACION A OBJETOS

Cap tulo 4 Evolucin de los Lenguajes o Orientados a Objetos

Lo ms importante a la hora de analizar algn diagrama que muestre esta evolucin1 a u o es que distingamos entre los llamados lenguajes puros, como Java, Eiel,. . . que representan la tendencia actual (lenguajes totalmente orientados a objetos que evitan, que eliminan las cosas molestas como la herencia mlitple) y los lenguajes h u bridos como C++, Object Pascal, etc. El resto, como decimos, podemos observarlo en un grco dirigido que plasme esta a historia ms o menos reciente: a antecedentes historicos El concepto de Orientacin a Objetos surge a partir del lenguaje Simula-67, un o programador de sucesos discretos. En 1970, con Smalltalk, se acua el trmino n e Orientacin a Objetos. o El padre de la Orientacin a Objetos es Alan Kay, creador de una mquina o a universal (Flex o Dynabook) basada en los conceptos de clase y herencia del Simula-67 y del Lisp. En los aos 70 la Orientaci a Objetos y la Inteligencia Articial comienzan n o a interrelacionarse de forma estrecha: Aparecen extensiones a lenguajes (Common Lisp Object System o CLOS), entornos de programacin (Kee, ART),. . . o Las teor de herencia de la Orientacin a Objetos inuyen en el desaas o rrollo de esquemas de representacin del conocimiento. o Se integran la Orientacin a Objetos y la Composicin Concurrente. o o Ya en los 80, tiene su auge el desarrollo de interfaces de usuario WIMP: windows, icons, mouse and pointers (Xerox, Apple). Tambin se desarrolla e Smalltalk, y permite ahora la reutilizacin del software. o Aparecen tambin los primeros problemas: como la mayor de los lenguajes e a Orientados a Objetos estaban muy inuenciados por el desarrollo de interfaces de usuario no eran ecaces en otros campos de programacin. Para combatirlo, o
1

Como el que tenemos en transparencias, por ejemplo.

33

 34 CAP ITULO 4. EVOLUCION DE LOS LENGUAJES ORIENTADOS A OBJETOS nacen lenguajes como Eiel, C++,. . . En la dcada de los 90 la investigacin se centra en: e o 1. El enfoque de la Ingenier en el desarrollo del software: CASE, IPSE,. . . a
2. 3. Disposicin de componentes de software reutilizables (lenguajes Orientados a o Objetos, Ada,. . . ). Sistemas abiertos (UNIX, X-Window,. . . ).

Nacen las Bases de Datos Relacionales, que incluyen extensiones post-relacionales precursoras de las Bases de Datos Orientadas a Objetos. Aparecen los primeros estndares, nace el OMG (Object Management Group), a las grandes empresas crean los suyos propios: Microsoft, IBM, AT&T,. . . Este agrupamiento (OMG) crea una gu de arquitectura para la integracin de la a o aplicacin Orientada a Objetos (Corba), as como el UML (Unied Modelling o Language). Fase I Dcada 70: Invencin e o Simulacin de sucesos o discretos SIMULA Kay: FLEX DYNABOOK Smalltalk Fase II Dcada 80: Confusin e o Interfaces: WIMP XEROX, APPLE Entornos LISP Entornos IA Nuevos lenguajes: Eiel, C++ Fase III Dcada 90 : Madurez e Anlisis, Diseo a n Sistemas Abiertos Aplicaciones B.D. Orientadas a Objetos Estndares a

Cuadro 4.1: Tabla resumen de la evolucin de la Orientacin a Objetos o o

Deniciones P.O.O. Mtodo de implementacin en el que los programas se organizan como e o colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de algn tipo de clase, tipos miembros de una jerarqu unidos u a mediante relaciones de herencia. Dise o O.O. Mtodo de diseo que abarca el proceso de descomposicn n e n o Orientada a Objetos y una notacin para describir los modelos lgico o o y f sico, as como los modelos esttico y dinmico del sistema que se a a disee. n Anlisis O.O. Mtodo de anlisis que examina los requisitos desde la persa e a pectiva de las clases y objetos del dominio.

Cap tulo 5 UML

Lo principal que veremos en este tema son diagramas de clase y cmo permutar entre o un diagrama UML y un lenguaje como Java, pero sin meternos en detalles de diseo. n Denicin o Un modelo es una simplicacin de la realidad que busca o permite una mejor o comprensin del sistema que estamos analizando. o La utilidad de un modelo es la posibilidad de ser usado para: visualizar cmo queremos que sea el sistema o especificar su estructura y comportamiento servir de plantilla que ayude al diseo n hacer funciones de documentacion UML es tambin una metodologa de desarrollo, igual que los modelos en cascada: e

o en espiral o incremental :

La tendencia actual es esta ultima, ms moderna y realista. a 35

36

CAP ITULO 5. UML

UML nace para solucionar la diversidad en metodolog orientadas a objetos (Booch, as OMT - Object Modeling Technique -, OOSE - Object Oriented System Engineering -, CoadYourdon), generando un estndar, pues a pesar de las diferencias el objetivo es comn: a u disear la estructura de clases de un sistema, esto es, identicar y establecer las relaciones n entre sus clases componentes. Para ello son muy importantes las dos primeras etapas: el anlisis, fase preliminar a en la que se examinan los requisitos y se identican los objetos, y el diseo, fase ms n a espec ca en la que se describen los modelos lgico y f o sico, la estructura de relacin entre o los objetos1 . UML es una metodolog amplia, pretendiendo abarcar todas las tnicas de modelaa e do, pero sencilla a la vez, y fue desarrollada en origen por Booch, Rumbaugh y Jacobson. En la actualidad, el O.M.G. (Object Management Group), que desarroll los estndares o a en orientacin a objetos, ha dejado paso a la R.T.F. (Revision Task Force) en lo que a o revisin y evoluciones se reere. o UML se integra en el proceso de: Anlisis Orientado a Objetos, que se ocupa, entre otras cosas, de pormenorizar los a detalles que genera el estudio de los casos de uso. Diseo Orientado a Objetos, que rena el anlisis hasta situarse sucientemente n a prximo al programa. Consecuentemente, est ms cerca del cdigo que el anlisis. o a a o a Se distinguen dos tipos: Lgico - fsico. o Esttico - dinmico. a a Programacin Orientada a Objetos. o y formalmente puede decirse que es: Denicin o UML es un lenguaje de modelado basado en la representacin grca mediante o a diagramas con el objetivo de: Visualizar. Especicar. Construir. Documentar. Para pasar de los diagramas (de clase, de interaccin,. . . ), surgidos del anlisis y o a diseo, a un programa a un lenguaje orientado a objetos, existen una serie de reglas, que n afectan a: Nombres Denen cmo hay que llamar a los elementos y a las relaciones entre ellos. o Alcance Denen el mbito en el que es amplicable un nombre. a
1

Un anlisis muy detallado se puede tomar como diseo. a n

5.1. MECANISMOS COMUNES Visibilidad Denen cmo se pueden ver los nombres. o Integridad Denen las relaciones de unos elementos con otros. Ejecucin Denen una simulacin de un sistema / modelo dinmico. o o a

37

5.1.

Mecanismos Comunes

Son mecanismos comunes de UML: Especicaciones: de nombre, atributos, mtodos,. . . . e

Adornos; los t picos son los de visibilidad, de multiplicidad,. . .

Divisiones comunes: Divisin entre bloque e instancia del bloque. o Divisin entre interfaz e implementacin. o o Mecanismos de extensibilidad: Estereotipos, nuevos bloques denidos a partir de los existentes.

Valores etiquetados, usados para aadir informacin. n o

Restricciones, que suelen usarse para escribir cosas de un lenguaje concreto que el estndar no implementa. a

38

CAP ITULO 5. UML

5.2.

Modelado Estructural: Diagrama de clases

UML cdigo o

Llamamos ingenier directa al paso: a

Debe tenerse cuidado de no limitar el UML tratando de ajustarnos al lenguaje que usaremos despus para implementarlo, pues se corre el riesgo de esbozar un diagrama e demasiado dependiente del lenguaje. Por contrapartida, tampoco se debe no limitarlo en absoluto, ya que en ese caso la correspondencia posterior con el lenguaje de programacin puede hacerse muy dif o cil. Lo ideal es, por supuesto, encontrar el equilibrio entre ambas situaciones. Tambin se permite la ingenier inversa, que es el paso: e a cdigo UML o El gran problema que presenta es que suele aportar demasiada informacin que no es o interesante para nosotros.

Cap tulo 6 Patrones de Software

Denicin o Un patrn es una regla con 3 partes que expresa una relacin entre un cono o texto, un problema y una solucin. o El objetivo es que exista una literatura de problemas caracter sticos ya resueltos para cuando se nos presente alguno similar acudir a ella y utilizar esa solucin, ya que es comn o u en P.O.O. que para ciertos problemas distintos la forma o estructura de la solucin que o adoptan sea similar. Por tanto, se pretende que haya una serie de soluciones efectivas (que ya se sabe que funcionan) y reutilizables (que puedan ser usadas en contextos similares). Esta denicin, acuada por el arquitecto Christopher Alexander, es perfectamente o n aplicable al desarrollo de software, o al menos as lo entendieron Ward Cunningham y Kent Beck, que la adoptaron por primera vez en la OOPSLA87, un congreso sobre Orientacin o a Objetos, en su disertacin Using Pattern Languages for O.O. Programs. o Su iniciativa ser seguida por ms personajes, como Jim Coplien (Avanced C++ a a 1 Programming Styles and Idioms , 1991) y E. Gamma, R. Helm, R. Johnson y J. Vlissides, los GoF (Design Patterns Elements of Reusable O.O. Software, 1995) y M. Grand y J. W. Cooper.

6.1.

Tipos de Patrones

Tenemos varios: Arquitectnicos Expresan la estructura fundamental del sistema software, mostrando o sus subsistemas y las relaciones entre stos. Son patrones de alto nivel y se usan en e la fase de anlsis. a De Dise o Desempean el mismo papel que los anteriores pero a ms bajo nivel, pues n n a entran en cmo son las comunicaciones entre los elementos del sistema. Son propios o de la fase de diseo. n De Idiomas De nuevo son anlogos, aunque ms espec a a cos an porque estn relaciou a nados con un lenguaje particular. Se tiene un patrn espec o co para cada lenguaje, con las diferencias que ello implique.
1

En este caso el autor llama idiomas a los tipos de patrones.

39

40

CAP ITULO 6. PATRONES DE SOFTWARE En general suelen usarse los patrones de Diseo. n

Adems de una clasicacin de patrones se tiene otra divisin: de antipatrones. Miena o o tras que un patrn nos muestra una prctica correcta de programacin, el antipatrn hace o a o o lo contrario, nos ensea las cosas que no se deben hacer, como por ejemplo los grandes n programas sin modulacin, algunas especicaciones de herencia,. . . o Tenemos dos tipos de antipatrones: Los que denen un determinado problema y describen una mala solucin que lleva o a una mala situacin. o Otros indican, si nos encontramos en una mala situacin, cmo transitar a una o o buena situacin, cmo arreglarlo (refactoring). o o

6.2.

Patrones de Dise o n

Se reconocen fundamentalmente cuatro, los tres primeros denidos por el GoF y el cuarto por M. Grand: Creacionales Tratan sobre cmo crear instancias de los objetos de cara a hacer proo gramas ms exibles y ms generales intentando abstraer lo mximo posible esta a a a operacin: cuando una clase ofrece unos servicios y otra los usa, se requiere el m o nimo acoplamiento para que se produzcan las menores molestias posibles en caso de modicarse la primera. Estructurales Tratan de cmo realizar combinaciones para formar estructuras mayores o (agrupaciones de clases). Comportamiento Tratan de aspectos relacionados con las comunicaciones entre objetos, cmo llevarlas a cabo para obtener las mayores ventajas,. . . o Fundamentales Son los patrones de diseo ms bsicos, tratan del uso de interfaces, la n a a composicin, la herencia,. . . o

Cap tulo 7 Objetos Distribuidos

7.1. Partes de una aplicacin o

Son principalmente tres: Interfaz del usuario: parte que, como su propio nombre indica, interacta con u el usuario, gestiona la informacin de entrada (cmo pedirla) y la de salida (cmo o o o mostrarla). Lgica de la aplicacin: toma la informacin de entrada del interfaz y la procesa o o o para transformarla y obtener la de salida. Es lo que distingue a unas de otras, en realidad. Suele llamarse tambin lgica de negocio empresarial. e o o Servicios: servicios que se ofrecen a la lgica de la aplicacin (por ejemplo bases o o de datos, archivos, comunicacin, impresin,. . . ). o o

7.2.

Tipos de aplicaciones

Distinguimos, segn cmo se estructuran las partes anteriores: u o Aplicaciones monol ticas monocapa. o Cliente/Servidor . Tres capas.

7.2.1.

Aplicaciones Monol ticas o Monocapa

Cada computador que ejecuta la aplicacin guarda en s mismo las tres partes: o

41

42 Ventajas

CAP ITULO 7. OBJETOS DISTRIBUIDOS

Fcil diseo e implementacin (no hay que tener en cuenta nada relativo a la comua n o nicacin entre distintas computadoras. . . ). o Adecuadas para un nmero reducido de usuarios. u Inconvenientes Dif de mantener (si hay un cambio hay que ir computador por computador accil tualizando la aplicacin en todos. . . ). o Poco escalable (si aumentan las necesidades computacionales o de espacio, supone cambiar las mquinas,. . . ). a Precisa cierta capacidad de proceso (todos los ordenadores que la ejecutan deben poder hacerlo en su conjunto).

7.2.2.

Cliente/Servidor

Tienen el siguiente aspecto (forma ms comn): a u

Ventajas Se reparte la potencia de proceso (la mquina cliente no tiene que hacer todo). a Al tener un servidor dedicado se tiene una gestin de los datos ms eciente. o a Hay independencia entre la aplicacin y los datos (que as pueden utilizarse en o otras). Esto tambin benecia que la aplicacin en su conjunto sea ms fcil de e o a a mantener, escalar y reutilizar. Inconvenientes Aplicaciones ms complejas. a Aumento del coste.

 7.3. COMUNICACION ENTRE APLICACIONES

43

7.2.3.

Tres Capas

Las tres capas de la aplicacin residen en tres computadores distintos. El interfaz se o convierte as en un servicio ms al servicio de la lgica. a o

Ventajas Simplicidad de mantenimiento (cambios en la lgica no hace falta distribuirlos en o todos los clientes). Escalabilidad. Inconvenientes Aplicaciones ms complejas (que sean ms fciles de mantener no implica que sean a a a ms fciles de construir). a a Cada vez hay ms aplicaciones de este tipo, sustituyendo a las de tipo Cliente/Servidor. a Variantes: n capas Nos encontramos con esta variante cuando hay un servicio que cubre otro servicio. . . En realidad seguimos teniendo las tres capas, aunque alguna de ellas se divida en subcapas. Ello no quiere decir que haya n computadores, pueden estar varias capas en el mismo. Denicin o Hiddleware: Es el software que se utiliza entre las distintas capas para favorecer la comunicacin entre las mismas. o Es aqu donde entran en juego los objetos distribuidos.

7.3.

Comunicacin entre aplicaciones o

Partimos de que existen una infraestructura y un protocolo de red (TCP/IP,. . . ). Podemos comunicar unas aplicaciones con otras:

44

CAP ITULO 7. OBJETOS DISTRIBUIDOS Mediante lo que se conoce como env de mensajes, o mediante llamadas a procedimientos remotos, o mediante objetos distribuidos.

7.3.1.

Env de mensajes o

Esta es una tcnica de bajo nivel en la que el programador se encarga de gestionar e todos los detalles de la comunicacin (un ejemplo: sockets). o

7.3.2.

Llamadas a procedimientos remotos

Tambin denominada RPC (Remote Procedure Call), Se trata de que una aplicacin e o llama a un procedimiento de un proceso que est en otra mquina. El problema en este a a caso es el paso de parmetros, que suele ser dependiente del lenguaje utilizado. Para solua cionarlo, se desarroll el DCE (Distributed Computing Environment), que dene los datos o independientemente del lenguaje mediante la NDR (Network Data Representation). Las aplicaciones que usan DCE RPC tienen un esquema:

7.3.3.

Modelos de objetos distribuidos

Estn basados en DCE, RPC. . . y la ventaja que aportan es que aprovechan la teca nolog ya existente y, al utilizar objetos, se tienen llamadas a mtodos de stos y no a a e e procedimientos de librer algo que permite aprovechar las utilidades de la orientacin as, o a objetos. Son ejemplos: DCOM, Java RMI, CORBA,. . . . DCOM Desarrollado por Microsoft, es la evolucin del modelo COM (Component Object Moo del) integrado en OLE (Object Linking and Embedding)1 , y sus siglas responden a las iniciales de Distributed COM. Lo que se hizo fue aplicar la misma tecnolog la misma a, idea, para objetos distribuidos. Ventajas Es utilizable desde cualquier lenguaje (siempre que ste tenga las capacidades nee cesarias.
1

Aunque tambin forma parte de ActiveX, por ejemplo. e

7.4. JAVA RMI Inconvenientes Est restringido a la plataforma windows 32-bits. a Java RMI

45

Desarrollado por los mismos creadores de Java, son las iniciales de Remote Method Invocation. Ventajas Utiliza tecnolog 100 % Java, de modo que se puede utilizar all donde haya una a mquina virtual Java, esto es, no est ligado a una plataforma concreta. a a Gran facilidad de uso: los objetos remotos son muy fciles de crear y utilizar. a Inconvenientes Est ligado a Java. a CORBA La Common Object Request Broker Arquitecture es la arquitectura ms comn a u 2 para los intermediarios en las peticiones de objetos. Est gestionado por el OMG . a Ventajas Puede utilizarla cualquier lenguaje, hay soporte para lenguajes desde los ms antia guos (como cobol!) hasta los ms modernos. a Pueden alojarse en cualquier plataforma (hay servicios corba para hasta una treintena de plataformas: Windows, Linux,. . . ). Inconvenientes Su uso es complicado, a veces es ms cmoda alguna de las anteriores soluciones a o naturales, que cuentan con facilidades para su manejo. . .

7.4.
7.4.1.

Java RMI
Servidor

Entre sus tareas se encuentran: Crear objetos remotos. Hacer disponibles las referencias a dichos objetos remotos. Permanecer esperando a que llamen los clientes.

2 Object Management Group, grupo de empresas dedicado al desarrollo de estndares, sobre todo en a orientacin a objetos. o

46

CAP ITULO 7. OBJETOS DISTRIBUIDOS

7.4.2.

Clientes

Deben poder: Obtener una referencia de un objeto remoto (en un determinado servidor). Llamar a mtodos de esos objetos remotos. e El esquema es ms o menos el siguiente: a

Skeleton y Stub son sendos proxies que hacen que la comunicacin por la red entre o clientes y servidores sea transparente a ambos.

7.4.3.
3

Creacin y ejecucin (cliente y servidor) o o

(1) Denicin del interfaz remoto. o El servidor ofrece unos servicios encarnados en los mtodos de un objeto remoto. e Para poder usar esos mtodos, por supuesto, hay que conocerlos, de modo que se e especican en un interfaz : import java.rmi.*; public interface InterfazServidor extends Remote { public String Consulta (String Criterio) throws RemoteException; } (2) Implementacin del interfaz. o (3) Compilacin de la clase Servidor. o (4) Crear STUB y SKELETON. Se lleva a cabo con la orden: $ rmic claseServidor
3

Ver transparencias.

7.5. CORBA

47

o El rmci genera dos clases: claseServidor STUB, que ha de ponerse a disposicin del cliente, y claseServidor SKELETON. (5) Ejecutar el registro RMI. Es tan sencillo como: $ start rmiregistry (6) Creacin de los objetos del Servidor. o Para ello simplemente se ejecuta el archivo Servidor.class, que en su mtodo main e crea una instancia del servidor. (7) Registro de los objetos del Servidor. El constructor de la clase Servidor llama a la funcin Naming.rebind, que sirve para o llevar a cabo el registro. (8) Implementacin de la clase Cliente. o El constructor de la clase Cliente llama a Naming.lookup para obtener la referencia del objeto remoto que quiere manejar. Una vez tra da, se ejectua como si fuera local.

7.5.

CORBA

Denido por la OMG, es en realidad una especicacin formal del OMA (Object o Management Arquitecture) al que las empresas se ajustan para fabricar los productos comerciales, lo que hace que no est ligado a ninguna plataforma. e Los pilares fundamentales de corba son tres: (1) IDL (Interface Denition Language): lenguaje de denicin de interfaces, para crearo las de manera sencilla e independiente del lenguaje. (2) ORB (Object Request Brokers): gestores de peticiones de objetos, intermediarios entre clientes y servidores. (3) GIOP (General Inter-ORB Protocol): protocolo de comunicacin entre ORBs. o

7.5.1.

IDL

IDL es un lenguaje de denicin de interfaces, que son el contrato entre clientes y o servidores. La ventaja que presenta es que es un lenguaje neutro (no es C, ni Java. . . ). A la par existen puentes de comunicacin entre stos e IDL, compiladores IDL, que a o e partir de una interfaz IDL obtiene una interfaz en el lenguaje destino:

As la forma de crear los interfaces es independiente del lenguaje. ,

48

CAP ITULO 7. OBJETOS DISTRIBUIDOS

7.5.2.

ORB

Los ORB aaden una capa ms a la comunicacin entre cliente y servidor, proporn a o cionando ms independencia de la plataforma y del lenguaje al mecanismo corba. Son a espec cos tanto para el lenguaje en que se codica el servidor (o el cliente), como para la plataforma en que est corriendo. a Su tarea es realizar el marshalling/unmarshalling de forma transparente para clientes y servidores.

Los orb de cada extremo pueden diferir en lenguaje y plataforma, lo que los distingue de skeleton y stub, que ten que estar codicados en el mismo lenguaje (Java RMI); lo an que habilita esto es el uso de un protocolo estndar como es GIOP. a Son ejemplos: el Visibroker de Inprise (Delphi), Java2 de Java. . .

7.5.3.

GIOP

Este protocolo no exist en la versin 1.0, se deni en la versin 2.0. Es una espea o o o cicacin genrica de cmo conectar dos ORBs, a la que luego se le ha de dar una imo e o plementacin concreta dependiendo del protocolo de transporte (TCP/IP, PX/SPX. . . ). o El estndar obliga a que como m a nimo se haga una implementacin de IIOP (Internet o Inter-ORB Protocol), la implementacin GIOP para TCP/IP. o

7.5.4.

Servicios CORBA

Pertenecientes al oma, slo algunas implementaciones de corba los implementan. Los o ms comunes son: a Nombres: facilita la resolucin de referencias a objetos. Este servicio se estar ejecuo a tando en un lugar conocido en la red, a donde cualquier cliente puede ir a consultar. Los clientes lo usan para obtener las referencias de los objetos remotos. Eventos: para gestionar los distintos tipos de eventos que se puedan dar entre os objetos corba. Los servicios corba son a su vez objetos corba que los proporcionan, de modo que pueden ser usadas de modo sencillo por los clientes.

7.5.5.

Uso de CORBA desde Java (Ejemplo)

(1) Crear el interfaz IDL.

7.5. CORBA (2) Compilar el chero IDL a nuestro lenguaje: $ idl2java -fno -cpp Consulta.idl

49

Las opciones son para que no se use el preprocesador de C. Esta orden crea una carpeta, SvrConsultas, en la que se guardan varios cheros: Interfaz en Java. Esqueleto. Stub. Dos archivos (clases) auxiliares. 1. Esqueleto del servidor Es la clase abstracta IConsultaImlBase, que sirve como base para la implementacin del servidor. o 2. Stub del cliente Es la clase IConsultaStub, que implementa el interfaz IConsulta. No se llama a este mtodo, sino que gestiona la llamada remota para llamar al proe cedimiento denido en el servidor. 3. Clases auxiliares Son dos: IConsultaHelper.java e IConsultaHolder.java. Contienen me todos estticos (que se pueden llamar sin crear una instancia). La primera a contiene el mtodo narrow, que hace un cast a una referencia corba para e devolver un objeto remoto como un objeto Java, y la segunda controla el paso de parmetros in y out que existen en otros lenguajes como C++. a

(3) Activar el servicio de nombres, que nos permitir obtener las referencias a los a objetos que queramos. En java2 se denomina tnameserver y generalmente corre en el puerto 900 de la mquina. a (4) Implementar el servidor. Se tienen dos clases en el archivo: 1. Clase ConsultaServant, que implementa el interfaz. 2. Clase ServidorConsulta, que registra el servidor, inicializa el ORB y espera las llamadas de los clientes. (5) Implementar el cliente, que inicializa tambin su ORB y obtiene referencias de e los objetos remotos a travs del servidor de nombres. e

50

CAP ITULO 7. OBJETOS DISTRIBUIDOS

7.5.6.

Acercamiento de Java a CORBA

Se produjo mediante dos acciones principales: La inclusin de un ORB en java2. o La implementacin de Java RMI sobre IIOP. o

7.6.

DCOM

Es el principal competidor de CORBA. Desarrollado por Microsoft, con todo lo que ello supone, destaca entre sus caracter sticas la de ser independiente del lenguaje.

7.6.1.

Interfaces DCOM

Tambin se basa en el concepto de los interfaces que luego son implementados. e En DCOM, los objetos se identican por medio de un nmero de 128 bits que se llama u GUID (Globally Unique Identier ) CLSID (Class ID). Existe un mtodo que proo e porciona estos nmeros garantizando que son unicos tanto en espacio (ya que utiliza la u direccin IP la direccin Ethernet para calcularlo) como en tiempo (utiliza tambin la o o o e fecha y hora de creacin). o Los problemas con que nos encontramos residen en que los objetos DCOM no son objetos al uso, esto es, un usuario puede conectarse, llamar a procedimientos del objeto, desconectar y ms tarde reconectarse y volver a llamar a ms procedimientos, y nada a a garantiza que la instancia del objeto sea la misma, (eso s ser de la misma clase), es , a decir, no mantienen el estado entre conexiones. Los objetos DCOM implementan interfaces, y siempre van a implementar uno denominado IUnknown. Este interfaz tiene los mtodos: e AddRef. Release. QueryInterface.

7.6. DCOM

51

Los dos primeros se usan para saber cuntos clientes estn accediendo al objeto (poseen a a referencia de l) en un determinado momento. El tercero comprueba qu otras interfaces e e implementa el objeto en cuestin. o

7.6.2.

Servidores DCOM

La clase IClassFactory permite crear instancias del tipo del objeto, es una clase que hace la funcin de constructor. o El equivalente al registro de nombres de CORBA es el registro de Windows.

7.6.3.

Acceso a un objeto DCOM

Hay tres formas de acceder a un objeto DCOM: (a) Servidores Internos. Tanto las aplicaciones como los objetos internos (cuyas referencias se tienen en librer dll) corren en un mismo espacio de nombres. as (a) Servidores Locales. En este caso los objetos se buscan en un exe, por tanto, en distinto espacio de nombres, aunque residan en la misma mquina y mismo sistema a operativo. La comunicacin se lleva a cabo gracias al LRPC (Lightweight RPC ), o una versin ms sencilla de RPC. o a (a) Servidores Remotos. Cliente y servidor se hallan en mquinas distintas, utilizan a el protocolo RPC para comunicarse. Si en los dos anteriores se pod usar objetos an COM, en este caso es obligado utilizar DCOM.

52

CAP ITULO 7. OBJETOS DISTRIBUIDOS

 Indice general
1. Evolucin de los lenguajes de programacin o o 1.1. Programacin no estructurada . . . . . . . . o 1.2. Programacin procedimental . . . . . . . . . o 1.3. Programacin estructurada . . . . . . . . . . o 1.4. Programacin modular . . . . . . . . . . . . o 1.5. TADs . . . . . . . . . . . . . . . . . . . . . 1.6. Programacin Orientada a Objetos . . . . . o 1.7. Resumen . . . . . . . . . . . . . . . . . . . . 2. Elementos bsicos de la Orientacin a o 2.1. Clases . . . . . . . . . . . . . . . . 2.2. Objetos . . . . . . . . . . . . . . . 2.2.1. Creacin de objetos . . . . . o 2.2.2. Denicin . . . . . . . . . . o 2.2.3. Caracter sticas principales . 5 5 5 5 6 6 6 7 9 9 11 11 11 11 15 15 16 16 17 18 18 19 23 25 25 26 26 28 28 28 30 33

. . . . . . .

. . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Propiedades bsicas de la Orientacin a Objetos a o 3.1. Abstraccin . . . . . . . . . . . . . . . . . . . . . o 3.2. Encapsulamiento . . . . . . . . . . . . . . . . . . 3.3. Modularidad . . . . . . . . . . . . . . . . . . . . . 3.3.1. Criterios de Modularidad de Meyer . . . . 3.3.2. Objetivos de los paquetes . . . . . . . . . 3.4. Jerarqu . . . . . . . . . . . . . . . . . . . . . . a 3.4.1. Herencia . . . . . . . . . . . . . . . . . . . 3.4.2. Alternativas a la herencia: la Composicin o 3.5. Polimorsmo . . . . . . . . . . . . . . . . . . . . 3.5.1. Polimorsmo Universal Paramtrico . . . . e 3.5.2. Polimorsmo Universal de Inclusin . . . . o 3.5.3. Sobrecarga . . . . . . . . . . . . . . . . . . 3.5.4. Coaccin . . . . . . . . . . . . . . . . . . . o 3.6. Tipicacin y ligadura . . . . . . . . . . . . . . . o 3.6.1. Tipicacin . . . . . . . . . . . . . . . . . o 3.6.2. Ligadura . . . . . . . . . . . . . . . . . . . 4. Evolucin de los Lenguajes Orientados a Objetos o

5. UML 35 5.1. Mecanismos Comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2. Modelado Estructural: Diagrama de clases . . . . . . . . . . . . . . . . . . 38 53

54

INDICE GENERAL

6. Patrones de Software 39 6.1. Tipos de Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.2. Patrones de Diseo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 n 7. Objetos Distribuidos 7.1. Partes de una aplicacin . . . . . . . . . . . . . o 7.2. Tipos de aplicaciones . . . . . . . . . . . . . . . 7.2.1. Aplicaciones Monol ticas o Monocapa . . 7.2.2. Cliente/Servidor . . . . . . . . . . . . . 7.2.3. Tres Capas . . . . . . . . . . . . . . . . 7.3. Comunicacin entre aplicaciones . . . . . . . . . o 7.3.1. Env de mensajes . . . . . . . . . . . . o 7.3.2. Llamadas a procedimientos remotos . . . 7.3.3. Modelos de objetos distribuidos . . . . . 7.4. Java RMI . . . . . . . . . . . . . . . . . . . . . 7.4.1. Servidor . . . . . . . . . . . . . . . . . . 7.4.2. Clientes . . . . . . . . . . . . . . . . . . 7.4.3. Creacin y ejecucin (cliente y servidor) o o 7.5. CORBA . . . . . . . . . . . . . . . . . . . . . . 7.5.1. IDL . . . . . . . . . . . . . . . . . . . . 7.5.2. ORB . . . . . . . . . . . . . . . . . . . . 7.5.3. GIOP . . . . . . . . . . . . . . . . . . . 7.5.4. Servicios CORBA . . . . . . . . . . . . . 7.5.5. Uso de CORBA desde Java (Ejemplo) . 7.5.6. Acercamiento de Java a CORBA . . . . 7.6. DCOM . . . . . . . . . . . . . . . . . . . . . . . 7.6.1. Interfaces DCOM . . . . . . . . . . . . . 7.6.2. Servidores DCOM . . . . . . . . . . . . 7.6.3. Acceso a un objeto DCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 41 41 42 43 43 44 44 44 45 45 46 46 47 47 48 48 48 48 50 50 50 51 51