lunes, 9 de diciembre de 2013

POO(PROGRAMACION ORIENTADA A OBJETOS)


La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herenciacohesiónabstracciónpolimorfismoacoplamiento y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientación a objetos.

Introducción
Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:
El estado está compuesto de datos o informaciones; serán uno o varios atributos a los que se habrán asignado unos valores concretos (datos).

El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.

La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).
Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean Programación Orientada a Objetos, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo Noruego en Oslo. En este centro se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión dellenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo AdaBASICLisp y Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet y a la implementación de la máquina virtual de Java en la mayoría de navegadoresPHP en su versión 5 se ha modificado; soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

Conceptos fundamentales
La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Clase
Definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiiones y la creación de un objeto a partir de ellas.

Herencia
(Por ejemplo, herencia de la clase C a la clase D) es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de POO.

Objeto
Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos internos del sistema (del programa). Es una instancia a una clase.

Método
Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.

Evento
Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento la reacción que puede desencadenar un objeto; es decir, la acción que genera.

Atributos

Características que tiene la clase

Mensaje
Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

Propiedad o atributo
Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Estado interno
Es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.

Componentes de un objeto
Atributos, identidad, relaciones y métodos.

Identificación de un objeto
Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Características de la POO
Existe un acuerdo acerca de qué características contempla la "orientación a objetos". Las características siguientes son las más importantes:

Abstracción
Denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos, y, cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

Encapsulamiento
Significa reunir todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Modularidad
Se denomina modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la modularidad de diversas formas.

Principio de ocultación
Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no puedan cambiar el estado interno de un objeto de manera inesperada, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

Polimorfismo
Comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre; al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O, dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

Herencia
Las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple
.
Recolección de basura
La recolección de basura o garbage collection es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse expresamente.

DIAGRAMA DE CLASES


Introducción
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Elementos
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).
Ejemplo:
Una Cuenta Corriente que posee como característica:
Balance
Puede realizar las operaciones de:
Depositar
Girar
y Balance
El diseño asociado es:

Atributos y Métodos:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:
public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).
Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:
public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).
Herencia (Especialización/Generalización): 
Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.
Agregación: 
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamadaComposición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
En donde se destaca que:
Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
La composición (por Valor) se destaca por un rombo relleno.
La agregación (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina.
Asociación: 
La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.
Dependencia o Instanciación (uso):
Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).
Casos Particulares:
Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.
Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.
Ejemplo:
Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:
key: Variable por la cual se realiza la búsqueda, puede ser generica.
item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico




DIAGRAMA DE ESTADO




En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.

Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.

Diagramas de estado en UML
Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.




DIAGRAMAS DE CASO DE USO


Jacobson (1994), además de introducir los casos de uso como elementos primarios del desarrollo del software, también diseñó un diagrama para la representación gráfica de los casos de uso. El diagrama de casos de uso es ya también parte del UML.




Actores
Empleamos el término actor para llamar así al usuario, cuando desempeña ese papel con respecta al sistema.el gerente de comercial, el comerciante, el agente de ventas y el sistema de contabilidad.
En la mencionada organización, probablemente habrá diversos comerciantes. Además, un usuario puede desempeñar varios papeles. Por ejemplo, un comerciante de edad madura podría desempeñar el papel de gerente de comercio y además ser un comerciante normal. Por otra parte, un comerciante puede ser también agente de ventas. Cuando se trata con actores, conviene pensar en los papeles, no en las personas ni en los títulos de sus puestas.

Los actores llevan a cabo casos de uso. Un mismo actor puede realizar muchos casos de uso; A la inversa, un caso de uso puede ser realizado Por varios actores.

En la práctica, los actores son muy útiles cuando se trata de definir los casos de uso. Al enfrentarse con un sistema grande, puede ser difícil obtener una lista de casos de uso. Es más fácil en tales situaciones definir la lista de los actores y después tratar de determinar los casos de uso de cada actor.
Obsérvese que no es necesario que los actores sean seres humanos, a pesar de que los actores estén representados por figuras humanas en el diagrama del caso de uso. El actor puede ser también un sistema externo que necesite cierta información del sistema actual. En la figura 3-1 se puede apreciar la necesidad de actualizar las cifras del sistema de contabilidad.

