UFPS prototipoOOP Client-Server 1996

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 en Química, Ingeniero Civil, Profesor de la

Universidad Francisco de Paula Santander.
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
2.1 NIVELES DE LA ARQUITECTURA 18

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
4.8.1 Registro de conexión 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
5.2.3.1 Reglas para la selección de asociaciones 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.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
6.2.1 Socket::CreateSocket 75
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 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 tipos de equipos y sistemas operativos en un único ambiente de
procesamiento.
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
o no.
WSAStartup 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 CLIENTE
socket crea el socket de escucha.
bind da un nombre al socket.
listen espera nuevas conexiones.
En espera. socket crea el socket.
connect contacta el servidor.
accept acepta la conexión.
send / recv envía y recibe información. send / recv envía y recibe información.
closesocket cierra la conexió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 CLIENTE
socket crea el socket.
bind da nombre al socket.
socket crea el socket.
sendto / rcvfrom envía y recibe datos. sendto / rcvfrom envía y recibe datos.
closesocket destruye el socket.
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 del alias, el servidor debe tener el nombre del
usuario.
4.4 CÓDIGOS DE CARACTERES
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_ADMINLOC1
RPL_ADMINLOC2 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_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_NOSUCHNICK
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 ANÁLISIS
5.1 INTRODUCCIÓN
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 Booch1, 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
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
Tiene
PROTOCOLO MENSAJE
Tiene
Está asociado
USUARIO SOCKET
Está asociado
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 asignar atributos a los objetos se debe tener en
cuenta los siguientes parámetros:
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 el actor, es decir, el agente que lo causa, la información que
contiene (parámetros) y el receptor.
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 aunque la información que se intercambia es diferente, los eventos son
similares.
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
Información del servidor Solicitud de conexión
Notificación de conexión Acepta conexiòn
Información del usuario

Pide acceso al sistema
Informa Estado Confirma permiso
Introduce texto
Envìa mensaje
Respuesta
Muestra resultado
Solicita desconexiòn
Envía mensaje de 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
Información del cliente solicitud de acceso

Rechazo
Aviso de rechazo

Rechazo
Aviso de rechazo

Rechazo
Aviso de rechazo
Aviso desconexión
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
Comando Mensaje
Respuesta
Informa respuesta
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
MENSAJE CREADO
Descomponer
Destruir
MENSAJE ANALIZADO
Mostrar contenido, prefijo,

comando y parámetros
FIGURA 5: Grafo de estado de Mensaje.
Enviar / recibir
mensajes
Destruir
Solicitar SOCKET DE
conexiòn CONEXION
Crear SOCKET
Socket VACIO
Unir a un SOCKET DE
servicio SERVIDOR
Destruir
Aceptar
conexiones
FIGURA 6: Grafo de estado de Socket.

60
Crear
protocolo Destruir
PROTOCOLO ACTIVO
Analiza
mensaje
FIGURA 7: Grafo de estado de Protocolo.
Crear Usuario 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 Mensajes de
0 del usuario 1 respuesta y 2
ENTRA DA error SA LIDA
DE CHA T DE
DA TOS DA TOS
Datos de USUA RIO 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
Informaciòn 1.0
de servidor Estado de conexiòn
INTENTA
CONEXION ARCHIVO DE
Conectado USUSARIOS
1.1
Informacón de usuario Estado del usuario

VERIFICA
PERMISOS
Usuario con
permisos
1.2
Mensajes Mensajes
DIALOGO
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...: Presenta información acerca de la fecha y versión del servidor y del
responsable del desarrollo.
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...: Muestra una ventana con información acerca de la versión, fecha y
responsables del proyecto.
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
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.
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.
FIGURA 15: Ventana de emoticones.
5.5.2.5 Ventana Acerca de.... Muestra información acerca del programa y de los desarrolladores.
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.
Se rvidor Clie nte
P rotoc olo Usua rio Usua rio
M e nsa je M e nsa je
Soc ke ts Soc ke ts
F
IGURA 17: Diagramas de subsistemas.
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.
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
de los atributos y objetos que son modificados por la operación) y un algoritmo. Debido a que el
sistema se maneja por eventos y de manera asincrónica, existen funciones como entrar al sistema, que
envían la solicitud de conexión o entrada al servidor pero no esperan respuesta, como sería natural en
sistemas con control secuencial de procesos o manejo sincrónico de eventos.
No se tienen en cuenta los valores que son exclusivos de la implementación, por ejemplo, un valor
devuelto como control de errores no será incluido dentro de la postcondición.
La definición de los algoritmos se puede realizar por medio de una descripción informal, lenguaje de
comandos guardados, diagrama de flujo o cualquier otro método. Lo importante es que se acomode a
las necesidades del programador para que pueda salvar la brecha entre la definición y el algoritmo real.
Se encuentran algunos algoritmos que no se definen porque son triviales, especialmente los que tienen
que ver con mostrar el contenido de atributos o su modificación. La importancia real de estos métodos
es que separan las estructuras de datos que contienen los atributos del exterior, proporcionando solidez
a las clases como se ve en el capítulo dedicado a objetos.

