1. Desarrollo de software
orientado a objetos
Unidad 5:
Modelo del Diseño

2. Agenda
 Del análisis al diseño
 Diagramas de Interacción
 Responsabilidades y métodos

3. Del análisis al diseño

4. Del Análisis al Diseño
 En el análisis se pone énfasis en el
conocimiento de los
requerimientos desde la
perspectivas del “qué”: ¿qué
procesos se requieren?, ¿qué
conceptos son necesarios para el
sistema?

5. Del Análisis al Diseño
 En el diseño se da forma al
sistema y se define su perfil (con
la arquitectura incluida).
 Se define “cómo” se satisfacen los
requerimientos funcionales y no
funcionales.

6. Del Análisis al Diseño
Propósitos:
 Lograr una clara comprensión de
requerimientos no funcionales
relacionados con lenguajes de
programación, reuso de
componentes, sistemas operativos,
tecnologías de distribución,
concurrencia, bases de datos, etc.

7. Del Análisis al Diseño
…….
 Tener la capacidad de descomponer
el trabajo de implantación en piezas
manejables que puedan ser
desarrolladas por distintos grupos.
 Capturar las interfaces más
importantes entre los distintos
subsistemas.

8. Del Análisis al Diseño
Modelo de Análisis
Modelo de Diseño
Es conceptual, una
abstracción del sistema sin
características de implem.
Es genérico respecto al
diseño (válido para muchos)
Contempla tres estereotipos
de clases: : “control”,
“entity” y “boundary”
Define pocas capas
Es físico, es el anteproyecto
de la implementación
Es específico para la
implementación
Diseña clases de muchos
estereotipos dependiendo
del lenguaje
Define muchas capas

9. Realización de los Casos de Uso
 Describe como se desarrolla un caso de uso
en términos de sus clases y objetos.
 Describe su diseño a partir de herramientas
concretas de entrada y salida.
 Se adjuntan a la especificación:
 La interfaz del usuario
 Los diagramas de interacción.
 Diagramas de clases orientados al diseño.

10. Realización de los Casos de Uso
 Se puede completar una
especificación esencial con el diseño
de las pantallas y su interacción.
 Se puede hacer especificaciones
reales redefiniendo el flujo de los
eventos utilizando los elementos de la
interfaz (orientando la especificación
a un manual de usuario).

11. Diagramas de interacción

12. Diagramas de interacción
 Conceptos base
 Enfoque Cliente Servidor
 Diagrama de Secuencia del Sistema
 Diagramas de interacción. ¿Qué
son?
 Diagramas de secuencia
 Diagramas de colaboración

13. Enfoque Cliente-Servidor
 Forma de solucionar un problema en la
vida real.
Pregunta:
¿Qué hago si mi auto se
descompone?
Solución
Voy al taller para que lo compongan

14. Enfoque Cliente-Servidor
Pasos en la solución del problema:
 Buscar un servidor apropiado (taller)
 Hacerle la petición del servicio (pasarle el
mensaje “arreglar auto”)
 El servidor emplea el método apropiado
para resolver la petición (procedimiento
de arreglo propio del taller)

15. Enfoque Cliente-Servidor
Consideraciones:
 Al cliente no le interesa cómo el servidor
resuelve su petición.
 La solución está encapsulada u oculta en
el servidor.
 El pensamiento de un servidor es buscar
alguien más para que colabore con la
solución.

16. Enfoque Cliente-Servidor
Cliente
Servidor
Colaborador(es)

17. Diagrama de secuencia del sistema
 Muestra los eventos que fluyen de
los actores al sistema
Evento
Sistema
Evento: Acción de
Evento: Acción de
un actor que
un actor que
provoca que el
provoca que el
sistema cambie
sistema cambie
de estado
de estado
Comportamiento del sistema

18. Diagrama de Secuencia del
Sistema
Vender Productos: Versión 1
Repetir hasta que no haya mas productos
Cajero
:Sistema
IntrProd(CUP, Cantidad)
TerminarVenta ()
EfectuarPago (Monto)

