• Author / Uploaded
• jack

• Categories
• Objeto (informática)
• Caso de uso
• Herencia (Programación Orientada a Objetos)
• Clase (Programación informática)
• Ingeniería de software

Citation preview

DIAGRAMAS EN UML CONALEP 173 CUAUTLA URIEL RODRIGUEZ BARRERA Carrera: PTB en Informática. Grupo: 4105

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.). En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde: o Superior: Contiene el nombre de la Clase o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). o 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: o Balance Puede realizar las operaciones de: o Depositar o Girar o y Balance El diseño asociado es:

Atributos y Métodos: o 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). o 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).  Relaciones entre Clases: 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: o uno o muchos: 1..* (1..n) o 0 o muchos: 0..* (0..n) o número fijo: m (m denota el número). o 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. o 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 llamada Composició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). Un Ejemplo es el siguiente:

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. o 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. o 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). ii.

Casos Particulares:

o 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. o 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. Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarán las relaciones para la implementación del Diccionario:

DUAGRAMA DE OBJETOS

Los diagramas de objetos representan las instancias de su proyecto de desarrollo Los diagramas de objetos de UModel® 2017 representan un único ejemplo de una clase y se utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo, llamado especificación de instancia, UModel le permite asignar una clase ya existente representada por la instancia. UModel ofrece automáticamente al objeto instancias de las propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para el objeto.

Los diagramas de objetos UML utilizan una notación similar a los diagramas de clases y se utilizan para ilustrar una instancia de una clase en un momento dado. Imagine que desea dibujar un diagrama de objetos para ilustrar un ejemplo real de una clase y de sus relaciones.

Los diagramas de objetos pueden ayudar a explicar las clases y su herencia. A veces se dibujan durante el proceso de planificación de clases o para ayudar a partes interesadas para quienes los diagramas de clases sean demasiado abstractos.

Puesto que los diagramas de objetos utilizan notaciones muy similares a los diagramas de clases, la barra de herramientas de diagramas de objetos usan algunos de los iconos de la barra de herramientas de diagramas de clases. Para editar los atributos y valores de un objeto puede utilizar la barra de

herramientas, el diálogo de propiedades o editarlos directamente en el diagrama.

DIAGRAMAS DE CASO DE USO

Introducción 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 interactuan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:  Actor.  Casos de Uso.  Relaciones de Uso, Herencia y Comunicación. Elementos  Actor:

Una definición previa, es que 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 Jefe de Local.  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: o 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. o 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. o 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 () o de Herencia (). 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.

Ejemplo: Como ejemplo esta el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:  Registrar el número de ítemes ingresados.  Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total  El usuario/cliente presiona el botón de comienzo  Existe un operador que desea saber lo siguiente: a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.  El operador debe además poder cambiar: a. Información asociada a ítemes. b. Dar una alarma en el caso de que: i.

Item se atora.

ii.

No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

DIAGRAMAS DE ESTADO

Diagrama de estados

De Wikipedia, la enciclopedia libre Saltar a navegación, búsqueda 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.

externos 

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 estado 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. Unevento es un acontecimiento importante a tomar en cuenta para el sistema. Unes tado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Unatr ans ición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

En UML, los estados se representan mediante óvalos. Las transiciones se representan mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial (círculo negro). Por ejemplo:

Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren, sus transiciones, y los estados que median entre estos eventos. En particular, es útil hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Por ejemplo, en el caso de usocom pr ar Pr oductos no está permitido efectuarpagoT ar jeta mientras no haya ocurrido el eventoter m inar Venta. Un diagrama de estado que describe los eventos globales del sistema y su secuencia en un caso de uso es un diagrama de estado para casos de uso. Por ejemplo, una versión simplificada del diagrama de estados para el caso de usocom pr ar Pr oductos es el siguiente:

Una versión más completa del diagrama anterior se muestra en la siguiente figura: El diagrama anterior aun no está completo, pues falta considerar algunos casos excepcionales, como por ejemplo, si al rechazar una tarjeta de crédito o un cheque, el cliente decide pagar usando otro método, por ejemplo pagando en efectivo.

DIAGRAMA DE SECUENCIA

Diagrama de Secuencia Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no están pensados para mostrar lógicas de procedimientos complejos. Línea de Vida Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el clasificador que posee el diagrama de secuencia.

Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento actor en la parte superior. Este usualmente sería el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y límite de los diagramas de robustez también pueden contener líneas de vida.

