En esta ocasin hablar de un tema relacionado con las Interfaces de Programacin de

Aplicaciones (API) y con las pruebas que juega un papel fundamental dentro de la
arquitectura: las interfaces. Las interfaces son los puntos de contacto que establecen un
contrato que permite el intercambio de informacin entre elementos que forman parte de
la arquitectura de un sistema de software. Estos elementos pueden ser lgicos (ej.
mdulos), dinmicos (ej. objetos) o fsicos (ej. nodos de hardware). Recordemos que la
arquitectura est formada por estructuras compuestas por elementos conectados entre s
(ver SG27), y es en los puntos de conexin donde se encuentran las interfaces.
Durante el diseo de la arquitectura (ver SG29), el arquitecto considera un subconjunto de
requerimientos que se denominan drivers para crear las estructuras que conforman a la
arquitectura del sistema. Estos requerimientos incluyen requerimientos funcionales
primarios, atributos de calidad y restricciones (ver SG28). Al disear la arquitectura, el
arquitecto identifica elementos que permiten satisfacer los drivers, junto con las interfaces
de estos elementos. La identificacin y definicin de las interfaces se hace, generalmente,
mediante un anlisis dinmico de la interaccin entre los elementos con el fin de soportar
un requerimiento particular. La figura 1 muestra un ejemplo de esto.

Figura 1. Estructuracin lgica para soportar el caso de uso CU-1 (llave: UML)
El caso de uso CU-1, que es primario, forma parte de los drivers mientras que los dems
casos de uso no. Al momento de disear la arquitectura, el arquitecto identifica elementos
(en este caso capas y componentes) que permiten soportar el driver. Una vez
identificados los elementos, se establecen los mensajes que deben intercambiar
instancias de los elementos para soportar el driver. En el ejemplo, el componente
ServicioCU1 tiene un mtodo procesa() que recibe dos parmetros p1 y p2 y regresa un
valor de retorno retA mientras que el componente Persistencia tiene un mtodo
almacena() que recibe un parmetro p3 y regresa un valor de retorno retB. En este caso,
el mtodo procesa() forma parte de la interfaz del componente ServicioCU1 mientras que
almacena() forma parte de la interfaz del componente Persistencia. Cabe sealar que en
general una interfaz tiene varios mtodos, a diferencia de este ejemplo simple.
El arquitecto no identifica todos los elementos y sus interfaces, solo lo hace para aquellos
que soportan los drivers. Sin embargo, estas decisiones establecen un marco de
referencia que permite a los desarrolladores identificar los elementos e interfaces para
requerimientos que no son drivers. Considerando el ejemplo previo, se deberan identificar
componentes para soportar los dems casos de uso as como sus interfaces.

Permiten realizar la integracin del sistema

En general un sistema es desarrollado de forma paralela por un equipo de desarrolladores
que se encargan de construir partes individuales que posteriormente sern conectadas. Si
el contrato entre las partes est bien definido desde el principio, se reducen los problemas
relacionados con la integracin. Retomando el ejemplo de la figura 1, supongamos que
los componentes ServicioCU1 y Persistencia son desarrollados por distintas personas. Si
previo al desarrollo de estos componentes se estableci que el componente Persistencia

tiene una interfaz con un mtodo retB almacena(p3), el desarrollador de ServicioCU1

tiene claro cmo interactuar con el componente Persistencia y la integracin normalmente
se hace sin dificultades. De lo contrario, es posible que la integracin se retrase por
correcciones necesarias para permitir que los componentes puedan interactuar.

Especificaciones para el diseo detallados de los mdulos

La interfaz de un componente sirve tambin como especificacin para realizar su diseo
detallado y construccin. Consideremos el ejemplo anterior en el cual la interfaz del
componente ServicioCU1 tiene un mtodo retA procesa(p1,p2). El desarrollador puede
disear y codificar el componente de diversas formas, siempre y cuando su diseo e
implementacin satisfagan el contrato establecido por la interfaz que, en este caso, es
que el componente provea el mtodo procesa().

Pruebas unitarias y de integracin

Al desarrollar un sistema es necesario probar sus partes de forma individual, esto es lo
que se conoce como prueba unitaria. La manera tpica de hacerlo es probando el
elemento a travs de su interfaz, pues se asume que si un componente satisface el
contrato que establece la interfaz entonces funciona correctamente. Retomando el
ejemplo de la figura 1, si se quiere probar el componente Persistencia , habra que invocar
el mtodo almacena() y corroborar si el valor de retorno ret2 es lo que se espera en base
al valor del parmetro p3.
Por otro lado, las interfaces permiten realizar prueba unitaria de elementos que dependen
de otros al soportar la sustitucin de elementos de los que se depende. Por ejemplo, si se
quiere probar el componente ServicioCU1 del ejemplo anterior, no es necesario que se
disponga del componente Persistencia. Basta con crear una implementacin de la interfaz
que debe implementar el componente Persistencia y que regrese los valores esperados.
Esto es lo que se conoce como un mock (sustituto). Cabe sealar que para lograr esto
es necesario hacer uso de alguna primitiva del lenguaje que permita especificar interfaces
de forma independiente de su implementacin.
Finalmente, las pruebas de integracin, como su nombre lo indica, se enfocan en probar
que los elementos se conectan de forma adecuada y para ello juegan un papel
fundamental las interfaces y su correcta definicin.

Conexin con sistemas externos

Es cada vez ms comn que los sistemas de software no sean entidades que trabajan de
forma individual. En la actualidad, un sistema de software frecuentemente hace uso de
funcionalidades provistas por otros sistemas, o bien proporciona funcionalidades para que
sean usadas por otro sistema.
Para permitir la interaccin entre sistemas, es necesario establecer interfaces que
establezcan un contrato sobre la manera en que se intercambia la informacin. Es comn
hoy en da que esas interfaces se describan usando un lenguaje tal como WSDL (Web

Services Description Language), si la comunicacin entre sistemas se realiza mediante

servicios web.

Interfaz de Programacin de Aplicaciones (API)

Las interfaces de programacin de aplicaciones (API) generalmente estn relacionadas
con libreras o frameworks (ver SG38). En lenguajes de desarrollo orientado a objetos
tales como Java, existe una API asociada con el lenguaje que proporciona una gran
cantidad de clases para propsitos diversos, como pueden ser el manejo de estructuras
de datos. En este caso, el API se usa creando instancias de las clases que son parte del
API, o bien, heredando y extendiendo a las mismas.
A continuacin se describen algunos aspectos de importancia que se deben considerar en
relacin con las interfaces.
Alta cohesin y bajo acoplamiento. Este es el principio fundamental del diseo de
interfaces. La alta cohesin se refiere a que cada componente haga una sola cosa,
mientras que el bajo acoplamiento busca que al modificar un elemento el cambio no se
propague hacia otros elementos. El bajo acoplamiento se logra encapsulando detalles de
implementacin. Esto significa que la interfaz de un elemento no debe exponer detalles
internos del mismo, tales como las estructuras de datos en las cuales se almacena el
estado, ya que estos detalles deben poder cambiarse sin necesidad de que esto afecte a
los clientes de la interfaz. Por lo anterior, la interfaz de un elemento se debe disear de
forma cuidadosa para no exponer detalles de implementacin, ya que el tener interfaces
no garantiza el bajo acoplamiento.
Programacin defensiva. Cuando una interfaz es expuesta para que sea usada por un
sistema externo o para que se construya un programa haciendo uso de ella, es necesario
tomar precauciones adicionales en relacin con los valores de entrada de los mtodos de
la interfaz. Lo anterior es parte de lo que se conoce como programacin defensiva e
implica, entre otras cosas, validar todas las entradas y considerar posibles situaciones
inesperadas. En las interfaces internas, es posible relajar un poco este aspecto si se tiene
seguridad de que no se recibirn valores que podran causar problemas.
Aspectos de calidad de servicio. En algunos casos, adems de la firma de la interfaz
que est compuesta por elementos sintcticos (nombre de mtodos, tipo de parmetros y
valores de retorno), es necesario especificar como parte de la interfaz aspectos
relacionados con la calidad de servicio. Un ejemplo de ello sera que la ejecucin de un
mtodo tiene que completarse en un tiempo establecido.

Conclusin
Las interfaces tanto internas como externas juegan un papel fundamental en el desarrollo
de un sistema de software. La definicin de las interfaces est intrnsecamente
relacionada con el diseo de la arquitectura, y una definicin deficiente de las interfaces
tiene muchas repercusiones negativas en el desarrollo del sistema. El no definir las
interfaces de forma oportuna impacta negativamente en la integracin del proyecto y en la

realizacin de pruebas del mismo, lo cual tiene repercusiones en el tiempo de desarrollo y

la calidad del sistema.
Por todo lo anterior, es necesario poner especial cuidado de identificar y definir
correctamente las interfaces entre los elementos del sistema.

Diseo Web vs Arquitectura de Sitios Web

Mara Teresa Bascun - Martes, Septiembre 22, 2015

Cuando requerimos del desarrollo de un sitio web nuevo o actualizar el que

tenemos habitualmente pensamos en el Diseo Web., sin embargo, ste es
slo una parte de laArquitectura Web. A veces los sitios se enfocan
demasiado en el aspecto visual, sin poner nfasis en cmo est organizada la
informacin que presentan. Es importante destacar que el desempeo depende
directamente de la arquitectura de un sitio o de una pgina web, es
decir, de cmo estn estructurados la navegacin y el contenido, entre otros.
Qu es la arquitectura de sitios web?
La arquitectura web define una tarea que requiere conocimientos tcnicos de
construccin, funcionales y de diseo para sitios o pginas web. Al igual que en la
arquitectura tradicional, actualmente el foco para el diseo y construccin de
pginas web se centra en el usuario y sus requerimientos.
La arquitectura web debe garantizar que el sitio web sea simple, altamente
funcional, amigable con mviles, que el usuario encuentre rpidamente lo que est
buscando, con un diseo que sea un reflejo de su marca, que se cumpla el
objetivo de negocio para el cual fue desarrollado el sitio, etc.

Qu es el diseo web?
Se refiere a la creacin del diseo visual de un sitio web, que debe generar una
interfaz efectiva con un aspecto limpio y visualmente atractivo para la arquitectura
del sitio. Como ya mencionamos, el diseo web es uno de los elementos de la
Arquitectura de un sitio web.
Principales agentes en el desarrollo de un sitio web:

Programador
Es quien genera los cdigos y hace que el sitio funcione.
Frecuentemente tiene experiencia en sistemas.
Diseador de sitios web
Es quien crea el diseo visual del sitio web (logo, botones,
banners, tipografa, etc).
Creador de contenido (copywriter)
Es la persona que crea el texto que va en las pginas.
Arquitecto Web
Aplica perspectiva de negocio al desarrollo del sitio. Aporta
la disciplina de negocio a diseadores y programadores.

Proceso de Arquitectura Web

La arquitectura de su sitio tiene relacin con la estructura del mismo y con cmo
las pginas se conectan entre s. Cuanto ms fcil sea para los visitantes
encontrar su contenido, ms tiempo van a pasar dentro de su pgina y lo ms
probable es que lleven a cabo alguna accin. Completar un formulario de contacto,
buscar informacin de un producto/servicio especfico, hacer una compra o hacer
clic en un botn de redes sociales son todas acciones realizadas por visitantes
felices. Debemos evitar visitantes confundidos, perdidos o frustrados que tienen
ms posibilidades de salir rpidamente de su pgina que de seguir navegando en
ella.
Algunos de los pasos necesarios en el proceso de arquitectura web son los
siguientes:

Identificar la audiencia(s) objetivo

Desarrollar enunciados de posicionamiento para cada audiencia
Desarrollar flujo de navegacin en el Home Page y arquitectura de
informacin
Creacin del mapa del sitio
Creacin de wireframes detallados para cada pgina del sitio
Desarrollar el diseo web del Home Page y de cada pgina interior
Desarrollar el contenido
Creacin del sitio mismo
Codificar, indexar, definir el hosting ms apropiado, etc

En conclusin, los principios utilizados para construir un edificio no son muy

distintos de los que se presentan en el proceso de desarrollar un sitio web. Los
sitios deben ser diseados en base a las necesidades de las personas que van a
utilizarlos, de la misma forma que los edificios deben ser diseados en relacin a
las necesidades de sus ocupantes.
En los edificios las manillas de las puertas estn a una altura especfica para que
las manos puedan alcanzarlas. En los sitios web los mens de navegacin no
tendran que ser diferentes deberan estar donde las personas los necesitan.
En el diseo de sitios web al igual que en el diseo de edificios, se requiere un
firme conocimiento de las tecnologas aplicadas. En el diseo de edificios estos
conocimientos son sobre las propiedades estructurales de los materiales,
electricidad, mecnica, plomera, etc en el desarrollo web se requieren de
conocimientos de lenguajes programacin y estructura de bases de datos, el
protocolo TCP/IP, el lenguaje HTML y muchos otros.
Finalmente, el trabajo que coordina el Arquitecto Web con programadores,
diseadores web y creadores de contenidos, lograr que la gente pueda usar su
sitio web y que cumpla el propsito de negocio para el cual fue construdo.