Sie sind auf Seite 1von 106

DISEÑO Y DESARROLLO DE UN PROTOTIPO BAJO EL PARADIGMA DE ORIENTACIÓN A OBJETOS Y LA ARQUITECTURA CLIENTE/SERVIDOR

PABLO JESÚS MOGOLLÓN SOMAVILLA

150327

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER ESCUELA DE INGENIERÍA DE SISTEMAS SAN JOSÉ DE CÚCUTA

1996

ii

DISEÑO Y DESARROLLO DE UN PROTOTIPO BAJO EL PARADIGMA DE ORIENTACIÓN A OBJETOS Y LA ARQUITECTURA CLIENTE/SERVIDOR

PABLO JESÚS MOGOLLÓN SOMAVILLA

150327

Trabajo de grado presentado para optar al título de Ingeniero de Sistemas.

DIRECTOR: MARTÍN CALIXTO Ingeniero de Sistemas

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER ESCUELA DE INGENIERÍA DE SISTEMAS SAN JOSÉ DE CÚCUTA

1996

iii

AGRADECIMIENTOS

El autor expresa su agradecimiento a:

MARTÍN CALIXTO, Ingeniero de Sistemas, Profesor de la Escuela de Ingeniería de Sistemas de la Universidad Francisco de Paula Santander y director de este trabajo.

DÉBORA DAZA DURÁN, Licenciada en Bibliotecología, Profesora de técnicas de redacción de la Universidad Francisco de Paula Santander y asesora metodológica de este trabajo.

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER.

ROSA M. SOMAVILLA BUENO, profesora de español del Colegio Santo Ángel.

PABLO P. MOGOLLÓN SÁNCHEZ, Doctor Universidad Francisco de Paula Santander.

en Química, Ingeniero Civil,

Profesor de la

NINOTCHKA REY PERDOMO. Estudiante de Filología de la Universidad Nacional.

JUAN C. ESTIVARIZ COVALEDA. Ingeniero de Sistemas de la Universidad Francisco de Paula Santander.

UNISOFTWARE Ltda.

Todas aquellas personas que en una u otra forma colaboraron en la realización del presente trabajo.

iv

TABLA DE CONTENIDO

 

pág.

INTRODUCCIÓN

1

1

PROGRAMACIÓN ORIENTADA A OBJETOS

2

1.1 DESARROLLO EVOLUTIVO

2

1.2 PUNTO DE VISTA DEL PROGRAMADOR

4

1.3 FORMALIZACIÓN DE CONCEPTOS

5

1.3.1 Abstracción

7

1.3.2 Encapsulamiento

8

1.3.3 Modularidad

9

1.3.4 Jerarquía

10

1.3.5 Tipificación

11

1.3.6 Concurrencia

12

1.3.7 Persistencia

13

 

1.4

CARACTERÍSTICAS DEL MODELO DE OBJETOS

13

1.4.1 TAMAÑO DEL SISTEMA

14

1.4.2 TIEMPO DE RESPUESTA

14

1.4.3 REUTILIZACIÓN DE CÓDIGO

14

1.4.4 MANTENIMIENTO DE LA APLICACIÓN

15

2

ARQUITECTURA CLIENTE SERVIDOR

16

v

2.2

IMPLEMENTACIONES DE LA ARQUITECTURA CLIENTE/SERVIDOR

19

2.2.1 Presentación distribuida

19

2.2.2 Presentación distribuida y lógica de aplicación

19

2.2.3 Modelo de servidor de base de datos

20

2.2.4 Modelo de servidor de transacciones

20

2.2.5 Modelo

21

2.3

TIPOS DE SERVIDORES

21

2.3.1 Servidores concurrentes e iterativos

21

2.3.2 Servidores orientados a conexión y no orientados a conexión

21

2.3.3 Servidores con información de estado y sin estado

22

2.4

VENTAJAS DEL MODELO CLIENTE/SERVIDOR

22

3 SOCKETS, UNA INTERFAZ PARA TCP/IP

24

 

3.1 TCP/IP

24

3.2 SOCKETS

25

3.3 PROTOCOLOS DE TRANSPORTE TCP/IP

27

 

3.3.1 TCP

27

3.3.2 UDP

28

4. ESPECIFICACIONES

30

4.1 INTRODUCCIÓN

30

4.2 EL SERVIDOR

31

4.3 LOS CLIENTES

32

4.4 CÓDIGOS DE CARACTERES

32

4.5 MENSAJES

32

4.6 FORMATO DE UN MENSAJE EN NOTACIÓN BNF

33

4.7 RESPUESTA NUMÉRICAS

35

4.8 DETALLE DE LOS COMANDOS

35

vi

4.8.1.1 Comando PASS

36

4.8.1.2 Comando NICK

36

4.8.1.3 Comando USER

36

4.8.1.4 Comando QUIT

37

4.8.2

Comandos del servidor

37

4.8.2.1 Comando VERSION

37

4.8.2.2 Comando TIME

38

4.8.2.3 Comando ADMIN

38

4.8.3

Comando con destinatario específico

38

4.9

MENSAJES DE ERROR

39

4.10 RESPUESTAS A COMANDOS

40

4.11 ASPECTOS A TENER EN CUENTA

42

4.11.1 Autenticación de acceso

42

4.11.2 Protocolo de red

42

4.11.3 Construcción de comandos

42

4.11.4 Despacho de comandos

42

4.11.5 Archivo de configuración

43

4.11.6 Acceso de clientes

43

 

5 ANÁLISIS

44

5.1 INTRODUCCIÓN

44

5.2 ANÁLISIS ESTÁTICO

44

5.2.1

Identificación de clases

44

5.2.1.1 Reglas para seleccionar candidatos a clases

45

5.2.1.2 Selección final de clases

46

5.2.2 Diccionario de datos

47

5.2.3 Identificación de las asociaciones estructurales

50

vii

 

5.2.3.2

Lista final de las asociaciones

51

5.2.4

Identificación de atributos

52

5.2.4.1 Reglas para identificar atributos

52

5.2.4.2 Lista final de atributos

53

5.2.5

Refinamiento del modelo estático con herencia

53

5.3

ANÁLISIS DINÁMICO

54

5.3.1

Preparar escenarios

54

5.3.1.1 Escenario 1

55

5.3.1.2 Escenario 2

56

5.3.1.3 Escenario 3

57

5.3.2

Diagramas de estado

58

5.4

MODELO FUNCIONAL

60

5.4.1 Identificar información de entrada y salida

60

5.4.2 Diagramas de flujo de datos

61

5.4.3 Identificación de reglas de coherencia

62

5.5

DEFINICIÓN DE LA INTERFAZ

63

5.5.1 Interfaz del servidor

63

5.5.2 Interfaz del cliente

64

5.5.2.1 Definición del menú

65

5.5.2.2 Ventana de conexión

66

5.5.2.3 Ventana para mensajes privados

67

5.5.2.4 Ventana para emoticones

68

5.5.2.5 Ventana Acerca de

68

 

6 DISEÑO

69

6.1 DIVIDIR EN SUBSISTEMAS

70

6.2 DEFINICIÓN DE ALGORITMOS

73

viii

6.2.2 Socket::Connect

75

6.2.3 Socket::Accept

75

6.2.4 Socket::Write

76

6.2.5 Socket::Read

76

6.2.6 Socket::OnWinSockEvent

76

6.2.7 Protocolo::Analiza

77

6.2.8 Mensaje::Parser

77

6.3

Diseño de las asociaciones

78

7. PROGRAMACIÓN

81

7.1

PROGRAMACIÓN DEL SERVIDOR

81

7.1.1 Apuntadores

81

7.1.2 Atributos redundantes

81

7.1.3 Ocultamiento de información

82

7.1.4 Ventanas de Windows

82

7.1.5 Manejo de módulos

82

7.1.6 Módulos de servidor

83

7.2

PROGRAMACIÓN DEL CLIENTE

85

7.2.1 Visual Basic y Programación Orientada a Objetos

85

7.2.2 Módulos de Visual Basic

84

8 CONCLUSIONES

87

9 RECOMENDACIONES

88

ANEXO 1. SOFTWARE DEL PROYECTO

90

ANEXO 2. LISTA DE NODOS INTERNET CON TEMAS SOBRE TCP/IP

92

BIBLIOGRAFÍA

94

ix

LISTA DE FIGURAS

 

pág.

FIGURA 1.

Grafo de clases

52

FIGURA 2.

Diagrama de eventos 1

56

FIGURA 3.

Diagrama de eventos 2

57

FIGURA 4.

Diagrama de eventos 3

58

FIGURA 5.

Grafo de estado de Mensaje

59

FIGURA 6.

Grafo de estado de Socket

59

FIGURA 7.

Grafo de estado de Protocolo

60

FIGURA 8.

Grafo de estado de Usuario

60

FIGURA 9.

Flujo de datos del sistema

61

FIGURA 10.

Flujo de datos del sistema de Chat

62

FIGURA 11.

Interfaz de servidor

64

FIGURA 12.

Ventana principal del cliente

66

FIGURA 13.

Ventana de conexión del cliente

67

FIGURA 14.

Ventana para mensajes privados

67

FIGURA 15.

Ventana de emoticones

68

FIGURA 16.

Ventana Acerca de

68

FIGURA 17.

Diagramas de subsistemas

71

FIGURA 18.

Diagrama de procesadores

73

FIGURA 19.

Diagrama de objetos.

80

x

LISTA DE TABLAS

 

pág.

TABLA 1.

Funciones básicas para sockets

26

TABLA 2.

Funciones de WinSock

27

TABLA 3.

Atributos asignados a las clases

53

TABLA 4.

Lista de operaciones de los objetos

74

TABLA 5.

Listado de módulos

83

TABLA 6.

Listado de módulos de interfaz del cliente

84

TABLA 7.

Listado de módulos de código del cliente

85

TABLA 8.

Listado de extenxiones de Visual Basic del cliente

85

INTRODUCCIÓN

Las exigencias de calidad y desempeño de los sistemas están cambiando constantemente. La ubicua

presencia de Internet, el concepto de trabajo en grupo, las bases de datos remotas, las modernas

plataformas multitarea de 32 bits, están permitiendo la creación de complejos sistemas distribuidos.

Ante este panorama, el ingeniero de software se ve obligado a enfrentarse a sistemas cada vez más

complejos y difíciles de desarrollar y mantener. Existen dos metodologías para facilitar el desarrollo

exitoso de estos sistemas: la programación orientada a objetos y la arquitectura cliente/servidor.

Aunque en nuestro medio se reconoce la importancia de estas metodologías, es poco el uso efectivo

que se hace de ellas. Esto podría producir un desfase entre la tecnología local y la tecnología de punta

similar al que produciría en estos momentos el desconocer o no aplicar la programación estructurada.

Este trabajo de grado quiere precisamente mostrar las aplicaciones de la programación orientada a

objetos y del cliente/servidor, con el propósito de animar a otros estudiantes de Ingeniería de Sistemas

de la Universidad Francisco de Paula Santander a conocer y aplicar estas técnicas. Primero se presenta

la teoría básica requerida para entender el comportamiento esperado del sistema, y posteriormente se

muestra todo el proceso de desarrollo de un prototipo que utiliza plenamente estas metodologías.

1 PROGRAMACIÓN ORIENTADA A OBJETOS

La programación orientada a objetos es una filosofía de análisis y desarrollo de sistemas con más de 25

años de evolución: sin embargo, sólo hasta ahora comienza a popularizarse entre los ingenieros de

software como una de las herramientas mas potentes para enfrentar la creciente complejidad de los

sistemas de computación que exige el mercado. Para tratar de dar a entender en que consiste el

Paradigma de Orientación a Objetos, se darán tres puntos de vista de esta metodología: primero, el

desarrollo

evolutivo

a

partir

de

metodologías

tradicionales;

posteriormente,

el

significado

del

paradigma para el diseñador; y por último, se presentara de manera más formal y profunda haciendo

énfasis en las ventajas y desventajas de la aplicación de la metodología.

1.1 DESARROLLO EVOLUTIVO

Aunque los avances en arquitectura de computadoras, lenguajes de computación, modelos de bases de

datos y en inteligencia artificial influyeron enormemente, se puede considerar que esta metodología es

el resultado de la evolución natural que parte de la programación estructurada, como se verá más

adelante, y no de una revolución de la ingeniería de software, que declaran algunos autores poco

avisados.

En la programación estructurada se encuentra que un programa se puede definir como la suma e

interacción de datos más un código.

3

PROGRAMA = DATOS + CÓDIGO

Se puede dividir el código en dos componentes: uno dedicado exclusivamente a la solución del

problema y otro dedicado al manejo de datos.

Esto se debe a que los datos por sí solos son un ente

inerte y sin significado. Por ejemplo, un arreglo de valores dentro de un programa no tiene significado

real hasta que aparece el código que permite sumar sus valores, encontrar un valor determinado, añadir

o retirar un elemento, etc. Este es un código que no está dedicado a la solución del problema, sino que

su fin es sólo manejar los datos. Así la parte de código que si se dedica a resolver el asunto del

programa puede hacer uso efectivo de los datos.

En las metodologías

más antiguas de programación, como la monolítica, estos dos códigos están

completamente mezclados y son indistinguibles; bajo los principios de la programación estructurada se

separa el código según su funcionalidad, pero el código que maneja datos sigue incrustado en el código

de solución. Por último, en la orientada a objetos estos dos códigos se separan físicamente de modo

que la ecuación se convierte en:

PROGRAMA = (DATOS + CÓDIGO DE DATOS) + CÓDIGO DE SOLUCIÓN

Los datos y el código de datos están íntimamente ligados: uno pierde significado si no interactúa con

el otro. Es un paso natural agruparlos, de manera que cada ítem de datos simple o complejo se

encuentre atado al código que lo convierte en un ente activo. Al estudiar esta asociación se pone en

evidencia que este nuevo ente es un modelo de los objetos que componen la realidad del dominio del

problema. Volviendo al ejemplo del arreglo, el nuevo ente compuesto por la definición de datos y las

diferentes rutinas que operan esos datos tiene un significado completo independiente del programa en

el cual esté incluido. Todas las características y funcionalidad necesarias de un arreglo se encuentran en

este nuevo ente al que ya se le puede llamar objeto.

4

1.2 PUNTO DE VISTA DEL PROGRAMADOR

Desde el punto de vista del programador, independientemente del origen y evolución de esta

metodología, los objetos son el medio por el cual se modela el mundo real sobre un sistema de

computación. Por cada objeto que el ingeniero de software encuentre en el sistema que está estudiando,

existirá un objeto correspondiente en el sistema de computación que tendrá un estado representado por

los datos y un comportamiento, representado por un código (métodos asociados a ese objeto). Esta es

la característica y el fin principal de los objetos: representar las cosas del mundo real, encapsulando

pedazos de conocimiento y de complejidad del problema en unidades con significado completo: divide

el problema en secciones y subsecciones cada vez más sencillas. Por ejemplo, en un sistema de

contabilidad manual encontramos el libro diario. El diseñador que está creando un sistema de

contabilidad, creará un objeto lógico correspondiente con todas las características y funcionalidad del

objeto material que son necesarias para el sistema. El resto del sistema interactuará con ese libro diario

en forma análoga a como sucede en el mundo material. La consecuencia de este proceso es que el

diseño del sistema lógico se vuelve mucho más natural pues se cuenta con los mismos objetos de la

realidad material que el ingeniero de software ya conoce. De esta manera, al analizar un sistema real, la

primera pregunta que se debe hacer es ¿qué cosas componen este sistema? A diferencia de la

programación estructurada, en que la primera pregunta es ¿qué hace el sistema?.

5

1.3 FORMALIZACIÓN DE CONCEPTOS

En este punto se tiene una cierta idea de qué es un objeto y cuál es su lugar dentro del proceso de

desarrollo de software. Es el momento de precisar y formalizar estas ideas y revisar las características y

alcances del Paradigma Orientado a Objetos.

Según Grady Booch (1994), la Programación Orientada a Objetos es un método de implementación en

el cual los programas son organizados como una colección cooperativa de objetos. Cada objeto

pertenece a una clase y cada clase se encuentra dentro de una jerarquía de relaciones de herencia o de

utilización. En esta definición aparecen dos términos nuevos: clase y herencia.

Una clase es la definición de un objeto; es decir, qué datos y objetos pertenecen a la clase, qué

subrutinas le proporcionan la funcionalidad o de qué otra clase se deriva. El objeto es una instancia de

la clase. Haciendo un símil con los tipos tradicionales de datos, el objeto es a la clase como la variable

al tipo de datos. De esta manera, podemos tener varios objetos en un programa que pertenecen a una

sola clase con funcionalidad idéntica y los mismos atributos, de la misma manera que podemos tener

varias variables de tipo entero.

La herencia, es la propiedad de la clase de tomar características de otras clases previamente definidas.

Por ejemplo, se tiene una base de datos de automotores, se puede tener una clase automotor con las

características mínimas de estos vehículos. Con está clase puedo crear las clases moto, automóvil, y

camión que tienen todas las características de automotor y añaden algunas más como número de

ruedas, capacidad de carga, etc. Incluso se puede seguir refinando la clase automóvil en las clases hijas

sedán y coupe. De esta manera, se van definiendo clases muy precisas sin repetir las especificaciones

comunes entre ellas. En el caso anterior se suele decir que automotor es la clase padre o superclase de

moto, automóvil y camión, y automóvil lo es de sedán y coupe.

6

Otro detalle que hay que tener en cuenta es que algunas clases se crean sólo para proveer una

funcionalidad básica que será heredada posteriormente por otras clases, pero que no están destinadas a

tener instancias propias. A estas clases se les llama metaclases. En el anterior ejemplo es probable que

no se cree nunca un objeto de la clase automotor, si no que se utilizará solamente como base de las

clases camión, moto y automóvil; por lo tanto, automotor es una metaclase. Por otro lado la clase

automóvil tal vez tenga instancias propias y a la vez es superclase de sedán y coupe.

Continuando con las definiciones dadas por G. Booch, el Diseño Orientado a Objetos (DOO) es un

método de diseño que incluye un proceso de descomposición de un sistema en objetos (se hace una

abstracción del sistema para encontrar sus componentes más importantes) y una notación para describir

los modelos lógico y físico, así como estático y dinámico, del sistema bajo diseño. Las dos ideas

principales son la descomposición por objetos y el uso de múltiples vistas del problema para tener

simultáneamente una visión global y en detalle del sistema. Dada esta definición del Diseño Orientado

a Objetos, el Análisis Orientado a Objetos (AOO) es el método de análisis que examina los

requerimientos del sistema desde la perspectiva de las clases y objetos encontrados dentro del dominio

del problema.

El análisis, diseño y programación orientados a objetos

se relacionan estrechamente: el diseño hace

uso de los productos que resultan del análisis y la programación hace uso de los productos del diseño.

Dadas las características del Paradigma de Orientación a Objetos, estas tres etapas de desarrollo de

programas no son comportamientos estancos, ni siguen un orden rígido. La posibilidad de tener

diferentes vistas

del problema y con diferente nivel de detalle permite una gran libertad a la hora de

decidir qué y cuando analizar, diseñar y programar.

7

Es conveniente tener en cuenta los conceptos anteriores para darse cuenta que trabajar sobre una

herramienta que maneje objetos no quiere decir siempre que se esté haciendo una programación real

orientada a objetos. El Paradigma de Orientación a Objetos tiene una filosofía clara, y el uso de una

herramienta que trabaje con objetos permite aprovechar las ventajas de esta tecnología. Como se verá

más adelante, el uso indiscriminado y sin bases de esta tecnología puede resultar en un pobre

desempeño del sistema que se desarrolla.

Hay cuatro conceptos fundamentales que enmarcan el modelo de Orientación a Objetos: abstracción,

encapsulamiento, modularidad y jerarquía. Existen también algunos conceptos menos importantes para

la definición del modelo de Orientación a Objetos, pero que se encuentran frecuentemente en la

aplicación práctica del modelo: reconocimiento de tipos, concurrencia y persistencia.

1.3.1 Abstracción. Es un modelo mental de un objeto en el cual se destacan las características

importantes para el observador y se ocultan aquellas que carecen de relevancia. Se pueden tener

diferentes vistas de un objeto con diferentes niveles de abstracción, de esta manera el desarrollador

puede elegir qué grado de complejidad quiere enfrentar. Inicialmente la abstracción se enfoca sobre la

vista exterior del objeto y permite separar la definición de un objeto de su implementación: es decir, al

abstraer inicialmente un objeto se busca averiguar qué es y qué hace un objeto. Posteriormente, en

sucesivas vistas más detalladas se va encontrando cómo funciona interiormente.

Decidir cuál es el conjunto correcto de abstracciones para el dominio de un problema es el objetivo

principal del diseño orientado a objetos. Se encuentran varios tipos de abstracción cuyo conocimiento

puede facilitar la tarea:

Abstracción de entidades: La abstracción corresponde a un modelo de una entidad del dominio del

problema. Más claramente, la abstracción corresponde a uno de los objetos que pertenecen al ámbito

8

del problema. Esta es la más importante, dado que se obtienen directamente del vocabulario del

problema y el diseño se basa generalmente en este tipo de abstracciones.

Abstracción de Acción: Un conjunto de operaciones estrechamente relacionadas que se modelan como

un objeto.

Abstracción de máquina virtual: Un grupo de operaciones que se reúnen porque son usadas por algún

nivel superior de control u operación. Es decir, ocultan detalles innecesarios al resto de los objetos que

intervienen en el programa.

Abstracción coincidental: Es un grupo de operaciones que no se relacionan entre sí por su naturaleza

como en las abstracciones anteriores, sino porque se usan dentro del dominio del programa y quedarían

dispersas de otro modo.

1.3.2

Encapsulamiento.

Después

de

completar

la

abstracción

de

un

objeto

se

procede

a

su

implementación. Esta implementación debe ser un secreto para el resto de los objetos del programa sin

importar que tan estrechamente interactúan con él. De esta forma se impide que partes del programa

dependan del desempeño interno de otras partes. Como se puede ver, abstracción y encapsulamiento; la

abstracción observa el objeto por fuera, mientras que el encapsulamiento se ocupa de la estructura

interna del objeto. Básicamente el encapsulamiento quiere decir que un objeto se comporta como una

caja negra para los demás objetos: es decir, los demás objetos saben cómo comunicarse con dicho

objeto, cómo proporcionar y obtener datos, pero no tienen conocimiento de sus procesos internos ni

pueden intervenir en ellos; sólo conocen su interfaz.

Se puede decir que una clase se compone de dos partes, la interfaz que captura su parte exterior (la

abstracción) y la implementación que define el desempeño del objeto.

9

1.3.3 Modularidad. Dividir un programa en componentes más simples puede reducir la complejidad

del mismo. Estas partes pueden ser tratadas por separado en cuanto a diseño y desarrollo, pero debe

existir una serie de reglas que les permita comunicarse entre ellas para poder comportarse como un

todo. Lenguajes como C, Pascal y Ada soportan el concepto de módulo: segmentos de código que están

separados físicamente en diferentes archivos y que se combinan después para crear el programa. Estos

módulos suelen estar compuestos de una interfaz (las definiciones de funciones o procedimientos y la

correspondiente lista de parámetros) y la implementación (el código correspondiente a cada función o

procedimiento). Esto lleva a un cierto grado de encapsulamiento; sin embargo, en los módulos que son

base para la metodología de diseño y programación estructurada, se puede violar fácilmente el

encapsulamiento. En la tecnología de software basada y orientada según el concepto de objetos, este

encapsulamiento debe ser total. Otra diferencia entre la programación estructurada y la orientada a

objetos radica en el criterio de división de los módulos. En la programación estructurada se realiza de

acuerdo con las diferentes tareas que se espera que realice el sistema. En la Programación Orientada a

Objetos la división se realiza, en primer lugar, de acuerdo con la identidad de los componentes del

sistema y en segundo lugar, de acuerdo con su funcionalidad.

Otra de las grandes razones para la modularidad es la reducción del costo de compilación de un

programa. Si se debe cambiar parte de un módulo se compila sólo este módulo y posteriormente se

encadena con el resto del programa. En un programa monolítico, el costo de compilación aumenta con

el tamaño del programa hasta volverse inmanejable pues no se puede compilar separadamente un

segmento del programa. Los cambios en un módulo hace referencia a modificaciones que solamente

afectan a la implementación de un módulo. Si se cambia la interfaz del módulo, es decir, renombrar

funciones

o

procedimientos

o

modificar

las

listas de

parámetros,

los demás módulos que

se

comunicaban con el que se acaba de cambiar se verán afectados y se deberán modificar también.

10

De esta manera se debe tener en cuenta dos cosas a la hora de diseñar los diferentes módulos. La

primera es que el módulo debe ser cohesivo; es decir, debe ser un conjunto de abstracciones

estrechamente relacionadas. Esto disminuiría la probabilidad de que la necesidad de un cambio en el

código se extienda a más de un módulo y haría que se pueda tratar de forma local. La segunda

propiedad es que mantengan independencia con respecto a los otros módulos: en otras palabras, que

dependan lo menos posible de los otros módulos para cumplir su cometido.

1.3.4 Jerarquía. Hacer directamente una abstracción de todos los componentes de un sistema sólo es

factible en los casos más sencillos. Por eso se suele encontrar una jerarquía de abstracciones que

simplifican gradualmente el programa. Las dos formas más comunes de jerarquía en un sistema

complejo son: es parte de y es del tipo de. En el caso de la relación es parte de, una clase forma parte

de la estructura de otra o es usada por otra. En el caso de la relación es del tipo de, una clase es un

caso especial de otra de la misma manera que una margarita es un caso especial de una planta.

La herencia es el tipo más importante de jerarquía, define una relación entre clases en la cual una de

ellas (la clase hija) comparte estructura y/o comportamiento de la otra (clase padre o superclase).

Anteriormente se dio un ejemplo de herencia simple usando automotores: es decir, cada clase hija tenía

sólo una clase padre. También se puede dar el caso de la existencia de herencia múltiple. Por ejemplo,

para definir un individuo para un sistema de un departamento de recurso humano dentro de una

empresa se puede definir la clase persona con los datos de nombre, edad, documento de identidad,

dirección, estado civil, etc., y la clase trabajador con su código de identificación, fecha de entrada a la

empresa, cargo, etc. Estas dos clase modelan dos conceptos diferentes e independientes pero como se

está interesado en guardar datos de un individuo, se crea la clase empleado que hereda todos los datos

(atributos) y la funcionalidad de las clases persona y trabajador y se pueden adicionar nuevos atributos

o métodos.

11

Algunas veces es difícil definir cuándo es más conveniente usar una jerarquía es parte de, o una es del

tipo de. Un método sencillo, que funciona en muchos casos, es preguntar ¿la clase A es una

especialización de la clase B o la clase B es un componente de la clase A?. Por ejemplo, en el caso de

los vehículos, tal vez interesa que la clase automotor tenga algún conocimiento sobre las ruedas que

usa. Se crea la clase rueda con los atributos y métodos adecuados. Ahora bien, ¿qué es mejor, que la

clase automotor herede de la clase rueda o que ésta tenga una relación es parte de un automotor?. De

ambas maneras se consigue que automotor adquiera el conocimiento y funcionalidad de rueda; pero si

no se hace la elección adecuada, se presentarán problemas de diseño y programación posteriormente.

Formulando la pregunta de la siguiente manera las cosas se ven más claras: ¿La clase automotor es un

caso especial de rueda?, o ¿la clase rueda es un componente de automotor?. Como un automotor no es

una rueda, es claro que la relación conveniente será rueda es una parte de automotor, y por lo tanto se

implementa como un atributo de automotor. Por otro lado, en el caso de la clase empleado, es obvio

que un empleado es un trabajador y también es una persona, por lo tanto, debe heredar de las clases

correspondientes. En los ejemplos anteriores se han mostrado casos extremos. En el trabajo real, a

veces, no es tan fácil realizar una distinción adecuada al derivar una clase de otras.

1.3.5 Tipificación. El término real para el Diseño Orientado a Objetos debería ser clasificación, pero

este concepto proviene de la teoría de tipos de datos abstractos en la cual se usa el término de tipo y no

de clase.

La tipificación es el refuerzo de la clase de un objeto, de forma tal que dos objetos de diferentes clases

no pueden ser intercambiados, o por lo menos sólo pueden intercambiarse de formas muy restringidas.

De acuerdo con la herramienta usada se pueden tener diferentes formas de clasificación. La primera

corresponde a la rigidez con que la herramienta lo maneja. Esto quiere decir que existen lenguajes que

12

proporcionan un tipificación fuerte, lo que protege al programa de errores (como tratar de sumar un

nombre con un apellido), pero le quita flexibilidad. Existen lenguajes que proporcionan un tipificación

débil que ofrece más flexibilidad y menos seguridad. Por otro lado, también se puede hablar de

encadenamiento estático y dinámico; en el primero, se debe conocer la clase (el tipo) de un objeto en el

momento de compilación; en el segundo, la clase de un objeto puede ser desconocida hasta el momento

de ejecución. El encadenamiento estático es provisto por compiladores que suelen ser económicos y

que gozan de tiempos de compilación relativamente cortos, mientras que el encadenamiento dinámico

es usado por compiladores mucho más costosos y que al enfrentarse a estructuras de datos muy

complejas suelen presentar tiempos de compilación largos. Además, las llamadas entre funciones en un

programa compilado bajo encadenamiento dinámico son mucho más lentas que bajo un programa

creado con un compilador que haga uso de encadenamiento estático, aunque podrá gozar de mayor

flexibilidad.

Como una tipificación fuerte y encadenamiento dinámico son conceptos independientes, encontramos

que existen herramientas que pueden tener tipificación fuerte y encadenamiento estático (Ada),

tipificación fuerte y encadenamiento dinámico (Object Pascal y C++), o sin tipificación y con

encadenamiento dinámico (SmallTalk).

1.3.6 Concurrencia. Es el término para denominar aquellos programas que pueden dominar varios

hilos de control y a través de ellos varios eventos simultáneamente. Los sistemas que manejan

concurrencia se pueden considerar muy complicados por naturaleza. La concurrencia no es una

característica de la tecnología de Orientación a Objetos, pero las características de esta tecnología la

hacen apropiada para resolver los problemas causados por la concurrencia. La posibilidad de abstraer a

alto nivel los objetos del sistema permite ocultar los problemas de la concurrencia hasta llegar a niveles

más bajos donde la concurrencia es más fácil de manejar. Los sistemas concurrentes se benefician del

Paradigma de Orientación a Objetos, pues a través de éste se definen implícitamente las unidades de

13

distribución y movimiento y las entidades que se comunican. El modelo de Orientación a Objetos se

enfoca sobre la abstracción de datos, el encapsulamiento y la herencia, mientras que la concurrencia se

enfoca sobre la abstracción de procesos y la sincronización. El objeto es un concepto que unifica estos

dos puntos de vista, cada objeto puede representar un hilo de control separado (una abstracción de un

proceso).

1.3.7 Persistencia. El concepto de persistencia tiene que ver con el tiempo de vida de un objeto. Las

posibilidades de tiempo de vida de un objeto se pueden encontrar en el siguiente espectro:

Resultados temporales en la evaluación de expresiones.

Variables locales de procedimientos y funciones (existen mientras el hilo de control esté en la

subrutina).

Variables globales (existen durante la ejecución del programa).

Datos que existen entre ejecuciones del programa.

Datos que existen entre versiones del programa.

Datos que sobreviven al programa.

Las metodologías tradicionales suelen hacer uso de los tres primeros tipos de persistencia, los tres

últimos son característicos de la tecnología de base de datos.

Al añadir el concepto de persistencia a la tecnología de Orientación a Objetos, obtenemos las bases de

datos orientadas a objetos. En la práctica real, se hace uso de tecnologías probadas como la secuencial,

jerárquica de red o relacional, añadiendo las posibilidades de la abstracción característica de la

metodología de Orientación a Objetos.

1.4 CARACTERÍSTICAS DEL MODELO DE OBJETOS

14

En ésta, la última sección del capítulo de objetos, se aclaran algunos aspectos que no se suelen tener en

cuenta en los textos especializados y que ayudan a decidir si en un proyecto de software se deben usar

objetos o no.

1.4.1 Tamaño del sistema. Se recalca que la necesidad de nuevas técnicas de desarrollo de software

para tratar exitosamente problemas de gran complejidad fue el motor que originó la aparición del

Paradigma de Orientación a Objetos. Cuanto mayor es el tamaño del programa, menor es el costo en

tiempo y esfuerzo en comparación con otras tecnologías. Sólo después de un cierto grado de

complejidad y tamaño resulta más rentable hacer uso del Paradigma de Orientación a Objetos que de

otras tecnologías.

1.4.2 Tiempo de respuesta. Un programa desarrollado sobre una herramienta de programación

orientada a objetos suele ser muy lento debido a las estructuras complejas que debe utilizar para

manejar el encadenamiento dinámico. Existen herramientas mixtas (como C++ y Object Pascal) que

permiten mezclar programación estructurada y orientada a objetos simultáneamente y son más

eficientes. Sin embargo para sistemas de tiempo real, con necesidad

de respuesta muy rápida resulta

poco práctico hacer uso del Paradigma de Orientación a Objetos.

1.4.3 Reutilización de código. Una gran ventaja del Paradigma de Orientación a Objetos es que si el

objeto se diseña bien, puede ser usado en diferentes programas. Algunos autores llegan a mostrar un

futuro en que el desarrollo de software consiste en usar objetos de manera análoga a como se usan los

circuitos integrados en electrónica. Por ejemplo en los compiladores comerciales de lenguajes

orientados a objetos suelen traer las clases contenedoras: Lista, Pila, Cola, Arreglo, etc. que son de uso

general. Sin embargo se presenta un problema. Para que un objeto se pueda usar en cualquier programa

se le debe dar funcionalidad completa, lo que se conoce como sobrediseño. Pero en cada uno de los

15

programas en que se utilice, no se hace uso de todas las características, se estará desperdiciando

espacio de memoria con código que no se utilizará.

1.4.4 Mantenimiento de la aplicación. Una de las etapas que menos se planifican en el desarrollo de

software y que presentan más problemas a los ingenieros de desarrollo es el mantenimiento de los

programas ya terminados. Existen dos razones principales para que un programa necesite ser reparado:

que cambien las especificaciones y requerimientos sobre los cuales fue creado el programa, o que

existan defectos de programación que no fueron detectados a tiempo. En cualquiera de los dos casos se

debe analizar el código y reescribirlo. La división de un sistema en objetos permite aislar los defectos

de código más fácilmente. Cuando un objeto no se comporta del modo esperado, el daño se encuentra

dentro del código de ese objeto; en cambio, en la programación estructurada y en tecnologías más

antiguas, un defecto de código se puede propagar hasta manifestarse en una sección del programa muy

alejada del lugar donde se originó. Además, una modificación en el código de un objeto resulta en un

cambio de comportamiento del objeto que se puede evaluar fácilmente pues sólo afecta al objeto (esto

se debe a la encapsulación).

2 ARQUITECTURA CLIENTE/SERVIDOR

La evolución de los sistemas de computación ha proporcionado varias formas de procesamiento

distribuido, simplificando el desarrollo de las aplicaciones y maximizando el aprovechamiento de los

recursos. La arquitectura cliente/servidor constituye un caso especial conocido como procesamiento

cooperativo. Esta arquitectura se basa en la interactuación de dos procesos: uno de ellos, el proceso

cliente, solicita la realización de una tarea; el otro, el proceso servidor, recibe la petición, realiza las

tareas pertinentes y devuelve la información al primer proceso.

Un ejemplo muy frecuente se encuentra en las redes locales en las cuales existe un proceso servidor en

un computador muy potente y diferentes procesos cliente en computadores terminales más modestos.

Los procesos cliente solicitan al proceso servidor acceso a los archivos que se encuentran en el

computador central, el proceso servidor revisa la información, verifica los permisos de acceso y provee

los archivos solicitados.

Una de las características de este modelo es que se establece un orden en la comunicación entre el

cliente y el servidor. Siempre el cliente inicia la comunicación con la petición del servicio. El proceso

servidor desarrolla la tarea solicitada y responde al proceso cliente con la información pertinente. Esto

se puede repetir varias veces. Incluso, en sistemas de comunicaciones entre pares (peer-to-peer) se

considera que el proceso que inicia la comunicación es un cliente del proceso que responde.

17

Por lo general, el servidor es un proceso que desarrolla un conjunto de tareas complejas y/o

especializadas. Además, suele estar en capacidad de recibir y procesar simultáneamente peticiones de

diferentes clientes (esto se conoce como concurrencia). Esto permite que los procesos cliente sean

pequeños y sencillos. En el caso de la red local se puede tener un computador central con gran

capacidad de recursos como disco duro de gran capacidad, microprocesador potente, conexiones a

múltiples redes, y una serie de terminales más modestos, por ejemplo sin disco duro, unidos al servidor

central por medio de una red de área local. A medida que aumenta el número de usuarios esta

configuración resulta ser más ventajosa que tener equipos de rango medio para cada uno de los

usuarios y una copia de cada uno de los programas en cada computador.

Aunque el esquema básico del modelo es la pareja de procesos cliente y servidor, es común que un

programa sea cliente de varios tipos de servidores o que un servidor sea cliente de otro servidor. Un

ejemplo se encuentra en los programas que se ejecutan sobre plataforma Windows y hacen uso de las

capacidades de servidor de objetos OLE de programas como Word, Excel y otros. De esta manera, un

programa puede contener toda la capacidad de un procesador de palabra y de una hoja cálculo con muy

poco esfuerzo de desarrollo. Los archivos de encadenamiento dinámico (archivos DLL) que ofrecen

funciones comunes a diferentes programas constituye otro ejemplo de servidor. En el ejemplo anterior

se ve que este modelo no es exclusivo de la interacción de procesos remotos en aplicaciones de

comunicaciones, sino que también se utiliza para desarrollar aplicaciones locales.

Muchas veces los servidores necesitan tener acceso a datos, procesos o recursos que están protegidos

por el sistema operativo. Por eso el servidor opera con privilegios especiales y es responsable por

realizar una serie de actividades que eviten el acceso de personas inadecuadas a recursos protegidos.

Estas tareas son:

Autenticación: verificar la identidad del cliente.

18

Autorización: determinar los permisos de acceso de un cliente.

Protección de Datos: garantizar que los datos no son revelados de manera no intencional.

Privacidad: los datos sobre un usuario se guardan de modo que no exista acceso no autorizado.

Protección: garantiza que las aplicaciones que se ejecutan sobre la red no pueden abusar de los

recursos existentes.

2.1 NIVELES DE LA ARQUITECTURA

Los primeros sistemas con arquitectura cliente/servidor constaban de dos niveles. Uno lo constituían

los clientes que enviaban peticiones y otro nivel correspondía a los servidores que respondían a las

peticiones. Sin embargo, en los casos en que existe un alto nivel de procesamiento de transacciones en

línea y gran número de clientes los tiempos de respuesta pueden degradarse de manera apreciable. Por

lo tanto, puede resultar aconsejable tener tres niveles: en uno se encuentran los clientes y la lógica de

representación gráfica; en un segundo nivel, un procesador independiente maneja las operaciones sobre

los datos o lógica de la aplicación; por último, en un tercer nivel, se encuentra un procesador dedicado

al almacenamiento y administración de datos.

Un ejemplo de distribución de tres niveles de un sistema cliente/servidor suele resultar conveniente

para motores de base de datos populares como Microsoft SQL Server y Oracle. Cuando el software del

motor y los archivos de base de datos se encuentran en discos diferentes o, aun mejor, en computadores

diferentes; el desempeño global del sistema mejorará con respecto a un sistema que tenga el software y

los datos en el mismo disco duro.

19

2.2 IMPLEMENTACIONES DE LA ARQUITECTURA CLIENTE/SERVIDOR

Aunque la filosofía de la arquitectura cliente/servidor es sencilla, el desarrollador se encuentra siempre

frente al siguiente problema: ¿qué servicios deben estar en el servidor y cuales en el cliente?.

Es claro que los servicios del servidor resultan muy costosos en operaciones de comunicaciones, pero

los servicios en el cliente pueden hacer lentas las operaciones al recargar el procesador. Las funciones

principales en un sistema cliente/servidor son de interfaz de usuario, de lógica de la aplicación (qué

operaciones se realizan sobre los datos) y de lógica de proceso de base de datos (cómo se administran

los datos).

Existen algunos tipos de distribución de las funciones que se explican a continuación.

2.2.1 Presentación distribuida. En este caso el cliente es muy sencillo y sólo maneja la lógica de la

interfaz (presentación de información, ventanas, diálogos, ratón, etc.), mientras que toda la lógica de la

aplicación y del manejo de base de datos se encuentran en el servidor.

La ventaja de este enfoque es su implementación sencilla, pero no se está reestructurando la manera de

manejar información, lo cual es importante en la arquitectura cliente/servidor.

2.2.2 Presentación distribuida y lógica de aplicación. La interfaz gráfica y parte de la lógica de la

programación (validación de datos y procesos sencillos) son ejecutados por el cliente. Las tareas

restantes son procesadas por el servidor. De esta manera se disminuyen el trabajo del servidor, el

tiempo de respuesta y la carga sobre los medios de comunicaciones.

20

Este

modelo

es

particularmente

recomendable

para

aplicaciones

complejas

que

requieren

alta

interacción con el usuario y que poseen un alto nivel de operaciones de entrada y salida.

2.2.3 Modelo de servidor de base de datos. El servidor se dedica exclusivamente a la base de datos.

La lógica de la aplicación y la manipulación de datos es ejecutada por el cliente. De esta manera, una

aplicación puede soportar diferentes tipos de bases de datos en múltiples servidores. Se libera a los

servidores del procesamiento de la aplicación, mejorando su tiempo de respuesta.

Sin embargo, si existe mucho tráfico de información entre los servidores y los clientes pueden

originarse cuellos de botella en la red. Por lo tanto este tipo de distribución es recomendada para

aplicaciones con poco volumen de operaciones de entrada y salida.

2.2.4

Modelo

de

servidor

de

transacciones.

Este

modelo

se

utiliza

cuando

el

volumen

de

transacciones entre el servidor y el cliente es muy elevado. El servidor contiene tanto la lógica de la

aplicación para manejo de datos (SQL generalmente) como el manejador de base de datos, mientras

que el cliente contiene la interfaz del usuario y el resto de la lógica de la aplicación.

La información se encapsula en transacciones. Una transacción puede definirse como una secuencia de

acciones predefinidas que se realizan en favor de una aplicación y que la llevan de un estado

consistente a otro.

Este modelo es recomendable para aplicaciones que tienen transacciones críticas, como operaciones

bancarias, reservaciones de aerolíneas y casas de bolsa.

21

2.2.5 Modelo entre pares. El procesamiento distribuido y cooperativo tiene como finalidad que todos

los componentes del sistema sean tratados por igual y puedan solicitar o proporcionar servicios como

cliente o servidor indistintamente.

La manipulación de datos ocurre tanto en el cliente como en el servidor, dependiendo de cual es más

conveniente para una tarea específica. La base de datos se encuentra distribuida entre clientes y

servidores. Esto requiere excelente coordinación y existen aspectos de integridad y control que deben

ser analizados en gran detalle.

2.3 TIPOS DE SERVIDORES

Los servidores son el eje de este modelo y los procesos más difíciles de implementar. Existen varios

aspectos que definen el comportamiento de un servidor y que son importantes para el programador.

2.3.1 Servidores concurrentes e iterativos. Se usa el término Servidor Iterativo a aquel que procesa

una sola petición cada vez, y el termino Servidor Concurrente para el que puede procesar varias

comunicaciones al mismo tiempo. Casi todos los servidores parecen ser concurrentes. Sin embargo, los

que no realizan procesos muy extensos pueden responder varias peticiones por medio de entrada y

salida asincrónicas a través de varios canales. De esta manera el servidor trabaja en forma concurrente,

sin necesidad que la implementación de bajo nivel se base en múltiples procesos.

2.3.2 Servidores orientados a conexión y no orientados a conexión. Un servidor orientado a

conexión mantiene abierto un puerto para cada cliente lo cual implica gasto de recursos. Un proceso

servidor se diseña idealmente para que se ejecute por siempre ya que el cliente siempre espera que el

servidor se encuentre disponible cuando lo necesite. Puede pasar que el cliente inicie la comunicación

y después se caiga: el puerto permanecerá abierto sin poder ser usado realmente, a menos que existan

22

procesos que se encarguen de verificar periódicamente cada uno de los puertos, lo que aumenta la

complejidad del servidor. En un servidor no orientado a conexión, los puertos no están atados al

destinatario. Se puede usar un sólo puerto para comunicarse con todos los clientes con menor consumo

de recursos. Sin embargo, este tipo de servidor suele requerir esfuerzo adicional para asegurar que la

comunicación sea correcta.

2.3.3 Servidores con información de estado y sin estado. La información que guarda un servidor

sobre las peticiones que está procesando en un momento dado se suele llamar estado del cliente.

Existen servidores que no guardan ninguna información, Servidores sin estado, y servidores que

mantienen información acerca de su interacción con los clientes. Por un lado, conocer el estado de las

transacciones permite procesar la información más eficientemente: sin embargo, también puede causar

problemas. Si un cliente se cae y vuelve a conectarse, el servidor abre otra entrada de datos de estado,

empiezan a consumirse recursos ineficientemente y puede llegar a copar la capacidad del proceso

servidor. Se puede implementar un criterio para descartar entradas de la tabla de datos de estado, por

ejemplo el tiempo sin uso de una conexión. Se desecha la conexión menos recientemente usada. Pero si

un cliente se cae y reconecta con frecuencia, puede resultar que este criterio descarte entradas de datos

de estado de clientes que están legítimamente conectados.

2.4 VENTAJAS DEL MODELO CLIENTE/SERVIDOR

Teniendo en cuenta lo visto en este capítulo se puede decir que el modelo cliente/servidor presenta las

siguientes ventajas:

Integración

de

diferentes

procesamiento.

tipos

de

equipos

y

sistemas

operativos

en

un

único

ambiente

de

23

Inmediato crecimiento de la capacidad de cómputo del sistema. Las capacidad de computo ya no se

mide por la capacidad de un computador central, sino como la suma de la capacidad de todos los

equipos interconectados.

Mejor aprovechamiento de los medios de comunicación tanto locales como remotos.

La relación de costos frente al tiempo de respuesta y capacidad de procesamiento resulta favorable con

respecto a otras arquitecturas.

3 SOCKETS, UNA INTERFAZ PARA TCP/IP

3.1 TCP/IP

TCP/IP es un protocolo de comunicaciones entre computadores; es decir, es un conjunto de reglas que

indican qué pasos deben seguir dos computadores para compartir información. TCP/IP es el conjunto

de protocolos de comunicaciones más extendido y usado en el mundo. Su nombre es el resultado de

las iniciales de Transport Control Protocol (Protocolo de Control de Transporte) e Internet Protocol

(Protocolo Interredes), sus dos componentes más importantes.

Los orígenes de TCP/IP se pueden encontrar en la red ARPANET de la Agencia de Proyectos de

Investigación Avanzados de la Defensa (DARPA, por sus siglas en Inglés) de Estados Unidos en 1969.

Con DARPA se intentaba crear una red que proveyera conexiones sólidas entre computadores de

diferentes fabricantes. Para 1975 la red ya era un producto suficientemente maduro como para dejar de

considerarlo un proyecto experimental y tratarlo como una red completamente operacional. La

necesidad de conectar no ya computadores, sino diferentes tipos de redes entre sí, originó el

Internet

Protocol Suite (Conjunto de Protocolos Internet) o TCP/IP que se normalizó en 1983. Inicialmente,

sólo centros militares de investigación y algunas universidades tuvieron acceso a la red. La utilización

de la red para usos universitarios, comerciales y particulares hizo que se decidiera, por razones de

seguridad militar, dividir la red

en dos: una continuaba con el nombre de

ARPANET que

posteriormente se llamó Internet; la otra, compuesta por la porción de nodos dedicados a uso militar, se

conoció como MILNET. El acceso de una a otra está rigurosamente controlado.

25

Internet ha crecido desde la red de cuatro nodos dada a conocer en 1969 hasta cubrir todo el mundo y

el espacio en nuestros días. El último vuelo del transbordador espacial estadounidense pudo ser

seguido por investigadores de todo el mundo a través de Internet.

3.2 SOCKETS

DARPANET se difundió ampliamente entre las universidades, la mayoría de las cuales utilizaba alguna

versión de UNIX, sistema operativo que fue prestado por AT&T a las universidades. Una de las

versiones más difundidas fue la creada en la Universidad de California, conocida como BSD UNIX

(Berkeley Software Distribution UNIX). ARPANET proveyó fondos a Bolt Beranek and Newman Inc

para implementar TCP/IP para UNIX y a Berkeley para incluir la implementación dentro de su BSD

UNIX.

En Berkeley decidieron añadir una nueva capa al protocolo para que fuese más fácil de manejar por

parte de los desarrolladores de software. El concepto básico de esta capa fue el SOCKET (enchufe).

Hasta el momento, la mayor parte de los nodos Internet trabajan en UNIX y sockets es la interfaz de

protocolos más usada, aunque existen otras como STREAMS que pueden ofrecer un mayor nivel de

abstracción.

Básicamente un socket es la abstracción a través de la cual se maneja la implementación de TCP/IP.

Internamente un socket es identificado por un entero conocido como descriptor, muy similar a los

descriptores de archivo del sistema de entrada/salida de UNIX. Este descriptor identifica donde se

encuentra la estructura de datos que necesita el sistema para saber cómo y con quien se va a comunicar.

26

Existe una serie de funciones básicas que se encargan de manejar los sockets y que dan soporte al resto

de las funciones del protocolo:

TABLA 1: Funciones básicas para sockets.

Nombre

Proceso

socket

Crea un nuevo descriptor para comunicaciones.

connect

Conecta a un punto remoto.

write

Envía datos a través de la conexión.

read

Lee datos que llegan a través de la conexión.

close

Termina la conexión y destruye el descriptor.

bind

Une dirección IP y un protocolo a un socket.

listen

El socket queda en espera de nuevas conexiones.

accept

Acepta una nueva conexión.

recv

Recibe un datagrama.

recvmsg

Variación del anterior.

recvfrom

Recibe un datagrama y registra su procedencia.

send

Envía un datagrama.

sendmsg

Variación del anterior.

sendto

Envía un datagrama a una dirección prefijada.

shutdown

Termina una conexión TCP.

getpeername

Obtiene la dirección de donde proviene una conexión.

getsockopt

Obtiene las opciones actuales del socket.

setsockopt

Cambia las opciones del socket.

Con el desarrollo y difusión de plataformas de 16 y 32 bits, se hizo necesario establecer una interfaz

para TCP/IP para estos sistemas. Con base en las especificaciones de los sockets de BSD UNIX, se

creó la especificación conocida como WINSOCK, una serie de definiciones de estructuras y funciones

que emulan la funcionalidad de los sockets. Sin embargo, las versiones iniciales de Windows, que

trabajaban a 16 bits, manejaban la multitarea de forma muy diferente de UNIX. Usar sockets de UNIX

pude crear bloqueos por tiempo indefinido en los programas de Windows. Para resolver este problema

se añadieron funciones con la misma funcionalidad básica que las listadas anteriormente pero que

trabajan en modo asincrónico. Esto quiere decir que, cuando una función asincrónica envía una

petición a través de la red, no queda esperando la respuesta bloqueando la ejecución del programa y de

todos los demás programas que se tengan abiertos. En vez de eso, el programa sigue ejecutándose. El

sistema de mensajes de Windows se encarga de avisar al programa que los datos se están recibiendo.

Las plataformas Windows NT y Windows 95 (sistemas operativos de 32 bits) presentan un manejo más

27

eficiente de la multitarea. Por lo tanto, no exigen el manejo de funciones de comunicaciones

asincrónicas, pero el uso de estas funciones permite desarrollar programas más amigables. El uso de las

funciones normales de sockets bloqueará,

bajo Windows de 32 bits,

solo al programa de

comunicaciones, mientras los demás programas siguen ejecutándose; pero el usuario probablemente

preferirá que no quede bloqueado ningún programa, lo cual se puede lograr con las funciones

asincrónicas.

Las funciones asincrónicas básicas (existen otras) son :

TABLA 2: Funciones de WinSock.

WSAAsyncSelect

Prepara los mensajes de notificación del sistema.

WSAACancelAsyncRequest

Cancela una operación asincrónica no completada.

WSASetBlockingHook

Establece un modo de bloqueo para una función.

WSAUnhookBlockingHook

Devuelve el modo de bloqueo normal.

WSACancelBlockingCall

Cancela una llamada que se está procesando.

WSAIsBlocking

Indica si el sistema está trabajando en modo bloqueante

WSAStartup

o no. Inicializa el sistema en modo asincrónico.

WSACleanup

Libera los recursos utilizados por el sistema.

3.3 PROTOCOLOS DE TRANSPORTE DE TCP/IP

Existen dos protocolos en TCP/IP que corresponden a la capa de transporte del modelo conceptual

conocido como Interconexión de Sistemas Abiertos (OSI por sus siglas en Inglés) de la Organización

Internacional de Normas

(ISO, de nuevo por sus siglas en Inglés).

Estos dos protocolos son TCP y

UDP. Dado que estos dos protocolos tienen diferentes características y definen la forma en que el

desarrollador enfrenta sus problemas de comunicaciones, es importante describirlos.

3.3.1 TCP. La sigla de este protocolo significa Protocolo de Control de Transporte. La implementación

de este protocolo ofrece un medio de transporte orientado a la conexión confiable de una corriente de

datos. Por confiable se quiere decir que implementa los mecanismos necesarios para garantizar que la

28

información que llega de un punto es correcta y está ordenada. La corriente de datos indica que provee

un flujo continuo de datos y es orientado a conexión porque cada socket está atado a una dirección

específica.

Este protocolo es el más común para redes de área ancha (WAN) pues ya implementa los mecanismos

para asegurar que la comunicación se realiza de manera adecuada. Por lo tanto, es el más utilizado en

las aplicaciones que corren sobre Internet. Para realizar la conexión entre el cliente y el servidor bajo el

protocolo de transporte TCP se cumplen los siguientes pasos:

SERVIDOR

socket crea el socket de escucha.

bind da un nombre al socket.

listen espera nuevas conexiones.

En espera.

accept acepta la conexión.

send / recv envía y recibe información.

closesocket cierra la conexión.

CLIENTE

socket crea el socket.

connect contacta el servidor.

send / recv envía y recibe información. closesocket cierra la conexión.

Como se puede ver el servidor tiene un socket que le permite detectar cuando un cliente desea

conectarse y crea un socket para poder comunicarse con cada uno de ellos; por lo tanto, para enviar

información a un cliente basta con enviarla a través del socket que le corresponda.

3.3.2 UDP. UDP significa Protocolo de Datagrama de Usuario. Como su nombre lo indica, provee

transporte de paquetes de información o datagrama, en vez de un flujo continuo. No implementa

mecanismos para hacer fiable la transmisión y no es orientado a conexión.

29

Dado que el protocolo no provee una comunicación segura, el desarrollador deberá implementar los

mecanismos necesarios por su cuenta. Sin embargo, el protocolo suele funcionar bien en una red de

área local en la generalmente no hay pérdida o intercambio en el orden de los paquetes. Al no ser

orientado a conexión, se puede usar un socket para enviar información a cualquier punto y el usuario

puede especificar el tamaño del paquete que desea recibir. El protocolo se encarga de transportar los

datos y reorganizarlos de nuevo en el formato especificado.

Para realizar la conexión entre el cliente y el servidor bajo el protocolo de transporte UDP se cumplen

los siguientes pasos:

SERVIDOR

socket crea el socket.

bind da nombre al socket.

sendto / rcvfrom envía y recibe datos.

closesocket destruye el socket

CLIENTE

socket crea el socket.

sendto / rcvfrom envía y recibe datos.

closesocket destruye el socket.

4 ESPECIFICACIONES

4.1 INTRODUCCIÓN

El primer paso al desarrollar un programa es la descripción del sistema que se va a crear. Esta

descripción debe ser lo más completa posible, ya que sobre ella se basarán los demás pasos del

desarrollo del sistema. El desarrollador de Software debe estar dispuesto a revisar y corregir las

especificaciones iniciales todas las veces que sea necesario ya que un error en las especificaciones

viciará todo el proceso.

Se ha desarrollado un sistema de Chat, es decir, un sistema que permite a una serie de usuarios

conectarse y establecer conversaciones. El sistema de conversación está diseñado para sostener

conferencias basadas en texto sobre protocolo TCP/IP. Una configuración típica involucra a un proceso

servidor que forma un punto central al cual se conectan los procesos cliente.

Las especificaciones se basan en el RFC (Request For Comment) 1459 titulado Internet Relay Chat

Protocol de J. Oikarinen y D. Reed y que se encuentra en varios NIC's (Net Information Center) en

Internet. Sin embargo, para el caso de este trabajo de grado se ha restringido el ámbito del sistema a un

sólo servidor (el sistema original incluye multitud de servidores) al cual se puede conectar n clientes.

También se han simplificado u omitido algunos comandos. Esto se debe a que el protocolo completo

resulta desproporcionadamente complejo para los fines que se buscan. Atender todos los detalles que

31

se encuentran en el protocolo original podría producir falta de claridad. Sin embargo este subconjunto

del protocolo IRC se puede extender fácilmente para desarrollar el protocolo completo.

La información completa sobre el protocolo original, se encuentra en el disquete que acompaña el

texto. Para comunicarse con los autores del RFC se puede dirigir a:

JARKKO OIKARINEN TUIRANTIE 17 AS 9 90500 OULU FINLANDIA E-MAIL: jto@tolsun.oulu.fi

DARREN REED 4 PATEMAN STREET WATSONIA, VICTORIA 3087 AUSTRALIA E-MAIL: avalon@coombs.anu.edu.au

También existen las siguientes listas oficiales de discusión sobre Internet:

PROTOCOLO FUTURO: ircd-three-request@eff.org

DISCUSIÓN GENERAL: operlist-request@eff.org

4.2 EL SERVIDOR

El servidor es el eje del

sistema de Chat. Se encarga de llevar a cabo las tareas de recepción, envío,

multiplexación, etc. de mensajes.

32

4.3 LOS CLIENTES

Cliente es todo proceso que puede conectarse al servidor. Cada cliente se distingue de los demás por un

alias único de máximo nueve (9) caracteres. Además

usuario.

4.4 CÓDIGOS DE CARACTERES

del alias, el servidor debe tener

el nombre del

El protocolo se basa en un conjunto de caracteres de ocho (8) bits que forman un octeto. Cada mensaje

puede estar compuesto de cualquier cantidad de octetos; sin embargo, algunos de estos octetos son

usados como códigos de control que actúan como delimitadores de mensajes.

Aunque son protocolos de 8 bits, los delimitadores y palabras clave se seleccionan de manera que se

puedan utilizar desde una terminal USASCII y una conexión Telnet.

4.5 MENSAJES

El servidor y los clientes intercambian mensajes que pueden generar o no una respuesta. Si el mensaje

contiene un comando válido, el cliente puede esperar una respuesta, pero no debe quedar en estado de

espera indefinidamente. Las comunicaciones entre el cliente y el servidor son asincrónicas por

naturaleza.

Cada mensaje contiene tres partes principales. El prefijo que es opcional, el comando y los parámetros

del comando (hasta 15 parámetros). El prefijo, el comando y los parámetros se separan por uno o más

espacios ASCII, caracter 0x20.

33

La presencia del prefijo se designa por el caracter ASCII de dos puntos (0x3b) que debe ser el primer

caracter del mensaje. No debe haber espacios entre los dos puntos y el prefijo. El prefijo es utilizado

para indicar el verdadero origen del mensaje. Si el prefijo se pierde , se considera que el mensaje se

originó en la conexión desde la cual se recibió. Esta convención tiene especial significado cuando

existe comunicación entre servidores. Si el prefijo no corresponde a ningún alias conocido, el mensaje

es descartado sin respuesta.

El comando puede ser una instrucción válida de una lista específica, como aparecen en el parágrafo 4.8

o un número de tres (3) dígitos representado en texto ASCII.

Los mensaje son siempre líneas de máximo 512 caracteres terminados con un par de caracteres CR-LF

(CARRIAGE RETURN LINE FEED). El comando y sus parámetros no pueden ocupar más de 510

caracteres. Si un mensaje ocupa más de 510 caracteres se cortará.

4.6 FORMATO DE UN MENSAJE EN NOTACIÓN BNF

Los mensajes del protocolo se deben extraer de la corriente de octetos. Por ello se designan los

caracteres CR Y LF

como separadores de mensajes. Los mensajes vacíos son descartados sin

respuesta; por lo tanto, se pueden usar sin problema secuencias de pares CR-LF entre mensajes.

El mensaje divide en los componentes: <prefijo>, <comando> y la lista de parámetros marcados por

componentes <middle> y <trailing>.

34

La representación BNF es:

<mensaje>::= [ : <prefijo> <ESPACIO> ] <comando> <parámetros> <CR-LF>

<prefijo>::= <servidor> | <alias> [ ! <user> ] [@ <host> ]

<comando>::= <letra> { <letra> } | <numero> <numero> <numero>

<ESPACIO>

::= <caracter ASCII 0X20>{<caracter ASCII 0X20>}

<parámetros>::= <ESPACIO> [ : <trailing> | <middle> <parámetros> ]

<middle> ::= <Cualquier secuencia no vacía de octetos sin incluir <ESPACIO>, NULO, CR ni LF y el

primer caracter no Puede ser ":">

<trailing> ::=<Cualquier secuencia, pude ser vacía, que no incluye NULO, CR o LF>

<CRLF>::= El par de caracteres de retorno de carro y avance de línea.

Advertencias:

<ESPACIO> esta compuesto solo de caracteres ASCII 0x20. Otros caracteres como TABULADOR no

se consideran espacios en blanco.

Los parámetros <middle> o <trailing> son tratados igual. El último parámetro puede ser una cadena

vacía.

El hecho de que los caracteres CR y LF

no pueden ser usados dentro de un mensaje

es sólo un

mecanismo de la construcción de mensajes. Esta norma posiblemente cambie en el futuro.

El caracter NULO no es un caracter especial del protocolo. Como puede causar problemas con el

manejo de cadenas de C, no se permite dentro de los mensajes.

35

4.7 RESPUESTAS NUMÉRICAS

La mayoría de los mensajes enviados al servidor generan una respuesta de algún tipo. La más común es

la respuesta numérica que se usa para comunicar errores y respuestas normales. El mensaje de

respuesta numérica está formada por el prefijo del remitente, el número de tres dígitos y el objetivo de

la respuesta. No se permite una respuesta numérica originada por un cliente; tales mensajes son

descartados por el servidor sin dar aviso. En todos los demás aspectos una respuesta numérica es

tratada como un mensaje normal.

4.8 DETALLE DE LOS COMANDOS

Los comandos deben ser reconocidos por el sistema. El servidor al que está conectado el cliente

verifica el mensaje de comando y devuelve las respuestas y errores apropiados. Si se encuentra un error

fatal la verificación del mensaje termina y el servidor devuelve un mensaje de error. Un error fatal

puede ser un comando incorrecto, un destino desconocido, un número incorrecto de parámetros o

privilegios no apropiados.

Al recibir el conjunto de parámetros, cada uno de ellos debe ser revisado y validado. Se debe enviar las

respuestas apropiadas al cliente remitente.

4.8.1 Registro de conexión. En este apartado se describen los Comandos usados para registrar la

conexión del cliente al servidor. El orden recomendado para estos Comandos es:

1. Comando PASS

2. Comando NICK

3. Comando USER

36

4.8.1.1 Comando PASS.

Parámetros: <clave de acceso>

El comando PASS es usado para especificar la clave de acceso de la conexión, la cual debe haber sido

registrada antes de cualquier intento de conexión. Se pueden enviar múltiples comandos PASS pero

sólo se registra el último y no puede cambiarse después de registrase la conexión.

Respuestas:

ERR_NEEDMOREPARAMS

ERR_ALREADYREGISTERED

4.8.1.2 Comando NICK (Alias).

Parámetros: <Alias>

Este Comando sirve para establecer el alias por el cual quiere ser reconocido el usuario o para

modificarlo si ya estaba establecido.

Respuestas:

ERR_NONICKNAMEGIVEN

ERR_ERRONEUSNICKNAME

ERR_NICKNAMEINUSE

ERR_NICKCOLLISION

4.8.1.3 Comando USER.

parámetros: <nombre de usuario> <nombre real>

El comando USER es usado al principio de la conexión para indicar el nombre de usuario y el nombre

real del cliente.

37

Respuestas:

ERR_NEEDMOREPARAMS

ERR_ALREADYREGISTRED

4.8.1.4 Comando QUIT.

Parámetros: [<mensaje de salida>]

Con este comando el cliente termina la sesión. El servidor debe cerrar la conexión con el cliente que

envía este comando.

Respuestas: No hay

4.8.2 Comandos del servidor. La siguiente serie de comandos se ha creado para obtener información

acerca del servidor del Chat.

4.8.2.1 Comando VERSION.

Parámetros: No hay.

El servidor debe responder con la información de versión.

Respuestas:

ERR_NOSUCHSERVER

RPL_VERSION

38

4.8.2.2 Comando TIME.

Parámetros: No tiene.

Este comando sirve para pedir información de hora local al servidor.

Respuestas:

RPL_TIME

4.8.2.3 Comando ADMIN.

Parámetros: No tiene.

Este comando es usado para obtener el nombre del administrador del sistema de Chat.

Respuestas:

RPL_ADMINE

RPL_ADMINLOC2

RPL_ADMINLOC1

RPL_ADMINEMAIL

4.8.3 Comando con destinatario específico. El comando PRIVMSG es el único que permite dirigir

un mensaje a una persona en especial.

Parámetros: <receptor> {,<receptor>} <texto a ser enviado>

Este comando es usado para enviar mensajes privados entre clientes. <receptor> es el alias de aquel

que debe recibir el mensaje.

Respuestas:

ERR_NORECIPIENT

ERR_CANNOTSENDTOCHAN

ERR_NOSUCHNICK

ERR_NOTEXTTOSEND

ERR_NOTOPLEVEL

39

4.9 MENSAJES DE ERROR

Se presenta una lista de las respuestas que son generadas por los comandos anteriormente descritos.

Para cada respuesta se da el número que le corresponde, el nombre, la cadena de respuesta y una breve

explicación cuando se considere necesario:

ERR_NOSUCHNICK: 401. <alias>: no existe al alias. Sirve para indicar que el alias suministrado

como parámetro al comando no se encuentra en uso.

ERR_NORECIPIENT: 411. No se especificó recipiente (<comando>)

ERR_NOTEXTTOSEND: 412. No hay texto que enviar.

ERR_UNKNOWNCOMMAND: 421. <comando>: Comando desconocido. El comando enviado es

desconocido.

ERR_NOADMININFO: 423. No existe información administrativa. Mensaje de respuesta cuando

ocurre un error al buscar información acerca del servidor.

ERR_FILEERROR: 424. :Error de archivo haciendo <operación de archivo> en <archivo>. Mensaje

de error de archivo genérico.

ERR_NONICKNAMEGIVEN: 431. Falta parámetro de alias.

ERR_ERROENUSNICKNAME: 432. <alias>: Alias erróneo. Este mensaje indica que el parámetro

de alias no está bien construido.

40

ERR_NICKNAMEINUSE: 433. <alias> : El alias esta siendo usado por otro cliente. Este mensaje

surge cuando un cliente trata de cambiar su alias a otro que está actualmente en uso.

ERR_USERNOTINCHANNEL: 441. <alias>: El cliente no está en

el sistema. Mensaje devuelto

cuando el objetivo del comando no se encuentra (por ejemplo un mensaje privado enviado a un cliente

equivocado).

ERR_NOTREGISTRED: 451. : Usted no está registrado. Un usuario trató de entrar al sistema sin

estar registrado previamente.

ERR_NEEDMOREPARAMS: 461. <comando> : Faltan parámetros.

