Tema 6

Diseño y Gestión de
Bases de Datos
Tema 6
Diseño Conceptual con UML
Profesoras: Laura Mota y Mª José Vicent

Diseño y Gestión de Bases de Datos. Diseño Conceptual con UML 2
Índice (Objetivos)
1. Repaso al diseño conceptual con el diagrama de clases
del UML.
2. Estudio de aspectos avanzados de los conceptos del
diagrama de clases del UML.
3. Refinamiento y verificación de diagramas de clases.
4. Casos.
Índice
del UML
1. Diagrama de clases
2. Clase
3. Atributos
4. Asociación
5. Clases débiles
6. Especialización/Generalización
7. Restricciones
diagrama de clases del UML.
3. Refinamiento y verificación de diagramas de clases.
4. Casos
1. Diseño conceptual con UML

• Metodología para el diseño de bases de datos relacionales.
• Se incidirá en dos aspectos principalmente:

• Aspectos metodológicos: estrategias y recomendaciones para
abordar el problema de diseño.
• Aspectos de lenguaje de modelado: presentación de lenguajes
adecuados para representar el sistema a desarrollar (modelo de
datos).

• Una metodología es un conjunto de procedimientos,
técnicas y ayudas a la documentación para el desarrollo de
un producto software (base de datos).
Técnicas: representan cómo llevar a cabo cada una de las

actividades o pasos que consta la metodología.
• Procedimentales
• Heurísticas
Modelos: instrumentos que se emplean para representar

una determinada realidad (modelos de datos).


• Un modelo de datos es una herramienta intelectual que
permite representar las propiedades estáticas y dinámicas
de la parcela del mundo real que es objeto de estudio.
• Los modelos de datos se diferencian entre sí en cuanto a

los conceptos que proporcionan y, en cuanto al
formalismo utilizado para su definición.

Para el diseño de la Base de Datos seguiremos el esquema:
Diagrama Clases UML
Diseño Lógico
(transformación)
Modelo Relacional
Diseño Físico
(adaptación, implementación,
rendimiento)
DDL de Oracle
1.1. Diagrama de clases

El diagrama de clases permite representar las estructuras
que constituyen el contenido del sistema de información
junto con restricciones de distintos tipos que limitan las
ocurrencias válidas de las mismas.
• clase
• atributo
• asociación
• generalización/especialización
• restricciones
1.2. Clase
La observación de la realidad permite detectar el conjunto de
“objetos” (físicos o conceptuales) de los que se quiere
almacenar información para, mediante el uso de la
clasificación, que es uno de los mecanismos de abstracción
más primario que existen, descubrir el conjunto de “clases” (o
tipos de objetos) que son de interés para la organización
Mundo real Modelo de la realidad
PERSONA
CLASIFICACIÓN
COCHE
1.2. Clase
• Los componentes básicos de un SI son los objetos de los
que se quiere almacenar información; todos los objetos que
son del mismo tipo se representan con un una clase.
Una clase es una descripción de un conjunto de
objetos que comparten las mismas propiedades.
• Con una clase se representará cualquier persona, concepto,
suceso o evento (en definitiva cualquier “cosa”) sobre el que
se quiera almacenar información.
Clase
1.3. Atributos
Un atributo es una propiedad de una clase identificado
con un nombre, cuyas instancias pueden tomar valor
de un conjunto de valores que se especifica.
Zona de especificación
Clase
de los atributos de la
clase
1.3. Atributos
A cada atributo se le puede especificar:
• Tipo de datos asociado que determina los valores que
puede tomar el atributo:
▪ El nombre de un tipo de datos conocido.
▪ Una enumeración de valores posibles entre
paréntesis.
▪ Registro.
• Restricciones:
▪ De unicidad
▪ De cardinalidad
▪ De identificación
1.3. Atributos
• Restricciones:
• De unicidad
Representa el hecho de que las distintas ocurrencias de

una clase deben tomar valores distintos para el atributo (o
conjunto de atributos) sobre los que se define.
Clase No puede haber dos

a:{único1} ocurrencias de la clase con el
mismo valor en a ni con el
b:{único2}
mismo valor a la vez en b y c.
c:{único2}
1.3. Atributos
• Restricciones:
• De cardinalidad
Expresan el número de valores que puede tomar el atributo
para cada ocurrencia de la clase.
• {1..1}: el atributo tiene exactamente un valor para cada
ocurrencia de la clase.
• {0..1}: el atributo puede tener como mucho un valor para
cada ocurrencia de la clase o puede no tener valor (es el
valor por defecto).
• {1..*}: el atributo puede tener más de un valor para cada
ocurrencia de la clase pero al menos tiene un valor.
• {0..*}: el atributo puede tener más de un valor para cada
ocurrencia de la clase o puede no tener valor.
1.3. Atributos
• Restricciones:
• De identificación
Un identificador es un conjunto de atributos con restricción

de unicidad y con cardinalidad {1..1} que permite distinguir
dos ocurrencias de la clase (sólo hay un identificador
aunque puede constar de varios atributos).
Clase
a:{id}
b:{id}
1.3. Atributos
1.4. Asociación
Las asociaciones permiten representar las posibles relaciones
existentes entre las clases del sistema de información.
Una asociación que conecta dos clases se dice que es binaria.
A B
Asociación
entre A y B
1.4. Asociación: asociación binaria

Adornos en una asociación:
• Sentido
• Nombre opcionales
• Rol
• Cardinalidad
A B
R
Rol_A Rol_B

Adornos en una asociación:
• Sentido
• Nombre
• Rol R(A(minA..maxA), B(minB..maxB))
• Cardinalidad
A B
R
minB ..maxB minA ..maxA
Cada ocurrencia de A se Cada ocurrencia de B se

relaciona con, como mínimo minA relaciona con, como mínimo minB
ocurrencias de B y como máximo ocurrencias de A y como máximo
con maxA ocurrencias de B. con maxB ocurrencias de A.

Cardinalidad: Valores más usuales
• minA= 1 y maxA= 1
• minA= 0 y maxA= *
• minA= 0 y maxA= 1
• minA= 1 y maxA= *
Cuando la cardinalidad mínima de una clase es

distinta de 0 se dice que esa clase tiene restricción
de existencia respecto a la asociación.

Diagrama que representa la información de qué ríos pasan
por qué provincias. Se ha representado que un río puede
pasar por varias provincias, al menos por una, y que por una
provincia puede que pasen varios ríos o ninguno.
Río Provincia
Pasa_por
cod_r: {id}:char cod_p: {id}:char
… 0..* 1..* …
1.4. Asociación: Clase-Asociación (presencia de

atributos)
Si se quiere incluir la información: durante cuántos kilómetros
pasa cada río por cada provincia que atraviesa.
Pasa_por debe definirse como una clase-asociación.
Río Provincia
Pasa_por
… 0..* 1..* …
Pasa_por
km: {1..1}:real
1.4. Asociación: Clase-Asociación (presencia de

atributos)
Clase-asociación: es un concepto que comparte propiedades
de la clase (tenencia de atributos, asociaciones, etc.) y de la
asociación (permite asociar a clases).
Río Provincia
Pasa_por
… 0..* 1..* …
Pasa_por
km: {1..1}:real
1.4. Asociación: Clase-Asociación (asociación

con otra clase)
El diagrama representa la información sobre discos y

canciones y las canciones que contiene cada disco.
1.4. Asociación: Clase-Asociación (asociación

con otra clase)
…además se quiere información sobre cantantes y de qué
cantante canta una determinada canción en un disco
Contiene
1.4. Asociación: Asociaciones n-arias

• Sea R una asociación n-aria (n > 2) definida sobre las clases A1,
A2,, An. El conjunto de ocurrencias posibles de R es R  A1 
A2    An. Sean A y B dos subconjuntos disjuntos del conjunto
de clases {A1, A2, , An} tales que A  B = {A1, A2,, An}. Las
cardinalidades se representan, para cada par de subconjuntos A
y B que se puedan formar, con la expresión siguiente:
R(A(minA..maxA), B(minB..maxB))
• Cada ocurrencia del conjunto de clases A puede estar

relacionada a través de R con n ocurrencias del conjunto de
clases B siendo minA  n  maxA.
• Cada ocurrencia del conjunto de clases B puede estar
relacionada a través de R con n ocurrencias del conjunto de
clases A siendo minB  n  maxB.
1.4. Asociación: Asociaciones n-arias

Ejemplo
• Sea R una relación cuaternaria entre las clases A, B, C y D. Las
cardinalidades a considerar son:
• R(A(minA..maxA), BCD(minBCD..maxBCD)) • R(AB(minAB..maxAB), CD(minCD..maxCD))
• R(B(minB..maxB), ACD(minACD..maxACD)) • R(AC(minAC..maxAC), BD(minBD..maxBD))
• R(C(minC..maxC), ABD(minABD..maxABD)) • R(AD(minAD..maxAD), BC(minBC..maxBC))
• R(D(minD..maxD), ABC(minABC..maxABC))
• Dada relación n-aria, en el diagrama de clases sólo se pueden

representar las cardinalidad de (n−1) clases frente a la enésima.
• Las demás cardinalidades, en el diagrama, se asumen con los
valores menos restrictivos, 0 para la mínima y * para la máxima,
si estos valores no son adecuados, habrá que incluir una
restricción de integridad en lenguaje natural.
1.4. Asociación: Asociaciones n-arias (ejemplo)

• pmin, gmin, amin→ 0
Docencia ( Profesor (pmin, pmax) , Asignatura-Grupo (0..1))
• pmax, gmax, amax→ *
Profesor Asignatura
DNI: {id}: char 0..1
Docencia 0..* código: {id}: char
nombre: {1..1}: char nombre:{1,1} :char
Docencia (Asignatura (amin, amax) , Profesor-Grupo (0..*))
0..*
Grupo
código: {id}: char
capacidad: {1..1}: int
Docencia (Grupo (gmin, gmax), Profesor-Asignatura (0..*))

1.5. Clases débiles

