Programaci

1
Programación Orientada a Aspectos

• Da Silva Carlos 01-33752
• García Irene 01-33903
• Osers Pablo 01-34232
• Ovalle Luis 01-34236
• Zager Carlos 01-34562

Sistemas de Operación III
2
Definición de POA

• Fue presentada en público por Gregor Kickzales y
  su equipo de investigación de Palo Alto Research
  Center en 1996.
• Paradigma de programación relativamente reciente.
• De esta forma se consigue
• Razonar mejor sobre los conceptos.
• Eliminar la dispersión del código.
• Implementaciones resultan más comprensibles,
  adaptables y reusables.

3
Definición de Aspecto

• Un aspecto es una unidad modular que se
  disemina por la estructura de otras unidades
  funcionales. Los aspectos existen tanto en la
  etapa de diseño como en la de implementación. Un
  aspecto de diseño es unaunidad modular del diseño
  que se entremezcla en la estructura de otras
  partes del diseño. Un aspecto de programa o de
  código es una unidad modular del programa que
  aparece en otras unidades modulares del programa
  (G. Kiczales)

4
Definición de Aspecto

• Los aspectos son la unidad básica de la POA, y
  pueden definirse como las partes de una
  aplicación que describen las cuestiones claves
  relacionadas con la semántica esencial o el
  rendimiento.
• También pueden verse como los elementos que se
  diseminan por todo el código y que son difíciles
  de describir localmente con respecto a otros
  componentes.
• Ej. patrones de acceso a memoria, sincronización
  de procesos concurrentes, manejo de errores, etc.

5
Estructura de un Programa OA
6
Estructura de un Programa OA

• Se muestra un programa como un todo formado por
  un conjunto de aspectos más un modelo de objetos.
• Con el modelo de objetos se objetos se recoge la
  funcionalidad básica.
• Los aspectos recogen características de
  rendimiento y otras no relacionadas con la
  funcionalidad esencial del mismo.

7
Objetivos Fundamentales de la POA

• Extraer y centralizar en un solo punto los
  "crosscutting concepts ? cada decisión se toma
  en un lugar concreto y no diseminada por la
  aplicación.
• Minimizar las dependencias entre ellos ?
  desacoplar los distintos elementos que
  intervienen en un programa.

8
Objetivos Fundamentales de la POA

• Idea principal es centralizar en un solo punto
  todos los aspectos comunes a las clases que
  forman el sistema software.

Figura 1. Evolución de un sistema OO a uno OA
9
Ventajas de la POA

• Un código menos enmarañado, más natural y más
  reducido.
• Mayor facilidad para razonar sobre los conceptos,
  ya que están separados y las dependencias entre
  ellos son mínimas.
• Un código más fácil de depurar y más fácil de
  mantener.

10
Ventajas de la POA

• Se consigue que un conjunto grande de
  modificaciones en la definición de una materia
  tenga un impacto mínimo en las otras.
• Se tiene un código más reusable y que se puede
  acoplar y desacoplar cuando sea necesario.

11
Programa Tradicional Vs. OA
12
Conceptos Básicos de POA
13
Consideraciones Importantes

• La POA no rompe con las técnicas de programación
  orientadas a objetos sino que las complementa y
  extiende.
• El nuevo paradigma de la programación orientada a
  aspectos es soportado por los llamados lenguajes
  de aspectos, que proporcionan constructores para
  capturar los
• elementos que se diseminan por todo el
  sistema.

14
Fundamentos de la POA

• Para tener un programa orientado a aspectos
  necesitamos definir los siguientes
• elementos
• Un lenguaje para definir la funcionalidad básica.
  Este lenguaje se conoce como lenguaje base. Suele
  ser un lenguaje de propósito general, tal como
  C o Java. En general, se podrían utilizar
  también lenguajes no imperativos.
