Facultad de Ingeniería

Arquitectura de Software

Laboratorio #4

Realizado por:

Grupo 2B - PinArt

Profesor:

Jeisson Andres Vergara Vargas

Cundinamarca
Bogotá, Colombia
24 de Abril de 2020
i. Requisitos: Equipos de Proyectos Reunidos

Integrantes:

Elsa Johanna Arias Muñoz

Andres Felipe Castillo Sopo

Camilo Andres Gil Ballen

Juan Camilo Monterrosa Sanchez

Tom Erick Perez Alvarez

Ronald Alexander Sarmiento Galviz

ii. Componente Web

1. Indagar acerca de las diferentes estrategias de diseño e implementación de componentes
de software Front-End de tipo web. Hacer énfasis en las sub-arquitecturas de dichos
componentes

Angular
Es un framework para aplicaciones web desarrollado en TypeScript, de código
abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web
de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador
con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que
el desarrollo y las pruebas sean más fáciles. La idea es usar los módulos que ofrece
angular para separar las responsabilidades.

Así que se detalla la construcción de la arquitectura desde este framework:

Módulo en angular: Su propósito es organizar las partes de la aplicación. Ordenando

la misma en bloques. Permitiendo extender nuestra aplicación con funcionalidades
de librerías externas. Permite a angular saber las importaciones/exportaciones
necesarias para que cierto componente funcione.

En concreto un módulo angular declara los componentes, directivas y pipes. E inicia

(bootstraps) de forma visual (el html/css) esos componentes para que sean visibles.
Luego, los módulos angular definen un template resolution environment, de forma
que los componentes declarados en este módulo sólo pueden usar módulos,
componentes, directivas y pipes declarados en el mismo.

Además, exporta otros módulos, ya sean nuestros, de angular o de librerías de

terceros, al igual que puede exportar componentes, directivas o pipes.

También Importa módulos y como añadido proveen de servicios, lo cual significa

que hacen disponibles los servicios para todos los componentes, directivas y pipes
que estén declaradas en ese módulo.

React + Redux

En el caso de React se estaría usando un concepto de arquitectura llamado Flux. Flux

es una subarquitectura que maneja Facebook a la hora de trabajar con React, no es
una librería ni un framework. Simplemente es una forma de complementar la forma
en la que trabaja React, agregando la idea de flujo de datos unidireccional.

Pero Flux se entiende mejor hablando de los componentes individuales que

constituyen esta subarquitectura. Estos son:

• Actions: Son métodos que cumplen la labor de “Helpers” y pasan data o

información al “Dispatcher”
 • Dispatcher: Recibe las acciones y cumple la distribución de trabajo a los
callbacks registrados.
• Stores: Contenedores para el “state” de la aplicación y donde se almacenan
los callbacks registrados para en el “Dispatcher”
• Controller Views: Componentes de React que usan el “state” guardado en
los Stores y lo pasan a sus componentes hijos.

A continuación, una vista de cómo sería el proceso dentro de react usando Flux como
subarquitectura.

Dispatcher: El “Dispatcher” es básicamente el gerente de todo este proceso. Es el

eje central de la aplicación. Este recibe las acciones y devuelve las acciones a realizar
y los datos que deben ser registrados en los callbacks.

Los métodos de la aplicación llaman al “Dispatcher”, el cual envía la carga de trabajo

a todos los callbacks registrados. Esta acción puede, entonces ser accionada dentro
de los Stores y va a tener como resultado un cambio de estado.

Un diagrama que explica lo previamente descrito viene siendo el siguiente:

Stores: En Flux, los Stores manejan los estados dentro de la aplicación para un
dominio concreto. Desde un punto de vista de alto nivel, esto básicamente significa
que por cada “sección” de la aplicación, los stores manejan los datos, la recuperación
de datos de los métodos y los callbacks del “Dispatcher”. Es importante tener en
cuenta que cada vez que hay un cambio de evento, los Controller Views relacionados
con el store van a estar escuchando y también cambiando de ser necesario.