Una clase sufre restricción de dependencia de identificación
cuando no puede identificarse con sus propios atributos de
manera que sus ocurrencias son distinguibles gracias a su
asociación con otra/s clase/s.
A este tipo de clases se les denomina clases débiles.
Esta restricción se representa con la etiqueta {id} en lugar de la
cardinalidad (la cardinalidad que suyace es siempre 1..1) e
implica que la clase débil cuenta entre sus atributos con el o los
atributos identificadores de la/s clase/s de las que depende, sin
que tengan que representarse explícitamente.
1.5. Clases débiles
A B
a:{id}:char {id} 0..* b:{id}:char
… …
A B
a:{id}:char {id} 0..1 b:char
… …
1.5. Clases débiles (ejemplo)
Ciudad País
Está
nom_c: {id}:char nom_p: {id}: char
… 0..* {id} …
{id}→ 1..1
restricción de
dependencia de
identificación
1.5. Clases débiles (ejemplo)
Recurso Pleito
Afecta
fecha: {1..1}: date num: {id}: int
… 0..1 {id} …
1.6. Generalización/Especialización
Cuando se detecta que entre distintas clases definidas en el

esquema existe una relación de inclusión, este hecho se
expresa por medio de la Generalización/Especialización.
Esto significa que la clase más general se especializa en
una o varias subclases, o dicho a la inversa, que una o
varias clases se generalizan en una superclase.
Todas las subclases de una clase tienen, además de sus

atributos propios, todos los atributos de sus superclases (en
cualquier nivel), aunque no se representan en el diagrama.
Total: toda ocurrencia de la clase G se especializa en C1, C2 o C3.

Parcial: puede haber ocurrencias de G que no se especialicen ni en C1 ni
en C2 ni en C3.
Disjunta: no puede haber ocurrencias de G que estén especializadas a la

vez en dos subclases.
Solapada: puede haber ocurrencias de G que se especialicen en más de
una subclase.
Las clases especializadas no tienen identificador.

Heredan la identificación de su superclase.
1.7. Restricciones
• Existen números lugares en el diagrama donde se
expresan restricciones:
• Atributos:
• De valor: precisando el tipo de datos asociado.
• Cardinalidad: precisando la multiplicidad de valores posible para
cada objeto en ese atributo.
• Clases:
• Unicidad: impide la existencia de objetos con el mismo valor para
los atributos especificados.
• Identificación: impide la existencia de objetos con el mismo valor o
sin valor en los atributos especificados.
• Asociaciones:
• Cardinalidad: limita la forma asociativa entre clases.
1.7. Restricciones
• Otras restricciones:
• Elementos de anotación: comentarios que se pueden utilizar
para describir, clarificar e incluir observaciones sobre cualquier
elemento del diagramas
Restricción de
integridad
Índice
del UML
diagrama de clases del UML
1. Estudio de la asociación y clase-asociación
2. Estudio de la generalización/especialización
3. Aspectos dinámicos
3. Refinamiento y verificación de diagramas de clases
4. Casos
2.1. Asociación y clase-asociación

A1 An
• Asociación
AS
Binaria
A1
An
• Asociación
N-aria
AS
A2
A3

• Aspectos a considerar:
• Identificador: no tienen*
• Identificación: para distinguir una ocurrencia de otra se
usarán las clases asociadas. ¿Cuáles? Depende de la
cardinalidad.
• Clase-asociación:
• Presencia de propiedades
• Corrección en el diseño
* Esto implica que si a una clase-asociación se le especifican atributos con la

etiqueta {id}, el diagrama es incorrecto.

• Identificador NO, identificación SÍ:
Cliente
Artículo nif: {id}: string
código: {id}: string dir: {1..1}: string
0..* 0..* nombre: {1..1}:
descrip: {1..1}: string
precio: {1..1}: real ape1: string
ape2: string
nom_pro: string
ERROR Albarán
Nº: {id}: integer
fecha: {1..1}: date
cant: {1..1}: integer

• Identificador NO, identificación SÍ:
• Identificación:
• Por cada conjunto de clases con cardinalidad máxima 1 hay una
posible identificación.
• Si no hay, todas las clases participan en la identificación.

• Identificación: Asociación binaria M:M
Proveedor Pieza
dni: {id}: string código: {id}: string
nombre: {1..1}:string
0..* Sum 0..* desc: {1..1}: string
dirección: {1..1}: string marca: {1..1}: string
Para distinguir una ocurrencia de Sum de otra se necesita el

dni del proveedor y el código de la pieza.

• Identificación: Asociación binaria 1:M
Departamento Empleado
código: {id}: string dni: {id}: string
nombre: {1..1}: string
1..1 0..* nombre: {1..1}: string
ubicación: {1..1}: string Pertenece edad: {1..1}: number
Para distinguir una ocurrencia de Pertenece de otra basta

con el dni del empleado.

• Identificación: Asociación binaria 1:1
Departamento Empleado
0..1 1..1 nombre: {1..1}: string
ubicación: {1..1}: string Jefe edad: {1..1}: number
Para distinguir una ocurrencia de Jefe de otra se necesita el

dni del empleado o el código de la departamento. Hay dos
formas posibles de identificación.

• Identificación: Asociación binaria reflexiva M:M
Pieza
código: {id}: string
compuesta componente
desc: {1..1}: string
0..* marca: {1..1}: string 0..*
Composición
Para distinguir una ocurrencia de Composición de otra son

necesarios dos códigos de pieza.

• Identificación: Asociación binaria reflexiva 1:M
Empleado
dni: {id}: string
jefe subordinado
1
0..1 edad: {1..1}: entero 0..*
Jerarquía
Para distinguir una ocurrencia de Jerarquía de otra basta

