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).