DIAGRAMAS DE CLASES EN UML

PRESENTADO POR:
EDILBERTO GUTIRREZ PALACIOS

PRESENTADO A:
WILSON LANCHEROS LOPEZ

CORPORACION UNIFICADA DE EDUCACIN SUPERIOR CUN

FACULTAD DE INGENIERIA DE SISTEMAS
PROGRAMACIN ORIENTADA A OBJETOS
2015

EDILBERTO GUTIERREZ PALACIOS

IINTRODUCCIN
Generalizando al producirse cualquier requerimiento de un software, surgen ideas. Poniendo un
ejemplo un administrador general de un negocio que compra y vende productos, se observa que
utilizado la informtica puede mejorar sustancialmente su administracin. Entonces, teniendo
una idea bastante clara de su necesidad, acude a especialistas en desarrollo de software.
Despus de varias entrevistas, los especialistas determinan que deben cumplir con las siguientes
etapas de trabajo para generar el software adecuado a los requerimientos de su cliente:
1.
2.
3.
4.
5.
6.

Relevamiento
Anlisis
Diseo
Desarrollo
Capacitacin
Mantenimiento

El relevamiento consiste en un dialogo permanente de los especialistas y el cliente (puede incluir

al personal de diferentes sectores del negocio) con el fin que los primeros identifiquen todos y
cada uno de los componentes de dicho negocio y cmo interactan. En definitiva, los
especialistas deben comprender aquella idea detalladamente y mantenerla mientras se produce el
software.
Para esto, los especialistas pueden hacer uso del UML ya que les ayudar a capturar la idea del
sistema requerido, para luego comunicarla a los involucrados en el proyecto. Esta tarea se lleva a
cabo en las etapas de anlisis y diseo, utilizando simbologa y diagramas UML con el objeto de
modelar el sistema.
Modelar el sistema utilizando los diagramas de UML, significara en definitiva contar con
documentos que plasman el trabajo de capturar la idea para la posterior evolucin del proyecto.
El cliente podr entender el plan de trabajo de los especialistas y sealar cambios si no se capt

EDILBERTO GUTIERREZ PALACIOS

correctamente alguna necesidad; o bien, indicar cambios sobre la marcha del proyecto. A su vez,
los especialistas encargados del desarrollo generalmente trabajaran en equipo, por lo que cada
uno de ellos podr identificar su trabajo particular y el general a partir de los diagramas UML.
UML proporciona las herramientas para organizar un diseo slido y claro, que comprendan los
especialistas involucrados en las distintas etapas de la evolucin del proyecto, y por qu no para
documentar un anteproyecto que ser entregado al cliente.

EDILBERTO GUTIERREZ PALACIOS

HISTORIA DE UML
UML respaldado por el OMG (Object Management Group), es un lenguaje de modelado de
sistemas de software. Diseado como una herramienta grfica donde se puede construir,
especificar, visualizar y documentar sistemas.
Permite representar el modelo de un escenario, donde se describen las entidades intervinientes y
sus relaciones. Tambin podemos al describir cada entidad, especificar las propiedades y el
comportamientos de las mismas.
Rational Software Corporation contrato en 1994 a James Rumbaugh y la compa se convirti
en la fuente de los dos esquemas de modelado orientado a objetos ms populares de la poca:
-

OMT (Object-modeling technique) de Rumbaugh, que era mejor para anlisis orientado a

objetos.
-

Mtodo Booch de Grady Booch, que era mejor para el diseo orientado a objetos.

Poco despus se les une Ivar Jacobson, el creador del mtodo de ingeniera de software orientado
a objetos. Jacobson se uni a Rational en 1995, despus de que su compaa Objectory AB fuera
comprada por Rational.
En 1996 Rational concluy que la abundancia de lenguajes de modelado estaba alentando la
adopcin de la tecnologa de objetos, y para orientarse hacia un mtodo unificado, encargaron a
estos especialistas que desarrollaran un Lenguaje Unificado de Modelado abierto.
Se organiz en 1996 un consorcio internacional llamado UML Partners, para completar las
especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una

