Que es UML

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar,
especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de
modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como
lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.

La concepción del UML

El UML es la creación de Grady Booch, Jame Rumbaugh e Ivar Jacobson y fue desarrollado en un esfuerzo para
simplificar el gran número de métodos de desarrollo orientados a objetos que se habían generado. Estos caballeros
apodados “los tres amigos”, trabajaban en empresas distintas durante la época de los 80 y principios de los 90 y cada
uno de ellos diseño su propia metodología para el análisis y diseño. Sus metodologías predominaron sobre las de sus
competidores. A mediados de los años noventa empezaron a intercambiar ideas entre si y decidieron desarrollar su
trabajo en conjunto con el objetivo de normalizar el lenguaje que se utilizaba a la hora de realizar el análisis y diseño en
esa época.

Posteriormente un gran número de grandes empresas se unieron para perfeccionar y afinar cada vez más estas
nomenclaturas, poco a poco esta forma de modelar fue tomando peso en los desarrollos de las pequeñas y grandes
empresas.

¿PARA QUÉ SIRVE UML?

UML sirve para hacer modelos bajo un lenguaje normado que permite:
 Visualizar como es un sistema o como queremos que sea.
 Especificar la estructura y/o comportamiento de un sistema.
 Hacer una plantilla que guíe la construcción de los sistemas
 Documentar las decisiones que hemos tomado.

UML puede ser usado extensivamente en: Recopilación de requerimientos, Análisis de aplicaciones, Diseño de sistemas,
en pruebas, en implementación, en reingeniería y prácticamente en cualquier actividad de desarrollo que sea
susceptible de ser modelada.

¿PORQUE ES IMPORTANTE UML?

En los principios de la computación, los programadores no realizaban análisis muy profundos sobre el problema a
resolver. Con frecuencia comenzaban a escribir el programa desde el principio, y el código necesario se escribía
conforme se requería.

Hoy en día, con sistemas cada vez más complejos, es necesario contar con un plan bien analizado. Un cliente tiene que
comprender que es lo que hará su equipo de desarrolladores, además tiene que ser capaz de señalar cambios si no se
han captado claramente sus necesidades. A su vez, el desarrollado es un esfuerzo orientado a equipos, por lo que cada
uno de sus miembros debe tener claridad de lo que debe realizar en su trabajo para poder lograr la solución.

La clave para solventar el desarrollo sobre los complejos sistemas que existen actualmente, está en organizar el proceso
de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del
sistema lo comprendan y convengan con él. El UML proporciona tal organización.

Beneficios de usar UML

  Mejores tiempos totales de desarrollo (de 50% o más). En la mayoría de organizaciones hoy en día el tiempo que
pasa desde que un proyecto arranca hasta que se estabiliza es más del doble de lo planeado originalmente. Con
el uso de UML las fases de análisis y diseño consumirán mayor tiempo, pero el tiempo de construcción,
implantación y estabilización se reducen drásticamente debido a que no hay correcciones mayores en las fases
de mayor impacto de un proyecto.

 Mejor calidad. El uso de UML hace indispensable la participación del usuario en la definición de requerimientos
y por lo tanto mejora considerablemente el apego del sistema a las necesidades de sus usuarios. El
mantenimiento correctivo se reduce drásticamente (hasta un 80% con respecto a un sistema hecho sin
metodología). Algo similar ocurre en los proyectos de reingeniería.

 Mejor soporte a la planeación y al control de proyectos. Al existir entregables definidos y estandarizados en las
distintas fases de un proyecto y al ser éstos revisables y certificables por gente distinta del autor, tenemos que
los planes de trabajo pueden ser fácilmente creados y corroborados en avance. Lo que permite tomar decisiones
a tiempo.

 Mayor independencia del personal de desarrollo. Al tener documentadas las aplicaciones en un lenguaje
estándar, podemos mover al personal de una aplicación a otra sin correr altos riesgos y sin depender del
conocimiento personal de las aplicaciones.

 Mayor soporte al cambio organizacional, comercial y tecnológico. Un modelo permite cuantificar el impacto de
