UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA

TRABAJO GRUPAL – UNIDAD 1 PASO 1

RECONOCIMIENTO DEL CURSO

GRUPO: 200609_10
LENGUAJE DE MODELADO UNIFICADO UML
TUTOR: NILSON ALBEIRO FERREIRA MANZANARES

Autores:

WILLIAM FERNANDO PARRA Código: 1.118.283.345

ELIZABETH RESTREPO TORO Código: 1.035.867.603

DIANA RODRIGUEZ COSME Código: 1.1130.642.492

JESÚS MARINO GÓMEZ MUÑOZ Código:

ISABEL CRISTINA GÓMEZ ACEVEDO Código: 24.336.954

UNAD

CEAD MEDELLIN

2017
 TABLA DE CONTENIDO

INTRODUCCIÓN......................................................................................................................................3

DESARROLLO DE ACTIVIDADES........................................................................................................4

Diagrama de Caso de Uso......................................................................................................................5

Diagrama de Actividades.........................................................................................................................8

Diagrama de Secuencia...........................................................................................................................9

Diagrama de Clases...............................................................................................................................11

Diagrama de Despliegue.......................................................................................................................13

CONCLUSIONES...................................................................................................................................15

REFERENCIAS BIBLIOGRÁFICAS.....................................................................................................16
 INTRODUCCIÓN

En el siguiente documento se presentará la investigación realizada sobre el Lenguaje

de Modelado Unificado UML, el cual permite describir de forma conceptual un sistema
a través de múltiples diagramas. Este lenguaje busca definir de forma visual, lógica y
de proceso las funcionalidades de un sistema, la secuencia de la ejecución de los
procesos, sus relaciones, los componentes que lo componen a alto nivel, entre otros;
se definirá un poco la función y conceptos básicos de los diagramas más usados, los
cuáles son: Diagrama de Caso de Uso, Diagrama de Actividades, Diagrama de
Secuencia, Diagrama de Clases, Diagrama de Despliegue.
 DESARROLLO DE ACTIVIDADES

A continuación se relaciona la tabla con el listado de diagramas que se van a investigar

y analizar con su responsable:

Diagrama Quien definirá o desarrollará

Diagrama de Caso de
Uso
Diagrama De Actividades
Diagrama de Secuencia
Diagrama de Clases
Diagrama de Despliegue
William Fernando Parra
Jesús Marino Gómez Muñoz
Diana Rodríguez Cosme
Elizabeth Restrepo Toro
Isabel Cristina Gómez Acevedo
 Diagrama de Caso de Uso

Un diagrama de caso de uso permite definir las funcionales que compone un sistema,
detallando los actores que participan en la activación de dichos procesos, el marco en
el cual se desarrollan esas actividades y las relaciones que existen entre todos estos
elementos. De acuerdo con esto se describirán a continuación cada uno de los
conceptos mencionados:

1) Evento Externo

 Alguna actividad de un ente externo ante la cual el sistema debe responder.

 Produce un estímulo que despierta una actividad esencial, la cual lleva a cabo las
tareas necesarias para dar respuesta al evento, y el sistema se duerme de nuevo
hasta que suceda otra ocurrencia del mismo, o de otro evento.
 Está constituido por la acción del ente externo y el estímulo generado hacia el
sistema.
 Un evento externo puede involucrar a uno o más actores.

2) Ente Externo

 Es un actor que utiliza el sistema con un propósito específico.

 Un actor no es una persona o un sistema, es la abstracción del rol que juega un ser
humano frente al sistema, o la abstracción del rol que juegan otros sistemas como
actores externos.
 La necesidad del actor se satisface con un evento externo del sistema.
 El conjunto completo de actores describe todas las formas de comunicación con el
sistema.
Los actores pueden participar en uno o más eventos externos, pero un actor que no
esté involucrado en ningún evento externo no tiene ningún sentido para un sistema.

3) Actor

El actor representa el responsable del inicio de la ejecución de la funcionalidad descrita

en un caso de uso, el actor puede corresponder a una persona o a un sistema y debe
definirse en términos de roles. Para lograr identificar los actores que participan en un
sistema, se puede tener como pauta la resolución de las siguientes preguntas:

 ¿Quién y qué usa el sistema?

 ¿Qué usuarios realizan las funciones principales del sistema?
 ¿Qué usuarios realizan funciones secundarias, como mantenimiento o
administración?
 ¿Dónde están usando el sistema?
 ¿Existe algún sistema externo de hardware o software?
 ¿Se presenta activación del sistema con algún proceso programado?

4) Caso de Uso

Define una secuencia de acciones que son ejecutadas por el sistema y que le dan un
resultado observable al actor. Para facilitar la identificación de los casos de uso en un
problema, se puede resolver los siguientes interrogantes:

 Cuáles son los objetivos de cada actor en el sistema?

