Arquitectura de Software Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María

Presentación • Instructor – Hernán Astudillo – Ingeniero Informático & PhD Computer Science – Profesor UTFSM, Of. F-118

• Horario & materiales

– Mi 3-4, C-327 – Adicional: sitio Web del curso regular • www.inf.utfsm.cl/~hernan/

Sesión 01

Arquitectura de Software H.Astudillo

2

1

•

Ejemplo motivacional: i-Banco Casero Problema (conocido) – operaciones bancarias desde la casa – vía internet (Web)

Sesión 01

Arquitectura de Software H.Astudillo

3

Fase 0 – Análisis • Solución simple – – – – – –

Sesión 01

cliente: browser Web servidor: scripts CGI (programas invocados según URL) comunicación vía HTTP seguridad: usuario y contraseña, vía formas HTML auditable: bitácora (“logs”) datos: BD detrás del servidor Web

Arquitectura de Software H.Astudillo

4

2

Fase 0 – Problema • Problema tecnológico – operaciones transaccionales (atómicas pero compuestas) – ...pero HTTP es “stateless”: cada invocación parte de cero

• Solución – ‘Sesiones’: pasar estado, o guardar estado y pasar clave; ambos casos pueden usar URL, forma, cookie...

Sesión 01

Arquitectura de Software H.Astudillo

5

Fase 0 – Encuesta • Estimaciones – número de clases – esfuerzo de construcción

Sesión 01

Arquitectura de Software H.Astudillo

6

3

Fase 1: masificación • Problema (conocido) – El sistema se vuelve popular – Muchos usuarios

• Problemas sistémicos – lento e inestable

• CGI levanta procesos -> memoria y velocidad

– colisiones en bitácoras y datos • problemas de concurrencia

– difícil de monitorear

Sesión 01

Arquitectura de Software H.Astudillo

7

Fase 1 – Análisis • Soluciones (complementarias) – – – –

Sesión 01

procesos residentes en memoria (por sesión) control de concurrencia (pesimista, probablemente) monitoreo dinámico y global replicación de servidores (balanceo de carga)

Arquitectura de Software H.Astudillo

8

4

Fase 1 – Encuesta • Estimaciones – número de clases – esfuerzo de construcción

Sesión 01

Arquitectura de Software H.Astudillo

9

Fase 2: PyMEs / sucursales • Problema (conocido) – El sistema se expande a usuarios corporativos

• Se recibe depósitos del empleador a empleados

– El sistema atrae usuarios internos

• Usuarios conectados vía intranet, rápida, segura, con plataforma uniforme • Problemas de responsabilidad y acceso

Sesión 01

Arquitectura de Software H.Astudillo

10

5

Fase 2 – Análisis • Notas – usuarios: personas y organizaciones (con representantes) – seguridad: separar autenticación y autorización • autenticación: certificados (extranet) y login (intranet) • autorización: modelo de ‘apoderado’(s) por empresa

• Problema

– aspectos especializados del dominio requieren modelos más ricos – estos modelos requieren administración (como parte del sistema)

• Soluciones – autorización

• modelo: roles y derechos • implantación: directorios centralizados (‘manejo de identidad’)

Sesión 01

Arquitectura de Software H.Astudillo

11

Fase 2 – Encuesta • Estimaciones (usando una arquitectura pre-empaquetada) – número de clases – esfuerzo de construcción

Sesión 01

Arquitectura de Software H.Astudillo

12

6

Fase 3: integración • Problema (grande al fin) – El banco decide incorporar pago de cuentas y transferencias • Por usuarios individuales y/o corporativos

– Transacciones con efectos en terceros

• No-repudiables • Mal uso puede afectar al banco, no sólo a los usuarios

– Conexión con sistemas legado

• Antiguos, pero funcionando (y bien) • Plataformas heterogéneas

Sesión 01

Arquitectura de Software H.Astudillo

13

Fase 3 – Solución •

