1

Factores que influencian la arquitectura

Stakeholders del sistema (clientes, usuarios, desarrolladores, PM, testers, trainers, deployer, etc)
Factores tcnicos y organizacionales
Contexto profesional de un arquitecto
Background de los arquitectos
Todos los stakeholders hacen sugerencias basadas en diferentes concepciones del negocio y diferentes objetivos.
Arquitectura en el contexto del negocio
La arquitectura sirve al propsito del negocio
Estos propsitos de negocio cambian en el tiempo
Invertir en, y luego la amortizacin de la infraestructura
Mantener costos bajos
Ganar dinero
El arquitecto debe conocer los objetivos de las organizaciones
Temas de la estructura organizacional
La promocin de los intereses creados, por ejemplo,
El mantenimiento de una base de datos existente en la organizacin
Mantener los estndares

El entorno tcnico depende de las tendencias actuales y de la tecnologa disponible. Actualmente es muy comn
hacer aplicaciones Web multiplataforma con una base de datos para el sistema de gestin, cosa que hace 10 aos no
era comn.aun asi, sin importar la tendencia se esta limitado por que tecnologa puede/quiere obtener la empresa.
UN ARQUITECTO TIENE UN PROFUNDO CONOCIMIENTO TECNICO, PERO TAMBIEN TIENE CAPACIDAD DE DIALOGO Y
NEGOCIACION PARA COORDINAR CON LOS STAKEHOLDERS LOS OBJETIVOS, LLEGAR A UN ACUERDO CON TODOS Y
LOGRAR UNA FLUIDA COMUNICACIN
El arquitecto es producto de la experiencia, tanto de las buenas (que repetir) como de las malas (que evitar). Sus
skills estn dados por:
Destrezas interpersonales: debe ser capaz de:
Negociar intereses contrapuestos de las partes interesadas
Promover la colaboracin entre equipos
Conocimientos tcnicos: debe entender:
Las relaciones entre calidad y la estructura
La tecnologa actual
2

Que la mayora de los requerimientos de una arquitectura no estn escritos en ningn documento de
requerimientos
Habilidades de comunicacin: debe ser capaz de
Transmitir claramente la arquitectura a los equipos (tanto verbal como por escrito)
Escuchar y comprender mltiples puntos de vista


La arquitectura de software de un programa de computacin o sistema es la estructura o estructuras del sistema,
que comprenden los componentes de software, las propiedades visibles de esos componentes y las relaciones entre
ellos.
Esto significa que
Una caja y una lnea dibujada por s solos no son arquitecturas.
La arquitectura incluye el comportamiento de los componentes
Una arquitectura es importante porque:
Software para un sistema o grupo de sistemas
Proporciona influencia sobre un mercado
Proporciona un vehculo para la supervisin de la gestin
Establece el alcance de los productos
Se puede utilizar como una herramienta de ventas (por ejemplo, se ajusta a estndares de la industria)
Las arquitecturas empresariales permiten
El aprendizaje en ms corto tiempo
Soporte de herramienta especializadas
Compartir los costos de infraestructura entre los sistemas




3

La arquitectura es importante por tres razones principales.
1. Constituye un vehculo para la comunicacin entre grupos de inters.
2. Es la manifestacin de las primeras decisiones de diseo acerca de un sistema.
3. Se trata de una abstraccin transferible y reutilizable de un sistema.
Pero si la arquitectura no esta bien definida, puede causar problemas:
Falla en intentar soportar las necesidades de negocio, generalmente porque:
Falta de compromiso del usuario para que el proyecto termine (problemas en la comunicacin)
El resultado entre el proveedor-usuario no es win-win
Este falla en cumplir con la calidad necesaria
El 50% de proyectos que se atrasan tienen problemas en la arquitectura
El 35% de los los proyectos que exceden el costo de construccin tienen problemas en la arquitectura
Para saber si una arquitectura es idnea, hay que realizar una evaluacin previa. A diferencia de una VERIFICACION
(que se hace al final para ver que se haya implementado bien), la EVALUACION se hace antes de implementar.Dicha
evaluacin puede ser hecha por gente interna o externa al proyecto, aunque lo mas recomendable es que este
hecha por gente externa (menos influenciada)de esa forma, se puede saber si la arquitectura cumple con los
requerimientos de negocio, atributos de calidad y restricciones presentes, asegurndose que el sistema a ser
construido cumple con las necesidades de los stakeholders.
Pasos bsicos para planear una evaluacin
Preparacin
Contexto
Definicin del equipo de Evaluacin
Alcance de la evaluacin
Representacin de la arquitectura
Realizacin
Presentar el problema de negocio a resolver y la arquitectura planteada
Evalan el costo, la funcionalidad, los atributos de calidad
Revisan requerimientos y posibles cambios
Discuten problemas y observaciones
Generar y distribuir los resultados
Issues y Recomendaciones
Anlisis de riesgo con plan de accin
Las arquitecturas pueden evaluarse:
Durante la propuesta (solo el esqueleto que permite estimar tiempos y costos)
La solucin cumple con los objetivos de negocio
Es tcnicamente factible, implementable?
Con los recursos disponibles y contexto actual es practica?
Durante el desarrollo. Arquitectura implementable. (por ejemplo, o por cada iteracin/importantes)
Identificar problemas y analizar los Riesgos tcnicos
4

Para evaluar se usan diferentes tcnicas, ya sea de cuestionamiento o cualitativas (cuestionarios, checklists,
escenariosSE USAN ANTES DE LA CONSTRUCCION DE LA ARQUITECTURA) o de medicin (mtricas arquitectnicas
como acoplamiento, cohesividad entre modulos, modificabilidad; o simulaciones con prototiposSE USAN UAN VEZ
QUE LA ARQUITECTURA FUE IMPLEMENTADA)