El tema de las interacciones con sistemas externos produce mucha confusión y variaciones de estilo entre los usuarios de los diagramas de casos de uso. .
Algunos sienten que todas las interacciones con sistemas remotas deben aparecer en el diagrama. Por ejemplo, si se necesita acceder a Reuters con el fin de cotizar un contrato, se deberá mostrar el vínculo entre el caso Negocia precio y Reuters.

Algunas personas consideran que sólo se deben mostrar los casos de uso con interacción externa, cuando quien inicia el contacto es otro sistema. Según esta regla, sólo se mostraría el caso de uso del sistema de contabilidad si dicho sistema invocara algún proceso que le dijera al sistema fuente que la hiciera.
Algunas personas consideran que sólo se deben mostrar los actores del sistema cuando ellas sean las que necesiten el caso de uso. Por tanto, si el sistema genera cada noche un archivo que después es recogido por el sistema de contabilidad, entonces éste es el actor que corresponde, debido a que es quien necesita el archivo generado.
Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor. Por el contrario, consideran que un actor es un usuario que desea algo del sistema (Por ejemplo, un archivo en particular). En el caso de nuestro ejemplo de sistema, los actores serían los auditores internos de la compañía.
Tomando en cuenta todos los factores, me inclino por la opción 3.
Todos los casos de uso tratan sobre funcionalidad requerida externamente. Si el sistema de contabilidad necesita un archivo, entonces ése es un requerimiento que debe satisfacerse.
El acceso a Reuters es importante, pero no una necesidad del usuario. Si sigue la opción 4, se termina por analizar el sistema de contabilidad, cosa que probablemente usted no quisiera hacer. Dicho lo anterior, siempre se deben cuestionar los casos de uso con los actores del sistema, descubrir los objetivos reales del usuario y considerar formas alternas para lograrlos.
Cuando trabaje con actores y casos de uso, no se preocupe mucho por la relación exacta entre ellos. Lo que le interesa casi siempre son los casos de uso; los actores son sólo un modo de llegar a ellos. Siempre y cuando obtenga todos los casos de uso, no se preocupe por los detalles acerca de los actores.
Sin embargo, una situación en la que los actores sí desempeñan un papel es en la configuración del sistema para varios tipos de usuarios. Si el sistema tiene casos de uso que corresponden a funciones de usuario de alto nivel, usted puede emplear los vínculos entre casos de uso y actores para hacer los perfiles de los usuarios. Cada usuario tendría una lista asociada de nombres de actores con la que se determinarían los casos de uso que puede ejecutar cada uno.

Otra buena razón para rastrear a los actores es la necesidad de saber cuáles son los casos de uso que quiere cada uno. Esto puede ser importante cuando usted esté evaluando las necesidades que compiten entre ellos. La comprensión de los actores puede servir para negociar entre demandas de desarrollo que compiten entre sí. También pueden ser útiles para especificar una política de seguridad.

Algunos casos de uso no tienen vínculos claros con actores específicos. Considérese una compañía de servicios públicos. Por supuesto, uno de sus casos de uso es "envío de factura". No es tan fácil, sin embargo, identificar un actor asociado. No existe un papel de usuario en particular que solicite una factura. La factura se envía al cliente, pero el cliente no protestaría si esto no se llevara a cabo. Lo que más se parece a un actor es el Departamento de facturación, en el sentido de que obtiene un valor del caso de uso. Pero la facturación generalmente no interviene en la ejecución del caso de uso.
Los actores pueden tener varios papeles con respecto a un caso de uso. Pueden ser los que obtienen un valor del caso de uso, o tal vez sólo participen en él. Dependiendo de cómo se utilice la relación entre los actores será la importancia de los papeles que desempeñen los actores. Por mi parte, suelo preocuparme más por controlar el desarrollo del sistema. Así, en general, siento un mayor interés por quién quiere que se construya un caso de uso (por lo general, quienes obtienen un valor del caso de uso).
La clave es tener en cuenta que algunos casos de uso no saltarán a la vista como resultado de ponerse á pensar en los casos de uso de cada actor. Si esto sucede, no se preocupe demasiado. Lo importante es comprender los casos de uso y los objetivos del usuario que satisfacen.

