unidad 2 relaciones de objetos. diagrama de clases

Programacin Orientada a Objetos

Analista Programador Universitario Plan 2008 Ao 2010

UNIDAD 2

RELACIONES ENTRE OBJETOS DIAGRAMA DE CLASES UML

Ariel Alejandro Vega 13

INTRODUCCION

Un concepto fundamental que debemos tener en cuenta a la hora de modelar la realidad por medio de objetos es que los mismos no son entidades aisladas. Los objetos interactan entre ellos constantemente por medio de mensajes. De esta forma se definen las responsabilidades de los objetos. Es decir, cuando modelamos una realidad y abstraemos de ellas objetos definimos principalmente sus responsabilidades. Una responsabilidad es una descripcin de lo que de lo que har el objeto. En otras palabras al modelar determinamos objetos y para cada uno de ellos primero definimos su contrato u obligacin. Esta obligacin o contrato en los objetos representa que informacin es valiosa y/o que operaciones (o sea sus atributos y operaciones) se necesitan de ese objeto. Cada objeto tiene al menos una responsabilidad y no debera poseer una gran cantidad de responsabilidades. Por qu? Porque esto indicara que es probable que de una misma clase se pueda crear otras clases, por lo cual se podra distribuir las responsabilidades entre las nuevas clases. Dijimos que los objetos interactan entre ellos, que no son entidades aisladas. Por lo tanto solicitan a travs de los mensajes algunas de las responsabilidades de los otros objetos. Esta interaccin provoca un vnculo o conexin entre los objetos. Esta conexin se denomina relacin. Una relacin es una conexin semntica entre objetos (es decir podemos claramente identificarla por una frase, como veremos ms adelante) y proveen un camino de comunicacin entre los objetos. Existen diversos tipos de relaciones entre objetos. En esta seccin daremos sus conceptos y luego en esta misma unidad al ver los diagramas de clases de UML se especificarn las notaciones de los mismos

RELACIN DE ASOCIACIN

Es una relacin que se da cuando existe un vnculo conceptual entre objetos. Se podra decir que es una relacin que se da cuando un objeto necesita algo de la otra, entonces de esta forma se establece el vnculo. La notacin semntica usual que se utiliza es est conectado o se asocia. Esto slo sirve para identificar la asociacin, ya que normalmente a la asociacin se le establece la palabra real que se utiliza para la asociacin Ejemplos: Una persona enciende el televisor. En esta relacin fijarse que se da la situacin de que una persona (que es un objeto) quiere ver televisin. Por lo tanto para ello necesita prenderla. Entonces el vnculo entre ellas es que la persona puede encender el televisor para poder ver televisin.

Adems entre objetos puede haber ms de un vnculo de asociacin. En el ejemplo anterior la persona no solo est vinculada a la televisin por la relacin Encender, sino que posee por ejemplo: Apagar, Cambiar de Canal, Configurar.

Otro ejemplo: Observe la imagen



UNIDAD 2



Tom (que es un objeto de la clase Persona) est vinculado con Bill (otro objeto de la misma clase) de dos formas: resulta que ambos trabajan en el mismo lugar y despus de un tiempo se hicieron amigos. Por lo tanto Tom es colaborador de Bill y, adems Tom es amigo de Bill. Por otro lado observen que el vnculo es verdadero ledo desde ambos extremos. Es decir Bill tambin es colaborador y amigo de Tom, aunque esto podra no ser verdad, a lo mejor Tom lo considera amigo a Bill, pero no ocurre lo mismo con Bill. Ya veremos que existen formas de indicar si el vnculo es unidireccional (se establece en un solo sentido) o bidireccional (se establece en ambos sentidos) Un ejemplo ms: Observe la imagen

Aqu podemos ver que un objeto se puede relacionar con ms de un objeto. Por ejemplo Juan viaja a su trabajo en auto. Pero resulta que el da de hoy el auto no arranc porque se agot su batera. Entonces tuvo que viajar en colectivo. Esto quiere decir que se establece un nuevo vnculo de asociacin entre Juan y el Colectivo. Adems fijarse que la relacin de asociacin puede o no darse al mismo tiempo. En este caso diramos que no es al mismo tiempo, pero en otros ejemplos si puede existir. Por ejemplo supongamos que Juan atiende una llamada en el colectivo, entonces se establece un vnculo entre Juan y su celular. Juan habla por Celular. Y esto ocurre al mismo tiempo que Juan viaja en colectivo. Y para finalizar con asociaciones, otro ejemplo ms:



