ActividadGrupal_Ejemplos_AS - Brigith Lojan

Vista previa del material en texto

UNIVERSIDAD NACIONAL DE LOJA 
FACULTAD DE LA ENERGÍA, LAS INDUSTRIAS Y LOS RECURSOS NATURALES NO 
RENOVABLES 
DISEÑO DE SOFTWARE 
CUARTO CICLO 
ARQUITECTURA DE SOFTWARE 
 TEMA: 
Ing. María Ruilova 
Paulina Chalco 
Brigith Lojan 
Lizbeth Quezada 
Gerardo Quizhpe 
 
Busque 20 ejemplos de arquitectura de software, arme un documento con cada ejemplo 
y especificación. 
 
Ejemplo 1: 
 
Sistema de reservas médicas 
 
El sistema de reservas médicas está diseñado para que se ejecute en un servidor que posea 
un contenedor web y un servidor de aplicaciones que maneje las transacciones y seguridad 
de la aplicación. 
La capa de presentación (vista y controlador) se ejecutarán en el contenedor web, las capas 
de negocio y persistencia (modelo) se ejecutarán en un servidor de aplicaciones. Para poder 
desplegar la aplicación es necesario contar con un servidor web como por ejemplo (apache) 
y un servidor de aplicaciones que posea servicios web 
La separación por capas se hizo para que la aplicación sea fácilmente escalable. 
El servidor web se comunica con el servidor de aplicaciones mediante servicios web 
La aplicación interactúa con una base de datos a través de una capa de persistencia, por 
ejemplo, Oracle a través de Hibernate 
 
Ejemplo 2: 
 
Arquitectura de un sistema bibliotecario de películas e imágenes. 
 
https://eva.unl.edu.ec/mod/url/view.php?id=1555782
 
 
 
EL modelo de arquitectura de un sistema bibliotecario está diseñado para llevar un control de 
las películas e imágenes que iche biblioteca posee, tiene varias ventajas como: 
• La distribución de datos es directa. 
• Permite el uso efectivo de sistemas de red. 
• Generalmente requiere hardware barato. 
• Es fácil añadir nuevos servidores o actualizar los existentes. 
 
Ejemplo 3: 
 
Arquitectura de software para el sistema de visualización médica Virmedic. 
 
La arquitectura sobre la que se desarrollan actualmente los productos se basa 
fundamentalmente en el empleo de capas y módulos, con el objetivo de agrupar las 
funcionalidades y delimitar las responsabilidades de los elementos que componen las 
aplicaciones. El proyecto Virmedic cuenta actualmente con dos productos (Visualizador 2D y 
Visualizador 3D). Como se observa en la figura. La arquitectura cuenta con una capa que 
representa el núcleo básico (Core) para los productos a desarrollar, esta capa se encuentra 
dividida en módulos que ofrecen funcionalidades comunes para las aplicaciones de 
visualización de imágenes médicas digitales. Dentro del módulo Plugin, perteneciente a la 
 
capa Core, se definen las interfaces a implementar para extender las aplicaciones mediante 
plugins, es necesario señalar que, en estos momentos, solo el Visualizador 2D hace uso de 
estos. 
 
Ejemplo 4: 
 
