Una vuelta de tuerca a Haythorn
Sonia Pamplona Roche
junio, 2006
Índice
• Introducción
–
–
–
–
Antecedentes
Objetivos
El caso de estudio
Método de trabajo
• Desarrollo
– Organización del espacio software
– Modificabilidad
– Semántica
• Conclusiones
Antecedentes
Introducción
• Se necesitan técnicas de diseño para
facilitar las modificaciones, pero hay
rechazo al uso de tales técnicas
• “What is object-oriented design?
–
Diseñar para facilitar las modificaciones,
–
Pautas para diseñar de ese modo.
• Ideas importantes, pero sólo esbozadas
Objetivos
Introducción
– Descubrir la esencia y consecuencias
del trabajo de Haythorn utilizando la
ambigüedad como instrumento de
análisis.
– Determinar la incidencia del trabajo de
Haythorn sobre criterios tradicionales
de diseño: modularidad, facilidad de
comprensión y copia de la realidad
El caso de estudio
Introducción
Distintas soluciones de diseño software para simular
situaciones de colas en un banco
ESTADO
ESTADO
ESTADO
ESTADO
ESTADO
ESTADO
ESTADO
Diseño I
Introducción
Diseño estructurado
tradicional
Datos estadísticos de la distribución de clientes
CREAR CLIENTE
• Las acciones son
funciones de
transformación de
datos
• Los elementos del
dominio son datos
Cliente en espera
Lista de cajeros libres
Cola de clientes
Cajero libre
Cajero libre
Cliente en espera
CAJERO
TERMINA CON
CLIENTE
ASIGNAR
CLIENTE A
CAJERO
(Cajero en servicio, Cliente siendo atendido)
(Cajero en servicio, Cliente siendo atendido)
Lista de clientes y cajeros
Diseño II
Introducción
Diseño orientado a
objetos “naive”
Banco
trabaja hasta (tiempo)
• Identifica los objetos a
partir de los elementos
del dominio.
Lista de cajeros
crear()
disponible()
Cliente
estado()
acepta (me)
sirve()
finaliza()
Cajero
Cola de clientes
siguiente()
Diseño III
Introducción
Diseño orientado a
objetos“auténtico”
C o la d e e v e n to s
o cu rre ()
C a je ro s irv e a c lie n te
• Enfatiza el uso de los
recursos de los
objetos.
p la n ifica (th is )
E v e n to
L le g a d a d e c lie n te
C a je ro fin a liza
d e sp a ch a r(clie n te *)
d e sp a ch a r(ca je ro *)
n u e vo (ca je ro *,clie n te *)
C o o rd in a d o r
n u e vo ()
b o rra r()
n o va cío ()
n o va cío ()
p u t(*)
p u t(*)
g e t()
g e t()
C o la d e c a je ro s
C o la d e c lie n te s
C a je ro
C lie n te
Diseño IV
Introducción
Extensión del diseño precedente
planifica(this)
Evento
Cola de eventos
ocurre()
Cajero sirve a cliente
nuevo(cajero,cliente)
Cajero finaliza
Llegada de cliente
despachar(cajero, cliente)
despachar(cliente)
Informa(condición)
Coordinador
put(cliente)
Informa(condición)
DameClienteEnEspera()
DameCajeroLibre()
Estado de Cajero
Cola de cajeros
Cola de clientes
Cajero
Cliente
Informa(condición)
Libre
Ocupado
Informa(condición)
Estado de Cliente
nuevo()
En cola
Siendo Atendido
Atendido
Método de trabajo
Introducción
1. Estudiar el algoritmo y su distribución en
cada diseño.
2. Estudiar los elementos y sus relaciones en
cada diseño.
3. Estudiar las consecuencias de los cambios
propuestos en cada diseño.
4. Estudiar la semántica de cada diseño, lo
que comunica el diagrama del diseño,
para estudiar la comprensión.
Organización del espacio software
Desarrollo
Cada diseño es una forma distinta de organizar el
mismo algoritmo. Son sistemas “alotrópicos” con
igual función, pero distintas propiedades.
Crear cliente
Banco
Mientras el banco esté abierto
Crear cliente
Mientras el banco esté abierto
Lista de cajeros
Obtener Siguiente Evento
Añadir cliente a cola
Obtener Siguiente Evento
Cliente
Si Siguiente Evento es una llegada de cliente
Si Siguiente Evento es una llegada de cliente
Llamada Crear Cliente
Crear cliente
Crear cliente
Llamada Cajero Libre
Llamada Estado cajero?
Llamada Mientras no llegue cliente
Añadir cliente a cola
Banco
Mientras no llegue cliente
Si Cajero Libre
Si Siguiente evento es cajero finaliza con
cliente
Llamada Servir Cliente
Llamada Añadir cliente cola
Llamada Finalizar cliente
Mientras el banco esté abierto
Si Siguiente evento es cajero finaliza con
cliente
Obtener Siguiente Evento
Fin del Mientras banco abierto
Cola de clientes
Fin Mientras no llegue cliente
Si Siguiente Evento es una llegada de cliente
Lista de cajeros
libres
Añadir cliente a cola
Llamada Crear cliente
Finalizar cliente
Si Siguiente evento es cajero finaliza con
cliente
Poner estado de cajero Libre
Cola de
clientes
Cajero
Llamada Finalizar cliente
Cliente siguiente
Servir cliente
Si hay cajeros libres y cola clientes NO
vacia
Finalizar cliente
Si hay cajeros libres y cola clientes NO
vacia
Estado cajero?
Llamada asignar cliente a cajero
Asignar cliente
a cajero
Finalizar cliente
Asignar cliente a cajero
Llamada Cliente Siguiente
Fin del Mientras
Poner estado de cajero Libre
Asignar cliente a cajero
Fin del Mientras
Si hay cliente siguiente
Servir cliente
Lista de cajeros
y clientes
Poner cajero libre
Estudio de las relaciones de cada diseño
Desarrollo
Ambigüedad en las relaciones de cada diseño
Banco
planifica(this)
Evento
Cola de eventos
planifica(this)
Evento
ocurre()
Cajero sirve a cliente
Cajero sirve a cliente
trabaja hasta (tiempo)
Cajero finaliza
Cola de eventos
ocurre()
Cajero finaliza
Llegada de cliente
Llegada de cliente
crear()
nuevo(cajero,cliente)
despachar(cajero, cliente)
despachar(cliente)
Informa(condición)
Coordinador
put(cliente)
Informa(condición)
Lista de cajeros
disponible()
nuevo(cajero, cliente)
Cliente
despachar(cajero)
despachar(cliente)
DameClienteEnEspera()
DameCajeroLibre()
Cola de cajeros
Cola de clientes
Coordinador
Estado de Cajero
borrar()
finaliza()
estado()
acepta (this)
Cajero
Cliente
Estado de Cliente
nuevo()
novacío()
sirve()
Cajero
Informa(condición)
novacío()
put()
nuevo()
put()
get()
get()
Cola de cajeros
Cola de clientes
Cajero
Cliente
Libre
Ocupado
Informa(condición)
En cola
Siendo Atendido
Cola de clientes
siguiente()
Relación ambigua
Relación unívoca
Atendido
Estudio de la modificabilidad
Desarrollo
Para cada cambio se estudia dónde se localiza y
si se propaga al resto del diseño.
• En el diseño II hay propagación de los cambios a
causa de las relaciones unívocas.
• En los diseños III y IV no hay propagación de los
cambios gracias a las relaciones ambiguas.
• Si hay relaciones ambiguas, los cambios no se
propagan.
• La modularidad no influye en la modificabilidad.
Semántica
Desarrollo
• La organización del espacio software incide en el significado
de los elementos y relaciones del diseño.
• Los diseños que facilitan las modificaciones, alejan los
diseños de los significados tradicionales.
• La resolución del conflicto precedente aconseja cambiar la
forma de pensar el diseño software.
• La comprensión de los diseños depende del observador.
• Cada observador apreciará una realidad distinta y además
llevará al diseño de forma distinta su imagen de la realidad.
• Se confirma que apreciar un diseño próximo a la realidad no
significa necesariamente que se modifique mejor.
Conclusiones
Conclusiones
•
La ambigüedad ha sido un instrumento efectivo de análisis porque
ha permitido explicar los distintos comportamientos de los diseños
desde una perspectiva uniforme.
•
La técnica de Haythorn consiste en organizar el espacio software
para:
– aislar los cambios potenciales dentro de abstracciones (ambigüedades)
especializadas
– obtener dependencias indiferentes a través de relaciones ambiguas.
•
La forma de organizar de Haythorn mejora la modificabilidad, pero
se aleja de los cánones tradicionales y se dificulta la comprensión.
•
Para mejorar la modificabilidad y la comprensión a la vez, hay que
reacomodar la forma de pensar el diseño software.
Descargar

Una vuelta de tuerca a Haythorn