Introducción

La programación orientada a objetos (POO) es un paradigma de programación

que se basa en la creación de objetos, los cuales tienen propiedades (atributos) y
comportamientos (métodos). Es una forma de programación muy utilizada en la
actualidad, ya que permite la creación de aplicaciones más eficientes, escalables
y fáciles de mantener.
En este trabajo se abordará la programación orientada a objetos desde una
perspectiva teórica y práctica. En primer lugar, se describirán los conceptos
fundamentales de la POO, como las clases, los objetos, los métodos y los
atributos. También se hablará sobre los principios SOLID, que son una serie de
reglas que nos ayudan a escribir código más eficiente y fácil de mantener.
1. Explicar la diferencia del diseño orientado a objeto y el diseño
estructurado.
El diseño orientado a objetos (OO) y el diseño estructurado son dos enfoques
diferentes para diseñar sistemas de software. Ambos enfoques tienen sus
propias fortalezas y debilidades, y es importante entender la diferencia entre
ellos para poder elegir el enfoque adecuado para un proyecto en particular.
El diseño estructurado es un enfoque más antiguo que se centra en la división
del software en componentes estructurales que interactúan mediante el
intercambio de información. El diseño estructurado se basa en la premisa de que
el software se puede dividir en pequeñas unidades funcionales, que se pueden
analizar y diseñar de manera independiente. El enfoque estructurado utiliza
diagramas de flujo de datos (DFD) y diagramas de estructura (DS) para
describir la estructura del sistema.
Por otro lado, el diseño orientado a objetos es un enfoque más moderno que se
centra en la descripción de los componentes del software como objetos que
interactúan entre sí para realizar una tarea. Los objetos son unidades de software
que encapsulan datos y comportamiento relacionados. Los objetos se organizan
en clases que definen las propiedades y métodos comunes a todos los objetos de
esa clase. El diseño orientado a objetos utiliza diagramas de clases y diagramas
de objetos para describir la estructura del sistema.
En general, el enfoque de diseño orientado a objetos es más adecuado para
sistemas de software grandes y complejos, mientras que el enfoque estructurado
es más adecuado para sistemas más pequeños y simples. El diseño orientado a
objetos se enfoca en la reutilización del código, lo que significa que el código se
puede utilizar en diferentes partes del sistema. El diseño estructurado se enfoca
en la claridad y la simplicidad, lo que significa que es más fácil de entender y
mantener.
En resumen, la diferencia principal entre el diseño orientado a objetos y el
diseño estructurado es que el diseño orientado a objetos se enfoca en los objetos
y sus interacciones, mientras que el diseño estructurado se enfoca en la división
del software en pequeñas unidades funcionales. Cada enfoque tiene sus ventajas
y desventajas y se debe elegir según las necesidades específicas del proyecto de
software.
2. Característica de la programación orientación a objeto
La programación orientada a objetos (POO) es un paradigma de programación
que se centra en la creación de objetos, que son instancias de clases, para
resolver problemas. La POO tiene varias características clave que la diferencian
de otros paradigmas de programación. A continuación, se presentan algunas de
las características más importantes de la programación orientada a objetos:
Abstracción: la abstracción es la capacidad de representar un objeto en términos
de sus características esenciales y ocultar los detalles irrelevantes. En la POO,
se utiliza la abstracción para definir las clases y sus atributos y métodos.
Encapsulamiento: el encapsulamiento es la capacidad de ocultar los detalles
internos de un objeto y solo exponer los métodos y atributos que son necesarios
para interactuar con él. El encapsulamiento en la POO se logra a través del uso
de modificadores de acceso, como public, private y protected.
Herencia: la herencia es la capacidad de una clase de heredar atributos y
métodos de otra clase. En la POO, la herencia se utiliza para crear nuevas clases
basadas en una clase existente.
Polimorfismo: el polimorfismo es la capacidad de un objeto de tener múltiples
formas o comportamientos. En la POO, el polimorfismo se logra a través del
uso de métodos y sobrecarga de operadores.
Clases y objetos: la POO se basa en la creación de clases, que son plantillas o
moldes para crear objetos. Los objetos son instancias de una clase y tienen
atributos y métodos.
Reutilización de código: la POO fomenta la reutilización de código a través de
la herencia y la composición. Los programadores pueden crear nuevas clases y
objetos utilizando código existente.
En resumen, la programación orientada a objetos es una forma de programación
que se centra en la creación de objetos para resolver problemas. La POO tiene
varias características clave, como la abstracción, el encapsulamiento, la
herencia, el polimorfismo y la reutilización de código, que hacen que sea un
paradigma de programación poderoso y flexible.
3. Lenguaje Unificado de Modelado (UML)
El Lenguaje Unificado de Modelado (UML, por sus siglas en inglés) es un
lenguaje de modelado visual utilizado para describir, especificar, construir y
documentar sistemas de software orientados a objetos. El UML se desarrolló
como un esfuerzo conjunto de un grupo de expertos en la industria del software,
liderado por Grady Booch, James Rumbaugh e Ivar Jacobson, y se ha
convertido en un estándar de facto para la documentación de software.
El UML utiliza una serie de diagramas para representar diferentes aspectos de
un sistema de software. A continuación, se describen algunos de los diagramas
más comunes utilizados en el UML:
Diagrama de clases: el diagrama de clases es el diagrama más común en el
UML. Se utiliza para representar la estructura estática de un sistema, mostrando
las clases y sus relaciones, atributos y métodos.
Diagrama de secuencia: el diagrama de secuencia se utiliza para representar la
interacción dinámica entre objetos del sistema en un orden temporal.
Diagrama de estados: el diagrama de estados se utiliza para representar el
comportamiento de un objeto en diferentes estados y transiciones entre ellos.
Diagrama de actividades: el diagrama de actividades se utiliza para
representar el flujo de control de un proceso o actividad en el sistema.
Diagrama de componentes: el diagrama de componentes se utiliza para
representar la estructura física del sistema, mostrando los componentes y sus
relaciones.
Diagrama de despliegue: el diagrama de despliegue se utiliza para representar
la configuración del sistema en términos de hardware y software, mostrando los
nodos y sus relaciones.
En resumen, el UML es un lenguaje de modelado visual utilizado para describir,
especificar, construir y documentar sistemas de software orientados a objetos.
Utiliza una serie de diagramas para representar diferentes aspectos de un
sistema, incluyendo la estructura estática, la interacción dinámica, el
comportamiento, la estructura física y la configuración del sistema.
4. Definición Diagrama de clases según Lenguaje Unificado de Modelado
(UML)
En el Lenguaje Unificado de Modelado (UML), un diagrama de clases es un
tipo de diagrama utilizado para representar la estructura estática de un sistema
de software orientado a objetos. El diagrama de clases muestra las clases del
sistema, sus atributos y métodos, y las relaciones entre ellas.
En un diagrama de clases, las clases se representan como rectángulos divididos
en tres secciones: la sección superior contiene el nombre de la clase, la sección
del medio contiene los atributos de la clase, y la sección inferior contiene los
métodos de la clase. Las relaciones entre las clases se representan mediante
líneas que conectan los rectángulos de las clases.
Hay varios tipos de relaciones que se pueden representar en un diagrama de
clases:
Asociación: una asociación representa una relación entre dos clases. Puede tener
un nombre y una multiplicidad que indica cuántas instancias de cada clase
pueden estar involucradas en la asociación.
Herencia: la herencia se representa mediante una línea punteada con una flecha
que apunta desde la clase hija a la clase padre. La clase hija hereda los atributos
y métodos de la clase padre.
Implementación: la implementación se representa mediante una línea punteada
con una flecha que apunta desde una clase a una interfaz. Indica que la clase
implementa la interfaz y proporciona una implementación para todos los
métodos de la interfaz.
Agregación: la agregación representa una relación entre dos clases en la que una
clase contiene una o varias instancias de otra clase. Se representa mediante una
línea con un rombo en el extremo que apunta a la clase que contiene las
instancias.
Composición: la composición es similar a la agregación, pero la clase que
contiene las instancias es responsable de su ciclo de vida. Se representa
mediante una línea sólida con un rombo lleno en el extremo que apunta a la
clase que contiene las instancias.
En resumen, un diagrama de clases en UML es un tipo de diagrama utilizado
para representar la estructura estática de un sistema de software orientado a
objetos. Se utiliza para mostrar las clases, sus atributos y métodos, y las
relaciones entre ellas, incluyendo la asociación, la herencia, la implementación,
la agregación y la composición.
5. Miembros de una clase, atributos y métodos (Explicar con ejemplos
todos los anterior)
En programación orientada a objetos, una clase es una plantilla que define la
estructura y el comportamiento de un objeto. Cada instancia de la clase es un
objeto que tiene sus propios valores de atributos y puede llamar a sus propios
métodos.

