20051122-ARC-BA 555555555555555555555.ppt

Introduccion a la arquitectura de software I

1. Introducción a la Introducción a la
Arquitectura de SoftwareArquitectura de Software
Billy ReynosoBilly Reynoso
UNIVERSIDAD DE BUENOS AIRESUNIVERSIDAD DE BUENOS AIRES
[email protected]@microsoft.com.ar

2. ObjetivosObjetivos
Suministrar 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 bien un , sino más bien un
surveysurvey de lo que significa AS, una evaluación de lo de lo que significa AS, una evaluación de lo
que ha llegado a ser y una puntualización sobre lo que ha llegado a ser y una puntualización sobre lo
que no esque no es
Despejar malos entendidos sobre arquitectura Despejar malos entendidos sobre arquitectura
como diseño de aplicacionescomo diseño de aplicaciones
Vincular perspectivas de la academia y la Vincular perspectivas de la academia y la
industriaindustria
Privilegiar elaboraciones de la corriente teórica Privilegiar elaboraciones de la corriente teórica
de CMU/SEIde CMU/SEI
Describir desarrollos de estado de arte, Describir desarrollos de estado de arte,
problemas pendientes y tendenciasproblemas pendientes y tendencias
Proporcionar 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

3. TemarioTemario
ObjetivosObjetivos
ContextoContexto
Errores de concepto habitualesErrores de concepto habituales
Antecedentes históricosAntecedentes históricos
Definición – Repositorio de definicionesDefinición – Repositorio de definiciones
Corrientes principalesCorrientes principales
Conceptos fundamentales (CMU/SEI)Conceptos fundamentales (CMU/SEI)
Estilos arquitectónicosEstilos arquitectónicos
Estilos y patronesEstilos y patrones
Lenguajes de Descripción Arquitectónica (ADLs)Lenguajes de Descripción Arquitectónica (ADLs)
Atributos de calidad, escenarios y tácticasAtributos de calidad, escenarios y tácticas
Métodos basados en arquitecturaMétodos basados en arquitectura
Situación, conclusiones y referenciasSituación, conclusiones y referencias

4. Contexto – 1995-2005Contexto – 1995-2005
Los 3 grandes temas de ingeniería de softwareLos 3 grandes temas de ingeniería de software
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) - 1996
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad y Michael StalSommerlad y Michael Stal
Organizational patterns (Coplien)Organizational patterns (Coplien)
Métodos heterodoxos (eXtreme Programming, Scrum, Métodos heterodoxos (eXtreme Programming, Scrum,
Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…) Evo, FDD, DSDM, RUP, AM, Crystal, LD, ASD…)
Arquitectura de SoftwareArquitectura de Software
Otros:Otros:
Refactorización Refactorización
AOP, SOA, Grid Computing, Semantic Web...AOP, SOA, Grid Computing, Semantic Web...

5. Conceptos cuestionables Conceptos cuestionables
(1/2)(1/2)
Arquitectura como normativa maduraArquitectura como normativa madura
Abundancia de herramientas de diseño Abundancia de herramientas de diseño
arquitectónicoarquitectónico
Semántica y lenguajes arquitectónicos iguales en la Semántica y lenguajes arquitectónicos iguales en la
academia y la industriaacademia y la industria
UML 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 & ciclo Posición de la AS bien definida en ingeniería & ciclo
de vidade 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 entre requerimientos y la especificación de casos de uso, o entre
éstos y el diseñoéstos y el diseño
Arquitectura vinculada a metodología y proceso RUPArquitectura vinculada a metodología y proceso RUP
La AS está La AS está formalmenteformalmente desarrollada las disciplinas de RUP desarrollada las disciplinas de RUP
(cf. Kazman, Kruchten (cf. Kazman, Kruchten et alet al 2004) 2004)

6. Conceptos cuestionables Conceptos cuestionables
(2/2)(2/2)
La AS tiene que ver con modelado OOLa AS tiene que ver con modelado OO
La AS no admite ni requiere otros La AS no admite ni requiere otros
paradigmasparadigmas
No 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 e generan la estructura de la aplicación e
incluso el código (analogía con modelos incluso el código (analogía con modelos
CASE)CASE)
El dilema del El dilema del roundtrip engineeringroundtrip engineering está está
resueltoresuelto
Hay que considerar modelo de DSLHay que considerar modelo de DSL

7. Antecedentes históricos Antecedentes históricos
(1/5)(1/5)
Edsger Dijkstra, 1968Edsger Dijkstra, 1968
Ciencias de la computación como rama aplicada de las Ciencias de la computación como rama aplicada de las
matemáticasmatemáticas
Niveles de abstracciónNiveles de abstracción
Stacks, abrazos mortales, semáforos, algoritmo de Stacks, abrazos mortales, semáforos, algoritmo de
camino más cortocamino más corto
NATO, 1968NATO, 1968
F. L. Bauer “Ingeniería de software”F. L. Bauer “Ingeniería de software”
NATO, 1969NATO, 1969
P. 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

8. Antecedentes históricos Antecedentes históricos
(2/5)(2/5)
Niklaus Wirth, 1971Niklaus Wirth, 1971
Niveles de abstracción Niveles de abstracción  Stepwise refinementStepwise refinement
DeRemer & Kron, 1976DeRemer & Kron, 1976
Programming in the largeProgramming in the large
Fred Brooks, 1975 – MMMFred Brooks, 1975 – MMM
Diseñador del OS/360, Premio Turing 2000Diseñador del OS/360, Premio Turing 2000
Arquitectura como interfaz usuarioArquitectura como interfaz usuario
El arquitecto es un agente del usuario, igual que quien El arquitecto es un agente del usuario, igual que quien
diseña su casadiseña su casa
Importancia de las estructuras de alto nivel y de Importancia de las estructuras de alto nivel y de
decisiones tomadas al principiodecisiones tomadas al principio
Arquitectura: qué hacer - Implementación: cómo hacerloArquitectura: qué hacer - Implementación: cómo hacerlo

9. Antecedentes históricos Antecedentes históricos
(3/5)(3/5)
David ParnasDavid Parnas
1972: Módulos – Ocultamiento de información1972: Módulos – Ocultamiento de información
1974: Estructuras de software1974: Estructuras de software
1976: 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 todos Una familia de programas es un conjunto de programas (no todos
los cuales han sido construidos o lo serán alguna vez) a los cuales es los cuales han sido construidos o lo serán alguna vez) a los cuales es
provechoso o útil considerar como grupo. Esto evita el uso de provechoso o útil considerar como grupo. Esto evita el uso de
conceptos ambiguos tales como “similitud funcional” que surgen a conceptos ambiguos tales como “similitud funcional” que surgen a
veces cuando se describen dominios. Por ejemplo, los ambientes de veces cuando se describen dominios. Por ejemplo, los ambientes de
ingeniería de software y los juegos de video no se consideran ingeniería de software y los juegos de video no se consideran
usualmente en el mismo dominio, aunque podrían considerarse usualmente en el mismo dominio, aunque podrían considerarse
miembros de la misma familia de programas en una discusión sobre miembros de la misma familia de programas en una discusión sobre
herramientas que ayuden a construir interfaces gráficas, que ambos herramientas que ayuden a construir interfaces gráficas, que ambos
casualmente utilizan”.casualmente utilizan”.

10. Antecedentes históricos Antecedentes históricos
(4/5)(4/5)
Línea de Dijkstra-Parnas-HoareLínea de Dijkstra-Parnas-Hoare
Fundamentación matemáticaFundamentación matemática
Métodos formalesMétodos formales
Programa fuertePrograma fuerte
Línea de BrooksLínea de Brooks
Ambiente humanoAmbiente humano
Visión cualitativaVisión cualitativa
Pensamiento no linealPensamiento no lineal
Programa crítico y heterodoxoPrograma crítico y heterodoxo

11. 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” arquitectura de software. Usamos el término “arquitectura”
en contraste con “diseño”, para evocar nociones de en contraste con “diseño”, para evocar nociones de
codificación, de abstracción, de estándares, de codificación, de abstracción, de estándares, de
entrenamiento formal (de los arquitectos de software) y de entrenamiento formal (de los arquitectos de software) y de
estilo. estilo.  Es tiempo de re-examinar el papel de la arquitectura Es tiempo de re-examinar el papel de la arquitectura
de software en el contexto más amplio del proceso de de software en el contexto más amplio del proceso de
software y de su administración, así como señalar las nuevas software y de su administración, así como señalar las nuevas
técnicas que han sido adoptadas”.técnicas que han sido 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, Robert Mary Shaw, David Garlan, Paul Clements, Robert
Allen, Rick KazmanAllen, Rick Kazman

12. 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 y los componentes, las relaciones entre ellos y el ambiente y los
principios que orientan su diseño y evolución.principios que orientan su diseño y evolución.
Adoptada por Microsoft en estrategia arquitectónica / MSF 3 & Adoptada por Microsoft en estrategia arquitectónica / MSF 3 &
44
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; esto desarrollo, aplicación y mantenimiento del software; esto
es, la aplicación de la ingeniería al software.es, la aplicación de la ingeniería al software.

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

14. 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), 1995
POSA, 1996POSA, 1996
Desarrollo de UML / OODDesarrollo de UML / OOD

15. Corrientes teóricas en ASCorrientes teóricas en AS
Arquitectura como etapa de la ingeniería Arquitectura como etapa de la ingeniería
de software orientada a objetosde software orientada a objetos
James Rumbaugh, Grady Booch, Ivar Jacobson James Rumbaugh, Grady Booch, Ivar Jacobson
(“los 3 amigos”), Craig Larman…(“los 3 amigos”), Craig Larman…
Arquitectura estructural – SEIArquitectura estructural – SEI
Corriente principal: Garlan, Shaw, ClementsCorriente principal: Garlan, Shaw, Clements
Variantes con modelos de datos (Medvidovic)Variantes con modelos de datos (Medvidovic)
Variantes radicales, formales (Moriconi-SRI)Variantes radicales, formales (Moriconi-SRI)
Arquitectura basada en patrones – SEIArquitectura basada en patrones – SEI
Arquitectura procesual (Kazman, Bass)Arquitectura procesual (Kazman, Bass)

16. VistasVistas
1977, análisis estructurado (Douglas Ross)1977, análisis estructurado (Douglas Ross)
Separación de incumbenciasSeparación de incumbencias
Habitualmente 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 vistas
Se basa en vista única e implícita, de carácter estructuralSe basa en vista única e implícita, de carácter estructural
Muchos arquitectos evitan hablar de vistasMuchos arquitectos evitan hablar de vistas
Cuando 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ón
En 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

17. Conceptos fundamentalesConceptos fundamentales
Vistas & 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

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

19. 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 autores
Cuando los “3” hablan de AS, las vistas Cuando los “3” hablan de AS, las vistas
no se refieren a no se refieren a viewpointsviewpoints o o concernsconcerns, ,
sino a niveles de abstracciónsino a niveles de abstracción
Definición diferente de “arquitectura”Definición diferente de “arquitectura”
Interfaces en vez de conectoresInterfaces en vez de conectores
Objetos 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

20. Estilos ArquitectónicosEstilos Arquitectónicos
Rumbaugh-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 objetos interactiva, (4) simulación dinámica de objetos
del mundo real, (5) sistemas de tiempo real, del mundo real, (5) sistemas de tiempo real,
(6) administrador de transacciones con (6) administrador de transacciones con
almacenamiento y actualización de datosalmacenamiento y actualización de datos
Pero: Pero: “estilos arquitectónicos”, “arquitecturas “estilos arquitectónicos”, “arquitecturas
comunes”, “marcos de referencia comunes”, “marcos de referencia
arquitectónicos prototípicos”, “formas arquitectónicos prototípicos”, “formas
comunes”, “clases de sistemas” comunes”, “clases de sistemas”
Definición no exhaustivaDefinición no exhaustiva
Criterios taxonómicos no homogéneosCriterios taxonómicos no homogéneos
Taxones 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)

21. Estilos arquitectónicosEstilos arquitectónicos
Perry & Wolf, 1992 Perry & Wolf, 1992
Incluyen:Incluyen:
Componentes (2003, “elementos”)Componentes (2003, “elementos”)
ConectoresConectores
Estructuras (topologías, Estructuras (topologías,
configuraciones)configuraciones)
Restricciones (Restricciones (constraintsconstraints))

22. Estilos ArquitectónicosEstilos Arquitectónicos
Estilos de Flujo de DatosEstilos de Flujo de Datos
Tubería y filtrosTubería y filtros
Estilos Centrados en DatosEstilos Centrados en Datos
Arquitecturas de Pizarra o Arquitecturas de Pizarra o
RepositorioRepositorio
Estilos de Llamada y RetornoEstilos de Llamada y Retorno
Model-View-Controller Model-View-Controller
(MVC)(MVC)
Arquitecturas en CapasArquitecturas en Capas
Arquitecturas Orientadas a Arquitecturas Orientadas a
ObjetosObjetos
Arquitecturas Basadas en Arquitecturas Basadas en
ComponentesComponentes
Estilos DerivadosEstilos Derivados
C2C2
GenVocaGenVoca
RESTREST
Estilos de Código MóvilEstilos de Código Móvil
Arquitectura de Máquinas Arquitectura de Máquinas
VirtualesVirtuales
Estilos heterogéneosEstilos heterogéneos
Sistemas de control de Sistemas de control de
procesosprocesos
Arquitecturas Basadas en Arquitecturas Basadas en
AtributosAtributos
Estilos Peer-to-PeerEstilos Peer-to-Peer
Arquitecturas Basadas en Arquitecturas Basadas en
EventosEventos
Arquitecturas Orientadas a Arquitecturas Orientadas a
Servicios (SOA)Servicios (SOA)
Arquitecturas Basadas en Arquitecturas Basadas en
RecursosRecursos

23. Tres ejemplos significativosTres ejemplos significativos
Arquitectura basada en eventosArquitectura basada en eventos
Arquitectura de pizarraArquitectura de pizarra
Arquitecturas orientadas a serviciosArquitecturas orientadas a servicios
Presentación separada en esta serie…Presentación separada en esta serie…

24. 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 conecta
Modelo de Modelo de push.push. A veces se vincula con patrón A veces se vincula con patrón
Observador (Observador (Observer patternObserver pattern))

25. Arquitecturas de PizarraArquitecturas de Pizarra

26. Arquitectura de PizarraArquitectura de Pizarra
H. Penny Nii, 1986 (H. Penny Nii, 1986 (Blackboard systemsBlackboard systems))
Cuándo se utiliza: Problemas no susceptibles de tratarse Cuándo se utiliza: Problemas no susceptibles de tratarse
analíticamenteanalíticamente
Reconocimiento de patrones, aprendizaje de máquina, Reconocimiento de patrones, aprendizaje de máquina, data miningdata mining
Firmas, huellas digitales, reconocimiento de iris, rostro, etcFirmas, huellas digitales, reconocimiento de iris, rostro, etc
Dos formas:Dos formas:
RepositorioRepositorio
Pizarra pura o tablero de controlPizarra pura o tablero de control
Procesamiento de señalesProcesamiento de señales
Reconocimiento de hablaReconocimiento de habla
Redes neuronales, algoritmo genético, simulación de Redes neuronales, algoritmo genético, simulación de
templadotemplado
Agentes autónomos (débilmente acoplados)Agentes autónomos (débilmente acoplados)

27. Estilos y patronesEstilos y patrones
POSA 96, Shaw 96POSA 96, Shaw 96
Patrones: Christopher Alexander 1977Patrones: Christopher Alexander 1977
Elementos que se repitenElementos que se repiten
Como un elemento en el mundo, cada patrón es una relación Como un elemento en el mundo, cada patrón es una relación
entre cierto contexto, cierto sistema de fuerzas que ocurre entre cierto contexto, cierto sistema de fuerzas que ocurre
repetidas veces en ese contexto y cierta configuración espacial repetidas veces en ese contexto y cierta configuración espacial
que permite que esas fuerzas se resuelvan. Como un elemento que permite que esas fuerzas se resuelvan. Como un elemento
de lenguaje, un patrón es una instrucción que muestra la de lenguaje, un patrón es una instrucción que muestra la
forma en que esta configuración espacial puede usarse, una y forma en que esta configuración espacial puede usarse, una y
otra vez, para resolver ese sistema de fuerzas, donde quiera otra vez, para resolver ese sistema de fuerzas, donde quiera
que el contexto la torne relevanteque el contexto la torne relevante
El patrón es, en suma, al mismo tiempo una cosa que pasa en 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 esa cosa y el mundo y la regla que nos dice cómo crear esa cosa y
cuándo debemos crearla. Es tanto un proceso como una cosa; cuándo debemos crearla. Es tanto un proceso como una cosa;
tanto una descripción de una cosa que está viva como una tanto una descripción de una cosa que está viva como una
descripción del proceso que generará esa cosa.descripción del proceso que generará esa cosa.

28. 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
Idiomas
Está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

29. Usos de estilosUsos de estilos
Mary Shaw, David Garlan, 1996Mary Shaw, David Garlan, 1996
Inspirado en trabajo de Parnas, 1972 (“On the criteria to Inspirado en trabajo de Parnas, 1972 (“On the criteria to
be used in decomposing systems into modules”) – Datos be used in decomposing systems into modules”) – Datos
compartidos vs ocultamiento de informacióncompartidos vs ocultamiento de información
Sistema de indexación de palabras clavesSistema de indexación de palabras claves
Datos compartidosDatos compartidos
Tipos abstractos de datosTipos abstractos de datos
Invocación implícitaInvocación implícita
Tubería y filtrosTubería y filtros
Comparación de versatilidad, dependencia, Comparación de versatilidad, dependencia,
modularidad, reutilización, refinamiento, ventajas & modularidad, reutilización, refinamiento, ventajas &
desventajasdesventajas
Antes de escribir una línea de códigoAntes de escribir una línea de código
Tablas de comparación de atributosTablas de comparación de atributos
Asignación de pesos a prioridadesAsignación de pesos a prioridades

30. 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
patronespatrones
Son fundamentales para la toma de Son fundamentales para la toma de
decisiones del diseño, ya que se dispone decisiones del diseño, ya que se dispone
de métodos de métodos comparativoscomparativos que no que no
existen para el caso de los existen para el caso de los patternspatterns
Metodologías SACAM, CBAMMetodologías SACAM, CBAM
Es esencial que se conserve un número Es esencial que se conserve un número
pequeño de estilos disponiblespequeño de estilos disponibles

31. Requerimientos no Requerimientos no
funcionalesfuncionales
PerformancePerformance
DisponibilidadDisponibilidad
ModificabilidadModificabilidad
SeguridadSeguridad
Verificabilidad (Verificabilidad (TestabilityTestability))
Gestionabilidad (instrumentación, Gestionabilidad (instrumentación,
managementmanagement, estado), estado)
UsabilidadUsabilidad

32. Atributos de CalidadAtributos de Calidad

33. EscenariosEscenarios
Equivalente no funcional de los casos de usoEquivalente no funcional de los casos de uso
No contemplados en UML / RUPNo contemplados en UML / RUP
Cuantificables - No hay diagramas de escenariosCuantificables - No hay diagramas de escenarios
EstímuloEstímulo, , ambienteambiente, , respuestarespuesta
Escenario 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 en
hora picohora 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 latencia en para reducir latencia en
escenario 1 a 2.5 segundosescenario 1 a 2.5 segundos dentro de una persona-semanadentro de una persona-semana..
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 sin
afectar la disponibilidad del sistemaafectar la disponibilidad del sistema..

34. 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 prueba descripción y (eventualmente) la prueba
de la arquitecturade la arquitectura
Representación de componentes, Representación de componentes,
conectores, configuraciones y conectores, configuraciones y
restriccionesrestricciones
Prueba de consistencia arquitectónicaPrueba de consistencia arquitectónica
Soporte de evoluciónSoporte de evolución

35. Géneros emparentadosGéneros emparentados
Lenguajes de especificacíón (LARCH, Z)Lenguajes de especificacíón (LARCH, Z)
Lenguajes de prototipado (Modechart, Lenguajes de prototipado (Modechart,
PSDL)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 ciclo Herramientas para definición de ciclo
de vida (UNAS/SALE)de vida (UNAS/SALE)

36. ADL Fecha Investigador - Organismo Observaciones
Acme 1995 Monroe & Garlan (CMU), Wile (USC)Lenguaje de intercambio de ADLs
Aesop 1994 Garlan (CMU) ADL de propósito general, énfasis
en estilos
ArTek 1994 Terry, Hayes-Roth, Erman
(Teknowledge, DSSA)
Lenguaje específico de dominio -
No es ADL
Armani 1998 Monroe (CMU) ADL asociado a Acme
C2 SADL 1996 Taylor/Medvidovic (UCI) ADL específico de estilo
CHAM 1990 Berry / Boudol Lenguaje de especificación
Darwin 1991 Magee, Dulay, Eisenbach, KramerADL con énfasis en dinámica
Jacal 1997 Kicillof , Yankelevich (Universidad de
Buenos Aires)
Adl - Notación de alto nivel para
descripción y prototipado
LILEANNA 1993 Tracz (Loral Federal) Lenguaje de conexión de módulos
MetaH 1993 Binns, Englehart (Honeywell) ADL específico de dominio
Rapide 1990 Luckham (Stanford) ADL & simulación
SADL 1995 Moriconi, Riemenschneider (SRI)ADL con énfasis en mapeo de
refinamiento
UML 1995 Rumbaugh, Jacobson, Booch (Rational)Lenguaje genérico de modelado –
No es ADL
UniCon 1995 Shaw (CMU) ADL de propósito general, énfasis
en conectores y estilos
Wright 1994 Garlan (CMU) ADL de propósito general, énfasis
en comunicación
xADL 2000 Medvidovic, Taylor (UCI, UCLA) ADL basado en XML

37. Acme/ArmaniAcme/Armani

39. ADLs: Sustento formalADLs: Sustento formal
DarwinDarwin: 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 orden
LILEANNALILEANNA: programación parametrizada e hiper-: programación parametrizada e hiper-
programaciónprogramación
RapideRapide: Posets: Posets
SAMSAM: Redes de Petri de transición de predicados, : Redes de Petri de transición de predicados,
lógica temporal de primer ordenlógica temporal de primer orden
JacalJacal: Redes de Petri: Redes de Petri
Casi todos los ADLs tienen BNFCasi todos los ADLs tienen BNF
Modelo estructural no ligado a OOModelo estructural no ligado a OO

40. Situación actual de los ADLsSituación actual de los ADLs
Ninguno se impuso ni en la academia ni en el Ninguno se impuso ni en la academia ni en el
mercadomercado
Compás de espera:Compás de espera:
UML 2UML 2
Domain Specific LanguagesDomain Specific Languages
XMLXML
Web 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 factores
Visión negativa: ADLs “obsoletos”Visión negativa: ADLs “obsoletos”
La producción de ADLs se ha desaceleradoLa producción de ADLs se ha desacelerado

41. 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 &
escenariosescenarios
[Primitivas de atributo][Primitivas de atributo]
Architecture Based Architecture Based
Design (ABD)Design (ABD)
Tácticas Tácticas
ArquitectónicasArquitectónicas
Comparació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 arquitecturaElección de arquitectura
Análisis de arquitectura Análisis de arquitectura
(SAAM)(SAAM)
Quality Attribute Quality Attribute
Workshop (QAW)Workshop (QAW)
Revisión activa de diseño Revisión activa de diseño
parcial (ARID)parcial (ARID)
Análisis de Análisis de
costo/beneficio (CBAM)costo/beneficio (CBAM)
Reformulación: UML & Reformulación: UML &
RUPRUP

42. Campos de ASCampos de AS
Fundamentos formales de la ASFundamentos formales de la AS
Bases matemáticasBases matemáticas
Caracterizaciones formales de propiedades extra-funcionales Caracterizaciones formales de propiedades extra-funcionales
tales como mantenibilidadtales como mantenibilidad
Teorías de la interconexiónTeorías de la interconexión
Técnicas arquitectónicas de análisisTécnicas arquitectónicas de análisis
Mé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 arquitectura
Codificación y guía arquitectónicaCodificación y guía arquitectónica
Herramientas y ambientes de diseño arquitectónicoHerramientas y ambientes de diseño arquitectónico
Estudios de casosEstudios de casos

43. Problemas pendientes en ASProblemas pendientes en AS
Falta de criterio unificadoFalta de criterio unificado
No hay un modelo de proceso de punta a puntaNo hay un modelo de proceso de punta a punta
Desarrollo en paralelo de conceptos antagónicos o no Desarrollo en paralelo de conceptos antagónicos o no
coordinadoscoordinados
Métodos ágilesMétodos ágiles
Metodologías de ciclo de vidaMetodologías de ciclo de vida
Patrones, estilos y tácticasPatrones, estilos y tácticas
Apropiación nominal de la AS por estrategias que no Apropiación nominal de la AS por estrategias que no
implementan principios arquitectónicos pero se implementan principios arquitectónicos pero se
benefician de su prestigiobenefician de su prestigio
Poca 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)