EDILBERTO GUTIERREZ PALACIOS

respuesta al OMG RFP. El borrador de la especificacin UML 1.0 de UML Partners fue
propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners form una
Fuerza de Tarea Semntica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para
finalizar las semnticas de la especificacin y para integrarla con otros esfuerzos de
estandarizacin. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto
de 1997 y adoptado por la OMG en noviembre de 1997.
UML desde 1995, es un estndar aprobado por la ISO como ISO/IEC 19501:2005 Information
technology Open Distributed Processing Unified Modeling Language (UML) Version
1.4.2.

EDILBERTO GUTIERREZ PALACIOS

DIAGRAMAS DE UML

Casos de Uso

Clases
Objetos
Statechart
Actividades
Secuencia
Colaboracin
Componentes
DIAGRAMA DE CLASES DE UML

Describe las clases y muestra las relaciones entre ellas.

TIPOS DE RELACIONES:

Is-a: una clase es del tipo de otra clase

Asociaciones entre clases:

Una clase contiene a otra clase (Has-a)

Agregacin

Composicin

Una clase usa otra clase (Uses-a)

Una clase crea a otra clase

REPRESENTACIN DE CLASES
MiClase

EDILBERTO GUTIERREZ PALACIOS

MiClase

La figura de la izquierda muestra el smbolo para una clase en su forma completa, y el de

la derecha en su forma abreviada.

Por convencin, los nombres de clases comienzan con maysculas y deben estar escritos

con letra de tipo bold en sus smbolos.

REPRESENTACIN DE CLASES (II)
MiClase

En la forma completa del smbolo:

El compartimento superior est destinado al nombre de la clase.

El compartimento del medio muestra los atributos de la clase.
El compartimento inferior muestra las operaciones.

ATRIBUTOS
Los atributos representan informacin acerca de un objeto.

EDILBERTO GUTIERREZ PALACIOS

El trmino atributo no es exactamente sinnimo de variable. Un atributo representa una

propiedad definida en trminos abstractos, mientras que una variable es el mecanismo de
implementacin del atributo.

ATRIBUTOS

Perso
na
nombre: String
fechaDeNacimiento: date
altura: float

Se ubican en el compartimento inferior de las clases.

Perso
na
nombre: String
fechaDeNacimiento: date
altura:float

OPERACIONES

getNombre():String
setNombre(nombre:String)
...
getEdad():integer
getAltura():float
setAltura(altura:float)

OPERACIONES SOBRECARGADAS
Las operaciones sobrecargadas aparecen varias
Veces en el smbolo de la clase (en cada ocasin con diferente cantidad o tipo de argumentos).
Una de las versiones de la operacin rebajarPrecio reduce el precio del producto en una cantidad
predeterminada y la otra recibe un porcentaje de descuento.

VISIBILIDAD DE ATRIBUTOS Y OPERACIONES

UML aade un prefijo a las operaciones y atributos para indicar su visibilidad:
+ Para atributos y operaciones pblicas.

EDILBERTO GUTIERREZ PALACIOS

# Para atributos y operaciones protegidas.

- para atributos y operaciones privadas.
Si se omite el prefijo, se asume que el atributo u operacin es pblica.
ATRIBUTOS Y OPERACIONES DE CLASES
Los atributos y operaciones de clase (aquellos que no pertenecen a una instancia en particular
sino que son compartidos por toda la clase) se representan en UML subrayados.
OrdenDeCompra
- NumeroDeOrdenes: int
...
+ getNumeroDeOrdenes():int
...

Registra el nmero de rdenes de compra creadas

Obtiene en nmero de rdenes de compra creadas.
OPERACIONES Y CLASES ABSTRACTAS
Polg
ono
area:float
...
+ getArea():float {abstract}
...

Polg
ono
area:float
...
+ getArea():float...

El nombre de una clase abstracta debe estar en estilo itlico o con la indicacin {abstract}.
Las operaciones abstractas tambin deben estar en estilo itlico o con la indicacin {abstract}.

