Notación UML para Modelado de Clases y Relaciones en Software

Notación Fundamental en Diagramas de Clases UML

Estructura Básica de una Clase

La representación estándar de una clase en UML sigue el siguiente formato:

+------------------+
|   NombreClase    | ← Nombre en CamelCase
+------------------+
| - atributo1: tipo|
| # atributo2: tipo|
| + atributo3: tipo|
+------------------+
| + metodo1(): tipo|
| # metodo2(): tipo|
| - metodo3(): tipo|
+------------------+

Visibilidad de Miembros

• + Público (public)
• - Privado (private)
• # Protegido (protected)

Tipos Especiales de Clases

Clase Abstracta

• Nombre presentado en cursiva o etiquetado con {abstract}.
• No puede ser instanciada directamente.

Interfaz

<<interface>>
  Interfaz

• Solo contiene la declaración de métodos (sin implementación).
• Permite simular herencia múltiple en lenguajes como Java.

Relaciones entre Clases

Dependencia

   Clase A - - - - > Clase B

• Relación débil y temporal.
• Clase A usa a Clase B (frecuentemente como parámetro de un método).
• Un cambio en Clase B podría afectar a Clase A.

Asociación

   Clase A ——————> Clase B
      rol1       rol2

• Una clase se relaciona estructuralmente con otra.
• Relación estable y permanente.
• Ambos objetos existen independientemente.
• Pueden incluir roles y multiplicidad en los extremos.

Agregación (Relación "Todo-Parte" Débil)

   Clase A <>——————> Clase B
  Contenedor     1..*   Parte

• Representa una relación de contención débil.
• Las partes (Clase B) pueden existir sin el todo (Clase A).
• Se denota con un rombo vacío en el lado del todo.

Composición (Relación "Todo-Parte" Fuerte)

   Clase A <&diam;>——————> Clase B
  Contenedor     1..*   Parte

• Representa una relación de contención fuerte.
• Las partes (Clase B) no pueden existir sin el todo (Clase A).
• Se denota con un rombo relleno en el lado del todo.

Herencia (Generalización/Especialización)

     Superclase
        ↑
        |
     Subclase

• La subclase hereda atributos y métodos de la superclase.
• La flecha (línea continua) apunta hacia la superclase.

Implementación

  <<interface>>
   Interfaz
      ↑
      |
      |
    Clase

• Una clase implementa los métodos definidos en una interfaz.
• Se utiliza una flecha discontinua que apunta a la interfaz.

Multiplicidad en Relaciones

Define cuántas instancias de una clase se relacionan con instancias de otra:

• 1 : Exactamente uno.
• * : Cero o más (equivalente a 0..*).
• 0..1 : Cero o uno (opcional).
• 1..* : Uno o más.
• n..m : De n a m instancias.

Buenas Prácticas de Diseño Orientado a Objetos

1. Encapsulación: Mantener los atributos privados y controlar el acceso mediante métodos (getters/setters).
2. Cohesión: Una clase debe tener un propósito claro y específico.
3. Nombres claros: Nombrar clases, atributos y métodos de forma descriptiva y consistente.
4. Minimizar dependencias: Evitar un exceso de relaciones entre clases para mejorar la mantenibilidad.
5. Uso adecuado de abstracciones: Emplear clases abstractas e interfaces para definir contratos.
6. Aplicar principios SOLID:
   • Single Responsibility (Responsabilidad Única)
   • Open/Closed (Abierto/Cerrado)
   • Liskov Substitution (Sustitución de Liskov)
   • Interface Segregation (Segregación de Interfaces)
   • Dependency Inversion (Inversión de Dependencias)

Ejemplo Completo de Modelado

        Persona                <<interface>>
       {abstract}              Comparable
+-------------------+        +------------+
| - nombre: String  |        | + compareTo()|
| - edad: int       |        +------------+
+-------------------+
| + getNombre()     |
| + setNombre()     |
+-------------------+
         ↑
         |
    +----+----+
    |         |
 Empleado    Cliente--------------+ (Asociación)
+---------+  +-----------+
| - sueldo|  | - teléfono|
+---------+  +-----------+