Analisis

Análisis
1. Visión general.
2. El análisis en el Proceso Unificado de Desarrollo.

2.1 Artefactos.
2.1.1 Modelo de análisis.
2.1.2 Clases de análisis.
2.1.3 Realización en análisis de los casos de uso.
2.1.4 Paquetes de análisis.
2.1.5 Descripción arquitectónica
2.2 Actividades.
2.2.1. Análisis arquitectónico.
2.2.2. Análisis de los casos de uso.
2.2.3. Análisis de las clases.
2.2.4. Análisis de los paquetes.
Ingeniería del software 1

1. Visión general
dependencia de traza
Modelo de
Requisitos Casos de Uso
0RGHORGH
$QiOLVLV
$QiOLVLV
Modelo de Modelo de
Diseño
Diseño Despliegue
Modelo de
Implementación
Implementación
Modelo de
Pruebas
Pruebas

1. Visión general
- Durante la captura de requisitos: lenguaje del cliente.

- Es impreciso: deja problemas sin resolver (ambigüedades).
Modelo de análisis:
- especificación detallada (precisa) de requisitos.
- refina los casos de uso como colaboraciones entre clasificadores:
clasificadores: clases de análisis, paquetes.
colaboraciones: realizaciones de los casos de uso.
Seleccionar asignaturas Realización en análisis
UI selec_asignaturas Gestor de asignaturas Asignatura

1. Visión general
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 contracto - Como precursor del diseño
- Puede contener redundancias, - No debería contener redundancias

inconsistencias (entre requisitos)
- Captura la funcionalidad del sistema - Da forma a la arquitectura para soportar tal

funcionalidad
Utilizaremos diferentes diagramas para expresar el modelo de análisis

1. Visión general
Modelo de Diagramas de
Caso de Uso Casos de Uso
Diagramas de
Clases Incluidos paquetes
Modelo de
Análisis Diagramas de
Componentes
Despliegue
Diseño
Diagramas de
Secuencias
Modelo de
Diagramas de
Despliegue Colaboraciones
Diagramas de
Modelo de Estados
Implementación
Diagramas de
Actividad
Pruebas Objetos
2. El análisis en el Proceso Unificado
2.1 Artefactos.
2.1.3 Realización en análisis de los casos de uso
2.1.5 Descripción arquitectónica.
2.2 Actividades.

)DVHV
$FWLYLGDGHV
&RQFHSFLyQ (ODERUDFLyQ &RQVWUXFFLyQ 7UDQVLFLyQ
5HTXLVLWRV
$QiOLVLV
'LVHxR
,PSOHPHQWDFLyQ
3UXHEDV
Iteración Itera. Itera. Itera. Itera. Itera. Itera. Itera.

preliminar #1 #2 #n #n+1 #n+2 #m #m+1
Ingeniería del software ,WHUDFLRQHV 7

2.1.1. 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
* *
Responsabilidades
* * Diagramas de clases
Diagramas de interacción
Atributos Descripción textual
Relaciones Realización
Clase de análisis en análisis
Interfaz Control Entidad

2.1.2. Artefactos. Clases de análisis
• Representa una abstracción de lo que serán una o

varias clases en diseño.
• Se centra en los requisitos funcionales.
Res posabilidades
A tributos
Relac iones
Clase de análisis
Límite Control Entidad

Clases límite o interfaz

<<boundary>>
Solicitud de pago
Solicitud de pago
Solicitud de pago
- Modelan la interacción entre el sistema y los actores.

- Representan la interfaz del sistema (ventanas, formularios, ...).
- Con poco detalle (NO indicar forma de los widgets).
- Describen la información presentada al actor y las peticiones que
hace el actor al sistema.
Estudiante UI Matriculacion
Clases Control <<control>>
GestorMatricula
GestorMatricula
GestorMatricula
- Representan la coordinación entre objetos.
- Encapsulan el flujo de control de un determinado caso de uso.
- Lógica del negocio, cálculos.
- Ni interacciones con el usuario ni problemas de almacenar
información.
Clases Entidad <<entity>>

Alumno Alumno
Alumno
- Modelan la información de larga vida (persistencia).

- Pueden ser pasivas o activas.
- Encapsulan información y operaciones asociadas.
- Por ejemplo: repositorios de información.
Usuario UI Acceso ControlDeAcceso
Alumno UI Alumno
Permisos
Profesor UI Profesor

2.1.3. 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.
Modelo de casos de uso Modelo de análisis

<<trace>>
Use case Realización en análisis
- La realización en análisis de un caso de uso, incluye:

- descripción textual del flujo de eventos
- diagramas de clases: clases participantes
- diagramas de interacción: escenarios del caso de uso
- Nada de requisitos no funcionales (hasta el diseño).

casos de uso
Diagramas de clase.
- 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.
Profesor UI Profesor GPr Asignatura
Diagrama de clases para la realización del caso de uso

“SXEOLFDUQRWDVGHSUiFWLFDV”

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 una clase límite.
- Utilizar mejor diagramas de colaboración que de secuencia.
3: seleccionar (asignatura, ficheroNotas)
4: publicar (asignatura, ficheroNotas)

1: publicar notas 5: notas (ficheroNotas)
7: OK 6: OK
: UI Profesor : GPr : Asignatura
: Profesor
2: visualizar ("asignaturas")
8: visualizar (notas publicadas)

casos de uso
Flujo de eventos.
- 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.
- Asignados a casos de uso.

- Quizás durante esta fase de análisis se obtengan algunos nuevos.
- Representarlos con restricciones {...}

2.1.4. Artefactos. Paquetes de análisis
Paquete de análisis
* *
Realización
Clase de análisis en análisis
- Para organizar los artefactos de análisis: clases de análisis,

realización de casos de uso y otros paquetes.
- Fuertemente cohesionados y débilmente acoplados.
- No existen en tiempo de ejecución.

2.1.5. Artefactos. Descripción arquitectura
• Los elementos importantes en la descripción

arquitectónica son:
– paquetes de análisis, clases de análisis relevantes.
– Estilo arquitectónico.

2.1 Artefactos.
2.1.3 Realización en análisis de los casos de uso
2.1.5 Descripción arquitectónica.
2.2 Actividades.

2.2. Actividades
• Para ilustrar las actividades, utilizaremos el ejemplo

del cajero automático.
Validar usuario
Sacar dinero
Cliente
del banco
Ingresar dinero
Transferencia

2.2.1. Actividades. Análisis arquitectónico
• Identificar paquetes de análisis
• Identificar clases de entidad “obvias”
• Identificar requisitos especiales

2.2.1.1. Identificar paquetes de análisis.

– Casos de uso que soportan un proceso del negocio.
– Casos de uso para dar soporte a un actor.
– Casos de uso relacionados por <<extend>> y generalización.
– Un caso de uso se realizará en varios paquetes.
Validar usuario Transacciones

bancarias
Gestión de cuentas
bancarias

2.2.1.2 Identificar clases entidad “obvias”.

– Dominio del problema.
– Durante la realización de los casos de uso.
– Intentar atributos y relaciones
– Cuenta. Entre otros atributos tendrá:número de cuenta y saldo

(deducidos de los casos de uso).
– UsuariosDelBanco. Soportará operaciones para autenticar a
los clientes del banco.

• Algunas asociaciones entre las clases de análisis:

- Los usuarios del banco poseen cuentas.
- Las transacciones bancarias las realizan los usuarios
del banco sobre cuentas bancarias.
UHDOL]D
0..n
Cliente del banco Transacción

RSHUD
1..2
SRVHH
1..n
Autenticar UsuariosDelBanco Cuenta

2.2.1.3 Identificar requisitos especiales

– La clase Cuenta será persistente.
– Las cuentas de los clientes pueden estar distribuidas.
– La información transmitida irá cifrada.
– El sistema será tolerante a fallos mediante replicación de
servidores.
– Se establece un índice de disponibilidad de 99% (sólo 1 de
cada 100 operaciones puede no ser realizada).
– El tiempo máximo de respuesta a una petición del cliente será
de 5 segundos.
– .....

2.2.1.4 Identificar estilo arquitectónico

Estilo arquitectónico: es la descripción de los tipos de componentes
y un patrón de su control de ejecución y/o transferencia de datos.
Modelo de referencia: es una división de las funcionalidades junto

con los flujos de datos entre las piezas.
Arquitectura de referencia: es el modelo de referencia planeado para

los componentes software (que implementarán las funcionalidades
definidas en el modelo de referencia) y los flujos de datos entre
componentes.
estilo arquitectónico + modelo de referencia

