Desarrollo Taller #4 UML Oscar Enrique Quiroga Contreras

Desarrollo taller UML
DESARROLLO TALLER #4
UML
OSCAR ENRIQUE QUIROGA CONTRERAS
SENA
CENTRO DE MARIALES Y ENSAYOS
PROGRAMACION SOFTWARE
BOGOTÁ
2019
3.1 REFLEXIÓN INICIAL.

¿Para qué sirven, cuando se emplean como se emplean, en qué casos debemos tener en
cuenta los casos de uso?
R: Los diagramas de casos de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interacción con los usuarios y/o 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.
¿Los casos de uso, sus especificaciones y el diagrama de casos de uso de un sistema
permiten acordar, entre el equipo de desarrollo y el cliente, los límites y los requisitos
funcionales de dicho sistema?
R: Si porque tanto el cliente como el equipo de desarrollo pueden tener sus funciones
específicas y se ven mostradas en el diagrama de casos de uso.
¿El diagrama de casos de uso de un sistema puede organizarse por medio de relaciones que
se pueden dar entre los diferentes casos de uso
R: Si se puede organizar funciones que se compartan entre los actores en el diagrama de
casos de uso.
¿Los actores de un sistema representan, en particular, personas (más precisamente roles que
interpretan personas), dispositivos u otros sistemas, y en general, cualquier cosa que
interactúa con dicho sistema?
R: Si un actor puede ser un sistema, un usuario particular o administrador etc y se muestra
como interactúa cada uno en el diagrama.
3.2 CONTEXTUALIZACIÓN E IDENTIFICACIÓN DE CONOCIMIENTOS
. Estimado aprendiz antes de iniciar el desarrollo de las actividades propuestas en este taller
es importante determinar:
¿Qué es UML?
- Es un Lenguaje Unificado de Modelado y se trata de un estándar que se ha adoptado
a nivel internacional por numerosos organismos y empresas para crear esquemas,
diagramas y documentación relativa a los desarrollos de software.
¿Qué es un caso de uso?
- Los diagramas de casos de uso sirven para especificar la funcionalidad y el
comportamiento de un sistema mediante su interacción con los usuarios y/o 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.
¿Cuáles son los elementos que constituyen un caso de uso?
¿Cuáles son los criterios que se deben tener en cuenta para la elaboración de un caso de
uso y el diagrama de caso de uso?
- Tener claro los actores que vamos a utilizar Conjunto de secuencias de acciones y
cada una de sus funciones sean individuales o compartidas o que dependan uno del
otro.
¿Cómo se relacionan los casos de uso?
- Comunicación: Relación (asociación) entre un actor y un caso de uso. El estereotipo
de la relación de comunicación es: <<communicate>> aunque generalmente no se
estipula ningún nombre
- Inclusión: Un caso de uso base incorpora explícitamente el comportamiento de otro
en algún lugar de su secuencia. La relación de inclusión sirve para enriquecer un
caso de uso con otro y compartir una funcionalidad común entre varios casos de
uso, también puede utilizarse para estructurar un caso de uso describiendo sus
subfunciones. El caso de uso incluido existe únicamente con ese propósito, ya que
no responde a un objetivo de un actor.
- Extensión: Un caso de uso base incorpora implícitamente el comportamiento de otro
caso de uso en el lugar especificado indirectamente por este otro caso de uso. En el
caso de uso base, la extensión se hace en una serie de puntos concretos y previstos
en el momento del diseño, llamados puntos de extensión, los cuáles no son parte del
flujo principal. La relación de extensión sirve para modelar: la parte opcional del
sistema, un subflujo que sólo se ejecuta bajo ciertas condiciones o varios flujos que
se pueden insertar en un punto determinado. Este tipo de relación produce confusión
y no debería utilizarse en exceso. Conviene su uso sólo para insertar un nuevo
comportamiento no previsto en un caso de uso existente. Estas relaciones se
representan mediante una flecha discontinua con el estereotipo <<extend>>.
- Especialización y generalización de los casos de uso: Un caso de uso (subcaso)

hereda el comportamiento y significado de otro, es decir las relaciones de
comunicación, inclusión y extensión del super-caso de uso. En muchas ocasiones
este super-caso de uso es abstracto y corresponde a un comportamiento parcial
completado en el subcaso de uso. O dicho de otra manera, Los casos de uso “hijo”
son una especialización del caso de uso “padre”. En la medida de lo posible debería
evitarse puesto que produce cierta confusión en algunas ocasiones.
3.3 Actividades de apropiación.
1. Como se llama la entidad que inicia el caso de uso?
- La entidad que inicia el caso de uso se llama Actor(es), el actor es un rol que un
usuario juega con respecto al sistema.
2. Qué se entiende con "Incluir" un caso de uso?
- Se denomina Include en los casos de uso y aparecen como funcionalidad común,