EVALUACIONES TEMPRANAS:
El objetivo es ver si la solucin tcnica cumple con los requerimientos y si es tcnicamente factible con los recursos y
tecnilogia disponibles.
Roles que participan:
Arquitecto evaluador (Puede haber un PM)
Especialistas evaluadores (Si es necesario)
Arquitecto, Analista y PM de Solution
Stakeholders que participaran en el Desarrollo
Fases:
1. Entender el contexto (Suposiciones, Restricciones, Atributos de Calidad, Negocio, Stakeholders)
2. Verificar si es razonable la solucin y permite cumplir con los requerimientos
3. Es posible ser construida por el team, ver la infraestructura y los recursos.
4. Identificar y Analizar los riesgos tcnicos (documentarlos)
Resultados: lista de issues y recomendaciones, lista de observaciones tcnicas que pueden terminar en riesgos
(evaluando cual es la probabilidad y su nivel de impacto y cual es la recomendacin mitigar, descartar, aceptar - )
Este tipo de evaluaciones tienen un costo bajo y pueden evitar problemas a futuro que generen altos costos, fuerza a
una mejora a la documentacin, detecta problemas de forma temprana, valida requerimientos (como se pone en tel
de juicio la adaptacin de la arquitectura a los mismos, se terminan evaluando tambin los requerimientos
descartando aquellos que no son importantes).
Una vez terminada la evaluacin se elabora un reporte que responde a 3 preguntas
Se ha diseado la arquitectura ms apropiada para el sistema?
Cul de las arquitecturas propuestas es la ms apropiada para el sistema a construir?
Se cumplieron con los atributos de calidad?
ATRIBUTOS DE CALIDAD Requerimientos no funcionales
Son aspectos no relacionados con la funcionalidad necesitada, pero definen la calidad y las caractersticas que el
sistema debe soportar. La arquitectura posibilita o inhibe estos atributos, aunque no todos dependen de esta y
algunos de estos requerimientos entran en conflicto entre si o con requerimientos funcionales.
5

Por lo general hay un problema a la hora de definirlos, ya que se definen de forma muy genrica (el sistema debe
ser modificabletodos los sistemas son modificables). EL REQUERIMIENTO TIENE QUE SER NO AMBIGUO Y SER
TESTEABLE.
Todo atributo de calidad tiene un ESTIMULO, un AMBIENTE, y una RESPUESTA que ayudan a su medicin.
Origen del Estmulo Cualquier actor que interacta con el sistema.
Estimulo Es una condicin que necesita ser considerada cuando arriba al sistema.
Ambiente Son las condiciones en la cual se encuentra el sistema en el momento que se recibe el estmulo.
Componentes Son los componentes del sistema Componente que son afectados
Respuesta La respuesta es la actividad que debe realizar el sistema.
Medida de la Respuesta Es un tipo de medida con al cual debe cumplir la respuesta para que el requerimiento
pueda ser testeado.

En lneas generales, los atributos de calidad se agrupan en:
Performance (Rendimiento)
Availability (Disponibilidad)
Security (Seguridad)
Testability (Comprobabilidad)
Modifiability (Modificabilidad)
Usability (Usabilidad)
PERFORMANCE
Es el grado en el cual el sistema o componente lleva a cabo una funcionalidad especifica dada una restriccin de
velocidad, precisin, etc. y el uso eficiente de los recursos
Patrones de Arribos (Eventos)
Puede ser peridico, probabilstica o espordico.
Dependiendo lo que se mide no importa la cantidad de usuarios sino los pedidos o transacciones.
Patrones de Respuesta
Latencia. Puede ser medido por el tiempo que tarde el sistema en responder
La cantidad de transacciones que el sistema puede responder
Nmeros de Eventos no procesados y la cantidad de informacin perdida por que el sistema no puede responder




6

Pasos previos:
Requerimientos: Evitar el lo ms rpido posible.
Qu se puede medir?: Consumo de recursos , Procesador, memoria, disco, red, etc. , Latencia ,
Escalabilidad
Medicin y profiling: Medicin del consumo de los recursos durante la ejecucin. Se necesitan datos de
prueba realistas (no necesariamente reales)
Tacticas
Incrementar la eficiencia computacional, elimitar el overhead o reducir el numero de eventos procesados
Poner limite a los tiempos de ejecucin (bound excecution times)
Poner limite mximo al numero de arribos encolados (bound queue size)
Concurrencia (thread especializados o multiples threads)
Replicacion
Cache
Escalamiento (vertical u horizontal)
Incrementar recursos
Admin de recursos:
Ej: Los usuarios inician 1.000 transacciones X, por minuto (probabilidad) bajo condiciones normales, de 9 a 18:00hs,
el sistema debe procesarlas (resultado en pantalla) en una latencia menor a 3 segundos.
Origen del Estmulo: Usuarios. Definir el tipo de Usuario si es necesario.
Estimulo: Inicio de Tx X. Probabilstico. 1.000 tx por minuto.
Ambiente: Procesamiento Normal. De 9 a 18. Carga Normal.
Componentes: Todo el Sistema.
Respuesta: Transaccin procesada.
Medida de la Respuesta: La latencia debe ser menor a 3 segundos.