=
arquitectura de referencia

Ejemplo: un compilador:
• Modelo de referencia: se conoce bien cómo dividir la
funcionalidad del compilador (léxico, sintáctico,
generador de código) y el flujo entre las partes (por
ejemplo, el léxico pasa tokens al sintáctico).
• Estilo arquitectónico: Pipe & filters
• Arquitectura de referencia: cada componente tiene
asignada unafuncionalidad (léxico, sintáctico, ...) y
pasa los datos generados al siguiente elemento de la
cadena.
• Con otro estilo arquitectónico (memoria compartida),
obtendríamos una arquitectura de referencia distinta
(manteniendo el mismo modelo de referencia)
Ejemplo de la arquitectura de un compilador

Secuencial Paralelo
Léxico Léxico Sintáctico Semántico
Sintáctico
Semántico
Representación
Optimizador Interna
Generador
de código


2.2.2. Actividades. Análisis 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.
• 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.
– Una clase de control que gobierne en flujo del caso de uso
– Representar las clases de análisis en un diagrama de clases

Análisis del caso de uso: “Validar usuario”
Validar usuario Realización en análisis
Interfaz de cajero UsuariosDelBanco Autenticar

(from Logical View) (from Logical View)

Describir las interacciones entre objetos
– Utilizar diagramas de colaboración

• instancias y enlaces
– Diagrama de colaboración por cada camino del caso de uso
– Sobre los diagramas de colaboración:

• inicia un actor
• no objetos supéfluos
• expresión de las interacciones: los mensajes no se asignan a
operaciones.

6HFXHQFLDFRUUHFWD
3: código
1: introducir tarjeta 4: autentica (datos, código)
7: visualiza (opciones)
: Cliente del banco 2: teclear código : Interfaz de cajero : Autenticar
5: valida (datos, codigo)
8: seleccioneOpcion (opciones)
6: OK
: UsuariosDelBanco

CyGLJRLQFRUUHFWR
3: código
4: autentica (datos, código)

1: introducir tarjeta
7: visualiza (error)

8: teclear código
6: Error
Faltaría:
- anular transacción (después del 2)
- si 3 veces error: cancelar y quedarse con : UsuariosDelBanco
la tarjeta.

Análisis del caso de uso: “Sacar dinero”
• Suponemos que el usuario ya ha sido identificado (se

ha ejecutado el caso de uso anterior). Ahora
selecciona la opción “sacar dinero”.
• PERO ¿dónde están los datos de la cuenta de la que
se va a sacar dinero?
– 1ª opción: en la clase Interfaz de cajero. Cuando reciba la
orden de sacar dinero debería enviar un mensaje a la clase
Transacción indicando: datos de la cuenta y operación
PROBLEMA: cliente pesado (fat): conoce la lógica del negocio

