UTM, Aguaszoft

1. Facultad de Ciencias Informáticas
Desarrollo de Aplicaciones Web
Unidad 3 Arquitectura orientada a
microservicios web y manejo de estados
PhD(c). Luis Fernando Aguas Bucheli
+593 984015184
@Aguaszoft
luis.aguas@utm.edu.ec

2. Objetivos de Desarrollo Sostenible
Meta
4.7 De aquí a 2030, asegurar que todos los alumnos adquieran
los conocimientos teóricos y prácticos necesarios para promover
el desarrollo sostenible, entre otras cosas mediante la educación
para el desarrollo sostenible y los estilos de vida sostenibles, los
derechos humanos, la igualdad de género, la promoción de una
cultura de paz y no violencia, la ciudadanía mundial y la
valoración de la diversidad cultural y la contribución de la cultura
al desarrollo sostenible

3. No hay caminos para la paz; la paz es el camino

4. Resultado de Aprendizaje
• Diseñar un producto de
software en el que se
apliquen principios de
diseño, para que sea
robusto, fácil de mantener
y modificar
Contenido
• Unidad 3 Arquitectura
orientada a microservicios web
y manejo de estados
• 3.2 Arquitectura de microservicios
• 3.2.1 Frameworks para
microservicios

5. Contexto
 Los 3 grandes temas de ingeniería de software
• Patrones
Design patterns (GoF) - 1995
 Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides
Architectural patterns (POSA) - 1996
 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y
Michael Stal
Organizational patterns (Coplien)
• Métodos heterodoxos (2001)
eXtreme Programming, Scrum, Evo, FDD, DSDM, RUP, AM, Crystal,
LD, ASD…)
• Arquitectura de Software (1992)

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

7. Definición
• http://www.sei.cmu.edu/architecture/definitions.html
• (1) Proceso dentro del ciclo de vida, (2) Topología, (3) Disciplina.
• Arquitectura - IEEE 1471-2000:
• La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus
componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y
evolución.
• Adoptada por Microsoft en estrategia arquitectónica / MSF
• Ingeniería - IEEE 610.12.1990:
• La aplicación de una estrategia sistemática, disciplinada y cuantificable al desarrollo, aplicación y
mantenimiento del software; esto es, la aplicación de la ingeniería al software.

8. La Arquitectura no es…
 Una normativa madura
 Igual en la academia y en la industria
 Diseño de software con UML
 Naturalmente vinculada con ingeniería & ciclo de vida
• Ocurre en algún punto entre la elicitación de requerimientos y la
especificación de casos de uso, o entre éstos y el diseño
 Naturalmente vinculada a metodología (RUP)
 Naturalmente relacionada con modelado Orientado a Objetos
 Hay vínculo “natural” entre requerimientos (casos de uso) y clases
 Las herramientas arquitectónicas generan el código de la
aplicación

9. Arquitectura es…
• Vista estructural de alto nivel
• Define estilo o combinación de estilos para una solución
• Se concentra en requerimientos no funcionales
• Los requerimientos funcionales se satisfacen mediante modelado y diseño de
aplicación
• Esencial para éxito o fracaso de un proyecto

10. Corrientes principales
• Arquitectura estructural – SEI – Carnegie Mellon
• Garlan, Shaw, Clements
• Variantes con modelos de datos (Medvidovic), radicales, formales (Moriconi-SRI), etc
• Arquitectura como etapa de la ingeniería de software orientada a objetos
• James Rumbaugh, Grady Booch, Ivar Jacobson (“los 3…”), Craig Larman…
• Arquitectura basada en patrones – SEI
• Redefinición de estilos como patrones POSA
• Microsoft Patterns & Practices
• Arquitectura procesual y metodologías
• Kazman, Bass (SEI)
• Variantes de arquitectura basada en escenarios

11. Estilos Arquitectónicos
 Rumbaugh & al 1991
• (1) transformaciones en lote, (2) transformaciones
continuas, (3) interfaz interactiva, (4) simulación dinámica de
objetos del mundo real, (5) sistemas de tiempo real, (6)
administrador de transacciones con almacenamiento y
actualización de datos
• Pero: “estilos arquitectónicos”, “arquitecturas comunes”,
“marcos de referencia arquitectónicos prototípicos”, “formas
comunes”, “clases de sistemas”

12. Estilos – Nueva concepción
• Perry & Wolf, 1992
• Componentes (ahora: Elementos)
• Conectores
• Configuraciones
• Restricciones (Constraints)
• “Mano mágica” (Fielding, 2000)
UML?

13. Estilos Arquitectónicos
•Estilos de Flujo de Datos
• Tubería y filtros
•Estilos Centrados en Datos
• Arquitecturas de Pizarra o Repositorio
•Estilos de Llamada y Retorno
• Model-View-Controller (MVC)
• Arquitecturas en Capas
• Arquitecturas Orientadas a Objetos
• Arquitecturas Basadas en Componentes
•Estilos de Código Móvil
• Arquitectura de Máquinas
Virtuales
•Estilos heterogéneos
• Sistemas de control de procesos
• Arquitecturas Basadas en Atributos
•Estilos Peer-to-Peer
• Arquitecturas Basadas en Eventos
• Arquitecturas Orientadas a
Servicios
• Arquitecturas Basadas en Recursos

14. Estilos derivados
• C2
• GenVoca
• REST

15. Estilos
• Sirven para sintetizar estructuras de soluciones
• Pocos estilos abstractos encapsulan una enorme variedad de
configuraciones concretas
• Definen los patrones posibles de las aplicaciones
• Permiten evaluar arquitecturas alternativas con ventajas y
desventajas conocidas ante diferentes conjuntos de requerimientos
no funcionales

16. Ejemplo
• Mala práctica:
• Aplicaciones clientes que consultan si sucedió algo
• Listener de HTTP, Archivo, Colas
• Buena práctica:
• Estilo basado en Eventos

17. Ejemplo
Arquitectura basada en eventos
•Modelo de push a veces se vincula con patrón Observador (Observer pattern)

18. Arquitectura basada en eventos
• Ventajas
• Simplicidad
• Evolución: se pueden reemplazar componentes suscriptores
• Modularidad: una sola modalidad para eventos diversos
• Puede mejorar eficiencia, eliminando la necesidad de polling por ocurrencia de evento
• Desventajas
• Posibilidad de desborde
• Potencial imprevisión de escalabilidad
• Pobre comprensibilidad: Puede ser difícil prever qué pasará en respuesta a una acción
• No hay garantía del lado del publisher que el suscriptor responderá al evento
• No hay mucho soporte de recuperación en caso de falla parcial

19. Arquitectura basada en eventos
• Dos modelos de arquitectura e implementación
• Tightly coupled events (TCE, eventos fuertemente acoplados)
• P. ej. COM Connection Points.
• Requiere que ambos componentes estén corriendo simultáneamente. No hay forma de filtrar evento
(p. ej. cuando acción alcance cierto valor)
• Requiere conocer ambas interfaces específicas
• Losely coupled events (LCE, eventos débilmente acoplados)
• P. ej. COM+ Events
• Almacenamiento de eventos (COM+ Catalog)
• Referencia: MSDN Library – COM+ Technical Series: Losely coupled events

20. Arquitectura basada en eventos
• Permiten invocación implícita de una herramienta cuando otra herramienta produce un evento
• También se llama Invocación implícita
• Un componente anuncia un evento. Otros registran interés en ese tipo de evento. Cuando se produce,
el sistema (la “mano invisible”) lo comunica a los suscriptores.
• Algunos incluyen a MVC en esta clase
• Modelo Publish / Subscribe
• MS: Registración de Eventos COM+, eventos (listeners) de BizTalk Server, Notification Service de
SQL Server

21. Arquitectura basada en eventos
• Herramientas en ambiente COM+/.NET
• En muchos casos no se requiere programación de bajo nivel
• También hay profusión de herramientas programáticas y servicios de
“mano mágica”
• Administrative tools
• Component Services
• COM+ Applications
• .NET Utilities, Biztalk Server/Interchange

22. Patterns
 Christopher Alexander, 1977
 Un patrón es una solución a un problema en un
contexto
 Un patrón codifica conocimiento específico
acumulado por la experiencia en un dominio
 Un sistema bien estructurado está lleno de patrones

23. Patterns - Alexander
 “Cada patrón describe un problema que ocurre una y
otra vez en nuestro ambiente, y luego describe el
núcleo de la solución a ese problema, de tal manera
que puedes usar esa solución un millón de veces
más, sin hacer jamás la misma cosa dos veces.”
 Ejemplos: galería, paseo, patio compartido,
columnata, estacionamiento

24. Elementos de un patrón
 Nombre
• Define un vocabulario de diseño
• Facilita abstracción
 Problema
• Describe cuando aplicar el patrón
• Conjunto de fuerzas: objetivos y restricciones
• Prerrequisitos
 Solución
• Elementos que constituyen el diseño (template)
• Forma canónica para resolver fuerzas
 Consecuencias
• Resultados, extensiones y tradeoffs

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

26. Organización de Patrones
• Propuesta por MS para Enterprise Solution Patterns Using Microsoft .NET (ESP)
• Propósito:
• Identificar relaciones entre patrones
• Agrupar patrones en clusters
• Identificar patrones a diversos niveles de abstracción
• Aplicar patrones a múltiples aspectos de una solución
• Organizar patrones en un frame
• Usar patrones para describir en forma concisa una solución…

27. Ejemplos de ESP
Niveles de abstracción
Vistas
Frame

28. Requerimientos no funcionales
Escenarios, tácticas, frameworks
 Performance
 Disponibilidad
 Modificabilidad
 Seguridad
 Verificabilidad (Testability)
 Gestionabilidad (instrumentación, management, estado)
 Usabilidad

29. Atributos de Calidad

30. Escenarios
 Estímulo, ambiente, respuesta
 Escenario de caso de uso:
• Un usuario remoto de web requiere un reporte de base de datos en hora
pico y lo recibe dentro de los 5 segundos.
 Escenario de crecimiento:
• Agregar un nuevo servidor de base de datos para reducir latencia en
escenario 1 a 2.5 segundos dentro de una persona-semana.
 Escenario exploratorio:
• La mitad de los servidores se bajará durante operación normal sin afectar la
disponibilidad del sistema.

31. Ejemplo de metodología
Refinamiento de Escenario
 Los escenarios se refinan considerando:
• 1. Estímulo - La condición que afecta al sistema
• 2. Respuesta - La actividad que resulta del estímulo
• 3. Fuente del estímulo - La entidad que lo genera
• 4. Ambiente - La condición bajo la cual el estímulo ocurre
• 5. Artefacto estimulado
• 6. Medida de respuesta - Para evaluar la respuesta del sistema
 Se describen los objetivos de negocio/misión afectados por el escenario y las
cualidades relevantes asociadas con él
 En funcíón de los escenarios se pueden evaluar los estilos arquitectónicos que
pueden satisfacer los requerimientos

32. Lenguajes de Descripción Arquitectónica
(ADLs)
 Componentes
 Conectores
 Configuraciones o sistemas
 Propiedades no funcionales
 Restricciones
 Estilos
 Evolución
 Herramientas de verificación

33. Métodos basados en Arquitectura
 Architecture Tradeoff Analysis Method (ATAM)
 Quality Attribute Workshops (QAW)
 Attribute-Driven Design (ADD)
 Active Reviews for Intermediate Designs (ARID)
 Cost-Benefit Analysis Method (CBAM)
 Software Architecture Comparison Analysis Method (SACAM)
 Quality-Attribute-Driven Software Architecture Reconstruction
(QADSAR)
 Architecture Based Design Method (ABD)
 Software Architecture Analysis Method (SAAM)

34. Usos de estilos
•Mary Shaw, David Garlan, 1996
• IEEE98SA-Styles-Patterns.pdf
• Inspirado en trabajo de Parnas, 1972 (“On the criteria to be used in decomposing
systems into modules”) – Datos compartidos vs ocultamiento de información
•Sistema de indexación de palabras claves
• Datos compartidos
• Tipos abstractos de datos
• Invocación implícita
• Tubería y filtros
•Comparación de versatilidad, dependencia, modularidad, reutilización,
refinamiento, ventajas & desventajas
•Antes de escribir una línea de código
•Tablas de comparación de
atributos
•Asignación de pesos a prioridades

35. Gracias
Somos UTM