República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Universitaria, Ciencia y Tecnología

Universidad Politécnica Territorial del Estado Bolívar
Modelado de Base de Datos
T8-INF-2T

MODELO DE CLASES

Profesora: Estudiantes:
Luzmeidy Bravo Alexander Serrano
(26.851.230)
Nelson Figuera
(28.342.503)

Ciudad Bolívar, julio de 2020.

 Índice
Págs.
Introducción...............................................................................................................................1

Modelo de Clases......................................................................................................................2

Objeto.....................................................................................................................................2

Clases.....................................................................................................................................2

Elementos..............................................................................................................................2

Tipos de clases.....................................................................................................................4

Notación de la visibilidad.........................................................................................................5

Interfaces....................................................................................................................................6

Relaciones..................................................................................................................................8

Notación de las relaciones.....................................................................................................10

Vista lógica o estructural.......................................................................................................11

Crear instancias (instanciar)..................................................................................................11

Ventajas de los diagramas de clases UML...........................................................................12

Desventajas de los diagramas de clases UML.....................................................................13

Conclusión...............................................................................................................................14

Bibliografía...............................................................................................................................15

Actividad Diseño de modelado de clases............................................................................16

 Introducción

Un lenguaje de modelado debe ser capaz de ofrecer los mecanismos necesarios para
capturar y modelar la abstracción de un sistema desde diferentes puntos de vista. Estos
puntos de vista deben dar lugar a diferentes diagramas que recojan tanto la definición
estática del sistema, como la componente de comportamiento dinámico del mismo.

En concreto, los diagramas de estructuras representan las abstracciones identificadas en

forma de clases y objetos, mostrando su estructura interna, así como sus interrelaciones.
Existen dos tipos de diagramas de estructura: los diagramas de clase y los diagramas de
objetos.

Los diagramas de clase describen los tipos de objetos de un sistema, así como los
distintos tipos de relaciones que pueden existir entre ellos. Los diagramas de clase se
convierten así en la técnica más potente para el modelado conceptual de un sistema
software, la cual suele recoger los conceptos clave del modelo de objetos subyacente al
método orientado a objetos que la incorpora.

Por su parte, los diagramas estáticos de objetos representan una instantánea del estado
del sistema en un momento dado, esto es, cada diagrama de objetos es una instancia del
diagrama de clase, que representa uno de los infinitos escenarios a los que puede dar origen
un diagrama de clase.

1
 Modelo de Clases

El propósito de un diagrama de clase es describir las clases que conforman el modelo de

un determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un
desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado durante las
fases de análisis y diseño, estando presente como guía en la implementación del sistema.

Objeto

Es la representación de algo que se describe mediante un identificador, una estructura y

un comportamiento. “Instancia de una Clase”.

Los diagramas de objetos están vinculados con los diagramas de clases. Un objeto es una
instancia de una clase, por lo que un diagrama de objetos puede ser visto como una
instancia de un diagrama de clases. Los diagramas de objetos describen la estructura
estática de un sistema en un momento particular y son usados para probar la precisión de los
diagramas de clases.

Cabe mencionar que una instancia se refiere a cada objeto que pertenece a una clase e
instanciación el proceso de generación o creación de las instancias de una clase.

Clases

Es una plantilla para crear objetos e implementar un comportamiento en un sistema. En

UML, una clase representa un objeto o un conjunto de objetos que comparte una estructura y
un comportamiento comunes. Se representan con un rectángulo que incluye filas del nombre
de la clase, sus atributos y sus operaciones. Al dibujar una clase en un diagrama de clases,
solo se debe cumplimentar la fila superior. Las otras son opcionales y se usan si deseas
agregar más detalles.

Elementos

Un diagrama de clases estándar está compuesto por tres partes:

 Sección superior: Contiene el nombre de la clase. Esta sección siempre es

necesaria, ya sea que se esté hablando del clasificador o de un objeto.

2
  Sección central: Contiene los atributos de la clase. Esta sección se usa para describir
cualidades de la clase. Esto solo es necesario al describir una instancia específica de
una clase.
 Sección inferior: Incluye operaciones de clases (métodos). Esto está organizado en
un formato de lista. Cada operación requiere su propia línea. Las operaciones
describen cómo una clase puede interactuar con los datos.

Se puede decir que existen tres perspectivas diferentes desde las cuales se pueden
utilizar los diagramas de clase:

 Conceptual: El diagrama de clase representa los conceptos en el dominio del

problema que se está estudiando. Este modelo debe crearse con la mayor
independencia posible de la implementación final del sistema.
 Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su
implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya que
un tipo representa una interfaz que puede tener muchas implementaciones diferentes.
 Implementación: Esta vista representa las clases tal cual aparecen en el entorno de
implementación.

Los diagramas de clase de UML pueden utilizarse en cualquiera de las tres perspectivas
presentadas, como se muestra en la siguiente imagen:
 Tipos de clases

 Clases parametrizables: plantillas de clases que se pueden parametrizar con uno

o más tipos de datos según sea necesario (clases genéricas).

 Clases abstractas: clases que no tienen implementación para todos los métodos
definidos.

 Clases utilitarias: clases que contienen librerías de funciones.

 Notación de la visibilidad:

Dependiendo del detalle del diagrama de clase, la notación para un atributo puede indicar
su nombre, su tipo, un valor de inicio y su visibilidad, siendo su sintaxis:

Visibilidad nombre: tipo = valor

Dónde:

 Visibilidad expresa si el atributo es visible para el resto de objetos del diagrama,

pudiéndose dar los siguientes casos:
o + Visibilidad pública: Visible por todos los objetos.
o # Visibilidad protegida: Visible sólo por el objeto y sus descendientes.
o Visibilidad privada: Visible sólo por el objeto.
 Nombre es el identificador del atributo.
 Tipo indica el dominio del atributo.
 Valor es un elemento opcional que indica un valor de inicio para el atributo.

Al igual que sucede con los atributos, las operaciones de una clase pueden especificarse
con diferente nivel de detalle según la siguiente sintaxis:

Visibilidad nombre (lista de parámetros): tipo de retorno

Tipos datos

Los tipos datos asocian a un conjunto de objetos con sus operaciones utilizando rangos
concretos de valores y agrupándolos con sus operaciones especiales. Los objetos pueden
tener varios tipos. Sus valores abarcan desde los tipos primitivos a las enumeraciones de
cierta longitud.

Los tipos datos son clasificadores y solo es posible identificar sus instancias a partir de su
valor. Con los tipos datos se visualizan en los diagramas de clases UML tipos valor, tipos
primitivos y tipos estructurados. Si se copia una instancia tipo dato o se modela dos
instancias del mismo tipo dato con el mismo valor, se consideran como instancias iguales.

Si el tipo dato posee atributos, UML lo clasifica como tipo dato estructurado. Sus
instancias solo se consideran iguales si su estructura y los valores de sus atributos son
iguales.
 Los tipos primitivos no muestran estructuras subordinadas, sino que constituyen valores
de datos atómicos. En los diagramas de clases también encuentran aplicación en
restricciones. Más allá de la especificación UML, estos tipos ostentan una semántica
compleja. En UML, sin embargo, no tienen identidad, por lo cual, en caso de tener el mismo
valor, no pueden diferenciarse. Algunos de los tipos primitivos en UML son:

 Booleanos (variables booleanas).

 Íntegros.
 Unlimited Natural (cifra natural, ilimitada).
 Real (cifra real).
 String / varchar (secuencia de caracteres).

Interfaces

Las interfaces son clasificadores, su notación se parece a la de las clases, aunque no son
clases sino declaraciones, es decir, declaran un conjunto de funciones y obligaciones
abiertas e interrelacionadas de forma lógica. Para ello utilizan un contrato. Si una instancia
ejecuta la interfaz, ha de cumplir con el contrato. Aquí se habla entonces de que una
instancia ofrece un servicio según contrato. En su rol de declaración, no configura instancias
por sí misma.

En su lugar lo hace la clase, porque puede instanciar. Su instancia utiliza especificaciones

de interfaces, para lo que ha de cumplir el contrato de la interfaz. Como contrapartida, utiliza
la interfaz como escenario público. Un clasificador puede implementar varias interfaces y a la
inversa, una interfaz puede servir a varios clasificadores. En el diagrama de clases UML las
notaciones de interfaz y clase son similares: un cuadrado que puede seccionarse en tres
partes opcionalmente.

Para mostrar que una clase utiliza una interfaz se utiliza la notación Interface Realization
(que conocemos por los clasificadores de comportamiento). Esta representa a una interfaz
suministrada (Provided Interface), una interfaz que ejecuta directamente a una instancia.
Esto se aplica también a clases superiores como los componentes. Si la clase tiene un
puerto público, es este el que proporciona la interfaz. Para dibujar una Interface Realization
se utiliza un círculo que se une al clasificador por medio de una línea.
 La notación de la interfaz se asemeja a la de la clase. Para diferenciarse, la interfaz lleva
la etiqueta <<interfaz>>. Las clases fijan a las interfaces por medio de Interface Usage o
Interface Realization.

