7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 1/14

METODOLOGÍA UML (Lenguaje Unificado de Modelado)

Es el lenguaje de modelado de sistemas software más conocido y utilizado en la

actualidad; está respaldado por el OMG (Object Management Group, Objeto de Gestión

de Grupo). 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 de negocio, 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 ésta

metodología es un "lenguaje de modelado" para especificar o describir métodos o

 procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema,

 para documentar y construir el sistema. 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 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 diagrama la

realidad de una utilización en un requerimiento. La programación orientada a objetos

viene siendo un complemento perfecto de UML, pero no por eso se puede tomar a UML

sólo y únicamente para lenguajes orientados a objetos.  En todas las disciplinas de la

Ingeniería se hace evidente la importancia de estos modelos ya que describen el aspecto

y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o

estar, en un estado de planeación. Es en este momento cuando los diseñadores del

modelo deben investigar los requerimientos del producto terminado y dichos

requerimientos pueden incluir áreas tales como funcionalidad, performance y

confiabilidad.

UML no es:

  Un lenguaje de programación visual, sino un lenguaje de modelamiento visual

  Una herramienta o depósito de especificación, sino un lenguaje para

modelamiento de especificación.

 Un proceso, sino que habilita procesos.

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 2/14

Fundamentalmente, UML está relacionado con la captura, comunicación y nivelación de

conocimientos.

MODELOS

Un modelo es una abstracción de algo, que se elabora para comprender ese algo

antes de construirlo. El modelo omite detalles que no resultan esenciales para la

comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de

construir una casa el arquitecto utiliza un plano, los músicos representan la música en

forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de

empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos

 bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad

utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura

estática; el modelo dinámico, con el que describe las relaciones temporales entre

objetos; y el modelo funcional que describe las relaciones funcionales entre valores.

Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la

realidad que tiene en sí misma información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles

de los originales, permiten probar más fácilmente los sistemas que modelan y

determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los

modelos permiten una mejor comunicación con el cliente por distintas razones:

  Es posible enseñar al cliente una posible aproximación de lo que será el

 producto final.

  Proporcionan una primera aproximación al problema que permite visualizar 

cómo quedará el resultado.

  Reducen la complejidad del original en subconjuntos que son fácilmente

tratables por separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los

aspectos importantes del problema y omite el resto. Los lenguajes de programación que

estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de

sistemas reales porque necesitan una especificación total con detalles que no son

importantes para el algoritmo que están implementando. En OMT se modela un sistema

desde tres puntos de vista diferentes donde cada uno representa una parte del sistema yuna unión lo describe de forma completa. En esta técnica de modelado se utilizó una

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 3/14

aproximación al proceso de implementación de software habitual donde se utilizan

estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos

tienen una secuencia en el tiempo (modelo dinámico) y se realiza una transformación

sobre sus valores (modelo funcional).

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de

la realidad que modela mediante los distintos tipos de diagramas que posee. Con la

creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier 

tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante

representaciones gráficas que contienen toda la información relevante del sistema. Un

diagrama es una representación gráfica de una colección de elementos del modelo, que

habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las

relaciones entre los objetos y los vértices se corresponden con los elementos del

modelo. Los distintos puntos de vista de un sistema real que se quieren representar para

obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para

entender el sistema.

MODELADO DE PROCESOS

El modelado de procesos debe ser entendido, a saber, por dos cuestiones

importantes: el modelado y los procesos. Frecuentemente los sistemas (conjuntos de

 procesos y subprocesos integrados en una organización) son difíciles de comprender,

amplios, complejos y confusos; con múltiples puntos de contacto entre sí y con un buen

número de áreas funcionales, departamentos y puestos implicados. Un modelo puede

dar la oportunidad de organizar y documentar la información sobre un sistema.

DEFINICION Y TECNICAS DE CONSTRUCCION

