PROGRAMACIÓN ORIENTADA A OBJETOS

PROGRAMACIÓN ORIENTADA A OBJETOS

• La programación orientada a objetos es una “filosofía”, un modelo de programación, con su teoría y su metodología.

• Un lenguaje orientado a objetos es un lenguaje de programación que permite el diseño de aplicaciones orientadas a objetos.

La orientación a objetos es un paradigma de programación que facilita la creación de software de calidad por sus factores que potencian el mantenimiento, la extensión y la reutilización del software generado bajo este paradigma.

La programación orientada a objetos trata de amoldarse al modo de pensar del hombre y no al de la máquina. Esto es posible gracias a la forma racional con la que se manejan las abstracciones que representan las entidades del dominio del problema, y a propiedades como la jerarquía o el encapsulamiento.

El elemento básico de este paradigma no es la función (elemento básico de la programación estructurada), sino un ente denominado objeto.

LOS OBJETOS

Un objeto no es más que un conjunto de variables (o datos) y métodos (o funciones) relacionados entre sí. Los objetos en programación se usan para modelar objetos o entidades del mundo real.

Un objeto es, por tanto, la representación en un programa de un concepto, y contiene toda la información necesaria para abstraerlo: datos que describen sus atributos y operaciones que pueden realizarse sobre los mismos.

CLASES

Las clases son abstracciones que representan a un conjunto de objetos con un comportamiento e interfaz común.

Los Objetos son instancias de las clases.

Las clases son a los objetos como los tipos de datos son a las variables.

CARACTERÍSTICAS DE LA POO

• Abstracción

• Encapsulamiento

• Polimorfismo

• Herencia

ABSTRACCIÓN

• Es una de las principales características a tener en cuenta ya que permite vislumbrar los diferentes agentes u objetos implicados en un problema.

• Captar los atributos y métodos que conforman cada objeto y la relación que existen entre ellos.

• Resolver el problema en subproblemas donde cada objeto se haga cargo de cada subproblema.

• La comunicación entre objetos generan la solución general a todo el problema. (Divide y vencerás).

ENCAPSULAMIENTO• Esta propiedad permite la ocultación de

la información es decir permite asegurar que el contenido de un objeto se pueda ocultar del mundo exterior dejándose ver lo que cada objeto necesite hacer público.

HERENCIA

• En orientación a objetos la herencia es el mecanismo fundamental para implementar la reutilización y extensibilidad del software. A través de ella los diseñadores pueden construir nuevas clases partiendo de una jerarquía de clases ya existente (comprobadas y verificadas) evitando con ello el rediseño, la modificación y verificación de la parte ya implementada. La herencia facilita la creación de objetos a partir de otros ya existentes, obteniendo características (métodos y atributos) similares a los ya existentes.

• Es la relación entre una clase general y otra clase más especifica. Por ejemplo: Si declaramos una clase párrafo derivada de una clase texto, todos los métodos y variables asociadas con la clase texto, son automáticamente heredados por la subclase párrafo.

17

Herencia en el mundo real

Medio de transporte

Vehiculo aéreo

Objeto de oficina

Cosa

Coche

Medio de tele-comunicación

POLIMORFISMO• En programación orientada a objetos el

polimorfismo se refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismo método de forma diferente.

• Por ejemplo, podemos crear dos clases distintas: Perro y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (perro y aves se mueven de forma distinta).

POLIMORFISMO

En programación orientada a objetos el polimorfismo se refiere a la capacidad para que varias clases derivadas de una antecesora utilicen un mismo método de forma diferente.

Por ejemplo, podemos crear dos clases distintas: Pez y Ave que heredan de la superclase Animal. La clase Animal tiene el método abstracto mover que se implementa de forma distinta en cada una de las subclases (peces y aves se mueven de forma distinta).

ANIMAL

POLIMORFISMO

Ejemplo dada una clase vehiculó la característica de vehículo podemos escribir las subclases: (Coche Camión Moto)

No importa que tipo de Vehículos se ya que si llamamos a su método NumeroRuedas( ) llamara al propio de cada subclase pero el objeto no deja de ser subclase.vehiculó

UML

UMLLenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad. Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema.

UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

MODELO DEL NEGOCIO• La finalidad es describir cada proceso del negocio,

especificando sus datos, actividades, roles y reglas de negocio.

• El modelo del negocio permite entender como funciona el negocio. Este es un aspecto clave para desarrollar software.

• Los analistas de negocios pueden usar la misma notación que los desarrolladores de software, mejorando la comunicación entre ellos.

• Un buen modelo de negocio provee una descripción independiente de que los procesos sean automatizados o no.

• Un modelo de negocio tiene dos componentes: un modelo de casos de uso y un modelo de objetos.

¿PORQUÉ MODELAR EL NEGOCIO?

• Porque es un excelente medio de comunicación visual para manejar la complejidad de los sistemas de una institución.

• Permite asegurar que los sistemas de software a desarrollar estarán alineados con las metas del negocio.

• Permite saber dónde se instalarán los sistemas, quién los usará, cómo se integrarán con otros sistemas y qué tareas automatizarán.

• Permite obtener rápidamente requerimientos del software.

• Puede ser un proceso de reingenieria o como parte del proceso de desarrollo de software.

• Un proceso de negocio automatizado será un caso de uso de software.

• Un caso de uso del negocio será un subsistema.

• Cada entidad del negocio podrá ser una clase.

¿QUÉ SE NECESITA PARA MODELAR EL NEGOCIO?

1. Definir el alcance del negocio: El sistema de software a construir nos indicará el área de la institución que debemos modelar.

2. Establecer que está dentro del negocio y que está fuera de él.

3. Identificar quiénes usan el negocio y cuáles son las diferentes formas de usarlo.

4. Conocer quiénes y con qué lógica hacen funcionar el negocio.

5. Determinar las cosas que usan los que hacen funcionar el negocio.

6. Elegir la notación con la que se hará el modelo.

7. Elegir la herramienta que se usará para realizar los diagramas del modelo.

DIAGRAMA DE CASOS DE USO

• Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso.

• Resultan especialmente útiles para determinar las características necesarias que tendrá el sistema.

• Los diagramas de casos de uso describen qué es lo que debe hacer el sistema, pero no cómo.

DIAGRAMA DE CLASES• Los diagramas de clases muestran las

diferentes clases que componen un sistema y cómo se relacionan unas con otras.

• Se dice que los diagramas de clases son diagramas estáticos porque muestran las clases, junto con sus métodos y atributos, así como las relaciones estáticas entre ellas: qué clases conocen a qué otras clases o qué clases son parte de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

DIAGRAMAS DE SECUENCIA• Los diagramas de secuencia muestran el

intercambio de mensajes en un momento dado.

• Los diagramas de secuencia ponen énfasis en el orden y el momento en que se envían los mensajes a los objetos.

• En los diagramas de secuencia, los objetos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta. El eje de tiempo también es vertical, incrementándose hacia abajo, de forma que los mensajes son enviados de un objeto a otro en forma de flechas con los nombres de la operación y los parámetros.

DIAGRAMA DE COLABORACIÓN• Los diagramas de colaboración muestran

las interacciones que ocurren entre los objetos que participan en una situación determinada.

• Esta es más o menos la misma información que la mostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones se producen en el tiempo.

DIAGRAMA DE COMPONENTES• Un diagrama de componentes representa cómo un

sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

• En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.

DIAGRAMA DE DESPLIEGUE• Los Diagramas de Despliegue muestran las

relaciones físicas de los distintos nodos que componen un sistema.

• La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación.

• Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria.