Docsity El Proceso Unificado Analisis y Especificacion de Requisitos

El proceso unificado: análisis
y especificación de requisitos
Ingeniería Infórmatica
Universidad Rey Juan Carlos (URJC)
69 pag.
Document shared on www.docsity.com

Downloaded by: ab-c-5 (4mgf6mail@gmail.com)
El Proceso Unificado
Tema 7: Análisis y Especificación
de Requisitos
Departamento de Lenguajes y Sistemas Informáticos II

Introducción
Modelo de
Especificado por análisis
Soportado por Modelo de

diseño
Modelo de Distribuido por

casos de uso
Modelo de
despliegue
Implementado por
Modelo de
implementación
Verificado por
Modelo de
pruebas

Introducción
Fases
Flujos de Trabajo Concepción Elaboración Construcción Transición
Requisitos
Análisis
Diseño
Implementación
Pruebas
Iteración Itera. Itera. Itera. Itera. Itera. Itera. Itera.

preliminar #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones

Índice
 >Introducción
 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

Introducción
 Durante la captura de requisitos:
 Lenguaje del cliente (CU)
 Buscar acuerdo
 Pueden quedar aspectos sin resolver (imprecisos) ya que:
 Los CU deben mantenerse tan independientes unos de otros como
sea posible: no centrar detalles, concurrencia, conflictos (ej. cajero)
 Los CU deben describirse en el lenguaje del cliente (LN, no formal)
 Cada CU recoge una funcionalidad completa e intuitiva, es decir, CU
reales. Evitar pequeños y abstractos -> Redundancia
 Objetivo del análisis:
 Analizar los requisitos en profundidad
 En el lenguaje de los desarrolladores

Introducción
 En el análisis:
 Tratamos aspectos internos
 Resolvemos problemas de interferencia, etc. de CU
 Usamos un lenguaje más formal
 Es decir, refinamos los requisitos, para facilitar
 Comprensión
 Preparación
 Modificación
 Mantenimiento…
 Mediante: clases de análisis y paquetes
 Pero existe trazabilidad
 Utilizaremos diferentes diagramas para expresar el modelo de
análisis

Introducción
Modelo de casos de uso Modelo de análisis
Lenguaje del cliente Lenguaje del desarrollador
Vista externa del sistema Vista interna del sistema
Estructurado en casos de uso Estructurado en clases de análisis y paquetes
Como contrato con cliente Por desarrolladores, como precursor del
diseño
Puede contener redundancias, No debería contener redundancias
inconsistencias (entre requisitos) inconsistencias (entre requisitos)
Captura la funcionalidad del Esboza cómo llevar a cabo la funcionalidad:
sistema aproximación al diseño
Define casos de uso que se Define realizaciones de casos de uso, cada
analizarán en el modelo de análisis una el análisis de un caso de uso del modelo
de casos de uso

Introducción
 En los requisitos
 Pensamos en el sistema desde fuera
 En el análisis
 Pensamos en el sistema desde dentro
 Primera aproximación al modelo de diseño e implementación
 Pero no siempre se puede conservar el análisis, ya que los aspectos de
implementación se abordan en el diseño
 Es importante tener una comprensión completa y precisa
de los requisitos antes del diseño
 Aunque esto no suele importar al cliente

Introducción
 Resumen de la importancia del modelo de análisis
 Ofrece una especificación más precisa de los requisitos
 Utiliza lenguaje de los desarrolladores (formalismo)
 Estructura los requisitos de tal forma que facilita su
comprensión, preparación, modificación y mantenimiento
 Primera aproximación al modelo de diseño

Introducción
 Ejemplos de cuándo hacer análisis y cómo usarlo
 Para poder planificar diseño e implementación de cada
incremento analizado (p.e., incrementos concurrentes)
 Proporciona una visión general del sistema, incluso a posteriori
 Para llevar a cabo diseños e implementaciones alternativas.
Análisis proporciona vista unificada
 Para hacer reingeniería con un sistema heredado (reutilización
del análisis)

Introducción
dependencia de traza
Modelo de Relación externa al modelo,

Requisitos Casos de Uso entre dos elementos,
que representan el mismo
concepto con niveles de
significado diferentes y
El modelo Modelo de con reglas específicas
Análisis para derivar uno de otro.
de análisis Análisis
se realiza
a partir de Modelo de Modelo de
los Diseño
Diseño Despliegue
casos
de uso
Modelo de
Implementación
Implementación
Modelo de
Pruebas
Pruebas

