Diagrama de descomposición funcional

1. Fase o fases en la que se utiliza de Togaf.

Se aplica en la planeación del negocio, ya que con este diagrama podemos hacer una
descripción detallada sobre el análisis que se hace a la arquitectura del negocio como tal. Este
diagrama se puede enriquecer mediante enlaces a otras partes del modelo, para indicar, por
ejemplo, que la aplicación es compatible con qué función, qué papel utiliza el que la función, y
así sucesivamente.

2. Descripción
El propósito del diagrama de descomposición funcional es mostrar en una sola página de las
capacidades de una organización que son relevantes para la consideración de una
arquitectura.
Mediante el examen de las capacidades de una organización desde una perspectiva funcional,
es posible desarrollar rápidamente modelos de lo que la organización hace sin ser arrastrado a
un amplio debate sobre cómo la organización lo realiza.
Una vez que un diagrama básico de descomposición funcional ha sido desarrollado, se hace
posible a la capa de “heat-maps” en la parte superior de este diagrama pueda mostrar el
alcance y decisiones. Por ejemplo, la capacidad para ser implementadas durante las diferentes
fases de un programa de cambio.

3. Herramientas que se pueden usar para su realización

El diagrama de descomposición de procesos (a menudo llamado descomposición ) explica la

ruptura de los procesos dentro de un proyecto o área de negocio o área funcional. El propósito
es mostrar todos los procesos e identificar relaciones y dependencias entre ellos. Tenga en
cuenta que una descomposición no profundiza en el cómo, simplemente describe el qué.
Existen procesos con subprocesos por debajo los cuales se les llaman procesos padres, los
otros son procesos hijos.
Para designarlos se sigue un par de pautas:

 Si usted analiza un proceso padre, debe dividirlo en al menos dos hijos; de lo contrario, no es
un verdadero padre.
 Todos los procesos hijos juntos deben describir completamente todas las actividades en el
proceso principal.

En el siguiente ejemplo podemos ver la planificación de una aerolínea en sus planes o

itinerarios de vuelo.
El diagrama no sigue ningún orden definido. Por ejemplo, usted no tiene que comprobar el
tiempo antes de planificar el vuelo. Del mismo modo, se puede ver el tiempo en cualquiera de
los lugares en el orden; usted no tiene que verlo desde el origen hasta en ruta hacia el destino,
porque el mal tiempo en cualquier punto de la ruta le impide volar esa ruta.

4. . Insumos requeridos para su utilización

1. Elija una de las tres maneras de construir su descomposición: de arriba hacia abajo, de abajo
hacia arriba, o por eventos.
Eso es correcto; puede utilizar tres métodos para crear su diagrama:
 De arriba hacia abajo: Comience con los procesos de alto nivel (requisitos) que ha
identificado durante la definición del alcance si ellos (si no lo hace, obtener ellos de sus grupos
de interés) tiene. A partir de ahí, seguir taladrando hacia abajo hasta llegar a los procesos que
contienen una forma; ese es su punto de parada.
 De abajo hacia arriba: Piense en todas las tareas detalladas que tienen que hacer en la zona
de estudio (o alcance) y luego encontrar agrupaciones
comunes. Al determinar las agrupaciones, un proceso puede caer en diferentes rubros; el
objetivo es que el equipo para determinar el mejor enfoque. Recuerde, lo que usted quiere
hacer es asegurarse de que no se pierda ningún proceso.
 Por eventos: Piensa en todos los desencadenantes (directivas que llevan a una serie de
acciones) y las tareas que siguen.
Tome notas y haga un boceto.
Recuerde que una gran técnica es el uso de las notas adhesivas para construir este diagrama.
Construir el diagrama actual y validarlo con los grupos de interés.

5. Ejemplos de utilización en general

En general, este proceso de descomposición se lleva a cabo ya sea con el fin de hacerse una
idea de la identidad de los elementos constitutivos (que pueden reflejar los procesos
individuales de física de interés, por ejemplo), o con el fin de obtener una representación
comprimida de la función global, una tarea que sólo es posible cuando los procesos
constitutivos poseen un cierto nivel de modularidad (es decir, la independencia o no de
interacción).

¿Qué es una BPMN?

La notación del modelado de procesos de negocio (BPMN) es un método de diagrama de flujo

