# Curso de UML

:::info
## Tabla de Contenido:
[TOC]
:::

## Diagramas de Clases:

En un diagrama de clases, se representan tanto las clases como las relaciones entre ellas. Las clases representan tipos de objetos que comparten características y comportamientos en común. Estas características y comportamientos se definen mediante atributos y métodos, respectivamente. Las asociaciones en el diagrama de clases representan las relaciones entre las clases, como la composición, agregación y herencia. En resumen, un diagrama de clases es una herramienta importante para modelar la estructura de un sistema orientado a objetos y las relaciones entre sus componentes.

#### Ejemplo:

| Estudiante |
|--------|
| |
| |

No se separan con nada las palabras, solo se empieza con mayuscula.

| EstudianteUniversitario |
|--------|
| |

Los objetos son representaciones específicas de una clase que han adquirido valores. Usando una analogía de planos y casas, podemos decir que, al igual que un plano puede servir para construir múltiples casas, una clase puede utilizarse para crear varios objetos. Sin embargo, así como un plano no es una casa, una clase no es un objeto en sí mismo. En la programación orientada a objetos, los objetos se representan como variables que contienen datos y métodos que les permiten realizar acciones específicas.

| Estudiante |
|--------|
|- nombre: String |
|- DNI: Int |
|-fechaNacimiento: Date|

| g1:Estudiante|
|--------|
| nombre: "Pablo"|
| DNI: 23341223434343 |
| fechaNacimiento: 1/5/2000|

>Se utiliza una convención de notación para diferenciar los diferentes tipos de datos en un sistema. Se utiliza el signo "-" para denotar datos que son privados, es decir, que solo pueden ser accedidos dentro del objeto. Por otro lado, el signo "+" indica que el dato es público y puede ser accedido desde cualquier parte del programa. Además, se utiliza el símbolo "#" para indicar que el dato solo puede ser visto por las subclases del objeto en cuestión. Esta notación ayuda a mantener la claridad y la organización en el diseño de sistemas y objetos.

## Enumerations

Users can define data types called enumerations, which contain a set of integer constants with unique names that define the range of allowed values.

|<<Enumeration>>| ProgramType|
|----------------|
| ARCHITECTURE |
| ENGINEERING |
| SCIENCES |

| g1:Student|
|--------|
| name: "Pablo"|
| ID: 23341223434343 |
| birthdate: 1/5/2000|
|- program: SCIENCES|

## Methods

Methods are actions related to the class that allow each object of that class to perform a specific task. These methods are used to model the behavior of objects and are represented in the third compartment of the UML diagram, along with the attributes. Like attributes, methods have visibility, a name, and can have a return type in case they need to return a value. However, some methods may not require a return value.

Student|
|----------|
|-name: String|
|-id: Int |
|-birthdate: Date |
|-program: ProgramType |
|+getName():String |
|+setName(String) |
|+getBirthdate(): Date |
|+getProgram(): ProgramType |
|+setProgram(ProgramType)|

- The responsibility of manipulating the information lies with its owner.
- Encapsulation allows objects to keep their attributes hidden and can only be manipulated through their methods.
- Who does what? The information owner handles its manipulation and encapsulation allows objects to maintain privacy of their attributes and can only be accessed through specific methods.

## Associations

Associations represent the relationships between different classes. An association is related to two classes.
The relationship between classes is represented by a line that connects them, which allows us to visualize how they are related to each other.
The reading direction is also specified, regardless of whether it is from left to right or from right to left.

## Cardinality

- Our simplest cardinality is 1 to 1.

- The next cardinality is 0 to 1.

- The many cardinality is expressed with *.


## Rol

En una asociación, los objetos se sitúan en los extremos y se les asigna explícitamente un rol que describe su función en la relación de manera clara.

La navegabilidad en la programación orientada a objetos se refiere a la forma en que las instancias de una clase pueden acceder entre sí. Para indicar la dirección de la navegabilidad se utiliza una flecha que señala la dirección permitida. Las instancias que se encuentran al final de la flecha pueden ser accedidas por las instancias al inicio de la misma, pero no al contrario. En los casos en los que no se especifica una dirección de la flecha, se entiende que la navegabilidad es bidireccional, lo que significa que las instancias pueden accederse mutuamente.

