Sistemas distribuidos.

Un sistema distribuido es una aplicación que ejecuta varios protocolos para coordinar multiples procesos en una red, donde todos sus componentes trabajan de forma conjunta para realizar una o varias tareas.

Los componentes de un sistema distribuido son principalmente: programas, procesos, mensajes, protocolos, redes y componentes.

Existen varias maneras en las que diferentes máquinas pueden comunicarse entre ellas, algunas de ellas son por medio de sockets, RPC, RMI, etc.

Sockets: son canales de comunicación entre procesos los cuales pueden entre aplicaciones de la misma máquina o distintas máquinas. Existen varios tipos de sockets (SOCK_STREAM, SOCK_DGRAM,SOCK_RAW), aunque no todos los sistemas operativos soportan los sockets.

Para comunicarse a traves de sockets primero se tiene que crear un socket, luego se realiza el intercambio de información y finalmente cuando ya no se quiere comunicar nada mas se corta la comunicación cerrando el socket previamente abierto.

RMI (metodo de invocación remota): es una API de java que permite realizar RPC pero aplicado a la programación orientada a objetos.

RPC (llamadas a procedimiento remoto): es un proceso de intercomunicación que permite que los programas de computadora  creen subrutinas o se ejecuten en otro espacio de memoria. Cuando se programa una aplicación RPC se realizan tres cosas.

  • Se especifican los protocolos para la comunicación cliente-servidor.
  • Se crea el programa cliente.
  • Se crea el programa servidor.

Corba: es una arquitectura estandar para sistemas distribuidos basados en OOP. Corba permite que multiples programas escritos en diferentes lenguajes de programación y que estan en diferentes máquinas trabajen juntos.

Para convertir mi proyecto en un sistema distribuido prefiero usar la plataforma de desarrollo “The Mozar Programming System”, la cual esta hecha para programación distribuida.

Bibliografía:

http://en.wikipedia.org/wiki/Java_remote_method_invocation

http://code.google.com/edu/parallel/dsd-tutorial.html

http://java.sun.com/developer/onlineTraining/corba/corba.html

http://www.gnu.org/s/libc/manual/html_node/Socket-Concepts.html#Socket-Concepts

Posted in Uncategorized | 1 Comment

Patrones de diseño

Los patrones de diseño en programación ayudan a resolver problemas que se presentan muy a menudo en el desarrollo de un programa. Podemos referirnos a los patrones de diseño en base a :

1.- Nombre: usado para describir el patrón.

2.- Synopsis: nos da una breve descripción sobre los  problemas a los que se puede aplicar el  patrón.

3.- Solución: breve descripción de la solución.

Existen varios tipos de patrones de diseño, pero yo les voy  a mostrar unos cuantos que me parecieron muy importantes.

Adapter

Este patron se usa cuando se tienen dos objetos los cuales queremos que interactuen, pero ambos tienen interfaces distintas el uno al otro. Uno de nuestros objetos puede ser el cliente (quien recibe servicios) y el otro el servidor (quien presta servicios). Como tenemos metodos que pertenecen a la interfaz del cliente los cuales no son los mismos que los metodos que pertenecen a la interfaz del servidor y en nuestro programa queremos conservar ambas interfaces, necesitamos una manera de comunicar el servidor con el cliente. Esto se realiza por medio de un adaptador el cual permite que los metodos del objeto cliente puedan ser entendidos por el objeto servidor y la tarea que se le encargo a este ultimo se lleve a cabo.

La siguiente imagen sirve para ilustrar la manera en que se aplica este patron de diseño.

Iterator

Se usa cuando tenemos un objeto que contiene una colección de datos de un cliente, los cuales son guardados en estructuras de datos (arboles, listas enlazadas, vectores, etc) y el cliente quiere acceder a ellos sin preocuparse sobre como son guardados los datos. Por lo cual tenemos que proveer una interfaz que permita acceder a los datos de una manera amigable.

