ChirixWorld

Patrón de Diseño Factory (Fábrica9

2011-06-04T09:31:00.000-07:00

En diseño de software, el patrón de diseño Factory Method consiste en utilizar una clase constructora (al estilo del Abstract Factory) abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el dedicado a la construcción de objetos de un subtipo de un tipo determinado. Es una simplificación del Abstract Factory, en la que la clase abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.

[editar]Estructura

Las clases principales en este patrón son el creador y el producto. El creador necesita crear instancias de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador, porque entonces las posibles subclases del creador deben poder especificar subclases del producto para utilizar.

La solución para esto es hacer un método abstracto (el método de la fábrica) que se define en el creador. Este método abstracto se define para que devuelva un producto. Las subclases del creador pueden sobrescribir este método para devolver subclases apropiadas del producto...

[editar]Ejemplo de código (en Java)

// Definimos la clase abstracta constructora
public abstract class Creator{
    // Operación que realiza 
    public Product  anOperation() {
 
        return factoryMethod();
    }
 
    // Definimos método abstracto
    protected abstract Product factoryMethod();
}

Ahora definimos el creador concreto.

public class ConcreteCreator extends Creator{
    protected Product factoryMethod() {
        return new ConcreteProduct();
    }
}

Y definimos el producto y su implementación concreta.

public interface Product{
    public void operacion();
}
 
public class ConcreteProduct implements Product{
    public void operacion(){
        System.out.println("Una operación de este producto");
    }
}

Y un ejemplo de uso :

public static void main(String args[]){
    Creator aCreator;
    aCreator = new ConcreteCreator();
    Product producto = aCreator.anOperation();
    producto.operacion();
}

Paradigmas de la Programación.

2011-05-27T20:37:00.000-07:00

Los “Paradigmas de programación” son la forma, la visión que determinan los métodos y las herramientas que un programador usara en la construcción de un software. Mayormente los lenguajes de programación están basados en uno o más paradigmas; por ejemplo el paradigma procedimental es seguido por la mayoría de los lenguajes actuales, tales como JAVA, Pascal y C++. También podemos encontrar lenguajes con la influencia de dos paradigmas, por ejemplo C++, que tiene su origen procedimental y al cual se le ha agregado el paradigma orientado a objetos.

En este artículo les hablare un poco sobre los siguientes paradigmas:

Funcional.
Estructural.
Orientada a Objetos.
Orientada a Eventos.
Orientada a Aspectos.

Programación Funcional.

Los orígenes de la programación funcional pueden rastrearse al matemático Alonzo Church, que trabajaba en la Universidad de Princeton, y, al igual que otros matemáticos de allí, estaba interesado en la matemática abstracta, particularmente en el poder computacional de ciertas máquinas abstractas. Las preguntas que se hacía eran por ejemplo: si dispusiésemos de máquinas de un ilimitado poder de cómputo, ¿qué tipos de problemas se podrían solucionar?, o ¿se pueden resolver todos los problemas? Para contestar este tipo de preguntas, Church desarrolló un lenguaje abstracto, denominado Cálculo Lambda, que el cual sólo realizaba evaluación de expresiones usando funciones como mecanismo de cómputo. Este lenguaje abstracto no tenía en cuenta limitaciones concretas de implementación de ningún tipo. Al mismo tiempo que Church, otro matemático, Alan Turing, desarrolló una máquina abstracta para intentar resolver el mismo tipo de problemas planteados por Church. Después se demostró que

ambos enfoques son equivalentes.

Las primeras computadoras digitales se construyeron siguiendo un esquema de arquitectura denominado de Von Neumann, que es básicamente una implementación de la máquina de Turing a una máquina real. Esta máquina forzó de alguna manera el lenguaje en el cual se escriben sus programas, justamente el paradigma procedimental, el cual, como menciona Backus en un muy famoso artículo que escribió al recibir el premio Turing en 1978 (Backus 1978), tiene tantísimos defectos, que muchos programadores padecemos aun hoy.

La programación funcional se aparta de esta concepción de máquina, y trata de ajustarse más a la forma de resolver el problema, que a las construcciones del lenguaje necesarias para cumplir con la ejecución en esta máquina. Por ejemplo, un condicionamiento de la máquina de Von-Neumann es la memoria, por lo cual los programas procedimentales poseen variables. Sin embargo en la programación funcional pura, las variables no son necesarias, ya que no se considera a la memoria necesaria, pudiéndose entender un programa como una evaluación continua de funciones sobre funciones. Es decir, la programación funcional posee un estilo de computación que sigue la evaluación de funciones matemáticas y evita los estados intermedios y la modificación de datos durante la misma.

Hoy en día existen diversos lenguajes funcionales. Se podría considerar como uno de los primeros lenguajes funcionales al LISP, que actualmente sigue en uso, sobre todo en áreas de la inteligencia artificial. También un pionero de este paradigma es APL desarrollado en los años 60 (Iverson 1962). El linaje funcional se enriqueció en los años 70, con el aporte de Robin Milner de la Universidad de Edimburgo al crear el lenguaje ML. Éste se subdividió posteriormente en varios dialectos tales como Objective Caml y Standard ML. A fines de los años 80, a partir de un comité, se creó el lenguaje Haskell, en un intento de reunir varias ideas dispersas en los diferentes lenguajes funcionales (un intento de estandarizar el paradigma). En el año 2008 Microsoft Research incluyó un nuevo lenguaje (funcional), denominado F#, a su plataforma .NET.

¿Qué es y de qué trata este paradigma?

Intentaré explicar la utilidad y potencia de la programación funcional, por medio de pequeños ejemplos, para comprender más rápidamente esta filosofía de programación. Dado el nombre del paradigma, sabemos básicamente que lo central en el mismo es la idea de función, que podríamos decir es análoga a lo que conocemos de funciones de la matemática. Por ejemplo, podemos escribir en el lenguaje funcional Haskell:

Factorial :: int -> int

factorial 0 = 1

factorial n = n * factorial (n-1)

Es decir, la última es una función sencilla, parecida a la que conocemos de las matemáticas de la secundaria, que permite calcular el factorial de un número entero

Comparemos esa línea de código de Haskell con la siguiente en un lenguaje como C#:

unsigned factorial (unsigned n)
{

int product = 1; // valor inicial

while (n > 1)

{

product *= n--; // acumulador

}
return product; // resultado

}

Este ejemplo es muy sencillo y los dos fragmentos de código son muy parecidos. Sin embargo, la definición de Haskell es mucho más cercana a la matemática:

0! = 1

n! = n * (n - 1)!

La pregunta que nos hacemos ahora, es si podemos construir programas complejos usando simplemente funciones. Esta pregunta se puede contestar fácilmente si describimos las características principales de este tipo de lenguajes. A modo de ejemplo de introducción, veamos como se escribiría el programa de ordenamiento QuickSort en Haskell:

quicksort [ ] = [ ]

quicksort ( x : xs ) = ( quicksort [ y | y <- xs, y <= x ] )

++ [ x ] ++

( quicksort [ z | z <- xs, z > x ] )

En este caso, conseguimos un programa muy sencillo y corto, que basa su potencia en la habilidad de Haskell de manipular listas ([ ]) y especificar funciones recursivas. Quicksort se define recursivamente, a partir de la misma definición matemática del algoritmo. Este algoritmo utiliza una estrategia de divide y conquista (divide and conquer), la cual divide a una lista en dos sublistas, la primera con elementos menores o iguales que uno dado, denominado pivot, y la segunda con elementos mayores. En la primera línea del cuerpo (línea 2), se define la primera sublista, en la segunda línea el pivot, y la tercera línea la tercera sublista. El operador predefinido ++ concatena dos listas. Cada llamada recursiva a QuickSort en el cuerpo especifica que se concatenará el nuevo elemento (y o z) a la lista de argumento siempre y cuando se cumpla con la condición de más a la derecha (ej. y <= x).

Comparemos ahora nuestro sencillo programa funcional con uno en un lenguaje procedimental, tal como C (Wikipedia 2008):

//Programa Quicksort en C
void quicksort(int* array, int left, int right)
{
if(left >= right)
return;

int index = partition(array, left, right);
quicksort(array, left, index - 1);
quicksort(array, index + 1, right);
}
int partition(int* array, int left, int right)
{
findMedianOfMedians(array, left, right);
int pivotIndex = left, pivotValue = array[pivotIndex], index =
left, i;
swap(&array[pivotIndex], &array[right]);
for(i = left; i < right; i++)
{
if(array[i] < pivotValue)
{
swap(&array[i], &array[index]);
index += 1;
}
}
swap(&array[right], &array[index]);
return index;
}

int findMedianOfMedians(int* array, int left, int right)
{
if(left == right)
return array[left];
int i, shift = 1;
while(shift <= (right - left))
{
for(i = left; i <= right; i+=shift*5)
{
int endIndex = (i + shift*5 - 1 < right) ? i + shift*5
- 1 : right;
int medianIndex = findMedianIndex(array, i, endIndex,
shift);
swap(&array[i], &array[medianIndex]);
}
shift *= 5;
}
return array[left]; Cuadernos de la Facultad n. 3, 2008

}

int findMedianIndex(int* array, int left, int right, int shift)
{
int i, groups = (right - left)/shift + 1, k = left +
groups/2*shift;
for(i = left; i <= k; i+= shift)
{
int minIndex = i, minValue = array[minIndex], j;
for(j = i; j <= right; j+=shift)
if(array[j] < minValue)
{
minIndex = j;
minValue = array[minIndex];
}
swap(&array[i], &array[minIndex]);
}
return k;
}

void swap(int* a, int* b)
{
int temp;
temp = *a;
*a = *b;
*b = temp;
}

Para demostrar las principales características de los lenguajes de programación funcionales modernos, vamos a utilizar el lenguaje Haskell. Este es un lenguaje funcional puro, de propósito general, que incluye muchas de las últimas innovaciones en el desarrollo de los lenguajes de programación funcional, como son las funciones de orden superior, evaluación perezosa (lazy evaluation), tipos polimórficos estáticos, tipos definidos por el usuario, encaje por patrones (pattern matching), y definiciones de listas por comprensión. Tiene además otras características interesantes como el tratamiento sistemático de la sobrecarga, la facilidad en la definición de tipos abstractos de datos, el sistema de entrada/salida puramente funcional y la posibilidad de utilización de módulos. Aunque seria imposible explicar con detalle cada una de estas características en este artículo, daremos una breve explicación de alguna de ellas. El lector interesado puede recurrir a un excelente libro en castellano (Ruiz 2004) y otros dos en inglés

(Thompson 1999; Doets & van Eijck 2004) para profundizar en el tema.

Programación Estructurada

La programación estructurada es una forma de escribir programas de ordenador (programación de computadora )

de forma clara. Para ello utiliza únicamente tres estructuras: secuencia, selección e iteración; siendo innecesario

y no permitiéndose el uso de la instrucción o instrucciones de transferencia incondicional (GOTO, EXIT

FUNCTION, EXIT SUB o múltiples RETURN).

Hoy en día las aplicaciones informáticas son mucho más ambiciosas que las necesidades de programación existentes en los años 1960, principalmente debido a las aplicaciones gráficas, por lo que las técnicas de programación estructurada no son suficientes. Ello ha llevado al desarrollo de nuevas técnicas, tales como la programación orientada a objetos y el desarrollo de entornos de programación que facilitan la programación de grandes aplicaciones.

A finales de los años 1960 surgió una nueva forma de programar que no solamente daba lugar a programas fiables y eficientes, sino que además estaban escritos de manera que facilitaba su comprensión posterior. El teorema del programa estructurado, demostrado por Böhm-Jacopini, demuestra que todo programa puede escribirse utilizando únicamente las tres instrucciones de control siguientes:

Secuencia
Instrucción condicional.
Iteración (bucle de instrucciones) con condición al principio.

Solamente con estas tres estructuras se pueden escribir todos los programas y aplicaciones posibles. Si bien los lenguajes de programación tienen un mayor repertorio de estructuras de control , éstas pueden ser construidas mediante las tres básicas.

Con la programación estructurada, elaborar programas de computador sigue siendo una labor que exige esfuerzo, creatividad, habilidad y cuidado. Sin embargo, con este estilo podemos obtener las siguientes ventajas.
Los programas son más fáciles de entender, ya que pueden ser leídos de forma secuencial, sin necesidad de hacer seguimiento a saltos de línea (GOTO) dentro de los bloques de código para entender la lógica.
La estructura del programa es clara, puesto que las instrucciones están más ligadas o relacionadas entre sí.
Reducción del esfuerzo en las pruebas. El seguimiento de los fallos o errores del programa ("debugging") se facilita debido a la estructura más visible, por lo que los errores se pueden detectar y corregir más fácilmente.
Reducción de los costes de mantenimiento de los programas.
Programas más sencillos y más rápidos (ya que es más fácil su optimización).
Los bloques de código son auto explicativos, lo que facilita la documentación.
Los GOTO se reservan para construir las instrucciones básicas. Aunque no se usan de forma directa, por estar prohibida su utilización, están incluidas implícitamente en las instrucciones de selección e iteración.
Un programa escrito de acuerdo a estos principios no solamente tendrá una mejor estructura sino también una excelente presentación.
La programación estructurada ofrece estos beneficios, pero no se la debe considerar como una panacea ya que el desarrollo de programas es, principalmente, una tarea de dedicación, esfuerzo y creatividad.

El principal inconveniente de este método de programación es que se obtiene un único bloque de programa, que cuando se hace demasiado grande puede resultar problemático su manejo; esto se resuelve empleando la programación modular, definiendo módulos interdependientes programados y compilados por separado (en realidad esto no es necesario, pero así ha sido históricamente). Un método un poco más sofisticado es la programación por capas, en la que los módulos tienen una estructura jerárquica en la que se pueden definir funciones dentro de funciones o de procedimientos.

Programación Orientada a Objetos.

Los objetos son entidades que combinan estado, comportamiento e identidad. El estado está compuesto de datos, y el comportamiento por procedimientos o métodos. La identidad es una propiedad de un objeto que lo diferencia del resto. La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

De esta forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento.

Los métodos y atributos están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El desarrollador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos. Hacerlo podría resultar en seguir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que la manejen por el otro. De esta manera se estaría llegando a una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Según se informa, la historia es que trabajaban en simulaciones de naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamiento. Fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar “en marcha” en lugar de tener un sistema basado en programas estáticos.

Conceptos fundamentales La programación orientada a objetos es una nueva forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos). Corresponden a los objetos reales del mundo que nos rodea, o a objetos internos del sistema (del programa). Es una instancia a una clase.

Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.

Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un “mensaje”. Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un “evento” con un nuevo mensaje para otro objeto del sistema.

