Arquitecturas Orientadas A Servicios.docx

ARQUITECTURA DE SOFTWARE – ENTREGA 3

ARQUITECTURAS ORIENTADAS A SERVICIOS

Tabla de contenido Introducción

2

Objetivo General

2

Objetivos Específicos

2

Justificación económica

3

Justificación Operativa

3

Justificación Investigativa

4

Glosario

4

Arquitectura de software

5

Cronograma de trabajo

8

Casos de uso

20

Objetivos del sistema

20

Requisitos de información

21

Documentación casos de uso control de acceso al sistema.

24

Conclusiones

36

Recomendaciones

39

Lista de referencias

40

Capítulo 1

ARQUITECTURA DE SOFTWARE – ENTREGA 3 INTRODUCCIÓN E INFORMACIÓN GENERAL Introducción Los patrones de diseño proveen soluciones comprobadas a problemas comunes ya que facilitan y mejoran los tiempos en un Proyecto de desarrollo de software. Es por esto, que autores como Gómez, M., Jiménez, G., Arroyo, J. (2009), hablan de los patrones de diseño como “un conocimiento que debería ser parte de la educación básica de los ingenieros y científicos de la computación”. Como parte de nuestra formación como ingenieros de software, se hace indispensable conocer las mejores prácticas que el mercado presenta en la actualidad pues se convertirán en un insumo valioso que a lo largo de nuestra vida profesional nos permitirá cosechar los frutos de su correcta utilización.

Objetivo General Diseñar e implementar una aplicación informática que permita automatizar la gestión administrativa y operativa del Hotel MolRodPin para brindar un servicio de calidad y eficiencia.

Objetivos Específicos Analizar los diferentes procesos administrativos y operativos actuales que posee el hotel, para facilitar el manejo de la información en la implementación de un programa. Diseñar una aplicación informática, basada con herramientas, interfaces visuales y de fácil comprensión, administración y manejo para los usuarios del sistema computarizado y personal del Hotel. Establecer los requerimientos informáticos en el uso del sistema, por medio de un manual de usuario que sirva como guía para el manejo de la plataforma web, capacitando a los usuarios que utilicen el sistema de gestión administrativa y operativa del Hotel. Desarrollar el código de programación con los requerimientos informáticos que necesita el sistema utilizando herramientas visuales, para producir una aplicación a medida de las necesidades del Hotel.

Evaluar el sistema en línea para verificar su uso y utilidad para las actividades administrativas

ARQUITECTURA DE SOFTWARE – ENTREGA 3 y operativas del Hotel.

Justificación Justificación económica Este trabajo permitirá la optimización de los recursos con los que cuenta actualmente el Hotel MolRodPin, además la inversión que se requiere para desarrollar e implementar no es una suma elevada que no pueda afrontar el flujo de la empresa, razón por la cual el desarrollo de este sistema se justifica plenamente desde el punto de vista económico.

Justificación Operativa La necesidad cada vez mayor de capacitación en el manejo de sistemas de gestión hotelera de última generación, dominio de idiomas y competencias necesarias para el desarrollo de roles propios de la actividad hotelera hacen cada vez más compleja y necesaria la implementación de sistemas de información. Cada vez se vuelve indispensable sistematizar las tareas cotidianas a fin de optimizar recursos tan valiosos como el tiempo y el talento humano. Las razones por las que la información se puede convertir en una ventaja competitiva para este sector, es que mejorará la toma de decisiones facilitando la comunicación directa con el cliente y por consiguiente, un acceso a un mercado más amplio que pueda solucionar en parte los problemas de estacionalidad e intermediación que lo caracterizan. Poder disponer de un sistema de gestión hotelera da como resultado: ● Optimización en la recogida de información. ● Esta información se tiene en tiempo real, lo que agiliza la toma de decisiones. ● Al tener esta información se hace posible mejorar la gestión del hotel a través del conocimiento del cliente, la gestión de disponibilidad económica y precios en función de la variación de la demanda y tarifas entre otros.

● Con el sistema de gestión hotelera implementado en el Hotel MolRodPin se busca

ARQUITECTURA DE SOFTWARE – ENTREGA 3 obtener ciertos beneficios como el mejoramiento de la rentabilidad y la productividad, partiendo principalmente de la satisfacción del cliente.

Justificación Investigativa Desarrollar esta aplicación para la industria hotelera es un gran desafío investigativo, ya que el resultado permitirá implementar una gran herramienta profesional y práctica, dando una solución a la gestión administrativa. Teniendo en cuenta estas razones y la tendencia del ámbito hotelero de hoy en día, se requiere la implementación de un software que se comporte como un “profesional de la hospitalidad” Tomando en consideración dichos postulados el desarrollo del sistema de gestión hotelera para el Hotel MolRodPin se justifica con sobrados motivos dentro del aspecto investigativo e innovador.

Glosario Book: El espacio (habitaciones) que el hotel posee a la venta Booking: Reservación confirmada Check in: Proceso de inscripción en un hotel o medio de transporte. Se realiza en recepción a la llegada del cliente donde se registran sus datos personales, se le asigna un número de habitación y se hace entrega de la llave Check out: Proceso de salida de un establecimiento hotelero con la correspondiente liquidación de la cuenta de gastos. Double: Habitación con dos camas o habitación con una cama Queen Size Full house: 100% de ocupación de un establecimiento hotelero Guest: Palabra inglesa aceptada en el vocabulario hotelero para significar huésped Master Account: Factura que se abre en caja para cargar los gastos de un grupo en especial. OK: cuando se hacer referencia que una reserva está confirmada On request: Se aplica a una reserva solicitada, pero pendiente de confirmación Rate: Tarifa de la habitación

