Modelamiento de Base de Datos Con UML

Post on 01-Feb-2016

37 views 2 download

description

Ejemplo de modelamiento de Base de datos con UML

Transcript of Modelamiento de Base de Datos Con UML

MODELAMIENTO DE BASE DE DATOS USANDO UML

Expositor :

Daniel Gamarra Moreno

Modelamiento de base de datos usando UML

• Tecnología de objetos • Lenguaje Unificado de Modelamiento

(UML) • ¿Por qué BDOO? • Diagrama de Clases • Traducción a tablas

MODELAMIENTO DE BASE DE DATOS USANDO UML

Gracias ...

Objeto

• Cualquier ente real o conceptual que posea características y comportamiento propios, únicos e inconfundibles.

Ambulancia Julia Flores

Reloj despertador Empresa

Clase

• Conjunto de objetos con características y comportamientos similares. Persona

Vehículo Edificio

Clases y subclases

• Clase – Es la abstracción de un objeto, un conjunto de ideas, no es

algo real. Por Ejemplo: • Al referirnos al objeto reloj, construimos en nuestro

cerebro una abstracción que tendrán: Manecillas, la escala horaria, un color, etc.

• Subclases – Es una clase formada a partir de otra; por ejemplo: reloj de

pared, reloj despertador.

Herencia

• Como los objetos se agrupan en clases y subclase, los objetos descendientes heredan características de los objetos antepasados.

• Para construir un nuevo objeto no es necesario partir desde el inicio, sino el nuevo objeto puede tomar las características de sus antepasados y puede definir sus propias características.

Polimorfismo

• Tomando como referencia los vehículos de transporte al dar una mensaje de dar vuelta a la derecha cada objeto activará mecanismos diferentes para cumplir la orden, a esta propiedad se le conoce como POLIMORFISMO.

• POLIMORFISMO es la capacidad que tienen los objetos de reaccionar de una manera distinta a una misma orden.

Encapsulamiento

• Encapsulamiento es el proceso por el cual se combinan datos y procesos al que van ser sometidos los datos.

UML

• Es un lenguaje de modelamiento, no un método. Sucesor de la ola de OOA&D que aparecen entre fines de los 80´s y principios de los 90´s.

Análisis y Diseño =

Greddy Booch

Notación y Semántica =

James Rumbaugh(OMT)

Procesos =

Ivar Jacobson (Objectory)

Lenguaje de

Modelación

Proceso

Metodología

+ =

Notación Pasos del Diseño

OOA&D

Rumbaugh Jacobson

Meyer

Harel

Wirfs-Brock Fusion

Embly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre y Post condiciones

Máquinas de estado

Responsabilidades

Descripción de operaciones, numeración de mensajes

Singleton clases

Marcos de trabajo, patrones, notas

Ciclo de vida de objetos

Clasificación

UML toma lo mejor de varios métodos

Sep ‘97 UML 1.1 Ene ‘97 UML 1.0 Jun ‘96 UML 0.9 Oct ‘95 Método Unificado 0.8

. . . Breve historia del UML

Microsoft Oracle IBM, HP Etc.

Ivar Jacobson se une a Rational en otoño ‘95

James Rumbaugh se une a Rational en Oct ‘94 OMT Booch

Use Case (OOSE)

Otros métodos

Moderador
Notas de la presentación
Durante 1996, los autores del UML invitaron a la comunidad de desarrolladores a realizar sus aportes.��Mientras tanto, la industria del software quería definir un lenguaje de modelamiento estándar.��En junio de 1995, el OMG reunió a todos metodologistas importantes dando lugar al primer acuerdo mundial de buscar estándares de la metodología, bajo la batuta del OMG.��Durante 1996, varias organizaciones consideraron UML como estratégico a su negocio. Racional estableció el consorcio de los socios de UML para una definición de UML 1,0. Entre ellos:��Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, y Unisys.��Esta versión se sometió al OMG para su aceptación como nuevo estándar en enero de 1997 y se unieron ObjecTime de IBM, Platinium Technology, Ptech, Taskon, Reich Technology y Softeam quienes produjeron la versión 1,1 del UML la cual fue adoptada como estándar a fines de 1997.

