Tema 3: Captura de requisitos De la visión de los requisitos...... a su captura como casos de uso.
-
Upload
esteban-antonio -
Category
Documents
-
view
3 -
download
0
Transcript of Tema 3: Captura de requisitos De la visión de los requisitos...... a su captura como casos de uso.
Tema 3: Captura de requisitos
De la visión de los requisitos ...
... a su captura como casos de uso
Contenidos1.- Introducción2.- Visión general de la captura de requisitos3.- El rol del flujo de trabajo (FT) de requisitos dentro
del ciclo de vida4.- Artefactos a obtener en los FT “captura requisitos”Anexos: trabajadores y flujo de actividades
1. Introducción• Capturar requisitos: qué
sistema debe construirse–Es difícil
• Usuarios no saben qué quieren–Construir sistema correcto
• Usar lenguaje sencillo en vez de documentos ininteligibles para los usuarios
2. Visión general de la captura de requisitos
• Listar requisitos candidatos• Entender contexto del sistema• Capturar requisitos funcionales• Capturar requisitos no funcionales
2.1. Listar los requisitos candidatos
• Aportar ideas de cómo cada uno ve el sistema y apuntarlas en una lista
• Indicar si deben incorporarse al sistema o no
2.2. Entender el contexto del sistema
• Modelado del dominio–Describir los “objetos” del dominio –Construir un glosario de términos
• Modelado del negocio–describir los procesos
2.3. Capturar los requisitos funcionales
• Encontrar casos de uso
2.4. Capturar los requisitos no funcionales
• Son propiedades o restricciones del sistema– no acerca de lo que hay que hacer
Resumen de la visión general de los requisitos
• HAY QUE CAPTURAR LOS REQUISITOS:
• NECESIDADES DE ALMACENAMIENTO DE DATOS– Modelo del Dominio (o Modelo del Negocio)
• NECESIDADES DE FUNCIONALIDADES DEL SISTEMA– Modelo de Casos de Uso y Requisitos Adicionales
3. Rol del Flujo de Trabajo de requisitos en el CV
Requisitos
Diseño
Implementación
Prueba
Análisis
ite r.# 1
ite r.# 2
ite r.# n
ite r.# n+1
ite r.# n+2
iter.#m
ite r.#m +1
Inicio Elaboración Construcción Transición
Iteraciones:
En el PUD lo que se hace fundamentalmente es obtener el MODELO DE CASOS DE USO
Rol del FT de requisitos en el CV
• Fase de iniciación: identificar la mayoría de los casos de uso y detallar los más críticos (10%)
• Fase de elaboración: capturar hasta el 80% de requisitos (y tener el 5-10% implementados)
• Fase de construcción: capturar e implementar el resto
• Fase de transición: no hay captura de requisitos
Pero el CV del PUD de Rational incluye más FTs…
Modelado del
Negocio
Gestión del
Proyecto
Existe FT donde se obtiene el Mod. del Negocio
CONSIDERAREMOS QUE AMBOS FLUJOS DE TRABAJO SON UNO: FT de CAPTURA DE REQUISITOSSe obtiene: MODELO DEL DOMINIO Y DE CASOS DE USO
4. Artefactos a obtener en los FT “captura requisitos”• casos de uso
• actores• prototipos de interfaces de usuario• glosario • diagrama de clases (modelo del dominio)• descripción de la arquitectura
Artefacto: actor
• Es tipo de usuario (persona)• O sistema externo
• Los actores se encuentran fuera del sistema y colaboran con él
Actor en UML
Empleado Sistema Bancario
SÓLO SI ES EXTERNO AL SISTEMA DE INFORMACIÓN QUE SE ESTÁ MODELANDO
Artefacto: caso de uso• Cada forma en la que un actor utiliza el
sistema• A un caso de uso hay que asociarle:
–Flujo de eventos: secuencia de acciones que indica cómo se interacciona con el actor/es
–Requisitos especiales: descripción textual de los requisitos no funcionales
Caso de Uso en UML
Estudiante
Realizar Matrícula
El estudiante DECIDE EJECUTAR EL C.U.
Caso de Uso en UML
Estudiante
Realizar Matrícula
Sistema Bancario
iniciador
Caso de Uso en UML
• Flujo de eventos (o sucesos)– El estudiante proporciona su DNI– El sistema muestra todas las asignaturas en las que puede
matricularse y que, de momento, no están completas– El estudiante escoge las asignaturas que desea– El sistema calcula el precio de la matrícula y realiza el cobro de la
cuenta del estudiante en el sistema bancario• Flujos de eventos alternativos:
– 1.- El DNI proporcionado no es el de un estudiante. Fin.– 2.- Alguna de las asignaturas está completa. Fin.
• NOTA: Esto puede ocurrir porque el CU se ejecuta concurrentemente
Caso de Uso en UML
• Requisitos especiales– El CU “REALIZAR MATRÍCULA” debe ejecutarse en un
tiempo razonablemente corto.– El CU debe indicar durante su ejecución si alguna de las
asignaturas en las que se quiere matricular está completa• No es aceptable que después de matricularte en una asignatura
te digan que no puede ser, que la asignatura estaba completa– Debe poder ejecutarse de manera simultánea por al
menos 20 estudiantes.– …
Errores típicos en CU
FLUJO DE EVENTOS:• El estudiante introduce el DNI, …• Se almacenan los datos de las matrículas en el sistema,…
Estudiante
Realizar Matrícula
Sistema
iniciador
NO SE TRATA DE UN SISTEMA EXTERNOSINO DEL PROPIO SISTEMA (EL C.U. ES PARTE DE ÉL)
Artefacto: Modelo de CU • Modelo que contiene todos los actores,
CUs y sus relaciones • Con el MCU, clientes y desarrolladores
se ponen de acuerdo• Entrada al análisis, diseño,
implementación y prueba
Modelo de CU (MCU) en UML
EstudianteRealizar Matrícula
Sistema Bancario
iniciador
Escoger Asignaturas
ProfesorPagar Nóminas
iniciador
Relaciones entre actores en UML
Estudiante
Solicitar Carnet Deportivo
Sistema Bancario
iniciador
¿ Y si los profesores también pueden solicitar carnet
deportivo?
Errores típicos en CU
Estudiante
Solicitar Carnet Deportivo
Sistema Bancario
iniciador
Profesor
NO, ya que eso significa que los 3 actores participan en el
caso de uso y eso no es lo que queremos
iniciador
Relaciones entre actores en UML
Estudiante
Solicitar Carnet Deportivo Estud.
Sistema Bancario
iniciador
Profesor
Solicitar Carnet Deportivo Prof.
iniciador
¿SOLUCIÓN? 1: CUs distintos
Relaciones entre actores en UML
Universitario
Solicitar Carnet Deportivo
Sistema Bancario
iniciador
ProfesorEstudiante
SOLUCIÓN 2: (MEJOR)
generalización entre actores
Relaciones entre CU: includes
CASO DE USO A
<<includes>>
ACTOR
CASO DE USO B
El CASO DE USO A includes al CASO DE USO B si SIEMPRE que se ejecuta el caso de uso A, se ejecuta el caso de uso B
Relaciones entre CU: extends
CASO DE USO A
<<extends>>
ACTOR
CASO DE USO B
- cond. C
El CASO DE USO A extends al CASO DE USO B si SIEMPRE que se ejecuta el caso de uso B, si se cumple la condición C, entonces se ejecuta el caso de uso A
Relaciones entre CU: generalización
CASO DE USO A
ACTOR
CASO DE USO B
El C.U. A es una especialización (o un caso particular) del C.U. B. Todo lo que se haya definido que se va a ejecutar para B se ejecutará también para A
Realizar Matrícula
Escoger Asignatura
Profesor
Relaciones entre CU en UML
Estudiante
Identificarse
<<includes>>
<<includes>>
Reservar Libro
Buscar Libro por código
Relaciones entre CU en UML
Lector<<includes>>
AMBOS CASOS DE USO DEBEN TENER SENTIDO EN EL SISTEMA
Realizar Matrícula
Escoger Asignatura
Profesor
Relaciones entre CU en UML
Estudiante
Identificarse
<<extends>>
<<extends>>
- No identificado
- No identificado
Ingresar Dinero
Retirar Dinero
Relaciones entre CU en UML
Cliente
Realizar Transacción
Flujo de eventos de RT:
- Identificar cliente
- Obtener su número de cuenta
- Comprobar que la cuenta no está bloqueada
Errores típicos en CU• Definir CU que no lo son
– No hay actor que lo ejecute– Es un procedimiento interno del sistema
• Ocurre normalmente al “buscar” includes o extends• REGLA DE ORO: Un CU es funcionalidad del sistema
que proporciona algún RESULTADO o VALOR a por lo menos un ACTOR.
Realizar Matrícula
Errores típicos en CU
Estudiante<<includes>>
Seleccionar asignatura
Si al realizar la matrícula, se van seleccionando (en la interfaz) asignaturas en las que matricularse NO ES CASO DE USO
Imprimir informes
Errores típicos en CU
Empleado<<includes>>
Imprimir informe
Un posible flujo de eventos sería:
• El empleado proporciona su identificador• Se seleccionan los informes del empleado aún no impresos• Se imprime cada uno de ellos
Posible excepción: generalización
Ingresar Dinero
Retirar Dinero
Cliente
Realizar Transacción
Flujo de eventos de RT:
- Identificar cliente
- Obtener su número de cuenta
- Comprobar que la cuenta no está bloqueada
En este caso no parece que “Realizar Transacción” sea un CASO DE USO REAL, pero PUEDE resultar ÚTIL para no repetir muchos flujos de eventos. Puede ocurrir en el caso de GENERALIZACIÓN
Artefactos: glosario y prototipo de interfaz
• GLOSARIO: Documento donde se definen los términos más comunes e importantes utilizados
• PROTOTIPO DE INTERFAZ DE USUARIO:• ayudan a entender las interacciones entre los
actores y el sistema• conseguir mejores interfaces de usuario
Ejemplo de GLOSARIO• ASIGNATURA: … • ESTUDIANTE: es una persona que está estudiando una carrera en la universidad
UnivX. Necesariamente debe estar matriculado en por lo menos una ASIGNATURA.
• MATRÍCULA: es el resultado de un proceso administrativo por el cual un ESTUDIANTE adquiere el derecho a ser evaluado en dos convocatorias de una ASIGNATURA. Se le asocia a un GRUPO. Tiene derecho a asistir a las clases del PROFESOR responsable de dicha ASIGNATURA en el GRUPO asignado.
• PROFESOR: es una persona que trabaja en UnivX y que imparte al menos una asignatura de una determinada TITULACIÓN. Se encarga de evaluar a todos los estudiantes matriculados en la asignatura y asignados a sus grupos. El profesor no puede ser estudiante en la misma carrera en la que imparte clases, pero sí en otras.
• …
Ej. prototipo de interfaz de CU
Socio
Tomar Préstamo Copia Libro Reservar Libro
<<extends>>
- No disponible
Flujo de eventos:El socio da su número de socio y la signatura del libro que desea tomar en préstamoEl sistema comprueba si existe alguna copia no prestada de dicho libroSi no hay copias disponibles: EXTENDS RESERVAR LIBROSe comprueba que el socio no se pasa de su número máximo de libros en préstamoSe registra el nuevo préstamo con la fecha actual
Ej. prototipo de interfaz de CU
CASO DE USO: TOMAR COPIA LIBRO EN PRÉSTAMO
Área de texto donde aparecerá el número de copia del libro que seha tomado en préstamo.
Si no hay ninguna libre o si el socio ha sobrepasado su númeromáximo de préstamos entonces se indicará aquí mismo.
CancelTOMAR EN PRÉSTAMO RESERVAR LIBRO
SIGNATURA LIBRO:
NÚMERO SOCIO:
Artefacto: modelo del dominio
• Captura los tipos de objetos en el contexto del sistema y sus relaciones.– “cosas” que existen – eventos que suceden
• Seguramente aparecerán en el GLOSARIO
Clase UMLNOMBRE DE LA CLASEatributo1atributo2...
método1 (parámetros): resultadométodo2 (parámetros) : void...
-- responsabilidades de la clase-- texto que indica qué hace, restricciones especiales de uso, etc.
VISIBILIDAD:+ = público- = privado# = visible para
subclases
Los objetos de dicha clase pueden almacenar valores en los atributos y ejecutar sus métodos
Ejemplo: Clase UML
Cliente
- nombre, dirección, tfno: String- fechaNac: Date- Aficiones: Vector(String) ...
+ getNombre(): String,…+ setNombre(n: String): void+ addAficion(a:String): void ...- - almacena datos de clientes
Los tipos (String, Date, void,..) NO son definidos por UML. Se suelen usar los del LP que se escoja
Especialización y Generalización en UML
NOMBRE DE LA SUPERCLASE
atributo1, atributo2 ...
método1 (parámetros),…
La SUBCLASE hereda todos los ATRIBUTOS y los MÉTODOS de la SUPERCLASE.
NOMBRE DE LA SUBCLASE
atribSubClase1, atribSubClase2 ...
metSubc1 (parámetros),…
Ejemplo de Especialización y Generalización en UML
INMUEBLE
direccion: String; precio: float…
PISO
numeroHabitaciones: int,…
GARAJE
cerrado: boolean,…
Asociación en UMLCLASE A CLASE B
suBsusA
1..* 0..1
cardinalidades
Almacenar pares <objeto de A, objeto de B> Indicando CARDINALIDAD
@b1
@b2
@a1
@a2@a3@a4
Objetos de la clase A
Objetos de la clase B
Cardinalidades en UML1 con uno
0..1 con uno o ninguno
* con cero, uno o varios
0..* con cero, uno o varios
1..* con uno o variosn con n exactamenten..m mínimo con n y máximo con m
Nota: n y m son números naturalesEjemplo: 8 , 17 , 7..9 ,…
Ej. de Asociación en UML
propietario 0..*CLIENTE INMUEBLEposee1
Posee 0..*CLIENTE INMUEBLE1
Otra opción es dar un único nombre a la asociación e indicar “cómo se lee”
Ej. de Asociación en UML
P. Pérez Mayor 13 943112232 3/3/89 Leer, Fútbol
K. Sola Mayor 3 943222232 4/3/89 Mus, Monte
Matia 12, 1A 90000.00 3
Hériz 1, 2A 85000.50 2
Hériz 5 15000.50 true
@C1
@C2
@P1
@P2
@G1
@C1
@C2
@P1@P2
@G1ASOCIACIÓN
Asociación n-aria en UMLCLASE A
CLASE B
0..*0..1
CLASE C 0..*
Un par <a,b> conocido puede estar asociado a los
sumo con un solo c
Un par <a,c> conocido puede estar asociado a los b’s que quiera
Un par <b,c> conocido puede estar asociado a
los a’s que quiera
Fijados el resto de objetos que participan en la asociación, ¿con cuántos pueden relacionarse?
Asociación n-aria en UML
<@a1,@c1,@b1><@a1,@c1,@b2><@a3,@c2,@b2><@a4,@c2,@b2>
@b1
@b2
@a1
@a2@a3@a4 @c1
@c2
<@a1,@b1> @c1 <@a1,@b2> @c1<@a3,@b2> @c2<@a4,@b2> @c2
cardinalidad 0..1 en el lado de C
<@c1,@b1> @a1<@c1,@b2> @a1<@c2,@b2> @a3 y @a4
cardinalidad 0..* en el lado de A<@a1,@c1> @b1 y @b2<@a3,@c2> @b2<@a4,@c2> @b2
cardinalidad 0..* en el lado de B
Ej. de asociación n-aria en UMLEstudiante
Asignatura
0..*0..*
Profesor 0..*
Información sobre qué profesores imparten qué asignaturas a qué estudiantes
HAY QUE ESTAR SEGUROS DE QUE SENECESITA UNA ASOCIACIÓN TERNARIA
Ej. de asociación n-aria en UMLEstudiante
Asignatura
**
Profesor
Los estudiantes se matriculan en asignaturasLos profesores imparten asignaturas
ASOCIACIÓN TERNARIA SÓLO SI HAY QUE DISTINGUIR CON QUÉ PROFESOR/ES
SE HA MATRICULADO
imparte
matriculadoEn
*
*
* ≡ 0..*
Ej. de asociación n-aria en UMLEstudiante
Asignatura
**
Profesor *
Los estudiantes se matriculan en asignaturas.Los profesores imparten asignaturas.Cuando un estudiante se matricula en una asignatura, NO todos los profesores que la imparten son sus profesores.
Ej. de asociación n-aria en UMLEstudiante
Asignatura
*0..1
Profesor *
par <est,asig> conocido con 0 ó 1 prof.Un estudiante se puede matricular en una asignatura SÓLO CON UNO DE LOS PROFESORES QUE LA IMPARTE, o no matricularse, claro.
Ej. de asociación n-aria en UMLEstudiante
Asignatura
*0..1
Profesor *
par <est,prof> conocido en 0 o varias asig
Un estudiante se puede matricular con el mismo profesor en DISTINTAS asignaturas o puede que no le corresponda ese profesor.
Ej. de asociación n-aria en UMLEstudiante
Asignatura
*0..1
Profesor *
par <prof,asig> conocido con 0 ó varios est
Un profesor puede impartir o no una asignatura, y si la imparte, entonces puede tener VARIOS estudiantes
Agregación en UML
ES UNA ASOCIACIÓN CON LA SEMÁNTICA “FORMADO POR/FORMA PARTE DE”
CLASE A CLASE B
1..*0..1
CLASE BCLASE A
formadoPor
formaParteDe 1..*
0..1
Ej. de agregación en UML
Coche Rueda
40..1
Motor1
Composición en UMLCLASE A CLASE B
1..*1
CLASE BCLASE A
compuestoPor
esComponenteDe 1..*
1
ES UNA ASOCIACIÓN CON LA SEMÁNTICA “COMPUESTO POR/ES COMPONENTE DE”
Única cardinalidad posible
Si se borra el a, se borran los b
Ej. de composición en UMLCoche Rueda
41
Motor1
En este S.I. no se permite tener “motores” ni “ruedas” sueltos, y al borrar el coche, se borra todo… Seguro que no se trata de un desguace.
Clase Asociación en UMLCLASE A CLASE B
suBsusA
1..* 0..1
Para almacenar <objeto de A, objeto de B, Atrs. PROPIOS>
@b1
@b2
@a1
@a2@a3@a4
Objetos de la clase A
Objetos de la clase B
CLASE C Clase Asociaciónatrib
@c1v1
@c2v2
@c3v3
Objetos de la clase C
Clase Asociación en UMLCLASE A CLASE B
suBsusA
1..* 0..1
CLASE C Clase Asociación
Cada objeto de C se refiere a un único objeto de A y a un
único objeto de B
Clase Asociación en UML
Si se quisiera que uno de C pudiera asociarse con varios de A y con 0 ó 1 de B entonces no se puede usar una clase asociación sino una clase (normal) y 2
asociaciones
CLASE A CLASE B
suBsusA
1..* 0..1
CLASE C
Ej. de clase Asociación en UML
Estudiante Asignatura
* *
Matrícula Clase Asociación
Si se desea poder almacenar el nº de convocatoria, nota obtenida,
curso académico, etc.
matriculadoEn
numConv,nota,…
Clase asociación n-aria en UML
CLASE A
CLASE B
0..*0..1
CLASE C 0..*
CLASE D
Diagrama de clases en UML
Durante la captura de requisitos se utiliza para representar el MODELO DEL DOMINIO.De momento, sólo interesan los ATRIBUTOSde las clases y NO SUS MÉTODOS
1 0..*
susA
suB
0..*
10..5
Clase A
Clase B
Clase C
Clase D
Clase EatrE1
…
atrD1 ..
…
…
…
Clase BDatrBD1 ..
Artefacto: descripción de la arquitectura
• Hay que realizar una descripción preliminar de la arquitectura
• Por lo menos debe dar cabida a los casos de usos con funcionalidad crítica
El Proceso Unificado de Desarrollo de Software es: • Guiado por casos de uso • Centrado en la arquitectura• Con un ciclo de vida iterativo e incremental
Casos de uso críticos• Son los casos de uso importantes para los usuarios
del sistema• que ayudan a encontrar el esqueleto del sistema
(la arquitectura) sobre el que añadir el resto de las funciones requeridas
• También son casos de uso con requisitos no funcionales importantes (rendimiento, tiempo de respuesta, etc.)
Anexo: Trabajadores
• Son las personas responsables de obtener los artefactos anteriores. En realidad se trata más bien de “puestos” que de “personas” ya que una misma persona podría desempeñar más de un puesto o trabajo. Son los siguientes:– Analista de sistema– Especificador de casos de uso– Diseñador del interfaz del usuario– Arquitecto
Trabajadores (2)– Analista de sistema:
• es responsable del modelo de casos de uso (el conjunto de requisitos), encontrar actores y casos de uso, asegurarse de que el conjunto es completo y consistente (con el glosario). No es responsable de especificar en detalle cada caso de uso.
– Especificador de casos de uso: • detalla específicamente casos de uso. Necesita trabajar estrechamente con
los usuarios reales.– Diseñador del interfaz del usuario
• define los prototipos de los interfaces de usuario– Arquitecto
• describe la vista arquitectural del modelo de casos de uso
Anexo: Actividades en el FT de requisitos
• 1.- Encontrar actores y casos de uso• Encontrar actores• Encontrar casos de uso• Describir brevemente cada caso de uso• Describir el modelo de casos de uso como un todo
• 2.- Priorizar los casos de uso• 3.- Detallar un caso de uso
• Estructurar la descripción de un caso de uso• Qué incluir en la descripción de un caso de uso• Formalizar las descripciones de casos de uso
Actividades en el FT de requisitos
• 4.- Prototipo de interfaz de usuario• Crear diseño lógico de interfaz de usuario• Crear prototipo y diseño físico de interfaz de usuario
• 5.- Estructurar el modelo de casos de uso• Identificar descripciones compartidas de funcionalidad• Identificar descripciones de funcionalidad adicionales y
opcionales• Identificar otras relaciones entre casos de uso