ARQUITECTURA DEL SOFTWARE: Según Pressman la arquitectura de software no es

ARQUITECTURA DE SOFTWARE – ENTREGA 3 más que una descripción de los subsistemas y componentes y su relación entre ellos. PATRÓN: Es una solución reutilizable de problemas que se presentan durante el desarrollo del software. ROL DEL ARQUITECTO DE SOFTWARE: Para definir que es un arquitecto de software se debe tener en cuenta el escenario y contexto en particular, además depende de la organización, el negocio, sus objetivos, la importancia y tamaño del proyecto. PATRONES DE ARQUITECTURA: Los patrones de arquitectura expresan un esquema organizativo estructural fundamental para sistema de software.

Modelo: representa la información con la que trabaja la aplicación, o sea, su lógica de negocio. Vista: convierte el modelo en una página web que facilita al usuario interactuar con ella. Controlador: es el encargado de procesar las interacciones del usuario y ejecuta los cambios adecuados en el modelo o en la vista. La arquitectura MVC separa la lógica de negocio (el modelo) y la presentación (la vista), lo que permite un mantenimiento más sencillo de las

aplicaciones. El controlador es el encargado de aislar al modelo y a la vista de los detalles del protocolo usado para las peticiones (consola de comandos, email, etc.). El modelo se encarga de la abstracción de la lógica referida a los datos, lo que permite que la vista y las acciones sean independientes.

Capítulo 2

Situación Problemática Recurrente Arquitectura de software Se hace necesario que este aplicativo cumpla con ciertos requisitos no funcionales, los cuales son característicos de una aplicación web que hacen relación a su arquitectura, seguridad, uso de estándares, rendimiento, escalabilidad y la interfaz del usuario entre otros. 1. Esta aplicación debe permitir que se abra en cualquier tipo de navegador.

2. Los datos que se almacenen deben estar en una base de datos donde se puedan realizar

ARQUITECTURA DE SOFTWARE – ENTREGA 3 consultas. 3. Debe ser muy accesible a través de la interfaz del usuario. Seguridad 1. Se deben crear usuarios administradores de los datos de la aplicación (Administrador), así como usuarios para acceder a ella (Usuario registrado, Usuario invitado, Recepción). 2. El usuario invitado va a poder tener acceso a la aplicación (solamente consulta del calendario de reservas (sin datos) y registro), si realiza su registro podrá realizar todas las operaciones de un Usuario Registrado, el cual tendrá un menú que no incluye ningún tipo de administración de la aplicación. 3. Este usuario podrá realizar o cancelar una reserva, consumo de servicios (bebida, comida, teléfono, internet, etc.), generar su factura tanto de la habitación como del consumo. También podrá consultar y reservar habitaciones disponibles. 4. En recepción se puede hacer reservas de un cliente (sea usuario registrado o no) y solicitar servicios para este, inclusive puede generar su propia factura, como también realizar un registro de salida (check-out). 5. El único que puede tener acceso a todo será el administrador, un ingreso, una salida, una modificación, una consulta, etc., tanto de entidades y relaciones del modelo de la aplicación. Tiene también la potestad de cambiar absolutamente todos los parámetros de la aplicación (precios, disponibilidad de servicios, etc). Estándares 1. Debe ser la licencia del uso de este software lo menos restrictiva posible. 2. Esta aplicación deberá cumplir los estándares de www.consortium ( html 7.0 o superior, CSS 2.0, etc) 3. El lugar donde se aloje esta página debe cumplir con ciertas normas para aplicaciones web (WAI), las cuales son dadas por el www.consortium y como mínimo debe tener el nivel A,

Interfaz del usuario

1. Este sitio debe ser ordenado en su contenido y funciones, con una estructura definida

ARQUITECTURA DE SOFTWARE – ENTREGA 3 y clara que abarque todas las funcionalidades disponibles.

2. Este sitio debe permitir la visualización de cualquier contenido multimedia, bien sea texto, gráfico, vídeo, etc. 3. Para los formularios de ingreso se debe tener en cuenta los elementos de interacción asíncrona en la interfaz del cliente. Un ejemplo puede ser al momento de registrar los datos de un usuario, que se facilite una selección de valores conocidos (ciudad donde vive), realizando un filtrado automático de valores que se aplican de acuerdo a como los va digitando dicho usuario. 4. También contará con consultas a través de dispositivos móviles (obviamente reducida), sin que esto afecte el desarrollo de la aplicación o el que tenga que realizarse una nueva aplicación para este tipo de dispositivos, sino que la arquitectura de la aplicación debe estar preparada para esto. Rendimiento 1. De acuerdo a la disponibilidad de los recursos, tanto de hardware como de software, la base de datos debe disponer de muchas conexiones configurables para que la aplicación pueda ser escalable. 2. Para no tener problemas de sobre carga con el servidor, se limitarán las peticiones asíncronas que se realicen. 3. El tener múltiples peticiones de acceso a la base de datos, no deben afectar en lo más mínimo el estado de la aplicación. 4. Cada petición que se realicé a través de la red, no debe superar un tiempo máximo, el cual viene marcado por el tiempo que tarda en cargar el servlet controlador.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Cronograma de trabajo

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Capítulo 3

SOAP

SOAP llamado así al protocolo basado en XML el cual realiza un intercambio de información

