INFORMATICA

INTRODUCCION

¿Por que nace el UML? La falta de estandarización en la manera de representar gráficamente un modelo, un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML.

¿Quienes y como crearon el UML? El lenguaje UML comenzó, cuando Rumbaugh se unió a la compañía Rational fundada por Booch, para unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). En octubre de 1995, Jacobson, se unió a Rational y la colaboración de otras empresas para que aportaran sus ideas. Condujeron a la definición de la primera versión de UML. El 14 de noviembre de 1997 cuando el Grupo Administrador de Objetos (Object Management Group, OMG) publicó como estándar la versión 1.1 del Lenguaje Unificado de Modelado (Unified Modeling Language, UML)

¿En que se centra el UML? UML es un lenguaje, que proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Se puede aplicar en el desarrollo de software entregando 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.

Los elementos de UML se clasifican en estructurales (Clases, interfaces. Colaboraciones, casos de uso, clases activas, componentes y nodos), de comportamiento (interacciones y máquinas de estado), de agrupación (paquetes) y de anotación (notas). A su vez, hay cuatro tipos de relaciones: De Dependencia, de asociación, de agrupación y de realización. Para construir un plano de software que tenga sentido, lo que se hace es combinar los elementos estructurales con sus respectivas relaciones, según sea el caso, obteniendo como resultado uno de los nueve diagramas que existen en UML, a saber: De clases, De objetos, de casos de uso, de secuencia, de colaboración, de estados, de actividades, de componentes y de despliegue.

UML nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.

ORIENTACION A OBJETOS

Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño, desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del código y reusabilidad, código que es dificil de modificar, ciclos de desarrollo largos y tecnicas de codificacion no intuituvas.

Un lenguaje orientado a objetos ataca estos problemas. Tiene tres características basicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. Muchos lenguajes cumplen uno o dos de estos puntos; muchos menos cumplen los tres. La barrera más difícil de sortear es usualmente la herencia.

El concepto de programación orientada a objetos (OOP) no es nuevo, lenguajes clásicos como SmallTalk se basan en ella. Dado que la OOP. se basa en la idea natural de la existencia de un mundo lleno de objetos y que la resolución del problema se realiza en términos de objetos, un lenguaje se dice que está basado en objetos si soporta objetos como una característica fundamental del mismo.

El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Podemos definir un objeto como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización.

Esta definición especifica varias propiedades importantes de los objetos. En primer lugar, un objeto no es un dato simple, sino que contiene en su interior cierto número de componentes bién estructurados. En segundo lugar, cada objeto no es un ente aislado, sino que forma parte de una organización jerárquica o de otro tipo.

ESTRUCTURA DE UN OBJETO

Un objeto puede considerarse como una especie de cápsula dividida en tres partes:

1 - RELACIONES

2 - PROPIEDADES

3 - METODOS

Cada uno de estos componentes desempeña un papel totalmente independiente:

Las relaciones permiten que el objeto se insterte en la organización y están formadas esencialmente por punteros a otros objetos.

Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización.

Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia.

Encapsulamiento y ocultación

Como hemos visto, cada objeto es una estructura compleja en cuyo interior hay datos y programas, todos ellos relacionados entre sí, como si estuvieran encerrados conjuntamente en una cápsula. Esta propiedad (encapsulamiento), es una de las características fundamentales en la OOP.

Los objetos son inaccesibles, e impiden que otros objetos, los usuarios, o incluso los programadores conozcan cómo está distribuída la información o qué información hay disponible. Esta propiedad de los objetos se denomina ocultación de la información.

Esto no quiere decir, sin embargo, que sea imposible conocer lo necesario respecto a un objeto y a lo que contiene. Si así fuera no se podría hacer gran cosa con él. Lo que sucede es que las peticiones de información a un objeto. deben realizarse a través de mensajes dirigidos a él, con la orden de realizar la operación pertinente. La respuesta a estas ordenes será la información requerida, siempre que el objeto considere que quien envía el mensaje está autorizado para obtenerla.