Una buena fuente para identificar los casos de uso son los eventos externos. Piense en todos los eventos del mundo exterior ante los cuales usted quiera reaccionar. Un evento dado puede provocar una reacción en el sistema en la que no intervenga el usuario, o puede causar una reacción que provenga principalmente de los usuarios. La identificación de los eventos ante los que se necesitará reaccionar será de ayuda en la identificación de los casos de uso

Uses y extends

 Éstos representan las relaciones de uses (usa) y extends (extiende) entre los casos de uso. Con frecuencia, tales relaciones son fuente de confusión para quienes mezclan los significados de ambos conceptos, de modo que tómese el tiempo necesario para comprenderlos.

Se usa la relación extends cuando se tiene un caso de uso que es similar a otro, pero que hace un poco más.
En nuestro ejemplo, el caso de uso es Captura negociación. Éste es un caso en que todo sucede sin contratiempos. Sin embargo, hay situaciones que pueden estropear la captura de una negociación. Una de ellas surge cuando se excede algún límite, por ejemplo, la cantidad máxima que la organización de comercio ha establecido para un cliente en particular. En este ejemplo, dado que no efectuamos el comportamiento habitual asociado con dicho caso de uso, efectuamos una variación.
Podríamos poner esta variación dentro del caso de uso Captura negociación. Sin embargo, esto llenaría dicho caso de uso de una gran cantidad de lógica especial, la cual oscurecería el flujo "normal".
Otro modo de abordar la variación es poner la conducta normal en un caso y la conducta inusual en cualquier otro lado. A continuación describiremos la esencia de la relación extends.
Primero obtenga el caso de uso simple y normal.

En cada paso de ese caso de uso, pregúntese "¿Qué puede fallar aquí?", "¿Cómo podría funcionar esto de modo diferente?"
Dibuje todas las variaciones como extensiones del caso de uso dado. Con frecuencia habrá un buen número de extensiones. Si se listan por separado serán mucho más fáciles de entender.
Puede suceder que se tenga qué dividir un caso de uso tanto en la etapa de elaboración como en la de construcción. Durante la elaboración, suelo dividir los casos de uso que se estén volviendo muy complicados.

En la etapa de construcción del proyecto(Enlace con un H2 del capitulo 2), realizo la división cuando no puedo construir un caso de uso completo en una sola iteración. Divido los casos de uso complejos en un caso normal y unas cuantas extensiones, y luego construyo el caso normal en una sola iteración y las extensiones como partes de una o varias iteraciones posteriores. (Por supuesto, aquí sucederán cambios en el plan de compromisos, lo que deberá negociarse con los usuarios.)

Las relaciones uses ocurren cuando se tiene una porción de comportamiento que es similar en más de un caso de uso y no se quiere copiar la descripción de tal conducta. Por ejemplo, tanto Analiza riesgo como Negociación precio requieren valuar la negociación. La descripción de la valuación de la negociación requiere de bastante escritura, y yo odio las operaciones de copiar y pegar. Por tanto, elaboro un caso de uso separado, Negociación valor, para esta situación y me refiero a él desde los casos de uso originales.
Adviértanse las diferencias entre extends y uses. Ambos implican la factorización de comportamientos comunes de varios casos de uso, dejando un solo caso de uso común que es empleado, o extendido, por otros varios casos de uso. No obstante, la intención es la que cambia.

En sus vínculos con los actores, estos dos tipos de relación implican asuntos diferentes. Tratándose de la relación extends, los actores tienen que ver con los casos de uso que se están extendiendo. Se supone que un actor dado se encargará tanto del caso de uso base como de todas las extensiones. En cuanto a las relaciones uses, es frecuente que no haya un actor asociado con el caso de uso común. Incluso si lo hay, no se considera que esté llevando a cabo los demás casos de uso.

Aplique las siguientes reglas.

Utilice extends cuando describa una variación de conducta normal.

Emplee uses para repetir cuando se trate de uno o varios casos de uso y desee evitar repeticiones.
Es probable que oiga usted el término escenario en conexión con los casos de uso. Cabe aclarar que este término se emplea de manera inconsistente. Algunas veces, escenario se usa como sinónimo de caso de uso. En el contexto del UML, la palabra escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso. Por ejemplo, para ordenar algunas mercancías, tendremos un solo caso de uso con varios escenarios asociados: uno en el cual todo va bien; otro donde no hay suficientes mercancías; otro en el que nuestro crédito es rechazado, y así por el estilo.

Conforme vaya realizando sus tareas de modelado, encontrará modelos que expresen la manera de hacer sus casos de uso, ya sea entre el software o entre la gente. Es evidente que hay más de una manera de llevar a cabo un caso de uso. En la jerga del UML, decimos que un caso de uso puede tener muchas realizaciones.
Con frecuencia se realizan varios bosquejos sobre los distintas formas de resolver un caso de uso, con el fin de discutirlas y determinar con cuál va a trabajar. Si hace esto, recuerde guardar información acerca de las realizaciones descartadas, incluyendo las notas de por qué se descartaron. No quisiera contarles cuántas horas he desperdiciado en discusiones del estilo de "yo sé que existe una razón por la que no hicimos eso, pero..."

DIAGRAMA DE DESPLIEGUE


El Diagrama de despliegue es un diagrama estructurado que muestra la arquitectura del sistema desde el punto de vista del despliegue (distribución) de los los artefactos del software en los destinos de despliegue.
Los artefactos representan elementos concretos en el mundo físico que son el resultado de un proceso de desarrollo. Ejemplos de artefactos son archivos ejecutables, bibliotecas, archivos, esquemas de bases de datos, archivos de configuración, etc

Destino de despliegue está generalmente representado por un nodo que es o bien de los dispositivos de hardware o bien algún entorno de ejecución de software. Los nodos pueden ser conectados a través de vías de comunicación para crear sistemas en red de complejidad arbitraria.
Hay que tener en cuenta, que en los diagramas  UML 1.x de despliegue los componentes eran enviados directamente a los nodos. En UML 2.x, los artefactos se despliegan en los nodos, y los artefactos pueden manifestar componentes (aplicar). Los componentes se implementa en nodos indirectamente a través de los  artefactos.

Los diagramas de despliegue pueden describir la arquitectura a nivel de especificación (también llamado nivel de tipo) o al nivel de instancia (de manera similar a los diagramas de clases y diagramas de objetos).

Los diagramas de despliegue de nivel de especificación muestran una visión general del despliegue de los artefactos hacia los destinos de despliegue , sin hacer referencia a casos concretos de artefactos o nodos.
Los diagramas de de nivel de instancia muestran el despliegue de instancias de artefactos en instancias específicas de los destinos de despliegue . Se pueden utilizar por ejemplo para mostrar las diferencias existentes en nombres/identificaciones en  ambientes de despliegue a desarrollo,  de "staging" o de producción, entre construcciones específicas o servidores de despliegue o dispositivos

.

DIAGRAMA DE SECUENCIA


En un diagrama de secuencia se indicarán los módulos o clases que forman parte del programa
y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada.
Se realizan diagramas de secuencia para definir acciones que se pueden realizar en la aplicación
en cuestión. Así, en el caso de una aplicación para jugar al ajedrez, se podrían realizar
diagramas de secuencia para “jugar una partida” o bien para acciones más específicas como
“mover pieza”.

El detalle que se muestre en el diagrama de secuencia debe estar en consonancia con lo que se
intenta mostrar o bien con la fase de desarrollo en la que esté el proyecto, no es lo mismo un
diagrama de secuencia que muestre la acción de “mover pieza” a otro que sea “mover caballo”,
o bien no es lo mismo un diagrama de secuencia “mover pieza” que verifique ciertos parámetros
antes de mover como la viabilidad del movimiento con respecto a una estrategia marcada a una
diagrama que no muestre este nivel de detalle por estar en una fase inicial de diseño del
sistema.