ARQUITECTURA DE SOFTWARE – ENTREGA 3 entre computadores. Aunque SOAP es usado para una variedad de sistemas de envío y también ser emitido por una variedad de protocolos, lo principal de SOAP es la llamada a procedimientos de forma remota vía HTTP. Por tanto, SOAP permite aplicaciones clientes para una fácil conexión a servicios remotos y la invocación de métodos también remotos. SOAP es el protocolo de comunicaciones para los servicios Web XML. Al estar descrito como protocolo de comunicaciones, SOAP incluye aspectos como la invocación de objetos o un servicio de nombres, pero no los especifica.

SOAP también soporta aplicaciones de tipo documental en las que el mensaje es simplemente un envoltorio sobre un documento XML. Las aplicaciones SOAP de tipo documental son muy flexibles y muchos servicios Web XML nuevos aprovechan esta flexibilidad para construir servicios que serían difíciles de implementar utilizando RPC.

Estructura de un mensaje SOAP.

Los datos pueden ser transmitidos a través de HTTP, SMTP, etc. SOAP especifica el formato de los mensajes. El mensaje

ARQUITECTURA DE SOFTWARE – ENTREGA 3 SOAP está compuesto por un envelope (sobre), cuya estructura está formada por los siguientes elementos: header (cabecera) y body (cuerpo).

Hoy en día vemos casi todas las implementaciones SOAP soportan el enlace HTTP el cual es opcional, porque es el único protocolo estandarizado para SOAP. Por esta razón, existe la equivocada idea de que SOAP requiere HTTP, ya que algunas implementaciones soportan transportes MSMQ, MQ Series, SMTP o TCP/IP, pero casi todos los servicios Web XML actuales utilizan HTTP porque es ubicuo.

La Web utiliza como protocolo fundamental el HTTP, y la mayoría de las organizaciones ya tienen una infraestructura de red que lo soporta y también personal que ya sabe cómo manejarlo. Otro aspecto importante es la infraestructura de seguridad, monitorización y balance de carga para HTTP, pero vemos que ya está ampliamente disponible en la actualidad. Existen muchas plataformas de hardware y software, y una característica primordial y convincente es la implementación de SOAP. Lo que significa que SOAP se puede utilizar para enlazar sistemas diferentes dentro y fuera de una organización. Se realizaron muchos experimentos en el pasado para buscar un protocolo de comunicaciones común que pudiera utilizarse para la integración de sistemas, pero ninguno ha tenido la amplia adopción de SOAP, principalmente porque SOAP es mucho menor y simple de implementar que muchos de los protocolos anteriores.

Ventajas de SOAP -

Ningún lenguaje de programación está ligado con SOAP, ya que no especifica una API. Esto hace que los desarrolladores puedan elegir un lenguaje de programación como JAVA o .NET, por ejemplo.

-

No se describe como se deben asociar los mensajes con HTTP en la especificación de SOAP.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Al ser un mensaje SOAP un documento XML, este se transporta por cualquier protocolo que sea capaz de enviar texto. -

Existen estándares que él aprovecha, como, por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema. También es independiente al protocolo de transporte, por lo que un mensaje SOAP puede ser enviado tanto por el protocolo HTTP o SMTP, por ejemplo.

-

Las aplicaciones que se ejecutan en plataformas estándares compatibles con SOAP pueden comunicarse con mensajes SOAP en otras aplicaciones que se ejecuten en otras plataformas, es decir, permite la interoperabilidad entre múltiples entornos.

-

La simplicidad de SOAP y la ubicuidad de HTTP los convierten en una base ideal para implementar servicios Web XML que pueden consumirse desde prácticamente cualquier entorno.

El mensaje SOAP

El tener un mensaje unidireccional, como una petición de un cliente a un servidor, o una respuesta de este a su cliente es lo que denominamos SOAP. Absolutamente todos los mensajes SOAP constan de dos elementos (etiquetas XML) las cuales son obligatorias (envelope y body) y tiene uno opcional (header). Por último, debemos tener en cuenta que estos elementos se asocian a un conjunto de reglas.

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Elementos principales de un mensaje SOA

Envoltura: en el mensaje siempre se debe tener un elemento raíz que se llama envelope (envoltura), quien contiene a los elementos header, body y foult. Existe una gran diferencia con otras especificaciones (HTTP y XML), al no tener un modelo tradicional de versiones, por ejemplo, existe el HTTP 1.0 y el HTTP 1.1, SOAP lo que utiliza son espacios de nombre XML (namespaces) para hacer la diferencia de sus versiones y esta debe ser referenciada en el elemento envelope. Header (cabecera): este es un elemento opcional el cual va a ofrecer un marco de trabajo flexible, para adicionar una especificación de requerimientos al nivel de la aplicación. Un ejemplo que podemos utilizar es una firma digital para un servicio de contraseña protegida. Esto también permite administrar transacciones y autorizaciones de pago. Body (cuerpo): este elemento si es obligatorio para todos los mensajes SOAP ya que contiene propiamente el mensaje como tal, es el que almacena el documento XML, que el receptor final procesará. Fault: al momento de presentarse un error el elemento body va a incluir al elemento fault, quien es el que tiene la información de la naturaleza del error. Petición SOAP: para que exista un funcionamiento debe haber una petición del cliente el cual contenga el nombre del método y sus parámetros necesarios.

ARQUITECTURA DE SOFTWARE – ENTREGA 3

En este ejemplo, un usuario (cliente de los Servicios Web), a través de una aplicación, solicita información sobre un viaje que desea realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a través de Internet. La agencia de viajes ofrece al usuario la información requerida y para proporcionar lo que él necesita, esta a su vez debe solicitar otra información (Servicios Web), relacionados con el hotel y la línea aérea. Acá vemos que la agencia de viajes va a tener información de los recursos, lo que la convierte en cliente de estos Servicios Web, ya que tendrá la información solicitada (hotel y aerolínea). Por último, el usuario realizará su pago a través de la agencia de viajes, quien será el intermediario entre este y el Servicio Web, quien gestionará dicho pago.