luego de haber especificado varios casos de uso, éste caso de uso es usado siempre
que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones,
que son opcionales.
3. Qué se entiende con “Extender" un caso de uso?
- Representa una parte de la funcionalidad del caso que no siempre ocurre y son un
caso de uso en sí mismas. Se denomina Extends.
4. Los casos de uso pueden ayudarle a analizar un negocio y un sistema. Imagine a una
gran tienda de equipos de cómputo que vende Hardware, periféricos y software.
¿Quiénes serían los actores?
- Actores: Los actores que se identifican en una tienda que vende equipos de
cómputo, hardware, software y periféricos son: El vendedor, el administrador y el
cliente.
- Vendedor: El vendedor podrá hacer las siguientes tareas: * Atraer compradores de
productos. * Ofrecer productos existentes * Exponer características técnicas de los
productos. * Ingresar al sistema. * Generar factura de compra * Recibir dinero de
compra * Devolver vueltas por compra.
- Administrador: * Ingresar al sistema * Generar reportes de ventas * Generar reporte
de productos faltantes. * Realizar inventario mensual * Administrar dinero de
ventas y compras. * Administrar dinero para pagos de empleados. * Administrar
garantías. Cliente: * Ver productos ofrecidos * Comparar productos * Comprar
producto * Pagar por compra * Recibir producto * Recibir Factura.
¿Cuáles serían algunos de los escenarios dentro de cada caso de uso?

* Sistema de venta de productos de Hardware y Software
* Sistema de administración de ventas

* Sistema de compras para almacén de Hardware y Software * Sistema de garantías de
Hardware y software.
3.3 Actividades de apropiación.
5. Cree un caso de uso relacionado con cualquier situación de la vida real.
3.4 TRANSFERENCIA DEL CONOCIMIENTO.
1. Realizar individualmente una lectura al siguiente material bibliográfico: UML gota a

gota de Fowler, Martin editorial Pearson. UML Desarrollo OO Xavier Ferré Grau,
Isabel Sánchez y el libro UML en 24 horas. Este material lo encontraran en la
plataforma Blackboard en el material de apoyo referente al tema.
2. Leer y analizar la información que se encuentra relacionada a continuación.
3.5 Actividades de Evaluación. En el restaurante “MAMAMIA” se realizan los

siguientes procesos para atender a los clientes: Cuando el cliente ingresa la propietaria
le da la bienvenida y recibe las prendas y los objetos de los clientes. Los clientes son
atendidos por meseros los cuales le van a indicar una mesa disponible. El mesero
entregara a los clientes la carta con el menú del día. Los clientes deben seleccionar el
menú de su predilección. El mesero recoge la carta con el menú seleccionado y se dirige
hacia la cocina, en donde entregará la lista con el menú seleccionado. La cocinera
servirá el menú seleccionado.
El mesero le hará llegar el menú preparado a los clientes que le solicitaron. Los clientes
después de disfrutar el menú elegido llamaran al mesero para solicitarle la cuenta.
Finalmente los clientes se retiran del restaurante “mamamia“recogiendo sus prendas y

objetos que serán entregados por la propietaria. Proponer los diagramas de uso, clases y
secuencia del anterior ejercicio.
Diagrama casos de uso
Diagrama de clases
Diagrama de secuencia
Realizar el análisis de casos de uso para los siguientes casos:
Sistema Registro Usuario

Sistema Modificar Usuario
Sistema Consultar Usuario
Sistema Registro de Administrador
Sistema Validación Usuario
Sistema de registro de usuarios

- El usuario registra en sistema usando un login y una contraseña

-Respuesta del sistema
-Los datos han ingresado correctamente
-Los datos han sido guardado en la base de datos
-Los datos ingresados son coherentes
-El dato ingresado ha sido modificado
-El registro ha sido creado correctamente
Sistema modificar usuario
- El usuario ingresa con el login y contraseña para sustituir los datos existentes en el
sistema.
- Acciones del actor
-ingresar con login y contraseña
-ingresar en base de datos
-Verificar Datos
-Modificar Datos
- -Crear registro
- Respuesta del sistema
-login correcto
-Datos introducidos son correctos

-Los datos indicaran cambios
-Los datos han sufrido cambios
-Los datos han sido guardado correctamente
Sistema Consultar Usuario
- El administrador consulta base de datos los datos correspondientes al usuario,

realiza pruebas de autenticación y informa al usuario
-El administrador accede por base de datos al registro del usuario
-El administrador verifica que los datos del usuario sean correctos
-El administrador informa al usuario el login y contraseña
-El usuario entra el sistema con el login y contraseña

o el sistema genera nombres y apellidos de los usuarios registrados
o El sistema expone el nombre del usuario y los datos cargados en el registro
o Informa en pantalla el login
o El sistema valida login y contraseña ingresados por el usuario.
Sistema registro de administrador
- El root introduce datos para registrar el administrador en la base de datos, después

el root asigna los permisos de administrador y notifica al administrador

o Ingresar datos
o Registra datos en la base de datos
o Asignar permisos
o Guardar Configuraciones
o Informar al administrador
Los datos fueron introducidos correctamente
o Los datos han sido registrados
o Los permisos de administrador han sido establecidos
o El registro se ha guardado correctamente
o Se informa al administrador
Sistema validación de usuario
- El usuario introduce datos al sistema, el sistema confronta los datos con la base de
datos y después valida datos
- Ingresar login y contraseña

- Confirmar datos en base de datos
- Validar Información
-Los datos del usuario fueron ingresaron correctamente

-Los datos introducidos por el usuario son correctos
-Validando información
Elaborar el diagrama de Clase del Enunciado 1 (la cadena de videoclubs)
Elaborar los diagramas de Clase del Sistema Propuesto en grupo, para el Proyecto que está
desarrollando en formación.
Responder los siguientes cuestionamientos:

¿En un objeto cómo o con qué elemento se representa su estado?
R: Se representa en un rectángulo con tres compartimientos. En el primero va el nombre del