o ¿Por qué el actor quiere usar el sistema?

o ¿El actor creará, guardará, cargará, borrará o leerá datos en el sistema?
o ¿El actor necesita ingresar información al sistema, para su almacenamiento o
procesamiento?
o ¿El actor necesitará ser informado sobre ciertas ocurrencias en el sistema?

Un caso de uso es un conjunto de eventos externos interdependientes y

funcionalmente relacionados. Describe una de las formas de utilización del sistema,
especifica el comportamiento de parte del sistema y es la descripción de una secuencia
de acciones, incluidas sus variaciones, que el sistema realiza para alcanzar un
resultado esperado por un actor. Se utilizan para reflejar el comportamiento deseado
del sistema que se está modelando, sin tener en cuenta la forma en que dicho
comportamiento debe implementarse. Sirven para que quien modela entienda
plenamente, qué se espera del sistema y le ayudan a validar contra el usuario final, y
experto en el sistema, que lo que entendió del sistema es correcto. Son la fuente para
generar la implementación y las pruebas que deben aplicarse. Describe una secuencia
completa, iniciada por el actor, en términos de solicitudes del actor y las respuestas del
sistema. Incluye el comportamiento habitual del sistema, ante ciertos estímulos, así
como las posibles variaciones en el mismo, las secuencias alternativas de acciones y
las secuencias para el manejo de posibles errores.

5) Frontera

Es el concepto que permite delimitar los elementos internos y externos, así como las
responsabilidades del sistema. Se representa gráficamente como el recuadro que
enmarca los casos de uso y sus relaciones.

6) Relaciones

Dentro de un diagrama de caso de uso se pueden presentar relaciones entre todos los
elementos, es decir:
 Relaciones entre Actores: Generalización

Generalización: El actor especializado hereda del actor general atributos y

secuencias de comportamiento, y puede adicionar sus propios atributos y
secuencias de acciones.

 Relaciones entre Casos de Uso: Inclusión, Extensión, Generalización

Inclusión: Este tipo de relación denota la inclusión de una secuencia determinada de

comportamiento de un Caso de uso incluido (B), dentro de la secuencia de control
del Caso de uso que lo incluye (A). Esta relación se utiliza cuando se detectan
acciones comunes a varios Caso de uso.

Extensión: Una relación de extensión, es una forma de dependencia, en la cual se

llama A al Caso de uso extendido y B al Caso de uso que extiende. El Caso de uso
B incrementa el comportamiento del Caso de uso A, adicionando secuencias de
acciones a la secuencia base. Esa adición de opciones es de carácter opcional.

Generalización: Una relación de generalización se da entre un Caso de uso

especializado y un Caso de uso más general. El Caso de uso especializado hereda
del Caso de uso general atributos y secuencias de comportamiento, y puede
adicionar sus propios atributos y secuencias de acciones. Los casos de uso
especializados son excluyentes entre sí.

 Relaciones entre Actores y Casos de Uso: Activación o Iniciación

Activación o Iniciación: Es el tipo de relación más básica que indica la invocación

desde un actor a un caso de uso o viceversa.
 Diagrama de Actividades

Un diagrama de actividades muestra un flujo de control general, representa el flujo de

trabajo paso a paso de los componentes en un sistema.

En general un diagrama de actividades muestra una serie de acciones o de tareas que

se ejecutan en cierto orden por eso motivo también son usados para elaborar Flujos de
Trabajo (Work Flow) en un sistema.

Un flujo de trabajo se puede ver una serie de tareas (Acciones) que son ejecutadas o
realizadas por ciertos actores en un orden preestablecido.

Imagenes Tomada de http://www.codecompiling.net/files/slides/UML_clase_03_UML_actividades_estados.pdf

 Diagrama de Secuencia

Los diagramas de Secuencia muestran la forma en que un grupo de objetos se

comunicación o interactúan entre sí a lo largo de un tiempo y facilita comprender la
ejecución de un proceso.

Los elementos que intervienen en un diagrama de secuencia son:

 Los objetos participando de la interacción

 La secuencia de mensajes intercambiados

 Un diagrama de secuencia contiene:

 Objetos con su línea de vida

 Mensajes intercambiados entre objetos de una secuencia ordenada

 Línea de vida activa

Objetos

Los objetos se colocan cerca de la parte superior del diagrama de izquierda a

derecha y se acomodan de manera que simplifiquen el diagrama

Mensajes

Los mensajes pueden ser simple, síncrono y asíncrono.

 Mensaje Simple: Es la transferencia de datos de un objeto a otro

 Mensaje Síncrono: Es cuando el objeto espera la respuesta a ese mensaje

antes de continuar con su trabajo

 Mensaje Asíncrono: Es cuando el objeto no espera la respuesta a ese