con el dni de un empleado.

• Identificación: Asociación binaria reflexiva 1:1
Persona
cónyuge A dni: {id}: string cónyuge B

0..1 edad: {1..1}: number 0..1
Matrimonio
Para distinguir una ocurrencia de Matrimonio de otra basta

con el dni de una de las dos personas casadas.

• Identificación: Asociación ternaria M:M:M
Proveedor Pieza
Suministra
0..* 0..* desc: {1..1}: string
0..*
Proyecto
denominación: {1..1}: string
lugar: {1..1}: string
Para distinguir una ocurrencia de Suministra de otra se

necesita el dni del proveedor, el código de la pieza y el
código del proyecto.

• Identificación: Asociación ternaria 1:M:M
Proveedor Pieza
Suministra
dni: {id}: string 0..* 0..* código: {id}: string
nombre: {1..1}: string desc: {1..1}: string
0..1
Proyecto
Para distinguir una ocurrencia de Suministra de otra se

necesita el dni del proveedor y el código de la pieza.

• Identificación: Asociación ternaria 1:1:M
Máquina Usar Trabajador
0..1 0..1 nom: {1..1}: string
descrip : {1..1}: string
precio : {0..1}: real dir: {1..1}: string
0..*
Proyecto
Para distinguir una ocurrencia de Usar de otra se necesita el

dni del trabajador y el código de la proyecto o el código del
proyecto y el código de la máqiuna.

• Clase-asociación: propiedades y corrección
Socio
Ejemplar nif: {id}: string
signat: {id}: string dir: {1..1}: string
0..* 0..* nombre: {1..1}:
título: {1..1}: string
editorial: {1..1}: string ape1: string
ape2: string
nom_pro: string
Préstamo Préstamo ha de modelar

préstamo: {1..1}: date el préstamo histórico en
devolución: {1..1}: date la biblioteca
• Identificador NO, identificación SÍ


Ejemplar Socio
e1 s1
21/1/19, 10/2/19
e2 s2
e3 s3
15/1/19, 23/1/19 Si la realidad a modelar es
e4 s4 ésa (un socio puede tomar
prestado el mismo ejemplar
… …
varias veces), el diseño es
1/3/19, 15/3/19
em sn incorrecto. Sólo se puede
tener información de un
préstamo de un mismo libro
a un mismo socio

Diseño incorrecto Solución 1
Cada préstamo puede tener varios

valores en el atributo cuándo. Cada
valor es un par de fechas.

Ejemplar Socio
e1 s1
21/1/18, 10/2/18
e2 s2
e3 s3
e4 s4
{(15/1/19, 23/1/19),
… (1/3/19, 15/3/19)}
…
em sn

Diseño incorrecto Solución 2

• Clase-asociación: aspectos importantes a considerar:
• La identificación viene dada por la identificación de la asociación.
• Estudiar:
• Equivalencia con asociaciones de mayor grado.
• Propiedades en las clases asociadas.

• Clase-asociación: Ejemplos
• Empleados que pertenecen a departamentos y se asignan a
proyectos.
• Personas que se casan en juzgados.
• Accidentes, vehículos involucrados y personas que los conducían.

• Clase-asociación: Ejemplos (empleado-departamento)
Empleado
Departamento
dni: {id}: string
0..* 0..1 nombre: {id}: string
salario: {0..1}: number ubicación: {1..1}: string
Pertenece
fecha: {1..1}: date
0..*
Proyecto Asignado
número: {id}: string nivel: {1..1}: number
1..1
presup: {0..1}: number

• Clase-asociación: Ejemplos (Matrimonio)
Persona
0..1 dni: {id}: string 0..1
dir: {1..1}: string
Cónyuge A Cónyuge B
Juzgado
número: {id}: string
Matrimonio
1..1 0..*
dir: {1..1}: string fecha: {1..1}: date
titular: {0..1}: string Celebra

• Clase-asociación: Ejemplos (Seguros)
Persona
dni: {id}: string
dir: {1..1}: string
0..1
Conducía
Participa
0..*
daño: {1..1}: string
Vehículo Accidente
mat: {id}: string número: {id}: number
clase: {1..1}: string fecha: {1..1}: date
modelo: {0..1}: string hora: {1..1}: string
1..* 0..*
Lugar: {1..1}: string

• Clase-asociación: Equivalencia con asociaciones de mayor
grado
• En ocasiones hay diagramas equivalentes.
• Se debe elegir al diagrama más simple y legible.

• Clase-asociación: Asociación de grado superior
Suministra
cantidad: {1..1}: number
Proveedor Pieza
0..* 0..* desc: {1..1}: string
0..*
Proyecto

Proveedor Pieza
0..* 0..*
Vende
Diagramas
equivalentes Suministra
0..*
Proyecto
1..* código: {id}: string

Proveedor Pieza
dni: {id}: string Vende código: {id}: string
*0..* 1..*
Suministra
0..*
*
*0..*
Proyecto
denominación: {1..1}: string Diagramas
equivalentes

Diagramas
Pieza
equivalentes
marca: {1..1}: string
Proveedor 0..**
Suministra
dni: {id}: string 1..* 0..**
dirección: {1..1}: string
0..*
*
Proyecto
Vende
cantidad: {1..1}: number denominación: {1..1}: string

