miércoles, 30 de julio de 2014

Diagrama de comunicación

En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es una versión simplificada del diagrama de colaboración de la versión de UML 1.x.[cita requerida]
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 clasessecuencia, 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 colocados 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.

Diagrama global de interacciones

Un diagrama global de las interacciones (en inglés: interaction overview diagram) es una de las trece clases de diagramas en el Lenguaje de Modelado Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.

Descripción[editar]

El diagrama global de las interacciones es un diagrama de comportamiento, más precisamente, uno de los cuatro diagramas de interacción. Muestra una cierta vista sobre los aspectos dinámicos de los sistemas modelados. Aunque un diagrama global de las interacciones es una representación gráfica de una interacción, éste se distingue fuertemente de los diagramas de secuencia y de comunicación, dos de los otros diagramas de interacción. De hecho, algunos elementos gráficos del diagrama global de las interacciones están tomados del diagrama de actividades, otro diagrama de comportamiento para el modelado de actividades.
Los modelos de interacción pueden llegar a ser muy grandes para sistemas complejos. Si el número de líneas de vida participantes y el número de mensajes intercambiados excede una cierta medida, se impone “modularizar” las interacciones y dividir en partes pequeñas, más manejables, de acuerdo a principios universales del diseño de sistemas, que también pueden ser visualizadas con la ayuda de un clásico diagrama de secuencias. La visión de conjunto de toda la interacción, de manera que la Big Picture o bien el cuadro global, puede entonces ser representada con la ayuda del diagrama global de las interacciones, provisto para eso.

Ejemplo[editar]

Ejemplo de un diagrama global de interacciones.
La figura muestra un ejemplo de un diagrama global de interacciones con un encabezado y un área de contenido. La palabra clave en el área de encabezado, en el caso de un diagrama global de interacciones, es sd ó interaction.
En este ejemplo, el diagrama global de interacciones combina un diagrama de secuencia, que está definido en el lugar (inglés inline), con una interacción (Drehtür für einen Durchgang freigeben o en español, Desbloquear la puerta giratoria para un libre paso), que está modelada en otra parte y que aquí está solo referenciada, reconocible en la palabra clave ref.
El flujo de control entre estas dos interacciones es modelada con elementos de los diagramas de actividades. El proceso comienza en un nodo inicial y finaliza en un nodo terminal para actividades. Un nodo de ramificación entre las interacciones embebidas (el diagrama de secuencia y el de interacción) modela la decisión de si la entrada se abre o si debe permanecer cerrada.

Diagrama de tiempos

El propósito primario del diagrama de tiempos es mostrar los cambios en el estado o la condición de una línea de vida (representando una Instancia de un Clasificador o un Rol de un clasificador) a lo largo del tiempo lineal. El uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en respuesta a los eventos o estímulos aceptados. Los eventos que se reciben se anotan, a medida que muestran cuándo se desea mostrar el evento que causa el cambio en la condición o en el estado.

Diagramas de Tiempos UML

En el estándar de Lenguaje de Modelado Unificado de OMG los diagramas de tiempo son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones detalladas sobre el embebidos.


Diagrama de colaboración

Un diagrama de colaboración en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Por otra parte, un diagrama de comunicación no muestra el tiempo como una dimensión aparte, por lo que resulta necesario etiquetar con números de secuencia tanto la secuencia de mensajes como los hilos concurrentes.
  • Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.
  • Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".
Un diagrama de comunicación es también un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de sólo clasificadores y asociaciones. Los roles de clasificador y los de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicación. Cuando se instancia una comunicación, los objetos están ligados a los roles de clasificador y los enlaces a los roles de asociación. El rol de asociación puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los símbolos de enlace pueden llevar estereotipos para indicar enlaces temporales.

Usos

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La comunicación muestra los parámetros y las variables locales de la operación, así como asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del programa.
Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica, pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales están menos claras.

Tipos

Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los creados durante la interacción (restricción {new}); los destruidos durante la interacción (restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción {transient}).
Aunque las comunicaciones muestran directamente la implementación de una operación, pueden también mostrar la realización de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles múltiples que los objetos pueden desempeñar en varias operaciones.
No hay ejemplos de los diagramas, diferentes casos o sistemas, ya que con UML se modelan áreas de un negocio así como los sistemas que estos requieren