Supongamos que tenemos dos clases, **Sala** y **Conferencia**, en las cuales un curso puede ser impartido en una o varias salas. Esta relación entre las dos clases se conoce como cardinalidad. En la abstracción que estamos manejando, tiene sentido que se pueda acceder a las salas desde las instancias de una conferencia, pero no al revés, ya que sería menos práctico. Por lo tanto, se ha decidido establecer una navegabilidad unidireccional en dirección de la clase Sala.

## Herencia

Imaginemos que tenemos dos clases: "Animal" y "Perro". La clase "Animal" podría tener los siguientes atributos y métodos:

- Atributos: edad, nombre, especie
- Métodos: comer(), dormir(), moverse()

La clase "Perro" heredaría los atributos y métodos de la clase "Animal", pero además tendría sus propios atributos y métodos específicos, como por ejemplo:

- Atributos adicionales: raza, color, tamaño
- Métodos adicionales: ladrar(), perseguir pelota(), morder()

Podríamos representar esta herencia en UML mediante un diagrama de clases, donde "Perro" sería una subclase de "Animal". La representación gráfica sería similar a esta:

          +-----------------+
          |     Animal      |
          +-----------------+
          | edad: int       |
          | nombre: string  |
          | especie: string |
          +-----------------+
          | comer()         |
          | dormir()        |
          | moverse()       |
          +-----------------+
                   ^
                   |
          +-----------------+
          |      Perro      |
          +-----------------+
          | raza: string    |
          | color: string   |
          | tamaño: string  |
          +-----------------+
          | ladrar()        |
          | perseguir pelota()|
          | morder()        |
          +-----------------+

En este ejemplo, podemos ver que la clase "Perro" hereda los atributos y métodos de la clase "Animal", y además tiene sus propios atributos y métodos específicos. De esta forma, podemos reutilizar el código de la clase **Animal** y evitar tener que escribir nuevamente los atributos y métodos que ya existen en la clase **Animal**.

En términos generales, en la herencia de clases se cumple lo siguiente: en primer lugar, las subclases adquieren los atributos, asociaciones y métodos de la superclase, lo que significa que las instancias de las subclases contienen tanto sus propios atributos como los de la superclase. En segundo lugar, las subclases pueden añadir nuevos atributos, asociaciones y métodos, lo que se traduce en una especialización de la superclase por parte de la subclase. En tercer lugar, las subclases tienen la capacidad de redefinir o implementar métodos y atributos de la superclase dentro de la subclase.

Las clases abstractas tienen como finalidad principal establecer una estructura jerárquica de conceptos, permitiendo una clasificación sistemática de los mismos. Por ejemplo, se puede organizar a los animales en categorías como vertebrados e invertebrados, o agrupar vehículos según su tipo, como automóviles, aviones y barcos. De igual manera, se pueden clasificar figuras geométricas en elipses, rectángulos y triángulos, entre otras categorías posibles.

## Asociaciones

Las asociaciones compuestas denotan relaciones de agregación, donde una clase es el todo y la otra clase representa una de las partes de dicho todo. En otras palabras, la agregación es una asociación entre dos clases donde una contiene partes que forman el todo. Por ejemplo, un carro tiene un motor, cuatro llantas y un sistema electrónico, mientras que un libro tiene un prólogo, varios capítulos y una bibliografía.

Cuando se forma una asociación entre objetos, se establece una conexión completa entre todas las instancias que representan el rol de la clase. En este contexto, la creación y la eliminación de dichas instancias depende completamente de los objetos a los que pertenecen. Es decir, se crea una interdependencia entre los objetos que conforman la asociación y su manipulación debe ser cuidadosamente gestionada para evitar problemas en el sistema.

## Asociaciones Compartidas

Las asociaciones compartidas son un tipo de relación que se refiere a la agregación. La agregación establece una conexión entre dos clases, una de las cuales representa el todo, mientras que la otra representa una parte del todo, en otras palabras, las partes que forman un todo. En comparación con las asociaciones compuestas, las asociaciones compartidas en la especificación de UML tienen menos limitaciones y restricciones.

## Relacion de Dependencias