GENERALIZACIN: HERENCIA SIMPLE

VehculoMotor

EDILBERTO GUTIERREZ PALACIOS

Automvil

Camin

Una jerarqua de herencia se muestra utilizando flechas que apuntan hacia arriba en la jerarqua
(en el ejemplo: Automvil y Camin son subclases de VehculoMotorizado).
GENERALIZACIN: HERENCIA SIMPLE (II)
VehculoMotorizado

Automvi

Camin

Otro estilo para mostrar una jerarqua de herencia.

GENERALIZACIN: HERENCIA MLTIPLE
UML permite mostrar herencia mltiple (cuando una clase hereda directamente de ms de una
superclase).
ASOCIACIONES
Una asociacin caracteriza un cierto tipo de relacin que puede darse entre instancias de
determinadas clases.
Por ejemplo, si tenemos las clases Persona y Perro, las siguientes relaciones podran darse
entre sus instancias:

Juan es propietario de Fido

Pedro es propietario de Rintintn

Pedro es propietario de Lassie

ASOCIACIONES (II)

Persona

propietari
o
1..1

DePerr
o

0.
.*
propie

Perro

EDILBERTO GUTIERREZ PALACIOS

La asociacin muestra que existe una relacin de propiedad entre personas y perros, por la cual
una persona puede ser propietario de cero o ms perros y un perro es propiedad de una nica
persona.
ASOCIACIONES (III)
Cada asociacin se muestra como una lnea entre dos clases.
El nombre de la asociacin aparece en la lnea.
El rol de cada clase en la asociacin aparece al lado de la clase, al final de la lnea.
La multiplicidad de la asociacin tambin aparece al final de la lnea.
MS SOBRE ASOCIACIONES

No es obligatorio poner nombres a las asociaciones. Sin embargo es recomendable (se

nombran con un sustantivo singular).

No es necesario poner nombres de roles tampoco.

La multiplicidad en un diagrama puede ser debatible, depende de lo que interese

representar en el modelo.

Puede existir ms de una asociacin entre un par de clases. Asimismo, una clase puede
tener una asociacin consigo misma.
COMPOSICIN
Permite expresar que un objeto se compone de otros objetos.
COMPOSICIN (II)

La asociacin entre el objeto compuesto y sus constituyentes se denota con un una lnea
con diamante relleno en el extremo del objeto compuesto.

El rol del constituyente aparece en el extremo del constituyente de la asociacin (un

objeto constituyente puede jugar ms de un rol).

Debe mostrarse la multiplicidad en el extremo del constituyente de la asociacin.

EDILBERTO GUTIERREZ PALACIOS

COMPOSICIN (III)
El objeto compuesto no existe sin sus componentes.

Un objeto constituyente puede formar parte de solo un objeto compuesto a la vez.

La composicin suele ser heterognea: los componentes suelen ser de distintas clases
(cola, fuselaje, etc.).

AGREGACIN
Permite expresar que un objeto agrupa a otros objetos.
AGREGACIN (II)
La asociacin entre el agregado y sus constituyentes se denota con un una lnea con diamante
abierto (no relleno) en el extremo del agregado.

El rol del constituyente aparece en el extremo del constituyente de la asociacin.

Debe mostrarse la multiplicidad en ambos extremos de la asociacin.

AGREGACIN (III)
El objeto agregado puede existir potencialmente sin sus objetos constituyentes.

Un objeto constituyente puede ser parte de ms de uno agregado.

La agregacin tiende a ser homognea: los objetos constituyentes son de la misma clase.

CREACIN
Se pude representar la idea que una clase es creada por otra utilizando la etiqueta <<create>>

DIAGRAMA DE OBJETOS DE UML

EDILBERTO GUTIERREZ PALACIOS

Muestran fotografas de los objetos pertenecientes a un sistema, en un momento determinado.

Sirven, por ejemplo, para ejemplificar la configuracin de objetos.