Esto se puede ver evidenciado de la siguiente forma:

Actions Creators & Actions: Los actions creators son colecciones de métodos que
son llamados dentro de las vistas (o en cualquier lado de ser necesario) para enviar
acciones al “Dispatcher”. Las acciones son el payload (carga de trabajo) que es
enviada por medio del dispatcher.

Controller Views: Los controller Views son simplemente los componentes de

React que están escuchando al cambio de los eventos y que obtienen el estado de la
aplicación desde los Stores. Ellos pueden pasar esa data a sus hijos por medio de
props.
Un diagrama que muestra este funcionamiento es el siguiente:
1. Seleccionar un lenguaje de programación y un framework, los cuales serán usados
para construir el componente web del sistema de software asociado al proyecto de
la asignatura.

Lenguaje elegido - Vue.js:

Usando Vue, manejamos un estado compartido y la modificación del estado se debe
importar en cada componente, haciendo uso de las funciones llamadas 'Actions'
ubicadas dentro del elemento store de la aplicación como se muestra a continuación.

Manejando la interoperabilidad con distintas API, la sub-arquitectura que modela los

intercambios de información se hace a través de las funciones “Actions” ubicadas en
el Store y gestionadas por el paquete Vuex. Cómo son usadas para la comunicación
directa con un API, se caracterizan por tener naturaleza asíncrona, o manejar sus
sentencias con promesas, además no tienen valor de retorno porque su ejecución
implica el disparo de una mutación (Mutations) que modifique el estado.
 La interacción directa con el usuario la manejan las vistas, que no son más que
componentes registrados en el enrutador de Vue, y que pueden anidar varios
componentes. Estos últimos encapsulan el comportamiento asociado a un fragmento
de html en interacción con la vista y con la aplicación (State). A continuación se
presenta un diagrama que especifica los elementos que agrupa un componente de vue,
en particular las secciones dedicadas al manejo de la reactividad dentro del ciclo de
vida del componente.

iii. Componente Móvil

1. Indagar acerca de las diferentes estrategias de diseño e implementación de

componentes de software Front-End de tipo móvil (nativos) para el sistema operativo
Android. Hacer énfasis en las arquitecturas internas (sub-arquitecturas) de dichos
componentes.

Kotlin vs Java

Kotlin: Es un lenguaje de programación de tipado estático que corre sobre la máquina

virtual de Java y que también puede ser compilado a código fuente de JavaScript.
Hablando de la importancia de este lenguaje, es el lenguaje JVM más soportado en
el ecosistema de Android, aparte de Java. Con Kotlin se escribe significativamente
menos código en comparación con Java. Menos líneas de código implican tamaños
de archivo más pequeños para Kotlin, en comparación con los equivalentes de Java.

Java: Java es uno de los lenguajes de programación más populares del mundo. Es un
lenguaje orientado a objetos, potente, versátil y multiplataforma (corre en cualquier
sistema operativo moderno). Además puedes obtener Java y gran cantidad de
herramientas para trabajar con él de forma gratuita, siendo la mayor parte de su
código libre y abierto.
Es el lenguaje nativo que utiliza Android, las aplicaciones que se comuniquen con el
sistema operativo y utilicen directamente el hardware van a usar Java. Estamos ante
uno de los lenguajes de programación más extendidos, lo cual se ve reflejado en su
comunidad y el amplio conocimiento extendido por ella.

Principios de Arquitectura Android

Para obtener una buena arquitectura hay algunos conceptos básicos que debemos
seguir.

Separación de preocupaciones: El componente debe hacer lo que se requiere, lo

veremos a continuación.

Para ello seguiremos un patrón arquitectónico que se asegure de cumplir con dicho
objetivo de una forma óptima. Veremos a continuación los principales de ellos.

MVC - Modelo Vista Controlador

Es una de las arquitecturas más comúnmente utilizadas, y está dividida en los

siguientes componentes:

Model: Obtener y manipular los datos, se comunica con el controlador, interactúa

