Tema 4 Ingenieria Del Software

Tema 4: Análisis y Especificación
de Requisitos
INGENIERÍA DEL SOFTWARE

Departamento Informática y Estadística
Índice
 Introducción
 Diagramas de comunicació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
2
Introducción
 Durante la captura de requisitos:
 Lenguaje del cliente (Casos de Uso)
 Buscar acuerdos
 Pueden quedar aspectos sin resolver (imprecisos) ya que:
 Los CU deben mantenerse tan independientes unos de otros como
sea posible: no centrarse en los detalles, concurrencia, conflictos…
 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 en Requisitos.
 Objetivo del análisis:
 Analizar los requisitos en profundidad
 En el lenguaje de los desarrolladores
3
Introducción
 En el análisis:
 Tratamos aspectos internos
 Resolvemos problemas de interferencia entre Casos de Uso
 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
 Existe trazabilidad (Requisitos  Análisis)
 Utilizaremos diferentes diagramas para expresar el modelo de
análisis
4
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 Para desarrolladores, como precursor del
diseño
Puede contener redundancias, No debería contener redundancias ni
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, y cada
analizarán en el modelo de análisis una de ellas representa el análisis de un caso
de uso del modelo de casos de uso
5
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 y generan implicaciones.
 Es importante tener una comprensión completa y
precisa de los requisitos antes del diseño
 Aunque este nivel de detalle no suele importar al cliente
6
Introducción
 En resumen:
El modelo de análisis resulta importante porque:
 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
7
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. ej.: incrementos concurrentes)
 Proporciona una visión general del sistema, incluso a posteriori
(mantenimiento)
 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)
8
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 Análisis
Modelo de con reglas específicas
para derivar uno de otro.
de análisis Análisis
se realiza
a partir de
los
casos
de uso
9
Introducción
Diagramas de
Modelo de Casos de Uso
Caso de Uso
Diagramas de
Clases Incluidos paquetes
Modelo de
Diagramas de
Análisis Componentes
Diagramas de
Modelo de Despliegue
Diseño
Diagramas de
Secuencia
Diagramas de
Modelo de Interacción
Diagramas de
Despliegue Comunicación
(Colaboración)
Modelo de Diagramas de
Estados
Implementación
Diagramas de
Actividad
Modelo de
Diagramas de
Pruebas
Objetos
10
Índice
 Introducción
 Artefactos
 Actividades
11
Diagramas de comunicación
 Son un tipo de diagrama de interacción
 Los diagramas de comunicación (colaboración en UML
1.x) describen interacciones entre objetos
 Se centran especialmente en el intercambio de mensajes
entre objetos a través de sus asociaciones
 Resaltan la organización estructural de los objetos que
envían y reciben mensajes.
 Dan una vista dinámica del sistema
 Aparecen en la fase de Análisis…
 … pero se refinan en la fase de Diseño
12
 Son útiles en la fase exploratoria para identificar objetos
 La distribución de los objetos en el diagrama permite

observar adecuadamente la interacción de un objeto con
respecto de los demás
 La estructura estática viene dada por los enlaces y la

dinámica por el envío de mensajes por los enlaces
13
 Colaboraciones: objetos que interactúan para ejecutar

alguna tarea junto con los enlaces entre ellos
 Constan de
 Participantes (objetos)
 Enlaces
 Mensajes (usan los enlaces)
14
Diagramas de comunicación. Mensajes
 Un mensaje desencadena una acción en el objeto destinatario
1:Mensaje() B
 Un mensaje se envía iterada y secuencialmente a una instancia o a

un conjunto de ellas:
1 *[i:=1..n] : Mensaje()
B
15
 Un mensaje se envía concurrentemente a una instancia o a un
conjunto de ellas:
1 *| | [i:=1..n] : Mensaje()
B
 Un mensaje se envía de manera condicionada:

[x>y] 1: Mensaje()
B
16
 Un mensaje que devuelve un resultado y tiene argumentos:
1: distancia:= mover(x,y)
B
 Mensajes a sí mismo:
17
 Los argumentos de un mensaje pueden ser valores

obtenidos como consecuencia de las llamadas anteriores
 Los argumentos pueden ser también expresiones de

navegación construidas a partir del objeto cliente
 Los argumentos pueden omitirse en el diagrama
18
 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. Original + punto
 Mensajes a la vez, añadiendo letra
 Se puede asignar a una variable
 Las iteraciones *
Learning UML 2.0, Kim Hamilton y Russell Miles, O'Reilly 2006
19
Diagramas de comunicación: Ejemplo
3: seleccionar (asignatura, ficheroNotas)
4: publicar (asignatura, ficheroNotas)

1: publicar notas 5: Notas (ficheroNotas)
7: OK 6: OK
: IU Profesor : GestorPub : Asignatura
: Profesor
2: visualizar (“¿asignatura?")
8: visualizar (“Notas publicadas”)
20
Índice
 Introducción
 Artefactos
 Actividades
21
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
22
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
Realización en análisis
Gestionar asignaturas
IU asignaturas Gestor de asignaturas Asignatura

23
Índice
 Introducción
 Artefactos
 Actividades
24
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 (requisitos
especiales) en diseño (aquí se anotan)
 Evidente en el contexto del dominio del problema (conceptual)
 Responsabilidades que representan una descripción textual de un
conjunto cohesivo de actividades sobre el comportamiento de una
clase
 Atributos reconocibles en el dominio del problema (conceptuales).
 Participa en relaciones conceptuales
 Tres estereotipos básicos:
 Interfaz, control o entidad
25
Clase de análisis Responsabilidades

Atributos
Relaciones
Interfaz Control Entidad
26
Utilizamos un ejemplo
 Un sistema de enseñanza virtual
 Actor: Estudiante
 Caso de Uso: Matricularse
 …
Sistema de enseñanza virtual

Matricularse
Matricularse
Estudiante
27
 Clases límite o interfaz
 Modelan interacción entre sistema y actores
 Interfaz conceptual del sistema (ventanas, formularios, ...)
 Describen lo que se obtiene con la interacción: presentar, recibir
información, peticiones…
 No cómo se lleva a cabo
 Modelan los requisitos en los límites del sistema
 Cambios aislados del resto del sistema
<<boundary>>
 Asociadas con al menos un actor y viceversa IU Matriculación
IU Matriculación
Estudiante IU Matriculación
28
 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 pueden asignar a una
información concreta
 No encapsulan ni interacciones con el usuario ni
problemas de almacenamiento de información
<<control>>
Gestor Matrícula
Estudiante IU Matriculación Gestor Matrícula Gestor Matrícula
29
 Clases Entidad
 Representan la información significativa para el sistema
 Modelan la información de larga vida (persistencia)
 Pueden provenir de las entidades del modelo de dominio o de
las del modelo de negocio, pero no tienen por qué
corresponderse completamente
 Pueden ser pasivas o activas (comportamiento complejo)
 Encapsulan información y operaciones asociadas
<<entity>>
Alumno
Estudiante IU Matriculación GestorMatricula Alumno Alumno
30
Usuario IU Acceso ControlDeAcceso
Estudiante IU Estudiante
Permisos
Profesor IU Profesor
31
Índice
 Introducción
 Artefactos
 Actividades
32
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
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
Caso de Uso Realización en análisis

33
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)
34
casos de uso. Diagramas de clases
 Una clase de análisis puede participar en varias
realizaciones de CU
 Responsabilidades, atributos y relaciones pueden ser
relevantes para una única realización de un caso de
uso
35
casos de uso
 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)
