análisis e ingeniería de requisitosair-2012-2013]tema4.pdfanálisis e ingeniería de requisitos...

Análisis e Ingeniería de Requisitos – Tema 4 www.kybele.urjc.es AIR - 1

Análisis e Ingeniería de Requisitos Tema 4: Análisis de Requisitos

Curso 2012-2013


Bibliografía Básica

El proceso unificado de desarrollo del software. Ivar Jacobson, Grady Booch, James Rumbaugh. Addison-Wesley

Análisis y Diseño Orientado a Objetos con UML y el Procesos Unificado. Stephen R. Schach. Mc Graw Hill.

Ingeniería del Software. Ian Sommerville,Addison Wesley, 2004ª Ed.


Índice

Visión general

Diagramas UML

Artefactos Modelo de análisis Clases de análisis Realización en análisis de los casos de uso Paquetes de análisis

Actividades Análisis de los casos de uso Análisis de las clases Análisis de los paquetes


Proceso Unificado

Flujos de trabajo principales (Workflows)

Requisitos

Diseño

Implementación

Prueba

Análisis

Planificación Anál. Riesgos Preparación

Elaboración Construcción Verificación

Transición

Fases Flujos de trabajo

Iteración(es) Inicial(es)

Iter. #1

Iter. #2

Iter. #3

Iter. #4

Iter. #5

Iter. #6

Iter. #7

(Adaptado de Jacobson, 1999)

Análisis e Ingeniería de Requisitos – Tema 4 www.kybele.urjc.es

Modelo de análisis

Modelo de diseño

Modelo de despliegue

Modelo de implementación

Modelo de pruebas

Modelo de casos de uso

Análisis Visión general


Requisitos

Pruebas

Implementación

Diseño

Análisis

Modelo de Despliegue

Modelo de Análisis

Modelo de Diseño

Modelo de Implementación

Modelo de Pruebas

Modelo de Casos de Uso

Dependencia de traza




Durante el análisis, analizamoss los requisitos que se describieron en la captura de requisitos, refinándolos y estructurándolos.

En la captura de requisitos:

Los casos de uso deben mantenerse tan independientes unos de otros como sea posible.

• Evitar interferencias, concurrencias y conflictos.

Los caso de usos deben describirse utilizando un lenguaje del cliente.

• Utilización solo de lenguaje natural -> perdemos poder expresivo.

Debe estructurarse cada caso de uso para que forme una especificación de funcionalidad completa.

• No estructurar casos pequeños

• Llegar a un equilibrio entre comprensibilidad y mantenibilidad.



Modelo de Casos de Uso Modelo de Análisis

Lenguaje del cliente (impreciso) Lenguaje del desarrollador

Vista externa del sistema Vista interna del sistema

Estructurado por casos de uso Estructurado por clases y paquetes

Utilizado como contrato entre

cliente-desarrolladores

Utilizado fundamentalmente por

desarrolladores para entender el

sistema

Redundancias, inconsistencias,

ambigüedades, etc. entre requisitos

No debería contener redundancias

ni inconsistencias de requisitos

Captura la funcionalidad del sistema Captura cómo llevar a cabo la

funcionalidad dentro del sistema

Define casos de uso que se

analizarán con más profundidad en el

modelo de análisis

Define realizaciones de casos de uso,

y cada una de ellas representa el

análisis de un caso de uso


Análisis Diagramas UML

Modelo de

Diseño

Modelo de

Pruebas

Modelo de

Despliegue

Modelo de

Implementación

Diagramas de

Casos de Uso

Diagramas de Clases

Diagramas de

Componentes

Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de

Estados

Diagramas de

Actividad

Diagramas de

Objetos

Modelo de

Casos de Uso

Diagramas de

Interacción

Modelo de

Análisis

Ayuda a refinar requisitos y estructurar los requisitos



¿Cuál es el objeto de análisis?

El modelo de análisis ofrece una especificación más precisa de los requisitos.

El modelo de análisis se describe utilizando el lenguaje de los desarrolladores. Puede introducir mayor formalismo.

El modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación, y en general, su mantenimiento.