También están las interfaces requeridas (Required Interfaces), que visualizan una relación
de dependencia. Aquí un elemento necesita a otro elemento para ejecutar todo el potencial
de sus funciones propias. En este caso un clasificador (o una de sus instancias) necesita una
interfaz. La Interface Usage (uso de la interfaz) especifica qué exigencias se plantean a la
interfaz. Para ello una línea une al clasificador con un medio círculo que simboliza a la
interfaz. El nombre de la interfaz se escribe en ambos representantes debajo del círculo o el
medio círculo.

Si una clase lleva una interfaz a una clase inferior, se ha de modelar la conexión de la
interfaz a la clase o instancia subordinada. La relación jerárquica se muestra con el acento
circunflejo (^), por ejemplo, ^interfaz 1.

Si se emplea la notación cuadrada de las interfaces, se dibuja una línea entre los dos
nodos. En los diagramas de clases, las líneas modelan las relaciones entre clases, instancias
o componentes. UML prescribe diferentes líneas y flechas para funciones y relaciones
diversas. En este caso, para unir a una clase con la interfaz requerida se utiliza una flecha
discontinua con punta abierta. Añade la etiqueta <<use>> a la flecha. Para unir a una
interfaz
requerida con una clase se utiliza una flecha discontinua con punta cerrada, sin rellenar. La
flecha apunta siempre en dirección a la interfaz.

Relaciones

Los tipos más importantes de relaciones estáticas entre clases son los siguientes:

 Asociación. Las relaciones de asociación representan un conjunto de enlaces

entre objetos o instancias de clases. Es el tipo de relación más general, y denota
básicamente una dependencia semántica. Por ejemplo, una Persona trabaja para
una Empresa. Se representa como una línea continua entre una clase a otra.

Cada asociación puede presentar elementos adicionales que doten de mayor

detalle al tipo de relación:
o Rol, o nombre de la asociación, que describe la semántica de la relación en
el sentido indicado. Por ejemplo, la asociación entre Persona y Empresa
recibe el nombre de trabaja para, como rol en ese sentido.
o Multiplicidad, que describe la cardinalidad de la relación, es decir, especifica
cuantas instancias de una clase están asociadas a una instancia de la otra
clase. Los tipos de multiplicidad son: Uno a uno, uno a muchos y muchos a
muchos.
 Herencia. Las jerarquías de generalización/especialización se conocen como
herencia. Herencia es el mecanismo que permite a una clase de objetos incorporar
atributos y métodos de otra clase, añadiéndolos a los que ya posee. Con la
herencia se refleja una relación “es_un” entre clases. La clase de la cual se hereda
se denomina superclase, y la que hereda subclase.
La generalización define una superclase a partir de otras. Por ejemplo, de las
clases profesor y estudiante se obtiene la superclase persona. La especialización o
especificación es la operación inversa, y en ella una clase se descompone en una
o varias subclases. Por ejemplo, de la clase empleado se pueden obtener las
 subclases secretaria, técnico e ingeniero. Esta relación se representa como una
línea continua con una flecha hueca en el extremo que apunta a la superclase.

 Agregación. Es un tipo de relación jerárquica entre un objeto que representa la

totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento
físico de estructuras relacionadas lógicamente. Los objetos “son-parte-de” otro
objeto completo. Por ejemplo, motor, ruedas, carrocería son parte de automóvil. Se
representa con un rombo hueco en la clase cuya instancia es una agregación de
las instancias de la otra.

 Composición. La composición es una forma de agregación donde la relación de

propiedad es más fuerte, e incluso coinciden los tiempos de vida del objeto
completo y las partes que lo componen. Por ejemplo, en un sistema de Máquina de
caf , las relaciones entre la clase máquina y producto, o entre máquina y depósito
de monedas, son de composición. Se representa con un rombo lleno en la clase
cuya instancia contiene las instancias de la otra clase.
  Dependencia. Una relación de dependencia se utiliza entre dos clases o entre una
clase y una interfaz, e indica que una clase requiere de otra para proporcionar
alguno de sus servicios. Una línea discontinua con una flecha apuntando a la clase
cliente. La relación puede tener un estereotipo que se coloca junto a la línea, y
entre el símbolo: << … >>.

Notación de las relaciones

Una relación de asociación se representa como una línea continua entre las clases
asociadas. En una relación de asociación, ambos extremos de la línea pueden conectar con
la misma clase indicando que una instancia de una clase est asociada a otras instancias
de la misma clase, lo que se conoce como asociación reflexiva.

La relación puede tener un nombre y un estereotipo, que se colocan junto a la línea. El