que modela los pasos de un proceso de negocio planificado de principio a fin. Un aspecto clave
de la gestión de procesos de negocio (BPM) es que representa visualmente una secuencia
detallada de los flujos de información y las actividades empresariales necesarias para finalizar
un proceso.

Su propósito es modelar formas de mejorar la eficiencia, representar nuevas circunstancias u

obtener ventaja sobre la competencia. Este método también ha experimentado un empuje
hacia la estandarización en los últimos años, y ahora su nombre es un poco
diferente: Notación y modelo de procesos de negocios, pero conserva la sigla BPMN. Se
diferencia de la creación de mapas de procesos de negocio, que realiza diagramas de
procesos actuales  para propósitos tales como la estandarización, la capacitación a empleados,
el control de calidad y la conformidad de auditoría. BPMN también es el equivalente
empresarial del lenguaje unificado de modelado (UML) empleado en el diseño de software.

Historia muy reciente

La iniciativa de la gestión de procesos de negocio (BPMI) desarrolló la notación del modelado

de procesos de negocio, que ha experimentado una serie de revisiones. En 2005, ese grupo se
fusionó con el Object Management Group (OMG), que se hizo cargo de la iniciativa. En 2011,
OMG lanzó BPMN 2.0 y cambió el nombre del método a modelo y notación de procesos de
negocio. Creó un estándar más detallado para el modelo de procesos de negocio, mediante el
uso de un conjunto más rico de símbolos y notaciones para los diagramas de procesos de
negocio. Desde 2014, BPMN también se complementó con un método de diagrama de flujo de
decisiones llamado el estándar "Decision Model and Notation", ya que BPMN no se presta a sí
mismo de forma natural a los flujos de decisión.
Propósitos y beneficios

En un nivel elevado, BPMN está dirigido a participantes y otros interesados en un proceso de

negocio con el fin de obtener conocimientos mediante una representación visual de los pasos
fácil de entender. En un nivel más específico, se dirige a las personas que implementarán el
proceso, brindando suficientes detalles para permitir una implementación precisa. Ofrece un
lenguaje estándar y común para todos los interesados, sean técnicos o no: analistas de
negocios, participantes del proceso, desarrolladores técnicos y directores, así como asesores y
equipos externos. Idealmente, cierra la brecha entre la intención del proceso y la
implementación, brindando suficientes detalles y claridad a la secuencia de las actividades
empresariales.

La diagramación puede ser mucho más fácil de entender que el texto narrativo. Permite una
colaboración y comunicación más fáciles para alcanzar el objetivo de un proceso eficiente que
produzca resultados de excelente calidad. También ayuda a orientar la comunicación hacia los
documentos en lenguaje de marcado extensible (XML) necesarios para ejecutar numerosos
procesos. Nuestro principal estándar XML se denomina BPEL o BEPEL4WS, que significa
"lenguaje de ejecución de procesos de negocio para servicios web".

Símbolos y elementos de diagramas BPMN 2.0

La BPMN representa estos cuatro tipos de elementos de los diagramas de procesos de

negocio.

1. Objetos de flujo: eventos, actividades y portales

2. Objetos de conexión: flujo de secuencia, flujo de mensaje y asociación

3. Carriles: piscina o carril

4. Artefactos: objeto de datos, grupo y anotación

Estos son los elementos individuales y cómo se usan para definir un proceso de negocio:

Eventos

Un disparador que inicia, modifica o finaliza un proceso. Los tipos de eventos incluyen
mensajes, temporizadores, errores, compensaciones, señales, cancelaciones, escalaciones,
enlaces y otros. Se muestran con círculos que contienen otros símbolos en función del tipo de
evento. Se clasifican como "lanzar" o "capturar", según su función.

Actividad

Una actividad o tarea particular llevada a cabo por una persona o sistema. Se muestra con un
rectángulo con bordes redondeados. Pueden volverse más detalladas con subprocesos, bucles,
compensaciones y múltiples instancias.

Gateway
Punto decisivo que puede modificar la ruta en función de las condiciones o los eventos. Se
muestran como diamantes. Pueden ser exclusivos o inclusivos, paralelos, complejos o basarse
en datos o eventos.

Flujo de secuencia