ERR_ALREADYREGISTRED: 462. :Usted no puede registrarse de nuevo. Respuesta a un segundo

intento de registro.

ERR_PASSWDMISMATCH: 464. : Clave de acceso incorrecta.

4.10 RESPUESTAS A COMANDOS

Cuando un mensaje es procesado correctamente, se le envía una respuesta que se compone de un

código de tres números que identifica el tipo de respuesta, frecuentemente acompañado de algunos

parámetros. Los códigos validos para respuesta a comandos son los siguientes:

RPL_NONE: 300. No es utilizado.

41

RPL_WHOISUSER: 311. <alias> <usuario> * : <nombre real>.

RPL_WHOISIDLE: 317. <alias> <entero>: segundos en espera.

RPL_ENDOFWHOIS: 318. <alias> : Final de la lista.

RPL_VERSION: 351. <versión>.<nivel de depuración> <servidor>: <comentarios>.

RPL_INFO: 371. :<cadena>.

RPL_ENDOFINFO: 374. : Fin de la lista.

RPL_TIME: 391. : <hora local>.

RPL_ADMINE: 256. <servidor> : Información administrativa

RPL_ADMINLOC1: 257. : <Información de localización>

RPL_ADMINLOC2: 258. : <Información de la organización que mantiene el servidor>

RPL_ADMINEMAIL: 259. : <Dirección electrónica del administrador>.

42

4.11 ASPECTOS A TENER EN CUENTA

4.11.1 Autenticación de acceso. Para todas las conexiones se revisa la clave de acceso especificada

previamente y se identifica el usuario responsable por la conexión, es decir, ambos se cotejan con las

listas que tenga el servidor del Chat.

4.11.2 Protocolo de red. El Chat se implementó sobre TCP dado que provee transmisión sin errores y

permite conversaciones sobre redes extensas. Sin embargo, para un sólo servidor limitado a una red

local la implementación podría haber sido hecha sobre UDP.

4.11.3 Construcción de comandos. Cada conexión está provista con su propio buffer en el cual se

guardan la entrada y análisis del comando más reciente. El buffer es analizado cada vez que se

completa una operación de lectura. En las conexiones de larga distancia los mensajes pueden llegar en

desorden. Cuando un comando QUIT llega antes que otros mensajes del mismo usuario y se procesa, la

cola correspondiente a esa conexión es eliminada y se pierden los mensajes que llegan posteriormente.

4.11.4 Despacho de comandos. Es normal encontrar líneas en la red sobresaturadas hasta el punto que

los protocolos de conexión no pueden manejarlo de manera eficiente. Para resolver este problema el

sistema cuenta con una cola FIFO para los datos que se van a enviar. Una "cola de envío" típica puede

crecer hasta los 200 kb. en un IRC grande con una conexión de red lenta.

Cuando se revisan las conexiones, el servidor lee y analiza los mensajes que entran, pone en cola los

mensajes que se deben enviar. Cuando todos los datos están procesados, la cola de datos es enviada.

Esto reduce el número de instrucciones Write() y ayuda a TCP a crear paquetes más grandes.

43

4.11.5 Archivo de Configuración. Para proveer una forma flexible de preparar y ejecutar el servidor,

se usa un archivo de configuración con información para el servidor como la siguiente:

Localización del servidor (Universidad, Ciudad, País, Compañía, etc.)

Responsable del IRC y dirección electrónica donde puede ser contactado.

Claves de acceso para los clientes que pueden tener acceso a comandos de operador.

De este archivo de configuración se puede obtener la información administrativa que soliciten los

usuarios.

4.11.6 Acceso de Clientes. Los servidores deben usar un archivo con la lista de control de acceso que

es utilizada para decidir quienes tienen acceso al sistema. Aunque no se desarrolló, es conveniente

encriptar la información de acceso para protegerla de manipulaciones no deseadas.

5.1 INTRODUCCIÓN

5 ANÁLISIS

El principal objetivo del Análisis Orientado a Objetos es representar el sistema a desarrollar en

términos de objetos. Se empieza por encontrar los componentes del sistema y sus relaciones

estructurales que conforman el modelo estático; posteriormente, se busca definir el modelo dinámico,

es decir, las sucesiones de eventos y diagramas de estado que identifican el comportamiento del

sistema y, por último, el modelo funcional, o sea, la identificación de los datos que entran y salen de

cada objeto o flujo de datos.

5.2 ANÁLISIS ESTÁTICO

5.2.1 Identificación de clases. El primer

paso en el desarrollo del sistema es su análisis. En él, se

codifica la información de las especificaciones en estructuras sencillas y se eliminan las ambigüedades

y la información redundante.

Según Grady Booch 1 , una forma sencilla y eficiente de encontrar los candidatos a objeto de un sistema

es revisar las especificaciones del mismo y anotar todos los sustantivos que se encuentren en el. Este

proceso no da la lista definitiva de objetos, pero es una buena base para empezar a desarrollar el

pero es una buena base para empezar a desarrollar el OBJECT ORIENTED Design with Applications. New

OBJECT ORIENTED Design with Applications. New York, The Benjamin/Cummings Publishing Company, 1991.

45

sistema; posteriormente se desecharán algunos objetos demasiado simples, se encontrará que dos

nombres representan al mismo objeto o que falta algún objeto.

La lista de nombres encontrada en las especificaciones del Chat son, en orden alfabético:

Alias

Grupo de usuarios

Objetivo

Archivo de configuración

Letra

Parámetro

Carácter especial

Límite

Prefijo

Carácter no-blanco

Lista

Proceso

Clave de acceso

Llave

Protocolo

Cliente

Máscara

Red

Comando

Mensaje

Respuesta

Conexión

Middle

Servidor

CRLF

Nombre de usuario

Trailing

Espacio

número

Usuario

5.2.1.1 Reglas para seleccionar candidatos a clases. Para seleccionar qué elementos de la lista son

candidatos a clases se siguen las reglas:

Si el sustantivo representa algo que está por fuera del dominio, el elemento no es una clase. Por

ejemplo, el término red aparece en las especificaciones, pero no está incluido dentro del sistema y por

lo tanto no es responsabilidad del sistema, aunque se base en ella.

Si el sustantivo es demasiado simple para ser tratado como objeto, se rechaza. Es el caso de los

términos nombre de usuario y alias, que por simples se pueden modelar a través de una cadena de

caracteres.

Si el sustantivo es demasiado general, se rechaza. Por ejemplo, proceso. Aunque es un término que

representa algo dentro del dominio del problema y no es suficientemente simple para descartarlo, es

muy ambiguo y no representa nada en concreto. En este caso se debe revisar las especificaciones que

46

pueden no ser tan específicas como debieran. Tal vez, se pueda rechazar el término porque exista otro

u otros posibles objetos que modelen la misma fracción de la realidad con mayor precisión.

Otra razón para rechazar una posible clase es que el sustantivo realmente represente una operación o

método de otra clase.

No es muy importante que se quede olvidado algún posible objeto al hacer por primera vez la lista. Las

carencias que muestre el sistema durante las etapas de diseño y programación advertirán al ingeniero de

desarrollo para que revise la lista.

5.2.1.2 Selección final de clases. Se hace una primera revisión por la naturaleza de los objetos; es

decir, qué objetos definen la misma porción del sistema o qué porciones del sistema faltan por definir.

Aquellos que se consideren tipos de objetos válidos generarán una clase.

Para empezar, los términos servidor y cliente son los dos entes en que se divide el sistema. Son

demasiado complejos para considerarlos clases, es más adecuado considerarlos subsistemas que estarán

compuestos de varias clases.

Usuario es otro término importante del sistema; por lo tanto, se considera que la clase usuario es parte

del sistema.

La red es el medio sobre el cual se va a mover la información del sistema. Es algo que existe

previamente, que no es responsabilidad del sistema y está por fuera de su dominio; por lo tanto, se

rechaza como objeto. Sin embargo, observando el capítulo correspondiente al protocolo sobre TCP/IP

y sockets se encuentra que la comunicación entre diferentes puntos de la red se establece a través del

47

mecanismo de sockets. Por ello, aunque no aparece en las especificaciones del protocolo, se tiene en

cuenta una clase socket.

Para implementar el protocolo se crea una clase Protocolo que es el objeto encargado de realizar la

tarea de seleccionar las respuestas adecuadas a los mensajes de comando según su naturaleza.

Mensaje es un término base para el sistema dado que es el formato en que la información es

intercambiada; así que también se tiene la clase mensaje. En cambio, respuesta y comando son sólo

tipos de mensajes. Se podría pensar en desarrollar clases hijas de mensaje para modelar la respuesta y

el comando, pero, de nuevo, lo importante de estos mensajes no es su funcionalidad, sino cómo

reacciona el resto de sistema a su presencia. Se pueden modelar a través de atributos de mensaje.

También, prefijo, parámetro, espacio, middle, trailing, CRLF, objetivo, que no son objetos sino

componentes de la estructura del mensaje, pueden modelarse dentro del comportamiento o atributos de

mensaje.

Los caracteres y números son demasiado simples para considerarlos objetos. También lo son los

conceptos de llave, clave de acceso y límite.

Después de terminar el proceso se encontraron las clases usuario, socket, protocolo y mensaje.

5.2.2 Diccionario de datos. Cada término por si solo puede tener varios significados. El diccionario

precisa el significado de cada término y su importancia dentro del sistema.

Alias: nombre que escoge un usuario para ser reconocido por los demás usuarios del sistema.

48

Archivo de configuración: archivo que contiene información acerca del servidor, del administrador

del sistema y de los clientes que pueden tener acceso al sistema.

Clave de acceso: conjunto de caracteres que se asigna a un usuario y que sólo debe conocer éste, para

ser reconocido por el sistema. La clave de acceso suele estar protegida a través de mecanismos de

codificación para que no se pueda obtener del archivo de configuración.

Cliente: proceso a través del cual un usuario puede hacer uso del sistema para intercambiar mensajes

con otros usuarios.

Comando: tipo de mensaje que emite un usuario o el servidor para modificar el estado de un usuario o

de un canal, para solicitar información o para desarrollar el proceso de registro de un usuario.

Error: tipo de mensaje que emite el servidor como respuesta a un comando que no ha podido

completarse con éxito.

Espacio: el carácter ASCII 0X20.

Máscara: conjunto de caracteres que se usan para hacer referencia a diferentes clientes cuyos alias

tienen estructura parecida.

Mensaje: cadena de caracteres que viaja a través del sistema llevando información de los usuarios al

servidor y viceversa.

Middle: cualquier secuencia no vacía de caracteres que no incluyan espacio o el carácter nulo.

49

Nombre de usuario: cadena de caracteres que identifica al usuario dentro del sistema de Chat.

Parámetro: cadena de caracteres que modifica las operaciones ejecutadas por el servidor cuando

recibe un comando.

Prefijo: parte de un mensaje que indica quien fue el emisor.

Protocolo: conjunto de reglas que definen como va a comportarse el proceso servidor.

Red: medió usado por el sistema para el intercambio de mensajes entre el servidor y los clientes.

Respuesta: tipo de mensaje que emite el servidor como respuesta a un comando que ha sido llevado a

cabo con éxito.

Servidor: proceso que se encarga de realizar las tareas de despacho de mensajes y mantener el estado

de cada canal y cliente.

Socket: Medio por el cual un programa puede acceder a los recursos de comunicaciones, establecer

conexiones e intercambiar datos con otros puntos de la red.

Trailing: cualquier secuencia de caracteres, incluso vacía, que no incluya espacio o el carácter nulo.

Usuario: persona que utiliza el sistema de Chat.

50

5.2.3 Identificación de las asociaciones estructurales. El paso siguiente es definir las relaciones

estáticas entre las clases. Las asociaciones corresponden con frecuencia a:

Una localización física: X está cerca a Y, Y está contenido en X, Y es parte de X.

Acciones directas: X maneja Y.

Necesidad: X usa Y.

Especialización: X es un tipo especial de Y.

Propiedad: X tiene Y , X es parte de Y.

La satisfacción de una condición: encaja con, limita con.

Se debe tener cierto cuidado al identificar

las asociaciones ya que es probable que algunas estén

implícitas en las especificaciones. Encontrarlas o no depende de la claridad de las especificaciones, del

conocimiento del dominio del problema que tenga el ingeniero y la etapa de desarrollo en que se

encuentre el sistema.

Las relaciones encontradas son:

El protocolo analiza mensaje.

El protocolo envía mensajes de respuesta o error.

Cada Usuario está asociado a un socket de comunicaciones.

El socket envía y recibe mensajes.

Existe un socket para aceptar conexiones.

El protocolo tiene un mensaje y un usuario

5.2.3.1 Reglas para la selección de asociaciones. Se debe especificar la semántica de las asociaciones

teniendo en cuenta los siguientes conceptos:

51

La relación debe ser una propiedad estructural y no meramente una acción temporal. El protocolo

analiza un mensaje no es una asociación estructural. Una relación estructural válida sería el Protocolo

contiene un mensaje.

No deben existir asociaciones ternarias. Cuando una asociación incluye tres o más clases se debe

descomponer en varias asociaciones binarias. La asociación ternaria "El protocolo tiene un mensaje y

un usuario"

no

es incorrecta pero

es

más

fácil de expresar y manejar

si

se

divide en las dos

asociaciones binarias "el protocolo tiene un mensaje" y "el protocolo tiene un usuario".

Asociaciones mal nombradas. Una asociación debe decir solamente qué es, no cómo o por qué sucede.

Se debe especificar la multiplicidad; sin embargo, no es necesario hacer mucho énfasis al principio en

este aspecto ya que es de esperar que cambie a medida que se desarrolla el análisis y se va teniendo un

conocimiento más profundo del sistema.

5.2.3.2 Lista final de asociaciones. Después de filtrar la lista con las reglas anteriores tenemos:

El protocolo tiene un mensaje.

El protocolo tiene un usuario.

Un usuario está asociado a un socket.

Un socket está asociado a un usuario.

Las asociaciones entre clases se pueden representar a través de un grafo de clases.

52

PROTOCOLO Tiene
PROTOCOLO
Tiene

USUARIO

Tiene

MENSAJE

Está asociado

52 PROTOCOLO Tiene USUARIO Tiene MENSAJE Está asociado Está asociado SOCKET FIGURA 1: Grafo de clases.
52 PROTOCOLO Tiene USUARIO Tiene MENSAJE Está asociado Está asociado SOCKET FIGURA 1: Grafo de clases.

Está asociado

SOCKET

FIGURA 1: Grafo de clases.

5.2.4 Identificación de atributos. El paso siguiente consiste en encontrar los atributos de los objetos.

Existen dos estructuras sintácticas que nos permiten encontrar atributos de objetos dentro de las

especificaciones. Una está compuesta de un nombre seguido de una frase posesiva: el color del

automóvil, el nombre del usuario. Por otro lado están los adjetivos que dan pistas acerca de los

atributos; por ejemplo, si en las especificaciones aparece la frase el automóvil rojo, es probable que

existan automóviles de otros colores y por lo tanto que color sea un atributo de la clase automóvil. Los

atributos suelen estar menos definidos que las clases o

las asociaciones en las especificaciones. El

éxito de esta etapa depende mucho del estilo del programador y de su conocimiento del sistema. Por

suerte, es poco frecuente que los atributos modifiquen la estructura básica del sistema, y, por lo tanto,

la omisión o la incorrecta definición de atributos sólo afectará a la clase a la que pertenecen y no a la

estructura general del diseño.

5.2.4.1 Reglas para identificación de atributos. Al

cuenta los siguientes parámetros:

asignar atributos a los objetos se debe tener en

Evitar los atributos derivados o redundantes. En el caso de un objeto que defina a una persona, los

atributos correspondientes a edad y fecha de nacimiento son redundantes pues uno se puede derivar del

otro. Se debe seleccionar sólo uno de ellos.

53

El atributo no debe ser un objeto. Si la existencia independiente del atributo es importante, entonces es

probable que sea en realidad un objeto. El que un elemento sea objeto o atributo depende en gran

medida de su importancia dentro de la aplicación que se va a desarrollar.

Valores Internos. Si el atributo corresponde a algo que no se ve fuera del objeto, se debe eliminar en

este estadio pues está definiendo algo que sólo es importante para la implementación del objeto.

5.2.4.2 Lista final de atributos. Al seguir las reglas anteriores obtenemos la siguiente tabla:

TABLA 3: Atributos asignados a las clases.

CLASE

ATRIBUTOS

Usuario

Alias, Nombre de Usuario, Clave de Acceso

Protocolo

Mensaje

Texto, Emisor, Tipo

socket

Dirección remota, Tipo de socket, Puerto de conexión.

5.2.5 Refinamiento del modelo estático con herencia. Para terminar de definir el modelo estático del

sistema se buscan estructuras similares entre los diferentes objetos. La relación de herencia puede

encontrarse de dos maneras: generalizando aspectos comunes de clases existentes en una superclase (de

abajo a arriba) o refinando clases en subclases especializadas (de arriba a abajo).

En el primer caso se buscan clases con atributos, asociaciones u operaciones similares; en el segundo

caso es normal encontrar nombres compuestos que definen un mismo objeto en diferentes situaciones.

En este estadio no se encontraron superclases o metaclases específicas del sistema. Durante el

desarrollo aparecieron clases genéricas que se usaron en la implementación de las clases y atributos:

sin embargo, por ser clases dependientes de la herramienta de desarrollo no se mencionan todavía.

54

5.3 ANÁLISIS DINÁMICO

5.3.1 Preparar escenarios. Con escenario se quiere decir un diálogo típico, una secuencia de eventos,

entre el usuario y el sistema para obtener una visión de lo que se espera del comportamiento del

sistema. Este paso da una buena idea de las principales interacciones, de la interfaz más apropiada y del

intercambio de información.

Primero se preparan escenarios para casos ideales en que no se cometen errores y, posteriormente, se

consideran los casos especiales en que surgen errores o inconsistencias.

Los eventos que se estudian en el escenario consisten en intercambio de información y los datos que se

intercambian

son los parámetros del evento. Por ejemplo, en el evento "El usuario introduce alias,

nombre de usuario y clave de acceso en el cliente", el alias, el nombre de usuario y la clave de acceso

son los parámetros del evento. Sin embargo, es común encontrar eventos que no tienen parámetros. En

estos casos la ocurrencia del evento es la propia información. Por ejemplo, los mensajes periódicos que

envía el reloj del sistema son importantes en sí mismos y no necesitan llevar información adicional.

Para cada evento se debe identificar

contiene (parámetros) y el receptor.

el actor, es decir, el agente que lo causa, la información que

Eventos que tienen las mismas características se pueden definir en un mismo escenario aunque tengan

diferentes parámetros. De esta manera se evita crear escenarios similares para casos similares. Por

ejemplo, el tercer escenario, que se describe más adelante, modela el intercambio de información para

cualquier comando, ya que

similares.

aunque la información que se intercambia es diferente, los eventos son

55

Para cada escenario se crea un diagrama de eventos que muestra gráficamente la secuencia de eventos.

5.3.1.1 Escenario 1. El primer caso es la situación ideal en la cual el proceso se lleva a cabo sin trabas.

El usuario introduce información del servidor en el cliente.

El cliente envía solicitud de conexión al servidor.

El servidor confirma el permiso de acceso.

El cliente notifica que la conexión está establecida.

El usuario introduce sus datos en el cliente.

El cliente solicita ingreso al sistema

Se recibe confirmación de acceso al sistema.

El cliente notifica el estado del sistema al usuario.

El usuario introduce texto.

El usuario envía mensaje.

El servidor devuelve respuestas.

El cliente presenta la información al usuario.

El usuario introduce solicitud de desconexión.

El cliente envía mensaje de desconexión.

El servidor cierra la conexión

56

USUARIO

CLIENTE

SERVIDOR

Solicitud de conexión

Solicitud de conexión Acepta conexiòn

Acepta conexiòn

Solicitud de conexión Acepta conexiòn

Pide acceso al sistema

Pide acceso al sistema Confirma permiso Envìa mensaje Respuesta Envía mensaje de desconexiòn
Pide acceso al sistema Confirma permiso Envìa mensaje Respuesta Envía mensaje de desconexiòn

Confirma permiso

Envìa mensaje

Pide acceso al sistema Confirma permiso Envìa mensaje Respuesta Envía mensaje de desconexiòn

Respuesta

Pide acceso al sistema Confirma permiso Envìa mensaje Respuesta Envía mensaje de desconexiòn

Envía mensaje de desconexiòn

Pide acceso al sistema Confirma permiso Envìa mensaje Respuesta Envía mensaje de desconexiòn
Envìa mensaje Respuesta Envía mensaje de desconexiòn Información del servidor Notificación de conexión

Información del servidor

Envía mensaje de desconexiòn Información del servidor Notificación de conexión Información del usuario Informa
Envía mensaje de desconexiòn Información del servidor Notificación de conexión Información del usuario Informa

Notificación de conexión

Información del usuario

servidor Notificación de conexión Información del usuario Informa Estado Introduce texto Muestra resultado Solicita
servidor Notificación de conexión Información del usuario Informa Estado Introduce texto Muestra resultado Solicita

Informa Estado

Introduce texto

Información del usuario Informa Estado Introduce texto Muestra resultado Solicita desconexiòn FIGURA 2: Diagrama

Muestra resultado

del usuario Informa Estado Introduce texto Muestra resultado Solicita desconexiòn FIGURA 2: Diagrama de eventos 1.

Solicita desconexiòn

FIGURA 2: Diagrama de eventos 1.

5.3.1.2 Escenario 2. En este escenario el usuario introduce mal los datos de acceso y por lo tanto el

servidor rechaza la conexión.

El usuario introduce su información de acceso.

El cliente envía mensajes de solicitud de acceso.

El servidor rechaza el acceso.

El cliente presenta aviso de rechazo.

Si es el tercer intento el cliente presenta aviso de desconexión. de otra manera vuelve al primer paso.

57

USUARIO

CLIENTE

SERVIDOR

 

Información del cliente

 
 
 

Aviso de rechazo

Información del cliente     Aviso de rechazo   Información del cliente   Aviso de rechazo
 

Información del cliente

  Información del cliente
 

Aviso de rechazo

  Información del cliente   Aviso de rechazo   Información del cliente   Aviso de rechazo
 

Información del cliente

  Información del cliente
 

Aviso de rechazo

del cliente   Aviso de rechazo   Información del cliente   Aviso de rechazo   Aviso
 

Aviso desconexión

del cliente   Aviso de rechazo   Información del cliente   Aviso de rechazo   Aviso
 

solicitud de acceso

  solicitud de acceso
 

Rechazo

  solicitud de acceso   Rechazo   solicitud de acceso     Rechazo   solicitud de
 

solicitud de acceso

 
 
 

Rechazo

de acceso   Rechazo   solicitud de acceso     Rechazo   solicitud de acceso  
 

solicitud de acceso

  solicitud de acceso
 

Rechazo

de acceso   Rechazo   solicitud de acceso     Rechazo   solicitud de acceso  

FIGURA 3: Diagrama de eventos 2.

5.3.1.3 Escenario 3. En este escenario el usuario está en medio de la conversación e intenta un

comando cualquiera. Como el tratamiento de todos los comandos es similar, no se prepara un escenario

para cada uno pues resultaría superfluo.

El usuario introduce un comando en el cliente.

El cliente envía el mensaje al servidor.

El servidor devuelve mensaje respuesta.

El cliente informa de la respuesta al usuario.

58

USUARIO

CLIENTE

SERVIDOR

Comando

Mensaje Respuesta

Mensaje

Mensaje Respuesta

Respuesta

Mensaje Respuesta
Mensaje Respuesta
58 USUARIO CLIENTE SERVIDOR Comando Mensaje Respuesta Informa respuesta FIGURA 4: Diagrama de eventos 3. 5.3.2

Informa respuesta

SERVIDOR Comando Mensaje Respuesta Informa respuesta FIGURA 4: Diagrama de eventos 3. 5.3.2 Diagramas de estado.

FIGURA 4: Diagrama de eventos 3.

5.3.2 Diagramas de estado. El diagrama de estado muestra los eventos que el objeto recibe o envía. Se

crea un diagrama de estado para cada una de las clases con un comportamiento no trivial. Cada

escenario o diagrama de eventos se corresponde con un camino a través de uno de los diagramas de

estado. El diagrama de estado de una clase contiene caminos que corresponden a los escenarios en que

participa esa clase. Puede suceder que hay estados a los cuales puede llegar claramente una instancia de

una clase determinada, pero que no aparece en los escenarios un evento que nos lleve a él. Esto quiere

decir que faltan por construir escenarios o que alguno de los ya construidos está incompleto.

59

Crear mensaje

59 Crear mensaje MENSAJE CREADO Descomponer MENSAJE ANALIZADO Destruir Mostrar contenido, prefijo, comando y parámetros
MENSAJE CREADO Descomponer MENSAJE ANALIZADO
MENSAJE CREADO
Descomponer
MENSAJE ANALIZADO
Destruir
Destruir

Mostrar contenido, prefijo,

comando y parámetros

FIGURA 5: Grafo de estado de Mensaje.

Crear Socket
Crear
Socket
Enviar / recibir mensajes Destruir Solicitar SOCKET DE conexiòn CONEXION SOCKET VACIO Unir a un
Enviar / recibir
mensajes
Destruir
Solicitar
SOCKET DE
conexiòn
CONEXION
SOCKET
VACIO
Unir a un
SOCKET DE
servicio
SERVIDOR
Destruir
Aceptar
conexiones

FIGURA 6: Grafo de estado de Socket.

60

Crear Destruir protocolo PROTOCOLO ACTIVO Analiza mensaje
Crear
Destruir
protocolo PROTOCOLO ACTIVO
Analiza
mensaje

FIGURA 7: Grafo de estado de Protocolo.

Crear Usuario
Crear Usuario
Destruir USUARIO ACTIVO Mostrar/modificar nombre real, nombre
Destruir
USUARIO ACTIVO
Mostrar/modificar
nombre real, nombre

de usuario, alias o

clave.

FIGURA 8: Grafo de estado de Usuario.

5.4 MODELO FUNCIONAL

5.4.1 Identificar información de entrada y salida. La información de entrada y salida es bastante

sencilla para este sistema.

61

La información de entrada es:

Información del servidor: dirección IP, nombre del servidor.

Información del usuario: alias, clave de acceso, nombre de usuario.

Mensajes.

La información de salida es :

Mensajes.

5.4.2 Diagramas de flujo de datos. En este punto se desarrollan diagramas de flujo de datos que

permiten identificar como se procesa la información de entrada para obtener resultados.

Mensajes de Mensajes respuesta y 0 2 del usuario 1 ENTRADA error SALIDA DE DE
Mensajes de
Mensajes
respuesta y
0
2
del usuario
1
ENTRADA
error
SALIDA
DE
DE
CHAT
DATOS
DATOS
Datos de
USUARIO
Datos de
entrada
salida

FIGURA 9: Flujo de datos del sistema.

Los procesos 0 y 2 componen la interfaz del sistema, el proceso 1 es el más importante y para el se

desarrolla otro diagrama de flujo de datos.

62

1.0 Estado de conexiòn INTENTA ARCHIVO DE CONEXION Conectado USUSARIOS 1.1 Estado del usuario VERIFICA
1.0
Estado de conexiòn
INTENTA
ARCHIVO DE
CONEXION
Conectado
USUSARIOS
1.1
Estado del usuario
VERIFICA
PERMISOS
Usuario con
permisos
1.2
Mensajes
DIALOGO