Modelo de tres capas para una arquitectura de software distribuida homogénea 
 
 
En la capa de Presentación se distribuye la lógica del cliente respectiva y parte de la lógica 
de la aplicación (a través de los applets). Los applets pueden ser ejecutados potencialmente 
en cualquier navegador y pueden invocar tanto métodos locales como remotos. Para ejecutar 
métodos de objetos remotos, Java posee el mecanismo RMI que permite la comunicación 
con el servidor de una manera transparente para el usuario. Este mecanismo será descrito 
en párrafos siguientes. En la capa de Aplicación, se encuentra básicamente el servidor Web 
y el servidor de aplicaciones (o varios). Esta capa implementa gran parte de la lógica de 
negocio específica del dominio; además se encarga de la manipulación de los datos (con la 
capa de Datos) y de la comunicación y manejo de eventos con el dispositivo físico –ver fig. 1. 
Para la manipulación de los datos, Java utiliza una interfaz de acceso a bases de datos 
llamada JDBC la que será presentada en la siguiente sección. En la capa de Datos se 
encuentra toda la información a la que tendrá acceso la aplicación servidora. La comunicación 
entre ambas capas se realiza a través del protocolo DBMS. Por otra parte, para la 
comunicación con el dispositivo físico, se utiliza la facilidad de métodos nativos (protocolo 
JNI), los que permiten ejecutar código no-Java desde clases Java. Esta estrategia puede ser 
una buena elección para el diseño e implementación cuando hay que integrar sistemas 
existentes o componentes desarrollados en diferentes ambientes o lenguajes. La 
característica principal de los ambientes homogéneos es que, tanto el cliente como el servidor 
deben estar implementados en el mismo lenguaje para permitir su intercomunicación. El 
mecanismo RMI permite distribuir las tareas o procesos sobre otros objetos en la red. Es 
decir, no sólo se puede realizar paralelismo local (threads) sino también paralelismo global 
(en otras máquinas, potencialmente con otros SO, etc.). Esta invocación a un objeto remoto 
es transparente al usuario, ya que éste no conoce en qué máquina reside físicamente dicho 
objeto, sino que los objetos remotos son vistos por el cliente como objetos locales. La 
transparencia es un atributo esencial de los sistemas distribuidos. 
 
 
 
Ejemplo 5: 
 
Solución informática para la gestión de cupos en prácticas pre-profesionales y 
pasantías. 
 
En este apartado se detalla cómo está conformado cada una de las partes que compone la 
solución informática, se detalles la aplicación móvil, la aplicación web y el servicio APIREST 
 
Ejemplo 6: 
 
Arquitectura de extensión del sistema de gestión de aprendizaje y el sistema 
adaptativo 
 
 
Se presenta la arquitectura de extensión del sistema de gestión de aprendizaje y el sistema 
adaptativo. Se presenta la adición de la lógica a nivel de los componentes de administración. 
También se presenta la extensión a la base de datos, la cual se soporta mediante el gestor 
MySQL. El bloque de lógica de negocio se comunica mediante un controlador AJAX a la base 
de datos de Moodle, teniendo en cuenta que el conjunto de servicios se lleva a cabo en el 
cliente y los usuarios se comunican con el servidor de forma transparente. Este controlador 
permite el desarrollo de aplicaciones y se sincroniza con un servidor. Para la extensión a nivel 
 
de los datos se usó un servidor PHP, el cual permite diseño web y se puede incorporar en 
HTML. 
 
Ejemplo 7: 
 
Arquitectura software de la plataforma virtual y remota 
 
 
Como se puede observar, la plataforma está compuesta por diferentes componentes de 
software dentro de los cuales se encuentra un instrumento virtual desarrollado en LabVIEW 
presente en el computador servidor del laboratorio, esta cuenta con una interfaz gráfica de 
usuario, un módulo de comunicación para un dispositivo joystick, y el modelo cinemático que 
se comunica tanto con una versión simulada en 3D del Robot cuyas partes fueron modeladas 
en el software Autodesk Inventor, como con el módulo para la manipulación del robot real. 
Por el lado del cliente se tiene una aplicación en Java para el acceso remoto, la cual también 
cuenta con el modelo cinemático del robot dentro de su núcleo y un modelo en 3D del brazo 
robótico diseñado por medio de java 3D. 
 
Ejemplo 8: 
 
