Practica Profesional ISFT 151 Noviembre 2014, Argentina

Arquitectura Web Distribuida en C++

Gabriel González Ferreira1, Sandra Machado2, Gabriel Alejandro Di Massa3, Juan

Manuel Silva4
1234Alumnos de la Práctica Profesional del Instituto Superior de Formación Técnica N° 151,
San Juan 4197, Mar del Plata, Argentina.

Profesor a Cargo: Gabriel Pimentel.

Resumen – La investigación se llevó a cabo con la creación e implementación de una de

arquitectura distribuida en C++. Se generó un ejecutable construído en C++ y se ejecutó en un
servidor HTTP mediante el uso de la interfaz CGI (Common Gateway Interface) y el estándar
que especifica. Toda la investigación se basó en estándares abiertos: DOM (Document Object
Model), HTTP (Hypertext Transfer Protocol RFC 2616), URI (Uniform Resource Identifiers
RFC 2396), C++ (ISO/IEC 14882:2011), STL (Standard Template Library), SQL (ISO/IEC
9075-1:2011). Se programaron bibliotecas ajustándose a estos estándares para facilitar la
implementación sintáctica y semántica de los mismos. Cabe mencionar que se programó una
biblioteca para implementar una manipulación simple y efectiva del Modelo en Objetos para la
Representación de Documento (DOM) en C++.

1. INTRODUCCIÓN
En el presente trabajo se investigó acerca de la posibilidad de utilizar C++ y una arquitectura de
estándares aprobados para realizar una aplicación web distribuida, para poder llegar a tal
cometido se tuvo que desarrollar íntegramente un marco de trabajo en C++ ya que no se contaba
con herramientas de dominio público para el desarrollo web en ese lenguaje y que se ajustasen a
los requisitos de estándares abiertos requeridos.
Basándonos en el protocolo HTTP (RFC 2616 y sustitutos) [1] desarrollamos los analizadores
para interpretar las peticiones respetando el formato URI (Uniform Resource Identifiers RFC
2396) [2]. Una vez analizadas las peticiones y obtenidos sus parámetros se procedió a programar
los manejadores de acceso a la base de datos para lo cual utilizamos el motor open source
Postgresql [3] en las consultas SQL programadas se utilizó íntegramente sentencias propias del
estándar de esta tecnología [4]
Para operar con la vista y manipular el contenido HTML, se diseñó una biblioteca en C++ en
acuerdo con la Document Object Model (DOM) Level 2 Core Specification [5].
Para que el binario resultante de la aplicación pueda ser ejecutado en el servidor HTTP se usó la
interfaz CGI [6] y el módulo para el servidor correspondiente.

1
RF- 01 Alta de Alumnos
Objetivos asociados OBJ–01 Gestionar los alumnos
Requisitos asociados RI–01 Información sobre alumnos
Descripción El sistema deberá comportarse tal como se describe en el
siguiente caso de uso cuando alguien solicite su ingreso
como Alumno
Precondición El solicitante no es un alumno del instituto y tiene su
documentación disponible.
Secuencia Paso Acción
Normal 1 El preceptor solicita al sistema comenzar el
proceso de alta de un nuevo alumno
2 El sistema solicita los siguientes datos del nuevo
alumno: nº del DNI, nombre, apellidos, fecha de
nacimiento, sexo, dirección y teléfono, datos de
la planilla A1, y la documentación
correspondiente para armar el legajo.
3 El preceptor solicita los datos requeridos y la
documentación al nuevo alumno
4 El preceptor comprueba que los datos
del nuevo alumno coinciden con los de la
documentación aportada
5 El preceptor proporciona los datos requeridos y
solicita al sistema que los almacene.
6 El sistema almacena los datos proporcionados,
imprime la planilla A1 y informa al preceptor de
la carrera de que el proceso ha terminado con
éxito
7 El preceptor entrega un ticket al alumno
constatando de que se ha inscripto correctamente.
Postcondición El alumno se ha inscripto en años anteriores y por lo tanto
ya tiene la documentación.
Excepciones Paso Acción
4 Si la documentación aportada no es correcta, el
preceptor cancela la operación, a continuación
este caso de uso termina
5 Si el sistema detecta que el nuevo alumno ya es
alumno del instituto, el sistema informa de la
situación al preceptor permitiéndole modificar los
datos proporcionados, a continuación este caso de
uso continúa
5 Si el preceptor decide cancelar la operación, el
sistema cancela la operación, a continuación este
caso de uso termina
Rendimiento Paso Cota de tiempo
4 60 segundos
Frecuencia esperada 15 veces/día
Estabilidad alta
Comentarios La frecuencia será mucho mayor durante la segunda
semana de diciembre y tercera semana de febrero,
probablemente 15 veces/día

2
 Fig 1: Diagrama de casos de uso del ejemplo implementado.

Diccionario de datos:
• Preceptor =*Secretario encargado de tareas administrativas de la institución*
Constancias:
A= *alumno*.
D=*docente*.

• Código de planilla =* código con el cual se identifica el formulario [A|D]+ Numero*.