75
6.2.1 Socket::CreateSocket
Descripción: Este método permite inicializar las estructuras de datos necesarias y provee un socket
válido.
Precondición: Número de puerto.
Postcondición: Socket válido.
Algoritmo:
Crea ventana par manejo de mensajes.
Crea el socket.
Si el número de puerto es válido entonces convierte el Socket en socket de servidor.
Inicial la notificación asincrónica de eventos.
Si el socket es de servidor lo deja atendiendo solicitudes de conexión.
6.2.2 Socket::Connect
Descripción: Permite a un socket de cliente solicitar una conexión al servidor.
Precondición: socket, dirección internet.
Postcondición: Socket conectado.
Algoritmo:
Si no es un socket válido termine.
Si es socket de servidor termine.
Envíe solicitud de conexión.
6.2.3 Socket::Accept
Descripción: Sirve para aceptar la solicitud de conexión de un cliente.
Precondición: Socket.
Postcondición: Conexión establecida.
Algoritmo:
76
Si el socket no es válido termine.
Si el socket no es servidor termine.
Crea una ventana para el nuevo socket.
Acepta la nueva conexión en el socket provisto.
Inicia notificación asincrónica de eventos para el nuevo socket.
6.2.4 Socket:: Write
Descripción: Este procedimiento coloca los datos a enviar en la cola de salida y solicita permiso para
enviarlos.
Precondición: Cadena de bytes y longitud.
Postcondición: Mensaje enviado.
Algoritmo:
Si el socket no es válido termine.
Asigne los datos de entrada a la estructura del socket.
Añada los datos a la lista de envío.
Envíe mensaje interno notificando que hay datos para despachar.
6.2.5 Socket::Read
Descripción: Lee datos de la cola de llegada.
Precondición: Nada
Postcondición: Datos leídos y longitud de los mismos.
Algoritmo:
Si no hay datos en la cola de llegada.
Saque datos de la cola de llegada.
6.2.6 Socket::OnWinSockEvent
77
Descripción: Se encarga de responder a los mensajes de notificación de eventos del subsistema de
sockets.
Precondición: Código del evento.
Postcondición: Respuesta al evento.
Algoritmo:
Si es mensaje de lectura pase los datos que llegan a la cola de entrada.
Si es mensaje de escritura envié los datos a través del socket.
6.2.7 Protocolo::Analiza
Descripción: Este método toma un mensaje y de acuerdo a su naturaleza y a los parámetros
proporciona una respuesta.
Precondición: Mensaje, Usuario.
Postcondición: Mensajes de respuesta y error.
Algoritmo:
Si el mensaje es de usuario, es despachado a todo los demás usuarios.
Si el mensaje es de conexión verifica que tenga parámetros y realiza las operaciones de conexión.
Si el mensaje solicita información del servidor, verifica que el usuario esté conectado, busca la
información y la entrega al usuario.
Si el mensaje es privado, busca al usuario destino y lo entrega.
6.2.8 Mensaje::Parser
Descripción: Este método descompone el mensaje en prefijo, comando y parámetros.
Precondición: Mensaje con contenido.
Postcondición: Mensaje analizado.
Algoritmo:
Convierte cadenas de caracteres en blanco en un sólo caracter en blanco.

