DIAGRAMA DE OBJETOS

TIPOS DE DIAGRAMAS
• Diagramas de estructura: mostrar la estructura
estática del sistema que se está modelando
– Incluye: diagramas de clase, componentes y/o
objetos.

• Diagramas de comportamiento: muestra el

comportamiento dinámico entre los objetos y el
sistema.
– Incluye: diagramas de actividades, casos de uso y de
secuencia
 Diagrama de Objetos
• La clase define las reglas; los objetos expresan
los hechos.
• La clase define que puede ser; el objeto
describe que es.
• Se considera un caso especial del diagrama de
clases.
• Puede construirse junto con el de clases.
• Describe una instancia de un diagrama de clase
en un momento en particular.
• Este diagrama contiene objetos y ligas.
 Objetivo
• Es una herramienta para probar y
entender un problema al documentar
ejemplos del dominio del problema.
También se usa durante el análisis y el
diseño para verificar la exactitud de un
diagrama de clases.
 Notación Diagrama de Objetos
• Consiste de dos elementos: objetos y
uniones (links). Un objeto es una entidad
real creada a partir de una clase, igual una
unión es creada a partir de una
asociación. Ejemplo Nombre de la clase
J.Perez: Cliente

clientID = 24629 Objeto J.Pérez del tipo Cliente

Nombre = Javier Perez
Direccion = Pino 45875
 Notación: objeto anónimo
• La forma abreviada utiliza :nombre de la
clase sin el nombre del objeto.
• Se usa cuando queremos dibujar un
ejemplo donde no importe el objeto
específico que participa.
Contiene hechos acerca de
los atributos. Cada atributo
: Cliente es nombrado y se le asigna un
valor. Por eso se dice que la
clientID = 24629 Clase son reglas a diferencia del
Nombre = Javier Perez Objeto que son hechos.
Direccion = Pino 45875
 Comparando el diagrama de
Clases y el de Objetos
Producto
Embarque -desc:String = null
-numSerie:String =asignado
-fecha:Date = hoy entrega …
-destino:Dierccion = null
… 0…1 1…*

21:Producto

-desc = harina
-numSerie = 563284
4321:Embarque
…

-fecha = 12-12-08
-destino = Toluca 96:Producto

-desc = frijol bayo

-numSerie = 582364
…
 Diagrama anterior
• El diagrama de objeto muestra que el objeto
4321 de tipo Embarque tiene dos Productos.
Cada atributo de los 3 objetos tiene asignado un
valor.
• Las operaciones de las clases no se incluyen en
el diagrama de objetos, ya que éstas no tienen
múltiples interpretaciones o valores como los
atributos. Cada objeto de la misma clase posee
las mismas operaciones.
Diagrama de clase
Tiene tres compartimentos: nombre, Tiene dos compartimentos: nombre
atributos y operaciones
Solo se pone el nombre de la clase
En los atributos se definen las
propiedades de los mismos
Se listan las operaciones
Las clases se conectan con una
asociación con nombre,
multiplicidad, roles.
Diagrama de objetos
y atributos
Se puede poner el nombre del
objeto : y el de la clase subrayados,
o solamente : y el nombre de la
clase
Solo se definen los valores de cada
atributo para la prueba que se esté
modelando
Las operaciones no están incluidas
en el objeto ya que son idénticas
para cada objeto de la misma clase
Los objetos se conectan con un link
que tiene un nombre y no tiene
multiplicidad.
 Aplicando Diagramas de Objetos
para probar Diagramas de Clases
VendorProduct
Product

CustomProduct

• Esta figura muestra que cada Producto puede

comprarse directamente a los proveedores
(VendorProduct) ó podemos empacarlos juntos
y hacer nuestro propio producto
(CustomProduct)
 Prueba caso 1, Diagrama de
objetos
4:VendorProduct
821:CustomProduct

12:VendorProduct

