Arquitectura de Software

Introduccin
No hay una metodologia de Arquitectura Arquitectura es un Diagrama (Es el diseo) No se puede medir ni evaluar El diseador mas antiguo es el Arquitecto Es la Infraestructura Yo estudie en un libro Es la tecnologia de moda

Contenido
Que es Arquitectura de Software?
Proceso de la Arquitectura Rol y Responsabilidades del Arquitecto Arquitectura Vs. Diseo

Arquitectura de Software
Que es una arquitectura?
Es el conjunto de decisiones significativas sobre la organizacin de un sistema de software que define los principios que guan el desarrollo, los componentes, principales del sistema, sus responsabilidades y la forma en que se interrelacionan.

Discusin
+ Definir la arquitectura en los proyectos actuales es

crtico...

Evolucin de Arquitecturas
Dos factores primarios en la ingeniera de software que han incrementado la importancia de la arquitectura:

Evolucin de Arquitecturas
Aplicaciones Monolticas
Interfaces grficas de usuario (GUI). Servicios de presentacin, negocios y persistencia en la misma mquina. No hay concurrencia de usuarios. Alto acoplamiento entre tiers.

Arquitectura Cliente-Servidor
+ Clientes pesados, no estndar + Conexiones dedicadas a BD + Protocolos pesados + Ejecucin remota de SQLs + Alta administracin + Bajo rendimiento + Alto trfico de red + Baja accesibilidad

Evolucin de Arquitecturas
Arquitectura Cliente-Servidor Mejorada Lgica de negocios en BD Clientes pesados, no estndar. Conexiones dedicadas a la BD. Mejora en rendimiento Alta administracin Baja escalabilidad Baja flexibilidad Baja portabilidad Arquitectura de 3 niveles
+ Reutilizacin de lgica de negocio para

diferentes clientes o sistemas. + Mejora la escalabilidad. + Mejora la flexibilidad. + Independencia de la base de datos.

Evolucin de Arquitecturas
Arquitectura de N-niveles

+ Bajo costo de administracin de clientes. + Alta accesibilidad. + Alta flexibilidad. + Alta disponibilidad y tolerancia a fallos. + Alta escalabilidad. + Independencia de DB

Evolucin de Arquitecturas
Visin de Arquitectura Orientada a Servicios (SOA)

+ Requerimientos

Arquitectnicos
+ Heterogeneidad
+ Escalabilidad + Disponibilidad + Distribucin

+ Manejabilidad de Procesos
+ Administracin y monitoreo de procesos,

servicios e infraestructura

Que es un Arquitecto de Software?

Arquitecto es un rol en un proyecto de desarrollo de software el cual es responsable de: Liderar el proceso de arquitectura. Producir los artefactos necesarios: Documento de descripcin de arquitectura Modelos y prototipos de arquitectura. El arquitecto: Visualiza el comportamiento del sistema. Crea los planos del sistema. Define la forma en la cual los elementos del sistema trabajan en conjunto. Responsable de integrar los requerimientos no-funcionales (NRFs) en el sistema.

Discusin
+ Existe alguna diferencia entre arquitectura y diseo

de software?

Arquitectura Vs. Diseo

+ La arquitectura y el diseo difieren en tres reas:
Arquitectura Nivel de Abstraccin Entregables Alto nivel Planear subsistemas, interfaces con sistemas externos, servicios horizontales, frameworks, componentes reutilizables, prototipo arquitectnico Seleccin de tecnologas, Requerimientos no funcionales (QoS), Manejo de riesgos Diseo Bajo nivel. Enfoque especfico en detalles Diseo detallado componentes. Especificaciones de codificacin Requerimientos funcionales

reas de Enfoque

Arquitectura Vs. Diseo

La arquitectura envuelve un conjunto de decisiones estratgicas de diseo, lineamientos, reglas y patrones que restringen el diseo y la implementacin de un software. Las decisiones de arquitectura causan un alto impacto en los proyectos de IT

Cdigo Implementacin Diseo

Arquitectura

Beneficios
1. Proporciona comunicacin entre los participantes del proyecto. 2. Manifiesta las decisiones de diseo tempranamente. 3. Las arquitecturas son un modelo reusable y transferible.

Qu son los patrones?

Son una forma de comunicar diseos !!!

Para Qu Comunicar el Diseo?

No reinventar soluciones a problemas conocidos. Reusar el conocimiento experto relativo a un diseo. Beneficios:
inexpertos pueden disear como expertos, menos errores debido al uso de diseos ya probados, los diseos probados son ms fcilmente mantenibles, el software puede disearse para tener ciertas propiedades.

Investigacin en Patrones de Arquitectura

