slides 03b [2pp], PDF, 71kb - Departamento de Informática

Arquitectura de Software
V: Prácticas
Hernán Astudillo
Departamento de Informática
Universidad Técnica Federico Santa María
<hernan at acm.org>
P
P
P
P
Contenido del curso
–
–
–
–
–
Sesión 05
Introducción, motivación y contexto
Representación de arquitecturas
Elaboración de arquitecturas
Principios y evaluación de arquitecturas
Prácticas de arquitectura
•
•
•
•
•
•
•
Políticas y Mecanismos
Re-visitando un ejemplo complejo
Componentes y Organizaciones
Terminología de Mercado
Estandarización
La profesión
Enseñando Arquitectura de Software
Arquitectura de Software H.Astudillo
2
1
V: Prácticas de arquitectura
• Políticas y mecanismos
•
•
•
•
•
•
Re-visitando un ejemplo complejo
Componentes y organizaciones
Terminología del mercado
Estandarización
La profesión
Enseñando Arquitectura de Software
Sesión 05
Arquitectura de Software H.Astudillo
3
Políticas y mecanismos
2
Políticas y mecanismos
• Idea:
– identificar y separar “dimensiones”
• Fundamento teórico
– Diferentes niveles de abstracción
– Ejecutar (“realize”) políticas con mecanismos disponibles
Sesión 05
Arquitectura de Software H.Astudillo
5
Ejemplo: e-mail
• Descripción del proceso:
– Escritor de correo prepara mensaje en cliente, y envía al lector,
quien lee el mensaje en su cliente de correo
– Implementación conocida por nosotros: vía Internet
– Modelo: caso de uso, diagrama de secuencia, etc.
• Nuestro interés: refinar el modelado de la comunicación
• Dimensiones de interés de la comunicación (en este ejemplo):
– Sincronía: sí ncrona vs. asíncrona
– Entrega: “push” vs. “pull”
– Topología: “broadcast” vs. “multicast”
Sesión 05
Arquitectura de Software H.Astudillo
6
3
e-mail: Sincronía [1/2]
• Modelo informal
– 2 personas – asíncronos – 2 clientes idem
– versión Internet:
• Clientes y servidores entre sí : TCP/IP síncrono
– versión con filas:
• Clientes y servidores entre sí son asíncronos
Sesión 05
Arquitectura de Software H.Astudillo
7
e-mail: Sincronía [2/2]
• Interesante: al refinar versión Internet...
– TCP/IP “realizado” por paquetes asíncronos
Sesión 05
Arquitectura de Software H.Astudillo
8
4
e-Mail: Entrega [1/2]
• Modelo informal
receiver
sender
push
toma
pull
me de
– usos:
• “push”: entrega cuando el enviador quiere
• “pull”: entrega cuando el receptor quiere
Sesión 05
Arquitectura de Software H.Astudillo
9
e-Mail: Entrega [2/2]
• Modelo UML
– (hacer in situ)
Sesión 05
Arquitectura de Software H.Astudillo
10
5
e-mail: Topología [1/2]
• Modelo informal
– “multicast” vs. “broadcast”
– (1:M especificados) vs. (1:todos en la red)
Sesión 05
Arquitectura de Software H.Astudillo
11
e-mail: Topología [2/2]
• Disonancia cognitiva
– “Multicast” puede ser implementado con “broadcast”
• Receptores que no debían escuchar ignoran el mensaje
• Requiere cambio en cada receptor
– “Broadcast” puede ser implementado con “multicast”
• Mantener catálogo de escuchadores
• Necesita cambio en cada receptor y catálogo
• Moraleja
– Mala opción inicial de política no impide buena solución
– Pero requiere trabajo adicional (tal vez sustancial)
Sesión 05
Arquitectura de Software H.Astudillo
12
6
Resumiendo
• Distinguir “políticas” y “mecanismos”
– roles en un proceso/descripcion de refinamiento
• Una solución que es mecanismo en un nivel de abstracción es
política en el nivel inferior
– (política y mecanismo son roles en una relación entre elementos
de diferentes niveles de abstracción)
• En general, una implementación puede ser documentada pero
no computada
– UML: «trace», «derive»
Sesión 05
Arquitectura de Software H.Astudillo
13
Componentes y organizaciones
7
Escalas de arquitectura
• Arquitectura de aplicaciones
– aplicación o sistema (colaboración de aplicaciones)
• Arquitectura de línea de productos
• “Framework” para un dominio
• Arquitectura de referencia
– definen vocabulario y permiten intercambio ínter-organizacional
– CORBA, .NET...
Sesión 05
Arquitectura de Software H.Astudillo
15
Componentes
• Componente [Whitehead]
– Pieza separable (independiente del contexto) de software
ejecutable
– ...que tiene sentido como unidad
– ...y puede interoperar con otros componentes
– ...dentro de un ambiente de apoyo
– ...y es accesable sólo vía sus interfaces
– ...y está listo para usar (posiblemente requiriendo instalación y
configuración)
• Fuentes de componentes
–
–
–
–
Sesión 05
Dominio (entidades, propiedades...)
Interfaces
Capas de abstracción (“máquinas virtuales”)
Instanciaciones de arquetipos
Arquitectura de Software H.Astudillo
16
8
Interoperabilidad
• Problema: cooperación entre componentes
– Número exponencial de pares
• Se complica al introducir más de una tecnología
• Mecanismos estandarizados para describir interfaces
– CORBA IDL
– COM IDL
– Interoperabilidad entre tecnologías
• “Modelos de componentes”
• COM, CORBA, EJB
• “Wrappers” (envoltorios)
– Servicios
• Propiedades transaccionales
• Manejo de seguridad
• Monitoreamiento
Sesión 05
Arquitectura de Software H.Astudillo
17
Modelos de componentes [1/3]
• Modelos de componentes distribuidos (clientes y servidores)
– COM: Common Object Model (Microsoft; en .NET)
– CORBA: Common ORB Architecture (OMG: Object Management
Group)
• ORB: Object Request Broker
– Java (Sun, JCP)
• Modelos extendidos para mejor apoyar servidores
– MTS (Microsoft Transaction Service)
– CCM (CORBA Component Model)
– EJB (Enterprise Java Beans)
• J2EE (Java 2 Enterprise Edition)
Sesión 05
Arquitectura de Software H.Astudillo
18
9
Modelos de componentes [2/3]
• Modelos extendidos con soporte adicional
–
–
–
–
Manejo transaccional
Seguridad
Persistencia
Disponibilidad
• “Clustering”, balanceo de carga
– Ambiente de ejecución
•
•
•
•
Ciclo de vida (instanciación, GC...)
“Threading”
“Pooling” de conexiones
Manejo de estado
– Monitoreamiento dinámico
Sesión 05
Arquitectura de Software H.Astudillo
19
Modelos de componentes [3/3]
• Servicios
– “Location” (ubicación)
• detección de componentes/servicios; análogo a guía telefónica
• JNDI (Java Naming & Directory Interface)
• CORBA Naming Service & Trading Service
– Manejo de transacciones
• autenticación, autorización, inviolabilidad, no-repudiación
• CORBA Security Service
• JAASL Java Authentication & Authorization Service
– Eventos, notificaciones & mensajería
• Mensajes asíncronos, point-to-point & publish-subscribe
• CORBA Notification (& Event) Services, Messaging Service
• JMS: Java Messaging Service
Sesión 05
Arquitectura de Software H.Astudillo
20
10
Organizaciones para arquitectura
• ¿Quién es responsable de hacer/gestionar arquitectura?
– Idea: asociar escalas de arquitectura a niveles de la
organización
• [Jacobson/Griss/Jonsson] 3 niveles:
– Empresa
– Departamento (unidad)
– Proyecto
• “Se delega autoridad, pero no responsabilidad”
– Estandarizar vía lenguaje compartido
• arquitectura de referencia
• patrones y estilos
Sesión 05
Arquitectura de Software H.Astudillo
21
Organizaciones para componentes
• Problema: propiedad y control de componentes
– Pueden no calzar con las unidades organizacionales
– Control de cambios
– Redundancia
• Soluciones
– Reestructurar la organización
– Imponer propiedad y/o factorización
– “Mercado interno” de componentes
• Decidir quién paga el costo de hacer casos generales
• Decidir quién paga cambios específicos
• Decidir modelo de propagación de cambios a los afectados
– Propiedad: unidades de negocio vs. centralizada
Sesión 05
Arquitectura de Software H.Astudillo
22
11
Terminología de mercado
“2 Capas”
• 2 capas: “cliente-servidor”
• Razón: concentrar recursos escasos en servidores
centralizados
– Redundancia mínima
– Rendimiento puede sufrir
– Autonomía mínima
Sesión 05
Arquitectura de Software H.Astudillo
24
12
“3 capas”
• 3 capas
– Razón: compartir datos, preservando integridad (ACID)
– “Negocio”: procesamiento propio del negocio
– 2 partes: objetos de negocio (entidades del dominio) y lógica de
control (funciones)
– “Presentación”: interacción con usuarios (incl. informes) y otros
sistemas
– “Datos”: manejo de datos persistentes (incl. integridad)
Sesión 05
Arquitectura de Software H.Astudillo
25
“4 capas”
Sesión 05
Arquitectura de Software H.Astudillo
26
13
“4 capas” (Cont.)
• “Usuario”: mecanismos de interacción con usuarios y otros
sistemas
• “Workspace”: manejo de sesiones y transacciones
• “Negocio” (empresa): procesos y entidades del negocio
• “Recursos”: elementos únicos compartidos (BD, sistemas
legado, servicios)
Sesión 05
Arquitectura de Software H.Astudillo
27
Productos
• Categorías de productos
– Empaquetados por tipo de problema y tipo de solución
• Tipos de solución: tecnologías
– “Middleware”
– MOM, BD, “directory servers”, TP Monitors, “workflow”...
• Tipos de problemas: servicios del negocio
– Paquetes
– ERP (Enterprise Resource Planning), CRM (Customer
Relationship management) y variaciones, Knowledge
Management...
Sesión 05
Arquitectura de Software H.Astudillo
28
14
Middleware
• “Middleware”: tecnologías para comunicar programas
distribuidos
• Britton propone clasificar middleware usando 8 aspectos de
la comunicación
–
–
–
–
–
–
–
–
Transporte (enlace) (ej: TCP/IP)
Protocolo (ej: HTTP)
API (ej: ODBC)
Formato (ej: ASCII)
Control de recursos en el servidor (ej: MTS)
Directorios/nombres (ej: DNS)
Seguridad (ej: Kerberos)
Administración
Sesión 05
Arquitectura de Software H.Astudillo
29
Middleware - Dimensiones
• Participantes en la comunicación
– programas/objetos cada vez más pequeños y numerosos
– IP (hardware), TCP (procesos), IIOP (objetos)
• Modo de comunicación
– sesiones: protocolos con o sin ellas
• TCP (IP con sesión), UDP (IP sin sesión)
– topología: 1:M, peer-to-peer, M:1
– iniciador: push, pull
– integridad vs. puntualidad (“timeliness”)
• Interfaz
– con API: número fijo de entradas
– con IDL: mecanismo para definir API ad-hoc
Sesión 05
Arquitectura de Software H.Astudillo
30
15
Servicios Web
• Integración usando infraestructura Web/Internet
• Aspectos
– Transporte
– Formato
– Búsqueda
• Soluciones empaquetadas (aún en desarrollo)
– “Web services”
• SOAP (Simple Object Access Protocol): HTTP + XML
• WSDL (Web Service Description Language)
• UDDI (Universal Description, Discovery and Integration)
– REST: Representational State Transfer
• HTTP + URL + XML/HTML/GIF/MIME/etc. (sin directorios)
– CORBA: IIOP + “marshalling” + Directory/Trader Service
Sesión 05
Arquitectura de Software H.Astudillo
31
Catálogos de arquitectura
• Catálogos
– Ingenieros tienen catálogos de partes disponibles
• con especificaciones de contexto, parámetros...
– Necesarios para centralizar y difundir información
• Fundamento teórico propuesto
– Clasificar Middleware
• Análisis de dimensiones aún pendiente
– Políticas y mecanismos
• Enfoque análogo
Sesión 05
Arquitectura de Software H.Astudillo
32
16
Estandarización
Estandarización
• Vasta cantidad de STLs
–
–
–
–
Sesión 05
OMG
OMA-RM
MDA
ECA
Arquitectura de Software H.Astudillo
34
17
OMG
• OMG: “Object Management Group”
– Consorcio industrial (600+ miembros)
• Propósitos:
– establecer guías para la industria
– crear especificaciones para administración de objetos
– proveer un marco común para desarrollar aplicaciones
• OMA: “Object Management Architecture”
– infraestructura conceptual para las especificaciones del OMG
• OMA-RM: “OMA Reference Model”
Sesión 05
Arquitectura de Software H.Astudillo
35
OMA-RM [1]
• ORB: “Object Request Broker”
– medio transparente para pedidos y respuestas en un ambiente
distribuido
– especificación: CORBA
– “Common ORB Architecture”
• Servicios de Objetos
– servicios (interfaces y objetos) con funciones básicas para
implementar objetos distribuidos
– especificación: CORBAservices
– ejemplos: Ciclo de Vida, Persistencia
Sesión 05
Arquitectura de Software H.Astudillo
36
18
OMA-RM [2]
• Facilidades Comunes
– servicios comunes pero no fundamentales
– especificación: CORBAfacilities
– ejemplos: administración, e-mail
• Objetos Aplicaciones
– aplicaciones (únicas por definición)
Sesión 05
Arquitectura de Software H.Astudillo
37
Modelado OMG
• Técnicas para desarrollar aplicaciones
– MOF: “Meta-Object Facility”
– UML: “Unified Modeling Language”
– MDA: “Model-Driven Architecture”
Sesión 05
Arquitectura de Software H.Astudillo
38
19
MDA [1]
• CIM: “Computing Independent Model”
– modelo de negocio
• PIM: “Platform Independent Model”
– arquitectura sin referencia a tecnología específica
• PSM: “Platform Specific Model”
– arquitectura en términos de una plataforma específica
– PM: “Platform Model”
• ISM: “Implementation Specific Model”
– arquitectura en términos de una implantación específica
Sesión 05
Arquitectura de Software H.Astudillo
39
MDA [2]
• Idea: a partir de modelos abstractos, refinar a modelos
concretos usando meta -modelos
• PM: “Platform Model”
– permite refinar PIM a PSM
Sesión 05
Arquitectura de Software H.Astudillo
40
20
ECA
• ECA: “Enterprise Collaboration Architecture”
– CCA: “Component Collaboration Architecture”
• consiste de “Process Components”
– Modelo de Entidades
– Modelo de Eventos
– Modelo de Proceso de Negocio
• especializa el CCA
Sesión 05
Arquitectura de Software H.Astudillo
41
La profesión
21
•
Otros sentidos de “arquitectura”
[1]
Por ámbito:
– “Enterprise Architecture”: visión y principios transversales en
la empresa
• p.ej. seguridad, flexibilidad, políticas de compra, reuso
– Arquitectura de Dominio: específica a un área
– Arquitectura de Línea de Productos: definiciones comunes a
productos (diseño y/o implementación)
– Arquitectura de Referencia: vocabulario (estilo y componentes)
para dominios de aplicación
Sesión 05
Arquitectura de Software H.Astudillo
43
Otros sentidos de “arquitectura” [2]
• Por tipo de preocupación:
– Arquitectura de Negocio: estrategias, organización y metas
para procesos de negocios
– Arquitectura de Aplicaciones: políticas para y soluciones de
software a problemas específicos
– Arquitectura Técnica (o Infraestructura): soluciones generales
y/o estandarizadas (redes, plataformas...)
– Arquitectura de Datos (o Información): almacenamiento y
manejo de información (propiedad, diseño, métodos...)
Sesión 05
Arquitectura de Software H.Astudillo
44
22
Metáforas y modelos
• Metáfora de arquitecto
– más adecuada: edificio, no casa
– justificar preguntas: así como el arquitecto del edificio puede
justificar sus preguntas, debemos poder justificar las nuestras
• Calidad de los modelos:
– casas: maquetas (modelos analógicos), levantamientos, planos...
– sistemas: vistas, diagramas...
• Apuesta de la disciplina: con el tiempo, nuestros modelos
mejorarán
– programa 1 de mejoramiento: ADLs
– programa 2: vistas
– (“programa” de investigación como en filosofía de la ciencia)
Sesión 05
Arquitectura de Software H.Astudillo
45
*** Teatro Japonés ***
• “leer” una performance
– sintaxis: gestos
– razones: historia detrás
• criticar
• hacer
• reflexionar
Sesión 05
Arquitectura de Software H.Astudillo
46
23
Técnicas del arquitecto [bis]
• Problema
– Elaboración concurrente de modelos para múltiples aspectos
• Técnicas clave
– Refinamiento
• Múltiples niveles de abstracción y completitud
– Descripción en capas
• Capas son modelos incompletos, pero comprensibles
– Refinamiento derivable
– “Refactoring” (factorización)
Sesión 05
•
Arquitectura de Software H.Astudillo
47
La gran “ility”: Rastreabilidad
[bis]
Noción fundamental de arquitectura
– Rastreabilidad: propiedad de un modelo que permite relacionar
una decisión con su justificación e implicaciones
– Permite estudiar impacto de cambios (forward) y razones para
acción propuesta (backward)
• Los modelos deben proveer información
– Refinamiento: explicado o aparente
– Niveles de abstracción : mapeables entre sí
• Una buena arquitectura “cuenta una historia”
– Explicar no sólo el que y como, sino el porqué
– Permite decisiones informadas a futuro
Sesión 05
Arquitectura de Software H.Astudillo
48
24
Enseñando Arquitectura de
Software
Analogías y educación
• Analogías desde la industria de construcción
– El arquitecto de software como arquitecto
– El diseñador o programador como constructor
• Analogías desde la industria cinematográfica
– El arquitecto del proyecto es el director de la película
– El jefe del proyecto es el productor de la película
• Formas de educación (y socialización)
– En estudios: como los abogados y los arquitectos
• Aprender mirando por encima del hombro
– En clínicas: como los médicos
• Aprender en equipo en modo crisis
– Pasiva: como los ingenieros
• Cursos teóricos, práctica post-graduación
Sesión 05
Arquitectura de Software H.Astudillo
50
25
Modelo docente
•
4 “niveles de competencia”
– Lectura de arquitecturas
• Poder usarlas como guía de acción
– Lectura crítica de arquitecturas
• Poder evaluarlas y modificarlas
– Elaboraci ón de arquitecturas
• Poder elaborar sistemas y descripciones de ellos
– Reflexión crítica sobre la disciplina
•
• Poder reflexionar más allá de lo operacional
• Ojo: no implica ser investigador
Formatos de entrega
– Secuencial vs. iterativo-incremental
• ¿Qué unidades usar?
Sesión 05
Arquitectura de Software H.Astudillo
51
Formato – modelo aplicado aquí
•
Estructura de esta charla
– Sólo los 3 primeros niveles
• conceptos superficiales (lectura no accionable )
– Entrega secuencial, sin iteraci ón
– Nivel de competencia impartido “bottom-up”
•
• ejemplos someros y recibidos, no elaborados
Algunas técnicas específicas
– “Problematizaci ón” inicial
• remover nociones previas, definir lo que no es arquitectura
– Uso de casos
•
• ejemplo seguido con complejidad incremental
• diálogo <flujo principal> -<”sidebars”> (introduciendo temas)
Restricciones clave
– tiempo: permitir reflexión
– dedicación: audiencia mixta
Sesión 05
Arquitectura de Software H.Astudillo
52
26
Formatos – modelos para cursos
•
Relajando restricciones: modelos posibles
•
Posibles extensiones
–
–
–
–
Casos: proyectos desarrollados en paralelo (entrelazados)
Modelo: “aprendiz” (como abogados, médicos, arquitectos)
Disyuntiva: formar arquitectos o investigadores
Casos límite: ¿cuánto tiempo y esfuerzo dedicar?
– Lectura crítica y elaboración: evaluaci ón y comparación
• soluciones alternativas de mercado a problema dado
– Reflexión: problemas aún abiertos
• derivación de arquitecturas desde requisitos sisté micos
• descripción de políticas, mecanismos, y realización
• relación derivación – capas (derivación aparente vs. real)
Sesión 05
Arquitectura de Software H.Astudillo
53
Conclusión
27
¿Un modelo o un diagrama?
Sesión 05
Arquitectura de Software H.Astudillo
55
Conclusión
• Reconocimiento reciente de la disciplina
– Dicotomía teoría-práctica
• Procesos, métodos y técnicas: aún madurando
– Arquitectos describen sistemas
– En forma que permita su evaluación a priori
– Y que permiten armar procesos para construirlos
• Rol fundamental:”stakeholders”
– Noción de calidad depende de ellos
• Las arquitecturas son medios
– (de comunicación y educación)
• El arquitecto es el director de la película
– Flor de laburo J
Sesión 05
Arquitectura de Software H.Astudillo
56
28
Referencias
• [Jacobson/Griss/Jonsson]
– Ivar Jacobson, Martin Griss, Patrik Jonsson
– Software Reuse: Architecture, Process and Organization for
Business Success
– Addison Wesley (1997)
• [Britton 2000]
– Chris Britton
– IT Architectures & Middleware: Strategies for Building Large,
Integrated Systems
– Addison Wesley (2000)
• [McLaughlin 2002]
– Brett McLaughlin
– Building Java Enterprise Applications, Vol. 1: Architecture
– O'Reilly (2002)
• [Sewell/Sewell 2001]
– Marc T. Sewell, Laura M. Sewell
– The Software Architect's Profession: An Introduction
– Prentice Hall (2001)
Sesión 05
Arquitectura de Software H.Astudillo
57
29