Introducción
Modelo de Diagramas de
Caso de Uso Casos de Uso
Diagramas de
Modelo de Clases Incluidos paquetes
Análisis
Diagramas de
Componentes
Modelo de
Diagramas de
Diseño Despliegue
Diagramas de
Modelo de Secuencia
Diagramas de
Despliegue Diagramas de Interacción
Colaboración/
Comunicación
Modelo de
Diagramas de
Implementación Estados
Diagramas de
Modelo de Actividad
Pruebas
Diagramas de
Objetos

Diagramas de comunicación
 Interacción
 Comunicación (colaboración en UML 1.x)
 Secuencia
 [Timing]
 [Interaction overview]
 Tipo de diagrama de interacción que se centra en la
interacción entre objetos (o partes) utilizando una
secuencia de mensajes
 Similares a los de secuencia sin mecanismos de
estructuración (fragmentos)
 Herramientas permiten transformar uno en otro

 Se centra en los enlaces necesarios para pasar un mensaje de
interacción
 Un enlace permite que pase un mensaje.
 Numeración indica el orden
 Mensajes anidados. Punto + original
 Mensajes a la vez, añadiendo letra
 Se puede asignar a una variable
 Learning UML 2.0, Kim Hamilton y Russell Miles, O'Reilly 2006

 * [ || ] [cláusula de iteración]
 [condición]
 Mensajes a sí mismo
 Learning UML 2.0, Kim Hamilton y Russell Miles, O'Reilly 2006

 UML Diagrams

Índice
 Introducción
 Artefactos
 >Modelo de análisis
 Actividades

Artefactos. Modelo de análisis
 Representa la estructura global del sistema (subsistemas
y/o capas en el modelo de diseño).
Descripción
arquitectónica
* *
Modelo de análisis Paquete de análisis
Diagramas de clases
Diagramas de interacción
** Descripción textual
*
Responsabilidades
Atributos
*
Relaciones Realización
Clase de análisis en análisis
Interfaz Control Entidad

Artefactos. Modelo de análisis
 Modelo de análisis:
 Especificación detallada (precisa) de requisitos.
 Refina los casos de uso como colaboraciones entre
clasificadores:
 Realización: relación semántica entre clasificadores, en la que uno
realiza (implementa) el comportamiento especificado por el otro
 Colaboración: conjunto de clases, etc., que colaboran para
proporcionar un comportamiento
Gestionar asignaturas Realización en análisis

participante
UI asignaturas Gestor de asignaturas Asignatura

Índice
 Introducción
 Artefactos
 >Clases de análisis
 Actividades

Artefactos. Clases de análisis
 Representa una abstracción de lo que serán una o varias clases
o subsistemas en diseño.
 Características:
 Centrado en requisitos funcionales. No funcionales (especiales) en