1997 (Adoptada por OMG) 1998 (revisión editorial sin cambios significativos) 1999 (revisión menor públicamente disponible) 2000 (planificada una revisión menor) 2001 (planificada una revisión menor) 2002 (planificada una revisión mayor)

Versiones del UML <<document>>

UML 1.1

<<document>> UML 1.2

<<document>> UML 1.5

<<document>> UML 1.3

<<document>> UML 2.0

<<document>> UML 1.4

<<document>> ISO Publica

especificación

Vistas de un modelo “Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

Vistalógica

Vista deprocesos

Vista dedespliegue

Vista deimplementación

Vista de requerimientos

Diagrama de Clases

Diagrama de Objetos

Diagrama de Estado

Diagrama de Secuencia

Diagrama de Colaboración

Diagrama de Actividad

Diagrama de Casos de Uso

Diagrama de Componentes

Diagrama de Despliegue

“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

Vistalógica

Vista deprocesos

Vista dedespliegue

Vista deimplementación

Vista de requerimientos

Diagrama de Clases

Diagrama de Objetos

Diagrama de Estado

Diagrama de Secuencia

Diagrama de Colaboración

Diagrama de Actividad

Diagrama de Casos de Uso

Diagrama de Componentes

Diagrama de Despliegue

Moderador
Notas de la presentación
VISTA DE REQUERIMIENTOS Es el enlace de las otras vistas Describe aspectos de comportamiento no de construccion Muestra la funcionalidad del sistema como es percibida por los actores externos Utiliza los diagramas de casos de uso y diagramas de actividad VISTA LOGICA Muestra el diseño de la funcionalidad Muestra la estructura (elementos que lo integran) mediante diagramas de clases y objetos Muestra la interaccion de los elementos mediante diagramas de Estado, Secuencia, Colaboracion y Actividad VISTA DE COMPONENTES O IMPLEMENTACION La vista logica era solo una abstraccion La vista de componentes muestran los archivos (ejecutables, fuentes, librerias)en los que se traducen los elementos logicos Muestra la dependencia entre estos elementos Consiste en diagramas de componentes VISTA DE DESPLIEGUE O IMPLANTACION Muestra como el software se despliega en el hardware Indica donde se ubica el software y como se comunican entre si Consiste en diagramas de despliegue VISTA DE PROCESOS O DE CONCURRENCIA combinacion de vista logica, componentes e implantacion Muestra el manejo de la concurrencia de los procesos (comunicacion y sincronizacion, hilos de control, procesos paralelos) Es importante para sistemas distribuidos y de tiempo real Consiste en diagramas de componentes y despliegue, y diagramas de estado, secuencia, colaboracion y actividad.

La necesidad de BDOO

• La Fabricación Integrada por Computadora (en el proceso de integración).

• Lo sistemas de automatización de oficina (manejo de datos Hypermedia)

• En la fabricación de un avión requiere el rastreo de millones de partes interdependientes que pueden ser ensambladas en diferentes configuraciones.

¿Por que no las base de datos relacionales?

• Las aplicaciones anteriores son caracterizadas por el manejo de información muy compleja eficientemente.

• Claramente la tecnología de las bases de datos relacionales a fracasado para el manejo de sistemas de información complejos.

Características de las BDOO

Tres enfoques de construcción de BDOO

• El Primero.- se puede utilizar el código actual altamente complejo de los sistemas de administración de las bases de datos, de modo que una BDOO se implante más rápido sin tener que iniciar de cero.

• El Segundo: considera a la BDOO como una extensión de la tecnología de las bases de datos por relación.

Tres enfoques de construcción de BDOO…

• El Tercero: reflexiona sobre la arquitectura de los sistemas de bases de datos y produce una nueva arquitectura optimizada, que cumple las necesidades de la tecnología OO.

Diagramas de clases

– Un diagrama de clases muestra el conjunto de clases y objetos importantes que hacen parte de un sistema, junto con las relaciones existentes entre estas clases y objetos