(cuando interactuar con una clase (Autenticar) o con otra
(Transacción).
Deseamos clientes ligeros (thin) (sacar).

– 2ª opción: en la clase Autenticar.

PROBLEMA: No parece que ésta función sea responsabilidad
de esta clase.
– 3ª opción: en la clase Transacción. Eliminamos la clase

Autenticar y sus responsabilidades (pocas) a Transacción
(que será la única clase control).
PROBLEMA: Si en Transacción ponemos toda la lógica del
negocio, puede llegar a ser muy compleja.
PERO, en este caso no es así.
Además, la clase Interfaz de cajero sólo tiene que
preocuparse de visualizar lo que le envíe Transacción y de
validar los datos de entrada (formato).

Sacar dinero Realización en análisis
Interfaz de cajero Transacción Cuenta

Cliente del banco Interfaz de cajero Transacción Cuenta

(from Use Case View)

6HFXHQFLDFRUUHFWD
11: dinero retirado
9: tarjeta retirada
3: importe
4: retirarDinero (importe)
1: sacar dinero
2: teclee importe 7: expulsaDinero (importe)

: Cliente del banco : Interfaz de cajero : Transacción
8: retirar tarjeta 5: reintegro (importe)
10: retirar dinero 6: OK
12: teclear código
: Cuenta

1RKD\VDOGR
10: tarjeta retirada
3: importe
4: retirarDinero (importe)
1: sacar dinero
2: teclee importe 7: no hay fondos

8: no hay saldo suficiente 5: reintegro (importe)
9: retirar tarjeta 6: no hay saldo
11: teclear código
Falta: : Cuenta
- en el cajero no hay dinero.
- se ha superado el límite diario

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

Cliente del banco Interfaz de cajero Transacción Cuenta


6HFXHQFLDFRUUHFWD
5: dinero introducido
6: validar (importe)
3: importe
1: ingresar dinero 7: ingresarDinero (importe)
2: teclee importe 10: OK

4: introducir dinero 8: ingreso (importe)
9: OK
11: dinero ingresado
: Cuenta

&DQWLGDGLQFRUUHFWD
: Cliente del banco : Interfaz de cajero

&DQWLGDGLQFRUUHFWD
5: dinero introducido
6: validar (importe)
3: importe
1: ingresar dinero
2: teclee importe
: Cliente del banco : Interfaz de cajero
4: introducir dinero
7: importe incorrecto

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.
Evitar condiciones de carrera: mirar primero si hay
saldo y luego sacar.
Transferencia Realización en análisis

6HFXHQFLDFRUUHFWD
5: cuenta destino
3: cantidad
6: transferencia (cuenta, cantidad)

1: transferencia
11: OK
2: teclee cantidad 7: reintegro (cantidad)
9: ingreso (cantidad)
8: OK
4: teclee cuenta destino
10: OK
12: transferencia realizada
cuentaOrigen : Cuenta cuentaDestino : Cuenta

1RKD\IRQGRVHQODFXHQWDRULJHQ
5: cuenta destino
3: cantidad

1: transferencia

1RKD\IRQGRVHQODFXHQWDRULJHQ
5: cuenta destino
3: cantidad

1: transferencia
9: no hay fondos

8: no hay saldo
10: no hay fondos
cuentaOrigen : Cuenta
&XHQWDGHVWLQRLQFRUUHFWD
5: cuenta destino
3: cantidad

1: transferencia
8: OK
¿Cómo sabemos que la cuenta destino es correcta?

&XHQWDGHVWLQRLQFRUUHFWD
5: cuenta destino 11: rollback
3: cantidad

1: transferencia
12: error
8: OK
10: error
13: error
¿Cómo sabemos que la cuenta destino es correcta?

Modelo de análisis
Cuenta
Cliente del banco Interfaz de cajero Transacción

UsuariosDelBanco

2.2.3. Actividades. 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 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
“9DOLGDUXVXDULR´ 6HFXHQFLDFRUUHFWD
3: código
6: OK
,QWHUID]GHFDMHUR 7UDQVDFFLyQ
visualizar “introducir tarjeta” autentica (datos, código)
visualizar “teclear código”
8VXDULRV'HO%DQFR : UsuariosDelBanco
leer código
visualizar (opciones) valida (datos, código)
seleccioneOpcion (opciones)

3: código
6: OK
,QWHUID]GHFDMHUR 7UDQVDFFLyQ
9LVXDOL]DUPHQVDMH autentica (datos, código)
leer código
8VXDULRV'HO%DQFR : UsuariosDelBanco
seleccioneOpcion (opciones)
valida (datos, código)

“9DOLGDUXVXDULR´ &yGLJRLQFRUUHFWR
3: código
4: autentica (datos, código)

1: introducir tarjeta
7: visualiza (error)

8: teclear código
,QWHUID]GHFDMHUR 7UDQVDFFLyQ 6: Error
Visualizar (mensaje) autentica (datos, código)

leer código
8VXDULRV'HO%DQFR
seleccioneOpcion (opciones) : UsuariosDelBanco
valida (datos, código)

“6DFDUGLQHUR´ 6HFXHQFLDFRUUHFWD
11: dinero retirado
9: tarjeta retirada
3: importe 4: retirarDinero (importe)
1: sacar dinero
2: teclee importe 7: expulsaDinero (importe)

: Cliente del banco 8: retirar tarjeta : Interfaz de cajero : Transacción
10: retirar dinero

5: reintegro (importe)
12: teclear código
,QWHUID]GHFDMHUR 7UDQVDFFLyQ 6: OK
Visualizar (mensaje) autentica (datos, código)

leer código retirarDinero (importe) (4)
seleccioneOpcion (opciones) 8VXDULRV'HO%DQFR : Cuenta
leer importe (3) valida (datos, código)