El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el
diagrama y a quién. En una primera fase de diseño podemos poner clases grandes y ficticias,
que representen un paquete/librería o, si nuestro programa está compuesto por varios
ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseñando el programa y queremos dejar bien atados
los detalles entre dos programadores, que cada uno va a programar una de las clases o módulos
que participan, entonces debemos posiblemente ir al nivel de clase real de codificación y
método, con parámetros y todo, de forma que los programadores tengan claro que métodos van
a implementar, qué deben llamar de la clase o módulo del otro, etc. Incluso si es un diagrama
para presentar al cliente, podemos hacer un diagrama de secuencia en el que sólo salga el actor
"jugador" y una única clase "juego ajedrez" que representa nuestro programa completo, de forma
que el cliente vea qué datos y en qué orden los tiene que meter en el programa y vea qué
salidas y resultados le va a dar el programa.

El siguiente puede ser un diagrama de secuencia del ejemplo del ajedrez a un nivel de diseño
muy preliminar.


DIAGRAMA DE COLABORACIÓ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. Se toma como ejemplo el caso de uso Pedir Producto ya descrito como diagrama de secuencia.


Objeto
Un objeto se representa con un rectángulo, que contiene el nombre y la clase del objeto en un formato nombreObjeto: nombreClase.

Enlaces
Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una linea contínua que une a dos objetos. Esta acompañada por un número que indica el orden dentro de la interacción y por un estereotipo que indica que tipo de objeto recibe el mensaje. Pueden darse varios niveles de subindices para indicar anidamiento de operaciones. Los estereotipos indican si el objeto que recibe el mensaje es un atributo (association y se asume por defecto), un parámetro de un mensaje anterior, si es un objeto local o global.

Flujo de mensajes
Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace.

Marcadores de creación y destrucción de objetos
Puede mostrarse en la gráfica cuáles objetos son creados y destruidos, agregando una restricción con la palabra new o delete, respectivamente, cercana al rectángulo del objeto

Objeto compuesto
Es una representación alternativa de un objeto y sus atributos. En esta representación se muestran los objetos contenidos dentro del rectángulo que representa al objeto que los contiene. Un ejemplo es el siguiente objeto ventana





HISTORIA UML

                                                           Historia de UML


El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.


Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguaje de programación, así como construir modelos por ingeniería inversa a partir de programas existentes.

La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.




De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.



En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).

Objetivos

Durante el desarrollo del UML sus autores tuvieron en cuenta:
Proporcionar una notación y semánticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporáneo de una forma directa y económica.
Proporcionar las semánticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnología de componentes, el cómputo distribuido, etc.
Proporcionar mecanismos de extensión de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.
Proporcionar mecanismos de extensión de forma que aproximaciones de modelado futuras podrían desarrollarse encima del UML.
Permitir el intercambio del modelos entre una gran variedad de herramientas.
Proporcionar semánticas suficientes para especificar las interfaces a bibliotecas para la comparición y el almacenamiento de componentes del modelo.


Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir.
UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores.
UML no pretende ser un método de desarrollo completo.
Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
Imponer un estándar mundial.


Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:
Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos.
Proporcionar mecanismos de extensión y especialización.
Ser independiente del proceso de desarrollo y de los lenguajes de programación.
Proporcionar una base formal para entender el lenguaje de modelado.
Fomentar el crecimiento del mercado de las herramientas OO.
Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y componentes.
Integrar las mejores prácticas utilizadas hasta el momento.


El UML debe entenderse como un estándar para modelado y no como un estándar de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo común (que unifica las semánticas) y una notación común que proporcione una representación de esas semánticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental. Bajo estas líneas genéricas proponen el proceso software definido en una de las extensiones del UML (Objectory Extension for Software Enginnering) , pero en general el proceso software es fuertemente dependiente de la organización y del dominio de aplicación



Los conceptos y modelos de UML pueden agruparse en las siguientes áreas conceptuales:

Estructura estática:

Cualquier modelo preciso debe primero definir su universo, esto es, los conceptos clave de la aplicación, sus propiedades internas, y las relaciones entre cada una de ellas. Este conjunto de construcciones es la estructura estática. Los conceptos de la aplicación son modelados como clases, cada una de las cuales describe un conjunto de objetos que almacenan información y se comunican para implementar un comportamiento. La información que almacena es modelada como atributos; La estructura estática se expresa con diagramas de clases y puede usarse para generar la mayoría de las declaraciones de estructuras de datos en un programa.