– Clase • El mundo real puede ser visto desde abstracciones

diferentes (subjetividad), cuyos mecanismos de abstracción son:

– Clasificación / Instanciación – Composición / Descomposición – Agrupación / Individualización – Especialización / Generalización

Clase • Atributo

– Identifican las características propias de cada clase.

– visibilidad nombre : tipo = valor-por-omisión {cadena de propiedades}

• Operaciones – Las operaciones que reconoce un

objeto se encuentran especificadas e implementadas en su clase respectiva.

– visibilidad nombre(lista-parámetros) : tipo {cadena-propiedades}

Persona

nombre:stringedad:integer

cambieNombre(nuevoNombre:string)camineHacia (punto:Coordenada)

edad ():integer

print ()print (x,y:integer)

Objeto

• Un objeto es la instancia de una clase.

Persona

Nombre:stringFecha de nacimiento:fecha

Persona

Luis Poma Rojas12 de enero de 1980

Asociaciones • Las asociaciones son el medio que establece las

relaciones entre los objetos, y entre las clases. • Especificación de multiplicidad o cardinalidad 1 Uno y sólo uno

0..1 Cero o uno

M..N De M a N (enteros naturales)

* De cero a varios

0..* De cero a varios

1..* De uno a varios

Asociación n-aria

Equipo

Nombre equipoDirección sede

Persona

AñoDenominación

Persona

Nombre personaDirección

GanaPierde

Lanzador

Roles

• Un rol es un extremo de una asociación. En una asociación binaria, se tienen dos posibles roles, o papeles que juegan las entidades relacionadas.

CompañiaPersona1..*1..*

EmpleadorEmpleado Trabaja para

11..*

Jefe

Subordinado

11..*

1..*1..*

Clase de asociación

Asociación cualificada

• Un objeto y un cualificador identifican a un único objeto en la asociación (forma una clave compuesta). Reduce la multiplicidad del rol opuesto. La nueva multiplicidad es 0 ó 1

Aerolínea Viajero nro_viajero * 0..1

Tablero Ajedrez

fila columna

1 1 Cuadro

Ordenamiento

– En la mayoría de las asociaciones que involucran más de un elemento, el orden de los mismos no es importante. Sin embargo, en algunas ocasiones el orden es importante.

Tarjeta Puerto

1..*1

{orden}

1..*1

Agregación y composición

PalabraOración

1..*

Parrafo

1..*

Texto

1..*1..* 1..* 1..*

Monitor CPU Teclado

Computador

Generalización

• La relación de generalización denota una relación de herencia entre clases.

Terrestre

Medio de Transporte

Marino Aéreo

Camión Moto Velero Aeroplano Avión Helicóptero

Dependencia

• Indica que cambiar el elemento independiente puede requerir cambios en los dependientes.

Caso para una librería

• Las novelas se clasifican como de ciencia ficción, romance, misterio, juveniles y policiales. Los libros técnicos se clasifican como de ingeniería, ciencias naturales o ciencias sociales. Cada libro tiene un título, uno o más autores, una editorial, un año de edición y un formato (tapas duras o edición económica). Los libros técnicos tienen además un código ISBN y capítulos, los que tratan una o más materias.

• La librería obtiene los libros por medio de proveedores que representan a una o más editoriales. De cada libro se tiene un stock (que puede ser cero). Al venderse un libro, el stock se actualiza. Si un cliente requiere un libro cuyo stock es cero, se puede realizar un encargo por parte del cliente. Esto significa que se pide el libro a un proveedor de la editorial del libro.

Diagrama de clases: Librería

Visibilidad

+ visibilidad publica. Los atributos de la parte pública son visibles a todas las clases (se pierde la encapsulamiento).

# visibilidad protegida. Los atributos de la parte protegida están visibles para los friends y para las clases derivadas de la original.

- visibilidad privada. es el más fuerte. Esta parte es totalmente invisible (excepto para los “friends” en terminología C++).

Cadena de propiedades (atributos)