Evento: un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera.

Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.

Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.

Estado interno: es una propiedad invisible de los objetos, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos).

Componentes de un objeto: atributos, identidad, relaciones y métodos.

Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

Algunas características:

Abstracción: Cada objeto en el sistema sirve como modelo de un “agente” abstracto que puede realizar trabajo, informar y cambiar su estado, y “comunicarse” con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción.

Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

Principio de ocultación: Cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que específica cómo pueden interactuar con los objetos de la clase.

Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado.

Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen.

Programación orientada a Aspectos.

La programación orientada a aspectos pretende dar solución a las tareas o eventos repetitivos que pueden, en un momento dado, retrasan la construcción de un software.

La Programación orientada a Aspectos constituye uno los avances más importantes de los últimos años en la ingeniería del software para edificar sistemas complejos empleando el principio de descomposición, ya que el modelo de objetos subyacente se ajusta mejor a los problemas del dominio real que la descomposición funcional.

La ventaja que tiene es que es fácil la integración de nuevos datos, aunque también quedan las funciones esparcidas por todo el código, y tiene los inconvenientes de que, con frecuencia, para realizar la integración de nuevas funciones hay que modificar varios objetos, y de que se produce un enmarañamiento de los objetos en funciones de alto nivel que involucran a varias clases.

La POA es una nueva metodología de programación que aspira a soportar la separación de las propiedades para los aspectos antes mencionados. Esto implica separar la funcionalidad básica y los aspectos, y los aspectos entre sí, a través de mecanismos que permitan abstraerlos y componerlos para formar todo el sistema.