Mensajes

Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un número de secuencia, una lista opcional de mensajes precedentes, una condición opcional de guarda, un nombre, una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explícita. En conclusión en un diagrama muy sencillo de hacer.

Flujos

Generalmente, un diagrama de comunicación contiene un símbolo para un objeto durante una operación completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explícitos. Por ejemplo, un objeto pudo cambiar de localización o sus asociaciones pudieron diferenciarse.
Los diferentes símbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversión". Un flujo "become" es una transición, a partir de un estado de un objeto a otro. Se dibuja como una flecha de línea discontinua con el estereotipo "become" o "conversión" y puede ser etiquetado con un número de serie para mostrar cuando ocurre. Un flujo de conversión también se utiliza para mostrar la migración de un objeto a partir de una localización a otra distinta para otro lugar también se deben marcar con el número en secuencias.

Cambios en versiones recientes de UML

En versiones recientes de UML este diagrama ha sido reemplazado por el diagrama de comunicación.

Diagrama de secuencia



El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"1

Utilidad[editar]

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.




Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

  • De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
  • Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

Diagrama de estado

                                      

En cualquier momento, un objeto se encuentra en un estado particular, la  luz está encendida o apagada, el auto en movimiento o detenido, la  persona leyendo o cantando, etc. . El diagrama de estados UML captura  esa pequeña realidad.



Estado  


El estado representa situaciones durante  la vida de un objeto. Se representa con  un rectángulo que tiene sus esquinas  redondeadas.  

Transición

Una flecha representa el pasaje entre  diferentes  estados de un objeto. Se  etiqueta con el evento que lo provoca y  con la acción resultante.   

Estado Inicial  
Estado Final  

Diagrama de flujo

El diagrama de flujo o diagrama de actividades es la representación gráfica del algoritmo o proceso. Se utiliza en disciplinas comoprogramacióneconomíaprocesos industriales y psicología cognitiva.
En Lenguaje Unificado de Modelado (UML), un diagrama de actividades representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un diagrama de actividades muestra el flujo de control general.
En SysML el diagrama de actividades ha sido extendido para indicar flujos entre pasos que mueven elementos físicos (p.ej., gasolina) o energía (p.ej., presión). Los cambios adicionales permiten al diagrama soportar mejor flujos de comportamiento y datos continuos.
Estos diagramas utilizan símbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y de fin de proceso.

Normas de trabajo

Un diagrama de flujo presenta generalmente un único punto de inicio y un único punto de cierre, aunque puede tener más, siempre que cumpla con la lógica requerida.
Las siguientes son acciones previas a la realización del diagrama de flujo:
  • Identificar las ideas principales al ser incluidas en el diagrama de flujo. Deben estar presentes el autor o responsable del proceso, los autores o responsables del proceso anterior y posterior y de otros procesos interrelacionados, así como las terceras partes interesadas.
  • Definir qué se espera obtener del diagrama de flujo.
  • Identificar quién lo empleará y cómo.
  • Establecer el nivel de detalle requerido.
  • Determinar los límites del proceso a describir.