• Changeable (Modificable) • AddOnly (Añadir solamente) • Frozen (Congelado)

Cadena de propiedades (Operaciones)

• Query. – No modifica el estado del sistema.

• Concurrency = nombre. – Donde nombre puede ser: sequential (secuencial),

guarded (defendido), concurrent (coexistente). • Abastract.

– No implementado.

Conversión del diagrama de clases a tablas

• Características de los RDBMS – Cada atributo debe asignársele un

dominio. – Una clave primaria. – Una clave candidata. – La integridad referencial. – Una clave foránea (externa).

Ejemplo

• Id_persona Clave primaria de persona.

• Id_empresa Clave primaria de empresa.

• Id_empresa Clave externa dentro de la tabla persona.

Id_persona Nom_persona Id_empresa

001 Juan Garcia 1001

002 Mario Bravo 1002

002 Juana bravo 1001

Id_empresa Nom_empresa

1001 Industria Pacifico

1002 Crackers & Hackers

1003 Pacifico S. A.

Tabla persona

Tabla empresa

Uso de identificadores de objetos

• Para cada objeto se utilice un identificador como clave primaria.

• Los lenguajes orientados a objetos implementa esta identidad mediante punteros o tablas de búsqueda que contienen punteros; identificador es la estructura equivalente dentro de una base de datos.

Traducción a tablas

De UML a Base de datos Relacionales

Asociación de muchos a muchos

Empresa

Nombre empresaDirección empresa

Persona

Nombre personaDirección1..*1..*

Trabaja-para

Cargo

Trabaja_para

1..* 1..*

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección0..*0..*

Trabaja-paraCargo

Trabaja_para

0..* 0..*

Asociación de uno a muchos …

• Se divide en tres tablas: una tabla para cada clase y la tercera tabla compuesta por las claves primarias de cada una de las clases más los atributos de la asociación. – Empresa(Id_empresa, nombre_empresa,

dirección_empresa) – Persona(Id_persona, nombre_persona,

dirección) – Trabaja_para(Id_empresa, id_persona, cargo)

Asociación de uno a muchos … Empresa

Nombre empresaDirección empresa

PersonaNombre personaDirección0..*0..1

Trabaja-paraCargo

Trabaja_para

0..1 0..*

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección0..*1

Trabaja-paraCargo

Trabaja_para

1 0..*

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección1..*0..1

Trabaja-paraCargo

Trabaja_para

0..1 1..*

Asociación de uno a muchos

• Se divide en tres tablas: una tabla para cada clase y la tercera tabla compuesta por las claves primarias de cada una de las clases más los atributos de la asociación. – Empresa(Id_empresa, nombre_empresa,

dirección_empresa) – Persona(Id_persona, nombre_persona,

dirección) – Trabaja_para(Id_empresa, id_persona, cargo)

Asociación de uno a muchos …

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección1..*1

Trabaja-paraCargo

Trabaja_para

1 1..*

Asociación de uno a muchos …

• Se divide en dos tablas: la primera tabla corresponde a la clase cuya participación es uno y la segunda compuesta por los atributos de la clase cuya participación es muchos más la clave primera de la primera tabla más los atributos de la asociación. – Empresa(Id_empresa, nombre_empresa,

dirección_empresa) – Persona(Id_persona, nombre_persona,

dirección, Id empresa, cargo)

Asociación uno a uno

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección0..11

Trabaja-paraCargo

Trabaja_para

1 0..1

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección0..10..1

Trabaja-paraCargo

Trabaja_para

0..1 0..1

Asociación uno a uno …

• Se divide en tres tablas: una tabla para cada clase y la tercera tabla compuesta por las claves primarias de cada una de las clases más los atributos de la asociación. – Empresa(Id_empresa, nombre_empresa,

dirección_empresa) – Persona(Id_persona, nombre_persona,

dirección) – Trabaja_para(Id_empresa, id_persona, cargo)

Asociación uno a uno

EmpresaNombre empresaDirección empresa

PersonaNombre personaDirección11

Trabaja-paraCargo