Mensajes Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o asíncronos: llamadas o señales. En el siguiente diagrama, el primer mensaje es un mensaje síncrono (denotado por una punta de flecha oscura), completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).

Ocurrencia de ejecución Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación de un foco de control. En el diagrama anterior hay tres ocurrencias de ejecución. El primero es el objeto origen que envía dos mensajes y recibe dos respuestas, el segundo es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta, y el tercero es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta. Mensaje Self Un mensaje self puede representar una llamada recursiva de una operación, o un método llamando a otro método perteneciente al mismo objeto. Este se muestra como cuando crea un foco de control anidado en la ocurrencia de ejecución de la línea de vida.

Mensajes perdidos y encontrados Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al destino esperado, o que han llegado a un destino que no se muestra en el diagrama actual. Los mensajes encontrados son aquellos que llegan de un remitente no conocido, o de un remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un elemento de punto final.

Inicio y final de línea de vida Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama de secuencia. En el último caso, la línea de vida se termina por un símbolo de detención, representado como una cruz. En el primer caso, el símbolo al inicio de la línea de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la creación. El siguiente diagrama muestra un objeto que fue creado y destruido.

Restricciones de tiempo y duración En forma predeterminada, un mensaje se muestra como una línea horizontal. Ya que la línea de vida representa el pasaje de tiempo hacia abajo, cuando se modela un sistema en tiempo real, o incluso un proceso de negocios en tiempo límite, puede ser importante considerar el tiempo que toma realizar las acciones. Al configurar una restricción de duración para un mensaje, el mensaje se mostrará como una línea inclinada.

Fragmentos combinados Se estableció anteriormente que no se espera que los diagramas de secuencia muestren lógicas de procedimientos complejos. Siendo este el caso, hay un número de mecanismos que permiten agregar un grado de lógicas de procedimientos a los diagramas y que a la vez vienen bajo el encabezado de fragmentos combinados. Un fragmento combinado es una o más secuencias de procesos incluidas en un marco y ejecutadas bajo circunstancias nombradas específicas. Los fragmentos disponibles son:



El fragmento Alternative (denotedo “alt”) modela estructuras if…then…else.



El fragmento Option (denotado “opt”) modela estructuras switch.



El fragmento Break modela una secuencia alternativa de eventos que se procesa en lugar de todo del resto del diagrama.



El fragmento Parallel (denotado “par”) modela procesos concurrentes.



El fragmento de secuenciado Weak (denotado “seq”) incluye un número de secuencias para las cuales todos los mensajes se deben procesar en un segmento anterior, antes de que el siguiente segmento pueda comenzar, pero que no impone ningún secuenciado en los mensajes que no comparten una línea de vida.



El fragmento de secuenciado Strict (denotado “strict”) incluye una serie de mensajes que se deben procesar en el orden proporcionado.



El fragmento Negative (denotado “neg”) incluye una serie de mensajes inválidos.



El fragmento Critical incluye una sección crítica.



El fragmento Ignore declara un mensaje o mensajes que no son de ningún interés si este aparece en el contexto actual.



El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que no se incluya en el fragmento Consider se debería ignorar.



El fragmento Assertion (denotado “assert”) designa que cualquier secuencia que no se muestra como un operando de la aserción es inválida.



El fragmento Loop incluye una serie de mensajes que están repetidos.

El siguiente diagrama muestra un fragmento loop.

También hay una ocurrencia de interacción, que es similar a un fragmento combinado. Una ocurrencia de interacción es una referencia a otro diagrama que tiene la palabra “ref” en la esquina izquierda arriba del marco, y tiene el nombre del diagrama referenciado que se muestra en el medio del marco Puerta Una puerta es un punto de conexión para conectar un mensaje dentro de un fragmento con un mensaje fuera del fragmento. EA muestra una puerta como un cuadro pequeño en un marco del fragmento.

Descomposición en parte Un objeto puede tener más de una línea de vida que viene de ésta. Esto permite mensajes de entre e intra objetos para que se muestren en el mismo diagrama.

DIAGRAMA DE ACTIVIDADES

Diagrama de Actividades En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para el Modelado de Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio. Un ejemplo de un diagrama de actividades se muestra a continuación

Las siguientes secciones describen los elementos que constituyen un diagrama de actividades. Actividades Una actividad es la especificación de una secuencia parametrizada de comportamiento. Una actividad muestra un rectángulo con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.