Los miembros de una clase se dividen en dos categorías: atributos y métodos.

Atributos: son las propiedades o características de un objeto. Son variables que

almacenan datos que describen el estado de un objeto. Por ejemplo, una clase
"Persona" podría tener atributos como nombre, edad, dirección, etc.

Métodos: son las funciones que realizan acciones en un objeto o en relación a

él. Son acciones que pueden ser llamadas por una instancia de la clase. Por
ejemplo, una clase "Persona" podría tener métodos como caminar, hablar,
respirar, etc.

En la mayoría de los lenguajes de programación orientados a objetos, los

miembros de una clase pueden ser privados, protegidos o públicos. Los
atributos y métodos privados solo se pueden acceder dentro de la clase, mientras
que los atributos y métodos protegidos solo se pueden acceder dentro de la clase
y sus subclases. Los atributos y métodos públicos son accesibles desde
cualquier lugar fuera de la clase.
6. Visibilidad (Explicar con ejemplos todos los anterior)
La visibilidad en el diseño orientado a objetos se refiere a la forma en que los
miembros de una clase (atributos y métodos) pueden ser accedidos y utilizados
por otras clases en un programa. La visibilidad se define mediante el uso de
modificadores de acceso, que son palabras clave que se utilizan en la
declaración de los miembros de una clase para indicar quién tiene acceso a
ellos.

