You are on page 1of 74

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

Ingeniería del software 2


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


Ingeniería del software 3
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

Ingeniería del software 4


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

Modelo de Diagramas de
Despliegue
Diseño
Diagramas de
Secuencias
Modelo de
Diagramas de
Despliegue Colaboraciones

Diagramas de
Modelo de Estados
Implementación
Diagramas de
Actividad

Modelo de Diagramas de
Pruebas Objetos
Ingeniería del software 5
2. El análisis en el Proceso Unificado

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 6


2. El análisis en el Proceso Unificado
)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


Ingeniería del software 8
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

Ingeniería del software 9


2.1.2. Artefactos. Clases de análisis

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
Ingeniería del software 10
2.1.2. Artefactos. Clases de análisis
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.
Ingeniería del software 11
2.1.2. Artefactos. Clases de análisis

Usuario UI Acceso ControlDeAcceso

Alumno UI Alumno
Permisos

Profesor UI Profesor

Ingeniería del software 12


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).

Ingeniería del software 13


2.1.3. Artefactos. Realización en análisis de los
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”

Ingeniería del software 14


2.1.3. Artefactos. Realización en análisis de los
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)

Ingeniería del software 15


2.1.3. Artefactos. Realización en análisis de los
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 {...}

Ingeniería del software 16


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.

Ingeniería del software 17


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.

Ingeniería del software 18


2. El análisis en el Proceso Unificado

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 19


2.2. Actividades

• Para ilustrar las actividades, utilizaremos el ejemplo


del cajero automático.
Validar usuario

Sacar dinero

Cliente
del banco
Ingresar dinero

Transferencia

Ingeniería del software 20


2.2.1. Actividades. Análisis arquitectónico

• Identificar paquetes de análisis

• Identificar clases de entidad “obvias”

• Identificar requisitos especiales

Ingeniería del software 21


2.2.1. Actividades. Análisis arquitectónico

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

Ingeniería del software 22


2.2.1. Actividades. Análisis arquitectónico

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.

Ingeniería del software 23


2.2.1. Actividades. Análisis arquitectónico

• 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

Ingeniería del software 24


2.2.1. Actividades. Análisis arquitectónico

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.
– .....

Ingeniería del software 25


2.2.1. Actividades. Análisis arquitectónico

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

Ingeniería del software 26


2.2.1. Actividades. Análisis arquitectónico

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)
Ingeniería del software 27
2.2.1. Actividades. Análisis arquitectónico

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

Ingeniería del software 28


2.2.1. Actividades. Análisis arquitectónico

Ingeniería del software 29


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.

Ingeniería del software 30


2.2.2. Actividades. Análisis casos de uso

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

Ingeniería del software 31


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)

Ingeniería del software 32


2.2.2. Actividades. Análisis casos de uso

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.

Ingeniería del software 33


Análisis del caso de uso: “Validar usuario”
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

Ingeniería del software 34


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

3: código

4: autentica (datos, código)


1: introducir tarjeta

7: visualiza (error)
: Cliente del banco 2: teclear código : Interfaz de cajero : Autenticar

5: valida (datos, codigo)


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.

Ingeniería del software 35


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).


Ingeniería del software 36
Análisis del caso de uso: “Sacar dinero”

– 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).

Ingeniería del software 37


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

Sacar dinero Realización en análisis

Interfaz de cajero Transacción Cuenta


(from Logical View) (from Logical View)

Cliente del banco Interfaz de cajero Transacción Cuenta


(from Use Case View)

Ingeniería del software 38


Análisis del caso de uso: “Sacar dinero”
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

Ingeniería del software 39


Análisis del caso de uso: “Sacar dinero”
1RKD\VDOGR
10: tarjeta retirada

3: importe
4: retirarDinero (importe)
1: sacar dinero

2: teclee importe 7: no hay fondos


: Cliente del banco : Interfaz de cajero : Transacción

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

Ingeniería del software 40


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

Ingresar dinero Realización en análisis

Interfaz de cajero Transacción Cuenta


(from Logical View) (from Logical View)

Cliente del banco Interfaz de cajero Transacción Cuenta


(from Use Case View)

Ingeniería del software 41


Análisis del caso de uso: “Ingresar dinero”
6HFXHQFLDFRUUHFWD
5: dinero introducido
6: validar (importe)

3: importe

1: ingresar dinero 7: ingresarDinero (importe)

2: teclee importe 10: OK


: Cliente del banco : Interfaz de cajero : Transacción

4: introducir dinero 8: ingreso (importe)

9: OK
11: dinero ingresado

: Cuenta

Ingeniería del software 42


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

: Cliente del banco : Interfaz de cajero

Ingeniería del software 43


Análisis del caso de uso: “Ingresar dinero”
&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

Ingeniería del software 44


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

Interfaz de cajero Transacción Cuenta


(from Logical View) (from Logical View)
Ingeniería del software 45
Análisis del caso de uso: “Transferencia”
6HFXHQFLDFRUUHFWD

5: cuenta destino

3: cantidad

6: transferencia (cuenta, cantidad)


1: transferencia

11: OK
: Cliente del banco : Interfaz de cajero : Transacción

2: teclee cantidad 7: reintegro (cantidad)

9: ingreso (cantidad)
8: OK
4: teclee cuenta destino

10: OK
12: transferencia realizada

cuentaOrigen : Cuenta cuentaDestino : Cuenta

Ingeniería del software 46


Análisis del caso de uso: “Transferencia”
1RKD\IRQGRVHQODFXHQWDRULJHQ