Es necesario pues describir un proceso de aplicación de UML. Se presentará un

 proceso sencillo destinado a aplicaciones cuyo desarrollo no involucra equipos de

 programadores ni tiempos de desarrollo muy grandes. Se trata de un proceso iterativo,

incremental y guiado por los casos de uso. Este proceso es resultado de añadir una etapa

de modelado de negocio al proceso.

A partir de los modelos especificados se pueden construir los sistemas

diseñados.

Un modelo UML esta compuesto por tres clases de bloques de construcción:

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 4/14

Elementos: Los elementos son abstracciones de cosas reales o ficticias (objetos,

acciones, etc.)

Relaciones: relacionan los elementos entre sí.

Diagramas: Son colecciones de elementos con sus relaciones.

Un Diagrama es la representación gráfica de un conjunto de elementos con sus

relaciones. UML ofrece una amplia variedad de diagramas para visualizar el sistema

desde varias perspectivas.

MODELO ESTÁTICO

El modelo estático es uno de los tres modelos que componen OMT, este modelo

tiene la tarea de modelar la estructura estática de nuestro sistema, mostrándonos las

clases, objeto y relaciones que existen dentro del sistema.

Ahora este modelo tiene dos herramientas para mostrar de una manera más

grafica el comportamiento estático del sistema, estas son “El diagrama de Clases” y “El

diagrama de Objetos”. 

El diagrama de clases como sus nombre indica, solo hace uso de clases para

representar el sistema, mientras el diagrama de objetos usa los objetos instanciados del

diagrama de clases, por lo cual para hacer un diagrama de objetos, previamente debimos

de haber realizado un diagrama de clases. El diagrama de clases usa los siguientes

símbolos para modelar el sistema.

Clases:

Para definir niveles de acceso se usa la siguiente nomenclatura:

+ (Publico)

# (Protegido)

- (Privado)

Seguido al nombre del atributo o método, se puede definir el tipo que representa

o que devuelve (solo métodos), para hacer esto deberemos de seguir la siguiente

nomenclatura:

 Nombre_Atributo/Metodo: Tipo_Dato

De igual modo para los parámetros de entrada usaremos la misma nomenclatura.

Relaciones Binarias:

La relación Binaria entre clase y objeto se representa mediante una línea recta y

en cada extremo se denota la multiplicidad de la relación, las multiplicidades existentes

son:

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 5/14

<!--[if !supportLists]-->- <!--[endif]-->Uno a muchos (1 - *)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Uno (1 – 1)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Cero o Uno (1 – 0..1)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Cero o Muchos (1 – 0..*)

<!--[if !supportLists]-->- <!--[endif]-->Uno a Uno o Muchos (1 – 1..*)

<!--[if !supportLists]-->- <!--[endif]-->Muchos a Muchos (* - *)

Además encima de la línea que representa la relación, se le deberá de etiquetar con

algún nombre:

  Relación de Herencia.

  Relación de Composición.

Conceptos que nos ayudaran a hacer mejores modelos estáticos:

Alta Cohesión:

La alta cohesión hace referencia a que: “Los atributos y operaciones de una clase

deben referenciar a la misma clase y no a atributos o funcionalidades de otras clases que

estén dentro del contexto del problema”, en otras palabras, tus clases deben de tener 

solo atributos y métodos que le conciernan solo a sí mismas.

Bajo Acoplamiento:

El bajo acoplamiento: “Define la característica de un diagrama de clase donde

cada clase debe de tener la mínima cantidad de asociaciones posible con otras clases”,

esto nos dice que no hagamos asociaciones inútiles entre clases.

Clave Candidata:

La clave candidata se la puede definir como: “Un atributo que debe de tener un

valor único”, la clave candidata se parece al OID, pero a diferencia de esta, en la clave

candidata se puede modificar su valor o eliminar el valor.

MODELO DINÁMICO

El modelo dinámico tiene la tarea de mostrar el comportamiento del sistema

durante el transcurso del tiempo o mejor dicho en función al tiempo.