Hay tres tipos de modificadores de acceso en la mayoría de los lenguajes de

programación orientados a objetos:

Public: Los miembros públicos de una clase son accesibles desde cualquier
parte del programa. Es decir, otras clases pueden acceder a ellos directamente
sin restricciones.

Private: Los miembros privados de una clase solo son accesibles dentro de la
propia clase. No pueden ser accedidos desde otras clases.

Protected: Los miembros protegidos de una clase son similares a los privados,
ya que solo son accesibles dentro de la propia clase. Sin embargo, las clases
hijas o subclases de la clase pueden acceder a los miembros protegidos.

La visibilidad es importante en el diseño orientado a objetos porque ayuda a

controlar el acceso a los miembros de una clase y a evitar que otros
componentes del programa los modifiquen de manera incorrecta. Además, una
buena práctica de diseño de clases es hacer que los miembros sean privados por
defecto y solo exponerlos públicamente cuando sea necesario para un uso
externo de la clase.
7. Clasificadores.
En el contexto del lenguaje unificado de modelado (UML), un clasificador es
cualquier cosa que pueda ser descrita y definida mediante una especificación,
como una clase, interfaz, componente o caso de uso. Los clasificadores se
utilizan para modelar los elementos de un sistema y sus relaciones.
A continuación, se describen los tipos de clasificadores más comunes en UML:
Clase: una clase es un tipo de clasificador que describe una colección de objetos
con características comunes, como atributos, operaciones y relaciones. Por
ejemplo, una clase "Persona" puede tener atributos como "nombre", "edad" y
"dirección", y operaciones como "caminar" o "hablar".
Interfaz: una interfaz es un tipo de clasificador que define un conjunto de
operaciones que una clase u otro tipo de objeto debe implementar. Por ejemplo,
una interfaz "Volador" puede definir la operación "volar", que deberá ser
implementada por las clases que implementen esa interfaz.
Componente: un componente es un tipo de clasificador que representa una
unidad física, modular y reutilizable de un sistema que puede ser desplegado e
independiente de otros componentes. Por ejemplo, un componente "Base de
datos" puede contener los datos del sistema y ser utilizado por otros
componentes del sistema.
Caso de uso: un caso de uso es un tipo de clasificador que representa la
descripción de una funcionalidad del sistema que es realizada por el usuario.
Por ejemplo, un caso de uso "Registrar usuario" describe el proceso que un
usuario realiza para registrarse en un sistema.
Artefacto: un artefacto es un tipo de clasificador que representa cualquier
elemento físico o lógico que sea necesario para la construcción, implementación
o despliegue de un sistema. Por ejemplo, un artefacto "Archivo de
configuración" puede contener la configuración del sistema.
En resumen, los clasificadores son elementos fundamentales del lenguaje
unificado de modelado que se utilizan para describir y definir los elementos de
un sistema. Los tipos de clasificadores más comunes son la clase, interfaz,
componente, caso de uso y artefacto. Cada uno de ellos tiene características y
propósitos específicos que los hacen útiles en diferentes contextos de modelado.
8. Investigar como elaborar un diagrama de clase a partir de un análisis de
un software.
Para elaborar un diagrama de clases a partir del análisis de un software, se
pueden seguir los siguientes pasos:
Identificar los requisitos del software: El primer paso es entender qué es lo
que se espera que el software haga, cuáles son las funcionalidades que debe
tener y qué requisitos debe cumplir. Esto puede hacerse a través de entrevistas
con los usuarios, revisión de documentación o análisis de procesos.
Identificar los objetos: Una vez que se conocen los requisitos, se debe
identificar qué objetos estarán involucrados en el sistema. Los objetos pueden
ser cosas concretas (como una factura, un producto, un cliente) o cosas
abstractas (como un proceso, una transacción, una sesión de usuario).
Identificar las clases: A partir de los objetos identificados, se deben agrupar en
clases. Una clase es una plantilla que define las propiedades y comportamientos
de un grupo de objetos. Por ejemplo, si se identifican objetos como "Factura",
"Producto" y "Cliente", se puede crear una clase "Venta" que contenga
información de estas tres entidades.
Definir los atributos: Los atributos son las características que tienen los
objetos de una clase. Por ejemplo, si se tiene una clase "Producto", los atributos
pueden ser "Nombre", "Descripción", "Precio", etc.
Definir los métodos: Los métodos son las operaciones que pueden realizarse
sobre los objetos de una clase. Por ejemplo, si se tiene una clase "Producto", los
métodos pueden ser "Agregar al carrito", "Eliminar del carrito", "Calcular el
precio total", etc.
Definir las relaciones: Las relaciones entre clases indican cómo están
conectados los objetos. Por ejemplo, si se tiene una clase "Cliente" y una clase
"Venta", se puede establecer una relación "Uno a muchos", donde un cliente
puede tener varias ventas.
Refinar el diagrama: Una vez que se han identificado las clases, atributos,
métodos y relaciones, se debe refinar el diagrama para hacerlo más claro y fácil
de entender. Se pueden agregar notas, comentarios o restricciones para aclarar
el diseño.
En resumen, para elaborar un diagrama de clases a partir del análisis de un
software, se deben identificar los requisitos del software, identificar los objetos,
definir las clases, atributos, métodos y relaciones, y refinar el diagrama para
hacerlo más claro y fácil de entender. Es importante que el diagrama refleje con
precisión la estructura y el comportamiento del software que se está analizando.
9. Explicar los siguientes conceptos y con ejemplos (no tienen que
programar) abstracción, encapsulación, herencia, polimorfismo.
Abstracción: La abstracción es un concepto clave de la programación orientada
a objetos. Se refiere a la capacidad de enfocarse en los aspectos esenciales de un
objeto o sistema, y de ignorar los detalles irrelevantes. En otras palabras, la
abstracción permite definir un objeto en términos de sus propiedades y
comportamientos esenciales, sin preocuparse por cómo se implementa
internamente.
Por ejemplo, si se quiere modelar un automóvil en un programa de
computadora, se pueden definir las propiedades esenciales como el modelo, la
marca, el año de fabricación, la capacidad del motor, etc. y los comportamientos
esenciales como arrancar, frenar, acelerar, etc. Sin embargo, no es necesario
conocer detalles como la estructura del motor, el diseño de la suspensión, etc.
Encapsulación: La encapsulación se refiere al proceso de ocultar la
complejidad de un objeto o sistema, y exponer solamente una interfaz
simplificada para interactuar con él. En otras palabras, la encapsulación permite
definir un objeto como una caja negra, donde los detalles internos están ocultos
y solo se pueden acceder a través de métodos públicos.
Por ejemplo, si se tiene una clase "Cuenta Bancaria", se pueden definir métodos
públicos como "depositar", "retirar" y "consultar saldo", que permiten
interactuar con el objeto. Sin embargo, los detalles internos de cómo se maneja
el saldo, cómo se realizan las transacciones, etc. están ocultos.
Herencia: La herencia es un concepto que permite crear nuevas clases a partir
de clases existentes, tomando sus propiedades y comportamientos y
añadiéndoles nuevas características. En otras palabras, la herencia permite
definir una relación de "es un tipo de" entre clases.
Por ejemplo, si se tiene una clase "Animal", se pueden definir clases más
específicas como "Perro" y "Gato", que heredan las propiedades y
comportamientos de la clase "Animal" y añaden nuevas características propias
de los perros y gatos.
Polimorfismo: El polimorfismo se refiere a la capacidad de un objeto de
comportarse de diferentes maneras según el contexto en el que se encuentra. En
otras palabras, el polimorfismo permite definir un objeto como una instancia de
una clase específica, pero también como una instancia de una clase más general
que lo contiene.
Por ejemplo, si se tiene una clase "Vehículo", se pueden definir clases más
específicas como "Automóvil" y "Camión". Si se define un método "conducir"
que opera sobre objetos de tipo "Vehículo", se puede llamar a este método tanto
sobre un objeto de tipo "Automóvil" como sobre un objeto de tipo "Camión", y
el comportamiento será diferente según el contexto.

