lunes, 9 de diciembre de 2013

PROGRAMACION ORIENTADA A OBJETOS





La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación.Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita soltarnos un poco con este tipo de programación.


Motivación

Durante años, los programadores se han dedicado a construir aplicaciones muy parecidas que resolvían una y otra vez los mismos problemas. Para conseguir que los esfuerzos de los programadores puedan ser utilizados por otras personas se creó la POO. Que es una serie de normas de realizar las cosas de manera que otras personas puedan utilizarlas y adelantar su trabajo, de manera que consigamos que el código se pueda reutilizar.

La POO no es difícil, pero es una manera especial de pensar, a veces subjetiva de quien la programa, de manera que la forma de hacer las cosas puede ser diferente según el programador. Aunque podamos hacer los programas de formas distintas, no todas ellas son correctas, lo difícil no es programar orientado a objetos sino programar bien. Programar bien es importante porque así nos podemos aprovechar de todas las ventajas de la POO.

Cómo se piensa en objetos

Pensar en términos de objetos es muy parecido a cómo lo haríamos en la vida real. Por ejemplo vamos a pensar en un coche para tratar de modelizarlo en un esquema de POO. Diríamos que el coche es el elemento principal que tiene una serie de características, como podrían ser el color, el modelo o la marca. Además tiene una serie de funcionalidades asociadas, como pueden ser ponerse en marcha, parar o aparcar.
Pues en un esquema POO el coche sería el objeto, las propiedades serían las características como el color o el modelo y los métodos serían las funcionalidades asociadas como ponerse en marcha o parar.

Por poner otro ejemplo vamos a ver cómo modelizaríamos en un esquema POO una fracción, es decir, esa estructura matemática que tiene un numerador y un denominador que divide al numerador, por ejemplo 3/2.
La fracción será el objeto y tendrá dos propiedades, el numerador y el denominador. Luego podría tener varios métodos como simplificarse, sumarse con otra fracción o número, restarse con otra fracción, etc.

Estos objetos se podrán utilizar en los programas, por ejemplo en un programa de matemáticas harás uso de objetos fracción y en un programa que gestione un taller de coches utilizarás objetos coche. Los programas Orientados a objetos utilizan muchos objetos para realizar las acciones que se desean realizar y ellos mismos también son objetos. Es decir, el taller de coches será un objeto que utilizará objetos coche, herramienta, mecánico, recambios, etc.

Clases en POO

Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablábamos de las clases coche o fracción porque sólo estuvimos definiendo, aunque por encima, sus formas.

Propiedades en clases

Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.
Métodos en las clases
Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.

Objetos en POO

Los objetos son ejemplares de una clase cualquiera. Cuando creamos un ejemplar tenemos que especificar la clase a partir de la cual se creará. Esta acción de crear un objeto a partir de una clase se llama instanciar (que viene de una mala traducción de la palabra instace que en inglés significa ejemplar). Por ejemplo, un objeto de la clase fracción es por ejemplo 3/5. El concepto o definición de fracción sería la clase, pero cuando ya estamos hablando de una fracción en concreto 4/7, 8/1000 o cualquier otra, la llamamos objeto.
Para crear un objeto se tiene que escribir una instrucción especial que puede ser distinta dependiendo el lenguaje de programación que se emplee, pero será algo parecido a esto.

miCoche = new Coche()
Con la palabra new especificamos que se tiene que crear una instancia de la clase que sigue a continuación. Dentro de los paréntesis podríamos colocar parámetros con los que inicializar el objeto de la clase coche.
Estados en objetos

Cuando tenemos un objeto sus propiedades toman valores. Por ejemplo, cuando tenemos un coche la propiedad color tomará un valor en concreto, como por ejemplo rojo o gris metalizado. El valor concreto de una propiedad de un objeto se llama estado.
Para acceder a un estado de un objeto para ver su valor o cambiarlo se utiliza el operador punto.
miCoche.color = rojo

El objeto es miCoche, luego colocamos el operador punto y por último el nombre e la propiedad a la que deseamos acceder. En este ejemplo estamos cambiando el valor del estado de la propiedad del objeto a rojo con una simple asignación.

