Introducción a la Introducción a la Arquitectura de SoftwareArquitectura de Software

Billy ReynosoBilly ReynosoUNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS AIRESBillyr@microsoft.com.arBillyr@microsoft.com.ar

ObjetivosObjetivosSuministrar una visión estructurada de la Suministrar una visión estructurada de la Arquitectura de Software contemporáneaArquitectura de Software contemporánea

No es pedagogía No es pedagogía Arquitectura 101Arquitectura 101, sino más , sino más bien un bien un surveysurvey de lo que significa AS, una de lo que significa AS, una evaluación de lo que ha llegado a ser y una evaluación de lo que ha llegado a ser y una puntualización sobre lo que no espuntualización sobre lo que no es

Despejar malos entendidos sobre Despejar malos entendidos sobre arquitectura como diseño de aplicacionesarquitectura como diseño de aplicacionesVincular perspectivas de la academia y la Vincular perspectivas de la academia y la industriaindustriaPrivilegiar elaboraciones de la corriente Privilegiar elaboraciones de la corriente teórica de CMU/SEIteórica de CMU/SEIDescribir desarrollos de estado de arte, Describir desarrollos de estado de arte, problemas pendientes y tendenciasproblemas pendientes y tendenciasProporcionar referencias a recursos, Proporcionar referencias a recursos, documentación y herramientasdocumentación y herramientas

http://www.microsoft.com/spanish/msdn/http://www.microsoft.com/spanish/msdn/arquitecturaarquitectura

TemarioTemarioObjetivosObjetivosContextoContextoErrores de concepto habitualesErrores de concepto habitualesAntecedentes históricosAntecedentes históricosDefinición – Repositorio de definicionesDefinición – Repositorio de definicionesCorrientes principalesCorrientes principalesConceptos fundamentales (CMU/SEI)Conceptos fundamentales (CMU/SEI)Estilos arquitectónicosEstilos arquitectónicosEstilos y patronesEstilos y patronesLenguajes de Descripción Arquitectónica Lenguajes de Descripción Arquitectónica (ADLs)(ADLs)Atributos de calidad, escenarios y tácticasAtributos de calidad, escenarios y tácticasMétodos basados en arquitecturaMétodos basados en arquitecturaSituación, conclusiones y referenciasSituación, conclusiones y referencias

Contexto – 1995-2005Contexto – 1995-2005Los 3 grandes temas de ingeniería de Los 3 grandes temas de ingeniería de softwaresoftware

Patrones Patrones Design patterns (GoF) - 1995Design patterns (GoF) - 1995

Erich Gamma, Richard Helm, Ralph Johnson y John Erich Gamma, Richard Helm, Ralph Johnson y John VlissidesVlissides

Architectural patterns (POSA) - 1996Architectural patterns (POSA) - 1996Frank Buschmann, Regine Meunier, Hans Rohnert, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael StalPeter Sommerlad y Michael Stal

Organizational patterns (Coplien)Organizational patterns (Coplien)

Métodos heterodoxos (eXtreme Programming, Métodos heterodoxos (eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal, LD, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…) ASD…) Arquitectura de SoftwareArquitectura de Software

Otros:Otros:Refactorización Refactorización AOP, SOA, Grid Computing, Semantic Web...AOP, SOA, Grid Computing, Semantic Web...

Conceptos cuestionables Conceptos cuestionables (1/2)(1/2)

Arquitectura como normativa maduraArquitectura como normativa maduraAbundancia de herramientas de diseño Abundancia de herramientas de diseño arquitectónicoarquitectónicoSemántica y lenguajes arquitectónicos iguales Semántica y lenguajes arquitectónicos iguales en la academia y la industriaen la academia y la industriaUML como lenguaje formal de modelado UML como lenguaje formal de modelado “arquitectónico”“arquitectónico”Posición de la AS bien definida en ingeniería & Posición de la AS bien definida en ingeniería & ciclo de vidaciclo de vida

Ocurre en algún punto entre la elicitación de Ocurre en algún punto entre la elicitación de requerimientos y la especificación de casos de uso, o requerimientos y la especificación de casos de uso, o entre éstos y el diseñoentre éstos y el diseño

Arquitectura vinculada a metodología y proceso Arquitectura vinculada a metodología y proceso RUPRUP

La AS está La AS está formalmenteformalmente desarrollada las disciplinas de desarrollada las disciplinas de RUP (cf. Kazman, Kruchten RUP (cf. Kazman, Kruchten et alet al 2004) 2004)

Conceptos cuestionables Conceptos cuestionables (2/2)(2/2)

La AS tiene que ver con modelado La AS tiene que ver con modelado OOOO

La AS no admite ni requiere otros La AS no admite ni requiere otros paradigmasparadigmasNo hay urgencia en considerar otros No hay urgencia en considerar otros paradigmas (Berners-Lee)paradigmas (Berners-Lee)

Las herramientas arquitectónicas Las herramientas arquitectónicas generan la estructura de la aplicación generan la estructura de la aplicación e incluso el código (analogía con e incluso el código (analogía con modelos CASE)modelos CASE)El dilema del El dilema del roundtrip engineeringroundtrip engineering está resueltoestá resuelto

Hay que considerar modelo de DSLHay que considerar modelo de DSL

Antecedentes históricos Antecedentes históricos (1/5)(1/5)

Edsger Dijkstra, 1968Edsger Dijkstra, 1968Ciencias de la computación como rama aplicada de Ciencias de la computación como rama aplicada de las matemáticaslas matemáticasNiveles de abstracciónNiveles de abstracción

Stacks, abrazos mortales, semáforos, algoritmo Stacks, abrazos mortales, semáforos, algoritmo de camino más cortode camino más corto

NATO, 1968NATO, 1968F. L. Bauer “Ingeniería de software”F. L. Bauer “Ingeniería de software”

NATO, 1969NATO, 1969P. I. Sharp, “Arquitectura de software”P. I. Sharp, “Arquitectura de software”

C.R. Spooner, 1971C.R. Spooner, 1971““Una arquitectura de software para los 70s”Una arquitectura de software para los 70s”Referencia accidentalReferencia accidental

Antecedentes históricos Antecedentes históricos (2/5)(2/5)

Niklaus Wirth, 1971Niklaus Wirth, 1971Niveles de abstracción Niveles de abstracción Stepwise refinementStepwise refinement

DeRemer & Kron, 1976DeRemer & Kron, 1976Programming in the largeProgramming in the large

Fred Brooks, 1975 – MMMFred Brooks, 1975 – MMMDiseñador del OS/360, Premio Turing 2000Diseñador del OS/360, Premio Turing 2000Arquitectura como interfaz usuarioArquitectura como interfaz usuarioEl arquitecto es un agente del usuario, igual que El arquitecto es un agente del usuario, igual que quien diseña su casaquien diseña su casaImportancia de las estructuras de alto nivel y de Importancia de las estructuras de alto nivel y de decisiones tomadas al principiodecisiones tomadas al principioArquitectura: qué hacer - Implementación: cómo Arquitectura: qué hacer - Implementación: cómo hacerlohacerlo

Antecedentes históricos Antecedentes históricos (3/5)(3/5)

David ParnasDavid Parnas1972: Módulos – Ocultamiento de información1972: Módulos – Ocultamiento de información1974: Estructuras de software1974: Estructuras de software1976: Familias de programas (Árbol de decisión) - 1976: Familias de programas (Árbol de decisión) - Descomposición - Alternativa a diagramas de flujo, Descomposición - Alternativa a diagramas de flujo, propensión estructural (propensión estructural (nono funcional) funcional)““Una familia de programas es un conjunto de programas (no Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o lo serán alguna vez) a todos los cuales han sido construidos o lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto los cuales es provechoso o útil considerar como grupo. Esto evita el uso de conceptos ambiguos tales como “similitud evita el uso de conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen dominios. funcional” que surgen a veces cuando se describen dominios. Por ejemplo, los ambientes de ingeniería de software y los Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se consideran usualmente en el mismo juegos de video no se consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma dominio, aunque podrían considerarse miembros de la misma familia de programas en una discusión sobre herramientas que familia de programas en una discusión sobre herramientas que ayuden a construir interfaces gráficas, que ambos ayuden a construir interfaces gráficas, que ambos casualmente utilizan”.casualmente utilizan”.

Antecedentes históricos Antecedentes históricos (4/5)(4/5)

Línea de Dijkstra-Parnas-HoareLínea de Dijkstra-Parnas-HoareFundamentación matemáticaFundamentación matemáticaMétodos formalesMétodos formalesPrograma fuertePrograma fuerte

Línea de BrooksLínea de BrooksAmbiente humanoAmbiente humanoVisión cualitativaVisión cualitativaPensamiento no linealPensamiento no linealPrograma crítico y heterodoxoPrograma crítico y heterodoxo

Antecedentes históricos Antecedentes históricos (4/5)(4/5)

Dewayne Perry, Alexander Wolf – 1992Dewayne Perry, Alexander Wolf – 1992““Foundations for the study of software Foundations for the study of software architecture”architecture”““La década de 1990, creemos, será la década de la La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término arquitectura de software. Usamos el término “arquitectura” en contraste con “diseño”, para evocar “arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de estándares, nociones de codificación, de abstracción, de estándares, de entrenamiento formal (de los arquitectos de de entrenamiento formal (de los arquitectos de software) y de estilo. software) y de estilo. Es tiempo de re-examinar el Es tiempo de re-examinar el papel de la arquitectura de software en el contexto más papel de la arquitectura de software en el contexto más amplio del proceso de software y de su administración, amplio del proceso de software y de su administración, así como señalar las nuevas técnicas que han sido así como señalar las nuevas técnicas que han sido adoptadas”.adoptadas”.

Escuela de Carnegie Mellon (CMU-SEI)Escuela de Carnegie Mellon (CMU-SEI)Sin conexión explícita con CMMI®Sin conexión explícita con CMMI®Mary Shaw, David Garlan, Paul Clements, Mary Shaw, David Garlan, Paul Clements, Robert Allen, Rick KazmanRobert Allen, Rick Kazman

DefiniciónDefinición

http://www.sei.cmu.edu/architecture/http://www.sei.cmu.edu/architecture/definitions.htmldefinitions.html

(1) Proceso dentro del ciclo de vida, (2) Topología, (3) (1) Proceso dentro del ciclo de vida, (2) Topología, (3) Disciplina.Disciplina.

Arquitectura - IEEE 1471-2000: Arquitectura - IEEE 1471-2000: La Arquitectura de Software es la organización La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.y los principios que orientan su diseño y evolución.

Adoptada por Microsoft en estrategia arquitectónica / MSF Adoptada por Microsoft en estrategia arquitectónica / MSF 3 & 43 & 4

Ingeniería - IEEE 610.12.1990: Ingeniería - IEEE 610.12.1990: [La Ingeniería de Software es] la aplicación de una [La Ingeniería de Software es] la aplicación de una estrategia sistemática, disciplinada y cuantificable al estrategia sistemática, disciplinada y cuantificable al desarrollo, aplicación y mantenimiento del software; desarrollo, aplicación y mantenimiento del software; esto es, la aplicación de la ingeniería al software.esto es, la aplicación de la ingeniería al software.

Otras definicionesOtras definiciones

Paul Clements, 1996: Paul Clements, 1996: ““La AS es, a grandes rasgos, una vista del La AS es, a grandes rasgos, una vista del sistema que incluye los componentes sistema que incluye los componentes principales del mismo, la conducta de esos principales del mismo, la conducta de esos componentes según se la percibe desde el componentes según se la percibe desde el resto del sistema y las formas en que los resto del sistema y las formas en que los componentes interactúan y se coordinan para componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle la supresión o diferimiento del detalle inherente a la mayor parte de las inherente a la mayor parte de las abstracciones”. abstracciones”. * Vista - * Componente* Vista - * Componente

Desarrollos paralelosDesarrollos paralelos

Década de 1990:Década de 1990:Metáfora de patrones de C. Alexander Metáfora de patrones de C. Alexander (1977)(1977)La Banda de los Cuatro (GoF), 1995La Banda de los Cuatro (GoF), 1995POSA, 1996POSA, 1996Desarrollo de UML / OODDesarrollo de UML / OOD

Corrientes teóricas en Corrientes teóricas en ASAS

Arquitectura como etapa de la Arquitectura como etapa de la ingeniería de software orientada a ingeniería de software orientada a objetosobjetos

James Rumbaugh, Grady Booch, Ivar James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3 amigos”), Craig Larman…Jacobson (“los 3 amigos”), Craig Larman…

Arquitectura estructural – SEIArquitectura estructural – SEICorriente principal: Garlan, Shaw, Corriente principal: Garlan, Shaw, ClementsClementsVariantes con modelos de datos Variantes con modelos de datos (Medvidovic)(Medvidovic)Variantes radicales, formales (Moriconi-Variantes radicales, formales (Moriconi-SRI)SRI)Arquitectura basada en patrones – SEIArquitectura basada en patrones – SEIArquitectura procesual (Kazman, Bass)Arquitectura procesual (Kazman, Bass)

VistasVistas

1977, análisis estructurado (Douglas Ross)1977, análisis estructurado (Douglas Ross)Separación de incumbenciasSeparación de incumbenciasHabitualmente 2 (funcional y de datos – ninguna Habitualmente 2 (funcional y de datos – ninguna aparece en AS)aparece en AS)

La AS clásica no habla de vistasLa AS clásica no habla de vistasSe basa en vista única e implícita, de carácter Se basa en vista única e implícita, de carácter estructuralestructuralMuchos arquitectos evitan hablar de vistasMuchos arquitectos evitan hablar de vistasCuando las vistas proliferan, se requieren lenguajes Cuando las vistas proliferan, se requieren lenguajes formales específicos para cada clase de vista formales específicos para cada clase de vista Las vistas son una abstracción conveniente, pero su Las vistas son una abstracción conveniente, pero su abundancia involucra problemas de sincronizaciónabundancia involucra problemas de sincronizaciónEn AS ortodoxa prevalecen 3: CC, concurrencia y En AS ortodoxa prevalecen 3: CC, concurrencia y despliegue (Bass, Clements, Kazman) despliegue (Bass, Clements, Kazman)

Lista corta (3 a 6) – Lista larga (8 o 9…)Lista corta (3 a 6) – Lista larga (8 o 9…)Viewpoints’96Viewpoints’96

Conceptos fundamentalesConceptos fundamentalesVistas & frameworksVistas & frameworks

Zachman (Niveles)

TOGAF (Arquitecturas)

4+1 (Vistas)

[BRJ99] (Vistas)

POSA (Vistas)

Microsoft (Vistas)

Alcance Negocios Lógica Diseño Lógica Lógica Empresa Datos Proceso Proceso Proceso Conceptual Sistema lógico Aplicación Física Implementación Física Tecnología Desarrollo Despliegue Representación Funcionamiento

Tecnología Casos de uso Casos de uso

Desarrollo Física

Tabla 1 - Vistas en los marcos de referencia

Vistas de UML…Vistas de UML…

Área Vista Diagramas Conceptos principales Vista estática Diagrama de clases Clase, asociación, generalización,

dependencia, realización, interfaz Vista de casos de uso

Diagramas de casos de uso

Caso de uso, actor, asociación, extensión, inclusión, generalización de casos de uso

Vista de implementación

Diagrama de componentes

Componente, interfaz, dependencia, realización

Estructural

Vista de despliegue Diagrama de despliegue Nodo, componente, dependencia, localización

Vista de máquinas de estados

Diagrama de estados Estado, evento, transición, acción

Vista de actividad Diagrama de actividad Estado, actividad, transición de terminación, división, unión

Diagrama de secuencia Interacción, objeto, mensaje, activación

Dinámica

Vista de interacción Diagrama de colaboración

Colaboración, interacción, rol de colaboración, mensaje

Gestión del modelo

Vista de gestión del modelo

Diagrama de clases Paquete, subsistema, modelo

Tabla 2 - Vistas y diagramas de UML, basado en [RJB00: 22]

No hay componentes, ni conectores, ni constraints, ni configutraciones

Vistas de UML…Vistas de UML…

Vistas y puntos de vista no están Vistas y puntos de vista no están homogeneizados en textos y autoreshomogeneizados en textos y autoresCuando los “3” hablan de AS, las Cuando los “3” hablan de AS, las vistas no se refieren a vistas no se refieren a viewpointsviewpoints o o concernsconcerns, sino a niveles de , sino a niveles de abstracciónabstracciónDefinición diferente de “arquitectura”Definición diferente de “arquitectura”

Interfaces en vez de conectoresInterfaces en vez de conectoresObjetos en lugar de componentes Objetos en lugar de componentes (“elementos”)(“elementos”)Los conectores no son conectores de Los conectores no son conectores de primera claseprimera clase

Estilos ArquitectónicosEstilos ArquitectónicosRumbaugh-Booch-Jacobson Rumbaugh-Booch-Jacobson 19911991

(1) transformaciones en lote, (2) (1) transformaciones en lote, (2) transformaciones continuas, (3) interfaz transformaciones continuas, (3) interfaz interactiva, (4) simulación dinámica de interactiva, (4) simulación dinámica de objetos del mundo real, (5) sistemas de objetos del mundo real, (5) sistemas de tiempo real, (6) administrador de tiempo real, (6) administrador de transacciones con almacenamiento y transacciones con almacenamiento y actualización de datosactualización de datos Pero: Pero: “estilos arquitectónicos”, “estilos arquitectónicos”, “arquitecturas comunes”, “marcos de “arquitecturas comunes”, “marcos de referencia arquitectónicos prototípicos”, referencia arquitectónicos prototípicos”, “formas comunes”, “clases de sistemas” “formas comunes”, “clases de sistemas” Definición no exhaustivaDefinición no exhaustivaCriterios taxonómicos no homogéneosCriterios taxonómicos no homogéneosTaxones de distinto nivel de inclusiónTaxones de distinto nivel de inclusión

Algunos tipos pueden incluir otros (ej. 6 y 3)Algunos tipos pueden incluir otros (ej. 6 y 3)

Estilos arquitectónicosEstilos arquitectónicos

Perry & Wolf, 1992 Perry & Wolf, 1992 Incluyen:Incluyen:

Componentes (2003, Componentes (2003, “elementos”)“elementos”)ConectoresConectoresEstructuras (topologías, Estructuras (topologías, configuraciones)configuraciones)Restricciones (Restricciones (constraintsconstraints))

Estilos ArquitectónicosEstilos ArquitectónicosEstilos de Flujo de DatosEstilos de Flujo de Datos

Tubería y filtrosTubería y filtros

Estilos Centrados en DatosEstilos Centrados en DatosArquitecturas de Pizarra o Arquitecturas de Pizarra o RepositorioRepositorio

Estilos de Llamada y Estilos de Llamada y RetornoRetorno

Model-View-Controller Model-View-Controller (MVC)(MVC)Arquitecturas en CapasArquitecturas en CapasArquitecturas Orientadas Arquitecturas Orientadas a Objetosa ObjetosArquitecturas Basadas en Arquitecturas Basadas en ComponentesComponentes

Estilos DerivadosEstilos DerivadosC2C2GenVocaGenVocaRESTREST

Estilos de Código MóvilEstilos de Código MóvilArquitectura de Máquinas Arquitectura de Máquinas VirtualesVirtuales

Estilos heterogéneosEstilos heterogéneosSistemas de control de Sistemas de control de procesosprocesosArquitecturas Basadas en Arquitecturas Basadas en AtributosAtributos

Estilos Peer-to-PeerEstilos Peer-to-PeerArquitecturas Basadas en Arquitecturas Basadas en EventosEventosArquitecturas Orientadas Arquitecturas Orientadas a Servicios (SOA)a Servicios (SOA)Arquitecturas Basadas en Arquitecturas Basadas en RecursosRecursos

Tres ejemplos Tres ejemplos significativossignificativos

Arquitectura basada en eventosArquitectura basada en eventosArquitectura de pizarraArquitectura de pizarraArquitecturas orientadas a serviciosArquitecturas orientadas a servicios

Presentación separada en esta serie…Presentación separada en esta serie…

Arquitectura basada en Arquitectura basada en eventoseventos

Impiden incurrir en el modelo de aplicaciones que Impiden incurrir en el modelo de aplicaciones que preguntan si sucedió algo.preguntan si sucedió algo.Generan la ejecución apenas ocurre el evento o el Generan la ejecución apenas ocurre el evento o el usuario se conectausuario se conectaModelo de Modelo de push.push. A veces se vincula con patrón A veces se vincula con patrón Observador (Observador (Observer patternObserver pattern))

Arquitecturas de PizarraArquitecturas de Pizarra

Arquitectura de PizarraArquitectura de PizarraH. Penny Nii, 1986 (H. Penny Nii, 1986 (Blackboard systemsBlackboard systems))Cuándo se utiliza: Problemas no susceptibles de Cuándo se utiliza: Problemas no susceptibles de tratarse analíticamentetratarse analíticamente

Reconocimiento de patrones, aprendizaje de máquina, Reconocimiento de patrones, aprendizaje de máquina, data data miningminingFirmas, huellas digitales, reconocimiento de iris, rostro, etcFirmas, huellas digitales, reconocimiento de iris, rostro, etc

Dos formas:Dos formas:RepositorioRepositorioPizarra pura o tablero de controlPizarra pura o tablero de control

Procesamiento de señalesProcesamiento de señalesReconocimiento de hablaReconocimiento de hablaRedes neuronales, algoritmo genético, simulación de Redes neuronales, algoritmo genético, simulación de templadotempladoAgentes autónomos (débilmente acoplados)Agentes autónomos (débilmente acoplados)

Estilos y patronesEstilos y patrones

POSA 96, Shaw 96POSA 96, Shaw 96Patrones: Christopher Alexander 1977Patrones: Christopher Alexander 1977

Elementos que se repitenElementos que se repitenComo un elemento en el mundo, cada patrón es una Como un elemento en el mundo, cada patrón es una relación entre cierto contexto, cierto sistema de relación entre cierto contexto, cierto sistema de fuerzas que ocurre repetidas veces en ese contexto y fuerzas que ocurre repetidas veces en ese contexto y cierta configuración espacial que permite que esas cierta configuración espacial que permite que esas fuerzas se resuelvan. Como un elemento de lenguaje, fuerzas se resuelvan. Como un elemento de lenguaje, un patrón es una instrucción que muestra la forma en un patrón es una instrucción que muestra la forma en que esta configuración espacial puede usarse, una y que esta configuración espacial puede usarse, una y otra vez, para resolver ese sistema de fuerzas, donde otra vez, para resolver ese sistema de fuerzas, donde quiera que el contexto la torne relevantequiera que el contexto la torne relevanteEl patrón es, en suma, al mismo tiempo una cosa que El patrón es, en suma, al mismo tiempo una cosa que pasa en el mundo y la regla que nos dice cómo crear pasa en el mundo y la regla que nos dice cómo crear esa cosa y cuándo debemos crearla. Es tanto un esa cosa y cuándo debemos crearla. Es tanto un proceso como una cosa; tanto una descripción de una proceso como una cosa; tanto una descripción de una cosa que está viva como una descripción del proceso cosa que está viva como una descripción del proceso que generará esa cosa.que generará esa cosa.

Comentario Problemas Soluciones Fase de Desarrollo

Patrones de Arquitectura

Relacionados a la interacción de objetos dentro o entre niveles arquitectónicos

Problemas arquitectónicos, adaptabilidad a requerimientos cambiantes, performance, modularidad, acoplamiento

Patrones de llamadas entre objetos (similar a los patrones de diseño), decisiones y criterios arquitectónicos, empaquetado de funcionalidad

Diseño inicial

Patrones de Diseño

Conceptos de ciencia de computación en general, independiente de aplicación

Claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, etc

Comportamiento de factoría, Clase-Responsabilidad-Contrato (CRC)

Diseño detallado

Patrones de Análisis

Usualmente específicos de aplicación o industria

Modelado del dominio, completitud, integración y equilibrio de objetivos múltiples, planeamiento para capacidades adicionales comunes

Modelos de dominio, conocimiento sobre lo que habrá de incluirse (p. ej. logging & reinicio)

Análisis

Patrones de Proceso o de Organización

Desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización

Productividad, comunicación efectiva y eficiente

Armado de equipo, ciclo de vida del software, asignación de roles, prescripciones de comunicación

Planeamiento

IdiomasEstándares de codificación y proyecto

Operaciones comunes bien conocidas en un nuevo ambiente, o a través de un grupo. Legibilidad, predictibilidad.

Sumamente específicos de un lenguaje, plataforma o ambiente

Implementación, Mantemimiento, Despliegue

Usos de estilosUsos de estilosMary Shaw, David Garlan, 1996Mary Shaw, David Garlan, 1996

Inspirado en trabajo de Parnas, 1972 (“On the criteria Inspirado en trabajo de Parnas, 1972 (“On the criteria to be used in decomposing systems into modules”) – to be used in decomposing systems into modules”) – Datos compartidos vs ocultamiento de informaciónDatos compartidos vs ocultamiento de información

Sistema de indexación de palabras clavesSistema de indexación de palabras clavesDatos compartidosDatos compartidosTipos abstractos de datosTipos abstractos de datosInvocación implícitaInvocación implícitaTubería y filtrosTubería y filtros

Comparación de versatilidad, dependencia, Comparación de versatilidad, dependencia, modularidad, reutilización, refinamiento, modularidad, reutilización, refinamiento, ventajas & desventajasventajas & desventajasAntes de escribir una línea de códigoAntes de escribir una línea de códigoTablas de comparación de atributosTablas de comparación de atributosAsignación de pesos a prioridadesAsignación de pesos a prioridades

Estilos - Conclusiones Estilos - Conclusiones

Después de 13 años, son menos Después de 13 años, son menos conocidos y frecuentados que los conocidos y frecuentados que los patronespatronesSon fundamentales para la toma de Son fundamentales para la toma de decisiones del diseño, ya que se decisiones del diseño, ya que se dispone de métodos dispone de métodos comparativoscomparativos que no existen para el caso de los que no existen para el caso de los patternspatterns

Metodologías SACAM, CBAMMetodologías SACAM, CBAM

Es esencial que se conserve un Es esencial que se conserve un número pequeño de estilos número pequeño de estilos disponiblesdisponibles

Requerimientos no Requerimientos no funcionalesfuncionales

PerformancePerformanceDisponibilidadDisponibilidadModificabilidadModificabilidadSeguridadSeguridadVerificabilidad (Verificabilidad (TestabilityTestability))Gestionabilidad (instrumentación, Gestionabilidad (instrumentación, managementmanagement, estado), estado)UsabilidadUsabilidad

Atributos de CalidadAtributos de Calidad

EscenariosEscenariosEquivalente no funcional de los casos de usoEquivalente no funcional de los casos de usoNo contemplados en UML / RUPNo contemplados en UML / RUPCuantificables - No hay diagramas de escenariosCuantificables - No hay diagramas de escenariosEstímuloEstímulo, , ambienteambiente, , respuestarespuestaEscenario de caso de uso:Escenario de caso de uso:

Un usuario remoto de web requiere un reporte de base de datosUn usuario remoto de web requiere un reporte de base de datos en hora picoen hora pico y y lo recibe dentro de los 5 segundoslo recibe dentro de los 5 segundos..

Escenario de crecimiento:Escenario de crecimiento:Agregar un nuevo servidor de base de datosAgregar un nuevo servidor de base de datos para reducir para reducir latencia en escenario 1 a 2.5 segundoslatencia en escenario 1 a 2.5 segundos dentro de una persona-dentro de una persona-semanasemana..

Escenario exploratorio:Escenario exploratorio:La mitad de los servidores se bajaráLa mitad de los servidores se bajará durante operación normaldurante operación normal sin afectar la disponibilidad del sistemasin afectar la disponibilidad del sistema..

Lenguajes de Descripción Lenguajes de Descripción Arquitectónica (ADLs)Arquitectónica (ADLs)

Lenguajes para el modelado, la Lenguajes para el modelado, la descripción y (eventualmente) la descripción y (eventualmente) la prueba de la arquitecturaprueba de la arquitecturaRepresentación de componentes, Representación de componentes, conectores, configuraciones y conectores, configuraciones y restriccionesrestriccionesPrueba de consistencia Prueba de consistencia arquitectónicaarquitectónicaSoporte de evoluciónSoporte de evolución

Géneros emparentadosGéneros emparentados

Lenguajes de especificacíón (LARCH, Lenguajes de especificacíón (LARCH, Z)Z)Lenguajes de prototipado Lenguajes de prototipado (Modechart, PSDL)(Modechart, PSDL)Lenguajes de modelado (UML)Lenguajes de modelado (UML)Lenguajes de programación (CODE, Lenguajes de programación (CODE, Ada)Ada)Herramientas para definición de Herramientas para definición de ciclo de vida (UNAS/SALE)ciclo de vida (UNAS/SALE)

ADL Fecha Investigador - Organismo ObservacionesAcme 1995 Monroe & Garlan (CMU), Wile (USC) Lenguaje de intercambio de ADLsAesop 1994 Garlan (CMU) ADL de propósito general, énfasis

en estilosArTek 1994 Terry, Hayes-Roth, Erman

(Teknowledge, DSSA)Lenguaje específico de dominio -No es ADL

Armani 1998 Monroe (CMU) ADL asociado a AcmeC2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estiloCHAM 1990 Berry / Boudol Lenguaje de especificaciónDarwin 1991 Magee, Dulay, Eisenbach, Kramer ADL con énfasis en dinámicaJacal 1997 Kicillof , Yankelevich (Universidad de

Buenos Aires)Adl - Notación de alto nivel paradescripción y prototipado

LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulosMetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominioRapide 1990 Luckham (Stanford) ADL & simulaciónSADL 1995 Moriconi, Riemenschneider (SRI) ADL con énfasis en mapeo de

refinamientoUML 1995 Rumbaugh, Jacobson, Booch (Rational) Lenguaje genérico de modelado –

No es ADLUniCon 1995 Shaw (CMU) ADL de propósito general, énfasis

en conectores y estilosWright 1994 Garlan (CMU) ADL de propósito general, énfasis

en comunicaciónxADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML

Acme/ArmaniAcme/Armani

ADLs: Sustento formalADLs: Sustento formalDarwinDarwin: cálculo Pi (: cálculo Pi (Milner-Parrow-WalkerMilner-Parrow-Walker))

BizTalk primitivo, Polyphonic C#BizTalk primitivo, Polyphonic C#

WrightWright: Communicating Sequential Processes : Communicating Sequential Processes (CSP), lógica de primer orden(CSP), lógica de primer ordenLILEANNALILEANNA: programación parametrizada e : programación parametrizada e hiper-programaciónhiper-programaciónRapideRapide: Posets: PosetsSAMSAM: Redes de Petri de transición de : Redes de Petri de transición de predicados, lógica temporal de primer ordenpredicados, lógica temporal de primer ordenJacalJacal: Redes de Petri: Redes de PetriCasi todos los ADLs tienen BNFCasi todos los ADLs tienen BNFModelo estructural no ligado a OOModelo estructural no ligado a OO

Situación actual de los Situación actual de los ADLsADLs

Ninguno se impuso ni en la academia ni en Ninguno se impuso ni en la academia ni en el mercadoel mercadoCompás de espera:Compás de espera:

UML 2UML 2Domain Specific LanguagesDomain Specific LanguagesXMLXMLWeb SemánticaWeb Semántica

Visión positiva: necesidad de métodos Visión positiva: necesidad de métodos formales debido a complejidad de factoresformales debido a complejidad de factoresVisión negativa: ADLs “obsoletos”Visión negativa: ADLs “obsoletos”La producción de ADLs se ha desaceleradoLa producción de ADLs se ha desacelerado

Metodologías Metodologías arquitectónicasarquitectónicas

Posicionamiento en Posicionamiento en ciclo de vida (AS en ciclo de vida (AS en RUP)RUP)Atributos de calidad Atributos de calidad & escenarios& escenarios[Primitivas de [Primitivas de atributo]atributo]Architecture Based Architecture Based Design (ABD)Design (ABD)Tácticas Tácticas ArquitectónicasArquitectónicasComparación de Comparación de alternativas (SACAM)alternativas (SACAM)Diseño basado en Diseño basado en atributosatributos (ADD) (ADD)

Ventajas y desventajas Ventajas y desventajas (ATAM)(ATAM)Elección de Elección de arquitecturaarquitecturaAnálisis de arquitectura Análisis de arquitectura (SAAM)(SAAM)Quality Attribute Quality Attribute Workshop (QAW)Workshop (QAW)Revisión activa de Revisión activa de diseño parcial (ARID)diseño parcial (ARID)Análisis de Análisis de costo/beneficio (CBAM)costo/beneficio (CBAM)Reformulación: UML & Reformulación: UML & RUPRUP

Campos de ASCampos de AS

Fundamentos formales de la ASFundamentos formales de la ASBases matemáticasBases matemáticasCaracterizaciones formales de propiedades extra-Caracterizaciones formales de propiedades extra-funcionales tales como mantenibilidadfuncionales tales como mantenibilidadTeorías de la interconexiónTeorías de la interconexión

Técnicas arquitectónicas de análisisTécnicas arquitectónicas de análisisMétodos de desarrollo basados en arquitecturaMétodos de desarrollo basados en arquitectura

Visual Studio 2005 Team SystemVisual Studio 2005 Team System

Recuperación y reutilización de arquitecturaRecuperación y reutilización de arquitecturaCodificación y guía arquitectónicaCodificación y guía arquitectónicaHerramientas y ambientes de diseño Herramientas y ambientes de diseño arquitectónicoarquitectónicoEstudios de casosEstudios de casos

Problemas pendientes en Problemas pendientes en ASAS

Falta de criterio unificadoFalta de criterio unificadoNo hay un modelo de proceso de punta a puntaNo hay un modelo de proceso de punta a puntaDesarrollo en paralelo de conceptos antagónicos o Desarrollo en paralelo de conceptos antagónicos o no coordinadosno coordinados

Métodos ágilesMétodos ágilesMetodologías de ciclo de vidaMetodologías de ciclo de vidaPatrones, estilos y tácticasPatrones, estilos y tácticas

Apropiación nominal de la AS por estrategias que Apropiación nominal de la AS por estrategias que no implementan principios arquitectónicos pero no implementan principios arquitectónicos pero se benefician de su prestigiose benefician de su prestigioPoca masa crítica de herramientas y lenguajes de Poca masa crítica de herramientas y lenguajes de modelado arquitectónico (de alto nivel, con modelado arquitectónico (de alto nivel, con conectores de primera clase)conectores de primera clase)

BeneficiosBeneficios

Decisiones tempranasDecisiones tempranasBarry Boehm, 1995Barry Boehm, 1995

Si un proyecto no ha logrado una arquitectura del sistema, Si un proyecto no ha logrado una arquitectura del sistema, incluyendo su justificación, el proyecto no debe empezar el incluyendo su justificación, el proyecto no debe empezar el desarrollo en gran escala. Si se especifica la arquitectura desarrollo en gran escala. Si se especifica la arquitectura como un elemento a entregar, se la puede usar a lo largo de como un elemento a entregar, se la puede usar a lo largo de los procesos de desarrollo y mantenimiento [Boe95].los procesos de desarrollo y mantenimiento [Boe95].

Análisis de consistencia antes de Análisis de consistencia antes de elaborar el diseño (y escribir el código)elaborar el diseño (y escribir el código)Sistematización de la experienciaSistematización de la experienciaHomogeneización del lenguaje (IEEE Homogeneización del lenguaje (IEEE 1471)1471)Herramientas para la evoluciónHerramientas para la evoluciónRe-utilizaciónRe-utilización

Conclusiones generalesConclusiones generalesImportancia de la Arquitectura de SoftwareImportancia de la Arquitectura de SoftwareCriticidad de las decisiones tempranas de Criticidad de las decisiones tempranas de arquitecturaarquitecturaAlto nivel de abstracciónAlto nivel de abstracciónVinculada con requerimientos no funcionalesVinculada con requerimientos no funcionalesFuerte impulso en la academia y la industriaFuerte impulso en la academia y la industriaHerramientas arquitectónicas aún en proceso de Herramientas arquitectónicas aún en proceso de definición y desarrollodefinición y desarrolloMetodologías arquitectónicas, en proceso de Metodologías arquitectónicas, en proceso de elaboración preliminarelaboración preliminarResta elaborar: tácticas arquitectónicas, métodos Resta elaborar: tácticas arquitectónicas, métodos basados en arquitectura, vínculo entre conceptos basados en arquitectura, vínculo entre conceptos de arquitectura, DSLs, factorías, de arquitectura, DSLs, factorías, building blocksbuilding blocks, …, …

ReferenciasReferencias

Artículos de Arquitectura de Software en Artículos de Arquitectura de Software en http://www.microsoft.com/spanish/msdn/arhttp://www.microsoft.com/spanish/msdn/arquitecturaquitecturaLen Bass, Paul Clements, Rick Kazman. Len Bass, Paul Clements, Rick Kazman. 2003. 2003. Software Architecture in PracticeSoftware Architecture in Practice, 2ª , 2ª ediciónediciónDocumentación del SEI en Carnegie MellonDocumentación del SEI en Carnegie Mellon

http://www.sei.cmu.edu/publications/publicationhttp://www.sei.cmu.edu/publications/publications.htmls.html

Rick Kazman, Philippe Kruchten et al. 2004. Rick Kazman, Philippe Kruchten et al. 2004. “Integrating Software-Architecture-centric “Integrating Software-Architecture-centric methods into the Rational Unified Process”, methods into the Rational Unified Process”, CMU/SEI-2004-TR-011CMU/SEI-2004-TR-011Recomendaciones IEEE 1471/2000Recomendaciones IEEE 1471/2000

¿Preguntas?Billyr@microsoft.com.ar