Muestra el orden de las actividades que se realizarán. Se representa con una línea recta con
una flecha. Puede mostrar un flujo condicional o un flujo predeterminado.

Flujo de mensajes

Muestra mensajes que fluyen en "piscinas" o límites organizativos, como los departamentos.
No debe conectar eventos o actividades dentro de una piscina. Se representa con una línea
discontinua que contiene un círculo al principio y una flecha al final.

Asociación

Se muestra con una línea punteada y asocia un artefacto o texto a un evento, actividad o
puerta de enlace.

Carril y piscina

Una piscina representa a los principales participantes de un proceso. Puede haber otra piscina
en otra compañía o departamento, pero igual estar involucrada en el proceso. Los carriles
dentro de una piscina muestran las actividades y los flujos para un determinado rol o
participante, definiendo quién es responsable de qué partes del proceso.

Artefacto

Información adicional que los desarrolladores agregan para aportar el nivel necesario de
detalle al diagrama. Hay tres tipos de artefactos: objeto de datos, grupo u anotación.
Un objeto de datos muestra los datos necesarios para una actividad. Un grupo muestra una
agrupación lógica de actividades, pero no cambia el flujo del diagrama. Una anotación brinda
una explicación más completa de una parte del diagrama.

Crear diagramas es rápido y sencillo con Lucidchart. Inicia una prueba gratuita hoy mismo para
empezar a crear y colaborar.
Crea un diagrama BPMN

¿Quién realiza el modelado de procesos de negocio?

El modelado de procesos de negocios puede incluir desde diagramas simples y dibujados a

mano hasta algunos más complejos con elementos expandibles que brinden suficientes
detalles de la implementación. Los analistas con credenciales se encargan de la BPMN en su
versión más sofisticada. El Object Management Group (OMG) ofrece cinco certificaciones en
BPMN 2.0 llamadas OCEB 2, que significa "experto certificado por OMG en BPM 2.0". Un
tramo se orienta al negocio, y el otro es técnico. OMG busca que BPMN 2.0 estandarice el
modelado de procesos de negocio del mismo modo que el lenguaje unificado de modelado
(UML) estandarizó el modelado de software.

BPMN requiere un compromiso de tiempo y energía, pero la recompensa en comprensión y

mejora puede ser enorme. La versión 2.0 se basa en las versiones anteriores y brinda un
conjunto estándar más enriquecido de símbolos y notaciones, permitiendo más detalle para
quienes lo necesitan.

La idea detrás de la gestión de procesos de negocio es crear un ciclo de vida de mejora

continua. Los pasos son modelar, implementar, ejecutar, monitorear y optimizar. Los
diagramas BPMN tienen un rol fundamental en eso.

Submodelos dentro de un diagrama BPMN

Los diagramas se usan para la comunicación con diversas audiencias, tanto técnicas como no
técnicas. Los submodelos permiten que los lectores puedan diferenciar fácilmente las
secciones del diagrama, encontrando lo que más se aplica a ellos. Los tipos de submodelos
son:

 Procesos de negocio privados. Son procesos internos de una organización específica y

no cruzan piscinas o límites organizativos.

 Procesos de negocio abstractos. Estos ocurren entre un proceso privado o interno y

otro participante o proceso. El proceso abstracto muestra al mundo exterior la
secuencia de mensajes necesaria para interactuar con el proceso privado. No muestra
el proceso interno o privado en sí mismo.

 Procesos de negocio colaborativos. Estos muestran las interacciones entre dos o más

entidades de negocio.

Otros tipos de diagramas

En BPMN 2, hay otros tipos de diagramas: conversación, coreografía y colaboración.

 Diagrama de coreografía: muestra las interacciones entre dos o más participantes.

También se puede expandir con subcoreografías.

 Diagrama de colaboración: muestra las interacciones entre dos o más procesos,

empleando más de una piscina. Todas las combinaciones de piscinas, procesos y
coreografías se pueden usar en un diagrama de colaboración.

 Diagrama de conversación: en general, se trata de una versión simplificada de un

diagrama de colaboración. Muestra un grupo de intercambios de mensajes
relacionados en un proceso de negocio. Se puede expandir con subconversaciones.
Recomendaciones clave para el modelado de procesos de negocio