Comportamiento dinámico:

Hay dos formas de modelar el comportamiento, una es la historia de la vida de un objeto y la forma como interactúa con el resto del mundo y la otra es por los patrones de comunicación de un conjunto de objetos conectados, es decir la forma en que interactúan entre sí. La visión de un objeto aislado es una maquina de estados, muestra la forma en que el objeto responde a los eventos en función de su estado actual. La visión de la interacción de los objetos se representa con los enlaces entre objetos junto con el flujo de mensajes y los enlaces entre ellos. Este punto de vista unifica la estructura de los datos, el control de flujo y el flujo de datos.

Construcciones de implementación:
Los modelos UML tienen significado para el análisis lógico y para la implementación física. Un componente es una parte física reemplazable de un sistema y es capaz de responder a las peticiones descritas por un conjunto de interfaces. Un nodo es un recurso computacional que define una localización durante la ejecución de un sistema. Puede contener componentes y objetos.

Mecanismos de extensión:
UML tiene una limitada capacidad de extensión pero que es suficiente para la mayoría de las extensiones que requiere el día a día sin la necesidad de un cambio en el lenguaje básico. Un estereotipo es una nueva clase de elemento de modelado con la misma estructura que un elemento existente pero con restricciones adicionales.

Organización del modelo:
La información del modelo debe ser dividida en piezas coherentes, para que los equipos puedan trabajar en las diferentes partes de forma concurrente. El conocimiento humano requiere que se organice el contenido del modelo en paquetes de tamaño modesto. Los paquetes son unidades organizativas, jerárquicas y de propósito general de los modelos de UML. Pueden usarse para almacenamiento, control de acceso, gestión de la configuración y construcción de bibliotecas que contengan fragmentos de código reutilizable.

Elementos de anotación
Los elementos de anotación son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clasificar y hacer observaciones sobre cualquier elemento de un modelo.
El tipo principal de anotación es la nota que simplemente es un símbolo para mostrar restricciones y comentarios junto a un elemento o un conjunto de elementos

Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML. Dependencia, asociación, generalización y realización, estas se describen a continuación

Dependencia
Es una relación semántica entre dos elementos en la cual un cambio a un elemento (el elemento
independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Se representa como una línea discontinua, posiblemente dirigida, que a veces incluye una etiqueta.

Asociación
Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un tipo especial de asociación y representa una relación estructural entre un todo y sus partes. La asociación se representa con una línea continua, posiblemente dirigida, que a veces incluye una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad y roles de los objetos involucrados
Generalización
Es una relación de especialización / generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, la generalización se representa con una línea con punta de flecha vacía.
Realización
Es una relación semántica entre clasificadores, donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las clases y componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan. La realización se representa como una mezcla entre la generalización y la dependencia, esto es, una línea discontinua con una punta de flecha vacía .

Diagramas


Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un sistema de forma que un diagrama es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema.

Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas).

Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantáneas de los diagramas de clases y cubren la vista de diseño estática o la vista de procesos estática desde la perspectiva de casos reales o prototípicos.

Diagramas de Casos de Usos
Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus relaciones. Cubren la vista estática de los casos de uso y son especialmente importantes para el modelado y organización del comportamiento.

Diagramas de Secuencia y de Colaboración
Tanto los diagramas de secuencia como los diagramas de colaboración son un tipo de diagramas de interacción. Constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas de secuencia enfatizan el ordenamiento temporal de los mensajes mientras que los diagramas de colaboración muestran la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de colaboración sin perdida de información, lo mismo ocurren en sentido opuesto.

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones, eventos y actividades. Estos diagramas cubren la vista dinámica de un sistema y son muy importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración.

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el flujo de control entre objetos.

Diagramas de Componentes
Muestra la organización y las dependencias entre un conjunto de componentes. Cubren la vista de la implementación estática y se relacionan con los diagramas de clases ya que en un componente suele tener una o más clases, interfaces o colaboraciones

Diagramas de Despliegue
Representan la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Muestran la vista de despliegue estática de una arquitectura y se relacionan con los componentes ya que, por lo común, los nodos contienen uno o más componentes.