SERVICIO WEB

Un servicio web muestra un conjunto de servicios los cuales son consumidos a través de la

ARQUITECTURA DE SOFTWARE – ENTREGA 3 red, lo que significa que especifica un conjunto de operación (funciones retornando un determinado valor), a través de una url, donde una aplicación cliente de manera remota lo puede consumir. Para nuestro caso, el servicio web cuenta con un buscador en donde el usuario (posible huésped), digita la ciudad en la que desea buscar su hotel. De manera automática se realiza esta búsqueda para ofrecer la disponibilidad hotelera de acuerdo con la ciudad seleccionada, teniendo en cuenta las prioridades del usuario. Apenas se realiza la elección, se va a redireccionar a la página web del hotel para que lleve a cabo la reserva.

Estos son los protocolos que poseen los servicios web para la aplicación del Proyecto: ● XML es capaz de hacer la organización y etiquetado de documentos. Cabe anotar que no es un lenguaje en sí mismo, sino un sistema que permite definir lenguajes de acuerdo con las necesidades. Las bases de datos, los documentos de texto, las hojas de cálculo y las páginas web son algunos de los campos de aplicación del XML. El metalenguaje aparece como un estándar que estructura el intercambio de información entre las diferentes plataformas. ● SOAP proporciona un mecanismo simple y ligero de intercambio de información entre dos puntos usando el lenguaje XML. No es más que un mecanismo sencillo de expresar la información mediante un modelo de empaquetado de datos modular y una serie de mecanismos de codificación de datos, lo que quiere decir que es un protocolo de comunicación basado en XML para intercambiar mensajes entre sistemas. En este caso SOAP capturará la información pública que arrojen las diferentes bases de datos de los Hoteles. ● WSDL es un documento XML que describe un conjunto de mensajes SOAP y cómo son enviados y recibidos. Este documento especifica, lo que debe contener tanto un mensaje de petición como un mensaje de respuesta. Cuando se expone un servicio web, se publica un archivo WSDL en el servidor web, y allí se muestran los parámetros, tipos de retorno, dirección para invocar el servicio, etc. También, es un formato estándar basado en XML para describir servicios web y mostrar cómo acceder a ellos. A través de este medio

permite enviar por un mensaje (la ubicación - municipios), ya que ofrece un método para

ARQUITECTURA DE SOFTWARE – ENTREGA 3 definir los servicios de la web y saber que hoteles se encuentran disponibles en estos, y este recibe un mensaje de la información de los hoteles que se encuentran en el municipio seleccionado, y el usuario puede escoger uno de acuerdo a sus necesidades bien sean económicas o personales. ● UDDI es un directorio donde se pueden localizar los Servicios Web, pero la información adicional que brindan los lenguajes descriptores como WSDL no es utilizada por UDDI, por eso se hace necesario crear una funcionalidad adicional que aproveche estos datos y los relacione con la información existente en el registro. Esto es lo que logra en el motor de búsqueda y se refleja en la cantidad y calidad de información que se obtiene de él, comparándolo con otro servicio y las funcionalidades de búsquedas ofrecidas para su registro.

HERRAMIENTAS DE DESARROLLO

HTML5 es una colección de estándares para el diseño y desarrollo de páginas web y representa la manera en que se muestra la información en el explorador de internet y de cómo se debe interactuar con ella. También nos permite una mayor interacción entre las páginas

web y su contenido media (video, audio, entre otros) así como una mayor facilidad a la hora de codificar nuestro diseño básico. En su momento Flash se usó en reemplazo de HTML para realizar desarrollos web apps: Audio, video, webcams, micrófonos, datos binarios, animaciones vectoriales, componentes de interfaz complejos, entre muchas otras cosas. Hoy en día HTML5 es capaz de hacer esto sin necesidad de plugins y con una gran compatibilidad entre navegadores. No es una nueva versión del lenguaje HTML sino una agrupación de diversas especificaciones concernientes al desarrollo web. Es decir, HTML 5 no se limita sólo a crear nuevas etiquetas, atributos y eliminar aquellas marcas que están en desuso o se utilizan inadecuadamente, sino que va mucho más allá.

TWITTER BOOTSTRAP es un conjunto de herramientas de software libre para diseño de

ARQUITECTURA DE SOFTWARE – ENTREGA 3 sitios y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como, extensiones de JavaScript opcionales adicionales. También permite crear interfaces web con CSS y JavaScript que adaptan la interfaz dependiendo del tamaño del dispositivo en el que se visualice de forma nativa, es decir, automáticamente se adapta al tamaño de un ordenador o de una Tablet sin que el usuario tenga que hacer nada, esto se denomina diseño adaptativo o ResponsiveDesign.

JQUERY es una biblioteca de JavaScript, que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. JQuery es software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la Licencia Pública General de GNU v2, permitiendo su uso en proyectos libres y privados. JQuery, al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas

en JavaScript que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio.

AJAX es el acrónimo de Asynchronous Javascriptand XML, es decir, Javascript y XML Asíncrono. es una técnica que permite la comunicación asíncrona entre un servidor y un navegador en formato XML mediante programas escritos en JavaScript y su principal objetivo es intercambiar información entre el servidor y el cliente (navegadores), sin necesidad de recargar la página.

Para comprender esta técnica, vamos a ver las tecnologías que la componen: ● JavaScript: Lenguaje de programación interpretado por los navegadores modernos. ● XML: Lenguaje de marcas utilizado para almacenar datos en forma legible. Se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas.

● Asíncrono: Tipo de comunicación entre procesos en que quien envía el mensaje continúa

ARQUITECTURA DE SOFTWARE – ENTREGA 3 con su ejecución sin esperar respuesta del receptor.

JSON este es un formato para intercambiar datos, los describe con una sintaxis dedicada el cual usa para identificar y gestionar los datos. JSON nació como una alternativa a XML, y su fácil uso en JavaScript generó un gran número de seguidores de esta alternativa. Su mayor ventaja es que puede ser leído por cualquier lenguaje de programación, lo que significa que puede ser usado para intercambiar información entre distintas tecnologías. Es una conformación ligera de intercambio de datos para interpretarlo y generarlo rápidamente haciendo que la información de la base de datos interactúe con mayor rapidez.

PHP es un lenguaje de código abierto propicio para desarrollo web y puede ser incrustado en HTML. Código abierto significa que es de uso libre y gratuito para todos los programadores que quieran usarlo. Incrustado en HTML significa que en un mismo archivo vamos a poder combinar código PHP con código HTML, siguiendo unas reglas. PHP se utiliza para generar páginas web dinámicas.

NUSOAP es un kit de herramientas (ToolKit) para desarrollar Web Services bajo el lenguaje PHP. Se compone de una serie de clases que hacen más fácil el desarrollo de Web Services. Provee soporte para el desarrollo de clientes (aquellos que consumen los Web Services) y de servidores (aquellos que los proveen).

SUBLIMETEXT editor de texto para escribir código en la mayoría de los lenguajes de programación y formatos documentales de texto, utilizados en la actualidad: Java, Python, Perl, HTML, JavaScript, CSS, HTML, XML, PHP, C, C++, etc. Permite escribir todo tipo de documentos de código en formato de texto y es capaz de colorear el código, ayudarnos a la escritura, corregir mientras escribimos, usar abreviaturas (snippets), ampliar sus posibilidades, personalizar hasta el último detalle, entre otras, casi cualquier cosa que le podamos pedir a un editor.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 XAMPP es un servidor independiente de plataforma, software libre, que consiste principalmente en la base de datos MySQL, el servidor web Apache y los intérpretes para lenguajes de script: PHP y Perl. El nombre proviene del acrónimo de X (para cualquiera de los diferentes sistemas operativos), Apache, MySQL, PHP, Perl. El programa está liberado bajo la licencia GNU y actúa como un servidor web libre, fácil de usar y capaz de interpretar páginas dinámicas.

DISEÑO DE CÓMO FUNCIONA INTERNAMENTE

El cliente busca un hotel en la UDDI (directorio donde podemos localizar los Servicios Web), y lo hace con todos los que se encuentren conectados con MolRodPin haciendo que busquen la información a hospedarse en estos hoteles de acuerdo con su ubicación. A partir de este, nos va a mostrar una lista de hoteles que se encuentran en el servicio por medio de la WSDL, el cual es un documento XML que describe un conjunto de mensajes SOAP y cómo los mensajes son enviados y recibidos, la WSDL ofrece un método para definir los servicios de la web y saber que hoteles se encuentran disponibles, y este recibe un mensaje de la información de los hoteles que se encuentran en la ciudad seleccionada para que el usuario o visitante puede escoger uno de acuerdo a su necesidad. Al momento de escoger un hotel el cliente envía una solicitud SOAP al servicio web, que no es más que un mecanismo sencillo de expresar la información mediante un modelo de empaquetado de datos modular y una serie de mecanismos de codificación de datos, por lo tanto, es un protocolo de comunicación basado en XML para intercambio de mensajes entre sistemas, esta solicitud pasa a las diferentes BASES DE DATOS las cuales son comunicadas con un receptor (WEB SERVICE), quien busca los hoteles de la ubicación escogida y una vez obtenida esta información manda una repuesta SOAP de los hoteles encontrados, este proceso es el que se utiliza como lenguaje de comunicación XML, para poderla interactuar el sistema en PHP y se recurrió a la librería NUSOAP que se adapta a este lenguaje para poder realizar este proceso. Con la referencia anterior se muestra gráficamente el sistema MolRodPin.

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Casos de uso Objetivos del sistema En esta parte se especifica una lista de los objetivos que el sistema MolRodPin espera alcanzar. OBJ-01

Control de Acceso al Sistema El sistema debe poder identificar al usuario administrador de MolRodPin.

Descripción

Existe un tipo de usuario que es, el administrador del hotel, pero este accede al sistema cuando MolRodPin le haya dado la autorización de acceder a su sistema. Es decir su dominio de la página, su usuario y contraseña.

Estabilidad

Alta

Comentarios

Se habilita un solo tipo de usuario: El administrador de MolRodPin. Y en caso de la página del Hotel el administrador del Hotel.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 OBJ-02

Gestión de Administración El sistema debe permitir ver toda la información de los usuarios

Descripción

registrados en el sistema al administrador además y poder manipular la información que estos dispongan. Para realizar esto, debe ingresar al sistema con su usuario y contraseña.

Estabilidad

Alta El administrador del MolRodPin, puede ver la información de todos los usuarios, también puede crear, actualizar, visualizar y

Comentarios

eliminar los hosting y la misma funciones para los servidores web. Además de modificar sus datos. En el caso de las páginas del hotel, podrán crear, actualizar, visualizar y eliminar las habitaciones, así como las reservaciones; adicionalmente actualizar la cuenta de usuario y la información del hotel.

OBJ-03

Gestión de Usuario

Descripción

El sistema debe permitir a un usuario normal acceder a las páginas de MolRodPin.

Estabilidad

Alta

Comentarios

En el Caso de MolRodPin el usuario podrá registrarse para adquirir sus servicios si desea registrarse en el hotel y validar la inscripción.

Requisitos de información A continuación se definirán los requisitos de información más relevantes a tener en cuenta que será acoplada en entorno web MolRodPin.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 RI-01

Información sobre Acceso al Sistema

Objetivos asociados

OBJ-01 Control de Acceso al Sistema

Requisitos asociados

RF-01 Acceso al Sistema Se necesita tener información correspondiente a los datos

Descripción

del administrador y el usuario que desea ingresar al sistema por medio de su usuario y contraseña. - Usuario.

Datos Específicos

- Contraseña.

Importancia

Alta

Comentarios

Esta función se cumple para la página de MolRodPin.

RI-02 Objetivos asociados

Información Administración MolRodPin OBJ-02Gestión de Administración RF-01Acceso al Sistema RF-02 Modificar Cuenta y Usuario RF-03 Crear Hosting RF-04 Consultar Hosting

Requisitos asociados

RF-05 Modificar Hosting RF-06 Eliminar Hosting RF-07 Consultar Servidor Web RF-08 Modificar Servidor Web RF-09 Validar Servidor Web Se debe tener información correspondiente a administrador

Descripción

que ingresa al sistema. - Usuario.

Datos Específicos

- Contraseña.

Importancia

Alta

Comentarios

Ninguno.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 RI-03 Objetivos asociados

Información Administración Hotel OBJ-02Gestión de Administración RF-01 Acceso al Sistema RF-02 Modificar Usuario y Cuenta RF-10 Modificar Información del Hotel RF-11Crear Habitación

Requisitos asociados

RF-12 Consultar Habitación RF-13 Modificar Habitación RF-14 Eliminar Habitación RF-15 Reserva Habitación RF-16 Eliminar Reserva Se debe tener información correspondiente a administrador

Descripción

que ingresa al sistema. - Usuario.

Datos Específicos

- Contraseña.

Importancia

Alta

Comentarios

Ninguno.

RI-04 Objetivos asociados

Información Usuario MolRodPin OBJ-03 Gestión de Usuario RF-17 Crear Cuenta Registro de Hotel

Requisitos asociados

RF-18 Completar y Validar Registro de Hotel RF-19 Buscar Reserva Hotel No se debe tener información correspondiente para ingresar

Descripción

al sistema.

Importancia

Alta

Comentarios

Ninguno.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 RI-05 Objetivos asociados

Información Usuario MolRodPin OBJ-03 Gestión de Usuario RF-17 Crear Cuenta Registro de Hotel

Requisitos asociados

RF-18 Completar y Validar Registro de Hotel RF-19 Buscar Reserva Hotel No se debe tener información correspondiente para ingresar

Descripción

al sistema.

Importancia

Alta

Comentarios

Ninguno.

Documentación casos de uso control de acceso al sistema. En la siguiente tabla se anexa la documentación del caso de uso relacionada con el acceso al sistema, esta función se acopla para la página web MolRodPin. RF-01

Acceso al Sistema

Objetivos asociados

OBJ-01 Control de Acceso al Sistema.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario intente ingresar al sistema.

Precondición

El usuario que desea ingresar debe estar previamente registrado en el sistema.

Secuencia Normal Paso 1

Acción El personal ingresa su cuenta de usuario y contraseña.

2

Click en botón Iniciar Sesión

3

El sistema verifica caracteres en blanco y tamaño de caracteres.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 4

El sistema verifica existencia del usuario en la base de datos.

5

Se identifica al usuario, sí está en la base de datos.

6

El usuario Ingresa al sistema.

Luego de entrar al sistema el usuario puede realizar sus Pos condición

actividades.

Excepciones

PASO 1

ACCION El usuario ingresa caracteres inválidos en los campos de usuario o contraseña.

2

El usuario no existe en la base de datos del sistema.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento de que un usuario quiere entrar al sistema.

RF-02

Modificar Perfil y Cuenta de Acceso

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador, ingrese a editar sus propios datos personales y cuenta de acceso.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

ARQUITECTURA DE SOFTWARE – ENTREGA 3 1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Cuenta y/o Settings”

3

El usuario cliquea botón.

4

Conectar a la base de datos para validar existencia del usuario.

5

Mostrar información del usuario

6

Editar datos deseados

7

Valida Datos

8

Guardar los cambios en la base de datos.

Al momento de editar el usuario y guardar los cambios, Pos condición

estos se almacenan en la BD.

Excepciones PASO 1

ACCION El usuario ingresa caracteres inválidos en los campos de del formulario.

2

Validar si un usuario está registrado en caso de cambiar su usuario.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el actor requiere para editar sus datos ya sea Administrador MolRodPin.

RF-03

Crear Hosting

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador, ingrese a Crear un Hosting.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Hosting”

3

El usuario cliquea botón “Nuevo”

4

Ingresar datos

5

Guardar en la base de datos.

Al momento de editar el usuario y guardar los cambios, Pos condición

estos se almacenan en la BD.

Excepciones PASO 1

ACCION El usuario ingresa caracteres inválidos en los campos de del formulario.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el actor requiere para registrar los datos de un hosting, debe seleccionar primero la opción “Registrados”, para que pueda escoger la iniciativa “Nuevo” y mostrar el formulario.

RF-04

Consultar Servidor Web

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee consultar un servidor web.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Pagina Web”

3

El usuario cliquea botón “Servidores web”

4

Conectar a la base de datos para validar existencias

5

Mostrar lista de Servidores Web

Al momento de editar el usuario y guardar los cambios, Pos condición

estos se almacenan en la BD.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el usuario requiere para consultar los Servidores Web.

RF-05

Validar Servidor Web

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador, intente modificar un Servidor web del sistema.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso 1

Acción Realizadas la Secuencias Normal RF-01

ARQUITECTURA DE SOFTWARE – ENTREGA 3 2

Realizadas la Secuencias Normal RF-04

3

Muestra informaciones

4

Buscar botón Validar y el actor cliquea botón

5

Conectar a la base de datos para validar existencia del Servidor Web

6

Valida el servidor web (página web)

7

Guardar los cambios en la base de datos.

Al momento de validar el servidor web, estos se almacenan Pos condición

en la BD.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el actor requiere para validar un servidor web, dado así que se pueden entregar los servicio de MolRodPin.

RF-06

Modificar Información del Hotel

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-03 Información de Administración Hotel.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador, el de Editar los datos del hotel.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Hotel”

3

El usuario cliquea botón “Settings”

ARQUITECTURA DE SOFTWARE – ENTREGA 3 4

Conectar a la base de datos para validar existencia del usuario

5

Mostrar información del Hotel

6

Editar datos deseados

7

Valida datos.

8

Guardar los cambios en la base de datos.

Al momento de editar el usuario y guardar los cambios, Pos condición

estos se almacenan en la BD.

Excepciones PASO 1

ACCION El usuario ingresa caracteres inválidos en los campos de del formulario

2

Validar si un usuario está registrado en caso de cambiar su usuario.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el actor requiere para editar los datos del hotel.

RF-07

Crear Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-03 Información de Administración Hotel.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador, el de Editar los datos del hotel.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Habitación”

3

El actor cliquea botón “Nuevo”

4

Ingresar datos

5

Guardar en la base de datos.

Pos condición Excepciones PASO 1

ACCION El usuario ingresa caracteres inválidos en los campos de del formulario.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el actor requiere para registrar los datos de una Habitación.

RF-08

Consultar Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee consultar las habitaciones.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “Habitación”

ARQUITECTURA DE SOFTWARE – ENTREGA 3 3

El administrador da click en el botón “Lista”

4

Conectar a la base de datos para validar existencias

5 Pos condición

Mostrar lista de Habitación

Al momento de editar el usuario y guardar los cambios, estos se almacenan en la BD.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el usuario requiere para consultar las habitaciones.

RF-09

Modificar Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee modificar una habitación del sistema.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Realizadas la Secuencias Normal RF-12

3

Muestra información

4

Se busca el botón de Actualizar y se da click

ARQUITECTURA DE SOFTWARE – ENTREGA 3 5

Conectar a la base de datos para validar existencia de la Habitación

Pos condición

6

Mostrar información de la habitación

7

Editar y modificar los datos deseados

8

Guardar los cambios en la bd

Al momento de editar el usuario y guardar los cambios, estos se almacenan en la BD.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el usuario requiere para consultar las habitaciones.

RF-10

Eliminar Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee eliminar los datos de una habitación del sistema.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Realizadas la Secuencias Normal RF-12

3

Muestra información

4

Se busca el botón de Eliminar y se da click

5

Conectar a la base de datos para validar existencia de la Habitación

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Pos condición

6

Mostrar información de la habitación

7

Validar la eliminación de la habitación

8

Guardar los cambios en la bd

Al momento de eliminar los datos, las reservas realizadas, se almacenan en la BD. Igualmente, al momento de realizar la eliminación de la información aparecerá un mensaje de advertencia por si dese o no realizar este proceso.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el usuario requiere eliminar una o varias habitaciones.

RF-11

Reservar Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee hacer una reserva a un usuario.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Buscar opción “reservar”

3

Se busca el botón y se da click

4

Ingreso de datos

5

Guardar en la base de datos

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Pos condición Excepciones PASO 1

ACCION El administrador digita algún carácter inválido en algún campo del formulario

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el administrador requiere para registrar los datos en la reserva de una o más habitaciones.

RF-12

Eliminar Reservas de Habitación

Objetivos asociados

OBJ-02 Gestión de Administración.

Requisitos asociados

RI-01 Información sobre Acceso al Sistema. RI-02 Información de Administración MolRodPin.

Descripción

El sistema deberá ejecutar ciertas acciones cuando el usuario administrador desee eliminar los datos de una reserva de habitación en el sistema.

Precondición

Ingreso previo del administrador o usuario al sistema para esta operación.

Secuencia Normal Paso

Acción

1

Realizadas la Secuencias Normal RF-01

2

Mostrar información

3

Se busca el botón “Eliminar” y se da click

4

Conectar a la base de datos para validar existencia de la reserva

5

Mostrar información de la reserva

6

Validar eliminación

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Pos condición

7

Eliminar datos deseados

8

Guardar los cambios en la base de datos

Al momento de eliminar los datos, las reservas realizadas, se almacenan en la BD. Igualmente, al momento de realizar la eliminación de la información aparecerá un mensaje de advertencia por si dese o no realizar este proceso.

Frecuencia Esperada

Alta

Comentarios

Estos son los pasos a realizar al momento que el usuario requiere eliminar una reservación.