UNIDAD 2



Aqu vemos que un alumno puede estar inscripto a varias asignaturas (2 en este caso). A su vez la materia puede considerarse un objeto y obviamente posee al menos un alumno, es decir se podra considerar un conjunto de alumnos. Y finalmente tenemos 2 profesores, el Prof. A imparte nicamente POO y el Prof. B imparte ambas materias. En pocas palabras podemos indicar con la asociacin la cantidad de objetos de una Clase que est asociado a otro objeto de otra clase. Este concepto recibe el nombre de multiplicidad. Resumiendo:

La relacin de asociacin permite indicar un vnculo entre dos o ms objetos. En trminos de objetos se dice que un objeto se asocia a otro. Por ejemplo: Si una persona llama usando su celular, en objetos se dice que la persona se asocia al celular.

La frase usual es se asocia o se conecta, que luego es representada por la frase real, por ejemplo: Persona utiliza Celular.

La relacin puede ser unidireccional o bidireccional En esta relacin se puede indicar la cantidad de objetos a la cual otro objetos se asocia. Esto

se llama multiplicidad.

LA ASOCIACIN DE AGREGACIN

La agregacin es una relacin muy importante en el mundo del modelado de objetos. Bsicamente podemos de decir que un objeto puede estar conformado por otros objetos. Imaginemos nuestra habitacin. Nuestra habitacin est conformada mnimamente por una cama, tal vez un escritorio, algn mueble, el ropero, etc. Ahora bien estos muebles son tambin objetos. Por lo tanto un objeto puede estar conformado por otros objetos, formando un nuevo objeto (recordar que todo objeto es nico por la identidad de los objetos) Otro ejemplo: un objeto sndwich, estar conformado por pan, lomito, huevo, jamn, quizs queso, etc. Estos ingredientes son otros objetos. Nuevamente un objeto est conformado por otros objetos, formando un objeto completamente nuevo. Una agregacin es un tipo especfico de relacin de asociacin. Bsicamente la agregacin es aquella relacin que permite que un objeto sea compuesto/descompuesto en otros objetos. La notacin semntica que permite identificar relaciones de agregacin es la frase forma parte de o formado por. Mencion que esta relacin es muy importante, Porqu? Imaginemos el siguiente escenario: Cuando se trata de escribir o leer desde una unidad de CD, se considera la unidad de CD como un objeto individual. Tambin se puede analizar cmo interacta la unidad de CD con el sistema de la computadora personal; los sistemas de computacin tambin se tratan como un objeto individual.



UNIDAD 2



Si se llama a un ingeniero para que repare un problema de una unidad de CD, su perspectiva de la unidad de CD es ms detallada. El ingeniero examina el motor de giro de la unidad de CD, la bandeja de la unidad y el haz de lser o el lector. Cada uno de estos elementos es un componente del objeto unidad de CD y es un objeto por s mismo. Las distintas perspectivas sobre la unidad de CD son igualmente vlidas y cada una se puede expresar en momentos diferentes. Al trabajar con objetos, resulta til emplear un nivel de abstraccin lo ms alto posible. De este modo, puede conceptualizar mejor los objetos importantes y entender mejor cmo funciona el sistema.

Hasta aqu lo que se coment, qu me aporta?: 1. Hemos delimitado la perspectiva de del sistema a la parte que nos interesa. Si no funciona la

lectora llamamos al tcnico y l se limita a reparar la unidad lectora, l no intentara ver el procesador para saber qu pas la lectora.

2. Si queremos colocar una lectora de DVD en lugar de una de DVD, simplemente sacamos la lectora de CD y colocamos la otra. De esta forma vemos que trabajar con agregacin de objetos podemos facilitar la integracin, sin embargo esto requiere un buen mecanismo de integracin. En el caso de la lectora, todo est preparado para que podamos reemplazar una lectora por otra. En los sistemas que realicemos esta facilidad la debemos poder implementar usando algn mecanismo: usar objetos facilita esta operacin porque recordemos que cada objeto encapsula su responsabilidad, adems con el uso de interfaces, es posible desacoplar an ms la funcionalidad. Entonces los objetos se pueden comportar como componentes. Y cada componente es un objeto. Esto simplifica mucho la tarea. Por ejemplo en el caso de la lectora: luego de instalar la nueva lectora es probable que el sistema detecte la configuracin ms eficiente de usarla porque el sistema simplemente usar la interface de la lectora, es decir no se conecta directamente al funcionamiento electrnico, esto es lo que permite colocar cualquier lectora.