Desarrollo de una herramienta de análisis y diseño de sistemas que permita la 
documentación de software basada en UML 2.0 y la generación de código fuente bajo 
la especificación del lenguaje programación C Sharp (ECMA-334) 
 
 
La arquitectura establecida para la construcción de la herramienta AleDan UML se 
basa en el desarrollo de software por capas, tal y como se indica en los puntos detallados a 
continuación: 
Se utiliza una arquitectura de cuatro capas claramente identificadas: Modelo, Bean, 
Controlador y Vista. 
La capa Modelo es la que tiene los objetos persistentes del dominio, es decir, encierra a las 
entidades. Además de ello cuenta con la capa UI, misma que se encarga de dibujar todos los 
objetos de modelo. 
Bean es la capa dirigida a la manipulación oedición de los objetos persistentes del Modelo. 
Esta capa a su vez provee las subcapas BeanInfo, PropertyEditor y Render. 
BeanInfo es la que describe la información de un objeto persistente indicando las propiedades 
que posee y los métodos de lectura y escritura para dichas propiedades; 
PropertyEditor son editores que pueden ser asociados a una propiedad determinada de un 
objeto persistente, o bien, a una clase de objetos; Render por su parte, es la que permite 
representar gráficamente un tipo de dato. 
La capa Controlador, es la responsable de dar funcionalidad a la Vista, interactúa con el 
Modelo los archivos de proyecto *.adu en una unidad de almacenamiento, y conjuntamente 
con los Bean, carga las propiedades en las 
vistas. 
 
Ejemplo 9: 
Banca electrónica para la cooperativa de ahorro y crédito de la pequeña empresa de 
Loja CACPE Loja. 
 
 
El modelo de la aplicación web Banca Electrónica se encuentra basado en una arquitectura 
de tres capas y básicamente consiste en: 
Capa de Interfaz de Usuario (para facilitar al usuario el uso del sistema) 
En esta capa se diseñó todo lo que constituye la interfaz gráfica y la interacción del usuario 
con el sistema. Esta capa se comunica únicamente con la capa de negocio. Básicamente 
contiene: 
● WebForm: páginas web con la configuración básica de la interfaz. 
● UserControl: los controles de usuario que nos permiten capturar los datos en los 
distintos formularios. 
● MasterPage: contiene las páginas de configuración para los WebForm Universidad 
Nacional de Loja BancaWeb – CACPE Loja Ingeniería en Sistemas 192 
● ControlInterfaz: contiene a las controladoras de interfaz, las cuales tendrán la 
responsabilidad de proporcionar los datos y una lógica de estos realizando consultas 
a servicios web. 
Capa de Negocio (para centralizar la lógica de la actividad) 
Esta capa define la lógica de comportamiento de la aplicación, contiene la lógica de negocio 
y las tareas para enviar las respuestas a las peticiones del usuario realizadas desde la capa 
de interfaz. Y además se comunica con la capa de datos para almacenar y recuperar 
información de la base de datos a través de los objetos de negocio siguiendo el patrón DTO. 
Un objeto de negocio se construye a partir de una clase que únicamente contiene 
propiedades, que se corresponderá en la mayoría de los casos con los campos que 
conforman cada tabla. Su misión principal es servir de contenedor destinado exclusivamente 
a la transferencia de información. La capa de negocio se compone de: 
● Entidades: contiene clases entidad o persistentes de la aplicación. 
 
● Controladoras: contiene a las controladoras del negocio, las cuales tendrán roles para 
acceder, filtrar, buscar, eliminar, modificar, entre otros. 
● Reutilizables: contiene objetos que pueden ser reutilizados, como DataSet y el patrón 
DTO (Data Transfer Object) los cuales permiten la manipulación de los datos de 
manera offline es decir fuera de conexión del gestor de base de datos. En la Banca 
Electrónica se corresponden a la librería de clases dtoWeb.cs. 
Capa de Acceso a los Datos (para guardar los datos) 
Es la encargada de realizar la lógica de acceso a los datos que están almacenados en la base 
de datos o archivos XML. Esta capa incluye la configuración del acceso a otros servicios web 
o a otras aplicaciones (Agentes de Servicio). De esta manera en esta capa se tiene: 
● Agentes de servicio: contiene a controladoras que permiten acceder a otros Servicios 
Web (ServicioWebPagoAgua, ServicioWebPagoLuz, ServicioWebPagoTeléfono) que 
no pertenecen a la aplicación en desarrollo (Banca Electrónica) pero necesitan datos 
de estas. También se utiliza esta capa para la comunicación entre subsistemas de la 
aplicación Universidad Nacional de Loja BancaWeb – CACPE Loja Ingeniería en 
Sistemas 193 Es necesario indicar que en el desarrollo de la Banca Electrónica se 
hizo uso del Data Access Aplication Block que es parte del framework Enterprise 
Library y que nos sirve para el acceso a los datos desde el asp.net. 
Ejemplo 10: 
 