objeto, en el segundo sus atributos y en el tercero sus operaciones. Este último puede ser
omitido si así se prefiere.
¿Qué es el estado pasivo de un objeto?
R: Es aquel en el que el objeto analizado simplemente espera a que algo ocurra en el

entorno para pasar a un nuevo estado. Un ejemplo es con el reproductor de MP3, este está
en “pausa” hasta que el usuario le indique que continúe reproduciendo la música o se
detenga totalmente.
¿Cuándo se presenta el estado activo de un objeto y qué valores puede adoptar?
R: Un estado está activo cuando se alcanza mediante una transición y se convierte en

inactivo cuando se abandona a través de una transición.
¿Qué es un suceso, en qué ocasiones se presenta y cómo afecta un suceso al sistema?
R: Los sucesos son los detalles que podemos colocar en las líneas de transición entre
estados dentro de nuestro UML, donde el suceso es lo que desencadena o provoca una
transición, Puede afectar cuando un objeto que envía un suceso a otro objeto puede esperar
una respuesta, pero la respuesta es otro suceso distinto, bajo el control del segundo objeto,
que puede decidir si lo envía o no lo envía. Por ejemplo: "el usuario pulsa el botón
izquierdo", "el vuelo 555 sale para San Andres".
¿A qué se llama transición del objeto?

R: Una transición es una relación entre dos estados; que indica cuando ocurre un evento el
objeto pasa de un estado anterior al siguiente y se representa por una flecha
Transición Simple: Una transición simple es una relación entre dos estados que indica que
un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones,
cuando un evento ocurre y si ciertas condiciones son satisfechas.
Transición interna: Es una transición que permanece en el mismo estado, en vez de
involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se
denota como una cadena adicional en el compartimiento de acciones del estado.
Transacción Compleja: Una transición compleja relaciona tres o más estados en una
transición de múltiples fuentes y/o múltiples destinos.
¿Cuál es el símbolo que se utiliza para representar el Estado Inicial de un Objeto?
R: Un punto grande en el diagrama apuntando con una transición a un estado lo que indica
es el estado en el que nace el objeto, es decir, el estado inicial. Y al modelar los estados de
un objeto nos podemos encontrar con que puede tener desde cero hasta N estados finales
diferentes.
¿Cuál es el símbolo que se utiliza para representar el Estado Final de un Objeto?
R: El estado final es el último estado en el que queda un objeto antes de desaparecer, o

cuando deja de tener más comportamiento. Los objetos que se mantienen siempre activos
regresan una y otra vez a estados anteriores, por eso no tienen un estado final. En cambio,
hay objetos que pueden terminar su vida de diferentes maneras; en diferentes estados. El
símbolo de estado final se muestra con un cirulo relleno con un aro a su alrededor.
¿Con qué símbolo se representa el estado transaccional de un objeto y en qué situaciones

se presenta dicho estado?
Una transición es una relación entre dos estados que indica que un objeto que esté en el
primer estado realizará ciertas acciones y entrará en el segundo estado cuando ocurra un
evento especificado y se satisfagan unas condiciones especificadas y se representa por una
flecha y se representa con un cuadro estilo nube de texto.
Realizar una consulta detallada acerca de los siguientes diagramas y luego implementar los
que considere pertinentes a su proyecto dependiendo la necesidad
DIAGRAMA DE COLABORACIÓN
El diagrama de colaboración es un tipo de diagrama de interacción cuyo objetivo es

describir el comportamiento dinámico del sistema de información mostrando cómo
interactúan los objetos entre sí, es decir, con qué otros objetos tiene vínculos o intercambia
mensajes un determinado objeto.
Descripción
Un diagrama de colaboración muestra la misma información que un diagrama de secuencia

pero de forma diferente. En los diagramas de colaboración no existe una secuencia
temporal en el eje vertical; es decir, la colocación de los mensajes en el diagrama no indica
cuál es el orden en el que se suceden. Además, la colocación de los objetos es más flexible
y permite mostrar de forma más clara cuáles son las colaboraciones entre ellos. En estos
diagramas la comunicación entre objetos se denomina vínculo o enlace (link) y estará
particularizada mediante los mensajes que intercambian.
Notación
Objeto
Un objeto se representa con un rectángulo dentro del que se incluye el nombre del objeto y,
si se desea, el nombre de la clase, separando ambos por dos puntos.
Vínculo
En el diagrama, un vínculo se representa como una línea continua que une ambos objetos y
que puede tener uno o varios mensajes asociados en ambas direcciones. Como un vínculo
instancia una relación de asociación entre clases, también se puede indicar la navegabilidad
del mismo mediante una flecha.
Mensaje
Un mensaje se representa con una pequeña flecha colocada junto a la línea del vínculo al
que está asociado. La dirección de la flecha va del objeto emisor del mensaje al receptor del
mismo. Junto a ella, se coloca el nombre del mensaje y sus argumentos.
A diferencia de los diagramas de secuencia, en los diagramas de colaboración siempre se

muestra el número de secuencia del mensaje delante de su nombre, ya que no hay otra
forma de conocer la secuencia de los mismos.
Además, los mensajes pueden tener asociadas condiciones e iteraciones que se

representarán como en los diagramas de secuencia.
DIAGRAMA DE COMPONENTES
El diagrama de componentes proporciona una visión física de la construcción del sistema