nombre suele corresponderse con expresiones verbales presentes en las especificaciones, y
define la semántica de la asociación. Los estereotipos permiten clasificar las relaciones en
familias y se escribirán entre el símbolo: << … >>.

Las diferentes propiedades de la relación se pueden representar con la siguiente notación:

 Multiplicidad: La multiplicidad puede ser un número concreto, un rango o una

colección de números. La letra „n‟ y el símbolo „*‟ representan cualquier número.
 Orden: Se puede especificar si las instancias guardan un orden con la palabra clave
„{ordered}‟. Si el modelo es suficientemente detallado se puede incluir una restricción
que indique el criterio de ordenación.
 Navegabilidad: La navegación desde una clase a la otra se representa poniendo una
flecha sin relleno en el extremo de la línea, indicando el sentido de la navegación.
  Rol o nombre de la asociación: Este nombre se coloca junto al extremo de la línea
que está unida a una clase, para expresar como esa clase hace uso de la otra clase
con la que mantiene la asociación.

Generalmente, cuando se desarrolla un modelo de datos no se utiliza toda esta

complejidad. Por ejemplo, generalmente no se definen métodos.

Vista lógica o estructural

 Polimorfismo: se puede usar el mismo nombre para la definición de un método en

varias clases sin importar la relación entra las mismas.
 Reescritura o sobre carga: permite nombrar código diferente con el mismo
nombre para más de una clase de objetos.
 Encadenamiento tardío: permite seleccionar el código adecuado al objeto
definido en la invocación del método.

Crear instancias (instanciar)

Se tomará de ejemplo la clase persona:

 La relación entre clase y código es importante, así se representaría en Java:

Las instancias:

Ventajas de los diagramas de clases UML

El diagrama de clases es uno de los diagramas UML más populares, representa
estructuras de sistemas tanto de forma detallada como general. Como diagrama de
estructuras, muestra un sistema en estado estático de modo que el observador obtiene una
perspectiva general de los elementos imprescindibles de un sistema, pero también visualizan
las relaciones entre los componentes de esta arquitectura. Con un diagrama de clases UML
se modelan desde objetos reales a clases abstractas con perfiles ampliables en cualquier
lenguaje de programación. Con ellos se facilita la comunicación entre departamentos
especializados en la realización de un proyecto.
 UML es una herramienta propia de personas que tienen conocimientos relativamente
avanzados de programación y es frecuentemente usada por analistas funcionales para definir
qué debe hacer un programa sin entrar a escribir el código y analistas-programadores que,
dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje
como Java, C#, Python o cualquier otro. De hecho, prácticamente cualquier persona puede
usar UML, incluso usarse para realizar esquemas o documentación de procesos que no
tengan que ver con la informática.

Desventajas de los diagramas de clases UML

UML recibe numerosas críticas por parte de los miembros de la comunidad de

desarrolladores software, entre ellas el ser demasiado extenso, carecer de significados
precisos para los elementos representados, dificultad para representar algunos tipos de
sistemas software o elementos, entre otros.

A pesar de ello y de no ser “perfecto” es un est ndar de amplio uso hoy día y una
herramienta fundamental en desarrollos software de gran envergadura.
 Conclusión

Se ha presentado una de las técnicas de modelado más difundidas en los métodos de

análisis y diseño orientado a objetos, haciendo un rápido recorrido por lo que son los
elementos esenciales de los diagramas de clase, las clases y sus principales relaciones
(asociación, agregación, dependencia y herencia).

El UML presenta otros diversos elementos (estereotipos, relaciones de dependencia,

relaciones de refinamiento) que pueden aparecer en este tipo de diagramas, estos permiten
tomar elementos propios del UML y convertirlos en otros que se ajusten más a las
necesidades.

Cabe mencionar la facilidad de comprensión de estos diagramas en el modelado de

sistemas software, así como su apoyo y presencia desde los modelos conceptuales iniciales
a la implementación, como dos de sus principales características.
 Bibliografía

[1] https://repositorio.grial.eu/bitstream/grial/353/1/DClase.pdf

[2] https://scielo.conicyt.cl/scielo.php?pid=S0718-
07642014000500016&script=sci_arttext&tlng=en

[3] https://www.ctr.unican.es/asignaturas/is1/is1-t10-trans-parte3.pdf

[4] https://www.teatroabadia.com/es/uploads/documentos/iagramas_del_uml.pdf

[5] http://stadium.unad.edu.co/ovas/10596_9836/diagrama_de_clases_de_diseo.html

[6]http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias%3Apis%3Adiagramas_de_clas
es_y_casos_de_uso.pdf