78
Extrae el prefijo.
Extrae el comando.
Verifica el tipo de comando.
Extrae cada uno de los parámetros.
6.3 DISEÑO DE LAS ASOCIACIONES
En el capítulo de análisis se hablo de las relaciones estructurales de las clases, ahora es conveniente
observar las asociaciones entre objetos. El vínculo ya no es de estructural, sino de como interactúan los
objetos entre sí. Al desarrollar el sistema es conveniente escoger una estrategia para implementar las
asociaciones.
Un aspecto a tener en cuenta al implementar una asociación es si se trata de una asociación en una
dirección o bidireccional. También se debe verificar si la asociación es uno-a-uno, uno-a-varios, o
varios-a-varios. Si una asociación es atravesada en una sola dirección, puede ser implementada con
una referencia o un puntero. Si la multiplicidad es uno-a-uno, entonces es una referencia o un puntero
simple. Si es uno-a-varios, entonces se usa un conjunto de punteros o referencias. Si se necesita un
ordenamiento específico para la asociación, se puede usar una lista enlazada o un arreglo en vez del
conjunto. También se puede crear un objeto que funcione como un diccionario; es decir, una lista de
pares de valores, por lo general apuntadores, que mantiene la información de las asociaciones de otros
dos objetos.
En el caso de asociaciones que son atravesadas en ambas direcciones se debe tener en cuenta con que
frecuencia es atravesada una asociación en cada dirección. Existen tres aproximaciones básicas:
79
Implementar como una asociación de una sola dirección y realizar una búsqueda cuando se necesite
hacer referencia en la otra dirección. Esta técnica sólo es útil cuando una dirección es mucho más
frecuentemente usada que la otra.
Implementar atributos en ambas direcciones usando las técnicas ya vistas. La búsqueda es muy rápida,
pero se deben hacer actualizaciones sobre los atributos correspondientes en ambas clases. Esta técnica
es muy útil cuando las búsquedas son mucho más frecuentes que las modificaciones.
Se puede usar un par de objetos diccionario, uno para una dirección y otro para la otra dirección. El
acceso es un poco más lento, pero se pueden usar técnicas de búsqueda. Una ventaja de usar un objeto
separado para implementar las asociaciones es que no afecta a las clases que se van a asociar.
Las asociaciones encontradas son bastante simples; los usuarios se reúnen en una lista que permite
hacer búsqueda secuencial para encontrar un usuario específico. Esta lista es conocida por el protocolo
y a través de ella puede acceder a cualquier usuario. El resto de las asociaciones se cumplen por medio
de apuntadores o de las funciones de interfaz de los objetos.

80
Socket de
Lista de Servidor
usuarios Usuarios
Usa Crea
Recorre Sockets
Crea
Crea
Mensaje Protocolo
Analiza
FIGURA 19: Diagrama de objetos.

7 PROGRAMACIÓN
La programación es la representación sobre un lenguaje de programación de todos los conceptos,
asociaciones, restricciones, etc. encontrados en el diseño. En este capítulo se explican las técnicas
usadas durante la codificación de los archivos fuente de los programas para aclarar las posibles dudas
surgidas al leer el código fuente.
7.1 PROGRAMACIÓN DEL SERVIDOR
7.1.1 Apuntadores. Para evitar la duplicación de información, gasto adicional de memoria y ahorrar el
tiempo en la creación de nuevas instancias de clases se ha preferido usar apuntadores antes que nuevos
objetos cuando ha sido posible.
7.1.2 Atributos redundantes. En el diseño se considera que no debe existir información redundante,
sin embargo, en la programación se suelen crear atributos redundantes para ahorrar tiempo. En la clase
Mensaje el atributo contenido coexiste con los atributos prefijo, comando, parámetros y tipo;
aunque todos los anteriores se pueden derivar de contenido a través de funciones que realicen cada vez
la separación de los componentes de la clase, se consideró más eficiente tener atributos derivados. De
esta manera están disponibles inmediatamente cada vez que se solicitan los datos de los componentes
de un Mensaje.
82
Desde el punto de vista de recursos del computador se está consumiendo mayor cantidad de memoria
para mejorar el tiempo de respuesta.
7.1.3 Ocultamiento de información. Se puede encontrar en las clases que los atributos son privados a
la clase y que se necesitan dos métodos por cada atributo: uno para modificar el valor del atributo y
otro para obtener el valor que contiene. Tal vez esto puede parecer ineficiente e innecesario; sin
embargo, mantener los datos privados protege la integridad del objeto; tener métodos de interfaz
favorece el mantenimiento de la clase. Se debe tener en cuenta que al acceder a los objetos a través de
métodos nadie conoce la composición interna del objeto; esto es favorable, pues se puede modificar la
estructura interna del objeto sin que afecte al resto del programa.
7.1.4 Ventanas de Windows. El manejo de las conexiones se basa en el uso de mensajes característico
de Windows. Dado que las ventanas son los entes que pueden recibir mensajes en Windows, las clases
CServerView y CMainView se hacen derivar de la clase CFormView que corresponde a una ventana.
Para cada conexión se abre una ventana que maneja sus propios mensajes y tiene su propio hilo de
control.
Aunque es normal que las ventanas destinadas a los sockets sean invisibles, se han mantenido visibles
para que resulte clara la forma en que el programa servidor responde a los requerimientos de los
diferentes clientes.
7.1.5 Manejo de módulos. Dado que el programa es muy grande se ha dividido en módulos. Cada
módulo del programa está compuesto de dos archivos: un archivo de cabecera, cuya extensión es h, que
define los atributos y la interfaz de la clase y un módulo de implementación, con extensión cpp, que
contiene el código de los métodos de la clase.

