ESTILOS ARQUITECTNICOS

Un estilo de arquitectura es una clasificacin de los sistemas software en

grandes familias cuyos integrantes comparten un patrn estructural comn.
Este estilo captura paradigmas de computacin y comunicacin utilizados
para tratar con los problemas de programacin de una clase en particular.
En otras palabras, indican los tipos de componentes y conectores
involucrados en una arquitectura. Los diferentes estilos de las arquitecturas
tiene sus fortalezas y debilidades y, ciertos estilos hacen que sea ms fcil o
ms difcil trabajar con diferentes obstculos. Las propiedades que
caracterizan cada estilo es lo que determina la eleccin de uno u otro

PRINCIPALES ESTILOS ARQUITECTNICOS
ESTILOS DE FLUJO DE DATOS
ESTILOS CENTRADOS EN DATOS
ESTILOS DE LLAMADA Y RETORNO
ESTILOS DERIVADOS ESTILOS DE CDIGO MVIL
ESTILOS HETEREOGNEOS
ESTILOS PER TO PER

Cualidades del Software
Correcto
Confiable
Robusto
Eficiente
Amigable
Verificable
Reusable
Portable
Interoperable
Productivo
A Tiempo
Visible
Coheso
Desacoplado
Comprensible
Mantenible

Correcto
La definicin supone:
La existencia de una especificacin de requisitos
La posibilidad de determinar sin ambigedad la correspondencia
entre la especificacin y el diseo.
La correctitud del software puede comprobarse probndolo o
mediante anlisis.
Confiable
A diferencia de la correccin, la confiabilidad es algo relativo.
El mercado puede admitir algunos errores en el software siempre que en
general se comporte en forma esperable.
No solo no damos garantas de correccin del software, sino que varios
productos incluyen un disclaimer .
Robusto
Datos de entrada incorrectos o fallas de hardware son las situaciones ms
frecuentes.
La cantidad de cdigo que se dedica a hacer el software robusto depende de
la experiencia de los usuarios o lo crtico de su misin.
Si algo se especifica como requisito, cumplirlo es cuestin de correccin; si
no est en los requisitos es cuestin de robustez.
Eficiencia
Muy lento baja la productividad de los usuarios.
Usa mucho disco puede ser muy caro ejecutarlo.
Usa mucha memoria puede afectar la performance de otros sistemas.
Amigable
La interfaz con el usuario es parte esencial del ser amigable.
Depende de los usuarios:
Novicios: mejor largos mensajes explicativos.
Expertos: aprecian los atajos.
Los sistemas insertos son amigables si son fciles de configurar.
La consistencia de las interfaces es un factor determinante.
Tambin la performance y la confiabilidad.

Verificable
La correccin y la performance pueden verificarse fcilmente.
La verificacin puede hacerse mediante anlisis o tesiting.

Reusable
La reutilizacin es ms apropiada para componentes que para sistemas
completos.
Las bibliotecas (libreras?) cientficas FORTRAN son los ejemplos ms
antiguos. Java APIs son ejemplos ms nuevos.
El reuso es una cualidad difcil (imposible?) de conseguir a posteriori.
La orientacin a objetos tiene el potencial para mejorar la reutilizacin y la
evolucin.
Tambin los patrones de arquitectura y el desarrollo de familias de
productos.
Portable
Una forma de lograr portabilidad es suponer la mnima configuracin.
Esto penaliza los sistemas que podran ejecutar mejor haciendo uso del
ambiente disponible.
Otra opcin es determinar sobre la marcha las disponibilidades del
ambiente.

Interoperable
Las componentes reutilizables son (deben ser) inherentemente
interoperables.
La estandarizacin de las interfaces promueve la interoperabilidad.
Los sistemas abiertos son casos tpicos de sistemas interoperables.
Productivo
La productividad de un equipo de desarrollo es generalmente menor que la
suma de las productividades individuales.
Existen mtricas para medir la productividad (LOC, puntos de funcin,
etc.).
La automatizacin y el soporte de software de desarrollo aumentan la
productividad.

A Tiempo
Tener el producto a tiempo da, en general, una mejor oportunidad
comercial, y a veces hace que el producto sea til o intil.
Tener un producto a tiempo sin confiabilidad o eficiencia tampoco es til.
Requiere:
Planificacin
Estimacin del trabajo
Hitos verificables
Visible
Diseo, testing, codificacin e integracin pueden suceder
simultneamente, pero deben coordinarse.
La visibilidad ayuda a evaluar el impacto de las decisiones.
Tambin es esencial cuando existe rotacin en el personal.
Cohesin
Coincidental:
No relacionados.
Lgica:
Funciones similar.
Temporal:
Ejecucin simultnea.
Procedural:
Secuencia de control.
Comunicacional:
Comparten el input.
Secuencial:
Output de uno es input del otro.
Funcional:
Todas las partes son necesarias para la funcin.
Objeto:
Todas las acciones actan sobre los mismos datos del objeto.