La POA es un desarrollo que sigue a la POO, y como tal, soporta la descomposición orientada a objetos, además de la procedimental y la funcional. Sin embargo, la programación orientada a aspectos no es una extensión de la POO, ya que puede utilizarse con los diferentes estilos de programación mencionados anteriormente.

Aplicando POA se puede escribir una funcionalidad básica “pura”, y especificar cada aspecto por separado.

Luego, existe un proceso de combinación que compondrá el sistema final.

La POA permite a los desarrolladores escribir, ver, y editar un aspecto diseminado por todo el sistema como una entidad por separado, de una manera inteligente, eficiente e intuitiva.

En este artículo mostraré la aplicación, metodología utilizada para convertir una implementación tradicional en una que considere aspectos basándome en los principios de la POA.

Entre los principales objetivos de la Programación Orientada a Aspectos tenemos:

Separar las funcionalidades comunes utilizadas en toda la aplicación como: algunos eventos, validaciones, mensajes, etc.
Separar las funcionalidades propias de cada modulo que no hacen parte de las anteriores como por ejemplo en calculo de alguna fórmula en un modulo especifico o lo que se podría llamar las reglas del negocio o la capa BL , por sus siglas en Ingles.

El aporte aquí seria que cuando se inicia la construcción de un proyecto de software o un modulo se deben pensaren aquellos eventos, validaciones o métodos que podrán ser reutilizados o llamados de diferentes instancias del aplicativo, para con esto poder crear librerías, frameworks, Dlls, Componente, etc.