Mensajes en objetos
Un mensaje en un objeto es la acción de efectuar una llamada a un método. Por ejemplo, cuando le decimos a un objeto coche que se ponga en marcha estamos pasándole el mensaje “ponte en marcha”.
Para mandar mensajes a los objetos utilizamos el operador punto, seguido del método que deseamos invocar.
miCoche.ponerseEnMarcha()
En este ejemplo pasamos el mensaje ponerseEnMarcha(). Hay que colocar paréntesis igual que cualquier llamada a una función, dentro irían los parámetros.
Otras cosas

Hay mucho todavía que conocer de la POO ya que sólo hemos hecho referencia a las cosas más básicas. También existen mecanismos como la herencia y el polimorfismo que son unas de las posibilidades más potentes de la POO.

La herencia sirve para crear objetos que incorporen propiedades y métodos de otros objetos. Así podremos construir unos objetos a partir de otros sin tener que reescribirlo todo.
El polimorfismo sirve para que no tengamos que preocuparnos sobre lo que estamos trabajando, y abstraernos para definir un código que sea compatible con objetos de varios tipos.
Son conceptos avanzados que cuesta explicar en las líneas de ese informe. No hay que olvidar que existen libros enteros dedicados a la POO y aquí solo pretendemos dar un repaso a algunas cosas para que os suenen cuando tengáis que poneros delante de ellas en los lenguajes de programación que debe conocer un desarrollador del web.

Ejemplo concreto de programación orientada a objetos

Para conseguir un ejemplo concreto de lo que es la programación orientada a objetos, podemos entrar en el Manual de PHP 5. Realmente este manual explica las características de orientación a objetos de PHP 5 y ofrece ejemplos concretos de creación de clases con características como herencia, polimorfismo, etc.

DIAGRAMA DE ACTIVIDADES


DIAGRAMA DE ACTIVIDADES

 Diagramas de Actividad

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.

Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.

Usando Diagramas de Actividad para modelar Casos de Uso

Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad.

Usando Diagramas de Actividad para modelar Clases

Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suel usar normalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad se usa conado todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Deberías asignar actividades a las clases antes de terminar con el diagrama de actividad.


DIAGRAMA DE CLASES

CONCEPTOS BÁSICOS DIAGRAMA DE CLASES

El diagrama de clase es el diagrama principal de diseño y análisis para un sistema, y en él se agrupan todas las clases y relaciones que existen entre ellas y que serán utilizadas dentro del sistema.  Los diagramas de Clases por definición son estáticos, esto es, representan que partes interactúan entre sí, sin indicar el momento en que ocurre.

Una clase agrupa los objetos que comparten estructura, comportamiento y relaciones similares. Una clase representa los conceptos del sistema que se desea modelar.

Gráficamente una clase se dibuja como un rectángulo con hasta tres (3) compartimentos:
Nombre de la clase
Lista de Atributos (opcional)
Lista de Operaciones (opcional)


Atributos de una clase

