UML Diagrama de Clases

DEFINICIÓN.

Un diagrama de clases es un gráfico que ilustra clases conectadas por medio de relaciones estáticas. 

OMG Unified Modeling Language Specification, 2000.

En la siguiente sección se abordaran las relaciones entre clases, la creación de clases se explicó en la entrada Programación OO - Clases de este mismo blog. Las clases se relacionan entre sí de varias maneras diferentes, en este apartado se destacan, la asociación, agregación, composición y especialización / generalización, estas relaciones serán explicadas con mayor profundidad a continuación.

Asociación.

Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de «conexiones» entre objetos.

Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí. Describe la conexión entre diferentes clases (la conexión entre los objetos reales se denomina conexión de objetos o enlace). Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo contrario.

En UML, las asociaciones se representan por medio de líneas que conectan las clases participantes en la relación, y también pueden mostrar el papel y la multiplicidad de cada uno de los participantes. La multiplicidad se muestra como un rango [mín...máx] de valores no negativos, con un asterisco (*) representando el infinito en el lado máximo.

Fuente: http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html

La multiplicidad por su parte fija el número de instancias que participan en la relación, a continuación se muestra la tabla que muestra la cardinalidad en una asociación.

1	uno y solo uno
0..1	cero o uno
*	muchos
0..*	cero o muchos
1..*	uno o muchos

Ejemplo de asociación

 

Agregación.

Las composiciones son tipos especiales de asociaciones que representan un nivel de acoplamiento más fuerte, las relaciones que se tratan de modelar son del tipo “tiene un” o “es parte de” donde una de las clases juega el rol de "completa" y las otras son las "partes".

La notación para representar las agregaciones es una línea con un rombo vació en el extremo apuntando a la clase completa. En la agregación las partes puedes existir aun cuando la clase completa haya dejado de hacerlo.                     

Composición.

Las composiciones, son tipos especiales de asociaciones que representan un nivel de acoplamiento más fuerte que las agregaciones, las relaciones que se tratan de modelar son del tipo “se compone de”, con la composición solo se puede pertenecer a un todo en consecuencia si se elimina el todo se eliminan las partes.

La notación para representar las composiciones, es una línea con un rombo lleno en el extremo apuntando a la clase todo. En la composición la clase todo maneja el ciclo de vida de los objetos que la componen, de esta manera se asegura que cuando el todo se destruye también sus partes.  
                

Si se observa detenidamente, el numero 54 no hace parte de las opciones de cardinalidad, sin embargo es valido poner un valor numérico si se sabe de ante mano que es estático por ejemplo el mazo de cartas americano tiene 54 figuras compuestas por 13 cartas por cada símbolo y 2 comodines, dicha configuración no cambia entonces es posible poner el numero de cartas como valor de la multiplicidad de la clase carta.


Herencia.

La herencia consiste en crear clases genéricas llamadas súper clases o clases padre, con los elementos comunes a un conjunto de subclases. Las subclases heredan (recogen) los atributos y comportamiento de la clase padre pudiendo agregar atributos y comportamiento propios, y modificar los atributos y comportamiento que vienen del padre.

La herencia cumple con el principio de sustitución de Liskov que afirma que: si S es un subtipo de T, entonces los objetos de tipo T en un programa de computadora pueden ser sustituidos por objetos de tipo S.


A pesar de que la herencia es una herramienta poderosa justificada por el re-uso de componentes comunes presentes en súper clases, también presenta problemas en el control de tipos como la covariación y el ocultamiento en los descendientes, temas que no se trataran en esta sección.                  

UML Elementos del Diagrama de Casos de Uso

INTRODUCCIÓN.

Los casos de uso se componen de un documento literal y un diagrama, el componente de documento se encuentra en la sección UML casos de uso de este blog, esta entrada se centra en los elementos del diagrama. A continuación se muestran y describen dichos elementos.

