jueves, 26 de febrero de 2009

LOS DIAGRAMAS DE COMUNICACIÓN

INTEGRANTES:

DIEGO FLOREZ

EDWIN GUARQUIN

GRUPO: 40099.

ADSI – SENA






ABSTRACT:

Our esposure is about the diagrams of communication.

Comumunication is a diagram that models the objetc and messages in sequence, the sequence diagram of comunicaction and use the same information and can transform between them.



PALABRAS CLAVES:

Cliente: Cualquier elemento de un sistema de información que requiere un servicio mediante el envío de solicitudes al servidor. Cuando dos programas se comunican por una red, el cliente es el que inicia la comunicación, mientras que el programa que espera ser contactado es el servidor. Cualquier programa puede actuar como servidor para un servicio y como cliente para otro.

Orientación a Objeto: En la programación tradicional, se distingue entre los datos y los procedimientos. En la técnica de programación orientada a objeto no es así, puesto que no existen los procedimientos como tales. Los elementos de los programas se denominan objetos y son considerados como entidades independientes que se relacionan e interactúan entre sí.

POO: programacion orientada a objetos

Actor: Se le llama actor a toda entidad extrena al sistema que guarda una relación con este y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos así como a entidades abstractas como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol, por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso.








INTRODUCCION:

A traves del Lenguaje Unificado de Modelado podemos especificar, visualizar y documentar los artefactos (modelos) de un sistema software, desde una perspectiva orientada a objetos.

Dentro de UML existe una familia de notaciones gráficas, útiles para diseñar sistemas de software y las podemos clasificar de la siguiente forma:

Las Estáticas:

  • Diagramas de clases
  • Diagramas de objetos
  • Diagramas de componentes
  • Diagramas de despliegue

L as Dinámicas:

  • Diagramas de casos de uso
  • Diagramas de secuencia
  • Diagramas de colaboración (comunicación)
  • Diagramas de estados
  • Diagramas de actividades








LOS DIAGRAMAS DE COMUNICACIÓN:

Se llamaban Diagramas de Colaboración en UML 1. Nos sirven para enfatizar los vínculos de datos entre los participantes de una interacción. Usan numeración para mostrar la secuencia de un mensaje y usualmente.

Un diagrama de Comunicación modela las interacciones entre objetos o partes en términos de mensajes en secuencia. Los diagramas de Comunicación representan una combinación de información tomada desde el diagrama de Clases, Secuencia, y Diagrama de casos de uso describiendo tanto la estructura estática como el comportamiento dinámico de un sistema.

Los diagramas de comunicación y de secuencia describen información similar, y con ciertas transformaciones, pueden ser transformados unos en otros sin dificultad.

Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son etiquetados con un número cronológico y colocado cerca del enlace por el cual se desplaza el mensaje. Leer un diagrama de comunicación conlleva comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.






VENTAJAS Y DESVENTAJAS:

Existe una equivalencia semántica

Si el esquema es simple, el comportamiento será simple.

Se Permite la generación de código

Los Diagramas de colaboración (Comunicación) muestran claramente los objetos a los que está conectado un determinado objeto.

En los diagramas de comunicación no se muestra mejor el orden en que se ejecutan los mensajes a diferencia de los Diagramas de secuencia.

Deben ser legibles y comprensibles para un usuario no experto.

Si hay mucho comportamiento condicional, se deben usar diferentes escenarios.
















VIDEO DE DIAGRAMAS DE COMUNICACIÓN:






CASOS DE USO:

Un caso de uso especifica un conjunto de secuencias de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular acto.

Casos de uso son ideados por Jacobson a principios de los noventa, inspirados en el concepto de escenario.

Describen qué hace el sistema, no cómo lo hace.

Elementos de un caso de uso:

Actores: Roles que pueden jugar los usuarios y se representan mediante monigotes. Un Actor sólo se puede conectar a un caso de uso mediante una asociación

Variantes: Se aplican para versiones especializadas de casos de uso, en el cual se extiende a otro ó un caso de uso incluye a otro.

Conjunto de secuencias de acciones: Cada secuencia representa un posible comportamiento del sistema.

En la realización de un caso de uso pueden intervenir diferentes actores: Principal y Secundarios

Un actor puede intervenir en varios casos de uso.

Se pueden identificar casos de uso a partir de actores y eventos externos

Dos tipos de actores:

Principal: Requiere al sistema el cumplimiento de un objetivo

Secundarios: El sistema necesita de ellos para satisfacer un objetivo.













CONCLUSIONES:

Los Diagramas de comunicacion no son una actividad de dibujar diagramas sino de escribir con el detalle necesario el flujo principal y los flujos alternativos. El objetivo inicial es identificar los actores y a partir de sus objetivos encontrar los casos de uso, Los diagrama de comunicacion son una una ayuda visual.

Los textos de los casos de uso deben ser claros y no se deben abusar de las relaciones de inclusión.

Un caso de uso debe tener un esquema apropiado, que incluya una interacción en la que se produzca un resultado de valor para cada actor.

Un error muy común en los casos de uso es, no identificar las tareas que inicia el propio sistema ya que Para un mejor desarrollo es conveniente comprobar que los casos de uso incluyen toda la funcionalidad del sistema.

El cambio mas profundo en los diagramas de comunicacion es que anteriormente tenia el nombre de "diagramas de colaboracion" por ser las colaborariones un diagrama de interaccion, al igual que los diagramas de secuencia, heredan la misma capacidad de soportar fragmentos combinados.

Y finalmente podemos concluir que algunos requisitos funcionales no conviene expresarlos como casos de uso.







BIBLIOGRAFIA:

http://es.wikipedia.org/wiki/Diagrama_de_comunicaci%C3%B3n

http://www.monografias.com/trabajos34/ingenieria-software/ingenieria-software.shtml

http://elvex.ugr.es/decsai/java/pdf/3E-UML.pdf

http://www.scribd.com/doc/7380607/Umberto-Eco-Diagramas-de-Comunicacion

http://www.nitsnets.com/uml/uml.swf







2 comentarios: