Proceso Unificado

1
Proceso Unificado
2
VistasUML
Objetos
Clases
Estado
Actividad
Secuencia
Colaboración
Casos uso
Componentes
Despliegue
Mapa
3
Proceso UnificadoIntroducción

• Proceso Procedimiento sistemático de llevar a
  cabo una tarea
• Ejemplos en el mundo de la gestión informatizada
  flujos de trabajo
• Proceso unificado Propuesto por OMG para diseño
  de software orientado a objetos
• Proceso iterativo, permite utilizar UML de manera
  natural

4
Metodologías de diseño de software, I

• Ciclo tradicional Modelo en cascada
• Análisis
• Diseño
• Codificación
• Pruebas
• Mantenimiento

5
Metodologías de diseño de software, II

• Ciclo evolutivo Modelo en espiral
• Definir subsistema (descomposición funcional)
• Construir modelo
• Ciclo repetido
• Análisis
• Diseño
• Codificación
• Prueba

6
Proceso unificadoCaracterísticas

• Basado en el análisis de requisitos (casos de
  uso)
• Construcción temprana de prototipos con la
  funcionalidad fundamental
• Afronta en primer lugar los mayores riesgos del
  diseño

7
Proceso UnificadoFases

• Iniciación (valoraciones generales)
• Elaboración (implementación iterativa de la
  arquitectura central, identificación de
  requisitos adicionales, valoraciones más
  detalladas)
• Construcción (implementación iterativa de los
  elementos restantes, preparación para el
  despliegue)
• Transición (pruebas beta, despliegue)

8
Proceso unificadoModelos

• Componentes de un modelo global UML
• Modelo de casos de uso
• Modelo de análisis
• Modelo de diseño
• Modelo de despliegue
• Modelo de implementación
• Modelo de pruebas

9
Proceso Unificado Campos
10
Tipos de requisitos

• Funcionalidad
• Características, capacidades, seguridad
• Usabilidad
• Factores humanos, ayuda, documentación
• Confiabilidad
• Frecuencia de fallos, recuperabilidad,
  predictibilidad
• Eficiencia
• Tiempos de respuesta, inversión, precisión,
  disponibilidad, utilización de recursos
• Apoyo
• Adaptabilidad, mantenibilidad, internacionalizació
  n, configuracionabilidad

11
Productos de la fase de análisis de requisitos
(modelo casos de uso)

• Casos de uso (req. funcionales) y otros
• Algunos diagramas de actividad
• Diagramas de secuencia de alto nivel (entre
  actores y sistemas) asociados a los casos de uso
• Pruebas finales a realizar

12
Productos de la fase de análisis, I

• Selección de casos de uso relevantes
• Primeros diagramas de clase (bocetos)
• Descripción sin detallar de relaciones
• Descripción sin detallar de atributos (tipos) y
  métodos (prototipos)
• Roles de las clases

13
Productos de la fase de análisis, II Roles
(estereotipos) de las clases
14
Productos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

15
Proceso UnificadoFlujo de trabajo Casos de uso
16
Proceso UnificadoFlujo de trabajo Análisis
17
Proceso UnificadoFlujo de trabajo Diseño
18
Proceso UnificadoFlujo de trabajo Implementación
19
Proceso UnificadoFlujo de trabajo Pruebas
20
Ejemplo simpleEnunciado de requisitos, I

• Diseñar una aplicación para la gestión de cursos
  de formación, que tendrá dos tipos de usuarios
  personal de servicio a clientes y personal de
  mantenimiento del programa de cursos de
  formación. Cada tipo de usuario podrá realizar
  las acciones indicadas en las transparencias
  siguientes

21
Ejemplo simpleEnunciado de requisitos, II

• El personal de servicio a clientes podrá hacer y
  cancelar reservas en cursos
• Cuando se haga una reserva de curso se confirmará
  la conformidad del cliente y la disponibilidad de
  plaza

22
Ejemplo simpleEnunciado de requisitos, III

• El personal de mantenimiento de programas podrá
  crear nuevos cursos, cancelar cursos, asociarles
  conferenciantes y crear catálogos de cursos

23
RECORDATORIO Productos de la fase de análisis de
requisitos

• Casos de uso (req. funcionales) y otros
• Algunos diagramas de actividad
• Diagramas de secuencia de alto nivel (entre
  actores y sistemas) asociados a los casos de uso