El concepto de programación orientada a aspectos fue introducido por Gregor Kiczales y su grupo, aunque el equipo Demeter había estado utilizando ideas orientadas a aspectos antes incluso de que se acuñara el término.

El trabajo del grupo Demeter estaba centrado en la programación adaptativa, que no es más que una instancia temprana de la programación orientada a aspectos. La programación adaptativa se introdujo alrededor de 1991.

Aquí los programas se dividían en varios bloques de cortes. Inicialmente, se separaban la representación de los objetos del sistema de cortes. Luego se añadieron comportamientos de estructuras y estructuras de clases como bloques constructores de cortes. Cristina Lopes propuso la sincronización y la invocación remota como nuevos bloques. No fue hasta 1995 cuando se publicó la primera definición temprana del concepto de aspecto realizada también por el grupo Demeter. Gracias a la colaboración de Cristina Lopes y Karl J. Lieberherr con Gregor Kiczales y su grupo se introdujo el término de programación orientada a aspectos.

La idea central que pretende la POA es admitir que un programa sea construido describiendo cada concepto separadamente. La POA muestra la separación de conceptos a través de mecanismos, que permiten abstraer y componer estos conceptos a lo largo del sistema.

Mediante una clase especial de lenguajes, llamados lenguajes orientados a aspectos (LOA), los cuales nos muestran mecanismos y constructores para la captura de los elementos que se diseminan por todos el sistema; lo cual logró ser el soporte fundamental para este nuevo paradigma POA.