• Clase-asociación: Equivalencia con asociaciones de mayor
grado:
• ¿Cuándo no es posible realizar la transformación?:
• Clase-asociación tiene atributos propios.
• Clase-asociación tiene una asociación en la que no está obligada
a participar

• Clase-asociación: Asociación de grado superior (imposible)
• Clase-asociación tiene atributos propios
Proveedor Pieza
0..* 0..* desc: {1..1}: string
Vende
No hay ternaria
precio: {1..1}: number
equivalente
0..*
Suministra
cantidad: {1..1}: number Proyecto

• Clase-asociación: Asociación de grado superior (imposible)
• Clase-asociación tiene una asociación en la que no está obligada
a participar
Proveedor Pieza
Vende
0..*
Suministra
cantidad: {1..1}: number Proyecto
No hay ternaria denominación: {1..1}: string
equivalente
• Motivos:
• Objetos con estructura diferenciada.
• Objetos con propiedades asociativas distintas.
• Representación de estados (dinámica).
• Aspectos avanzados:
• Especialización múltiple.
• Herencia múltiple.
• Objetos con estructura diferenciada:
• Optimiza la representación.
• Permite expresar más propiedades y con más precisión.
• Ejemplo:
• La empresa desea mantener información sobre los empleados
dni, nombre y teléfono.
• Existen diferentes tipos de empleados: administrativos,
técnicos e ingenieros. De los primeros se desea conocer su
velocidad tipográfica pulsaciones, de los segundos su
especialidad y de los terceros es obligatorio saber su carrera
Empleado
dni: {id}: string
teléfono: {0..1}: string
título: {0..1}: string
pulsa: {0..1}: number
especial: {0..1}: string
• Problemas:
• Representación de la especialización oculta.
• Representación de la especialización por valor de propiedades.
• Imposibilidad de expresar restricciones sobre la especialización.
• Imposibilidad de expresar cardinalidades mínimas sobre título,
pulsa y especial.
Empleado <<enumeration>>
dni: {id}: string
nombre: {1..1}: string tipo_empleado
teléfono: {0..1}: string administrativo
título: {0..1}: string ingeniero
pulsa: {0..1}: number técnico
especial: {0..1}: string
tipo: tipo_empleado
• Problemas:
• Representación de la especialización por valor de una propiedad tipo.
• Imposibilidad de expresar restricción de solapamiento de la
especialización.
• Representación inexacta del valor de las propiedades de las clases
especializadas y el valor de la propiedad tipo.
• Imposibilidad de expresar cardinalidades mínimas sobre título, pulsa y
especial.
Empleado
dni: {id}: string
{total, disjunta}
Administrativo Ingeniero Técnico

pulsa: {1..1}: number título: {1..1}: string especial: {1..1}: string
• Objetos con propiedades asociativas distintas:
• Expresa con más precisión las asociaciones
• Permite expresar más propiedades en las asociaciones y con
más precisión
• Ejemplo:
• Se desea mantener información sobre máquinas expendedoras:
nº serie, descripción y peso.
• Las máquinas que no están en reparación se encuentran
ubicadas en empresas. Es necesario saber la fecha desde la cual
se encuentran en dichas empresas.
• Las que se encuentran en reparación tienen asignado un taller de
reparación.
Ubicada
fecha: {1..1}: date Empresa
Máquina 0..1
nºserie: {id}: string 0..*
peso: {0..1}: number
desc: {o..1}: string {una o la otra, no las dos}
0..*
Taller
0..1
• Problemas:
• Representación de la especialización oculta.
• Representación de la especialización por la forma de asociarse.
• Imposibilidad de expresar propiedades de la especialización.
Máquina
nºserie: {id}: string
desc: {0..1}: string Ubicada
fecha: {1..1}: date
{total, disjunta}
En_reparación En_Uso
0..* 0..*
1..1
Reparar 1..1
Taller Empresa
• Representación de estados (dinámica) :
• Representación incorrecta de los estados.
• Permite expresar información de cada estado pero no las
transiciones.
• Ejemplo:
• Representar los estados civiles de un ciudadano español.
Ciudadano
dni: {id}: string
Matrimonio nombre: {1..1}: string
dir: {1..1}: string
fecha: {1..1}: date
1..1
Casado
1..1 {Parcial, disjunta}
Separado Viudo
fecha: date fecha: {1..1}: date
motivo: {1..1}: string
Divorciado
fecha: {1..1}: date
• Representación incorrecta de los estados.
• Permite expresar información de cada estado pero no las
transiciones.
• Problemas:
• La transición entre estados no se representa bien.
• Las propiedades asociadas a las transiciones no se pueden
representar (OCL*).
* OCL: Object Constraint Language es un lenguaje para la descripción formal de

expresiones en los modelos UML.
• Equivalencia con diagrama de estados: SECUENCIA
El cambio de estado implica

herencia estructural y
persistencia existencial
C
• Equivalencia con diagrama de estados: CICLOS
Problemas semánticos
C
• Representación evolutiva histórica:
• Sólo se puede expresar parte de esa evolución.
• La información histórica requiere representación explícita.
• Representación del cambio de estado:

• No se puede representar.
• Especialización múltiple:
• Es posible especializar una clase por diversos motivos.
• Cada especialización expresa aspectos semánticos distintos.
• Ejemplo:
• La empresa desea mantener información sobre los empleados
dni, nombre y teléfono.
• Existen diferentes tipos de empleados: administrativos,
técnicos e ingenieros. De los primeros …
• Además algunos empleados son gerentes que pueden dirigir
proyectos.
• Por otro lado cualquier empleado de la empresa puede trabajar
a tiempo completo o por horas. En el primer caso es necesario
almacenar el salario mensual y en el segundo las horas y el
precio por hora.
• Especialización múltiple:
Empleado
dni: {id}: string
{parcial, disjunta} {total, disjunta}
Administrativo Ingeniero Técnico Gerente Completo Parcial

pulsa:{1..1} título:{1..1} espec:{1..1} salario:{1..1} tarifa:{1..1}
horas:{1..1}
1..1
Dirige
0..*
Proyecto
• Herencia múltiple:
• Una clase especializada de más de una clase.
• Retícula de especialización → Raíz única
• Ejemplo:
• Las personas vinculadas a la universidad pueden ser
empleados, exalumnos o estudiantes.
• De los exalumnos se desea saber qué carrera/s acabaron.
• Los empleados pueden ser o administrativos, profesores o
becarios. De los primeros se desea saber el puesto y de los
segundo el rango.
• Los estudiantes pueden ser de licenciatura, de postgrado o
becarios. De los primeros se desea saber la carrera que están
realizando, de los segundo el programa de doctorado y de los
terceros el departamento asignado.
• Herencia múltiple: Empleado
dni: {id}: string
{total, solapada}
Personal Exalumno Estudiante

salario: {1..1}: number título: {1..1}: string fecha_ing:{1..1}: date
{total, disjunta} {total, disjunta}
PAS PDI Becario Postgrado Egresado

puesto:{1..1} cat:{1..1} beca:{1..1} doct:{1..1} carrera:{1..1}
Propiedades de un becario: {dni, nombre, teléfono, salario, fecha_ing, beca}

Identificación de un becario: {dni}
2.3. Aspectos dinámicos

• Dinamismo en el diagrama de clases del UML:
• Asociación
• Clase débil
• Asociación con cardinalidad mínima >0: restricción de existencia
• Atributos requeridos
• Generalización/Especialización
• Otras propiedades dinámicas

• Asociación
• Concepto dependiente:
• Una ocurrencia de la asociación tiene que asociar objetos de
todas las clases que toman parte.
• Operatividad limitada:
• Inserción de ocurrencias (Vende).
• Borrado de objetos de las clases que participan.
Proveedor Pieza
0..* Vende 0..*
Inserción en Vende: debe existir el Proveedor y la Pieza

Borrado en Proveedor o en Pieza: ¿qué hacer con las ocurrencias de Vende
en las que participan?

• Clase débil
• Clase dependiente:
• Un objeto de la clase débil necesita de la existencia previa de los
objetos con los que se asocia y que requiere para su identificación.
• Inserción de objetos de la clase débil (Ciudad).
• Borrado de objetos de la clase usada para la identificación (País).
País Ciudad
nombre: {id}: string
nombre: {id}: string {id} 0..* población: {1..1}: number
población: {1..1}: number
extensión: {1..1}: number
extensión: {1..1}: number Pertenece Ubicación: {1..1}: string
Inserción en Ciudad: hay que insertar en Pertenece

Borrado País: hay que borrar en Ciudad
Borrado en Ciudad: hay que borrar en Pertenece

• Asociación con cardinalidad mínima >0: Rest. Existencia
• Clase dependiente: la clase sufre esta restricción.
• Un objeto de la clase tiene que estar asociada con la otra.
• Inserción de objetos de la clase con la rest. Existencia (Departamento).
• Borrado de ocurrencias de la asociación (Pertenece).
Empleado Departamento
1..* 0..1
Pertenece
Inserción en Departamento: hay que insertar en Pertenece

Borrado en Pertenece: comprobar que el departamento participa en otra
ocurrencia de Pertenece

• Generalización/Especialización
• Las clases especializadas son dependientes de la clase general
• Inserción sobre clase general (Empleado).
• Borrado sobre la clase general (Empleado).
• Especialización/Desespecialización (Administrativo, Técnico,
Ingeniero)
Empleado
dni: {id}: string
{ , }


Empleado
dni: {id}: string
{T, D}

Inserción en Empleado: insertar en Administrativo/Ingeniero/Técnico (sólo en

una)
Borrar en Empleado: borrar en Administrativo/Ingeniero/Técnico
Insertar en Administrativo/Ingeniero/Técnico: no posible
Borrar en Administrativo/Ingeniero/Técnico: borrar el Empleado o insertarlo
como una de las otras dos
especializaciones

Empleado
dni: {id}: string
{T, S}

Inserción en Empleado: insertar en Administrativo/Ingeniero/Técnico (en una

o en varias)
Inserción en Administrativo/Ingeniero/Técnico: debe existir el empleado.
Borrar en Administrativo/Ingeniero/Técnico: borrar el Empleado si es su única
especialización o insertarlo como
una de las otras dos
especializaciones

