Upload
haphuc
View
217
Download
1
Embed Size (px)
Citation preview
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
Sesión 01 Arquitectura de Software -H.Astudillo
3
Ejemplo motivacional: i-Banco Casero• Problema (conocido)
– operaciones bancarias desde la casa
– vía internet (Web)
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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...
Sesión 01 Arquitectura de Software -H.Astudillo
6
Fase 0 – Encuesta• Estimaciones
– número de clases– esfuerzo de construcción
4
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
9
Fase 1 – Encuesta• Estimaciones
– número de clases– esfuerzo de construcción
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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’)
Sesión 01 Arquitectura de Software -H.Astudillo
12
Fase 2 – Encuesta• Estimaciones (usando una arquitectura pre-empaquetada)
– número de clases– esfuerzo de construcción
7
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
14
Fase 3 – Solución• (modelar in situ)
8
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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)
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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’...
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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)
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
33
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
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
Sesión 01 Arquitectura de Software -H.Astudillo
35
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
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
Sesión 01 Arquitectura de Software -H.Astudillo
37
Stakeholders (simple)
arquitecto
specs
implantador
analista
arquitetura
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
39
Stakeholders
arquitecto
revisor
specs
sistema
implantador
arquitetura
QA
analista
arquitetura
admin
sistema
arquit
etura
jefe deprojeto
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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)
Sesión 01 Arquitectura de Software -H.Astudillo
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
Sesión 01 Arquitectura de Software -H.Astudillo
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