[7] https://www.usmp.edu.pe/publicaciones/boletin/fia/info67/UML.pdf
 Actividad: Diseño de modelado de clases

a1) HOTEL SOL DE ORIENTE.

Identificación de clases

 Hotel
 Empleado
 Aseo
 Cliente
 Reservación
 Factura
 Detalle_factura
 Servicios (clientes_servicios)

Identificación de atributos

 Hotel: RIF, nombre, dirección, teléfono.

 Empleado: empleadoId, cédula, nombres, apellidos, estado_civil, email,
telefono1, telefono2, fecha_ingreso, sueldo, cod_empleado, servicio,
jefatura.
 Aseo: aseoId, habitación, fecha.
 Cliente: clienteId, cédula, nombres, apellidos, dirección, email, telefono1,
telefono2.
 Reservación: reservacionId, fecha_entrada, fecha_salida, nro_noches,
habitación.
 Factura: facturaId, fecha, forma_pago, comisión_pago, monto_total.
 Detalle_factura: servicioId, monto_iva, monto.
 Servicios: servicioId, descripción, precio.
o clientes_servicios: fecha.
Identificación de asociaciones
Modelo de clases
a2) CONCESIONARIO DE AUTOMÓVILES.

Identificación de clases

 Concesionario
 Cliente
 Vehículo (vehiculo_cliente, vehiculo_concesionario)
 Taller
 Mecánico
 Reparación

Identificación de atributos

 Concesionario: RIF, nombre, dirección, telefono1, telefono2, email1, email2.

 Cliente: clienteId, cédula, nombres, apellidos, dirección, telefono1,
telefono2, email1, email2.
 Vehículo: matriculaVehic, marca, modelo, color, nro_motor,
 fecha_fabricacion, kilometraje.
o Vehiculo_cliente: fecha_compra.
o Vehiculo_concesionario: uso, estatus, precio.
 Taller: cod_servicio.
 Mecánico: mecanicoId, cédula, nombres, apellidos, fecha_contrato, salario.
 Reparación: fecha_entrada, falla, reparación, fecha_salida.

Identificación de asociaciones
 Modelo de clases

a3) ENTIDAD BANCARIA.

Identificación de clases

 Banco
 Cuenta
 Empleado
 Cliente
 Transacción

Identificación de atributos

 Banco: RIF, nombre, dirección, teléfono, email.

 Cuenta: nro_cuenta, tipo, interés_ahorro, limite_descubierto, fecha_acceso.
 Empleado: empleadoId, cédula, nombre, apellido, email, teléfono, dirección.
 Cliente: clienteId, cédula, nombres, apellidos, cuenta, seguro_social, email,
dirección, teléfono.
 Transacción: nro_transaccion, fecha, cantidad.
Identificación de asociaciones
 Modelo de clases

4) SERVICIOS COMUNITARIOS
Identificación de clases

 Usuario (o administrador)
 Proyecto (servicio_comunitario, inscripción)
 Integrante (serv_com_integrante, inscripcion_integrante)
 PNF
 Municipio
 Parroquia
 Identificación de atributos

 Usuario: usuarioId, nombre_usuario, contraseña.

 Proyecto: nombre, año, tutor_academico.
o servicio_comunitario: servComId, tutor_institucional, sector,
responsable_sector.
o inscripcion: inscripcionId.
 Integrante: nombre, cédula.
o serv_com_integrante: servComIntId, sexo, código.
o inscripcion_integrante: inscIntId.
 PNF: pnfId, nombre.
 Municipio: municipioId, nombre.
 Parroquia: parroquiaId, nombre.

Identificación de asociaciones
Modelo de clases
5)
Identificación de clases

 Estudiante
 Curso (ingles, matemática, física)
 Proyecto
 Factura
 Det_fact_cl
 Pre_inscripcion
 Profesor
 Sueldo
 Recibo
 Det_recibo

Identificación de atributos

 Estudiante: cédula, nombre, teléfono.

 Curso: codCurso, descripción, costo.
o Inglés: cant_hora.
o Matemática: lugar.
o Física: cant_al.
 Proyecto: nro_p, nombre, cant_alum.
 Factura: codFac, descripción, dirección.
 Det_fact_cl: detFac, importe, cantidad.
 Pre_inscripcion: cod, nom_curso, fecha_inicio, fecha_final.
 Profesor: ficha, nombre, apellido, fecha_inicio.
 Sueldo: cod, descripción, cant_horas.
 Recibo: codR, fecha, descuento, monto.
 Det_recibo: detR, importe, iva, total.
Identificación de asociaciones
Modelo de clases