View
39
Download
3
Category
Preview:
Citation preview
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))
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
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
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
Recommended