Acciones Una acción representa un solo paso dentro de una actividad. Las acciones se denotan por rectángulos con las puntas redondeadas.

Restricciones de Acción Las restricciones se pueden adjuntar a una acción. El siguiente diagrama muestra una acción con pre y post condiciones locales.

Flujo de Control Un flujo de control muestra el flujo de control de una acción a otra. Su notación es una línea con una punta de flecha.

Nodo Inicial Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuación.

Nodo Final Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se describe como un círculo con un punto dentro del mismo.

El nodo final de flujo se describe como un círculo con una cruz dentro del mismo.

La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un solo flujo de control, y el nodo final de actividad denota el final de todos los flujos finales dentro de la actividad. Flujos de Objetos y Objeto Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se muestra cómo un rectángulo.

Un flujo de objeto se muestra como un conector con una punta de flecha denotando la dirección a la cual se está pasando el objeto.

Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos. Una notación de acceso rápido para el diagrama de arriba sería usar los pins de salidas y entradas.

Un almacén de clave se muestra como un objeto con las clave «datastore».

Nodos de Decisión y Combinación Los nodos de decisión y combinación tienen la misma notación: una forma de diamante. Los dos se pueden nombrar. Los flujos de control que provienen de un nodo de decisión tendrán condiciones de guarda que permitirán el control para fluir si la condición de guarda se realiza. El siguiente diagrama muestra el uso de un nodo de decisión y un nodo de combinación.

