Você está na página 1de 58

==========================================================

DIAGRAMA DE CLASES

===========================================================

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 1


OBJETIVO

1. El concepto de clase

2. Las relaciones entre clases

3. El diagrama de clase y su importancia para el análisis y diseño

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 2


INTRODUCCION

En la evolución del software los objetos fueron una abstracción de nuevo tipo,
es decir, cualitativamente diferente a las demás porque eran variables que se podían
asociar con el concepto de cosa. Gracias a este nivel de ambigüedad, los objetos
facilitaron el acceso a un campo más amplio de trabajo. Con los objetos el software
aumento su capacidad para enfrentar la complejidad, pero no era suficiente. En la
misma dirección, convenía disponer de mayor nivel de abstracción y se inventaron
las clases para expresar abstracciones de cosas (objetos). Una vez más, se facilitó el
trabajo porque las clases permiten pensar el diseño con menos elementos, expresar
relaciones de forma más compacta (abstracta) y además, dejan abierta la puerta
para elevar todavía más el potencial de ambigüedad.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 3


CAPITULO I

Las clases

Los objetos se podrían definir uno a uno o en conjunto. Para conseguir esto
último se han inventado las clases como las definiciones de los conjuntos de objetos.
Ya se utilizaron en el programa orientado a objetos para pintar círculos. Las clases
Círculo, Ventana y Formulario sirvieron para definir las propiedades de los objetos
círculo, ventana y formulario respectivamente. Algunos lenguajes de programación
permiten definir uno a uno los objetos y otros, los más difundidos, exigen la definición
(clase) de los conjuntos de objetos aunque sólo se utilice un elemento.

En general, los conjuntos se definen de forma extensiva o intensiva. Por


ejemplo, el conjunto X formado por los número 6 y 7, se puede definir de estas dos
maneras:

X = {6, 7}

X = {x / x ε N y 5 < x < 8}

La primera es una definición extensiva porque enumera todos los elementos


del conjunto, mientras que la segunda es una definición intensiva o comprensión

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 4


porque describe las propiedades que cumplen todos los elementos del conjunto, sin
mencionar los elementos. Las clases son definiciones del segundo modo.

Clase: es una definición intensiva de un conjunto de objetos. Es una definición


intencional porque establece las propiedades (atributos y métodos) distintivas
de cualquier elemento del conjunto. Por ejemplo, clase círculo ≡ {radio, centro,
color, crear, pintar} define que cualquier objeto círculo tiene un radio, un
centro, un color, se puede crear y pintar. Dicho de otra forma, si un objeto
tiene estas propiedades entonces es un círculo, según la definición previa. Los
valores de los atributos pueden diferir de un objeto a otro. Todos los objetos
de una clase tienen la misma semántica, las mismas operaciones y los
mismos atributos aunque pueden diferir sus valores.

Considerando las clases se podría decir que un objeto es una instancia


(ejemplo concreto) de una clase o un elemento del conjunto definido por una clase.
La notación UML de un objeto en particular, teniendo en cuenta la clase a la que
pertenece, es objeto:clase. Por ejemplo, circulo1:Circulo. Si se quiere expresar un
objeto cualquiera (anónimo) de una clase la notación sería “:clase”.

Desde la perspectiva de los objetos como variables software, las clases


desempeñan un papel semejante al de tipo de variable que se utiliza en el enfoque
estructurado.

Desde el punto de vista de la ambigüedad (capacidad para expresar alternativas), las


clases enriquecen el enfoque de objetos. Un objeto es una cosa y una clase define
un conjunto de cosas con iguales propiedades, pero particularidades (valores)
distintos. Las clases expresan una generalización, una abstracción, mayor que los
objetos. La estructura y relaciones de los elementos del sistema software se pueden
pensar en términos de las clases, y dejar los objetos para pensar los diseños
dinámicos particulares del sistema, usando los diagramas de interacción.
En la figura 1 se puede observar a un esqueleto humano con sus partes, pues es
una plantilla que toda persona tiene en su estructura interna; a esto diríamos que es
una clase persona; la actriz estadounidense: Katie Colmes, pertenece a esa

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 5


estructura con su sus propios valores de los atributos de la clase y a eso se llama
objeto.
En la figura 2 se puede observar la plantilla de un auto; y cuando ya se fabrica en si
los autos llega a tener existencia propia y a esto también se le llama objeto.
Por lo tanto, cuando una clase ya toma existencia propia o ya llega a tener valores
sus atributos, se dice que la clase esta instanciado y se convierte en objeto.

Calase persona
Objetos instanciados:

Jose y su hijo Pepito Katie Colmes(La actriz estadunidense)


Fig. 1

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 6


Clase: Auto

Instancias:

Fig. 2

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 7


CAPITULO II

NOTACION DE LAS CLACES EN UML


Una clase en UML se representa con un rectángulo de 4 compartimientos asi como
se muestra en la figura 3:

Fig. 3

Primer compartimiento:

Fig. 4

En el primer compartimiento se pone el nombre de la clase y opcionalmente se pone


la multiplicidad de la clase, en la parte superior derecho mostrado en la figura 5

Fig. 5

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 8


El nombre de la clase debe ser algo que represente la clase, Se acostumbra poner
la primera letra del nombre de la clase en mayúscula y los espacio en blanco con un
sub guión( “_” )
Ejemplo 1:
En la figura 6 se muestran 6 clases

Boleta Boleta_Detalle

Alumno Curso

Fig. 6

La multiplicidad(N) de la clase representa la cantidad de objetos que puede tener


una clase
Segundo compartimiento
En el segundo compartimiento se pone los atributos que posee una clase
Atributo:
Un atributo es una propiedad común a un conjunto de objetos, por ejemplo el
conjunto de objetos de la figura 7:
Clase: Aves

Fig. 7

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 9


Atributos:
- nombre
- colorPluma
- colorPico
- colorPata
- formaPico
- peso
En UML se representaría la clase Aves con sus atributos; así como en la figura 8.

Fig. 8

¿Cuáles seria los atributos del conjunto de objetos de la figura 2?


Solución

- modelo
- anioFabricacion
- peso
- caballoFuerza
- color
- placa
- etc.
En UML seria así como en la figura 9.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 10


Fig. 9

Especificación de atributos
Un atributo se puede especificar utilizando la siguiente sintaxis:

Visibilidad  nombre  multiplicidad  : tipo  valor inicial  cadena  de  propiedades

Visibilidad  : Los atributos de una clase pueden ser accesibles por:


 Toda las clases
 Las clases en las que son definidas
 Las clases en las que son definidas y por sus descendientes
Y de acuerdo a esto un atributo posee una característica llamado visibilidad.
Existe existen tres tipos de visibilidad:

Public(+):Si un atributo tiene visibilidad publica, indica que se puede acceder desde
dentro o fuera de la clase a la que pertenece y para indicar esto se pone el “+”
delante del nombre del atributo.

Private(-):Si un atributo tiene visibilidad privada, indica que se puede acceder solo
desde dentro de la clase a la que pertenece, en otras palabras esto indica que solo
los métodos de la clase tienen permiso para manipular al atributo.
Para indicar que un atributo es privado se pone el “-” delante del nombre del
atributo.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 11


Protected(#):Si un atributo tiene visibilidad protegida, indica que se puede acceder
desde la clase a la que pertenece y además se puede acceder desde las clases
descendientes y para indicar esto se pone el “#” delante del nombre del atributo

Cuando no se indica la visibilidad del atributo, se asume que es pública


Ejemplo 2:
NombreClase
+atributo1
+atributo2
-atributo3
+atributo4
#atributo5

Fig. 10
De la clase(figura 10) se observa que:
 El atributo1, atributo2 y atributo4 tiene visibilidad publica
 El atributo3 tiene visibilidad privada y
 El atributo5 tiene visibilidad protegida
En la herramienta CASE Rational Rose se utiliza para la representación de la
visibilidad los símbolos que se muestran en la figura 11

Fig. 11

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 12


 multiplicidad  : Muestra la cantidad de veces que el atributo se repite; se coloca
después del nombre del atributo y dentro de corchetes
Ejemplo 3:

NombreClase
+atributo1
+atributo2
-atributo3[0...3]

Fig. 12

En la figura 12. El atributo3 es privada y tiene multiplicidad de: 0, 1, 2 ó 3.

tipo : Es el tipo de dato que tiene el atributo y puede ser cualquiera de los tipos de
uso común tales como: int, string, char, float, double, date.
Ejemplo 4:
En la figura 12 se presenta la clase persona con sus atributos: nombre, DNI,
telefono,direccion: de tipo string, fechaNacimiento: de tipo Date

Fig. 12

  valor inicial  : Es el valor inicial por defecto que se le puede asignar a un atributo;
esto es útil para no tener inconsistencia de datos, en la figura 13 se muestra una

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 13


clase Usuario, con sus tres compartimientos: Nombre Clase, Parámetros y
operaciones.

Fig. 13

cadena  de  propiedades : es un conjunto de propiedades que indican el grado de

cambio que puede sufrir los atributos, que pueden ser:


Changeable: Se utiliza para indicar que no existe restricciones para modificar el
atributo
AddOnly: Se usa cuando los atributos tienen una multiplicidad mayor que 1 y
significa que se puede añadir mas mavlores, pero una vez creado los valores, no
puede ser removido ni alterados.
Frozen: esto indica que los valores de los atributos no pueden ser cambiados una
vez que el objeto se inicializo.

Tercer compartimiento
Contiene las operaciones que los objetos de una clase pueden realizar.
Operaciones
Las operaciones describe el comportamiento de un objeto de una clase, es decir
como un objeto interactúa con su entorno.
Ejemplo 5:
En al figura 14 se puede observar la clase usuario con tres operaciones en el tercer
compartimiento: Alumno(); que es el constructor de la clase, agregar alumno(),
Inscripción.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 14


Fig. 14

Cesar Liza Avila nos menciona lo siguiente:


“Según UML. Una operación representa el servicio que puede ser requerido por una
instancia de la clase y que afecta su comportamiento. Un método es la
implementación de una operación, esto es la forma especifica de cómo lleva a cabo
la operación”1

La sintaxis de las operaciones es similar al de los atributos:

Visibilidad  nombre (lista  parametros) : tipo  retorno cadena  de  propiedades

Visibilidad  : Visibilidad de las operaciones

Las operaciones de una clase tiene 3 tipos de visibilidad que son:

Publica(+): La operación puede ser invocado por cualquier objeto de otras clases;
para indicar esto se le antepone al nombre el símbolo “+” .
Privada(-): La operación puede ser invocada solo por la clase en la que fue creada;
para indicar esto se le antepone al nombre el símbolo “-”.
Protegida(#): Indica que la operación no puede ser invocada desde otra clase pero
si desde la clase en la que fue creada y de las clases descendientes; para indicar
esto se le antepone al nombre el símbolo “#”.
1
Libro Modelamiento con UML, Cesar Avila, pag. 78

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 15


Ejemplo 6:

Fig. 15

En la figura 15 se observa que las operaciones Usuario(), AgregarUsuario(),


EliminarUsuario() de la clase Usuario son de visibilidad privada; la operación
listarUsuario() es de visibilidad publica; las operaciones crearcuenta(),
cambiarpassword() tiene visibilidad protegida, esto significa que se puede acceder
desde las clases Alumno y Administrativo.

(lista  parametros) : Lista de parámetros


En la lista de parámetros se menciona las variables de entrada de la operación.
tipo  retorno : Tipo de retorno
El tipo de retorno es el valor que la operación retorna

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 16


Constructores y destructores: dos operaciones especiales

Los objetos son variables software estáticas (creadas en tiempo de


compilación) o dinámicas (creadas en tiempo de ejecución) según se programe. El
software tradicional tiene mecanismos para crear y destruir (liberar la memoria)
variables, el software de objetos también. En el caso de los objetos, estos
mecanismos se denominan constructores y destructores respectivamente.

Un constructor es una operación de una clase encargada de crear un objeto


de esa clase. Opcionalmente, también inicializa el estado del objeto. En el lenguaje
Java, el constructor de una clase debe tener, obligatoriamente, el mismo nombre de
la clase a la que pertenece. Por ejemplo, en el programa para pintar círculos:

 el constructor de la clase Ventana es Ventana()

 el constructor de la clase Circulo es Circulo()

 y el constructor de la clase FormularioCírculo es FormularioCírculo()

Los constructores son operaciones que pertenecen a la clase, no a los


objetos. Carece de sentido enviar un mensaje a un objeto para que se cree él mismo
cuando aún no existe. El mensaje para crear un objeto se manda a la clase. Esta
peculiaridad se refleja en el diagrama de secuencia dirigiendo la flecha del mensaje
de creación hacia la caja, en lugar de a su línea de vida como el resto de los
mensajes. Es una forma de enfatizar que el objeto no existe hasta ese momento.
UML utiliza un estereotipo de mensaje, <<create>>, para indicar la creación de un
objeto.

En términos de código, el mensaje para crear un objeto adopta la forma “new


Constructor”. Como resultado, la operación devuelve el objeto y se le asigna a una
variable. Por ejemplo:

circulo1 = new Circulo();

circulo2 = new Circulo();

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 17


Antes de mandar estos mensajes hay que declarar los atributos circulo1 y
circulo2. Algunos lenguajes crean los objetos en el momento de la declaración de la
variable, pero Java exige la declaración y los mensajes.

Una clase puede tener más de un método constructor para crear objetos de
forma distinta. Por ejemplo, un constructor puede crear el objeto inicializando todos
sus atributos y otro sin inicializarlos, o inicializando sólo alguno de ellos. Estos
constructores tienen el mismo nombre y se diferencian en los parámetros que
reciben. Por ejemplo:

Círculo()

Círculo (int centrox, int centroy, int radio, color Color)

Los clientes de la clase Circulo podrían utilizar indistintamente uno u otro


método para crear un objeto de esta clase.

Un destructor es un método que libera la memoria destruyendo el objeto. A


diferencia de los constructores, los destructores son métodos de los objetos. Para
destruir un objeto, se le envía un mensaje a él mismo para que se destruya.

Actualmente los destructores se usan poco porque los lenguajes de


programación proporcionan mecanismos, como el “garbage collector” de Java, que
se encargan de destruir automáticamente los objetos que no estén siendo utilizados.
Sin embargo, aunque el método destructor no exista, en los diagramas de secuencia
se suele mostrar el mensaje <<destroy>>, para enfatizar que a partir de ese
momento el objeto deja de usarse.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 18


Responsabilidad de la clase
Cesar Liza Avila menciona lo siguiente:
“Todas las clases deben cumplir una labor y esto es la responsabilidad de la clase.
Una responsabilidad es un contrato u obligación que la clase debe cumplir, pues
viene a ser el fin para la cual fue creada. Los atributos y comportamientos son las
características de la clase que le permite cumplir con esas responsabilidades”2.

Las responsabilidades de la clase se menciona en el cuarto compartimiento, así


como se muestra en la figura 16.

Fig. 16

2
Modelamiento con UML, Cesar Avila, Pag 84

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 19


Ejemplos de clases:

Fig. 17
En al figura 17 se muestra clases: en donde se menciona el nombre y sus
responsabilidades de cada clase

En al figura 18 se muestra una clase Cuenta, con un atributo balance de tipo entero y
tres operaciones: depositar(monto: int):void; que recibe un parámetro de tipo
entero y no retorna valor alguno, girar(monto: int):boolen; que recibe un
paramentro de tipo entero y retorna un valor de tipo bolean(0 ó 1), balance():int; que
no recibe ningun parámetro y retorna un valor de tipo entero.
En la figura 19 se tiene la clase vehiculo con tres clases con visibilidad protegida y
tres operaciones con visibilidad publica; en este caso el operador Vehiculo() es el
constructor del objeto y el operador  Vehiculo() es el destructor del objeto.
La clase Vehiculo es una clase mas general de la clase Auto y de la clase
Camioneta. A esto se llama generalización que se hablara mas adelante en la
CAPITULO III.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 20


Fig. 18 Clase Cuenta

Fig. 19 Clase Vehiculo

Fig. 20 Representación de una clase Auto

Fig. 21 Representación de una clase Camioneta

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 21


CAPITULO III

Diagrama de clases (estructura estática)

Los diagramas de clases son diagramas de estructura estática que muestran las
clases del sistema y sus interrelaciones (incluyendo herencia, agregación,
asociación, etc). Los diagramas de clase son el pilar básico del modelado con UML,
siendo utilizados tanto para mostrar lo que el sistema puede hacer (análisis), como
para mostrar cómo puede ser construido (diseño). El diagrama de clases de más alto
nivel (main class diagram), será lógicamente un dibujo de los paquetes que
componen el sistema. A su vez cada paquete tendrá un main class diagram que
muestra las clases del paquete

Las clases se documentan con una descripción de lo que hacen, sus métodos y sus
atributos. Las relaciones entre clases se documentan con una descripción de su
propósito, su cardinalidad (cuantos objetos intervienen en la relación) y su
opcionalidad (cuando un objeto es opcional el que intervenga en una relación). La
descripción de clases complejas se puede documentar con diagramas de estados

El diagrama de clases expresa la estructura u organización del sistema software en


términos de las clases. Es un reflejo abstracto de los componentes y las relaciones
entre ellos. Se puede interpretar como el plano general del sistema porque describe

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 22


la ordenación completa del sistema, aunque se puede usar de forma parcial, siempre
que se advierta esta condición.

d d
e c e c
b b
f f
a a

(1) (2)

d c d c
e b e
a
a f b
f
I G N M

Fig. 22 Consecuencias de distintas formas de organizar el sistema

Además de intervenir en el funcionamiento, el diseño del diagrama de clases es


clave porque expresa la organización del sistema y la organización, a su vez, decide
sobre aspectos fundamentales: el significado, la facilidad de desarrollo en paralelo y
la facilidad de modificación. Por significado se entiende la interpretación del sistema
que se obtiene al “leer” el diagrama.

La figura 22 muestra el efecto sobre el significado y la facilidad de


modificación de dos formas de organizar las clases. Ambas producen dos clases,
pero con consecuencias distintas respecto al significado y, a la facilidad de desarrollo
y modificación del sistema.

El primer diseño produce las clases I y G, definidas por sus componentes:

I ≡ {f, g, d}

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 23


G ≡ {a, b, c}

Con cuatro relaciones entre ellas.

El segundo diseño produce dos clases distintas N y M, con otros significados


definidos por sus componentes:

N ≡ {a, d}

M ≡ {b, c, e, f}

Con una relación entre ellas.El mismo conjunto de componentes y relaciones


{a-d-c-e-f-b}, si se quiere el mismo algoritmo, produce sistemas con propiedades
diferentes cuando se organiza de formas diferentes. El primer diseño tiene el
significado {I, G}, es difícil de desarrollar en paralelo esas clases y también es difícil
modificarlas. El segundo diseño tiene el significado {N, M}, es fácil de desarrollar en
paralelo esas clases y también es fácil modificarlas.

La figura 23. Muestra el diagrama de clases del sistema para dibujar círculos.
Se aprecian las clases, los elementos que componen cada clase y las relaciones
entre las clases.

FormularioCirculo
-int centrox
-int centroy
-int radio
-Color color
-JLabel centroxLabel
-JLabel centroyLabel
Ventana Circulo -JLabel radioLabel
-Circulo circulo1 -int centrox -JLabel colorLabel
-Circulo circulo2 -int centroy -String centroxString
+Ventana() -int radio -String centroyString
-asignarLookAndFeel() -Color color -String radioString
-setCloseClick() -boolean haydatos -String colorString
+paint(entrada Graphics g) +Circulo() -JTextField centroxTextField
+main(entrada String[] args) +paint(entrada Graphics g) -JTextField centroyTextField
-JTextField radioTextField
-JComboBox colorField
+FormularioCirculo()
+obtenerCentrox()
+obtenerCentroy()
+obtenerRadio()
+obtenerColor()

Figura 23 Diagrama de clases del sistema para pintar círculos

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 24


Un diagrama de clases ayuda al desarrollo y mantenimiento si se puede “leer”
de un golpe. La figura 23 “dice que”: el sistema está formado por ventanas que
contienen círculos, que a su vez, se definen usando unos formularios. Y además,
enuncia todas las propiedades de los elementos que constituyen el sistema. Se sabe
que las clases “contienen” y “usan” por el significado de las flechas, pero esto se
verá después.

Un diagrama de clases tiene los siguientes elementos:

- Clases
- Relaciones entre clases
- Cardinalidad
- Navegabilidad

El diagrama de clases y los diagramas de secuencia

El diagrama de clases puede aparecer en las primeras ideas del diseño o


después, derivado de diagramas de secuencias, pero casi nunca es definitivo y se
refina progresivamente con los rediseños y refactorizaciones (modificaciones que no
cambian la función) del sistema.

El diagrama de clases complementa a los diagramas de secuencias, muestra


la forma del soporte de los mecanismos, mientras que los diagramas de secuencias
muestran el funcionamiento parcial de los mecanismos. Como son vistas del mismo
sistema, pero desde ángulos distintos, deben coincidir en aquellos aspectos que
compartan. La Figura A muestra un diagrama de secuencias del mecanismo para
pintar dos círculos y su reflejo en el diagrama de clases.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 25


ventana
Diagrama de
<<create>> secuencias
círculo1
Pintar()
<<create>>
círculo2
Pintar()

Diagrama de
clases
correspondiente

Ventana Círculo Formulario

Círculo()
Pintar()

Figura A Correspondencia entre el diagrama de clases y los diagramas de


secuencias

El diagrama de secuencias de la figura expresa cómo se crean y se pintan los


círculos desde el objeto ventana. A este esquema le corresponde el diagrama de
clases mostrado en la misma figura, donde se reflejan las clases Ventana y Círculo, y
una relación entre ellas. El resto del diagrama de clases (por ejemplo, Círculo y su
relación con Formulario) estaría asociado con otros diagramas de secuencia

El diagrama de secuencias define el funcionamiento parcial del mecanismo


para pintar círculos (nada dice acerca de cómo se obtiene la información para definir
los círculos, ni otros aspectos) y el diagrama de clases, correspondiente, describe la
organización de los elementos del sistema, en términos de los conjuntos y sus
relaciones:

El sistema está formado por objetos ventana y círculo; todos los objetos
ventana usan a objetos círculo y además, los objetos círculos tienen las
propiedades de crearse y pintarse.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 26


Es importante observar que el diagrama de clases se puede obtener, aunque
sea de forma parcial, de los diagramas de secuencias. Pero, no al revés. Del
diagrama de clases no se pueden obtener los diagramas de secuencia. Viendo el
diagrama de clases no se sabe cómo funciona el sistema. Sin los diagramas de
secuencia la descripción del sistema queda incompleta. Pero tampoco los diagramas
de secuencia son suficientes para describir el sistema porque faltarían los atributos
de los objetos, operaciones internas, las relaciones jerárquicas entre clases y entre
objetos.

Relaciones entre clases

La descripción de la estructura (organización) del sistema debe dar los elementos y


las relaciones entre ellos. Por ejemplo, “el sistema está formado por ventanas que
contienen círculos, que a su vez, se definen usando formularios”. Las palabras
“contienen” y “usando” establecen las relaciones entre los elementos.

El enfoque de objetos acepta cuatro tipos de relaciones entre elementos. Tres


entre objetos y una entre clases, pero todas se expresan en el diagrama de clases.
Cada tipo de relación tiene asociado un símbolo particular. Si se confunden los
símbolos cambia el significado del diseño.

Asociación (conexión entre clases)

Dependencia (relación de uso)

Generalización/Especialización (Relaciones de herencia)

En la tabla 1 se resumen los tipos de relaciones que pueden existir entre clases

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 27


Dependencia

Generalización

Multiplicidad
Tipos de 1..*
Binaria
relaciones entre 0..*
clases Según el número Reflexiva, etc.
de clases
participantes

N-aria Clase
asociación

Asociación

Composición

Según de cómo se
una las clases

Agregación

Tabla Nº 1

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 28


Dependencia

Se denomina relación de dependencia, o de uso, a la relación de una clase


hacia otra, cuando los objetos de la primera utilizan objetos de la segunda, como
argumento en alguna operación, o sus objetos utilizan alguna de las operaciones de
la otra clase. La relación de dependencia es una relación direccional porque los
objetos que usan dependen de la especificación de los objetos usados, mientras que
los usados son independientes de quién los usa.

En UML la relación de dependencia se representa con una flecha discontinua


del elemento dependiente A hacia el elemento independiente B (del que usa hacia el
usado).

A B

Relación de dependencia o de uso

Figura 24 Representación de dependencia en UML

Del diagrama de secuencias de la figura 25 se deriva que hay una relación de


dependencia de la clase Ventana hacia la clase Círculo, y otra relación de
dependencia de la clase Círculo hacia la clase Formulario. La primera relación se
debe a que el objeto ventana crea al objeto círculo1; por tanto, depende de la
sintaxis del constructor. Y la segunda relación se debe a la creación y uso del objeto
FormularioCírculo.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 29


Ventana

Circulo1

<<create>> FormularioCirculo

<<create>>

obtenerCentrox()

obtenerCentroy()

obtenerRadio()

obtenerColor()

Figura 25 Diagrama de secuencias de obtención de los datos de un círculo

Durante la creación del objeto Círculo1, su constructor crea otro objeto


FormularioCírculo. La finalidad de este otro objeto es solicitar por pantalla las
coordenadas del centro, el valor del radio y el color. Cuando el usuario ha introducido
los datos en el formulario, finaliza el método <<create>> de FormularioCirculo.
Entonces, Circulo1 recupera el control y envía los mensajes correspondientes para
conocer los valores dados por pantalla. La figura 26 ilustra la relación de
dependencia de Círculo hacia Formulario.

Círculo Formulario

Relación de dependencia o de uso

Figura 26 Relación de dependencia de la clase Círculo hacia la clase


Formulario.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 30


En una relación de dependencia, el vínculo del objeto dependiente hacia el
independiente es efímero; lo usa y después lo olvida. Es una relación débil entre
objetos, pero que puede ser muy fuerte entre clases si el diseño descuida la
ambigüedad de la relación. Por ejemplo, es una relación muy fuerte cuando el objeto
dependiente se trae atributos del otro objeto para procesarlos como sucede en el
caso de la extracción de dinero del cajero automático.

Asociación

Se denomina relación de asociación a la relación de una clase hacia otra,


cuando los objetos de la primera contienen atributos que son objetos de la segunda.
La relación de asociación permite “navegar” de los objetos que contienen a los
objetos contenidos. La asociación se presenta en dos modalidades unidireccional y
bidireccional. En la primera, al menos un atributo de los objetos de una clase
pertenece a otra clase. En la segunda, los objetos de cada clase contienen al menos
un atributo perteneciente a la otra clase.

En UML la asociación unidireccional se representa con una flecha continua de


la clase que contiene a la clase cuyos objetos son contenidos. La asociación
bidireccional se representa con una línea continua entre las clases asociadas. Figura
27.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 31


A B
x es de la clase B Unidireccional
de A hacia B

A B

x es de la clase B z es de la clase A Bidireccional


entre A y B

Relaciones de asociación

Figura 27 Relaciones de asociación.

En el esquema superior de la figura 27, la flecha continua de A hacia B


expresa que todos los objetos de clase A tienen al menos un atributo que es (refiere
a) un objeto perteneciente a la clase B. Se indica en particular el atributo x. La línea
continua del esquema inferior expresa que todos los objetos de clase A tienen al
menos un atributo que es (refiere a) un objeto perteneciente a la clase B y que todos
los objetos de clase B tienen al menos un atributo que es (refiere a) un objeto
perteneciente a la clase A. El atributo x pertenece a B y el atributo z pertenece a B.

Gracias a la globalidad, la asociación permite el acceso directo de las


operaciones al objeto atributo. Por ejemplo, la operación Ventana (constructor de la
clase) accede a los objetos círculo1 y círculo2 directamente (sin pasar por
parámetros) porque esos objetos son atributos de la clase Ventana. Este acceso se
aprecia en el pseudocódigo parcial de la declaración de la clase Ventana y de su
constructor Ventana.

Ventana ≡ {

círculo 1, círculo 2 : Círculo “atributos de la clase Círculo”

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 32


}

Ventana::Ventana ≡ {

círculo1  nuevoCírculo “crear el objeto círculo1”

círculo2  nuevoCírculo “crear el objeto círculo2”

círculo1.Pintar “mensaje a círculo1 para que se pinte”

círculo2.Pintar “mensaje a círculo1 para que se pinte”

En una relación de asociación, el vínculo del objeto continente con el objeto


contenido es permanente. Es una relación fuerte entre objetos que dificulta la
plasticidad del software.

Agregación

Se denomina relación de agregación entre clases cuando hay una relación


“todo/parte” entre los objetos de ambas clases. En el ejemplo del sistema para pintar
círculos, se puede decir que la clase Ventana tiene una relación de agregación con
la clase Círculo porque su respectivos objetos tienen una relación “todo/parte”.

En UML se utiliza una línea continua y un rombo en el lado del todo para
representar una relación de agregación. figura 28.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 33


todo parte

A B

X es de la clase B

Relación de agregación simple

Figura 28 Relación de agregación

La relación de agregación introduce, conceptualmente, una estructura


jerárquica del tipo “está formado por” en el diagrama de clases y esto la diferencia de
las relaciones de dependencia y asociación que son relaciones entre iguales, es
decir, donde ningún objeto tiene más importancia que otro.

Sin embargo, la relación de agregación equivale a una relación de asociación


desde el punto de vista del comportamiento; sólo realza una relación conceptual
entre objetos. Por esta causa también se le denomina agregación simple o débil.

La composición es otra forma de agregación con una fuerte relación de


pertenencia; un objeto “parte” sólo pertenece a un objeto “todo” y cuando se destruye
el objeto “todo” se destruye el o los objetos “parte”. Por ejemplo, la relación entre una
ventana y el menú que contiene. Un menú sólo pertenece a una ventana, si la
ventana se mueve, el menú se debe mover igual; si la ventana se destruye, también,
se debe destruir el menú. En la composición el objeto “todo” controla la disposición y
vida de las partes. Hay un cierto efecto transitivo: lo que le ocurre al todo le debe
ocurrir a las partes.

A diferencia de la agregación simple, la relación de composición afecta al


comportamiento de los objetos y también se le denomina agregación fuerte, como
una vía de realzar esta diferencia.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 34


En UML se utiliza una línea continua y un rombo relleno en el lado del “todo”
para representar una relación de composición. Figura 29.

A B

X es de la clase B

Destructor {
x.Destructor
}

Relación de composición o agregación fuerte

Figura 29.1 Relación de composición

Una manera de conseguir la destrucción de los objetos “partes” es


programando al destructor del “todo” para que destruyan los objetos “partes” antes
de destruirse a sí mismo.

Los símbolos de agregación y composición, a veces, se utilizan con una punta


de flecha en el lado opuesto al rombo. Posiblemente se quiere destacar que la
agregación y la composición son casos particulares de la asociación, cuyo símbolo
tiene una punta de flecha. Pero esta punta de flecha es redundante porque la
posición del rombo basta para indicar el sentido de la relación: del todo a la parte.

Volviendo al ejemplo del sistema para pintar círculos, el diseño puede asignar
una relación de asociación, agregación (simple) o composición entre las clases
Ventana y Círculo, según convenga. Se podría utilizar una asociación si nada se
quiere realzar; una agregación para indicar que los objetos círculos son “parte” del
objeto ventana. Y una composición, en el caso de querer ligar la existencia de los
círculos a la ventana, de forma que al desaparecer la ventana desapareciesen
también los círculos.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 35


Considerando esa última posibilidad se ha diseñado el diagrama de clases del
sistema como se muestra en la. Figura 30Figura , ya vista con anterioridad.

FormularioCirculo
-int centrox
-int centroy
-int radio
-Color color
-JLabel centroxLabel
-JLabel centroyLabel
Ventana Circulo -JLabel radioLabel
-Circulo circulo1 -int centrox -JLabel colorLabel
-Circulo circulo2 -int centroy -String centroxString
+Ventana() -int radio -String centroyString
-asignarLookAndFeel() -Color color -String radioString
-setCloseClick() -boolean haydatos -String colorString
+paint(entrada Graphics g) +Circulo() -JTextField centroxTextField
+main(entrada String[] args) +paint(entrada Graphics g) -JTextField centroyTextField
-JTextField radioTextField
-JComboBox colorField
+FormularioCirculo()
+obtenerCentrox()
+obtenerCentroy()
+obtenerRadio()
+obtenerColor()

Figura 30 Relación de composición y relación de uso en el ejemplo del sistema


para pintar círculos

El diagrama ahora se podría leer de la siguiente manera: el sistema esta


integrado por ventanas que tiene círculos como partes propias y esos círculos usan a
formularios para especificar sus valores particulares. La diferencia más importante
entre ambas relaciones es que las ventanas recuerdan (conservan) a los círculos
mientras que los círculos se olvidan de los formularios después de usarlo. La
diferencia de comportamiento entre la asociación y la composición se disuelve al
usar Java, dada su forma automática de destruir los objetos.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 36


Ejemplo 7

Queremos construir una aplicación que pinte un triángulo en la pantalla. La


aplicación debe permitir que el cliente introduzca los datos del triángulo.

Solución

En el problema podemos pensar en tres objetos: ventana, triángulo y


formulario.

1. el objeto triángulo será la variable software capaz de recordar las constantes


de un triángulo, capaz de crearse a sí misma y, además, capaz de pintar el
triángulo.

triangulo ≡ {vértice superior, base, altura, color, crear, pintar}

2. el objeto ventana que contendrá el triángulo .

ventana ≡ {triángulo, crear, pintar}

3. y el objeto formulario que será el encargado de leer los datos necesarios para
crear el triángulo.

formulario ≡ {crear, leer}

La figura 31 muestra el diagrama de clases de esta solución.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 37


FormularioTriangulo
-int verticesuperiorx
-int verticesuperiory
-int base
-int altura
-Color color
-JLabel verticesuperiorLabel
Triangulo -JLabel verticesuperiorLabel
-int verticesuperiorx -JLabel baseLabel
-int verticesuperiory -JLabel alturaLabel
Ventana
-int base -JLabel colorLabel
-Triangulo triangulo -int altura -String verticesuperiorxString
+Ventana() -Color color -String verticesuperioryString
-asignarLookAndFeel() -boolean haydatos -String baseString
-setCloseClick() +Triangulo() -String alturaString
+paint(entrada Graphics g) +paint(entrada Graphics g) -String colorString
+main(entrada String[] args) +mover(entrada int desplazamientox, entrada int desplazamientoy) -JTextField verticesuperiorxTextField
+ampliar(entrada int zoomout) -JTextField verticesuperioryTextField
+reducir(entrada int zoomin) -JTextField baseTextField
+borrar() -JTextField alturaTextField
-JComboBox colorField
+FormularioTriangulo()
+obtenerVerticeSuperiorx()
+obtenerVerticeSuperiory()
+obtenerBase()
+obtenerAltura()
+obtenerColor()

Figura 31 Diagrama de clases de Pintar Triángulo

A continuación se muestra el código Java de las clases Ventana, Triángulo y


FormularioTriángulo.

================================================================
===

public class Ventana extends JFrame{

private Triangulo triangulo;

public Ventana() {

//Pintar la ventana vacía


setTitle("Pintar Triangulo ");
asignarLookAndFeel();
setCloseClick();
setExtendedState(MAXIMIZED_BOTH);

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 38


setVisible(true);

//Crear un triangulo y añadirlo a la ventana


triangulo=new Triangulo();
getContentPane().add(triangulo);

//Repintar la ventana con el triangulo


pack();
setExtendedState(MAXIMIZED_BOTH);
repaint();
}

private void asignarLookAndFeel()


{
//Forzar el Look and Feel de la ventana al del sistema
String laf = UIManager.getSystemLookAndFeelClassName();
try {
UIManager.setLookAndFeel(laf);
}

catch (UnsupportedLookAndFeelException exc)


{System.err.println("Unsupported: " + laf);}
catch (Exception exc)
{System.err.println("Error cargando: " + laf);}
}

private void setCloseClick()


{
//Controlar el cierre de la ventana
addWindowListener(new WindowAdapter()
{ public void windowClosing(WindowEvent e)

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 39


{System.exit(0);}
});
}
public void paint (Graphics g)
{
super.paint(g);
if (triangulo!=null)
triangulo.paint(g);

public static void main(String[] args) {

new Ventana();

}
public class Triangulo extends JPanel{

//Coordenada x del vertice superior


private int verticesuperiorx;

//Coordenada y del vertice superior


private int verticesuperiory;

//Base
private int base;

//Altura
private int altura;

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 40


//Color
private Color color;

private boolean haydatos=false;

// Crea una nueva instancia de Triangulo */


public Triangulo() {

// Mostrar el formulario para obtener los datos del triangulo


FormularioTriangulo formulario= new FormularioTriangulo();
JDialog dialog =new JDialog();
dialog.setTitle("Introduzca los datos del triangulo");
dialog.setModal(true);
dialog.setContentPane(formulario);

dialog.setDefaultCloseOperation(javax.swing.WindowConstants.HIDE_ON_CLOSE);
dialog.pack();
dialog.show();

// Obtener los datos introducidos por el usuario


verticesuperiorx=formulario.obtenerVerticeSuperiorx();
verticesuperiory=formulario.obtenerVerticeSuperiory();
base=formulario.obtenerBase();
altura=formulario.obtenerAltura();
color=formulario.obtenerColor();
haydatos=true;

public void paint(Graphics g) {

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 41


int [] coordenadasx=getCoordenadasX();
int [] coordenadasy=getCoordenadasY();

super.paint(g);
//Si el usuario ha introducido los datos pinta el triangulo
if (haydatos){
g.setColor(color);
g.drawPolygon(coordenadasx, coordenadasy, 3);
g.fillPolygon(coordenadasx, coordenadasy, 3);
g.dispose();
}

private int [] getCoordenadasX(){

int [] coordenadasx = new int [3];

coordenadasx[0]=verticesuperiorx;
coordenadasx[1]=verticesuperiorx-(base/2);

coordenadasx[2]=verticesuperiorx+(base/2);

return coordenadasx;
}

private int [] getCoordenadasY(){

int [] coordenadasy= new int[3];

coordenadasy[0]=verticesuperiory;
coordenadasy[1]=verticesuperiory+altura;

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 42


coordenadasy[2]=verticesuperiory+altura;

return coordenadasy;
}

public void mover (int desplazamientox, int desplazamientoy){

verticesuperiorx = verticesuperiorx + desplazamientox;


verticesuperiory = verticesuperiory + desplazamientoy;
}

public void ampliar (int zoomin){

if (zoomin > 0){


base= base * zoomin;
altura=altura*zoomin;
}

public void reducir (int zoomout){

if (zoomout > 0){


base = base / zoomout;
altura = altura / zoomout;
}

public void borrar(){

//Pintarme del color del fondo de la ventana

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 43


color= this.getBackground();
repaint();
}
}

public class FormularioTriangulo extends JPanel{

//Valores de los cuadros de texto


private int verticesuperiorx;
private int verticesuperiory;
private int base;
private int altura;
private Color color;

//Etiquetas de los campos de texto


private JLabel verticesuperiorxLabel;
private JLabel verticesuperioryLabel;
private JLabel baseLabel;
private JLabel alturaLabel;
private JLabel colorLabel;

//Textos de las etiquetas


private static String verticesuperiorxString = "Coordenada x del vértice superior: ";

private static String verticesuperioryString = "Coordenada y del vértice superior: ";


private static String baseString = "Base: ";
private static String alturaString = "Altura: ";
private static String colorString = "Color: ";

//Campos de texto y combo para introducir los datos


private JTextField verticesuperiorxTextField;

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 44


private JTextField verticesuperioryTextField;
private JTextField baseTextField;
private JTextField alturaTextField;
private JComboBox colorField;

//Crea una nueva instancia de FormularioTriangulo


public FormularioTriangulo() {

//crear las etiquetas


verticesuperiorxLabel = new JLabel(verticesuperiorxString);
verticesuperioryLabel= new JLabel(verticesuperioryString);
baseLabel= new JLabel(baseString);
alturaLabel= new JLabel(alturaString);
colorLabel= new JLabel(colorString);

//crear los campos de texto


verticesuperiorxTextField = new JTextField(5);
verticesuperioryTextField= new JTextField(5);
baseTextField= new JTextField(5);
alturaTextField= new JTextField(5);

//crear el combo de colores


String [] colorValues= {"Azul","Naranja","Verde","Rojo","Amarillo","Gris"};
colorField = new JComboBox(colorValues);
colorField.setEditable(false);

//Asignar las etiquetas a los campos de texto


verticesuperiorxLabel.setLabelFor(verticesuperiorxTextField);
verticesuperioryLabel.setLabelFor(verticesuperioryTextField);

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 45


baseLabel.setLabelFor(baseTextField);
alturaLabel.setLabelFor(alturaTextField);
colorLabel.setLabelFor(colorField);

//Distribuir las etiqueta en un panel


JPanel labelPane = new JPanel();
labelPane.setLayout(new GridLayout(0, 1));
labelPane.add(verticesuperiorxLabel);
labelPane.add(verticesuperioryLabel);
labelPane.add(baseLabel);
labelPane.add(alturaLabel);
labelPane.add(colorLabel);

//Distribuir los campos de texto en otro panel.


JPanel fieldPane = new JPanel();
fieldPane.setLayout(new GridLayout(0, 1));
fieldPane.add(verticesuperiorxTextField);
fieldPane.add(verticesuperioryTextField);
fieldPane.add(baseTextField);
fieldPane.add(alturaTextField);
fieldPane.add(colorField);

//Poner los dos paneles en un nuevo panel, las etiquetas a la izquierda,


//los campos de texto a la derecha.

JPanel contentPane = new JPanel();


contentPane.setBorder(BorderFactory.createEmptyBorder(20, 20, 20, 20));

contentPane.setLayout(new BorderLayout());
contentPane.add(labelPane, BorderLayout.CENTER);
contentPane.add(fieldPane, BorderLayout.EAST);

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 46


add(contentPane);

//Obtiene el Color seleccionado por el usuario


public Color obtenerColor()
{
String string=(String)colorField.getSelectedItem();
Color color;

if (string.equals("Azul"))
color=Color.BLUE;
else if (string.equals("Verde"))
color=Color.GREEN;
else if (string.equals("Naranja"))
color=Color.ORANGE;
else if (string.equals("Rojo"))
color=Color.RED;
else if (string.equals("Amarillo"))
color=Color.YELLOW;
else if (string.equals("Gris"))
color=Color.GRAY;
else
color=Color.BLACK;

return color;
}

//Obtiene la coordenada x del vertice superior introducida por el usuario


public int obtenerVerticeSuperiorx(){

if (verticesuperiorxTextField.getText()!= null)

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 47


return Integer.parseInt(verticesuperiorxTextField.getText());
else
return 0;
}

//Obtiene la coordenada y del vertice superior introducida por el usuario


public int obtenerVerticeSuperiory(){

if (verticesuperioryTextField.getText()!= null)
return Integer.parseInt(verticesuperioryTextField.getText());
else
return 0;
}

//Obtiene la base introducida por el usuario


public int obtenerBase(){

if (baseTextField.getText()!= null)
return Integer.parseInt(baseTextField.getText());
else
return 0;
}

//Obtiene la altura introducida por el usuario


public int obtenerAltura(){

if (alturaTextField.getText()!= null)
return Integer.parseInt(alturaTextField.getText());
else
return 0;
}
}

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 48


Al ejecutar el programa anterior, se mostraría al usuario el formulario de la
figura 32:

Fig. 32

Una vez introducidos los datos, se pinta el triángulo en la ventana, como se


muestra en la figura 33

Fig. 33

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 49


CAPITULO IV

LOS DIAGRAMAS DE CLASES Y EL MODELO ENTIDAD RELACION

DOS PARADIGMAS DISTINTOS

Cuando se realiza un software utilizando la metodología estructurada, nuestro


modelo de datos lo plasmamos en un diagrama entidad relación, para lo cual existen
manejadores de base de datos relacionales como son:

- SQLServer

- Oracle

- MySQL

- Etc.

Pero cuando se a utilizado el paradigma orientado o objetos, eso lo plasmamos en


un diagrama de clases; el problema surge cuando queremos hacer persistente a
nuestras clases instanciadas. Necesariamente tenemos que tener manejadores de
base de objetos que en el mercado ya existen actualmente pero que no son muy
comercial y algunos de ellos son:

- Poet

- Db4o

Algunos confunden los conceptos y simplemente dicen que un diagrama de clases


es nuestro diagrama entidad relación. Esto esta completamente mal por que los dos
paradigmas son totalmente diferentes y esto se muestra a continuación:

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 50


Paradigmas cara a cara:

Relacional Orientado a objetos

 Orientada al uso de funciones  Orientada a Objetos


 Centrada en los datos  Centrada en servicios
 Los datos constituyen un ente  Los datos coexisten junto a los
propio y van completamente procesos que los tratan.
separados de las funciones que los  Estas entidades son los Objetos
manejan.  Simplifica el tratamiento de los
 De hecho uno puede existir datos.
perfectamente sin la existencia del  Objetos, atributos, asociaciones con
otro. otros objetos, herencia, UML …
 Esto crea una complejidad añadida 

a la hora de manejar esos datos.


 Los datos son independientes de
las entidades que los procesan
 Dichos datos deben ser
almacenados en bases de datos
relacionales compuestas
principalmente de Tablas, Filas
(registros), y Campos.
 .Dichos datos deben mantener una
relación coherente entre ellos
(Relación impuesta por la Base de
datos).
 Columnas, claves ajenas, consultas
lenguaje SQL

¿Qué pasa si queremos almacenar Objetos creados por un lenguaje orientado


a Objetos en una base de datos Relacional?
En este instante se produce lo que vamos a llamar la (Entre Objetos y Datos
Relacionales) Inadaptación de Impedancia

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 51


Esquema del Paradigma Relacional

CLASE PARADIGM
A
RDBMS

OBJETO1
X
X
TABLA1 TABLA2

OBJETO2

OBJETO3
X
ENTORNO DE OBJETOS ENTORNO DE DATOS

Fig. 34.

En la figura 34 se observa la diferencia que existe entre los dos paradigmas

La solución comúnmente aceptada pasa por lo que llamaremos

Mapeo Objeto - Relacional

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 52


Mapeo (Objeto – Relacional)
 Nos permite mapear los objetos a registros en las tablas de base de
datos.
 Esto se realiza mediante una hoja de mapeo en la que “convertimos”
cada clase en una tabla, cada objeto en un registro (fila) de la base de
datos y cada atributo en una columna de la misma.
 Tenemos que manejar las relaciones entre Clases (Tablas) mediante
las típicas claves principales, primarias y/o externas.

CLASE MAPEO

REGISTRO1 RDBMS

OBJETO1
REGISTRO2 X
TABLA1

X
TABLA2

OBJETO2

OBJETO3
REGISTRO3
X
<atributo
ENTORNO DE OBJETOS > ENTORNO DE DATOS
<columna
>

Fig. 35.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 53


En la figura 35 se puede observar lo que es el mapeo de objetos, en donde
cada clase se convierte en una tabla y cada objeto se trasforma en registro para ser
almacenado en la base de datos relacional, un atributo de la clase seria una columna
de la tabla y un registro de la tabla seria un objeto. Y cuando queremos hacer el caso
inverso, ósea recuperar el objeto tenemos que convertirlo: cada columna de la tabla
en un atributo de la clase y el registro de la tabla en un objeto.

Hacer todo este proceso requiere bastante esfuerzo en la implementación.

En el mercado existen productos que realizan dicho proceso de casamiento entre los
dos paradigmas y uno de ellos es el:
HIBERNATE

En la figura 36 y 37 se observa la clase Persona y las clases Emplyee y Customer


que son clases especializadas de la clase persona y como quedaría cuado se hace
la transformación a un diagrama entidad relación

VERTICAL

Fig. 36

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 54


HORIZONTAL

Fig. 37

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 55


CONCLUSIONES

- Las clases son muy importante; según la metodología Rup uno de los
artefactos en la etapa de análisis es presentar un diagrama de clases de
análisis, que nos sirve para delimitar nuestros sistemas y otro diagrama de
clases de diseño que es más completo.

- Los diagramas de clases son su homologo de los diagramas entidad


relación si se habla del mundo estructurado.

- Cuando se realiza un análisis y diseño orientado a objetos al final se tiene


el diagrama de clases pero cuando ya se implementara necesariamente se
tiene que transformar a un diagrama entidad relación por que actualmente
no se cuenta con manejadores de base de objetos.

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 56


BIBLIOGRAFIA

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 57


LIBROS

o Tutorial and Presentations Bell College: Presentations [Object


Persistence.
o
DIRECCIONES DE INTERNET

• http://xdoclet.sf.net

• http://boss.bekk.no/boss/middlegen

• http://www.andromda.org

Ing. Elmer Chuquiyauri Saldivar – Técnicas de Programación I Página 58