un cambio antes de hacerlo y permite ensayar distintos enfoques de solución. Con UML un cambio se puede
hacer primero en papel.

 Alto reusó. Los productos de un desarrollo pueden ser usados en otro. Se pueden crear componentes reusables
que con la difusión y administración adecuadas minimizarán costos y errores.

 Minimización de costos. Los puntos antes mencionados tienen un impacto económico que generalmente tiende
a ser proporcional al tamaño de la organización.

Inconvenientes de usar UML

 No es una metodología, además de usar UML es necesario implementar una metodología

 No cubre todas las necesidades de especificación de un proyecto software
o No define los documentos textuales o el diseño de interfaces de usuario
 Puede resultar complejo alcanzar un conocimiento completo del lenguaje
o Sin embargo => Regla del 80 – 20

Conceptos básicos para el modelado

Un modelo según Grady Booch:

a. Simplificación completa y auto consistente de la realidad
b. Creado para comprender mejor un sistema.
c. Provee el plano del sistema a construir
d. Puede representar un plan detallado o dar una vista de muy alto nivel
e. Si es bueno, incluye los aspectos realmente importantes para cierto punto de vista

Para términos prácticos es necesario comprender los siguientes conceptos:

 Sistema: Colección de elementos, posiblemente divididos en subsistemas, organizados para lograr un propósito.
Está descrito por un conjunto de modelos.
  Vista (Arquitectural): Proyección de la organización y estructura de un modelo de un sistema, centrada en un
aspecto. Contiene un subconjunto de los elementos incluidos en el modelo
 Diagrama: Representación gráfica de un conjunto de elementos del modelo y sus relaciones. En UML
generalmente corresponde a un grafo conexo de nodos (elementos) y arcos (relaciones).

Diagramas de UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el
UML es un lenguaje, cuenta con reglas para combinar tales elementos.

El UML tiene numerosos tipos de diagramas y, por lo tanto, soporta la creación de muchos diferentes tipos de modelos
de sistema. Sin embargo, a continuación se van a detallar los diagramas esenciales para representar un sistema

1. Diagrama de Clases
2. Diagrama de Casos de Uso
3. Diagrama de Secuencia

Diagrama de Clases

Los diagramas de clases muestran las diferentes clases que componen un sistema y cómo se relacionan unas con otras.
Se dice que los diagramas de clases son diagramas “estáticos” porque muestran las clases, junto con sus métodos y
atributos, así como las relaciones estáticas entre ellas: qué clases “conocen” a qué otras clases o qué clases “son parte”
de otras clases, pero no muestran los métodos mediante los que se invocan entre ellas.

Un diagrama de clases está compuesto por los siguientes elementos:

 Clase: atributos y métodos (operaciones).

 Relaciones: Herencia, Composición, Agregación, Asociación y dependencia.

Clase

 Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A
través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

 Las clases tienen atributos que representan alguna propiedad de la clase que comparten todos los objetos de
esa clase.

Atributo

 Un atributo es una propiedad nombrada de una clase, que describe un rango de valores que puede tomar esa
propiedad en las instancias. Por ejemplo, nombre, edad o peso son atributos de objetos Persona
 Cada nombre de atributo es único dentro de una clase, pero cada atributo tiene un valor para cada instancia de
la clase.
 Diferentes instancias de objetos pueden tener los mismos o distintos valores para un atributo dado.
 Un atributo debería ser un valor de datos puro, no un objeto.

Operaciones

 Una operación es una función o transformación que puede ser aplicada por o sobre objetos de una clase.
o Todos los objetos de una clase comparten las mismas operaciones
o Una operación es la implementación de un servicio que puede requerirse de cualquier objeto de la clase.
  Las operaciones en una clase definen lo que la clase puede hacer y pueden considerarse como la interface de la
clase

En UML, una clase es representada por un rectángulo que posee tres divisiones:

Los atributos y operaciones pueden mostrarse o no, dependiendo del nivel de detalle deseado.

Ejemplo 1:

Una Persona que posee como característica: Nombre y Edad

Puede realizar las operaciones de: Cambiar de trabajo y Cambiar de dirección

El diseño asociado es:

Persona
Nombre
Edad
cambiar de trabajo()
cambiar de dirección()

Ejemplo 2:
Un Fichero que posee como características: Nombre, Tamaño en bytes y Última actualización
Puede realizar la operación de: Imprimir