DISPONIBILIDAD
Es el grado de operabilidad de un sistema. Esta relacionada con las fallas y las consecuencias asociadas,
diferenciando entre desperfecto (fault) que no son controlados o falla (failure) que si son observables.
Hay que tener en cuenta la CONFIABILIDAD, CAPACIDAD DE RECUPERACION DE DESASTRES, CORTES (programados o
no), TOLERANCIA A FALLOS. Una mayor disponibilidad implica un costo mayor.
Medidas de Prevencion: MONITOR DE PROCESOS, TRANSACCIONES, TECNICAS DE INTEGRACION, REPLICACION DE
DATOS.
Ej: Si el Middleware tiene alguna falla y no recibe pedidos, para transacciones que necesitan ser procesadas de
manera asincrnicas se debe auditar en un archivo de log y se debe reintentar X veces con un intervalo de Y
segundos.


7

Origen del Estmulo: El Middleware est cado.
Estimulo: Transacciones asincrnicas a procesar.
Ambiente: En todo momento.
Componentes: Manejador de Transacciones e Interfaz con el Middleware.
Respuesta: Guardar en log y Reintentar.
Medida de la Respuesta: X veces con un intervalo de Y.

MODIFICABILIDAD
Relacionado con el costo del cambio, teniendo en cuenta QUE HAY QUE CAMBIAR, CUANDO Y QUIEN LO HACE. Se
puede agrupar en:
Mantenibilidad: relacionado a solucin de problemas
Extensibilidad: para agregar nuevas funcionalidades
Restructuracion: reorganizar la aplicacin
Interoperabilidad: integracin entre sistemas
Tacticas
Basicamente hay que ubicar bien los puntos a modificar para evitar ripple effects (que una modificacin me genere
cambios inesperados). Para evitar esto tambin es importante tener un diseo que tenga: Cohesion y acoplamiento,
Coherencia semntica, Generalizacion, Anticipado a los cambios
Ej.: Un stakeholder desea que el sistema publique algn servicio para ser consumido por otra aplicacin (y no por
pantalla) luego de que el sistema est en su primera release de produccin y el tiempo de desarrollo (anlisis,
design, code, test y deploy) no supere los 25 das desde la aprobacin del Change Request.
Origen del Estmulo: Stakeholder.
Estimulo: Desea agregar funcionalidad.
Ambiente: Etapa de Mantenimiento.
Componentes: Core Service e Interfaces.
Respuesta: Cambio de Requerimiento correctamente implementado.
Medida de la Respuesta: Que no supere los 25 das.

SEGURIDAD
Medida sobre la habilidad del sistema para resistir usos no autorizados in dejar de prestar servicio. Tener en cuenta
que los ataques no siempre son de accesos no deseados, tambin hay ataques sobre la disponibilidad (DoS) o
pueden ser problemas de seguridad internos.
Principios: NO REPUDIO, CONFIDENCIALIDAD, INTEGRIDAD, ASEGURAMIENTO, DISPONIBILIDAD, AUDITORIA.
Tacticas:
Resistencia a ataques
Autenticacin de usuarios
Autorizacin de usuarios
Confidencialidad de los datos (encripcin, VPN, SSL)
Integridad de los datos (redundancia, checksums, hash, firmas)
8

Limitar la exposicin o el acceso (DMZ)
Deteccin de ataques
Recuperacin
Recuperacin, restauracin
Identificacin, Auditora
Ej: Si el administrador de accesos (seguridad) realiza, agrega o quita algn rol a cualquier usuario, estos cambio
deben ser reflejados de manera inmediata en la sesin del usuario a la cual se le modificaron los accesos
Origen del Estmulo: Administrador de Accesos.
Estimulo: Cambio de roles.
Ambiente: En cualquier momento.
Componentes: Todo el Sistema.
Respuesta: Reflejar los cambios.
Medida de la Respuesta: Inmediatamente.
COMPROBABLIDAD
Es el grado de facilidad que tiene un sistema para probarse correcto. El 40% del costo de un proyecto es consumido
por el testing.
Tacticas:
Tipos de Test
Unitario (modularidad, separar interfaz de implementacin, mock objects, inyeccin de dependencias)
Integracin
Aceptacin
Performance / Carga / Stress
Regresin (automatizacion de tests y datasets, manejo de dependencias de ejecucin, automatizacin de corridas)
Escenarios
Casos de test
Juegos de datos
Casos bsicos
Casos extremos
Test Driven Development (contract first)
Ej.: Un tester unitario que realiza el test de un componente X debe poder ejecutar los scripts y debe poder llegar a un
nivel de completitud del 70% en 4 horas
Origen del Estmulo: Tester unitario.
Estimulo: Testear el componente.
Ambiente: En etapa de desarrollo y mantenimiento.
Componentes: Componente X.
Respuesta: 70% de completitud.
Medida de la Respuesta: 4 horas.



9