El modelo de análisis puede considerarse como una primera aproximación al modelo de diseño.



Leemos:

¿Es preciso hacer siempre el análisis?

• Vemos caso concretos.

¿Cuál es el papel del análisis en el ciclo de vida del

software?

• La forma de ver y emplear el análisis de un

proyecto a otro puede variar. Vemos tres

variantes.


Índice

Visión general

Conceptos de UML




Conceptos de UML

Clasificador Concepto discreto en el modelo que tiene identidad, estado,

comportamiento, y relaciones

Tipos de Clasificadores Elementos del Sistema:

• Clase • Interfaz • Tipos de datos

Conceptos de Comportamiento: • Caso de Uso

Elementos del entorno: • Actor

Estructuras de implementación: • Componente • Nodo • Subsistema


Conceptos de UML

Otros conceptos: Clase

Conjunto de objetos con estructura, comportamiento, relaciones, y semántica común

Objeto

Estructura + operaciones + estado interno + identidad Un objeto es una instancia de una clase

Realización

Relación semántica entre clasificadores, en la cual un clasificador especifica un contrato que otro clasificador se compromete a llevar a cabo

Colaboración

Define las interacciones que han de producirse entre los objetos con el fin de que estos puedan desempeñar su papel


Índice

Visión general

Conceptos de UML




Artefactos

Modelo de Análisis

Modelo de análisis: Especificación detallada (precisa) de requisitos

Refina los casos de uso como colaboraciones

Clasificadores: clases de análisis, paquetes

Colaboraciones: realizaciones de los casos de uso, interacciones

Gestionar Matrícula Realización en análisis

UI Matriculación Gestor de Matrículas Alumno


Artefactos

Modelo de Análisis

Modelo de análisis Representa la estructura global del sistema (subsistemas y/o capas en el

modelo de diseño)

*

Clase de análisis

Paquete de análisis

Realización en análisis

Modelo de análisis

*

* *

* *

Diagramas de clases Diagramas de interacción Descripción textual

Interfaz Control Entidad

Responsabilidades

Atributos

Relaciones

Descripción arquitectónica


Artefactos

Clases de Análisis

Representan una abstracción de lo que serán una o varias clases en diseño

Características: Se centran en Requisitos Funcionales, pospone los no funcionales (Req. especiales) Contexto del dominio del problema (más conceptual) Comportamiento definido mediante responsabilidades de nivel más alto y menos formal

Responsabilidad: descripción textual de un conjunto cohesivo del comportamiento de una clase Atributos a un nivel alto (tipos conceptuales y reconocibles en el dominio del problema). En diseño son tipos de L. de programación Con frecuencia los atributos de análisis son clases en diseño e implementación

Relaciones a nivel conceptual

Tipos: de interfaz, de control o de entidad


Artefactos

Clases de Análisis

Clases de análisis

Clase de análisis

Interfaz Control Entidad

Resposabilidades

Atributos

Relaciones


Artefactos

Clases de Análisis

Ejemplo: Un sistema de enseñanza virtual Actor: Estudiante

Caso de Uso: Matricularse

……

Estudiante

Matricularse

Sist. de enseñanza virtual

Matricularse


Artefactos

Clases de Análisis: Interfaz

Modelan la interacción entre el sistema y los actores, implica recibir (y

presentar) información y peticiones de (y hacia) los usuarios y los sistemas externos

Modelan las partes del sistema que dependen de sus actores, por lo que clarifican y reúnen los requisitos en los límites del sistema

Representan la interfaz del sistema (ventanas, formularios, ...), pero con poco detalle

Cada clase interfaze debe asociarse al menos con un actor

IU Matriculación

IU Matriculación

<<boundary>>

IU Matriculación

Estudiante UI Matriculacion


Artefactos

Clases de Análisis: Control

Se usan para representar el control de un caso de uso concreto

Representan coordinación, secuencia, transacciones y control de otros objetos

Se usan para encapsular el control de un caso de uso concreto (un proceso laboral, de control o de cálculo)

No representan ni interacciones con el usuario ni problemas de almacenamiento de información. Manejan y coordinan las acciones y los flujos de control principales, delegando trabajo a otros objetos (de interfaz, de entidad)

