Академический Документы
Профессиональный Документы
Культура Документы
(Diseo y Arquitectura)
Clases 12 y 13
Otoo del 2005
El Proyecto:
Revitalizar el centro (town) de Manteo, North Carolina.
Los desafos:
Revitalizar el centro sin destruir sus aspectos caractersticos.
Detectar y potenciar las caractersticas que eran importantes
para los habitantes de Manteo.
Establecer lineamientos of caractersticas (patrones) que
deberan respetar las nuevas construcciones/remodelaciones.
The Spirit of Patterns: The Re-
design of Manteo
El mapa de la Estructura Sagrada
Jules Park
The Dutchess restaurant
A gravel parking lot
The post office
The marshes (pantanos)
Locally made street signs
Fearings soda shop
The church
The cemetery
... Etc.
Ejemplo de Estos Patrones
Ejemplo de Estos Patrones
The Theory of Patterns: A
Pattern Language
Objetivo:
Especificar calidad sin un nombre.
. conocimiento reusable.
Layers: Problema
Si los servicios no estn bien organizados, el sistema
podra tener problemas de mantenibilidad,
adaptabilidad y escalabilidad.
Layers: Solucin
Estructurar el sistema en un nmero apropiado de
capas.
Empezar con la capa con el nivel ms bajo de
abstraccin.
Poner la capa J sobre la J-1 hasta alcanzar la capa N.
Los servicios de J usan los servicios de J-1.
No se requiere un orden en la implementacin, ni
ninguna sofisticacin.
Dentro de cada capa, las componentes tienen el mismo
nivel de abstraccin.
Layers: Estructura de la Solucin
Caractersticas principales de la estructura:
los servicios de la capa J se basan solamente en los de
la capa J-1;
no existen otras dependencias entre las capas;
la estructura puede verse como una pila o una cebolla.
Nivel 2
Nivel 1 Usuario
Layers: Otra Estructura
Cada capa puede ser una entidad compleja formada
por distintas componentes.
Una componente en la capa J puede llamar a:
otra componente en la capa J,
componentes en la capa J-1 directamente,
una interfaz definida en la capa J-1.
Otras Aplicaciones
Mquinas Virtuales.
APIs.
Sistemas de Informacin.
Layers: Consecuencias
Desventajas:
data
f1
data
f2
data
Pipes y Filtros: Dinmica
Escenario 2: Push/Pull Pipeline:
origen y destino de datos pasivos,
el filtro 2 juega el rol activo iniciando el proceso.
Filtro 1 Filtro 2
Fuente de Datos Destino de Datos
pull pull/push
data read
read f1
data
f2
data
write
Pipes y Filtros: Implementacin
Dividir las tareas en una Decidir implementacin de
secuencia de pasos de cada pipe:
procesamiento: determina la
los procesos deben ser implementacin de los
independientes y filtros (activo o pasivo).
ordenados.
Disear e implementar
Definir el formato de los filtros.
datos transmitidos a travs
Disear poltica de errores.
de cada pipe:
flexibilidad vs. Instalar el sistema.
performance.
Ejemplo: Compilador MOCHA
Los sucesivos filtros Analizador
comparten un cierto Lexicogrfico
estado: la tabla de
Tabla de Smbolos
smbolos. Analizador
Sintctico/Parser
No es una arquitectura
Pipes y Filtros estricta. Analizador
Semntico
La implementacin es
un nico programa. Generador de
Cdigo Intermedio
Pipes y Filtros: Consecuencias
Beneficios: Desventajas:
los archivos intermedios compartir informacin de
no son necesarios, estado es caro y poco
flexibilidad, flexible,
Inteligencia Pizarron
artificial. (datos compartidos)
bc7
Sistemas bc4
colaborativos de
apoyo a la toma
de decisiones. bc5
bc6 cmputo
memoria
Pizarrn: Contexto
Un dominio inmaduro en el cual no existe una
solucin conocida o factible de antemano.
Pizarrn: Problema
La descomposicin del problema abarca muchas
reas de especialidad.
Cada solucin parcial requiere distintas
representaciones y paradigmas.
El conocimiento es incierto o aproximado.
Pizarrn: Problema
Fuerzas:
una bsqueda exhaustiva de soluciones no es factible,
los mdulos deben ser intercambiables porque ninguno
es seguro que obtenga la mejor solucin,
existen algoritmos que obtienen soluciones parciales,
input, output y algoritmos usan datos con diferentes
representaciones,
algunos algoritmos usan los resultados de los otros.
Pizarrn: Solucin
Coleccin de programas Existe un control central que
independientes que trabajan coordina los programas
colaborativamente sobre dependiendo del estado de
datos compartidos. los datos (moderador):
resolucin oportuna de
Cada programa se
problemas.
especializa en resolver parte
del problema. Se experimenta con
soluciones parciales, se las
Los programas no se
combina y se las desecha.
comunican directamente sino
a travs de los datos. Los programas tambin
pueden tomar iniciativa e
interactuar con los datos.
Pizarrn: Estructura
Pizarrn:
almacenamiento central de Control:
informacin, monitorea el estado del
vocabulario: conjunto de sistema y decide la
todos los datos que prxima accin,
aparecen en el pizarrn. las decisiones se basan
en el progreso o costo
Bases de Conocimiento:
del conocimiento,
subsistemas independientes detecta estados finales
especializados,
aceptables e insolubles.
escriben y leen del pizarrn,
parte de diagnstico y parte
de accin.
Patrones
Arquitectnicos para
Sistemas Interactivos
Patrones para Sistemas
Interactivos
La informacin se 30
Rojo
Azul
39
6
muestra con distintos
20
10 Verde 10
formatos. 0
Negro Rojo Azul Verde Ot ro
Otro 2
Problema:
Las interfaces de usuario son muy
frecuentemente cambiadas.
Cambios en la funcionalidad deben reflejarse en
las interfaces.
Puede haber interfaces a medida para ciertos
usuarios.
Diferentes paradigmas de interfaz:
digitar informacin,
seleccionar conos.
Construir un sistema monoltico es caro y difcil.
Modelo-Vista-Control (MVC)
Fuerzas:
la misma informacin se presenta de distintas formas,
cambios en los datos deben reflejarse en la interfaz
inmediatamente,
las interfaces deben modificarse fcilmente, ojal
durante la ejecucin,
distintas interfaces portables no deben afectar la
operacin esencial.
Modelo-Vista-Control (MVC)
Solucin:
MVC divide la aplicacin en Cada view tiene asociada un
procesamiento, input y controlador. El controlador
output. recibe eventos como input
(movimientos del mouse,
El modelo representa la
activacin de botones) y los
funcionalidad y los datos
traduce a solicitudes de
esenciales, y es
servicios del modelo o la
independiente de la
view.
representacin en las
interfaces. El usuario interacta con el
modelo solamente a travs
La view obtiene datos del
de controladores.
modelo y los despliega para
el usuario.
Modelo-Vista-Control (MVC)
Estructura:
Modelo View
encapsula la informacin despliega los datos para
esencial y exporta el usuario;
procedimientos que realizan tienen procedimientos de
procesamiento especfico de la actualizacin para recibir
aplicacin; nuevos datos.
provee funciones para que las Controlador
views accedan a la
informacin; existe un controlador
para cada view;
el mecanismo de cambio-
propagacin mantiene recibe los inputs de una
informados a las views y a los view como eventos y los
controladores dependientes. interpreta.
MVC: Estructura del Ejemplo
Torta
El modelo guarda los votos
acumulados para cada
partido poltico y permite Controlador_Tr
Barras Controlador_Tb
Tabla
MVC: Dinmica
Escenario I: Input del usuario cambia el modelo y
gatilla el mecanismo de cambio-propagacin.
obtener datos
actualizar
obtener datos
Modelo-Vista-Control (MVC)
Implementacin:
Ejemplo (cont.):
- Diferentes versiones, adaptan la interfaz de usuario a necesidades
especficas, por ej., para ver las bancas del parlamento en funcin
de los partidos polticos.
Fuerzas:
- Los agentes normalmente mantienen su estado y sus
datos, sin embargo tienen que cooperar y trabajar en
conjunto.
- Los agentes proveen su propia interfaz de usuario pues
cada uno tiene una cierta interaccin prevista con el
usuario. Sin embargo, las modalidades de interaccin
deben ser similares para que la HCI del producto sea
homognea.
- Separar la presentacin, de la funcionalidad, para que los
cambios en la interfaz no afecten demasiado al resto del
sistema. De todos modos la presentacin y la funcionalidad
deben tener parmetros de acoplamiento aceptables.
Presentacin-Abstraccin-Control
Solucin:
- Organizar la estructura del sistema, jerrquicamente, segn 3
niveles de agentes: alto nivel, intermedio y bajo nivel.
- Los agentes de alto nivel proveen el ncleo de la
funcionalidad del sistema. Este tipo de agente es quien
coordina y estructura la funcionalidad del sistema (menes,
barras de herramientas, etc).
- Los agentes de bajo nivel representan conceptos
autocontenidos, sobre los cuales los usuarios del sistema
actan. Tpicamente estos agentes soportan las operaciones
de los usuarios.
- Los agentes intermedios representan combinaciones o
relaciones entre agentes de bajo nivel. Por ejemplo, este tipo
de agentes puede representar diversas vistas sobre los datos.
Presentacin-Abstraccin-Control
Solucin:
- Ejemplo: veamos un sistema de informacin electoral.
Repositorio
Alto nivel
Acceso a Datos
Controlador
Intermedio
de Vistas
Solucin:
- Cada uno de los agentes es responsable de una parte de la
funcionalidad de la aplicacin y contiene 3 componentes:
presentacin, abstraccin y control.
- La presentacin provee el aspecto visible del agente.
- La abstraccin provee el modelo de datos del agente y las
operaciones para operar con estos datos.
- El control conecta los componentes de presentacin y de
abstraccin, y le agrega la funcionalidad necesaria para
comunicarse con otros agentes.
Presentacin-Abstraccin-Control
Estructura: cada agente representado en la jerarqua
tiene la siguiente estructura.
Controlador de Vistas
Control Presentation
Abstraction
InteractionData
BarData PresentationData
SendMsg
SetChartData Update
ReceiveMsg
GetChartData Open
GetData
Close
Zoom
Print
Agente Graficador de Barras
Presentacin-Abstraccin-Control
Dinmica: para cada escenario que sea representativo, es
necesario definir la dinmica de las clases que forman
parte de la estructura. Definir al menos un par de
escenarios.
Consecuencias:
- Beneficios: Separacin de conceptos, soporte para el
cambio y la extensin, soporte multitarea.
- Complicaciones: Incrementa la complejidad del sistema,
presenta problemas de eficiencia y de aplicabilidad,
involucran componentes de control complejos.
Patrones para
Sistemas Adaptables
Patrones para Sistemas
Adaptables
MicroKernel: Es usado en sistemas de software que
deben adaptarse a los cambios en los requisitos. Este
separa el ncleo funcional, la funcionalidad extendida y
los aspectos relativos al cliente.
Reflexion: Provee un mecanismo para cambiar la
estructura y el comportamiento de un sistema de
software, en forma dinmica. Este patrn divide a una
aplicacin en dos partes: un meta nivel que provee
informacin acerca de las propiedades del subsistema
seleccionado, y un nivel base que provee la lgica de la
aplicacin.
MicroKernel
Ejemplos de sistemas MicroKernel son los sistemas operativos:
NextSTEP, UNIX System V, MS Windows, OS/2 Warp.
Contexto: Desarrollo de aplicaciones que utilizan interfaces de
programacin similares, sobre las cuales construye un ncleo de
funcionalidad similar.
Problema: El desarrollo de software de dominio especfico es una
tarea no trivial (Sist. Operativos, GUIs, etc). Los tiempos de vida
de estos sistemas son largos, y tienen que incorporar los cambios
tecnolgicos con el menor costos (y tiempo) posible.
Fuerzas:
- La plataforma de la aplicacin debe contemplar los cambios
tecnolgicos tanto en hardware como en software. Sin embargo,
considerar todas las posibilidades podra elevar el costo
innecesariamente.
- La plataforma de la aplicacin debe ser portable, extensible y
adaptable, para permitir la integracin de las tecnologas
emergentes. Estas tecnologas pueden ser actuales o futuras.
MicroKernel
Solucin:
- Encapsular los servicios fundamentales de la
plataforma de aplicacin, en un componente
microkernel. El microkernel incluye la funcionalidad
que permite a otros componentes, ejecutar en forma
separada (como proceso) y comunicarse entre ellos.
Este es conocido como internal server.
- Encapsular los servicios perifricos al ncleo en
subsistemas que agrupan servicio similares. Estos
son conocidos como external servers.
- Los clientes se comunican con los external servers
usando las facilidades de comunicacin provistas por
el microkernel.
MicroKernel
Estructura:
MicroKernel
executeMechanism
External Server initComunication Internal Server
receiveRequest calls findReceiver activate executeService
dispatchRequest createHandle receiveRequest
executeService sendMsg
callInternalServer
sends
request
Adapter Client
callService doTask
createRequest Calls service
MicroKernel
Dinmica: Idem a patrones anteriores.
Consecuencias:
- Beneficios: Portabilidad, flexibilidad, escalabilidad,
confiabilidad, transparencia.
- Problemas: Performance, Complejidad del diseo e
implementacin.
Recomendaciones Generales
Desempeo.
Si el desempeo es un requisito crtico, la arquitectura debe
estar diseada para albergar las operaciones crticas, dentro
de un nmero reducido de subsistemas (menos cambios de
contexto).
Ojal con poca comunicacin entre ellos.
Esto significa utilizar componentes de grano grueso, de esa
manera habr menos componentes en el sistema.
Seguridad.
Si la seguridad es un requisito crtico, se debe utilizar una
arquitectura estratificada (por capas).
Los recursos ms crticos deben alojarse en las capas ms
inferiores (internas).
Cada capa debe proveer un mecanismo de validacin, de
acuerdo a la informacin que sta maneja.
Recomendaciones Generales
Proteccin (de operaciones).
Si la proteccin es un requisito crtico, la arquitectura
debe estar diseada de tal forma que las operaciones
relacionadas con la proteccin, se localicen en nico
subsistema o en un conjunto muy reducido de estos.
Esto reduce los costos y los problemas de validacin, y
hace posible crear sistemas de proteccin relacionados.
Disponibilidad.
Si la disponibilidad es un requisito crtico, como parte de
la arquitectura se deben incluir componentes
redundantes.
Estos podrn reemplazar a los componentes con
problemas, en caso de fallas.
Recomendaciones Generales
Mantenibilidad.
Si la mantenibilidad es un requisito crtico, la arquitectura
debe estar diseada utilizando componentes
autocontenidos de grano fino.
Estos componentes pueden ser mdulos o componentes
de software bien definidos.
Estos podrn cambiarse o reemplazarse con facilidad, y
con un mnimo efecto sobre el resto del sistema.
Los productores de datos deben estar separados de los
consumidores.
Las estructuras de datos compartidas deben evitarse.
La circulacin de rdenes de control entre mdulos o
subsistemas, tambin debe evitarse.
Conclusiones
Hay arquitecturas de son mejores que otras, dependiendo
del escenario de trabajo (dominio + infraestructura
previa), del tipo de software a desarrollar, y de lo que se
pretende obtener.
Los patrones arquitectnicos brindan una sugerencia
(genrica) acerca de cmo resolver algunos de los
problemas arquitectnicos mas comunes.
Los patrones arquitectnicos no son la salvacin de nadie,
pero generalmente ayudan.
Se pueden utilizar mezclas de patrones, y adaptaciones de
ellos.