Módulo: Entornos de Desarrollo | Ciclo: Desarrollo de Aplicaciones
1. Introducción
Para crear una aplicación informática, es necesario llevar a cabo una serie de tareas previas durante las etapas de análisis y diseño. Estas etapas requieren obtener modelos gráficos que representen:
La información que es necesario manejar en la aplicación
Las operaciones que se deben realizar sobre dicha información
UML (Unified Modeling Language): El estándar internacional para crear estos modelos. Es un lenguaje gráfico que se emplea para visualizar, especificar, construir y documentar un sistema por medio de diferentes tipos de diagramas.
Una aplicación orientada a objetos consta de una serie de clases relacionadas entre sí, a partir de las cuales se crean objetos que se envían mensajes.
2. Conceptos Básicos de la Orientación a Objetos
El paradigma orientado a objetos supuso un cambio de visión en relación con el desarrollo de software. Básicamente, se pasó de prestar atención a los procesos a dar mayor relevancia a los datos sobre los que se debe operar.
Conceptos Fundamentales
OBJETO: Es una instancia de una clase. Es un agente abstracto que puede realizar trabajo, informar y cambiar su estado, así como comunicarse con otros objetos.
CLASE: Descripción de un conjunto de objetos que comparten atributos, operaciones, relaciones y semántica comunes.
MENSAJE: Solicitud de un objeto para que otro objeto (o él mismo) ejecute uno de sus métodos.
Características de un Lenguaje Orientado a Objetos
Según Coad y Yourdon (1991), un lenguaje de programación orientado a objetos debe cumplir las siguientes características:
1. ABSTRACCIÓN
Cada objeto en el sistema funciona como un agente abstracto que puede realizar trabajo, informar y cambiar su estado, así como comunicarse con otros objetos sin revelar cómo se implementan estas características.
2. ENCAPSULAMIENTO
Reúne todos los elementos que pueden considerarse pertenecientes a una misma entidad. Esto permite aumentar la cohesión de los componentes del sistema.
3. POLIMORFISMO
Comportamientos diferentes asociados a objetos distintos pueden compartir el mismo nombre. Al llamarlos por este nombre, se utilizará el comportamiento correspondiente al objeto que se esté usando.
4. HERENCIA
Las clases con atributos o métodos comunes se relacionan entre sí formando jerarquías de clasificación en las que las subclases (clases hija) poseen por herencia los atributos y métodos de la superclase o superclases.
5. MODULARIDAD
Propiedad que permite dividir una aplicación en partes más pequeñas llamadas módulos, cada uno de los cuales debe ser lo más independiente posible de los otros módulos.
6. OCULTAMIENTO
Cada objeto está aislado del exterior y expone su interfaz a otros objetos. Solo los métodos del objeto pueden acceder a su estado, evitando efectos secundarios e interacciones inesperadas.
7. RECOLECCIÓN DE BASURA
Técnica por la cual el entorno se encarga de destruir automáticamente los objetos que hayan quedado sin ninguna referencia a ellos. En lenguajes como C++ y Object Pascal, esta característica no existe.
Ejemplo de Abstracción: Clase Coche
La abstracción permite al programador trabajar con objetos de manera simplificada.
Una clase "Coche" podría tener propiedades como: modelo, marca, año de fabricación, número de asientos, color, etc. También podría tener métodos como "acelerar", "frenar", "girar", etc.
Cuando se crea un objeto de la clase Coche, se puede acceder a estas propiedades y métodos para interactuar con el objeto de manera controlada.
Por ejemplo, un programador que diseñe una aplicación de alquiler de coches podría enfocarse en el método "reservar" de la clase Coche, en lugar de preocuparse por cómo se implementan los frenos o el motor.
Ejemplo de Encapsulamiento: Clase CuentaBancaria
Ejemplo completo en Java:
public class CuentaBancaria {
private int saldo;
public CuentaBancaria(int saldoInicial) {
saldo = saldoInicial;
}
public void depositar(int monto) {
saldo += monto;
}
public boolean retirar(int monto) {
if (saldo >= monto) {
saldo -= monto;
return true;
} else {
return false;
}
}
public int getSaldo() {
return saldo;
}
}
public class Animal {
private String nombre;
private int edad;
public Animal(String nombre, int edad) {
this.nombre = nombre;
this.edad = edad;
}
public void hablar() {
System.out.println("Soy un animal y puedo hacer ruidos.");
}
}
public class Perro extends Animal {
private String raza;
public Perro(String nombre, int edad, String raza) {
super(nombre, edad);
this.raza = raza;
}
public void hablar() {
System.out.println("Soy un perro y hago guau guau.");
}
}
public class Gato extends Animal {
private String color;
public Gato(String nombre, int edad, String color) {
super(nombre, edad);
this.color = color;
}
public void hablar() {
System.out.println("Soy un gato y hago miau.");
}
}
Uso:
Perro miPerro = new Perro("Fido", 3, "Labrador");
Gato miGato = new Gato("Misifu", 2, "Blanco");
miPerro.hablar(); // Soy un perro y hago guau guau.
miGato.hablar(); // Soy un gato y hago miau.
Ejemplo de Polimorfismo
El mismo método se comporta diferente según el objeto:
Clase Animal con método "hacerSonido": En subclase Perro → "Woof", en subclase Gato → "Miau"
Clase Forma con método "calcularArea": En subclase Círculo → π*r², en subclase Rectángulo → base*altura
Interfaz ReproductorMultimedia: En clase Audio → reproduce archivo de audio, en clase Video → reproduce archivo de video
3. El Lenguaje UML
El modelo orientado a objetos surgió como parte de las metodologías de análisis y diseño orientado a objetos, que comenzaron su andadura durante los años 80 del siglo pasado. A partir del año 1996, se integraron varios de estos métodos, dando lugar al lenguaje unificado de modelado (UML), cuya última versión es la 2.5.1, que data del año 2017.
Principios Básicos para Diseñar el Modelo de un Sistema
La elección sobre qué modelos crear tiene una enorme influencia sobre cómo se acomete un problema y cómo se da forma a una solución.
Todo modelo puede ser expresado con diferentes niveles de precisión.
Los mejores modelos están liésuados a la realidad.
Un único modelo o vista no es suficiente. Cualquier sistema no trivial se aborda mejor mediante un pequeño conjunto de modelos casi independientes y desde múltiples puntos de vista.
3.1 Tipos de Elementos en UML
3.1.1 Elementos Estructurales
Son elementos que representan conceptos o cosas materiales:
Clase
Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica.
Interfaz
Colección de operaciones que especifican un servicio de una clase o componente.
Colaboración
Define una interacción y es una sociedad de roles que colaboran para proporcionar un comportamiento cooperativo.
Caso de Uso
Describe un comportamiento de un sistema desde el punto de vista del usuario.
Clase Activa
Tipo especial de clase cuyos objetos tienen uno o más procesos o hilos de ejecución.
Componente
Parte modular del diseño del sistema que oculta su implementación tras un conjunto de interfaces externas.
Artefacto
Parte física y reemplazable del sistema que contiene información física (bits).
Nodo
Elemento físico que existe en tiempo de ejecución y representa un recurso computacional.
3.1.2 Elementos de Comportamiento
Representan un comportamiento en el tiempo y en el espacio:
Interacción: Conjunto de mensajes intercambiados entre un conjunto de objetos.
Máquina de Estados: Especifica las secuencias de estados por los que pasa un objeto durante su vida.
Actividad: Especifica la secuencia de pasos que ejecuta un proceso computacional.
3.1.3 Elementos de Agrupación
Son las partes organizativas de los modelos UML. El principal es el PAQUETE:
Mecanismo de propósito general para organizar el diseño
Puede incluir elementos estructurales, de comportamiento y otros paquetes
A diferencia de los componentes, los paquetes son puramente conceptuales
3.1.4 Elementos de Anotación
Son las partes explicativas de los modelos UML. El más importante es la NOTA: símbolo para mostrar restricciones y comentarios asociados a un elemento.
3.2 Tipos de Diagramas en UML
En UML se pueden construir hasta 14 tipos de diagramas distintos, agrupados en dos tipos genéricos: estructurales y de comportamiento.
Diagramas Estructurales
Diagramas de Clases: Muestran un conjunto de clases y las relaciones entre ellas.
Diagramas de Objetos: Muestran un conjunto de objetos y sus relaciones.
Diagramas de Componentes: Describen la estructura del software.
Diagramas de Despliegue: Muestran nodos de procesamiento y artefactos.
Diagramas de Paquetes: Muestran la descomposición del modelo en unidades organizativas.
Diagramas de Perfiles: Permiten extender UML para plataformas particulares.
Diagramas de Estructura Compuesta: Muestran la estructura interna de un elemento.
Diagramas de Comportamiento
Diagramas de Casos de Uso: Determinan la funcionalidad desde el punto de vista del usuario.
Diagramas de Actividades: Muestran el flujo paso a paso de una computación.
Diagramas de Estados: Muestran una máquina de estados.
Diagramas de Interacción: Muestran objetos y los mensajes que se envían entre ellos.
4. Clases, Atributos, Métodos y Visibilidad
Concepto de Clase
Un objeto es una instancia de una clase. Una clase está formada por un conjunto de objetos que poseen la misma estructura y el mismo comportamiento.
Ejemplos:
Clase "Libro": Representa cualquier libro de una biblioteca. Cada ejemplar es un objeto.
Clase "Cuenta": Representa cualquier cuenta bancaria. Cada cuenta de cliente es un objeto.
Componentes de una Clase
Atributos
Son las propiedades que posee una clase. Cada atributo tiene:
Un nombre
Un tipo de dato (numérico entero, numérico real, cadena de caracteres, etc.)
Posiblemente un valor por defecto
Clase Libro: código (int), ISBN (String), título (String), editorial (String), prestado (boolean)
Métodos
Son las operaciones que se pueden llevar a cabo con los objetos de la clase y definen el comportamiento de la clase.
Solo accesible desde métodos de la clase donde está declarado.
Public
+
Accesible desde métodos de cualquier clase.
Protected
#
Accesible desde la clase y sus subclases.
Package
~
Visible en las clases del mismo paquete.
Tipos de Datos en UML
Tipos básicos: Int (entero), String (cadena), Boolean (true/false)
Tipos de lenguajes OO: Float/double (real), Char (carácter), Date (fecha), Time (hora), DateTime
Sintaxis
Atributo: visibilidad nombre: tipo [= valor_por_defecto]
Método: visibilidad nombre(parámetros): tipo_retorno
4.1. Principio de Ocultación
El principio de ocultación, también conocido como principio de encapsulamiento, es uno de los fundamentos de la programación orientada a objetos. Se refiere a la idea de que los datos y el comportamiento de un objeto deben estar ocultos a otros objetos, y sólo deberían ser accesibles a través de una interfaz pública.
Ejemplo: Si tienes una clase "Coche", los detalles internos como la velocidad, el combustible, la posición del motor, etc. deberían estar ocultos de otros objetos. Solo deben ser accesibles a través de métodos públicos como "acelerar", "frenar", "cambiar de marcha", etc.
Encapsulamiento vs Principio de Ocultación
Encapsulamiento: Es el mecanismo utilizado para ocultar los detalles internos de un objeto y restringir el acceso directo a sus atributos y métodos. Implica la agrupación de datos y métodos dentro de un objeto y el control de acceso a través de una interfaz pública.
Principio de Ocultación: Es una guía de diseño que enfatiza la importancia de mantener la información oculta y acceder a ella a través de interfaces controladas. Establece que los detalles internos de un objeto deben estar ocultos del mundo exterior.
Ambos conceptos trabajan juntos para promover la seguridad, la modularidad y la simplicidad del código.
4.2. Interfaz
Una interfaz en programación orientada a objetos es una colección de métodos abstractos y constantes que pueden ser implementados por cualquier clase que implemente la interfaz. Es como un contrato que establece una serie de requisitos que una clase debe cumplir.
Características de las Interfaces
1. Abstracción
Las interfaces permiten definir un conjunto de comportamientos abstractos que pueden ser implementados por diferentes clases de maneras diferentes.
2. Polimorfismo
Cualquier objeto que implemente una interfaz puede ser utilizado de manera intercambiable con otros objetos que implementen la misma interfaz.
3. Flexibilidad
Las clases pueden adaptarse a diferentes situaciones o requerimientos, mejorando la reutilización del código.
4. Contrato Formal
Las interfaces establecen un contrato formal que define qué métodos y propiedades debe proporcionar una clase.
Evolución de las Interfaces en Java
Versión
Características
Antes de Java 8
Solo métodos abstractos y constantes (public static final)
Desde Java 8
Métodos default (con implementación) y métodos estáticos
Desde Java 9
Métodos privados para encapsular lógica común
Nota: En programación orientada a objetos en general (no solo Java), una interfaz no puede tener métodos concretos, ya que su propósito es definir un contrato que las clases deben cumplir.
4.3. Clase Abstracta
Una clase abstracta se define utilizando la palabra clave "abstract". Puede contener tanto métodos abstractos como métodos concretos. Un método abstracto es un método que no tiene cuerpo y debe ser implementado por cualquier clase que derive de la clase abstracta.
Características Principales
No puede ser instanciada directamente
Se utiliza principalmente para ser heredada por otras clases
Puede tener: solo métodos concretos, combinación de concretos y abstractos, o solo abstractos
Si tiene al menos un método abstracto, debe ser declarada como abstracta
Obligaciones de las Subclases
1. Si la subclase es concreta: Debe implementar todos los métodos abstractos heredados.
2. Si no implementa todos los métodos: Debe ser declarada también como abstracta.
3. El compilador fuerza: Que toda clase concreta tenga implementaciones completas de todos los métodos.
Ejemplo: Una clase abstracta "Animal" con método abstracto "hacerSonido()" puede tener subclases "Perro" y "Gato" que implementan ese método de forma diferente.
4.4. Colaboración
En UML, una colaboración es un conjunto de objetos que interactúan entre sí para lograr un objetivo común. Es una reunión temporal de objetos que trabajan juntos para lograr una tarea.
Ejemplos de Colaboraciones
1. Sistema de reserva de vuelos: Objetos "Vuelo", "Pasajero" y "Reserva". La colaboración implica que "Reserva" se comunique con "Vuelo" y "Pasajero" para verificar disponibilidad y registrar información.
2. Aplicación de compras online: Objetos "Producto", "CarritoCompras" y "Cliente". La colaboración implica que "CarritoCompras" se comunique con "Producto" y "Cliente" para agregar productos y procesar el pago.
4.5. Diferencias entre Máquina de Estados y Actividad
Máquina de Estados
Actividad
Se enfoca en el comportamiento del objeto
Se enfoca en el flujo de trabajo del proceso
Representa estados de un objeto (ej: "reproduciendo", "pausado")
Representa acciones secuenciales (ej: "extraer datos", "validar", "generar")
Cambia en respuesta a eventos específicos
Fluye de una acción a otra
Ejemplos
Máquina de estados: Un objeto "ReproductorMusica" con estados "reproduciendo", "pausado", "detenido". Cambia en respuesta a eventos como iniciar canción o pulsar botón.
Actividad: Proceso "Procesamiento de facturas" con actividades: extraer datos de facturas → validar datos → generar facturas. Cada actividad conectada a otras mediante transiciones.
5. Relaciones entre Clases
5.1 Agregación
Tipo de relación entre clases que representa un objeto compuesto por otros objetos.
COMPUESTO: Representa el todo
COMPONENTE: Las partes que lo componen
Ejemplo: Un cuadro puede estar compuesto de un marco, un cristal y una lamina. El marco puede existir antes de hacer el cuadro y no tiene que dejar de existir al destruir el cuadro.
Representación: Rombo con fondo blanco al lado del compuesto.
Cardinalidades o Multiplicidades
1: Uno
0..1: Cero o uno
0..*: Cero o varios
1..*: Uno o varios
N: El número indicado
N..M: Entre N y M
5.2 Composición (Agregación Fuerte)
Tipo especial de agregación con las siguientes restricciones:
La multiplicidad al lado del compuesto es siempre 1
Si se elimina el compuesto, hay que eliminar todos los componentes
Ejemplo: Relación entre un plan de estudios y sus asignaturas.
Representación: Rombo con fondo negro.
5.3 Generalización y Especialización
Ocurre cuando se establece una jerarquía de clases y subclases motivada por atributos y/o métodos comunes.
SUPERCLASE: Contiene los atributos y métodos comunes
SUBCLASE: Hereda los de la superclase más los propios específicos
Ejemplo: Superclase "Cuenta" → Subclases "CuentaCorriente" y "CuentaDeAhorro"
Representación: Línea con triángulo apuntando a la superclase.
5.4 Asociación
Relaciones genéricas entre clases que no tienen las características de la agregación ni de la generalización-especialización.
Grado de la Relación
Reflexivas: Grado 1 (vincula una clase consigo misma)
Binarias: Grado 2 (vincula dos clases)
Ternarias: Grado 3
Navegabilidad
Sentido en el que se puede acceder a información desde una clase. Se representa mediante una punta de flecha.
Clases Asociativas
Ejemplo: Relación entre Pedido y Artículo mediante la clase asociativa LíneaPedido (contiene el atributo "cantidad").
5.5 Realización
Relación establecida entre una clase Interfaz y las clases que implementan esa interfaz.
Ejemplo: Clases Figura y Fracción que implementan la interfaz Comparar.
6. Tipos de Clases de Análisis
Durante la fase de análisis, se deben identificar tres tipos de clases:
Clases de Interfaz
Modelan la interacción entre el sistema y sus actores. Reciben y muestran información. Modelan ventanas, formularios, impresos, etc.
Clases de Entidad
Modelan información que persiste en el tiempo. Suelen mostrar una estructura de datos lógica.
Clases de Control
Realizan la coordinación y el control sobre otros objetos del sistema. Modelan la dinámica del sistema delegando trabajo a otras clases.
7. Herramientas para la Creación de Diagramas de Clases
7.1 diagrams.net
Herramienta muy sencilla de aprender y utilizar
No realiza comprobaciones sobre los diagramas creados
Disponible en línea (https://app.diagramas.net/) o como aplicación de escritorio
Formato nativo: XML con extensión .drawio
7.2 Papyrus
Herramienta más avanzada
Se integra en Eclipse como módulo
Permite realizar todo tipo de diagramas UML
7.3 Modelio
Aplicación de modelado UML de código abierto
Permite crear todo tipo de diagramas UML
Genera código Java automáticamente
Incluye módulo Java Designer
Soporte para ingeniería inversa
8. Generación de Código a partir de Diagramas de Clases
Una vez generado un diagrama de clases, se puede crear automáticamente el código en Java mediante el empleo de un generador de código.
Con Modelio
Especificar que las clases o paquetes son elementos Java (Properties → Java)
Seleccionar la clase en el explorador del modelo
Menú contextual: Java Designer → Generate
Se crea un archivo .java en la carpeta src del proyecto
El código generado incluye:
Importaciones necesarias
Anotaciones propias de Modelio
Atributos para reflejar navegabilidad de relaciones
Métodos get y set (si está configurado)
9. Generación de Diagramas de Clases a partir de Código (Ingeniería Inversa)
Ingeniería Inversa: Proceso llevado a cabo con el objetivo de obtener información o un diseño a partir del código fuente, para determinar sus componentes y cómo interactúan.