jueves, 5 de diciembre de 2013

POO


POO


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.

DIAGRAMAS DE INTERACCIÓN

Contenido

  • Modelando flujos de control por orden de tiempo
  • Modelado flujos de control por organización
  • Ingeniería hacia adelante e ingeniería inversa


Definiciones

Diagramas de interacción 

Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos. Son importantes para modelar los aspectos dinámicos de un sistema y para construir sistemas ejecutables a través de ingeniería hacia adelante e ingeniería inversa.

Comúnmente contienen:

  • Objetos
  • Enlaces
  • Mensajes


Pueden servir para visualizar, especificar, construir y documentar los aspectos dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar un flujo particular de control de un caso de uso.

Los diagramas de interacción están conformados por los diagramas de secuencia y los diagramas de colaboració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.





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.


DIAGRAMAS DE CASO DE USO

CONCEPTOS BÁSICOS

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

  • Actores
  • Casos de uso
  • Relaciones de uso, herencia y comunicación


Actor

Un actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de vendedor con respecto al sistema puede ser realizado por un vendedor o bien por el supervisor.

Caso de uso

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones
Asociación 
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

Dependencia o Instanciación 

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

Generalización 

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Relaciones en un diagrama de casos de uso

Entre los elementos de un diagrama de Casos de uso se pueden presentar tres tipos de relaciones, representadas por líneas dirigidas entre ellos (del elemento dependiente al independiente)
Comunica (communicates). Relación entre un actor y un caso de uso, denota la participación del actor en el caso de uso determinado. En el diagrama de ejemplo todas las líneas que salen del actor denotan este tipo de relación.

Usa (uses).

Relación entre dos casos de uso, denota la inclusión del comportamiento de un escenario en otro. En el caso del ejemplo el caso de uso Cancelar incluye en su comportamiento DarVueltas; y PedirProducto incluye también DarVueltas


Extiende (extends). 

Relación entre dos casos de uso, denota cuando un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso de uso que extienda la forma de pedir azucar, parta que permita escoger el tipo de azuacr (normal, dietético moreno) y además la cantidad en las unidades adecuadas para cada caso (cucharaditas, bolsitas o cucharaditas, respectivamente). Un posible diagrama se muestra a continuación





DIAGRAMA DE PAQUETES


un diagrama de paquetes muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido

partes del diagrama de paquetes

paquetes:Agrupación de elementos que pueden ser casos de usos clases o componentes es posible anidar paquetes entre si se representan mediante un símbolo en forma de carpeta el nombre se coloca en la pestaña y el contenido dentro de la carpeta la visibilidad de los elementos devén indicarse con los símbolos “+” “-“”#”+

dependencias: indica que un elemento de un paquete requiere a otro de un paquete distinto . Se representa mediante una flecha discontinua con inicio en el paquete que depende del otro 


DIAGRAMAS DE COMPONENTES

Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente puede comprender una gran porción de un sistema.



El diagrama de abajo muestra algunos componentes y sus relaciones internas. Los conectores Ensamble ‘vinculan’ las interfaces proporcionadas suministrada por el Producto y el Cliente a las interfaces requeridas especificadas por orden. Una relación de dependencia traza los detalles de la cuenta asociada del cliente a la interfaz requerida, ‘pago’, indicada por orden

Los componentes son similares en práctica a los diagramas de paquete como los límites definidos y se usan para agrupar elementos en estructuras lógicas. La diferencia entre Diagramas de Paquete y Diagramas de Componente es que los diagramas de componente ofrecen un mecanismo de agrupamiento más rico semántica mente. Con los Diagramas de Componente todos los elementos del modelo son privados mientras que los diagramas de Paquete solo muestran ítem públicos.

Representando Componentes

Los componentes se representan como un clasificador rectangular con la clave «componente», opcional mente el componente se puede mostrar como un rectángulo con un icono de componente en la esquina derecha arriba.


Interfaces Requeridas

El conector Ensamble une la interfaz requerida del componente (Componente1) con la interfaz proporcionada de otro componente (Component2); esto permite que un componente provea los servicios que otro componente requiere. Las Interfaces son colecciones de uno o más métodos que pueden o no contener atributos.


Componentes con puertos 

Usar puertos con Diagramas de Componentes permite que se especifique un servicio o comportamiento a su entorno así como también un servicio o comportamiento que un componente requiere. Los puertos pueden especificar entradas, salidas así como también operar bi-direccionalmente. El siguiente diagrama detalla un componente con un puerto para servicios En Línea conjuntamente con dos interfaces proporcionadas Ordenar Entrada y Seguimiento así como también una interfaz requerida Pago.