10- Modulación de la información.

La modulación de la información es un principio fundamental en la
programación orientada a objetos (POO), que se refiere a la capacidad de dividir
nuestro código en módulos o componentes más pequeños y especializados, de
tal manera que cada uno de ellos tenga una función específica y claramente
definida.

En la POO, los módulos se representan mediante las clases, que son estructuras
que encapsulan datos y comportamientos relacionados. Cada clase es un módulo
independiente, que puede comunicarse con otros módulos mediante la
definición de interfaces claras y bien definidas.

La modulación de la información es importante porque nos permite escribir

código más fácil de entender, mantener y modificar. Si nuestro código está
dividido en módulos bien definidos, podemos trabajar en cada uno de ellos por
separado, sin afectar al resto del sistema.

Además, la modulación de la información nos permite reutilizar código de

forma eficiente, ya que podemos utilizar módulos existentes en lugar de escribir
código nuevo desde cero. Esto nos permite ahorrar tiempo y reducir la
complejidad del sistema en general.

En resumen, la modulación de la información es un principio fundamental en la

POO, que nos permite dividir nuestro código en módulos bien definidos y
especializados. Al hacerlo, podemos escribir código más fácil de entender,
mantener y modificar, y también podemos reutilizar código de forma eficiente.
11- Tipos de asociaciones entre clases, definirla y como se representan