de información. Muestra la organización de los componentes software, sus interfaces y las
dependencias entre ellos.
Descripción
Como ya se ha indicado, los elementos de estos diagramas son los componentes software y
las dependencias entre ellos.
Un componente es un módulo de software que puede ser código fuente, código binario, un
ejecutable, o una librería con una interfaz definida. Una interfaz establece las operaciones
externas de un componente, las cuales determinan una parte del comportamiento del
mismo. Además se representan las dependencias entre componentes o entre un componente
y la interfaz de otro, es decir uno de ellos usa los servicios o facilidades del otro.
Estos diagramas pueden incluir paquetes que permiten organizar la construcción del
sistema de información en subsistemas y que recogen aspectos prácticos relacionados con
la secuencia de compilación entre componentes, la agrupación de elementos en librerías,
etc.
Notación
Componente
Un componente se representa como un rectángulo, con dos pequeños rectángulos

superpuestos perpendicularmente en el lado izquierdo.
Para distinguir distintos tipos de componentes se les puede asignar un estereotipo, cuyo
nombre estará dentro del símbolo: << ... >>
Interfaz
Se representa como un pequeño círculo situado junto al componente que lo implementa y

unido a él por una línea continua. La interfaz puede tener un nombre que se escribe junto al
círculo. Un componente puede proporcionar más de una interfaz.
Paquete
Un paquete se representa con un icono de carpeta (ver Diagrama de Paquetes).
Relación de dependencia
Una relación de dependencia se representa mediante una línea discontinua con una flecha
que apunta al componente o interfaz que provee del servicio o facilidad al otro. La relación
puede tener un estereotipo que se coloca junto a la línea, entre el símbolo: <<...>>
Ejemplo
Sistema encargado de la gestión de los préstamos y reservas de libros y revistas en una

biblioteca. El lenguaje de desarrollo será Java, y los accesos a la información del prestatario
serán mediante un paquete de Base de Datos.
DIAGRAMA DE COMUNICACIÓN
En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es una
versión simplificada del diagrama de colaboración de la versión de UML 1.x.[cita requerida]
Un diagrama de comunicació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
usodescribiendo tanto la estructura estática como el comportamiento dinámico de un
sistema.
Los diagramas de comunicación y de secuencia describen información similar, y con ciertas
transformaciones, pueden ser transformados unos en otros sin dificultad.
Para mantener el orden de los mensajes en un diagrama de comunicación, los mensajes son
etiquetados con un número cronológico y colocados cerca del enlace por el cual se desplaza
el mensaje. Leer un diagrama de comunicación conlleva comenzar en el mensaje 1.0, y
seguir los mensajes desde un objeto hasta el siguiente, sucesivamente.
DIAGRAMA DE DESPLIEGUE
Definición
Los diagramas de despliegue son los complementos de los diagramas de componentes que,
unidos, proveen la vista de implementación del sistema. Describen la topología del sistema
la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.Los
diagramas de despliegue representan a los nodos y sus relaciones. Los nodos son
conectados por asociaciones de comunicación tales como enlaces de red,
conexiones TCP/IP.
De que se trata
Los diagramas de despliegue muestran la configuración en funcionamiento del sistema

incluyendo su software y su hardware. Para cada componente de un diagrama es necesario
que se deba documentar las características técnicas requeridas, el tráfico de la red, el tiempo
de respuesta.
Usos
 Sistemas empotrados: Un sistema empotrado es una colección de hardware con una

gran cantidad de software que interactúa con el mundo físico.
 Sistemas cliente-servidor: Los sistemas Cliente-Servidor son un extremo del
espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad
de red de los clientes a los servidores y sobre la distribución física de los componentes
software del sistema a través de nodos.
 Sistemas completamente distribuidos: En el otro extremo se encuentra aquellos
sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen
varios niveles de servidores.
Ventajas
 Muestra un conjunto de nodos y sus relaciones.

 Se utilizan para describir la vista de despliegue estática de un sistema.
 Se relacionan con los diagramas de componentes, ya que un nodo normalmente
incluye uno o más componentes.
Desventajas
 La posible falla en la modelación de un hardware.

 Tales sistemas contienen a menudo varias versiones de componentes software,
alguno de los cuales pueden incluso migrar de un nodo a otro.El diseño de tales
sistemas requiere tomar decisiones que permitan un cambio continuo de la topología
del sistema.
Componentes
Nodo
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso

computacional, generalmente con memoria y capacidad de procesamiento.Un Nodo es un
elemento de hardware o software.
Instancia de nodo
Una instancia 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. Una instancia puede o no tener un
nombre antes de los dos puntos.
Estereotipo de nodo
Estereotipo, son cosas u objetos q se repiten sin variación.El estereotipo de un nodo es la

manera de poder verificar que tipo de nodo es el que se esta observando.
Artefactos
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los
modelos del proceso (modelos de Caso de uso, modelos de Diseño, etc.), archivos fuente,
ejecutables, documentos de diseño, reportes de prueba, prototipos, manuales de usuario etc.
Donde un artefacto es un conjunto de componentes.
Asociación
Una asociación representa una ruta de comunicación entre los nodos. Donde esta asociación
va incluida con misma dependencia del diagrama de componentes.
Estándares
 Executable: especifica un artefacto que se puede ejecutar en un nodo.

 Library: Biblioteca de objetos estática o dinámica.
 File: artefacto que representa un documento que contiene condigo fuente o datos.
 Document: artefacto que representa un documentos.
Antecedentes
Diagrama de Componentes: permiten modelar sistemas de software de cualquier tamaño y