GestorMatricula GestorMatricula

<<control>>

GestorMatricula

Estudiante UI Matriculacion GestorMatricula


Artefactos

Clases de Análisis: Entidad

Modelan la información y el comportamiento asociado de algún fenómeno o concepto (persona, objeto y suceso del mundo real).

Persisten durante la aplicación.

Pueden provenir de las entidades del dominio o de las del negocio, pero no tienen por qué corresponderse completamente

Diferencia: clases entidad -> objetos manejados por el sistema, clases de entidad del negocio -> objetos presentes en el negocio en general.

Pueden ser pasivas o activas (comportamiento complejo)

Encapsulan información y operaciones asociadas

Suelen mostrar una estructura de datos lógica y contribuyen a comprender de qué información depende el sistema

Alumno

Alumno Alumno

<<entity>>

Estudiante UI Matriculacion Alumno GestorMatricula


Artefactos

Realización de Casos de Uso

Realización de los casos de uso en análisis Colaboración dentro del modelo de análisis que describe cómo se lleva a

cabo y se ejecuta un caso de uso determinado en términos de las clases de análisis y sus interacciones.

La realización en análisis de un caso de uso, incluye: Diagramas de clases: clases participantes

Diagramas de interacción: escenarios del CU

Descripción textual del flujo de eventos (sucesos)

Nada de requisitos no funcionales (hasta el diseño).

Modelo de casos

de uso Modelo de análisis

Use case Realización en análisis

<<trace>>

Traza directa hacia un caso de uso concreto del modelo de casos de uso


Artefactos


Realización de los casos de uso en análisis

Diagramas de clases Una clase de análisis puede participar en varios casos de uso.

Algunas responsabilidades, atributos y asociaciones suelen ser específicos de un sólo caso de uso.

Estudiante UI Matriculación Gestor

Matricula

Alumno

Diagrama de clases para la realización del caso de uso

“Matricularse”


Artefactos



Diagramas de interacción Representan como interactúan cooperativamente los objetos para

implementar el comportamiento definido por los casos de uso.

La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje al sistema.

Una interacción es un conjunto de mensajes que se intercambian dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación)

En análisis se suelen utilizar diagramas de colaboración (también se podrían utilizar diagramas de secuencia)



Diagramas de interacción

Artefactos


Diagrama de colaboración para la realización del caso de uso “Matricularse” del actor “estudiante”

AIR - 27


Ejemplo

Pagar Factura

Descripción:

El Sistema de Facturación y Pago ofrece un caso de uso llamado pagar factura, que lo utiliza un comprador para planificar los pagos de las facturas por los bienes que el/ella ha solicitado y recibido.


Ejemplo

Pagar Factura

Descripción paso a paso del caso de uso: Después de que el caso de uso comience, el comprador ya ha

recibido la factura (enviada por otro caso de uso llamado “Enviar Factura al Comprador”), y también ha recibido los bienes y servicios demandados:

1. El comprador visualizará las facturas recibidas e indicará la factura que desea pagar. El sistema comprobará las facturas con sus correspondientes confirmaciones de pedidos antes de mostrar la lista de facturas a pagar al comprador.

2. El comprador seleccionará las facturas y planificará el pago por banco. El sistema genera una solicitud de pago para dicha factura.


Ejemplo

Pagar Factura


Artefactos



Flujos de eventos Una realización de un casos de uso pueden ser difícil de leer, es útil

un texto adicional que los explique.

Describir en términos de objetos (no mencionar atributos,

responsabilidades, asociaciones)

Si es muy complejo ¿no será mejor dividir el caso de uso?

Requisitos no funcionales Asignados a casos de uso

Se recogen si aparecen


Ejemplo

Pagar Factura

Flujo de eventos: El comprador indica que desea consultar las facturas a través de IU Pagar