• Uno o varios lenguajes de aspectos. El lenguaje
  de aspectos define la forma de los aspectos, por
  ejemplo, los aspectos de AspectJ se programan de
  forma muy parecida a las clases.
• Un tejedor de aspectos.

15
Fundamentos de la POA
Los puntos de enlace son una clase especial de
interfaz entre los aspectos y los módulos del
lenguaje de componentes. Son los lugares del
código en los que éste se puede aumentar con
comportamientos adicionales. Estos
comportamientos se especifican en los aspectos.
16
Fundamentos de la POA

• El encargado de realizar este proceso de mezcla
  se conoce como tejedor (del término inglés
  weaver). El tejedor se encarga de mezclar los
  diferentes mecanismos de abstracción y
  composición que aparecen en los lenguajes de
  aspectos y componentes ayudándose de los puntos
  de enlace. El proceso de mezcla se puede retrasar
  para hacerse en tiempo de ejecución, o hacerse en
  tiempo de compilación.

17
Implementación en Lenguajes
Estructura de una implementación en los
lenguajes tradicionales.
18
Implementación en lenguajes
Estructura de una implementación en los
lenguajes de aspectos.
19
Fundamentos de la POA

• Los aspectos describen apéndices al
  comportamiento de los objetos. Hacen referencia a
  las clases de los objetos y definen en qué punto
  se han de colocar estos apéndices. Puntos de
  enlace que pueden ser tanto métodos como
  asignaciones de variables.
• Las clases y los aspectos se pueden entrelazar
  de dos formas distintas
• Entrelazado estático
• Entrelazado dinámico

20
Fundamentos de la POA
Entrelazado estático El entrelazado estático
implica modificar el código fuente de una clase
insertando sentencias en estos puntos de enlace.
Es decir, que el código del aspecto se introduce
en el de la clase.
21
Fundamentos de la POA

• Ventajas
• La principal ventaja de esta forma de
  entrelazado es que se evita que el nivel de
  abstracción que se introduce con la programación
  orientada a aspectos se derive en un impacto
  negativo en el rendimiento de la aplicación.
• Desventajas
• Es bastante difícil identificar los aspectos en
  el código una vez que éste ya se ha tejido, lo
  cual implica que si se desea adaptar o reemplazar
  los aspectos de forma dinámica en tiempo de
  ejecución nos encontremos con un problema de
  eficiencia, e incluso imposible de resolver a
  veces.

22
Fundamentos de la POA
Entrelazado dinámico Una precondición o
requisito para que se pueda realizar un
entrelazado dinámico es que los aspectos existan
de forma explícita tanto en tiempo de compilación
como en tiempo de ejecución. Para conseguir esto,
tanto los aspectos como las estructuras
entrelazadas se deben modelar como objetos y
deben mantenerse en el ejecutable. Dado un
interfaz de reflexión, el tejedor es capaz de
añadir, adaptar y borrar aspectos de forma
dinámica, si así se desea, durante la ejecución.
23
Fundamentos de la POA

• Desventaja
• El principal inconveniente subyacente bajo este
  enfoque es el rendimiento y que se utiliza más
  memoria con la generación de todas estas
  subclases.

24
Fundamentos de la POA

• Una de las primeras clasificaciones de las
  formas de combinar el comportamiento de los
  componentes y los aspectos fue dada por John
  Lamping.
• Yuxtaposición
• Consiste en la intercalación del código de los
  aspectos en el de los componentes. La estructura
  del código mezclado quedaría como el código base
  con el código de los aspectos añadidos en los
  puntos de enlace. En este caso, el tejedor sería
  bastante simple.

25
Fundamentos de la POA

• Mezcla
• Es lo opuesto a la yuxtaposición, todo el
  código queda mezclado con una combinación de
  descripciones de componentes y aspectos.
• Fusión
• En este caso, los puntos de enlace no se tratan
  de manera independiente, se fusionan varios
  niveles de componentes y de descripciones de
  aspectos en una acción simple.