diseño (aquí se anotan=
 Evidente en el contexto del dominio del problema (conceptual)
 Más responsabilidades que operaciones y signaturas
 Descripción textual de un conjunto cohesivo del comportamiento de una
clase
 Atributos reconocibles en el dominio del problema (conceptuales).
A veces pasan a ser clases en diseño
 Relaciones conceptuales
 Tres estereotipos básicos:
 Interfaz, control o entidad

Clase de análisis Resposabilidades

Atributos
Relaciones
Interfaz Control Entidad

 Clases límite o interfaz
 Modelan interacción entre sistema y actores
 Interfaz conceptual del sistema (ventanas, formularios, ...)
 Presentar, recibir información, peticiones…
 No cómo se lleva a cabo
 Modelan los requisitos en los límites del sistema
 Cambios aislados <<boundary>>
IU Matriculación
 Asociadas con al menos un actor y viceversa
IU Matriculación
Estudiante UI Matriculacion

 Clases Control
 Se usan para representar el control de un caso de uso
concreto
 Representan la coordinación, secuencia, transacciones y
control de otros objetos
 Lógica del negocio, cálculos que no se puede asignar a una
información concreta
 No encapsulan ni interacciones con el usuario ni problemas de
almacenamiento de información
<<control>>
GestorMatricula
Estudiante UI Matriculacion GestorMatricula GestorMatricula

 Clases Entidad
 Representan la información significativa para el sistema
 Modelan la información de larga vida (persistencia)
 Pueden provenir de las entidades del dominio o de las del
negocio, pero no tienen por qué corresponderse
completamente
 Pueden ser pasivas o activas (comportamiento complejo)
 Encapsulan información y operaciones asociadas <<entity>>
Alumno
Estudiante UI Matriculacion GestorMatricula Alumno Alumno
26
Factura
PlanificadorPagos cambiaestado
Comprador IU Solicitud Pagos
planifica factura

Índice
 Introducción
 Artefactos
 >Realización en análisis de los casos de uso
 Actividades

Artefactos. Realización en análisis de los
casos de uso
 Es una colaboración que describe cómo se realiza en
análisis un caso de uso en términos de clases de análisis y
sus interacciones
 Solución que implementa un caso de uso en términos de las
relaciones entre clases y objetos y su interacción para
conseguir la funcionalidad deseada
Realización Colaboración
Modelo de casos de uso Modelo de análisis
Flujo de eventos-análisis
Gestionar asignaturas Realización en análisis
Diagrama de clases
Diagramas de interacción
<<trace>>
Requisitos especiales
Use case Realización en análisis

casos de uso
 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
 Requisitos no funcionales si aparecen (si no se deja para el
diseño)

casos de uso. Diagramas de clases
 Una clase de análisis puede participar en varias
realizaciones
 Responsabilidades, atributos y asociaciones pueden ser
relevantes para una única realización de un caso de uso

casos de uso
 Diagramas de clases: clases participantes
 >Diagramas de interacción: escenarios del CU
 Requisitos no funcionales si aparecen (si no se deja para el
diseño)

casos de uso. Diagramas de interacción
 La secuencia de acciones en un caso de uso comienza
cuando un actor envía un mensaje a un objeto interfaz
 Usaremos diagramas de comunicación(colaboración)
 Tipos de objetos:
 De interfaz: puede participar en dos o más instancias de caso
de uso, pero a menudo se crean y se finalizan dentro de una
sola realización de caso de uso
 De entidad: suele tener una vida larga y participar en varias
realizaciones de caso de uso
 De control: suelen encapsular el control asociado con un caso
de uso concreto, aunque puede participar en más de una
realización de casos de uso

casos de uso. Diagramas de interacción
3: seleccionar (asignatura, ficheroNotas)
4: publicar (asignatura, ficheroNotas)

1: publicar notas 5: Notas (ficheroNotas)
7: OK 6: OK
: UI Profesor : GPub : Asignatura
: Profesor
2: visualizar (“¿asignatura?")
8: visualizar (notas publicadas)

Artefactos. Realización en análisis de casos
de uso. F. de eventos y Req. no funcionales
 Diagramas de clases: clases participantes
 Diagramas de interacción: escenarios del CU
 Para clarificar los diagramas de colaboración: descripción textual
 Si es muy complejo ¿no será mejor dividir el caso de uso?
 Requisitos no funcionales si aparecen (si no, se deja para el
diseño)
 Asignados a casos de uso.
 Se recogen si aparecen.

Índice
 Introducción
 Artefactos
 >Paquetes de análisis
 Actividades

Artefactos. Paquetes de análisis
 Para organizar los artefactos de análisis: clases de análisis,
realización de casos de uso y otros paquetes.
*
Paquete de análisis
* *
Realización
Clase de análisis en análisis

 Fuertemente cohesionados y débilmente acoplados.
 La cohesión es la medida cualitativa de lo estrechamente
relacionados que están los elementos internos de un módulo
 El acoplamiento es un concepto abstracto que nos indica el
grado de interdependencia entre módulos.
 Son conceptuales, aunque ...

 Características
 Pueden representar una separación de intereses de análisis:
analizarse de forma separada por diferentes desarrolladores
con diferente conocimiento del dominio.
 Los paquetes de análisis se deben crear basándonos en
requisitos funcionales y en el dominio del problema y deberían
ser reconocibles por las personas con conocimiento del
dominio. No deben basarse en requisitos no funcionales o en
el dominio de la solución.
 Los paquetes de análisis probablemente se convertirán en
subsistemas en diseño

Índice
 Introducción
 Artefactos
 >Actividades

Actividades del análisis en el PU
 La creación del modelo de análisis comienza identificando:
 Los paquetes de análisis
 Las clases de entidad evidentes
 Los requisitos especiales comunes
 Esta identificación se realiza de forma continua a medida que el
modelo de análisis evoluciona.
 Después se realiza cada caso de uso en términos de clases de
análisis exponiendo los requisitos de comportamiento de cada
clase (creando responsabilidades), atributos y relaciones.
 Según se avanza se refinan y mantienen los paquetes de análisis

Actividades del análisis en el PU
 Para ilustrar las actividades, utilizaremos el ejemplo del
cajero automático.

Índice
 Introducción
 Artefactos
 Actividades
 >Análisis de los casos de uso

Actividades. Análisis casos de uso
 Analizamos cada caso de uso para:
 >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.
 Capturar/asignar requisitos no funcionales a clases de análisis.

Actividades. Análisis casos de uso.
Identificar las clases de análisis
 Identificar las clases de análisis
 Clases entidad se derivan de la descripción del caso de uso o
de las clases del modelo del dominio.
 Una clase interfaz por cada actor (protocolo de
comunicación).
 Una clase de control que gobierne el flujo del caso de uso
 Representar las clases de análisis en un diagrama de clases
 Considerar las clases ya existentes

Análisis del caso de uso: “Validar usuario”

 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.
 Capturar/asignar requisitos no funcionales a clases de análisis.

Actividades. Análisis casos de uso.
Distribuir comportamiento entre las clases
 Describir las interacciones entre objetos
 Utilizar diagramas de comunicación/colaboración
 Instancias y enlaces
 1 diagrama de colaboración por cada camino del caso de uso
(escenarios)
 Sobre los diagramas de colaboración:
 Inicia un actor
 Expresión de las interacciones: mensajes

 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.
 >Capturar/asignar requisitos no funcionales a clases de análisis.
 Incorporar a la realización los requisitos especiales, para tratarlos en
el diseño (persistencia, transacciones por hora…)

Análisis del caso de uso: “Validar usuario”
Camino Básico
 Caminos alternativos:
 “Anular transacción”
 “código incorrecto” *
 si 3 veces error: cancelar y quedarse con la tarjeta

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

Análisis del caso de uso: “Sacar dinero”
Camino básico
 * MagicDraw: Opción: Show stereotypesText and Icon
 En el cajero no hay dinero
 Se ha superado el límite diario
 No hay saldo…

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

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 de
destino.
 Comprobar primero si hay saldo y luego sacar

Diagrama de clases completo (ejemplo)

Índice
 Introducción
 Artefactos
 Actividades
 >Análisis de las clases

Actividades. Análisis de las clases
 >Identificar las responsabilidades
 Identificar atributos
 Identificación de asociaciones y agregaciones
 Identificación de generalizaciones
 Capturar requisitos especiales

 Identificar responsabilidades
 En cada caso de uso, ver qué papel juega (diagramas de
colaboración).
 Combinar papeles y describirlos juntos.

Análisis de las clases. Identificar
responsabilidades. “Validar usuario”
 Secuencia correcta
IU Cajero Gestor de Autenticación

Mostrar (Ingrese Clave) Validar (DatosTarjeta, Clave)
Mostrar (Mensaje)
Mostrar (Seleccione Opción)
Usuario
Leer Tarjeta
Leer Clave Validar (DatosTarjeta, Clave)

responsabilidades. “Validar usuario”
 Código Incorrecto

Mostrar (Mensaje) Validar (DatosTarjeta, Clave)
Leer Tarjeta
Usuario
Leer Clave
Validar (DatosTarjeta, Clave)

responsabilidades. “Sacar dinero”
 Secuencia correcta

Cuenta
Mostrar (Mensaje) Validar (DatosTarjeta, Clave)
Egreso (Cantidad)
Leer Tarjeta Usuario
Leer Clave Validar (DatosTarjeta, Clave)
Leer importe Gestor de Sacar Dinero
Entregar Dinero (Cantidad) Sacar (Cantidad)
Entregar Tarjeta
 Identificar las responsabilidades
 >Identificar atributos

 Suelen ser nombres.
 Los tipos son conceptuales y se deben intentar reutilizar
 Las instancias de atributos no se comparten entre clases
 Se redefine en su propia clase
 Si exceso de atributos (clase compleja), separar clases
 Tipos:
 Clases entidad: derivados del dominio.
 Clases interfaz
 Con actores humanos: campos de texto, etiquetas, etc
 Con subsistemas externos: propiedades de la interfaz de comunicación.
 Clases control: estado de la sesión actual, cálculos, acumulados...

Análisis de las clases. Identificar atributos
“Validar usuario”. Secuencia correcta
IU Cajero
Gestor de Autenticación
Contador
Usuario
DatosTarjeta, Clave

Análisis de las clases. Identificar atributos
“Transferencia”. Secuencia correcta
Interfaz de cajero Gestor de Autenticación

Contador
UsuariosDelBanco Cuenta
Saldo, Límite
DatosTarjeta,Clave

Análisis de las clases
Clase Atributos Responsabilidades
IU Cajero “Definir IU” Mostrar (mensaje)
Leer (tarjeta); leer (clave)
Leer (cantidad)
Entregar Dinero (cantidad)
ContarBilletes
Validar (Cantidad)
Leer (opciones)
Usuario DatosTarjeta, Clave Validar (DatosTarjeta, Clave)
Cuenta Saldo Ingreso (Cantidad); Reintegro
Límite diario (Cantidad)
Gestor de Autenticación Contador Autenticar (DatosTarjeta, Clave)
Gestor de Sacar Dinero Sacar (Cantidad)
Gestor de Transferencia Transferencia (NroCuenta, Cantidad)
… … …

 >Identificación de asociaciones y agregaciones
 Definir multiplicidad y papeles
 Agregación y composición
 Identificar generalizaciones y/o especializaciones entre clases

 >Identificación de generalizaciones
 Para extraer comportamiento compartido y común entre
clases de análisis, a nivel alto
 >Capturar requisitos especiales
 Requisitos no funcionales asociados a una clase de análisis que
se tratarán en diseño e implementación

Índice
 Introducción
 Artefactos
 Actividades
 >Análisis de los paquetes

Actividades. Análisis de los paquetes
 Con el objetivo de refinarlos
 Paquetes débilmente acoplados
 Elementos cohesionados
 Se identifican las clases que tienen la dependencia con
clases de otros paquetes para:
 Estimar efecto de futuros cambios
 Asegurarnos que el paquete contiene las clases correctas
(cohesión)
 Reubicar clases contenidas en paquetes que son demasiado
dependientes de otros paquetes.

Bibliografía
 El Proceso Unificado de Desarrollo de Software. I.
Jacobson, G. Booch y J. Rumbaugh. Pearson Prentice-Hall
2007


Docsity El Proceso Unificado Analisis y Especificacion de Requisitos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Docsity El Proceso Unificado Analisis y Especificacion de Requisitos

Cargado por

Copyright:

Formatos disponibles

El proceso unificado: análisis

Document shared on www.docsity.com

Departamento de Lenguajes y Sistemas Informáticos II

Document shared on www.docsity.com

Soportado por Modelo de

Modelo de Distribuido por

Document shared on www.docsity.com

Flujos de Trabajo Concepción Elaboración Construcción Transición

Iteración Itera. Itera. Itera. Itera. Itera. Itera. Itera.

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Modelo de Relación externa al modelo,

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

 Learning UML 2.0, Kim Hamilton y Russell Miles, O'Reilly 2006

Document shared on www.docsity.com

 Learning UML 2.0, Kim Hamilton y Russell Miles, O'Reilly 2006

Document shared on www.docsity.com

Document shared on www.docsity.com

Interfaz Control Entidad

Document shared on www.docsity.com

Gestionar asignaturas Realización en análisis

UI asignaturas Gestor de asignaturas Asignatura

Document shared on www.docsity.com

Document shared on www.docsity.com

Clase de análisis Resposabilidades

Interfaz Control Entidad

Document shared on www.docsity.com

Document shared on www.docsity.com

Estudiante UI Matriculacion GestorMatricula GestorMatricula

Document shared on www.docsity.com

Estudiante UI Matriculacion GestorMatricula Alumno Alumno

Document shared on www.docsity.com

Document shared on www.docsity.com

Modelo de casos de uso Modelo de análisis

Use case Realización en análisis

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

3: seleccionar (asignatura, ficheroNotas)

4: publicar (asignatura, ficheroNotas)

8: visualizar (notas publicadas)

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com

Document shared on www.docsity.com