El diseño UML asociado es:

Fichero
Nombre fichero
Tamaño en bytes
Ultima actualización
imprimir()

Ejemplo 3:
Un Vehículo que posee como características: Color, modelo y año
Puede realizar las operaciones de: Acelerar y Frenar

El diseño UML asociado es:

 Vehículo
Color
Modelo
Año
acelerar()
frenar()

Relaciones entre Clases

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden interrelacionar dos o más clases (cada uno
con características y objetivos diferentes).

Los tipos de relaciones posibles son:

 Herencia
 Agregación y Composición
 Asociación
 Dependencia

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Súper Clase, por ende la Subclase además
de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Súper Clase

Ejemplo 1:

Jugador
Nombre
Tamaño
Peso
Velocidad
pasar()
driblar()
tirar()

Defensa Delantero Centro

Nombre Nombre
Tamaño Tamaño
Peso Peso
Velocidad Velocidad
quitarbalon() centrarbalon()

Ejemplo 2:
 Trabajador

Directivo Administrativo Obrero

Agregación y Composición:

 Agregación:

o Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del
que lo incluye, el objeto base utiliza al incluido para su funcionamiento

 Composición:

o Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el
tiempo de vida del que lo incluye, el Objeto base se construye a partir del objeto incluido, es decir, es
"parte/todo"

Ejemplo 1: Ejemplo 2:

Almacen Curso Ventana

Cuentas Cliente Alumno Marco

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que
no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Puede tener un nombre que la
describe (verbo, con dirección de lectura).
 Cliente Ordencompra

Jugador Equipo
Participa en

Dependencia o Instancia:

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de
otro objeto/clase). El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de
otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está
condicionado a la instanciación proveniente desde el objeto Aplicación):

Aplicación Ventana

Diagrama de Caso de uso

Un caso de uso es una técnica de modelado usada para describir lo que debería hacer un sistema nuevo o lo que hace un
sistema que ya existe. Los casos de uso describen bajo la forma de acciones y reacciones el comportamiento de un
sistema desde el punto de vista de un usuario, permiten definir los límites del sistema y las relaciones entre el sistema y
el entorno.

Los principales componentes de los casos de uso son:

 Casos de uso: Son descripciones funcionales del sistema; describen cómo los actores pueden usar un sistema
 Actores: El actor es una entidad externa que tiene interés en interactuar con el sistema. A menudo, es una
persona que usa el sistema, pero también puede ser otro sistema o alguna clase de dispositivo hardware que
necesita interactuar con el sistema
 Sistema: El sistema se observa como una caja negra que proporciona casos de uso. Cómo lo haga el sistema,
cómo se implementen los casos de uso y cómo trabajen internamente no importa
 Relaciones.

Los propósitos primarios de los casos de uso son:

 Decidir y describir los requerimientos funcionales del sistema, dando lugar a un acuerdo entre el cliente (y/o
usuario final) y los programadores que desarrollan el sistema.
 Dar una descripción clara y consistente de lo que debería hacer el sistema, de modo que el modelo se use a lo
largo del proceso de desarrollo.
 Proporcionar una base para realizar verificaciones (test) del sistema que comprueben su funcionamiento.
  Proporcionar la capacidad para rastrear requerimientos funcionales en clases y operaciones reales del sistema,
verificando los casos de uso afectados por cambios y extensiones al sistema.

Un modelo de casos de uso se describe en UML mediante un diagrama de casos de uso (use-case diagram) y puede
dividirse en varios diagramas de casos de uso.

Un diagrama de casos de uso contiene elementos del modelo para el sistema, los actores y los casos de uso, y muestra
las diferentes relaciones entre estos elementos. Estos diagramas dan una visión del modelo, pero las descripciones
reales de los casos de uso suelen ser textuales, usando el lenguaje y terminología del cliente/usuario.

Para poder comprender mejor como interpretar y construir un Diagrama de casos de uso es necesario profundizar un
poco más en sus diferentes componentes:

Actores

 Un actor es alguien o algo que interactúa con el sistema, pero que es externo al sistema
 Un actor es una clase, no una instancia. El actor representa un papel, no a un usuario individual del sistema
 Un caso de uso siempre es iniciado por un actor que le envía un mensaje o estímulo. Los actores llevan a cabo