26
Mecanismos de construcción de ptos. de corte

• Prescindencia (obliviousness)?
• La prescindencia se refiere a que el programador
  encargado de implementar una funcionalidad
  específica no debería estar al tanto de las otras
  dimensiones que pueden afectar su código.
• Cuantificación (quantification)?
• La cuantificación es la posibilidad de indicar
  en qué puntos de unión se aplicará un aspecto,
  sin necesidad de enumerarlos uno por uno.

27
Conclusiones

• La separación de los aspectos a todos los niveles
  (diseño, codificación y ejecutable) es un paso
  importante que se ha comenzado a dar, pero que
  aún hay que refinar, sobre todo en cuestiones de
  eficiencia.
• El campo de la orientación a aspectos es un campo
  de investigación muy joven, en el que se abre un
  horizonte bastante amplio.
• El estado actual de la investigación en POA es
  análogo al que había hace veinte años en la
  programación orientada a objetos.

28
DCOM

• Sistemas de Operación III

29
DCOM The Distributed Component Object Model

• DCOM es un protocolo que le permite a los
  componentes de un software comunicarse
  directamente sobre la red de manera, segura,
  confiable y eficiente
• DCOM permite la movilidad de los componentes
  logrando que cada uno este cerca de la localidad
  que le corresponda según su área de negocio.
• DCOM se encarga de todos los protocolos de bajo
  nivel (capa de red), para dejar al programador el
  negocio real.

30
DCOM Arquitectura

• DCOM es una extension del modelo Component Object
  Model (COM).
• COM define cómo los componentes y clientes
  interactuan entre sí.
• Cliente y componente pueden conectarse sin ningun
  intermediario.

31
DCOM Arquitectura

• En un sistema operativo la comunicación entre dos
  o mas procesos diferentes debe implementar
  librerias o funciones de IPC.
• COM provee esta comunicación de manera
  transparente intercepta llamadas desde el
  cliente y las redirecciona al compomente.

32
DCOM Arquitectura

• Cuando el cliente y el componente se encunetran
  en maquinas diferentes DCOM reemplaza el IPC
  local por una comunicación via red.
• Ni el cliente ni el componente saben que la
  comunicación entre ambos se hace sea via red o
  local (IPC).

33
DCOM Componentes y Reusabilidad

• La mayoria de las aplicacoines distribuidas no
  son desarrolladas desde cero.
• La gran variedad de herramientas, software y
  hardware debe ser utilizado para reducir tiempo y
  costo.
• DCOM aprovecha la gama de productos desarrollados
  con COM.
• Diseñar con COM o DCOM asegura reusabilidad y
  portabilidad ademas de alargar la vida del
  software.

34
DCOM Independiente de Localidad

• Problemas del desarrollo de sistemas
  distribuidos
• La distancia entre los componentes debería
  acortarse.
• Algunos sólo pueden ser ejecutados en
  arquitecturas o lugares específicos.
• Componentes más pequeños y simples facilitan
  desarrollo y aumentan felixibilidad pero degradan
  la eficiencia de la red.
• Componentes grandes y complejos aprovechan la red
  pero reducen la felixibilidad.

35
DCOM Independiente de Localidad

• Resolver estos detalles es relativamente fácil
  con DCOM.
• DCOM oculta la localidad de los componentes, bien
  sea local o una máquina muy lejana.
• La independencia de localidad provista por DCOM
  simplifica y mejora el performance al tener la
  libertad de colocar los componentes en el mejor
  sitio posible para así optimizar la comunicación.

36
DCOM Independiente de Localidad
37
DCOM Neutralidad del Lenguaje

• COM y DCOM son totalmente independientes del
  lenguaje.
• Permite al programador escoger el lenguaje que
  más conoce.
• Esta libertad permite la realización de
  prototipos de manera rápida.
• Se utiliza un IDL para crear las intefaces.

38
DCOM Manejo de conexión