complejidad. Permite especificar un componente como unidad modular con interfaces bien
definidas.
Diagrama de Paquetes: más que un diagrama constituyen una herramienta para mostrar los
elementos que se integran en un sistema, aplicación o módulos. Muestra como el sistema
esta dividido en agrupaciones lógicas mostrando las dependencias entre agrupaciones.
DIAGRAMA DE ESTRUCTURA COMPUESTA

Un diagrama de estructura es un tipo de diagrama en el Lenguaje de Modelado
Unificado (UML), que muestra la estructura interna de una clase y las colaboraciones que
esta estructura hace posibles. Esto puede incluir partes internas, puertas mediante las
cuales, las partes interactúan con cada una de las otras o mediante las cuales, instancias de
la clase interactúan con las partes y con el mundo exterior, y conectores entre partes o
puertas. 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.
Conceptos de estructura compuesta

Las entidades de estructura compuesta claves identificadas en la especificación UML 2.0
son: clasificadores estructurados, partes, puertas, conectores, y colaboraciones.
Parte
Una parte representa un rol jugado en tiempo de ejecución por una instancia de una clase o
por una colección de instancias. La parte puede nombrar solamente un rol,
una superclase abstracta, o puede nombrar una clase concreta específica. La parte puede
incluir un factor de multiplicidad (cardinalidad), tal como el [0..*] mostrado para Viewer en
el diagrama.
Puerta
Una puerta es un punto de interacción que puede ser usado para conectar clasificadores
estructurados con sus partes y con el ambiente. Las puertas pueden opcionalmente
especificar los servicios que proveen y los servicios que requieren de otras partes del
sistema. En el diagrama, cada uno de los cuadrados pequeños es una puerta. Cada puerta
tiene un tipo y esta etiquetado con un nombre, tal como "var", "indVar1", o "view" en el
diagrama. Las puertas pueden contener un factor de multiplicidad, por ejemplo [3].
Las puertas pueden ya sea delegar los requerimientos recibidos a partes internas, o pueden
entregarlos directamente para el comportamiento del clasificador estructurado en el que la
puerta está contenido. Las puertas públicas, que son visibles en el ambiente, son mostradas
sobre el borde de la parte, mientras que las puertas protegidas, que no son visibles en el
ambiente, son mostradas en el borde interno de la parte. Todas las puertas en el diagrama
son públicas, excepto por la puerta view a lo largo del borde derecho de FibonacciSystem.
Conector
Un conector une dos o más entidades, permitiéndoles interactuar en tiempo de ejecución.
Un conector es representado por una línea que une una combinación de partes, puertas
y clasificadores estructurados. El diagrama muestra tres conectores entre puertas, y un
conector entre un clasificador estructurado y una parte.
Colaboración
Una colaboración es generalmente más abstracta que un clasificador estructurado. Ésta es
mostrada como un óvalo sin relleno conteniendo los roles que las instancias pueden jugar
en la colaboración.
Clasificador estructurado
Un ClasificadorEstructurado representa una clase, frecuentemente una clase abstracta, cuyo
comportamiento puede ser completa o parcialmente descrito mediante interacciones entre
partes.
Un ClasificadorEncapsulado es un tipo de clasificador estructurado que contiene puertas.
En el diagrama abajo, ambos FibonacciSystem y Variable son clasificadores encapsulados,
porque ambos tienen puertas a lo largo de sus límites.
Ejemplo de diagrama de estructura compuesta

Como ejemplo, considere un modo posible de modelar la producción de la Sucesión de
Fibonacci.
Este diagrama de estructura compuesta UML 2.0 especifica que las instancias de la clase
'FibonacciSystem' están compuestas de varias partes. La superior de estas partes está
identificada como teniendo el clasificador 'FibonacciFunction'. Tres de las partes son
identificadas por el rol que ellas juegan dentro de instancias del FibonacciSystem – el
rol NMinus2, el rol NMinus1, y el rol N. La quinta parte, identificada por su
clasificador Viewer, incluye una especificación de multiplicidad. En tiempo de ejecución
puede haber 0 o más instancias de Viewer o de alguna subclase concreta de Viewer.
En tiempo de ejecución las instancias de clase que implementan estos tres roles deben
proveer los servicios especificados por la interfaz IVarmediante sus puertas var. Una de
tales clases es Variable, mostrada sobre el diagrama con una puerta llamada var de
tipo Var que realiza la interfaz IVar.
La puerta llamada "view" es una puerta no-pública que puede ser usada por una instancia
de FibonacciSystem para acceder a la(s) instancia(s) opcional(es) de Viewer.
f
DIAGRAMA DE FLUJO
¿Qué es un diagrama de flujo?
Un diagrama de flujo es un diagrama que describe un proceso, sistema o algoritmo