Elemento	Función en el diagrama
Actor	El termino ACTOR, se refiere a un tipo de estereotipo que representa una entidad (persona, grupo de personas, sistema informático), externa al sistema que será modelado y que interactúa con uno o más casos de uso. Se representa por una figura humana, independientemente de que sea una persona o un sistema.
Caso de Uso	Dentro del diagrama los casos de uso son representados por óvalos, en el interior de ellos se ubica el nombre del caso de uso por ejemplo “registrar datos”.
Sistema	En el diagrama el sistema es representado con un rectángulo, dentro del rectángulo deben estar los casos de uso y fuera de él los actores, actores y casos de uso se relacionan por medio de asociaciones, casos de uso con casos de uso pueden relacionarse con asociaciones simples, extensiones, inclusiones o generalizaciones.
Asociación	Asociación es la relación entre un actor un caso de uso. La Asociación es representada por una línea solida que va desde el actor hasta el caso de uso, en muchas herramientas de modelado la flecha no tiene dirección ya que se asume que parte desde el actor.
<< Extends >>	Un Caso de Uso puede extender el comportamiento de otro, por lo general cuando se consideran circunstancias particulares   por ejemplo  en una empresa de alimentos el caso de uso (clasificar tomates) puede extender a (descartar tomates), siempre y cuando el tomate en cuestión no pase cierta validación. La Extensión se representa con el estereotipo << Extend >> y una flecha que va desde el caso de uso extendido hasta el principal. En este caso la flecha es punteada aunque algunas herramientas de modelado usan la flecha de generalización con el estereotipo << Extend >>.
<< Include >> o  << Uses >>	Un caso de uso puede incluir la funcionalidad de otro como parte de su proceso normal, en general se asume que el caso de uso incluido se llama cada vez que el caso de uso base se ejecuta. Un Caso de Uso puede ser incluido por uno o más casos de uso, por lo que ayuda a reducir la duplicación de funcionalidad al factorizar el comportamiento común en los casos de uso que son muchas veces utilizados de nuevo. La Inclusión se representa con el estereotipo << include >> y una flecha que va desde el caso de uso principal hasta el que incluye. En este caso la flecha es punteada aunque algunas herramientas de modelado usan la flecha de generalización con el estereotipo << Include >>.
Generalización	La generalización es una relación entre casos de uso que implica que el caso de uso hijo contiene todos los atributos, comportamiento y puntos de extensión definidos en el caso de uso padre y además participa en todas las relaciones de los casos de uso padres. Cockburn, Alistair. 2000. Writing Effective Use Cases También es posible utilizar la generalización con los actores, sin embargo es una práctica poco utilizada La generalizacion es representada en el diagrama con una flecha con punta triangular vacia, que va desde el caso de uso hijo hasta el caso de uso principal.

  
En los videos que se encuentra a continuación se muestra como realizar diagramas de casos de uso en las herramientas de modelado, ArgoUML y StarUML.

1. Diagramas de caso de uso utilizando ArgoUML.

2. Diagramas de caso de uso utilizando StarUML.

UML Casos de Uso

DEFINICIÓN.

Caso de uso es un documento narrativo que describe la secuencia de eventos de un ACTOR (agente externo) que utiliza el sistema para completar un proceso.

Jacobson, 1992

Un CASO DE USO es una descripción de las INTERACCIONES y las RESPONSABILIDADES de un sistema, "objeto de debate " o "sistema en diseño”, con AGENTES EXTERNOS o ACTORES. Un actor puede ser una persona un grupo de personas o un sistema informático. El caso de uso es asociado con el OBJETIVO de un actor en particular, que es llamado el ACTOR PRINCIPAL del caso de uso. El caso de uso describe los distintos conjuntos de interacciones que pueden ocurrir entre diversos agentes externos o actores mientras que el actor principal está en la búsqueda de su objetivo. También se describen las responsabilidades del sistema bajo diseño sin tener en cuenta técnicas de implementación o componentes del sistema. Cada posible secuencia de interacciones es llamada ESCENARIO. El caso de uso agrupa juntos todos los escenarios relacionados con el objetivo del actor principal, incluyendo tanto los escenarios donde el objetivo es conseguido como los escenarios donde el objetivo debe ser abandonado.

Cockburn, Alistair. 2000. Writing Effective Use Cases

En la definición anterior, se resaltan en letra mayuscula algunos conceptos destacados, la definición original no resalta ningun concepto.

DESCRIPCIÓN DE UN CASO DE USO.

 

La descripción de un caso de uso se compone de dos partes principales, el diagrama que representa gráficamente el caso de uso y una descripción textual que aclara de forma literal el diagrama, en esta sección se explicara la descripción textual que es la más importante pues documenta completamente el caso de uso y sus posibles escenarios.

 

1. ENCABEZADO

 

1.1. Identificador del caso de uso

Cada caso de uso tiene un único identificador numérico, también se pueden agrupar de forma jerárquica usando otras notaciones como X.Y o combinar un código numérico con un código alfabético como RF1, RNF1, etc.

 

1.2. Nombre del caso de uso

El nombre debe ser conciso, debe estar orientado al resultado del caso de uso. Debe reflejar las tareas que el usuario necesita llevar a cabo para usar el sistema. El nombre debe llevar un verbo pues es una acción. Ejemplo.

1. Generar orden de compra
2. Registrar PIN.

 

1.3. Registro Histórico

 

1.3.1 Creado Por.

En esa parte se pone el nombre de la persona “Autor” de ese caso de uso.

 

1.3.2 Fecha de creación

En esta parte se pone la fecha de creación inicial del caso de uso.

 

1.3.3 Actualizado Por.

Se pone el nombre de la persona que realizo la última actualización, también se pueden conservar los nombres de las personas que actualizaron previamente el caso de uso.

 

1.3.4 Fecha de actualización.

Se escribe la fecha de la última actualización.

 

2. DEFINICIÓN DE LOS CASOS DE USO.

 

2.1. Actores

En esta parte se ubican los nombres de los actores implicados en el caso de uso, tenga en cuenta que en un caso de uso o un conjunto de ellos pueden interactuar uno o muchos actores.

 

2.2. Trigger o Disparador.

Identifica el evento que inicia el caso de uso. Podría ser un evento de negocios externos o de sucesos del sistema que hace que el caso de uso pueda empezar, también podría ser el primer paso en el flujo normal.

 

2.3. Descripción

Proporcionar una breve descripción de la razón y los resultados del caso de uso, o una descripción de alto nivel de la secuencia de acciones y los resultados de la ejecución del caso de uso.

 

2.4. Precondiciones

Lista todas las actividades que deben ser tenidas en cuenta o todas las condiciones que deben ser cumplidas, antes de que el caso de uso empiece. Las precondiciones deben ser numeradas.

1. El usuario debe autenticar su identidad. 

 

2.5. Postcondiciones

Describen el estado del sistema una vez terminada la ejecución del caso de uso. Deben ir numeradas.

1. El articulo queda registrado en la base de datos.
2. El precio del artículo queda actualizado en la base de datos.

 

2.6. Escenarios

 

2.6.1 Flujo norma de eventos.

Provee una descripción detallada de las acciones del usuario y las respuestas del sistema durante la ejecución normal del caso de uso, son las condiciones esperadas cuando el caso de uso se ejecuta sin contratiempos, Esta secuencia de diálogo en última instancia conduce a lograr el objetivo expuesto en el nombre y la descripción de casos de uso. Esta descripción puede ser escrita como una respuesta a la pregunta hipotética: ¿Cómo se pueden hacer cumplir las tareas que sugiere el nombre del caso de uso?. Para lograr una buena conformación del flujo normal se recomienda numerar las acciones de los usuarios y las respuestas del sistema a manera de pasos para llegar a la meta del caso de uso.

 

2.6.2 Flujos alternos.

Documenta los escenarios que pueden ocurrir cuando el caso de uso no puede ser ejecutado completamente. Se enumeran igual que el flujo normal de eventos con las acciones del usuario y las respuestas del sistema.

 

2.7. Puntos de extensión.

Es donde se establece en qué momento, del hilo de ejecución del caso de uso se va a extender a otro.

 

