Está en la página 1de 28

Universidad Nacional Ingeniería de Sistemas

de Trujillo

Diagramas de clase CLASE 02

Curso: Tecnología de la Programación II.


Docente: Mg. Zoraida Yanet Vidal Melgarejo.

Diagrama de Clases. 2

 Son los diagramas más comunes en el modelado de sistemas


orientados a objetos.

 El diagrama de clase representa clases, sus partes y la forma en la que


las clases de los objetos están relacionados con otro.

 Son importantes no sólo para visualización, especificación y


documentación de modelos estructurales, sino también para construir
sistemas ejecutables.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 1
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases. 3

 El Diagrama de Clase es el diagrama principal de análisis y diseño de


un sistema. En él se especifica la estructura de clases del sistema, con
relaciones entre clases y estructuras de herencia.

 Su objetivo varía en análisis y diseño:


• Durante el análisis del sistema, el diagrama se desarrolla buscando
una solución ideal.
• Durante el diseño, se usa el mismo diagrama, y se modifica para
satisfacer los detalles de las implementaciones.

Diagrama de Clases. 4

• Los diagramas de clases proporcionan una perspectiva estática del


sistema (representa su diseño estructural)

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 2
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases. 5

 En la elaboración de un Diagrama de Clases se sugiere seguir los


siguientes pasos:
• Identificar las clases.
• Mostrar los atributos y operaciones (posteriormente).
• Dibujar asociaciones.
• Etiquetar asociaciones y en caso necesario los roles.
• Indicar multiplicidad.
• Dibujar flechas de dirección.

Diagrama de Clases. 6

 Es importante recordar que los objetos son realmente cosas dentro de


un programa de computador; que cuando se habla sobre “libros” y
“copias”, por ejemplo, realmente nos referimos a la representación de
estas cosas dentro de nuestro sistema.

 Las consecuencias de esto son que hay que tener cuidado:


• De no almacenar información que es definitivamente irrelevante
para nuestro sistema.
• De no perder la visión del hecho de que ¡los objetos son el sistema!

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 3
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases. 7

 El último punto es particularmente interesante. Un error clásico es


inventarse una clase, a menudo llamada [Cualquier_cosa]System, que
implementa todo el comportamiento interesante del sistema.

 Pero en Orientación a Objetos todo el negocio es el sistema; ¡este es el


tema! Es fácil dejarse llevar hacia un diseño monolítico donde hay un
único objeto que conoce y hace todo. Esto está mal porque tales
diseños son muy difíciles de mantener: tienden a tener presunciones
sobre cómo será utilizado el sistema.

Diagrama de Clases: las Clases. 8

1. Identificación de clases y objetos.

• La construcción de un modelo de clases incluye la identificación de


las clases que deberían existir en nuestro sistema: ésta es una parte
fundamental del trabajo de diseñar un sistema orientado a objetos.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 4
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Clases. 9

• Hay dos objetivos que se pretenden alcanzar:


o Construir, lo más rápido y barato posible, un sistema que satisfaga
nuestros requisitos actuales. Para ello: “Cada comportamiento que
requiera el sistema debe ser proporcionado por los objetos de las clases
que elijamos”.

o Construir un sistema que sea fácil de mantener y adaptar a futuros


requisitos. Para lograrlo: “Un buen modelo de clases está formado por
módulos encapsulados, con acoplamiento débil (pocas dependencias
entre módulos) y cohesión fuerte (los módulos poseen interfaces que
proporcionan al desarrollador lo necesario que debe conocer para
utilizarlos)”.

Diagrama de Clases: las Clases. 10

• En la práctica, es probable que al construir un modelo de clases lo


haga correctamente la primera vez. La colección de clases en su
modelo de diseño, es una de las cosas que probablemente cambiará
a los largo y dentro de las iteraciones de desarrollo. Normalmente
identificará primero y más fácilmente las clases más importantes de
los objetos del dominio, es decir, aquellas que pertenecen de manera
obvia al problema, en vez de aquellas que se introducen para
resolverlo; las otras clases, que se corresponden con menos claridad
con los objetos del dominio, son más difíciles de identificar con
seguridad.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 5
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Clases. 11

