Arquitecturas Orientadas A Servicios

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
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
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
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
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
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
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.
Cronograma de trabajo
Capítulo 3
SOAP
SOAP llamado así al protocolo basado en XML el cual realiza un intercambio de información
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

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.
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.
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.
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
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
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
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
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.
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.
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.
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.
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 Información Administración MolRodPin

Objetivos asociados 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.
Importancia Alta
Comentarios Ninguno.
RI-03 Información Administración Hotel
Objetivos asociados 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.
Importancia Alta
RI-04 Información Usuario MolRodPin

Objetivos asociados 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
RI-05 Información Usuario MolRodPin
Objetivos asociados 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
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 Acción
1 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.
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 ACCION

1 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.
RI-02 Información de Administración MolRodPin.
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
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 ACCION
los campos de del formulario.
2 Validar si un usuario está registrado en
caso de cambiar su usuario.
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

usuario administrador, ingrese a Crear un Hosting.
esta operación.
Secuencia Normal
Paso Acción
2 Buscar opción “Hosting”
3 El usuario cliquea botón “Nuevo”
4 Ingresar datos
5 Guardar en la base de datos.
Excepciones
PASO ACCION
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

usuario administrador desee consultar un servidor web.
esta operación.
Secuencia Normal
Paso Acción
2 Buscar opción “Pagina Web”
3 El usuario cliquea botón “Servidores web”
existencias
5 Mostrar lista de Servidores Web
Comentarios Estos son los pasos a realizar al momento que el usuario
requiere para consultar los Servidores Web.
RF-05 Validar Servidor Web

usuario administrador, intente modificar un Servidor web
del sistema.
esta operación.
Secuencia Normal
Paso Acción
3 Muestra informaciones
4 Buscar botón Validar y el actor cliquea
botón
existencia del Servidor Web
6 Valida el servidor web (página web)
Al momento de validar el servidor web, estos se almacenan
Pos condición en la BD.
requiere para validar un servidor web, dado así que se
pueden entregar los servicio de MolRodPin.
RF-06 Modificar Información del Hotel

RI-03 Información de Administración Hotel.
usuario administrador, el de Editar los datos del hotel.
esta operación.
Secuencia Normal
Paso Acción
2 Buscar opción “Hotel”
3 El usuario cliquea botón “Settings”
existencia del usuario
5 Mostrar información del Hotel
6 Editar datos deseados
7 Valida datos.
Excepciones
PASO ACCION
los campos de del formulario
2 Validar si un usuario está registrado en
caso de cambiar su usuario.
requiere para editar los datos del hotel.
RF-07 Crear Habitación

RI-03 Información de Administración Hotel.
usuario administrador, el de Editar los datos del hotel.
esta operación.
Secuencia Normal
Paso Acción
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 ACCION
requiere para registrar los datos de una Habitación.
RF-08 Consultar Habitación

usuario administrador desee consultar las habitaciones.
esta operación.
Secuencia Normal
Paso Acción
2 Buscar opción “Habitación”
3 El administrador da click en el botón
“Lista”
existencias
5 Mostrar lista de Habitación
Pos condición Al momento de editar el usuario y guardar los cambios,
estos se almacenan en la BD.
requiere para consultar las habitaciones.
RF-09 Modificar Habitación

usuario administrador desee modificar una habitación del
sistema.
esta operación.
Secuencia Normal
Paso Acción
3 Muestra información
4 Se busca el botón de Actualizar y se da
click
existencia de la Habitación
6 Mostrar información de la habitación
7 Editar y modificar los datos deseados
8 Guardar los cambios en la bd
Pos condición Al momento de editar el usuario y guardar los cambios,
estos se almacenan en la BD.
requiere para consultar las habitaciones.
RF-10 Eliminar Habitación

usuario administrador desee eliminar los datos de una
habitación del sistema.
esta operación.
Secuencia Normal
Paso Acción
3 Muestra información
4 Se busca el botón de Eliminar y se da click
existencia de la Habitació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
Pos condición 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.
requiere eliminar una o varias habitaciones.
RF-11 Reservar Habitación

usuario administrador desee hacer una reserva a un
usuario.
esta operación.
Secuencia Normal
Paso Acción
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
Pos condición
Excepciones
PASO ACCION
1 El administrador digita algún carácter
inválido en algún campo del formulario
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

usuario administrador desee eliminar los datos de una
reserva de habitación en el sistema.
esta operación.
Secuencia Normal
Paso Acción
2 Mostrar información
3 Se busca el botón “Eliminar” y se da click
existencia de la reserva
5 Mostrar información de la reserva
6 Validar eliminación
7 Eliminar datos deseados
8 Guardar los cambios en la base de datos
Pos condición 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.
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
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,
 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 WS-
Addressing.
 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 WS-
Addressing.
● 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.
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
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-y-
rest.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

Arquitecturas Orientadas A Servicios

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Arquitecturas Orientadas A Servicios

Загружено:

Авторское право:

Доступные форматы

ARQUITECTURA DE SOFTWARE – ENTREGA 3

ARQUITECTURAS ORIENTADAS A SERVICIOS

Modelo: representa la información con la que trabaja la aplicación, o sea, su lógica de

aplicaciones. El controlador es el encargado de aislar al modelo y a la vista de los detalles

Situación Problemática Recurrente

Interfaz del usuario

Estructura de un mensaje SOAP.

ARQUITECTURA DE SOFTWARE – ENTREGA 3

La Web utiliza como protocolo fundamental el HTTP, y la mayoría de las organizaciones ya

El tener un mensaje unidireccional, como una petición de un cliente a un servidor, o una

Elementos principales de un mensaje SOA

HTML5 es una colección de estándares para el diseño y desarrollo de páginas web y

JQUERY es una biblioteca de JavaScript, que permite simplificar la manera de interactuar

AJAX es el acrónimo de Asynchronous Javascriptand XML, es decir, Javascript y XML

SUBLIMETEXT editor de texto para escribir código en la mayoría de los lenguajes de

DISEÑO DE CÓMO FUNCIONA INTERNAMENTE

OBJ-01 Control de Acceso al Sistema

OBJ-03 Gestión de Usuario

A continuación se definirán los requisitos de información más relevantes a tener en cuenta

RI-02 Información Administración MolRodPin

RI-04 Información Usuario MolRodPin

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

RF-01 Acceso al Sistema

3 El sistema verifica caracteres en blanco y

Excepciones PASO ACCION

RF-02 Modificar Perfil y Cuenta de Acceso

RF-03 Crear Hosting

RF-04 Consultar Servidor Web

RF-05 Validar Servidor Web

RF-06 Modificar Información del Hotel

RF-07 Crear Habitación

RF-08 Consultar Habitación

RF-09 Modificar Habitación

RF-10 Eliminar Habitación

RF-11 Reservar Habitación

RF-12 Eliminar Reservas de Habitación

Se avanza en el estudio de una arquitectura de software apropiada en base al estudio de

1. Independiente de los frameworks. La existencia de esta forma de construir cosas

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

4. Independiente de la base de datos. Se puede cambiar el motor de persistencia ya

5. Independiente de cualquier componente externo. Se aplica la misma regla descrita

● SOAP requiere menos código en las transacciones, la seguridad, la coordinación,

Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las

Cervantes Maceda, H., Velasco-Elizondo, P. y Castro Careaga, l. (2016). Arquitectura de

Dell EMC. (2018). Glosario de Dell EMC. Recuperado de

Mintic. (s.f.). Arquitectura TI Colombia. Marco de Referencia. Recuperado de

Qbit México REST Vs SOAP. Recuperado de

Вам также может понравиться