MODERNIZACIÓN DE SISTEMA DE
GESTIÓN DE CONTENIDOS
TRABAJO FINAL DE GRADO DE
INGENIERÍA DE SISTEMAS
UNIVERSIDAD NACIONAL DEL CENTRO
DE LA PROVINCIA DE BUENOS AIRES
FACULTAD DE CIENCIAS EXACTAS
por
Bernardo Ezequiel Geringer
Director
Mg. Claudio Aciti
Codirector
Resúmen
El presente trabajo final muestra el resultado de la modernización del Sistema
de Gestión de Contenidos “InnyCMS”, cuya primera versión fue desarrollada en el
año 2008.
A través de los años se incorporaron mejoras al desarrollo para suplir las
falencias encontradas durante su uso. Sin embargo, un trabajo más profundo debía
ser realizado para lograr un producto con mejores prestaciones.
Este trabajo final describe la arquitectura, diseño y tecnologías propuestas
para luego dar paso a una explicación del funcionamiento de InnyCMS como
Sistema de Gestión de Contenidos. Si bien la solución propuesta está enfocada en
la utilización de InnyCMS como un Sistema de Gestión de Contenidos para la
creación de Sitio Web, el mismo puede ser utilizado como Sistema de Gestión de
Contenidos de Propósito General gracias a una mayor flexibilidad a la hora de
definir datos e interfaces de gestión, como así también a la incorporación de un
esquema de usuarios, permisos y roles, ausentes en su versión previa.
El desarrollo, realizado en el lenguaje de programación PHP y utilizando
MySQL como motor de base de datos, posee tres módulos principales. El primero
de ellos, denominado Panel de Administración, permite la gestión de los usuarios,
sitios y roles. El segundo de los módulos, es el Sistema de Gestión de Contenidos,
que permite a los usuarios realizar la administración de los contenidos y
Índice General
Resúmen 1
Índice General 3
Capítulo 1
Introducción 7
1.1 Antecedentes 7
1.2 Motivación 9
1.3 Objetivo 10
1.4 Alcance 11
1.5 Organización del Trabajo 11
Capítulo 2
Estado del Arte 13
2.1 Sitios y Aplicaciones Web 13
2.2 Sistemas de Gestión de Contenidos (CMS) 15
2.3 Bases de Datos 16
2.3.1 MySQL 16
2.3.2 MariaDB 17
2.3.3 Microsoft SQL Server 17
2.3.4 PostgreSQL 17
2.3.5 CouchDB 18
2.3.6 MongoDB 18
2.3.7 Cassandra 18
2.4 Lenguajes de Programación (Serverside) 19
2.4.1 ASP.NET 20
2.4.2 JAVA/JSP 20
2.4.3 Python 21
2.4.4 PHP 21
2.4.5 JavaScript/Node.js 23
2.5 Alojamiento de Sitios y Aplicaciones Web (Hosting) 24
2.5.1 Apache Tomcat 25
2.5.2 Microsoft ISS 25
2.5.3 Nginx 25
2.5.4 Apache HTTP Server 25
2.6 Servicios de terceros 28
2.7 CMS Dinámicos 29
2.7.2 Plugins 32
2.7.3 Arquitecturas Orientadas a Objetos 32
2.7.4 Mecanismo de Callbacks 33
2.7.5 Plantillas del CMS 34
Capítulo 3
Análisis de requerimientos 35
3.1 Requerimientos Funcionales 35
3.2 Requerimientos No Funcionales 37
3.2.1 Compatibilidad 37
3.2.2 Portabilidad 37
3.2.3 Usabilidad 37
3.2.4 Seguridad 38
3.2.5 Mantenibilidad 38
3.2.6 Auditabilidad 38
Capítulo 4
Arquitectura y diseño de la solución 39
4.1 Selección de tecnologías utilizadas 39
4.1.1 Base de Datos: MySQL / MariaDB 39
4.1.2 Lenguaje de Programación Back-End: PHP + Smarty 39
4.1.3 Framework Frond-End: Metronic (Bootstrap + jQuery) 40
4.1.4 Sistema de Control de Versiones: Git 41
4.1.5 Servidor Web: Apache HTTP Server 41
4.2 Descripción de la arquitectura de la solución 41
4.2.1 Cliente 42
4.2.2 Servidor 44
4.2.3 Base de Datos 45
4.3 Diseño de la solución 53
4.3.1 Panel de Administración 54
4.3.1.1 Sitios 55
4.3.1.2 Colecciones de un Sitio 58
4.3.1.3 Sidebar 61
4.3.1.4 Usuarios 62
4.3.1.5 Usuarios y Sitios 65
4.3.1.6 Auditabilidad 67
4.3.2 Sistema de Gestión de Contenidos 68
4.3.2.1 Inicio de Sesión 68
4.3.2.2 Selección de Sitio 68
4.3.2.3 Perfil de Usuario 70
4.3.2.5 Colecciones 71
4.3.2.5.1 Listado de documentos 72
4.3.2.5.2 Crear un documento 73
4.3.2.5.3 Editar un documento 75
4.3.2.5.4 Visualizar un documento 76
4.3.2.5.5 Reposicionar un documento 76
4.3.2.5.6 Borrar un documento 77
4.3.2.5.7 Importar / Exportar documentos 77
4.3.2.5.8 Borrar todos los documentos 79
4.3.2.6 Categorías 79
4.3.2.7 Bucket 80
4.3.2.7.1 Subir archivos 80
4.3.2.7.2 Listado de archivos 82
4.3.2.7.3 Borrar archivos 83
4.3.2.7.4 Etiquetar archivos 84
4.3.2.7.5 Buscar archivos 85
4.3.2.7.6 Limpiar bucket 86
4.3.2.7.7 Vaciar bucket 87
4.3.3 API 87
4.3.3.1 Manipulación de archivos 88
4.3.3.2 Manipulación de documentos 89
4.3.4 Tipos de Datos 92
4.3.4.1 InnyType_Text 95
4.3.4.2 InnyType_Textarea 98
4.3.4.3 InnyType_Richtext 99
4.3.4.4 InnyType_Email 100
4.3.4.5 InnyType_Integer 101
4.3.4.6 InnyType_Float 103
4.3.4.7 InnyType_Datetime 104
4.3.4.8 InnyType_Date 105
4.3.4.9 InnyType_Time 105
4.3.4.10 InnyType_Checkbox 106
4.3.4.11 InnyType_Radio 107
4.3.4.12 InnyType_Select 108
4.3.4.13 InnyType_Reference 110
4.3.4.14 InnyType_Binary 112
4.3.5 Documentos y Colecciones 114
Capítulo 5
Experiencia de uso del sistema 121
5.1.1 Gesell.Tur.Ar 122
5.1.2 Diario El Tiempo 123
5.1.3 deKit 124
5.1.4 Metigoshe Lutheran Church 125
5.2 Resultados obtenidos 125
5.2.1 Gesell.Tur.Ar 126
5.2.2 Diario El Tiempo 128
5.2.3 deKit 130
5.2.4 Metigoshe Lutheran Church 132
Capítulo 6
Conclusión 133
Capítulo 7
Trabajos futuros 136
7.1 Login con Google y Facebook 136
7.2 Formulario de Registro de Usuarios 136
7.3 Tablas con diseño a medida 136
7.4 API REST 136
7.5 Cambiar conector de base de datos 137
7.6 Permitir conectar con otras bases de datos 137
7.7 Limitar tamaño de base de datos 137
Índice de Figuras 138
Capítulo 1
Introducción
1.1 Antecedentes
Los primeros sitios web, que formaron parte de la llamada Web 1.0, eran
simples archivos HTML estáticos alojados en un directorio de un servidor web. La
actualización de estos archivos, a través del protocolo FTP, era sumamente
engorrosa. Esta primera versión de la web, de acuerdo a Berners-Lee, podría ser
considerada de solo lectura [1]. Si se requería una modificación a una porción de
código común a todas las páginas, necesariamente habría que modificar de forma
individual cada uno de los archivos.
El primer paso para avanzar hacia la gestión de contenidos en un sitio web
fue la incorporación de Server Side Includes [2]. SSI es un conjunto de directivas
escritas en los archivos HTML, que son evaluadas por el servidor web al momento
recibir la solicitud del recurso correspondiente. Estas directivas permiten añadir
contenido generado de forma dinámica a las páginas web.
Con la llegada de los lenguajes de scripting en el lado del servidor como
ASP, PHP y más tarde JSP, la entrega de sitios web generados dinámicamente
comenzó a ser cada vez más frecuente. La introducción del DOM (Modelo de
Objetos del Documento), que permite la manipulación de los elementos que
conforman el documento HTML y utilizando llamados asíncronos a través de
JavaScript, permitió la actualización de la información presentada en el sitio web sin
necesidad de recargar la página [3].
Todos estos avances tecnológicos potenciaron la cantidad de sitios e
de forma organizada toma real importancia. Cuando una organización adopta una
estrategia de gestión de contenidos unificada, puede asegurar que el contenido será
consistente independientemente de la plataforma o medio por el cuál se lo consulte.
Entre las principales ventajas de contar con un sistema de gestión de contenidos se
pueden mencionar: menor tiempo al mercado, mejor utilización de recursos,
reducción de costos, mejor calidad de contenido y distribución ilimitada a distintos
medios [4][5].
Los primeros sistemas de gestión de contenidos surgen a finales del año
1995, con Vignette. La intención de este software era hacer más accesible y
personalizada la publicación de de sitios web. Es a este software al que se le da el
crédito de acuñar el término “sistema de gestión de contenidos” [3].
La principal función de un sistema de gestión de contenidos es la de brindar,
a partir de una única fuente de información, los datos necesarios a ser consumidos
por sitios web, aplicaciones móviles, folletos impresos u otro tipo de publicaciones a
medida [6][7].
A principio de los 2000, los sistemas de gestión de contenidos dominaban la
web. Distintos frameworks de programación y CMS libres aparecieron [8].
OpenCMS, PHP-Nuke, WordPress, Drupal y Joomla ofrecían alternativas gratuitas
para gestionar contenido. La masividad y popularidad de estos sistemas los lleva a
ser el principal foco de ataques y hackeos en la web [9].
A partir de 2003, algunos sistemas de gestión de contenidos ofrecían
plantillas prefabricadas para usuarios sin conocimientos de HTML o CSS. Algunas
de ellas como Wordpress (2003) o Wix (2006), sin llegar a ser puramente sistemas
de gestión de contenidos, facilitan a los usuarios beneficiarse de un sitio web sin
tener conocimientos de programación, utilizando desarrollos, extensiones y
1.2 Motivación
Este Trabajo Final surge en el marco de una empresa de software, la cual
posee un área de desarrollo de sitios web apuntado principalmente a PyMES del
ámbito local y nacional.
Debido a la naturaleza del sector al que apunta este área de negocios, la
empresa optó por desarrollar un sistema de gestión de contenidos web propio
apuntado a optimizar el desarrollo, despliegue, control de calidad, gestión, tiempos
de capacitación de personal y mantenimiento en general de sitios web, con el fin de
ofrecer buenas soluciones a precios competitivos.
Fue así como se desarrolló el sistema de gestión de contenidos InnyCMS.
Este software de gestión de contenidos, desarrollado en el año 2008, sirvió durante
años a la empresa y a cientos de clientes.
Debido a la antigüedad del desarrollo y al avance tecnológico en materia de
sitios web durante los últimos años, InnyCMS carece actualmente del nivel de
diseño y prestaciones que los usuarios esperan de un sistema de gestión de
contenidos moderno.
El principal problema detectado fue la imposibilidad de realizar la gestión de
contenidos desde dispositivos móviles de manera cómoda y ágil, siendo este punto
el principal encontrado para realizar la modernización.
Otro aspecto a considerar fue la imposibilidad de realizar la gestión de
contenidos de un sitio por más de un usuario, conllevando esto a un único
superusuario que realizaría de forma irrestricta la gestión de toda la información
Se detectaron también falencias en la administración del espacio de
almacenamiento y en la imposibilidad de importar y exportar datos desde y hacia
otros sistemas externos.
Por último, los avances y mejoras del lenguaje de programación en el que
estaba implementada la solución, varios métodos y funcionalidades fueron
quedando obsoletas o deprecadas, por lo que el estancamiento de la versión del
lenguaje limitaba la capacidad de los desarrolladores beneficiarse, en los desarrollos
que utilizan InnyCMS, de las nuevas características del lenguaje.
Es por estos motivos que se comenzó a evaluar una modernización del CMS
para ofrecer a los clientes y desarrolladores una solución que guarde relación a los
tiempos que corren y las tecnologías más utilizadas [10][11][12].
1.3 Objetivo
Se propone como objetivo de este trabajo el diseño y desarrollo de una nueva
versión de InnyCMS, contemplando las falencias detectadas en la versión anterior y
las sugerencias recibidas tanto por los desarrolladores como por los clientes finales.
Deberá ser posible utilizar InnyCMS desde un dispositivo móvil como desde
un ordenador de forma indistinta, proveyendo las mismas funcionalidades en todos
los casos y permitiendo siempre una correcta visualización de la interfaz de usuario,
asegurando una óptima usabilidad y experiencia de usuario.
El desarrollo deberá contemplar un esquema de roles y permisos que permita
limitar el acceso al sistema y a las funcionalidades que se ofrezcan para cada
El sistema debe proveer una serie de métodos que conformen una API para
consulta y edición de información sin necesidad de utilizar la interfaz gráfica
propuesta.
1.4 Alcance
El sistema contempla las funcionalidades que le permitirán a un primer
conjunto de usuarios, llamado administradores, realizar la administración de
usuarios y sitios web que posea el CMS y otro conjunto, llamado administradores de
sitios, realizar la gestión de los contenidos de los sitios web que se le hayan
asignado.
El CMS provee a los desarrolladores un conjunto de métodos, a través de su
API, que permite conectar el sitio web del cliente con la información almacenada en
la base de datos a través de InnyCMS.
La interfaz de usuario de InnyCMS cuenta con un diseño responsivo que
asegura la correcta visualización de la interfaz de usuario en la mayoría de los
dispositivos móviles y de escritorio.
El sistema asegura la compatibilidad con PHP 7, la versión más reciente del
lenguaje, para que la interpretación del código se realice sin advertencias ni errores.
1.5 Organización del Trabajo
El presente trabajo está organizado del siguiente modo: En este capítulo se
realiza la introducción al tema, exponiendo el objetivo de este Trabajo Final. En el
siguiente se presenta el estado del arte. A continuación, en el tercer capítulo, se
analizan los requisitos funcionales y no funcionales de la solución. En el cuarto se
describe y detalla la solución propuesta para llegar al objetivo de este Trabajo Final.
Capítulo 2
Estado del Arte
2.1 Sitios y Aplicaciones Web
Una página web es un documento que puede ser accedido y visualizado a
través de un navegador de Internet [13]. Este documento está escrito en el lenguaje
HTML y puede contener: texto; especificación de estilos de diseño que adaptan la
estética visual de la página (hojas de estilos); fragmentos de código para ejecución
local (scripts) que permiten mayor interactividad con el usuario y el contenido del
sitio; y archivos multimedia como imágenes, sonidos y videos.
Un sitio web es una colección de páginas web relacionadas y conectadas
entre sí que comparten un único nombre de dominio o dirección de Internet [14]. En
un sitio web tradicional, los usuarios son llamados visitantes, ya que son
simplemente consumidores de los datos y recursos que el sitio web posee y que
viajan únicamente en un solo sentido.
Como contraparte existe el concepto de aplicación web: Un conjunto de
páginas web que comparten un nombre de dominio, que posee interacción con el
usuario y existe envío de datos en ambos sentidos. A la hora de utilizar una
aplicación web, sus usuarios podrán, además de consumir recursos, modificarlos,
crear nuevos, e incluso borrar los existentes. Además, las aplicaciones web
permiten a sus usuarios realizar acciones no relacionadas con su contenido: enviar
correos electrónicos, participar de encuestas, realizar compras y pagos online,
consultar el estado de un envío postal, realizar un comentario u opinar sobre un
tema en particular, publicar o compartir contenido en redes sociales, entre tantas
Es importante aclarar que si bien la diferencia entre sitio y aplicación web es
clara y bien marcada, en ocasiones la industria suele utilizar ambos términos de
forma cruzada e indistinta. Esto se debe a que en la actualidad, la mayoría de los
llamados “sitios web” permiten algún nivel de interacción con sus visitantes (aunque
sólo sea la opción de comunicarse mediante un formulario de contacto, o un botón
para compartir el sitio con otros usuarios). Es por esto que la línea que separa los
sitios de las aplicaciones web se hace cada vez más difusa, y estos términos se
utilizan en muchos casos de forma indistinta.
Para ejemplificar estos dos conceptos podemos decir que un sitio web puede
ser un blog o diario online, un portal de consulta del clima, un folleto online de un
destino turístico o la cartelera del cine local. De igual manera podemos ejemplificar
como aplicaciones web a los siguientes tipos de portales: webmail, una wiki, una red
social, una banca online o los sistemas de gestión de contenidos.
Finalmente, se pueden encontrar los llamados portales de Internet [15]. Un
portal de Internet (web portal en inglés) es una herramienta web que ofrece a sus
usuarios, acceso a una serie de recursos y servicios relacionados a un mismo tema.
Un portal puede incluir diferentes subsitios y aplicaciones como buscadores, foros,
documentos, compra electrónica, enlaces relacionados, etc. Se puede decir que el
principal objetivo de un portal en Internet, es el de resolver las necesidades de
información específica sobre un tema en particular.
Ejemplos de este tipo de web pueden ser los sitios web de organizaciones
como gobiernos locales o nacionales que reúnen en único portal toda la información
y brindan de forma centralizada todos los servicios disponibles para los ciudadanos.
Si bien existen muchas formas de categorizar los diferentes sitios web, este
trabajo se basa en el contenido de los mismos (y en particular, en la administración
de sus contenidos). Bajo este punto de vista, existen dos tipos de sitios web: Los
estáticos, que requieren la intervención de un desarrollador que modifique los
al mismo; y los dinámicos,que pueden presentar a sus usuarios distinta información sin que se requiera modificación a los archivos de código fuente.
Los sitios dinámicos generalmente obtienen su información de una o más
bases de datos, e incluyen un sistema que permite gestionar los contenidos
almacenados en las mismas, facilitando en gran medida las tareas de
mantenimiento de los administradores del sitio. Estos sistemas son conocidos como Sistemas de Gestión de Contenidos (en inglés: Content Management System, más
conocido por sus siglas CMS).
2.2 Sistemas de Gestión de Contenidos (CMS)
Un sistema de gestión de contenidos es un claro ejemplo de una aplicación
web. Un CMS permite a los usuarios del mismo agregar, editar o eliminar los datos
que deseen tener guardados en un repositorio, principalmente para utilizar en su
sitio web, sin necesidad de tener conocimientos técnicos. En este sentido podemos
decir que el CMS funciona como una capa que facilita la interacción entre el usuario
y la base de datos [6][7].
Los sistemas de gestión de contenidos se configuran y ejecutan en un
servidor web y proveen servicios al usuario final a través de una interfaz (frontend)
que generalmente es accedida utilizando un navegador de Internet.
Facilita el mantenimiento de los sitios web ya que no requiere crear o editar
un nuevo archivo fuente con cada nueva publicación o modificación que se haga en
el sitio así como tampoco requiere modificar todos los archivos ya programados
cuando se introduzca un cambio visual a la web, ya que la generación de las
páginas es dinámica a través de plantillas.
Los contenidos que por lo general se gestionan son textos, gráficos,
La utilización de un sistema de gestión de contenidos puede permitir el
versionado de los datos, el manejo de usuarios y diferentes niveles de permisos e
interfaces para proveer la información a diversas fuentes.
2.3 Bases de Datos
Como se explicó en el punto anterior, los sistemas de gestión de contenidos
suelen utilizar motores de bases de datos donde almacenan los datos que el usuario
dispone para gestionar. Actualmente existe en el mercado una gran variedad de
motores de bases de datos que se adaptan a las necesidades de cada proyecto en
cuanto a escalabilidad, simplicidad, seguridad, performance o costos.
Las dos principales categorías en las que se clasifican las bases de datos
son según sean éstas relaciones o no relacionales. Como ejemplos de bases de
datos relacionales, se pueden remarcar MySQL, MariaDB, Microsoft SQL Server y
PostgreSQL, mientras que como ejemplo de bases de datos no relacionales podemos destacar CouchDB, MongoDB y Cassandra.
2.3.1 MySQL
MySQL es el motor de base de datos más popular y
conocido del mercado, actualmente propiedad de Oracle, dispone de licencias de uso libre como así también dispone
de versiones propietarias y pagas que agregan funcionalidades adicionales [16].
Este motor está disponible en todos los sistemas operativos y es utilizado por
una gran variedad de aplicaciones web como Wordpress, Joomla, Drupal, Simple
Machine Forums, phpBB y portales de gran escala como Facebook, Google, Twitter,
2.3.2 MariaDB
Luego de que Oracle adquirió Sun Microsystem (y
con él a MySQL), surge de la mano de un grupo de los
desarrolladores originales de MySQL una nueva base de
datos que se basa en el código fuente de MySQL. Esta nueva base de datos
introduce grandes cambios y mejoras tanto en lo técnico como en lo legal,
garantizando que siempre habrá una versión de MariaDB con licencia GPL[17]. De
esta forma, la comunidad de software libre obtiene nuevamente una base de datos
en su ecosistema que resulta altamente compatible con MySQL y que permite, en la
gran mayoría de los casos, cambiar de MySQL a MariaDB sin mayores
inconvenientes.
2.3.3 Microsoft SQL Server
Es el motor de base de datos de Microsoft,
utilizado ampliamente en sus productos. Posee soporte
para guardar y recuperar información de aplicaciones
que corren tanto local como remotamente a través de
una red. Microsoft SQL Server corre únicamente en los sistemas operativos
Windows y en una acotada cantidad de distribuciones de Linux [18].
2.3.4 PostgreSQL
Otro popular motor de base de datos relacional es
PostgreSQL, de código abierto y utilizado por Instagram,
posee una gran de usuarios y usa control de
concurrencia multiversión que le permite a cada
transacción tener una foto de la base de datos y así evitar locks de lectura.
2.3.5 CouchDB
A diferencia de las bases de datos mencionadas
anteriormente, CouchDB es un gestor de bases de datos
NoSQL de código abierto [20]. Esto significa que no
almacena sus datos y relaciones en tablas sino que lo
hacen en colecciones de documentos independientes
utilizando el formato JSON y permitiendo consultas a través del lenguaje JavaScript.
Esto lo convierte en un motor totalmente pensado para ser usado en la web.
2.3.6 MongoDB
MongoDB es también un motor de gestión de
bases de datos NoSQL de código abierto que
almacena documentos en colecciones. El formato que utiliza es BSON, basado en
JSON, pensado para utilizar más eficientemente el almacenamiento y la velocidad
de acceso [21]. Entre las principales características, el formato BSON introduce
mejoras al almacenar los tipos de datos o la longitud de los mismos en caso de ser
muy grandes, incurriendo en mayor espacio en disco utilizado.
2.3.7 Cassandra
Este motor de base de datos NoSQL también
almacena documentos y su fuerte es que es es distribuido y
basado en un modelo de almacenamiento clave-valor [22].
Desarrollado en Java y utilizado por compañías como Uber,
Reddit, Netflix y Apple, se utiliza en sistemas que requieren
2.4 Lenguajes de Programación (Serverside)
Un sitio web dinámico o una aplicación web debe ser desarrollada utilizando
un lenguaje de programación que provea tanto las capacidades necesarias para el
desarrollo de páginas web, como así también las herramientas necesarias para
conectarse con diversos motores de bases de datos, APIs y aplicaciones de
terceros con los que se deba integrar un desarrollo web.
Entre los lenguajes más populares para el desarrollo web están ASP.NET,
Java/JSP, Python, PHP, Ruby, Neko, Perl, Rust y Javascript con NodeJS, entre
otros. Para evitar extender este apartado sobre lenguajes de programación más de
lo necesario, nos enfocaremos en los 5 lenguajes más populares del mercado
actual: PHP, Java/JSP, ASP.NET, Python y JavaScript/NodeJS.
Cada uno de ellos posee sus particularidades y ventajas por sobre los
demás, dependiendo de las prestaciones requeridas, el hardware sobre el que se
esté por montar el desarrollo y el volumen esperado de tráfico que deberá soportar
la solución.
Entre las distintas clasificaciones que podemos hacer entre ellos, la que más
se destaca es si los mismos son compilados o interpretados. Tanto ASP.NET como
JSP son lenguajes que deben ser compilados para poner una aplicación en
funcionamiento; Como contraparte PHP, Javascript y Python son lenguajes que no
deben ser compilados para poner a correr la aplicación dentro de un servidor, sino
que basta con disponer de los archivos de código fuente para realizar su ejecución.
Esta clasificación resulta importante ya que los lenguajes interpretados,
dónde el código fuente es el entregable, permiten procesos de deploy más simples
y eficientes, lo que ahorra costos de desarrollo y mantenimiento. Al mismo tiempo la
sean técnicamente de código abierto para el cliente, lo que puede hacer que en algunos casos estos lenguajes no sean viables para ciertos proyectos.
A continuación se detallan las características de los principales lenguajes para desarrollo analizados en este trabajo:
2.4.1 ASP.NET
Es un framework de código
abierto, desarrollado por Microsoft, para la construcción de sitios web dinámicos,
aplicaciones web y servicios web [23].
Este framework está construido sobre el Common Language Runtime, un
entorno de ejecución que permite a los desarrolladores escribir código ASP.NET
utilizando cualquier lenguaje admitido por el .NET Framework, como C++, C# o
Visual Basic.
Si bien hasta hace unos años, los desarrollos realizados en .NET Framework
solamente podían ser ejecutados en ambientes Windows, hoy por hoy existen
versiones de ASP.NET Core que permiten construir y ejecutar aplicaciones tanto en
Windows, como en Linux y Mac OS.
2.4.2 JAVA/JSP
JavaServer Pages es una tecnología que
ayuda a los desarrolladores a crear sitios web
dinámicos basados en HTML y XML a partir del
lenguaje de programación Java [24]. Si bien
existen otras herramientas y frameworks como
sitios web sobre el lenguaje Java, JSP es la alternativa pura de Java para la construcción de un sitio web.
La primera vez que un usuario accede a un archivo JSP, el servidor web
convertirá este archivo en código fuente Java, compilará este código, cargará la
nueva clase en la memoria de la máquina virtual de Java y ejecutará el servicio de la
clase resultante. Este proceso suele tomar cierto tiempo, por lo que usualmente se
nota un retraso en el primer acceso a un archivo JSP. Las peticiones subsiguientes
serán procesadas más rápidamente debido a que el servidor invoca directamente al
método de la clase que fue generada y cargada la primera vez que el el archivo fue
solicitado.
2.4.3 Python
Es un lenguaje de código abierto,
interpretado, de alto nivel, de propósito múltiple, con tipos dinámicos y manejo
automático de memoria con hincapié en la
legibilidad del código con una sintaxis simple y concisa [25].
El lenguaje Python puede ser descargado e instalado en cualquier sistema
operativo y, además, posee innumerables plugins, complementos y frameworks que
extienden las funcionalidades básicas del lenguaje y enriquecen enormemente los
desarrollos web.
2.4.4 PHP
Es un lenguaje de scripting para servidores, de
propósito general y especialmente adecuado para el
El código PHP es procesado por un intérprete, que suele ejecutarse como un
módulo dentro de los propios servidores de páginas web. El servidor combina el
resultado de la interpretación y ejecución del código PHP con los recursos
solicitados por el navegador web y los entrega al mismo para que estos puedan ser
presentados usuario final.
El código PHP puede ser embebido entre código HTML para la generación de
sitios web dinámicos o puede ser utilizado de forma standalone para la creación de
scripts que corren por consola.
Debido a que el lenguaje PHP es totalmente interpretado y en su forma más
pura debe ser procesado con cada petición al servidor, existen extensiones como
PHP-FPM que mejoran la performance de las peticiones, manteniendo una copia en
memoria de los archivos PHP ya precompilados, lo que permite ahorrar lecturas en
disco y tiempos de compilación.
A la hora de publicar un desarrollo hecho en lenguaje PHP, se debe subir al
servidor el código fuente de la solución junto con todos los archivos o assets que
incluya el desarrollo como imágenes, animaciones, archivos javascript, hojas de
estilo, html estáticos, etc.
Debido a que PHP es un lenguaje multiparadigma, podemos desarrollar
programas bajo el paradigma funcional, procedural, orientado a objetos o alguna
combinación de ellos ya que debido a su enfoque híbrido y a la ausencia de threads,
eventos o una instancia maestra, cada script comienza y termina cada vez que es
invocado explícitamente sin interferir con otras ejecuciones existentes, reduciendo
así la posibilidad de fallo general del sitio web y evitando el consumo de recursos
innecesarios en el servidor en caso de que ningún script o recurso esté siendo
2.4.5 JavaScript/Node.js
Node.js es una entorno de ejecución
multiplataforma, de código abierto, que
permite la ejecución de código JavaScript en
servidores, donde agrega una capa de manejo
de redes y acceso a los recursos del sistema,
que no están disponibles cuando se utiliza dentro de un navegador web [27].
JavaScript es un lenguaje potente y liviano, orientado a eventos, que permite
el desarrollo tanto de aplicaciones front-end como back-end.
Debido a su naturaleza orientada a eventos, las soluciones de servidor
implementadas en javascript, suelen incluir su propio servidor web (inician un socket
donde reciben y administran conexiones de red), y no necesita de un servidor web
adicional como Apache HTTP server o NGinx, lo que lo hace ideal para soluciones
donde se requiere adaptar los protocolos HTTP o en aquellos escenarios donde
Apache HTTP Server o NGinx no funcionan adecuadamente (como puede ser la
comunicación por web-sockets).
Es importante aclarar que ni JavaScript ni Node.js brindan soporte para
múltiples threads (sino que existe un único thread que ejecuta la aplicación
completa). Esto generalmente no es un problema debido a que su por naturaleza
asincrónica se generan interrupciones constantes en el flujo de ejecución (por
ejemplo, al enviar una consulta a una base de datos, mientras se espera el
resultado, se continúa con la ejecución de otros eventos, y cuando llega el resultado
de la base de datos, se ejecuta el evento asociado a la finalización de la misma).
El lado negativo de esta limitación, es que si ocurre un error o excepción no
capturada, se detiene la ejecución de la aplicación completa. Así mismo, en caso de
falta poner en funcionamiento múltiples instancias de Node.js e incluir un esquema de balanceo de carga en la aplicación.
Finalmente, cada aplicación que corra en un servidor deberá tener asignado
un puerto diferente, por lo que utilizar muchas aplicaciones Node.js en un servidor,
implica que sólo una podrá utilizar los puertos estándar 80 y 443, o bien que se
deberá configurar un servidor web como Apache o NGinx, que actúe de proxy ante
todas las instancias Node.js. Por este motivo, es que la gran mayoría de los
servicios de hosting, no brindan soporte para este lenguaje (salvo aquellos que
ofrecen máquinas virtuales o dedicadas, que son más complejas de utilizar que los
servicios de hosting estándar).
2.5 Alojamiento de Sitios y Aplicaciones Web (Hosting)
A la hora de llevar un desarrollo a la nube, existen dos grandes alternativas
para poder alojar un sitio o aplicación web: Servidor dedicado o servidor compartido.
Esta decisión no siempre es trivial y dependiendo de los requerimientos de software,
hardware, seguridad y tecnología que se tengan se debe tomar esta decisión.
Existen sistemas operativos pensados pura y exclusivamente para alojar
aplicaciones en red como GNU/Linux, Microsoft Windows Server, Mac OS X Server,
Solaris o FreeBSD; aunque actualmente cualquier sistema operativo del mercado
permite incorporar software propio o de terceros y así convertirse en proveedores de
servicios web.
Entre las aplicaciones más conocidos de servidores web se pueden
2.5.1 Apache Tomcat
Desarrollado en Java, de código abierto, funciona en cualquier sistema
operativo que soporte la máquina virtual de Java. Tiene soporte para sitios web
realizados en JSP [28].
2.5.2 Microsoft ISS
Internet Information Services (IIS) es un servidor web y un conjunto de
servicios de Microsoft, que corre sobre sistemas operativos Windows y soporta los
principales protocolos que funcionan sobre Internet [29]. Las aplicaciones que
corren en estos servidores suelen ser desarrolladas en el lenguaje ASP o ASP.Net
de Microsoft, aunque en versiones más recientes también da soportes a desarrollos
realizados en el lenguaje PHP.
2.5.3 Nginx
Siendo el segundo servidor web más utilizado, Nginx tiene además la
capacidad de proveer servicios de proxy y balanceador de carga utilizando pocos
recursos y permitiendo escalabilidad [30].
Fue creado para mejorar notablemente el desempeño del Apache HTTP
Server, permitiendo atender hasta cuatro veces más peticiones por segundo y
entregando contenido estático más rápido, aunque sacrificando flexibilidad y
soportando una única configuración a nivel global.
2.5.4 Apache HTTP Server
Este servidor de código abierto y multiplataforma es el más popular de los
existentes y corre mayormente en entornos Linux, aunque puede ser instalado
tantos otros protocolos y a través de módulos permite incorporar funcionalidades
que extienden las prestaciones brindadas. Soporta los lenguajes Perl, PHP y Python
a través de estos módulos.
A través de la técnica de Virtual Hosting Apache permite que en una única
instancia corriendo en un servidor, pueda servir múltiples sitios web y modificar las
configuraciones globales en cada uno de los sitios web a través de archivos
.htaccess, permitiendo una configuración más flexible para cada caso puntual. Es
este último motivo uno de los puntos claves para consolidarse como el software de
servidor web más popular entre proveedores de hosting.
Dependiendo de las características del desarrollo y habiendo hecho un
repaso por los distintos sistemas de base de datos, lenguajes de programación y
tipos de servidores web, podemos mencionar las principales características de los
servicios de hosting dedicados o compartidos.
Los servidores dedicados son, como su nombre lo decide, servidores físicos
o virtuales en los que los recursos de los que se disponen es pura y exclusivamente
para uso de quien lo contrate. De esta forma el desempeño, configuración y
mantenimiento del mismo queda a cargo del administrador de sistemas.
La ventaja de contar con un servidor dedicado es la libertad de elegir tanto el
sistema operativo, el servidor web y el lenguaje de programación a utilizar en el
desarrollo, ya que queda bajo responsabilidad del administrador la instalación y
configuración de todos aquellos parámetros y aspectos que excedan la
configuración básica, necesitándose así mayor tiempo de startup.
La administración y mantenimiento de un servidor dedicado requiere por
parte del administrador un trabajo más fino sobre la toma de medidas de seguridad,
la utilización de recursos o la restauración del sistema ante una falla, caída general
Por el contrario, contratando un servicio de alojamiento compartido, evitaremos tener que preocuparnos por algunas cuantas cuestiones que asumimos
atajadas y controladas por nuestro proveedor aunque es probable que nos veamos
limitados a la hora de realizar elecciones tecnológicas, como así también
restringidos a la hora de utilizar los recursos del servidor, ya que se nos asignará
una porción de la capacidad total del hardware disponible; generalmente se limita el
espacio en disco, la cantidad de núcleos disponibles para la ejecución de nuestros
scripts como así también el tiempo de ejecución de los mismos en los procesadores,
ancho de banda y cantidad de conexiones simultáneas.
Además, este tipo de servicio suele poseer algunas restricciones en cuanto a
las tecnologías con las que se puede trabajar dependiendo del plan contratado. Por
lo general, este tipo de servicio de alojamiento está montado sobre sistemas Unix,
utilizando como servidor web Apache HTTP Server, bases de datos MySQL y
lenguaje de programación PHP.
También pueden existir problemas de performance en nuestro sistema, dado
a que un desarrollo de terceros que esté alojado el servidor puede estar ejecutando
un script que esté ejecutándose con mucha frecuencia y con costo de
procesamiento superior a lo habitual, consumiendo así todos los recursos del
servidor, afectando a los demás desarrollos allí alojados.
Otro aspecto no menor es la seguridad, ya que en caso de una mala
configuración del servidor, falta de aislamiento en los directorios y una mala
asignación de permisos de escritura o ejecución puede conllevar a que scripts
maliciosos recorran los archivos y carpetas del servidor, insertando código fuente
malicioso en archivos de otros desarrollos.
Por último, una característica no menor, es la capacidad de debug que
tenemos en estos servidores compartidos. Ante un error inesperado, existen menos
mecanismos de debug disponibles ya que no se suele tener acceso a los logs de
2.6 Servicios de terceros
Si bien un sitio o aplicación web provee una serie de recursos propios al
usuario final, existen servicios que son provistos por terceros llamados
complementos (plugin en inglés) que ayudan a enriquecer el contenido presentado y
mejorar tanto la experiencia, como la interactividad y el engagement del usuario.
Esto también ayuda a reducir esfuerzos de diseño y desarrollo, ya que por lo
general es un componente enlatado que puede ser fácilmente adaptado y reutilizado
con cada desarrollo que se desee. En la actualidad existen servicios de redes
sociales, de entretenimiento, de información, de estadísticas, entre otros.
Los servicios sociales se encuentran centrados mayormente en la distribución
y redistribución de contenidos en la web gracias a plugins que permiten compartir,
recomendar, comentar o simplemente demostrar interés en un recurso publicado en
la web. Entre ellos se pueden mencionar los plugins sociales de Facebook, Twitter,
Reddit, Pinterest o LinkedIn.
Además existen servicios dedicados exclusivamente al entretenimiento y
permiten a los usuarios embeber su contenido en los sitios web. Esto permite que
un usuario sin conocimientos técnicos pueda, dentro de su sistema de gestión de
contenidos, embeber una porción de código HTML con un video, audio, o una
publicación realizada en una red social para que se visualice en el sitio web. Los
principales proveedores de estos complementos son YouTube, Vimeo, Facebook y
Twitter.
También hay servicios de terceros que permiten presentar datos
complementarios no necesariamente ligados al entretenimiento: La ubicación en un
mapa de un punto de interés, el recorrido a realizar entre dos puntos de una ciudad
o entre dos ciudades, información actualizada del clima o la cotización de las
principales monedas y mercados del mundo, así como también cierta información al
particular, el recorrido de un punto a otro en una misma ciudad o entre ciudades,
información complementaria del clima, los índices bursátiles internacionales o la
cotización de las monedas extranjeras.
Los servicios con fines de estudio estadístico son cada vez más útiles y más
ricos. Proveen información a los administradores de sitios web acerca del
comportamiento del conjunto total de sus usuarios y permite segmentar por distintos
criterios este público con el fin de realizar mejores y más efectivas campañas de
marketing. Herramientas de este estilo son provistas por distintas compañías,
siendo Google Analytics y Facebook Pixel dos de las más usadas para hacer
seguimiento a los usuarios y medir conversiones de objetivos.
2.7 CMS Dinámicos
Si bien existen en el mercado muchos CMS estáticos (CMS que no permiten
ser adaptados o modificados sin modificar su código fuente), actualmente, se espera
que un CMS pueda ser adaptado y reutilizado fácilmente para administrar diferentes
conjuntos de datos de diferentes dominios [6].
Para esto, los CMS modernos implementan mecanismos mediante los cuales
un desarrollador puede modificar y modelar las interfaces de usuario y las
interacciones con las bases de datos. Entre estos mecanismos se encuentran
mayormente: la especificación de APIs para el desarrollo de plugins; proveer
mecanismos para cambiar la implementación del CMS como arquitecturas
orientadas a objetos, o mecanismos de retro-llamados (callbacks); fomentar el
desarrollo de templates que extienden o reemplazan parte del CMS; y definir un
formato para especificar los datos que deben ser administrados (llamados
metadatos) que el CMS utiliza para adaptar su comportamiento e interfaces sin
necesidad de realizar adaptaciones.
Cabe aclarar que si bien es cierto que la mayoría de los CMS no utiliza una
enfoques híbridos), a cada CMS se lo suele asociar con un mecanismo en particular (el mecanismo predominante en su diseño y arquitectura).
A continuación se detallan brevemente los diferentes mecanismos identificados para adaptar un CMS.
2.7.1 Metadatos
Los metadatos, son datos que describen otros datos. En general, un grupo de
metadatos se refiere a un grupo de datos que describen el contenido informativo de
un objeto al que se denomina recurso [6].
Los metadatos son utilizados en varios campos de la informática, como la
recuperación de información o la web semántica, aunque no son exclusivos del
área, ya que también se utilizan para todo tipo de recursos, como videos, música, un
libro en una biblioteca, una obra de arte en un museo o para un hueso en el armario de un paleontólogo.
Si bien es cierto que las nuevas necesidades de búsqueda de información
han suscitado un interés por las normas y prácticas de metadatos hasta entonces
desconocido, el concepto de metadatos es anterior a Internet y a la web.
Actualmente, algunos CMS los utilizan para definir con precisión los datos
que debe administrar, así como también la forma en la que estos se agrupan,
relacionan y presentan a los usuarios finales y administradores.
A nivel técnico, existen infinitas formas de representar metadatos (desde
serializaciones personalizadas en formato binario, hasta representaciones con formatos estándar XML o JSON).
En el caso de las representaciones en formatos estándar como XML o JSON,
estructura que deberían tener estos XML y JSON). Estos meta-metadatos suelen ser utilizados para generar documentación automática acerca del formato esperado
de los metadatos, pero también pueden ser utilizados para validar los metadatos ya
escritos o para asistir en su escritura mediante herramientas de auto-completado de
escritura o mediante la generación de formularios específicos para cada metadato.
Para poder entender un poco mejor el concepto de metadato, se plantea la
siguiente situación: Pensemos en que existe un espacio de almacenamiento finito
que tiene un dato escrito en binario y no tenemos, en principio, forma de saber qué
significa ese dato. Ahora pensemos que existe una manera de saber qué significa
esa secuencia de ceros y unos: los metadatos. El metadato nos indicará las
características que tiene el dato almacenado en ese espacio de memoria: Es un
número, es de punto flotante, la representación sigue el estándar IEEE. Además de
la información precisa acerca de lo que se está almacenando, los metadatos
podrían incluir información adicional para la validación de la información guardada.
Podría, por ejemplo, incluir restricciones de dominio para el número que se quiera
almacenar en dicha posición de memoria.
Teniendo un poco más en claro lo que significa un metadato, pensemos en
qué podría ser un metadato que describa al metadato anterior.
Si tenemos un metadato que describe el tipo de dato, podríamos pensar en
un metadato que describa los distintos tipos de datos. Para esto, podríamos pensar
en una lista de tipos de datos disponibles: enteros, punto flotante, string, binario,
entre otros. Para cada uno de estos tipos de datos, el conjunto de parámetros
adicionales que acepta. En este caso estaríamos en presencia de un
2.7.2 Plugins
Existe otro mecanismo que permite la modificación de un CMS que son los
plugins. Los plugins son archivos que permiten a un software existente agregar
nueva funcionalidad específica [6].
Para esto el CMS debe prever una arquitectura que soporte la incorporación
de actualizaciones a través de plugins y además proveer un mecanismo de fácil
añadido de los mismos, siendo generalmente un formulario al cuál se le adjuntará
un archivo comprimido. Dentro de este archivos se encontrarán los distintos
archivos con código fuente, archivos de estilo y recursos adicionales que utilice, que
deberán cumplir con el estándar impuesto por el CMS para una correcta integración
y un óptimo funcionamiento.
Si bien los plugins pueden agregar comportamiento al núcleo del CMS,
cambiar la apariencia y extender su funcionalidad básica, suelen ser populares los
plugins que proveen los mecanismos de integración con otros sistemas y sitios. Por
ejemplo: Google Analytics, Google Maps, Redes Sociales como Facebook y Twitter,
o Gateways de Pago como PayPal o MercadoPago.
De esta forma se brinda al usuario del CMS funcionalidades adicionales que
podrá incorporar a medida que sean necesarias, sin la necesidad de realizar
modificaciones al código fuente en pocos y sencillos pasos.
2.7.3 Arquitecturas Orientadas a Objetos
Plantear una arquitectura orientada a objetos a la hora de desarrollar un CMS
permite a los desarrolladores que lo utilicen adaptar, reutilizar e incluso mantener las
Con este enfoque de desarrollo y previendo que sea este el mecanismo de
extensión, es necesario contar con conocimientos de programación en el lenguaje
en que esté desarrollado el CMS y, además, conocer la arquitectura completa del
mismo para realizar correctamente las modificaciones y no incurrir en fallas de
seguridad o bugs en el sistema.
Un desarrollador que desee realizar una modificación al módulo de autenticación de usuarios del CMS, deberá entonces crear una nueva clase que
extienda el controlador de sesiones y re-implementar los métodos que tengan
impacto en la mejora deseada, logrando así mantener la consistencia y
mantenibilidad del CMS.
2.7.4 Mecanismo de Callbacks
Proveer a los desarrolladores el mecanismo de callbacks (retrollamada en
castellano) permite extender la funcionalidad del CMS sin necesidad de modificar el
código fuente del mismo [6]. De esta forma no es necesario conocer la arquitectura
y lógica del CMS por completo para poder hacer adaptaciones o agregar controles
adicionales.
El CMS proveerá una lista de los callbacks existentes a los que el
desarrollador se podrá suscribir o permitirá a los desarrolladores, bajo algún
esquema definido por el CMS, indicar bajo qué condiciones o en qué circunstancias
cierta retrollamada debe ser ejecutada, comportamiento que replica a un trigger de
una base de datos.
Existirá un archivo o un directorio en el que el desarrollador deberá incorporar
las retrollamadas con el fin de realizar las modificaciones o extensiones adicionales.
Con este mecanismo el desarrollador podrá agregar controles adicionales,
por ejemplo, para que a la hora de la creación o edición de un recurso administrado
verificar que los datos interesados cumplen con algún criterio definido en el mismo, o en caso de ser necesario, realizar alguna funcionalidad adicional como podría ser
la interacción con un web service a través de su API o el envío de un mail a un
conjunto de destinatarios para informar la modificación realizada.
2.7.5 Plantillas del CMS
Los CMS son desarrollos que adaptan las interfaces de usuario en base al
tipo de información que haya disponible para presentar o prepara un formulario listo
para ser precargado en base a los metadatos que hayan sido provistos a la hora de
su configuración [6].
Sin embargo existen algunos CMS más modernos que ofrecen a los
desarrolladores del mismo extender o reemplazar parte del CMS a través de la
técnica de templating. De esta forma el programador puede ir más allá de las
adaptaciones naturales que realiza el CMS y proceder a cambiar aspectos estéticos
de ciertas partes del sistema de gestión de contenidos o incluso soportar nuevas
Capítulo 3
Análisis de requerimientos
3.1 Requerimientos Funcionales
InnyCMS deberá permitir al administrador del mismo personalizar las
opciones que aparecen en el menú principal dependiendo de las necesidades y
características con las que cuente el sitio a administrar.
InnyCMS deberá permitir a los usuarios finales disponer del juego completo
de caracteres unicode con el fin de incorporar emojis y texto multi idioma en el
contenido de su sitio.
InnyCMS deberá permitir que en una única instalación se puedan gestionar
los contenidos de más de un sitio web.
InnyCMS deberá permitir que un sitio sea administrado y gestionado por más
de un usuario.
InnyCMS deberá permitir que un usuario pueda ser administrador de más de
un sitio web al mismo tiempo.
InnyCMS deberá soportar un mecanismo de metadatos que permita una fácil
configuración de las interfaces de usuario y las estructuras de datos que sean
gestionadas.
InnyCMS deberá presentar una nueva interfaz gráfica para permitir a los
usuarios finales realizar la gestión de contenidos tanto desde dispositivos móviles
InnyCMS deberá presentar una nueva interfaz gráfica a los administradores
del mismo para permitir la gestión de los sitios y los usuarios del CMS tanto desde
dispositivos móviles como así también desde computadoras de escritorio.
InnyCMS deberá soportar un mecanismo eficiente de gestión de archivos con
el fin de facilitar un acceso rápido al listado de los mismos y poder visualizar la
relación que existe entre cada archivo y los recursos propios del sistema de gestión
de contenidos. Adicionalmente se espera que el mecanismo de gestión de archivos
supervise el espacio ocupado por los mismos en la base de datos.
Los usuarios que redacten contenido en InnyCMS deberán contar con un corrector ortográfico integrado a los campos de texto enriquecido.
InnyCMS deberá ser multi idioma y debe permitir al usuario cambiar de forma
fácil y rápida entre un idioma disponible y otro.
InnyCMS deberá contar con un mecanismo que permita a cualquier
programador incorporar un nuevo tipo de dato fácilmente.
InnyCMS deberá contar con un apartado en el que los usuarios puedan crear
un árbol de categorías y subcategorías que servirá para categorizar los documentos
cargados en la base de datos.
Cada usuario de InnyCMS deberá ser capaz de administrar los datos que
sean parte de su perfil como así también cambiar su contraseña.
InnyCMS deberá permitir a los programadores, de forma fácil, configurar las
interfaces gráficas para que puedan administrar tablas que no sean parte del
conjunto base del CMS.
errores inesperados. Deberá visualizar siempre pantallas amigables y con la información suficiente como para comunicarle al administrador del sitio lo ocurrido.
InnyCMS deberá permitir a los administradores configurar el tamaño máximo
que puede ocupar la base de datos de una instancia del cms.
3.2 Requerimientos No Funcionales
3.2.1 Compatibilidad
InnyCMS debe ser programado en PHP, lenguaje de programación utilizado
por la empresa para sus desarrollos web y lenguaje de programación utilizado por la
versión de InnyCMS existente.
3.2.2 Portabilidad
InnyCMS debe ser compatible indistintamente con los motores de base de
datos MySQL y MariaDB.
InnyCMS deberá funcionar en servidores con sistemas operativos linux,
windows o macOS.
3.2.3 Usabilidad
InnyCMS deberá contar con una interfaz de usuario amigable y fácil de usar,
asegurando usabilidad y buena experiencia de usuario tanto en dispositivos móviles
como en computadoras.
El código fuente de InnyCMS debe poder ejecutarse sin warnings ni notices
3.2.4 Seguridad
InnyCMS deberá contar con los controles de seguridad necesarios para que
un usuario que no sea parte del sistema o sin los suficientes permisos no pueda
realizar la gestión de contenidos.
3.2.5 Mantenibilidad
El código fuente de InnyCMS debe estar disponible para la empresa en un
repositorio Git.
InnyCMS debe proveer un mecanismo de actualización automático y rápido
en los proyectos que lo utilicen.
3.2.6 Auditabilidad
InnyCMS deberá dejar constancia de qué usuario y en qué momento dió de
Capítulo 4
Arquitectura y diseño de la solución
4.1 Selección de tecnologías utilizadas
Para el desarrollo de la solución de la herramienta InnyCMS, sea por
limitaciones o por prestaciones que ofrecen las tecnologías, se decidió realizar la
implementación teniendo en cuenta las siguientes herramientas y tecnologías con
las consideraciones que hicieran falta para cada una.
4.1.1 Base de Datos: MySQL / MariaDB
Desde la empresa se requiere que la versión propuesta del CMS funcione
indistintamente entre MySQL y MariaDB. Para lograr esto, se eligió trabajar de
forma local con el sistema de gestión de bases de datos MySQL, ya que es el motor
por defecto en los entornos de desarrollo, y se decidió montar un entorno de
pruebas con MariaDB para asegurar la compatibilidad del desarrollo con ambos
motores. En los nuevos ambientes de producción de la empresa es MariaDB el
motor presente, pero MySQL sigue siendo el motor más utilizado por lo que se debe
garantizar el funcionamiento de forma indistinta.
4.1.2 Lenguaje de Programación Back-End: PHP + Smarty
Para la solución final de InnyCMS se pidió que el mismo sea desarrollado en
el lenguaje PHP. El desarrollo actual corre en la versión 5.4 del lenguaje, la cual
difiere de la versión 7, la más reciente del mercado, que deberá ser tenida en cuenta
en este desarrollo. Es por este motivo que se deberán refactorizar todas las clases,
métodos y funciones existentes para que cumplan con los estándares descritos en
Si bien el lenguaje PHP en sí mismo permite ser embebido dentro de
archivos HTML para la generación de plantillas en sitios web dinámicos, esta
estrategia suele resultar en código ilegible y muy propenso a errores. Por otro lado,
afecta al diseño y a la arquitectura de la solución. Todo desarrollo realizado en PHP,
para asegurar una correcta separación entre la lógica del negocio y la presentación,
requiere del uso de un motor de plantillas. Debido a que la versión actual de
InnyCMS utiliza Smarty como motor de plantillas y los desarrolladores ya están
familiarizados con el mismo, desde la empresa se decidió que la versión propuesta
de InnyCMS debería contar con el mismo motor, con la singularidad de que debería
actualizarse a la versión más reciente. Esta actualización deberá realizarse no
solamente por las ventajas que trae consigo Smarty 3: simplificación de la sintaxis;
utilización de funciones PHP en los templates; mejoras de performance a la hora de
compilar las plantillas, sino que también Smarty 2 no es compatible con PHP 7.
4.1.3 Framework Frond-End: Metronic (Bootstrap + jQuery)
Para acelerar las tareas de desarrollo y no insumir tiempo y recursos en el
diseño gráfico de la versión propuesta de InnyCMS, se optó por utilizar el framework
visual Metronic. Este framework proveerá a la solución un conjunto plantillas base,
de las cuales se seleccionará una de ellas para construir la nueva interfaz gráfica
del Sistema de Gestión de Contenidos y otra para el Panel de Administración de
InnyCMS. Sobre estas plantillas base se incorporarán los recursos y componentes
tanto visuales como funcionales adicionales que provee el framework que ya fueron
estudiados, diseñados y testeados. Esto permitirá construir un desarrollo responsivo
teniendo en cuenta las últimas tendencias en materia de UI & UX del mercado.
Metronic es un framework que, para la creación de sitios web responsivos,
utiliza el sistema de grillas de Bootstrap, un framework creado por Twitter. Este
sistema de grillas es ampliamente utilizado en el mercado y se adoptó para todos
los proyectos realizados en la empresa.
En la interfaz de usuario, además del código HTML que conforma el
existe también código JavaScript de ejecución local en el navegador del usuario.
Existen bibliotecas que simplifican la interacción con el DOM, el manejo de eventos
o los llamados asincrónicos. Entre ellas se encuentra jQuery, que forma parte del
framework elegido y que los desarrolladores de la empresa usan a diario.
4.1.4 Sistema de Control de Versiones: Git
El desarrollo actual cuenta con un sistema de control de versiones (CVS)
pero el mismo ya no es utilizado en los nuevos desarrollos de la empresa. Es por
este motivo que se decidió migrar InnyCMS a Git, sistema que actualmente es
utilizado por la empresa para el control de versiones de todos los proyectos y que,
además, nos será de gran utilidad ya que nos permitirá integrar el sistema de
gestión de contenidos como submódulo de los proyectos que lo utilicen, permitiendo
un mecanismo de actualización ágil y rápido, cumpliendo así unos de los requisitos
no funcionales pedidos.
4.1.5 Servidor Web: Apache HTTP Server
En materia de software de servidor se decidió continuar utilizando Apache
HTTP Server 2, debido a que este software ya está montado en toda la
infraestructura de servidores de la empresa, así como también viene incluido como
software de base en los equipos que utilizan los desarrolladores cotidianamente.
4.2 Descripción de la arquitectura de la solución
A grandes rasgos y por el tipo de desarrollo a realizar se puede ver que esta
herramienta tendrá una clásica arquitectura cliente-servidor para aplicaciones web,
en la cual el cliente desde su dispositivo, sistema operativo y navegador de internet
preferido inicia una solicitud al servidor, del cual espera y recibe una respuesta
(Figura 4.1). Es el navegador quien procesa e interpreta la respuesta del servidor,
navegador web debe soportar el protocolo HTTP/HTTPs para la comunicación a
través de internet con el servidor y los estándares de HTML5, CSS3 y JavaScript
para la renderización de las interfaces gráficas.
Figura 4.1: Arquitectura cliente-servidor.
4.2.1 Cliente
Desde el punto de vista del cliente se puede detallar que las interfaces
gráficas están desarrolladas íntegramente teniendo en cuenta el estándar HTML5.
El esqueleto HTML que recibe y procesa el cliente está construido utilizando
el Framework Metronic, herramienta que provee un conjunto plantillas que usan
Bootstrap y CSS3 para la creación de interfaces responsivas. Además brinda un
conjunto de componentes genéricos, con la ayuda de la biblioteca jQuery, que
agregan dinamismo al desarrollo.
La construcción de la aplicación que corre sobre el cliente, definiendo el
Figura 4.2: Aplicación vista desde el cliente.
Como puede observarse en la Figura 4.2, el cliente utilizando su navegador
web favorito realizará una petición al servidor a través de su capa de red. Esta
petición se realizará a través del protocolo HTTP. El cliente quedará a la espera de
una respuesta. Una vez recibida, para que el navegador pueda representar el
contenido recibido, debe construir los árboles del DOM y el CSSOM. En
consecuencia, debemos asegurarnos de proporcionar el lenguaje de marcado HTML
y CSS al navegador lo más rápido posible. El lenguaje de marcado HTML se
transforma en un Document Object Model (DOM) y el lenguaje de marcado CSS se
transforma en un CSS Object Model (CSSOM). Ambas estructuras de datos son
independientes.
Los árboles CSSOM y DOM se combinan en un árbol de representación. A
continuación, este árbol se utiliza para computarizar el diseño de cada elemento
visible y sirve como entrada del proceso de pintura que permite representar los
píxeles en la pantalla. Para lograr un óptimo rendimiento de representación, es
imprescindible optimizar cada uno de estos pasos.
JavaScript es un lenguaje dinámico que se ejecuta en un navegador y nos
permite modificar prácticamente todos los aspectos del comportamiento de la
página: podemos agregar o eliminar elementos del árbol del DOM. También
podemos modificar las propiedades del CSSOM de cada elemento, entre otras
exacto en que es encontrado durante la construcción del DOM, en el diagrama
anterior el código JavaScript se ubicó en la parte superior del diagrama anterior.
Esto se debe a que este código JavaScript será lo último en ejecutarse, ya que es
una buena práctica incluir el código JavaScript en las últimas líneas del HTML
entregado al navegador.
4.2.2 Servidor
Desde el punto de vista del servidor se puede mencionar que el mismo estará
montado sobre el sistema operativo Linux, corriendo el servidor web Apache HTTP
Server 2 y el lenguaje de programación elegido es PHP, tal como se muestra en la
Figura 4.3.
Figura 4.3: Aplicación vista desde el servidor.
En el desarrollo de InnyCMS podemos remarcar la existencia de tres
componentes principales: El Panel de Administración, el Sistema de Gestión de
Contenidos y una API de consulta e interacción para facilitar el desarrollo de sitios
web a los desarrolladores.
El Panel de Administración es un conjunto de interfaces gráficas que
permiten a los usuarios administradores realizar la gestión de sitios y usuarios que
serán parte del CMS y utiliza el patrón MVC (modelo-vista-controlador).
El Sistema de Gestión de Contenidos está compuesto también por una serie