Empleado
dni: {id}: string
{P, D}

Insertar en Administrativo/Ingeniero/Técnico: sólo si el empleado no está ya

especializado

Empleado
dni: {id}: string
{P, S}


Inserción en Administrativo/Ingeniero/Técnico: debe existir el empleado.

• Otras propiedades dinámicas
• Restricciones dinámicas: de transición, multiestado, etc.
• Propiedades sobre las operaciones.
Empleado
dni: {id}: string
sueldo: {0..1}: number
El sueldo de los empleados no puede

incrementarse en más de un 20%
Índice
del UML
diagrama de clases del UML
3. Refinamiento y verificación de diagramas de clases
1. Atributos agregables
2. Subconjuntos de objetos de una clase
3. Eliminación de asociaciones redundantes
4. Eliminación de asociaciones redundantes por transitividad
5. Elegir asociaciones del menor grado posible
6. Clases-asociaciones definidas correctamente
7. Asociaciones enmascaradas
8. Modelado de objetos complejos
4. Casos
3.1. Atributos agregables

• Existencia de atributos agregables
• Clase nueva con sentido existencial
Proyecto
provincia: {0..1}: string
ciudad: {0..1}: string
Ciudad Proyecto
provincia: {1..1}: string 0..1 0..* código: {id}: string
nombre: {id}: string nombre: {1..1}: string
Está
3.2. Subconjuntos de objetos de una clase

• Existencia de subconjuntos de objetos de una clase
diferenciables
Cliente
dni: {id}: string
Empresa
nombre: {1..1}: string 0..* 0..1 cif: {id}: string
país: {0..*}: string nombre: {1..1}: string
guía: {0..1}: string
Pertenece
Cliente
dni: {id}: string
{total,solapada}
Turista Viajante Empresa

0..* 1..1 cif: {id}: string
guía: {0..1}: string país: {0..*}: string
Pertenece nombre: {1..1}: string
3.3. Eliminación de asociaciones redundantes

• Misma forma y misma semántica
Proveedor Pieza
0..* Vende 0..*
dir: {0..1}: string color: {0..1}: string
0..* Suministra 0..*
El significado de las relaciones

Vende y Suministra es el mismo
(sobra una de las dos)
3.3. Eliminación de asociaciones redundantes

• Misma forma y distinta semántica
Profesor Departamento
0..* Pertenece 0..1 código: {id}: string
dni: {id}: string
nombre: {1..1}: string nombre: {1..1}: string
dir: {0..1}: string teléfono: {0..1}: string
0..* Dirige 0..1
El significado de las relaciones

Pertenece y Dirige es distinto
3.4. Eliminación de asociaciones redundantes por

transitividad
• Realizar la composición y la semántica es equivalente
Ciudad Provincia
nombre: {id}: string 0..* Está en 1..1 código: {id}: string 0..*
ayunt.: {1..1}: string nombre: {1..1}: string
0..*
Pertenece
Comunidad Aut.
Es de 1..1 código: {id}: string
nombre: {1..1}: string 1..1
Toda ciudad es de la comunidad autónoma a la que

pertenece la provincia en la que está la ciudad
3.4. Eliminación de asociaciones redundantes por

transitividad
• Realizar la composición y la semántica es equivalente
Ciudad Provincia
nombre: {id}: string 0..* Está en 1..1 código: {id}: string 0..*
ayunt.: {1..1}: string nombre: {1..1}: string
Pertenece
La asociación Es de se deriva de
Comunidad Aut.
Está en y Pertenece
nombre: {1..1}: string 1..1
3.5. Elegir asociaciones del menor grado posible
Alumno Profesor
exp: {id}: string 0..* dni: {id}: string
Docencia 0..1
nombre.: {1..1}: string nombre: {1..1}: string
edad: {1..1}: number
0..*
Asignatura
Si cada asignatura es impartida únicamente por un profesor, el

diagrama es incorrecto.
3.5. Elegir asociaciones del menor grado posible
Alumno Profesor
exp: {id}: string dni: {id}: string
edad: {1..1}: number
0..*
0..1
Matrícula Imparte
Asignatura
0..* 0..*
3.6. Clases-asociaciones definidas correctamente

Visita
fecha: {1..1}: date
Médico diagnos: {0..1}: string Paciente
0..* 0..*
nºcol: {id}: string nss: {id}: string
Visitas
datos: {1..*}:
fecha: {1..1}: date
diagnos: {0..1}: string
Médico Paciente
0..* 0..*
3.6. Clases-asociaciones definidas correctamente

Visita
fecha: {1..1}: date
Médico diagnos: {0..1}: string Paciente
0..* 0..*
Visita
0..* fecha: {id}: date 0..*
diagnos: {0..1}: string
Pasa Va
Médico Paciente
nombre.: {1..1}: string {id} {id} nombre: {1..1}: string
3.7. Asociaciones enmascaradas

• Enmascaramiento en una clase
Proveedor Pieza Pedido
dni: {id}: string código: {id}: string código: {id}: string
nombre: {1..1}: string desc: {1..1}: string dni: {id}: string
dir: {0..1}: string color: {0..1}: string precio: {1..1}: number
Pedido
Proveedor precio: {1..1}: number Pieza
dir: {0..1}: string color: {0..1}: string
3.7. Asociaciones enmascaradas