• Un CustomProduct se crea ensamblando

VendorProducts, por ejemplo los VendorProducts
4, y 12 crean el CustomProduct 821, la siguiente
figura muestra como debe cambiarse el diagrama
de clases para incluir la relación de agregación
entre CustomProduct y VendorProduct.
 Cambio en el diagrama de clases
VendorProduct
Product
1…*

0…*
CustomProduct

• El cambio muestra que un CustomProduct es

creado de uno ó más VendorProducts. Pero un
VendorProduct no nesecita usarse en un
CustomProduct forzosamente.
 Caso 2, diagrama de clases
VendorProduct
Product
2…*

0…*
CustomProduct

• ¿Cuál es el número mínimo de objetos tipo

VendorProduct que pueden formar un
CustomProduct?. Si dejamos 1, no habría
diferencia entre ambos productos
 Prueba caso 3, Diagrama de
objetos
213:CustomProduct
823:CustomProduct

23:CustomProduct

• ¿Es posible que varios CustomProduct

configuren otro CustomProduct?, en caso
afirmativo, habría que incluir un asociación
reflexiva, en el diagrama de clases, ver sig fig.
 Cambio en el diagrama de clases
VendorProduct
Product
1…*

0…* 0…*
CustomProduct

0…*

• La prueba revela la necesidad de soportar

agregación entre un CustomProduct y otros
CustomProducts. Por ejemplo un condimento
puede estar formado por 3 especies diferentes.
 Creando un esquema de base de
datos para el Modelo
• El esquema de base de datos consiste de dos fases:
creación de un esquema lógico y la creación de un
esquema físico.
• Es posible mapear entidades OO a tablas de bases de
datos.
• El esquema lógico se representa por un diagrama
Entidad-Relación.
• Cada instancia de una clase se almacena como un
renglón único en la tabla correspondiente.
• Los atributos son representados como cambos en las
tablas.
• La asociación entre clases se representa como llaves
foráneas entre las tablas.
 Estrategia
• Para convertir un diagrama de clases en
un diagrama lógico ER:
1. Convertir cada clase en una tabla
2. Especificar la llave primaria de cada
tabla
3. Crear asociaciones ER con distintas
multiplicidades.
 Validando el modelo
• ¿Cómo sabemos que este diagrama modela realmente
el dominio del problema? Una técnica consiste en
construir diagramas de objetos usando los escenarios de
casos de uso y verificando que el diagrama de objetos
se ajusta al diagrama de clases.
• Supongamos el siguiente proceso:
– Un agente de reservaciones de los hoteles C&H está esperando
llamadas de clientes que quieran reservar un cuarto de hotel.
Suena el teléfono y es un cliente que quiere reservar para ir al
hotel de Cancún en Semana Santa, el agente selecciona “Crear
una Reservación” en su pantalla principal y aparece una
reservación en blanco. Hasta este momento lo único que
sabemos es la ubicación del hotel (Cancún).
:Ubicación
Nombre=“Cancún”
 Ejemplo
• En un sistema de reservaciones, el
diagrama de clases es:
1…* hecha para 1
Reservación Cliente
1…*

1
1…* ubicada en 1
Cuarto Ubicación
 Continuación ejemplo…
– El agente pregunta de que fecha a que fecha
quiere ir e introduce las fechas en la forma.
– Se despliegan los cuartos disponibles en esa
fecha y en esa ubicación y el cliente
selecciona el 7120.

1352:Cuarto
Reservación
NumReserv = null
Status = verif 326:Cuarto :Ubicación
D_llegada = 8/04/09 Nombre:Cancún
D_salida=15/04/09

7120:Cuarto
 Continuación ejemplo…
– El agente introduce los datos del cliente en el
sistema y el objeto Cliente se relaciona con la
reservación :Cliente
Nombre: “Jaime”
Apellido = “López”
Dirección = “xxxx”
Tel = “5874587587”
1352:Cuarto
Reservación
NumReserv = null
Status = verif 326:Cuarto :Ubicación
D_llegada = 8/04/09 Nombre:Cancún
D_salida=15/04/09

