Arquitectura de Software V: Prácticas - inf.utfsm.clhernan/cursos/MII414-2004s2/bitacora/... · 2 Sesión 05 Arquitectura de Software - H.Astudillo 3 V: Prácticas de arquitectura

1

Arquitectura de SoftwareV: Prácticas

Hernán AstudilloDepartamento de Informática

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

Sesión 05 Arquitectura de Software -H.Astudillo

2

Contenido del curso– 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

PPPP

2


3

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

Políticas y mecanismos

3


5

Políticas y mecanismos• Idea:

– identificar y separar “dimensiones”• Fundamento teórico

– Diferentes niveles de abstracción– Ejecutar (“realize”) políticas con mecanismos disponibles


6

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”

4


7

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


8

e-mail: Sincronía [2/2]• Interesante: al refinar versión Internet...

– TCP/IP “realizado” por paquetes asíncronos

5


9

e-Mail: Entrega [1/2]• Modelo informal

– usos:• “push”: entrega cuando el enviador quiere• “pull”: entrega cuando el receptor quiere

receiversender

push

pull

toma

me de


10

e-Mail: Entrega [2/2]• Modelo UML

– (hacer in situ)

6


11

e-mail: Topología [1/2]• Modelo informal

– “multicast” vs. “broadcast”– (1:M especificados) vs. (1:todos en la red)


12

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)

7


13

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»

Componentes y organizaciones

8


15

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


16

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

– Dominio (entidades, propiedades...)– Interfaces– Capas de abstracción (“máquinas virtuales”)– Instanciaciones de arquetipos

9


17

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


18

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)

10


19

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


20

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

11


21

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


22

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

12

Terminología de mercado


24

“2 Capas”• 2 capas: “cliente-servidor”• Razón: concentrar recursos escasos en servidores

centralizados– Redundancia mínima– Rendimiento puede sufrir– Autonomía mínima

13


25

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


26

“4 capas”

14


27

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


28

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

15


29

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


30

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

16


31

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


32

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

17

Estandarización


34

Estandarización• Vasta cantidad de STLs

– OMG– OMA-RM– MDA– ECA

18


35

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”


36

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

19


37

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)


38

Modelado OMG• Técnicas para desarrollar aplicaciones

– MOF: “Meta-Object Facility”– UML: “Unified Modeling Language”– MDA: “Model-Driven Architecture”

20


39

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


40

MDA [2]• Idea: a partir de modelos abstractos, refinar a modelos

concretos usando meta -modelos• PM: “Platform Model”

– permite refinar PIM a PSM

21


41

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

La profesión

22


43

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


44

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

23


45

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)


46

*** Teatro Japonés ***• “leer” una performance

– sintaxis: gestos– razones: historia detrás

• criticar• hacer• reflexionar

24


47

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)


48

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

25

Enseñando Arquitectura de Software


50

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

26


51

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?


52

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

27


53

Formatos – modelos para cursos• Relajando restricciones: modelos posibles

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

• Posibles extensiones– 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)

Conclusión

28


55

¿Un modelo o un diagrama?


56

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☺

29


57

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)

Documents

Arquitectura de Software V: Prácticas - inf.utfsm.clhernan/cursos/MII414-2004s2/bitacora/... · 2 Sesión 05 Arquitectura de Software - H.Astudillo 3 V: Prácticas de arquitectura