83
Visual C++ crea automáticamente, de acuerdo con las especificaciones del ingeniero de software, una
serie de módulos que implementan las funciones mínimas de un programa típico de Interfaz de
Múltiples Documentos (MDI por sus siglas en inglés). Esto permite tener una base desde la cual partir
y asegura hasta cierto punto que el usuario siga la filosofía del manejo de documento y presentación
típico de Windows.
Cada módulo creado específicamente para este trabajo de grado corresponde a una clase o conjunto de
clases que están estrechamente relacionadas entre sí. Por ejemplo el módulo Usuario contiene las clases
CWinSock (que modela el subsistema básico de sockets para Windows), CDatagramSocket (que define
un socket de tipo UDP) y CStreamSocket (que es la clase correspondiente a los sockets TCP).
7.1.6 Módulos de servidor. La siguiente es la lista de módulos creados o modificados durante el
desarrollo de este sistema.
TABLA 5: Listado de módulos del servidor.
MainView Corresponde a la ventana para la conexión de servidor siguiendo

la nomenclatura de Arthur Dumas en "Programing Winsock".
SrvView Corresponde a la ventana para la conexión con cliente según la
nomenclatura anterior.
Usuario Contiene la clase CUsuario.
Mensaje Contiene la clase CMensaje
Protocolo Contiene CProtocolo.
Cwinsock Contiene la definición de las clases Cwinsock, CStreamSocket y
CDatagramSocket.
84
7.2 PROGRAMACIÓN DEL CLIENTE
7.2.1 Visual Basic y la Programación Orientada a Objetos. El cliente tiene características diferentes
en cuanto a la forma de programar. La principal diferencia es que Visual Basic hace uso de objetos
(cada uno de los controles es un objeto, las formas son objetos) pero no esta diseñado específicamente
hacia la programación con objetos.
Para plasmar el diseño orientado a objetos sobre esta herramienta se crean módulos por cada una de las
clases que se encuentran en el diseño; en cada una de ellas se colocan las variables y las funciones que
corresponden a los atributos y métodos de una clase, de esta manera se simula el encapsulamiento.
7.2.2 Módulos de Visual Basic. El programa está compuesto por tres clases de módulos, interfaz
,código y extensiones de Visual Basic. Los módulos de interfaz corresponden a ventanas que muestran
y solicitan información; están contenidos en archivos con extensión frm y frx. Los módulos de código
contienen definiciones de variables y constantes y subrutinas. Los módulos de código se encuentran en
archivos de texto con extensión bas. Las extensiones de Visual Basic son componentes que cumplen
una función específica y se pueden considerar como una clase reutilizable; los archivos que los
contienen tiene extensión vbx.
TABLA 6: Listado de módulos de interfaz del cliente.
frmAcerca Contiene la ventana Acerca de... típica de Windows con

información del desarrollador del programa, versión y fecha del
programa e institución a la que pertenece.
frmConectar En esta ventana se encuentra el control SocketWrench para manejo

de sockets.
frmConexión Esta ventana solicita la información del usuario y la dirección del

servidor para realizar la conexión.
frmEmoticones Esta ventana lee un archivo de texto con emoticones y su

85
descripción y los pone a disposición del usuario para incluirlos en

sus mensajes.
frmEntrada Ventana de presentación que aparece al inicio de la ejecución con

información acerca de programa.
frmMensajePrivado Ventana que permite enviar un mensaje a una persona específica.
Main Ventana principal desde la cual se realiza el trabajo principal y se

pueden llamar a las demás ventanas.
TABLA 7: Listado de módulos de código del cliente.
Conexión Este módulo contiene la información necesaria para establecer una

conexión a través del control de socket que esta en la ventana
frmConectar.
CsWSock El archivo es provisto por la compañía que creó el control de

sockets y contiene constantes necesarias para poder usarlo.
General Este módulo se ideó para contener funciones de uso general
Mensaje Este módulo contiene las funciones y variables necesarias para

analizar los mensajes recibidos y presentarlos al usuario.
Usuario Contiene los datos necesarios de usuario.
TABLA 8: Listado de extenxiones de Visual Basic del cliente.
CSWSOCK Define los datos y los procedimientos para manejar un socket bajo
protocolo TCP/IP.
GRID El contenido de este archivo crea una rejilla para mostrar datos.
8 CONCLUSIONES
A lo largo de este trabajo se han mostrado como la arquitectura cliente/servidor es una excelente
herramienta para el desarrollo de sistemas distribuidos; el Paradigma de Orientación a Objetos tiene
muchas ventajas frente a otras metodologías de desarrollo cuando se elaboran sistemas de computación
grandes y complicados; y la simplicidad de la interfaz de sockets para crear programas que se
comunique por medio del conjunto de protocolos TCP/IP. Por lo tanto la conclusión natural de este
trabajo es que el uso de las técnicas adecuadas de desarrollo de software permite enfrentar proyectos
grandes y complejos, y consecuentemente el ingeniero de sistemas debe desarrollar sus habilidades y
conocimientos al mismo ritmo que evoluciona la ciencia del desarrollo de software.
Tanto la arquitectura cliente/servidor y la programación orientada a objetos son tecnologías maduras y
que han recorrido un largo camino de evolución. Sin embargo, en nuestro medio no pasan de ser un
tema de conversación, sin que se haga uso efectivo de sus propiedades. Esto no es sólo inconveniente,
también es peligroso pues pronto un ingeniero de sistemas que mantenga está actitud no podrá utilizar
eficientemente muchas de las crecientes capacidades de hardware de computadores o de
comunicaciones y por lo tanto no podrá competir en un mercado que evoluciona tan rápido como el de
sistemas.
9 RECOMENDACIONES
Los programas cliente y servidor que se han desarrollado aquí tienen como única función ser un
ejemplo de desarrollo de software y por lo tanto se han simplificado para lograr claridad. El
responsable de este trabajo recomienda proveer al servidor las siguientes características:
En un servidor real no es necesario mostrar las ventanas para manejo de mensajes, aun más, puede
resultar inconveniente. En este trabajo se utilizan exclusivamente para mostrar claramente como se van
enviando los mensajes. Por lo tanto la interfaz del servidor se deberá modificar.
El programa servidor debe proveer acceso a datos estadísticos del funcionamiento de la red, por
ejemplo, número de usuarios conectados por día o por hora, número de mensajes transmitidos por hora,
número de mensajes erróneos. Estos datos pueden ser presentados por medio de números o de gráficos
y proveerán de información al administrador para establecer el desempeño del sistema.
Se debe añadir el mecanismo de canales a través del cual, diferentes grupos de usuarios pueden
establecer conexiones separadas sobre el mismo sistema de Chat.
El sistema debe soportar la presencia de múltiples servidores. Esta característica permite utilizar el
sistema de Chat sobre redes grandes más eficientemente que con el modelo de un sólo servidor.
89
Se debe implementar un sistema de encriptación para los datos almacenados en los archivos del
servidor. También puede ser recomendable el proporcionar la característica de enviar y recibir
mensajes encriptados para crear canales seguros.

ANEXO 1. SOFTWARE DEL PROYECTO
Con esta tesis se entregan los programas ejecutables y el código fuente del servidor y el cliente, el
documento RFC 1459 correspondiente al protocolo completo de IRC y el archivo comprimido de la
extensión de Visual Basic para el manejo de sockets. En este anexo se indica como están distribuidos
los archivos en el disquete.
Código del cliente (Visual Basic 3.0) \CODIGO\CLIENTE

Código del servidor (Visual C++ 2.1) \CODIGO\SERVIDOR
Archivos ejecutables del cliente \EJECUTABLE\CLIENTE
Archivos ejecutables del servidor \EJECUTABLES\SERVIDOR
Extensiones y librerías del cliente \EJECUTABLE\CLIENTE\SYSTEM
Archivo RFC1459.TXT (Raiz)
Archivo CSWSK110.ZIP (Raiz)
Para instalar el servidor basta con crear un directorio y copiar en el los archivos ejecutables del mismo;
en el caso del cliente se deben copiar sus archivos en un directorio especial para el y, además, se deben
copiar las extensiones y librerías en el directorio SYSTEM de WINDOWS (Suele encontrarse en el
siguiente camino C:\WINDOWS\SYSTEM).
El archivo RFC1459.TXT es un archivo plano que puede ser leído con cualquier editor de texto
sencillo como Notepad que viene con Windows.