(modelar in situ)

Sesión 01

Arquitectura de Software H.Astudillo

14

7

Fase 3 – Notas • Problemas de ‘integración’ – – – –

integridad de datos: transacciones coordinadas y/o distribuidas compatibilidad de formatos, plataformas, protocolos... disponibilidad: tolerancia a fallas en general: sistemas y políticas heterogéneos

• Posibles soluciones – – – – –

Sesión 01

construcción ad-hoc (p.ej. ‘heartbeat’, ‘logs’...) servicios Web (XML, SOAP, UDDI...) ‘message brokers’: mensajes+filas confiables (ej: IBM MQ) sistema operativo (o BD) distribuido (p.ej. Oracle) combinación de elementos y/o productos

Arquitectura de Software H.Astudillo

15

Tema: descripción de arquitecturas • Notaciones similares a diseño (p.ej. UML, ‘4+1’) • También existen notaciones formales (ADLs)

– Vistas del sistema a construir • Vistas estáticas (clases, asociaciones, capas...) • Vistas dinámicas (estados, secuencia, colaboración...) • Vistas funcionales (casos de uso, interfaces...)

– Vistas del proceso a seguir

• Subsistemas y componentes (unidades de trabajo) • Dependencias entre unidades (para planificar; Gantt/Pert...)

• Vistas son definidas por tipo de ‘lector’

– ¿Quién lee especificaciones de arquitectura? • Mejor dicho, ¿a quién le importa lo que hace el arquitecto?

– ‘Stakeholders’: los afectados (lectores y evaluadores)

Sesión 01

Arquitectura de Software H.Astudillo

16

8

Tema: problemas “sistémicos” • Mayor escala provoca problemas sistémicos

– Rendimiento, disponibilidad (estabilidad), confiabilidad... – No puede identificarse un lugar específico ‘culpable’ – No son defectos de programación, sino malas decisiones sobre protocolos, políticas de replicación, concurrencia...

• Impacto de requisitos

– El arquitecto privilegia las propiedades sistémicas por sobre la “funcionalidad” (tareas) – En general, con sistemas grandes es más difícil satisfacer las propiedades de ejecución que ejecutar la tarea misma – Errores de arquitectura (o diseño) son caros

• Foco del arquitecto

– requisitos sistémicos (descripción y solución)

Sesión 01

Arquitectura de Software H.Astudillo

17

Tema: arquitecturas sistematizadas • Problemas recurrentes, usualmente coexistentes • Pre-empaquetar tecnologías

– sesiones, control de concurrencia, monitoreo...

• ‘Arquitecturas de línea de productos’

– factorización y reuso intra-organización

• ‘Arquitecturas de referencia’ para aplicaciones – ‘Servlets’: objetos-procesos (esquema MVC) – ASP (Active Server Pages):

• ‘Arquitecturas de referencia’ – CORBA (objetos distribuidos heterogéneos; casi S.O.) – RM-ODP (Open Distributed Processing-Reference Model)

Sesión 01

Arquitectura de Software H.Astudillo

18

9

Generando arquitecturas • Generación de arquitecturas alternativas – identificar políticas (propiedades de alto nivel) – determinar combinaciones de mecanismos suficientes

• Dimensiones y valores (+/- ortogonales) – integridad: vía transacciones

• semánticas: nivel de serialización, anidamiento, sagas... • concurrencia: lock, timestamp, file system, BD...

– tolerancia a falla: vía replicación

• del sistema: redundancia activa, ‘failover’ (master)... • del estado: propagado dinámicamente, periódicamente, ‘cacheado’...

– comunicación: vía enlaces (modo, medio, formato, meta...)

• modo: push, pull... • medio: punto-punto/multicast/broadcast, síncrona/asíncrona, mensajes vs. ‘streams’...

Sesión 01

Arquitectura de Software H.Astudillo

19

Evaluando arquitecturas • Implantando arquitecturas

– Solución H0: programar (flexible/ameno vs. costo/tiempo) – Tecnologías con capacidades suficientes (J2EE, .NET...) – Productos: comercial vs. Open Source (riesgo vs. costo)

• Problema

– Evaluar arquitecturas & comparar alternativas

• ¿Qué significa ‘mejor’?

– Criterios de optimalidad: efectividad, costo, simplicidad, futura integración o crecimiento, marketing... – Sólo los ‘stakeholders’ pueden realmente escoger (no son decisiones técnicas) – Una buena arquitectura es una buena descripción de una buena solución • “buena”: responde las preguntas de los ‘stakeholders’

Sesión 01

Arquitectura de Software H.Astudillo

20

10

Reflexión • ¿Qué hemos hecho? • Introducción paulatina de fuentes de complejidad – – – –

Madurez tecnológica Escala (tamaño) Complejidad del dominio Heterogeneidad

– – – –

Descripción de arquitecturas Problemas sistémicos Arquitecturas sistematizadas Evaluación y comparación

• Introducción paulatina de temas de arquitectura

• Enfoque a vuelo de pájaro

– Sin notación detallada – Sin detalles técnicos (de problemas ni soluciones)

Sesión 01

Arquitectura de Software H.Astudillo

21

“Arquitectura de Software”

11

La disciplina • Origen histórico de la disciplina – Percepción creciente que problemas de diseño “en grande” son cualitativamente diferentes – Énfasis en diseñar para lograr propiedades más que para tener funciones – Shaw+Garlan (1996): referencia estándar • • • •

Sesión 01

(Aunque hay publicaciones anteriores con nombres similares) Identificaron “estilos de arquitectura” Privilegiaron medir y comparar por sobre meramente hacer Tradición continúa en el SEI (CMU)

Arquitectura de Software H.Astudillo

23

¿Pero porqué “arquitectura”? • ¿Porqué “arquitectura” de software? – Analogía clave: arquitectos, ingenieros y constructores

• Diversos profesionales (y perfiles), pero complementarios y parte de un equipo • Roles complementarios: determinar tipo de construcción vs. elaborar plano eléctrico vs. alzar muros

• La arquitectura de software no es sobre “objetos” ni “pantallas” ni “funciones” – Mayor granularidad y mayor abstracción – Se habla de componentes y propiedades

• Propósito y audiencia: – ...no es sobre cómo hacer software – ...sino sobre qué software hacer (o reusar o comprar)

Sesión 01

Arquitectura de Software H.Astudillo

24

12

Arquitecto de Software – misión • Tarea del arquitecto – Con una descripción de tareas y propiedades sistémicas… – …especificar una solución en términos de componentes – ...supervisar el proceso de construcción (“Guardián de la visión”)

• La descripción responde las preguntas de los ‘stakeholders’ – Permite evaluar a priori el sistema a ser construido – Sirve como ‘guía de acción’ a los constructores – .Permite elaborar un plan de construcción

• Propósito:

– Permitir razonar sobre el sistema y sobre el proceso

Sesión 01

Arquitectura de Software H.Astudillo

25

Arquitectura, diseño, programación • Contraste de escala y propósito – Arquitectura: determinar qué software hay que hacer (o comprar o reutilizar) – Diseño: determinar cómo hacerlo – OBS.: • Estas son tareas (roles), no excluyentes • No hay un límite duro entre ambas cosas

• Arquitectura vs. programar (especificar una computación) – Arquitectura es sobre problemas y propiedades sistémicos

• En general, al construir grandes sistemas es más difícil satisfacer las propiedades de la ejecución que ejecutar la tarea • La descripción de la ‘funcionalidad’ (tareas) tiene menos importancia relativa

– Errores de arquitectura (o diseño) son prácticamente incurables

Sesión 01

Arquitectura de Software H.Astudillo

26

13