con la base de datos y puede actualizar las vistas.

View: Es básicamente lo que vemos en la interfaz de usuario, se comunica con el

controlador y puede interactuar con el modelo.
Controller: Se comunica tanto con la vista como con el modelo, toma la entrada del
usuario de los servicios de la vista y solicita los datos al modelo para pasarlos a la
vista.
Esta arquitectura se suele utilizar por el apoyo que le puede ofrecer al manejo de
técnicas asíncronas, además de que permite un proceso de desarrollo más rápido y
modular, puesto que las modificaciones no afectan a todo el modelo, manteniendo la
lógica del negocia separa en este.

Pero se ha ido dejando aparte puesto que, debido a que el controlador de código suele
convertirse en un elemento altamente inmanejable, dificultando las pruebas de unidad
e incrementando la complejidad del sistema de software.

MVP - Modelo Vista Presentador

Rompe la dependencia con lo que se tiene en la Vista, y está dividido en los siguientes
componentes:

Model: Igual que en el MVC, maneja la lógica de negocio y los estados de los datos,
pero ahora, no tiene ninguna interacción con la Vista.

View: Consiste en la interfaz de usuario e interactúa con el Presenter.

Presenter: Controla todo el comportamiento que se desea mostrar de la aplicación,

presentando los datos del modelo. Maneja la Vista, diciéndole qué hacer, manejando
cualquier interacción entre el modelo y la vista.

Se suele utilizar gracias a que, el código es más legible y mantenible, disminuyendo

la complejidad de la vista, para poder cambiarla con mayor facilidad y puesto que la
lógica de negocio está separada del interfaz de usuario, la complejidad de las pruebas
sobre el sistema de software también baja. No obstante, el tamaño del código puede
llegar a ser bastante excesivo, puesto que requiere de una gran cantidad de interfaces
para la interacción entre capas y la unión entre la vista y el presentador es bastante
ajustado.
MVVM - Model View ViewModel

La principal ventaja de esta arquitectura es que elimina el acoplamiento entre los

componentes (Model, View y ViewModel), de tal manera que la única referencia
entre los elementos es a través de la referencia de los observables.

Modelo: De igual manera que las arquitecturas MVC y MVP, este elemento se
encarga de la lógica de negocios y la representación de los datos, para esto puede usar
recursos locales o remotos.

View: Se encarga del código de la interfaz con el usuario (IU), generalmente XML,
la principal diferencia con las demás arquitecturas se presenta a la hora de realizar
peticiones al intermediario (ViewModel), no se obtienen respuestas directamente,
para la obtención de respuestas se debe suscribir a los observables que el ViewModel
expone.

ViewModel: Es el intermediario entre los dos componentes anteriores, se desacopla

totalmente de la vista, no debe saber y le es indiferente de que vista proviene una
petición, a nivel de implementación esto es equivalente a decir que no tiene una
referencia de la vista. Su interacción se da con el modelo, al cual le envía peticiones
y recibe respuestas. La comunicación la vista se limita únicamente a los observables.

Ventajas:
• Se reduce ampliamente el acoplamiento entre la vista y el intermediario
(ViewModel).
 • Se elimina el concepto de interfaz y vista entre la vista y el intermediario,
este concepto puede generar bastantes problemas en una gran cantidad
de escenarios.

• Los Test se suelen simplificar en gran medida, ya que se pueden realizan

usando solo eventos.

Desventajas
• En interfaces muy extensas y poco flexibles, suele ser tedioso la creación de
una gran variedad de observables para responder a las distintas solicitudes.

• Dado que se elimina la comunicación directa producto del acoplamiento, el

tamaño del código puede aumentar de manera excesiva si no se tiene una
planeación que aborde la mayoría las peticiones que la arquitectura debe
solucionar.

2. Seleccionar un lenguaje de programación, el cual será usado para construir

el componente móvil del sistema de software asociado al proyecto de la
asignatura.

Lenguaje Elegido - KOTLIN:

Los principales motivos que influenciaron el escoger Kotlin como lenguaje para el
desarrollo de la aplicación móvil son:
• Cantidad de código: En Kotlin se escribe una menor cantidad de líneas de
código repetitivo en comparación a Java.
• Interoperabilidad: Kotlin es interoperable con Java, lo cual permite
apalancarse de todas las librerías existentes de Java, la JVM y los
frameworks.
• Curva de aprendizaje: Debido a que en el grupo todos cuentan con bases
en Java el aprendizaje de Kotlin se verá facilitado por los conocimientos
previos.
• Proporciona un rendimiento mejorado en tiempo de ejecución: El
rendimiento durante el tiempo de ejecución es alto.
• Corutinas: Kotlin permite la creación de corutinas.
• Seguridad de datos nulo: En Kotlin los tipos son no-nulos por defecto, lo
cual facilitará el manejo de errores referentes al manejo de los mismos.

Arquitectura Elegida - MVVM:

A la hora de elegir qué arquitectura usar, se le dio mayor importancia al acoplamiento
de los componentes, esto permitió que en primera instancia se descarta la
Arquitectura MVC, luego de evaluar las ventajas y desventajas de MVP y MVVM se
optó por usar la arquitectura Model-View-ViewModel, ya que esta reduce la
comunicación entre la vista y el intermediario en la mayor medida posible mediante
el uso de Observers.

Referencias:
[1] Vandana Srivastava. (2019). MVC vs MVP vs MVVM architecture in Android. 24/04/2020,
de MindOrks Sitio web: https://blog.mindorks.com/mvc-mvp-mvvm-architecture-in-android
[2] Amit Shekhar. (2020). MVVM Architecture - Android Tutorial for Beginners - Step by Step
Guide. 24-04-2020, de MindOrks Sitio web: https://blog.mindorks.com/mvvm-architecture-android-
tutorial-for-beginners-step-by-step-guide

[3] SomosTechies [Jesus Angulo]. (2020, 04 24). Arquitecturas móviles - MVC, MVP, MVVM
y Flux [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=tozOPRdhDM8

[4] Kevin Javier Morales. (2019). Arquitecturas de Software en Android: MVC, MVP y
MVVM. 24-04-2020, de Platzi Sitio web: https://platzi.com/blog/arquitecturas-de-software-en-
android-mvc-mvp-y-mvvm/

[5] Eric Maxwell. (2017). MVC vs. MVP vs. MVVM on Android. 24-04-2000, de Realm Sitio
web: https://academy.realm.io/posts/eric-maxwell-mvc-mvp-and-mvvm-on-android/

[6] Illya Alvarado. (2019). Los 3 principales lenguajes para programar aplicaciones en
Android. 24-04-2000, de Cero Ideas Sitio web: https://ceroideas.es/los-3-principales-lenguajes-
para-programar-aplicaciones-en-android/

[7] Vaishnavi M R. (2019). Kotlin vs Java: Which is the best fit?. 24-04-2020, de Edureka! Sitio
web: https://www.edureka.co/blog/kotlin-vs-java/

[8] Angular. (2020). Recuperado 24 April 2020, desde https://angular.io/

[9] Angular ¿qué son los módulos y cómo se refactoriza una aplicación?. (2020). Recuperado 24
April 2020, desde https://medium.com/@yonem9/angular-qu%C3%A9-son-los-m%C3%B3dulos-y-
c%C3%B3mo-se-refactoriza-una-aplicaci%C3%B3n-9457550e8e9

[10] Building and serving Angular apps. (2020). Recuperado 24 April 2020, desde
https://angular.io/guide/build

[11] Thinking in components with Vue.js. (2020). Recuperado 24 April 2020, from
https://medium.com/@_shirish/thinking-in-components-with-vue-js-a35b5af12df

[12] Vue js. (2020). Retrieved 24 April 2020, desde https://vuejs.org/

[13] What is Vuex? | Vuex. (2020). Recuperado 24 April 2020, desde https://vuex.vuejs.org/