Los atributos representan alguna propiedad dentro de la clase.  Los atributos son valores que son instanciados de la clase. Una clase puede tener varios atributos o ninguno.

Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta razón se crearon niveles de visibilidad para los elementos que son:
  • (-)  Privado: Son accesibles sólo por métodos propios de la clase.
  • (#) Protegidos: Son accesible sólo por las clases derivadas de la original.
  • (+) Públicos: Son accesibles por cualquier clase


Operaciones de una clase

Una operación es la implementación de un servicio que podrá ser requerido por cualquier objeto de la clase para afectar su comportamiento. En otras palabras, una operación es una abstracción de algo que se quiera hacer sobre un objeto y sea compartido por todos los objetos de la clase.

Se puede diferenciar una operación colocando su firma:
  • Declarando el nombre de la operación
  • Declarando los parámetros
  • Declarando el valor retornado


Relaciones entre clases

Al construir abstracciones, descubrimos que muy pocas de las clases diseñadas actúan solas, y muchas otras colaboran con otras clases. Por lo que debemos conocer cómo se relacionan unas con otras. 


Existen en el modelado orientado a objetos tres tipos de relaciones:
  • Dependencia
  • Generalización
  • Asociación


La Dependencia representa el uso de las relaciones entre clases, La Generalización sirve para conectar las clases generales a otras más específicas, es decir, para relaciones subclase/superclase, y la Asociación indica relaciones estructurales entre los objetos.

La Agregación se deriva de la Asociación y la Especialización se deriva de la Generalización. Ambos tipos de relaciones forman jerarquías de clases.

Dependencia

La dependencia se usa para mostrar que una clase usa otra clase como un argumento, el cual se especifica en la firma de la operación. En el diagrama anterior la clase Event es utilizado por la clase Window por sus métodos.
Se dibuja como una flecha punteada.




Generalización

La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general.  A la clase más general se le denomina “Superclase” o “Padre” y a la clase más específica se le denomina “Subclase” o “Hijo”.  A veces este tipo de relación es referenciada como "is-a-kind-of" o “es-un-tipo-de”.  Por ejemplo, la clase CuadroDialogo es un tipo de la clase Ventana.

Las subclases heredan propiedades de sus clases padre, es decir, atributos y operaciones y asociaciones de la clase padre están disponibles en sus clases hijas.

Una clase puede tener cero, uno o más padres. Una clase que no tiene padre es llamada clase raíz o clase base. Una clase que no tiene hijos es una clase hoja. Una clase que tiene exactamente un padre se dice que usa herencia sencilla; una clase que tiene más de un padre se dice que tiene herencia múltiple.

La Generalización y Especialización son equivalentes en cuanto al resultado: la jerarquía y herencia establecidas. La Especialización es una técnica muy eficaz para la extensión y reutilización.



Asociación

Es la relación estructural que especifica que objetos de una cosa están conectados a objetos de otras. Dada una conexión de asociación en dos clases, se puede navegar desde un objeto de una clase a un objeto de la otra clase, y viceversa.

Una asociación que conecta exactamente dos clases se llama asociación binaria, aunque se pueden asociar más clases la cual se llamaría asociación n-aria. Se dibuja como una línea continua.

Existen cuatro conceptos que se aplican a la asociación:

  • Nombre
  • Rol
  • Multiplicidad

 Nombre

Una asociación puede tener un nombre para describir su naturaleza.


Rol

Cuando una clase participa dentro de una asociación, tiene un rol específico que juega en la relación.





Multiplicidad


En el modelado, es importante definir cuantos objetos pueden estar conectados en una instancia de la asociación. Mostrándose la multiplicidad en el rol de la asociación.

Puede determinarse por la especificación de multiplicidad (mínima...máxima)
Uno y sólo uno
0..1 Cero o uno
M...N Desde M hasta N (enteros naturales)
* Cero o muchos
0..* Cero o muchos
1..* Uno o muchos (al menos uno)
Un número específico (N)




El diagrama de clases se desarrolla a través de información obtenida en los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboración. Los objetos encontrados durante el análisis son modelados en términos de la clase a la que instancian, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas.

DIAGRAMA DESPLIEGUE

DIAGRAMA DE COLABORACION

DIAGRAMA DE COLABORACIÓN 

Un diagrama de colaboración sirve para describir un determinado escenario de un caso de uso al mostrar la interacción entre el conjunto de objetos que cooperan en la realización de dicho escenario.

Suele ser conveniente especificar en la parte izquierda del diagrama, el caso de uso que se está representando para que resulte más sencilla su validación.

Los diagramas de colaboración conforman, junto con los diagramas de secuencia, los diagramas de interacción para modelar el comportamiento dinámico de un sistema haciendo énfasis en la secuencia de los mensajes intercambiados por un conjunto de objetos para un caso de uso en particular.

Tanto los diagramas de colaboración como los diagramas de secuencia muestran la misma información pero destacando un aspecto particular.  Los diagramas de secuencia muestran de forma explícita la secuencia de los mensajes intercambiados por los objetos, mientras que los diagramas de colaboración muestran de forma más clara cómo colaboran los objetos, es decir, con qué otros objetos tiene vínculos o intercambia mensajes un determinado objeto.

¿Qué es una Interacción?

Es el conjunto de mensajes intercambiados por los roles de clasificador a través de los roles de asociación. Un mensaje es una comunicación unidireccional entre dos objetos, un flujo de objeto con la información de un remitente a un receptor. Un mensaje puede tener parámetros que transporten valores entre objetos. Un mensaje puede ser una señal (comunicación explícita entre objetos, con nombre y asíncrona) o una llamada (la invocación sincronía de una operación con un mecanismo para el control, que retorna posteriormente al remitente). Un patrón de intercambios de mensajes que se realizan para lograr un propósito específico es lo que se denomina una interacción.


Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales) y ciclos en la ejecución.  En general, un diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado para un caso de uso hoja.



Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.

Los elementos que conforman un diagrama de colaboración son:

Instancias

Las instancias representan un objeto o instancia cualquiera de una clase determinada (no a una instancia real).