informático. Se usan ampliamente en numerosos campos para documentar, estudiar,
planificar, mejorar y comunicar procesos que suelen ser complejos en diagramas claros y
fáciles de comprender. Los diagramas de flujo emplean rectángulos, óvalos, diamantes y
otras numerosas figuras para definir el tipo de paso, junto con flechas conectoras que
establecen el flujo y la secuencia. Pueden variar desde diagramas simples y dibujados a
mano hasta diagramas exhaustivos creados por computadora que describen múltiples pasos
y rutas. Si tomamos en cuenta todas las diversas figuras de los diagramas de flujo, son uno
de los diagramas más comunes del mundo, usados por personas con y sin conocimiento
técnico en una variedad de campos. Los diagramas de flujo a veces se denominan con
nombres más especializados, como "diagrama de flujo de procesos", "mapa de procesos",
"diagrama de flujo funcional", "mapa de procesos de negocios", "notación y modelado de
procesos de negocio (BPMN)" o "diagrama de flujo de procesos (PFD)". Están
relacionados con otros diagramas populares, como los diagramas de flujo de datos (DFD) y
los diagramas de actividad de lenguaje unificado de modelado (UML).
omo una representación visual del flujo de datos, los diagramas de flujo son útiles para
escribir un programa o algoritmo y explicárselo a otros o colaborar con otros en el mismo.
Puedes usar un diagrama de flujo para explicar detalladamente la lógica detrás de un
programa antes de empezar a codificar el proceso automatizado. Puede ayudar a
organizar una perspectiva general y ofrecer una guía cuando llega el momento de codificar.
Más específicamente, los diagramas de flujo pueden:
 Demostrar cómo el código está organizado.

 Visualizar la ejecución de un código dentro de un programa.

 Mostrar la estructura de un sitio web o aplicación.
 Comprender cómo los usuarios navegan por un sitio web o programa.
A menudo, los programadores pueden escribir un pseudocódigo, una combinación de

lenguaje natural y lenguaje informático que puede ser leído por personas. Esto puede
permitir más detalle que el diagrama de flujo y servir como reemplazo del diagrama de
flujo o como el próximo paso del código mismo.
Los diagramas relacionados que se emplean en el software informático incluyen:
 Lenguaje unificado de modelado (UML): este es el lenguaje de propósito general

usado en la ingeniería de software para el modelado.
 Diagramas Nassi-Shneiderman (NSD): usados para la programación informática
estructurada. Llevan el nombre de sus creadores: Isaac Nassi y Ben Shneiderman,
quienes los desarrollaron en 1972 en la Universidad Estatal de Nueva York en
Stony Brook. También se denominan "estructogramas".
 Diagramas DRAKON: DRAKON es un lenguaje de programación visual de
algoritmos empleado para crear diagramas de flujo.
DIAGRAMA DE OBJETOS
Los diagramas de objetos de UModel representan un único ejemplo de una clase y se
utilizan para ilustrar un punto de datos en su aplicación. Cuando cree un objeto nuevo,
llamado especificación de instancia, UModel le permite asignar una clase ya existente
representada por la instancia. UModel ofrece automáticamente al objeto instancias de las
propiedades pertinentes desde la clase y el usuario puede insertar valores de muestras para
el objeto.
Los diagramas de objetos UML usan una notación similar a los diagramas de clase y se
usan para ilustrar una instancia de una clase en un momento concreto. También pueden
servir para ilustrar una clase y sus relaciones con un ejemplo de la vida real.
Los diagramas de objetos pueden ayudar a explicar clases y herencias y a menudo se usan
al diseñar clases o como apoyo ilustrativo para las partes interesadas no técnicas, que a
veces encuentran los diagramas de clases demasiado abstractos.
Como la notación es muy similar a la de los diagramas de clases, la dos barras de

herramientas comparten varios iconos. Puede editar los atributos y valores de un objeto con
la barra de herramientas directamente en el diagrama o usando el cuadro de diálogo
"Propiedades".
DIAGRAMA DE PAQUETES
Un diagrama de paquetes en el Lenguaje Unificado de Modeladorepresenta las
dependencias entre los paquetes que componen un modelo. Es decir, muestra cómo un
sistema está dividido en agrupaciones lógicas y 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 paquetes están normalmente organizados para maximizar la coherencia interna dentro
de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas
maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede
asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el
orden de desarrollo requerido.
Relaciones entre paquetes

Entre paquetes pueden existir relaciones de dependencia y generalización.
Las dependencias entre paquetes denotan que algún elemento de un paquete depende de los
elementos en otro paquete. Existen diferentes tipos de relaciones de dependencia entre
paquetes:
 Importación: Modelado como una dependencia estereotipada con <<import>>.

 Acceso: Modelado como una dependencia estereotipada con <<access>>.
 Combinación: Modelado como una dependencia estereotipada con <<merge>>.
 Exportación: Modelado implícitamente a través de la visibilidad pública en los
elementos del paquete. No se exporta explícitamente a algún paquete.
La importación de paquetes o import se define como "una relación entre un espacio de
nombres de importación y un paquete, lo que indica que el espacio de nombres importador
agrega los nombres de los miembros del paquete a su propio espacio de nombres".1 Por
defecto, una dependencia entre dos paquetes sin etiqueta se interpreta como una relación de
este tipo.
Tanto la importación de paquetes como el acceso de paquetes indican que el paquete
origen, paquete fuente o paquete importador, tiene acceso al contenido del paquete destino,
es decir, el contenido público del destino se añade al espacio de nombres del origen. La
diferencia radica en que la importación de paquetes añade los elementos públicos del
paquete destino al espacio de nombres público del origen, mientras que el acceso de
paquetes añade los elementos públicos del destino al espacio de nombres privado del
origen. Ambas relaciones son transitivas.
Una relación de combinación o fusión entre paquetes especifica que el contenido del
paquete origen (receptor) se extiende con el contenido del paquete destino. La combinación
de paquetes o merge se define como "una relación dirigida entre dos paquetes, que indica
que el contenido de los dos paquetes se va a combinar. Es muy similar a la generalización
en el sentido de que el elemento fuente añade conceptualmente las características del
elemento destino para sus propias características lo que resulta en un elemento que combina
las características de ambos".2 En esta relación, si existe un elemento tanto en el paquete
fuente y el paquete de destino, después la definición del elemento de origen se ampliará
para incluir la definición del elemento de destino.
Una generalización es una relación entre un clasificador más general (superclase) y un
clasificador más específico (subclase). Cada instancia del clasificador específico es también
una instancia indirecta del clasificador general. La generalización entre paquetes es similar
a la generalización entre clases, los paquetes hijos heredan los elementos del paquete padre.
La generalización entre paquetes suele utilizarse para especificar familias de paquetes.
Elementos básicos
 Paquete: Un mecanismo de propósito general para la organización de elementos y