Facturas (1,2). El Comprobador de Facturas comprobará las facturas con sus correspondientes confirmaciones de pedidos antes de mostrar la lista de facturas del comprador (comprobación que depende de las reglas de negocio del comprador: comparación de precio, fecha entrega, contenido factura con confirmación pedido,… ). El objeto Comprobación de Facturas utiliza las reglas del negocio para decidir las preguntas a hacer a los objetos Pedidos (3,4) y cómo analizar las respuestas. Una vez analizadas las facturas estas se mostrarán a través de la IU Pagar Facturas (5,6). Las facturas a pagar podrían quedar marcada de alguna forma por el IU Pagar Facturas, quizás mediante un color diferente que lo resalte.

El comprador selecciona una factura mediante el IU Pagar Facturas y planifica su pago (7). El IU Pagar Facturas solicita al Planificador de Pagos que planifique el pago de la factura (8). Después el Planificador de Pagos crea una solicitud de pago (9,10,11). El IU Pagar Facturas mostrará al comprador la factura en estado “planificada” (14).


Artefactos

Paquetes de Análisis

Un paquete es un conjunto de clases (y otros elementos) relacionadas, generalmente relevante para un pequeño

subconjunto de actores o suficientemente representativo por sí mismo, que puede implementarse o llevarse a cabo como una

sola unidad.


-


Artefactos


Paquetes de análisis Sirve para organizar los artefactos de análisis: clases de análisis,

realización de casos de uso y otros paquetes

Deben incluir artefactos fuertemente cohesionados y débilmente acoplados

No existen en tiempo de ejecución

*

Clase de análisis


Realización

en análisis

* *


Artefactos


Ejemplo:

Transacciones

Consultas

Venta de entradas

Mantenimiento

Reposiciones Cliente

Empleado

Personal

Mto

Cajero automático


Ejercicios Análisis

Ejemplo: Caso de Uso: Registrar perfil de ADN

Ejemplo: Publicar Actas


Ejemplo

Perfil de ADN

Lista de requisitos detallada R1. Para cada perfil se debe registrar la persona solicitante y los

marcadores obtenidos, labor que realizará siempre el biólogo.

R2. Además para cada perfil se debe indicar el responsable que autorizó la prueba.

R3. Igualmente, el biólogo que realizó el perfil y la fecha en que fue realizada.


Ejemplo

Perfil de ADN

Describir el modelo de casos de uso

Biólogo

Registrar Perfil

Aplicación de almacenamiento

de perfiles de ADN

R1, R2, R3


Ejemplo

Perfil de ADN

Qué incluir en una descripción de un CU flujo de eventos

Flujo de eventos del caso de uso “Registrar Perfil”

Camino básico

ACTOR SISTEMA

1. El biólogo introduce su login y pwd 2. El sistema valida los datos

3. Introduce el nombre de la persona, los marcadores y el responsable que autorizó la prueba

4. El sistema agrega el nombre del biólogo y la fecha del sistema

5. El sistema solicita la confirmación del usuario para terminar

6. El biólogo acepta la operación y fin del caso de uso.

Caminos alternativos

Evento 3. El actor puede cancelar la operación

Evento 6. El actor puede cancelar la operación.


Ejemplo

Perfil ADN

Diagrama de Clases


Ejemplo

Perfil ADN

Diagrama de interacción


Ejemplo

Perfil ADN

Realización del caso de uso:

Identificar clases de análisis


Ejercicios Análisis

Ejemplo: Caso de Uso: Registrar perfil de ADN

Ejemplo: Publicar Actas



Diagramas de interacción

Artefactos


Diagrama de colaboración para la realización del caso de uso “Publicar notas” del actor “profesor”

AIR - 44


Índice

Visión general

Conceptos de UML




Análisis Ejemplo - Actividades

Usaremos el ejemplo del “cajero automático”

Sacar dinero

Ingresar dinero

Transferencia

Cliente del banco

Validar usuario

<<include>>

<<include>>

<<include>>


Análisis Actividades

Análisis de los casos de uso:

Identificar las clases de análisis necesarias para la realización del caso de uso

Distribuir el comportamiento del caso de uso entre las clases de análisis describir las interacciones entre objetos

Capturar/asignar requisitos no funcionales a clases de análisis




Identificar las clases de análisis:

Clases entidad se derivan de la descripción del caso de uso

Una clase interfaz por cada actor

Generalmente, uUna clase de control que gobierne en flujo del caso de uso




Identificar las clases de análisis: Representar las clases de análisis en un diagrama de clases

Validar usuario Realización en análisis

UsuariosDelBanco

(from Logical View)

Autenticar

(from Logical View)

Interfaz de cajero




Describir las interacciones entre objetos:

Utilizar diagramas de colaboración • Indicar instancias y enlaces

Un diagrama de colaboración por cada camino del caso de uso • Siempre inicia un actor

• La expresión de las interacciones se traduce en mensajes entre objetos


Análisis

Ejemplo – Análisis de los casos de uso

Análisis del caso de uso “Validar usuario” Camino Básico

: Interfaz de cajero : Cliente del banco

1: introducir tarjeta

2: teclear código

3: código

: Autenticar

4: autentica (datos, código)

: UsuariosDelBanco

5: valida (datos, codigo)

6: OK

7: visualiza (opciones)

8: seleccioneOpcion (opciones)


Análisis


Análisis del caso de uso “Validar usuario” Camino Alternativo: Código incorrecto

Faltaría:

• anular transacción (después del 2)

• si 3 veces error: cancelar y quedarse con la tarjeta.



2: teclear código

3: código

: Autenticar


: UsuariosDelBanco


6: Error

7: visualiza (error)

8: teclear código


Análisis


Análisis del caso de uso “Sacar dinero” Realización en análisis

Diagrama de clases

Sacar dinero Realización en análisis

Interfaz de cajero Cuenta

(from Logical View)

Transacción

(from Logical View)

Cliente del banco Interfaz de cajero

(from Use Case View)

Transacción Cuenta


Análisis


Análisis del caso de uso “Sacar dinero” Camino Básico

: Interfaz de cajero

1: sacar dinero

2: teclee importe

3: importe

: Transacción

4: retirarDinero (importe)

: Cuenta

5: reintegro (importe)

6: OK

7: expulsaDinero (importe)

8: retirar tarjeta

9: tarjeta retirada

10: retirar dinero

11: dinero retirado

12: teclear código

: Cliente del banco


Análisis del caso de uso “Sacar dinero” Camino Alternativo: No hay saldo

Faltaría:

• en el cajero no hay dinero.

• se ha superado el límite diario

: Interfaz de cajero : Transacción

: Cuenta


7: no hay fondos


6: no hay saldo

1: sacar dinero

2: teclee importe

3: importe

8: no hay saldo suficiente

9: retirar tarjeta

10: tarjeta retirada

11: teclear código

: Cliente del banco

Análisis



Diagrama de clases completo



Cuenta

Transacción

UsuariosDelBanco

Análisis




Análisis de las clases

Identificar las responsabilidades de las clases de análisis

Identificar atributos y relaciones de las clases de análisis.

Capturar requisitos especiales




Identificar las responsabilidades de las clases de análisis

En cada caso de uso, ver qué papel juega (diagramas de colaboración).

Combinar papeles y describirlos juntos


Análisis

Ejemplo – Análisis de las clases

Análisis de las clases: identificar responsabilidades “Validar usuario”



2: teclear código

3: código

: Autenticar


: UsuariosDelBanco


6: OK



: Cliente del banco

Interfaz del cajero

visualizar “introducir tarjeta”

visualizar “teclear código”

leer código

visualizar (opciones)

seleccioneOpcion (opciones)

Transacción

autentica (datos, código)

UsuariosDelBanco

valida (datos, código)


Análisis


Análisis de las clases: identificar responsabilidades

Interfaz del cajero

visualizar (mensaje)

leer código


leerImporte 3:

expulsaDinero (importe) 7:

Transacción

autentica (datos, código)

retirarDinero(importe)4:


1: sacar dinero

2: teclee importe

3: importe

: Transacción


: Cuenta


6: OK

7: expulsaDinero (importe)

8: retirar tarjeta

9: tarjeta retirada

10: retirar dinero

11: dinero retirado

12: teclear código

: Cliente del banco