En programación orientada a objetos, las asociaciones entre clases son las

relaciones que existen entre distintas clases de un sistema. Hay varios tipos de
asociaciones, que se pueden definir de la siguiente manera:
Asociación simple: es una relación básica entre dos clases, donde una clase
conoce a la otra y puede interactuar con ella. Se representa con una línea sólida
que une las dos clases, y se puede agregar una flecha para indicar la dirección
de la relación (si es que existe una dirección).
Asociación bidireccional: es una asociación simple en la que las dos clases se
conocen y pueden interactuar entre sí. Se representa con una línea sólida que
une las dos clases, sin flechas.
Asociación unidireccional: es una asociación simple en la que una clase
conoce a la otra, pero la segunda clase no conoce a la primera. Se representa
con una línea sólida y una flecha que apunta a la clase que conoce a la otra.
Asociación de agregación: es una relación en la que una clase representa a un
conjunto de objetos de otra clase. Se representa con una línea que une las dos
clases, y en la clase que representa el conjunto se puede dibujar un rombo vacío
en el extremo de la línea que indica la dirección de la asociación.
Asociación de composición: es una relación en la que una clase representa a un
conjunto de objetos de otra clase y es responsable de crear y destruir esos
objetos. Se representa con una línea que une las dos clases, y en la clase que
representa el conjunto se dibuja un rombo lleno en el extremo de la línea que
indica la dirección de la asociación.
Asociación de dependencia: es una relación en la que una clase utiliza los
servicios de otra clase, pero no mantiene una referencia a ella. Se representa con
una línea punteada que une las dos clases, y se puede agregar una flecha para
indicar la dirección de la relación.
En resumen, las asociaciones entre clases representan las relaciones entre
distintas clases de un sistema. Cada tipo de asociación tiene una definición
específica y se representa de manera diferente en un diagrama de clases. Estos
diagramas son herramientas útiles para modelar sistemas complejos y entender
cómo interactúan sus componentes.

12- Diferencias entre Composición y Agregación.