Informaciòn

de servidor

permisos 1.2 Mensajes DIALOGO Informaciòn de servidor Informacón de usuario Mensajes FIGURA 10: Flujo de datos

Informacón de usuario

Mensajes

FIGURA 10: Flujo de datos del sistema de Chat.

Los dos primeros procesos son muy simples para continuar expandiéndolos en nuevos diagramas de

flujo. El proceso 1.2 es más complicado, pero el intercambio de datos sigue siendo muy simple.

5.4.3 Identificación de reglas de coherencia. Es importante tener en cuenta algunos aspectos del

sistema que no se encuentra reflejado en los diferentes gráficos y tablas de las actividades de análisis

anteriores. Estos son relaciones no estructurales entre los objetos, pero que son imprescindibles para

definir adecuadamente el sistema.

Para el sistema de Chat se ha encontrado el siguiente conjunto de reglas de coherencia:

Existe solamente un servidor dentro del sistema de Chat.

No se especifica límite de clientes que se puedan conectar al servidor.

Hay una conexión por cada usuario.

Hay un usuario por cada conexión.

El servidor tiene una y sólo una conexión de servidor.

63

5.5 DEFINICIÓN DE LA INTERFAZ

El último paso del análisis es la definición de los formatos de interfaz. Ya se conocen los valores de

entrada y salida y los eventos que va a desencadenar el usuario. A esta altura el ingeniero de desarrollo

ya tiene elementos para decidir cómo va a aceptar y mostrar datos.

Para cada uno de los formatos se muestra su presentación, se describe cómo se introducen los datos y

con qué formato, se indican qué procesos se desencadenan y el árbol de menú, en caso de que exista

uno. Como la aplicación se va a desarrollar sobre plataformas Windows, se utilizarán los mecanismos

normales de tal plataforma para diseñar la interfaz.

5.5.1 Interfaz del servidor. La interfaz del servidor es muy sencilla, porque el servidor trabaja en

forma automática y sin intervención de un operador.

Tiene una ventana principal dentro de la cual se pueden ver las ventanas hijas que presentan

información de la conexión de servidor y de cada una de las conexiones con los clientes.

También tiene un menú con las siguientes opciones:

Opción Programa/Salir: Termina la ejecución del servidor.

Opción Ventana/Cascada: Coloca las ventanas abiertas en cascada mostrando sus títulos.

Opción Ventana/Mosaico: Coloca las ventanas en mosaico de forma que se pueda ver una porción del

contenido de todas ellas.

64

Opción Ventana/Arreglar Iconos: Coloca ordenadamente los iconos de las ventanas en la parte inferior

de la ventana principal.

Opción Ayuda/Acerca de

responsable del desarrollo.

:

Presenta información acerca de la fecha y versión del servidor y del

acerca de la fecha y versión del servidor y del FIGURA 11. Interfaz de servidor. 5.5.2

FIGURA 11. Interfaz de servidor.

5.5.2 Interfaz del cliente. La interfaz del cliente es mucho más compleja y está compuesta por varios

formatos.

El formato principal esta compuesto de un menú, una barra de herramientas desde la cual se puede

acceder a las operaciones más frecuentes, una caja de edición para introducir el texto de los mensajes

que se envíen, un botón para enviar el mensaje después de que se ha terminado de escribir el texto y

65

otro para borrar el texto si se decide que no se quiere enviar; por último, existe una lista donde se

pueden ver los mensajes que llegan al cliente.

5.5.2.1 Definición del menú. El menú esta compuesto de cuatro opciones principales a las cuales se

puede acceder por medio del ratón

o por medio del teclado en las formas normales de la plataforma

Windows. Las cuatro opciones se dividen en sub-opciones que desencadenan procesos.

Opción Conexión: Contiene las opciones para acceder al servidor, desconectarse de el y para enviar

mensajes privados.

Opción Conexión/Establecer conexión: Solicita la información necesaria acerca del servidor y del

usuario y realiza el proceso necesario para conectarse al servidor.

Opción Conexión/Terminar conexión: Envía los mensajes necesarios para avisar de la desconexión al

servidor y termina la ejecución del programa.

Opción Conexión/Mensaje privado: Permite enviar un mensaje a un usuario específico que este

haciendo uso del sistema.

Opción Emoticones: Pone a disposición una serie de emoticones para ser incluidos en el mensaje a

enviar.

Opción Información/Versión del servidor: Solicita al Servidor la información de la versión.

Opción Información /Información del administrador: Obtiene el nombre del administrador del sistema

Chat.

66

Opción Información /Hora del servidor: Pide información de hora local al Servidor.

Opción Ayuda/Ayuda: Permite acceder a la ayuda del sistema

Opción Ayuda/Acerca de

responsables del proyecto.

:

Muestra una ventana con información acerca de la versión, fecha y

una ventana con información acerca de la versión, fecha y FIGURA 12: Ventana principal del cliente.

FIGURA 12: Ventana principal del cliente.

5.5.2.2 Ventana de conexión. Esta ventana solicita la dirección Internet del servidor y el nombre real,

nombre de usuario, alias y clave de acceso del usuario. Una vez introducida esta información, se

intenta la conexión del servidor.

67

67 FIGURA 13: Ventana de conexión del cliente. 5.5.2.3 Ventana para mensajes privados. En esta ventana

FIGURA 13: Ventana de conexión del cliente.

5.5.2.3 Ventana para mensajes privados. En esta ventana se introduce un mensaje y el alias del

usuario destinatario y sólo el recibirá el mensaje.

un mensaje y el alias del usuario destinatario y sólo el recibirá el mensaje. FIGURA 14:

FIGURA 14: Ventana para mensajes privados.

68

5.5.2.4 Ventana de emoticones. Esta ventana muestra una lista de emoticones con su descripción y

contiene botones para copiar el emoticón en el mensaje a enviar o para cancelar el proceso.

emoticón en el mensaje a enviar o para cancelar el proceso. FIGURA 15: Ventana de emoticones.

FIGURA 15: Ventana de emoticones.

5.5.2.5 Ventana Acerca de

Muestra información acerca del programa y de los desarrolladores.

5.5.2.5 Ventana Acerca de Muestra información acerca del programa y de los desarrolladores. FIGURA 16: Ventana

FIGURA 16: Ventana Acerca de

6 DISEÑO

El diseño es el paso que permite salvar la brecha que hay entre el análisis y el desarrollo final del

sistema. Los pasos que se siguen para este diseño son:

Dividir el sistema en subsistemas y localizarlos en dispositivos de hardware.

Combinar los tres modelos definidos en los análisis estático, dinámico y funcional para definir

algoritmos.

Definir la implementación de las asociaciones.

En este paso ya se toman en cuenta las herramientas de desarrollo que se van a usar. Existe una serie de

clases reutilizables a disposición del ingeniero de diseño en las diferentes herramientas de desarrollo

orientadas a objetos; por ejemplo, el Object Windows Library (OWL), o el Microsoft Fundational

Classes

(MFC).

Además,

en

ambiente

Windows

se

debe

tomar

en

cuenta

las

librerías

de

encadenamiento dinámico disponibles o archivos con extensión DLL y los componentes BVX y OCX,

que ponen a disposición del usuario clases completas. En los anexos se encuentra una lista de

direcciones Internet de organizaciones, empresas y universidades que proporcionan información acerca

de los protocolos de Internet, programas ya desarrollados para TCP/IP y componentes para manejo de

Sockets.

70

Se requiere que el servidor domine los problemas de concurrencia: por lo tanto, se implementa para

ejecutarse sobre una plataforma potente y con capacidad de multitarea como Windows 95 o Windows

NT. Para desarrollarlo se utiliza la herramienta Visual C++ con MFC, la razón para escoger esta

herramienta es que MFC es soportada por varios de los compiladores de C++ más populares del

mercado y, por lo tanto, se pueden aplicar las ideas de este trabajo sin necesidad de usar la misma

herramienta haciéndolo más general. También se aprovechan

las clases de sockets de Arthur Dumas

que aparecen en el libro Programing Winsock y que a su vez hacen uso de la librería WinSock.Dll

versión 1.1. Estas clases son sencillas de entender y se pueden documentar de manera que las ideas

utilizadas en ellas se apliquen a otras herramientas de desarrollo.

El cliente es un proceso con menor exigencia para su desempeño y mayor para la interfaz. Por lo tanto,

se escogió como herramienta de desarrollo para el cliente el lenguaje Visual Basic 3.0 de 16 bits para

que pueda ser ejecutada sobre computadores personales normales bajo plataforma Windows 3.11 o

superior. Para el manejo de sockets se utiliza el componente SocketWrench/VB, que contiene las clases

básicas para la creación de conexiones en Visual Basic.

6.1 DIVIDIR EN SUBSISTEMAS

Salvo en los casos más triviales, un sistema se puede dividir en subsistemas. En el caso de este

proyecto hay dos susbsistemas, el servidor y al cliente.

En el diseño estos dos subsistemas se tratan aparte por dos razones:

Cada subsistema es suficientemente complicado para ser un sistema por su propia cuenta. En realidad,

es normal que el desarrollo del servidor y el cliente se hagan por diferentes ingenieros de desarrollo y

por lo tanto se analicen y diseñen como sistemas separados que se rigen por un mismo protocolo.

71

Se desarrollaron el servidor y el cliente en dos herramientas diferentes, orientados a plataformas

diferentes de acuerdo con las características y necesidades de cada uno.

Cada uno de estos dos subsistemas se divide a su vez en subsistemas más simples que se llaman

módulos y que equivalen a las clases. Se puede mostrar la organización de los subsistemas por medio

de capas y particiones.

Servidor Cliente Protocolo Usuario Usuario Mensaje Mensaje Sockets Sockets
Servidor
Cliente
Protocolo
Usuario
Usuario
Mensaje
Mensaje
Sockets
Sockets

IGURA 17: Diagramas de subsistemas.

F

En un sistema dividido en capas, cada subsistema se define en términos de los subsistemas que están

encima y debajo de él y a los cuales ofrece o solicita servicios. Si se crean las capas de manera que

cada capa solamente se comunique con las que están inmediatamente encima y debajo de ella, se dice

que es una arquitectura cerrada. Este tipo de organización de subsistemas suele ofrecer una gran

flexibilidad, porque cada capa se comporta como un compartimento estanco, de manera que cada

modificación que necesite el sistema no se suele propagar a más de una capa.

72

En el caso que las capas conozcan y se puedan comunicar con capas no adyacentes se suele decir que

se trata de una arquitectura abierta. Este tipo de arquitectura no es tan robusta como la arquitectura

cerrada, pero ofrece mayor libertad al ingeniero de desarrollo y mayores posibilidades de optimización

ya que se pueden obtener algunos servicios de una capa sin tener que atravesar capas intermedias que

resulten innecesarias en un caso dado.

Las particiones dividen un sistema en una serie de subsistemas independientes que ofrecen cada uno un

tipo de servicio.

Por lo general, un sistema no suele mostrar una forma exclusiva de organización. Sin embargo, existe

un caso, muy cercano al tema que se está tratando, que vale la pena mostrar: el modelo de referencia de

Interconexión de Sistemas Abiertos de la Organización Internacional de Normas. Este modelo se basa

en siete capas; cada una de ellas basa su desempeño exclusivamente en las necesidades y servicios de

las capas contiguas, es decir, se basan en una arquitectura cerrada. De esta manera, cada subsistema

tiene un comportamiento perfectamente definido y un ingeniero que va a desarrollar una de las capas

sólo debe tener en cuenta la capa inferior y superior, de otro modo debería tener un conocimiento en

detalle de todo el sistema. No debe resultar confuso que un sistema abierto se base en una arquitectura

cerrada. Con sistema abierto se hace referencia a sistemas que se pueden comunicar con otros sistemas

de características muy diferentes y la arquitectura cerrada tiene que ver con su organización interna.

El siguiente paso es localizar los subsistemas en procesadores: se desarrolla un diagrama en el cual se

muestra

como

se

relacionan físicamente los subsistemas y qué procesos se cumplen en cada

procesador. En el caso de este proyecto el diagrama es muy sencillo y se podría haber omitido; en otros

proyectos este diagrama puede ser vital para entender qué se puede esperar en cuanto a tiempos de

respuesta, necesidades de hardware y otros.

73

Cliente Servidor 1 Cliente Cliente 2 3 FIGURA 18: Diagrama de procesadores.
Cliente
Servidor
1
Cliente
Cliente
2
3
FIGURA 18: Diagrama de procesadores.

6.2 DEFINICIÓN DE ALGORITMOS

La definición de los algoritmos se basa en la combinación de los tres modelos definidos para el

análisis: estático, dinámico y funcional.

El modelo estático muestra las clases a las que se le van a asignar las operaciones y la información que

se debe manejar; el modelo funcional muestra cómo llega la información del exterior, cómo se

transforma y cómo se presenta, lo cual se debe reflejar en las operaciones; por último, el modelo

dinámico muestra las acciones de cada una de las clases cuya funcionalidad se debe encontrar también

en sus operaciones.

74

La lista de operaciones encontradas es :

TABLA 4: Lista de operaciones de los objetos.

Clase

Operaciones

socket

CreateSocket ,connec, accept, Write, Read, OnWinSockEvent.

Protocolo

Analiza.

Usuario Cambiar nombre, Cambiar alias, cambiar clave, cambiar nombre real, cambiar tipo, mostrar alias, mostrar clave, mostrar nombre, mostrar nombre real, mostrar tipo. Mensaje Modificar contenido, mostrar contenido, Descomponer, mostrar comando, mostrar tipo, mostrar parámetro.

Para cada una de las operaciones se define una condición inicial o precondición (estado inicial de los

atributos y objetos que se ven involucrados en la operación), un resultado o postcondición (estado final