Imaginemos que el cliente quiere realizar un ciclo sobre los datos, como le hemos proveido una interfaz el cliente realiza un ciclo usando los componentes de la interfaz la cual a su vez realiza el trabajo de pasar los datos. De esa manera facilitamos la manipulación de los datos.

Composite

Trata con el problema de la creación de objetos complejos a partir de objetos mas simples, lo cual se soluciona usando una colección de elementos simples pero que puedan ser unidos entre ellos de varias maneras.

Un ejemplo muy conocido son las ventanas graficas de los programas, las cuales basicamente estan formadas por contenedores y componentes y agrupados de tal manera que se forma la ventana que se desea.

Flyweight

Cuando se tienen muchos objetos que tienen la misma información, se puede ahorrar espacio en memoria creando una clase que se encargue de manejar la información que es común a varios objetos y haciendo que esos objetos obtengan su información la un objeto de la clase anterior.

Model View Controller (MVC)

Es una manera de descomponer una aplicación en tres partes: el modelo, la visualización y el controlador. originalmente diseñado para la aplicación de una GUI. Se comporta de la siguiente forma.

Entrada –> Procesamiento –> Salida
Controlador –> Modelo –> Visualización

Este patrón es el que pienso usar, en donde la visualización es la ventana donde se ve el laberinto, las entradas son los datos que el robot pasa a el contenedor el cual modela a los muros y guarda sus posiciones y la del robot(s).

 

Bibliografía:

An Introduction to Object-Oriented Programming,(3rd Edition)
Timothy Budd

http://ootips.org/mvc-pattern.html

http://www.go4expert.com/forums/showthread.php?t=5127#prototype

Posted in Uncategorized | 2 Comments

Diagramas UML del proyecto

A continuación muestro las imagenes de los diagramas UML de mi proyecto.

Diagrama de clase.

Diagrama de actividad.

Los anteriores diagramas son la base de mi proyecto.

Posted in Uncategorized | 1 Comment

Diagrama de actividad UML

Se usan para representar las actividades que realizan los objetos que pertenecen al sistema que se intenta modelar.

El diagrama que se muestra a continuación representa las actividades mas importantes que lleva a cabo un robot que busca la salida a un laberinto.

Se puede ver el funcionamiento básico del robot en el laberinto:

-Inicio de la actividad

– Inicia el robot en el laberinto.

-Checa por un obstaculo frente a el.

-En caso de encontrarse con algun obstaculo (“otro robot, un muro”), gira y vuelve a checar.

-Si el camino esta libre avanza.

-Si ya llego a la meta se detiene.

-Si no esta en la meta vuelve a checar.

-Fin de la actividad

Explicando simbolos.

El circulo negro al inicio del diagrama indica el inicio de un diagrama de actividad.

El rectangulo redondeado en las esquinas indica ya sea una actividad o un estado del objeto.

El rombo indica un condicional.

Las dirección de las flechas indica el flujo de la actividad.

El circulo medio negro/blanco del final de la imagen indica el final de un diagrama de actividad.

Bibliografia

Posted in Uncategorized | 1 Comment

UML Diagramas de Clase

Los diagramas de clase en UML se usan para modelar las clases del sistema con las relaciones que existen entre ellas.

En UML una clase se representa de la siguiente manera:

Los simbolos “#,-,+”, tienen un significado en uml.

  • La palabra reservada protected se representa por: #
  • La palabra reservada private se representa por: –
  • La palabra reservada public se representa por: +

Las clases se relacionan para formar el sistema a modelar, por lo tanto necesitamos formas para modelar grupos de clases relacionadas entre ellas, lo cual se lleva a cabo por medio de las siguientes componentes:

Asociaciones : son las relaciones que hay entre las clases, son representadas por una                linea. Ademas estas relaciones pueden tener elementos extras como: nombre, multiplicidad, rol y navegabilidad.

Nombre: indica el tipo de relaciòn que hay entre las clases que pertenecen a esa relaciòn.

Multiplicidad: define cuantas instancias de una clases pueden ser asociadas con instancias de otra clase.

Simbolo Significado
* Cero o mas
0 Cero
1 Uno
1..* Uno o mas
0..1 Cero o un