91
El archivo CSWSK110.ZIP es un archivo comprimido con el programa PKZIP de uso común y que
contiene todos los archivos necesarios para instalar el componente y documentos en varios formatos
sobre el componente de sockets y sobre la especificaciones de Winsock que pueden resultar muy útiles.
ANEXO 2. LISTA DE NODOS INTERNET CON TEMAS SOBRE TCP/IP
El encontrar información específica sobre el desarrollo de aplicaciones que trabajen sobre red puede
ser difícil y costoso en tiempo y dinero. La fuente más extensa y económica es Internet a través del
sistema clásico de FTP anónimo o del novedoso WWW. Por lo tanto a continuación se provee una
pequeña lista de lugares donde se puede obtener información acerca de TCP/IP y de redes en general.
En la mayoría de ellos se puede encontrar información sobre otros lugares donde obtener más
información.
En la lista se especifican las direcciones (lugares) de los servidores y los temas que son importantes
para el desarrollo de redes.
LUGAR EN LA RED TEMAS

ftp://ftp-belnet.bc Networking, Linux.
ftp://ftp.calva.com (USA) Herramientas para Internet.
ftp://ftp.ciw.uni.karlsruhe.de (USA) Hitchickers guide to Internet.
ftp://ftp:cix.org (USA) Commercial Interent Exchange Asociation
ftp://ftp.cs.curtin-edu-au (AUSTRALIA) Internet.
ftp://ftp.cs.widener.edu (USA) Zen y el arte de Internet.
ftp://ftp.cs.buffalo.edu (USA) TCP, Linux.
ftp://ftp.cse.ucsc.edu (USA) Todo Internet.
ftp://ftp.eff.org (USA) Guía de recursos para Internet.
ftp://ftp.eunet.es (ESPAÑA) Software para Internet.
ftp://ftp.fee.vutbr.cz (REP. CHECA) TCP/IP Redes.
ftp://ftp.microdyne.com (USA) Winsockets.
ftp://ftp.microsoft.com (USA) Winsockets.
ftp://ftp.msem.com (USA) Revista de Internet.
ftp://ftp.rdc.puc.rio.br (BRASIL) TCP/IP para D.O.S.
ftp://ftp.rdu.ac.uk (Reino Unido) TCP/IP.
ftp://ftp.ripe.net (USA) Internet Society (ISOC).
93
ftp://ftp.rpi.edu (USA) Herramientas para Internet.

ftp://ftp.saldford.ac.uk (Reino Unido) Redes.
ftp://ftp.sesqui.net (USA) TCP/IP Digest.
ftp://ftp.shizuoka.ac.jp (JAPON) Redes.
ftp://ftp.uconn.edu (USA) TCP/IP para D.O.S. Redes.
ftp://ftp.uniovi.es (USA) Redes.
ftp://ftp.usma.edu (USA) TCP/IP.
ftp://godzilla.cgl.rmit.oz.au (AUSTRALIA) TCP/IP Redes Herramientas para redes.
ftp://naic.nasa.gov (USA) Aplicaciones para red y cenro de información.
ftp://nic.wiscnet.net (USA) TCP/IP para desktops.
ftp://oak.oakland.edu (USA) TCP/IP.
ftp://onet.on.ca (CANADA) TCP/IP.
ftp://phil.utmb.edu (USA) Herramientas para red.
ftp://rhino.microsoft.com (USA) TCP/IP, Winsockets.
ftp://risc.ua.edu (USA) Archivos TCP/IP.
http://info.cern.ch Servidores para WWW.
http://java.sun.com Lenguaje JAVA para WWW.
http://www.catalyst.com VBX/OCX para Internet (SocketWrench/VB).
http://www.dart.com VBX/OCX para Internet.
http://www.distinct.com VBX/OCX para Internet.
http://www.dwsapps.texas.net Programación con WinSock.
http://www.enterprise.net Desarrollo de WWW.
http://www.ncsa.uiuc.com Servidores para WWW.
http://www.netgen.com Servidores para WWW.
http://www.netmanage.com VBX/OCX para Internet.
http://www.tucows.com Programación con WinSock.
http://www.w3.org Desarrollo de WWW.
94
BIBLIOGRAFÍA
ARQUITECTURA CLIENTE/Servidor. En: PC Regional: América Latina, Vol. 4, No. 24 (Mayo,

1993); p. 21-23. Santafé de Bogotá, Empresar Editores.
AYRE, Rick y WILLMOTT, Don. The Internet mean business. En: PC Magazine, Vol. 14, No. 9
(Mayo, 1996); p. 195-246. New York, Ziff Davis.
BECERRA, Cesar A. C++: Una herramienta para la programación orientada a objetos. Santafé de
Bogotá, Kimpres, 1993. 387 p.
BIRMAN, Kenneth P., y RENESSE, Robert van. Software for Reliable Networks. En: Scientific
American, Vol. 274, No. 5 (mayo, 1996); p. 48-53. New York, Scientific American.
BOOCH, Grady. Object Oriented Design with applications. Redwood City, The Benjamin/Cummings,
1994. 585 p.
CLARKSON, Mark. All-terrain networking. En: Byte, Vol. 18, No 5 (1993); p. 256-259, Los Angeles,
McGraw Hill.
CONER, Douglas E. Internet working with TCP/IP. New York, Prentice Hall, 1993. 493 p.
DOBB’S. Toolbook of C. New York, Prentice Hall, 1986. 635 p.
DUMAS, Arthur. Programing Winsock. Indianapolis, Sams, 1995. 358 p.
DUNCAN, Ray. Operator and Function Overloading in C and C++. En: PC Magazine, Vol. 10, No. 14
(agosto, 1991); p. 433-442. New York, Ziff Davis.
_____. Implementig Encapsulation and Inheritance in C++. En: PC Magazine, Vol. 10, No. 16
(septiembre, 1991); p. 405-412. New York, Ziff Davis.
DVORAK, John. The information cow path en PC Magazine. Vol. 13, No. 10 (1991); p. 93-95. New
York, Ziff Davis.
DVORAK, John y ANIS, Nick. Telecomunicaciones para PC. Madrid, McGraw Hill, 1992. 362 p.
ELLISON, Carol. Building worgroup solutions en PC Magazine, Vol. 10, No. 9 (Mayo, 1991); p. 107-
123. New York, Ziff Davis.
FTP SOFTWARE INC. PC/TCP 2.2 Development Kit for DOS. North Andover, FTP Software, 1992.
356 p.
95
GONZÁLEZ, John Eduard. Winsaeta: Emulador de terminales P27 en ambientes Windows. Santafé de
Bogotá, Universidad de los Andes, 1994. 25 p.
-----. Proyecto dirigido “Sistema de comunicaciones A6 Windows. Santafé de Bogotá, Universidad de

los Andes, 1995. 32 p.
HUNTER, Bruce H. Y BRADFORD, Karen. UNIX SYSTEMS (advanced administration and

management handbook). New York, McMillan, 1991. 245 p.
KAARE, Christian. C++ Template Technology. En: PC Magazine, Vol. 13, No. 2 (enero, 1994). New
York, Ziff Davis.
-----. C++ Application Framework. En: PC Magazine, Vol. 13, No. 3 (febrero, 1994). New York, Ziff
Davis.
KERNIGHAM, Brian Y RITCHIE, Dennis. The C programming language. New Jersey, Prentice-Hall,
1978. 226 p.
KRUGLINSKY, David J. Progrese con Visual C++. Madrid, McGraw Hill, 1994. 665 p.
MACE, Thomas y MUNRO, Jay. Fresh takes on RAD. En: PC Magazine, Vol. 15, No. 1 (Enero 1996);
p. 239-243. New York, Ziff Davis.
MARCHUK, Michael. Internet applications with Visual Basic. s.l. . Que, 1995. 367 p.
MELO, John. Future communications en BYTE, Vol. 18, No. 7 (1993); p. 123-130. Los Angeles,
McGraw Hill.
MORGAN, Rachel; McGILTON, Henry. Introducción al UNIX Sistema V. México. McGraw Hill,
1989. 286 p.
MURRAY, William H.; PAPPAS, Chris H. Programación en Windows 3.1. Madrid,