Acoplamiento
Sistemas muy acoplados
Comparten variables o informacin de control.
Sistemas desacoplados
Interfaces definidas con listas de parmetros.
Comprensible
Caractersticas que afectan la comprensibilidad del sistema:
Cohesin y acoplamiento
Nombres
Documentacin
Complejidad
Si un sistema es comprensible, es tambin ms mantenible y verificable.
Desde el punto de vista del usuario, ser comprensible es ser amigable y
robusto.

Mantenible
Tipos de mantenimiento:
correctivo (aprox. 20%)
adaptativo (aprox. 20%)
perfectivo (ms de 50%)
Software Mantenible:
reparable: que permite corregir defectos,
evolucionable: facilita la introduccin de nuevas funcionalidades.

Condiciones:
nmero de componentes,
acoplamiento,
documentacin
completa,
comprensible,
al da,
uso de componentes estndar.
La evolucionabilidad decrece con cada versin del software.


Especificacin de
Requisitos
Software
Un software es correcto si se comporta de acuerdo con su especificacin.

El software se comporta de acuerdo con lo esperado por el usuario.
Correcto
Confiable
Esta es una seal de la inmadurez del rea.

Un software es robusto si se comporta en forma razonable an en
situaciones no anticipadas.

Un sistema de software es eficiente si usa sus recursos en forma econmica.

Un software es amigable si sus usuarios lo encuentran fcil de utilizar.

El software es verificable si sus propiedades pueden ser comprobadas.

Software ya construido se usa con pocos o ningn cambio.

Un software es portable si puede ejecutarse en
distintos ambientes (hardware, sistemas operativos, etc.).

Un sistema es interoperable si puede coexistir y cooperar con otros
sistemas.


La productividad es la eficiencia del proceso de desarrollo del software.

El proceso de desarrollo debe obtener su producto en el tiempo planeado.

Un proceso de desarrollo de software es visible si todos sus pasos estn
claramente documentados, y se puede saber su estado de avance en cada
momento.


Medida de la relacin entre las partes de una componente.

Mdulo A
Mdulo B
Mdulo C
Mdulo D
rea de datos
Compartidos
Mdulo A
Datos de A
Mdulo B
Datos de B
Mdulo C
Datos de C
Mdulo D
Datos de D

Un sistema es comprensible si es fcil comprender cmo funciona.

Un sistema es mantenible si es fcil modificarlo.