19. Cómo elaborar un diagrama de
secuencia del sistema
 Colocar el símbolo del objeto sistema
y una línea vertical
 Para cada actor colocar su símbolo y
una línea vertical
 A partir de los eventos del caso de uso
identificar los eventos externos que
son generados por los actores para los
casos de uso

20. Cómo nombrar los eventos
 Deben denominarse de tal manera que
estén desprovistos del medio físico de
entrada o de elementos de la interfaz.
 Se debe utilizar verbos en infinitivo.
 Deben captar el propósito de la
operación y no definirse en función de la
interfaz.
TerminarVenta Vs OprimirTeclaEnter

21. Denominación de los Eventos
IntroducirImporteOfrecido(Monto)
IntroducirPago(Monto)
EfectuarPago(Monto)
¡Cada vez mejor!
Importante:
Importante:
Describir el
Describir el
propósito
propósito

22. Diagrama de Secuencia del
Sistema
Para todos los
productos el cajero
registra el CUP y la
cantidad….
Cajero
:Sistema
IntrProd(CUP, Cantidad)
...Al terminar la captura
indica que la venta
terminó.
TerminarVenta ()
EfectuarPago (Monto)
...El cajero registra el importe recibido en
efectivo

23. Diagramas de interacción…
¿Qué son?
 Un diagrama de interacción es una
representación gráfica de las
interacciones entre los objetos.
 Existen dos versiones:
 Diagramas de secuencia
 Diagramas de colaboración

24. Diagramas de interacción…
¿Qué son?
 Cada uno de estos diagramas
proporciona una vista diferente de la
misma interacción.
 Los diagramas de secuencia están
ordenados de acuerdo al tiempo.
 Los diagramas de colaboración ponen
énfasis en los mensajes entre los objetos y
pueden incluir flujos de datos.

25. Diagramas de secuencia
 Introducción.
 Elementos.
 Distribución del flujo de control en
diagramas de secuencia.

26. Introducción
 Los diagramas de secuencia se usan
para ilustrar la realización de los casos
de uso.
 Una organización típica tiene un
diagrama de secuencia para el flujo
normal de eventos de un caso de uso
y otro para cada flujo alternativo
independiente.

27. Introducción
 Los diagramas de secuencia son importantes
para los diseñadores porque aclaran los roles
de los objetos dentro de un flujo y
proporcionan un input básico en la
determinación de las responsabilidades de
clases e interfases.
 A diferencia de un diagrama de colaboración
un diagrama de secuencia incluye una
secuencia cronológica, pero no relaciones
entre objetos.

28. Elementos del diagrama de
secuencia
 El diagramas muestran:
 Los objetos y actores que participan en la
interacción.
 La secuencia de mensajes intercambiada
entre dichos objetos.

29. Diagramas de secuencia
 Contiene:
 Objetos con sus líneas de vida
 Mensajes intercambiados entre los
objetos ordenados secuencialmente
 Focos de Control (opcionales).
 Scripts adicionales que aclaran el
propósito de la interacción entre objetos

30. Diagrama de secuencia

31. Objetos
 Los objetos se dibujan como
rectángulos con nombres subrayados.
 Las líneas de vida de los objetos son
representadas por líneas punteadas.
Representa la existencia o presencia
de un objeto en un determinado
tiempo.

32. Actores
 Los actores se representan
normalmente al inicio de un diagrama
de secuencia como el que invoca a la
interacción de los objetos.
 Si hay mas de un actor es preferible
que se coloquen todos al inicio
(extremo izquierdo) o al final (extremo
derecho).

33. Mensajes
 Un mensaje es la comunicación entre objetos
que conlleva información y la expectativa de
obtener un resultado.
 Están indicados por flechas horizontales que
son direccionadas desde una línea vertical
(que representa al objeto cliente) hasta la otra
(que representa al objeto servidor)
 Las flechas horizontales están etiquetadas con
el nombre del mensaje.