• Conexiones a través de la red son mucho mas
  frágiles que una local.
• Los componentes deben ser notificados en caso que
  un cliente se caiga o que existan problemas con
  la red.
• DCOM maneja las conexiones de la misma manera
  para componentes locales mono-usuario como
  componentes distribuidos multi-usuario contando
  las referencias de acceso al mismo.
• DCOM implementa un protocolo de ping para
  determinar si un cliente está vivo. (después de 3
  fallas se libera la conexión).

39
DCOM Manejo de conexión

• Las conexiones en DCOM son bidireccionales. Por
  lo que es fácil implementar aplicaciones
  peer-2-peer o cliente-servidor.
• DCOM provee de un poderoso mecanismo de
  recolección de basura distribuido totalmente
  transparente para la aplicación.

40
DCOM Escalabilidad

• Un factor crítico en toda aplicación
  distribuida es su habilidad para crecer en
  función del número de usuarios, el volumen de
  datos y las funcionalidades requeridas.
• La aplicación debe ser compacta y rápida para
  satisfacer peticiones sencillas, pero al mismo
  tiempo debe ser capaz de manejar demandas de
  mayor complejidad sin sacrificar su buen
  desempeño y confiabilidad usual.
• Para lograr esto DCOM provee una serie de
  mecanismos.

41
DCOM Escalabilidad

• Multiprocesamiento simétrico
• Un número muy grande de hilos puede resultar
• en demasiados cambios de contexto. Mientras
• muy pocos puede causar el uso ineficiente de
• algunos procesadores.

42
DCOM Escalabilidad

• Desarrollo flexible
• DCOM permite distribuir facilmente el conjunto
• de los componentes de la aplicación sobre los
• diversos computadores disponibles, una manera
• sencilla y bastante económica de favorecer la
• escalabilidad.

43
DCOM Escalabilidad

• Manejo de versiones (evolución)?
• La escabilidad no está solo ligada al número
• de usuarios y de transacciones. También tiene
• mucho que ver con la necesidad de escalar en
• función de las nuevas características que sean
• presentadas y requeridas a, y por la aplicación.
• DCOM provee mecanismos de evolución para
• clientes y componentes.

44
DCOM Escalabilidad

45
DCOM Desempeño

• La escalabilidad resulta inútil si el
  desempeño inicial no es satisfactorio. Surge la
  pregunta si soportar casi cualquier lenguaje o el
  hecho de poder correr componentes en el otro lado
  del mundo no afecta el rendimiento de la
  aplicación.
• El asunto es que al usar DCOM el cliente
  nunca ve el objeto en sí. Esta transparencia es
  lograda a través de una idea simple
• La única manera en que un cliente puede
  comunicarse con un componente es mediante
  llamadas a métodos

46
DCOM Desempeño

• El cliente obtiene las direcciones de estos
  métodos de forma simple, a través de una tabla
  que contiene las direcciones de los
  mismos(vtable).
• Cuando un cliente desea llamar un método de
  un determinado componente sólo basta obtener la
  dirección del mismo. De manera que el único
  overhead producido por el modelo de programación
  DCOM sobre uno tradicional es el llamado
  indirecto de métodos sobre el modelo directo.

47
DCOM Ancho de banda y retardo

• Las aplicaciones distribuidas toman ventaja de
  la red para mantener conectados a los diversos
  componentes.
• En teoría DCOM esconde completamente el hecho
  de que los componentes se están ejecutando en
  diferentes computadores. En la práctica sin
  embargo las aplicaciones deben tomar en cuenta
  dos principales restricciones

48
DCOM Ancho de banda y retardo

• Ancho de Banda el tamaño de los parámetros
  afecta directamente el tiempo que toma completar
  la llamada a un método.
• Retardo (Latency) La distancia existente entre
  los diferentes componentes demora hasta el
  paquete más pequeño de datos.

49
DCOM Seguridad