3. En caso de que pudiramos mejorar el funcionamiento de nuestra lectora, podemos hacerlo sin afectar al resto del sistema. En nuestro caso real, no podemos hacerlo, porque no somos tcnicos, ni siquiera los tcnicos pueden hacerlo, porque las lectoras vienen de fbrica. Pero la idea central es esa, que al dividir un objeto en otros objetos, Podemos mejorar o modificar cada uno de ellos sin afectar a los otros, ya que el mecanismo de integracin estara asegurado.

De todas formas estas ventajas sern evidentes a la hora de programar, as que lo importante es entender el concepto de agregacin.

LA ASOCIACIN DE COMPOSICIN

La relacin de composicin es un tipo de agregacin con un vnculo muy fuerte, de tal modo que no se puede concebir que exista un objeto compuesto fuera del todo al que pertenece.



UNIDAD 2



Por ejemplo: Un tablero de ajedrez est compuesto por 64 casillas, es decir hay una relacin de agregacin entre tablero y las casillas, las 64 casillas forman el tablero; por otro lado si hacemos que desaparezca el tablero las casillas tambin desaparecern. Otro ejemplo: Una guitarra est compuesta por 6 cuerdas, el diapasn, el clavijero y la caja de resonancia. Si desaparece la guitarra los elementos no tienen sentido fuera de ella. Una ltima aclaracin sobre las relaciones de agregacin y de composicin: Como distinguir si una relacin es de agregacin o de composicin. Existen algunos puntos clave: En la relacin de agregacin un objeto componente (se dice objeto compuesto) puede llegar a pertenecer a ms de un objeto todo (por ejemplo un control remoto universal puede formar parte del televisor y del reproductor de dvd) mientras que en la composicin s o s un objeto componente pertenece un objeto de una clase a la vez.

LA RELACIN DE GENERALIZACIN

En la unidad 1 se presentaron las propiedades de los objetos. Uno de ellas es la herencia. La herencia es tambin un tipo de relacin entre objetos. Por lo tanto es importante considerar la importancia de la herencia, no slo como una propiedad, sino como una relacin entre objetos. Al igual que la agregacin y la composicin la generacin (o especializacin) de los objetos resulta ser fcil de representar con los objetos. La generalizacin clarifica el diseo y mejora la productividad. La notacin semntica para representar objetos es la frase es un tipo de o es una.

OTRAS RELACIONES DE INTERS

La realizacin: Es una relacin de contrato con otra clase. Se utiliza para implementar clases. Supongamos que definimos que tenemos una Clase que representa una coleccin de personas. Supongamos que el sistema debe permitir la consulta por dni o nombre y no se permite que no estn presentes estas consultas. Adems no se permite ningn otro tipo de consulta. Con esta relacin definimos un objeto que es el contrato el cual otro objeto debe respetar. Generalmente se utilizan para las denominadas interfaces. Supongamos que para el ejemplo anterior. Definimos una interfaz que se llama ConsultadorDePersonas (el cual posee las operaciones buscarPorDni y buscarPorNombre) y tenemos la clase Persona, entonces la relacin sera Persona implementa ConsutadorDePersonas.

La Dependencia: Es una relacin de uso. Es decir una clase utiliza otra clase. Y si esta ltima se altera, la anterior se puede ver afectada. En cambio si la primera se modifica sus cambios no afectan a la segunda. Este tipo de relacin provoca lo que se denomina acoplamiento, el cual debe ser en lo posible evitado. La notacin semntica es la frase usa Existen diversos tipos de casos de dependencia, los cuales sern detallados posteriormente en esta misma unidad. Por ejemplo se suele utilizar para indicar que una aplicacin invoca a otra y se genera entonces una ventana, es decir desde una ventana se invoca a otra ventana, para ello es necesario que la aplicacin genere un objeto de la clase Ventana y entonces mostrarla. Si por alguna razn modificamos la ventana esto puede afectar a la aplicacin, en cambio si modificamos la aplicacin la clase Ventana se mantiene igual.

UML Y EL DIAGRAMA DE CLASES

UML es una herramienta para modelar aspectos de un desarrollo de software (aunque no solo se limita al software) que es el resultado de varias experiencias que fueron integradas y modificadas por el aporte de diversos autores y empresas que conformaron lo que se conoce el Consorcio de UML. Sus padres oficialmente reconocidos son: Grady Booch, James Rumbaugh e Ivar Jacobson. Cada uno de ellos en sus diversas experiencias de desarrollo cre sus propias metodologas de desarrollo y aportaron la creacin de diversos modelos para el anlisis y diseo orientado a objetos.