El modelo dinámico al igual que el estático tiene dos herramientas para representar esto,

y estas son “El Diagrama de Estado” y “El diagrama de Sucesos”. 

Ahora me gustaría definir que es un diagrama de estados para que se entienda

mejor, donde y como implementarlo:

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 6/14

Diagrama de Estados:  “Es un diagrama que presenta los estados en los que puede

encontrarse un objeto, junto con las transacciones entre los estados, y muestra los

estados Inicial y Final de una secuencia de cambios de estados”2 

Para entender mejor la anterior definición procedamos a definir que es un estado:

“Estado es la situación en la cual se encuentra un objeto con sus respectivos

valores para sus atributos en un punto del tiempo específico”. 

La anterior definición nos da como pauta que si alguno de los atributos se modifica

existe la posibilidad de cambio de estado, y digo posibilidad ya que puede darse el caso

que si un atributo se modifica este puede no variar el estado del objeto; La variación de

un atributo casi siempre se debe a un Evento o Suceso, así que sería bueno definir 

formalmente que es un evento o suceso:

Evento: “Hecho que se produce en un punto del tiempo, que puede o no modificar un

atributo” 

Con esto ya definido, creo que el concepto de Diagrama de estados se entiende a

cabalidad, ahora lo que nos resta es ver los símbolos que se utilizan para modelar uno de

estos diagramas:

Estado:

La nomenclatura de un estado es simple, en la parte de arriba se debe de

especificar el nombre del estado sin subrayados, negrillas u otras cosas, después en la

estructura tenemos tres identificadores básicos que son “entrada”, “salir” y “hacer”,

tanto entrada como salir son acciones que se deben de dar tanto cuando se entra al

estado como cuando se sale del estado, en el identificador hacer, podemos definir tareas

que el objeto va a realizar mientras este en ese estado.

Estado Inicial: El estado inicial es cuando un objeto acaba de ser instanciado.  

Estado Final: El estado final es cuando un objeto es destruido. 

Transición: La transición se representa con una línea recta y encima de esta el evento

que produjo el cambio de estado. 

Estado Compuesto: Un estado compuesto o súper estado, es un estado que engloba a

dos o más estados dentro de uno solo. 

Ahora es el turno del diagrama de sucesos, al igual que el otro diagrama, procederemos

a definirlo.

Diagrama de Sucesos: “Es un diagrama que muestra la interacción entre los distintos

objetos mediante los mensajes que se mandan entre ellos, en un escenario enespecífico”.

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 7/14

Creo que el concepto está realmente claro, pero creo que mejoraría si defino que es un

escenario.

Escenario:  “Es un conjunto especifico de eventos o sucesos que se dan dentro del

sistema en un momento de tiempo dado”. 

Con esto ya está re-claro que modela el diagrama de sucesos, por lo cual solo me resta

explicar el elemento con los que se modela este diagrama.

Actor:

El actor, es quien interactúa con el sistema, este actor puede ser una persona real,

otro sistema o alguno objeto de nuestro sistema, todo depende de nuestro escenario, al

actor se lo representa como un hombrecito.

Objeto:

Los objeto en este diagrama se representan con un cuadrado, donde se sitúa el

nombre del objeto, todo sub-rayado, además tiene una línea punteada saliendo de la

 parte baja del recuadro, esta representa su línea de tiempo.

Mensaje:

Los mensajes se representan con una línea recta y una flechita, además en la

 parte de arriba se encuentra la etiqueta de este, como un apunte recordar, que los

mensajes que se indiquen en el diagrama de sucesos previamente debieron de ser 

definidos en el diagrama de estados, ya que en ese diagrama definimos las relaciones

que por donde fluye el mensaje.

MODELADO DE PROCESOS

El modelado de procesos, así como su nombre lo indica, tiene 2 aspectos que lo

definen: el modelado y los procesos. Frecuentemente, los sistemas, conjuntos de

 procesos y subprocesos integrados en una organización, son difíciles de comprender,