5: cuenta destino

3: cantidad

6: transferencia (cuenta, cantidad)


1: transferencia

: Cliente del banco : Interfaz de cajero : Transacción

2: teclee cantidad 7: reintegro (cantidad)

4: teclee cuenta destino

cuentaOrigen : Cuenta cuentaDestino : Cuenta

Ingeniería del software 47


Análisis del caso de uso: “Transferencia”
1RKD\IRQGRVHQODFXHQWDRULJHQ

5: cuenta destino

3: cantidad

6: transferencia (cuenta, cantidad)


1: transferencia

9: no hay fondos
: Cliente del banco : Interfaz de cajero : Transacción

2: teclee cantidad 7: reintegro (cantidad)

4: teclee cuenta destino


8: no hay saldo

10: no hay fondos

cuentaOrigen : Cuenta
Ingeniería del software 48
Análisis del caso de uso: “Transferencia”
&XHQWDGHVWLQRLQFRUUHFWD
5: cuenta destino

3: cantidad

6: transferencia (cuenta, cantidad)


1: transferencia

: Cliente del banco : Interfaz de cajero : Transacción

2: teclee cantidad 7: reintegro (cantidad)

9: ingreso (cantidad)
8: OK
4: teclee cuenta destino

cuentaOrigen : Cuenta cuentaDestino : Cuenta

¿Cómo sabemos que la cuenta destino es correcta?


Ingeniería del software 49
Análisis del caso de uso: “Transferencia”
&XHQWDGHVWLQRLQFRUUHFWD
5: cuenta destino 11: rollback

3: cantidad

6: transferencia (cuenta, cantidad)


1: transferencia

12: error
: Cliente del banco : Interfaz de cajero : Transacción

2: teclee cantidad 7: reintegro (cantidad)

9: ingreso (cantidad)
8: OK
4: teclee cuenta destino

10: error
13: error

cuentaOrigen : Cuenta cuentaDestino : Cuenta

¿Cómo sabemos que la cuenta destino es correcta?


Ingeniería del software 50
Modelo de análisis

Cuenta

Cliente del banco Interfaz de cajero Transacción


(from Use Case View)

UsuariosDelBanco

Ingeniería del software 51


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

Ingeniería del software 52


2.2.3. Actividades. Análisis de las clases

Identificar responsabilidades

– En cada caso de uso, ver qué papel juega (diagramas de


colaboración).
– Combinar papeles y describirlos juntos.

Ingeniería del software 53


Análisis de las clases. Identificar responsabilidades
“9DOLGDUXVXDULR´ 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
,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)

Ingeniería del software 54


Análisis de las clases. Identificar responsabilidades
“9DOLGDUXVXDULR´ 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
,QWHUID]GHFDMHUR 7UDQVDFFLyQ
9LVXDOL]DU PHQVDMH autentica (datos, código)
leer código
8VXDULRV'HO%DQFR : UsuariosDelBanco
seleccioneOpcion (opciones)
valida (datos, código)

Ingeniería del software 55


Análisis de las clases. Identificar responsabilidades
“9DOLGDUXVXDULR´ &yGLJRLQFRUUHFWR

3: código

4: autentica (datos, código)


1: introducir tarjeta

7: visualiza (error)
: Cliente del banco 2: teclear código : Interfaz de cajero : Autenticar

5: valida (datos, codigo)


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)

Ingeniería del software 56


Análisis de las clases. Identificar responsabilidades
“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)
Ingeniería del software 57
2.2.3. Actividades. Análisis de las clases

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.

Ingeniería del software 58


Análisis de las clases. Identificar atributos
“9DOLGDUXVXDULR´ 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
,QWHUID]GHFDMHUR

7UDQVDFFLyQ
códigoCuenta : UsuariosDelBanco

8VXDULRV'HO%DQFR
colección de pares (datosCuenta, codigo)

Ingeniería del software 59


Análisis de las clases. Identificar atributos
“7UDQVIHUHQFLD´ 6HFXHQFLDFRUUHFWD
5: cuenta destino

3: cantidad
6: transferencia (cuenta, cantidad)
1: transferencia

2: teclee cantidad 11: OK


: Cliente del banco : Interfaz de cajero : Transacción

4: teclee cuenta destino


7: reintegro (cantidad)

9: ingreso (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)

Ingeniería del software 60


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)

Ingeniería del software 61


2.2.3. Actividades. Análisis de las clases

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

Ingeniería del software 62


2.2.4. Actividades. Análisis de los paquetes

• Paquetes débilmente acoplados

• Clases cohesionadas

• Clases de interacción

Ingeniería del software 63


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?

Ingeniería del software 64


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

Ingeniería del software 65


Casos de Usos de
Usuarios

Usuario

Casos de Usos de
Administrador

Administrador

Casos de Uso de
Profesor

Profesor

Casos de Usos
de Alumno

Alumno
Ingeniería del software 66
Validar Clave de Acceso
Usuario
(from Use Case View)

Modificar Clave de Acceso

Validar Clave de Acceso Realización de Analisis - Validar


Clave de Acceso

IU Usuario Gestor de Acceso al Usuarios


Sistema

Ingeniería del software 67


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

Ingeniería del software 68


Insertar Notas
Profesor
(from Use Case View)

Consultar Notas
Alumno
(from Use Case View)

Ingeniería del software 69


,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

Ingeniería del software 70


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)

Ingeniería del software 71


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

Ingeniería del software 72


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)

Ingeniería del software 73


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

Ingeniería del software 74