Arquitectura para un sistema de Cine de Barrio: Venta de entradas online 
 
 
Como se puede observar, se ha dividido la aplicación en una arquitectura distribuida en tres 
capas (Modelo-Vista-Controlador), donde la parte del modelo ha sido desarrollada en base a 
un servicio web de .NET , logrando la persistencia de los datos mediante el uso de Db4objects 
. El servicio web ofrece una API que se accede desde una aplicación web J2EE (Servlets) 
mediante el uso de la plataforma AXIS . Esta sub-aplicación J2EE genera una vista mediante 
páginas dinámicas JSP en combinación con Ajax (Librerías DWR). 
Por último, y debido al hecho de que hacer la práctica en grupo obliga a utilizar algún gestor 
de contenidos, hemos decidido utilizar Joomla (posiblemente uno de los CMS más extendidos 
 
y distribuido bajo licencia GNU/GPL) como base donde montar la aplicación, necesitando de 
la tecnología PHP y de la base de datos MySQL para su implementación también. 
Por tanto, la siguiente lista muestra un resumen de las tecnologías empleadas: 
● Servicios WEB XML (C#) en la plataforma .NET de Microsoft 
● Servicios WEB XML (Java) en la plataforma AXIS de Apache 
● Base de datos para objetos: Db4o 
● PHP y MySQL para Joomla 
● Servlets y JSPs 
● Servidores Web Apache e IIS 
● Contenedor de aplicaciones Apache TOMCAT 
● XML-FO y Apache FOP para la creación dinámica de entradas 
● Marco DWR para Ajax 
● JavaScript 
● JDom para la gestión de XML 
● XHTML para las páginas web 
Además de todas las tecnologías anteriores, cabe destacar que también se ha hecho uso de 
un recurso ofrecido por Google Maps a través de su API pública, de modo que se ha 
construido un pequeño mashup para mostrar la localización exacta del cine (Obviamente, en 
este caso, de la facultad). 
 
Ejemplo 11: 
Diseño e implementación de una tienda virtual para la venta de equipos informáticos 
para la empresa "SETCOMPC" de la ciudad de Loja. 
Arquitectura por Capas 
En cuanto a la arquitectura que se implementa en el proyecto Web de ventas online es una 
arquitectura en capas, de tal forma que permita tener los componentes separados. La 
solución como se mencionó anteriormente está basada en el modelo de componentes por 
capas, tal como nos muestra la figura: 
 
 
 
 
 
 
 
 
 
 
Capa de Presentación 
Dicha capa permitirá al usuario alcanzar una forma de interacción con la aplicación, nuestra 
interfaz de usuario se implementará utilizando las páginas Microsoft ASP.NET, que permitirán 
procesar y dar formato a los datos de usuario, así como registrar y validar los datos 
procedentes de éstos. Además, en esta capa se han implementado funciones JavaScript y 
técnicas de AJAX.Net que permiten mejorar el rendimiento de la aplicación 
Capa Empresarial 
La capa empresarial o capa de negocios puede constar de un único paso o de un flujo de 
trabajo organizado para alcanzar un objetivo determinado dentro de nuestro sistema, desde 
luego el sistema requerirá el uso reglas de negocio que definen su funcionamiento. Es de 
suma importancia cada tarea sea encapsulada en un solo método. 
Capa de Acceso a Datos 
La capa de acceso a datos permite que la aplicación pueda tener una participación de los 
datos existentes y registrados en su base de datos. Este proceso puede ser de consulta o de 
grabado según corresponda. El origen de los datos puede ser uno o más. 
Ejemplo 12: 
Desarrollo de una aplicación WEB que permita la gestión de reservaciones y 
generación automática de calendarios deportivos para la cancha sintética zona fútbol. 
Diseño arquitectónico 
Para tener en claro todos los detalles del sistema y saber cómo está constituido la estructura 
de los datos y los componentes del mismo, es necesario realizar el diseño arquitectónico del 
sistema. La arquitectura que maneja el sistema sigue el modelo de 3 capas como se muestra 
a continuación. 
 
 
Capade presentación. - Encargada de generar la interfaz de usuario y se comunica 
directamente con la capa de negocio. 
Capa de Negocio. - Contiene la lógica que modela los procesos del negocio y en donde se 
llevan a cabo las peticiones de los usuarios. En esta capa se establecen las reglas a 
cumplirse. 
Capa de Datos. - Encargado de abastecer toda la información necesaria a la capa de 
negocio. 
Ejemplo 13: 
Sistema de gestión académica vía web para el Colegio Fiscomisional La Dolorosa. 
Arquitectura J2EE 
“La especificación de J2EE define su arquitectura basándose en los conceptos de capas, 
containers, componentes, servicios y las características de cada uno de éstos. Las 
aplicaciones J2EE están divididas en cuatro capas: la capa cliente, la capa web, la capa 
negocio y la capa datos. 
 
Capa Cliente: Esta capa corresponde a lo que se encuentra en el computador del cliente. Se 
constituye en la interfaz gráfica del sistema y se encarga de interactuar con el usuario. J2EE 
tiene soporte para diferentes tipos de clientes incluyendo clientes HTML, applets Java y 
aplicaciones Java. 
Capa Web: Se encuentra en el servidor web y contiene la lógica de presentación que se 
utiliza para generar una respuesta al cliente. Recibe los datos del usuario desde la capa 
cliente y basado en éstos genera una respuesta apropiada a la solicitud. J2EE utiliza en esta 
 
capa los componentes Java Servlets y JavaServer Pages para crear los datos que se 
enviarán al cliente. 
Capa Negocio: Se encuentra en el servidor de aplicaciones y contiene el núcleo de la lógica 
del negocio de la aplicación. Provee de las interfaces necesarias para utilizar el servicio de 
componentes del negocio. Las componentes del negocio interactúan con la capa de datos. 
Capa Datos: Esta capa es responsable del sistema de información de la empresa que incluye 
bases de datos, sistema de procesamiento de datos. 
Ejemplo 14: 
Sistema de Gestión Médica para el departamento de Bienestar Estudiantil y Policlínico 
de Motupe. 
Arquitectura cliente-servidor de 3 capas 
 
En este modelo, toda la lógica de negocios es extraída fuera de la aplicación ejecutándose 
en el cliente. La aplicación en cada cliente es responsable de la interfaz de usuario y de 
comunicarse con la capa de la lógica de negocio. Ya no es más la responsable de 
implementar reglas de negocio ni acceso a la base de datos. Su trabajo es solamente como 
una capa de presentación. Las tres capas que conforman esta arquitectura son: 
Lógica de presentación: Contiene todo lo relativo a la presentación (ventanas, informes, 
textos, sonidos, video) hacia el usuario y toda la interacción con el mismo a través de teclado, 
ratón y micrófonos, etc. 
Lógica de aplicación: Contiene los algoritmos, procesos y ‘workflows’ de la aplicación. Es la 
esencia de la aplicación propiamente dicha. 
Lógica de datos: Gestiona todo lo relativo al almacenamiento y recuperación de datos. 
 
 
 
Ejemplo 15: 
Arquitectura para el desarrollo de aplicaciones web 
 
 
Esta separación permite dividir el aplicativo en módulos más mantenibles y sencillos de 
evolucionar. 
En general la arquitectura de referencia del SAS está basada en el patrón Boundary Control 
Entity (BCE), esta se aplicará si no se especifica lo contrario. 
Como puede observarse, la arquitectura propuesta es independiente de la tecnología a usar, 
siendo válida tanto para los desarrollos realizados en Java como .NET. Además, es 
importante destacar que la propuesta que aquí se presenta es un modelo a seguir de forma 
obligatoria por todos los proveedores de software, si bien es posible la modificación de la 
misma si fuera necesario, para lo cual será necesario presentar y justificar una propuesta de 
cambio a la STIC para su valoración y aceptación. 
 
Ejemplo 16: 
 
Desarrollo e implantación de un sistema de gestión de proyectos para la constructora 
"DISYCONS" (diseño y construcción). 
 
 
El aspecto más relevante de Seam es la forma en la que integra el uso de varias tecnologías 
ya existentes para la creación de aplicaciones web en Java para facilitar la implementación 
del patrón MVC4 de una forma que resulta más intuitiva para desarrollador y más rápida de 
programar, pero sin perder la potencia y las 
características que provee JEE. En la figura 3 se puede visualizar la arquitectura del sistema 
con Seam. 
 
Ejemplo 17: 
 
Desarrollo e implementación de un proyecto de Software Libre con entorno WEB para 
Cooperativas de Ahorro y Crédito, orientado a Asociaciones de Precooperativa de 
Ahorro y Crédito Kiskinchir, Caja Solidaria Ñauparina del Cantón Saraguro de la 
Provincia de Loja 
 
 
Symfony toma lo mejor de la arquitectura MVC y la implementa de forma que el desarrollo de 
aplicaciones sea rápido y sencillo. 
En primer lugar, el controlador frontal y el layout son comunes para todas las acciones de la 
aplicación. Se pueden tener varios controladores y varios layouts, pero solamente es 
obligatorio tener uno de cada. El controlador frontal es un componente que sólo tiene código 
relativo al MVC, por lo que no es necesario crear uno, ya que Symfony lo genera de forma 
automática. 
La otra buena noticia es que las clases de la capa del modelo también se generan 
automáticamente, en función de la estructura de datos de la aplicación. La librería Propel se 
encarga de esta generación automática, ya que crea el esqueleto o estructura básica de las 
clases y genera automáticamente el código necesario. 
Cuando Propel encuentra restricciones de claves foráneas (o externas) o cuando encuentra 
datos de tipo fecha, crea métodos especiales para acceder y modificar esos datos, por lo que 
la manipulación de datos se convierte en un juego de niños. La abstracción de la base de 
datos es completamente transparente para el programador, ya que se realiza de forma nativa 
mediante PDO (PHP Data Objects). Así, si se cambia el sistema gestor de bases de datos en 
cualquier momento, no se debe reescribir ni una línea de código, ya que tan sólo es necesario 
modificar un parámetro en un archivo de configuración. 
Por último, la lógica de la vista se puede transformar en un archivo de configuración sencillo, 
sin necesidad de programarla. 
 
Ejemplo 18: 
 
Arquitectura de Software para el Soporte de Comunidades Académicas Virtuales en 
Ambientes de Televisión Digital Interactiva 
 
 
 
 
En la arquitectura propuesta el televisor es un elemento de despliegue de información. Siendo 
el STB el encargado de manejar la interactividad a nivel de usuario, pues es el dispositivo que 
recibe las peticiones o eventos del usuario y las envía a través del canal de retorno pasando 
por el mediador hasta el directorio de servicios. Las peticiones son generadas por el STB y 
tienen el formato de los mensajes HTTP (GET y PUT) del protocolo REST, razón por la cual, 
el STB debe permitir el soporte de librerías para el procesamiento de los mensajes de 
respuesta en formato JSON. Otra de las funciones que cumple el STB es determinar la 
disposición y las características gráficas de los servicios en la pantalla del televisor (colores, 
tipos de fuente, etc); para ello es necesario tener en cuenta las recomendaciones para 
despliegue de contenidos de TDi propuestas en Campo et al. [2010b]. De estas 
recomendaciones se destaca la referente a la ubicación de los servicios a la derecha de la 
pantalla, dándole mayor importancia al contenido multimedia. 
Además de lo anterior es importante tener en cuenta, que la mayoría de los servicios de las 
CAV, requieren el uso de texto para su interacción (Chat, Foros, Wikis, entre otros), es por 
ello recomendable que el STB cuente con interfaces opcionales que le permitan conectarse 
con otros dispositivos que faciliten la interacción como por ejemplo, un teclado, micrófono, 
controles remoto adicionales, entre otros. 
Ejemplo 19: 
Uso de Ontologías para mapear una Arquitectura de Software consu Implementación 
 
 
La ausencia de mapeos entre la arquitectura de un sistema y su implementación dificulta: el 
entendimiento del código en relación a su diseño arquitectónico original, el mantenimiento 
evolutivo del sistema y la práctica de chequeo de conformidad arquitectural. Por esta razón, 
en este trabajo se propone un enfoque para la generación automática de mapeos que permita 
identificar correspondencias entre elementos de la arquitectura y su implementación (Figura 
1). A partir de una descripción de la arquitectura y del código fuente, se definen dos 
ontologías, denominadas “ontología arquitectónica” y “ontología de la implementación”, 
respectivamente. Luego, estas dos ontologías son tomadas como entradas por el proceso de 
alineación, el cual tiene como objetivo encontrar las correspondencias entre ambas 
ontologías. Dicho proceso está compuesto por tres actividades: emparejamiento, cómputo de 
similitud y agrupamiento. En el emparejamiento, se generan todas las posibles parejas entre 
las entidades de las dos ontologías. A partir de este emparejamiento, se realiza el cómputo 
de similitud de cada pareja de entidades basándose en sus características. Luego del 
cómputo de similitud se realiza el agrupamiento de las parejas de entidades de acuerdo al 
grado de similitud presentado entre estas. Finalmente, se selecciona como resultado de la 
alineación el grupo que posee parejas de mayor similitud, las cuales se presentan como salida 
al usuario. 
Ejemplo 20: 
Una arquitectura de software para la integración de objetos de aprendizaje basada en 
servicios web. 
 
 
La forma más habitual de implementar una aplicación orientada a servicios es mediante 
Servicios Web, una tecnología basada en estándares e independiente de la plataforma. 
Básicamente, una aplicación orientada a servicios es una colección de servicios web 
distribuidos. Estos servicios se comunican entre sí. Esta comunicación puede involucrar 
simplemente el paso de datos o la coordinación de alguna actividad entre varios servicios. 
Las tecnologías que definen la arquitectura de un Servicio Web se pueden observar en la 
figura 1. 
 
Bibliografía: 
● 2.2. Interfaces del Sistema - Documento de Arquitectura de Software para Sistema 
Reserva de Horas Médicas. (s. f.). ArqSoftware. 
https://sites.google.com/site/softwarearchitecturedocument/proposito/2-2-interfaz-del-
sistema 
● Peña, R. A. D. (s. f.). Arquitectura de software para el sistema de visualización médica 
Vismedic. Scielo. http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1684-
18592016000100006 
● Modelo de tres capas para una arquitectura de software distribuida homogénea. (s. f.). 
researchgate. Recuperado 19 de enero de 2022, de 
https://www.researchgate.net/figure/Modelo-de-tres-capas-para-una-arquitectura-de-
software-distribuida-homogenea_fig1_334958467 
● Mendoza, J. X. (s. f.). Solución Informática. dspace.unl.edu.ec. 
https://dspace.unl.edu.ec/jspui/bitstream/123456789/24319/1/JhonyXavier_MendozaJ
ap%C3%B3n.pdf 
https://sites.google.com/site/softwarearchitecturedocument/proposito/2-2-interfaz-del-sistema
https://sites.google.com/site/softwarearchitecturedocument/proposito/2-2-interfaz-del-sistema
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1684-18592016000100006
http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1684-18592016000100006
https://www.researchgate.net/figure/Modelo-de-tres-capas-para-una-arquitectura-de-software-distribuida-homogenea_fig1_334958467
https://www.researchgate.net/figure/Modelo-de-tres-capas-para-una-arquitectura-de-software-distribuida-homogenea_fig1_334958467
https://dspace.unl.edu.ec/jspui/bitstream/123456789/24319/1/JhonyXavier_MendozaJap%C3%B3n.pdf
https://dspace.unl.edu.ec/jspui/bitstream/123456789/24319/1/JhonyXavier_MendozaJap%C3%B3n.pdf
 
● (N.d.). Revistaespacios.Com. Retrieved January 20, 2022, from 
https://www.revistaespacios.com/a20v41n06/a20v41n06p14.pdf 
● (N.d.-b). Researchgate.Net. Retrieved January 20, 2022, from 
https://www.researchgate.net/figure/Arquitectura-software-de-la-plataforma-virtual-y-
remota-Fuente-Autores-Como-se-puede_fig3_319149270 
● Quinche, G. E. R. (2016, 4 julio). Repositorio Digital - Universidad Nacional de Loja: 
Desarrollo de una herramienta de análisis y diseño de sistemas que permita la 
documentación de software basada en UML 2.0 y la generación de código fuente bajo 
la especificación del lenguaje programación C Sharp (ECMA-334). dspace. 
https://dspace.unl.edu.ec/jspui/handle/123456789/14455 
● Carrión, T. H. L. (2016, 23 junio). Repositorio Digital - Universidad Nacional de Loja: 
Desarrollo e implantación de un sistema de gestión de proyectos para la constructora 
«DISYCONS» (diseño y construcción). Dspace. 
https://dspace.unl.edu.ec/jspui/handle/123456789/14274 
● Pilco Muñoz, J. Sistema de Gestión Médica para el departamento de Bienestar 
Estudiantil y Policlínico de Motupe.. Dspace.unl.edu.ec. Retrieved from 
http://dspace.unl.edu.ec/jspui/handle/123456789/14486. 
● Ayala Martínez, B., & Cabrera Cueva, J. Banca electrónica para la cooperativa de 
ahorro y crédito de la pequeña empresa de Loja CACPE Loja.. Dspace.unl.edu.ec. 
Retrieved from http://dspace.unl.edu.ec/jspui/handle/123456789/14389. 
● Hidalgo Méndez, G., & Samaniego Ramón, L. Diseño e implementación de una tienda 
virtual para la venta de equipos informáticos para la empresa "SETCOMPC" de la 
ciudad de Loja.. Dspace.unl.edu.ec. Retrieved from 
http://dspace.unl.edu.ec/jspui/handle/123456789/14514. 
● Romero, C. E. L. (2016, 30 junio). Repositorio Digital - Universidad Nacional de Loja: 
Desarrollo e implementación de un proyecto de Software Libre con entorno WEB para 
Cooperativas de Ahorro y Crédito, orientado a Asociaciones de Precooperativa de 
https://www.revistaespacios.com/a20v41n06/a20v41n06p14.pdf
https://www.researchgate.net/figure/Arquitectura-software-de-la-plataforma-virtual-y-remota-Fuente-Autores-Como-se-puede_fig3_319149270
https://www.researchgate.net/figure/Arquitectura-software-de-la-plataforma-virtual-y-remota-Fuente-Autores-Como-se-puede_fig3_319149270
https://dspace.unl.edu.ec/jspui/handle/123456789/14455
 
Ahorro y Crédito Kiskinchir, Caja Solidaria Ñauparina del Cantón Saraguro de la 
Provincia de Loja. Dspace. https://dspace.unl.edu.ec/jspui/handle/123456789/14403 
● Imaicela Sarango, J., & Ordóñez Mediavilla, A. Desarrollo de una aplicación WEB que 
permita la gestión de reservaciones y generación automática de calendarios deportivos 
para la cancha sintética zona futbol.. Dspace.unl.edu.ec. Retrieved from 
http://dspace.unl.edu.ec/jspui/handle/123456789/14291. 
● Viñan Ludeña, M., & Vivanco Encalada, B. Sistema de gestión académica vía web para 
el Colegio Fiscomisional La Dolorosa.. Dspace.unl.edu.ec. Retrieved from 
http://dspace.unl.edu.ec/jspui/handle/123456789/14454. 
● Vázquez, H. C. (2016, 23 septiembre). Uso de ontologías para mapear una arquitectura 
de software con su implementación. CICDigital. 
https://digital.cic.gba.gob.ar/handle/11746/4297 
 
 
 
 
http://dspace.unl.edu.ec/jspui/handle/123456789/14454
https://digital.cic.gba.gob.ar/handle/11746/4297