UsuariosDelBanco

valida (datos, código)

Cuenta

reintegro(importe) 5:




Identificar atributos

Suelen ser nombres

Los tipos son conceptuales

Clases entidad: derivados del dominio.

Clases interfaz con actores humanos: campos de texto, etiquetas, etc.

Clases interfaz con subsistemas externos: propiedades de la interfaz de comunicación.

Clases control: estado de la sesión actual


Análisis


Análisis de las clases: identificar atributos“Validar usuario”

Interfaz del cajero

Usuarios del banco

Colección (datosCuenta, código)



2: teclear código

3: código

: Autenticar


: UsuariosDelBanco


6: OK



: Cliente del banco

Transacción

codigoCuenta


Análisis


Análisis de las clases: identificar atributos “Transferencia”

Interfaz del cajero

Usuarios del banco

Colección (datosCuenta, código)

Cuenta

saldo

Transacción

codigoCuenta

cantidad


1: transferencia

2: teclee cantidad

3: cantidad

4: teclee cuenta destino

5: cuenta destino

12: transferencia realizada

6: transferencia (cuenta, cantidad)

11: OK

7: reintegro (cantidad)

8: OK

9: ingreso (cantidad)

: Cliente del banco

cuentaOrigen : Cuenta cuentaDestino : Cuenta

10: OK


Análisis


Clase Atributos Responsabilidades

Interfaz de cajero

Los necesarios para definir el interfaz

de usuario

visualizar (mensaje)

leer (tarjeta); leer (código)

leer (importe)

expulsarDinero (importe)

noHayFondos

validar (importe); errorIngreso


UsuariosDeBanco

colección de pares (datosCuenta,

codigo)

validar (datos, código)

Cuenta Saldo

límite diario

reintegro (importe)

ingreso (importe)

Transacción código cuenta

cantidad

autenticar (datos, código)

retirarDinero (importe)

ingresarDinero (importe)

transferencia (cuenta, cantidad)



Análisis de los paquetes

Paquetes débilmente acoplados

Elementos cohesionados

Clases de interacción


Análisis del caso de uso: “Ingresar dinero”



(from Logical View)

Transacción

(from Logical View)

Ingresar dinero



Transacción Cuenta



Camino básico


: Cuenta

6: validar (importe)

1: ingresar dinero

2: teclee importe

3: importe

4: introducir dinero

5: dinero introducido

11: dinero ingresado

7: ingresarDinero (importe)

10: OK

8: ingreso (importe)

9: OK

: Cliente del banco



Camino alternativo: Cantidad incorrecta


• Diagrama de clases



Camino Alternativo: Cantidad incorrecta


1: ingresar dinero

2: teclee importe

3: importe

4: introducir dinero

5: dinero introducido

7: importe incorrecto

6: validar (importe)

: Cliente del banco


Análisis del caso de uso: “Transferencia”

Suponemos que el usuario ya ha sido identificado.

La cuenta origen es la de la tarjeta y hay que teclear la destino.

El importe y el nº de cuenta destino se dan juntos. Mirar primero si hay saldo y luego sacar.



(from Logical View)

Transacción

(from Logical View)

Transferencia


Análisis del caso de uso: “Transferencia” Camino básico



1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

12: transferencia realizada


11: OK


8: OK

9: ingreso (cantidad)

10: OK

: Cliente del banco


Análisis del caso de uso: “Transferencia” Camino Alternativo: No hay fondos en la cuenta origen


cuentaOrigen : Cuenta

1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

10: no hay fondos


9: no hay fondos


8: no hay saldo

: Cliente del banco


Análisis del caso de uso: “Transferencia” Camino Alternativo: Cuenta destino incorrecta



11: rollback

1: transferencia

2: teclee cantidad

3: cantidad


5: cuenta destino

13: error


12: error


8: OK 9: ingreso (cantidad)

10: error

: Cliente del banco


Análisis e Ingeniería de Requisitos Tema 4: Análisis de Requisitos

Curso 2012-2013

análisis e ingeniería de requisitosair-2012-2013]tema4.pdfanálisis e ingeniería de requisitos...

Documents