casos de uso.
 Un actor debe tener un nombre que refleje su papel
 Un actor debe tener alguna relación con uno o más casos de uso
 Para identificar los actores, se establecen las entidades interesadas en usar e interactuar con el sistema

Caso de uso

 Un caso de uso representa una funcionalidad completa tal como la percibe un actor
 Un caso de uso en UML se define como una secuencia de acciones que realiza un sistema y que conduce a un
resultado observable

Relaciones:

 Relación de extensión (<<extend>>):

o Añade acciones, que pueden ser opcionales, al comportamiento de un caso de uso general.
o El caso de uso extendido puede incluir comportamiento del caso de uso que se extiende, aunque no
tiene que incluir todo el comportamiento.
o Representan una parte de la funcionalidad del caso que no siempre ocurre.
 Relación de inclusión (<<include>>, <<use>>):
o Un caso de uso incluye el comportamiento completo de un caso de uso general.
 Relación de generalización: 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
 Relación de asociación: Se utiliza para conectar un actor con el caso de uso

Ejemplo de extensión:
 Manejar auto <<extender>> Tocar bocina

Comprar entrada cine <<extender>> Comprar cabritas

Cenar <<extender>> Tomar café

Ejemplo de inclusión:

Ejemplo de generalización:

Resolver Consulta

Profesional

Resolver consulta
Jurídica

Abogado

Resolver consulta
psicológica

Psicólogo

Componentes gráficos del diagrama casos de uso en UML

 CASO DE USO

ACTOR

Asociación

<<incluir>> Inclusión

<<extender>> Extensión

Generalización

Descripción de los casos de uso

 La descripción de un caso de uso normalmente es textual.

 Es una especificación simple y consistente de cómo interactúan los actores y los casos de uso (el sistema).
 Se concentra en el comportamiento externo del sistema e ignora cómo se hacen realmente las cosas dentro del
sistema.
 El lenguaje y la terminología son los mismos que los usados por el cliente/usuario del sistema.

Pasos para realizar y documentar un diagrama de casos de uso

Diagrama de Secuencia

Un diagrama de secuencias muestra la interacción de un conjunto de objetos de una aplicación a través del tiempo, en el
cual se indicaran los módulos o clases que formaran parte del programa y las llamadas que se hacen cada uno de ellos
para realizar una tarea determinada, por esta razón permite observar la perspectiva cronológica de las interacciones. En
el diagrama, los objetos se colocan en la parte superior y el tiempo avanza de arriba hacia abajo. Es importante recordar
que el diagrama de secuencias se realiza a partir de la descripción de un caso de uso.

En los diagramas de secuencia se representa el tiempo de manera vertical. El tiempo se inicia en la parte superior y
avanza hacia la parte inferior. Un mensaje que está más cerca de la parte superior ocurrirá antes que uno que este cerca
de la parte inferior. Con ello, el diagrama de secuencia tiene dos dimensiones. La dimensión horizontal es la disposición
de los objetos, y la dimensión vertical muestra el paso del tiempo.

Los diagramas de secuencia se componen de los siguientes elementos:

 Objeto/Actor: El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa
las llamadas a métodos del objeto

 Mensaje simple: Corresponde a la transferencia de control de un objeto a otro

 Mensaje síncrono: Este tipo de mensaje esperará la respuesta a tal mensaje antes de continuar

 Mensaje asíncrono: Este tipo de mensaje no esperará la respuesta para continuar

  Mensaje recursivo: Hace referencia cuando el Objeto/Actor se invoca a sí mismo, generando un auto mensaje

Representación en UML de un diagrama de secuencia

Ejemplo1:

Página
Cliente BD
web
Ingresar usuario y
contraseña
Solicitar validación
de credenciales
Validar
credenciales

Cargar página
de inicio
Mostrar página
de inicio

Ejemplo 2:
Manguera de
Tambor Drenaje
agua
Abastecimiento de agua

Permanecer
Inmmovil

Detenerse

Girar de un
lado a otro

Vaciar agua jabonosa

Reabastecer agua
Girar de un
lado a otro