Razones • Razones para pensar en arquitectura – Software es difícil de mantener

• Cambios tienen muchas ramificaciones

– Necesidad de integrar aplicaciones

• Sistemas compuestos de aplicaciones • Cambios en estructura organizacional impactan el sistema

– Cambios en representación de información – Cambios en tecnología

Sesión 01

Arquitectura de Software H.Astudillo

27

Usos • Medio de educación: para entrenar gente • Comunicación entre stakeholders: incluyendo futuros arquitectos • Base para analizar el sistema: rendimiento, seguridad, usabilidad, disponibilidad, modificabilidad...

Sesión 01

Arquitectura de Software H.Astudillo

28

14

¿De qué hablan los arquitectos? • Postura #1: arquitectos de grandes sistemas de SW ‘piensan’ en macro-componentes – Capas (‘layers’) – Procesos y ‘pipes’ – Clientes y servidores

• Postura 2: ‘piensan’ en políticas y mecanismos – Tolerancia a fallas, rendimiento … – Replicación --> ‘failover’, balanceo de carga …

• Tenemos 2 vocabularios con focos complementarios: – Estructura: componentes y conectores – Propiedades: políticas y mecanismos

Sesión 01

Arquitectura de Software H.Astudillo

29

Definiciones más formales [1/2] • IEEE 1471

– ‘Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.’

• IEEE 1471

– An architecture is the highest-level concept of a system in its environment – highest level = essential, unifying concepts and principles – system = application, system, platform, system-of systems, enterprise, product line, ... – environment = development, operational, programmatic, context – Implication: Every System has an Architecture

Sesión 01

Arquitectura de Software H.Astudillo

30

15

Definiciones más formales [2/2] •

Alan Cooper –

•

‘Architects synthesize people, technology and purpose, [to] create a vision of a solution.’

Perry+Wolfe (via Boehm) – –

Sesión 01

SW Arch. = {Elements, Forms, Rationale/Constraints} Software architecture deals with the design and implementation of the high-level structure of software, by assembling architectural elements in well-chosen forms to satisfy functional and non-functional requirements (e.g. performance, reliability, scalability, portability, availability)

Arquitectura de Software H.Astudillo

31

Arquitectura y proceso

16

Tipos de requisitos [1] • Los tipos son conocidos; corresponden a: – fuentes diferentes – modos de relevar diferentes – naturaleza diferente

Sesión 01

Arquitectura de Software H.Astudillo

33

Tipos de requisitos [2] • Funcionales: tareas especificas permitidas por el sistema – Qué: “El sistema debe permitir hacer X” – Quién: El analista (casos de uso, modelos de dominio...)

• Propiedades (no funcionales): garantías sistémicas de operación del sistema

– Qué: Rendimiento, confiabilidad, disponibilidad... (“ilities”) – Quién: Informales(!); muchas veces suplidas por el arquitecto

• Restricciones al sistema: limitaciones a posibles soluciones – Qué: Decisiones a priori que restringen las soluciones válidas – Quién: Jefes de proyecto más que analistas (!)

Sesión 01

Arquitectura de Software H.Astudillo

34

17

Requisitos - resumen • Resumiendo – 3 tipos

• Funciones • Propiedades • Restricciones

– Confirmar que los 3 tipos sean documentados • O al menos entendidos

Sesión 01

Arquitectura de Software H.Astudillo

35

Audiencia del arquitecto [1] • ¿A quién le importa lo que el arquitecto hace? – ‘Stakeholders’ – Implicados; ‘los que tienen algo en juego’ • los “afectados” por la calidad de lo que hace el arquitecto

• Stakeholders usuales

– Analista (representa al cliente) – Implantador (programador y/o diseñador de sub-partes)

Sesión 01

Arquitectura de Software H.Astudillo

36

18

Stakeholders (simple) analista s pe cs arquitecto

ra etu uit arq

implantador

Sesión 01

Arquitectura de Software H.Astudillo

37

Audiencia [2] • Stakeholders usuales – Analista (representa al cliente) – Implantador (programador y/o diseñador de sub-partes)

• Stakeholders adicionales – – – –

Sesión 01

Arquitecto revisor y/o de otros sistemas QA y/o integradores Jefe de proyecto Administrador del sistema

Arquitectura de Software H.Astudillo

38

19

Stakeholders analista

sp ec s

arquitecto arquitetura ra etu uit arq

ar qu ite tu ra

revisor

jefe de projeto

implantador

sis tem a

QA

Sesión 01

Arquitectura de Software H.Astudillo

sis tem a

admin

39

Calidad según los stakeholders • La solución debe... – – – –

Satisfacer los requisitos (analistas) Ser ‘construible’ (programadores & diseñadores) Ser testable (QA) Ser administrable (administradores)

• La descripción de la solución debe... – Ser evaluable (otros arquitectos)

• El proceso de construcción debe... – Ser manejable (jefe de proyecto)

Sesión 01

Arquitectura de Software H.Astudillo

40

20

¿“Evaluable”? ¿“Manejable”? • Solución evaluable... – Debe permitir evaluar compromisos y opciones

• Por lo tanto, debe tener rastreabilidad entre las partes de la solución y del problema

• Proceso manejable... – Debe ser particionada e indicar dependencias

• Particiones: unidades naturales de asignación de trabajo • Dependencias: la base para definir calendario

• Solución debe satisfacer requisitos

– ¿Obvio? Not really; debe convencer al analista

Sesión 01

Arquitectura de Software H.Astudillo

41

Stakeholders – resumen • El arquitecto debe... – Describir un sistema a ser construido – Hacer una descripción útil para sus stakeholders – Permitir derivar un proceso para construirlo

• Una arquitectura debe ser más que una lista de productos – Y más que un mero modelo de componentes (!)

Sesión 01

Arquitectura de Software H.Astudillo

42

21

Referencias [1/2] •

[Bass/Clements/Kazman 2003]

•

[Shaw/Garlan 1996]

•

[Hohmann 2003]

•

[Whitehead 2002]

– Len Bass, Paul Clements, Rick Kazman – Software Architecture in Practice (2nd Ed.) – Addison Wesley (2003) – Mary Shaw, David Garlan – Software Architecture. Perspectives on an Emerging Discipline – Prentice Hall (1996) – Luke Hohmann – Beyond Software Architecture: Creating and Sustaining Winning Solutions – Addison Wesley (2003) – Katharine Whitehead – Component-Based Development: Principles and Planning for Business Systems – Addison Wesley (2002)

Sesión 01

Arquitectura de Software H.Astudillo

43

Referencias [2/2] • [Astudillo/Hammer 1998]

– Hernán Astudillo, Stuart Hammer – Understanding the Architect’s Job – Software Architecture Workshop of OOPSLA’98 (1998)

• [Szyperski 1998]

– Clemens Szyperski – Component Software: Beyond Object-Oriented Programming – Addison Wesley (1998)

•

[Jacobson/Griss/Jonsson 1997]

•

[Kruchten 2000]

– – –

Ivar Jacobson, Martin Griss , Patrik Jonsson Software Reuse: Architecture, Process and Organization for Business Success Addison Wesley (1997)

– – – –

Philippe Kruchten The Rational Unified Process: An Introduction (2nd Ed.) Addison Wesley (2000) www.rational.com/whitepapers/

Sesión 01

Arquitectura de Software H.Astudillo

44

22

Recursos • “Software Architecture” – Software Engineering Institute (SEI), Carnegie-Mellon University – www.sei.cmu.edu/ata/

• “Software Architecture Papers”

– Software Engineering Research Laboratory (SERL), University of Colorado – www.cs.colorado.edu/users/serl/arch/papers.html

Sesión 01

Arquitectura de Software H.Astudillo

45

23