36
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 (antiguos 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
37
casos de uso. Diagramas de interacción
Ejemplo: Caso de uso “Publicar Notas” del actor “Profesor”
3: seleccionar (asignatura, ficheroNotas)
4: publicar (asignatura, ficheroNotas)

1: publicar notas 5: Notas (ficheroNotas)
7: OK 6: OK
: IU Profesor : GestorPub : Asignatura
: Profesor
2: visualizar (“¿asignatura?")
8: visualizar (“Notas publicadas”)
38
casos de uso
 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)
39
Artefactos. Realización en análisis de casos
de uso. F. de eventos y Req. no funcionales
  Descripción textual del flujo de eventos
 Para clarificar los diagramas de comunicació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
40
Índice
 Introducción
 Artefactos
 Actividades
41
Paquetes en UML
 Los paquetes ofrecen un mecanismo general para la

organización de los modelos agrupando elementos de
modelado
 Se representan gráficamente como:
Nombre de
paquete
42
Paquetes en UML
 Cada paquete corresponde a un subconjunto del modelo

y contiene, según el modelo, clases, objetos, relaciones,
componentes y diagramas asociados
 Un paquete puede contener otros paquetes, sin límite de

anidamiento pero cada elemento pertenece a (está
definido en) solo un paquete
 Un paquete encapsula a la vez que agrupa
43
Paquetes en UML
 El operador “::” permite designar una clase definida en un

contexto distinto del actual
 Por ejemplo, la expresión Ventas::Producto designa
la clase Producto definida en el paquete Ventas
44
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
- 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.
45
 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
46
 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.
 Los paquetes de análisis probablemente se convertirán en
subsistemas en diseño.
47
Ejemplo
Cajero automático
Transacciones
Mantenimiento Personal
Mantenimiento
Consultas
Cliente
Reposiciones
Venta de entradas Empleado
48
Índice
 Introducción
 Artefactos
 Actividades
49
Actividades del análisis
 La creación del modelo de análisis comienza identificando:
 Los paquetes de análisis. Ej:
 Agrupar CU que den soporte a un proceso de negocio
 CU que den soporte a un actor
 CU relacionados mediante generalizaciones y extensiones…
 Las clases de entidad evidentes (p.e. Modelo del Dominio.)
 Los requisitos especiales comunes (RNF)
 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
50
Actividades del análisis
 Para ilustrar las actividades, utilizaremos el ejemplo del
cajero automático.
Cajero Automático
Sacar Dinero
<< include >>
<< include >>

Validar Cliente
Cliente Ingresar Dinero
<< include >>
Hacer Transferencia
51
Índice
 Introducción
 Artefactos
 Actividades
52
Actividades. Análisis de los 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.
53
Actividades. Análisis de los casos de uso
Identificar las clases de análisis
 Identificar las clases de análisis

 Una clase entidad se deriva 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 (otros CU)
54
Análisis del caso de uso: “Validar usuario”
<<trace>>
Validar usuario Realización en análisis de Validar usuario
IU Cajero
Gestor de Usuario
Autenticación
 Representamos las clases de análisis en un diagrama de clases
Diagrama de clases del caso de uso Validar usuario:
IU Cajero Gestor de Usuario

Cliente
Autenticación
55
Actividades. Análisis casos de uso.
Distribuir comportamiento entre las clases
 Describir las interacciones entre objetos
 Utilizar diagramas de comunicación
 Instancias y enlaces
 Un diagrama de comunicación por cada camino del caso
de uso (escenarios)
 Sobre los diagramas de comunicación:
 Inicia un actor
 Expresión de las interacciones: mensajes
56
Actividades. Análisis casos de uso
Capturar/asignar requisitos no funcionales
 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…)
57
Diagrama de clases completo (ejemplo)
58
Flujo de eventos
Camino básico del caso de uso
“Validar Cliente”
ACTOR SISTEMA
1. Este caso de uso empieza 2. Pide la clave de
cuando un Cliente introduce identificación
una tarjeta en el cajero
3. Introduce la clave 4. Comprueba la clave
5. Presenta las opciones
de operaciones
disponibles y termina el
caso de uso.
Caminos alternativos
Evento 3. El cliente cancela la transacción
Evento 4. La clave no es válida y se reinicia el caso de
uso. Si ocurre tres veces se cancela la transacción y no
se devuelve la tarjeta
59
Camino Básico
 Caminos alternativos:
 “Anular transacción”
 “Clave incorrecta” *
 si 3 veces error: cancelar y quedarse con la tarjeta
