Вы находитесь на странице: 1из 26

TALLER DE UML

JESUS ADRIAN ANAYA SARRIA

Servicio Nacional de Aprendizaje - SENA


Tc Programación de software Ficha: 1321642
Bogotá, Colombia
2017
3.1 Actividades de Reflexión inicial

¿Para qué sirven cuando se emplean como se emplean, en qué casos debemos
tener en cuenta los casos de uso?

un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que
usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese
momento, ese actor, junto con otros actores, intercambian datos o control con el
sistema, participando de ese caso de uso. Se emplean para ilustrar los requerimientos
del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él
mismo.
El nombre de un caso de uso se expresa con un verbo en gerundio, seguido
generalmente por el principal objeto o entidad del sistema que es afectado por el caso.
Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso
en su interior.

Los casos de uso tienen las siguientes características:


1) Están expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa
con él, aunque el énfasis está puesto en la interacción.
4) Son iniciados por un único actor.
5) Están definidos al uso de una determinada funcionalidad
El último punto es tal vez el más difícil de definir la funcionalidad de un sistema en casos
de uso son aún más difusos, y por esto se hace importante usar el sentido común en
estas decisiones.
debemos tener en cuenta los casos de uso son un medio de comprensión del sistema
para desarrolladores, usuarios finales y expertos del dominio y ayudan a validar la
arquitectura y a verificar el sistema en el transcurso su desarrollo
¿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?

Sí, porque definir requerimientos, es importante describir al sistema desde el punto de


vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir de
esta forma, es más fácil validar que los requerimientos documentados son los
verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la
forma en la que están expresados.

¿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?

Sí, ya que describen las relaciones y las dependencias entre un grupo de casos de uso
y los actores participantes en el proceso. para facilitar la comunicación con los futuros
usuarios del sistema, y con el cliente, y resultan especialmente útiles para determinar
las características necesarias que tendrá el sistema.

¿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?

Si, dado que importante tener clara la diferencia entre usuario y actor. Un actor es una
clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume
un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La
forma más simple de entender esto es pensar en perfiles de usuario de un sistema
operativo
3.2 Actividades de contextualización e identificación de conocimientos
necesarios para el aprendizaje.

¿Qué es UML?

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de


Modelado”. 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 (programas informáticos).

¿Qué es un 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, permitiendo definir los límites del sistema y las relaciones entre
el sistema y el entorno.

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

1. Actores: Son los diferentes usuarios y el papel que representan dentro del
sistema.

2. Caso de uso: Representan todo lo que el usuario puede realizar dentro del sistema
3. Relaciones: Para asociar los elementos anteriores.

``comunica (<<communicates>>): Relación (asociación) entre un actor y un caso


de uso que denota la participación del actor en dicho caso de uso.

``usa ( <<uses>>) (o <<include>> en la nueva versión de UML): Relación de


dependencia entre dos casos de uso que denota la inclusión del comportamiento
de un escenario en otro.

``extiende (<< extends>>): Relación de dependencia entre dos casos de uso que
denota que un caso de uso es una especialización de otro. Por ejemplo, podría
tenerse un caso de uso que extienda la forma de pedir azúcar, para que permita
escoger el tipo de azúcar (normal, dietético o moreno) y además la cantidad en
las unidades adecuadas (cucharadas o bolsas). Un posible diagrama se muestra
en la figura

¿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?

Los criterios de un caso de uso son:


Encontrar los casos de uso
 Su objetivo es establecer el alcance del sistema
 Se deben encontrar los casos de uso fundamentales
 Se deben describir los casos de uso en lenguaje natural
 Se debe realizar la verificación de los casos de uso
Detallar los casos de uso
 Su objetivo es lograr una especificación de requisitos completa
 Se deben completar los pasos de los casos de uso en forma detallada
 Se deben extender los casos de uso
 Se debe realizar la validación de los casos de uso
Refinar los casos de uso
 Su objetivo es documentar en detalle los casos de uso
 Se debe refinar la documentación textual
 Se deben revisar en detalle los requisitos no funcionales
 Se debe incorporar la documentación anexa, diagramas, etc.
Los criterios de un diagrama de caso de uso son:
 elaborar una lista de actores y definir sus roles
 elegir el actor más representativo del sistema para comenzar el diagrama
 agotar todas las necesidades funcionales del actor incorporando los
casos de uso de la funcionalidad base
 para cada caso de uso, buscar los actores que deban colaborar con él
 repetir los dos pasos anteriores para cada actor
 incorporar la funcionalidad necesaria para excepciones y errores
 obtener los actores abstractos mediante generalización
 describir cada caso de uso a medida que se incluye en el modelo
 validar y verificar el modelo junto con los usuarios

¿Cómo se relacionan los casos de uso?