El hecho de que cada objeto sea una cápsula facilita enormemente que un objeto determinado pueda ser transportado a otro punto de la organización, o incluso a otra organización totalmente diferente que precise de él. Si el objeto ha sido bien construído, sus métodos seguirán funcionando en el nuevo entorno sin problemas. Esta cualidad hace que la OOP sea muy apta para la reutilización de programas.

Organización de los objetos

En principio, los objetos forman siempre una organización jerárquica, en el sentido de que ciertos objetos son superiores a otros de cierto modo.

Existen varios tipos tipos de jerarquías: serán simples cuando su estructura pueda ser representada por medio de un "arbol". En otros casos puede ser más compleja.

APLICACION DE LA ORIENTACION A OBJETOS

El desarrollo de los lenguajes de programación ha sufrido constantes transformaciones y mejoras aprovechando la experiencia acumulada en desarrollos anteriores así como las reflexiones que sobre el tema han ido surgiendo. En este marco se ha evolucionado desde lenguajes donde podía programarse sin ninguna estructura definida, a lenguajes estructurados y finalmente a lenguajes orientados a objetos, siendo cada uno de ellos una evolución natural de sus antecesores, superando sus diferencias y aportando capacidades nuevas. Respecto al cálculo de estructuras, y a pesar del dominio de los lenguajes orientados a objetos en la mayoría de los campos de la programación, no se explotan todavía todas las posibilidades ofrecidas por las nuevas técnicas de programación, lo que se traduce en códigos poco flexibles en ciertos aspectos (principalmente en lo que a manejo de información se refiere) y con una cierta dificultad para ser mantenidos y ampliados. En este artículo se revisa la evolución de los lenguajes de programación, se apuntan y comentan las mejoras introducidas en este campo recientemente y se detallan posibles aplicaciones al calculo de estructuras. Para ellos se expone una base teórica de la programación orientada a objetos y se desarrolla su aplicación en un programa de cálculo estructural diseñado por los autores y basado en las ideas anteriores.

USO DE RELACIONES

Trabajando con los miembros de mi team de desarrollo me di cuenta que a los programadores le costaba interpretar los Diagramas de Clases que el analista realizaba. O existían interpretaciones ambiguas de lo que el realizaba, perdiendo asi la principal funcionalidad del lenguaje UML. Especialmente en cuanto a las relaciones que existían entre las clases. Por eso me dispuse a realizar este pequeño documento, donde voy a tratar de explicar que significa cada relación, en mis palabras, y como se traduce esto a código.

AGREGACION, COMPOSICION, INTERFACES Y REALIZACION

Asociación:

Es generalmente, una relación estructural entre clases, es decir, que en el ejemplo, existe un atributo de la clase medio de transportes, que es del tipo Conductor. La navegalidad nos muestra donde esta ubicado el atributo. Es decir cual es la clase que tiene contiene el atributo si ésta no lo mostrase. La multiplicidad en una Asociación dice bastante, ya que de eso dependerá si el atributo, es una colección o simplemente una variable de referencia a un objeto.

Agregación:

Es una relación que se derivó de la asociación, por ser igualmente estructural, es decir que contiene un atributo, que en todos los casos, será una colección, es decir un Array, Vector, Collections, etc, y además de ello la clase que contiene la colección debe tener un método que agregue los elementos a la colección. También se puede leer como que un medio de transporte tiene varios pasajeros.
Nos esta diciendo que los objetos pasajero forman parte del objeto medio de transporte.Pero, su ciclo de vida no esta atado al del objeto medio de transporte. Es decir si el Autobus se destruye los pasajeros pueden seguir existiendo independientemente, ( o por lo menos por eso rezaríamos)

Composición