mensaje antes de continuar.

Líneas de Tiempo

La línea de vida o de tiempo, es representada con una línea vertical, estas expresan
el tiempo de vida del objeto. El rectángulo vertical que se puede apreciar es una
barra de activación su función es representar el tiempo de duración del mensaje
Recursividad

En ocasiones un objeto posee una operación que se invoca a sí misma. A esto le

conoce como recursividad y es una característica fundamental de varios lenguajes
de programación.

Propósitos

 Poner énfasis en el orden y momento en que se envían los mensajes a los

objetos.

 Proporcionar un camino a partir de los escenarios para describir las

operaciones en una forma más detallada.

 Mostrar la secuencia de comportamiento de un caso de uso.

Ventajas y Desventajas

 Ventajas: Facilidad para interpretar los mensajes en función de tiempo

 Desventajas: Un diagrama de secuencia demasiado largo puede presentar

problemas para entenderlo (Para personas ajenas al sistema).
 Diagrama de Clases

El diagrama de clases permite representar en un modelo una situación del mundo

real de forma figurativa formando la estructura de un sistema, es usado
especialmente en la POO (Programación orientada a objetos) ya que se utiliza
como una especie de molde o estándar que puede ser programado. Es más una
guía que permite llevar lo recopilado en el levantamiento de requisitos de un
programa a la programación.

Los elementos que intervienen en él son:

1) Las clases: estas son el molde, plantilla de los objetos del mundo real, a su vez
la componen los atributos y los métodos. Las clases sirven para adaptar a los
objetos ya que básicamente es la recopilación de las características genéricas
que compone a los mismos. Es como el molde de una paleta, la clase puede
llamarse Paleta y define que tiene rasgos como la forma, el color, el sabor etc,
pero el objeto en sí tiene otras características, aunque la clase Paleta de cierta
forma agrupa estas características, no determina cómo será el objeto, por ella,
pasa un objeto “paleta 1” que es amarilla, sabe a banano y es de forma de
corazón, otro que es rosada, sabe a fresa y parece un rectángulo o inclusive
están las de mango que contienen trozos de la fruta.

2) Atributos: son las características o rasgos generales de una clase.

3) Métodos o comportamientos: son en sí las acciones, operaciones que realizan

los objetos descritos por la clase.

Para centrar un poco las definiciones dadas, daremos un ejemplo, quizás es el más
básico: si tenemos una clase llamada Persona, los atributos de ésta podrían ser:
nombre, identificación, fecha de nacimiento, sexo y en métodos podría ser
CalcularEdad(). En el diagrama por ser un modelo, representa todo de forma
general, es decir, si vamos a un objeto para esta clase podríamos decir que se trata
de Elizabeth Restrepo, 1.035.867.603, 04/03/94, F y en los métodos podría ser que
CalcularEdad() arroje 22. Pero Elizabeth no se verá en el diagrama, si no en una BD
o en el programa como tal.

4) Relaciones: son otro componente, son la forma en cómo se relacionan las clases
y bien puede ser: de agregación, herencia entre otras. Puedes decir si entre dos
clases hay una relación de uno a muchos como por ejemplo la relación entre las
clases “Tienda de videojuegos” y “Videojuegos” cada uno puede ser diferente,
pero podríamos decir que una tienda de videojuegos contiene muchos
videojuegos, en el momento de programar, estas relaciones cobran mucho
 sentido y permiten ver un pre- modelado del diagrama que tendría la Base de
datos, sin embargo, se debe tener presente que no son lo mismo ya que no
cumplen la misma función. Otra de las relaciones interesantes es por ejemplo la
de herencia o generalización, la manera más sencilla de entender es que si
tienes una clase general como Vehículo (super clase), puedes tener otras clases
(subclases) que le hereden sus atributos y métodos como Motocicleta,
Camiones, Aviones; estas últimas 3 clases podrán usar los atributos y métodos
de la superclase y podrán tener sus propios atributos y métodos.

El diagrama de clases determina las relaciones entre las clases, e inclusive distintos
programas para modelarlo, dan la opción para decir que tipo de variables son los
atributos y si tiene límite de ingreso, además que tipo de información arroja el
método, si un número o una cadena o un boolean etc, o si no arroja solo una
información (void).
 Diagrama de Despliegue

El Diagrama de despliegue representa a los nodos y sus relaciones, donde se

muestra de manera estructurada la arquitectura del sistema que, unidos, proveen la
vista de implementación del mismo en él también se describe la topología del
sistema la estructura de los elementos de hardware y el software que ejecuta cada
uno de ellos. Los nodos son conectados por asociaciones de comunicación tales
como enlaces de red, conexiones TCP/IP.

Componentes

 Nodo: es un elemento de hardware o software, es un objeto físico en tiempo de

