sábado, 9 de enero de 2010
Informe del Proyecto
Informe detallado del proyecto : http://www.slideshare.net/carldu29/informe-final-poo-2872088
viernes, 8 de enero de 2010
lunes, 4 de enero de 2010
Detalles del proyecto
El chat que desarrollado utiliza sockets, los cuales funcionan bajo una arquitectura cliente servidor, en donde se tiene un servidor y los clientes se conectan a éste y a través de él, se comunican entre si. La gracia del chat es que hace envio de objetos en vez de simples cadenas de texto, para ésto se utiliza la clase ObjectInputStream y ObjectOutputStream, los objetos de estas clases permiten escribir y leer objetos con los metodos writeObject y readObject, ambos reciben como parámetro un objeto. Cuál es el truco ? que todo lo que viaje por la red debe estar serializado, en el caso del chat se utiliza una clase Mensaje, la cual tiene un contenido (avatar, color de la fuente, mensaje en texto, etc) y cada parte del contenido debe estar serializado a su vez, si alguna cosa no está serializada, entonces la clase que lo contiene no podrá estarlo tampoco.
Para tener una visión completa del sistema, invito a ver la arquitectura del chat:
Como pueden ver, el cliente consta de dos partes fundamentales, Cliente y Orquestador.
Cliente es la parte gráfica, la que el usuario vé y Orquestador es la parte que se conecta con el servidor y maneja la lógica (envía y recibe mensajes).
La parte servidor tiene un Servidor que recibe las conexiones y maneja una lista de clientes, la cual está en un objeto de la clase RecursoClientes, la cual utiliza el patrón de diseño Singleton (thread safe). Cuando un cliente se conecta, el Servidor recibe el nickname del Cliente y busca en la lista si ya existe, de ser así impide la conexión y avisa al Cliente (es una regla que implementé), en caso contrario la conexión se acepta y se delega el trabajo a un thread ManejadorCliente, el cual se encarga de recibir los mensajes del Cliente y se los pasa a los demás Clientes de la lista, además se encarga de quitarlo de la lista cuando éste se desconecta y avisa a los demás de la desconexión (entre otras cosas).
El problema con la arquitectura utilizada es que mientras mas clientes se conecten, mas recursos del servidor se utilizarán, ya que por cada cliente se crea un nuevo hilo (Thread). Una solución es NO usar Threads ni Sockets, sino usar SocketChannel de java.nio, pero es más difícil de utilizar (y entender), pero vale la pena ya que según conocimos la baja en la utilización de recursos es altísima, además de una mejora sustancial en la eficiencia y rapidez de respuesta en el servidor.
Si les interesa pueden ver el diagrama de clases del cliente
y del servidor.
El servidor es bastante mas sencillo en el sentido de que son menos clases,se aplicó coceptos cómo qué son el patrón de diseño Singleton (thread safe) y la concurrencia con Threads. Por lo demás es bastante simple.
El cliente es mas complejo en el sentido que tiene mas clases, pero varias son solo clases para definir algunas cosas gráficas, nada complejo de entender. La clase mas importante es Orquestador, que es la que se encarga de toda la lógica y paso de mensajes hacia el cliente (a través de la interfaz OrquestadorInterface) y hacia el servidor (otros clientes).
Hay que tener en cuenta que lo que se envía por la red son objetos de tipo Mensaje, por lo tanto esa clase debe estar tanto en el cliente como en el servidor.
Acá pueden ver el diagrama de secuencia del servidor
y del cliente.
Con esos diagramas se puede ver la secuencia de mensajes desde que un cliente se conecta hasta que se desconecta.
Una gracia de usar NetBeans 6.0 es que viene con UML integrado y soporta ingenieria inversa (o reversa) por lo que pueden hacer diagramas de cualquier tipo (soportado) desde el código fuente con un simple click derecho en el proyecto -> Reverse Engineer y listo. También pueden generar un nuevo proyecto UML y generar código a partir del diagrama de clases, es decir pueden utilizar UML hacia ambos lados, desde y hacia, lo cual encuentro sumamente genial y por sobre todo útil.
Suscribirse a:
Entradas (Atom)