USABILIDAD
Depende del grado de facilidad para operar el sistema:
Facilidad de aprendizaje
Uso eficiente
Minimizar el impacto de errores
Adaptabilidad
Incrementar satisfaccin del usuario
Si bien esto depende por lo general del rea de User Experience, hay que tomar en cuenta algunas caractersticas al
a hora de disear la arquitecturas: permitir cancelar operaciones que estn siendo procesadas, deshacer
operaciones ejecutadas, etc.
Ej.: Los usuarios del modulo X, una vez que ejecutan cualquier accin, el sistema debe proveer la posibilidad de
cancelarlas durante su ejecucin y quedar como antes de la ejecucin de la misma
Origen del Estmulo Usuarios del mdulo X.
Estimulo Minimizar el impacto de error cancelando operaciones.
Ambiente Procesamiento Normal. Carga Normal.
Componentes Mdulo X.
Respuesta Transaccin cancelada.
Medida de la Respuesta Sistema integro antes de la ejecucin.
EVALUACION DE UNA ARQUITECTURA - ATAM
Para asegurarse que la arquitectura elegida sea la correcta hay que validar que las decisiones hechas fuesen las
indicadas. No se puede recurrir solo a la intuicin y la experiencia, dado que es muy caro cambiar una arquitectura
una vez implementada, y que esta afecta a la totalidad del proyecto, adems que facilita al entendimiento de los
requerimientos.
Una buena evaluacin descubre problemas de forma temprana, ayuda a producir mejoras en la arquitectura,
congrega stakeholders, obliga a tomar decisiones sobre los atributos de calidad (dado que no siempre se puede
cumplimentar con todos), prioriza objetivos en conflicto, obliga a una clara documentacin. Su mayor costo esta
dado por el tiempo invertido, ya sea por los stakeholders como en posibles cambios en el cronograma del proyecto.
ATAM es un metodo de evaluacion de arquitectura basado en cuestionarios y escenarios, que permite evaluar que
tan bien un atributo de calidad es soportado por la arquitectura(permitiendo reconocer las decisiones de
arquitectura que afectan a mas de un atributo de calidad). Provee un entendimiento en como los atributos de
calidad interactuan (tradeoff). NO SOLO EVALUA COMO LA ARQUITECTURA SATISFACE LOS OBJETIVOS DE CALIDAD
PARTICULARES, TAMBIEN HACE EXPLICITO COMO ESTOS INTERACTUAN ENTRE SI.
Escenario: Un escenario es una breve descripcion de la interaccion de uno de los grupos de interes con el sistema
Stakeholders: Un individuo, equipo u organizacion (o clases de los mismos) con intereses en, o relacion con un
sistema
Architectural view: Una representacion de todo un sistema desde la perspectiva de un conjunto relacionado de
requerimientos
Requerimientos funcionales: Especificar lo que el software tiene que hacer
Requerimientos no funcionales Especificar lo bien que se debe hacer
10


Atributos de calidad
Performance
Disponibilidad
Usabilidad
Seguridad
VISTA USUARIO FINAL
Time to market
Costo y beneficio
Tiempo de vida
estimado
Mercado apuntado
Integracion con
sistemas existentes
Planes de Rollback
VISTA ORGANIZACIONAL
Mantenibilidad
Portabilidad
Reusabilidad
Testeabilidad
VISTA USUARIO
DESARROLLADOR

En el ATAM participan todos los stakeholders clave para el diseo de la arquitectura: EQUIPO EVALUADOR,
RESPONSABLES DE LA TOMA DE DECISIONES, INTERESADOS EN LA ARQUITECTURA.
PRESENTACION
1-Presentacion del ATAM
Equipo evaluador, representantes de
los clientes, equipo de arquitectura
2-Presentacion de los Objetivos de negocio
3-Presentacion de la Arquitectura
INVESTIGACION Y
ANALISIS
4-Identificar las aproximaciones arquitecturales
5-Generar el rbol de atributos de utilidad
6-Analizar las aproximaciones arquitecturales
TESTING
7-Brainstorming de ideas y priorizacin de
escenarios
TODOS LOS STAKE HOLDERS
8-Analizar aproximaciones arquitecturales Equipo evaluador, representantes de
los clientes, equipo de arquitectura
REPORTE 9-Presentacion de resultados TODOS LOS STAKE HOLDERS

ATAM-1
Es una presentacin informal donde se definen las reglas de la evaluacin, se explican las tcnicas a utilizar ( utility
tree, escenarios, brainstorming) y se explica que se va a obtener al final de la misma.
EQUIPO EVALUADOR: de 3 a 5 personas, preferentemente externos al proyecto
Project decisin makers: tienen la autoridad para aprobr cambios (incluido el arquitecto)
Stakeholders: interesados en atributos de calidad y experos en implementacin de QAs
ATAM-2:
El gerente de proyecto presenta el sistema desde el punto de vista de negocio: funcionalidad, restricciones,
objetivos, stakeholders involucrados, relacin entre atributos de calidad y objetivos de negocio.
ATAM-3
Se presenta la arquitectura, las aproximaciones seguidas, las limitaciones tcnicas, sistemas externos involucrados.
ATAM-4:
El equipo de trabajo identifica las aproximaciones arquitecturales sin analizarlas (cliente-servidor, 3-tier, proxy,
hardware redundante, etc.)
ATAM-5:
El equipo de evaluacin de los stakeholders identifican y priorizan los objetivos de calidad. En las hojas del rbol de
priorizan las dimensiones graduando la importancia del sisema y el grado de dificultad.

11

Ej.:


Se definen tambin los escenarios que representan los intereses de los stakeholders y ayudan al entendimiento de
los atributos de calidad. Estos deben ser LO MAS ESPECIFICOS POSIBLES y deben cubrir: USOS PREVISTOS (USE CASE),
CAMBIOS ANTICIPADOS (EXCENARIO DE CRECIMIENTO), TENSIONES IMPREVISTAS.
Ej.:
Escenario caso de uso: Usuario remoto solicita un informe de base de datos a traves de Internet durante el periodo
pico y lo recibe dentro de los 5 segundos.
Escenario de Crecimiento: Anadir un nuevo servidor de datos para reducir la latencia en el escenario 1 y 2,5
segundos en una semana.
Escenario exploratorio: La mitad de los servidores se caen durante la operacion normal sin afectar la disponibilidad
general del sistema.
ATAM-6
Se analizan las aproximaciones arquitecturales utilizando como entrada los artefactos de los puntos 4 y 5,
idenficiando de esa forma RIESGOS, PUNTOS SENSIBLES(propiedades de uno o mas componentes que son criticas
para lograr un atributo de calidad. Ej: Mantener un backup de la base afecta la fiabilidad) Y TRADEOFFS
(propiedades que afectan a mas de un punto sensible. Ej: mantener un backup de la base de datos afecta al
rendimiento por lo que compromete tanto la fiabilidad como rendimiento).
ATAM-7
Se generan escenarios con un proceso de brainstorming, ayudados por el UTILITY TREE y luego se somenten a
votacin.
ATAM-8
Se utilizando los mejores escenarios del paso anterior y se ejecutan nuevamente las actividades del paso 6. Se repite
el ciclo hasta que no sea posible generar mas escenarios.
ARAM-9
Se documenta todo lo obtenido y se lo presenta. Ayuda a mejorar la representacin de la arquitectura, generar las
relaciones entre las decisiones arquitectnicas con los atributos de calidad y la relacin de los escenarios de negocio
con los atributos de calidad.
Se obtiene:

12

Utility tree detallado
Lista de tradeoff y puntos sensibles
Lista de riesgos y no riesgos
Agrupacion de riesgos segn el aspecto en el que impacta en la arquitectura.






DATAFLOW - PIPES & FILTERS
Un patrn es una solucin reutilizable. Puede ser
ARQUITECTONICO: expresa un esquema de organizacin estructural, suministrando un conjunto predefinido
de subsistemas y especificando responsabilidades, reglas y lineamientos para organizar las relaciones entre
ellos.
Define: que forma tienen los COMPONENTES, que forma tiene la COMUNICACIN entre ellos, que
RESTRICCIONES se pone a dicha comunicacin.
DE DISEO: suministra un esquema para refinar subsistemas o componentes de un sistema y/o las
relaciones entre ellos, describiendo la estructura de componentes que se comunican entre si y resuelven un
problema general en un contexto particular
DE CODIFICACION: buenas practicas
ANTIPATRON:
Una buena arquitectura suele combinar varios patrones.


13


Patrones Arquitectnicos
Para subdivisiones de alto nivel:
Layers: aplicaciones que pueden descomponerse en
subtareas
Pipes & Filters: aplicaciones que procesan streams de
data
Blackboard: problemas para los que no se conocen
estrategias determinsticas de solucin.
Relacionados con sistemas distribuidos:
Broker
Sistemas interactivos:
MVC
PAC
Sistemas adaptativos:
Microkernel
Reflection
Los patrones arquitectnicos generan EFICIENCIA, PORTABILIDAD Y FLEXIBILIDAD.
Supongamos ahora una situacin en donde se necesita implementar un
WS para imprimir polizas de seguro cuyos mensajes estn basados en un
estndar XML pero cada empresa amplio dicho estndar para incluir mas
datos. Ademas, el WS tiene que agregar datos locales de cada cliente que
enva los mensajes.

Si el WS se tuviese que encargar de realizar la transformacin del
mensaje, se pierde flexibilidad ante nuevos requerimientos y la
reusabilidad de las transformaciones.

Luego, se utiliza el patrn PIPES & FILTERS con 3 transformaciones
implementadas como filtros:
-Conversin: se convierte el mensaje a un formato interno
independiente, reduciendo la dependencia a las extensiones de cada
empresa sobre el XML
-Enriquecimiento: se agregan los datos extra que se necesitan
-Renderizado: el mensaje ya tiene toda la info necesaria, luego se genera
la documentacin en el formato que haya sido pedida.

Las arquitecturas Data - flow tienen como meta reutilizacin y modificabilidad. El estilo DF se caracteriza por
concebir un sistema como una serie de transformaciones sobre data de entrada.
Pipes-and-filters enfatiza la transformacin incremental de data en componentes sucesivos.
Los Filtros transforman incrementalmente la data (stream-to-stream), usan poca informacin de contexto y no
mantienen informacin de estado.
Los Pipes son sin estado y solo existen para transmitir data entre filtros.
Contexto: procesar streams de data
Problema: un solo componente puede no ser factible por mltiples razones.
Aplicabilidad: si se puede identificar un flujo secuencial (generalmente unidireccional) de data a lo largo de pasos
de proceso y cada paso es dependiente temporalmente del paso previo.
Solucin: en lugar de construir un gran componente que implementa todos los pasos: dividir el procesamiento en
pasos lgicamente distintos.
1. Data Source: entrega los datos de entrada al proceso a un Pipe
2. Pipe: transfiere la data. Se encarga del buffering, sincronizacin, etc. Tiene que manejar la comunicacin
entre filtros activos y pasivos.
14

3. Filter: obtiene la data de los sucesivos pasos mediante un Pipe y realiza alguna transformacin sobre esta y
la devuelve como output a otro Pipe.
4. Data Sink: consume la data de salida que viene del ultimo Filter a traves de un Pipe.
Estrategias posibles:
PUSH de data de salida bajo request (pasivo)


PULL de data de entrada bajo request (pasivo)






15



PUSH & PULL de data al completar el proceso (activo)


Un caso mas complejo:

Hay 2 filtros activos. El buffering pipe hace de Data Sink del primero y Data Source del segundo.

16



Pasos para IMPLEMENTAR:
Dividir las tareas del sistema en una secuencia de pasos de procesamiento
Definir el formato de la data a ser transmitida: uniforme o representaciones diferentes?
Decidir cmo implementar cada conexin de pipe: los filtros son pasivos o activos? La invocacin es directa? De
que tamao ser el buffer?
Disear e implementar los filtros: comportamiento ser reutilizable?
Disear el manejo de excepciones: ignorar entradas errneas?Por donde salen los errores, mismo canal o canal
aparte?Como se reinicia el pipeline?Como se resincroniza?
Implementar
VENTAJAS DESVENTAJAS
a. Mejoras futuras por intercambio o combinacin de
pasos (flexibilidad)
b. Reutilizacin de pasos de proceso
c. Pasos no adyacentes no comparten informacin
d. Diferentes fuentes de datos de entrada
e. Presentacin o almacenamiento de resultados finales
de maneras diferentes
f. Almacenamiento explcito de resultados intermedios
para procesos ulteriores
g. Alto rendimiento: Baja latencia, dado que se procesan
los filtros de forma incremental + Paralelistmo
a.Compartir informacin de estado puede ser inflexible
o costoso
b. Overhead por transformacin de data y cambios de
contexto y uso de threads.
c. Dificil de usar en aplicaciones interactivas
d. Manejo de errores





