Arquitectura de aplicaciones web: evolución, componentes, tecnologías y planificación
Las aplicaciones web forman parte de muchas actividades cotidianas: consultar una calificación, comprar un producto, realizar una transferencia, reservar una cita o registrar la asistencia de un grupo. Aunque estas acciones se presentan mediante pantallas, formularios y botones, detrás de cada una existe un conjunto de componentes que colaboran para recibir información, aplicar reglas, consultar datos y entregar resultados.
Comprender la arquitectura de una aplicación web implica estudiar cómo se organiza el sistema, qué responsabilidad tiene cada componente y cómo se comunican sus partes. Esta comprensión permite desarrollar aplicaciones que funcionen correctamente, puedan mantenerse y protejan la información que administran.
A lo largo de este artículo se utilizará un ejemplo: un sistema web para el préstamo de equipos de cómputo de una institución educativa. En él, los usuarios podrán consultar equipos disponibles, solicitar préstamos y registrar devoluciones. Este caso permitirá relacionar los conceptos con decisiones concretas de desarrollo.
Video explicativo: Arquitectura de aplicaciones web
1.1 Evolución de las aplicaciones web
Figura 1. Formas de uso de la Web que conviven: documentos, contenido dinámico, actualización parcial y experiencias integradas. Ilustración didáctica original.
1.1.1 Internet y la Web: conceptos relacionados
Internet es una infraestructura de redes interconectadas que permite intercambiar información entre dispositivos mediante protocolos de comunicación.
La World Wide Web, también llamada Web o WWW, es un sistema de recursos enlazados que utiliza esa infraestructura. Sus recursos se identifican mediante direcciones y pueden consultarse con programas como los navegadores.
Por ejemplo:
Al abrir una página en un navegador se utiliza la Web.
El correo electrónico utiliza Internet, aunque su funcionamiento puede involucrar protocolos distintos de los de la Web.
Una aplicación de correo abierta en el navegador combina una interfaz web con los servicios que permiten administrar mensajes.
Una aplicación web también puede funcionar dentro de una red local. Un sistema escolar instalado en un servidor de la institución podría consultarse desde las computadoras del laboratorio sin estar publicado para todo Internet.
1.1.2 Origen de la Web
Tim Berners-Lee desarrolló la Web en el CERN a partir de 1989 para facilitar el intercambio de información. El proyecto articuló tres elementos fundamentales:
HTML: una forma de estructurar documentos con enlaces.
HTTP: un protocolo para solicitar y transferir recursos.
URL: una forma de identificar y localizar recursos.
El 30 de abril de 1993, el CERN puso el software de la Web en el dominio público, una decisión que favoreció su expansión.
La idea central del hipertexto consiste en relacionar documentos mediante enlaces. En lugar de consultar información de manera estrictamente secuencial, una persona puede desplazarse entre recursos relacionados.
Por ejemplo, una página sobre programación puede contener un enlace a otra que explique variables y, desde allí, conducir a ejemplos de funciones.
1.1.3 Primeras páginas: publicación de información
Las primeras experiencias de la Web se concentraron en publicar documentos que las personas podían consultar.
Una página institucional podía mostrar:
Nombre de la institución.
Oferta educativa.
Dirección.
Horarios.
Información de contacto.
Un ejemplo sencillo sería:
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<title>Laboratorio de cómputo</title>
</head>
<body>
<h1>Laboratorio de cómputo</h1>
<p>Horario de atención: lunes a viernes, de 8:00 a 15:00.</p>
<a href="reglamento.html">Consultar el reglamento</a>
</body>
</html>
El servidor puede almacenar este documento y enviarlo cuando alguien lo solicita.
Se habla de contenido estático cuando el recurso se entrega tal como está almacenado, sin generarlo específicamente para cada solicitud.
“Estático” no significa que una página deba carecer de animaciones o interactividad. Un sitio servido como archivos estáticos puede incluir JavaScript, reproducir video o realizar cálculos en el navegador.
La característica se refiere a cómo se produce y entrega el contenido, no a si hay movimiento en pantalla.
1.1.4 Aplicaciones dinámicas: información que depende de la solicitud
Con el crecimiento de la Web surgió la necesidad de procesar formularios, consultar bases de datos y mostrar contenido diferente según el usuario.
Una aplicación dinámica puede generar una respuesta a partir de:
La identidad de quien solicita información.
Los parámetros enviados.
Las reglas del sistema.
Los datos almacenados.
El momento de la consulta.
En el sistema de préstamos, dos usuarios podrían abrir la misma dirección y obtener resultados diferentes:
Un estudiante ve sus solicitudes.
El encargado ve las solicitudes pendientes.
Un administrador ve herramientas para gestionar usuarios.
El servidor recibe la solicitud, ejecuta código y produce una respuesta. Esta puede ser un documento HTML o datos que después utilizará el navegador. MDN explica esta distinción entre recursos estáticos y respuestas generadas mediante programación del lado del servidor.
Ejemplo:
Si el laboratorio tiene diez equipos y tres están prestados, la aplicación debe consultar la situación actual y mostrar siete disponibles. Una lista escrita manualmente en una página podría quedar desactualizada después del siguiente préstamo.
1.1.5 Mayor participación del usuario
La Web también evolucionó hacia sistemas en los que las personas crean y modifican información:
Publican comentarios.
Suben fotografías.
Editan documentos.
Comparten archivos.
Califican productos.
Participan en plataformas educativas.
La expresión Web 2.0 se utiliza para describir esta orientación participativa. No representa una versión oficial de HTTP ni una actualización que deba instalarse.
El cambio relevante fue pasar de un uso principalmente informativo a uno en el que los usuarios también producen contenido y ejecutan procesos.
En el sistema de préstamos, un usuario deja de limitarse a leer un reglamento: puede solicitar un equipo, consultar la respuesta y revisar su historial.
1.1.6 Actualización parcial de las páginas
En una aplicación tradicional, muchas interacciones provocan la carga de un documento completo.
Por ejemplo:
El usuario llena un formulario.
Lo envía.
El servidor procesa la información.
El navegador carga una nueva página con el resultado.
Más adelante se extendió el uso de solicitudes desde JavaScript para intercambiar información sin reemplazar toda la página.
A esta técnica se le conoce habitualmente como AJAX, por Asynchronous JavaScript and XML. Aunque el nombre menciona XML, actualmente es frecuente intercambiar datos en JSON.
En el catálogo de equipos, al seleccionar “Mostrar solamente disponibles”, JavaScript puede solicitar los resultados y actualizar únicamente la lista.
Esto puede mejorar la experiencia, pero exige resolver otros problemas:
Mostrar que la información está cargando.
Informar fallas de conexión.
Evitar solicitudes duplicadas.
Mantener una navegación comprensible.
Comunicar los cambios a personas que utilizan tecnologías de asistencia.
1.1.7 Aplicaciones de múltiples páginas y de una sola página
Una MPA, o aplicación de múltiples páginas, utiliza diferentes documentos para sus secciones. Al navegar, el servidor normalmente entrega otra página.
Una SPA, o aplicación de una sola página, carga una interfaz inicial y utiliza JavaScript para gestionar buena parte de la navegación y de las actualizaciones posteriores.
Aspecto | MPA | SPA |
Navegación habitual | Solicitud de otro documento | Actualización de la interfaz mediante JavaScript |
Generación de la interfaz | Frecuentemente en el servidor | Frecuentemente en el navegador |
Complejidad inicial | Puede ser menor en proyectos sencillos | Requiere gestionar estado, rutas y carga de datos |
Ejemplo | Portal con formularios y páginas independientes | Panel de trabajo con muchas interacciones continuas |
Estas formas pueden combinarse. Un sitio puede utilizar páginas generadas en el servidor e incorporar componentes muy interactivos.
Una SPA tampoco implica que toda la aplicación funcione sin servidor: puede depender continuamente de servicios remotos.
1.1.8 Aplicaciones móviles y diseño adaptable
La expansión de teléfonos y tabletas cambió las condiciones de uso de la Web.
Una aplicación debe considerar:
Pantallas de distintos tamaños.
Interacción táctil.
Teclados virtuales.
Conexiones variables.
Dispositivos con capacidades diferentes.
El diseño adaptable, o responsive design, permite ajustar la presentación al espacio disponible.
En una computadora, el catálogo puede mostrar varias tarjetas por fila; en un teléfono, una sola columna.
La adaptación también debe considerar el contenido. Una tabla con veinte columnas puede necesitar una presentación distinta para que resulte útil en una pantalla pequeña.
1.1.9 Aplicaciones web progresivas
Una PWA, o aplicación web progresiva, utiliza tecnologías de la Web para ofrecer capacidades que pueden aproximarse a las de una aplicación instalada.
Según su implementación y el soporte del navegador, puede proporcionar:
Instalación.
Acceso a recursos almacenados localmente.
Algunas funciones sin conexión.
Notificaciones.
Integración con ciertas capacidades del dispositivo.
Un service worker puede interceptar solicitudes y administrar recursos en caché, lo que permite diseñar experiencias sin conexión. Estas capacidades requieren implementación deliberada; no aparecen automáticamente por convertir un sitio en instalable.
En el sistema de préstamos, una PWA podría permitir consultar el reglamento sin conexión. Sin embargo, confirmar un préstamo requiere conocer la disponibilidad actual.
Si dos dispositivos están desconectados, ambos podrían creer que el mismo equipo sigue disponible. Por ello, consultar información almacenada localmente y confirmar una operación compartida son problemas diferentes.
1.1.10 Servicios distribuidos y aplicaciones integradas
Las aplicaciones también pueden integrar servicios especializados:
Correo electrónico.
Almacenamiento de archivos.
Identidad.
Pagos.
Mapas.
Videoconferencias.
Una aplicación de préstamos podría registrar la operación en su base de datos y utilizar un proveedor externo para enviar la notificación.
La evolución de la Web no significa que cada tecnología nueva sustituya a todas las anteriores. Las páginas estáticas, los formularios tradicionales, las SPA y las PWA siguen siendo útiles en contextos diferentes.
La elección depende del problema y de los recursos disponibles.
1.2 Arquitectura de las aplicaciones web
Figura 2. Recorrido simplificado de una solicitud entre navegador, backend y base de datos en el sistema de préstamos. Ilustración didáctica original.
1.2.1 Qué significa arquitectura
La arquitectura de software define la organización fundamental de un sistema:
Sus componentes principales.
Las responsabilidades de cada componente.
Las relaciones entre ellos.
Los mecanismos de comunicación.
Las decisiones que condicionan su evolución.
Para comprenderla, puede utilizarse la analogía de un restaurante:
Restaurante | Aplicación web |
Cliente que solicita un platillo | Usuario que realiza una operación |
Menú y espacio de atención | Interfaz |
Procedimiento para recibir pedidos | Protocolo y contrato de comunicación |
Cocina que procesa el pedido | Lógica de la aplicación |
Inventario de ingredientes | Datos almacenados |
Reglas de preparación y venta | Reglas del negocio |
La analogía ayuda a identificar responsabilidades: que una opción aparezca en el menú no garantiza que existan ingredientes para prepararla. Del mismo modo, que un equipo aparezca disponible en una pantalla no garantiza que siga disponible al confirmar el préstamo.
1.2.2 Modelo cliente-servidor
En el modelo cliente-servidor:
El cliente solicita recursos o servicios.
El servidor recibe solicitudes y entrega respuestas.
El navegador funciona como cliente web, pero también pueden existir otros clientes: una aplicación móvil, otro servidor o una herramienta de pruebas.
La palabra servidor puede referirse al equipo que ejecuta un servicio o al programa que atiende solicitudes. Un mismo equipo físico puede ejecutar varios servicios.
En nuestro ejemplo:
El navegador solicita el catálogo.
La aplicación procesa la consulta.
La base de datos proporciona información.
El servidor devuelve el resultado.
1.2.3 Qué ocurre al abrir una dirección
Supongamos una dirección ficticia:
https://laboratorio.example/equipos?estado=disponible
Sus partes principales son:
Parte | Significado |
https | Esquema de acceso |
laboratorio.example | Nombre del servidor |
/equipos | Ruta del recurso |
estado=disponible | Parámetro de consulta |
De forma simplificada, al abrirla:
El navegador determina cómo conectarse al destino; puede consultar DNS para resolver el nombre.
Establece o reutiliza una conexión.
En HTTPS, la comunicación utiliza TLS para proteger los datos en tránsito y verificar la identidad del servidor mediante certificados.
Envía una solicitud.
Recibe una respuesta.
Interpreta el contenido.
Solicita recursos adicionales cuando son necesarios.
La caché, las conexiones reutilizadas y otros intermediarios pueden evitar que todos estos pasos se repitan de la misma manera en cada visita. MDN presenta el recorrido general desde la dirección hasta la representación del contenido en el navegador.
HTTPS protege la comunicación; no garantiza por sí mismo que la aplicación tenga reglas correctas o carezca de vulnerabilidades.
1.2.4 Solicitudes y respuestas HTTP
HTTP establece cómo se intercambian solicitudes y respuestas.
Una representación simplificada de una solicitud HTTP/1.1 sería:
GET /api/equipos?estado=disponible HTTP/1.1
Host: laboratorio.example
Accept: application/json
La respuesta podría ser:
HTTP/1.1 200 OK
Content-Type: application/json
[
{
"id": 12,
"nombre": "Laptop 12",
"estado": "disponible"
}
]
La solicitud contiene un método, un destino y encabezados; también puede incluir un cuerpo. La respuesta contiene un código de estado, encabezados y, cuando corresponde, un cuerpo.
Los encabezados proporcionan información adicional. Por ejemplo, Content-Type indica el tipo de contenido del cuerpo.
Métodos frecuentes:
Método | Uso habitual |
GET | Consultar una representación de un recurso |
POST | Enviar datos para que el recurso los procese; frecuentemente crear |
PUT | Crear o reemplazar el estado del recurso identificado |
PATCH | Aplicar modificaciones parciales |
DELETE | Solicitar la eliminación del recurso o de su asociación |
El método, por sí solo, no implementa permisos. Una solicitud DELETE debe ser autenticada y autorizada cuando la operación lo requiera.
Códigos de estado frecuentes:
Código | Significado general | Ejemplo |
200 | Operación atendida correctamente | Consulta del catálogo |
201 | Recurso creado | Registro de un préstamo |
400 | Solicitud inválida | Formato incorrecto |
401 | Faltan credenciales válidas | Sesión no válida |
403 | Operación no permitida | Usuario sin autorización |
404 | Recurso no encontrado | Equipo inexistente |
409 | Conflicto con el estado actual | Equipo que ya fue prestado |
500 | Error interno del servidor | Falla inesperada |
HTTP es esencialmente sin estado: el protocolo no conserva automáticamente una sesión de usuario entre solicitudes. La aplicación puede relacionarlas mediante identificadores de sesión, cookies u otros mecanismos.
1.2.5 Frontend: interacción y presentación
El frontend corresponde a la parte con la que interactúa el usuario.
Incluye:
Formularios.
Menús.
Tablas.
Mensajes.
Botones.
Presentación adaptable.
Interacciones en el navegador.
En el sistema de préstamos, el frontend permite elegir un equipo y enviar la solicitud.
También puede detectar errores evidentes, como un campo obligatorio vacío. Sin embargo, las comprobaciones del navegador pueden ser omitidas o alteradas.
Por ello, no debe decidir de manera definitiva si una persona tiene permiso para registrar préstamos o si un equipo está disponible.
1.2.6 Backend: procesamiento y reglas
El backend realiza el procesamiento del lado del servidor.
Entre sus responsabilidades se encuentran:
Verificar identidad y permisos.
Validar información.
Aplicar reglas.
Consultar y modificar datos.
Coordinar operaciones.
Integrar servicios.
Producir respuestas.
Ejemplos de reglas del sistema:
Un estudiante puede tener como máximo un préstamo activo.
Un equipo en mantenimiento no puede prestarse.
Un usuario suspendido no puede solicitar préstamos.
Una devolución no debe registrarse dos veces.
Estas reglas deben verificarse en el servidor, aunque la interfaz también ofrezca orientación al usuario.
1.2.7 Persistencia y base de datos
La persistencia permite conservar información después de cerrar el navegador o reiniciar un proceso.
Una base de datos puede almacenar:
Usuarios.
Equipos.
Préstamos.
Devoluciones.
Historial de operaciones.
Un modelo inicial podría contener:
Entidad | Datos principales |
Usuario | Identificador, nombre, rol, estado |
Equipo | Identificador, código de inventario, descripción, condición |
Préstamo | Identificador, usuario, equipo, fechas |
Registro de auditoría | Actor, operación, recurso, momento |
Las relaciones permiten saber qué usuario recibió qué equipo.
Una clave foránea puede impedir que se registre un préstamo asociado con un usuario inexistente. Esta es una forma de integridad referencial.
En una aplicación web convencional, el navegador se comunica con el backend; este accede a la base de datos. Las credenciales administrativas de la base no deben incorporarse al JavaScript que recibe el usuario.
1.2.8 Arquitectura por capas
Una organización frecuente separa el sistema en:
Presentación: interacción con el usuario.
Lógica del negocio: reglas y procesos.
Acceso a datos: lectura y escritura en los mecanismos de persistencia.
Es importante distinguir capas lógicas y niveles físicos.
Las capas representan responsabilidades del software. Los niveles físicos representan dónde se ejecutan sus componentes.
Una aplicación puede tener tres capas lógicas y ejecutarse en un solo servidor. También puede distribuirlas entre varios equipos. La documentación de Microsoft distingue explícitamente estas dos dimensiones.
Ejemplo: registrar un préstamo
Presentación: recibe la selección del equipo.
Negocio: verifica que el usuario pueda solicitarlo.
Acceso a datos: registra el préstamo.
Base de datos: conserva la información y aplica restricciones.
Separar responsabilidades facilita cambiar la apariencia sin reescribir las reglas del préstamo.
1.2.9 Patrón Modelo-Vista-Controlador
El patrón MVC organiza responsabilidades mediante tres elementos:
Elemento | Responsabilidad |
Modelo | Datos y comportamiento del dominio |
Vista | Presentación |
Controlador | Recibir la interacción y coordinar la respuesta |
Por ejemplo:
Un controlador recibe la solicitud para prestar un equipo.
Invoca la lógica correspondiente.
El modelo representa las reglas y los datos involucrados.
Una vista presenta la confirmación.
En implementaciones reales puede haber servicios, repositorios y otros componentes adicionales.
El modelo no se reduce a “una tabla” ni el controlador debería concentrar toda la lógica del sistema. Además, MVC y arquitectura de tres capas son clasificaciones relacionadas, pero diferentes.
1.2.10 Arquitectura monolítica
Una aplicación monolítica reúne sus funcionalidades principales en una unidad de despliegue.
Puede contener módulos como:
Usuarios.
Inventario.
Préstamos.
Reportes.
Un monolito puede estar bien organizado. Cuando mantiene límites claros entre módulos se habla de un monolito modular.
Para el sistema de préstamos propuesto, esta sería una elección inicial razonable: permite mantener las reglas relacionadas dentro de una aplicación y reduce la cantidad de servicios que deben operarse.
La limitación aparece cuando el tamaño, las dependencias o la organización del equipo dificultan modificar y desplegar el conjunto.
1.2.11 Arquitectura de microservicios
Los microservicios organizan el sistema en servicios que pueden desarrollarse y desplegarse con mayor independencia, normalmente alrededor de capacidades del negocio.
Por ejemplo:
Identidad.
Inventario.
Préstamos.
Notificaciones.
Sus ventajas potenciales incluyen el despliegue y escalado independiente. Sus costos incluyen comunicación por red, fallas parciales, seguimiento de operaciones y coordinación de datos.
Microsoft advierte que adoptar microservicios exige cambiar también la forma de diseñar, desplegar y operar el sistema.
En un proyecto pequeño, dividir cada función en un servicio puede aumentar el trabajo sin resolver una necesidad real.
1.2.12 API: contrato de comunicación
Una API, o interfaz de programación de aplicaciones, define cómo un componente puede utilizar funciones o datos de otro.
Una API web puede ofrecer operaciones como:
Método y ruta | Propósito |
GET /api/equipos | Consultar equipos |
GET /api/equipos/12 | Consultar un equipo |
POST /api/prestamos | Solicitar un préstamo |
POST /api/prestamos/85/devolucion | Registrar una devolución |
Para crear un préstamo, el cliente podría enviar:
{
"equipoId": 12
}
El backend debe obtener la identidad del usuario desde el mecanismo de autenticación. No basta con aceptar un identificador enviado por el navegador y suponer que le pertenece.
La respuesta podría ser:
{
"id": 85,
"equipoId": 12,
"estado": "activo"
}
JSON es un formato de intercambio de datos. Una API puede utilizarlo, pero también puede intercambiar otros formatos.
REST es un estilo arquitectónico para sistemas distribuidos. Tener rutas HTTP y respuestas JSON no demuestra, por sí solo, que una API cumpla todas sus restricciones.
1.2.13 Concurrencia: dos usuarios solicitan el mismo equipo
Figura 3. Dos usuarios pueden observar la misma disponibilidad; el backend y la base de datos deben impedir el préstamo duplicado. Ilustración didáctica original.
Supongamos esta situación:
Ana consulta el equipo 12 y lo ve disponible.
Luis consulta el mismo equipo y también lo ve disponible.
Ana confirma.
Luis confirma inmediatamente después.
Si el sistema registra ambos préstamos, ha fallado una regla fundamental.
La solución requiere que la comprobación y el registro se coordinen de manera atómica, mediante transacciones, restricciones y mecanismos de concurrencia apropiados.
Un flujo conceptual sería:
Iniciar transacción.
Obtener y proteger los datos necesarios
para evaluar las reglas concurrentes.
Comprobar que:
- el usuario está habilitado;
- no supera su límite de préstamos;
- el equipo admite el préstamo;
- el equipo no tiene otro préstamo activo.
Registrar el préstamo.
Confirmar la transacción.
Si alguna comprobación falla:
revertir y responder con el error correspondiente.
La forma exacta depende del gestor y del diseño.
Desactivar el botón después del primer clic ayuda a la interfaz, pero no resuelve los conflictos entre distintos usuarios.
1.2.14 Seguridad en la arquitectura
La seguridad debe formar parte de la organización del sistema.
Autenticación: comprobar quién es el usuario.
Autorización: comprobar qué puede hacer y sobre qué recursos.
Un estudiante autenticado puede consultar sus préstamos sin tener permiso para revisar los de todos los demás.
Las sesiones deben protegerse porque un identificador de sesión robado puede permitir actuar como el usuario. OWASP trata su gestión como una parte central de la seguridad de aplicaciones web.
También deben considerarse:
Validación del lado del servidor.
Consultas parametrizadas.
Protección de secretos.
Codificación segura de la salida.
Prevención de solicitudes no autorizadas.
Actualización de dependencias.
Registros de auditoría sin contraseñas ni tokens.
Las consultas parametrizadas separan los valores proporcionados por el usuario de la estructura de la consulta SQL y son una defensa principal contra la inyección SQL.
1.3 Tecnologías para el desarrollo de aplicaciones web
Figura 4. Función de HTML, CSS, JavaScript, backend y base de datos. Ilustración didáctica original.
1.3.1 Distinguir las categorías
En desarrollo web conviven herramientas de naturaleza diferente:
Categoría | Función | Ejemplos |
Lenguaje de marcado | Estructurar documentos | HTML |
Lenguaje de estilos | Definir presentación | CSS |
Lenguaje de programación | Expresar instrucciones y lógica | JavaScript, PHP, Python, Java, C# |
Entorno de ejecución | Ejecutar programas | Node.js, JVM, .NET |
Biblioteca | Proporcionar funciones o componentes | React |
Framework | Ofrecer estructura y convenciones | Django, Laravel, Angular |
Gestor de base de datos | Almacenar y consultar datos | PostgreSQL, MySQL |
Servidor HTTP | Atender tráfico HTTP | Apache HTTP Server, Nginx |
Control de versiones | Registrar cambios | Git |
Esta distinción evita afirmaciones incorrectas como “Node.js es un lenguaje” o “HTML administra la base de datos”.
1.3.2 HTML: estructura y significado
HTML significa HyperText Markup Language.
Describe la estructura y el significado del contenido:
<main>
<h1>Equipos disponibles</h1>
<article>
<h2>Laptop 12</h2>
<p>Equipo para actividades académicas.</p>
<button type="button">Solicitar préstamo</button>
</article>
</main>
Aquí:
<main> identifica el contenido principal.
<h1> presenta el encabezado principal.
<article> agrupa contenido con sentido propio.
<h2> identifica un apartado.
<button> representa una acción.
Elegir elementos por su significado ayuda a conservar una estructura comprensible y a utilizar el comportamiento que el navegador ya proporciona.
HTML también permite construir formularios:
<form action="/prestamos" method="post">
<label for="equipo">Número de equipo</label>
<input
id="equipo"
name="equipoId"
type="number"
min="1"
required
>
<button type="submit">Solicitar préstamo</button>
</form>
El atributo name identifica el dato que se enviará. El id permite asociar el campo con su etiqueta.
El formulario requiere un servidor que atienda /prestamos; escribirlo en HTML no implementa el registro.
1.3.3 CSS: presentación y adaptación
CSS significa Cascading Style Sheets.
Permite controlar colores, tamaños, espacios y distribución:
body {
margin: 0;
font-family: system-ui, sans-serif;
line-height: 1.6;
color: #172033;
background: #f3f5f8;
}
main {
max-width: 70rem;
margin: auto;
padding: 1.5rem;
}
.catalogo {
display: grid;
grid-template-columns:
repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
gap: 1rem;
}
article {
padding: 1.25rem;
background: white;
border: 1px solid #cbd5e1;
border-radius: 0.75rem;
}
button {
padding: 0.7rem 1rem;
color: white;
background: #1747a6;
border: 0;
border-radius: 0.4rem;
}
button:focus-visible {
outline: 3px solid #8a3b00;
outline-offset: 3px;
}
La cuadrícula adapta la cantidad de columnas al espacio disponible. El estilo de foco permite reconocer el botón seleccionado al navegar con teclado.
Una interfaz debe comunicar estados mediante texto y otros recursos; depender solamente de un color puede dificultar su interpretación.
1.3.4 JavaScript: comportamiento
JavaScript permite responder a eventos, procesar información y modificar la interfaz.
Por ejemplo:
const boton = document.querySelector("#mostrar-reglamento");
const reglamento = document.querySelector("#reglamento");
boton.addEventListener("click", () => {
reglamento.hidden = !reglamento.hidden;
boton.setAttribute(
"aria-expanded",
String(!reglamento.hidden)
);
});
Este código:
Localiza dos elementos.
Escucha el clic.
Cambia la visibilidad del reglamento.
Actualiza el estado comunicado mediante aria-expanded.
El DOM, o modelo de objetos del documento, es la representación del documento que permite a JavaScript consultar y modificar sus elementos.
1.3.5 Ejemplo completo: catálogo con filtro local
El siguiente ejemplo integra HTML, CSS y JavaScript. Puede guardarse como catalogo.html y abrirse en un navegador.
Permite filtrar una lista local. No consulta un servidor ni registra préstamos: su propósito es mostrar cómo colaboran las tecnologías del frontend.
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta
name="viewport"
content="width=device-width, initial-scale=1"
>
<title>Catálogo del laboratorio</title>
<style>
* {
box-sizing: border-box;
}
body {
margin: 0;
font-family: system-ui, sans-serif;
line-height: 1.6;
color: #172033;
background: #f3f5f8;
}
main {
max-width: 60rem;
margin: auto;
padding: 1.5rem;
}
.filtro {
display: flex;
gap: 0.5rem;
align-items: center;
margin-block: 1.5rem;
}
.catalogo {
display: grid;
grid-template-columns:
repeat(auto-fit, minmax(min(100%, 15rem), 1fr));
gap: 1rem;
}
article {
padding: 1.25rem;
background: white;
border: 1px solid #cbd5e1;
border-radius: 0.75rem;
}
article h2 {
margin-top: 0;
}
input:focus-visible {
outline: 3px solid #1747a6;
outline-offset: 3px;
}
</style>
</head>
<body>
<main>
<h1>Catálogo del laboratorio</h1>
<p>
Consulta los equipos y utiliza el filtro
para mostrar solamente los disponibles.
</p>
<label class="filtro">
<input id="solo-disponibles" type="checkbox">
Mostrar solamente disponibles
</label>
<p id="resumen" role="status"></p>
<section
id="catalogo"
class="catalogo"
aria-label="Lista de equipos"
></section>
<noscript>
<p>
Este ejemplo necesita JavaScript
para construir el catálogo.
</p>
</noscript>
</main>
<script>
const equipos = [
{ id: 1, nombre: "Laptop 01", disponible: true },
{ id: 2, nombre: "Laptop 02", disponible: false },
{ id: 3, nombre: "Proyector 01", disponible: true }
];
const filtro =
document.querySelector("#solo-disponibles");
const catalogo =
document.querySelector("#catalogo");
const resumen =
document.querySelector("#resumen");
function mostrarEquipos() {
const visibles = equipos.filter((equipo) => {
return !filtro.checked || equipo.disponible;
});
catalogo.replaceChildren();
for (const equipo of visibles) {
const tarjeta = document.createElement("article");
const titulo = document.createElement("h2");
const estado = document.createElement("p");
titulo.textContent = equipo.nombre;
estado.textContent = equipo.disponible
? "Estado: disponible"
: "Estado: prestado";
tarjeta.append(titulo, estado);
catalogo.append(tarjeta);
}
resumen.textContent =
`Equipos mostrados: ${visibles.length}`;
}
filtro.addEventListener("change", mostrarEquipos);
mostrarEquipos();
</script>
</body>
</html>
Cómo funciona:
HTML establece las zonas de la página.
CSS organiza las tarjetas.
JavaScript almacena la lista de ejemplo.
El evento change detecta el cambio del filtro.
filter() selecciona los equipos correspondientes.
createElement() construye los elementos.
textContent inserta los nombres como texto.
role="status" permite comunicar la actualización del resumen a tecnologías de asistencia.
Si se cambia la disponibilidad en ese arreglo, solamente cambia la información de esa ejecución local. Otros usuarios no recibirían la modificación y, al recargar, se restaurarían los valores escritos en el código.
1.3.6 Consultar una API con JavaScript
Para obtener datos compartidos se puede utilizar fetch():
async function consultarEquipos() {
const respuesta = await fetch("/api/equipos", {
headers: {
Accept: "application/json"
}
});
if (!respuesta.ok) {
throw new Error(
`No fue posible consultar los equipos: ${respuesta.status}`
);
}
return await respuesta.json();
}
La ruta es relativa al origen de la página y requiere un backend que la implemente.
await permite esperar el resultado dentro de una función asíncrona sin bloquear el hilo de JavaScript durante la espera de la red.
La comprobación de respuesta.ok es relevante: recibir un estado HTTP de error, como 404, no hace que fetch() rechace automáticamente la promesa.
La interfaz también debe manejar el resultado:
async function cargarCatalogo() {
try {
mostrarMensaje("Cargando equipos...");
const equipos = await consultarEquipos();
dibujarCatalogo(equipos);
mostrarMensaje("Catálogo actualizado.");
} catch (error) {
mostrarMensaje(
"No fue posible cargar el catálogo. Intenta nuevamente."
);
console.error(error);
}
}
Las funciones mostrarMensaje() y dibujarCatalogo() representan funciones de la interfaz que deben implementarse.
1.3.7 Lenguajes y entornos del backend
El backend puede desarrollarse con distintas tecnologías.
Lenguaje | Entorno o plataforma | Ejemplos de frameworks |
JavaScript o TypeScript | Node.js | Express, NestJS |
PHP | PHP | Laravel, Symfony |
Python | Python | Django, Flask |
Java | JVM | Spring Boot |
C# | .NET | ASP.NET Core |
Ruby | Ruby | Ruby on Rails |
No es necesario dominar todas para desarrollar una aplicación.
Node.js permite ejecutar JavaScript fuera del navegador. Incluye capacidades para trabajar con redes, archivos y otras funciones del sistema. Su documentación lo describe como un entorno de ejecución multiplataforma.
TypeScript incorpora comprobación estática de tipos al desarrollo basado en JavaScript. Su código habitualmente se transforma en JavaScript para ejecutarse. Los tipos no sustituyen la validación de los datos recibidos desde una red.
1.3.8 Bibliotecas y frameworks
Una biblioteca proporciona herramientas que el programa utiliza. Un framework establece una estructura más amplia y coordina parte de la ejecución.
Los frameworks web pueden facilitar:
Enrutamiento.
Procesamiento de solicitudes.
Plantillas.
Validación.
Acceso a datos.
Autenticación.
Pruebas.
Estas facilidades reducen trabajo repetitivo, pero deben configurarse y utilizarse correctamente. MDN explica que los frameworks del servidor ofrecen herramientas para resolver operaciones habituales del desarrollo web.
La elección debe considerar el conocimiento del equipo, la documentación, el mantenimiento y las necesidades del proyecto.
1.3.9 Bases de datos relacionales y no relacionales
Las bases de datos relacionales organizan información en tablas relacionadas y suelen utilizar SQL.
Ejemplos: PostgreSQL, MySQL y SQLite.
Un esquema ilustrativo en PostgreSQL sería:
CREATE TABLE usuarios (
id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
nombre VARCHAR(120) NOT NULL
);
CREATE TABLE equipos (
id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
codigo VARCHAR(30) NOT NULL UNIQUE,
nombre VARCHAR(120) NOT NULL
);
CREATE TABLE prestamos (
id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
usuario_id INTEGER NOT NULL REFERENCES usuarios(id),
equipo_id INTEGER NOT NULL REFERENCES equipos(id),
fecha_prestamo TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP,
fecha_devolucion TIMESTAMPTZ,
CHECK (
fecha_devolucion IS NULL
OR fecha_devolucion >= fecha_prestamo
)
);
CREATE UNIQUE INDEX un_prestamo_activo_por_equipo
ON prestamos (equipo_id)
WHERE fecha_devolucion IS NULL;
En este diseño:
PRIMARY KEY identifica cada registro.
NOT NULL impide omitir valores obligatorios.
UNIQUE evita códigos repetidos.
REFERENCES establece relaciones.
CHECK verifica una condición.
El índice único parcial impide tener dos préstamos activos del mismo equipo.
El ejemplo todavía requiere otras reglas, como el límite de préstamos por usuario y el tratamiento de equipos en mantenimiento.
PostgreSQL documenta restricciones de unicidad, claves primarias, claves foráneas y comprobaciones como mecanismos para preservar la integridad de los datos.
Las bases no relacionales abarcan modelos diferentes:
Documentos.
Clave-valor.
Grafos.
Familias de columnas.
No representan una opción universalmente superior o inferior. La elección depende de las consultas, las relaciones, las garantías necesarias y la operación del sistema.
1.3.10 Servidores, alojamiento y servicios de infraestructura
Un proyecto publicado necesita recursos de ejecución y conectividad.
Conviene distinguir:
Dominio: nombre utilizado para localizar un servicio.
DNS: sistema que publica información para resolver nombres.
Alojamiento: recursos donde se almacenan o ejecutan componentes.
Servidor HTTP: programa que atiende solicitudes.
Servidor de aplicaciones: entorno o proceso que ejecuta la lógica.
Certificado TLS: elemento utilizado para acreditar la identidad del servidor en HTTPS.
CDN: infraestructura distribuida que puede acercar contenido a los usuarios.
En un despliegue posible, Nginx recibe las solicitudes, sirve archivos y reenvía las operaciones dinámicas al proceso de la aplicación.
En otro, una plataforma administrada se ocupa de buena parte de esa infraestructura. La función sigue existiendo aunque el desarrollador no configure cada componente directamente.
1.3.11 Herramientas de desarrollo
Un entorno de trabajo también necesita herramientas para crear y mantener el sistema:
Herramienta | Utilidad |
Editor o IDE | Escribir y revisar código |
Herramientas del navegador | Inspeccionar elementos, solicitudes y errores |
Git | Registrar cambios y colaborar |
Gestor de paquetes | Administrar dependencias |
Herramientas de prueba | Verificar comportamiento |
Automatización de integración | Ejecutar revisiones de forma repetible |
Contenedores | Empaquetar aplicaciones y dependencias |
Git ayuda a recuperar versiones del código, pero no sustituye una estrategia de respaldo de la base de datos ni de los archivos subidos por usuarios.
1.3.12 Cómo seleccionar una combinación tecnológica
Una combinación de tecnologías se conoce como stack.
Para el sistema de préstamos podrían plantearse varias opciones:
HTML, CSS, JavaScript, PHP y PostgreSQL.
HTML, CSS, JavaScript, Python con Django y PostgreSQL.
HTML, CSS, JavaScript, Node.js y PostgreSQL.
La selección debería responder preguntas como:
¿Qué domina el equipo?
¿Qué infraestructura existe?
¿Qué funcionalidades se requieren?
¿Cuánto costará mantenerlo?
¿Quién atenderá fallas y actualizaciones?
¿Existen restricciones de integración?
Para un primer sistema pequeño, una aplicación modular con páginas generadas en el servidor y JavaScript puntual puede cubrir las necesidades con una complejidad manejable. Esta es una decisión propuesta para el caso del artículo, no una regla para todos los proyectos.
1.4 Planificación de aplicaciones web
Figura 5. Aspectos de la planificación y el ciclo de vida de la aplicación. El proceso admite revisión e iteración. Ilustración didáctica original.
1.4.1 Planificar comienza por el problema
La planificación define qué se necesita construir, por qué, para quién, con qué recursos y cómo se verificará.
Una solicitud inicial podría ser:
“Necesitamos una página para prestar computadoras”.
Esa frase aún no aclara el problema.
Una descripción más útil sería:
El laboratorio registra los préstamos en papel. Esto dificulta conocer la disponibilidad, localizar equipos pendientes de devolución y consultar el historial de cada usuario.
La segunda descripción permite identificar resultados esperados, incluso antes de elegir un lenguaje.
1.4.2 Identificar interesados y usuarios
Los interesados son las personas o áreas que influyen en el proyecto o reciben sus efectos.
En el ejemplo:
Interesado | Necesidad |
Estudiante | Consultar y solicitar equipos |
Encargado | Controlar préstamos y devoluciones |
Docente | Conocer disponibilidad |
Dirección | Consultar reportes |
Administrador técnico | Mantener y recuperar el sistema |
Una misma persona puede desempeñar varios roles.
También conviene observar el proceso real:
¿Cómo se identifica al solicitante?
¿Quién entrega físicamente el equipo?
¿Se necesita aprobación?
¿Qué ocurre si regresa dañado?
¿Cómo se registra un préstamo sin conexión?
¿Quién corrige un error de captura?
Estas preguntas descubren requisitos que una lista de pantallas puede pasar por alto.
1.4.3 Definir objetivos comprobables
Un objetivo general podría ser:
Centralizar el registro de préstamos y devoluciones para conocer la situación de los equipos.
Los objetivos específicos deberían poder verificarse:
Mostrar equipos elegibles para préstamo.
Registrar quién recibe cada equipo.
Impedir préstamos activos duplicados.
Conservar el historial.
Producir un reporte de préstamos pendientes.
Para evaluar el beneficio, primero conviene medir el proceso actual.
Por ejemplo, si localizar un préstamo en papel toma varios minutos, puede definirse una meta de consulta y comprobarla con usuarios reales.
1.4.4 Delimitar el alcance
El alcance establece qué se entregará en una versión.
Primera versión propuesta:
Inicio y cierre de sesión.
Catálogo de equipos.
Registro de préstamos.
Registro de devoluciones.
Consulta de préstamos activos.
Administración básica de usuarios.
Posibles versiones posteriores:
Lectura de códigos QR.
Recordatorios.
Reservaciones por horario.
Reportes avanzados.
Integración con otros sistemas.
Esta separación permite entregar una solución útil sin incorporar todas las ideas al mismo tiempo.
Un cambio que parece pequeño puede ampliar considerablemente el proyecto. “Enviar recordatorios” también implica definir destinatarios, horarios, reintentos, plantillas y tratamiento de errores.
1.4.5 Requisitos funcionales
Los requisitos funcionales describen lo que debe hacer el sistema.
Identificador | Requisito |
RF-01 | Permitir iniciar sesión a usuarios habilitados |
RF-02 | Mostrar el catálogo según los permisos |
RF-03 | Registrar préstamos elegibles |
RF-04 | Registrar devoluciones |
RF-05 | Impedir dos préstamos activos del mismo equipo |
RF-06 | Permitir al usuario consultar su historial |
RF-07 | Permitir al encargado consultar préstamos pendientes |
Es preferible describir comportamientos observables.
“Debe ser moderno” no aclara qué implementar ni cómo verificarlo.
1.4.6 Requisitos no funcionales
Los requisitos no funcionales describen cualidades y condiciones de operación.
Categoría | Ejemplo |
Seguridad | Verificar permisos en cada operación protegida |
Rendimiento | Definir un tiempo de respuesta bajo una carga concreta |
Accesibilidad | Permitir completar los flujos principales con teclado |
Compatibilidad | Funcionar en los navegadores acordados |
Recuperación | Restaurar datos mediante un procedimiento probado |
Mantenimiento | Documentar configuración y despliegue |
Privacidad | Limitar los datos recopilados a lo necesario |
Un requisito de rendimiento debe indicar cómo se medirá.
Por ejemplo:
En un entorno de prueba definido, con un volumen de datos y concurrencia acordados, el percentil 95 de las consultas del catálogo deberá completarse en menos de dos segundos.
El percentil 95 expresa que el 95 % de las mediciones queda en ese valor o por debajo. El número utilizado aquí es ilustrativo y debe ajustarse al contexto.
1.4.7 Historias de usuario y criterios de aceptación
Una historia de usuario expresa una necesidad:
Como encargado del laboratorio, quiero registrar la devolución de un equipo para que pueda volver a prestarse.
Los criterios de aceptación convierten esa necesidad en condiciones comprobables:
El préstamo debe existir y estar activo.
El usuario debe tener permiso.
Debe registrarse la fecha de devolución.
Una segunda devolución no debe duplicar la operación.
La disponibilidad debe actualizarse de forma coherente.
Ejemplo:
Dado un préstamo activo del equipo 12,
cuando un encargado autorizado registra la devolución,
entonces el préstamo queda finalizado
y el equipo puede volver a solicitarse
si no tiene otra condición que lo impida.
La última condición es necesaria: devolver un equipo dañado no significa que deba quedar inmediatamente disponible.
1.4.8 Analizar factibilidad
Antes de comprometer el proyecto conviene revisar:
Factibilidad técnica: infraestructura, conectividad, conocimientos e integraciones.
Factibilidad económica: desarrollo, dominio, alojamiento, mantenimiento y soporte.
Factibilidad operativa: personas que usarán el sistema y capacidad para incorporarlo al trabajo.
Factibilidad temporal: posibilidad de terminar y verificar el alcance dentro del plazo.
También deben identificarse las obligaciones aplicables al tratamiento de datos y al uso de servicios. La planificación necesita determinar quién será responsable de esa revisión.
Un sistema técnicamente correcto puede fracasar si nadie mantiene actualizado el inventario.
1.4.9 Diseñar procesos, navegación e interfaces
Antes de programar conviene representar el flujo de trabajo.
Solicitud de préstamo:
El usuario inicia sesión.
Consulta equipos.
Selecciona uno.
Revisa condiciones.
Confirma.
El sistema verifica reglas.
Muestra el resultado.
También deben diseñarse las rutas alternativas:
Sesión vencida.
Equipo recién prestado.
Usuario suspendido.
Conexión interrumpida.
Datos inválidos.
Un wireframe muestra la organización de una pantalla sin necesidad de definir todos sus detalles visuales.
Un prototipo permite explorar interacciones antes de implementar la aplicación completa.
Las pantallas deben contemplar estados vacíos, errores y carga, además del resultado exitoso.
1.4.10 Planificar accesibilidad desde el inicio
La accesibilidad permite que personas con distintas capacidades utilicen el sistema.
Entre las decisiones iniciales se encuentran:
Utilizar controles semánticos.
Proporcionar etiquetas.
Mantener contraste suficiente.
Conservar foco visible.
Evitar instrucciones basadas solamente en color.
Explicar errores junto a los campos correspondientes.
Permitir ampliación del contenido.
Evaluar navegación con teclado.
WCAG organiza la accesibilidad alrededor de cuatro principios: contenido perceptible, operable, comprensible y robusto. W3C también recomienda incorporarla durante todo el proceso, con responsabilidades y evaluación continua.
Una herramienta automática puede detectar ciertos problemas, pero la evaluación también necesita revisión manual de los flujos.
1.4.11 Diseñar datos, permisos y contratos
La planificación debe resolver decisiones que afectan a toda la aplicación:
Qué entidades existen.
Cómo se relacionan.
Qué estados son válidos.
Qué operaciones permite cada rol.
Qué información intercambian los componentes.
Una matriz inicial de permisos podría ser:
Operación | Estudiante | Encargado | Administrador |
Consultar catálogo | Sí | Sí | Sí |
Consultar historial propio | Sí | Sí | Sí |
Consultar préstamos de todos | No | Sí | Sí |
Registrar devoluciones | No | Sí | Sí |
Administrar usuarios | No | No | Sí |
Esta matriz es una propuesta del ejemplo. Debe validarse con la institución.
El contrato de una API debe especificar:
Método y ruta.
Datos de entrada.
Autenticación.
Reglas.
Respuestas exitosas.
Errores posibles.
Acordarlo evita que frontend y backend trabajen con interpretaciones diferentes.
1.4.12 Identificar riesgos
Un riesgo es una situación incierta que puede afectar el proyecto.
Riesgo | Consecuencia | Respuesta prevista |
Préstamos simultáneos | Duplicación | Transacciones y restricciones |
Pérdida de datos | Historial incompleto | Respaldos y restauración probada |
Falla de conexión | Operación interrumpida | Procedimiento de contingencia |
Uso de cuenta ajena | Operaciones atribuidas incorrectamente | Controles de identidad y sesión |
Ampliación continua del alcance | Retraso | Priorización y control de cambios |
Falta de capacitación | Registros incorrectos | Guías y acompañamiento |
La existencia de un respaldo no demuestra que pueda recuperarse el sistema. Es necesario realizar una restauración de prueba.
1.4.13 Priorizar una primera versión útil
Un producto mínimo viable es una versión limitada que permite resolver una necesidad relevante y obtener evidencia de uso.
Para este sistema, la primera versión necesita registrar préstamos con integridad. Puede posponer gráficos complejos.
La priorización puede considerar:
Valor para el usuario.
Riesgo.
Dependencias.
Esfuerzo.
Frecuencia de uso.
“Conservar correctamente los préstamos” tiene prioridad sobre “personalizar el color del panel”.
1.4.14 Organizar el trabajo en incrementos
Una secuencia posible sería:
Incremento | Resultado verificable |
1 | Problema, alcance y reglas acordados |
2 | Modelo de datos y prototipo revisados |
3 | Acceso y catálogo funcionales |
4 | Préstamos y devoluciones funcionales |
5 | Pruebas, correcciones y recuperación |
6 | Publicación, capacitación y seguimiento |
Esto no significa que cada incremento dure una semana. La duración depende del tamaño del equipo, las horas disponibles y la complejidad.
El trabajo iterativo permite revisar decisiones cuando aparece nueva información. No elimina la necesidad de documentarlas.
1.4.15 Planificar pruebas
Las pruebas deben derivarse de los requisitos y riesgos.
Para el sistema de préstamos resultan especialmente útiles estos casos:
Caso | Resultado esperado |
Usuario habilitado solicita equipo libre | Se registra el préstamo |
Usuario suspendido intenta solicitarlo | Se rechaza |
Dos usuarios solicitan el mismo equipo | Solo uno obtiene el préstamo |
Estudiante intenta registrar devolución | Se deniega según la política |
Se repite una devolución | No se duplica |
Se modifica el identificador de otro usuario | No se expone información sin permiso |
Se restaura un respaldo | Se recuperan datos y funcionamiento |
Pueden combinarse pruebas de reglas, integración, flujos completos, seguridad, accesibilidad y rendimiento.
Probar solamente las pantallas no demuestra que las restricciones de la base funcionen bajo concurrencia.
1.4.16 Preparar publicación y mantenimiento
Publicar requiere más que copiar archivos.
Debe establecerse:
Configuración del entorno.
Gestión de secretos.
Dominio y HTTPS.
Migraciones de base de datos.
Monitoreo.
Respaldos.
Procedimiento de reversión.
Responsable de soporte.
Conviene distinguir ambientes:
Desarrollo: construcción.
Pruebas: verificación.
Producción: uso real.
Después de publicar continúan la corrección de errores, actualización de dependencias, revisión de accesos y atención a los usuarios.
1.4.17 Mantener trazabilidad
La trazabilidad conecta una necesidad con su implementación y su verificación.
Necesidad | Requisito | Implementación | Verificación |
Evitar duplicación | RF-05 | Regla del backend y restricción de datos | Solicitudes simultáneas |
Proteger historiales | Acceso por permisos | Autorización por recurso | Intento de consulta ajena |
Recuperar información | Requisito de recuperación | Respaldo y procedimiento | Restauración |
Facilitar uso con teclado | Requisito de accesibilidad | Controles y foco adecuados | Recorrido manual |
Esta relación ayuda a demostrar que el sistema responde al problema original.
Integración del ejemplo: de la pantalla al préstamo registrado
El sistema de préstamos permite reunir los cuatro subtemas.
La evolución explica por qué una página informativa puede transformarse en una aplicación que recibe solicitudes y conserva historiales.
La arquitectura establece que la interfaz recibe la intención del usuario, el backend verifica las reglas y la base de datos conserva el resultado.
Las tecnologías permiten implementar esas responsabilidades: HTML estructura, CSS presenta, JavaScript facilita interacciones y el backend coordina operaciones persistentes.
La planificación determina qué debe construirse, qué límites tendrá y cómo se comprobará su funcionamiento.
Una solicitud completa seguiría este recorrido:
El usuario pulsa “Solicitar préstamo”.
El navegador envía la petición.
El backend identifica al usuario.
Comprueba sus permisos.
Valida el identificador del equipo.
Coordina las comprobaciones y el registro dentro de una operación consistente.
La base de datos aplica sus restricciones.
El servidor confirma o informa un conflicto.
La interfaz presenta el resultado.
El sistema conserva el registro necesario para seguimiento.
Que el botón responda es solamente una parte del funcionamiento. La operación está bien resuelta cuando la respuesta es correcta, los datos quedan consistentes y cada usuario actúa dentro de sus permisos.
Referencias y enlaces de consulta
Las siguientes fuentes incluyen explicaciones conceptuales, documentación técnica y guías para ampliar los temas.
CERN. Historia de la Web. Origen y desarrollo inicial de la World Wide Web. https://home.cern/science/computing/the-birth-of-the-web/
MDN Web Docs. Cómo funciona la Web. Navegadores, servidores, DNS y recursos. https://developer.mozilla.org/es/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works
MDN Web Docs. Introducción a la programación del lado del servidor. Contenido dinámico y responsabilidades del backend. https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Introduction
MDN Web Docs. Visión general de cliente y servidor. Solicitudes, procesamiento y respuestas. https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview
MDN Web Docs. Visión general de HTTP. Fundamentos del protocolo. https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview
Microsoft Learn. Arquitectura de N niveles. Capas lógicas y niveles físicos. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier
Microsoft Learn. Arquitectura de microservicios. Características y compromisos operativos. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices
MDN Web Docs. Aprende desarrollo web. Formación en HTML, CSS, JavaScript y herramientas. https://developer.mozilla.org/es/docs/Learn_web_development
Node.js. Introducción oficial. Entorno de ejecución de JavaScript. https://nodejs.org/learn/getting-started/introduction-to-nodejs
PostgreSQL. Restricciones. Integridad, unicidad y relaciones entre tablas. https://www.postgresql.org/docs/18/ddl-constraints.html
MDN Web Docs. Aplicaciones web progresivas. Características y desarrollo de PWA. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
OWASP. Prevención de inyección SQL. Consultas parametrizadas y otras medidas de protección. https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
OWASP. Gestión de sesiones. Protección de sesiones e identificadores. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
W3C WAI. Introducción a WCAG. Estándares de accesibilidad web. https://www.w3.org/WAI/standards-guidelines/wcag/
W3C WAI. Planificación y gestión de la accesibilidad web. Integración de accesibilidad durante el proyecto. https://www.w3.org/WAI/planning-and-managing/
Comentarios