diagramas de modelo en grupos. Proporciona un espacio de nombres encapsulado
dentro del cual todos los nombres deben ser únicos. Se utiliza para agrupar elementos
relacionados semánticamente. Es un espacio de nombres, así como un elemento que
puede estar contenida en los espacios de nombres de otros paquetes. Visualmente se
representa como una carpeta.
 Dependencia: Indica que un elemento de un paquete requiere a otro de un paquete
distinto. Visualmente se representa mediante una flecha discontinua con inicio en el
paquete que depende del otro, es decir, la flecha parte del elemento de origen y apunta
hacia el elemento destino.
 Estereotipos: Existen tres estereotipos de relación de dependencia entre paquetes.
Visualmente un estereotipo de dependencia se representa como el nombre de la
dependencia entre un par de símbolos mayor y un par de símbolos menor (<< >>), se
coloca junto a la flecha que señala la dependencia. <<import>> significa una
importación publica, los elementos importados tienen visibilidad pública dentro del
espacio de nombre del paquete origen o paquete importador, <<access>> significa una
importación privada, se utiliza para indicar la visibilidad privada, y <<merge>>
significa que la fuente de la combinación importa los contenidos importados por el
destino .
DIAGRAMA DE SECUENCIA
El diagrama de secuencia es un tipo de diagrama de interacción cuyo objetivo es describir

el comportamiento dinámico del sistema de información haciendo énfasis en la secuencia
de los mensajes intercambiados por los objetos.
Descripción
Un diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo y el

eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del diagrama
hacia la inferior. Normalmente, en relación al tiempo sólo es importante la secuencia de los
mensajes, sin embargo, en aplicaciones de tiempo real se podría introducir una escala en el
eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su
colocación debería poseer la mayor claridad posible.
Cada objeto tiene asociados una línea de vida y focos de control. La línea de vida indica el
intervalo de tiempo durante el que existe ese objeto. Un foco de control o activación
muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operación,
ya sea directamente o mediante un procedimiento concurrente.
Notación
Objeto y línea de vida
Un objeto se representa como una línea vertical discontinua, llamada línea de vida, con un
rectángulo de encabezado con el nombre del objeto en su interior. También se puede incluir
a continuación el nombre de la clase, separando ambos por dos puntos.
Si el objeto es creado en el intervalo de tiempo representado en el diagrama, la línea

comienza en el punto que representa ese instante y encima se coloca el objeto. Si el objeto
es destruido durante la interacción que muestra el diagrama, la línea de vida termina en ese
punto y se señala con un aspa de ancho equivalente al del foco de control.
En el caso de que un objeto existiese al principio de la interacción representada en el

diagrama, dicho objeto se situará en la parte superior del diagrama, por encima del primer
mensaje. Si un objeto no es eliminado en el tiempo que dura la interacción, su línea de vida
se prolonga hasta la parte inferior del diagrama.
La línea de vida de un objeto puede desplegarse en dos o más líneas para mostrar los
diferentes flujos de mensajes que puede intercambiar un objeto, dependiendo de alguna
condición.
Foco de control o activación
Se representa como un rectángulo delgado superpuesto a la línea de vida del objeto. Su

largo dependerá de la duración de la acción. La parte superior del rectángulo indica el inicio
de una acción ejecutada por el objeto y la parte inferior su finalización.
Mensaje
Un mensaje se representa como una flecha horizontal entre las líneas de vida de los objetos
que intercambian el mensaje. La flecha va desde el objeto que envía el mensaje al que lo
recibe. Además, un objeto puede mandarse un mensaje a sí mismo, en este caso la flecha
comienza y termina en su línea de vida.
La flecha tiene asociada una etiqueta con el nombre del mensaje y los argumentos.
También pueden ser etiquetados los mensajes con un número de secuencia, sin embargo,
este número no es necesario porque la localización física de las flechas que representan a
los mensajes ya indica el orden de los mismos.
Los mensajes pueden presentar también condiciones e iteraciones. Una condición se

representa mediante una expresión booleana encerrada entre corchetes junto a un mensaje,
e indica que ese mensaje sólo es enviado en caso de ser cierta la condición. Una iteración se
representa con un asterisco y una expresión entre corchetes, que indica el número de veces
que se produce.
(Nota.- Esta notación es la más habitual, pero MÉTRICA Versión 3 no exige su

utilización).
Ejemplo
Diagrama de secuencia para el caso de uso: Prestar un ejemplar de una aplicación

encargada de los préstamos y reservas de una biblioteca:
DIAGRAMA DE TIEMPOS
En el estándar de Lenguaje de Modelado Unificado de OMG los diagramas de tiempo son
una representación especial de interacción que se enfoca en el tiempo de los mensajes
enviados entre objetos. Se pueden usar estos diagramas para mostrar restricciones
detalladas sobre el tiempo, ó para mostrar los cambios con líneas de vida respecto al
tiempo. Los diagramas de tiempo son generalmente utilizados con sistemas en tiempo real o
en sistemas embebidos.
DIAGRAMA GLOBAL DE INTERACCIONES
Los diagramas globales de interacción de UModel utilizan elementos de diagramas de