Los pasos a seguir para construir el diagrama de flujo son:
  • Establecer el alcance del proceso a describir. De esta manera quedará fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente.
  • Identificar y listar las principales actividades/subprocesos que están incluidos en el proceso a describir y su orden cronológico.
  • Si el nivel de detalle definido incluye actividades menores, listarlas también.
  • Identificar y listar los puntos de decisión.
  • Construir el diagrama respetando la secuencia cronológica y asignando los correspondientes símbolos.
  • Asignar un título al diagrama y verificar que esté completo y describa con exactitud el proceso elegido.
  • Descripción

    En UML 1.x, un diagrama de actividades es una variación del diagrama de estado UML donde los "estados" representan operaciones, y las transiciones representan las actividades que ocurren cuando la operación es completa.
    El diagrama de mensajes de UML 2.0, mientras que es similar en aspecto al diagrama de actividades UML 1.x, ahora tiene semánticas basadas en redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de actividades. El diagrama de actividad es una forma especial de diagrama de estado usado para modelar una secuencia de acciones y condiciones tomadas dentro de un proceso.
    La especificación del Lenguaje de Modelado Unificado (UML) define un diagrama de actividad como:
    “… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la realización de las acciones o subactividades.”1
    El propósito del diagrama de actividad es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones.
    Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz.
    Una Interfaz es un grupo de operaciones relacionadas con la semántica.
  • Tipos de diagramas de flujo

    • Formato vertical: En él, el flujo y la secuencia de las operaciones, va de arriba hacia abajo. Es una lista ordenada de las operaciones de un proceso con toda la información que se considere necesaria, según su propósito.
    • Formato horizontal: En él, el flujo o la secuencia de las operaciones, va de izquierda a derecha.
    • Formato panorámico: El proceso entero está representado en una sola carta y puede apreciarse de una sola mirada mucho más rápido que leyendo el texto, lo que facilita su comprensión, aun para personas no familiarizadas. Registra no solo en línea vertical, sino también horizontal, distintas acciones simultáneas y la participación de más de un puesto o departamento que el formato vertical no registra.
    • Formato Arquitectónico: Describe el itinerario de ruta de una forma o persona sobre el plano arquitectónico del área de trabajo. El primero de los flujogramas es eminentemente descriptivo, mientras que los utilizados son fundamentalmente representativos.

    Simbología y significado

    • Óvalo o Elipse: Inicio y término (Abre y cierra el diagrama).
    • Rectángulo: Actividad (Representa la ejecución de una o más actividades o procedimientos).
    • Rombo: Decisión (Formula una pregunta o cuestión).
    • Círculo: Conector (Representa el enlace de actividades con otra dentro de un procedimiento).
    • Triángulo boca abajo: Archivo definitivo (Guarda un documento en forma permanente).
    • Triángulo boca arriba: Archivo temporal (Proporciona un tiempo para el almacenamiento del documento).

    Cursograma

    Se trata de la más común y práctica entre todas las clases de diagramas de flujo. Describe el flujo de información en un ente u organización, sus procesos, sistemas administrativos y de control. Permite la impresión visual de los procedimientos y una clara y lógica interpretación.

    Simbología y normas del cursograma

    • Círculo: Procedimiento estandarizado.
    • Cuadrado: Proceso de control.
    • Línea continua: Flujo de información vía formulario o documentación en soporte de papel escrito.
    • Línea interrumpida: Flujo de información vía formulario digital.
    • Rectángulo: Formulario o documentación. Se grafíca con un doble de ancho que su altura.
    • Rectángulo Pequeño: Valor o medio de pago (cheque, pagaré, etc.). Se grafíca con un cuádruple de ancho que su altura, siendo su ancho igual al de los formularios.
    • Triángulo (base inferior): Archivo definitivo.
    • Triángulo Invertido (base superior): Archivo Transitorio.
    • Semióvalo: Demora.
    • Rombo: División entre opciones.
    • Trapezoide: Carga de datos al sistema.
    • Elipsoide: Acceso por pantalla.
    • Hexágono: Proceso no representado.
    • Pentágono: Conector.
    • Cruz de Diagonales: Destrucción de Formularios.
    Según la normativa, el flujo presupuesto es de izquierda a derecha y de arriba hacia abajo, siendo optativo el uso de flechas. Cuando el sentido es invertido (de derecha a izquierda o de abajo hacia arriba), es obligatorio el uso de la flecha.

    Historia

    La paternidad del diagrama de flujo es en principio algo difusa. El método estructurado para documentar gráficamente un proceso como un flujo de pasos sucesivo y alternativos, el "proceso de diagrama de flujo", fue expuesto por Frank Gilbreth, en la Sociedad Americana de Ingenieros Mecánicos (ASME), en 1921, bajo el enunciado de "Proceso de Gráficas-Primeros pasos para encontrar el mejor modo". Estas herramientas de Gilbreth rápidamente encontraron sitio en los programas de ingeniería industrial.
    Al principio de los 30, un ingeniero industrial, Allan H. Mogensen comenzó la formación de personas de negocios en Lake PlacidNueva York, incluyendo el uso del diagrama de flujo. Art Spinanger, asistente a las clases de Mogesen, utilizó las herramientas en su trabajo en Procter & Gamble, donde desarrolló su “Programa Metódico de Cambios por Etapas”. Otro asistente al grupo de graduados en 1944, Ben S. Graham, director de ingeniería de Formcraft Standard Register Corporation, adaptó la gráfica de flujo de procesos al tratamiento de la información en su empresa. Y desarrolló la gráfica del proceso de múltiples flujos en múltiples pantallas, documentos, y sus relaciones. En 1947, ASME adoptó un conjunto de símbolos derivados de la obra original de Gilbreth como Norma ASME para los gráficos de procesos (preparada Mishad, Ramsan y Raiaan).
    Sin embargo, según explica Douglas Hartree fueron originalmente Herman Goldstine y John von Neumann quienes desarrollaron el diagrama de flujo (inicialmente llamado "diagrama") para planificar los programas de ordenador. Las tablas de programación original de flujo de Goldstine y von Neumann, aparecen en un informe no publicado, "Planificación y codificación de los problemas de un instrumento de computación electrónica, la Parte II, Volumen 1 "(1947), reproducido en las obras completas de von Neumann.
    Inicialmente los diagramas de flujo resultaron un medio popular para describir algoritmos de computadora, y aún se utilizan con este fin. Herramientas como los diagramas de actividad UML, pueden ser considerados como evoluciones del diagrama de flujo.
    En la década de 1970 la popularidad de los diagramas de flujo como método propio de la informática disminuyó, con el nuevo hardware y los nuevos lenguajes de programación de tercera generación. Y por otra parte se convirtieron en instrumentos comunes en el mundo empresarial. Son una expresión concisa, legible y práctica de algoritmos. Actualmente se aplican en muchos campos del conocimiento, especialmente como simplificación y expresión lógica de procesos, etc.

    Ventajas de los diagramas de flujo

    • Favorecen la comprensión del proceso al mostrarlo como un dibujo. El cerebro humano reconoce muy fácilmente los dibujos. Un buen diagrama de flujo reemplaza varias páginas de texto.
    • Permiten identificar los problemas y las oportunidades de mejora del proceso. Se identifican los pasos, los flujos de los reprocesos, los conflictos de autoridad, las responsabilidades, los cuellos de botella, y los puntos de decisión.
    • Muestran las interfaces cliente-proveedor y las transacciones que en ellas se realizan, facilitando a los empleados el análisis de las mismas.
    • Son una excelente herramienta para capacitar a los nuevos empleados y también a los que desarrollan la tarea, cuando se realizan mejoras en el proceso.
    • Al igual que el pseudocódigo, el diagrama de flujo con fines de análisis de algoritmos de programación puede ser ejecutado en un ordenador, con un IDE como Free DFD.

    Software para diseño de diagramas de flujo

    Actualmente existe una gran cantidad de software para la elaboración de diagramas de flujo. A continuación se listan los programas más comunes para elaborar diagramas de flujo.
    • Microsoft Office ofrece 3 herramientas útiles para la elaboración de diagramas. Uno de ellos es Microsoft Office Word, que nos permite crear diagramas de flujo básicos a través de la opción "Formas" que tiene un apartado especial para diagramas de flujo. De igual manera Microsoft Office Power Point ofrece las mismas opciones para crear los diseños de diagramas de flujo. Otra herramienta un poco más sofisticada es Microsoft Office Visio, que además de la simbología básica de los diagramas de flujo cuenta con una variedad de herramientas para elaborar otros tipos de diagramas como es el caso diagramas UML entre otros tipos de diagramas de flujo.
    • Otro programa eficiente y muy fácil de usar es el programa "Dia" que brinda una solución rápida para la creación de diagramas de flujo además de otro tipo de diagramas usados en el ambiente informático. Es considerado la versión no comercial de Microsoft Visio