Es posible formalizar esta comunicacin para poder reusar el conocimiento experto? Premisas:
existen problemas recurrentes en el diseo de software, las soluciones a estos problemas tienen ciertas propiedades invariantes (solucin abstracta), pueden capturarse los problemas y las soluciones.

Patrones de Arquitectura de Software

Los patrones en general, y en particular los de arquitectura, son un intento de formalizar la comunicacin y el reuso de la experiencia de diseo, capturan la experiencia probada de diseo de software, describen problemas recurrentes que surgen en determinados contextos, describen esquemas de soluciones probados, Son una herramienta para los no expertos, Ofrecen un paso ms hacia la ingeniera de software:
permite que gente comn haga cosas que antes requeran virtuosismo.

Patrones: el Reuso de la Experiencia

Los diseadores expertos manejan patrones recurrentes de clases y colaboraciones tiles ante determinados problemas. Los patrones resuelven problemas concretos y crean diseos ms elegantes, flexibles y reutilizables.

Permiten la reutilizacin de la experiencia en Diseo

Qu es un Patrn?
Un patrn de arquitectura de software es un esquema genrico probado para solucionar un problema particular, el cual es recurrente dentro de un cierto contexto. Este esquema se especifica describiendo los componentes, con sus responsabilidades y relaciones.

Caractersticas de los Patrones

Atacan problemas recurrentes que ocurren en situaciones especficas y dan una solucin.
Variabilidad de las interfaces.

Documentan experiencias de diseo existentes y bien probadas.

Experiencia en el desarrollo de sistemas interactivos.

Identifican y especifican abstracciones de alto nivel. Proveen un vocabulario comn y comprensible.

Ms Caractersticas de los Patrones

Son una forma de documentar la arquitectura del software.

Facilitan la construccin de software con propiedades definidas (propiedades particulares).

Interfaces intercambiables y modelo reutilizable.

Ayudan a construir arquitecturas heterogneas y complejas.

Patrones en la Ingeniera de Software

Pueden verse como bloques de construccin mentales, para tratar con distintos aspectos del diseo de software.

Hay patrones de arquitectura, patrones de diseo, patrones de procesos, patrones de interfaces.

Categoras de Patrones Arquitectnicos

Patrones Simples

Capas, Tubos-y-Filtros, Pizarrn, Repositorio

Sistemas Distribuidos

Broker (Microkernel, Pipes-y-Filtros), CAGS, Cliente-Servidor

Sistemas Interactivos

Modelo-View-Controlador, Presentacin-Abstraccin-Control
Patrones Adaptables

MicroKernel, Reflexion

Patrones Arquitectnicos Simples

Patrones Simples
Capas: Ayuda a estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas con distintos niveles de abstraccin (granularidad). Tubos-y-Filtros: Provee una estructura para sistemas que procesan datos de entrada. El procesamiento puede estar encapsulado en uno o ms procesos (filtros). Pizarrn: til en problemas para los cuales no hay una solucin conocida. Generalmente provee aproximaciones a la solucin final. Repositorio: Ayuda a estructurar sistemas centrados en los datos, hacindolos ms flexibles y adaptables. .... Estos son modelos generales, que requieren instanciaciones especficas.

Capas
La arquitectura de layers o capas ayuda a estructurar aplicaciones que pueden descomponerse en grupos de subtareas con diferentes niveles de abstraccin.

Capas
Es una arquitectura cliente-servidor en el que el objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la capa de presentacin al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al nivel requerido sin tener que revisar entre cdigo mezclado.

Pipes y Filtros
El patrn de arquitectura de pipes y filtros provee una estructura para procesar flujos de datos. Cada paso de procesamiento se encapsula en un filtro. Los datos se pasan usando los pipes entre filtros adyacentes. Recombinando los filtros pueden construirse distintas familias de sistemas relacionados.

Pipes y Filtros
Consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe).

Pizarrn
El patrn de arquitectura de pizarrn es til para problemas en que no se conoce una estrategia determinstica para calcular la solucin. Varios subsistemas especializados reunen su conocimiento para construir una solucin parcial aproximada.

Variantes del Patrn: REPOSITORIO y CLIENTE-SERVIDOR

Pizarrn
Modelo arquitectnico de software habitualmente utilizado en sistemas expertos, sistemas multiagente y, en general, sistemas basados en el conocimiento Un dominio en el que no hay ningn enfoque cerrado (algortmico) conocido o viable para resolver un problema. Por ejemplo, sistemas de vigilancia, reconocimiento de voz y sistemas AI.

Patrones Arquitectnicos para Sistemas Interactivos

Patrones para Sistemas Interactivos