• El uso de la red en aplicaciones distribuidas no
  solo impone dificultades físicas referentes al
  ancho de banda y retardo de la red. También trae
  consigo nuevas consideraciones de seguridad
  referentes a la comunicación entre clientes y
  componentes.
• Dado que ahora muchas operaciones son accesibles
  fisicamente a cualquiera con acceso a la red, el
  acceso a estas operaciones tiene que ser
  restringido en un nivel mayor.
• Si la plataforma no brinda un método de seguridad
  cada aplicación se vería forzada a implementar
  sus propios mecanismos y DCOM perdería gran parte
  de su atractivo.

50
DCOM Balance de la carga

• Mientras más exitosa la aplicación, mayor será
  la carga del creciente número de usuarios en
  todos los componentes de la aplicación. Lo
  adecuado es distribuir el trabajo entre los
  servidores disponibles.
• DCOM no es capaz de facilitar este balance de
  la carga transparentemente, sin embargo permite
  implementar de manera sencilla algunos mecánismos
  a fin de lograr esto.
• Balance de carga estático
• Balance de carga dinámico.

51
DCOM Tolerancia a fallas

• DCOM provee soporte básico para tolerancia a
  fallas a nivel de protocolo
• Administrador de conexión compartida entre
  componentes Detecta fallas a nivel de hardware
  tanto en la red como del lado del cliente.
• Hot Backup Dos copias del mismo componente del
  lado del servidor corriendo en paralelo en
  diferentes máquinas, procesando la misma
  información.
• Componentes de referencia En presencia de
  fallas, hay una reconexión al mismo componente de
  referencia establecido en la primera conexión.
  Provee una nueva instancia del componente que
  esté corriendo en otra máquina.

52
DCOM Tolerancia a fallas

• Las aplicaciones sin embargo tendrán que lidiar
  con recuperación de errores a alto nivel
  (consistencia, pérdida de información, etc.)?

53
DCOM Independencia del protocolo

• DCOM puede utilizar cualquier protocolo de
  transporte, como TCP/IP, UDP, IPX/SPX y NetBIOS.
• DCOM proporciona un marco de seguridad a todos
  estos protocolos. Los desarrolladores pueden usar
  las características proporcionadas por DCOM y
  asegurar que las aplicaciones sean independientes
  del protocolo.

54
DCOM Independencia de plataforma

• Estándar binario por plataforma Para poder
  mezclar y acoplar componentes realizados con
  distintas herramientas de diferentes proveedores
  y usarlo con distintas implementaciones del
  propio DCOM.
• Estándar de operatividad multi-plataforma
  Servicios o abstracciones multi-plataforma
  localización de componentes, creación y conexión
  a los mismos, invocación de métodos y un
  framework de seguridad. También utiliza los
  servicios disponibles en cada plataforma.
• Plataformas Disponibles Se encuentra disponible
  para la familia Windows en general, la Macintosh
  de Apple y Solaris de SUN. Se está trabajando en
  portar DCOM a otras distribuciones UNIX.

55
DCOM Continua integración con otros protocolos
de Internet

• Las aplicaciones basadas en DCOM pueden conectar
  transparentemente cualquier red privada virtual.

56
DCOM Continua integración con otros protocolos
de Internet

• SOBRE INTERNET
• DCOM trabaja bien con firewalls tanto a nivel de
  protocolos (basada en puertos) como los filtros a
  nivel de aplicación.
• DCOM utiliza un solo puerto para inicializar las
  conexiones. Asigna un rango configurable de
  puertos para los componentes corriendo en una
  máquina.
• Los administradores de servidores pueden decidir
  comunicar DCOM a través de HTTP, traspasando
  efectivamente la mayoría de los firewalls.
• En cada escenario de conexión a través de la red,
  DCOM provee una seguridad flexible según sea
  necesaria.

57
DCOM vs. CORBA

58
DCOM vs. CORBA

59
DCOM

PREGUNTAS