Conclusiones El desarrollo del presente proyecto nos ha llevado a adquirir un mejor conocimiento sobre las mejores prácticas de desarrollo a través de la arquitectura de Software con el apoyo de Los patrones de diseño los cuales nos proveen soluciones comprobadas a problemas comunes ya que facilitan y mejoran los tiempos en un Proyecto de desarrollo de software. Se avanza en el estudio de una arquitectura de software apropiada en base al estudio de estilos, patrones, arquitecturas y estándares existentes, partiendo de un modelo del negocio que considera las interacciones existentes. La utilización de un estilo de arquitectura permite resolver el problema planteado que para nuestro caso es un desarrollo Web que permita efectuar las reservas en un hotel para lo cual se decide aplicar una tecnología: HTLM, JavaScript y PHP (MySql) bajo una arquitectura cliente servidor que permita cumplir con las expectativas del cliente (Hotel) que permite a sus usuarios o clientes ingresar desde la Web a la página del hotel y gestionar la reserva para su alojamiento en las fechas estipuladas y permitiendo si así lo desea efectuar no solo la reserva sino el pago de la misma, esto mediante arquitectura orientada al servicio (SOA).

En este proceso de desarrollo del proyecto se validan los diferentes conocimientos adquiridos

ARQUITECTURA DE SOFTWARE – ENTREGA 3 para el desarrollo, así como la aplicación de las mejores prácticas que se encuentren en el mercado.

Desarrollar una aplicación para la industria hotelera es un gran desafío investigativo, ya que el resultado permitirá implementar una gran herramienta profesional y práctica, dando una solución a la gestión administrativa del sector. La arquitectura de software tiene una serie de objetivos en común los cuales se enumeran a continuación: 1. Independiente de los frameworks. La existencia de esta forma de construir cosas en el sistema no depende de un framework. 2. Testeable. Tu arquitectura hace que tu código pueda ser testeado. 3. Independiente de la UI. Tus reglas de negocio no se ven alteradas por un requerimiento de UI, cuando se desarrolla una funcionalidad nueva es la UI la que se adapta a las reglas de negocio y nunca al revés. 4. Independiente de la base de datos. Se puede cambiar el motor de persistencia ya que las reglas de negocio no son dependientes de la implementación concreta de la base de datos sino que es la base de datos la que se adapta a estas reglas. 5. Independiente de cualquier componente externo. Se aplica la misma regla descrita en la base de datos pero relacionada a componentes externos así como integraciones con otros sistemas, librerías, etc. Sobre los casos de uso estos nos ayudan a expresar con un lenguaje más natural las acciones posibles que nuestro sistema puede realizar y de esa forma listan las funcionalidades del mismo. Un listado de los casos de uso ordenados por funcionalidad nos ayudará a saber de qué trata la aplicación con la que estamos trabajando.

En cuanto al protocolo,

ARQUITECTURA DE SOFTWARE – ENTREGA 3 

El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.



Es más seguro debido a que su implementación siempre o la mayoría de las veces se hace del lado del servidor.



SOAP es ideal para webservices de corporaciones donde se manejan datos complejos y se necesita una precisión detallada.



Soporta varios protocolos y tecnologías, incluyendo WSDL, XSD, SOAP y WSAddressing.



Los entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.



SOAP requiere menos código en las transacciones, la seguridad, la coordinación, direccionamiento, la confianza, etc.

● El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto. ● Es más seguro debido a que su implementación siempre o la mayoría de las veces se hace del lado del servidor. ● SOAP es ideal para webservices de corporaciones donde se manejan datos complejos y se necesita una precisión detallada. ● Soporta varios protocolos y tecnologías, incluyendo WSDL, XSD, SOAP y WSAddressing. ● Los entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

● SOAP requiere menos código en las transacciones, la seguridad, la coordinación, direccionamiento, la confianza, etc.

ARQUITECTURA DE SOFTWARE – ENTREGA 3 Recomendaciones Se debe tener bastante cuidado en la selección de la tecnología y la arquitectura ya que de ello depende la optimización del trabajo, la confiabilidad y una implementación efectiva y eficaz en todo nivel. El uso constante de estilos permitirá concentrarse en los drivers importantes, más que en la forma de implementar la solución. Si una arquitectura de software cumple con los objetivos podría clasificarse en el grupo de arquitecturas llamadas limpias. Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo. Si se desea modificar algo en el servidor esto impacta de una forma negativa en los clientes ya que ellos realizar varias modificaciones al código

ARQUITECTURA DE SOFTWARE – ENTREGA 3

Lista de referencias Cervantes Maceda, H., Velasco-Elizondo, P. y Castro Careaga, l. (2016). Arquitectura de software, conceptos y ciclo de desarrollo. Mexico: CENGAGE Learnig.

Dell EMC. (2018). Glosario de Dell EMC. Recuperado de https://colombia.emc.com/corporate/glossary/reference-architecture.htm

Mintic. (s.f.). Arquitectura TI Colombia. Marco de Referencia. Recuperado de http://www.mintic.gov.co/arquitecturati/630/w3-propertyvalue-8114.html

Qbit México REST Vs SOAP. Recuperado de http://qbit.com.mx/blog/2012/02/14/rest-vs-soap/ Informaciontecnologiachiny Sistemas Distribuidos. Recuperado de http://informaciontecnologiachiny.blogspot.com/2013/10/ventajas-y-desventajas-de-soap-yrest.html

http://opac.pucv.cl/pucv_txt/txt-1500/UCG1571_01.pdf http://www.mad.es/serviciosadicionales/ficheros/est-tema12.pdf http://openaccess.uoc.edu/webapps/o2/bitstream/10609/2123/1/iroigm_memoria.pdf