2.8. Excepciones.

 Describir las condiciones de error que podrían ocurrir durante la ejecución del caso de uso y define cómo el sistema es responder a esas condiciones. Además, se describe cómo el sistema ha de responder si la ejecución de casos de uso falla por alguna razón imprevista. Las excepciones se pueden identificar en términos de una 4 tupla, de la forma “X.Y.E.Z”, donde X es el identificador del caso de uso, Y indica el flujo normal si es (0) o alternativo si es mayor que (0), E indica excepción y Z es el numero de secuencia de las excepciones. Por ejemplo. 4.0.E.1 significa que el caso de uso 4, en su flujo normal presenta una excepción y que dicha excepción es la número 1.

 

2.9. Includes

Lista de todos los casos de uso de que son incluidos, llamados por el presente caso de uso.

 

2.10. Prioridad.

En esta parte se indica la prioridad relativa de la implementación de la funcionalidad del caso de uso, puede usar una escala de 3 valores como alto, medio y bajo aun cuando usar escalas más amplias podría ayudar a mejorar la priorización y trazabilidad de los casos de uso.

 

2.11. Frecuencia de uso

Estimar el número de veces en que el caso de uso se llevará a cabo por los actores, debe indicarse alguna unidad de tiempo.

 

2.12. Reglas de negocio.

Lista todas las reglas de negocio que influencian el caso de uso.

 

2.13. Requerimientos especiales

Se incluyen los requisitos adicionales, tales como los requisitos no funcionales que pueden necesitar para el caso de uso, que se abordarán durante el diseño o implementación de él. Estos pueden incluir requisitos de rendimiento u otros atributos de calidad.
  

NOTA: En el siguiente link podrá encontrar un ejemplo que se será útil para realizar su propia platilla para documentar casos de uso.

Descarga plantilla para documento Casos de Uso

Ejemplo Abstraccion.

Ejemplos.

 

En esta sección usaremos el lenguaje de programación java para realizar ejemplos de abstracción, polimorfismo, encapsulamiento y herencia.

 

Ejemplo Abstracción.

 

Para este ejemplo se va a trabajar la abstracción de un vehículo, para lo cual se hace el siguiente razonamiento.

1. Los vehículos pueden ser de varias clases (aéreo, terrestre, acuático e híbridos), por tanto todos los vehículos tienen una clase.
2. Todos los vehículos tienen una velocidad máxima.
3. Todos los vehículos mecánicos consumen algún tipo de combustible.
4. Todos los vehículos pueden llevar un número determinado de pasajeros o carga, para el ejemplo se considera solo el transporte de pasajeros.

Y se podrían seguir poniendo tantas características como se consideren necesarias para conseguir una buena abstracción del objeto. La siguiente es la representación de la abstracción en java solo de los atributos, y un método constructor.

 
    public class Vehiculo {
    String clase;
    int velocidadMax;
    String combustible;
    int numeroPasajeros;

    public Vehiculo(String clase, int velocidadMax, 
    String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }
} 

 

Ejemplo Encapsulamiento.

El encapsulamiento en Java se implementa con las palabras reservadas private o protected, y su función es esconder el estado del objeto. Cabe resaltar que cuando los atributos del objetos son privados se deben implementar interfaces que permitan el acceso a los mismos, estas son llamadas propiedades y se notan setNombreAtributo y getNombreAtributo. Los set se usan para asignar valores a los atributos y los get para retornar el valor del atributo. 

    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    public Vehiculo(String clase, int velocidadMax, 
    String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }

    
    public String getClase() {
        return clase;
    }
    public void setClase(String clase) {
        this.clase = clase;
    }
    public int getVelocidadMax() {
        return velocidadMax;
    }
    public void setVelocidadMax(int velocidadMax) {
        this.velocidadMax = velocidadMax;
    }
    public String getCombustible() {
        return combustible;
    }
    public void setCombustible(String combustible) {
        this.combustible = combustible;
    }
    public int getNumeroPasajeros() {
        return numeroPasajeros;
    }
    public void setNumeroPasajeros(int numeroPasajeros) {
        this.numeroPasajeros = numeroPasajeros;
    }
}

 

