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.





TIPOS DE DIAGRAMAS

Tipos de Diagramas de UML

Estructura

Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de estructura compuesta
Diagrama de paquetes
Diagrama de despliegue

Comportamiento

Diagrama de casos de uso
Diagrama de actividades
Diagrama de estado

Interacción

Diagrama de secuencia
Diagrama de colaboración
Diagrama de tiempo
Diagrama de interacción

DIAGRAMA DE COLABORACIÓN


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









DIAGRAMAS 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.






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.






UML

UML 


Lenguaje Unificado de Modelado

 (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). 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.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

                                                                                                                             

HISTORIA 

Antes de UML 1.x


Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se unió a Rational en 1995 después de que su compañía, Objectory AB, fuera comprada por Rational. Los tres metodologías eran conocidos como los Tres Amigos, porque se sabía de sus constantes discusiones sobre las prácticas metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.

Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.


UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integradas al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.

Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.


El Lenguaje de Modelado Unificado es un estándar internacional:

ISO / IEC 19501:2005 Tecnología de la información - Procesamiento distribuido abierto - Lenguaje de Modelado Unificado (UML) Versión 1.4.2


UML 2.x
UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML 1.3, 1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.
Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML 2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser formalmente liberada.