34. Mensajes
 El orden de los mensajes de
acuerdo al tiempo está indicado
por la posición vertical, con los
primeros en la parte de arriba.
 La numeración es opcional y está
basada en la posición de las líneas
verticales.

35. Focos de control
 Los focos de control representan el
tiempo relativo en el que un flujo de
control está focalizado en un objeto.
 Representa la secuencia de tiempo en
que un objeto esta dirigiendo sus
mensajes.
 Deben ser mostrados en un diagrama
de secuencia para establecer ciclos.

36. Ej. Diagrama de Secuencia con
focos de control

37. Scripts
 Para escenarios complejos, los diagramas
de secuencia pueden enriquecerse con el
uso de scripts.
 Estos, se escriben a la izquierda del
diagrama de secuencias con los pasos
alineados con las interacciones entre
objetos.
 Los scripts pueden ser escritos en lenguaje
natural o pseudo código.

38. Scripts para los Diagramas de
Secuencia
 Ejemplo
Comprobante
El objeto comprobante
obtiene de cada uno de
sus detalles el
precioxcantidad para
calcular el total
Detalle
Compobante
* Obtener Detalle(): PrecioXCantidad

39. Distribución del control en un
diagrama de secuencia
 La distribución del control en un
diagrama de secuencia puede ser
centralizado, descentralizado o
comúnmente una combinación de
ambos comportamientos.

40. Distribución del control en un
diagrama de secuencia
 El control centralizado significa que unos pocos
objetos gobiernan el flujo enviando y recibiendo
mensajes del resto de objetos.
 Estos objetos de control deciden el orden en el que
otros objetos serán activados.
 La interacción entre los otros objetos es mínima o no
existe.
CONTROL CENTRALIZADO
: Usuario
: IReserva : CReservas : Reserva : Cliente : Producto

41. Distribución del control en un
diagrama de secuencia
 La principal ventaja del control
centralizado consiste en que cada
objeto no necesita hacer
seguimiento del comportamiento del
siguiente.
 Si se requiere hacer cambios en el
curso de eventos se hace los
cambios en le objeto de control.

42. Distribución del Control en un
Diagrama de Secuencia
 El control centralizado es apropiado:
 Si el orden en el cual los sub-eventos se
desarrollarán son cambiantes.
 Si se espera adicionar sub-eventos o
nuevos escenarios.
 Si se quiere conservar partes de la
funcionalidad como piezas separadas
reusables.

43. Distribución del control en un
diagrama de secuencia
 El control descentralizado se origina
cuando los objetos participantes se
comunican directamente unos con otros
sin la intervención del un objeto
controlador.
CONTROL DESCENTRALIZADO
: Usuario
: IReserva : CReservas : Reserva : Cliente : Producto

44. Distribución del control en un
diagrama de secuencia
 El control descentralizado es apropiado:
 Si las fases de sub-eventos están fuertemente
emparejados como en el caso de objetos:
 Participantes de una jerarquía: País-DepartamentoProvincia-Distrito.
 Que forman parte de una organización (información)
jerárquica: CEO-Gerencia de División-Gerente de
Sección, etc.
 Que representan una progresión cronológica fija
(siempre se van a realizar en un orden determinado):
Publicidad, Pedido, Facturación, Despacho y Pago.

45. Distribución del control en un
diagrama de secuencia
 El control descentralizado es
apropiado:
 Si se desea encapsular (y en
consecuencia hacer abstracciones) la
funcionalidad porque se usa
frecuentemente como un todo.

46. Diagramas de colaboración
 Introducción.
 Elementos.
 Multiobjetos.

47. Introducción
 Al igual que los diagramas de
secuencia, los de colaboración se
usan para aclarar los roles de los
objetos que participan en un flujo de
eventos de un caso de uso.
 Son la principal fuente de información
para determinar las responsabilidades
de las clases e interfaces.

48. Introducción
 El diagrama muestra las interacciones
entre objetos organizadas alrededor
de los propios objetos y sus mutuas
conexiones.
 Son mejores para comprender todos
