Arquitectura de software en capas

Una "arquitectura de software", es un conjunto de normas, patrones y guías, que definen de forma genérica, como realizar todo un proyecto desde el nivel más alto. Es decir, sería como la "plantilla inicial", a partir de la cual, se realizaría todo un proyecto de software.

Una de las arquitecturas de software más utilizadas y mejor consideradas en el desarrollo Web, es la arquitectura de capas.

La filosofía de esta arquitectura, se basa en dividir el software en partes o capas, de manera que cada capa sea lo más independiente posible con respecto a las demás. De esta forma en caso de tener que cambiar alguna de las partes, el resto mantengan su funcionalidad y no necesiten ser modificadas.

Por lo general, la arquitectura de capas dentro del desarrollo Web, se suele dividir en 3 grandes capas (arquitectura de 3 capas):
  1. Capa de presentación: Englobaría la parte de presentación de la información al usuario. nunca debería tener código de servidor. En partes donde se necesitase poner valores de variables u otros datos, pasados en ejecución, se suele crear una definición de tipos de datos, para poder ser tratados posteriormente, por ejemplo:
    Hola [NOMBRE_USUARIO], bienvenido.
    En un proyecto Web, serían los datos descargados al equipo del usuario: (X)HTML, CSS, JavaScript, ...
  2. Capa de lógica de negocio: Serían las aplicaciones, programas y funcionalidades encargadas de que el proyecto funcione. En esta capa, nunca deberían encontrarse datos de presentación (código HTML por ejemplo) ni tratamientos de datos (por ejemplo una sentencia SQL SELECT * FROM TABLA).
    Además, esta capa se encargaría de tratar los datos de la capa de presentación y de realizar las peticiones a los procesos de la capa de datos. Estos conectores con las otras capas, deberían ser lo más independientes posibles, ya que en caso de cambiar cualquier capa, se debe cambiar su correspondiente "conector".
    En un proyecto Web, serían las aplicaciones ejecutadas en el servidor: PHP, ASP, JSP, PERL, ...
  3. Capa de datos: Sería la encargada, tanto del almacenamiento de los datos, como del tratamiento de los mismos. En un proyecto Web, sería, por lo general, la Base de Datos, con sus correspondientes procesos almacenados, funciones y triggers, encargados del tratamiento de los datos (tanto selección como eliminación, modificación o inserción).
    También podría ser, por ejemplo, un sistema de archivos con los datos, en este caso, debería tener una serie de procesos para tratar esos datos, que son los que serían llamados desde la capa de lógica para tratar los datos.


Las principales ventajas de la arquitectura de capas, es, como se ha dicho, que al estar dividido el proyecto en partes claramente diferenciadas, en caso de cambios, estos sólo afectarían a una capa (por lo general), mientras que el resto de capas, no sufrirían modificaciones, por lo que se podría hacer de una forma más rápida y eficaz.
Además en el desarrollo, se puede realizar cada capa de forma paralela, de forma que se pueda hacer de forma más rápida y eficaz. Esto permite además crear grupos de trabajo especializados en cada materia, por ejemplo:
  1. Capa de presentación: Equipo de diseñadores, maquetadores, seos, expertos en estándares (XML, HTML, CSS), etc.
  2. Capa de lógica de negocio: Equipo de desarrolladores (analistas, programadores, ...), expertos en el lenguaje en el que se desarrolle.
  3. Capa de Datos: Equipo de expertos en BBDD, sistemas, estructuras de sistemas de ficheros, etc.

Las principales desventajas, son que, en la práctica las divisiones de cada capa, pueden ser "difusas", por lo que si no hay un análisis minucioso y experto de lo que se necesita y, sobre todo, de los cambios que se pueden producir, puede hacer que, en el momento en que haya que hacer un cambio no previsto de cierta relevancia, el análisis original se caiga y haya que hacer todo de nuevo. Por ejemplo, la capa de datos, suele interpretarse como "capa de base de datos", lo que puede ser fatal, en caso de que se recurra a otros tipos de datos.

Otra desventaja que suele producirse, es que aunque el análisis original sea bueno, con el paso del tiempo, un proyecto, va pasando por diferentes manos, algunas más expertas que otras y se puede (se suele) tender a tomar atajos, con lo que diferentes capas (sobre todo la de negocio), acaban teniendo funcionalidades, propias de las otras.
Además en caso de equipos diferenciados (equipo de desarrollo, de diseño, de BBDD), la comunicación entre equipos / departamentos en la realidad en muchas empresas, suele ser deficiente, por lo que suelen ser los encargados de cada equipo (en teoría los más expertos), los que decidan tomar esos atajos.

Una vez explicado todo esto, hay que recordar que aunque en la teoría, hay tres capas, con 2 "conectores", que podrían (deberían) ser interpretados, como 2 capas más, en la práctica, estas se pueden (y deberían) dividir en muchas más, a continuación veamos algunos ejemplos:

Ejemplo 1: Validación de login en una Web.

En la capa de presentación se harían los "templates" necesarios:

LOGIN_INICIO_CORRECTO.tpl
[tpl_CABECERA]
<p>Bienvenido de nuevo [var_NOMBRE]</p>
[tpl_PIE]


LOGIN_INICIO_ERRONEO.tpl
[tpl_CABECERA]
<p>Se ha producido un error en el login</p>
[tpl_PIE]


Como se comento, estas plantillas, podrían tener formatos de texto especiales, para indicar al "conector" que sea tratado de alguna forma, por ejemplo:
[var_LOQUESEA] -> Podría indicar que se sustituya por el valor de una variable llamada "LOQUESEA"
[tpl_LOQUESEA] -> Podría indicar que se sustituya por el contenido de un archivo template llamado "LOQUESEA"
[fun_LOQUESEA ([var_UNO],[var_DOS])] -> Podría indicar que se sustituya por el valor de una función llamada "LOQUESEA" (recibiendo dos valores de variables)


En la capa de lógica de negocio se harían las ejecuciones en servidor necesarias:


// Recogida de datos del formulario (usuario, password)

// Llamada conector datos, usuario_valido, pasando: usuario password

// Si es usuario válido: llamada conector presentación, LOGIN_INICIO_CORRECTO
// Si no: llamada conector presentación, LOGIN_INICIO_ERRONEO



En la capa de datos, se encontraría la funcionalidad, encargada de evaluar el usuario y password:


// Recogida de valores (usuario, password)

// Comprobación formato valores válido y que el usuario existe
// Comprobación password de usuario es igual al pasado

// Si (password_usuario == password_pasado) devolver nombre_usuario
// Si no devolver false



En la capa de negocio se encontraría, el conector de presentación, este tendría una funcionalidad principal, para que al ser llamada desde la capa de negocio, devuelva, todo lo propio de la capa de presentación, con los cambios pertinentes.
En principio, esto sería una funcionalidad sencilla, centralizada y facil de cambiar en caso de ser necesario, debería hacer algo así:

pasa_formato:

// Recogida de valores (documento template)

// lectura de documento
// mientras buscar textos a parametrizar
  // Si texto tipo variable, reemplazar por valor variable
  // Si texto tipo función, evaluar posibles variables y reemplazar por valor función
  // Si texto tipo template, llamar esta función (recursiva)
// Fin mientras

// Devolver texto resultante



En la práctica, se pueden crear muchas funciones, encargadas de hacer tareas repetitivas, o necesarias para la creación de documentos (por ejemplo, pintar una tabla sin saber el número de filas al ser estas por parámetro), por ejemplo:
  • Pinta_formulario
    • Pinta_campo_texto
    • Pinta_area_texto
    • Pinta_boton
    • Pinta_selector
  • Pinta_tabla
    • Pinta_cabecera
    • Pinta_línea
  • ...

Todas estas funcionalidades, deberían ser llamadas desde "pasa_formato" cuando se solicite desde la capa de presentación (por ej: [fun_PINTA_TABLA([var_VALORES_TABLA])]), por lo que deberían ser consideradas de la capa conector de presentación. De forma que, por ejemplo si se quisiese cambiar la salida de, por ejemplo HTML a, por ejemplo, documentos Word, se debería cambiar toda la capa de presentación (obvio), pero además, la forma de pintar las tablas, formularios, etc. Es decir, el conector de presentación.

El conector de datos, por último, también debería tener una funcionalidad principal, que reciba los datos, de la forma lo más estandarizadamente posible, para que posibles modificaciones en la capa de datos, no afecten a las otras capas, por ejemplo:


// Ini Funcionalidad apertura
  // Creación valores necesarios
  // Inicializaciones necesarias
// Fin Funcionalidad apertura

// Ini Funcionalidad peticion_datos
  // Recogida valores petición
  // Lanzar petición
  // Devolver resultado petición
// Fin Funcionalidad peticion_datos

// Ini Funcionalidad cierre
  // Modificación valores necesarios
  // Eliminaciones necesarias
// Fin Funcionalidad cierre



Ejemplo 2: Diseño gráfico de una Web completa.

En un gráfico se podría representar de la siguiente forma:



Donde:
  • La capa de presentación, al ser en el ejemplo HTML (típico para desarrollos Web), se ha dividido en 3 subcapas:
    • HTML, o la estructura de los datos. También sería por ejemplo XML, RSS, ...
    • CSS o formato de los datos. También serían las imágenes.
    • JS o aplicaciones de lógica de presentación (no confundir con lógica de negocio), donde se englobarían las funcionalidades de presentación (ejecutadas desde la máquina del usuario)
    La capa de "estructura de datos" (HTML), en este caso, tendría un "conector", que no sería otra cosa, que el "template" encargado de llamar a los archivos correspondientes de las otras subcapas, por ejemplo:

    CABECERA.tpl
    <head>

      <!-- Se crean las llamadas a CSS >
      <link rel="stylesheet" type="text/css" href="/directorio_estilos/estilo1.css">
      <link rel="stylesheet" type="text/css" href="/directorio_estilos/estilo2.css">
      <link rel="stylesheet" type="text/css" href="/directorio_estilos/estiloN.css">

      <!-- Se crean las llamadas a JS >
      <script type="text/javascript" src="/directorio_scripts/script1.js"></script>
      <script type="text/javascript" src="/directorio_scripts/script2.js"></script>
      <script type="text/javascript" src="/directorio_scripts/scriptN.js"></script>

    </head>
  • La capa de datos, se dividiría en 2 subcapas:
    • Los Datos.
    • Las funcionalidades encargadas de manejar los datos.
  • La capa de negocio, como se ve en el gráfico se comunica con las otras capas mediante los conectores.
  • Los conectores, que en realidad, formarían parte de la capa de lógica de negocio:
    • El conector de presentación, que sería llamado desde las funcionalidades de la capa de negocio y llamaría a los templates requeridos, realizando las funcionalidades requeridas en caso de ser necesario.
      Desde la capa de negocio, nunca se debería llamar directamente a una "funcionalidad de apoyo".
    • El conector de datos, que sería llamado desde las funcionalidades de la capa de negocio y llamaría a las funcionalidades requeridas.
      Desde la capa de negocio, nunca se debería acceder directamente a los datos.


Ejemplo 3: Cambio del diseño (apariencia) de la Web.

Teniendo en cuenta el ejemplo anterior, en caso de que se necesite, cambiar la apariencia de la Web, en caso de haber seguido el diseño, sólo habría que cambiar en la capa de presentación, la subcapa de presentación de los datos, que englobaría los CSS e imágenes, así como su "conector", es decir, cambiar la referencia a los archivos nuevos. Incluso se podrían hacer diseños paralelos para diferentes circunstancias.
Aquí, se ve un ejemplo, de como un cambio que podría ser costoso, con este sistema, se simplificaría mucho teniendo que tocar en una parte muy pequeña y delimitada del proyecto.

Ejemplo 4: La página debe ser ahora en Flash.

En este caso, habría que cambiar toda la capa de presentación, cambiando los HTML, con sus correspondientes CSS y scripts, por archivos Flash, que hagan esas mismas funcionalidades.

Además el conector de presentación, debería ser reescrito por completo, tanto la funcionalidad principal (pasa_formato), que ahora, podría simplemente, crear el HTML, llamando al Flash apropiado en cada caso, como las funcionalidades de apoyo.

Sin embargo, el resto del proyecto (capa negocio y capa datos), debería seguir inalterable.

Ejemplo 5: Los datos han cambiado.

Imaginando que los datos han cambiado a, por ejemplo un sistema de ficheros, habría que cambiar toda la capa de datos, incluidas las funcionalidades encargadas de tratar esos datos, que deberían cambiar de procesos de la base de datos, a por ejemplo una aplicación o scripts que se encarguen de ello.
No tendría que ser necesariamente en el mismo lenguaje que en la capa de lógica de negocio, y si así fuera, estas funcionalidades, no deberían ser consideradas como tal.

En caso de que se haya previsto adecuadamente, esto no debería afectar al resto del proyecto, por ejemplo si en la capa negocio se llama de la siguiente manera al conector de datos:

Apertura();
PeticionDatos("LoginUsu", "usu1", "Pass1");
Cierre();

En el caso de BBDD:
  • Apertura: Inicia valores y conector BBDD.
  • PeticionDatos: Llama al proceso almacenado del primer valor (LoginUsu), pasándole como parámetros, el resto.
  • Cierra: Finaliza valores y conector BBDD.

En caso de ser un script:
  • Apertura: Inicia valores.
  • PeticionDatos: Llama a la funcionalidad del primer valor (LoginUsu), pasándole como parámetros, el resto.
  • Cierra: Finaliza valores.



Links relacionados:
Conectarse a una Base de Datos MySQL (PHP)
Ejecutar sentencias SQL a un array bidimensional (PHP)
Leer líneas de un archivo con la función file (PHP)
Recorrer directorio para tratar su contenido (PHP)
Funciones de conexión a bases de datos (ASP)
Crear conexión a una BD (Base de Datos) (ASP)
Como usar los estilos
Aplicar los estilos a diferentes dispositivos
Lincar páginas a archivos JS
Cargar y presentar variables de fichero externo (Flash)
Ejecutar JavaScript desde Flash por URL (Flash)
Generador de códigos para crear el HEAD (HTML)
Guardar datos binarios en un fichero (V.B.)
Métodos de conexión HTTP


Para cualquier duda, consulta, sugerencia, opinión, colaboración, etc; no dude en ponerse en contacto con nosotros

Copyright © 2002-2017 [McAnam]. Reservados todos los derechos.
www.mcanam.com