2. Técnica: Identificación de nombres.

• Se procede en dos etapas:


o Identifica las clases candidatas seleccionando todos los nombres y
locuciones nominales de la especificación de requisitos del sistema
(considérelos en forma singular y no incluya frases que contengan “o”
como candidatas).

o Descarte las candidatas que son inapropiadas por cualquier razón,


renombrando las clases restantes si es necesario.

Diagrama de Clases: las Clases. 12

• Las razones por las que se podría decidir que una clase candidata es
inapropiada incluyen que es:

1. Redundante, donde a la misma clase se le ha dado más de un nombre.


Es, sin embargo importante recordar que los objetos parecidos no tienen
que se completamente iguales: una de las cosas que hay que decidir es si
las clases son los suficientemente diferentes para considerarlas clases
distintas. Por ejemplo, se incluyen aquí pares como “préstamo” y
“préstamo a corto plazo”: son diferentes, pero probablemente sólo en los
valores de los atributos. Elija un nombre para la clase que abarque todas
las descripciones que quiera que incluya.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 6
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Clases. 13

2. Impreciso, donde no se puede indicar de forma no ambigua lo que


significa un nombre. Obviamente hay que eliminar la ambigüedad antes
de poder decir que se trata de una clase.

3. Un evento u operación, donde el nombre hace referencia a algo que se


hace para, por o en el sistema. A veces tales cosas están bien modeladas
en una clase, pero no es lo normal. Pregúntese si la instancia del evento u
operación tiene estado, comportamiento e identidad. Si no, descártelo.
El estado de un objeto lo constituyen todos los datos (atributos) que
encapsula en un momento determinado.
El comportamiento es la manera como actúa y reacciona un objeto, en
función de sus cambios de estado y el paso de mensajes.
La identidad es que a los objetos se les hace referencia por un nombre (el
valor de una variable en un programa cliente) pero el nombre del objeto
no es lo mismo que el objeto, porque un mismo objeto puede tener varios
nombres diferentes.

Diagrama de Clases: las Clases. 14

4. Metalenguaje, donde el nombre forma parte de la manera en que se


definen las cosas. Se utilizan los nombres requisitos y sistema, por
ejemplo, como parte del lenguaje de modelado, en vez de representar
objetos en el dominio del problema.

5. Fuera del alcance del sistema, donde el nombre es relevante para


describir cómo funciona el sistema pero que no hace referencia a algo.

6. Un atributo, donde está claro que un nombre hace referencia a algo


sencillo, sin un comportamiento interesante, que es un atributo de otra
clase.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 7
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Clases. 15

• En general, si se duda si mantener una clase, una buena práctica


sería mantener dos listas, una con los candidatos más firmes y otra
con los más dudosos. Con ello se evita perder información mientras
se está distinguiendo todavía las cosas de las que se esté seguro, de
las cosas que tienen que ser fijadas todavía.

Diagrama de Clases: las Relaciones. 16

 Las relaciones existentes entre las distintas clases nos indican cómo se
comunican los objetos de esas clases entre si.

 Los mensajes “navegan” por las relaciones existentes entre las


distintas clases.

 Existen distintos tipos de relaciones:


- Asociación (Conexión entre clases).
- Dependencia (relación de uso).
- Generalización/especialización (relaciones de herencia).

 Al dibujar las relaciones entre clases, se incluye información tal como


la etiqueta, el rol y la multiplicidad de dicha relación.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 8
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Relaciones. 17

• Rol
o Identifica con nombres a los elementos que aparecen en los extremos de la
línea que denota la relación, dicho nombre describe la semántica que tiene la
relación en el sentido indicado. Por ejemplo, la asociación entre Persona que
Trabaja Para una Empresa, recibe el nombre de trabajador y empleador
como rol en ese sentido.
Etiqueta

Rol Rol

Diagrama de Clases: las Relaciones. 18