La relación de dependencia entre dos clases se produce cuando una de ellas necesita de la otra para su correcta implementación, ya sea a nivel semántico o estructural. Este tipo de relación también se conoce como **cliente-proveedor**, puesto que una de las clases actúa como proveedor y suministra los elementos necesarios para que la otra clase, el cliente, pueda llevar a cabo su tarea de forma adecuada. Las dependencias entre clases son una parte fundamental en el modelado de sistemas, ya que permiten definir la interacción y el flujo de datos entre diferentes componentes.

         +----------+               +-----------+
         |   ClaseA |<--------------|   ClaseB  |
         +----------+               +-----------+

En este ejemplo, la clase A depende de la clase B para su implementación, lo que significa que la clase A utiliza algún elemento o método de la clase B. La flecha punteada indica la dirección de la dependencia, que va desde la clase dependiente (ClaseA) hacia la clase proveedora (ClaseB). Esto significa que si la clase B cambia, puede afectar la implementación de la clase A.

## Caso Practico de la Fundacion:

Se crea en base a los conocimientos adquiridos, un diagrama de clase complejo sobre la Fundacion y el servicio social.


En este caso se puede ver que entre la clase Alumno y la clase Servicio Social existe una asociacion en la cual un servicio social podria tener 0 o varios alumnos, pero el alumno solo puede estar en un servicio social, en el caso de RegistroAlumno y DecentralizedFOundation, existe una Asociacion abierta compartida, ya que a pesar de que el alumno pertenece a la Fundacion no necesariamente es parte unicamente de ello, ya que puede estar cursando su carrera a la par de que hace el servicio ahi, asi como que se tiene que la asociacion es que Decentralized puede tener 0 o varios alumnos, y Alumno puede estar en Decentralized totalmente o puede estar como se dijo anteriomente cursando su carrera u otra actividad a la par de estar en la Fundacion, se puede ver que entre los revisores y Alumno, existe una herencia, ya que los revisores, imparten el curso o las actividades a los alumnos, pero esta tambien cuenta con una asociacion con Decentralized Foundation, ya que de aqui toma sus recursos para llevar acabo sus funciones, aunque tiene sus propiedades tanto de puesto como de nombre de Revisor.
Como se dijo, los Revisores tienen una relacion con Decentralized la cual es una relacion bidireccional ya que el revisor puede pertenecer a en este caso a Decentralized pero Decentralized puede tener 1 o mas revisores, en el caso de Decentralized y Programa, podemos ver que es una relacion direccional, ya que Decentralized se alimenta de programa, para tener el material para que los revisores puedan impartir los cursos o las actividades, como podemos ver tiene tipo de conocimiento, y podemos ver que tiene relacion con una Enumeracion llamada Conicimientos, dependiendo el tipo de conocimiento que se requiera tambien se ve que tiene relacion con otra Enumeracion dependiendo si la tarea a realizar e suna actividad o una capacitacion, podemos notar que en este caso la relacion es compuesta, ya que depende el Programa totalmente de Decentralized y si este no existiera no podria existir el programa.
Despues la asociacion entre Servicio Social y Decentralized, es una asociacion compartida, ya que a pesar de que Decentralized es parte de el todo Servicio Social, no necesariamente es totalmente suyo, ya que Decentralized puede estar buscando en otros servicios sociales y no solo en este, asi como tambien que Servicio Social, no da solamente servicio social en Decentralized, puede dar en mas instituciones o fundaciones.
Por ultimo, se puede ver la herencia de Decentralized con Comprobante y Plazo, los cuales heredan el abstracto de la super clase Decentralized para obtener tanto la validacion del servicio social como que se cumplio el plazo para la Fundacion.

## LICENSE

Copyright (C) 2023 DECENTRALIZED CLIMATE FOUNDATION A.C.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License". 

## Referencias

> **Coursera, UML en español**, Universidad de los Andes, [Curso de UML en español](https://www.coursera.org/learn/uml?)

## Autor y Revisor
> Work developed in collaboration with the [Decentralized Climate Foundation](https://decentralizedclimate.org).
- [Gustavo Bermudez](mailto:[e-mail])
Revisor:
- [Omar Octavio Huerta Valdez](mailto:[e-mail])