expulsaDinero (importe) (7) &XHQWD
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 de las clases. Identificar atributos
3: código
6: OK
,QWHUID]GHFDMHUR
7UDQVDFFLyQ
códigoCuenta : UsuariosDelBanco
8VXDULRV'HO%DQFR
colección de pares (datosCuenta, codigo)

Análisis de las clases. Identificar atributos
“7UDQVIHUHQFLD´ 6HFXHQFLDFRUUHFWD
5: cuenta destino
3: cantidad
1: transferencia
2: teclee cantidad 11: OK


7: reintegro (cantidad)
12: transferencia realizada
8: OK
,QWHUID]GHFDMHUR 10: OK
7UDQVDFFLyQ
códigoCuenta
&XHQWD cuentaOrigen : Cuenta cuentaDestino : Cuenta
cantidad
saldo
8VXDULRV'HO%DQFR
colección de pares (datosCuenta, codigo)

Análisis de las clases
&ODVH $WULEXWRV 5HVSRQVDELOLGDGHV
Interfaz de cajero “Definir IU” visualizar (mensaje)
leer (cantidad)
expulsarDinero (importe)
noHayFondos
validar (importe)
errorIngreso
UsuariosDeBanco colección de pares validar (datos, código)
(datosCuenta, codigo)
Cuenta saldo reintegro (importe)

ingreso (importe)
Transacción código cuenta autenticar (datos, código)

retirarDinero (importe)
ingresarDinero (importe)
transferencia (cuenta, cantidad)

Identificar asociaciones y agregaciones
– Disminuir el acoplamiento
– No optimizar los caminos de acceso
– Definir multiplicidad y papeles
– Agregación y composición
– Identificar generalizaciones-especializaciones entre clases

2.2.4. Actividades. Análisis de los paquetes
• Paquetes débilmente acoplados
• Clases cohesionadas
• Clases de interacción

Y ahora ¿qué?
• ¿Qué hacemos con los artefactos obtenidos?

• ¿De qué valen en la fase de diseño?
• ¿Hay que mantener y actualizar los productos
generados, o tirarlos?
• ¿Cómo se transita al diseño?

Veremos...
• Paquetes de análisis → subsistemas en diseño
• Clases de análisis → una o varias clases de diseño
• Realización de los casos de uso en análisis →

– ayudan a determinar las clases de diseño que intervendrán en
ese caso de uso
– secuencia de interacciones entre clases de diseño
• Análisis arquitectónico → arquitectura inicial para el

diseño

Casos de Usos de
Usuarios
Usuario
Casos de Usos de
Administrador
Administrador
Casos de Uso de
Profesor
Profesor
Casos de Usos
de Alumno
Alumno
Validar Clave de Acceso
Usuario
Modificar Clave de Acceso
Validar Clave de Acceso Realización de Analisis - Validar

Clave de Acceso
IU Usuario Gestor de Acceso al Usuarios

Sistema

1: Validar (Usuario, Contraseña) 2: Validar (Usuario, Contraseña)
6: Esperar Opcion 5: Visualizar (Menu del Usuario)

: Usuario : IU Usuario : Gestor de Acceso al Sistema
3: Buscar y Verificar (Usuario, Contraseña)
4: Ok(Tipo Usuario)
: Usuarios

Insertar Notas
Profesor
Consultar Notas
Alumno