1. Define claramente el alcance del proceso con un principio y un final.

2. Quizá debas crear primero un mapa del proceso de negocio actual para destacar las
ineficiencias antes de modelar una forma mejor con BPMN.

3. Busca que los diagramas BPMN quepan en una sola página, incluso si la página tiene el
tamaño de un póster, como sucede en algunos casos.

4. Diseña los flujos de secuencia de forma horizontal. Muestra las asociaciones y los flujos
de datos verticalmente.

5. Puedes crear distintas versiones del diagrama para diferentes interesados, en función
del nivel de detalle necesario para cada rol.

6. BPMN no es apropiada para modelar estructuras organizativas, desgloses funcionales

o modelos de flujo de datos. Aunque BPMN muestra algunos flujos de información en
los procesos de negocio, no es un diagrama de flujo de datos (DFD).

Cómo realizar un modelado de procesos de negocio con Lucidchart

Es fácil crear modelos de procesos de negocio con Lucidchart. Después de registrarte,

simplemente inicia sesión y crea un documento en blanco o comienza con una plantilla.
Asegúrate de abrir la biblioteca de figuras BPMN, después arrastra y suelta las figuras que
necesites en el lienzo.

También puedes definir el estilo de las líneas, aplicar formato al texto o cambiar la posición de
los elementos para obtener el aspecto que desees. Luego, descarga, exporta o comparte tu
diagrama de la forma que gustes.

Un diagrama de flujo de datos o DFD (sus siglas en español e inglés) es una representación

gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos
también se puede utilizar para la visualización de procesamiento de datos (diseño
estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD
que primero muestra la interacción entre el sistema y las entidades externas.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador

original del diseño estructurado, basado en el modelo de computación de Martin y Estrin:
"flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas
esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador
de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las
etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a
poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el
sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser
elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer
diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de
flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo
resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el
sistema. La manera en que cualquier sistema es desarrollado, puede determinarse a través de
un diagrama de flujo de datos.
Los niveles de un DFD son:

 Nivel 0: Diagrama de contexto

 Nivel 1: Diagrama de nivel superior

 Nivel 2: Diagrama de detalle o expansión

Índice

 1Conexiones entre los elementos de un DFD

o 1.1Conexiones permitidas

 2Características de los niveles de un DFD

o 2.1Diagrama de Contexto: Nivel 0

o 2.2Diagrama de Nivel Superior: Nivel 1

o 2.3Diagrama de Detalle o Expansión: Nivel 2

Conexiones entre los elementos de un DFD[editar]

Conexiones permitidas[editar]

1. ENTIDAD - PROCESO

2. PROCESO - PROCESO

3. PROCESO - ALMACÉN

Características de los niveles de un DFD[editar]

Diagrama de Contexto: Nivel 0[editar]

En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con
su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la
organización, o factores externos a la misma. Se dibuja un solo proceso que representa al
sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más
adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el
sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el
dibujo, ya que estos son procesos estructurados y ordenados, además posee una cardinalidad
que varia según la función que desempeñe cada diagrama. Resulta de gran utilidad para los
niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama
de Flujo de Datos DFD de Nivel "0".

Diagrama de Nivel Superior: Nivel 1[editar]

En el diagrama de nivel superior se plasman todos los procesos que describen al proceso
principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre
ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de
construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de
abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera
ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo
en realidad un requisito no-funcional.

Diagrama de Detalle o Expansión: Nivel 2[editar]

En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos

principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí
en adelante se permiten los flujos entre procesos.

El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado
en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de
complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo
de sistemas. También se recomienda el diagrama de nivel superior.

El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified Modeling Language)

