Classes

==========================================================
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

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.

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

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

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

Clase: Auto
Instancias:
Fig. 2

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

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

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.

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.

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

 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

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.

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

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

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();

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.

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

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.

Fig. 18 Clase Cuenta
Fig. 19 Clase Vehiculo
Fig. 20 Representación de una clase Auto
Fig. 21 Representación de una clase Camioneta

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

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}

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

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.

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.

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

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

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.

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.

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.

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”

}
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.

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.

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.

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
+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.

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.

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
+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);

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)

{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;

//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) {

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;

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

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;

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);

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);

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)

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;
}
}

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

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:

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

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

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.

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

HORIZONTAL
Fig. 37

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.

BIBLIOGRAFIA

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

Classes

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Classes

Transféré par

Droits d'auteur :

Formats disponibles

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NOTACION DE LAS CLACES EN UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

cambio que puede sufrir los atributos, que pueden ser:

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

Cesar Liza Avila nos menciona lo siguiente:

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:

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

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

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

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

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

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

 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

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

circulo1 = new Circulo();

circulo2 = new Circulo();

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

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

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

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

Actualmente los destructores se usan poco porque los lenguajes de

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

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

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

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

Fig. 19 Clase Vehiculo

Fig. 20 Representación de una clase Auto

Fig. 21 Representación de una clase Camioneta