17

BLACKBOARD
La idea de la arquitectura Blackboard es una coleccin de programas independientes que trabajan conjuntamente en
una estructura de datos comn SIN LLAMARSE UNO A OTRO NI CON UNA SECUENCIA PREDETERMINADA PARA SU
ACTIVACION. Cada programa est especializado en la solucin de una parte especfica de la tarea global, y todos los
programas trabajan juntos en la solucin. Existe un componente central de control que evalua el estado actual del
proceso y coordina con los programasespecializados.
Es un modelo de resolucin de problemas incremental y oportunista.
Modelo de Resolucin de Problemas: Esquema para organizar los pasos de razonamiento y el conocimiento del
dominio para construir una solucin al problema (provee una estructura conceptual para organizar el conocimiento y
unas estrategias para aplicar ese conocimiento).
Resolucin de Problemas Incremental: Las soluciones completas son construidas "pieza" a "pieza" a partir de una
solucin (parcial) basada en datos incompletos.
Oportunismo: Aplicacin de la estrategia de razonamiento ms apropiada en cada momento.
El blackboard es una estructura global de datos compuesta por un conjunto de fuentes de conocimiento (KS :
Knowledge sources). Cada KS es un modulo computacionalmente independiente que contiene conocimiento til en
el contexto de la aplicacin del sistema.
Cundo se utiliza:
Problemas no susceptibles de tratarse analticamente
Reconocimiento de patrones, aprendizaje de mquina, data mining
Firmas, huellas digitales, reconocimiento de iris, rostro, etc.
EJ: Procesamiento de seales, Reconocimiento de habla, Redes neuronales, algoritmos genticos, Agentes
autnomos (dbilmente acoplados)
Dos formas:
Repositorio
Pizarra pura o tablero de control
SE OBTIENEN POSIBLES SOLUCIONES PARCIALES O UNA SOLUCION TOTAL APROXIMADA

18


Composicin de una KS:
Precondicin: Determina si se activa la KS.
Problema: Reevaluacin.
Informacin adicional: valor indicando la importancia de la KS, estimacin de la duracin de la
ejecucin del cuerpo (til para el Mdulo de Control).
Cuerpo: Acciones a realizar por la KS cuando se ejecuta.
No existe un estndar para la codificacin: procedural, conjuntos de reglas.
No suelen mantener un estado interno entre distintas ejecuciones (se suele almacenar en el
Blackboard).
Ejemplo: Un grupo de personas intentando resolver un rompecabezas en una habitacin con una pizarra. Cada
persona cuenta con una cantidad X de piezas.
1. Inicio: unos voluntarios ponen sus piezas ms "prometedoras" en la pizarra.
2. Cada persona mira sus piezas y ve si alguna de ellas encaja en las piezas que ya hay en la pizarra.
3. Aquellos con las piezas apropiadas se acercan a la pizarra y actualizan la solucin.
4. Esto causa que otras piezas encuentren su lugar. (vuelve al paso 2)
No importa si una persona tiene ms piezas que otra.
El rompecabezas completo puede ser resuelto en absoluto silencio.
Cada persona "se activa" a s misma, conociendo cuando sus piezas contribuirn a la solucin.
Existe un orden no establecido a priori sobre las personas para acercarse a la pizarra.
El comportamiento cooperativo aparente es proporcionado por el estado de la solucin en la pizarra.
Solucin construida incrementalmente (una pieza cada vez) y de forma oportunista (conforme se da una
oportunidad para aadir una pieza).
Lo opuesto a comenzar sistemticamente desde una esquina e intentar cada pieza.

SUPONGAMOS AHORA que la habitacin tiene un pasillo central que lleva a la pizarra por donde puede pasar solo
una persona.

Se necesita luego un monitor, alguien que vea al grupo y elija el orden en el cual las personas se acercan a la pizarra.
19

1. El monitor pide a todas las personas con piezas para aadir que levanten sus manos.
2. El monitor elige una persona de entre las que tienen sus manos levantadas segn algn criterio, como por
ejemplo, la persona que levanta primero la mano, la que tiene una pieza que sirve de puente entre dos islas
de solucin (es decir, dos grupos de piezas completadas)
El monitor, o mdulo de control, puede elegir una estrategia al comienzo de la resolucin, o desarrollar diferentes
estrategias a medida que la solucin comienza a revelarse.




Estrategias de control:
Foco de Atencin: Seleccionar una zona del BB. y el/los KS/s ms apropiado/s para esa zona (contexto)esto es una
estrategia de Activacin.
Ciclo de Control de Periodo Acotado: Seleccionar las KSs en base al tiempo de ejecucin estimado de las mismas, y
al tiempo que tiene para su ejecucin el mdulo de Controlesto es una aplicacin a sistemas de tiempo real.
Terminacin: Si el sistema debe finalizar su ejecucin, se puede utilizar una KS especial cuyas precondiciones
evalan la validez de la solucin.
Codificacin de la Estrategia de Control: Almacenar la estrategia de control en el BB. y construir KSs que la puedan
modificaresto es un sistema adaptativo.




REPOSITORY
Los componentes del sistema deben compartir informacin para trabajar efectivamente: Toda la informacin est
contenida en una base de datos central, el repositorio. En general los sistemas que manejan grandes cantidades de
informacin se estructuran con un Repositorio central:
-Sistemas de informacin,
20