UNIDAD 2



La empresa Rational termin sumando a sus filas a estos 3 desarrolladores, entonces ellos apostaron a unificar los diversos modelos que crearon, de esta experiencia surgi UML (Lenguaje de Modelado Unificado). A la propuesta original o anteproyecto de UML se le sumaron numerosas modificaciones como respuesta a las reacciones del mercado las cuales fueron acertadamente aceptadas, con lo cual tuvo una amplia retroalimentacin. En 1997, con el aporte de los nmerosos miembros del Consorcio de UML (DEC, Microsoft, HP, Intellicorp, Oracle, Rational, entre otros) se produjo la versin 1.0 de UML y se puso a disposicin de la OMG. Desde entonces con diversas modificaciones y evoluciones UML se ha convertido en el Estndar que recomienda la OMG (Group Management Objetcs) para la Industria del Software. Lo que ofrece UML es un conjunto de diagramas conformados por elementos grficos. Cada diagrama puede modelar uno o varios aspectos del software y pueden llegar a ser ms o menos tiles dependiendo de la etapa del ciclo de desarrollo en la que se el grupo de desarrollo se encuentre. UML es un Lenguaje porque define reglas que dirigen la forma en que deben combinarse los componentes Entonces lo importante es conocer para qu cosa funciona cada diagrama, y luego ver la notacin que se puede utilizar. Incluso UML permite cierta libertad a la hora de usar los elementos de cada Diagrama, para poder incluso combinarlos. No es el objetivo de la asignatura estudiar UML, sin embargo dado que se realiz una introduccin al modelado orientado a objetos, la definicin de los objetos, sus propiedades y relaciones, resulta apropiado utilizar un modelo para representar las clases, algunas de sus propiedades y las relaciones. UML aporta un modelo ampliamente utilizado por los desarrolladores para modelar las clases denominado Diagrama de Clases. El Diagrama de Clases es un diagrama del tipo esttico (dado que no refleja la interaccin entre las clases, simplemente refleja la estructura del mismo, como si fuera una foto). En el Diagrama de Clases una clase puede representarse de 3 formas:

Como un rectngulo, es este caso solo se representa el nombre de la clase. Por ejemplo

Como un rectngulo dividido en dos partes, en este caso se representa el nombre de la clase y sus atributos u operaciones. Por ejemplo

Como un rectngulo dividido en 3 partes, en este caso se representa el nombre de la clase, sus atributos y sus operaciones. Observe que las operaciones son acciones que inician con un verbo en infinitivo seguido de un parntesis. Por ejemplo

El Diagrama de Clases puede ser utilizado en cualquier ciclo de vida del desarrollo de un sistema (tpicamente anlisis, diseo, implementacin, prueba, mantenimiento). En cada una de estas fases



UNIDAD 2



puede adoptar nuevos conceptos. Por ejemplo en el anlisis y diseo nosotros podemos indicar que un atributo es numrico, fecha, o cadena de caracteres. Mientras que en la implementacin nosotros podemos indicar el tipo de dato del atributo segn el lenguaje de programacin. La visibilidad En el Diagrama de Clases de UML nosotros podemos indicar la visibilidad de los atributos y de las operaciones. La visibilidad permite definir el grado en el cual un atributo u operacin estar disponible para que sea usado por otras clases. Por tal razn la visibilidad est relacionada con la relacin de realizacin. Existen 3 tipos o niveles de visibilidad:

Pblico (+): en este nivel de visibilidad el atributo u operacin de una clase est disponible para todas las dems clases. Esto es, una clase cualquiera puede leer o asignar valores al atributo de clase que es definido como pblico. De la misma forma cualquier clase puede invocar una operacin que ha sido definida como pblica.