Al igual que en la agregación, es una relación estructural pero se le suma, que tiene un método de destrucción de los objetos. Y a diferencia de la asociación, el ciclo de vida del objeto area está relacionado con el del objeto ruta. Es decir que si la ruta de viaje se levanta, las áreas que surgían a partir de ella desaparecen. También se puede leer como que una ruta tiene varias áreas de cobertura.
Mucho se ha discutido a cerca de las agregaciones y las composiciones, el debate es casi tan caliente como el de los include y extends de los casos de uso. Ya que algunos sostienen que los lenguajes orientados a objetos, tienen garbage collector, por lo que no necesitan métodos de destrucción de los objetos (relacionados a los ciclos de vida en la compocición). Y que la programación es la misma para las composiciones y las agregaciones, y que la diferencia es meramente conceptual entre una y otras. Es mas existen varias interpretaciones, pero la expuesta es a la cual yo adhiero.

Clase de Asociación

Es una Clase que surge de una multiplicidad de muchos a muchos, y fue incorporada en UML para dar soporte a este caso. Se sacan los atributos de las clases involucradas y se los incorpora a una clase a parte. Al igual que las anteriores hace referencia a una relación estructural. En el ejemplo son los objetos viaje y ruta

Realización

Es una relación de contrato con otra clase. Se la utiliza para implementar una interfaz. En lenguajes como java o php utilizamos la palabra reservada “implements”

public class Viaje implements Registrable{…}

Generalmente cuando no estamos seguros si “algo” es una interfaz o una clase abstracta, por que dibujaron los tag que hacen referencias a las interfaces, debemos ver la relación para saber.

Generalización

Es una relación de herencia. Se puede decir que es un relación “es un tipo de” ( IS-A ). En nuestro ejemplo: “un Autobus es un tipo de Medio de transporte”. Es entre una clase hija y su clase madre. En la codificación podemos encontrar la palabra “extends” que hace referencia a esta relación. Además podemos encontrar palabras claves tales como “this” y “super” ( Java ) o "self" y “parent” ( PHP ). Para darnos cuenta que existe una relación de este tipo involucrada.

public class Autobus extends MedioDeTransporte{…}

Dependencia

Es una relación de uso, es decir que una clase utiliza a otra. Y si esta ultima se altera, la anterior se puede ver afectada.
En código se suelen traducir principalmente como las clases donde se hace la instanciación de un objeto. En nuestro ejemplo la clase Viaje realiza los “new” de los distintos objetos. En este momento puede que te preguntes como puede hacer un new de una clase abstracta, jeje. No realiza los new de la clase abstracta, si no de sus hijas.Seria algo así como

MedioDeTransporte medio = new Autobus();

También se sostiene que este tipo de relación hace referencias, a los parámetros que se pasan en un método, bajo este concepto, en java, podría ser algo así como:

public void crearViaje(MedioDeTransporte medio){}

Por ultimo también se sostiene que podemos codificar esta relación realizando un “return” del tipo de dato en algún método.
Bueno espero haber limpiado algunas dudas, hay mucho para discutir sobre el asunto.

INTRODUCCION A CASOS DE USO

 Describen una interacción típica entre un usuario (actores) y un sistema de cómputo. Es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje Produce algo de valor para algún actor como el cálculo de algún resultado Describe qué hace un sistema pero no especifica cómo lo hace El caso de uso capta alguna función visible para el usuario. El caso de uso puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario. Un caso de uso debe ser simple, claro y conciso.

PARA QUE SIRVEN LOS CASOS DE USO? Para capturar el comportamiento deseado del sistema sin tener que especificar como se implementa ese comportamiento Como medio de comprensión del sistema para desarrolladores, usuarios finales y expertos del dominio Ayudan a validar la arquitectura y a verificar el sistema en el transcurso del desarrollo de este
DIAGRAMAS DE CASOS DE USO

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.

• La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

El diagrama 1 describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.

• La descripción escrita del comportamiento del sistema al afrontar una tarea de negocio o un requisito de negocio. Esta descripción se enfoca en el valor suministrado por el sistema a entidades externas tales como usuarios humanos u otros sistemas.

• La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.

En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.

El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.

La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.