-Sistemas de comando y control
-Sistemas CAD.

Contexto: Existe una gran cantidad de informacin que varios componentes deben poder acceder.
Problema: Componentes diversos acceden informacin compartida en forma asincrnica.
Solucin: Existe un repositorio de datos donde se almacena el conocimiento compartido por todos los componentes.









21

VENTAJAS DESVENTAJAS
-Forma eficiente de compartir gran cantidad de
informacin.
-No hay necesidad de transmitir informacin entre los
distintos componentes del sistema.
-Distintos componentes no necesitan saber qu datos
producen o consumen otros componentes.
-Las actividades de respaldo, seguridad, control de
acceso y recuperacin de errores estn centralizadas.
-El formato de los datos es visible, de modo que es
posible desarrollar nuevos componentes con ese
formato.
-Todos los componentes deben acordar un formato para
los datos del repositorio.
-Este formato deber ser una decisin de compromiso
entre las necesidades de los distintos componentes.
-El rendimiento del sistema es probablemente
bajo.
-Nuevos componentes con distinta representacin
de datos son difcilmente integrados al sistema.
-Modificar el formato de los datos del repositorio implica
cambios en todos los componentes.
-Distintos componentes pueden tener distintas
necesidades de servicios de apoyo.
-Es difcil distribuir el repositorio sobre una serie de
mquinas.

BLACKBOARD VS REPOSITORY
En el modelo de repositorio los datos compartidos son pasivos, y el control lo manejan los componentes que lo
acceden.
En el blackboard, los datos compartidos toman un rol ms activo: Las bases de conocimiento actan sobre los
datos.
El blackboard detecta ciertas condiciones e invoca otras bases de conocimiento
RULES BASED SYSTEMS
Muchas veces el conocimiento experto que ciertas personas utilizan para realizar una tarea experta puede ser
representado como reglas. Una regla se entiende como una estructura con un componente IF y un componente
THEN.
La sentencia (una o varias) luego del IF representa un patrn que queremos observar. La sentencia (una o varias)
luego del THEN representa las conclusiones que queremos sacar o las acciones que queremos tomar.
Un sistema basado en reglas entonces:
Identifica un patrn y saca conclusiones de lo que significa
O identifica un patrn y recomienda qu se debe hacer al respecto
O identifica un patrn y toma directamente una accin apropiada
La idea de un sistema de razonamiento basado en reglas es que ejecuta una serie de ciclos. En cada ciclo, trata de
seleccionar una regla apropiada de su coleccin de reglas (segn las circunstancias en ese momento) y ejecutarla.
Dado que al ejecutar una regla se pueden modificar los datos, puede ser que se disparen otras y se contine el
razonamiento. Parecido a una persona hilando ideas para llegar a una conclusin.
Una regla escrita de la manera explicada se conoce como una production rule. Un conjunto de reglas de
produccin, ms un soft que pueda razonar con estas, se conoce como un production system.
22


Hay una diferencia radical entre un sistema de reglas y cdigo clsico de un programa: En un programa, el if..then..
son parte integral del cdigo y representa un punto donde la ejecucin debe derivarse en una o ms direcciones. En
un sistema basado en reglas el if...then se encuentran en una base de reglas, el que tiene la responsabilidad de
control en el sistema elige una regla de la base de conocimiento que es apropiada para la circunstancia actual, luego
la utiliza.

SISTEMAS EXPERTOS

La coleccin de principios (reglas) que pueden tratar diferentes problemas se conoce como knowledge base. La
coleccin de detalles especficos que aplican al problema actual (variables, datos y el estado actual de resolucin) se
mantienen en la working memory. Ambos repositorios de informacin son trabajados por el inference engine.
Cualquier sistema experto prctico necesita un centro explicativo. Es esencial que un sistema experto sea capaz de
explicar su razonamiento. Esto da al usuario la confianza en el sistema y hace ms fcil "debuguear" el sistema.
23

Es normal incluir una interfaz de experto y un editor de base de conocimientos, ya que cualquier KBS va a necesitar
un mecanismo para crear y modificar de manera eficiente la base de conocimientos.
Como razona el sistema:
Tiene una Working Memory: Contiene elementos de datos. Su presencia o ausencia, hace que el motor de
inferencia active ciertas reglas. El sistema decide: Machea con las reglas de la base de reglas? Si es as, seleccione
la regla.
Tiene un Inference Engine: El sistema se inicia poniendo un dato adecuado en la working memory.
Reconocer-actuar ciclo: cuando los datos de la working memory coinciden con los requisitos de alguna de las reglas
del sistema, la accin de la regla es ejecutada.

Es una manera totalmente declarativa de representar conocimiento. Se identifica y expresa el conocimiento de un
tema en particular directamente en la rulebase. Uno no se preocupa cundo, cmo o en qu secuencia se usa la
regla. Cuando se quiere expandir el conocimiento, se agregan ms reglas a la rulebase.
Las reglas en s son muy fciles de entender y para alguien experto (en el tema que el sistema est operando) para
criticar y mejorar.
RULE & EVENT BASED
Un Evento es un cambio significativo de estado en un momento particular del tiempo.
Ej.: una entrada de una llamada, un logina una PC, una compra de acciones, un mensaje en Twitter
Evento Complejo (Complex Event) es una abstraccin de otros eventos llamados sus miembros. Ej.:
-La cada de la bolsa de 2008: es una abstraccin de muchos miles de eventos particulares, incluyendo cada compra
individual de acciones
-Una compra exitosa en Amazon: es una abstraccin de diferentes eventos sobre el carro de compra en el mismo
sitio
Complex Event Processing/CEP, es un concepto de procesamiento de eventos que intenta procesar mltiples
eventos con el objetivo de identificar los eventos interesantes dentro del conjunto total (event cloud)
CEP utiliza tcnicas como deteccin de patrones complejos de muchos eventos, correlacin y abstraccin de
eventos, jerarquas de eventos y las relaciones entre estos.
Ejemplo de uso: sistema de emergencia (911), deteccin de fraude en tarjetas, soluciones de logstica en tiempo real
(trafico areo+terrestre+estado del clima).


