Arquitectura de Software - Departamento de Informática...

1

Arquitectura de Software

Hernán AstudilloDepartamento de Informática

Universidad Técnica Federico Santa María<hernan at acm.org>

Sesión 01 Arquitectura de Software -H.Astudillo

2

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/

2


3

Ejemplo motivacional: i-Banco Casero• Problema (conocido)

– operaciones bancarias desde la casa

– vía internet (Web)


4

Fase 0 – Análisis• Solución simple

– 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

3


5

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


6

Fase 0 – Encuesta• Estimaciones

– número de clases– esfuerzo de construcción

4


7

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


8

Fase 1 – Análisis• Soluciones (complementarias)

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

5


9

Fase 1 – Encuesta• Estimaciones



10

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

6


11

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’)


12

Fase 2 – Encuesta• Estimaciones (usando una arquitectura pre-empaquetada)


7


13

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


14

Fase 3 – Solución• (modelar in situ)

8


15

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– 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


16

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)

9


17

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)


18

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)

10


19

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


20

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’

11


21

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

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

• Introducción paulatina de temas de arquitectura– Descripción de arquitecturas– Problemas sistémicos– Arquitecturas sistematizadas– Evaluación y comparación

• Enfoque a vuelo de pájaro– Sin notación detallada– Sin detalles técnicos (de problemas ni soluciones)

“Arquitectura de Software”

12


23

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• (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)


24

¿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)

13


25

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


26

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

14


27

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


28

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

15


29

¿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


30

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

16


31

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)– 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 y proceso

17


33

Tipos de requisitos [1]• Los tipos son conocidos; corresponden a:

– fuentes diferentes– modos de relevar diferentes– naturaleza diferente


34

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 (!)

18


35

Requisitos - resumen• Resumiendo

– 3 tipos• Funciones• Propiedades• Restricciones

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


36

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)

19


37

Stakeholders (simple)

arquitecto

specs

implantador

analista

arquitetura


38

Audiencia [2]• Stakeholders usuales

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

• Stakeholders adicionales– Arquitecto revisor y/o de otros sistemas– QA y/o integradores– Jefe de proyecto– Administrador del sistema

20


39

Stakeholders

arquitecto

revisor

specs

sistema

implantador

arquitetura

QA

analista

arquitetura

admin

sistema

arquit

etura

jefe deprojeto


40

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)

21


41

¿“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


42

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 (!)

22


43

Referencias [1/2]• [Bass/Clements/Kazman 2003]

– Len Bass, Paul Clements, Rick Kazman– Software Architecture in Practice (2nd Ed.)– Addison Wesley (2003)

• [Shaw/Garlan 1996]– Mary Shaw, David Garlan– Software Architecture. Perspectives on an Emerging Discipline– Prentice Hall (1996)

• [Hohmann 2003]– Luke Hohmann– Beyond Software Architecture: Creating and Sustaining Winning

Solutions– Addison Wesley (2003)

• [Whitehead 2002]– Katharine Whitehead– Component-Based Development: Principles and Planning for Business

Systems– Addison Wesley (2002)


44

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]– Ivar Jacobson, Martin Griss , Patrik Jonsson– Software Reuse: Architecture, Process and Organization for Business Success– Addison Wesley (1997)

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

23


45

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

Arquitectura de Software - Departamento de Informática...

Documents

Transcript of Arquitectura de Software - Departamento de Informática...