Ingeniería del Software II - Modelado de clases con UML - Fernando Pereñiguez
Summary
TLDREn este vídeo se explica cómo modelar la estructura de un sistema a través de un diagrama de clases, utilizando como ejemplo un sistema de gestión de pedidos. Se detalla cómo identificar clases como Pedido, Línea de Pedido, Producto, Cliente (personal y corporativo) y Vendedor. Se establecen relaciones entre estas clases, como generalización, asociación y dependencia, para reflejar adecuadamente la realidad del negocio. Además, se mencionan atributos y métodos de algunas clases para un modelado más preciso.
Takeaways
- 📝 Se aborda el modelado de la estructura del sistema a través de la elaboración de un diagrama de clases para un sistema de gestión de pedidos.
- 🛒 El sistema permite a los clientes realizar pedidos compuestos por varias líneas de pedido, cada una relacionada con un producto específico.
- 👥 Se diferencian dos tipos de clientes: personal y corporativo, con diferencias en los métodos de pago y en la relación con los vendedores.
- 💳 Los clientes personales pueden pagar con tarjetas de crédito, mientras que los corporativos tienen un contrato con un límite de crédito.
- 🏢 Los clientes corporativos están atendidos por vendedores asignados, que forman parte de la empresa y gestionan una cartera de clientes.
- 🔵 Se deben identificar las clases que modelan los conceptos del dominio del sistema, como Pedido, Línea de Pedido, Producto, Cliente, etc.
- 🔗 Se establecen relaciones entre las clases que reflejen la realidad del sistema, como generalización, asociación, composición y dependencia.
- 👨👧👦 Los clientes (generalización) se dividen en clientes personal y corporativo (especialización).
- 🔗 Se asocia el cliente con los pedidos que realiza, y se establece una relación de composición entre Pedido y Línea de Pedido.
- 🔗 Se establece una relación de agregación entre Línea de Pedido y Producto, y de asociación entre Cliente y su método de pago específico.
- 👔 La relación entre Cliente Corporativo y Vendedor es de tipo asociación, con un vendedor asignado por cliente.
- 💼 Se puede modelar la dependencia entre un Vendedor y el Sistema de Pago utilizado para procesar las ventas.
Q & A
¿Qué es el modelado de la estructura del sistema y cómo se relaciona con el diagrama de clases?
-El modelado de la estructura del sistema es el proceso de diseñar un diagrama de clases que representa los diferentes componentes y sus relaciones en un sistema. Este diagrama de clases es una herramienta de modelado utilizado en la ingeniería del software para visualizar la estructura de los objetos, sus atributos y las relaciones entre ellos.
¿Cuál es el caso práctico que se aborda en el vídeo?
-El caso práctico trata sobre un sistema de gestión de pedidos que permite a los clientes realizar pedidos a una empresa. Este sistema distingue entre clientes personales y clientes corporativos, y tiene un conjunto de vendedores que atienden únicamente a clientes corporativos.
¿Qué diferencia hay entre un cliente personal y un cliente corporativo en el sistema?
-Un cliente personal es una persona que realiza pagos mediante tarjetas de crédito, mientras que un cliente corporativo es una empresa que tiene un contrato con un límite de crédito para realizar compras.
¿Cuál es la relación entre los vendedores y los clientes corporativos?
-Cada vendedor se encarga de una cartera de clientes corporativos, pero un cliente corporativo solo es atendido por un único vendedor.
¿Qué tipo de relaciones se pueden establecer en un diagrama de clases?
-En un diagrama de clases se pueden establecer relaciones de dependencia, asociación, generalización y realización.
¿Cómo se establece una relación de generalización en el diagrama de clases?
-Una relación de generalización se establece cuando una clase es más general y se puede particularizar en dos o más tipos específicos, como se ve entre 'Cliente', 'Cliente Personal' y 'Cliente Corporativo'.
¿Qué es una relación de asociación y cómo se representa en el diagrama de clases?
-Una relación de asociación se establece cuando dos clases están relacionadas pero no una depende de la otra. Se representa con una línea que une las clases y a veces se indica la multiplicidad de la relación.
¿Cuál es la diferencia entre una relación de composición y una de agregación?
-La relación de composición indica que los objetos de una clase forman parte de los objetos de otra clase de tal manera que no pueden existir sin ellos, como las 'Líneas de Pedido' dentro de un 'Pedido'. La relación de agregación es menos fuerte y permite que los objetos de ambas clases existan independientemente, como una 'Línea de Pedido' que consta de varios 'Productos'.
¿Cómo se representa una relación de dependencia en el diagrama de clases?
-Una relación de dependencia se representa con una flecha que apunta desde la clase dependiente hacia la clase de la que depende, generalmente cuando una clase utiliza a otra en sus métodos.
¿Qué detalles se pueden incluir en una clase en el diagrama de clases?
-En una clase se pueden incluir atributos, como la 'Línea de Crédito' en la clase 'Contrato', y operaciones o métodos, como 'Consultar Saldo' en la clase 'Sistema de Pago'.
¿Cómo se determina la multiplicidad en una relación de asociación?
-La multiplicidad se determina por la cantidad de objetos de una clase que pueden estar asociados con los objetos de otra clase. Por ejemplo, un cliente puede tener uno o más pedidos, mientras que un pedido pertenece a un solo cliente.
Outlines
📊 Modelado de la estructura del sistema
El vídeo comienza explicando cómo modelar la estructura de un sistema, específicamente creando un diagrama de clases para un sistema de gestión de pedidos. Se describe el caso práctico de un cliente que realiza pedidos a una empresa, donde cada pedido está compuesto por varias líneas de pedido que a su vez se refieren a productos específicos. Se diferencian dos tipos de clientes: personal y corporativo, con métodos de pago distintos, y se menciona la existencia de vendedores que atienden solo a clientes corporativos. Se enfatiza la importancia de identificar clases y establecer relaciones entre ellas para reflejar adecuadamente el dominio del problema.
🔗 Relaciones entre clases en el diagrama
Este párrafo profundiza en las relaciones entre las clases identificadas en el diagrama de clases. Se explican los cuatro tipos de relaciones: dependencia, asociación, generalización y realización. Se establecen relaciones de generalización entre 'Cliente' y sus subtipos 'Cliente personal' y 'Cliente corporativo', y entre 'Sistema de pago' y sus formas específicas de pago. Se definen relaciones de asociación entre 'Cliente' y 'Pedido', y entre 'Pedido' y 'Línea de pedido', y se diferencian las relaciones de composición de las de agregación. También se menciona la relación de asociación entre 'Cliente corporativo' y 'Vendedor', y la dependencia entre 'Vendedor' y 'Sistema de pago'. Se proporcionan ejemplos de atributos y métodos para algunas clases, como 'Línea de crédito' en la clase 'Contrato' y el método 'consultar saldo' en la clase 'Sistema de pago'.
🎥 Conclusión del vídeo
El vídeo concluye agradeciendo la atención del público y anuncia la continuación de la serie en futuras entregas. El objetivo principal del vídeo es resaltar la importancia de identificar correctamente los conceptos del dominio y modelarlos a través de clases, estableciendo relaciones adecuadas para reflejar fielmente la información del mundo real del caso práctico que se busca resolver.
Mindmap
Keywords
💡Modelado de la estructura del sistema
💡Diagrama de clases
💡Clientes
💡Pedidos
💡Líneas de pedido
💡Productos
💡Clientes personal y corporativo
💡Métodos de pago
💡Relaciones de clases
💡Vendedores
💡Contrato de crédito
Highlights
Introducción al modelado de la estructura del sistema y elaboración del diagrama de clases para un caso práctico.
Explicación del caso práctico de un sistema de gestión de pedidos.
Descripción de los componentes del sistema: clientes, pedidos, líneas de pedido y productos.
Diferenciación entre clientes personales y corporativos y sus métodos de pago.
Importancia de los vendedores en la relación con los clientes corporativos.
Identificación de las clases en el diagrama de clases del sistema.
Uso de anotaciones para representar las clases en el diagrama.
Inclusión de atributos y operaciones en las clases.
Establecimiento de relaciones entre las clases para reflejar la realidad del sistema.
Tipos de relaciones entre clases: dependencia, asociación, generalización y realización.
Relación de generalización entre clientes y sus subtipos personal y corporativo.
Relación de asociación entre cliente y pedido con multiplicidad.
Relación de composición entre pedido y línea de pedido.
Relación de agregación entre línea de pedido y producto.
Relación de asociación entre cliente personal y tarjeta de crédito y cliente corporativo y contrato.
Relación de asociación entre cliente corporativo y vendedor con multiplicidad específica.
Uso de la relación de dependencia entre vendedor y sistema de pago.
Detalles sobre la representación de atributos como la línea de crédito en el contrato.
Inclusión de métodos en las clases, como consultar saldo en el sistema de pago.
Objetivo del modelado basado en diagramas de clases para reflejar la realidad del caso práctico.
Transcripts
Hola bienvenidos
en este vídeo vamos a tratar el modelado de la estructura del sistema
concretamente lo que vamos a hacer es elaborar el diagrama de clases de un caso
práctico
que tenéis para trabajar en el boletín de ejercicios asociado a este tema
bien en este vídeo vamos trabajar el caso práctico que trata acerca de un
sistema de gestión de pedidos
este sistema tata de un cliente que pueda realizar pedidos
a una empresa
cada pedido
nos dice que está formado por varias líneas de pedido
a su vez cada línea pedido se refiere lógicamente
a un producto que se está realizando
el pedido
se diferencian dos tipos de cliente un cliente personal sería una persona particular
y un cliente corporativo una empresa
la diferencia entre otro tipo de clientes es que
el cliente personal va a poder realizar pagos mediante tarjetas de crédito
y el cliente corporativo tiene un contrato con la empresa
y este contrato tiene asociado un límite de crédito el cual le permite realizar
compras a nuestra empresa
además se da la circunstancia de que la empresa tiene un conjunto de
vendedores
que se encargarán de atender peticiones de los clientes corporativos
solamente de los corporativos no de particulares
y será la relación de que cada vendedor
se hace cargo de una cartera de clientes corporativos
pero a un cliente cooperativo
solamente le atiende un único vendedor
dada
este enunciado de un caso práctico
deberemos de realizar
un modelado de estructura del sistema
básicamente
tenemos que hacer un diagrama de clases donde en primer lugar identifiquemos las clases
que pueden modelar bien los conceptos de este dominio
y a continuación deberemos de establecer relaciones entre esas clases
reflejen fielmente lo que
sucede realmente en el mundo real de la aplicación
aunque si analizamos detenidamente el enunciado
veremos que aquellos conceptos que se refieren a cosas de
el dominio aplicación
podrían tratarse a priori como clases de nuestro sistema
así por ejemplo como podéis observar en la trasparencia
podemos identificar
como tipo de clases un pedido
líneas de pedido un producto
clientes y a su vez otro tipo de cliente que existen personal y corporativo
también los métodos de pago como son la tarjeta de crédito o el contrato que se
establece con la empresa
o también una clase de sistema podría ser
los vendedores
que forman parte de esta empresa
una vez que hemos identificado aquellos conceptos y cosas de nuestro dominio
que creemos que pueden valernos para establecer como clases
en nuestor diagrama
iniciaríamos
el dibujo de nuestro diagrama estableciendo las clases
como podéis ver los utilizamos la anotación que ya hemos estudiado a lo
largo de este tema
dónde cada clase pues básicamente es un rectángulo
donde ahora mismo únicamente tenemos un nombre
pero conforme avancemos en el diseño
de la aplicación ampliaremos la información que aquí
insertamos a cada clase
básicamente lo que me estoy refiriendo es a incluir atributos
y operaciones a cada clase
ahora mismo ya hemos identificado a las clases
y el siguiente paso para completar los telegramas de clases
sería estudiar que relacionase se pueden establecerr en estas clases
porque para que un diagrama de clases sea consistente este bien formado
las clases no deberían de quedar aisladas
siempre debe asistir relaciones entre ellas
de forma que se pueda navegar
entre ellas y
manejar y manipular la información de nuestro sistema
pues bien si analizamos nuevamente
el enunciado de este ejercicio ya analizamos el supuesto práctico
podríamos
definir distintos tipos de relaciones
recordad que las relaciones que se establecen entre clases son de cuatro
tipos
tenemos por un lado la relación de dependencia
que se dan cuando una clase depende de otra
por ejemplo una clase en un método recibe un parámetro que es un objeto
de un determinado tipo de clase
la que esta clase
tendría una dependencia sobre otra
una dependencia sería más fuerte y se domina asociación
cuando entre dos clases realmente se establece un vínculo
que las vincula
una clase a y una clase b podemos establecer una asociación
de forma que los objetos instancias de una clase estarían relacionados
con ciertos objetos de otra
en base a criterios que nosotros impongamos
recordad también que existe la generalización entre clases
qué básicamente esto viene a ser la herencia bien conocida la programación
orientada a objetos
y finalmente también la realización entre clases
donde una clase implementa una interfaz o un contrato que se define
si analizamos el enunciado podemos establecer por ejemplo
el siguiente conjunto de relaciones
por ejemplo
algo que es muy claro vemos que
entre las clases cliente cliente personal y clientes corporativos
se puede establecer una relación de generalización
vemos claramente que clientes es una clase más general y que se puede
particularizar en dos tipos personal y corporativo
algo similar sucede con los sistemas de pago
puesto que podemos tener un sistema de pago que es un concepto general
y éste se particularizan dos tipos
cuando se realiza por tarjeta de crédito
o mediante un contrato
que se establece entre el cliente corporativo
y en esta empresa
además de estas relaciones de generalización
podemos científicar otro tipo de relaciones de asociación
por ejemplo vemos que entre cliente en la clase pedido podemos establecer una
relación de asociación
de forma que a cada cliente se le pueda asociar los pedidos que está realizando
notar que también a esta relación le estamos asignando una multiplicidad
de modo que indicamos que un cliente puede tener asociados uno o más pedidos
y que un pedido sólo
pertenece a un único cliente
lo tratamos con el valor 1 en el otro extremo de la asociación
fijaros que entre las relaciones pedido
y línea de pedido y producto también existen dos tipos de la asociación de
relación
dos casos bien distintos por un lado entre pedido y línea de pedido es una
asociación
de tipo composición
porque se da la circunstancia de que un pedido
está formado por un conjunto de líneas de pedido
y recordar que esto se denota mediante un rumbo dónde se rellena
de color negro el contenido este rumbo en el estremo
del mismo modo entre la clase línea de pedido y producto podemos establecer
una relación de asociación
pero en este caso fijaros que
una línea de pedido consta de un conjunto de productos
aquí lo que estamos denotando es una agregación
de forma que una línea de pedido
puede referirse a uno o más productos que se estén solicitando su
pedido
pero aquí no hay una dependencia producto y línea de pedido
es decir si esta asociación se rompe
tiene sentido que sigan existiendo los productos en nuestro sistema
entonces
al no existir esta dependencia en tiempo de vida
la relación no sería de composición
sino que sería de agregación
también podemos establecer más relaciones de asociación
ente cliente personal y tarjeta de crédito o entre cliente corporativo
y contrato
para reflejar lo que nos indica el supuesto práctico
y es que los clientes personales realizan pagos con tarjeta de crédito
y que los clientes corporativos realizan pagos mediante contrato
notar que esta relación
refleja
fielmente lo que nos dice el enunciado
si estableciéramos una relación de asociación
entre cliente
y sistema de pago realmente no estaremos modelando
correctamente sistema
porque de hacerlo así lo que estaríamos diciendo es que cualquier tipo de cliente
puede utilizar cualquier sistema de pago
por ejemplo
un cliente personal puede utilizar tarjeta de crédito o contrato
y esto realmente no es lo que está sucediendo
está restringido el método de pago que pueda realizar cada tipo de cliente
por ello la relación de asociación
debe establecerse entre cliente personal y tarjeta de crédito
y por otro lado entre cliente corporativo
y contrato
finalmente vemos que tenemos también una relación de asociación
entre cliente corporativo y vendedor
que es lo que nos indicaba al final el supuesto práctico
un vendedor tiene una cartera de clientes corporativos y fijaros que la
multiplicidad que asignamos es muchos, un asterisco
pero un cliente corporativo sólamente tiene un único vendedor por ello la
multiplicidad sería 1
y por último el tercer tipo de relación la que utilizamos en nuestro diagrama de clases
sería la de dependencia
y por ejemplo
la podemos utilizar entre un vendedor de un sistema de pago
de forma que
cuando se realiza una venta en este sistema
ésta tiene asociado
un sistema de pago en concreto con el que se analiza esa operación
y finalmente a modo de ejemplo aunque este supuesto práctico no nos facilita
mucha información de sistema
si que os quería mostrar
algunos detalles que podríamos dar a acerca de algunas clases
por ejemplo
en el ensayo práctico nos habla de una línea de crédito que tiene asociada un
contrato que se establece entre nuestra empresa
y los clientes corporativos
esta línea de crédito podría moderarse como un atributo
de la clase contrato
y fijaros que este atributo decimos que es visible públicamente externo
por ello le ponemos el símbolo más
y decimos que este atributo seria de tipo y por internet admite tipo integerde tipo entero
del mismo modo
otro tipo de información que podríamos ver en nuestro modelado de clases
es que la clase y sistema de pago puede tener un método que sería consultar saldo
que devolvería un valor entero que sería el saldo disponible
en esta
tarjeta de crédito o bien en este contrato
para realizar compras
en nuestro sistema
como podéis ver
el objetivo principal
de un modelado basado en un diagrama de clases
es que identifiquemos correctamente los conceptos de nuestros dominios
y qué esos conceptos que los programamos mediante clases
sepamos relacionarnos de forma adecuada
para que se esté reflejando fielmente
la información
del mundo real del caso práctico
que estamos intentando resolver
muy bien gracias por vuestra atención y nos vemos en próximos vídeos
関連動画をさらに表示
Tutorial - Diagrama de Clases UML
🚀 MÉTODOS CONSTRUCTORES y OBJETOS en JAVA | 🤔| POO con Java 🖥️ | Explicación FÁCIL 2023 | #4
🚀 CLASES ABSTRACTAS en JAVA | 🤔| Programación Orientada a Objetos 🖥️ | Explicación FÁCIL 2023 | #9
CASO USO UML
Base de Datos #3| Ejercicio Diagrama Entidad Relación
Curso Java. Estructuras principales VI. Clase Math. Vídeo 9
5.0 / 5 (0 votes)