Diagrama 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. En los conceptos se debe detallar mas de un caso de uso para poder identificar que es lo que hace un caso de uso.
  • 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.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso de uso base tendra que realizar tambien el caso de uso incluido), desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describir casos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve.

Extensión (extend)

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión .
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."
documentan el comportamiento de un sistema desde el punto de vista de un usuario
En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azucar y podemos seleccionar de entre azucar rubia,blanca o su unidad de medida bolsa , kilo.

Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."
En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Diagrama de despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar la disposición física de los artefactos software en nodos (usualmente plataforma de hardware)1 

Elementos


Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

Aspectos Generales

La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Usos

Algunos de los usos que se les da a los diagramas de despliegue son para modelar:
  • Sistemas empotrados: Un sistema empotrado es una colección de hardware con una gran cantidad de software que interactúa con el mundo físico.
  • Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistema a través de nodos.
  • Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores. Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema

Diagrama de paquetes

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra cómo un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.
Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

Diagrama de estructura compuesta

Un diagrama de estructura es un tipo de diagrama en el Lenguaje de Modelado Unificado (UML), que muestra la estructura interna de unaclase y las colaboraciones que esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de la clase interactúan con las partes y con el mundo exterior, yconectores entre partes o puertas. Una estructura compuesta es un conjunto de elementos interconectados que colaboran en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol definido en la colaboración.