A estos elementos se los denomina aspectos, cuya definición sería que un aspecto es un concepto que no es posible encapsularlo claramente, y que resulta diseminado por todo el código. Los LOA dar cumplimiento a las siguientes propiedades:

Cada aspecto debe ser claramente identificable.
Cada aspecto debe auto-contenerse.
Los aspectos deben ser fácilmente intercambiables.
Los aspectos no deben interferir entre ellos.
Los aspectos no deben interferir con los mecanismos usados para definir y evolucionar la funcionalidad, como la herencia.

Aplicando POA se puede escribir una funcionalidad básica “pura”, y especificar cada aspecto por separado. Luego, existe un proceso de combinación que compondrá el sistema final.

Los puntos de enlace brindan la interfaz entre aspectos y componentes. Son lugares dentro del código donde es posible agregar comportamiento adicional.

El comportamiento adicional puede agregarse en tres momentos particulares: antes, después, en lugar de.

El encargado de la composición es llamado Weaver. Guiado por los puntos de enlace teje el código base con el código de los aspectos.

Los tres principales requerimientos de la POA son:

Un lenguaje para definir la funcionalidad básica, conocido como lenguaje base o componente. Podría ser un lenguaje imperativo, o un lenguaje no imperativo (C++, Java, Lisp, ML).
Uno o varios lenguajes de aspectos, para especificar el comportamiento de los aspectos. (COOL, para sincronización, RIDL, para distribución, AspectJ, de propósito general.)
Un tejedor de aspectos (Weaver), que se encargará de combinar los lenguajes. Tal proceso se puede retrasar para hacerse en tiempo de ejecución o en tiempo de compilación.

Los lenguajes orientados a aspectos muestran una manera diferente de programación de software para encapsular aquellos conceptos que cruzan todo el código.

Para que los aspectos y componentes se puedan mezclar, deben tener algunos puntos comunes, que son los que se conocen como puntos de enlace.