Una instancia u objeto se ilustra con un rectángulo, que contiene el nombre y la clase del objeto en un formato nombreObjeto: nombreClase.


Enlaces

Los enlaces representan una conexión entre instancias que indican navegabilidad y visibilidad entre ellas.  Establece una relación cliente-servidor entre las instancias


DIAGRAMA DE SECUENCIA

DIAGRAMA DE SECUENCIA.

Un diagrama de secuencia sirve para describir en detalle un determinado escenario de un caso de uso al mostrar la interacción entre el conjunto de objetos que cooperan en la realización de dicho escenario.

Suele ser conveniente especificar en la parte izquierda del diagrama, el caso de uso que se está representando para que resulte más sencilla su validación.

Los diagramas de secuencia conforman, junto con los diagramas de colaboración, los diagramas de interacción para modelar el comportamiento dinámico de un sistema haciendo énfasis en la secuencia de los mensajes intercambiados por un conjunto de objetos para un caso de uso en particular.

Tanto los diagramas de secuencia como los diagramas de colaboración muestran la misma información pero destacando un aspecto particular.  Los diagramas de secuencia muestran de forma explícita la secuencia de los mensajes intercambiados por los objetos, mientras que los diagramas de colaboración muestran de forma más clara cómo colaboran los objetos, es decir, con qué otros objetos tiene vínculos o intercambia mensajes un determinado objeto.

Un diagrama de secuencia muestra la existencia y duración de las instancias, pero no sus relaciones.

Un diagrama de secuencia tiene dos dimensiones, el eje vertical que representa el tiempo y el eje horizontal que represente los diferentes objetos. El tiempo avanza desde la parte superior del diagrama hacia la inferior.

Normalmente, en relación al tiempo sólo es importante la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podría introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su colocación debería poseer la mayor claridad posible.


Los elementos que conforman un diagrama de secuencia son similares a la notación de los diagramas de colaboración.  Adicional mente se encuentran los siguientes aspectos:


Una línea de vida por cada objeto

Un objeto se representa como una línea vertical discontinua, llamada línea de vida, con un rectángulo de encabezado con el nombre del objeto en su interior. También se puede incluir a continuación el nombre de la clase, separando ambos por dos puntos. La línea de vida indica el intervalo de tiempo durante el que existe ese objeto.

Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la línea comienza en el punto que representa ese instante y encima se coloca el objeto. Si el objeto es destruido durante la interacción que muestra el diagrama, la línea de vida termina en ese punto y se señala con un aspa de ancho equivalente al del foco de control.

En el caso de que un objeto existiese al principio de la interacción representada en el diagrama, dicho objeto se situará en la parte superior del diagrama, por encima del primer mensaje. Si un objeto no es eliminado en el tiempo que dura la interacción, su línea de vida se prolonga hasta la parte inferior del diagrama.

La línea de vida de un objeto puede desplegarse en dos o más líneas para mostrar los diferentes flujos de mensajes que puede intercambiar un objeto, dependiendo de alguna condición.

Uno o varios focos de control por cada objeto

Un foco de control o activación muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operación, ya sea directamente o mediante un procedimiento concurrente.

Se representa como un rectángulo delgado superpuesto a la línea de vida del objeto. Su largo dependerá de la duración de la acción. La parte superior del rectángulo indica el inicio de una acción ejecutada por el objeto y la parte inferior su finalización.


DIAGRAMAS DE ESTADO

DIAGRAMAS DE ESTADO 


Un diagrama de estados muestra la secuencia de estados que un objeto ó una interacción pueden atravesar durante su existencia en respuesta a eventos externos o internos que provocan los cambios de un estado a otro.

Un diagrama de estados es útil sólo para los objetos con un comportamiento
Significativo.  El resto de objetos se puede considerar que tienen un único
Estado.

Un diagrama de estados completa la definición de los casos de uso y sirven de base para el diseño de la interfaz de usuario. 

 Los diagramas de estados y los diagramas de interacción son complementarios.

Un  ejemplo de un diagrama de estados podría ser:

En un diagrama de estados el objeto analizado siempre posee un estado en un momento determinado, caracterizado por los valores de los atributos y los enlaces del objeto. El estado en el que se encuentra un objeto determina su comportamiento valido.

Un diagrama de estados es un grafo dirigido y deterministico que permite expresar concurrencia, sincronización (Si la comunicación es síncrona el objeto debe esperar la respuesta)y jerarquías de objetos.  Los estados inicial y final están diferenciados de los demás.

