Arquitectura de Software 1
Arquitectura de Software 1
Arquitectura de Software 1
TESIS DE GRADO
LA PAZ – BOLIVIA
2015
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LICENCIA DE USO
por la confianza y todo el apoyo brindado para lograr este anhelado paso,
Primeramente quiero agradecer de manera especial al Padre Celestial quien ilumina mis
pasos en todo momento y llena mi vida de bendiciones.
Lic Javier Reyes Pacheco por el interés y la guía que ha mostrado en el desarrollo de esta
investigación, agradezco mucho el apoyo y sus buenos consejos en aquellos momentos de
incertidumbre.
Lic. Brigida Carvajal Blanco por ser una docente ejemplar, en las observaciones,
sugerencias y en todo el apoyo prestado para la conclusión del presente trabajo.
A mis estimados compañeros con quienes emprendimos toda esta travesía en la carrera y
llegamos a formar una gran amistad: Irma, Cinthia, Jeaqueline, Zara, Maritza, Eva,
Karina, Ivonne, Ronald, Rubén, Reynaldo, Elio, Cristhian, Demis, Diego, Alberto, Adalid,
Rudy, Miguel y asimismo a Boris por su apoyo incondicional.
CAPITULO 2................................................................................................................................... 16
MARCO TEORICO ......................................................................................................................... 16
2.1. DISEÑO ARQUITECTONICO ............................................................................................17
CAPITULO 3................................................................................................................................... 51
MARCO APLICATIVO..................................................................................................................... 51
3.1. ANALISIS DEL MÉTODO ..................................................................................................52
CAPITULO 4................................................................................................................................... 74
DEMOSTRACION DE HIPOTESIS ................................................................................................... 74
4.1. OBTENCION DE DATOS ...................................................................................................75
CAPITULO 5................................................................................................................................... 79
CONCLUSIONES Y RECOMENDACIONES....................................................................................... 79
REFERENCIA BIBLIOGRAFICA ........................................................................................................ 81
BIBLIOGRAFIA ............................................................................................................................. 82
ANEXOS ........................................................................................................................................ 85
ANEXO A : UML .........................................................................................................................85
DOCUMENTOS.............................................................................................................................. 94
INDICE DE FIGURAS
La información forma parte de nuestro lenguaje natural y de nuestra vida diaria, en todas
partes nos vemos involucrados con la misma. CORBA, DCOM, y Java RMI disfrutaron
de un éxito considerable, hasta la aparición de entornos Web. Un sistema basado en Web
es un sistema vivo. Es como un jardín que sigue evolucionando, cambiando y creciendo.
The information is part of our natural language and our daily life, everywhere we are involved
with it. CORBA, DCOM, and Java RMI enjoyed considerable success until the advent of Web
environments. A Web-based system is a living system. It is like a garden that continues to evolve,
change and grow.
The Web engineering helps create an infrastructure, providing maintenance and support
creativity. But the interesting part of this process is a service provider, one who serves others.
The Cloud is a model that allows access from the network to a shared set of computing resources,
configurable and released to the customer with minimal management effort or interaction with
the service provider. It has three delivery models that are IaaS, Paas and Saas, which can be
deployed through a public cloud, private cloud or a Community-nine,
The cloud computing provider owns and manages the cloud infrastructure. The existence of
many different consumers within a cloud architecture referred to as a multi-tenancy model.
RESUMEN
1
1.1. INTRODUCCION
La información forma parte de nuestro lenguaje natural y de nuestra vida diaria, en todas
partes nos vemos involucrados con la misma, así también, los diferentes servicios de
información que comenzaron de forma manual y que hasta nuestros tiempos están
sufriendo cambios continuos a fin de mejorar los mecanismos con el uso de nuevas
tecnologías.
2
Si bien, empresas como la cadena de Hoteles Radisson, la tienda estadounidense de
comercio electrónico Amazon, American Airlines, y otros, están cambiando sus
procesos de información a fin de brindar a sus clientes información oportuna, reservas
en línea, emisión de tickets de vuelo, compras en línea, reserva de mesa en un restaurante
u otros servicios para el cliente. Basados en ese cambio de procesos de información en
línea es que comenzamos el presente trabajo que contempla una arquitectura de
aplicaciones empresariales puestas en la nube.
1.2. ANTECEDENTES
Los programadores tenían que pasar una cantidad significativa de tiempo para
especificar un protocolo de mensajería y el mapeo de las diversas estructuras de datos.
Como el desarrollo de aplicaciones de computación distribuida aumentó, era necesario
nuevos mecanismos y enfoques para facilitar la construcción de aplicaciones
distribuidas. La primera tecnología de computación distribuida para ganar uso
generalizado fue llamada procedimiento remoto (RPC), desarrollado en la década de
1980 por Sun Microsystems. RPC demostró ser una solución adecuada para el desarrollo
de las arquitecturas cliente / servidor de dos niveles.[4]
3
La investigación en el área de objetos distribuidos permitió superar este problema con
la especificación de dos tecnologías que compiten: La arquitectura de ejecución de
aplicaciones CORBA (Common Objetct Request Broker Architecture) y el modelo de
objeto común distribuido DCOM (Distributed Common Object Model). Más adelante
se Java se convirtió en un nuevo competidor por medio de un método de invocaciones
remotas (RMI). [4]
CORBA
CORBA es una arquitectura abierta estandarizada gestionado por OMG
(Object Management Group). La tecnología CORBA puede considerarse una
generalización de la tecnología llamada a procedimiento remoto (RPC) e
incluye varias mejoras sobre los objetos de datos y en las primitivas de datos.
El propósito de esta tecnología y la arquitectura era para permitir el desarrollo
de aplicaciones y servicios distribuidos que pueden comunicarse con
interoperabilidad con otras aplicaciones dispares través de la red. CORBA fue
desarrollado fundamentalmente para lograr una disciplina para implementar
la portabilidad e interoperabilidad de las aplicaciones a través de diferentes
plataformas de hardware, entornos operativos e implementaciones de
hardware dispares.[4]
4
La tecnología CORBA mostrada en la Figura 1.1, utiliza un protocolo binario
llamado Internet Inter-ORB Protocol (IIOP) para comunicarse con objetos
remotos.[4]
DCOM
A mediados de la década de 1990, Microsoft Corporation presentó una
tecnología llamada COM que permitió el desarrollo de módulos de software
denominados componentes para la integración de aplicaciones a través de la
arquitectura cliente-servidor.
La tecnología DCOM mostrada en la figura 1.2, permitió la interacción entre
los componentes basados en la red sobre el Entorno de Computación
Distribuido (DCE).[4]
5
La Tecnología DCOM se basa esencialmente en una capa de objetos RPC,
que a su vez está en la cima de la DCE RPC que permite la comunicación
entre objetos remotos. DCOM utiliza un protocolo binario, denominado
objeto de llamada a procedimiento remoto (ORPC), para la comunicación
distribuida entre objetos remotos. Las Tecnologías como Object Linking and
Embedding (OLE), ActiveX, y Microsoft Transaction Server (MTS) son
algunos de los avances tecnológicos de Microsoft basados en las tecnologías
COM y DCOM.[4]
6
J2EE
7
La especificación J2EE, controlada por el JCP, se lleva a cabo luego por
muchos fabricantes de servidores de aplicaciones diferentes que compiten en
un mercado muy grande. Esto significa que el cliente es libre de elegir el
servidor de aplicaciones y el vendedor y, en una fecha posterior, para cambiar
a un proveedor diferente si es necesario, pero cualquier software existente
debe ser portátil entre las implementaciones de diferentes proveedores.[4]
La tecnología del Internet da otra perspectiva de recurrir a los servicios Web para la
creación y entrega de aplicaciones a través de la red. Este método permite que las
aplicaciones se comuniquen independientemente de la plataforma o el sistema
operativo. Lo positivo es que los desarrolladores pueden eliminar los principales
esfuerzos de las pruebas de portabilidad y calidad.
8
Arquitectura Orientada a Servicios (SOA)
Pero, sin una red subyacente común, protocolos comunes para la comunicación de
programa a programa, y una arquitectura común para ayudar a las aplicaciones a declarar
su disponibilidad y servicios, se ha demostrado que es difícil de implementar plataformas
de comunicación de programa a programa entre los módulos de aplicación.
9
Como se ha podido observar, el uso de diferentes tecnologías con respecto al tratado de
la información y el proceso de integración de aplicaciones en la web, dio lugar a
diferentes soluciones, que si bien comenzaron siendo novedad en su momento, se fueron
convirtiendo en nuevos desafíos para los desarrolladores conforme cambiaba las
operaciones comerciales y se requería contemplar la escalabilidad de los mismos.
Una propuesta interesante que se maneja como solución es migrar la empresa a La Nube,
que propone ser masivamente escalable, y cuenta con muchos beneficios incorporados
de eficiencia, disponibilidad y de alta utilidad; contrario a ello surgen interrogantes como:
¿Cuánto de inversión será requerida para que una empresa opte por este servicio? ¿Qué
mecanismo se pueden aplicar para la integración de aplicaciones empresariales? ¿Qué
seguridad tengo con respecto a los datos de información? ¿Qué proveedores distribuyen
este servicio?, interrogantes que el presente trabajo pretende reflejar con respecto al uso
de esta tecnología; si bien La Nube promete ahorrar en costos, agilidad, innovación,
flexibilidad y simplicidad. Los ofrecimientos de distribuidores, en términos de servicio
de aplicaciones, plataformas e infraestructura natural, son continuos logros, y el ahorro
económico que es un buen atractivo en un ambiente económico competitivo.
1.3. PROBLEMATICA
10
CAUSA EFECTO
1. Existen empresas que brindan el 1. El pago de servicio es único y realizar
servicio de Hosting para alojar alguna modificación implica un costo
portales o almacenamiento de aparte.
archivos.
3. Existe un bajo interés por optar 3. La Nube constituye una tendencia nueva
nuevas tecnologías para el tratado que hace imaginar precios elevados al
de información. cual no desean ingresar por temor de
perder información importante o no.
11
1.3.2. Definición del problema
1.4. OBJETIVOS
12
1.6. HIPOTESIS
13
1.7. JUSTIFICACION
El empleo de la Nube es un concepto nuevo que recién toma curso en nuestro medio,
existiendo temor de adicionar y/o mejorar el servicio actual con el que cuentan,
dejando de lado los beneficios y mejoras tecnologías que conlleva contar con uno o
más proveedores.
Los cambios siempre conllevan a soluciones más viables; desde esta perspectiva las
empresas que brindan servicios en línea son los directos responsables de garantizar
tecnologías de punta así como de nuevas plataformas de desarrollo o de nuevas
aplicaciones listas para ser utilizadas en la medida que sea conveniente para la
empresa; considerándose que los beneficios son compartidos, por un lado la
institución proveedora mejora sus prestaciones tecnológicas y por otra parte son las
empresas que optimizan sus servicios acorde a sus requerimientos y posibilita a
minimizar sus gastos en cuanto a infraestructura tecnológica.
14
Si bien cada empresa contempla diferentes gastos en cuanto a compra y/o
mantenimiento de infraestructura tecnológica (No se considera el pago de sueldos,
impuestos y viáticos), la respuesta a la implementación juega un papel preponderante
a la hora de demostrar eficiencia y efectividad en el negocio, invertir en soluciones
de proveedores de servicios trae consigo mejoras referentes a minimizar gastos y
optimizar los recursos económicos en pos de la estabilidad empresarial.
1.8. APORTES
Una herramienta que será empleada para el desarrollo del presente trabajo es el
modelo 4 + 1 vistas (ver el punto 2.1.1 del capítulo 2 del Marco Teórico) que a través
de sus áreas de desarrollo permitirá una mejor representación del modelo propuesto.
15
CAPITULO 2
MARCO TEORICO
RESUMEN
16
2.1. DISEÑO ARQUITECTONICO
Diseño:
“El diseño es lo que casi todo ingeniero quiere hacer. Es el lugar en el que las reglas
de la creatividad —los requerimientos de los participantes, las necesidades del
negocio y las consideraciones técnicas— se unen para formular un producto o
sistema. El diseño crea una representación o modelo del software, el modelo de
diseño proporciona detalles sobre arquitectura del software, estructuras de datos,
interfaces y componentes que se necesitan para implementar el sistema. ”. [1]
Arquitectura:
Hay una diferencia entre los términos arquitectura y diseño. Un diseño es una
instancia de una arquitectura, similar a un objeto que es una instancia de una clase.
Por ejemplo, considere la arquitectura de cliente-servidor. Con esta arquitectura es
posible diseñar de muchos modos un sistema de software basado en red, con el uso
de una plataforma Java (Java EE) o Microsoft (estructura .NET). Entonces, hay una
arquitectura, pero con base en ella pueden crearse muchos diseños. Así, no es válido
mezclar “arquitectura” y “diseño”. [1]
17
Definición 1: El diseño arquitectónico representa la estructura de los datos y de los
componentes del programa que se requieren para construir un sistema
basado en computadora. Considera el estilo de arquitectura que adoptará
el sistema, la estructura y las propiedades de los componentes que lo
constituyen y las interrelaciones que ocurren entre sus componentes
arquitectónicos. [1]
El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes.
Tal como se muestra en la Figura 2.1, cada vista se refiere a un conjunto de intereses de
diferentes stakeholders del sistema. [12]
Cada vista se describe en lo que llamamos “diagrama” (blueprint) que usa su notación
particular. Los arquitectos también pueden usar estilos de arquitectura para cada vista, y
por lo tanto hacer que coexistan distintos estilos en un mismo sistema. [12]
18
El modelo de 4+1 vistas es bastante genérico: se puede usar otra notación y herramientas
que las aquí descritas, así como también otros métodos de diseño, especialmente para las
descomposiciones lógica y de procesos.[12]
La vista lógica apoya principalmente los requisitos funcionales –lo que el sistema debe
brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie
de abstracciones clave, tomadas del dominio del problema en la forma de objetos o clases
de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia.
Esta descomposición no solo se hace para potenciar el análisis funcional, sino también
sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del
sistema.[12]
19
Figura 2.2: Notación para la vista lógica
Fuente: [12]
Estilo: El estilo usado para la vista lógica es el estilo de orientación a objetos. La principal
guía para el diseño de la vista lógica es el intentar mantener un modelo único y coherente
de objetos a lo largo de todo el sistema, para evitar la especialización prematura de las
clases y mecanismos particulares o de un procesador. [12]
20
El nivel más alto la arquitectura de procesos puede verse como un conjunto de redes
lógicas de programas comunicantes (llamados “procesos”) ejecutándose en forma
independiente, y distribuidos a lo largo de un conjunto de recursos de hardware
conectados mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse
para apoyar la separación de la operación del sistema en línea del sistema fuera de línea,
así como también para apoyar la coexistencia de versiones de software de simulación o
de prueba. [12]
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos
representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente
(por ejemplo: comenzar, recuperar, reconfigurar, y detener). [12]
21
2.1.1.3. La vista de Desarrollo
Notación: Tal como se muestra en la Figura 2.4, usamos una variante de la notación de
Booch limitándonos a aquellos items relevantes para la arquitectura. [12]
22
2.1.1.4. La vista Física
La vista física toma en cuenta primeramente los requisitos no funcionales del sistema
tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance
(throughput), y escalabilidad. Los variados elementos identificados –redes, procesos,
tareas y objetos– requieren ser mapeados sobre los variados nodos. Por lo tanto, el mapeo
del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre
el código fuente en sí. [12]
Notación: para la arquitectura física. Los diagramas físicos pueden tornarse muy
confusos en grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo
de la vista de procesos (véase la figura 2.5). [12]
2.1.1.5. Escenarios
Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el
uso de un conjunto pequeño de escenarios relevantes –instancias de casos de uso más
generales–. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas
de interacción de objetos. [12]
23
Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos
principales:
Notación: La notación es muy similar a la vista lógica para los componentes (ver Figura
2.2), pero usa los conectores de la vista de procesos para la interacción entre objetos (ver
Figura 2.3). [12]
Por lo tanto, la arquitectura lógica tiene en cuenta sólo el aspecto funcional de los
requisitos.
24
De la lógica al desarrollo: Una clase se implementa generalmente como un módulo. Las
clases grandes se descomponen en múltiples paquetes. Colecciones de clases
íntimamente relacionadas – categorías de clases– se agrupan en subsistemas. [12]
Las vistas lógica y de desarrollo son muy cercanas, aunque se refieren a distintos asuntos.
Cuanto mayor es el proyecto, mayor es también la distancia entre estas dos vistas.
Similarmente para las vistas de procesos y física. [12]
Considerar que UML nace casi a la vez que el modelo 4+1, por lo que en un origen no
existía una clara relación entre ambos, en el ANEXO A se puede ver acerca de los
elementos pertenecientes a UML que serán utilizados, es así que se tiene la siguiente
translación que se presenta en la siguiente tabla:
VISTA UML
Desarrollo Componentes
Física Despliegue
25
2.2. INGENIERIA WEB
Desde su origen y la promoción como una nueva disciplina en 1998, la ingeniería Web
está recibiendo creciente interés entre los actores de los sistemas basados en la web,
incluyendo desarrolladores, clientes, gobierno agencias, usuarios, académicos e
investigadores. Además, este nuevo campo ha atraído profesionales de otras disciplinas
relacionadas, tales como multimedia, ingeniería de software, sistemas distribuidos,
informática, y la recuperación de información. [2]
26
En general, se conoce como proveedores a las empresas o particulares que ofrecen
servicios tecnológicos. Estos pueden ser acceso y conexión a Internet, telefonía móvil,
hosting de aplicaciones y sitios web, acceso a servicios y cuentas en determinados
softwares o sitios web, etc. [13]
Este tipo de proveedores son virtuales, ya que no constituyen personas físicas, pero
cumplen un rol similar en facilitar el uso y acceso de un individuo o equipo a
posibilidades y servicios. [13]
Aunque los aspectos generales de la gestión del servicio son comunes a todos ellos
existen obvias diferencias en los aspectos organizativos en cada caso. [14]
27
Cada tipo de proveedor de servicios tiene sus ventajas e inconvenientes que pasamos a
analizar. [14]
II
- Se comparten costes y riesgos - Asumir actividades que no aportan
entre diferentes unidades. ventajas competitivas a la
[14] organización o empresa. [14]
- Posicionamiento más - Posibles conflictos de intereses
competitivo frente a entre diferentes unidades de
proveedores externos. [14] negocio.[14]
- Estandarización de procesos.
[14]
- Mayores opciones de
crecimiento [14]
28
2.4. ARQUITECTURA ORIENTADA AL SERVICIO (SOA)
Una arquitectura orientada a servicios (SOA) como se muestra en la figura 2.6 es un estilo
de organización que guía todos los aspectos de la creación y utilización de servicios de
negocio a lo largo de su ciclo de vida (desde la concepción hasta la jubilación). El
concepto organizador clave de una SOA en sí es un servicio. Los procesos, principios y
métodos definidos por SOA están orientadas hacia los servicios; las herramientas de
desarrollo seleccionados por una SOA están orientados hacia la creación y el despliegue
de los servicios; y la infraestructura de tiempo de ejecución proporcionado por una SOA
está orientado a la ejecución y gestión de los servicios. [3]
29
2.4.1. Características de SOA
30
2.4.4. SOA y servicios Web
Se basa en XML como su formato de mensaje y por lo general se basa en otros protocolos
de la capa de aplicaciones, llamada a procedimiento más notablemente remoto (RPC) y
HTTP para la negociación y transmisión de mensajes. [3]
Las ventajas de utilizar SOAP sobre HTTP es que SOAP permite una comunicación más
fácil a través de servidores proxy y servidores de seguridad que la tecnología de ejecución
remota anterior y es lo suficientemente versátil como para permitir el uso de diferentes
protocolos de transporte. [3]
Los servicios Web REST se basan en HTTP como protocolo lo suficientemente rico
como para satisfacer completamente las necesidades de aplicaciones de servicios Web.
[3]
REST requiere menos software del lado del cliente para ser escrito que otros enfoques,
porque un solo navegador puede acceder a cualquier aplicación y cualquier recurso.[3]
31
2.5. ARQUITECTURA BASADA EN PROVEEDORES
Para comprender bien este apartado, se tiene identificado a los siguientes actores que son:
El Proveedor de servicios: representa una entidad que diseña y desarrolla una aplicación
o un módulo de software u otro servicio que interactúa con las consultas de los
consumidores de servicios por medio de la red. [20]
32
Figura 2.7 Representación de una arquitectura basada en proveedores
Fuente: Adaptación [20]
33
Definición 2: Una Aplicación Empresarial es una aplicación de software desarrollada
para administrar las operaciones, activos y recursos de una empresa. [15]
2.6.1.1. Características
34
2.6.2. Gestión de Aplicaciones Empresariales
35
Usabilidad: Se define como la facilidad de comprensión y uso de un servicio, la
facilidad de uso también se ve afectada por la familiaridad, continuidad, y la
fuerza de los hábitos adquiridos [3]
36
Para ofrecer nuevos productos y servicios de forma fácil y rápida
Para agilizar su proceso interno y operaciones
Para fortalecer las relaciones de suministro
Para mejorar las relaciones con clientes
EAI permite la integración de toda la empresa con las diversas aplicaciones a través de
diferentes productos y tecnologías, con una vista de 360 ° en relación con el cliente a
través de múltiples canales de interacción. [3]
Los conceptos básicos relacionados con la EAI se describen aquí. Un EAI robusto y
flexible proporciona una combinación de métodos de integración y modos de
comunicación que están incorporados en los diversos modelos de integración que se
implementan dentro de la arquitectura EAI como se expone a continuación. [3]
Métodos de Integración
Los métodos de integración son enfoques utilizados para guiar una solicitud de un
emisor a un receptor. Los dos métodos principales de la integración son los
siguientes:
37
2) Interfaz: En este enfoque, el emisor se comunica a través de una interfaz,
que define explícitamente las acciones que pueden ser invocados por una
aplicación. Las interfaces son difíciles de cambiar y ampliar; se encuentran
asociados a una aplicación particular. [3]
3) Conector: En este enfoque, la aplicación proporciona un punto de acceso
que permite que un mensaje o invocación en una interfaz pase a la
aplicación; un conector es más que una interfaz que proporciona
capacidades adicionales como el control de errores y la comprobación de la
validación, la conversión y transformación de datos en formato adecuado,
y la gestión de la información de estado que permite la entrega garantizada
o la recuperación adecuada. Muchas aplicaciones no tienen un punto de
entrada previamente predefinida o creada en la aplicación.
En esos casos, se puede utilizar archivos de datos, bases de datos, interfaces
de usuario, o la memoria como el punto de entrada para la inyección de
peticiones. [3]
Modos de Comunicación
38
Se utiliza cuando se requiere la comunicación de información sin la
necesidad de coordinar las actividades o respuestas. [3]
Opciones de Middleware
39
Integración de Presentación
Integración Funcional
40
2) Tecnología de Objetos Distribuidos (DOT): Se logra la integración al
proporcionar interfaces de objetos que hacen que las aplicaciones se vean
como objetos. Las aplicaciones pueden tener acceso a otras aplicaciones a
través de una red a través. CORBA de OMG, COM + de Microsoft y Java
2 Enterprise Edition de Sun (J2EE) son ejemplos de DOT. [3]
Integración de Datos
En este modelo, la integración se lleva a cabo sin pasar por la lógica de negocio de
aplicaciones existente y se accede directamente a los datos creados, procesados y
almacenados por cada una de las aplicaciones correspondientes. Por ejemplo, un
sistema de facturación basado en Oracle se puede integrar con un sistema de pedido
de un cliente basado en IBM utilizando la tecnología de puerta de enlace de base
de datos que integra la base de datos DB2 con la base de datos Oracle. [3]
41
Integración de Procesos de Negocio
“La Nube es un modelo para permitir adecuadamente, una petición accedida desde
de la red a un conjunto compartido de recursos de computo configurables (por ej.
redes, servidores, almacenamiento, aplicaciones, y servicios) que son rápidamente
aprovisionados y liberados a disposición del cliente con un mínimo esfuerzo de
gestión o la interacción con el proveedor de servicios. Este modelo promueve la
disponibilidad y está compuesto por cinco características principales, tres modelos
de entrega, y cuatro modelos de despliegue. [3]
42
2.7.1. Características
IaaS del inglés Infrastructure as a Service, de acuerdo con NIST, está definido de la
siguiente manera: “Es la capacidad suministrada al consumidor como ser el
procesamiento, el almacenamiento, las redes y otros recursos de computación, donde el
consumidor puede utilizar y operar un software cualquiera, que puede incluir sistemas
operativos y aplicaciones. [3]
43
El consumidor no puede administrar o controlar la infraestructura de la nube pero tiene
control sobre los sistemas operativos, el almacenamiento, el despliegue de aplicaciones
y posiblemente un control limitado de componentes de conexión de red (por ej. Host
firewalls)”. [3]
El usuario de IaaS tiene facultad solo en la infraestructura del equipo físico permitido y
puede usarlo como si fuera su computadora propia en una red lejana y tiene control sobre
el sistema operativo y software alojados ahí. IaaS es ilustrado en la figura 1. el proveedor
de IaaS tiene control sobre el equipo físico verdadero, y el usuario de nube puede pedir
la asignación de recursos virtuales, que son asignado por el proveedor de IaaS. Por lo
tanto, IaaS es ideal para los usuarios que quieren el control completo sobre la pila de
software que operan.
PaaS del inglés Platform as a Service, NIST define PaaS de la siguiente manera: “Es la
capacidad suministrada al consumidor para desplegar aplicaciones creadas usando
lenguajes de programación y herramientas soportadas por el proveedor de la
infraestructura de nube creada o adquirida.” [3]
Las plataformas de PaaS son muy adecuadas para usuarios de nube que descubren que el
software estándar personalizado que están usando se ajusta al software estándar
personalizado proveído por uno de los distribuidores de PaaS. Esto permite que a ellos
se concentren en la aplicación. Azure, Google Apps, y Hadoop son algunas plataformas
de PaaS conocidas. Asimismo los distribuidores tradicionales como HP, IBM, y
Microsoft ofrecen las soluciones que pueden ser usados construir PaaS privados. [3]
44
2.7.2.3. Software como un servicio (SaaS)
SaaS del inglés Software as a Service, NIST la define de la siguiente manera: “Es la
capacidad suministrada al consumidor para usar las aplicaciones del proveedor corriendo
sobre una infraestructura en la nube. Las aplicaciones son accesibles por el cliente desde
diferentes dispositivos a través de una interfaz de cliente como ser un navegador de web
(por ej. el correo electrónico basado en Web). El consumidor no administra o controla la
infraestructura de nube incluyendo la red, los servidores, los sistemas operativos, el
almacenamiento o incluso la capacidad de las aplicaciones individuales, pero tiene la
posibilidad limitada de leves ajustes a una específica aplicación de usuario.” [3]
Cualquier aplicación que puede ser accedida usando un navegador de web puede ser
considerado como SaaS. Observe la figura 1 sobre el SaaS, el proveedor de SaaS controla
todas las capas aparte de la aplicación. Los usuarios que entran al sistema del servicio de
SaaS pueden ambos usar la aplicación y configurar la aplicación para su uso.[3]
Por ejemplo, los usuarios pueden usar Salesforce.Com para almacenar sus datos del
cliente. Las aplicaciones de SaaS prominentes incluyen Salesforce.Com para CRM,
documentación de Google para el compartimiento de documento, y sistemas de correo
electrónico de Web como Gmail, Hotmail, y Yahoo! Correo. Los distribuidores de IT
como HP e IBM también venden sistemas que pueden ser arreglados para poner SaaS en
una nube privada; SAP, por ejemplo, puede ser usado como un ofrecimiento de SaaS
dentro de una empresa u otra entidad. [3]
45
Figura 2.8: Los tres modelos de entrega de la nube
Fuente: [3]
Como su nombre indica, está asequible al público en general y es llevado por una
organización. La organización podría ser una empresa (como Google), académica, o un
departamento gubernamental.[3]
Tiene un propósito exclusivo para una organización especial. Los recursos de la nube
pueden ser ubicados sobre o fuera de la premisa y pueden ser administrados y dirigidos
por la organización consumidora o una tercera parte. [3]
46
2.7.3.3. Nube Híbrida
Se forman cuando más de un tipo de infraestructuras de nube son utilizadas para una
situación particular. Por ejemplo, una organización puede utilizar una nube pública para
algún aspecto de su empresa, pero también tener una nube privada sobre la premisa para
los datos que son confidenciales. [3]
Son un modelo de nube donde los recursos existen para varias partes que tienen un interés
compartido o la misma causa. Investigadores y Organizaciones académicas la han creado
para dirigir experimentos científicos a gran escala (e- ciencia). [3]
Esta parte del EIC 62264, en conjunción con la norma IEC 62264-1, especifica el
contenido de la interfaz genérica entre las funciones de control de fabricación y otras
funciones empresariales. Las interfaces consideradas son las interfaces entre los niveles
3 y 4 del modelo jerárquico definido en la norma IEC 62264-1. El objetivo es reducir el
riesgo, el coste y los errores asociados con la implementación de las interfaces. [19]
Desde el IEC 62264 se cubre muchos dominios y hay muchos estándares diferentes en
esos dominios, la semántica de la presente norma se describe en un nivel objetivo y
permitir a los otros estándares ser asignados a estas semánticas. Para ello este estándar
define un conjunto de elementos de contenido interfaces genéricas, junto con un
mecanismo para extender esos elementos para implementaciones. [19]
47
El límite se identifica mediante modelos pertinentes que representan funciones, equipo
físico, la información en el dominio MO & C, y los flujos de información entre los
dominios. [19]
48
El modelo muestra los niveles jerárquicos en el que se toman las decisiones. La interfaz
abordado en esta norma se encuentra entre el nivel 4 y nivel 3 del modelo de jerarquía.
49
SIMBOLO DEFINICIÓN
Define un packaqe, una colección de modelos de
objetos utilizan clases, y otras modelos UML. En este
documento un paquete es utilizar para especificar un
modelo externo, como una regla de producción de
referencia modelo de OA a otra parte del modelo
Define una clase de objetos, cada uno con los tipos
sam de atributos. Cada objeto es único de
identificación o enumerable. No hay operaciones o
métodos se enumeran para las clases. Atributos con
un '-'before su nombre indica atributos que son
generalmente opcional en cualquier uso de la clase
Una asociación entre los elementos de una clase y
elementos de otra o la misma clase. Cada asociación
se indentified. Puede tener el número esperado o
rango de miembros de la subclase, cuando "n" indica
un número indeterminado. Por ejemplo 0. N significa
que pueden existir cero o más miembros de la
subclase ..
50
CAPITULO 3
MARCO APLICATIVO
RESUMEN
51
3.1. ANALISIS DEL MÉTODO
52
3.1.2. Proveedores de IaaS
A continuación en la siguiente tabla se presentamos una lista con proveedores que tienen
a disposición el servicio IaaS y asimismo cuentan con una lista de precios para realizar
las comparativas.
CARACTERISTICAS
Transferencia
Escalabilidad
Integración
Procesador
Memoria
Softlayer de IBM 1 – 32 1 – 48 Gb 1Gb – 1,2 500 Gb 1 mes
[21] Núcleos Tb
Atlantic.net [22] 1 – 20 512Mb – 20 Gb – 2TB a
Núcleos 64 Gb 650 Gb 9TB
Amazon EC2 [23] 1 – 40 1 – 244 1 – 48000 1 Año
Núcleos Gb Gb
SSD: 32 –
6400 Gb
Elastichost [24] 10 Mhz – 128 – 2 Gb – 1 – 1000
20000 Mhz 8192 Mb 1862 Gb Gb
Microsoft azure 1 – 32 0,75 – 20 – 605 1 mes
[25] Núcleos 112 Gb Gb
SSD: 50 –
6144 GB
CenturyLink [26] 1 – 16 1 – 128 1 – 4000 1 mes
Núcleos Gb Gb
Rackspace [27] 6 a 32 24 – 128 730 Gb – 4 meses
Núcleos Gb 3000 Gb
vmware cloud 1 – 16 1 – 240 0 – 6Tb 3 meses
[28] Núcleos Gb SSD: de 0 a
6 TB
google cloud [29] 1 – 32 24 – 128 730 – 3000 2 meses
Núcleos Gb Gb
Joyent [30] 1 – 32 1 – 128 3 - 30720 10 Gb
Núcleos Gb Gb
Tabla 3.1: Proveedores de IaaS
53
3.1.3. Proveedores de PaaS
A continuación en la siguiente tabla se presentamos una lista con proveedores PaaS que
tienen a disposición su lista de precios.
A continuación en la siguiente tabla se presentamos una lista con proveedores que tienen
a disposición el servicio SaaS.
54
Apple Icloud [36] Amazon Flexible Payments Service (Amazon FPS)
Amazon DevPay
En la figura 3.1, tenemos las entidades que mínimamente se requiere para lograr la
funcionalidad que necesitamos.
55
A continuación se detalla las clases mostradas en la figura anterior:
56
3.2. VISTA DE DESPLIEGUE
57
3.3. VISTA DE PROCESOS
Figura 3.4: Uso de Diagrama de Actividades para la Vista de Procesos del Consumidor
Fuente: Elaboración Propia
58
Figura 3.5: Uso de Diagrama de Actividades para la Vista de Procesos del Proveedor
Fuente: Elaboración Propia
Ahora bien, el siguiente gráfico es fundamental para explicar las actividades que se
realizan a nivel de servicios.
Figura 3.6: Uso de Diagrama de Actividades para la Vista de Procesos entre Procesos
Fuente: Elaboración Propia
59
3.4. VISTA FISICA
60
Capa EIA: Corresponde a la capa de Integración de aplicaciones sobre los
servicios de la capa CLOUD, esta perspectiva permite organizar mejor los
procesos IaaS, PaaS y SaaS.
Capa de Proveedores de servicio: Enmarca claramente el monitoreo y/o control
de ambas capas, a fin de garantizar un servicio acorde a los requerimientos de los
clientes.
61
3.5. ESCENARIOS
62
3.5.2. Vista Lógica a Vista de Despliegue
63
3.5.3. Vista de Procesos a Vista Física
64
3.5.1. Vista de Despliegue a Vista Física
El Hotel Real Plaza (Ex Hotel Radisson La Paz) – ubicado en la Av. Arce #2177 es uno de los
hoteles más reconocidos en la ciudad de la Paz, pertenecía a la cadena de Hoteles Radisson hasta
el año 2014, , dentro de sus plataformas de soluciones tiene instalado el sistema hotelero de
Micros Fidelio (adquirido por Oracle el 23 de junio del 2014). En la figura 3.12 se muestra como
esta implementado actualmente el sistema.
65
Figura 3.12: Implementación actual Hotel Real Plaza
Fuente: Elaboración propia
66
Se tiene previsto la actualización del sistema Opera, para lo cual se tiene los siguientes datos.
Compra de servidor: DELL PowerEdge T110 II SAS valor 2295.83 $us (cotización
adjunta en el ANEXO C)
Pago Licencia de Uso de Micros – Fidelio cada 6 meses: 7000 $us
Inversión y pago en un año es de 5295.83 $us.
Pago actual del servicio de Internet: 1910 Bs (velocidad de internet 2MB)
Pago de Ip público: 110 Bs
Una propuesta diferente es la de contar con el servicio Oracle Cloud el cual tendría la siguiente
propuesta gráfica.
67
En el grafico 3.14 se muestra la arquitectura de Oracle Cloud, y en lafigura 3.15 la arquitectura
basada en proveedores de servicio en conjunción con la de Oracle.
68
Figura 3.15: Arquitectura de Proveedores de servicio con Oracle Cloud Data
Fuente: Elaboración Propia
El hotel trabaja 24 Horas al día y los 365 días del año, teniéndose las siguientes observaciones:
Calculo al mes:
69
Al año sería: 8400 $us
Ahorro a obtener: 2295.83 $us (no se compraría el servidor) + 5600 al año de ahorro.
70
Contabilidad
Ventas
Reservas
Recepción
Ama de llaves
Tabla 3.5: Carga horaria de uso del sistema hotelero de Lunes a Viernes
71
12:00 – 14:30 10:00 Horario de almuerzo Recepción
personal de turno Reservas (turnante)
Ama de llaves
72
La suma de la carga horaria será:
Así el cálculo de pago por consumo por horas en el plan standard edition Service. Con
High-Memory Compute 197 * 1,176 = 231.84 $us al mes
El ahorro con respecto de un pago por mes es => 8400 – 2782.08 = 5617.92
73
CAPITULO 4
DEMOSTRACION DE HIPOTESIS
RESUMEN
74
4.1. OBTENCION DE DATOS
75
4.2. REALIZANDO LA PRUEBA DE HIPOTESIS
76
Obteniendo el resultado de la ecuación de T Student.
̅̅̅1 − 𝑋
𝑋 ̅̅̅2 405.254 − 184.507
𝑡= 𝑡= t= 2,95
𝜎2 𝜎2 √24759.97 + 31219.5962
√ 1+ 2
𝑛1 𝑛2 10 10
2
𝜎2 𝜎2 24759.97 31219.5962 2
( 𝑛 1 + 𝑛 2) ( 10 + 10 )
𝐺𝑙 = 1 2
−2 𝐺𝑙 = 2 −2
𝜎2
2
𝜎2
2 24759.97 31219.5962 2
(𝑛 −1 1) (𝑛 −1 1) ( 10 − 1 ) ( 10 − 1 )
1 +
𝑛1 + 2𝑛 10 10
2
Gl = 13.99 = 14
Así el valor obtenido de t=2.95 con 14 grados de libertad, teniendo también el valor
crítico que es 2.131 con una probabilidad de 0.05.
Gráfica:
77
Decisión:
Interpretación:
78
CAPITULO 5
CONCLUSIONES Y RECOMENDACIONES
RESUMEN
79
Ya para concluir en el desarrollo de la tesis presentada se contempla las siguientes
conclusiones y recomendaciones.
Conclusiones:
Está claro que se puede fusionar diferentes arquitecturas a fin de proyectar otra
como nueva solución.
La complejidad de la información no está en la cantidad de datos, mas al contrario
se encuentra en la ordenación de los procesos.
Los proveedores de servicio adecuan su infraestructura en base a los
requerimientos existentes.
Una idea es la generación de muchas nuevas ideas así como una solución es la
alternativa para otras soluciones.
Recomendaciones:
Una de las recomendaciones que considero muy importante es poder contar con
un servidor Cloud Universitario para desarrollo o investigación de nuevas
herramientas o aplicaciones.
Los precios obtenidos de las empresas de servicio pueden sufrir cambios o dejar
de estar vigentes, se recomienda ingresar a los links referidos en bibliografía.
80
REFERENCIA BIBLIOGRAFICA
81
BIBLIOGRAFIA
[2] Suh, W. (2005). Web Engineering Principies and techniques. United States:
Jhn Wiley
[3] Kale, V. (2015). Guide to Cloud Computing For business and technology
managers. Recuperado de http://dl.acm.org/citation.cfm?id=2723821#
[4] Li, Q., Wang, Z., Li, W., Li, J., Wang, C., Du, R. (2013). Applications
integration in a hybrid cloud computing environment: modelling and
platform. Enterprise Information Systems. 7(3), 273-271
[8] Alarcon, R. (2000). Diseño orientado a objetos con UML. Madrid: Grupo
Eidos
82
[14] Itil Foundation (2015).Proveedores de servicios. Recuperado de:
http://itilv3.osiatis.es/estrategia_servicios_TI/introduccion_objetivos_p
roveedores_servicios.php
[16] Guardado, B., Garcia, N., Melara, G., Rubio, N., Umanzor, F. (2012).
Software Libre y Comercial de Aplicación para el área de
Administración de Empresas. Universidad De El Salvador. El Salvador.
Recuperado de https://es.scribd.com/doc/84636708/2/%C2%BFQue-
es-un-Software-o-Aplicacion-Empresarial
83
[27] Rackspace (2015). Portal de Servicios Cloud. http://www.rackspace.com/
84
ANEXOS
ANEXO A : UML
DIAGRAMA DE CLASES
85
- Herencia: Un objeto es una instancia de una clase. Esta idea tiene una consecuencia
importante como instancia de una clase, un objeto tiene todas las características de la
clase de que que proviene. A eso se le conoce como herencia. No importa que
atributos y acciones decida usar de la clase Lavadora, cada objeto de la clase heredara
dichos atributos y operaciones. Ejemplo: la lavadora, el refrigerador, el horno
microondas y cosas por el estilo son subclases de la clase electrodomésticos.
86
DIAGRAMA DE COMPONENTES
DIAGRAMA DE DESPLIEGUE
87
Instancia de Nodo: Una instancia de nodo se puede mostrar en un diagrama. Una instancia
se puede distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos
puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre antes de los
dos puntos. El siguiente diagrama muestra una instancia nombrada de una computadora.
Asociación: En el contexto del diagrama de despliegue, una asociación representa una ruta
de comunicación entre los nodos. El siguiente diagrama muestra un diagrama de despliegue
para una red, mostrando los protocolos de red como estereotipos y también mostrando
multiplicidades en los extremos de la asociación.
Nodo como contenedor: Un nodo puede contener otros elementos, como componentes o
artefactos. El siguiente diagrama muestra un diagrama de despliegue para una parte del
sistema embebido y muestra un artefacto ejecutable como contenido por el nodo madre
(motherboard).
DIAGRAMAS DE ACTIVIDAD
Un diagrama de actividades ha sido diseñado para mostrar una visión simplificada de lo que
ocurre durante una operación o proceso. Es una extensión de un diagrama de estados. El
diagrama de estados muestra los estados de un objeto y representa las actividades como
88
flechas que conectan a los estados. El diagrama de actividades resalta, precisamente a las
actividades.
89
ANEXO B : SLA
Es un acuerdo negociado entre dos partes donde una de ellas es el cliente y la otra un
proveedor de servicios. Estos acuerdos pueden estar vinculados legalmente, o ser un contrato
informal (relaciones interdepartamentales). Constituye una herramienta que ayuda a ambas
partes a llegar a un consenso en términos del nivel de calidad del servicio, en aspectos tales
como tiempo de respuesta, disponibilidad horaria, documentación disponible, personal
asignado al servicio, etc.
También constituye un punto de referencia para el proceso de mejora continua, ya que el
poder medir adecuadamente los niveles de servicio es el primer paso para mejorarlos y de
esa forma aumentar los índices de calidad, KPI (del inglés Key Performance Indicator,
conocido como Indicador clave de desempeño o Indicador clave de rendimiento).
Los ANS definen un punto de entendimiento común sobre servicios, prioridades,
responsabilidades y garantías. Cada área de servicio debe tener un ANS definido, que
comprenda los niveles de disponibilidad, servicio, rendimiento u otros atributos del servicio,
como la facturación.
Los ANS se han utilizado desde finales de los años 80 por parte de operadores de
telecomunicaciones como parte de sus contratos con clientes empresariales. Esta práctica se
ha extendido hasta tal punto que actualmente es habitual que un usuario firme un contrato
con un proveedor de servicios que incluya una serie de ANS para prácticamente todos los
mercados.
Los departamentos de grandes corporaciones han adoptado también el sistema de acuerdos
de nivel de servicio respecto a los clientes internos, departamentos de la misma organización
ya que mediante este sistema se logra mejorar la calidad del servicio, así como se muestra
en la figura 7.
90
Figura 7: Contexto de un SLA
Fuente: [http://es.wikipedia.org/wiki/Acuerdo_de_nivel_de_servicio]
Los ANS están, por su naturaleza, basados en los resultados del servicio recibido por el
usuario como elemento del acuerdo. Las organizaciones también pueden definir y
especificar el sistema por el que el servicio debe ser cumplido mediante una especificación
(especificación del nivel de servicio). Este tipo de acuerdo recibe el nombre de input SLA,
aunque este tipo de acuerdo ha quedado obsoleto ya que las organizaciones permiten a los
proveedores seleccionar el método de cumplimiento de los acuerdos.
91
ANEXO C : COTIZACION DE SERVIDORES
92
93
DOCUMENTOS
94
La Paz, Diciembre de 2015
Señor
M. Sc. Edgar Palmiro Clavijo Cárdenas
DIRECTOR CARRERA DE INFORMATICA
FACULTAD DE CIENCIAS PURAS Y NATURALES
UNIVERSIDAD MAYOR DE SAN ANDRES
Presente
De mi mayor consideración:
c.c./ Arch
La Paz, Diciembre de 2015
Señor
Lic. Javier Hugo Reyes Pacheco
TUTOR METODOLOGICO
Presente
De mi mayor consideración:
Tengo a bien dirigirme a su persona, para darle a conocer que luego de efectuar el
seguimiento a la estructura y contenido de la Tesis de Grado titulado: “IMPLEMENTACIÓN DE
ARQUITECTURA BASADA EN PROVEEDORES DE SERVICIOS PARA APLICACIONES EMPRESARIALES
INTEGRADAS EN LA NUBE”, elaborado por el Universitario: MAXIMILIANO REYES ULU CALLO, con
C.I. 4337403 L.P., en calidad de Asesor expreso mi conformidad con el contenido y la forma de
trabajo, dando mi Aval, para que el postulante pueda realizar la defensa de la Tesis de Grado,
para optar al título de Licenciado en Informática mención Ingeniería de Sistemas Informáticos, de
acuerdo a normas y reglamento vigentes.
Sin otro particular, me suscribo de su persona con las consideraciones más distinguidas.
c.c. Arch.