24

Cuando se utiliza:
Gran volumen de eventos, pero slo algunos de inters real
Generalmente los eventos son inmutables (ya pasaron, no se pueden cambiar)
Generalmente las reglas reaccionan a los eventos que pasaron
Fuerte relacionamiento temporal entre los eventos
Eventos individuales no son importantes
La composicin y agregacin de eventos si es importante
Se pueden definir ventanas movibles de inters en las cuales el CEP procesa los datos, basadas en tiempo o
cantidad de eventos.
Acumular consumos de tarjetas en una semana, para detectar posibles fraudes, detectando comportamientos de
consumo
Acumular ventas de una lnea de cajas de un supermercado en una hora para aplicar promociones o elevar stock
Acumular compras de una accin en la bolsa en una hora para tomar decisiones de compra o venta de portafolio
Acumular operaciones bancarias en diferentes canales por 4 horas para detectar posible comportamiento
fraudulento
METODOS DE PERSISTENCIA
Archivos: XML, ancho fijo, CSV, .ini, indexados, etc.
Prevalencia: los datos se mantienen en RAM. No hay tranformacion, alto grado de transparencia, alta
performancepero la aplicacin entera tiene que poder ser contenida en memoria, no hay un buen sistema
hibrido.
Bases de datos: extraen la lgica de persistencia fuera de la aplicacin. Tienen mtodos de bsqueda,
recuperacin de fallas, controles de integridad, son escalables, buena performance, controles de auditoria.
Tipos posibles
o Grafos
o Jerarquicas
o Relacionales
o Objetos: no hay transformaciones, los objetos se guardan tal como son en el modelo. Compleja para
consultas transversales, resistencia al uso (problemas de interoperabilidad y para cocinar datos).
o Asociativas
o Multidimensionales
o NO-SQL: distribuidas por naturaleza, apuntan a escalabilidad extrema. Muy pocas aseguran ACID
(atomicidad, consitencia, aislamiento, durabilidad).
ESB (Enterprise Services Bus)
Es un patrn de arquitectura para integrar componentes que utiliza un componente de arquitectura empresarial que
integra aplicaciones. Basicamente: UN PRODUCTO QUE IMPLEMENTA UNA ARQUITECTURA.




25

1ra solucin propuesta






El problema es que el EIA tiene que hablar el mismo idioma que todos los sistemas para poder comunicarlos, y si se
agrega un nuevo sistema hay que modificar el EIA para que pueda acoplarlo.
2da solucin:







El Broker es un producto cerrado que solo maneja un tipo dem ensjae. Los conectores que se incorporan sirven para
traducir los mensajes de los diferentes sistemas a un solo idiomael propio del brker, y lo mismo para el otro
lado.
3ra solucin: ESB






A nivel patrn es una evolucin del brker, ya que cada sistema necesita un traductor para hablar conel ESB.
Incorpora una serie de modulos que ofrecen facilidades:
ADAPTERS: traduccin de protocolos para que un sistema pueda comunicarse con el ESB
TRANSFORMERS: modificacin de mensajes dentro del ESB para agregar o expandir la info
Sist 2
Sist. 3
Sist. 1
EIA
Sist 2
Sist. 3
Sist. 1
broker
ESB
Sist. 1 Sist. 2 Sist. 3
26

ROUTING: derivacin de mensajes para que estos vayan de un sistema a otro (se pueden especificar varios
destinos, como tambin reglas de balanceo de carga).
WORLFLOWS: validacin, completitud de datos, transformaciones, etc. Manejo de colas (almacenamiento de
los datos hasta que se puedan enviar de forma asincrnica)








DEBUGING: inyeccin de mensajes, ver el estado de las variables en el workflow
Modulos de administracin (propios del ESB):
SEGURIDAD
MONITOREO: estado general (carga de equipos o servicios, alertas, etc.) y manejo de SLA
EVENTOS: notificaciones programadas cuando ocurre un evento o llega un mensaje (desde mensaje de
alertas a envios de mails)
REPOSITORIO DE SERVICIOS: agrupa los servicios existentes para exponerlos cmodamente, para que quien
se coencte al ESB sepa que hay disponible.
Tecnologias de transporte: permite multiples tecnologa para comunicar a los sistemas:
Archivos: FileSystem, FTP, SFTP
HTTP: Web Services SOAP, REST, XML,
URLEncoded
Colas: MQ, JMS
SMTP
Socket: TCP, UDP
Java: RMI, POJO
Adapters Legacy: DB, SAP, JD Edwards, CORBA,COBOL,
VENTAJAS DESVENTAJAS
Centrada en estndares abiertos
Fcil de modificar. Brinda flexibilidad a la
organizacin
Escala desde una solucin particular a una
empresarial sin muchos inconvenientes
Soporta comunicacin sincrnica y asincrnica
Ms configuracin, menos cdigo. Basado en
componentes reutilizables
Se puede modificar "en caliente"
Agrega overhead a la comunicacin
Reduce la velocidad de comunicacin
No es apropiado para grandes mensajes. No
reemplaza a un ETL


Sist 1
Transformer 1-2
XML 1
XML 2
Adapter 1
Adapter 2 Sist. 2