60
Camino Alternativo: Clave incorrecta
61
Caso de Uso: Validar Usuario
Camino Alternativo: Supera los 3 intentos de validación
62
Análisis del caso de uso: “Sacar dinero”
<<trace>>
Sacar dinero Realización en análisis de Sacar dinero
IU Cajero
Gestor de Cuenta
Sacar dinero
Diagrama de clases del caso de uso Sacar dinero:
IU Cajero Gestor de Cuenta

Cliente
Sacar dinero
63
Análisis del casos de uso: “Sacar dinero”
Flujo de eventos
Camino básico del caso de uso “Sacar Dinero”
ACTOR SISTEMA
1. Selecciona la operación de Sacar dinero 2. Pide la cantidad a retirar
3. Introduce la cantidad a sacar 4. Procesa la petición
5. Devuelve la tarjeta
6. Entrega el dinero solicitado
7. Recoge la tarjeta
8. Recoge el dinero y termina el caso de uso
Evento 3. El cliente anula la transacción .
Evento 4. La cantidad supera el saldo. Se indica el error y se cancela la operación.
Evento 4. La cantidad supera el límite diario. Se indica el error y se pide otra cantidad.
Evento 4. El cajero no dispone de dinero. Se indica el error y se cancela la operación.
Evento 7. Pasado un tiempo no recoge la tarjeta. El cajero se traga la tarjeta.
64
Camino básico
 * MagicDraw: Opción: Show stereotypesText and Icon
 Caminos alternativos:
 En el cajero no hay dinero
 Se ha superado el límite diario
 No hay saldo…
65
Camino Alternativo: Supera el límite diario.
66
Camino Alternativo: No hay billetes.
2: Mostrar (No hay billetes disponibles)
67
Camino Alternativo: No hay saldo
68
Análisis del caso de uso: “Ingresar dinero”
<<trace>>
Ingresar dinero Realización en análisis de Ingresar dinero
IU Cajero
Gestor de Cuenta
Ingresar dinero
Diagrama de clases del caso de uso Ingresar dinero:
IU Cajero Gestor de Cuenta

Cliente
Ingresar dinero
69
Flujo de eventos
Camino básico del caso de uso “Ingresar Dinero”
ACTOR SISTEMA
1. Selecciona la operación de Ingreso 2. Pide la cantidad a ingresar
3. Introduce el importe a ingresar 4. Abre el cajón depósito del dinero en metálico

5. Introduce el dinero 6. El sistema contabiliza dicho dinero y comprueba si
coincide con el importe
7. Notifica al usuario que el ingreso se ha realizado
8. Devuelve la tarjeta
9. Recoge la tarjeta y termina el caso de uso
Evento 3. El usuario cancela la operación.
Evento 5. El usuario cancela la operación.
Evento 6. Notifica al usuario que la cantidad no coincide con el dinero introducido y permite que se repita la operación
desde el principio.
Evento 9. El usuario no recoge la tarjeta pasado un tiempo. El cajero se traga la tarjeta.
70
Camino básico
71
Camino Alternativo: Cantidad incorrecta
72
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
<<trace>>
Realizar Realización en análisis de Realizar transferencia
transferencia
IU Cajero
Gestor de Transferencia Cuenta
Diagrama de clases del caso de uso Realizar transferencia:
IU Cajero Gestor de Transferencia Cuenta