amplios, complejos y confusos; con múltiples puntos de contacto entre sí y con un buen

número de áreas funcionales, departamentos y puestos implicados. Un modelo puede

dar la oportunidad de organizar y documentar la información sobre un sistema.

Modelo

Un modelo es una representación de una realidad compleja. Modelar es

desarrollar una descripción lo más exacta posible de un sistema y de las actividades

llevadas a cabo en él.

Cuando un proceso es modelado, con ayuda de una representación gráfica

(diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 8/14

entre distintas actividades, analizar cada actividad, definir los puntos de contacto con

otros procesos, así como identificar los subprocesos comprendidos. Al mismo tiempo,

los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad

al inicio de acciones de mejora.

Diagramado

Diagramar es establecer una representación visual de los procesos y

subprocesos, lo que permite obtener una información preliminar sobre la amplitud de

los mismos, sus tiempos y los de sus actividades.

La representación gráfica facilita el análisis, uno de cuyos objetivos es la

descomposición de los procesos de trabajo en actividades discretas. También hace

 posible la distinción entre aquellas que aportan valor añadido de las que no lo hacen, es

decir que no proveen directamente nada al cliente del proceso o al resultado deseado. En

este último sentido cabe hacer una precisión, ya que no todas las actividades que no

 proveen valor añadido han de ser innecesarias; éstas pueden ser actividades de apoyo y

ser requeridas para hacer más eficaces las funciones de dirección y control, por razones

de seguridad o por motivos normativos y de legislación.

Diagramar es una actividad íntimamente ligada al hecho de modelar un proceso,

que es por sí mismo un componente esencial en la gestión de procesos de negocios.

Tocaremos 3 de los lenguajes de modelado de procesos más conocidos:

Lenguaje Unificado de Modelado (UML)

Es uno de los lenguajes de modelado de procesos más conocidos y utilizados en

la actualidad. Está respaldado por el OMG, Object Management Group o Grupo de

Gestión de Objetos). El UML es un lenguaje gráfico para visualizar, especificar,

construir y documentar un sistema. Además, ofrece un estándar para describir un

"plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de

negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de

 programación, esquemas de bases de datos y componentes reutilizables.

Es importante resaltar 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.

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 9/14

Business Process Modeling Notation (BPMN)

En español, Notación para el Modelado de Procesos de Negocio, es una notación

gráfica estandarizada que permite el modelado de procesos de negocio, en un formato

de flujo de trabajo (workflow). BPMN fue inicialmente desarrollada por la organización

Business Process Management Initiative (BPMI), y es actualmente mantenida por el

OMG (Object Management Group), luego de la fusión de las dos organizaciones en el

año 2005. Su versión actual es la 1.2 y hay una versión futura propuesta, la 2.0.

El principal objetivo de BPMN es proveer una notación estándar que sea

fácilmente legíble y entendible por parte de todos los involucrados e interesados del

negocio (stakeholders). Entre estos interesados están los analistas de negocio (quienes

definen y redefinen los procesos), los desarrolladores técnicos (responsables de

implementar los procesos) y los gerentes y administradores del negocio (quienes

monitorizan y gestionan los procesos). En síntesis BPMN tiene la finalidad de servir 

como lenguaje común para cerrar la brecha de comunicación que frecuentemente se

 presenta entre el diseño de los procesos de negocio y su implementación.

Diagrama de flujo de datos (DFD)

El diagrama de flujo de datos puede ser utilizado para visualizar el

 procesamiento de datos. Los diagramas de flujo fueron inventados por Larry

Constantine, el desarrollador original del diseño estructurado, basado en el modelo de

computación de Martin y Estrin:”flujo grafico de datos”. Con el DFD los usuarios

 pueden ver cómo funciona el sistema, lo que va a lograr y como se pondrá en práctica.

Puede ser usado para proporcionar al usuario de cómo van a resultar los datos físicos en