actividades y de diagramas de secuencia para mostrar el flujo de la ejecución del programa.
También puede utilizar este tipo de diagrama para deconstruir casos complejos en los que
sería necesario utilizar rutas if-then-else para ilustrarlos como un solo diagrama de
secuencia.
La barra de herramientas de los diagramas globales de interacción de UModel contiene

iconos para el nodo inicial, el nodo final, las decisiones, las combinaciones, las
bifurcaciones y las flechas, pero no contiene ningún elemento adicional que pueda crear
sintaxis UML inválida. Las flechas de control de flujo conectan diagramas de secuencia ya
existentes con las interacciones de su modelo para ilustrar el flujo de ejecución.
En las fases tempranas del proyecto puede construir diagramas de secuencia incompletos y
usarlos como marcadores de posición en el diagrama global de interacción mientras usted
diseña todo el flujo de la aplicación. Esta función permite diseñar el flujo del programa de
forma superficial antes de completar todos los detalles de cada secuencia individual. Puede
completar cada uno de esos diagramas de secuencia más tarde o incluso delegarlos en otros
miembros del equipo.

Desarrollo Taller #4 UML Oscar Enrique Quiroga Contreras

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo Taller #4 UML Oscar Enrique Quiroga Contreras

Cargado por

Copyright:

Formatos disponibles

Desarrollo taller UML

3.1 REFLEXIÓN INICIAL.

¿Cuáles son los elementos que constituyen un caso de uso?

- Especialización y generalización de los casos de uso: Un caso de uso (subcaso)

3.3 Actividades de apropiación.

1. Como se llama la entidad que inicia el caso de uso?

2. Qué se entiende con "Incluir" un caso de uso?

- Se denomina Include en los casos de uso y aparecen como funcionalidad común,

3. Qué se entiende con “Extender" un caso de uso?

¿Cuáles serían algunos de los escenarios dentro de cada caso de uso?

* Sistema de administración de ventas

5. Cree un caso de uso relacionado con cualquier situación de la vida real.

3.4 TRANSFERENCIA DEL CONOCIMIENTO.

1. Realizar individualmente una lectura al siguiente material bibliográfico: UML gota a

2. Leer y analizar la información que se encuentra relacionada a continuación.

3.5 Actividades de Evaluación. En el restaurante “MAMAMIA” se realizan los

Finalmente los clientes se retiran del restaurante “mamamia“recogiendo sus prendas y

Diagrama casos de uso

Realizar el análisis de casos de uso para los siguientes casos:

Sistema Registro Usuario

Sistema de registro de usuarios

- El usuario registra en sistema usando un login y una contraseña

Sistema modificar usuario

-Datos introducidos son correctos

Sistema Consultar Usuario

- El administrador consulta base de datos los datos correspondientes al usuario,

- Respuesta del sistema

Sistema registro de administrador

- El root introduce datos para registrar el administrador en la base de datos, después

- Acciones del actor

Sistema validación de usuario

- Acciones del actor

- Ingresar login y contraseña

- Respuesta del sistema

-Los datos del usuario fueron ingresaron correctamente

Elaborar el diagrama de Clase del Enunciado 1 (la cadena de videoclubs)

Responder los siguientes cuestionamientos:

R: Se representa en un rectángulo con tres compartimientos. En el primero va el nombre del

¿Qué es el estado pasivo de un objeto?

R: Es aquel en el que el objeto analizado simplemente espera a que algo ocurra en el

¿Cuándo se presenta el estado activo de un objeto y qué valores puede adoptar?

R: Un estado está activo cuando se alcanza mediante una transición y se convierte en

¿Qué es un suceso, en qué ocasiones se presenta y cómo afecta un suceso al sistema?

¿A qué se llama transición del objeto?

¿Cuál es el símbolo que se utiliza para representar el Estado Inicial de un Objeto?

¿Cuál es el símbolo que se utiliza para representar el Estado Final de un Objeto?

R: El estado final es el último estado en el que queda un objeto antes de desaparecer, o

¿Con qué símbolo se representa el estado transaccional de un objeto y en qué situaciones

El diagrama de colaboración es un tipo de diagrama de interacción cuyo objetivo es

Un diagrama de colaboración muestra la misma información que un diagrama de secuencia

A diferencia de los diagramas de secuencia, en los diagramas de colaboración siempre se

Además, los mensajes pueden tener asociadas condiciones e iteraciones que se

El diagrama de componentes proporciona una visión física de la construcción del sistema

Un componente se representa como un rectángulo, con dos pequeños rectángulos

Se representa como un pequeño círculo situado junto al componente que lo implementa y

Sistema encargado de la gestión de los préstamos y reservas de libros y revistas en una

Los diagramas de despliegue muestran la configuración en funcionamiento del sistema

 Sistemas empotrados: Un sistema empotrado es una colección de hardware con una

 Muestra un conjunto de nodos y sus relaciones.

 La posible falla en la modelación de un hardware.

Un nodo es un objeto físico en tiempo de ejecución que representa un recurso

Estereotipo, son cosas u objetos q se repiten sin variación.El estereotipo de un nodo es la

 Executable: especifica un artefacto que se puede ejecutar en un nodo.