Osborne/McGraw Hill, 1993. 216 p.
NAULE, Barry. A First Steo Toward Client/Server. En: PC Magazine, Vol. 13, No. 14 (agosto, 1994);
p. 403-405. New York, Ziff Davis.
NORTON, Peter. Periféricos y accesorios para la IBM/PC, PS/2 y compatibles. México, Prentice Hall
Hispanoamericana, 1992. 329 p.
PETZOLD Charles. The Visual Development enviroment: More than just a prtty face. En: PC
Magazine, Vol. 11, No. 11 (julio, 1992); p- 195-245. New York, Ziff Davis.
-----. An Introduction To Multithreading Under Windos NT. En: PC Magazine, Vol. 12, No. 14
(agosto, 1993); p.406-411. New York, Ziff Davis.
POHL, Ira. Object Orientd Programing using C++. Redwood City, The Benjamin/Cummings, 1993.
496 p.
RAGO, Stephen. UNIX System V: Network Programing. Massachussets, Adisson Wessley, 1992. 761
p.
96
RIEKEN, Bill y WIEMAN,Lile. Adventures in UNIX networking application progaming. New York,
John Wiley & Sons, 1992. 438 p.
ROBINSON, Peter. Object Oriented Design. London, Chapman & Hall, 1992.
ROSEN, Kenneth, ROSINSKI, Richard y FARBER, James. UNIX sistema V versión 4. Madrid,
McGraw Hill, 1990. 639 p.
RUMBAUGH, James; BLAHA, Michael; PREMERLANI, William; EDDY, Frederick; LORENSEN,

William. Object-Oriented : Modeling and Desing. Englewood Cliffs, New Jersey. Prentice
Hall, 1991. 395 p.
SALENI, Joe. Tools for wide area communications. En: PC Magazine. Vol. 10, No. 15 (Septiembre,
1991); p. 231-302. New York, Ziff Davis.
SANDERS, Donald H. Informática presente y futuro. México, McGraw Hill, 1988. p. 1480.
SCHILDT, Herbert. Turbo C/C++: Manual de referencia. Madrid: Osborne/McGraw Hill, 1992. p.
127.
_____. Lenguaje C: Programación avanzada. México, McGraw Hill, 1987. 298 p.
SEYMOUR, Jim. OOP Will Make Our Lives Easer, Too. En: PC Magazine, Vol. 15, No. 5 (marzo,
SHATZ, Sol M. Development of distributed software. New York, McMillan, 1993. p. 320.
STIX, Gary. Domesticating Cyberspace. En: Scientific American. Vol. 269, No. 2 (febrero, 1993);
p.84-92. New York, Scientific American
STONE, David. PC communications comes of age. En: PC Magazine, Vol. 7, No. 13 (julio, 1988); p.
127-206. New York, Ziff Davis.
SUAREZ, Emilio y KRAMIS, Jorge. Arquitecturas para ambientes cliente/servidor. En: Software &
Productivity, No. 2 (1995); p. 9-12. México, Powersoft Latin America.
TANEMBAUM, Andrew S. Redes de ordenadores. México, Prentice Hall Hispanoamericana, 1986. p.

530.
THOMPSON, Keith y RIGNEY, Steve. Dialing up the LAN. En: PC Magazine. Vol. 10, No. 15
(septiembre, 1991); p. 177-230. New York, Ziff Davis.
WILLMOTT, Don. The Internet, Make it work for you. En: PC Magazine, Vol. 14, No. 17 (Octubre,

UFPS prototipoOOP Client-Server 1996

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

UFPS prototipoOOP Client-Server 1996

Hochgeladen von

Copyright:

Verfügbare Formate

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

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

DISEÑO Y DESARROLLO DE UN PROTOTIPO BAJO EL PARADIGMA DE

PABLO JESÚS MOGOLLÓN SOMAVILLA

Trabajo de grado presentado

DIRECTOR: MARTÍN CALIXTO

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

El autor expresa su agradecimiento a:

MARTÍN CALIXTO, Ingeniero de Sistemas, Profesor de la Escuela de Ingeniería de Sistemas de

DÉBORA DAZA DURÁN, Licenciada en Bibliotecología, Profesora de técnicas de redacción de

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER.

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

PABLO P. MOGOLLÓN SÁNCHEZ, Doctor 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

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.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

2.1 NIVELES DE LA ARQUITECTURA 18

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.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.3 PROTOCOLOS DE TRANSPORTE TCP/IP 27

4.3 LOS CLIENTES 32

4.4 CÓDIGOS DE CARACTERES 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

4.8.1 Registro de conexión 35

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