la ultima instancia y como tienen un efecto en la estructura del sistema. La elaboración

de un DFD ayuda a identificar los datos de las transacciones en el modelo de datos.

El modelado de procesos DFD consta de 3 niveles:

Nivel 0 o de contexto: consta en que solo se dibuja el proceso principal y los flujos

entre éste y sus entidades.

Nivel 1 o superior: consiste en plasmar todos los procesos que describen al proceso

 principal.

Nivel 2 o de expansión: permite interconexiones entre procesos. 

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 10/14

MODELADO ESTRUCTURAL

Se modelan los aspectos estáticos de un sistema. Se utilizan clases Para cada

clase hay que determinar un conjunto de responsabilidades y posteriormente determinar 

los atributos y las operaciones necesarias para llevar a cabo las responsabilidades de la

clase.

Responsabilidades:

o  Fin para el que es creada una clase.

o  Obligaciones

o  Es buena práctica iniciar especificando las responsabilidades de cada clase.

  Objetivo: Abstraer lo necesario y suficiente. No dar demasiadas

responsabilidades a una sola clase ni obtener clases con muy pocas

responsabilidades.

Relaciones:

o  Manera de representar las interacciones entre clases

o  OJO: Si se modela en exceso, se obtendrán diagramas con un alto nivel de

dificultad para poder leerlos. Si se modela insuficiente, se obtendrán diagramas

sin la semántica suficiente.

Interfaces:

o  Colección de operaciones que sirven para especificar el servicio que una clase o

componente da al resto de las partes involucradas en un sistema.

o  UML las utiliza para modelar las líneas de separación de un sistema.

o  Puede participar en relaciones de realización.

o  Una interfaz especifica un contrato para una clase o componente sin dictar su

implementación.

Roles:

o  Una clase puede implementar varios interfaces. Un rol denota un

comportamiento de una entidad en un contexto particular.

o  Lo habitual es utilizar la notación en forma de círculo para denotar líneas de

separación del sistema cuando utilizamos componentes, y utilizar la notación

expandida en las relaciones de realización.

Paquetes:

o  Mecanismo de propósito general para organizar elementos de modelado en

grupos

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 11/14

o  Se puede controlar la visibilidad de los elementos de un paquete (algunos podrán

ser visibles, otros estarán ocultos)

o  Un paquete forma un espacio de nombres.

o  Los paquetes se pueden anidar, pero deben evitarse paquetes muy anidados. Dos

o tres niveles de anidamiento como máximo.

Instancias:

o  Sinónimo de objeto. Representa la manifestación concreta de una abstracción

(clase, nodo, casos de uso, asociaciones...)

o  Sus operaciones se denotan como: u.getPermisos()

o  Los valores concretos de sus atributos determinan su estado

MODELADO DEL COMPORTAMIENTO

o  Se modelan los aspectos dinámicos de un sistema mediante interacciones

o  Utilizada para modelar el flujo de control dentro de una operación, una clase, un

componente, un caso de uso el propio sistema

o  Un mensaje es la especificación de una comunicación entre objetos que

transmite información, con la expectativa de que se desencadenará una

actividad.

¿Dónde aparecen las interacciones?

o  En la colaboración de objetos existentes en el contexto de un sistema o un

subsistema

o  Entre los objetos de un mismo subsistema en la implementación de una

operación

o  En el contexto de una clase (cómo los atributos y diferentes operaciones

interaccionan entre sí para dar lugar a una nueva operación)

o  Los objetos que participan en una interacción son o bien elementos concretos

(objetos) o bien elementos prototípicos (clases, nodos y casos de uso).

Enlace: Instancia de una asociación. Siempre que exista un enlace entre dos objetos, un

objeto puede mandar un mensaje al otro. 

Mensajes: Especificación de una comunicación entre objetos que transmite

información, con la expectativa de que se desencadenará alguna actividad

Tipos de mensajes