ejecución que representa un recurso computacional, generalmente con memoria
y capacidad de procesamiento.

 Instancia de nodo: puede o no tener un nombre antes de los dos puntos. Se

puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y
tiene dos puntos antes del tipo de nodo base.

 Estereotipo de nodo: es la manera de poder verificar que tipo de nodo es el que

se está observando. Son cosas u objetos q se repiten sin variación.

 Artefactos: representan un producto concreto en el mundo físico que son el

resultado de un proceso de desarrollo de software, que puede incluir los
modelos del proceso (modelos de Caso de uso, modelos de Diseño, etc.),
archivos ejecutables, bibliotecas, esquemas de bases de datos, archivos de
configuración, archivos fuente, documentos de diseño, reportes de prueba,
prototipos, manuales de usuario etc. Donde un artefacto es un conjunto de
componentes.

 Asociación: representa una ruta de comunicación entre los nodos. Donde esta
asociación va incluida con misma dependencia del diagrama de componentes.

Los diagramas de despliegue pueden describir la arquitectura a nivel de

especificación (también llamado nivel de tipo) o al nivel de instancia (de manera
similar a los diagramas de clases y diagramas de objetos).

 A nivel de especificación muestran una visión general del despliegue de los

artefactos hacia los destinos de despliegue, sin hacer referencia a casos
concretos de artefactos o nodos.
 A nivel de instancia muestran el despliegue de instancias de artefactos en
instancias específicas de los destinos de despliegue. Se pueden utilizar por
ejemplo para mostrar las diferencias existentes en nombres/identificaciones en
ambientes de despliegue a desarrollo, de "staging" o de producción, entre
construcciones específicas o servidores de despliegue o dispositivos.

Imagen Tomada de https://www.ecured.cu/Archivo:Diagrmad.jpg

 CONCLUSIONES

 Los diagramas expuestos sólo son acertados si la información recolectada en el

levantamiento de requisitos, es funcional, procedimental, verídica y clara.

 Es importante identificar en la información suministrada o en el entorno de la

situación o proceso a diagramar, los componentes que forman el diagrama, tales
como ¿quiénes actúan en ese entorno?, ¿qué relaciones se manejan? ¿con qué
o entre quienes?, etc.

 Algunos diagramas dependen de otros, por lo que es necesario la realización de

éstos para poder tener una secuencia lógica que abarque la realidad modelada
del caso propuesto.

 No es pertinente confundir un diagrama de clases y un modelo de base de

datos, dado a que tienen distintas funciones y en la programación orientada a
objetos, se usan en niveles diferentes.

 El lenguaje unificado de modelado UML es una de las principales herramientas

para el análisis y diseño de sistemas de información, permite plasmar en
términos técnicos y fácilmente entendibles por los encargados de la
programación todas las ideas que se han recopilado en la fase de
requerimientos las cuales han sido expresadas por el cliente.

 Los Diagramas permiten plasmar desde diferentes perspectivas la funcionalidad

de un producto a través de casos de uso donde se especifica lo que piensa el
cliente en términos del que él programador puede entenderlo a través de los
diagramas de transición de estados que muestran como varia la información en
el sistema, entre otros diagramas.
 REFERENCIAS BIBLIOGRÁFICAS

Bohorquez, L. (2012). Conceptualización de Objetos y Clases. [Página Web].

Recuperado de:
http://ova.ufps.edu.co/drupal/files/OA12clases_objetos/index.html

Ecured. (s/f). Diagrama de Despliegue. Recuperado de

https://www.ecured.cu/Diagrama_de_despliegue

Ferreira, N. (2016). Introducción A Lenguaje De Modelado Unificado. [Página Web].

Recuperado de: http://hdl.handle.net/10596/9839

Gómez, V. (2016). Diagrama de clases. Recuperado de:

http://instintobinario.com/diagrama-de-clases/

Introduction To OMG's Unified Modeling Language™ (UML®) http://www.uml.org/what-

is-uml.htm

Lenguaje unificado de modelado. (s/f). Recuperado de

https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado

Modelo de clases. (s/f) Recuperado de

http://users.dcc.uchile.cl/~psalinas/uml/modelo.html

Miguel Angel Quintana, Lewis Caraballo (2013). Diagramas de Secuencia. [Pagina

Web]. Recuperado de: http://es.slideshare.net/still01/diagramas-de-secuencia-
16815274

Una ontología para la representación de conceptos de diseño de software. (2017).

Recuperado el 16 Febrero de 2017, de
http://www.bdigital.unal.edu.co/25046/1/22291-106826-1-PB.pdf

Visión General de los Diagramas de Despliegue. (s/f). Recuperado el 16 Febrero de

2017 de http://umldiagramadespliegue.blogspot.com.co/