es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad;
está respaldado por el Object Management Group (OMG).

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML

ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos
conceptuales tales como procesos, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en
el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está
descrito el modelo.

Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una
metodología de desarrollo de software (tal como el Proceso Unificado Racional, Rational
Unified Process o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje
Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en
un requerimiento. Mientras que programación estructurada es una forma de programar como
lo es la orientación a objetos, la programación orientada a objetos viene siendo un
complemento perfecto de UML, pero no por eso se toma UML solo para lenguajes orientados
a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las
entidades representadas.

Índice

 1Estandarización de UML

 2Historia

o 2.1Antes de UML 1.x

 o 2.2UML 1.x

o 2.3UML 2.x

 3Tipos de diagramas en UML 2.5

o 3.1Estructurales

 3.1.1Diagrama de clases

 3.1.2Diagrama de componentes

 3.1.3Diagrama de despliegue

 3.1.4Diagrama de objetos

 3.1.5Diagrama de paquetes

 3.1.6Diagrama de perfiles

 3.1.7Diagrama de estructura compuesta

o 3.2De comportamiento

 3.2.1Diagrama de actividades

 3.2.2Diagrama de casos de uso

 3.2.3Diagrama de máquina de estados

 3.2.4Diagrama de interacción

 3.2.4.1Diagrama de secuencia

 3.2.4.2Diagrama de comunicación

 3.2.4.3Diagrama de tiempos

 3.2.4.4Diagrama global de interacciones

 4Referencias

 5Enlaces externos

Estandarización de UML[editar]

Desde el año 2004, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005

Information technology — Open Distributed Processing — Unified Modeling Language (UML)
Versión 1.4.2.

En el año 2012 se actualizó la norma a la última versión definitiva disponible en ese momento,

la 2.4.1, dando lugar a las normas ISO/IEC 19505-1

Historia[editar]

Antes de UML 1.x[editar]

Después de que la Rational Software Corporation contratara a James Rumbaugh de General

Electric, en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado
orientado a objetos más populares de la época: Object-Modeling Technique (OMT) de
Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch (de Grady
Booch) que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar
Jacobson, el creador del método de ingeniería de software orientado a objetos. Jacobson se
unió a Rational, en 1995, después de que su compañía Objectory AB fuera comprada por
Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabía de sus
constantes discusiones sobre las prácticas metodológicas.

En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la

adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron
a los Tres Amigos que desarrollaran un "lenguaje unificado de modelado" abierto. Se consultó
con representantes de compañías competidoras en el área de la tecnología de objetos durante
la OOPSLA '96; eligieron "cajas" para representar clases en lugar de la notación de Booch que
utilizaba símbolos de "nubes".

Bajo la dirección técnica de los Tres Amigos (Rumbaugh, Jacobson y Booch) fue organizado un

consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del
UML, y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML
1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes,
la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y
administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla
con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue
presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x[editar]

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo, el uso de
rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, sí se
adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La
notación de "Casos de Uso" del Objectory y la notación de componentes de Booch fueron
integrados al resto de la notación, pero la integración semántica era relativamente débil en
UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.

Conceptos de muchos otros métodos orientados a objetos (MOO) fueron integrados

superficialmente en UML con el propósito de hacerlo compatible con todos los MOO. Además,
el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar
amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en
una gran variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de
solamente un usuario a sistemas concurrentes y distribuidos.

UML 2.x[editar]

UML ha madurado considerablemente desde UML 1.1, varias revisiones menores (UML 1.3, 1.4
y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha seguido la
revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y 2.1.2,
aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado
oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML
2.5.1 fue lanzado en octubre de 2012 como una versión "En proceso" que fue formalmente
liberada en junio de 2015.

Tipos de diagramas en UML 2.5[editar]

Existen dos clases principales de tipos de diagramas: diagramas estructurales y diagramas
de comportamiento. Estos últimos incluyen varios que representan diferentes aspectos de
las interacciones. Estos diagramas pueden ser categorizados jerárquicamente como se muestra
en el siguiente diagrama de clases:

Estructurales[editar]

Los diagramas estructurales muestran la estructura estática del sistema y sus partes en
diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de estructura:

Diagrama de clases[editar]

Los diagramas de clase son, sin duda, el tipo de diagrama UML más utilizado. Es el bloque de
construcción principal de cualquier solución orientada a objetos. Muestra las clases en un
sistema, atributos y operaciones de cada clase y la relación entre cada clase. En la mayoría de
las herramientas de modelado, una clase tiene tres partes, nombre en la parte superior,
atributos en el centro y operaciones o métodos en la parte inferior. En sistemas grandes con
muchas clases relacionadas, las clases se agrupan para crear diagramas de clases. Las
diferentes relaciones entre las clases se muestran por diferentes tipos de flechas.

Diagrama de componentes[editar]

Un diagrama de componentes muestra la relación estructural de los componentes de un

sistema de software. Estos se utilizan principalmente cuando se trabaja con sistemas
complejos que tienen muchos componentes. Los componentes se comunican entre sí
mediante interfaces. Las interfaces se enlazan mediante conectores.

Diagrama de despliegue[editar]

Un diagrama de despliegue muestra el hardware de su sistema y el software de ese hardware.

Los diagramas de implementación son útiles cuando la solución de software se despliega en
varios equipos, cada uno con una configuración única.

Diagrama de objetos[editar]

Los diagramas de objetos, a veces denominados diagramas de instancia, son muy similares a
los diagramas de clases. Al igual que los diagramas de clases, también muestran la relación
entre los objetos, pero usan ejemplos del mundo real. Se utilizan para mostrar cómo se verá
un sistema en un momento dado. Debido a que hay datos disponibles en los objetos, a
menudo se utilizan para explicar relaciones complejas entre objetos.

Diagrama de paquetes[editar]

Diagrama de perfiles[editar]

Diagrama de perfil es un nuevo tipo de diagrama introducido en UML 2. Este es un tipo de

diagrama que se utiliza muy raramente en cualquier especificación.

Diagrama de estructura compuesta[editar]

Los diagramas de estructura compuesta se utilizan para mostrar la estructura interna de una
clase.

De comportamiento[editar]

Muestran el comportamiento dinámico de los objetos en el sistema.

Diagrama de actividades[editar]

Los diagramas de actividad representan los flujos de trabajo de forma gráfica. Pueden
utilizarse para describir el flujo de trabajo empresarial o el flujo de trabajo operativo de
cualquier componente de un sistema. A veces, los diagramas de actividad se utilizan como una
alternativa a los diagramas de máquina del estado.

Diagrama de casos de uso[editar]

Como el tipo de diagrama UML más conocido, los diagramas de casos de uso ofrecen una
visión general de los actores involucrados en un sistema, las diferentes funciones que
necesitan esos actores y cómo interactúan estas diferentes funciones. Es un gran punto de
partida para cualquier discusión del proyecto, ya que se pueden identificar fácilmente los
principales actores involucrados y los principales procesos del sistema.

Diagrama de máquina de estados[editar]

Los diagramas de máquina de estado son similares a los diagramas de actividad, aunque las
anotaciones y el uso cambian un poco. En algún momento se conocen como diagramas de
estados o diagramas de diagramas de estado también. Estos son muy útiles para describir el
comportamiento de los objetos que actúan de manera diferente de acuerdo con el estado en
que se encuentran en el momento.

Diagrama de interacción[editar]

Los diagramas de interacción incluyen distintos tipos de diagramas:

Diagrama de secuencia[editar]

Los diagramas de secuencia en UML muestran cómo los objetos interactúan entre sí y el orden
en que se producen esas interacciones. Es importante tener en cuenta que muestran las
interacciones para un escenario en particular. Los procesos se representan verticalmente y las
interacciones se muestran como flechas. Los diagramas de secuencia de UML forman parte de
un modelo UML y solo existen dentro de los proyectos de modelado UML.

Diagrama de comunicación[editar]
El diagrama de comunicación se llamó diagrama de colaboración en UML 1. Es similar a los
diagramas de secuencia, pero el foco está en los mensajes pasados entre objetos.

Diagrama de tiempos[editar]

Los diagramas de sincronización son muy similares a los diagramas de secuencia. Representan
el comportamiento de los objetos en un marco de tiempo dado. Si es solo un objeto, el
diagrama es directo, pero si hay más de un objeto involucrado, también se pueden usar para
mostrar interacciones de objetos durante ese período de tiempo.

Diagrama global de interacciones[editar]

Los diagramas generales o globales de interacción son muy similares a los diagramas de
actividad. Mientras que los diagramas de actividad muestran una secuencia de procesos, los
diagramas de interacción muestran una secuencia de diagramas de interacción. En términos
simples, pueden llamarse una colección de diagramas de interacción y el orden en que
suceden. Como se mencionó anteriormente, hay siete tipos de diagramas de interacción, por
lo que cualquiera de ellos puede ser un nodo en un diagrama de vista general de interacción.