Los elementos que conforman un diagrama de estados son:

Estados

Un estado se representa mediante de un rectángulo con las esquinas redondeadas.  Puede tener de forma opcional uno o más secciones, tales como el nombre y las transiciones internas.

En la sección nombre se coloca el nombre del estado.  Mientras que en la sección transiciones internas se coloca una lista de acciones realizadas mientras el objeto están en un estado según el siguiente formato:

evento argumentos / acción

Cada nombre de evento puede aparecer más de una vez en un único estado.  Las acciones pueden utilizar los atributos y enlaces del objeto al que pertenecen o los parámetros de transiciones de entrada.  Las siguientes acciones utilizan palabras reservadas:

  • entrar: ocurre a la entrada del estado
  • salir: ocurren a la salida del estado
  • hacer: ocurren mientras está en el estado
  •  

Existen dos (2) estados especiales y que se distinguen del resto:

El estado inicial y el estado final.  El primero ocurren cuando se crea un objeto y el segundo ocurre cuando este desaparece. Se ilustran mediante un punto negro y un punto negro con un circulo externo respectivamente.



Subestados

Además de los compartimentos de nombre y transiciones internas, cada estado puede tener un compartimiento con un diagrama anidado.

Un estado se puede refinar ya sea mediante subestados concurrentes, a través de relaciones AND ó mediante subestados mutuamente excluyentes, utilizando la relación OR.

La expansión de un estado en subestados concurrentes se indica a través de un gráfico dividido en subregiones horizontales con líneas discontinuas.  Cada una de estas subregiones horizontales puede tener un nombre opcional y debe contener un diagrama de estados anidado, con estados disjuntos.

La expansión de un estado en subestados sirve para determinar su estructura en detalle.

En dichos ilustraciones, los estados iniciales y finales se consideran
Pseudoestados, es decir, son un artificio notacional, no un elemento
Significativo.


Eventos

Un evento es un suceso notable. Una situación que puede disparar una transición.

Los eventos pueden ser de distintos tipos, no necesariamente excluyentes:
Señal recibida de forma explícita
Llamada a una operación desde otro objeto.
Condición que se verifica
Transcurso de un período de tiempo

Los eventos de señales ocurren cuando se recibe una señal explicita desde otro objeto.  Los eventos de llamada ocurren se recibe una llamada de operación por parte de otro objeto. Las señales y las llamadas se denotan por el nombre del disparador de la transición.

Las señales y las llamadas se definen a través del siguiente formato:

evento ( [parametro: tipoDatos] )

Los eventos de condiciones ocurren si una condición dada ha sido verificada, normalmente descrita a través de una expresión lógica.  Estos eventos se denotan como condiciones de guarda en las transiciones, y no se les da nombre.

Un evento de condición se representa a través de una condición sin evento, utilizando por ejemplo:
when( pH>7.0 )

Los eventos de tiempo ocurren por el transcurrir de un cierto tiempo luego de que un evento ocurre o por la ocurrencia de una determinada fecha u hora.

Un evento por transcurso de tiempo es una expresión que evalúa dicho intervalo.   Por defecto indica el tiempo transcurrido en el estado en curso, por ejemplo:
after( 5 segundos )

Otros eventos temporales podrían ser especificados como condiciones, como por ejemplo:
when( fecha=“1/01/2000” )

Transiciones

Hay dos (2) tipos de transiciones:

Transiciones simples

Una transición simple es una relación entre dos estados, indicando que un objeto del primer estado entrará en el segundo estado y realizará ciertas operaciones cuando ocurra un evento dado si determinadas condiciones
se cumplen.

El disparador de la transición es la ocurrencia del evento que está etiquetando la transición.

El evento podría tener parámetros, que se utilizarán en:
  •  - Las acciones especificadas en la transición
  •  - Las acciones iniciadas en el siguiente estado


Los eventos se procesan de forma exclusiva en cada momento, nunca concurrente mente.

Si un evento no disparara ninguna transición, simplemente se ignora.

Las transiciones se representan por una flecha sólida que va de un estado a otro, etiquetada por un string de transición con el siguiente formato:

Evento ( [parámetros] ) [condición guarda] / acción

La condición de guarda es una expresión lógica en términos de los parámetros del evento disparado, atributos y enlaces del objeto al que pertenece la máquina de estados.