UNIVERSIDAD TCNICA ESTATAL DE QUEVEDO

FACULTAD CIENCIAS DE LA INGENIERA

CARRERA INGENIERA EN SISTEMAS
MDULO IV

UNIDAD DE APRENDIZAJE
PROGRAMACIN WEB

TEMA:
FUNDAMENTOS DE ARQUITECTURA DE APLICACIONES Y ESTILOS
ARQUITECTURALES

INTEGRANTES:
STEVEN HURTADO BECERRA
EDISON VICENTE ILLESCAS
RANDY RODRGUEZ PADILLA
RONALD HURTADO ZAMBRANO

DOCENTE
ING. GLEISTON GUERRERO
 FUNDAMENTOS DE ARQUITECTURA DE APLICACIONES

En el diseo de la arquitectura de un sistema es un proceso que consta en definir la solucin parar

los requisitos tcnicos y operacionales del sistema. Bsicamente se define los componentes que
formaran el sistema, la relacin que abra entre ellos, y como se dar la iteracin para lograr la
funcionalidad. En el diseo se trata los diferentes temas que nos ayudarn a tener xito en nuestro
sistema o evitar el fracaso [1]. Al respecto surgen algunas preguntas que se tendr que hacer:

En qu entorno va a ser desplegado nuestro sistema?

Cmo va a ser nuestro sistema puesto en produccin?
Cmo van a utilizar los usuarios nuestro sistema?
Qu otros requisitos debe cumplir el sistema? (seguridad, rendimiento, configuracin,
concurrencia)
Qu cambios en la arquitectura pueden impactar al sistema ahora o una vez desplegado?

Se debe tomar en cuenta a los usuarios del sistema, el propio sistema y cules son los objetivos del
negocio, pues ellos imponen ciertos requisitos y restricciones que deben ser tomadas en cuenta en el
proceso de diseo de la arquitectura debe ser un compromiso basndose en el inters de cada
participante [1].

Lo que ms importa para los usuarios es que el sistema responda de forma fluida y para el negocio
el coste sea poco. El arquitecto tiene como trabajo delinear los escenarios y requisitos de calidad,
puntos clave que se deben cumplir adems de las acciones o situaciones que no deberan ocurrir. La
arquitectura debe soportar los cambios a futuro que se presenten, por ende es responsabilidad del
arquitecto tomar medidas ante el anlisis de sus decisiones de diseo, compromisos para satisfacer a
los usuarios, al sistema y los objetivos del negocio [1].

Lo que la arquitectura debera hacer es lo siguiente:

Mostrar la estructura del sistema ocultando los detalles

Satisfacer el inters de los agentes, al igual que ocuparse los requisitos funcionales y de
calidad.
Determinar el tipo de sistema a desarrollar junto a los estilos arquitecturales que sern
usados [1].

Para el diseo de la arquitectura primeramente se debe decidir el tipo de sistema o aplicacin que se
va a construir, los principales son aplicaciones mviles, aplicaciones web, de escritorio, servicio,
RIAs. La seleccin del tipo de aplicacin determina de cierta manera el tipo de estilo arquitectural a
utilizar, los principales estilo son Cliente-Servidor, Arquitectura en Capas, Sistema de componentes,
N-Niveles, SOA. Para una aplicacin que ofrece servicios puede considerase este ltimo estilo
arquitectural [1].

Se tiene que tener claro que una aplicacin puede responder a ms de una arquitectura ejemplo de
esto es una pgina web hecha con ASP.NET MVC con estilo Cliente/Servidor pero tambin sigue
una estilo Modelo Vista Controlador. Una vez seleccionado los estilos con los que se ajustan el
sistema que se va a crear lo que sigue es decidir cmo se van a construir los bloques que
conformaran el sistema, esto mediante el uso de distintas tecnologas y estas estn limitadas por las
restricciones de despliegue y las que son impuestas por el cliente [1].

La implementacin de requisitos de calidad hace referencia a las propiedades no funcionales que

debe tener el sistema, como la seguridad, usabilidad, persistencia, manteniabilidad, etc. Para
conseguir eso se deber implementar funcionalidad extra, ortogonal a la funcionalidad bsica del
sistema. Para que estos requisitos sean implementados debemos hacernos la pregunta Qu
requisitos de calidad requiere el sistema? Analizando los casos de uso, luego de que se conozca los
requisitos de calidad para nuestro sistema surgen otras preguntas Cmo consigo que mi sistema
cumpla estos requisitos? Qu criterios indican que mi sistema cumple dichos requisitos? [1].

Los requisitos nos obligaran a tomar ciertas decisiones sobre nuestro sistema por ejemplo
refirindose a la seguridad, se tendr que decidir cmo va hacer la autenticacin de los usuarios, la
autorizacin entre las distintas capas del sistema adems la comunicacin, instrumentacin o
chequeo de datos, excepciones [1].

De acuerdo a los cambios que se presenten al futuro del sistema no hay que formalizar todo al
disear la arquitectura del sistema, no asumir nada que no pueda ser comprobado y dejar la opcin
de poderlo realizar a futuro [1]. Algunas claves que nos servirn son:

o Construir hasta el cambio ms que hasta el final.

o Utilizar herramientas de modelado para analizar y reducir riesgos.
o Utilizar modelos visuales como herramientas de comunicacin.
o Identificar las decisiones clave a tomar.

Al crear la arquitectura del sistema de forma iterativa e incremental, surgen las siguientes preguntas
a responder:

Qu partes de la arquitectura son ms susceptibles de cambiar?

Qu partes clave de la arquitectura representan el mayor riesgo si las diseo mal?
Qu partes de la arquitectura puedo dejar para el final sin que ello impacte en el desarrollo
del sistema?
Cules son las principales suposiciones que hago sobre la arquitectura y como las verifico?
 Qu condiciones pueden provocar que tenga que cambiar el diseo?

La arquitectura se ira definiendo poco a poco esto se podra entender como un proceso de
maduracin, como el de un ser vivo. Se tendr una arquitectura como lnea base y que ser
considerada como una visin del sistema en el momento actual del proceso. Seguido de la lnea
base se tendrn otras arquitecturas que sern consideradas como candidatas que sern el siguiente
paso en la maduracin de la arquitectura. Pues estas arquitecturas candidatas incluyen un tipo de
aplicacin, arquitectura de despliegue, tecnologas seleccionadas, estilo arquitectural, requisitos de
calidad y las decisiones transversales [1]. Estas arquitecturas candidatas deben responder las
siguientes preguntas:

Qu suposiciones he realizado en esta arquitectura?

Qu suposiciones he realizado en esta arquitectura?
Cules son los riesgos tomados con la evolucin de la arquitectura?
Qu medidas puedo tomar para mitigar esos riesgos?
En qu mediad esta arquitectura es una mejora sobre la lnea base o las otras arquitecturas
candidatas?

Debido a que se utiliza una metodologa iterativa e incremental para el desarrollo de la arquitectura,
pues se debe seguir con el mismo patrn para la implementacin y eso se puede realizar haciendo
pruebas arquitecturales que servirn para moderar riesgos rpidamente o probar la maduracin de la
arquitectura. La arquitectura candidata se evala contra la lnea base, pues si resulta mejor se
convierte en la nueva line base en la cual crear y evaluar las nuevas arquitecturas candidatas [1].
Las nuevas arquitecturas candidatas que surgen de la prueba, se les haces las siguientes preguntas:

Soluciona algn riesgo conocido esta arquitectura?

Introduce nuevos riesgos?
Cumple con nuevos requisitos del sistema?
Se encarga de implementar algn requisito de calidad?
Realiza casos de uso arquitecturalmente significativos?
Se encarga de implementar alguna parte del sistema transversal?

El proceso de diseo de la arquitectura se tiene que decidir cul es la funcin ms importante a

desarrollar, adems el tipo de aplicacin y estilo arquitectural, decisiones sobre la seguridad,
rendimiento que de alguna otra forma afecta al sistema. En el diseo de la arquitectura se decide
cules son los componentes bsicos y cmo ser la relacin para la funcionalidad. Esto se hace paso
a poso con todo lo que se puede comprobar y dejar abierto lo que no [1].

ESTILOS ARQUITECTURALES
Los estilos arquitecturales consisten en una herramienta bsica para el arquitecto para dar forma a la
aplicacin que se desean realizar, bsicamente un estilo arquitectural se lo define como conjunto de
componentes, conexiones entre los componentes, restricciones en la comunicacin de los
componentes que se encuentran conectados [1].

Para una arquitectura no se debe basar en un estilo si no la participacin de ms estilos para sacarles
ventaja, no se debe olvidar que estos estilos arquitecturales dan una forma abstracta de como dividir
el sistema en partes y cmo interactan entre ellas. Generalmente los estilos arquitecturales son
descripciones abstractas y no estn sujetas a ningn paradigma de programacin. A continuacin se
presentan los principales estilos arquitecturales juntamente con sus caractersticas principales [1].

1. ESTILO ARQUITECTURAL CLIENTE/SERVIDOR

Especifica la relacin de dos aplicaciones: Cliente (tiene peticiones), Servidor (respuestas) [1].

Los clientes realizan solicitudes de un servicio especfico donde debe recibir una respuesta a su
solicitud, el servidor la recoge y desarrolla la solicitud donde da la respuesta que es requerida [2].

Dentro de lo funcional se lo puede definir en su estructura como una arquitectura distribuida la cual
nos ayuda a los distintos usuarios poder acceder a la informacin de forma precisa y sin
contratiempo en todos los entornos por ejemplo multiplataforma [3].

CARACTERISTICAS
Su estilo de trabajo se puede dar en sistema distribuido.
Comunica la informacin utilizando distintos protocolos y formatos.
Su relacin del cliente donde el realiza diferentes peticiones y el servidor que se
encarga de enviar respuestas [1].
Se mantiene centralizados los cdigos y datos del servidor donde ocasiona que el
mantenimiento de por si sea menos costoso donde la integridad de datos es de
manera compartida.
Contiene procesos acoplados que ayudan a cambiar las solicitudes de los servicios
con las respuestas utilizando los mensajes [2].

BENEFICIOS
Seguridad al almacenar en el servidor los datos dndole ms control.
Los datos en el servidor son mejores para sus actualizaciones y accesos.
Su mantenimiento es de mejor manera al tener servidores con distintas
responsabilidades.
Soporta diferentes dispositivos y clientes [1].
 2. ESTIL
O

ARQUITECTURAL
BASADO EN COMPONENTES

Describe una
aproximacin a los
diseos de los sistemas
de componentes que pueden exponer
de diferente
manera interfaces de maneras definidas en su totalidad donde ayudan entre s para
darle solucin al problema [1].

Prevalece en una rama de la ingeniera en software donde se encuentra las descomposiciones del
diferente software para componentes funcionales [4].

CARACTERISTICAS
Mediante componentes individuales puede disear aplicaciones.
Contiene interfaces en los componentes en la descomposicin de los sistemas.
Pueden comunicarse por mtodos, eventos y propiedades.
Estos pueden ser reutilizados en distintas aplicaciones.
Cada componente es independiente a otro componente [1].
BENEFICIOS
Se puede cambiar un componente por una actualizacin sin modificar los diferentes
componentes que contiene el sistema.
Los costos para el mantenimiento y desarrollo son bajos en donde se pueden
utilizar los componentes.
Su utilizacin se la puede realizar en diferentes aplicaciones y sistemas por ser
independientes.
Iniciar la aplicacin con ningn dato de entrada o simplemente pocos de ellos [1].
 3. ESTILO

ARQUITECTURAL EN CAPAS (N-LAYER)

Se encarga en la distribucin de manera jerrquica de todas las responsabilidades y los roles que
dan la divisin eficaz para los problemas que se deben solucionar [1].

Es arquitectnico que fcilmente es utilizada para aplicaciones de manera empresariales, dentro de

su esquema sus capas altas tienen definidos sus servicios por capas ms bajas [5].

CARACTERISTICAS
En su gran mayora las interacciones se da entre capas vecinas.
Pueden estar en una misma mquina la misma capa de las aplicaciones o darse el
caso de estar en distintos equipos.
Los diferentes niveles pueden agregar las responsabilidades de los niveles que se
encuentran al inferior.
Se visualiza la vista de manera completa de los modelos donde pueden
proporcionar detalles con las relaciones de las capas [1].
 BENEFICIOS
Poder realizar actualizaciones dentro de las capas sin que el sistema tenga alguna
alteracin.
Poder mejorar en gran magnitud la estabilidad y rendimiento en las capas en sus
niveles fsicos.
Las capas ya construidas se pueden reutilizar o agregarse.
La lgica de negocio mediante los servicios que exponen las aplicaciones [1].

4. ESTILO

ARQUITECTURAL PRESENTACIN DESACOPLADA

El estilo de presentacin desacoplada o tambin conocido como presentacin separada indica cmo
debe realizar el manejo de las acciones de usurario, la manipulacin de la interfaz y los datos de la
aplicacin. Este estilo separe estos componentes al cual tambin reciben el nombre de vista, model
y controlador [1].

CARACTERSTICAS
Como su propio nombre lo indica se basa en la presentaciones separada, es decir sus
diseos son muy conocidos pero adems separa la vista de interfaz, la lgica de
presentacin y la lgica de negocio.
Permite un trabaja armnico entre el diseador y desarrollador debido a la separacin
entre la lgica de negocios y la interfaz, es por ello que permite a los diseadores crear
interfaces grficas, mientras que a los desarrolladores les permite escribir cdigo para
 su funcionamiento. Este estilo se recomendara principalmente para proyectos web en
donde lo principal es un buen diseo.
Los comportamientos individuales del usuario mejoran el soporte [1].

BENEFICIOS

Los beneficios de utilizar el estilo de presentacin desacoplada son bsicamente dos:

Testeabilidad: Debido la implementacin individual de clases que pueden ser testeadas

y futuramente remplazados.
Reusabilidad: Debido a los controladores pueden ser utilizados en otras partes, adems
de ello este estilo se basa en patrones de diseo conocidos [1].

5. ESTILO ARQUITECTURAL N-
NIVELES (N- TIER)

El estilo arquitectural de N-Niveles es muy parecido al estilo arquitectural en Capas (N-Layer), con
su diferencia que se sita cada pieza en mquinas distinta. Esto son los niveles fsicos, separando la
funcionalidad en niveles fsicos, como se muestra en la siguiente ilustracin [1].

CARACTERSTICAS
El estilo arquitectural N-Niveles, tiene como principal caracterstica la separacin de
niveles fsicos diferencindolo con el estilo popular N-Capas, el cual tiene similitudes
pero no son iguales. Cuando hablamos una separacin fsica nos referimos a que cada
nivel o segmento se encuentran en mquinas diferentes.
La separacin fsica permite mayor seguridad y estabilidad para muestro sistema a
desarrollar [1].

BENEFICIOS
 Los beneficios de utilizar este estilo son bsicamente tres:

Mantenibilidad: Debido a que los niveles estn separados de uno a otros, los cambios
que realizamos a uno de ellos, no afectara a los dems.
Escalabilidad: Los niveles se basan en despliegue de capas permitiendo la habilidad
para reaccionar y adaptarse sin perder calidad. Esta es una propiedad deseable de un
sistema.
Disponibilidad: Al existir niveles significa que es tolerante a los fallos, puesto que falle
un nivel no significa el fallo total del sistema. Muchas aplicaciones web cuentan con
respaldos en casos de fallos del sistema [1].

6. ESTILO

ARQUITECTURAL ORIENTADA AL DOMINIO (DDD)

El estilo de arquitectura orientada al dominio es un enfoque para desarrollar software complejos

donde es fundamental definir un modelo de dominio del negocio, sus elementos y componentes
relacionados entre ellos. Adems identificar los patrones de diseo de la arquitectura en concreto.
DDD proporciona una estructura de prcticas y terminologa para tomar decisiones de diseo que
se concentran y aceleran los proyectos de software referidas a los dominios complicados. [6]

CARACTERSTICAS
El estilo arquitectural Arquitectura orientada al dominio (DDD), tiene como
principal caracterstica la utilizacin del Lenguaje Ubicuo es decir un lenguaje
comn entre los programadores y expertos de dominio, permitiendo al programador
estar involucrado en las discusiones sobre el modelo.
 Este estilo se basa principalmente en las partes que involucran las reglas de
negocio, por ende involucra a los expertos de dominio.
Enfoque principal a la lgica de dominio [1].

BENEFICIOS

Los beneficios de utilizar este estilo son bsicamente tres:

Comunicacin: Este estilo se basa en la utilizacin del lenguaje ubicuo por ende la
comunicacin es su principal beneficio, permitiendo que todas las partes del equipo
puedan intervenir en todo el proceso que comprende el desarrollo del sistema [1].
Extensibilidad: Este beneficio se refiriere a que el sistema que realicemos utilizando
este estilo, ser ms fcil la evolucin para futuras versiones de la aplicacin;
adaptndose a las nuevas tecnologas [1].
Mejor Testing: Las pruebas de software ser ms fciles de pasar, debido a que el
diseo es a desacoplar los objetos. Esto significa mejor control de calidad para el
sistema [1].
 7. ESTILO ARQUITECTURAL ORIENTADO A OBJETOS

Este estilo es el que define al sistema como un conjunto objetos que sirven de soporte entre si en
lugar de utilizar un conjunto de procedimientos. Estos objetos discretos, independientes y poco
acoplados y se comunican mediante interfaces para permitirse enva y recibir mensajes [1].

CARACTERSTICAS
Este es un estilo para el diseo de aplicaciones basado en un nmero de unidades
lgicas y cdigo reusable.
Se encarga de describir el uso de objetos que contiene los datos tanto su
comportamiento para el uso de los mismos y la asignacin de roles.
Se hace necesaria la reutilizacin para la encapsulacin, la modularidad, el
polimorfismo y la herencia.
Crea una secuencia predefinida de tareas y acciones [1].

BENEFICIOS

Permite la comprensin ya que el diseo orientado a objetos define una serie de objetos del mundo
real. Testeabilidad gracias a la encapsulacin de objetos aparte que gracias a la encapsulacin el
polimorfismo y la abstraccin [1].

8. ESTILO ARQUITECTURAL ORIENTADO A SERVICIOS

El estilo orientado a servicios permite la funcionalidad como un conjunto de servicios para ser
consumidos los mismos que usan interfaces estndares las cuales pueden ser invocadas, publicadas
y descubiertas [1].

CARACTERSTICAS
La interaccin con el servicio es muy desacoplada.
 Se puede realizar la empaquetacion de procesos de negocios como servicios.
Los clientes y otros servicios tienen la facilidad de acceder a servicios remotos a travs
de la red [1].

BENEFICIOS
La reduccin de costes por medio de la reutilizacin de servicios comunes con interfaz
estndar.
Al ser autnomos se puede acceder a travs de un contrato formal.
Tienes acceso a servicios adecuados o puedes comprarlos a una empresa [1].

9. ESTILO ARQUITECTURAL BUS DE SERVICIOS

Define un sistema software que puede enviar y recibir mensajes usando uno o ms canales de tal
manera que las aplicaciones pueden interactuar sin conocer detalles la una de la otra [1].

CARACTERSTICAS
Este es un estilo para disear aplicaciones donde su interaccin se realiza por medio de
mensajes a travs de un canal de comunicacin comn.
Las comunicaciones entre estas (aplicaciones) se hacen de manera asncronas.
Si utilizas MSMQ debes implementarlo [1].

BENEFICIOS
La expansin es una de ellas ya que puedes aadir o eliminar del bus sin afectar a las
dems aplicaciones.
La reduccin de la complejidad ya que la aplicacin solo necesita conocer cmo
comunicarse con el bus.
 Al no haber intermediarios entre aplicaciones mejora su rendimiento
Las aplicaciones se pueden asociar al bus para atender varias peticiones al mismo
tiempo [1].
 BIBLIOGRAFA

[1] U. Z. C. M. A. R. B. J. C. N. Csar de la Torre Llorente, Gua de Arquitectura N-Capas

orientada al Dominio con .NET 4.0, Espaa: Krasis Press, 2010.

[2] F. Diaz, EL MODELO CLIENTE/SERVIDOR, Espaa.

[3] L. Marquez, Cliente-Servidor.

[4] J. A. S. Gil, Arquitectura basada en componentes.

[5] LINS, Aplicaciones Empresariales, Arquitectura de Software y Web Services, Uruguay, 2012.

[6] E. Evans, DDD Community, 28 03 2007. [En lnea]. Available:

http://dddcommunity.org/learning-ddd/what_is_ddd/. [ltimo acceso: 16 10 2016].