Navegabilidad: representa la visibilidad que tienen unas clases sobre otras en una misma relaciòn. La flecha apunta en la direcciòn de la visibilidad, asi en la siguiente figura la clase B tiene conocimiento de la clase A pero A no sabe de la existencia de B.

Rol: indica el papel que juega una clase en la relación.

Relaciones de herencia (generalizaciones): para representar que un grupo de clases ha heredado metodos o atributos de otra clase en uml se usa el siguiente esquema.

Las siguientes imagenes muestran una composición y una agregación.

Una composición nos permite agregar elementos a una clase, estos elementos (“clases, interfaces, etc”) dependen directamente de la clase, por lo que si la clase de la cual dependen es eliminada, también lo son los elementos agregados.

Al contrario de una composición, en una agregación el elemento que fue agregado no depende directamente de la clase, por lo cual tambièn puede ser agregado a otras clases y permanecer en el modelo aun y cuando las clases a las estaba agregado son eliminadas.

Diagrama UML de mi proyecto.

Brevemente explicado. El laberinto es una especializacion de una clase panel que nos permite mostrar contenido en una ventana y a su vez implementa metodos de una clase grafica. Laberinto tiene como agregado una clase Contenedor, y contenedor puede tener cero o mas objetos de la clase Muro en el y los objetos  de Muro solo pueden tener un contenedor.

Contenedor es la clase que guarda las posiciones de los Muros que se van a dibujar en el Laberinto. Ademas  en el Laberinto puede haber uno o mas objetos de la clase Robot y un Robot solo puede estar en un Laberinto.Los Robots pueden chocar con cero o mas Robots y con cero o mas Muros.

Los Robots se avanzan, retroceden, giran a la izquierda o derecha y checar si chocaron.

Esto es simplemente lo que mi diagrama de clases representa.

 

Bibliografía:

Posted in Uncategorized | 3 Comments

Definición de proyectos individuales

Esta es la presentación de mi proyecto, es sencilla pero muestra lo que pretendo realizar.

Posted in Uncategorized | 3 Comments

Herencia y polimorfismo: modularidad y reutilización de código

Dos de las principales formas de reutilizar código en la programación orientada a objetos son:
a) Herencia.
b) Polimorfismo.

La herencia nos permite extender las propiedades de una clase a otras. Estas propiedades son metodos y atributos, los cuales pertenecen a una clase (clase padre, superclase) pero tambien son parte de otras clases (clases hijo).

Las clases hijo ademas de tener los mismos métodos y atributos de la clase padre, pueden tener otros metodos y atributos propios.

La siguiente imagen muestra una clase padre  y sus clases hijo.

De la anterior imagen se alcanza a observar que las tres clases hijo comparten la misma información que la clase padre, pero ademas tienen metodos y atributos adicionales. Este es un ejemplo de como por medio de la herencia se pueden crear nuevas clases que tengan con mayor información y metodos mas especificos hacia su uso.

El polimorfismo es la habilidad de usar un metodo que implementa una acción difrente dependiendo del tipo de datos que recibe. Como ejemplo veamos las siguientes operaciones:

2+2 // suma de dos numeros enteros
2+2.1 // suma de un entero y un decimal
2+”hola” /* concatenación del numero 2 y la palabra hola (si el lenguaje de pro        gramacion lo permite)*/
“hola”+” “+”mundo” // concatenación de palabras

Como podemos ver el operador “+” realiza operaciones distintas para distintos datos. Lo mismo pasa en OOP con un metodo de una clase el cual realiza funciones distintas para distintos tipos de datos, como ejemplo en la imagen anterior teniamos el metodo “girar”. Aunque se realice la misma acción en cada vehiculo, la bicicleta gira de manera diferente al avión y lo mismo pasa con el automovil.

Un video que me parecio muy interesante.

Bibliografía:
An Introduction to Object-Oriented Programming,(3rd Edition)
Timothy Budd

Python para todos
Raúl González Duque

http://openbookproject.net/thinkcs/python/english2e/



Posted in Uncategorized | 1 Comment