Modelo-View-Controlador: divide a una aplicacin interactiva en tres componentes: modelo, vistas y controladores. Presentacin-Abstraccin-Control: define al sistema como una jerarqua de agentes que coorperan entre s para implementar la funcionalidad de la aplicacin.

Modelo-View-Controlador
El patrn de arquitectura de modelo-view-controlador (MVC) divide una aplicacin interactiva en tres partes. El modelo contiene los datos y la funcionalidad esencial. Las views despliegan la informacin al usuario. Los controladores manejan el input. Las views y los controladores juntos componen la interfaz con el usuario. El mecanismo de cambio-propagacin asegura la consistencia de la interfaz con el modelo.

Modelo-Vista-Control (MVC)

Utilizado para construir interfaces de usuario en Smalltalk-80.
Basado en tres tipos de objetos:
Modelo: objeto aplicacin. Encapsula el ncleo funcional y los datos involucrados. Vistas: presentacin de informacin por pantalla (al usuario). Controlador: define la forma en la que debe reaccionar la interfaz del usuario, frente a la entrada de datos (del usuario).

Desacopla el modelo de las vistas.

Hace a los sistemas ms mantenibles, flexibles y adaptables.

Ejemplo: Sistema de Informacin

Sistema de elecciones
polticas. Negro: Rojo: Azul: Verde: Otro: 43% 39% 6% 10% 2%

Los usuarios votan a

travs de una interfaz grfica.
50 40 30 20 10 0 Negro Rojo Azul Verde Ot ro

La informacin se
muestra con distintos formatos.

Negro Rojo Azul Verde Otro

43 39 6 10 2

Los cambios por

votacin deben reflejarse en forma inmediata.

Debe poderse integrar otras formas de presentacin de los resultados tales como la distribucin de candidatos en el parlamento. Las presentaciones deben ser portables.

Modelo-Vista-Control (MVC)
Contexto: Aplicaciones interactivas con interfaces humanocomputador cambiantes y flexibles. 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
procesamiento, input y output.

Cada view tiene asociada un

controlador. El controlador recibe eventos como input (movimientos del mouse, activacin de botones) y los traduce a solicitudes de servicios del modelo o la view.

El modelo representa la
funcionalidad y los datos esenciales, y es independiente de la representacin en las interfaces.

La view obtiene datos del

modelo y los despliega para el usuario.

El usuario interacta con el

modelo solamente a travs de controladores.

Modelo-Vista-Control (MVC)
Estructura:
Modelo
encapsula la informacin esencial
y exporta procedimientos que realizan procesamiento especfico de la aplicacin;

View
despliega los datos para el
usuario;

tienen procedimientos de
actualizacin para recibir nuevos datos.

provee funciones para que las

views accedan a la informacin;

Controlador
existe un controlador para
cada view;

el mecanismo de cambiopropagacin mantiene informados a las views y a los controladores dependientes.

recibe los inputs de una

view como eventos y los interpreta.

MVC: Estructura del Ejemplo

Torta
El modelo guarda los votos
acumulados para cada partido poltico y permite que las views accedan a los nmeros de votos.
Controlador_Tr

Hay varias views: grfico de

barras, mapas o tablas.

Controlador_Ba

Base de votos

Barras

Controlador_Tb

Tabla

Presentacin-Abstraccin-Control (PAC)
El patrn de arquitectura PAC define una estructura jerrquica de agentes cooperativos. Cada agente es responsable de un aspecto especfico de la funcionalidad de la aplicacin y est compuesto por tres componentes: presentacin-abstraccincontrol.

Presentacin-Abstraccin-Control (PAC)
Ejemplo: Consideremos un Sist. de Informacin Electoral.
-

Ofrece una hoja de clculo para el ingreso de datos Ofrece varios tipos de tablas y de grficos para representar los distintos resmenes de la informacin almacenada. Los usuarios interactan con el software a travs de la interfaz grfica.
90 80 70 60 50 40 30 20 10 0

1tr. Este 20 Oeste 30 Norte 47

2tr. 3tr. 4tr. 25 90 20 38 32 32 47 45 45

Este Oeste Norte

1er trim.

2do trim.

3er trim.

4to trim.

2tr Usuario Hoja de Clculo

4tr

1tr

3tr

Presentacin-Abstraccin-Control (PAC)
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.

Presentacin-Abstraccin-Control
Solucin:

- Ejemplo: veamos un sistema de informacin electoral.

Repositorio

Acceso a Datos Controlador de Vistas

Hoja de Clculo

Grfico Torta

Grfico Lneas

Grfico Barras

Patrones para Sistemas Adaptables Investigar

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.