• Multiplicidad
o Indica la cardinalidad de la relación. En el ejemplo se utilizan 1 , 1 ..*, 5 , *,
como indicadores de multiplicidad.

Relación
Multiplicidad Multiplicidad

Rol Rol

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 9
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Relaciones. 19

o Determina cuantos objetos de cada tipo intervienen en la relación, es decir, el


número de instancias de una clase que se relacionan con UNA instancia de la
otra clase

o Cada relación tiene dos multiplicidades (una para cada extremo de la


relación): cuando la multiplicidad mínima es CERO, la relación es opcional; y
una multiplicidad mínima mayor o igual que UNO establece una relación
obligatoria.

Diagrama de Clases: las Relaciones. 20

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 10
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: las Relaciones. 21

• Dirección
o La dirección en las flechas de la asociación determinan en que dirección puede
recorrerse una asociación en el momento de la ejecución.
o Una asociación sin flechas significa que se puede ir de un objeto a otro y
viceversa.
o En el ejemplo siguiente el tipo de flecha en la asociación implica que desde el
objeto Reservación puedes recuperar (dirigirte hacia) el objeto Cliente.
También implica que del objeto Cliente se puede recuperar el juego de
reservaciones para ese cliente.

Diagrama de Clases: las Relaciones. 22

1.- Relación de Asociación

1.1.- Asociación de Agregación

1.2.- Asociación de Composición

2.- Relación de Dependencia

3.- Relación de Generalización

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 11
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación. 23

 Una asociación en general es una línea que une dos o más símbolos.
Pueden tener varios tipos de adornos, que define su semántica y
características. Los tipos de asociaciones entre clases presentes en un
diagrama estático son: asociación binaria, asociación reflexiva,
asociación n-aria, agregación, composición.
 La asociación expresa una conexión bidireccional entre objetos. Una
asociación es una abstracción de la relación existente en los enlaces
entre los objetos. Puede determinarse por la especificación de
multiplicidad (mínima...máxima)

Diagrama de Clases: Asociación Binaria. 24

 Una asociación binaria se representa mediante una línea sólida que une
dos clases, se trata de una relación entre las dos clases no muy fuerte, es
decir, no se exige dependencia existencial ni encapsulamiento.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 12
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación Binaria. 25

Diagrama de Clases: Asociación


26
Reflexiva.

 Una clase puede asociarse con sí misma. Una clase Empleado puede
relacionarse con sí misma a través del rol gerente/dirige.
 No significa que una instancia está relacionada consigo misma, sino que
una instancia de la clase está relacionada con otra instancia de la
misma clase.
• Por ejemplo: Una instancia de Empleado
puede ser el jefe de otras instancias de
Empleado. Como el rol subordinado tiene una
multiplicidad de 0…*, significa que puede
tener o no tener otros empleados a quien
dirigir. Una instancia de Empleado tiene un
sólo jefe o ninguno (en caso de ser el mismo
jefe).

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 13
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación


27
Reflexiva.

Diagrama de Clases: Asociación N-aria. 28

 Es una forma de expresar una relación entre tres o más clases.


 La clase de asociación es dependiente en existencia de las otras clases.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 14
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación N-aria. 29

Diagrama de Clases: Asociación de


30
Composición.

 Es un tipo de relación fuerte, el objeto agregado no puede existir de


forma independiente.
 Agregación disjunta y estricta: Las partes sólo existen asociadas al
compuesto (sólo se accede a ellas a través del compuesto).
 Gráficamente, se muestra con un rombo lleno en uno de los extremos
(compuesto).

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 15
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación de


31
Composición.

Diagrama de Clases: Asociación de


32
Agregación.

• Es un tipo de relación débil, el objeto agregado puede existir de forma


independiente.
• Las partes pueden forma parte de distintos agregados.
• Gráficamente, se muestra con un rombo vacío en uno de los extremos.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 16
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Asociación de


33
Agregación.

Diagrama de Clases: Dependencia. 34

 Relación (más débil que una asociación) que muestra la relación entre
