Casa
abierta al tiempoUNIVERSIDAD A U T ~ N O M A
METROPOLITANA
Unidad: Iztapalapa
División: Ciencias Básicas e Ingeniería
Carreras:
Ingeniería en Electrónica
Licenciatura en Computación
Materia: Proyecto terminal
I1
Título: Sistema cooperativo en Java
Fecha: Septiembre de 1999
Alumnos:
David Flores Velázquez
9222
1468
Sisterria Cooperativo en Java
Flores
Velázquez
David
Solano Suárez Humberto
Univers'idad Autónoma Metropolitana
Contenido
Prefacio iv
Introducción vi
1 Objetivos 1
2 Fundamentos 2
2.1 Análisis y Diseño Orientado a Objetos . . . 2
2.2 Programación Distribuida . . . 3
2.3 Comunicación con RPC (Remote Procedure Call) . . . 4
2.4 CORBA (Common Object Request Broker Architecture) . . . 5
2.4.1 IDL (Interface Definition Language) . . . 6
2.4.2 ORB (Object Request Broker)
. . .
72.4.3 ORB en el servidor . . . 7
2.4.4 ORB en el cliente . . . 8
2.5 RMI (Remote Method Invocation) . . . 8
2.5.1 Nivel stub/skeleton . . . 9
2.5.2 Nivel de referencia remota
. . .
102.5.3 Nivel de transporte . . . 10
2.5.4 Interfaz del objeto remoto . . . 10
2.5.5 Implementación en el servidor . . . 11
2.5.6 El registro RMI . . . 11
2.5.7 Stub del cliente y skeleton del servidor . . . 11
2.6 Serialización de objetos . . . 14
2.7 AWT
. . .
153.1 Funcionalidad ofrecida . . . 16
3.2 Jerarquía de Clases . . . 16
3.2.2 Servidor . . . 28
3 Modelo de la Aplicación 16 3.2.1 Cliente
. . .
164 Funcionamiento del Sistema 45
Lista
de
Tablas
3.1 Clases y Métodos del sistema . . . 38
3.2 Clases y MCtodos del sistema(Continuaci6n) . . . 39
3.3 Clases y Métodos del sistema(Continuaci6n)
. . .
403.4 Clases y Métodos del sistema(Continuaci6n) . . . 41
3.5 Clases y Métodos del sistema(Continuaci6n) . . . 42
3.6 Clases y Métodos del sistema(Continuaci6n)
. . .
43Lista
de
Figuras
2.1 Petición local y remota . . . 5
2.2 Interacción cliente . servidor . . . 6
2.3 Arquitectura de capas de RMI . . . 9
3.1 Jerarquía de clases del cliente . . . 17
3.2 Jerarquía de clases del servidor
. . .
293.4 Clases relacionadas con TextApplication
. . .
353.3 Clases relacionadas con DrawApplication
. . .
333.5 Clases relacionadas con la clase AdressDialog
. . .
363.6 Clases que sirven para crear los dibujos y el texto
. . .
374.1 Ventana de inicio del cliente . . . 45
4.2 Ventana de información del usuario
. . .
464.3 Ventana para el intercambio de mensajes
. . .
474.4 Ventana de texto . . . 48
Prefacio
Las razones que hacen interesante la idea de trabajar en un Proyecto Terminal son la posibilidad de vincular los conocimientos adquiridos a lo largo de la carrera de Electrónica y Computación, así como extender estos conocimientos en un área que permita obtener una visión distinta del trabajo en red. El presente trabajo habla de un Sistema que permite a un grupo de personas trabajar de manera conjunta y organizada sin necesidad de estar en el mismo sitio para expresar sus ideas y desarrollar su trabajo. Esto puede conseguirse a través de una red de computadoras(por ejemplo Internet), en donde se puede trabajar en un documento (que puede ser de texto, dibujos, o archivos de algún otro tipo) y observar de manera inmediata los cambios que cada una de las personas hace sobre el documento, el hecho de trabajar vía Internet implica que los usuarios pueden encontrarse en cualquier parte del mundo; a un sistema con las
características descritas se le denomina Sistema Cooperativo. Pero no sólo es eso lo interesante, sino poder entender qué es lo que hay detrás de este sistema y
que permite dicho comportamiento, así como entender la utilidad y los alcances del sistema para un trabajo en grupo de manera organizada.
A lo largo de esta exposición se explicará cuáles son los elementos que hacen posible dicho sistema y cuáles son las razones por las que se utilizan las herramientas para el diseño e implementación.
En el capítulo 1 se presentan las objetivos que este trabajo persigue y la forma en que se distribuye dicho trabajo.
Para el capítulo 2 se da una breve explicación de los conceptos necesarios para el desarrollo del sistema.
En el capítulo 3 se comienza a dar el modelo generado para el sistema, así
como su implementación.
En el capítulo 4 se muestran las características del sistema y su fun- cionamiento.
Por ultimo en el capítulo 5 pueden encontrarse alsconclusiones de este trabajo.
Ya existe el modelo fundamental para este Sistema y una primera apli- cación, el siguiente paso e s pensar en una extensión del modelo que consiga hacerlo más variado y por lo mismo útil. No es el objetivo de este trabajo extender la primera aplicación sino hacer una segunda.
de proporcionar a los interesados la oportunidad de evaluar, corregir, modificar
Introducción
Se puede hablar de un Sistema Cooperativo como una aplicación de 10s Sis-
temas Distribuidos. Este sistema pretende dar la apariencia de un documento
centralizado sobre el cual una o más personas trabajan en tiempo real(1a actua- lización del documento debe ser rápida para aparentar esto), lo que permite ver los cambios que cada persona realiza sobre el documento en el momento que se hacen. La realidad es que cada una de las personas tiene en su computadora una copia del documento y el sistema se encarga de hacer las actualizaciones co- rrespondientes sobre cada uno de los documentos. El sistema permite al usuario saber cuales son los grupas de trabajo que ya existen o crear su propio grupo de trabajo. Ya dentro del sistema se puede saber quienes son los usuarios que se encuantran trabajando en ese momento.
Existen sistemas comerciales que poseen las características antes mensic- nadas (como Netmeeting de internet explorer o Netscape Conference) aparte de un conjunto de carcaterísticas adicionales que los hacen muy utiles para la comunicación escrita o visual.
Para poder conseguir lo anterior es necesario entender lo que una aplicación distribuida significa así como los requerimientos para trabajar en un ambiente Cliente/Servidor.
Java fue el lenguaje de programación elegido para la implementación del sistema ya que el modelo es orientado a objetos y el lenguaje permite imple- mentar un modelo con esa característica.
Otras de las ventajas de Java son la funcionalidad que ofrece para un de- sarrollo sencillo de un ambiente gráfico, así como su mecanismo de interconec- tividad que es RMI y que hace sumamente sencilla y segura la comunicación a través de una red.
Capítulo
1
Objetivos
El proyecto está dividido en dos partes. En la primera parte los objetivos perseguidos son:
o Presentar aspectos fundamentales del paradigma orientado a objetos que permitan entender los modelos y conceptos, expuestos mas adelante.
o Entender los fundamentos de un Sistema Distribuido.
o Conocer alternativas para la interconectividad como son RPC y CORBA
y realizar una comparación con RMI.
o Conocer y trabajar con Java.
Los objetivos para la segunda fase del proyecto son:
o Diseñar y presentar el modelo de lo que será la nueva aplicación.
Capítulo
2
Fundamentos
2.1
Análisis y Diseño Orientado
a
Objetos
La utilización del paradigma orientado a objetos ofrece ventajas como la abs- tracción que permite la descomposición de la complejidad de los sistemas, encon- trando patrones comunes de comportamiento entre los elementos de un sistema específico. Esto permite agrupar a dichos elementos en lo que se denomina como clases que se pueden pensar como un modelo o la especificación de características
y comportamiento del objeto que la clase está modelando. Al hablar de un ob- jeto nos referimos a una instancia de la clase, cada objeto creado de una clase tendrá un comportamiento, estado e identidad que le permitirá ser distinguido de los demás. La definici6n de clases resulta subjetiva porque depende del in- terés del individuo que quiere describir y modelar al sistema. Pensando en una red de comunicaciones como un sistema puede ser diferente el modelo que un ingeniero propone del que un usuario puede proponer, pues este último sólo se preocupa por los servicios que la red ofrece mientras que el ingeniero deberá pre- ocuparse por todos los elementos relacionados. Un buen grado de abstracción permite identificar las jerarquías y relaciones entre los objetos para entender el funcionamiento del sistema de forma más adecuada, también permitirá ex- tender el sistema agregando características nuevas sin muchas dificultades, se podrá hablar de una evolución del sistema y de la reutilización de elementos [l].
Como ejemplo se tiene al sistema cooperativo que pretende poder comu- nicar a uno o varios clientes con un servidor que se encargará de ofrecer dife- rentes servicios como la comunicación entre los usuarios. Lo que nos interesa en este caso son tanto las propiedades como el comportamiento del los elementos de este sistema. Al pensar en un comportamiento común entre los objetos podemos pensar en que cada cliente desarrolla el mismo comportamiento aunque pueden encontrarse, cada uno, en distintos estados y tener diferentes identidades que permitirán distinguirlos, esto puede permitir definir una clase de tipo Cliente. Si por ejemplo el cliente necesita crear una ventana para su área de trabajo
mayoría de las características que se requieren se puede crear una nueva clase ventana que tome las características de la clase ventana inicial y que además agregue características nuevas, con esto estamos utilizando una característica de la programación orientada a objetos llamada herencia.
Otro aspecto interesante que se puede hacer es crear una clase que defina el comportamiento de lo que un objeto debe tener sin implementar este com- portamiento, a esto se le llama interface y tiene como finalidad que la persona implemente el comportamiento de la forma que más le convenga.
Gracias a la herencia puede definirse para una clase servidor un compor- tamiento inicial sabiendo 'que se puede evolucionar a la clase servidor de una manera sencilla y sin hacer grandes cambios; se está reutilizando lo que ya ex- istía. Desde luego tanto el cliente como el servidor en general pueden constar de varias clases. Lo que se puede hacer es agrupar estas clases dando como re- sultado la creación de un módulo, con esto se puede conseguir que la estructura de cada módulo sea lo bastante simple para ser comprendida en su totalidad, a lo anterior se le denomina modularidad, cada uno de estos módulos debe ser débilmente acoplado, es decir no debe ser dependiente de otros módulos porque esto generaría problemas para la reutilización de elementos. En el caso de las relaciones entre objetos se define la relación de enlace para la cual el paradigma define la comunicación enhe objetos que no es más que el paso de parámetros entre ellos o la utilización lde los métodos de un objeto por otro. La relación de agregación se refiere a la contención de un objeto en otro, de forma explícita se puede encontrar la declaración de una clase dentro de otra. Un ejemplo sería crear una clase botón y una clase ventana que siempre necesite de botones, entonces se puede definir a la clase botón dentro de la clase ventana.
2.2
Programación Distribuida
Los siguientes conceptos son comunes para los temas de programación dis- tribuida citecomputing y ,se hará uso de ellos a lo largo de este trabajo:
o Marshal: Es la tarea, de empacar los argumentos de un método para en- tregarlos al objeto remoto y la tarea de recoger los valores regresados por el método para el cliente
[a].
o Skeleton: Es la interfaz entre la implementación del objeto remoto y el administrador de objetos del lado del servidor y es usado para crear nuevas instancias de la clase y para conducir las llamadas de métodos remotos a
l a implementación del objeto.
2.3
Comunicación con RPC (Remote Procedure
Call)
La Llamada a Procedimientos Remotos (RPC en inglés) permite a un cliente ejecutar procedimientos en otra computadora en la red o servidor remoto. El término remoto no necesariamente significa que el cliente y el servidor se están comunicando a través de la red; de hecho, pueden ambos existir en la misma máquina. La diferencia entre llamada a procedimientos local y remoto es que en el primer caso el cliente ejecuta el proceso en su propio espacio de direc- cionamiento y en la segunda el cliente y el servidor se ejecutan como dos pro- cesos separados. La biblioteca de RPC maneja la comunicación entre estos dos procesos. RPC utiliza un modelo de comunicación petición
-
respuesta [3]. El cliente envía un mensaje de petición al servidor el cual regresa un mensaje de respuesta. La comunicación entre el cliente y el servidor se lleva a cabo por medio de dos stubs uno del lado del cliente y otro del lado del servidor. Aquí puede verse una diferencia entre RMI y RPC ya que el primero no utiliza dos sino sólo un stub que está del lado del cliente y un skeleton del lado del servidor. En RPC un stub se define como una interface que implementa el protocolo de RPC y especifica como serán construidos e intercambiados los mensajes. Losstubs son generados por medio de un compilador que los liga al cliente y al servidor.
En la figura 2.1 puede verse cómo se ejecutan una petición local y una remota. El cliente hace una petición al servidor pasando argumentos y el servi- dor responde a la petición enviando resultados al cliente. En el diagrama de la izquierda la comunicación es bastante simple, y en el diagrama de la derecha el cliente y el servidor se valen cada uno de su propio stub para efectuar la comunicación y los stubs utilizarán el transporte de red para comunicarse entre ellos y dar la petición o entregar resultados a quien corresponde.
La utilización de IPC (Interprocess Communications) es esencial para el modelo cliente-servidor, el problema es que su utilización resulta poco fácil pero con la utilización de RPC! menos laborioso, también se evita la necesidad de trabajar a bajo nivel. En RPC en general, los servicios se encuentran a la espera de una petición de conexión, el servicio puede dar al cliente la dirección que necesita para abrir el canal de comunicación con el servidor. El servidor puede entonces aceptar la petición (o denegarla) enviando la respuesta necesaria. El servidor debe indicar al registro de puertos en que puerto estará ubicado para que cuando el cliente haga la petición obtenga la dirección correspondiente. Los pasos necesarios para la comunicación con RPC son:
1. Cuando cualquier servidor RPC (demonio o proceso que está a la espera de una petición) es iniciado, este establece una dirección donde escuchará la petición. Debe registrar el número de puerto (dirección), en el mapa de puertos. El cliente y las aplicaciones del servidor tienen direcciones arbitrarias.
Uamccia Locd
Figura 2.1: Petición local y remota.
(usando un número de servidor de programa), el mapa de puertos en la máquina del servidor es consultado para identificar el número de puerto que va a recibir el mensaje de petición de RPC.
3. El cliente y el servidor pueden entonces abrir una ruta de comunicación para ejecutar el Procedimiento Remoto. El cliente produce una petición; el servidor envía una, respuesta.
En la figura 2.2 puede verse como el cliente hace consulta al mapa de puertos preguntando por Ita dirección del puerto donde el servidor escuchará las peticiones. El servidor por su lado registra en el mapa de puertos la dirección del puerto que utilizará para escuchar las peticiones. Una vez efectuado lo anterior puede establecerse la ruta de comunicación.
2.4
CORBA
(Common
Object Request Broker
Architecture)
En 1989 fue fundada la OlMG (Object Management Group) y actualmente es
I I r ,
Figura 2.2: Interacción cliente - servidor.
cación entre aplicaciones y también ofrece servicios para accesarlos por nombre, guardarlos, mostrar sus estados y definir relaciones entre ellos, CORBA tiene el potencial para tomar ventaja de cualquier otro desarrollo cliente/servidor. La primera versión de CORBA salió en 1991, la versión 2.0 en 1994 y la versión 3.0
en 1998.
Los componentes que conforman CORBA son los siguientes:
ORB (Object Request Broker) Que es el que permite a objetos cliente que invoquen a métodos de objetos servidor sin tener consideraciones del lugar donde se encuentren estos últimos.
o IDL (Interface Definition Languaje) Es usada para especificar el protocolo
por el cual los objetos distribuidos pueden ser accesados.
o IIOP (Internet inter-ORB protocol) Un protocolo binario para la comu- nicación entre ORB, el cual permite mandar mensaje a sistemas remotos de diferentes vendedores vía TCP/IP.
2.4.1
IDL (Interface Definition Language)
El lenguaje de definición de interfaz permite especificar el contrato y los límites que tendrán los component,es, esto es que sólo hace la declaración de los métodos
y no los implementa. Cuando es compilada la interfaz en el cliente y el servidor,
l
asentradas y salidas en los argumentos de los métodos son usadas para generar
2.4.2 ORB (Object Request Broker)
Es la parte que permite tener objetos que hagan peticiones a otros objetos que sean locales o remotos, esto permite obtener:
e Invocaciones dinámicas y estáticas. e Unión a lenguajes de alto nivel.
e Sistema auto descriptivo.
e Transparencia remota/local
e Seguridad en los mensajes.
o Mensajes polimórficos.
La ORB del cliente es responsable de aceptar peticiones del cliente para un objeto remoto, encontrando la implementación del objeto en el sistema dis- tribuido, aceptando la referencia del lado del cliente con el objeto remoto. Del lado del servidor la ORB permite que objetos del servidor registren nuevos objetos, el servidor ORB recibe la petición del cliente ORB y usa la interfaz del skeleton del objeto para invocar la activación del método de ese objeto, el servidor ORB genera una referencia del objeto para el nuevo objeto y envía esta referencia al cliente, el cliente ORB convierte esta referencia al lenguaje específico y el cliente usa esta referencia para invocar métodos en el objeto remoto.
2.4.3 ORB
en el servidor
Una vez que las interfaz IDL ha sido escrita, esta puede ser convertida al stub del cliente y el skeleton del servidor, para hacer esta tarea existen conversores o
compiladores que traducen la interfaz en código para ser usado por el lenguaje en el que se realizará la implementación. Conversores de IDL existen para C,
C++, Smalltalk, Ada, Java (JOE es un compilador IDL para Java, y NEO es la interfaz aplicación/programación que permite a los programas ser integrado a NEO y es el que provee soporte para aplicaciones de redes integrando CORBA)
,
etc. El skeleton del servidor actúa como la base para la implementación de la interfaz del objeto e incluye métodos específicos que el servidor ORB usa para mapear una petición del cliente con la llamada del método del objeto implementado. Una vez definido la implementación para el objeto, se necesita registrar la implementaci6n del objeto con el servidor ORB y opcionalmente ligarlo con un nombre. En lado del servidor tenemos los siguientes elementos:e Los stubs IDL del servidor.
0 La interfaz dinámica skeleton.
o La implementación d.el repositorio.
o La interfaz ORB.
2.4.4
ORB
en
el
cliente
El cliente usa un stub para accesar los datos y métodos de una instancia remota del objeto. Un stub es generado compilando el IDL, el stub contiene métodos específicos de CORBA para que el cliente ORB pueda realizar marshal a los argumentos del método para ser enviados al servidor y unmarshal para valores regresados. Los componentes que tenemos del lado del cliente son los siguientes:
o El stub IDL del cliente.
o La interfaz dinámica de invocación. o La interfaz depositora de APIs.
o La interfaz ORB.
El stub y el skeleton no tienen porqué estar compilados en el mismo Lenguajes soportados por CORBA: C, C++, Java, Ada95, Cobol y Small- Plataformas Win32, IJnix
,
MVSProtocolos de comunicación e interconexiones soportados por CORBA: TCP/IP, IPX/SPX, FDDI., ATM, Ethernet.
Hardware: RISC y CISC. Ventajas:
lenguaje de programación. talk entre otros.
o La creación de aplicaciones extensibles. Soluciones escalables.
o Desacoplo con la interfaz de usuario.
o Independencia del lenguaje de programación.
o Administración basa'da en el web.
Integración con productos comerciales NMS(network management sys-
tem).
2.5
RMI (Remote Method Invocation)
El mecanismo RMI permite la acción de invocar métodos de una interfaz remota en un objeto remoto. RMI es parte de Java API y ofrece los elementos necesarios para desarrollar un sistema distribuido de objetos en Java citeRMITutoria1.
Figura 2.3: Arquitectura de capas de RMI.
o Dar soporte a llamadas de regreso del servidor a applets
o Integrar el modelo de objetos distribuido en el lenguaje Java.
o Desaparecer las diferencias entre modelos de objetos distribuidos y objetos locales.
o Hacer la escritura de aplicaciones distribuidas lo más sencilla posible. o Preservar la seguridad proveída por el ambiente de ejecución de Java.
El sistema RMI consiste de 3 niveles:
o Nivel stub/skeleton
o Nivel de referencia remota
o Nivel de transporte
como se ve en la figura 2.3.
2.5.1
Nivel stub/skeleton
El nivel stub/skeleton es la interfaz entre el nivel de aplicación y el resto del sistema RMI. Esta capa no se preocupa con especificaciones de transporte, pero transmite datos a la capa de referencia remota vía la abstracción de flujos mar- shal, el flujo marshal emplea un mecanismo llamado serialización de objetos el cual permite a objetos Java ser transmitidos entre direcciones remotas. Los objetos transmitidos que usan el sistema de serialización de objetos son pasados por copia a la dirección rernota, en caso de que los objetos transmitidos sean ob- jetos remotos, estos son pasados por referencia. El stub para un objeto remoto
o Iniciar las llamadas a un objeto remoto.
o Realizar el marshal a. los argumentos y mandarlos a un flujo marshal.
o Informar al nivel de referencia remota que una llamada debe ser invocada.
o Realizar unmarshal para el valor regresado de un flujo marshal.
o Informar a el nivel de referencia remota que la llamada ha sido completada. El skeleton para un objeto remoto es una entidad del lado del servidor que contiene un método el cual atiende las llamadas para la implementación del objeto remoto, sus funciones son descritas a continuación:
o Realizar unmarshal de los argumentos obtenidos de un flujo de marshal. Hacer la llamada para la implementación del objeto remoto.
o Realizar el marshal al valor regresado de la llamada o excepción en un flujo marshal.
2.5.2 Nivel de referencia remota
El nivel de referencia remota se encarga de lidiar con la interfaz de transporte] también es responsable por exteriorizar un protocolo de referencia remota es- pecífico. El nivel de referencia remota tiene 2 componentes que son cooperativos entre si, uno del lado del cliente y otro del lado del servidor. El lado del cliente tiene información específica para el servidor remoto y se comunica usando el nivel de transporte vía la abstracción de un flujo orientado a conexión.
2.5.3 Nivel de transporte
El nivel de transporte es el encargado de poner la conexión con las direcciones remotas, manejar las conexiones, escuchar las llamadas entrantes, mantener una tabla de objetos remotos que existen en las direcciones] entre otras cosas.
Los componentes del sistema RMI son los siguientes:
2.5.4 Interfaz del objeto remoto
Es donde se hará la declaración del objeto y los métodos remotos que serán usados por el cliente e implementados en el servidor, esta interfaz debe extender
2.5.5
Implementación en el servidor
Ya que se definió la interfaz del objeto remoto, se debe escribir la imple- mentación de la interfaz en el servidor, este usualmente también extiende la clase java. rmi. server .UnicastRemoteObject y esta a su vez extiende la clase
j ava. m i . server. Remoteserver la cual es la clase base para implementar ob-
jetos en RMI.
2.5.6
El registro RMI
El registro se inicia usando el comando rmiregistry, este solo es necesario ini- ciarlo del lado del servidor, una vez que se inicia el registro en el servidor, por default este usa el puerto 1099 aunque puede usarse cualquier otro. Una vez que el registro esta funcionando uno puede registrar la implementación del objeto usando un nombre, por medio de la interfaz java.rmi.Naming, por otro lado el cliente puede localizar esta clase registrada usando java.rmi.Naming.lookup
2.5.7
Stub
del cliente
y
skeleton del servidor
Una vez definida la interfaz del objeto y echa la implementación en la clase servidor se compila la clase de forma usual en Java y para la creación del stub
y del skeleton se hace uso del compilador de stub de RMI llamado rmic [4]. El skeleton actúa como una interfaz entre el registro RMI y las instancias de la implementación del objeto en el servidor, cuando el cliente hace una petición para la invocación de un método esta es recibida y el skeleton es llamado para extraer los parámetros serializados y pasarlos a la implementación del objeto. un stub del cliente es regresado al cliente cuando la instancia remota de la clase es solicitada atravez de la interfaz Java.rmi.Naming, el stub tiene que engancharse al subsistema de serialización del objeto en RMI para realizar el marshal a los parámetros del objeto.
A continuación tenemos un ejemplo de un programa cliente/servidor im- plementado con RMI. Supongamos que tenemos una computadora que está físicamente conectada a equipos de monitoreo de clima (termómetros, medi- dores de huwedad, etc). Este sería nuestro servidor. El método remoto que se va a invocar es getClimaLectura(
1,
se necesitará una implementación de esto en e1 servidor, y tendremos que proveer de una interface al cliente para que pueda saber cuales son los servicios ofrecidos.Esta es la clase que encapsula las lecturas del clima.
import java.io.*;
public class Lectura implemeets Serialirrable(
public float velviento; public String barometro;
public Lectura (String s,float r,float t,float w,String b) {
forecast = S ;
lluvia = r;
temperatura = t;
velViento = n ;
barometro = b;
3
3
El código del cliente es sumamente simple y se deben considerar dos aspec- tos importantes:
1. La definición de un administrador de seguridad; que puede ser el que proporcionan las librerias de Java.
2. Definir un administrador de excepciones; el cual se encarga de notificar al usuario de posibles problemas.
import java.rmi.*;
import java.rmi.server.RMIC1assLoader;
public class ClienteR {
static public void main (Stringu S ) {
System. setSecurityHanager(new RMISecurityManagero 1 ;
try {
Class cl = RMIClassLoader.loadClass("Ap1ic");
Runnable client = (Runnable) cl.neaInstance();
client.run();
System.out.println(e);
3
catch(Exception e) {1
3
3
Esta es la parte del cliente
public class Aplic implements Runnable {
public void r u n 0 C
Lectura g = null;
try C
ClimaIntf wi = (Clima1ntf)Naming.
g = wi .getClimaLecturaO;
System.out.println(e);
lookup("//laryc.uam.nur/Clima");
3
catch(Exception e) C3
if (g ! = null) C
System. out. println("E1 clima es "+g
.
f orecast) ;System.out.println(g.11uvia +
System.out .println("la temperatura es " +
System.out .println("velocidad del viento: I' +
System.out .println("el barometro indica I' +
"cm. de lluvia han caido recientemente");
g.temperatura
+
*'C+'> ;g
.
velViento + "kmh") ;g.barometro);
3
3
3
Esta es la interface donde se definen alsfunciones que soportará el servidor
import java.rmi.*;
public interface ClimaIntf extends Remote C
public Lectura getClimaLectura0 throws RemoteException;
3
Esta es el servidor e irnplementa los métodos que se definieron en la inter- faz.
import java.rmi.*;
public class ClimaImpl extends UnicastRemoteObject
implements ClimaIntf C
Lectura g = new Lectura("soleado",O.OF,75.OF,5.OF,"steady");
public ClimaImplO throws RemoteException C
3
super (
1
;public static void main (String argC1) C
System.setSecurityManager(new RMISecurityManagero); try
3
3
3
ClimaImpl wi = new ClimaImplO;
Naming.rebind("Clima",wi);
System.out.println("Estaci6n de clima funcionando");
catch(Exception e) C
System. out. println( "ClimaImpl error:
+
e) ;public Lectura
return g;
3
3
getClimaLectura() throws RemoteException C
Como puede verse es sumente simple tomar esta alternativa comparándola con la opción de implementar la comunicación por medio de sockets. RMI permite hacer referencia a métodos remotos, como si estos estuvieran en la misma máquina.
2.6
Serialización de objetos
Otra facilidad que brinda RMI es la serialización de objetos, Java incluye esta clase para poder convertir un objeto en un flujo de bytes y reensamblar los bytes de nuevo a una copia idéntica del objeto original, en RMI la serialización facilita el uso para realizar marshal y unmarshal a los argumentos objetos de los métodos, cualquier objeto que sea usado como argumento en un método remoto debe ser una extensión de java. io. Serializable [5].
Esta utilidad de serializar objetos será considerada para conseguir que el programa guarde el trabajo realizado en un archivo, para m& tarde hacer uso
2.7
AWT
Otra de las caracteristica que será de gran ayuda para el desarrollo y diseño de la interfaz el AWT(Abstract Window Toolkit), se debe tener en cuenta la versión de Java que se emplea ya que hay diferencias en cuanto al modelo de AWT que se emplea en la versión 1.0 y la versión 1.1 en adelante [6].
El cambio de java 1.1 más notable es el nuevo procesamineto de evento, adoptado para el kit de herramientas de Interfaz de Usuario Gráfico (CUI) y de ventanas AWT, se da esencialmente un modelo ”de llamada” citeGraficaAwt. Cuando se crea un componente de GUI, se dice a éste qué método o métodos debe invocar cuando ocurra un evento particular (por ejemplo, cuando el usuario presiona un botón del mouse o elige un elemento en una lista). En este modelo diferentes clases de Java representan las distintas clases de eventos, se da el uso
de listeners(oyentes), son objetos que se dedican a ofrecer los servicios cuando determinado evento ocurre. Un objeto que genera eventos(un evento fuente) mantiene una lista de oyentes interesados en saber cuándo ocurre el evento y
proporciona métodos que permiten a los oyentes agregarse y removerse de una lista de objetos interesados.
El siguiente es un pequeño ejemplo del uso de los oyentes.
public class Escribir implements MouseListener
-t
private int ultimo-x, ultimo-y;
//le dice a este applet que objetos de MouseListener
public void i n t o
<
3
this. addMouseListener(this) ;
/ / Un método de la interfaz MouseListener invocado cuando
// el usuario presiona el botón del ratón
public void mousePressed(MouseEvent e)
<
ult imo-x = e. getx ( ) ;
ultimo-y = e. gety() ;
3
Capít
u10
3
Modelo
de
la Aplicación
3.1
Funcionalidad ofrecida
La descripción del sistema comienza con la funcionalidad que este ofrecerá y más adelante se comenzará con la descripción de los diagramas de clase.
o Contar con un área que permita ver quienes están trabajando en ese mo- mento con el documento que se eligió.
o Contar con un área de envío y recepción de mensajes para la comunicación entre usuarios. Como característica, el usuario podrá elegir con cuales personas desea comunicarse, o hacerlo con todas a la vez.
Disponer de un menú del cual se puedan escoger la aplicación con la cual
se desea trabajar ( así como el documento, ya que podrán existir varios trabajos en torno a los cuales se forman grupos de trabajo).
o Contar con un área de dibujo que permita escoger el tipo de elemento que se desea dibujar. También debe poderse escoger el color para cada objeto.
o De la misma forma que el punto anterior se debe contar con un área de texto (en una ventana a parte del área de dibujo) que permita trabajar con un documento de tipo texto.
o Tener la posibilidad de guardar el trabajo ya hecho en un archivo con un formato definido más adelante. Desde luego también deben poder abrirse documentos ya creados y editarse.
3.2
Jerarquía de Clases
3.2.1
Cliente
A continuación se muestra la jerarquía de clases del Cliente ver figura 3 . 1 .
1nterface.WorkgroupInterface
Y
1nterface.FirstgroupInterface
sólo definen parte de lo que el sistema hace y serán las clases como
Workgroup
Y
Works.MainAp1icaction
las que realmente implementarán dicho comportamiento. A continuación se da la descripción de lo que hacen alsfunciones más importantes:
En general todas las interfaces extienden la clase java.rmi.Fkmote haciendo que las clases que hagan uso de ellas, puedan ser llamadas remotamente. Siendo la parte del protocolo que se utiliza en RMI.
La función
UpdateUserList
que pertenece a
1nterface.WorkgroupInterface
se encarga de actualizar la lista de usuarios cada vez que uno de estos entra o deja el sistema recibiendo como parametro un elemento de tipo
java.uti1.Vector
que le permite saber quién fue el usuario que entró o salió.
o La función displayMessage es parte de la inteface FirstgroupInteface y es implementada en la clase MainApplication es parte del mecanismo que implementa la comunicación entre usuarios.
o La función Updatetopics que también es parte de FirstgroupInteface se encarga de actualizar la lista de temas exitentes al momento de entrar un usuario al sistema.
La clase DrawApplication se encarga de la creación y manipulación de los objetos gráficos.
La clase TextApplication implementa al igual que las demás métodos, atrib- utos y se vale de otras clases para poder manejar la utilidad de texto que es parte del sistema.
package Works; //se utilizan 3 paquetes para
import java.awt.*; //en works se encuentran todas las
import java.awt.event.*; //directamente con el cliente.
import java.io.Serializable; import java.rmi.*;
import java.rmi.server.*; import java.util.Vector; import Interface.*;
// modularizar el sistema
// clases relacionadas
Esta parte se utiliza para incluir los paquetes necesarios empleados por la clase. El mismo sistema se encuentra en un paquete y esto se hace con la intención de modularizar que es una de las características mensionadas en el capítulo de fundamentos al principio del trabajo.
//Se puede ver cuales son las clases que MainApplication
//extiende y l a s interfaces que implementa.
public class MainApplication extends Frame
implements WorkgroupInterface, FirstgroupInterface, Serializable,
Remot e,
ActionListener,
WindowListener €
//se da la descripción de las variables empleadas
/**
Referencia al servidor*/
private FirstInterface server; private String addressserver; private String userhlame; private String grouphlame;
/**
Indica si está conectado ha algún servidor*/
private boolean state;
/**
Contiene los nombres de los usuarios que estan en el mismotema
*/
private Vector partners;
/**
Contiene los nombres de todos los usuarios del sistema*/
private Vector allUsers;
/**
Contiene los temas existentes en el servidor*/
private Label statusBar;
private TextApplication textApplication; private DrawApplication drawApplication;
public MainApplicationo {
state = false;
userName =
setMenuBar(new HenuMainApplication(this));
area = new ChatArea(this1;
add("Center",area) ;
statusBar = new Label("",Label .RIGHT) ;
add("South",statusBar);
pack() ;
1
//Esta función se encarga de obtener y verificar el nombre de
// usuario
public void actionPerformed(ActionEvent e) €
Vector v;
String S ;
Object o = e.getSource();
if ( o == area.msgField
I I
o == area. send) {S = area.msgField.getText0;
if(s.length() > O) { //verifica que el nombre
S = userName
+
'I: 'I+
S+
"\n"; //no tenga longitud ceroarea.addMessage(s); //y obtiene a los
area. msgField
.
setText ("") ;area. msgField
.
requestFocus ( ) ;v = area.getAlXPartners();
send(s,v) ;
// del usuario
// usuarios del grupo
1
1
S = e. getAct ionCommand() ;
if ( s == "salir") {
1
if (s == "item 1")
4:
//para una aplicación de tiposalir();
// texto
textApplication = new TextApplication(this,
textApplication.setLocation(l00,100); textApplication.setVisible(true);
"Text application : : I' + userName,this) ;
if(s == "item 2 " ) € //para una aplicación de
// dibujo
drawApplication := new DrawApplication(this,
drawApplication. setLocation(100,lOO) ;
drawApplication.setVisible(true);
"Draw application : : I'
+
userName,this);3
3
/**
*
Realiza la conexión con el servidor obteniendo lista de*
temas y de usuarios.*/
public boolean connecting(String address)
c
addressserver = " / , P
+
address+
"/Firstserver"; try €UnicastRemoteObject .exportObject(this) ;
server = (FirstInterface)Naming.lookup(addressServer);
if (server == null) €
3
return false;
server.getListWorks(this);
3
catch(Exception e) {System.out.println(
e.printStackTrace();
return false ;
"Error en MainApplication::connecting()");
3
return true;
3
/**
*/
*
Termina la conexi6n con el servidor.public void disconnecting()
<
try C
server.logoff(userNae,groupName);
state = false;
3 catch (Exception e) C
System.out.println(
"Error en MainApplication: :disconnecting()");
3 3
*
Obtiene la direcc:i6n del servidor con el que se tiene*
conexion.*/
public String getAddress0
<
return addressserver;
public Vector getAllUsers() {
return allUsers;
1
/**
*/
*
Obtiene el nombre del grupo donde se est& trabajando.public String getGroup0 {
1
return groupName ;
public Vector getpartnerso
<
return partners;
3
public Vector getThemes0 {
return themes ;
1
/**
*/
*
Obtiene el nombre de usuario que se est& usando.public String getuser() {
return userName ;
3
/**
*
Asigna un nombre de usuario y un nombre de grupo.*/
public void register(String group,String user) {
WorkServerInterface workserver; try
<
workserver =(WorkServerInterface)
userName = user;
groupName = group;
if (workServer.login(this,user)) {
Naming.lookup(addressServer);
server.registerTopic(group,user);
I
statusBar. setText("Name: "
+
user + " , Theme: "+
group) ;3
3
catch (Exception e) {System.out.println(
"Error en MainApplication::register(String,String)");
3
3
public void salir0
c
if(state == true)
System.exit(0); disconnectingo;
>
public void send(0bject o) C
send(o,partners) ;
3
/**
*/
*
Envía informaci6n a otros usuarios.public void send(0bject o, Vector toUsers)
String partner;
if( toUsers. size(>==O) C
tousers = partners;
try C
server. updateBuf f er (groupName , o) ;
3
catch(Exception e) CSystem.out.println(
System.out .println("
*
server.updateBuffer0");"Error en MainApplication: : send(0bject ,Vector)") ;
3
3
try C
for(int tmp = O; tmp < tousers.size0; tmp++) C
partner = (String)toUsers.elementAt(tmp);
if (userName. compareTo(partner) != O) C
server .unicastMessage(partner,o) ;
3
3
3
catch(Exception e) CSystem.out.println(
System.out.println("
*
server.unicastMessage()");"Error en MainApplication::send(Object,Vector)");
3
//
. . .
// Implementacih de WindowListener
//
. . .
public void uindowActivated(WindowEvent e) {
3
public void windowClosed(WindowEvent e) {
Object o=e.getSource();
if(o == textApplication) {
textApplication = null;
3
if(o == drawApplication) {
drawApplicat ion 1- null ;
3
3
public void uindowClosing(WindowEvent e) {
Object o=e.getSource(); if (o == textApplication) {
textApplicat ion. exit ( ) ;
3
if(o == drauApplication) {
drawApplication.exit();
3
3
public void windowDeactivated(WindowEvent e) {
3
public void uindowDeiconified(WindowEvent e) {
public void windowIconified(WindouEvent e) {
3
public void windowOpened(WindowEvent e) {
3
//
. . .
// Implementación de WorkgroupInterface
/**
*/
*
Recibe mensajes provenientes del servidor.public void displayConnect(String message)
throws RemoteException {
area. addHessage( message
+
"\n") ;area.msgField.requestFocus0;
3
/**
*/
*
Recibe la lista de usuarios de todos los grupos.public void updateUserList(Vector users)
throws RemoteException {
allusers = users;
String partner; area.removeAllUseru();
for(int tmp = O; tmp < users.size(); tmp++) {
partner = (String) users. elementAt (tmp) ;
if (userName. compareTo(partner) != O)
area.addAllUsers(partner);
3
//
. . .
/ / Implementaci6n de FirstGroupInterface
//
. . .
/**
*/
*
Recibe la lista de usuarios del mismo grupo.public void clients(Vector users) throws RemoteException {
partners = users;
String partner; area.removeUsers0;
for(int tmp = O; tmp < users.size0; tmp++) {
partner = (String) users.elementAt(tmp);
if(userName.compareTo(partner) != O)
area.addUsers(partner);
3
3
public void content(0bject o) throws RemoteException
<
/**
*/
*
Recibe informaci6n de otros usuarios.public void displayHessage(0bject o) throws RemoteException {
String S= o. getclass ( )
.
getlame() ;System-out .println("Recibiendo: I' + S ) ;
if(s.compareTo("java.1ang.String") == 0 ) {
area.addHessage((String)o);
3
else if(s.compareTo("Works.Text") == 0 ) {
textApplication.recive((Text)o);
if(textApplication!=null) {
3
1
else if(drawApplication!=null) {
drawApplication.recive((Forma)o);
3
3
/**
*/
*
Recibe la lista de temas disponibles en el servidor.public void updateTopics(Vector themes)
throws RemoteException {
this.themes = themes;
3
/ /
. . .
public static void main(String arg[]) {
int aux; Vector v; boolean b; AddressDialog a;
RegisterDialog r ;
MainApplication m = new MainApplication();
a = new AddressDialog(m,"Server address:",ll);
a. setTitle("Server address") ;
a.setLocation(i00,100); a.setVisible(true);
if(a.getEstado0 == false) {
m.salir0;
3
System.out.print("1ntentando conexi6n con el servidor 'I+
a. getTexto( )+'I
. . .
") ;r = new RegisterDialog(m);
System.out.print("0bteniendo temas
. . .
"1;
v = m.getThemes0;
System.out .println("listo");
if(v != null) C
System.out.println("Cargando") ;
for(aux = 0;aux <: v.sizeO;aux++) C
3
r.addGroupList((String)v.elementAt(aux));
3
System.out .print("Obteniendo usuarios
. . .
" ) ;v = m.getAllUsers();
System.out.println("listo");
if (v != null) C
System.out .println("Cargando") ;
for(aux = 0;aux < v.size();aux++) C
3
r.addUserList((String)v.elementAt(aux));
3
r. setTitle("User register") ;
r
.
setLocat ion( iO0,ioO) ;r.setVisible(true);:
if(r.getEstado() == false) -(
3
m. salir0 ;
m.register(r.getGroup(),r.getUser());
m.addWindowListener(new ¡fina()); m.setTitle("REMM Application") ;
m.setLocation(i00,100);
m.setVisible(true) ;
3
1
class wina extends WindowAdapter {
public void windowClosing(WindowEvent e){
System. exit (O) ;
El texto dentro del código da una descripción de cada una de las funciones.
Las clases se encuentran dentro de paquetes para obtener modularidad en el sistema. Existen 3 paquetes uno de ellos es works en donde se encuentran
l
asclases relacionadas con el cliente, en el siguiente paquete se encuetran las
clases relacionadas con el servidor y en el último paquete se encuentran las interfaces utilizadas. Se trata de agrupar en forma lógica las clases para obtener la modularidad buscada.
3.2.2
Servidor
La jerarquía de clases del Servidor-ver figura 3.2-que se presenta es explicada a continuación.
En el diagrama se puede ver como las interfaces extienden a la interface Java.Rmi.Remote para poder implementar la comunicación.
Firstserver y WorkgroupServer se encargaran de implementar las funciones de las interfaces. Algunas de las funciones más reelevantes se presentan a con- tinuación:
En el caso de broadcastConnect() se desea de implementar un multicast (enciar mensage a todos los usuarios que pertenecen a un mismo grupo de trabajo).
o Con las funciones logoin() y logoffw() se pretende conectar y desconectar del al sistema a un usuario registrandolo en una lista o eliminandolo de ésta.
La función connect() recupera la ista de clientes en caso de encontrar usuarios.
La clase Register será la estructura de la lista junto con los métodos que se encargarán de manipular sus elementos(como AddRegisterO, Erase() y Seek()) A continuación se da el código de una de las clases más importantes del servidor que es Workgroup9 , erver.
package Server; //Este es el paquete donde se encuantran las
import Interface.*; //relacionas con el servidor import java.rmi.*;
import java.rmi.server.*;
import java.rmi.registry.LocateRegistry; import java.util.*;
import j ava.
*
;~~
En el código anterior puede verse el uso del paquete server para agrupar los elementos que forman parte del servidor. Y enseguida comienza el código de la clase WorkgroupServer.
//Esta clase se vale del unicast para implementar
// la comunicación
public class WorkgroupServer extends UnicastRemoteObject
implements WorkServerInterf ace {
//Se declara un Hashtable para enlistar los usuarios
// y su referencia
protected static Hashtable broadcastList = new Hashtable();
public WorkgroupServer() throws RemoteException {
3
super (
1
;public void connect(Workgroup1nterface client)
throws RemoteException
<
if (!broadcastList.isEmpty()) € //checa si hay usuarios
Vector v = getuserlist(); //obtiene la lista de clientes
// verifica que cliente se conecto para
// actualizar la lista
try €
//hace una llamada remota enviando la lista
// de clientes
client.updateUserList(v);
System.out.println("Error en WorkgroupServer::connect");
System. out. println("WorkServer error: I'
+
e.printStackTrace();
1
catch (Exception e) €e. getMessage() ) ;
3 3
1
public void logoffW(String user) throws RemoteException {
// remove el cliente desde broadcastList
// permitiendo que cada uno de los clientes conozca
// su salida
if (broadcastList.containsKey(user)) {
broadcastList
.
remove(user) ;String message;
broadcastconnect (message) ;
System.out.println(message);//despliega en consola la
// salida del cliente
3
Vector userList = getUserList0;
Enumeration e = broadcastList.elements();// enumara los
// clientes
// conectados.
while (e.hasMoreElements()) {
WorkgroupInterface c = (WorkgroupInterface)
updateUserlist(c, userlist); //actualiza la lista
e. nextElement
(1
;3
public synchronized boolean login(Uorkgroup1nterface client,
String user)
throws RemoteException {
if (broadcastList
.
containsKey(user1)//si el usuario esta contenido manda un mensaje client. displayconnect ("Login name ' I ' + user +
" '
is already in use."+
"\nPlease type another user name. ' I ) ;return false;
3
// si el usuario no esta adentro de la lista
// el user se usa como llave y client como valor
// de la llave
broadcastList.put(user, client);
broadcastconnect (user + I' has entered the Workgroup") ;
System-out .printlnCuser + I' has entered") ;
Vector userList = getUserList ( ) ;
// enumera los clientes conectodos.
Enumeration e = broadcastList
.
elements ( ) ;while (e.hasMoreElements0) {
WorkgroupInterface c = (WorkgroupInterface)e.nextElement();
//actualiza sus listas
updateUserList (c ~ userlist) ;
3
return true ;
3
public void broadcastConnect(String message) {
/ / enumera las llaves
// y manda un mensaje a todos los clientes de la lista.
while (enum.hasMoreElements())
<
String key = (String) enum.nextElement();
WorkgroupInterf ace client = (WorkgroupInterf ace)
try { //hace uso de una llamada remota
client.displayConnect(message);
3
catch (Exception e) {System.out.printh(
System.out.println("Connect:
+
e.getMessage0);e.printStackTrace0;
broadcastList.get(key);
"Error en WorkgroupServer::broadcastConnect");
3
1
3
private Vector getuserlist() {
Vector v = new Vector(); // hace un vector de usuarios.
Enumeration e = broadcastList.keys();
while (e.hasMoreElements()) {
String user = (String) e.nextElement();
v.addElement(user);
3
return v;
3
private void updateUserList(Workgroup1nterface client,
Vector userlist) {
// verifica que cliente se conecto para actualizar
// la lista
try {
client.updateUserList(userList);
1
catch (Exception e) {System.out.println(
System.out.printXn("updateList error: 'I + e.getMessage());
e. printStackTrace() ;
"Error en Workgroupserver : :updateUserList") ;
3
1
3Los siguientes diagramas presentan una parte del modelo más detallada mostrando cómo interaccionan alsclases relacionadas. En el primer caso se
\
i
La figura que se muestra enseguida muestra a Textkpplication refI'extAp. El diagrama de la clase AdressDialog permite ver cuales son alsclases con
l
asque interactúa refDialog.
Por último se tiene el diagrama que muestra las relaciones entre la clase encargada de serializar los objetos y las clase de forma y texto refserial. La clase de forma se vale a su vez de otras clases que le permitirán dibujar rectángulos, circulos y líneas.
il./
/
/ !
I
j \
\
main ( )
getlistwork() unicastMessage()
updateBuf f er ( )
registerTopic0
updateuser()
logoff ( )
Register()
add (
1
erase ( )
seek()
Workgroupserver
connect ( )
logoffw()
login()
broadcastConnect ( )
getUserList ( )
updateUserList ( )
AddressDialog
actionPerformed() actualizarEstado()
cerrar ( )
getEstado() getTexto() setvisible0
Descripción
Es la parte servidor del sistema, encargada de permitir la entrada a los usuarios al sistema
y de almacenar los temas de trabajo programa servidor del sistema
envía al usuario la lista de temas registrados envía un objeto a un usuario específico actuliza el buffer del servidor
realiza el registro de un usuario y su tema da de baja a un usuario
actualiza la lista de usuarios a cada usuario con un tema en común
Es una lista ligada para contener a los usarios de un tema en común, manteniendo un buffer para el trabajo echo por los mismos
inserta un nodo a la lista borra un nodo de la lista busca un nodo dentro de la lista
Es usado por el servidor para enviar información
a todos los usuarios, también para dar de alta y
de baja a los usuarios del sistema
envía a cada usuario la lista de usaurios de todo el sistema
borra a un usuario de la lista y avisa a los demás usuarios
inserta un usuario a la lista y da aviso a los demás usuarios
envía un mensaje a todos los usuarios del sistema
regresa una lista de todos los usuarios del sistema
envía la lista de usuarios de todo el sitema a un usuario
Es una interfaz gráfica, donde se pide al usuario una dirección válida de un servidor con el que se
quiera conectar
maneja las acciones al oprimir los botones revisa si se ha introducido información antes de continuar
es llamado antes de terminar la ventana de dialogo
da el valor del botón oprimido por el usuario da el texto intriducido por el usuario
-
Descripción
Tiene un conjunto de métodos que deberán cumplir las aplicaiones usadas por MainApplication
para revisar que se pueda cerrar una aplicacion para recivir objetos de una aplicación externa para enviar objetos a una aplicación externa Es una forma usada por la aplicación de dibujo que permite dibujar círculos
dibuja un círculo en un objeto panel.
Es una forma usada por la aplicación de dibujo que permite dibujar círculos con relleno
dibuja la figura en un objeto panel Interfaz gráfica creada para tener una área donde se puedan recibir mensajes, otra donde se pueden editar los mensajes a enviar y una más que muestra los destinatarios posibles sirve para insertar nombres en la lista de todos los usuarios
sirve para insertar nombres en la lista de los usarios compañeros
para mostrar texto en el áres de mensajes borra todos los nombres de la lista de los usuarios compañeros
quita todos los nombres de la lista de todos los usuarios
obtiene una lista con los nombres escojidos en ambas listas por el usuario
Es la aplicación de dibujo, contiene un área para relalizar dibujos, provee por medio de un menú las formas a dibujar y los colores maneja las acciones del mouse y el menú
es llamado antes de terminar la aplicación obtiene un objeto de figura, para que sea dibujado por la aplicación
envía un objeto de figura, para que sea transmitido
muestra u oculta la ventana.
sirve para escojer y abrir un archivo. sirve para guardar en un archivo las figuras dibujadas
- -
Clase o Método
saveAsFile()
readFile()
writefile()
DrawArea
crear ( )
dibujaro dibujaro
getcolor ()
getDraw ( )
getTipo ( )
paint ( )
setcolor() setTipo() Forma dibujar() setcolor0 Linea dibujaro HainApplication main() actionPerformed() connecting() disconnecting()
exit ( )
Descripción
guarda en un archivo las figuras dibujadas, pidiendo un nombre para el archivo a crear lee de un archivo la información de las figuras para dibujarlas
escribe en un archivo las figuras actualmente dibujadas
Define un área donde se puede realizar dibujos dado unas coordenadas y un tipo de figura se crea un objeto de figura para que sea dibujado dibuja en el área un figura
dibuja en el área una figura y además da la opción de enviarla
obtiene el color actual que se está utilizando obtiene en una lista las formas dibujadas en el área
obtiene el tipo de la figura que se está utilizando
redibuja las formas cuando es necesario pone el nuevo color a utilizar
establece el nuevo tipo de figura a utilizar Clase de donde serán dervadas las demás formas para dibujo
para que sea dibujada la figura en un objeto Panel
cambia el color de la figura
Es una forma usada por la aplicación de dibujo que permite dibujar líneas
dibuja una línea en un objeto panel
Es la interfaz con el usuario, es la encargada de contactar con un servidor dada una dirección
y de obtener los temas disponibles, así como de enviar y recibir información de los otros usuarios vía el servidor
programa cliente
maneja las acciones del menú
esta encargada de iniciar la conexion con el servidor
termina la conexión con el servidor
método que es llamado cuando se quiere terminar el programa
’
Clase o Método
getAddress0
getAllUsers()
getGroup0
getpartners ( )
getThemes ( )
getuser ( )
register()
send ( )
send ( )
uindouActivated() windowClosed() windowClosing() windowDeactivated()
windowDeiconif ied()
windouIconified() windowOpened()
displayconnect ()
updateUserList ( )
clientso
updateTopics ( )
displayMessage()
content ( )
MenuDrauApplication createMenuColors() createMenuFile0 createMenuItem() createMenuTools() MenuMainApplication createMenuApplication() createMenuFile0 createMenuItem0
-
Descripciónda la dirección del servidor con el cual se tiene la conexión actual
da una lista de los usuarios que estan usando el sistema
da el nombre del grupo al cual se ingresó da una lista de los usuarios que estpan en el mismo tema
da una lista de temas o grupos disponibles en el sistema
da el nombre del usuario que se está usando realiza el registro de un usuario y de su tema envía un objeto a todos los usarios del mismo tema
envía un objeto a una lista de usuarios específica
no usada
activada cuando se cierra alguna aplicación activada antes de cerrar alguna aplicacion no usada
no usada no usada no usada
implmentacion de WorkgroupInterface implmentacion de WorkgroupInterface implmentacion de FirstgroupInterface implmentacion de FirstgroupInterface implmentacion de FirstgroupInterface implmentacion de FirstgroupInterface Es le menú usado por DrawApplication crea un menú para la elección de colores
crea un menú con las opciones de guardar, abrir, cerrar
inicializa los items de menú
crea un menú para elejir un tipo de herramienta de dibujo
Es el menú usado por MainApplication crea un menú para la elección de aplicación crea un menu para cerrar la aplicación inicializa los items de menú