los efectos de un objeto dado y para
el diseño de procedimientos.

49. Elementos
 Contiene:
Objetos.
Actores.
Asociaciones entre objetos.
Mensajes intercambiados entre los
objetos.
 Flujos de datos entre objetos (si existen).





50. Diagramas de colaboración
 Ejemplo:

51. Objetos
 Los objetos se dibujan como
rectángulos con nombres subrayados
English
101
Sólo Objeto
English 101:
Curso
Objeto y Clase
:Curso
Sólo Clase

52. Actores
 Se representan normalmente para
invocar o iniciar una interacción.
 Si hay mas de uno es mejor
diagramarlos en la periferia.

53. Vínculos
 Un vínculo de interacción está
representado por una línea que
conecta a los íconos de los objetos.
 Indica que hay un camino de
comunicación entre dos objetos
conectados.
Horario : Formulario
Un curso : Curso

54. Notaciones para los vínculos
 Un vínculo de interacción puede estar
documentado con:
 Una flecha que apunta desde el objeto cliente
hacia el objeto servidor.
 El nombre del mensaje con una lista opcional
de parámetros y/o valores de retorno.
 Un número secuencial opcional que muestra el
orden relativo en que los mensajes son
enviados.

55. Notaciones para los Vínculos
Mensaje
Puntos del cliente
al servidor
2: Selecciona cursos
Objeto
cliente
Horario : Formulario
1: Obtiene prerrequisitos
Lista de Cursos
Un Curso : Curso
Vínculo
Data de retorno
Objeto
Servidor

56. Representación de parámetros
 Los parámetros pueden anotarse
dentro de un paréntesis a
continuación del nombre del mensaje.
Es opcional incluir el tipo.
obtieneHorarioDisp(IdCurso: char)
:Curso
:Horario

57. Representación del mensaje
que devuelve valor
 Puede incluirse un valor de retorno
anteponiendo una variable y un operador de
asignación.
 La sintaxis es:
retorno : mensaje(parametro : tipoParametro) : tipoRetorno
1: Creditos := obtieneCreditos(IdCurso: char):Entero
:Controladora
Matricula
:Curso

58. Representación de la iteración
 La iteración se indica poniendo un
asterisco (*) al número de secuencia.
1* : CM := cursoMatriculado():detalleMatricula
:Matricula
:Detalle
Matricula

59. Representación de la iteración
 La iteración con cláusula.
1* :[i:=1..10] CM i := ObtenerCurso():Curso
:Controladora
Cursos
:Curso

60. Representación de condicionales
mutuamente excluyentes
 La iteración con cláusula.
1a :[con beca] ExonerarPago(IdMatricula)
:Controladora
Pagos
:Matricula
:Cuenta
Corriente
1b :[sin beca] CrearCuenta(IdMatricula)

61. Representación de las
colecciones
 Un multiobjeto, colección o conjunto de
instancias se representa como:
:Detalle Matricula
 Suele implementarse como un grupo de
instancias guardadas en un contenedor u
objeto colección

62. Representación de los mensajes
a un multiobjeto
2:
mens2()
1: mens1()
:Venta
1.1: crear()
vl:VentaDetalle
2.2: imprimir()
1.2: adicionarDetalle(vl)
:VentaDetalle
2.1: vl := obtenerDetalle(IdVenta)

63. ¿Cómo comenzar?
 Procedimiento recomendado:
1 Preparar un diagrama para cada operación
del sistema (encontradas en los diagramas
de secuencia del sistema para cada caso de
uso), que lo incluya como mensaje inicial.
2 Dividir el diagrama si se vuelve complejo.
3 Diseñar un sistema de objetos interactuantes
para que realicen las tareas (tomar en cuenta
las post-condiciones de contratos o casos de
uso).

