ARQUITECTURA DE SOFTWARE

En los inicios de la informática, la programación se consideraba un arte y se

desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guías
generales, con base a las cuales se puedan resolver los problemas.

A estas, se les ha denominado Arquitectura de Software, por que, semejanza de los

planos de un edificio o construcción, estas indican la estructura, funcionamiento e
interacción entre las partes del software.

PATRONES DE DISEÑO SOFTWARE

El diseño es un modelo del sistema, realizado con una serie de principios y técnicas,
que permite describir el sistema con el suficiente detalle como para ser implementado.

Pero los principios y reglas no son suficientes, en el contexto de diseño podemos

observar que los buenos ingenieros tienen esquemas y estructuras de solución que
usan numerosas veces en función del contexto del problema.

Este es el sentido cabal de la expresión "tener un mente bien amueblada", y no el

significado de tener una notable inteligencia. Estos esquemas y estructuras son
conceptos reusables y nos permiten no reinventar la rueda. Un buen ingeniero reutiliza
un esquema de solución ante problemas similares.

Christopher Alexander (creador del libro “A Pattern Language:

Towns/Building/Construction” en 1977) comenta que “Cada patrón describe un
problema que ocurre una y otra vez en nuestro entorno, para describir después el
núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada
más de un millón de veces sin hacerlo siquiera dos veces de la misma forma”. Por ello,
dice Alexander que los numerosos usos de un patrón no se repiten dos veces de la
misma forma.

Siguiendo el libro de GOF (libro “Gang-Of-Four”) los patrones se clasifican según el

propósito para el que han sido definidos:

Creación Estructural De Conducta

Interprete
Método de
Clase Adaptador (clases)
Fabricación
Plantilla

Cadena de
Responsabilidad,
Adaptador (objetos),
Comando (orden),
Fábrica, Constructor, Puente, Composición,
Objeto Iterador, Intermediario,
Prototipo, Singleton Decorador, Fachada,
Observador, Estado,
Flyweight
Estrategia, Visitante,
Memoria
VENTAJAS DE LOS PATRONES:

La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de modo

que los sistemas evolucionen de forma adecuada.

Cada patrón permite que algunos aspectos de la estructura del sistema puedan
cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad
y mantenimiento.

Un patrón es un esquema o micro arquitectura que supone una solución a problemas

(dominios de aplicación) semejantes (aunque los dominios de problema pueden ser
muy diferentes e ir desde una aplicación CAD a un cuadro de mando empresarial).

También conviene distinguir entre un patrón y una arquitectura global del sistema.

Por decirlo en breve, es la misma distancia que hay entre el diseño de un componente
(o módulo) y el análisis del sistema.

Es la diferencia que hay entre el aspecto micro y el macro, por ello, en ocasiones se
denomina a los patrones como "micro arquitecturas".

MODELO VISTA CONTROLADOR

Modelo Vista Controlador (MVC) es un estilo de arquitectura de software que separa

los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres
componentes distintos.

El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página

HTML y el código que provee de datos dinámicos a la página.

El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el

controlador es el responsable de recibir los eventos de entrada desde la vista.

HISTORIA

El patrón (M.V.C) fue descrito por primera vez en 1979 por Trygve Reenskaug,
entonces trabajando en Smalltalk en laboratorios de investigación de Xerox.

M.V.C. divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada.

Para esto, utiliza las siguientes abstracciones:
Modelo: Encapsula los datos y las funcionalidades. El modelo es independiente de
cualquier representación de salida y/o comportamiento de entrada.

Vista: Muestra la información al usuario. Pueden existir múltiples vistas del modelo.
Cada vista tiene asociado un componente controlador.

Controlador: Reciben las entradas, usualmente como eventos que codifican los
movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc.

Los eventos son traducidos a solicitudes de servicio ("service requests") para el modelo
o la vista.

Se han desarrollado a lo largo de los años, desde la presentación de este patrón a la

comunidad científica 3 variantes fundamentales, que se presentan brevemente a
continuación.

VARIANTE INICIAL DEL PATRÓN MVC

Variante en la cual no existe ninguna comunicación entre el Modelo y la Vista y esta

última recibe los datos a mostrar a través del Controlador.

VARIANTE INTERMEDIA DEL PATRÓN MVC

Variante en la cual se desarrolla una comunicación entre el Modelo y la Vista, donde

esta última al mostrar los datos, la busca directamente en el Modelo, dada una
indicación del Controlador, disminuyendo el conjunto de responsabilidades de este
último.
VARIANTE MODIFICADA PARA APLICACIONES MULTIMEDIA DEL MVC,
CONOCIDA COMO MVCMM