Ejemplo Polimorfismo.

Para el ejemplo de polimorfismo se tomara la clase con atributos y se van a agregar dos constructores, dicho polimorfismo se llama sobre carga, se observa cómo dos métodos tienen el mismo nombre pero reciben diferentes parámetros. En este tipo de polimorfismo hay que tener cuidado con la firma del método ya que dos métodos con el mismo nombre no pueden tener la misma firma. 

    public class Vehiculo {
    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    // Constructor lleno
    public Vehiculo(String clase, int velocidadMax, 
            String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }
    
    // Constructor vacio
    public Vehiculo(){}
} 

 

Ejemplo Herencia.

Para el ejemplo de herencia vamos a crear la clase automóvil que también es un vehículo, la herencia en java se implementa con la palabra reservada extends y la referencia al constructor del padre.

    

/**********************************
CLASE PADRE
**********************************/

    public class Vehiculo {
    private String clase;
    private int velocidadMax;
    private String combustible;
    private int numeroPasajeros;

    // Constructor lleno
    public Vehiculo(String clase, int velocidadMax, 
            String combustible, int numeroPasajeros) {
        this.clase = clase;
        this.velocidadMax = velocidadMax;
        this.combustible = combustible;
        this.numeroPasajeros = numeroPasajeros;
    }

    public String getClase() {
        return clase;
    }
    public void setClase(String clase) {
        this.clase = clase;
    }
    public int getVelocidadMax() {
        return velocidadMax;
    }
    public void setVelocidadMax(int velocidadMax) {
        this.velocidadMax = velocidadMax;
    }
    public String getCombustible() {
        return combustible;
    }
    public void setCombustible(String combustible) {
        this.combustible = combustible;
    }
    public int getNumeroPasajeros() {
        return numeroPasajeros;
    }
    public void setNumeroPasajeros(int numeroPasajeros) {
        this.numeroPasajeros = numeroPasajeros;
    }
}


/**********************************
CLASE HIJO
**********************************/
    
    public class Automovil extends Vehiculo{
    private int numeroLlantas;
    private int numeroPuertas;
    private String modelo;

    // Constructor que incluye atributos de la super clase o clase padre.
    
    public Automovil(String clase, int velocidadMax, String combustible, 
    int numeroPasajeros, int numeroLlantas, int numeroPuertas, String modelo)
    {
        super(clase,velocidadMax, combustible, numeroPasajeros);
        this.numeroLlantas = numeroLlantas;
        this.numeroPuertas = numeroPuertas;
        this.modelo = modelo;
    }
    public int getNumeroLlantas() {
        return numeroLlantas;
    }
    public void setNumeroLlantas(int numeroLlantas) {
        this.numeroLlantas = numeroLlantas;
    }
    public int getNumeroPuertas() {
        return numeroPuertas;
    }
    public void setNumeroPuertas(int numeroPuertas) {
        this.numeroPuertas = numeroPuertas;
    }
    public String getModelo() {
        return modelo;
    }
    public void setModelo(String modelo) {
        this.modelo = modelo;
    }    
}

Programación OO - Objeto

Objetos.

 

El concepto objeto es fundamental en la programación OO, por lo cual se explica a continuación.

 

Definición de objeto:

 

"Un objeto tiene estado, comportamiento, e identidad; la estructura y comportamiento de objetos similares son definidos en su clase común; los terminos instancia y objeto son intercambiables".

Booch, 1991

" Nosotros definimos un objeto como un concepto, abstracción o cosa con un significado y límites bien definidos para el problema a manejar".

Rumbaugh, 1991

" Un objeto es cualquier cosa a la que se le aplica un concepto, el que representa una idea o noción que nosotros compartimos y aplicable a ciertos objetos en nuestro conocimiento".

Martin, 1992

De las definiciones anteriores se puede determinar que un objeto es:

Los conceptos de estado, comportamiento e identidad, son explicados a continuación con algunos ejemplos sencillos para facilitar su comprensión.

 