Conceptos de estructura compuesta

Las entidades de estructura compuesta claves identificadas en la especificación UML 2.0 son: clasificadores estructurados, partes, puertas, conectores, y colaboraciones.

Parte

Una parte representa un rol jugado en tiempo de ejecución por una instancia de una clase o por una colección de instancias. La parte puede nombrar solamente un rol, unasuperclase abstracta, o puede nombrar una clase concreta específica. La parte puede incluir un factor de multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en el diagrama.

Puerta

Una puerta es un punto de interacción que puede ser usado para conectar clasificadores estructurados con sus partes y con el ambiente. Las puertas pueden opcionalmente especificar los servicios que proveen y los servicios que requieren de otras partes del sistema. En el diagrama, cada uno de los cuadrados pequeños es una puerta. Cada puerta tiene un tipo y esta etiquetado con un nombre, tal como "var", "indVar1", or "view" en el diagrama. Las puertas pueden contener un factor de multiplicidad, por ejemplo [3].
Las puertas pueden ya sea delegar los requerimientos recibidos a partes internas, o pueden entregarlos directamente para el comportamiento del clasificador estructurado en el que la puerta está contenido. Las puertas públicas que son visibles en el ambiente son mostradas sobre el borde (límite o frontera), mientras que las puertas protegidas que no son visibles en el ambiente son mostradas dentro de la frontera (borde o límite). Todas las puertas en el diagrama son privadas, excepto por la puerta view a lo largo del límite derecho de FibonacciSystem.

Conector

Un conector une dos o más entidades, permitiéndoles interactuar en tiempo de ejecución. Un conector es representado por una línea que une una combinación de partes, puertas y clasificadores estructurados. El diagrama muestra tres conectores entre puertas, y un conector entre un clasificador estructurado y una parte.

Colaboración

Una colaboración es generalmente más abstracta que un clasificador estructurado. Ésta es mostrada como un óvalo sin relleno conteniendo los roles que las instancias pueden jugar en la colaboración.

Clasificador estructurado

Un ClasificadorEstructurado representa una clase, frecuentemente una clase abstracta, cuyo comportamiento puede ser completa o parcialmente descrito mediante interacciones entre partes.
Un ClasificadorEncapsulado es un tipo de clasificador estructurado que contiene puertas. En el diagrama abajo, ambos FibonacciSystem y Variable son clasificadores encapsulados, porque ambos tienen puertas a lo largo de sus límites.

Ejemplo de diagrama de estructura compuesta

Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la clase 'FibonacciSystem' están compuestas de varias partes. La superior de estas partes está identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes son identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem – el rol NMinus2, el rolNMinus1, y el rol N. La quinta parte, identificada por su clasificador Viewer, incluye una especificación de multiplicidad. En tiempo de ejecución puede haber 0 o más instancias de Viewer o de alguna subclase concreta de Viewer.
En tiempo de ejecución las instancias de clase que implementan estos tres roles deben proveer los servicios especificados por la interfaz IVar mediante sus puertas var. Una de tales clases es Variable, mostrada sobre el diagrama con una puerta llamada var de tipo Var que realiza la interfaz IVar.
La puerta llamada "view" es una puerta no-pública que puede ser usada por una instancia de FibonacciSystem para acceder a la(s) instancia(s) opcional(es) de Viewer

Trabajando con hp

Las Herramientas de modelado UML 2.0 debiesen proveer un diagrama de estructura compuesta separado. Los iconos de dibujo son típicamente etiquetados Classifier (clasificador estructurado o clasificador encapsulado), Part, Port, Connector, y Collaboration.