En programación orientada a objetos, la composición y la agregación son dos
tipos de asociaciones entre clases que se utilizan para representar relaciones
entre objetos en un sistema. Aunque ambas están relacionadas con la idea de
que una clase contiene a otra, hay diferencias importantes entre composición y
agregación:
Propiedad de la relación: En la composición, una clase "posee" a la otra clase
y es responsable de crear y destruir sus objetos. En la agregación, una clase
"conoce" a la otra clase, pero no es responsable de crear ni destruir sus objetos.
Tiempo de vida de los objetos: En la composición, los objetos de la clase
contenida existen solo mientras la clase contenedora existe. En la agregación,
los objetos de la clase contenida pueden existir independientemente de la clase
contenedora.
Cardinalidad: En la composición, la cardinalidad es siempre 1:1 o 1:N, lo que
significa que una instancia de la clase contenedora solo puede contener una
instancia de la clase contenida (o varias instancias de la clase contenida). En la
agregación, la cardinalidad puede ser 0:1, 1:1, 0:N o 1:N, lo que significa que
una instancia de la clase contenedora puede contener cero o varias instancias de
la clase contenida.
Para entender mejor las diferencias, aquí hay un ejemplo:
Supongamos que queremos modelar una biblioteca que contiene libros.
Podríamos usar la composición para representar la relación entre la biblioteca y
los libros, ya que una biblioteca posee los libros y es responsable de crearlos y
destruirlos. En este caso, la biblioteca tendría una lista de libros que contiene
todas las instancias de la clase Libro.
Por otro lado, podríamos usar la agregación para representar la relación entre la
biblioteca y los autores de los libros, ya que la biblioteca solo conoce a los
autores y no es responsable de crearlos ni destruirlos. En este caso, la biblioteca
tendría una lista de autores que contiene todas las instancias de la clase Autor, y
cada instancia de Autor tendría una lista de libros que contiene todas las
instancias de la clase Libro que ha escrito.
En resumen, la composición y la agregación son dos tipos de asociaciones entre
clases que se utilizan para representar diferentes tipos de relaciones entre
objetos. La elección entre composición y agregación depende de las necesidades
del sistema que se está modelando.

13- Como dibujar un diagrama de clases y explicar con un ejemplo

Para hacer un diagrama de clases, sigue estos pasos:
1. Identifica las clases: Haz una lista de todas las clases relevantes en tu
sistema o aplicación. Por ejemplo, si estás creando un sistema de gestión
de biblioteca, las clases podrían ser Libro, Usuario, Biblioteca, etc.
2. Identifica las relaciones: Identifica las relaciones entre las clases. Por
ejemplo, un Usuario puede tomar prestado varios Libros, pero un Libro
solo puede ser prestado a un Usuario a la vez.
3. Dibuja las clases: Dibuja cada clase como un rectángulo con su nombre
en la parte superior.
4. Dibuja las relaciones: Dibuja las relaciones entre las clases como líneas
entre los rectángulos. Usa flechas para indicar la dirección de la relación.
Por ejemplo, si un Usuario puede tomar prestado varios Libros, dibuja
una línea de Usuario a Libro con una flecha que apunte hacia Libro.
5. Agrega atributos y métodos: Si es necesario, agrega los atributos y
métodos a las clases. Por ejemplo, un Libro podría tener un atributo de
título y un método de devolución.
 6. Ajusta el diagrama: Ajusta el diagrama para que sea fácil de leer y
entender. Agrupa las clases relacionadas juntas y coloca las clases más
importantes en la parte superior del diagrama.
7. Agrega notas: Agrega notas si es necesario para aclarar cualquier aspecto
del diagrama que no sea evidente.
Recuerda que un diagrama de clases es una representación visual de tu sistema
o aplicación, y que puede ser tan simple o complejo como sea necesario.

Conclusión
En definitiva, la programación orientada a objetos es una herramienta poderosa
para el desarrollo de software, y es esencial que los programadores dominen los
conceptos y técnicas relacionadas con este paradigma. Esperamos que este
trabajo haya sido útil para comprender los fundamentos de la POO y para
aplicarlos en el propio trabajo de programación.
Fuentes

https://www.ibm.com/docs/es/spss-modeler/saas?topic=language-object-
oriented-programming.
https://diagramasuml.com/.
https://diagramasuml.com/diagrama-de-clases/