Los puntos de enlace brindan la interfaz entre aspectos y componentes; son lugares dentro del código donde es posible agregar el comportamiento adicional que destaca a la POA. Dicho comportamiento adicional es especificado en los aspectos.

A quien realiza el proceso de tejer se lo denomina tejedor (weaver), que es quien se encarga de mezclar los diferentes mecanismos de abstracción y composición que surgen en los lenguajes de aspectos y componentes ayudándose de los puntos de enlace.

La estructura de una implementación basada en aspectos es análoga con relación a la estructura de una implementación basada en los LPG. Una implementación basada en LPG consiste en:

Un lenguaje.
Un compilador o intérprete para ese lenguaje.
Un programa escrito en ese lenguaje que implemente la aplicación.

Una implementación basada en POA consiste en:

El lenguaje base o componente para programar la funcionalidad básica.
Uno o más lenguajes de aspectos para especificar los aspectos.
Un tejedor de aspectos para la combinación de los lenguajes.
El programa escrito en el lenguaje componente que implementa los componentes.
Uno o más programas de aspectos que implementan los aspectos.
Gráficamente, se tiene una estructura como la siguiente:

Describiré algunos conceptos de los lenguajes de mayor funcionalidad en la actualidad:

• JPAL.- Permite separar los puntos de enlace, que son independientes del lenguaje base, de sus acciones asociadas que dependen de decisiones de implementación. Permite generar un Esquema de

Tejedor (brinda un puente entre el control de la ejecución y la ejecución de la acción). Su principal aplicación es para la implementación de sistemas distribuidos.

• D.- Denominado ambiente de lenguajes, en vez de solamente lenguaje, porque consiste en realidad de dos lenguajes: COOL, para controlar la sincronización de hilos (threads), y RIDL, para programar la interacción entre componentes remotos. El diseño deD es semi-independiente del lenguaje componente, ya que D impone requerimientos sobre el lenguaje componente que satisfacen naturalmente los lenguajes orientados a objetos.

• COOL.- COOL (COOrdination aspect Language) es un lenguaje de aspectos de dominio específico para tratar con la exclusión mutua de hilos, sincronización, suspensión y reactivación de hilos.

• RIDL.- RIDL (Remote Interaction and Data transfers aspect Language) es un lenguaje de aspectos de dominio específico que maneja la transferencia de datos entre diferentes espacios de ejecución.Un programa RIDL consiste de un conjunto de módulos de portales. Los módulos de portales o directamente portales se asocian con las clases por el nombre.

• ASPECTC.- AspectC es un simple lenguaje de aspectos de propósito general que extiende C, es un subconjunto de AspectJ sin ningún soporte para la programación orientada a objetos o módulos explícitos.

• ASPECTS.- AspectS, un lenguaje de aspectos de propósito general, utiliza el modelo de lenguaje de spectJ y ayuda a descubrir la relación que hay entre los aspectos y los ambientes dinámicos. Soporta programación en un metanivel, manejando el fenómeno de Código Mezclado a través de módulos de aspectos relacionados. Está implementado en Squeak sin cambiar la sintaxis, ni la máquina virtual.

• ASPECTC++.- AspectC++[29] es un lenguaje de aspectos de propósito general que extiende el lenguaje C++ para soportar el manejo de aspectos. En este lenguaje los puntos de enlace son puntos en el código componente donde los aspectos pueden interferir. Los puntos de enlaces son capaces de referir a código, tipos, objetos, y flujos de control.

• MALAJ.- Malaj es un sistema que soporta la programación orientada a aspectos. Define constructores lingüísticos separados para cada aspecto de dominio específico, donde el código de los aspectos tiene una visibilidad limitada del código funcional, reduciendo los posibles conflictos con las características lingüísticas tradicionales y también, con el principio de encapsulación.

• ASPECJ.- AspectJ es un lenguaje orientado a aspectos de propósito general, cuya primera versión fue lanzada en 1998 por el equipo conformado por Gregor Kickzales (líder del proyecto), Ron Bodkin, Bill Griswold, Erik Hilsdale, Jim Hugunin, WesIsberg y Mik Kersten. Es una herramienta que está en desarrollo y las nuevas versiones pueden tanto corregir errores de su versión predecesora como modificar el lenguaje.

Ejemplo de Diagrama de Clases

2011-05-01T20:11:00.000-07:00