Estado

El estado hace referencia a los valores presentes en el conjunto de atributos de un objeto. El estado es variable en el tiempo, el comportamiento de un objeto puede cambiar el estado del mismo. 

Por ejemplo imagine un objeto círculo, con un atributo nombrado “radio”. Ahora observe la figura, el objeto circulo en un tiempo t determinado tiene 5 como valor del atributo radio, sin embargo en un tiempo t diferente el valor del atributo radio cambia por 3, tratándose del mismo objeto en tiempos t diferentes. 

Comportamiento

El comportamiento de un objeto, agrupa las operaciones que este puede realizar o a las que puede responder mediante estímulos externos representados en forma de mensajes enviados por otros objetos. Las operaciones pueden tener efecto directo sobre los atributos. 

Ahora teniendo como base la figura anterior donde se muestran los círculos, imagine la operación calcular área, esta operación deberá retornar el valor de la operación matemática PI * (radio * radio), donde radio es el valor de dicho atributo en ese instante de tiempo.

 

Identidad

La identidad es el mecanismo por el cual se puede diferenciar un objeto de otro, se puede tomar como un identificador univoco y es interesante cuando se tienen objetos con los valores de sus atributos iguales, la identidad es implementada en los lenguajes de programación de manera implícita, así que no es responsabilidad del programador crearla. Un ejemplo de ello son los OID o identificadores de objetos por sus siglas en ingles que proveen la identidad de un objeto independientemente de su ubicación física.

 

Clasificación de objetos según su comportamiento.

Los objetos según su comportamiento se pueden agrupar en 3 categorías que son:

1. Actores
2. Servidores
3. Agentes

Los objetos Actores, son iniciadores de la interacción, son generalmente objetos activos.

Los objetos Servidores, por el contrario de los actores no son iniciadores de una interacción su función se limita a responder peticiones de otros objetos, siempre son destinatarios de los mensajes.

Los objetos Agentes, reúnen las características de clientes y servidores, los agentes pueden interactuar con otros objetos en todo momento bien sea por iniciativa propia o a consecuencia de una solicitud externa.

 

Comunicación entre objetos.

La unidad de comunicación entre objetos se denomina mensaje, existen 5 categorías de mensajes que son:

1. Simple
2. Síncrono
3. Esperado
4. Cronometrado
5. Asíncrono

Los mensajes a su vez se componen de los siguientes componentes.

1. Nombre del receptor del mensaje
2. Método invocado
3. Información necesaria para la ejecución del método

Programación OO - Clases

Definición.

 

Independientemente del lenguaje de programación en que se implementen, las clases son plantillas de objetos, también se puede tomar como la descripción abstracta de un grupo de objetos, estas tienen una estructura que se conforma de dos componentes principales atributos y métodos (operaciones). 

La representación grafica que prevalece en la actualidad es la de Yurdon y Coad, donde se dibuja un rectángulo divido horizontalmente en 3 partes, En la parte superior se ubica el nombre de la clase, en la parte media es destinada a los atributos y la parte inferior se reserva para los métodos. 

Atributos

Los atributos describen el estado de un objeto, En términos generales son características generales de la clase, que la diferencian de otras. 

En las implementaciones que se encuentran en los lenguajes de programación los atributos suelen representarse como variables de instancia, ademas deben ser privados.

 

Métodos

Los métodos (operaciones o servicios) describen el comportamiento asociado a un objeto. La ejecución de un método puede conducir a cambiar el estado del objeto o dato local del objeto, los métodos deben ser privados con excepción de los métodos que solo son usados únicamente en la misma clase

 

Ejemplo de clase con atributos y métodos

La figura muestra la clase Punto con sus atributos coordenadaX y coordenadaY que son los elementos necesarios para definirlo y diferenciarlo de la clase línea por ejemplo que necesitaría cuando menos un par de puntos. También se observan los métodos moverCoordenadaX y moverCoordenadaY. Que representan posibles comportamientos que se pueden lograr por un objeto de la clase Punto. 

