UML.docx
-
Upload
jesus-bolivar -
Category
Documents
-
view
14 -
download
0
Transcript of UML.docx
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.