7120:Cuarto
 Continuación ejemplo…
– El agente pregunta si quiere confirmar la
reservación….. En caso afirmativo el sistema
cambia el status a “Confirmada” y le asigna
un número de reservación: :Cliente
Nombre: “Jaime”
Apellido = “López”
Dirección = “xxxx”
Tel = “5874587587”
1352:Cuarto
Reservación
NumReserv = 4582
Status = confirmada 326:Cuarto :Ubicación
D_llegada = 8/04/09
Nombre:Cancún
D_salida=15/04/09

7120:Cuarto
Un cliente quiere reservar más de una habitación,
de acuerdo con el diagrama de clases sólo se
puede reservar un cuarto por Reservación. Esto
nos indica que la multiplicidad en Cuarto debe
cambiarse a 1…*. (Este es otro escenario).
1…* hecha para 1
Reservación Cliente
1…*

1…*
1…* ubicada en 1
Cuarto Ubicación
Con los cambios en la multiplicidad
– El diagrama de clases cambia en “Cuarto”

Reservación
Cliente
NumReserv 1…* 1
Status Nombre
D_llegada Apellido
D_salida Dirección
1…* Tel
ReservarCto( )

1…*

Cuarto Ubicación
1…* 1 Nombre
Nombre Dirección
Capacidad
 Paso 1: Mapear entidades a
Tablas
Crear una tabla para cada clase, dejando
los atributos
Reservación
Cliente
NumReserv
Status Nombre
D_llegada Apellido
D_salida Dirección
Tel

Cuarto Ubicación
Nombre
Nombre Dirección
Capacidad
 Paso 2: Especificar llaves
primarias para cada tabla

Reservación
Cliente
ID_Reservación
Status ID_Cliente
D_llegada Nombre
D_salida Apellido
Dirección
Tel

Cuarto Ubicación
El número de cuarto
ID_Ubicación ID_Ubicación
puede repetirse de
ID_Cuarto Nombre
un hotel a otro por eso
Nombre Dirección
es necesario incluir en
la PK el ID_Ubicación Capacidad
 Paso 3: Crear una Asociación en las
relaciones Uno a Muchos en el diagrama E-
R, usando llaves foráneas (FK)

Reservación
Cliente
ID_Reservación
Status ID_Cliente
D_llegada Nombre
D_salida Apellido
ID_Cliente FK Dirección
Tel

Cuarto Ubicación

ID_Ubicación FK ID_Ubicación
ID_Cuarto Nombre
Nombre Dirección
Capacidad
 Paso 4: Crear una Asociación en las
relaciones Muchos a Muchos en el diagrama
E-R
Reservación
ID_Reservación
Status Fue necesario incluir
D_llegada una tabla entre las
Cliente
D_salida tablas Reservación
ID_Cliente FK y Cuarto, con una llave ID_Cliente
primaria compuesta. Nombre
En el diagrama de Clases Apellido
no existía ya que no hay Dirección
atributos exclusivos de Tel
ReservarCuarto esta clase

ID_Reservación
ID_Ubicación Cuarto Ubicación
ID_Cuarto
ID_Ubicación ID_Ubicación
ID_Cuarto Nombre
Nombre Dirección
Capacidad
 Diagrama E-R
Reservación
ID_Reservación
Status
D_llegada Cliente
1…* 1
D_salida
ID_Cliente FK ID_Cliente
Nombre
1…* Apellido
Dirección
1 Tel
ReservarCuarto

ID_Reservación
ID_Ubicación Cuarto Ubicación
ID_Cuarto 1 1..*
ID_Ubicación ID_Ubicación
ID_Cuarto 1..* Nombre
Nombre 1 Dirección
Capacidad