• Documentación Aportada=
▪ Matriculación= *constancia que se ha presentado todos los requisitos*+fotocopias
dni +titulo + nro de registro +foto+ certificado médico.
◦ Alumno:
▪ Datos personales= Apellido +nombres +sexo + dni +fecha y lugar de nacimiento
+estado civil+ hijos (cantidad)+familiares a cargo + domicilio + Nro +piso +
depto +loc / barrio+ partido + código postal + teléfono+ teléfono alternativo
(pertenece a )
▪ Estudios cursados=* estudios realizados por el alumno*
▪ Otros estudios= *otros estudios realizados por el alumno*+institución +año de
egreso datos laborales =*Información laboral del alumno*+trabaja [ si | no]+
actividad +horario habitual +obra social.
▪ Solicitud de inscripción =aspirante+ año+ Instituto+ carrera +turno +fecha de
solicitud de la inscripción + presento documentación +visada por.
▪ Titulo= [nivel medio | polimodal]+año de egreso+ escuela distrito.
3
Fig 2: Diagrama de sequencia del ejemplo implementado.

4
2. ARQUITECTURA
Si bien no se implementó de manera pura la arquitectura MVC (Model View Controller –
Modelo Vista Controlador) [7], es la arquitectura que mejor se ajusta ya que se hizo uso de un
patrón para resolver la persistencia en el modelo relacional y mantener el modelo en objetos lo
más íntegro posible.
A continuación se ve en la figura 3 un diagrama de clases de la arquitectura implementada:

Fig 3: Diagrama de clases de la arquitectura implementada.

5
ActionMap::Create()
{
_httpActionMap["CreateUser"] = new CreateUser;
_httpActionMap["ReadAllUsers"] = new ReadAllUsers;
return _httpActionMap;
}
void CreateUser::executeWith( parameters)
{
user->setName(parameters["user-name"]);
usersDataset -> create(user);
usersView -> displayListOf(allUsers);
}

Fig 4a y 4b: Diagrama de secuencia de la arquitectura implementada.

View::Change()
{
view.Update();
}

6
2.1 MODELO

Fig 5: Diagrama de secuencia de la interacción del modelo.

En el modelo se aplicó una simple técnica de persistencia acuñada por Martin Fowler como Data
Mapper [8], donde una clase en este caso el Dataset separa los objetos en memoria de la base de
datos. Su responsabilidad es para transferir datos entre los dos y también para aislarlos unos de
otros.

3. CONTROLADOR

Fig 6: Diagrama de secuencia resaltando la sección del controlador.

El diseño del controlador se ve representado principalmente por las acciones encapsuladas en un

TDA (Tipo de Dato Abstracto): Action, pero también contempladas por el manejador de
peticiones (Request Handler) que permite convertir las peticiones en Acciones reales para el
sistema, direccionarlas y separar sus parámetros.

7
4. VISTA

Fig 7: Diagrama de secuencia resaltando la sección de la Vista

Para poder separar el control de la Vista se desarrolló una biblioteca para manipular el DOM
(Document Object Model) [5]. Los documentos HTML[9] estáticos son manipulados y
dinamizados por alcance, manteniendo una real separación entre la lógica de la vista y su
representación y maquetación.

5. CONCLUSIONES
Se realizó un relevamiento de los estándares abiertos y públicos que combinados sirvieron para
desarrollar una aplicación web distribuida en c++.
Se aplicaron ciertos principios de diseño y una arquitectura que hicieron posible la separación de
la lógica de negocio y la capa de datos.
Se utilizó un lenguaje compilado para desarrollar un ejecutable en el ámbito de un servidor
HTTP.
En base a lo expuesto, se concluye que es posible realizar “Aplicaciones Web” con un lenguaje
con las características de C++.

8
6. REFERENCIAS
[1]Hyper Text Tranfer Protocol y sustitutos en:
http://www.w3.org/Protocols/rfc2616/rfc2616.html.
[2]Uniform Resource Identifiers (URI): GenericSyntax
https://www.ietf.org/rfc/rfc2396.txt.
[3] http://www.postgresql.org/about/ .
[4]SQL (ISO/IEC 9075-1:2011)
http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=53681.
[5] Document Object Model (DOM) Level 2 Core Specification http://www.w3.org/DOM/ .
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ .
[6] CGI (Common Gateway Interface) http://tools.ietf.org/html/rfc3875 .
[7] Model-View-Controller (MVC) http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html .
[8] Data Mapper http://martinfowler.com/eaaCatalog/dataMapper.html.
[9] HTML (Hypertext Markup Language) https://tools.ietf.org/html/rfc1866.
https://tools.ietf.org/html/rfc2854.
[10] Principios de Diseño.

7. BIBLIOGRAFÍA
Booch, Graddy (1996). “Análisis y diseño orientado a objetos con aplicaciones”. Addison
Wesley Iberoamericana, Reading, Massachusets, United States.
Gamma, Erich; Helm, Richard; Johnson, Ralph; Vissides, John (2003). “Patrones de Diseño:
Elementos de software orientado a objetos reutilizable”. Pearson Addison Wesley, Madrid
España.
Stroustrup, Bjarne (1991). “El Lenguaje de Programación C++ Segunda Edición”. Addison
Wesley Iberoamericana, Reading, Massachusets, United States..
Stroustrup, Bjarne (1997). “The C++ Programming Language Third Edition”. Addison Wesley,
Reading, Massachusets, United States.