• Pruebas finales a realizar

24
Diagrama de casos de uso
25
Diagrama de actividadHacer reserva
ok
ok
ok
ok
26
Pruebas previstas
customer service
programme maintenance
Introduce nuevo curso
Curso
makeReservation
cancelCourse
27
RECORDATORIOProductos de la fase de análisis, I

• Selección de casos de uso relevantes
• Primeros diagramas de clase (bocetos)
• Descripción sin detallar de relaciones
• Descripción sin detallar de atributos (tipos) y
  métodos (prototipos)
• Roles de las clases

28
AnálisisCasos de uso relevantes
29
AnálisisBocetos de clases, I
ltltboundarygtgt BDDClases
Cliente
Curso
Reserva
ltltboundarygtgt IUCliente
ltltboundarygtgt IUManten
Empleado
30
AnálisisBocetos de clases, II
31
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

32
DiseñoDiagrama de estado
Añadir métodos a clase Curso
33
Completar clases
Faltan los tipos de los atributos y los
prototipos de los métodos Normalmente no se
añaden nuevas relaciones
34
Diagrama de secuencia
servCli Empleado
manten Empleado
curso1 Curso
creaCurso()
Reserva
hazReserva()
Cliente
chk(this)
chk(this)
addRes(this)
anular()
35
Diagrama de componentes
36
Diagrama de despliegue
37
Segunda iteración, I

• REVISAR CASOS DE USO
• Revisar análisis Otras clases,
• Revisar diseño Otros diagramas de estado y
  colaboración,
• Implementar métodos
• Primeras pruebas

38
Segunda iteración, IINuevas clases
39
EjemploEnunciado de requisitos, I

• Se desea diseñar el software necesario para una
  red bancaria provista de cajeros automáticos
  (ATM, automatic teller machines), que serán
  compartidos por un consorcio de bancos
• Cada banco dispone de su propio ordenador,
  provisto de software propio, que lleva la
  información sobre sus cuentas y procesa las
  transacciones que actúan sobre dichas cuentas

40
EjemploEnunciado de requisitos, II

• A los ordenadores de banco están conectadas las
  estaciones de cajero, que son propiedad del banco
  y en las que operan cajeros humanos, que pueden
  crear y anular cuentas, e introducir
  transacciones sobre ellas
• Las transacciones pueden ser ingresos en efectivo
  o en cheques, retiradas de fondos en efectivo,
  cobros de cheques (solamente mediante un cajero
  humano), transferencias o peticiones de
  información (saldo, últimos movimientos, etc)

41
EjemploEnunciado de requisitos, III

• Los cajeros automáticos aceptan tarjetas de
  crédito, interaccionan con el usuario, se
  comunican con un ordenador central para llevar a
  cabo las transacciones, entregan dinero en
  efectivo al usuario e imprimen recibos
• El sistema llevará correctamente el registro de
  las transacciones efectuadas, cumplirá
  características aceptables de seguridad y
  manejará correctamente accesos concurrentes a la
  misma cuenta

42
EjemploEnunciado de requisitos, IV

• El coste de desarrollo de la parte compartida del
  sistema se dividirá entre los bancos que forman
  parte del consorcio en función del número de
  clientes provistos de tarjetas de crédito

43
RECORDATORIO Productos de la fase de análisis de
requisitos

• Casos de uso (req. funcionales) y otros
• Algunos diagramas de actividad
• Diagramas de secuencia de alto nivel (entre
  actores y sistemas) asociados a los casos de uso
• Pruebas finales a realizar

44
Análisis de requisitosDetección de casos de uso,
I

• Se desea diseñar el software necesario para una
  red bancaria provista de cajeros automáticos
  (ATM, automatic teller machines), que serán
  compartidos por un consorcio de bancos
• Cada banco dispone de su propio ordenador,
  provisto de software propio, que lleva la
  información sobre sus cuentas y procesa las
  transacciones que actúan sobre dichas cuentas

45
Análisis de requisitos Detección de casos de
uso, II

• A los ordenadores de banco están conectadas las
  estaciones de cajero, que son propiedad del banco
  y en las que operan cajeros humanos, que pueden
  crear y anular cuentas e introducir transacciones
  sobre ellas