Nodos de Bifurcación y Unión Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal como vertical (la orientación depende de si el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales de control. El siguiente diagrama muestra un ejemplo de su uso.

Una unión es diferente de una combinación ya que la unión sincroniza dos flujos de entrada y produce un solo flujo de salida. El flujo de salida desde una unión no se puede ejecutar hasta que todos los flujos se hayan recibido. Una combinación pasa cualquier flujo de control directamente a través de esta. Si dos o más flujos de entrada se reciben por un símbolo de combinación, la acción a la que el flujo de salida apunta se ejecuta dos o más veces. Región de Expansión Una región de expansión es una región de actividad estructurada que se ejecuta muchas veces. Los nodos de expansión de salida y entrada se dibujan como un grupo de tres casillas representando una selección múltiple de ítems. La clave reiterativa, paralelo, o flujo se muestra en la esquina izquierda arriba de la región.

Gestores de Excepción Los gestores de Excepción se pueden modelar en diagramas de actividad como en siguiente ejemplo.

Región de Actividad Interrumpible Una región de actividad interrumpible rodea un grupo de acciones que se pueden interrumpir. En un ejemplo simple como el siguiente, la acción Procesar Orden se ejecutará hasta su cumplimiento cuando pase control a la acción Cerrar Orden, a menos que una interrupción Cancelar Pedido se reciba, la cual pasará el control a la acción Cancelar Orden.

Partición Una partición de una actividad se muestra como calles horizontales o verticales. En el siguiente diagrama, las particiones se usan para separar acciones dentro de una actividad en aquellas realizadas por el departamento de contabilidad y aquellas realizadas por el cliente.

DIAGRAMA DE COLABORACION

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. Un diagrama de colaboración es una descripción de una colección de objetos que interactúan para implementar un cierto comportamiento dentro de un

contexto. Sirve para describir una sociedad de objetos cooperantes unidos para realizar un cierto propósito. Una colaboración contiene ranuras que son rellenadas por los objetos y enlaces en tiempo de ejecución. Una ranura de colaboración se llama Rol porque describe el propósito de un objeto o un enlace dentro de la colaboración. Un rol clasificador representa una descripción de los objetos que pueden participar en una ejecución de la colaboración, un rol de asociación representa una descripción de los enlaces que pueden participar en una ejecución de colaboración. Un rol de clasificador es una asociación que está limitada por tomar parte en la colaboración. Las relaciones entre roles de clasificador y asociación dentro de una colaboración sólo tienen sentido en ese contexto. En general fuera de ese contexto no se aplican las mismas relaciones. Una Colaboración tiene un aspecto estructural y un aspecto de comportamiento. El aspecto estructural es similar a una vista estática: contiene un conjunto de roles y relaciones que definen el contexto para su comportamiento. El aspecto de comportamiento es el conjunto de mensajes intercambiados por los objetos ligados a los roles. Al conjunto de mensajes intercambiados pro los objetos en una colaboración se llaman Interacción. Una colaboración puede incluir una o más interacciones.

¿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 diagramas de secuencia proporcionan una forma de ver el escenario en un orden temporal - qué pasa primero, qué pasa después. Los usuarios entienden fácilmente este tipo de diagramas, por lo que resultan útiles en las primeras fases de análisis. Contrariamente, los diagramas de colaboración proporcionan la representación principal de un caso de uso hoja, ya que las colaboraciones

se organizan entorno a los enlaces de unos objetos con otros. Este tipo de diagramas se utilizan más frecuentemente en la fase de diseño, es decir, cuando estamos diseñando la implementación de las relaciones. Se toma como ejemplo el caso de uso PedirProducto.

A diferencia de otras notaciones que muestran tanto el estado y el comportamiento de la clase en el diagrama de clases, UML separa el comportamiento de las clases en los diagramas de colaboración. Los diagramas de clase de UML no incluyen flujo de mensajes entre clases, es por esto que los diagramas de colaboración se deben crear en paralelo con los diagramas de clases. Aunque se puede indicar el orden del flujo de mensajes en un diagrama de colaboración numerando los mensajes, no se suele hacer, ya que para este propósito son mejores los diagramas de secuencia.

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.

§ Mensajes Los mensajes se representan mediante una flecha etiquetada. Un mensaje esta asociado a un enlace y para el caso de los diagramas de colaboración tienen asociados un número que indican el orden de ocurrencia.

En general, la sintaxis para mostrar los mensajes son: [retorno :=] mensaje([parámetro [:tipoDatos]] [:tipoRetorno] Donde, retorno: indica el resultado de la operación (opcional) mensaje: indica el mensaje enviada u operación invocada parámetro: indica los argumentos usados para el mensaje tipoDatos: indica el tipo de datos de cada parámetro (opcional) tipoRetorno: indica el tipo de retorno de la operación (opcional)

Un mensaje se ilustra mediante una flecha y existen los siguientes tipos: Llamada a procedimiento u otra forma de llamada con anidamiento de control. La secuencia anidada termina antes de que siga la operación que invocó. Puede usarse para procesos concurrentes cuando el mensaje es síncrono. Comunicación asíncrona, sin anidamiento de control. El objeto que envía no se detiene a esperar respuesta. Retorno de una llamada a procedimiento. Esta flecha puede omitirse si queda claro por el fin de la activación.

§ Parámetros Los parámetros se muestran entre paréntesis a la derecha del nombre del mensaje. Opcionalmente se puede mostrar además su tipo de datos.

§ Tipo de retorno El valor de retorno es opcional y puede ser mostrado a la izquierda del mensaje separándolo con un dos punto seguido de un igual (:=).

§ Iteracción Las iteracciones se indican mediante un asterisco (*) a continuación del número de secuencia del mensaje indicando que el mensaje es enviado en forma repetida (en forma de ciclo) al receptor.

§ Creación de instancias La creación de una instancia se ilustra mediante el envio de un mensaje “create” que puede incluir o no parámetros. Lo usual es especificar un nombre para la instancia con el fín de usarla luego.

§ Destrucción de instancias La destrucción de instancias se ilustra mediante el envio de un mensaje “delete” que puede incluir o no parámetros. § Números de secuencia Los números de secuencia determinan el orden de ocurrencia de los mensajes. El mensaje que inicia la interacción generalmente no es numerado.

§ Mensajes condicionales Un mensaje es enviado únicamente si el mensaje se cumple. La guarda se muestra en paréntesis rectos ([ ]) a la izquierda del mensaje.

DIAGRAMA DE COMPONENTES En Visual Studio, un diagrama de componentes muestra los elementos de un diseño de un sistema de software. Un diagrama de componentes permite visualizar la estructura de alto nivel del sistema y el comportamiento del servicio que estos componentes proporcionan y usan a través de interfaces. Para crear un diagrama de componentes UML, en el menú Arquitectura, haga clic en Nuevo diagrama UML o de capas. Para ver qué versiones de Visual Studio admiten esta característica, vea Compatibilidad de versiones con las herramientas de arquitectura y modelado. Puede usar un diagrama de componentes para describir un diseño que está implementado en cualquier idioma o estilo. Solo es necesario identificar los elementos del diseño que interactúan con las otros elementos del diseño a través de un conjunto restringido de entradas y salidas. Los componentes pueden ser de cualquier escala y pueden estar interconectados de cualquier manera.

Para obtener más información acerca de cómo se usan los diagramas de componentes en el proceso de diseño, vea Modelar la arquitectura de la aplicación. Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.