un cliente y el proveedor de un servicio usado por el cliente:
• Cliente es el objeto que solicita un servicio.
• Servidor es el objeto que provee el servicio solicitado.

 Un cambio en un elemento (el elemento independiente) puede afectar a


la semántica del otro elemento (elemento dependiente).

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 17
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Dependencia. 35

• Gráficamente, la dependencia se muestra como una línea discontinua


con una punta de flecha que apunta del cliente al proveedor.

Clase dependiente Clase independiente

Video Televisión
Canal

grabar(c : canal) cambiar(c : canal)

Diagrama de Clases: Dependencia. 36

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 18
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Generalización. 37

 Es una relación entre dos clases en donde una de ellas, llamada


subclase o clase hija, hereda los atributos y el comportamiento de otra,
llamada superclase o clase padre.

 En una generalización no hay multiplicidad ni roles.

 Las subclases heredan características de las clases de las que se


derivan y añaden características específicas que las diferencian.

 La visibilidad “protected” permite que sólo objetos de la misma clase ó


subclase vean el elemento.

Diagrama de Clases: Generalización. 38

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 19
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Generalización. 39

Diagrama de Clases: Paquete. 40

 Es un elemento organizador que


proporciona UML al dividir el
sistema en paquetes que lo hace más
fácil de entender.

 Un paquete es una forma de agrupar


clases (u otros elementos en otro
tipo de diagramas) en modelos
grandes. Pueden tener asociaciones
de dependencia o de generalización
entre ellos. Un ejemplo puede ser el
siguiente

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 20
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Interfaces. 41

 Una interface no es una clase. Una clase tiene una instancia de su tipo,
mientras que una interface debe tener al menos una clase para
implantarla. En UML, una interface es considerada como una
especialización de una clase.

 Una interface se dibuja como una clase, pero en el compartimento


superior del rectángulo aparece un texto ó una inicial que indica que se
trata de una interface y no de una clase.

 Se representan como clases pero con el estereotipo <<interface>>.

 Solo contienen operaciones públicas.

Diagrama de Clases: Interfaces. 42

• En el diagrama anterior las clases ArrayList y LinkedList implementan a la


interface List. Se reconoce a la interface por que en el diagrama se puede
visualizar el estereotipo <<interface>> y porque las líneas que indican el tipo
de relación son punteadas y no continuas (como en la herencia entre clases).

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 21
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Clase Abstracta. 43

 Una clase abstracta se denota con el nombre de la clase y de los


métodos con letra "itálica". Esto indica que la clase definida no puede
ser instanciada pues posee métodos abstractos (aún no han sido
definidos, es decir, sin implementación). La única forma de utilizarla es
definiendo subclases, que implementan los métodos abstractos
definidos.

Diagrama de Clases: Clase


44
Parametrizada.

 Se denota con un subcuadro en el extremo superior de la clase, en


donde se especifican los parámetros que deben ser pasados a la clase
para que esta pueda ser instanciada.

 El ejemplo más típico es el caso de un Diccionario en donde una llave o


palabra tiene asociado un significado, pero en este caso las llaves y
elementos pueden ser genéricos.

 La genericidad puede venir dada de un Template (como en el caso de


C++) o bien de alguna estructura predefinida (especialización a través
de clases).

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 22
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Clase


45
Parametrizada.

• En el ejemplo no se especificaron los atributos del Diccionario, pues


ellos dependerán exclusivamente de la implementación que se le quiera
dar.

Diagrama de Clases: Ejemplo 1. 46

En una empresa de Ventas, un cliente (Natural o Jurídico) realiza un


pedido que es atendido por un Personal. Dicho personal tiene a su cargo
a otro personal. El cual ocupa un puesto específico en la empresa.
En un pedido se pueden consignar la venta de varios productos. Así
también un producto puede estar relacionado con varios pedidos.
Un producto se encuentra relacionado con una sola categoría, a la cual
pueden pertenecer varios productos

Realizar un Diagrama de Clases que grafique las relaciones existentes.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 23
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Ejemplo 1. 47

Diagrama de Clases: Ejemplo 2. 48

Se desea diseñar un diagrama de clases sobre la información de las


reservas de una empresa dedicada al alquiler de automóviles, teniendo en
cuenta que un determinado cliente puede tener en un momento dado
hechas varias reservas.
De cada cliente se desean almacenar el número de su DNI, su nombre, su
dirección y su número de teléfono. Además dos clientes se diferencian
por un código único.
Cada cliente puede ser avalado por otro cliente de la empresa.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 24
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Ejemplo 2. 49

Una reserva la realiza un único cliente pero puede involucrar varios coches.
Es importante registrar la fecha de inicio y final de la reserva, el precio del
alquiler de cada uno de los coches, los litros de gasolina en el depósito en el
momento de realizar la reserva, el precio total de la reserva y un indicador
de si el coche o los coches han sido entregados.
Todo coche tiene siempre asignado un determinado garaje que no puede
cambiar. De cada coche se requiere la placa, el modelo, el color y la marca.
Cada reserva se realiza en una determinada agencia.

Diagrama de Clases: Ejemplo 2. 50

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 25
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Ejemplo 3. 51

La Policía quiere crear una base de datos sobre la seguridad en algunas


entidades bancarias. Para ello tiene en cuenta:
Que cada entidad bancaria se caracteriza por un código y por el domicilio
de su Central.
Que cada entidad bancaria tiene más de una sucursal que también se
caracteriza por un código y por el domicilio, así como por el número de
empleados de dicha sucursal.
Que cada sucursal contrata, según el día, algunos vigilantes jurados, que
se caracterizan por un código y su edad. Un vigilante puede ser contratado
por diferentes sucursales (incluso de diferentes entidades), en distintas
fechas y es un dato de interés dicha fecha, así como si se ha contratado
con arma o no.

Diagrama de Clases: Ejemplo 3. 52

Por otra parte, se quiere controlar a las personas que han sido detenidas
por atracar las sucursales de dichas entidades. Estas personas se definen
por una clave (código) y su nombre completo.
Alguna de estas personas están integradas en algunas bandas organizadas
y por ello se desea saber a qué banda pertenecen, sin ser de interés si la
banda ha participado en el delito o no Dichas bandas se definen por un
número de banda y por el número de miembros.
Así mismo, es interesante saber en qué fecha ha atracado cada persona
una sucursal. Evidentemente, una persona puede atracar varias
sucursales en diferentes fechas, así como que una sucursal puede ser
atracada por varias personas.

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 26
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Diagrama de Clases: Ejemplo 3. 53

Igualmente, se quiere saber qué Juez ha estado encargado del caso,


sabiendo que un individuo, por diferentes delitos, puede ser juzgado por
diferentes jueces. Es de interés saber, en cada delito, si la persona
detenida ha sido condenada o no y de haberlo sido, cuánto tiempo pasará
en la cárcel. Un Juez se caracteriza por una clave interna del juzgado, su
nombre y los años de servicio.
NOTA: En ningún caso interesa saber si un vigilante ha participado en la
detención de un atracador

Ejemplo 3: 54

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 27
Universidad Nacional Ingeniería de Sistemas
de Trujillo

Ejemplo 4: 55

Una biblioteca tiene copias de libros. Estos últimos se caracterizan por su


nombre, año y autor. Un libro está relacionado con una categoría (novela, teatro,
poesía, ensayo) así como también con una editorial. Los autores se caracterizan
por su nombre y fecha de nacimiento. Se considera que el autor sólo tiene una
nacionalidad.
Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, con
retraso o en reparación.
Los lectores pueden tener un máximo de 3 libros en préstamo.
Cada libro se presta un máximo de 30 días, por cada día de retraso, se impone
una “multa” de dos días sin posibilidad de coger un nuevo libro.

Realizar un diagrama de clases para realizar el préstamo y devolución de libros.

Ejemplo 4: 56

Curso: Tecnología de la Programación II Tema: Diagramas de Clase


Docente: Mg. Zoraida Yanet Vidal Melgarejo Pág. 28

También podría gustarte