Tarea #1 Para el blog, de Algoritmos y Programación III (Universidad Católica Andrés Bello)

El enunciado del ejercicio es el siguiente:

Steve es un amante de los animales, pero a la vez un geek de la programación. El colecciona arañas, gatos y peces y ha decidido hacer un pequeño sistema para poder manejar su colección de animales. Para ello ha podido generar la siguiente información:

Las arañas, gatos y peces son animales. Todo animal tiene un número de patas (8, 4 y O respectivamente). Por lo general un animal puede caminar y comer, aunque evidentemente cada uno de ellos lo hace de forma diferente (los peces por ejemplo, no caminan). A los gatos y a los peces por lo general se les da un nombre y ambos son mascotas (a las arañas no importa darles un nombre y mucha gente considera que no son mascotas). Por cada mascota se desea poder darle un nombre, saber cual es ese nombre y jugar con él, aunque no todos los animales juegan de la misma manera.

¿Puedes tratar de generar un diagrama de clases en UML que permita darle solución a la información suministrada por Steve?. Recuerda que él puede tener varios animales.

Mi solución es la siguiente.

-Clase Fish:
La Cual tiene su atributo (nombre) ya que el enunciado especifica que toda mascota se le puede asignar uno. Manejo un constructor el cual manipulara el nombre y numero de patas del pescado, también podemos ver el Set and Get para poder visualizar u escribir el nombre del animal, el método eat y por último el método para jugar.

-Clase Cat:
Exactamente a nuestra anterior clase no hay mayores cambios.

-Clase Spider:
En esta clase podemos observar que solamente tiene su constructor y el método eat, ya que como lo dice el enunciado a las Arañas no se les considera mascotas por lo tanto no se les asigna un nombre.

-Clase Pet:
Nuestras clases bases (pet y fish) implementan esta clase para obtener/fijar el nombre de una mascota o jugar.

-Clase Animal:
Es la generalización de nuestras clases bases tanto pet, fish como spider son animales y esta clase tiene los métodos respectivos para caminar y comer.

-Clase ListAnimal
Una clase controladora, donde podemos borrar/agregar/modificar/buscar todos los animales de Steve.

Nota: Podemos ver la imagen en inglés ya que este semestre podemos decir que es un "Standard" en la materia.

Presentación

2011-04-11T14:39:00.000-07:00

Hola a todo/as, antes que nada mucho gusto.

Mi nombre: César Chirino

Mi ocupación: Estudiante de Ingeniería Informática (UCAB)

Mi pasión: O varias mejor dicho, Programar, Jugar, Leer, el Arte Digital.

Mi Ubicación: Venezuela!

¿Por qué Creo este Blog?

¿Cuanto tenemos que navegar para encontrar noticias realmente interesantes?

Se resume que tenemos que abrir desde 10 pestañas en un Navegador hasta pasar horas viendo noticias de nuestros intereses y en el camino leer muchas mas aburridas. En un intento de comprimir todo esto es un solo sitio creo este blog, claro algunos podrán decir que no todos tenemos los mismos gustos (es Valido) por eso aquí les relato sobre lo que Posteare.

-Tecnología

-Hablare sobre Pascal / C / C++ / Java (También puedo ayudar un poco a aquellos que empiezan a programar)

-Estrenos de Películas (Reseñas sobre Películas de gran Interés, no Farándula)

-Libros (Que en verdad merecen la pena ser leídos)

-Juegos (Normalmente juegos Online)

-Chistes (soy amante de los BUENOS chistes)

-Arte Digital (Figura, Animaciones en 2D y 3D)

-y bueno de todo un poco lo que ocurra en nuestras calles Venezolanas.

(Seguramente Publicaré más cosas pero ahorita no se me ocurren jaja)

PD: En pocas ocasiones escribiré Testamentos (expresión Venezolana para textos largos :D), siempre intentaré ser lo mas conciso posible. Como mucho de ustedes yo también me ladillo(fastidio/canso) de leer tonterías.

Primera entrada.

2011-04-11T14:11:00.000-07:00

Lunes 11 de Abril de 2011

Probando algunas cositas en Internet, una de estas es crear este blog. ¿Blogs? una idea interesante, a ver si podemos hacer algo maravilloso en este, publicando información de Tecnología día a día, Lenguajes de Programación, Juegos y quien sabe cualquier cosa interesante que surja.