El documento presenta información sobre diagramas UML de casos de uso y requisitos. Introduce los casos de uso y define su propósito de describir las interacciones entre actores y el sistema. Explica las relaciones entre casos de uso como generalización, inclusión y extensión.
www.modelado.pnfi.org
Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
www.modelado.pnfi.org
Los Casos de Uso (Ivar Jacobson) describen, bajo la forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario.
Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno.
Los Casos de Uso son descripciones de la funcionalidad del negocio/sistema independientes de la implementación.
Este trabajo fue presentado como parte del curso Ingeniería y calidad del Software ofrecido como parte de la Especialización en Informática y Ciencias de la Computación en la Fundación Universitaria Konrad Lorenz
La Ética en la Ingeniería de Software de Pruebas: Necesidad de un Código ÉticoAntonio Vallecillo
En esta charla se analiza la necesidad de un código ético en el desarrollo de la actividad profesional en el ámbito de la ingeniería de software y, consecuentemente, en las pruebas.(mpartida en el Primer Congreso del Comité Español de Empresas de Pruebas Software (SSTQB). Sevilla, 16/6/2016. http://www.sstqb.es/eventos/gira2016sstqbetapasevilla.html)
Esta presentación le pertenece a Tania Landivar.
Las estructuras de datos lineales (vectores ) obliga afijar por adelantado el espacio a ocupar en memoria, de modo que, cuando se desea añadir un nuevo elemento que rebase el tamaño prefijado del array, no es posible realizar la operación sin que se produzca un error en tiempo de ejecución, para evitar esto se hace uso de las listas enlazadas.
Una lista enlazada es una colección o secuencia de elementos llamados nodos, dispuestos uno detrás de otro, en la que cada elemento se conecta al siguiente elemento por un “enlace” o “referencia”.
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?Software Guru
La entrevista es quizás la técnica más común y con mejor relación costo-beneficio en la etapa de levantamiento (o elicitación) de requisitos (o requerimientos). Sin embargo, muchos desarrolladores descuidan la preparación adecuada para las entrevistas, y las convierten en reuniones ineficaces que generan pérdida de tiempo. El propósito de esta presentación es dar a conocer un conjunto de directrices que orienten la planificación y ejecución de una entrevista. Estos son algunos de los temas a tratar:
- ¿Qué es la entrevista para la obtención de requisitos?
- Directrices fundamentales para una entrevista eficaz
- Habilidades que se requieren para el entrevistador
- Errores comunes en las entrevistas
- Factores que inhiben el entrevistado
- Preparación de la entrevista
- Preparación del guión
- Formatos de entrevista
- Tipos de preguntas
- Documentación de la entrevista
Este trabajo fue presentado como parte del curso Ingeniería y calidad del Software ofrecido como parte de la Especialización en Informática y Ciencias de la Computación en la Fundación Universitaria Konrad Lorenz
La Ética en la Ingeniería de Software de Pruebas: Necesidad de un Código ÉticoAntonio Vallecillo
En esta charla se analiza la necesidad de un código ético en el desarrollo de la actividad profesional en el ámbito de la ingeniería de software y, consecuentemente, en las pruebas.(mpartida en el Primer Congreso del Comité Español de Empresas de Pruebas Software (SSTQB). Sevilla, 16/6/2016. http://www.sstqb.es/eventos/gira2016sstqbetapasevilla.html)
Esta presentación le pertenece a Tania Landivar.
Las estructuras de datos lineales (vectores ) obliga afijar por adelantado el espacio a ocupar en memoria, de modo que, cuando se desea añadir un nuevo elemento que rebase el tamaño prefijado del array, no es posible realizar la operación sin que se produzca un error en tiempo de ejecución, para evitar esto se hace uso de las listas enlazadas.
Una lista enlazada es una colección o secuencia de elementos llamados nodos, dispuestos uno detrás de otro, en la que cada elemento se conecta al siguiente elemento por un “enlace” o “referencia”.
¿Cómo realizar entrevistas eficaces para obtener requisitos de software?Software Guru
La entrevista es quizás la técnica más común y con mejor relación costo-beneficio en la etapa de levantamiento (o elicitación) de requisitos (o requerimientos). Sin embargo, muchos desarrolladores descuidan la preparación adecuada para las entrevistas, y las convierten en reuniones ineficaces que generan pérdida de tiempo. El propósito de esta presentación es dar a conocer un conjunto de directrices que orienten la planificación y ejecución de una entrevista. Estos son algunos de los temas a tratar:
- ¿Qué es la entrevista para la obtención de requisitos?
- Directrices fundamentales para una entrevista eficaz
- Habilidades que se requieren para el entrevistador
- Errores comunes en las entrevistas
- Factores que inhiben el entrevistado
- Preparación de la entrevista
- Preparación del guión
- Formatos de entrevista
- Tipos de preguntas
- Documentación de la entrevista
El curso Ingeniería de Software tiene como objetivo que el estudiante comprenda, mediante el análisis, lectura e interpretación, la forma en que interactúan los elementos y componentes de un sistema de información, e ingeniar y proponer modelos de alternativas de solución a necesidades y problemas encontrados o que permitan aprovechar oportunidades tecnológicas.
En este contexto, la temática presentada en este objeto de aprendizaje está orientada hacia el modelado de comportamiento de un producto software, particularmente a partir del diseño de Casos de Uso, modelo que se utiliza de forma actual para describir la ‘historia de uso de un sistema’, que permite entender y describir requerimientos para el diseño de un producto software.
ROMPECABEZAS DE ECUACIONES DE PRIMER GRADO OLIMPIADA DE PARÍS 2024. Por JAVIE...JAVIER SOLIS NOYOLA
El Mtro. JAVIER SOLIS NOYOLA crea y desarrolla el “ROMPECABEZAS DE ECUACIONES DE 1ER. GRADO OLIMPIADA DE PARÍS 2024”. Esta actividad de aprendizaje propone retos de cálculo algebraico mediante ecuaciones de 1er. grado, y viso-espacialidad, lo cual dará la oportunidad de formar un rompecabezas. La intención didáctica de esta actividad de aprendizaje es, promover los pensamientos lógicos (convergente) y creativo (divergente o lateral), mediante modelos mentales de: atención, memoria, imaginación, percepción (Geométrica y conceptual), perspicacia, inferencia, viso-espacialidad. Esta actividad de aprendizaje es de enfoques lúdico y transversal, ya que integra diversas áreas del conocimiento, entre ellas: matemático, artístico, lenguaje, historia, y las neurociencias.
1. 1Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
D. JavierD. Javier JesúsJesús GutiérrezGutiérrez RodríguezRodríguez
javierj@us.es
www.lsi.us.es/~javierj
Universidad de Sevilla
ETS Ingeniería Informática
Av. Reina Mercedes S/N
41015 Sevilla
Tlf. 954553867
Fax. 954553917
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
2. 2Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Introducción a los casos de uso.
Diagramas de casos de uso de UML.
Relaciones actor-actor y casos de uso-caso de uso.
Ejemplos de diagramas de casos de uso.
Índice
3. 3Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
Introducción a los casos de uso
4. 4
Introducción
Definiciones:
» Proceso de negocio:
Flujo de trabajo de la organización. Existe por sí mismo.
» Requisito:
Característica que el sistema software debe tener.
» Caso de uso:
Técnica para la definición de requisitos funcionales.
5. 5
Introducción
Definiciones:
» Caso de uso:
1. Conjunto de acciones realizadas por el sistema.
2. Producen un resultado observable.
3. Participan actores.
6. 6Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
Diagramas de casos de uso de UML
7. 7
Diagramas de casos de uso
¿Qué casos de uso identificamos?
» Iniciar una nueva partida.
» Descubrir una casilla.
» Marcar una casilla.
¿Quién realiza estos casos de uso?
» El jugador.
8. 8
Diagramas de casos de uso
ud Casos de uso
Buscaminas
Jugador
01. Iniciar partida
02. Descubrir una
casilla.
03. Marcar una
casilla.
9. 9
Diagramas de casos de uso
ud Casos de uso
Buscaminas
Jugador
01. Iniciar partida
02. Descubrir una
casilla.
03. Marcar una
casilla.
Caso de Uso: interacción entre
actores y el sistema que produce un
resultado observable de valor para un
actor.
Asociación: la participación de un
actor es necesaria para realizar el caso
de uso.
Límite del sistema: agrupa casos de
uso dentro de un mismo sistema. Útil
cuando tenemos varios sistemas /
subsistemas.
Actor: alguien o algo externo al
sistema que interactúa con él
desempeñando un rol.
Un caso de uso siempre es iniciado
por un actor externo.
10. 10
Ejercicio: Descripción del problema
Sokoban es un juego de varios niveles.
Cada nivel está compuesto por un jugador, cajas, repisas y muros.
El objetivo del jugador es empujar todas las cajas sobre las repisas.
Cuando esto sucede el jugador pasa al siguiente nivel.
Para mover una caja, el jugador debe colocarse al lado y empujarla.
Si la casilla hacia la que está empujando la caja está libre la caja se
moverá.
Si el jugador se queda bloqueado, es decir, no puede terminar el
nivel, puede reiniciar el nivel perdiendo una vida.
Cuando el jugador pierde todas sus vidas la partida termina.
11. 11
Ejercicio: diagramas de casos de uso
ud Casos de uso
Jugador
Iniciar partida
Mover jugador
extension points:
En la dirección del jugdor
hay una caja
Todas las cajas en repisas
Terminar partida
Mover caja
Cargar un nivel
Reiniciar partida
«include»
«include»
«extend»
«extend»
12. 12Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
Relaciones actor-actor y casos de uso-casos de uso
13. 13
Relaciones
Ya hemos visto la única relación posible entre un actor y un caso
de uso: asociación.
También podemos establecer una única relación entre actores:
generalización.
En UML podemos establecer tres relaciones entre casos de uso:
generalización, inclusión y extensión.
14. 14
Generalización actor – actor.
ud Casos de uso
Pintor
Arqueologo
01. Buscar
restauraciones de
retablos.
02. Buscar
excavaciones
arqueológicas.
Deseamos un tercer actor catalogador
cuya misión sea catalogar retablos y
excavaciones de la misma manera que
un pintor o arqueólogo..
Alternativas:
1. Repetir los casos de uso para el
actor catalogador.
2. Añadir al actor catalogador
Etc…
15. 15
Generalización actor – actor.
ud Casos de uso
Pintor
Arqueologo
01. Buscar
restauraciones de
retablos.
02. Buscar
excavaciones
arqueológicas.
Catalogador
ud Casos de uso
Pintor
Arqueologo
01. Buscar
restauraciones de
retablos.
02. Buscar
excavaciones
arqueológicas.
Catalogador
Añadir al actor catalogador
Definir al actor catalogador
como una extensión de los
actores pintor y
arqueólogo.
16. 16
Inclusiones y extensiones
Un actor administrador puede entrar en
el sistema, dar de alta a un pintor y
marcharse.
Un actor administrador puede entrar en
el sistema, asignar a un pintor una
restauración y marcharse.
Un administrador puede entrar en el
sistema, empezar a asignar a un
pintor una restauración, durante el
proceso darse cuenta de que el pintor
no está en el sistema, darlo de alta
sobre la marcha, terminar la
asignación y marcharse.
Extensión
ud Ejemplos de casos de uso
Administrador
Alta de pintor
Asignación de
pintor a
restauración
«extend»
19. 19
Inclusiones y extensiones
Un actor administrador puede entrar
en el sistema, asignar a un pintor
una restauración y marcharse.
Para elegir una restauración a la que
asignar un pinto, el administrador debe
realizar una búsqueda entre todas las
restauraciones existentes y seleccionar
una.
Inclusión
ud Ejemplos de casos de uso
Administrador
Alta de pintor
Asignación de
pintor a
restauración
Búqeuda de
restauraciones
«extend»
«include»
20. 20Web: www.sevinge.es e-mail: info@sevinge.es
Telf.: 954 091 086 – FAX: 954 460 306
Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
Ejemplos de diagramas de casos de uso
22. 22
Inclusiones y extensiones
Ejercicio: sistema de normativas
» Actor funcionario
• Suscribirse a avisos de normativas.
• Buscar normativas
• Ver detalles de una normativa.
» Actor registrador
• Acceder al sistema con su nombre y clave.
• Registrar normativa.
• Borrar normativa.
• Reemplazar normativa,
23. 23
Inclusiones y extensiones
Funcionario
Consultar normativas
Suscribirse a avisos de normativa
Registrador
Registrar normativa
Borrar normativa
Reemplazar normativa
Acceso al sistema
<<include>>
<<include>>
<<include>>
Ver una normativa
<<extend>>
Subsistema de funcionarios
Subsistema de registradores
24. 24Pabellón de Italia. C/ Isaac Newton s/n. Planta 4ª
Isla de la Cartuja. 41092 Sevilla
Diagramas UML de casos de uso y de requisitosDiagramas UML de casos de uso y de requisitos
Ejercicios
25. 25
Ejercicios
Un sistema automático de cambio de grupos para asignaturas
funciona de la siguiente manera:
El profesor da de alta una asignatura y proporciona al sistema
un listado con los alumnos matriculados en dicha asignatura.
Un alumno que quiera cambiar de grupo en una asignatura
puede consultar las peticiones de cambio.
Si encuentra alguna que le interese, el alumno solicita el cambio
y el sistema lo almacena.
Si no, el alumno puede dejar el cambio que desea por si a otro
alumno le interesara.
Los alumnos sólo pueden consultar y publicitar cambios de las
asignaturas en las que están matriculados.
27. 27
Ejercicios
Se desea desarrollar un sistema de encuentros virtuales (parecido a un chat).
Cuando se conecta al servidor, un usuario puede entrar o salir de un
encuentro.
Cada encuentro tiene un manager.
El manager es el usuario que ha planificado el encuentro (el nombre del
encuentro, la agenda del encuentro y el moderador del encuentro).
Cada encuentro puede tener también un moderador designado por el
manager.
La misión del moderador es asignar los turnos de palabra para que los
usuarios hablen.
El moderador también podrá dar por concluido el encuentro en cualquier
momento.
En cualquier momento un usuario puede consultar el estado del sistema, por
ejemplo los encuentros planeados y su información.
29. 29
Ejercicios
Un sistema personal de bolsa se conecta periódicamente a
servidores que ofrecen información de las cotizaciones.
El sistema personal permite marcar una serie de valores para
realizar un seguimiento y consultar los datos de dichos valores.
Si a la hora de actualizar las cotizaciones uno de los valores
marcados presenta una gran subida o bajada, informará a
usuario de ello.
Hay más de un actorHay más de un actor
31. 31
Ejercicios
Un juego de teléfono móvil dónde participan dos jugadores cada
uno con su propia terminal.
Cuando dos jugadores desean jugar, uno de ellos crea una
nueva partida y el otro se conecta.
El objetivo del juego es manejar una nave y disparar al contrario.
Si uno de los dos jugadores acierta, la partida termina.
Si uno de los dos jugadores deja la partida (o se pierde la
conexión) la partida termina.