Vaciar agua de enjuague

Detenerse

Girar en un
solo sentido

Detenerse
Ejercicios Diagrama de clases

1. Genere tres diagrama de clases donde se relacionen por asociación ( ) como mínimo 3 Clases, considere
al menos un atributo y operación para estas clases
2. Genere un diagrama de Clase donde exista como mínimo una relación de herencia ( ) y 5 Clases.
3. Genere un diagrama de Clase que contenga como mínimo una relación de composición( ) y dos de
agregación ( )
4. Genere un diagrama donde se relacionen como mínimo 7 clases y que esté presente al menos dos de las
relaciones presentadas.

Ejercicios Diagramas casos de uso

1. Del clásico juego “buscaminas”, identifique los siguientes conceptos:

 Actor = Persona
 Casos de uso (mínimo 4) = Iniciar partida, descubrir casilla, marcar casilla, cerrar juego
 Sistema = buscaminas

2. Del clásico juego “Pac-Man”, identifique los siguientes conceptos:

 Actor = Persona
 Casos de uso (mínimo 4) = Iniciar partida, moverse horizontalmente, moverse verticalmente, comer
fantasma.
 Sistema = Pac-Man

3. Genere un diagrama de caso de uso en base a:

  El cajero automático lo puede utilizar el cliente y el empleado de la sucursal
 El cliente deberá identificarse en la terminal antes de realizar cualquier operación
 Además podrá cambiar el pin, obtener los últimos movimientos y saldo y realizar retiro de dinero
 La única función del empleado es reponer billetes en el cajero

Solución:

Retiro de dinero

Cambiar PIN

<<incluir>> Pedir movimientos

Cliente y saldo
<<incluir>>

<<incluir>>

Validarse

Reponer billetes
Empleador

4. Genere un diagrama de caso de uso en base a:

 Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe
controlar y/o aceptar:
i. Registrar el número de ítems ingresados.
ii. Imprimir un recibo cuando el usuario lo solicita:
1. Describe lo depositado
2. El valor de cada ítem
3. Total
iii. El usuario/cliente presiona el botón de comienzo
iv. Existe un operador que desea saber lo siguiente:
1. Cuantos ítems han sido retornados en el día.
2. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.
v. El operador debe además poder cambiar:
1. Información asociada a ítems.
2. Dar una alarma en el caso de que:
a. Ítem se atora.
b. No hay más papel.

Solución:

Paso 1, identificamos a los actores que interactúan con el sistema

 Cliente Operador
Paso 2, un Cliente puede Depositar Ítems y un Operador puede cambiar la información de un Ítem o bien puede
Imprimir un informe:
Generar reporte
diario
Depositar item

Cliente Cambiar item Operador

Paso 3, un ítem puede ser una Botella, un Tarro o una Jaba

Depositar item

Depositar botella Depositar tarro Depositar jaba

Paso 4, la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien
puede ser realizada a petición de un operador
Generar reporte
Depositar item
diario

<<incluir>> <<incluir>>

Imprimir

Paso 5, final

Generar alarma

Imprimir

<<incluir>>
Depositar botella
Cliente Generar reporte Operador
<<incluir>>
diario
Depositar tarro

Depositar item
Cambiar item
Depositar jaba
 5. Según el proceso de atención de pacientes en la unidad de cuidados intensivos UCI, se necesita registrar el
ingreso de pacientes a la unidad, teniendo en consideración que:
 El paciente debe ser trasladado al hospital más cercano
 La enfermera se encarga de tomar los datos del paciente y realizar la primera revisión al paciente
 Se debe elaborar un registro de ingreso del paciente

Según lo mencionado anteriormente genere el diagrama de caso de uso asociado a la problemática.

Solución:

Traslado al hospital

Obtener datos
paciente

Paciente
Revisión del
Enfermera paciente

Generar registro
de ingreso

6. Es requerido realizar un diagrama que represente la gestión de niveles o etapas de un videojuego

 Al momento de ingresar a este video juego debemos identificar las maneras que tiene el usuario de
interactuar con el menú principal. Este menú posee 3 opciones: Jugar – Gestionar Nivel – Salir.
 Para la gestión de niveles se deben considerar las siguientes opciones:
i. El jugador decide jugar a los niveles creados.
ii. El usuario decide editar los niveles del videojuego para modificar algún detalle del mismo o
crear niveles nuevos.
 La tercera opción está relacionada con la petición de salir de la propia aplicación

Solución
 Cargar niveles Nuevo nivel

<<incluir>> <<incluir>> <<incluir>> Editar nivel

Siguiente nivel <<incluir>>

<<incluir>> <<incluir>>
Gestionar
Jugar
niveles <<incluir>>
<<incluir>> <<incluir>> Guardar nivel

Nivel anterior

Salir

Usuario
7. Se requiere generar un diagrama para una máquina de expendio de snack que permita graficar las siguientes
funciones operacionales:
 Un cliente puede comprar diferentes tipos de snack.
 Un proveedor debe ser capaz de reestablecer los snack que falten en la máquina, para esto debe
asegurarse de abrir y cerrar correctamente la máquina.
 Un recolector se encarga de retirar periódicamente el dinero recaudado por la máquina y se encarga de
reponer el dinero para otorgar el vuelto al cliente

Solución:

Comprar snack

Cliente
Abrir máquina

<<incluir>>
<<incluir>>
Reponer snack
faltante
Recolectar dinero
<<incluir>> Proveedor
<<incluir>>
<<incluir>>
Recolector
Cerrar máquina
Reponer dinero
Ejercicios Diagrama de secuencias

1. Genere un diagrama de secuencia que represente el siguiente procedimiento para poder hervir agua:
 El usuario debe llenar el hervidor con agua
 El usuario enchufa el hervidor a la corriente
 El usuario enciende el hervidor
 El hervidor hierve el agua
 El hervidor se detiene
 El usuario recibe su agua hervida

Solución:

Persona Hervidor Corriente

poner agua

enchufar

encender

hervir agua

detenerse

termino hervir

2. Genere un diagrama de secuencia para los procesos que debe realizar un usuario para revisar su estado de
cuenta dentro de la página del banco, considerando que:
 El usuario debe ingresar sus credenciales a la página del banco
 La página solicita la validación de la información a la base de datos
 La base de datos valida y responde a la solicitud de validación
 Se carga la página principal de la cuenta del cliente
 El usuario visualiza la página principal de su cuenta
 El usuario selecciona “ver estado de cuenta”
 La página carga el estado de cuenta
 El usuario visualiza la página del banco

Solución:
 Página
Cliente BD
web
Ingresar usuario y
contraseña
Solicitar validación
de credenciales
Validar
credenciales

Cargar página
de inicio
Mostrar página
de inicio

ver estado de cuenta

Cargar estado de cuenta

Mostrar estado de cuenta

3. Genere un diagrama de secuencia para los procesos que debe realizar un usuario para cambiar la contraseña
con la cual inicia sesión en la página web del banco, considerando que:
 El usuario debe ingresar sus credenciales a la página del banco
 La página solicita la validación de la información a la base de datos
 La base de datos valida y responde a la solicitud de validación
 Se carga la página principal de la cuenta del cliente
 El usuario visualiza la página principal de su cuenta
 El usuario selecciona “cambiar contraseña web”
 La página carga el formulario para cambiar la contraseña
 El usuario visualiza el formulario para cambiar de contraseña
 El usuario ingresa la contraseña actual, la contraseña nueva y envía la solicitud para realizar el cambio
 La página envía la actualización de la contraseña a la base de datos
 La base de datos actualiza la contraseña
 La base de datos responde que se cambió la contraseña correctamente
 La página web responde que se cambió la contraseña correctamente
 El usuario es notificado sobre el cambio de contraseña

Solución:
 Página
Cliente BD
web
Ingresar usuario y
contraseña
Solicitar validación
de credenciales
Validar
credenciales

Cargar página
de inicio
Mostrar página
de inicio

Seleccionar cambiar
contraseña
Cargar formulario para
cambiar contraseña

Mostrar formulario

Ingresar contraseña
actual

Ingresar contraseña
nueva
Solicitar cambio de contraseña
Enviar contraseña
nueva y antigua
Actualizar
contraseña

Fin actualización
Notificación
cambio de contraseña