,QVHUWDU1RWDV
&RQVXOWDU1RWDV
([iPHQHV ([iPHQHV
3UiFWLFDV 3UiFWLFDV
$VLJQDWXUD
$VLJQDWXUD
&XUVR
&XUVR
$UFKLYR
$FHSWDU &DQFHODU
$FHSWDU &DQFHODU
1RWDVGH([iPHQHV 1RWDVGH3UiFWLFDV
$VLJQDWXUD ......... $VLJQDWXUD .........
&XUVR ........ &XUVR ........
Not as de Exám enes Not as de Práct icas
..... .....
..... .....
.... ....
&HUUDU &HUUDU

Insertar Notas Realización de Análisis - Insertar
Notas
IU Profesor Usuarios
(from Casos de Usos de Usuarios)
Gestor de Profesor Profesores

Asignaturas
(from Casos de Usos de Administrador)

3: Buscar DNI de Usuario
: Usuarios
9: Insertar Notas (Opcion, Asignatura, Curso, Archivo) 10: Insertar Notas (Opcion, Asignatura, Curso, Archivo)
4: Buscar Asignatura de Profesor (DNI)
1: Opcion (Insertar Notas) 2: Seleccion (Insertar Notas)
8: Ingresar opcion y datos 7: Visualizar (Insertar Notas) 5: Buscar Asignatura y curso (DNI)
: Profesor : IU Profesor : Gestor de Profesor
14: Esperar Nueva Opcion 13: Visualizar (Menu de Profesor)
6: Visualizar Asignatura (Asignaturas, Cursos)
12: Ok Alta Archivo
: Profesores
11: Alta Notas ( Archivo)
: Asignaturas

Consultar Notas Realización de Análisis - Consultar
Notas
IU Alumno Alumnos
(from Casos de Usos de Administrador)
Gestor de Alumno Usuarios
(from Casos de Usos de Usuarios)
Asignaturas
(from Casos de Uso de Profesor)

15: Cerrar 16: Cerrar
3: Buscar DNI de Usuario
9: Consultar Notas (Opcion, Asignatura, Curso) 10: Consultar Notas (Opcion, Asignatura y Curso)
: Usuarios
1: Opcion (Consultar Notas) 2: Seleccion (Consultar Notas)

4: Buscar Asignaturas Matriculado (DNI)
8: Ingresar Opcion, Asignatura y Curso 7: Visualizar (Consultar Notas) 5: Buscar Asignatura y Curso (DNI)
: Alumno : IU Alumno : Gestor de Alumno

14: Mostar y esperar cierre 13: Visualizar (Notas de Exámenes o Practicas)
6: Visualizar Asignatura (Asignaturas, Curso)

18: Esperar Nueva Opcion 17: Visualizar (Menu de Alumno)
11: Listar Notas (Opcion)
: Alumnos
12: Mostrar (Archivo)
: Asignaturas

Analisis

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Analisis

Hochgeladen von

Copyright:

Verfügbare Formate

Análisis

2. El análisis en el Proceso Unificado de Desarrollo.

Ingeniería del software 1

Ingeniería del software 2

- Durante la captura de requisitos: lenguaje del cliente.

Seleccionar asignaturas Realización en análisis

UI selec_asignaturas Gestor de asignaturas Asignatura

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

- Como contracto - Como precursor del diseño

- Puede contener redundancias, - No debería contener redundancias

- Captura la funcionalidad del sistema - Da forma a la arquitectura para soportar tal

Utilizaremos diferentes diagramas para expresar el modelo de análisis

Ingeniería del software 4

Ingeniería del software 6

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

Ingeniería del software ,WHUDFLRQHV 7

• Representa la estructura global del sistema

Interfaz Control Entidad

• Representa una abstracción de lo que serán una o

Límite Control Entidad

Ingeniería del software 9

Clases límite o interfaz

- Modelan la interacción entre el sistema y los actores.

Clases Entidad <<entity>>

- Modelan la información de larga vida (persistencia).

Usuario UI Acceso ControlDeAcceso

Ingeniería del software 12

Modelo de casos de uso Modelo de análisis

Use case Realización en análisis

- La realización en análisis de un caso de uso, incluye:

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

Ingeniería del software 13

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

Profesor UI Profesor GPr Asignatura

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

Ingeniería del software 14

- La secuencia de acciones en un caso de uso comienza cuando un

3: seleccionar (asignatura, ficheroNotas)

4: publicar (asignatura, ficheroNotas)

8: visualizar (notas publicadas)

Ingeniería del software 15

- Para clarificar los diagramas de colaboración: descripción

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

- Asignados a casos de uso.

Ingeniería del software 16

- Para organizar los artefactos de análisis: clases de análisis,

Ingeniería del software 17

• Los elementos importantes en la descripción

Ingeniería del software 18

Ingeniería del software 19

• Para ilustrar las actividades, utilizaremos el ejemplo

Ingeniería del software 20

• Identificar paquetes de análisis

• Identificar clases de entidad “obvias”

• Identificar requisitos especiales

Ingeniería del software 21

2.2.1.1. Identificar paquetes de análisis.

Validar usuario Transacciones

Ingeniería del software 22

2.2.1.2 Identificar clases entidad “obvias”.

– Intentar atributos y relaciones