• Enmascaramiento en atributos
Profesor
Departamento
dni: {id}: string
dir: {0..1}: string
cod_dep: {0..1}: string
Profesor Departamento
dni: {id}: string 0..* Pertenece 0..1 código: {id}: string
nombre: {1..1}: string nombre: {1..1}: string
dir: {0..1}: string teléfono: {0..1}: string
3.8. Modelado de objetos complejos

• Asociaciones binarias reflexivas: propiedades y
representación

• Asociaciones binarias reflexivas:
Pieza
compuesta código: {id}: string componente
0..* 0..*
Forma_parte

• Asociaciones binarias reflexivas: r1
C
r2
• Propiedades que no se pueden represeentar:
• Reflexiva: c  C, c A c A
• Irreflexiva: c  C, c A c
• Simétrica: c1,c2  C, c1 A c2  c2 A c1
• Antisimétrica: c1,c2  C, (c1 A c2)  (c2 A c1)  c1 = c2
• Transitiva: c1,c2,c3  C, (c1 A c2)  (c2 A c3)  (c1 A c3)
• Intransitiva: c1,c2,c3  C, (c1 A c2)  (c2 A c3)  (c1 A c3)
• Acíclica
• …

• Propiedades que no se expresan:
• Acíclica
• Transitiva
• Irreflexiva
Pieza
compuesta componente
0..* 0..*
Forma_parte

• Propiedades que no se expresan:
• Irreflexiva
• Simétrica
Persona
cónyuge A cónyuge B
0..1 0..1
Matrimonio

Empleado
dni: {id}: string subordinado
jefe
0..1 edad: {1..1}: entero 0..*
Jerarquía
• ¿La cardinalidad mínima de subordinado podría ser 1?

• Propiedades:
• Antisimétrica
• Irreflexiva
4. Casos
• Ver (en la carpeta del Poliformat Teoría→Tema 6→ Casos):
• Casi 1: Servicio de mantenimiento
• Caso 2: Agencia fotográfica
• Caso 3: empresa VACB

Tema 6

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 6

Cargado por

Copyright:

Formatos disponibles

Diseño y Gestión de

Profesoras: Laura Mota y Mª José Vicent

1. Diseño conceptual con UML

• Se incidirá en dos aspectos principalmente:

1. Diseño conceptual con UML

Técnicas: representan cómo llevar a cabo cada una de las

Modelos: instrumentos que se emplean para representar

1. Diseño conceptual con UML

1. Diseño conceptual con UML

• Los modelos de datos se diferencian entre sí en cuanto a

1. Diseño conceptual con UML

Diagrama Clases UML

1.1. Diagrama de clases

Mundo real Modelo de la realidad

Representa el hecho de que las distintas ocurrencias de

Clase No puede haber dos

Un identificador es un conjunto de atributos con restricción

1.4. Asociación: asociación binaria

1.4. Asociación: asociación binaria

Cada ocurrencia de A se Cada ocurrencia de B se

1.4. Asociación: asociación binaria

Cuando la cardinalidad mínima de una clase es

1.4. Asociación: asociación binaria

1.4. Asociación: Clase-Asociación (presencia de

1.4. Asociación: Clase-Asociación (presencia de

1.4. Asociación: Clase-Asociación (asociación

El diagrama representa la información sobre discos y

1.4. Asociación: Clase-Asociación (asociación

1.4. Asociación: Asociaciones n-arias

• Cada ocurrencia del conjunto de clases A puede estar

1.4. Asociación: Asociaciones n-arias

• Dada relación n-aria, en el diagrama de clases sólo se pueden

1.4. Asociación: Asociaciones n-arias (ejemplo)

Docencia (Asignatura (amin, amax) , Profesor-Grupo (0..*))

Docencia (Grupo (gmin, gmax), Profesor-Asignatura (0..*))

1.5. Clases débiles

1.5. Clases débiles

1.5. Clases débiles (ejemplo)

1.5. Clases débiles (ejemplo)

Cuando se detecta que entre distintas clases definidas en el

Todas las subclases de una clase tienen, además de sus

Total: toda ocurrencia de la clase G se especializa en C1, C2 o C3.

Disjunta: no puede haber ocurrencias de G que estén especializadas a la

Las clases especializadas no tienen identificador.

2.1. Asociación y clase-asociación

2.1. Asociación y clase-asociación

* Esto implica que si a una clase-asociación se le especifican atributos con la

2.1. Asociación y clase-asociación

2.1. Asociación y clase-asociación

2.1. Asociación y clase-asociación

Para distinguir una ocurrencia de Sum de otra se necesita el

2.1. Asociación y clase-asociación

Para distinguir una ocurrencia de Pertenece de otra basta

2.1. Asociación y clase-asociación

Para distinguir una ocurrencia de Jefe de otra se necesita el

2.1. Asociación y clase-asociación

Para distinguir una ocurrencia de Composición de otra son

2.1. Asociación y clase-asociación

Para distinguir una ocurrencia de Jerarquía de otra basta

2.1. Asociación y clase-asociación

cónyuge A dni: {id}: string cónyuge B

Para distinguir una ocurrencia de Matrimonio de otra basta

2.1. Asociación y clase-asociación