Cliente
73
Flujo de eventos
Camino básico del caso de uso “Transferencia”
ACTOR SISTEMA
1. Selecciona la operación de Transferencia 2. Pide la cantidad a transferir
3. Introduce la cantidad 4. Pide el número de cuenta
5. Introduce el número de cuenta 6. El sistema comprueba que existe saldo suficiente en la cuenta
del cliente
7. El sistema realiza un ingreso sobre la cuenta destino
8. Se informa al cliente de que la operación se ha realizado
satisfactoriamente
9, Descontar cantidad en cuenta origen
10. Se expulsa la tarjeta
11. Recoge la tarjeta y termina el caso de uso
Evento 3,5. El actor puede cancelar.
Evento 6. Si no existe saldo suficiente se informará que no es posible realizar la operación.
Evento 7. Si ocurre algún problema con el ingreso se informará que no se ha realizado.
Evento 10. Si el actor no recoge la tarjeta, el cajero automático tragará la tarjeta.
74
Camino básico
75
C. Alternativo: Sin fondos en cuenta origen
7: Sacar
76
Cuenta destino incorrecta
77
Diagrama de clases completo (ejemplo)
78
Requisitos especiales
 La clase Cuenta será persistente.
 La clase Transacción será transitoria.
 Las transacciones serán ACID (Atomicity, Consistency, Isolation
and Durability).Atómicas, Consistentes, Aisladas y Duraderas.
 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.
 .....
79
Índice
 Introducción
 Artefactos
 Actividades
80
Actividades. Análisis de las clases
 Identificar las responsabilidades
 Identificar atributos
 Identificación de asociaciones y agregaciones
 Identificación de generalizaciones
 Capturar requisitos especiales
81
 Identificar responsabilidades
 En cada caso de uso, ver qué papel juega (diagramas de
comunicación).
 Combinar responsabilidades y describirlas juntas.
82
Análisis de las clases. Identificar
responsabilidades. “Validar usuario”
 Secuencia correcta
IU Cajero
Gestor de Autenticación
Mostrar (Ingrese Clave) Solicitar Validar (DatosTarjeta, Clave)
Mostrar (Seleccione Opción) Solicitar Mostrar (Opciones menú)
Leer Tarjeta Usuario
Leer Clave Validar (DatosTarjeta, Clave)
83
responsabilidades. “Validar usuario”
 Código Incorrecto
IU Cajero Gestor de Autenticación

Mostrar (Mensaje) Solicitar Validar (DatosTarjeta, Clave)
Leer Tarjeta Solicitar Mostrar (Error)
Leer Clave Usuario
Validar (DatosTarjeta, Clave)
84
responsabilidades. “Sacar dinero”
 Secuencia correcta
IU Cajero Gestor de Autenticación Cuenta

Mostrar (Mensaje) Validar (DatosTarjeta, Clave) Sacar (Cantidad)
Leer Tarjeta Usuario Gestor de Sacar Dinero
Leer Clave Validar (DatosTarjeta, Clave) Sacar (Cantidad)
Leer importe
Entregar Dinero (Cantidad)
85
Entregar Tarjeta
 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...
86
Análisis de las clases. Identificar atributos
“Validar usuario”. Secuencia correcta
IU Cajero Gestor de Autenticación Usuario
Mensaje Contador DatosTarjeta, Clave
DatosTarjeta, Clave Opciones menú

DatosTarjeta, Clave
87
Análisis de las clases. Identificar atributos
“Transferencia”. Secuencia correcta
Sacar
IU Cajero Gestor de Transferencia Cuenta

Mensaje Cuenta Cuenta
Cuenta Cantidad Saldo
Cantidad Mensaje Límite
Cantidad
88
Análisis de las clases
Clase Atributos Responsabilidades
IU Cajero Clave: texto de 4 dígitos Mostrar (mensaje)
Mensaje: texto Leer (tarjeta); leer (clave)
Cantidad: numérico Leer (cantidad)
… Entregar Dinero (cantidad)
ContarBilletes
Validar (Cantidad)
Leer (opciones)
Usuario DatosTarjeta:… Validar (DatosTarjeta, Clave)
Clave: texto de 4 dígitos
Cuenta Saldo: numérico Ingreso (Cantidad); Reintegro
Límite diario: numérico (Cantidad)
Gestor de Autenticación Contador: numérico Autenticar (DatosTarjeta, Clave)
Gestor de Sacar Dinero Sacar (Cantidad)
Gestor de Transferencia Transferencia (NroCuenta, Cantidad)
… … …
89
 Identificación de asociaciones y agregaciones

 Definir multiplicidad y roles
 Agregación y composición
 Identificación de generalizaciones
 Identificar generalizaciones y/o especializaciones entre clases
 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