Los casos de uso se conectan a los actores mediante asociaciones, denominadas líneas
de comunicación (communication lines).
– Las asociaciones muestran con qué actores se comunica el caso de uso, incluyendo
el actor que inicia la ejecución del caso de uso.
– La asociación normalmente es una relación uno a uno sin dirección. Esto significa que
una instancia de actor se comunica con una instancia de caso de uso y que pueden
comunicarse en ambas direcciones
5.Cree un caso de uso relacionado con cualquier situación de la vida real.

Caso de uso del control remoto de un televisor

3.1 Actividades de evaluación


En el restaurante “MAMAMIA” se realizan los siguientes procesos para atender a los
clientes:

Cuando el cliente ingresa la anfitriona les da la bienvenida y recibe las prendas y los
objetos de los clientes.

Los clientes son atendidos por meseros los cuales le van ha 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
entregara la lista con el menú seleccionado.

La Cocina 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 anfitriona.

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 Registro Usuario

Referencia 1
Nivel
Nombre Registro Usuario
Actor Usuario
Descripción El usuario registra en sistema usando un
login y una contraseña
Precondición Conocer los datos del usuario para
registrarlo
Acciones del actor Respuesta del sistema
-ingresar datos -Los datos han ingresado correctamente
-Guardar en base de datos -Los datos han sido guardado en la base de
-Verificar Datos datos
-Modificar Datos -Los datos ingresados son coherentes
-Crear registro -El dato ingresado ha sido modificado
-El registro ha sido creado correctamente
Posibles Fallos -Creación de otro usuario
-Datos inválidos -Pedir verificación de datos vía usuario.
-Repetición en datos del usuario
Sistema Modificar Usuario

Referencia 2
Nivel
Nombre Modificar Usuario
Actor Usuario
Descripción El usuario ingresa con el login y
contraseña para sustituir los datos
existentes en el sistema
Precondición Conocer el registro de login y contraseña
Acciones del actor Respuesta del sistema
-ingresar con login y contraseña -login correcto
-ingresar en base de datos -Datos introducidos son correctos
-Verificar Datos -Los datos indicaran cambios
-Modificar Datos -Los datos han sufrido cambios
-Crear registro -Los datos han sido guardado
correctamente
Posibles Fallos Acciones
-Campos inválidos -verificación de datos modificados
-Campos vacíos recientemente
-verificación de campos vacíos
Sistema Consultar Usuario

Referencia 3
Nivel
Nombre Consultar Usuario
Actor Usuario
Administrador
Descripción El administrador consulta base de datos
los datos correspondientes al usuario,
realiza pruebas de autenticación y
informa al usuario
Precondición Conocer el usuario que se va a consultar
Acciones del actor Respuesta del sistema
-El administrador accede por base de -el sistema genera nombres y apellidos
datos al registro del usuario de los usuarios registrados
-El administrador verifica que los datos -El sistema expone el nombre del usuario
del usuario sean correctos y los datos cargados en el registro
-El administrador informa al usuario el -Informa en pantalla el login
login y contraseña -El sistema valida login y contraseña
-El usuario entra el sistema con el login ingresados por el usuario.
y contraseña
Posibles Fallos Acciones
-Login y contraseña incorrectos -Solicitar al administrador la consulta del
usuario
Sistema Registro de Administrador

Referencia 4
Nivel
Nombre Registro Administrador
Actor Root
Descripción 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
Precondición Solicitud de registro de administrador
Acciones del actor Respuesta del sistema
-Ingresar datos -Los datos fueron introducidos
-Registra datos en la base de datos correctamente
-Asignar permisos -Los datos han sido registrados
-Guardar Configuraciones -Los permisos de administrador han sido
-Informar al administrador establecidos
-El registro se ha guardado
correctamente
-Se informa al administrador
Posibles Fallos Acciones
-Error al asignar permisos de -Inténtelo más tarde
administrador
Sistema Validación Usuario

Referencia 5
Nivel
Nombre Validación Usuario
Actor Usuario
Descripción El usuario introduce datos al sistema, el
sistema confronta los datos con la base
de datos y después valida datos
Precondición Verificar un login y contraseña de
usuario registrado en sistema
Acciones del actor Respuesta del sistema
-Ingresar login y contraseña -Los datos del usuario fueron ingresaron
-Confirmar datos en base de datos correctamente
-Validar Información -Los datos introducidos por el usuario
son correctos
-Validando información
Posibles Fallos Acciones
-Datos Incorrectos -Por valor ingresar los datos del usuario
registrado
Elaborar el diagrama de Clase de el Enunciado 1 (la cadena de videoclubs)
Elaborar los diagramas de Clase del Sistema Propuesto en grupo, para el Proyecto que
está desarrollando en la formación.

