2. ESTRUCTURA DEL RUP
Fases
F. Trabajo Procesos
Inicio Elaboración Construcción Transición
Modelación de Negocios
Requerimientos
Análisis y Diseño
Implementación
Prueba
Desarrollo
F. Trabajo Soporte
Admin. Configuración
Administración
Ambiente
Iteración(es) Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminar #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones
3. El Modelo de Análisis
El propósito fundamental del modelo de análisis es resolver
analizando los requisitos con mayor profundidad, pero con la
diferencia de que puede utilizarse el lenguaje de los
desarrolladores de proyectos para describir los resultados.
En consecuencia podemos razonar más sobre los aspectos
internos del sistema, y por tanto resolver aspectos relativos a la
interferencia de casos de uso y demás.
Podemos estructurar los requisitos de manera que nos facilite
su comprensión, su preparación, su modificación y su
mantenimiento.
Se puede considerar como una primera aproximación al
modelo de diseño y es por tanto, una entrada fundamental
cuando se da “forma” al sistema en el diseño y la
implementación.
4. Realización de un caso de uso
Una realización de Caso de Uso describe cómo es
realizado un caso de uso en particular dentro del
modelo del diseño, en términos de la colaboración
de sus objetos
Realización del Caso de Uso
6. Rational Rose
Una realización por cada caso de Uso
<<realize>>
Atender reserva de Buffet R_Atender reserva de Buffet
(from Use Cases)
7. Artefacto: clase del Análisis
Una clase de análisis representa la abstracción de una o varias
clases y/o subsistemas del diseño del sistema. Esta abstracción
posee las siguientes características:
Una clase de análisis se centra en el tratamiento de los
requisitos funcionales.
Una clase de análisis también define atributos, aunque esos
atributos son de alto nivel, pero normalmente estos pasan
hacer una clase en el diseño.
Las clases del análisis siempre encaja en uno de tres
estereotipos básicos: Interfaz, Control, Entidad.
8. Clases análisis del Modelo de Análisis
Clas e de Interfaz C las e de entidad
Clase de control
Clase de Interfaz Clase de Gestor Clase de entidad
9. Clase de Interfaz
Las clases de interfaz se utilizan para modelar la
interacción entre el sistema y los actores.
Las clases de interfaz modelan las partes del sistema
que dependen de sus actores, lo cual implica que
clasifican y reúnen los requisitos en los límites del
sistema.
Las clases de interfaz representan a menudo
abstracciones de ventanas, formularios, paneles,
interfaces de comunicaciones.
10. Clase de Interfaz, ejemplo:
(f rom U s e C as e View)
Comprador IU Solicitud de Pago
11. Clase de Entidad
Las clases de entidad modelan información y el
comportamiento asociado de algún fenómeno o
concepto, como persona o un objeto.
Las clases de entidad reflejan la información de un
modo que beneficia a los desarrolladores al diseñar e
implementar el sistema, incluyendo su soporte de
persistencia.
Las clases de entidad suelen mostrar una estructura de
datos lógica y contribuyen a comprender de qué
información depende el sistema.
12. Entidades: Capturando Atributos
Permiten capturar aquellos datos
Permiten capturar aquellos datos
que nos interesa mantener de la
que nos interesa mantener de la
entidad
entidad
Representan la estructura interna
Representan la estructura interna
<Nombre> de los objetos de la entidad
de los objetos de la entidad
Se vinculan con la información de
Atributos / Se vinculan con la información de
negocio.
Conocimiento negocio.
Determinan el estado interno del
Determinan el estado interno del
objeto
objeto
Sirven de base para el desarrollo
Responsabilidades Sirven de base para el desarrollo
de las responsabilidades
de las responsabilidades
adquiridas por los objetos de la
adquiridas por los objetos de la
entidad
entidad
13. (f rom U s e C as e View)
IU Solicitud de Pago
Comprador
Muestra
Factura
14. Clase de Gestor
Las clases de control representan coordinación,
secuencia, transacciones y control de otros objetos y se
usan con frecuencia para encapsular el control de un
caso de uso en concreto.
Los aspectos dinámicos del sistema se modelan con
clases de control, debido a que ellas manejan y
coordinan las acciones y los flujos de control
principales, y delegan trabajo a otros objetos.
15. (f rom U s e C as e View)
Factura
Comprador
Cambia estado
Planifica
factura
IU Solicitud de Pago
Gestor de Tabla
17. Diagrama de Secuencia y de Comunicación (colaboración)
Los diagramas de secuencia y de colaboración son Isomorfos.
Un diagrama de secuencia se puede transformar mecanicamente en un
diagrama de colaboración. Un diagrama de colaboración se puede
transformar mecanicamente en un diagrama de secuencia.
Flujo alternatico
2.2.5.
4: Selecciona intervalo
Flujo alternativo llama al Caso de
2.2.1. uso incluido
horario, dia, descripción VisualizarHorario
1: Crear o modificar actividad
: Usuario : InterfazActividad
2: solicita/buscar periodos de tiempo
5: visualizan los nuevos cambios
3: visualida horario
6: actualiza la actividad
: GestroActividad : Actividad
18. Ejemplo : Realización de un caso de uso en el Modelo de Análisis
Dependencia de traza
<<realize>>
Realización del
caso de uso
Sacar Dinero Sacar dinero
Salida Interfaz Retirada Cuenta
del de Efectivo
Cajero
Clase de entidad
Clases de interfaz Clase de control
19. Ejemplo : Una clase que participa en varias realizaciones de
caso de uso en el Modelo de Análisis
Sistema de Cajero Automático
Modelo de casos de uso Modelo de Análisis
Salida Retirada de
Sacar Dinero Efectivo
Transferencia Interfaz Transferencias Cuenta
del Cajero
Cliente entre Cuentas Cliente
de Banco de Banco
Ingresar Dinero Receptor Ingreso
de Dinero
Clases que participan y desempeñan roles en las 3 realizaciones de casos de uso
20. Ejemplo : Uso de diagramas de colaboración para describir una
realización de caso de uso en el Modelo de análisis
Diagrama de colaboración para la realización del caso de
uso Sacar Dinero en el Modelo de Análisis
21. Diagrama de Casos de Uso
S i co n ti e n e GU I
<< in clu d e >>
C o n su l ta r p ro v e e d o re s C o n su l ta r sto c k
(f ro m C as os d e U s o ) (f ro m C a s o s d e U s o )
R e g i stra r re p u e sto s e n a l m a c é n
<< i n c l u d e> >
< < in clu d e >> (f ro m C a s o s d e U s o )
<< in clu d e >>
< < in clu d e > >
A l m a c e n e ro
H a c e r p ag o s (f ro m A c t o re s )
(f ro m C a s o s d e U s o )
C o n su l ta r ó rd e n e s d e c o m p ra
H a c e r ó rd en e s d e c o m p ra C o ti z a r
(f ro m C a s o s d e U s o )
(f ro m C a s o s d e U s o ) (f ro m C a s o s d e U s o )
<< in clu d e > > N o ti e n e G U I
< < e x te n d > >
Gaf
(f ro m A c t o re s )
V e ri fi c a r d a to s d e c l i e n te s
G en e ra r n o ta d e p e d i d o y (f ro m C a s o s d e U s o )
fa c tu ra c i o n
(f ro m C a s o s d e U s o )
< < in clu d e > >
Ve n d e d o r
(f ro m A c t o re s )
F a c tu ra r
(f ro m C a s o s d e U s o )
23. Arquitectura del análisis, continua...
C AP A D E A P LIC A C ION
P agos C ompras C o mercia l Facturacion CA PA E S PE CÍF IC A
---------------------------------------------------------------------------------------------------...
A gendaP ersonal A lmacenes C AP A GE NE RAL
24. R_A_Consultar stock
Consult ar s tock
<< real iz e> > (fro m Ca so s d e Uso )
R_A _Consultar s tock
25. Estructura Interna
s olic ita b us c ar produc to
V end edor
indic a b us c ar a ob tiene
(fro m A cto re s)
Inte rfaz Cons ultaS toc k Ges torS toc k P roduc to
s olic ita b us c ar produc to
A lm ac enero
(fro m A cto re s)
26. Flujo Básico: Almacenero
5: S elec ciona produc to
7 : obtiene
2: Ingres a produc to a bus c ar
6: c arga Des cripc ión
Nom bre/P alabra de Des c ripc ión
P Cos to
1 : S elec c iona tipo de filt ro 3: filtra 4: obtiene lis tado
: A lm ac enero : Inter faz Con s ult aS toc k : Ges torS toc k : P roduc to
Flujo Básico: Vendedor
5: S elecc iona producto
7 : obtiene
2: Ingres a produc to a busc ar
6: carga Des c ripción
Nom bre/P alabra de Desc ripción
P Cos to
1 : S elecc iona tipo de filt ro 3: filtra 4: obtiene lis tado
: V endedor : Interfaz Con s ult aS toc k : Ges torS toc k : P roduc to
27. R_A_Generar Notas de
Pedido y Facturación
<<realize>>
R_A_Generar Notas de Pedido y Generar nota de pedido y
Facturación facturacion
(from Caso s de Uso )
29. R_A_Cotizar: Estructura Interna
s ol ic it a c o ti z ar indic a validar guarda
V end edor Interfaz Cotiz ac ion G estorCotiz ac ion Cot iz ac io n
(fro m A cto re s)
30. R_A_Cotizar: Flujo Básico
11: G rab a cot iz ac ión
8: Ingres a dato de C otiz ac ión 3.1 C o n su lta r sto ck
D is ponibilidad
Tipo de P ago
7: Ingre s a P V defini tivo 12: V alida grabac ión
4: Ingres a P V tent ativo
10: C alc ula P V Total
3: S olic ita bus c ar
9: C alc ula P V N eto
1: Ingres a c liente a bus c ar 13: guarda
5: C alc ula M G : C otiz ac ion
R U C /N om bre
2: bus c a c liente
: V endedor : Interfaz C otiz ac ion
6: obtiene m árgenes
2 .1 V e rific a r d a to s d e
: G es torC otiz ac ion
c li e n te s M in%
M ax%
: P rodu c to
31. R_A_Cotizar: Esc: Actualizar
cotización
P unto de E x tens ión: Generar Notas
de P edido y Fac turac ión
5: Graba
4: Cam bia es tado
6: valida
1: Ingres a Nro Cotiz ac ión a bus c ar 2: bus c a
: V endedor : Interfaz Cotiz ac ion : Ges t orCot iz ac ion
3: obt iene
7: guarda
: Cotiz ac ion
32. Crear año escolar
2: selecciona crear
1: ingresa datos
: Di re ctor A ula : Interfaz C rear Año E scolar
V acantes
A ño
S eccion FA 1:datos
4: valida incorrectos
Nombre del A ño
5: graba
: año E scolar : Gestor C re ar Año
E scolar
3: obtiene
capacidad
: aulas
35. Tarjetas CRC
Clase - Responsabilidad - Colaboración
• Las clases también se pueden descubrir usando tarjetas Clase-
Responsabilidad-Colaboración (CRC).
• Es un medio sencillo de identificar y organizar las clases
• Ayudan a identificar las colaboraciones cercanas:
– jerarquías de generalización/especialización o
– jerarquías de agregación entre las clases
• A medida que se completan más escenarios surgen más patrones
de colaboración entre las clases
• Las tarjetas CRC son muy efectivas en técnicas de OO porque:
– Se enfocan en los problemas
– Previenen la generalización prematura
– Fomentan el “pensamiento orientado a objetos”
36. Tarjetas CRC
Una tarjeta CRC es una tarjeta de 3 x 5 que muestra:
1. El nombre y descripción de la clase
2. Las responsabilidades de la clase: se refieren a atributos y
operaciones relevantes para la clase.
• Conocimiento interno de la clase
• Servicios que brinda la clase
3. Los colaboradores para las responsabilidades
• Un colaborador es una clase cuyos servicios son
necesarios para cumplir una responsabilidad.
• Decimos que un objeto colabora con otro, si para
ejecutar una responsabilidad necesita enviar cualquier
mensaje a otro objeto.
37. Una sesión de Tarjetas CRC
Se escoge un grupo de personas para representar los roles de los
objetos que participan en un escenario de CU.
Se crea una tarjeta para cada objeto del escenario.
A cada participante se le asigna un grupo de tarjetas que
representan objetos similares.
La persona se convierte en una “clase”
Los escenarios que se escojan deben ser desarrollados por los
participantes como si se hiciera una representación.
38. Una sesión de Tarjetas CRC, continua...
En las tarjetas se anotan las responsabilidades y colaboraciones
que vayan surgiendo de las representaciones de los escenarios
Se crean tarjetas para cualquier objeto nuevo que se descubra.
Orden de la Sesión:
–Análisis del problema
–Definición de clases
•Tormenta de ideas
•Filtrado de clases
–Definición de superclases y subclases
–Definición de responsabilidades.
–Definición de atributos.
–Operación en escenarios determinados
39. Una sesión de Tarjetas CRC, continua...
Se usan normalmente en sesiones de experto del
área/desarrollador o desarrollador/desarrollador en
grupos no mayores a 6 personas para discutir sobre las
características de la implementación.
40. Responsabilidades
• Representan características estables de una clase: atributos y
operaciones
– Atributos: se extraen de la naturaleza de la clase
– Operaciones: se extraen del análisis gramatical.
• Verbos: candidatos a operaciones
• La inteligencia del sistema debe distribuirse en forma
igualitaria, ubicando la información (atributos) y el
comportamiento (servicios) en la misma clase.
41. Colaboradores
• Representan solicitudes de un cliente a un servidor para
realizar una responsabilidad.
• Dos objetos colaboran entre sí al necesitar enviarse
mensajes para ejecutar una responsabilidad
• Ayuda a identificar relaciones entre clases
• Se examinan 3 relaciones genéricas entre clases:
– Es-parte-de
– Tiene-conocimiento-sobre
– Depende-de
43. Beneficio de las Tarjetas CRC
•Los patrones de colaboración emergen a medida que más y más
escenarios se completan.
•Las tarjetas se pueden distribuir físicamente para representar las
colaboraciones estrechas.
•Esto puede ayudar a identificar las jerarquías de generalización o
especialización, y asociaciones de agregación entre las clases
(estos temas se desarrollan mas adelante).
•Las tarjetas de CRC son más efectivas para grupos nuevos en
técnicas de OO porque:
Previenen enfocarse en temas de Programacion OO
Previenen la generalización prematura
Impulsan a “pensar orientado a objetos”