• Las transacciones pueden ser ingresos en efectivo
  o en cheques, retiradas de fondos en efectivo,
  cobros de cheques (solamente mediante un cajero
  humano), transferencias o peticiones de
  información (saldo, últimos movimientos, etc)

46
Análisis de requisitos Detección de casos de
uso, III

• Los cajeros automáticos aceptan tarjetas de
  crédito, interaccionan con el usuario, se
  comunican con un ordenador central para llevar a
  cabo las transacciones, entregan dinero en
  efectivo al usuario e imprimen recibos
• El sistema llevará correctamente el registro de
  las transacciones efectuadas, cumplirá
  características aceptables de seguridad y
  manejará correctamente accesos concurrentes a la
  misma cuenta

47
Análisis de requisitos Detección de casos de
uso, IV

• El coste de desarrollo de la parte compartida del
  sistema se dividirá entre los bancos que forman
  parte del consorcio en función del número de
  clientes provistos de tarjetas de crédito

48
Análisis de requisitos

• DIAGRAMA DECASOS DE USO

49
Análisis de requisitosActividades

• Cada banco dispone de su propio ordenador,
  provisto de software propio, que lleva la
  información sobre sus cuentas y procesa las
  transacciones que actúan sobre dichas cuentas
• Los cajeros automáticos aceptan tarjetas de
  crédito, interaccionan con el usuario, se
  comunican con un ordenador central para llevar a
  cabo las transacciones, entregan dinero en
  efectivo al usuario e imprimen recibos

50
Análisis de requisitos

• DIAGRAMA DE ACTIVIDADES

51
Análisis de requisitos Pruebas previstas

• Cajero crea cuenta
• Usuario hace ingreso en efectivo
• Usuario hace ingreso en cheques
• Usuario retira fondos en efectivo
• Cajero paga cheque
• Cajero anula cuenta

52
RECORDATORIOProductos de la fase de análisis, I

• Selección de casos de uso relevantes
• Primeros diagramas de clase (bocetos)
• Descripción sin detallar de relaciones
• Descripción sin detallar de atributos (tipos) y
  métodos (prototipos)
• Roles de las clases

53
Análisis

• SELECCIÓN DE CASOS DE USO RELEVANTES

54
AnálisisDetección de clases, I

• Se desea diseñar el software necesario para una
  red bancaria provista de cajeros automáticos
  (ATM, automatic teller machines), que serán
  compartidos por un consorcio de bancos
• Cada banco dispone de su propio ordenador,
  provisto de software propio, que lleva la
  información sobre sus cuentas y procesa las
  transacciones que actúan sobre dichas cuentas

55
Análisis Detección de clases, II

• A los ordenadores de banco están conectadas las
  estaciones de cajero, que son propiedad del banco
  y en las que operan cajeros humanos, que pueden
  crear cuentas e introducir transacciones sobre
  ellas
• Las transacciones pueden ser ingresos en efectivo
  o en cheques, retiradas de fondos en efectivo,
  cobros de cheques, transferencias o peticiones de
  información (saldo, últimos movimientos, etc)

56
Análisis Detección de clases, III

• Los cajeros automáticos aceptan tarjetas de
  crédito, interaccionan con el usuario, se
  comunican con un ordenador central para llevar a
  cabo las transacciones, entregan dinero en
  efectivo al usuario e imprimen recibos
• El sistema llevará correctamente el registro de
  las transacciones efectuadas, cumplirá
  características aceptables de seguridad y
  manejará correctamente accesos concurrentes a la
  misma cuenta

57
Análisis Detección de clases, IV

• El coste de desarrollo de la parte compartida del
  sistema se dividirá entre los bancos que forman
  parte del consorcio en función del número de
  clientes provistos de tarjetas de crédito

58
Análisis

• Bocetos de clases
• Relaciones
• Atributos y métodos

59
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

60
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

61
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

62
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

63
RECORDATORIOProductos de la fase de diseño

• Subsistemas (paquetes)
• Diseño completo de clases, interfaces y diagramas
  de estado
• Diagramas de colaboración para los casos de uso
  seleccionados
• Componentes
• Vista de despliegue

64
Segunda iteración, I

• REVISAR CASOS DE USO
• Revisar análisis Otras clases,
• Revisar diseño Otros diagramas de estado y
  colaboración,
• Implementar métodos
• Primeras pruebas

65
Segunda iteración, II

• Nuevas clases