Responder los siguientes cuestionamientos:


¿En un objeto cómo o con qué elemento se representa su estado?
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?


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?

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?
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 123 sale para Valencia".

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

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?
.
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?

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.

Realizar una consulta detallada acerca de los siguientes diagramas y luego implementar
los que considere pertinentes a su proyecto dependiendo la necesidad.

Diagrama de Secuencias
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 indicarán 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. Es importante recordar que el diagrama de secuencias se realiza a partir
de la descripción de un caso de uso.

Entre las ventajas que tiene la elaboración de un diagrama de secuencias están las
siguientes:
Elementos de un Diagrama de Secuencias

 Rol de la Clase
El rol de la clase describe la manera en que un objeto se va a comportar en el contexto.
No se listan los atributos del objeto.
 Activación
Los cuadros de activación representan el tiempo que un objeto necesita para completar
una tarea.

 Mensajes
Los mensajes son flechas que representan comunicaciones entre objetos. Las medias
flechas representan mensajes asincrónicos. Los mensajes asincrónicos son enviados
desde un objeto que no va a esperar una respuesta del receptor para continuar con sus
tareas.
 Líneas de Vida
Las líneas de vida son verticales y en línea de puntos, ellas indican la presencia del
objeto durante el tiempo.

 Destrucción de Objetos
Los objetos pueden ser eliminados tempranamente usando una flecha etiquetada
“<<destruir>>” que apunta a una X.
 Loops
Una repetición o loop en un diagrama de secuencias, es representado como un
rectángulo. La condición para abandonar el loop se coloca en la parte inferior entre
corchetes [ ].
Búsqueda simple proyecto directorio web
Diagrama de Paquetes

Los diagramas de paquetes se usan para reflejar la organización de paquetes y sus


elementos. Cuando se usan para representaciones, los diagramas de paquete de los
elementos de clase se usan para proveer una visualización de los espacios de nombres.
Los usos más comunes para los diagramas de paquete son para organizar diagramas
de casos de uso y diagramas de clase, a pesar de que el uso de los diagramas de
paquete no es limitado a estos elementos UML.

Ejemplo de un diagrama de paquetes

Los elementos contenidos en un paquete comparten el mismo espacio de nombre, el


hecho de compartir espacios de nombres requiere que los elementos contenidos en un
espacio de nombre específico tengan nombres únicos.

Los paquetes se pueden construir para representar relaciones tanto físicas como
lógicas. Cuando se elige incluir las clases a los paquetes específicos, es útil asignar las
clases con la misma jerarquía de herencia a los paquetes, las clases que están
relacionadas a través de la composición y las clases que colaboran que también tienen
un fuerte argumento para ser incluidas en el mismo paquete…
Los paquetes se representan en UML 2.0 como carpetas y contienen los elementos que
comparten un espacio de nombre; todos los elementos dentro de un paquete deben
tener un identificador único. El paquete debe mostrar el nombre del paquete y puede
opcionalmente mostrar los elementos dentro del paquete en compartimientos extras.

Combinación de paquetes
Cuando un conector «merge» se usa en un paquete, la fuente de la combinación importa
los contenidos importados y anidados del destino. Si existe un elemento dentro del
origen y el destino, las definiciones del elemento origen se expandirán para incluir las
definiciones del elemento contenidas en el destino. Todos los elementos agregados o
actualizados por una combinación se notan por una relación de generalización desde el
origen hasta el destino.

Importación de Paquetes
El conector «import» indica que los elementos dentro del paquete destino, que en este
ejemplo es una sola clase, se importarán al paquete origen. El espacio de nombre del
paquete origen ganará acceso a la Clase/s de Destino; el espacio de nombre del destino
no está afectado.

Conectores Anidados
El conector anidado entre el paquete destino y los paquetes de origen reflejan lo que
muestran los contenidos del paquete.

Diagrama de paquetes proyecto directorio web


Bibliografía

http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php
http://www-gris.det.uvigo.es/~avilas/UML/node25.html
Libro de UML: EL LENGUAJE UNIFICADO DE MODELADO, Booch, Jacobson,
Rumdaugh, pág. 190- 223
http://www.sparxsystems.com.ar/resources/tutorial/uml2_packagediagram.html
Gutiérrez, D. 2011. UML Diagrama de Secuencia. Universidad de los Andes.(En
línea).. Formato PDF. Disponible en:
http://www.codecompiling.net/files/slides/UML_clase_06_UML_secuencia.pdf

Grau, X y Sánchez, M. s/f. Desarrollo Orientado a Objetos con UML. (En línea). Formato
PDF. Disponible en: http://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf
http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-
uml.pdf

Kendall, K y Kendall, J. 2011. Análisis y diseño de sistemas. 8 ed. México. Pearson


Education. p 600