Protegido (#): en este nivel de visibilidad el atributo u operacin de una clase est disponible nicamente para sus subclases.

Privado (-): en este nivel de visibilidad el atributo u operacin de una clase no est disponible para ninguna otra clase. Solo pueden ser usadas por las operaciones de la misma clase.

He aqu algunos ejemplos de visibilidad de atributos y operaciones

En el caso de la Clase Televisin se puede observar que tiene 2 atributos pblicos, dado que la marca y el modelo son caractersticas que deben estar disponibles para cualquier otra clase Tambin debera ser posible que cualquier clase pueda modificar el volumen de la Televisin. Sin embargo la operacin colorearImagenEnPantalla() es una operacin interna. En el caso de la Clase Automovil tiene una operacin protegida llamada actualizarKilometraje(). Observe que cualquier subclase de Automovil puede usar esta operacin con lo cual se evita la necesidad de volver a crear esta operacin en cada subclase. La Generalizacin La generalizacin se representa mediante una flecha dirigida desde la subclase hasta su superclase. En la unidad uno se us esta notacin para representar el concepto de herencia. La generalizacin permite que una clase hija herede todos los atributos y propiedades de la clase madre. Por ejemplo las clases vertebrados e invertebrados pueden heredar de animal. Observe que nicamente se est representando la herencia a nivel de nombres de clases. En este caso se habla de generalizacin porque la superclase posee los atributos y operaciones comunes de todas sus hijas. Pero adems la herencia permite lo que se denomina especializacin. Esto es, una hija puede agregar atributos y operaciones no contemplados en la superclase y puede modificar las operaciones definidas en la superclase de acuerdo a sus necesidades especficas.



UNIDAD 2



La Asociacin En el diagrama de clases la asociacin se representa mediante una lnea que une dos clases. Comnmente se escribe en la lnea una frase que representa la asociacin. Cuando se realiza de esta forma se dice que la asociacin es bidireccional, es decir la relacin es en ambos sentidos. A veces puede que la asociacin sea unidireccional. En ese caso la misma se puede representar de dos formas: haciendo que la lnea sea una flecha que indique la direccin

O usando lo que se denomina navegadores. Por ejemplo

Cualquiera de las dos opciones es vlida. Tambin es posible indicar el papel de cada una de las clases que intervienen en la relacin. Para ello se coloca el papel en el extremo de cada clase. Por ejemplo

Tambin en la relacin de asociacin es posible establecer la multiplicidad. La multiplicidad indica la cantidad de objetos de una clase que se relacionan con el objeto de una clase asociada. Existe una diversidad de notaciones para la multiplicidad, los cuales son indicados a continuacin:

A continuacin se describen varios ejemplos de multiplicidad



UNIDAD 2



La Agregacin Se representa mediante un rombo que seala cual es la clase que est conformada por otras clases. Se pueden aplicar las reglas de la multiplicidad.

La Composicin Se representa mediante un rombo relleno que seala cual es la clase que est conformada por otras clases. Se pueden aplicar las reglas de la multiplicidad.

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el Objeto Almacen tambin son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

Dependencias La dependencia se establece mediante una flecha punteada. Para el ejemplo de la aplicacin que instancia una ventana, sera

Cabe destacar que la instanciacin no es el nico ejemplo de dependencia. Otros caso de dependencia aparece cuando una operacin recibe como parmetro un objeto y por lo tanto la operacin depende del tipo de parmetro que reciba. Por ejemplo: supongamos que estamos



UNIDAD 2



ante una aplicacin y que se debe mostrar un formulario en una ventana, el cual ser elegido desde un men de opciones. Esto se puede representar de esta forma

Donde la operacin implementada sera as mostrarFormulario(f:Form) y Form representa un tipo de formulario especfico. La Realizacin La realizacin se representa mediante una lnea punteada con una flecha sin relleno. Por ejemplo supongamos que Tenemos una clase Persona y tenemos una Clase Factura. Ambas deben poseer una operacin que les permita ordenar personas por nombre y facturas por fecha. Imagine entonces un contrato que define la operacin ordenar mediante una Interfaz denominada Ordenacion. Entonces ambas clases deben implementar este contrato. Cada una en su forma especfica realiza la operacin ordenar() pero no puede obviarla o evitarla. Tampoco se permite que realicen otra operacin. Tambin observe que la interfaz tiene un identificador que indica que es una interfaz. Este identificador se denomina estereotipo. Otra forma de representar la interfaz es colocar es iniciar el nombre de la Clase con la letra I. En el ejemplo sera IOrdenacion el nombre de la interfaz.

BIBLIOGRAFIA

UML y Patrones de Diseo. Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda Edicin. Pearson Prentice Hall.

Aprendiendo UML en 24 horas. Joseph Schmuller. Prentice Hall. Oracle 10g. Programacin JAVA. Gua del Alumno Volmen 1. Jeff Gallus.

unidad 2 relaciones de objetos. diagrama de clases

Documents