El siguiente video muestra cómo crear clases en la herramienta de modelado ArgoUml.

Programación OO - Elementos principales.

Elementos principales.

Independientemente del leguaje de implementación, el paradigma de programación objeto se basa en 4 conceptos fundamentales. La abstracción, el encapsulamiento, el polimorfismo y la herencia. Dichos pilares van a ser explicados a continuación en forma superficial. 

  

Abstracción:

En POO la abstracción hace referencia a la capacidad de expresar las características principales de un objeto. Como consecuencia de esto se logra tener un modelo claro del objeto centrado en la pregunta ¿qué hace? 

El método de abstracción es arbitrario. Lo que permite que un objeto pueda ser visto a través de abstracciones diferentes. La siguiente figura muestra la colección de toros de Picasso que ejemplifica de forma magistral el espíritu de la abstracción, en dicha secuencia se puede observar como los primeros toros son muy ricos en detalles que no hacen parte esencial de la representación del toro hasta llegar al número 11, donde se encuentra un toro reducido a una representación de muy pocos trazos pero con expresividad suficiente para saber que es un toro.  

Imagenes tomadas de: http://www.artyfactory.com/art_appreciation/animals_in_art/pablo_picasso.htm

 

Encapsulamiento. 

El encapsulamiento se utiliza para ocultar o esconder las características esenciales de un objeto, de manera que no pueda ser alterado por otros objetos, en cierto modo proveen un efecto de caja negra donde la interacción entre objetos debe hacerse por medio de su interfaz y no directamente. 

Dependiendo de la implementación del lenguaje OO. Se tienen diferentes reglas de visibilidad para atributos, métodos y / o clases, dichas reglas son:

1. Privado: visible sólo para la clase y para las clases amigas o del mismo paquete en C++ y Java, respectivamente.
2. Protegida: visible sólo para las clases derivadas (subclases).
3. Pública: visible para todas las clases con las que está asociada.

 

Herencia:

 

Tiene su justificación en una ventaja de la programación OO, que es la reutilización de código, tomando en cuenta la analogía con la herencia genética, en programación se trata de que una clase puede heredar de otra u otras. Las clases hijas son especializaciones de la súper clase por lo que deben incluir atributos y métodos propios, Existen dos tipos de herencia denominadas herencia simple y herencia múltiple. 

La herencia simple se da cuando una clase hija hereda de solo una clase llamada padre o súper clase, como resultado la clase hija hereda los atributos y métodos de su padre ( este tipo de herencia es el soportado en java). 

Sabiendo cómo se da la herencia simple es fácil imaginar cómo funciona la herencia múltiple, básicamente consiste en que una clase herede de más de una clase padre, aunque es mucho más natural que la herencia simple dado que en muchos casos un objeto posee caracterizas y comportamientos de otros varios y no solo de uno, hay que ser cuidadoso con su uso ya que se pueden tener resultados indeseados (soportada en C++).

Polimorfismo:

Quizá es uno de los pilares de la programación OO, más complejos de entender, sin embargo se va a tratar de explicar de forma sencilla, el polimorfismo se aplica en los métodos y se refiere a que el mismo método puede ser usado para diferentes fines según se necesite. 

Para explicar mejor este concepto vamos a echar mano de la implementación en java. En ese lenguaje se tienen dos clases de polimorfismo uno se llama sobrecarga y el otro se llama sobre escritura. Esta definición puede variar según la implementación, sin embargo el concepto de polimorfismo es el mismo. 

La sobrecarga se refiere a que un método puede implementarse para varios fines con el mismo nombre en la misma clase, el ejemplo más simple se observa con los métodos constructores que se pueden implementar con varios parámetros diferentes como el constructor vacío y el constructor lleno.

La sobre escritura se aplica cuando una clase hereda de otra u otras (en java solo existe herencia simple), en ese sentido la clase hija hereda sus atributos y métodos, sin embargo esto no implica que los métodos se tengan que utilizar estrictamente en la forma que lo hace su padre, en caso de haber cambios en la implementación de un método este se escribe de nuevo en la clase hija con sus particularidades.