o  Llamada: Invoca una operación sobre un objeto. o  Retorno: Devuelve un valor al invocador. 

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 12/14

o  Envío: Envía una señal a un objeto.

o  Creación. 

o  Destrucción. 

Modelado de un Flujo de Control: Construir una representación gráfica (a modo de

diagrama de secuencias o de colaboración) de las acciones que tienen lugar entre un

conjunto de objetos.

Casos de Uso: Especifica el comportamiento de un sistema o una parte del mismo, y es

una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que

ejecuta un sistema para producir un resultado observable para un actor.

Se emplean para capturar el comportamiento deseado del sistema en desarrollo

sin tener que especificar cómo se implementa ese comportamiento.

Proporcionan un medio para que desarrolladores y usuarios finales del sistema

lleguen a una comprensión común del sistema.

 No especifican cómo se implementa: especifican un comportamiento deseado,

 pero no indican cómo se lleva a cabo.

 Normalmente se evita el empleo de jergas técnicas, prefiriendo en su lugar un

lenguaje más cercano al usuario final. En ocasiones, se utiliza a usuarios sin experiencia

 junto a los analistas para el desarrollo de casos de uso.

Un caso de uso representa un requisito funcional del Sistema.

Actores:

Los actores representan un rol que puede ser jugado por una persona, un

dispositivo hardware o incluso otro sistema. Se pueden representar categorías de actores

más generales. Sólo se pueden conectar a los casos de uso a través de asociaciones.

DIAGRAMAS DE UML

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema

modelado:

  Diagrama de Clases: Es un tipo de diagrama estático que describe la estructura

de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los

diagramas de clases son utilizados durante el proceso de análisis y diseño de los

sistemas, donde se crea el diseño conceptual de la información que se manejará

en el sistema, y los componentes que se encargaran del funcionamiento y la

relación entre uno y otro.

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 13/14

  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.

  Diagrama de Objetos: Son utilizados durante el proceso de Análisis y Diseño

de los sistemas informáticos en la metodología UML. 

  Diagrama de Estructura Compuesta: 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.

  Diagrama de Despliegue: Se utiliza para modelar el hardware utilizado en las

implementaciones de sistemas y las relaciones entre sus componentes.

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.

  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 Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema

modelado:

  Diagrama de Actividades: Es la representación gráfica del algoritmo o proceso.

Se utiliza en disciplinas como  programación, economía, procesos

industriales y psicología cognitiva. 

  Diagrama de Casos de Uso: Es una especie de diagrama de comportamiento.

UML mejorado El Lenguaje de Modelado Unificado 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

7/16/2019 UML.docx

http://slidepdf.com/reader/full/umldocx-5633856e09271 14/14

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. 

  Diagrama de Estados: La representación gráfica de las fronteras entre

diferentes estados de la materiade un sistema, en función de variables elegidas

 para facilitar el estudio del mismo. Cuando en una de estas representaciones

todas las fases corresponden a estados de agregación diferentes se suele

denominar diagrama de cambio de estado. 

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que

enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:

  Diagrama de Secuencia: Es un tipo de diagrama usado para modelar 

interacción entre objetos en un sistema según UML. 

  Diagrama de comunicación, que es una versión simplificada del Diagrama

de colaboración: Modela las interacciones entre objetos o partes en términos de

mensajes en secuencia. Los diagramas de comunicación representan una

combinación de información tomada desde el diagrama de clases, secuencia, 

y diagrama de casos de uso describiendo tanto la estructura estática como el

comportamiento dinámico de un sistema.

  Diagrama de Tiempos: Es una gráfica de formas de onda digitales que muestra

la relación temporal entre varias señales, y cómo varía cada señal en relación a

las demás.

  Diagrama global de interacciones o Diagrama de vista de interacción: Es

una de las trece clases de diagramas en el Lenguaje de Modelado

Unificado (UML), un lenguaje de modelamiento para software y otros sistemas.