Variante en la cual se diversifica las funcionalidades del Modelo teniendo en cuanta las
características de las aplicaciones multimedia, donde tienen un gran peso las medias
utilizadas en estas.

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el

control generalmente es el siguiente:

1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo,

el usuario pulsa un botón, enlace)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la
notificación de la acción solicitada por el usuario. El controlador gestiona el
evento que llega, frecuentemente a través de un gestor de eventos (handler) o
callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de
forma adecuada a la acción solicitada por el usuario. Los controladores
complejos están a menudo estructurados usando un patrón de comando que
encapsula las acciones y simplifica su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz
de usuario. La vista obtiene sus datos del modelo para generar la interfaz
apropiada para el usuario donde se refleja los cambios en el modelo (si se
utiliza la variante 2 descrita anteriormente, de lo contrario lo obtiene a través
del Controlador). El modelo no debe tener conocimiento directo sobre la vista.
Sin embargo, el patrón de observador puede ser utilizado para proveer cierta
indirección entre el modelo y la vista, permitiendo al modelo notificar a los
interesados de cualquier cambio. Un objeto vista puede registrarse con el
modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin
saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a
 la vista aunque puede dar la orden a la vista para que se actualice. Nota: En
algunas implementaciones la vista no tiene acceso directo al modelo, dejando
que el controlador envíe los datos del modelo a la vista, según lo descrito en la
segunda variante.
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el
ciclo nuevamente.

COMPONENTES

MODELO

Son operaciones entre datos recibidos o solicitados, accesos a base de datos.

Su función es preparar todos los elementos que puedan variar en las vistas y
preparárselos a estas introduciéndolos en variables.
Esta codificado junto con parte del controlador (en actions).
Un cambio aquí, repercute en todas las vistas que utilicen esos datos.

VISTAS

No suelen cambiar a no ser por razones de diseño y estos cambios no influyen

al resto de la aplicación ni a la forma de obtener los datos.
En aplicaciones web: Html, jsp, etc.
Pintan las variables u objetos que reciben del modelo directamente o usando
los metodos GET del objeto.

CONTROLADOR

En función de lo que recibe por parte del usuario, decide:

Que parte/s del modelo se va a ejecutar.

Que vista es la que tiene que representar los datos.

CONTROLADOR (ACTIONS)

Los actions son objetos donde se realizan llamadas al modelo (crear, obtener y/o
cambiar datos) y donde se toman decisiones sobre que parte de este se ejecuta

¿PORQUÉ UTILIZAR MVC?

El fácil mantenimiento de código en un futuro, ya que al estar separadas los distintos

procesos según su tipo.

Si quisiéramos por ejemplo cambiar de tipo de base de datos, solo tendremos que
cambiar la capa modelo.

Como todos los programadores que llevan unos años machacando teclas, mi mayor
ilusión es ver mi código reutilizado una y otra vez en los proyectos en los que me voy o
me van metiendo. A medida que he ido ganando experiencia, mi sistema de
programación cada vez se acerca más a un sistema modular, basado en capas o
grupos.
CONCLUSIONES

Actualmente existen miles de aplicaciones web en la red, muchas de ellas realizadas

con una programación desestructurada y sin diferenciación de módulos.

Esto implica una difícil actualización, optimización y división de trabajo. En estos

momentos las aplicaciones web están convirtiéndose en software de gran complejidad
que en ocasiones se implementan por diferentes personas, como por ejemplo el equipo
de programadores y el equipo de diseñadores.

Esto obliga a utilizar un modelo estructurado de programación. El modelo MVC no es el

único que existe, pero nos proporciona una división tanto lógica como técnica en el
sistema.

Además proporciona un medio más organizado para el diseño del sistema, permitiendo
realizar aplicaciones pensadas para todos los tipos de navegadores que existen.

Sistemas tan famosos como BLOGGER, GMAIL, WIKIPEDIA utilizan estos modelos para
su implementación, están marcando el futuro del desarrollo de aplicaciones.

BIBLIOGRAFIA

PATRONES DE DISEÑO

http://www.proactiva-calidad.com/java/patrones/index.html#algunos_patrones

M.V.C

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

http://www.monografias.com/trabajos43/patron-modelo-vista/patron-modelo-
vista2.shtml

http://laurel.datsi.fi.upm.es/~ssoo/DAW/presentaciones/mvc/index.php

http://carlos-serrano-sanchez.blogspot.com/2006/10/modelo-mvc.html