90
Índice
 Introducción
 Artefactos
 Actividades
91
Actividades. Análisis de los paquetes
 Con el objetivo de refinarlos
 Paquetes débilmente acoplados (grado de interdependencia)
 Elementos cohesionados (relacionados)
 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.
92
Bibliografía
 El Proceso Unificado de Desarrollo de Software. I.
Jacobson, G. Booch y J. Rumbaugh. Pearson Prentice-Hall
2007
93

Tema 4 Ingenieria Del Software

Cargado por

Copyright:

Formatos disponibles

Tema 4 Ingenieria Del Software

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

Tema 4 Ingenieria Del Software

Cargado por

Copyright:

Formatos disponibles

Tema 4: Análisis y Especificación

INGENIERÍA DEL SOFTWARE

Modelo de Relación externa al modelo,

 Son útiles en la fase exploratoria para identificar objetos

 La distribución de los objetos en el diagrama permite

 La estructura estática viene dada por los enlaces y la

 Colaboraciones: objetos que interactúan para ejecutar

 Un mensaje se envía iterada y secuencialmente a una instancia o a

 Un mensaje se envía de manera condicionada:

 Los argumentos de un mensaje pueden ser valores

 Los argumentos pueden ser también expresiones de

 Los argumentos pueden omitirse en el diagrama

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

3: seleccionar (asignatura, ficheroNotas)

4: publicar (asignatura, ficheroNotas)

8: visualizar (“Notas publicadas”)

Interfaz Control Entidad

IU asignaturas Gestor de asignaturas Asignatura

Clase de análisis Responsabilidades

Interfaz Control Entidad

Sistema de enseñanza virtual

Estudiante IU Matriculación Gestor Matrícula Gestor Matrícula

Estudiante IU Matriculación GestorMatricula Alumno Alumno

Usuario IU Acceso ControlDeAcceso

Modelo de casos de uso Modelo de análisis

Caso de Uso Realización en análisis

Ejemplo: Caso de uso “Publicar Notas” del actor “Profesor”

3: seleccionar (asignatura, ficheroNotas)

4: publicar (asignatura, ficheroNotas)

8: visualizar (“Notas publicadas”)

 Los paquetes ofrecen un mecanismo general para la

 Se representan gráficamente como:

 Cada paquete corresponde a un subconjunto del modelo

 Un paquete puede contener otros paquetes, sin límite de

 Un paquete encapsula a la vez que agrupa

 El operador “::” permite designar una clase definida en un

- Un paquete es un conjunto de clases (y otros elementos) relacionadas, generalmente

Venta de entradas Empleado

<< include >>

<< include >>

 Analizamos cada caso de uso para:

 Identificar las clases de análisis

 Representar las clases de análisis en un diagrama de clases

 Representamos las clases de análisis en un diagrama de clases

Diagrama de clases del caso de uso Validar usuario:

IU Cajero Gestor de Usuario

 Capturar/asignar requisitos no funcionales a clases de

Diagrama de clases del caso de uso Sacar dinero:

IU Cajero Gestor de Cuenta

2: Mostrar (No hay billetes disponibles)

Diagrama de clases del caso de uso Ingresar dinero:

IU Cajero Gestor de Cuenta

3. Introduce el importe a ingresar 4. Abre el cajón depósito del dinero en metálico

Diagrama de clases del caso de uso Realizar transferencia:

IU Cajero Gestor de Transferencia Cuenta

IU Cajero Gestor de Autenticación

IU Cajero Gestor de Autenticación Cuenta

IU Cajero Gestor de Autenticación Usuario

Mensaje Contador DatosTarjeta, Clave