Trabaja_para

1 1

Asociación uno a uno …

• Se usa una sola tabla que contiene los atributos de ambas tablas más los atributos de la asociación. La clave primaria esta formada por las claves primarias de ambas tablas. – Emp_per(Id_empresa, nombre_empresa,

dirección_empresa, Id_persona, nombre_persona, dirección, cargo)

Asociación n-arias (n>2)

Equipo

Nombre equipoDirección sede

Persona

AñoDenominación

Persona

Nombre personaDirección

GanaPierde

Lanzador

Asociación n-arias (n>2) ..;

• Se divide en una tabla para cada clase más una tabla para la asociación compuesta por las claves primarias de cada clase más los atributos de la asociación. – Persona(Id_persona, nombre_persona, dirección) – Equipo(Id_equipo, nombre_equipo, dirección_sede) – Año(Id_año, Año, denominación) – Per-Equi-año(Id_lanzador, Id_equipo, Id_año, gana,

pierde)

Asociaciones cualificadas

Empresa

Nombre empresaDirección empresa

Persona

Nombre personaDirección0..*

Cargo0..*

Trabaja_para

0..* 0..*Cargo

Asociaciones cualificadas…

• Se divide en tres tablas: las dos primeras tablas corresponden a cada clase y la tercera compuesta por las claves primarias de cada clase más el atributo cualificador. – Empresa(Id_empresa, nombre_empresa,

dirección_empresa) – Persona(Id_persona, nombre_persona,

dirección) – Trabaja_para(Id_empresa, id_persona, cargo)

Herencia simple

• Primera forma: Tabla superclases y subclases

• Segunda forma: Una tabla para cada subclase

• Tercera forma: Una tabla superclase

Pieza

Nombre piezaCosto

Bomba

Presión de succiónPresión de descarga

Intercambiador de calor

Area superficial

Primera forma: Tabla superclases y subclases

• Una tabla para la superclase compuesto por sus atributos más un atributo que indique el tipo de clase. Una tabla para cada subclase compuesto por la clave primaria de la clase más sus atributos. – Pieza(Id_pieza, nombre_pieza, costo, tipo_pieza) – Bomba(Id_pieza, presión_succión,

presión_descarga) – Intercambiador de calor(Id_pieza, área_superficial)

Segunda forma: Una tabla para cada subclase

• Una tabla para cada subclase compuesto por los atributos de la superclase más sus atributos. – Bomba(Id_pieza, nombre_pieza, costo,

presión_succión, presión_descarga) – Intercambiador de calor(Id_pieza,

nombre_pieza, costo, área_superficial)

Tercera forma: Una tabla superclase

• Una sola tabla para la superclase compuesto por los atributos de la superclase más un atributo que identifique el tipo de clase más los atributos de cada subclase. – Pieza (Id_pieza, nombre_pieza, costo,

tipo_pieza, presión_succión, presión_descarga, área_superficial)

PersonaNombreDirecciónNum. seg. social

Tiempo trabajado()ganar salario()

Trabaja-paraCargo{Tipo trabajador}

Trabajador

ProyectoNombre del proyectoPresupuestoPrioridad

1..*

1

1..*

1

Trabaja en

CompañiaNombre empresaDirección empresaNúmero teléfonoProducto principal

Contratar()Despedir()

1..*1..* 1..*1..*

Trabaja_para

Administrador

1

1

1

1

DepartamentoNombre de departamento

11..*11..*

11 11

ProductoNombre del productoCostePrecio

1..*

1..*1..*

1..*

Administra

tiene

Responsable deFabrica

Ejemplo

Tablas

• Compañia(idcom, nombre, dirección_empresa, teléfono, producto principal)

• Persona(idper, dirección, numero seguro social, tipo trabajador, idproy)

• Trabaja_para(idcom, idper, cargo) • Proyecto(idproy, nombre proyecto, presupuesto, prioridad,

idper) • Departamento(iddepar, nombre departamento, idper, idprod) • Producto(idprod, nombre producto, coste, precio) • Tiene(iddepar, idcom)