REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENSA

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITÉCNICA
DE LA FUERZA ARMADA
NUCLEO LARA
BARQUISIMETO

Lenguaje unificado
de modelado (UML)

INTEGRANTES:
MIGDALIA SALAZAR CI 17728034
WILMARYS PÉREZ CI 23918287
WHITNEY LEÓN CI 24549627
YORLYS OROPEZA CI 25142034
SECCIÓN: 7N01IS

ABRIL, 2018
 UML

El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de

modelado visual común y semántica y sintácticamente rico para la arquitectura, el diseño y
la implementación de sistemas de software complejos, tanto en estructura como en
comportamiento. UML tiene aplicaciones más allá del desarrollo de software, por ejemplo
en el flujo de procesos en la fabricación

Es comparable a los planos usados en otros campos y consiste en diferentes tipos de

diagramas. En general, los diagramas UML describen los límites, la estructura y el
comportamiento del sistema y los objetos que contiene.

UML no es un lenguaje de programación, pero existen herramientas que se pueden usar

para generar código en diversos lenguajes usando los diagramas UML. Este lenguaje guarda
una relación directa con el análisis y el diseño orientados a objetos.

Diagramas UML

Estructurales: Muestran la estructura estática de los objetos en un sistema.

 Diagrama de clases: 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: 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: 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: 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: Como su nombre indica, un diagrama de paquetes muestra
las dependencias entre diferentes paquetes de un sistema.
 Diagrama de perfiles: El 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: Los diagramas de estructura compuesta se
utilizan para mostrar la estructura interna de una clase.

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

 Diagrama de actividades: 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 Como el tipo de diagrama de diagramas 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 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.

De interacción

 Diagrama global de interacciones: 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.
 Diagrama de comunicación: 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 secuencia 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.
 Diagrama de tiempos 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.

Los diagramas de secuencia de UML forman parte de un modelo UML y solo existen
dentro de los proyectos de modelado UML. Para crear un diagrama de secuencia UML, en el
menú Arquitectura, haga clic en Nuevo diagrama de capas o UML.

Estudio de caso
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse
para llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de
uso se denominan actores. En el contexto de ingeniería del software, un caso de uso es una
secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra
la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión
entre los elementos del modelo, por ejemplo la especialización y la generalización son
relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requisitos del sistema
al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Su uso es común para la captura de requisitos funcionales, especialmente con el paradigma

de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con
resultados igualmente satisfactorios con otros paradigmas de programación.
Actores

Artículo principal: Actor (UML)

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que
le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye
a todos los sistemas externos, además de entidades abstractas, como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por
lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin
embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que
nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y
siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de
capturar dicho requisito en el modelo de caso de uso final.

Tipos de relaciones

 Comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de

uso que denota la participación del actor en dicho caso de uso.
 Usa (<<uses>>) (o <<include>> en la nueva versión de UML): Relación de
dependencia entre dos casos de uso que denota la inclusión del comportamiento de
un escenario en otro.
 Extiende (<<extends>>): Relación de dependencia entre dos casos de uso que denota
que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso
 de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de
azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas
(cucharadas o bolsas).
 Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos
encontramos con un caso de uso similar a otro pero que hace algo más que éste
(variante). Por contra, utilizaremos una relación tipo <<uses>> cuando nos
encontramos con una parte de comportamiento similar en dos casos de uso y no
queremos repetir la descripción de dicho comportamiento común.

 En una relación <<extends>>, un actor que lleve a cabo el caso de uso base puede
realizar o no sus extensiones. Mientras, en una relación <<include>> el actor que
realiza el caso de uso base también realiza el caso de uso incluido.

 En general utilizaremos <<extends>> cuando se presenta una variación del

comportamiento normal, e <<include>> cuando se repite un comportamiento en dos
casos de uso y queremos evitar dicha repetición.

 Por último en un diagrama de casos de uso, además de las relaciones entre casos de
uso y actor (asociaciones) y las dependencias entre casos de uso (<<include>> y
<<extends>>), pueden existir relaciones de herencia ya sea entre casos de uso o entre
actores.

Llamamos modelo de casos de uso a la combinación de casos de uso y sus

correspondientes diagramas. Los modelos de casos de uso se suelen acompañar por un
glosario que describe la terminología utilizada. El glosario y el modelo de casos de uso son
importantes puntos de partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes
realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a
descartarla, si es el caso.
Pasos para la Definición de un Caso de Uso:

Id
Nombre
Referencias cruzadas
Creado por
Última actualización por
Fecha de creación
Fecha de última actualización
Actores
Descripción
Trigger
Pre-condición
Post-condición
Flujo normal
Flujos alternativos
Includes
Frecuencia de uso
Reglas de negocio
Requisitos especiales
Notas y asunto