64. Diagramas de interacción y
otros artefactos
Especificaciones de
casos de uso y postcondiciones, diagramas
de clases de análisis
Casos de uso y diagramas de
Secuencia del Sistema
:Sistema
Iniciar Reserva()
Caso de uso: Realizar Reserva()
Post Condiciones:
• Se creó un objeto Reserva.....
Diagramas de
interacción
: Usuario : IReserva : CReservas
Iniciar Reserva()

65. Ejemplo de elaboración de
diagramas de interacción
 Caso de Uso:
Registrar
Reserva
(escenario de
la reserva en
agencia).
: Usuario
SISTEMA
IniciarReserva()
BuscarCliente()
BuscarProducto()
TerminarReserva()

66. Ejemplo de elaboración de
diagramas de interacción
IListaReserva
CReserva
EFormaPago
IReserva
CProductos
Counter
EReserva
(from Actores)
EProducto
CCliente
ECliente

67. Ejemplo de elaboración de
diagramas de interacción
Operación: IniciarReserva ()
 Descripción: Permite la creación de una
nueva reserva.
 Pre-Condiciones:
 El sistema conoce la agencia registradora.
 Post-Condiciones:
 Se creo una instancia de la clase Reserva.
 Se asoció una agencia a la instancia Reserva.

68. Ejemplo de elaboración de
diagramas de interacción
: SUCURSAL
: Usuario
R1 : RESERVA
: IListaReservas
: CReserva
IniciarReserva()
IniciarReserva()
ObtenerSucursal(IdSucursal)
CrearReserva( )
AbrirIReserva(Ope, NombreAgencia)
: IReserva

69. Ejemplo de elaboración de
diagramas de interacción
1: IniciarReserva()
: Usuario
: IListaReservas
2: IniciarReserva()
3: ObtenerSucursal(IdSucursal)
:SUCURSAL
: CReserva
4: CrearReserva( )
5: AbrirIReserva(Ope, NombreAgencia)
: IReserva
R1:RESERVA

70. Responsabilidades y
métodos

71. Responsabilidades y Métodos
 Las responsabilidades no son mas que los contratos
u obligaciones que tienen las clases.
 Las responsabilidades se implementan como
métodos.
 Se descubren a partir de los diagramas de
interacción.
 Asignarlas correctamente es uno de los problemas
de mayor importancia en el DOO.
 Podemos agruparlas en dos categorías:
 Hacer
 Conocer

72. Responsabilidades y Métodos
 Entre las responsabilidades
relacionadas con hacer están:
 Hacer algo en uno mismo:
 Imprimir Comprobante()
 Iniciar una acción en otros:
 CalcularTotalesVenta()
 Controlar y coordinar actividades en otros
objetos:
 RegistrarVenta()

73. Responsabilidades y Métodos
 Entre las responsabilidades relacionadas
con conocer están:
 Estar enterado de los datos privados
encapsulados: MostrarNombreCliente()
 Estar enterado de la existencia de objetos
conexos: MostrarDetalleVenta()
 Estar enterado de las cosas que se pueden
derivar o calcular CalcularImpuesto()
 Se pueden inferir del Modelo Conceptual

74. Responsabilidades y Métodos
 Otra forma de reconocer responsabilidades
es a partir de la naturaleza de las clases.
 Las interfaces son expertas en mostrar y recibir
información.
 La entidades son expertas en el manejo de
datos.
 Las controladoras son las administradoras de
los casos de uso y se encargan de resolver los
pedidos complejos (que involucran a varias
clases).
 Los multiobjetos son expertos en manejar listas
de objetos

75. Conclusiones
 Asignar responsabilidades de manera adecuada
es una de las tareas mas importantes del diseño y
la que ocupa mas tiempo.
 Los diagramas de interacción se usan en dos fases:
 En la primera, ayudan a descubrir los métodos de las
clases.
 En la segunda deben ser actualizados de tal manera que
todos los métodos de las clases estén en algún diagrama
de interacción.
 Los patrones de diseño son útiles para asignar
responsabilidades correctamente.
 Las tarjetas CRC permiten documentar las clases y
sus colaboradoras mas cercanas.