44. BeneficiosBeneficios
Decisiones tempranasDecisiones tempranas
Barry 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 como un desarrollo en gran escala. Si se especifica la arquitectura como un
elemento a entregar, se la puede usar a lo largo de los procesos elemento a entregar, se la puede usar a lo largo de los procesos
de desarrollo y mantenimiento [Boe95].de desarrollo y mantenimiento [Boe95].
Análisis de consistencia antes de elaborar Análisis de consistencia antes de elaborar
el diseño (y escribir el código)el diseño (y escribir el código)
Sistematización de la experienciaSistematización de la experiencia
Homogeneización del lenguaje (IEEE 1471)Homogeneización del lenguaje (IEEE 1471)
Herramientas para la evoluciónHerramientas para la evolución
Re-utilizaciónRe-utilización

45. Conclusiones generalesConclusiones generales
Importancia de la Arquitectura de SoftwareImportancia de la Arquitectura de Software
Criticidad de las decisiones tempranas de arquitecturaCriticidad de las decisiones tempranas de arquitectura
Alto nivel de abstracciónAlto nivel de abstracción
Vinculada con requerimientos no funcionalesVinculada con requerimientos no funcionales
Fuerte impulso en la academia y la industriaFuerte impulso en la academia y la industria
Herramientas arquitectónicas aún en proceso de Herramientas arquitectónicas aún en proceso de
definición y desarrollodefinición y desarrollo
Metodologías arquitectónicas, en proceso de Metodologías arquitectónicas, en proceso de
elaboración preliminarelaboración preliminar
Resta elaborar: tácticas arquitectónicas, métodos Resta elaborar: tácticas arquitectónicas, métodos
basados en arquitectura, vínculo entre conceptos de basados en arquitectura, vínculo entre conceptos de
arquitectura, DSLs, factorías, arquitectura, DSLs, factorías, building blocksbuilding blocks, …, …

46. ReferenciasReferencias
Artículos de Arquitectura de Software en Artículos de Arquitectura de Software en
http://www.microsoft.com/spanish/msdn/arquihttp://www.microsoft.com/spanish/msdn/arqui
tecturatectura
Len Bass, Paul Clements, Rick Kazman. 2003. Len Bass, Paul Clements, Rick Kazman. 2003.
Software Architecture in PracticeSoftware Architecture in Practice, 2ª edición, 2ª edición
Documentación del SEI en Carnegie MellonDocumentación del SEI en Carnegie Mellon
http://www.sei.cmu.edu/publications/publications.hhttp://www.sei.cmu.edu/publications/publications.h
tmltml
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-011
Recomendaciones IEEE 1471/2000Recomendaciones IEEE 1471/2000

47. ¿Preguntas?
[email protected]