ESTILOS ARQUITECTNICOS PIPES and FILTERS (Tuberas y
filtros)Cada componente tiene un conjunto de entradas y un conjuntode
salidas. Filters (Filtros) Pipes (Tuberas) Un componente lee la rfaga
(stream) de datos en sus entradas y produce una rfaga de datos en sus
salidas. Los componentes se conocen como filtros y son
independientes. Los conectores se comportan como conductores de las
rfagas, transmitiendo salidas de un componente hacia entradas de otro. El
mejor ejemplo de este estilo son los programas escritos en el Shell de Unix
(Bach, 1986). Otros ejemplos se observan en el rea de procesamiento de
seales, programacin paralela y sistemas distribuidos.
17. ESTILOS ARQUITECTNICOS ORGANIZACIONES POR TIPOS
DE DATOS ABSTRACTOS Y O-OLa representacin de los datos y sus
operaciones primitivas seencapsulan en Tipos de Datos Abstractos (TDA) u
objetos. Manejador obj op op (TDA) op obj op op obj op obj op op
Llamada de Nota: obj es un manejador op obj op es una invocacin un
proceso op Los componentes son objetos (o instancias de tipos de datos
abstractos). Los objetos son ejemplos de un tipo de componente llamado
manejador porque es el responsable de preservar la integridad de un
recurso Los objetos interactan a travs de invocaciones a funciones y
procedimientos. La implementacin de las funciones y procedimientos
est oculta para el objeto cliente, lo cual permite hacer las modificaciones
fcilmente. Para hacer uso de un servicio se hace necesario conocer la
identidad del objeto; al hacer un cambio en un objeto es necesario
modificar todos los objetos que lo invocan.
18. ESTILOS ARQUITECTNICOS BASADOS EN EVENTOS,
INVOCACIN IMPLCITAEn el estilo anterior, la interfaz de los
componentes (objetos)cuentan con una coleccin de procedimientos y
funciones, y laintegracin entre ellos se logra a travs de la invocacin
explcitade stos. En este estilo, se considera una tcnica de
integracinconocida como invocacin implcita. Los componentes son
mdulos cuyas interfaces proveen una coleccin de procedimientos y un
conjunto de eventos. Los procedimientos se llaman de la manera usual pero
el componente tambin puede activar algunos de sus procedimientos con
los eventos del sistema. Esto har que estos procedimientos sean invocados
cuando los eventos ocurren en tiempo de ejecucin. Los generadores de
eventos no saben cuales componentes se afectarn por el evento. Ejemplos
de este estilo son los sistemas de gestin de bases de datos cuando aseguran
la consistencia de los datos, las aplicaciones con interfaces de usuarios al
separar la representacin de los datos de las aplicaciones que las gerencian.
19. ESTILOS ARQUITECTNICOS SISTEMAS EN CAPASEstn
organizados jerrquicamente; cada capa le presta serviciosa la capa superior
y es cliente de la capa inferior. Sistemas tiles Llamadas usuales de
procedimientos Servicio base Nivel central Composicin de varios
elementos Usuarios Los componentes implementan un mquina virtual en
alguna capa de la jerarqua. Los conectores estn definidos en los
protocolos que determinan cmo las capas interactan. Los ejemplos ms
conocidos de este estilo arquitectural son los protocolos de comunicacin.
20. ESTILOS ARQUITECTNICOS REPOSITORIOSConsta de dos (2)
tipos de componentes: una estructura central de datosque refleja el estado
actual y una coleccin independiente de compo-nentes que operan sobre el
almacn central. Computacin fc1 fc2 fc8 fc3 Blackboard Acceso (datos
directo Memoria fc7 compartidos) fc4 Nota: fc es una fuente de
conocimiento fc6 fc5 Las interacciones entre los componentes pueden
variar significativamente. El tipo de control seleccionado puede llevar a dos
categoras: Si el tipo de transaccin es una entrada que dispara la
seleccin del proceso a ejecutarse, se est hablando de las tradicionales
bases de datos. Si el estado actual de la estructura central de datos es el
principal activador de los procesos a ejecutarse, se habla de un estilo de
repositorio tipo pizarrn (blackboard). Son muy utilizados para aplicaciones
que requieren interpretaciones complejas de procesamiento de seales, tales
como reconocimiento del habla y de patrones.
21. ESTILOS ARQUITECTNICOS INTRPRETESEn una organizacin
intrprete,una maquina virtual es produci-da en software. Un intrprete
incluye el pseudoprograma inter-pretado y la mquina de interpretacin
misma. Memoria Programa a ser Entradas Datos interpretado (programa)
Computacin (mquina) Motor de Estado Salidas Instruccin seleccionada
interpretacin interno del Datos seleccionados simulado interpretador
Acceso a datos (bsqueda/almacenamiento) Los intrpretes son a menudo
usados para construir maquinas virtuales que enlazan la mquina de
computacin esperada por la semntica y la mquina de computacin
disponible en el hardware.


Criterios para la seleccin de una arquitectura (o
estilo arquitectnico)
Para un proyecto software dado puede haber varias a
rquitecturas apropiadas.
Se elige una teniendo en cuenta los
objetivos
, que deben estar priorizados, ya que unas
arquitecturas satisfacen mejor unos objetivos que o
tros.
Criterios clsicos:
o
Extensibilidad
: facilitar la adicin de nuevas caractersiticas (
features
).
Hace ms complejo el diseo.
Aporta mayor grado de abstraccin.

Ejemplo
: arquitectura que soporte no este juego de tablero
particular, sino
cualquier tipo de juego de tablero.
Generalizar requiere invertir tiempo en el diseo:
decidir qu tipo de extensiones
pueden surgir, etc.
La distincin de requisitos opcionales/deseables es
til aqu, ya que seala hacia
dnde apunta el desarrollo del sistema.
o
Modificabilidad
: facilitar el cambio de requisitos.
Es distinto del anterior, aunque requiera tcnicas
similares.

Ejemplo
: posibilidad de cambiar las reglas del juego.
o
Simplicidad
: hacer fcil de entender, hacer fcil de implement
ar.
Difcil de coordinar con los dos anteriores.
o
Eficiencia
: lograr alta velocidad o pequeo tamao.
Otros criterios: reuso, escalabilidad, coste, requi
sitos no funcionales...
Los
requisitos no funcionales
guan la seleccin de la arquitectura ms convenie
nte. Ej:
o
Rendimiento
Componentes de grano grueso (reducen comunicacione
s).
o
Mantenibilidad
Componentes de grano fino (simplifican modificacio
nes).
o
Disponibilidad
Componentes redundantes (si uno falla, otro sigue
funcionando).