Escue la P oli téc nica Supe rior d e Jaén
SUPERMERCADO 4.0:
PRECIOS A MEDIDA
Alumno: Marcos David Moreno Torres
Tutores: Miguel Ángel García Cumbreras Salud María Jiménez Zafra
Dpto: Departamento de informática
Julio, 2019
U
NIVERSIDAD DEJ
AÉN Escuela politécnica superior de JaénTrabajo Fin de Grado
Universidad de Jaén
Escuela Politécnica Superior de Jaén Departamento de Informática
D. Miguel Ángel García Cumbreras y D.ª Salud María Jiménez Zafra, tutores del Proyecto Fin de Carrera titulado: “Supermecado 4.0: Precios a medida”, que presenta Marcos David Moreno Torres, autoriza su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.
Jaén, Julio de 2019
El alumno: Los tutores:
Marcos David Moreno Torres D. Miguel Ángel García Cumbreras D.ª Salud María Jiménez Zafra GARCIA
CUMBRERA S MIGUEL ANGEL - 52871272E
Firmado digitalmente por GARCIA CUMBRERAS MIGUEL ANGEL - 52871272E Nombre de reconocimiento (DN): c=ES,
serialNumber=IDCES-52871272 E, givenName=MIGUEL ANGEL, sn=GARCIA CUMBRERAS, cn=GARCIA CUMBRERAS MIGUEL ANGEL - 52871272E Fecha: 2019.07.16 08:56:17 +01'00'
JIMENEZ ZAFRA SALUD MARIA - 77370897R
Firmado digitalmente por JIMENEZ ZAFRA SALUD MARIA - 77370897R
Nombre de reconocimiento (DN): c=ES,
serialNumber=IDCES-77370897R , givenName=SALUD MARIA, sn=JIMENEZ ZAFRA, cn=JIMENEZ ZAFRA SALUD MARIA - 77370897R Fecha: 2019.07.16 10:04:47 +02'00'
MORENO TORRES MARCOS DAVID - 15518470W
Firmado digitalmente por MORENO TORRES MARCOS DAVID - 15518470W Fecha: 2019.07.16 10:12:05 +02'00'
Agradecimientos
Podemos decir que este proyecto es el resultado del aprendizaje de estos años de universidad, y creo que se ve claramente reflejado.
Parece que detrás de este trabajo solo hay un alumno y su coordinador, pero son muchos los factores que influyen para que un proyecto como este salga adelante.
En estos factores entran reflejados la familia y los amigos. Sin ellos todo esto no hubiera sido posible. De una forma o de otra cada uno ha aportado su grano de arena a que esto haya sido posible. Si no es por la persistencia de mis padres para que estudie una carrera quizás hoy no estaría escribiendo este documento. Y no cabe duda, de que sin el apoyo y ayuda de los compañeros de la carrera para sacar año tras año las asignaturas adelante hubiera sido todo más complicado.
Compañeros que muchos serán amigos para toda la vida.
Por todo esto y por mucho más esto ha podido realizarse. Asique quiero daros las gracias a todos y espero que sigáis siendo así porque valéis muchísimo.
Índice
Agradecimientos... 3
Capitulo 1: Introducción ...13
1.1. Motivación ... 15
1.2. Objetivos ... 16
1.3. Metodología del proyecto ... 18
1.4. Estructura del proyecto ... 19
Capitulo 2: Ingeniería del software ...22
2.1. Análisis de costes ... 25
2.2. Perfiles de usuario ... 26
2.2.1. Usuario cliente: ...26
2.2.2. Usuario administrador ...27
2.3. Requisitos funcionales ... 27
2.3.1. Usuario estándar (app móvil): ...27
2.3.2. Usuario administrador (web): ...28
2.4. Requisitos no funcionales ... 28
2.4.1. Interfaz de ambas aplicaciones: ...28
2.4.2. Accesibilidad: ...29
2.4.3. Rendimiento: ...29
2.4.4. Usabilidad: ...29
2.5. Casos de uso ... 29
2.5.1. Diagrama de caso de uso: ...29
2.5.2. Declaración de casos de uso (historias de los casos) ...30
2.6. Diagrama de máquina de estados: ... 35
2.6.1. Diagrama de app móvil ...35
2.6.2. Diagrama de app web ...36
2.7. Diagrama de clases ... 37
2.8. Diseño de la app móvil ... 40
2.8.1. Metáfora visual ...40
2.8.2. Storyboard ...43
2.9. Diseño de la app web ... 48
2.10. Base de datos ... 51
Capítulo 3: Estudio del módulo Arduino ...57
3.1. Tipos de Arduino ... 59
3.2. Componentes electrónicos utilizados en el proyecto ... 64
3.3. Conexión de los distintos dispositivos ... 65
3.4. ¿Por qué utilizar una conexión a internet mediante ethernet en lugar de por WiFi? .. ...66
Capítulo 4: Estudio de las tecnologías de desarrollo de las apps ...70
4.1. ¿Qué es una app? ... 71
4.2. ¿Para qué plataforma debería crear la app móvil? ... 72
4.3. Ventajas de IOS frente a Android: ... 73
4.4. Ventajas de Android frente a IOS: ... 73
4.5. Android Studio ... 74
4.6. Versiones de sistema operativos Android:... 75
4.7. ¿Qué herramienta uso para crear mi web? ... 79
4.8. Framework y tipos ... 80
4.9. Firebase ... 83
Capítulo 5: Desarrollo ...86
5.1. Conexión base de datos con app móvil ... 87
5.2. Aplicación móvil ... 88
5.2.1. Login ...89
5.2.2. Vista principal de la app ...91
5.2.3. Tiendas ...91
5.2.4. Contacto...92
5.2.5. Reservas ...93
5.2.6. Ofertas ...95
5.2.7. Vista principal con menú ...96
5.2.8. Vista de productos ...96
5.2.9. Notificaciones ofertas disponibles ...98
5.3. Conexión base de datos Firebase con Codeigniter ... 99
5.4. Aplicación web ... 101
5.4.1. Login ... 102
5.4.2. Gestión de productos ... 103
5.4.3. Gestión de reservas ... 105
5.4.4. Historial de reservas ... 106
5.4.5. Cerrar sesión ... 106
5.5. Conexión a internet de Arduino ... 106
5.6. Comunicación Arduino con servidor web ... 108
Capítulo 6: Pruebas de validación y usabilidad ... 112
6.1. Pruebas de validación: ... 113
6.1.1. App móvil ... 113
6.1.2. App web ... 113
6.1.3. Arduino ... 114
6.2. Usabilidad ... 114
Capítulo 7: Conclusión y futuras mejoras ... 121
7.1. Conclusiones ... 122
7.2. Futuras mejoras ... 123
Anexo: Manuales de instalación ... 126
1. Creación de una app en Android Studio ... 127
2. Creación de proyecto con firebase ... 131
3. Creación de una web a partir de CodeIgniter ... 133
Referencias ... 138
Índice de figuras
Figura 1.1: Porcentaje de productos retirados en proporción a las ventas realizadas ...14
Figura 1.2: Gráfica con el porcentaje de los productos más desechados. ...14
Figura 1.3: El mal negocio de tirar los alimentos (El País). ...16
Figura 1.4: Demostración de producto con precio usando display. ...17
Figura 1.5: Diagrama de funcionamiento del sistema. ...18
Figura 1.6: Viñeta simulando los problemas al desarrollar un proyecto sin una comunicación ni estudio adecuados. ...19
Figura 2.1: Diagrama de Gantt. ...24
Figura 2.2: Diagrama de caso de uso. ...30
Figura 2.3: Diagrama de máquina de estados (I). ...35
Figura 2.4: Diagrama de máquina de estados (II). ...36
Figura 2.5: Diagrama de clases app móvil ...39
Figura 2.6: Metáfora visual (I) ...40
Figura 2.7: Metáfora visual (II) ...40
Figura 2.8: Metáfora visual (III) ...41
Figura 2.9: Metáfora visual (IV) ...41
Figura 2.10: Metáfora visual (V). ...41
Figura 2.11: Metáfora visual (VI). ...41
Figura 2.12: Metáfora visual (VIII). ...42
Figura 2.13: Metáfora visual (IX). ...42
Figura 2.14: Metáfora visual (X). ...42
Figura 2.15: Metáfora visual (XI). ...42
Figura 2.16: Storyboard app móvil (I) ...44
Figura 2.17: Storyboard app móvil (I) ...44
Figura 2.18: Storyboard app móvil (III) ...45
Figura 2.19: Storyboard app móvil (IV) ...45
Figura 2.20: Storyboard app móvil (V) ...46
Figura 2.21: Storyboard app móvil (VI) ...46
Figura 2.22: Storyboard app móvil (VII) ...47
Figura 2.23: Storyboard app móvil (VIII) ...47
Figura 2.24: Storyboard app web (I) ...48
Figura 2.25: Storyboard app web (II) ...48
Figura 2.26: Storyboard app web (III) ...49
Figura 2.27: Storyboard app web (IV) ...49
Figura 2.28: Storyboard app web (V) ...50
Figura 2.29: Storyboard app web (VI) ...50
Figura 2.30: Estructura productos en la bddd. ...52
Figura 2.31: Estructura “Reservas” en la bbdd. ...53
Figura 2.32: Estructura “Ofertas específicas” en la bbdd. ...54
Figura 2.33: Atributos tabla user ...54
Figura 3.1: Arduino Mega ...58
Figura 3.2: Esquema del montaje de los distintos display con arduino ...66
Figura 3.3: Módulo arduino con ethernet shield. ...68
Figura 3.4: Módulo arduino con los 4 display ...68
Figura 4.2: Gráfica del porcentaje de sistema operativos usados en los móviles ...72
Figura 4.3: Android Studio ...75
Figura 4.4: Estadística con el porcentaje de uso de cada versión de Android (2018) ...79
Figura 4.5: CMS vs Framework ...79
Figura 4.6: Principales frameworks de php (2019) ...81
Figura 4.7: Principales características de Firebase. ...83
Figura 5.1: Clase que almacena las reservas ...87
Figura 5.2: Consulta a la base de datos Firebase...88
Figura 5.3: Login app ...89
Figura 5.4: Métodos de autenticación de Firebase ...90
Figura 5.5: Usuarios Firebase ...90
Figura 5.6: Vista principal de la app...91
Figura 5.7: Vista mapa con tienda física ...92
Figura 5.8: Vista de contacto ...93
Figura 5.9: Vista reservas ...94
Figura 5.10: Vista reservas con fecha ...94
Figura 5.11: Vista ofertas de productos. ...95
Figura 5.12: Menú de la app ...96
Figura 5.13: Productos ...97
Figura 5.14: Confirmar reserva de producto ...97
Figura 5.15: Envío de notificaciones de Firebase. ...98
Figura 5.16: Fichero php para el envío de notificaciones ...99
Figura 5.17: Notificación de oferta ...99
Figura 5.18: Configuración base de datos en Codeigniter ... 100
Figura 5.19: Acceso a la bbdd ... 101
Figura 5.20: URL acceso a base de datos Firebase ... 101
Figura 5.21: Selección de todos los productos de la bbdd ... 101
Figura 5.22: Login web ... 102
Figura 5.23: Visualización de productos ... 103
Figura 5.24: Visualización de producto individual ... 103
Figura 5.25: Selección de oferta específica ... 104
Figura 5.26: Vista para modificar producto ... 105
Figura 5.27: Gestión de reservas ... 106
Figura 5.28: Historial de reservas ... 106
Figura 5.29: Asignación de valores para el módulo ethernet ... 107
Figura 5.30: Comprobación de si servidor DHCP asigna IP ... 108
Figura 5.31: Maqueta Arduino (montaje) ... 110
Figura 5.32: Maqueta Arduino ... 110
Figura 6.1: Viñeta simulando pruebas de validación ... 113
Figura 6.2: Encuesta de usabilidad app (I) ... 115
Figura 6.3: Encuesta de usabilidad app (II) ... 116
Figura 6.4: Encuesta de usabilidad app (III) ... 117
Figura 6.5: Resultados de la encuesta (I) ... 118
Figura 6.6: Resultados de la encuesta (II) ... 118
Figura 6.7: Resultados de la encuesta (III) ... 118
Figura 6.8: Resultados de la encuesta (IV) ... 119
Figura A.1: Ventana principal de Android Studio ... 127
Figura A.2: Nombre de la app ... 128
Figura A.3: Selección de dispositivos. ... 128
Figura A.4: Modelos predefinidos ... 129
Figura A.5: Desarrollo de la app ... 129
Figura A.6: Crear proyecto Firebase ... 131
Figura A.7: Añadir Firebase a una aplicación de Android. ... 132
Figura A.8: Android Studio con Firebase ... 133
Figura A.9: XAMPP ... 134
Figura A.10: Estructura de carpetas CodeIgniter ... 134
Figura A.11: Dentro de application CodeIgniter ... 135
Índice de tablas
Tabla 2.1: Costes de hardware ...25
Tabla 2.2: Costes de maqueta de madera ...25
Tabla 2.3: Costes de alquiler de hosting ...25
Tabla 2.4: Costes de sueldo de trabajador ...26
Tabla 2.5: Declaración de casos de uso ...31
Tabla 2.6: Descripción textual “Visualizar productos" ...32
Tabla 2.7: Descripción textual “Realizar oferta" ...32
Tabla 2.8: Descripción textual “Gestionar productos" ...33
Tabla 2.9: Descripción textual “Visualizar reservas" ...34
Tabla 2.10: Descripción textual “Aceptar/Cancelar reservas" ...34
Tabla 3.1: Tipos de Arduino ...63
Tabla 3.2: Material para la creación del proyecto ...65
Tabla 4.1: Versiones de Android ...78
Capitulo 1:
Introducción
En una sociedad de consumo como la nuestra, un gran porcentaje de productos que encontramos en supermercados y grandes superficies son perecederos o pueden sufrir deterioro y hay que desecharlos.
FACUA-Consumidores en Acción ha encuestado a veintiocho cadenas de supermercados e hipermercados y sólo ocho han aclarado qué hacen con los alimentos que no venden. Cada día se destruyen en España 21.000 toneladas de comida, de las que unas 1.000 son responsabilidad del sector de la distribución comercial.
A continuación adjunto los resultados de un estudio realizado por el periódico el país en el que se muestra el tanto por ciento de productos retirados por caducidad.
Figura 1.1: Porcentaje de productos retirados en proporción a las ventas realizadas
Figura 1.2: Gráfica con el porcentaje de los productos más desechados.
Un estudio con datos de 2015 de la asociación AECOC —donde están representados El Corte Inglés, Carrefour, Mercadona o Eroski— apunta un porcentaje significativamente más reducido de desperdicio: el 1,7% de todo el volumen comercializado por la distribución se retira, medio punto menos que en 2013. El 43% de esos alimentos no son aptos para el consumo humano y se destruyen. Tienen un valor aproximado de 292 millones de euros, que se elevan a 336 millones con las donaciones.
¿Cómo solucionamos estos problemas?
Se han optado por distintos métodos para intentar vender este tipo de producto.
Algunas de estas soluciones son:
Situarlos en lugares más a la vista de los clientes.
Bajarles el precio cuando se acerca su fecha de caducidad o consumo preferentes, sin que el cliente haya sido informado previamente y por lo tanto si no visita el comercio, no tiene acceso a esta información.
Y estas y otras soluciones no han tenido mucho éxito, y lo demuestran las grandes cantidades de producto que se sigue desechando.
1.1. Motivación
En un artículo de la BBC, se mencionan las distintas medidas que han considerado los distintos países del mundo para solventar de una forma u otra este problema que afecta a todos. Por ejemplo, existen distintas medidas en países como Francia para intentar dar salida a estos productos y que no acaben en un vertedero.
Gracias a las 200.000 firmas de ciudadanos que apoyaron la iniciativa de Guillaume Garot, ex ministro delegado de Agricultura, el pasado 9 de diciembre los diputados acordaron por unanimidad una normativa que obliga a los supermercados de más de 400 metros cuadrados a donar la comida que descartan para bancos de alimentos, alimentación animal o abonos. La ministra Ségolène Royale tuvo duras negociaciones con el sector y amenazó con publicar el nombre de quienes no se comprometieron a sumarse a la iniciativa. “Y no creo que les haga buena
publicidad”, comentó. El objetivo final de Francia es reducir en 2025 a la mitad las sobras.
A día de hoy no existen medidas similares en España. Para intentar solucionar este problema se propone este proyecto, que tiene como finalidad principal ayudar a los comercios a que estos productos sean consumidos por los clientes antes de que lleguen a su fecha de caducidad y por lo tanto se tengan que desechar.
Figura 1.3: El mal negocio de tirar los alimentos (El País).
1.2. Objetivos
Como he mencionado anteriormente el principal objetivo de este proyecto es por una parte crear una confianza entre el cliente y el comercio con la ayuda de una aplicación móvil bastante “amigable”, y de esta forma que le sea más sencillo realizar la compra. Y por otra parte, evitar que muchos productos de un comercio acaben deteriorándose, conllevando esto a pérdidas de ingresos en los comercios y a la retirada de productos.
Mi planteamiento se divide en las siguientes fases:
1. “Obligar” al cliente a instalar la app del comercio en cuestión, de manera que si lo hace sea recompensado con información privilegiada ante el resto de los clientes.
2. El cliente podrá realizar reservas online desde la app.
3. Cuando un producto esté cerca de perecer, bajaremos el precio de este (digitalmente), e informaremos al cliente de la oferta.
4. Creación de un sitio web para que el administrador sea capaz de gestionar las reservas de los clientes y los productos
Con esta solución intentamos aportar varias ventajas:
El cliente podrá comprar un producto que normalmente utiliza a un precio más barato.
El comercio consigue poner a la venta un producto al que le cuesta dar salida, y el cliente obtiene el producto que habitualmente utiliza a un precio más bajo y sin moverse del sofá de su casa.
Este tipo de cosas crean confianza en el cliente, lo que conlleva a que con la correspondiente publicidad, no dudará en instalarse la app del comercio que normalmente frecuente.
Para el funcionamiento de este sistema utilizaremos una placa con un microprocesador llamada Arduino (detallado más adelante), en la cual van conectados los distintos display con el nombre y precio de los productos. Esta placa será la encarga de cambiar los precios dinámicamente, basándose en un algoritmo, el cual bajará los precios de un producto según se vaya acercando la fecha de caducidad de este.
Figura 1.4: Demostración de producto con precio usando display.
Figura 1.5: Diagrama de funcionamiento del sistema.
1.3. Metodología del proyecto
Para el desarrollo de este trabajo he seguido con mi coordinador una metodología ágil por iteraciones, donde en cada iteración vamos a ir definiendo, desarrollando y probando todo el proyecto. Incrementando funcionalidades en las siguientes iteraciones.
Las primeras iteraciones han consistido en el planteamiento del problema. Un breve estudio de la cantidad de productos que un comercio debe tirar al vertedero al no poder venderlos, y las distintas medidas tomadas por algunos países vecinos para intentar solventar esta pérdida.
Una vez que ya somos conscientes de la gravedad del asunto, nos ponemos manos a la obra para el desarrollo del proyecto.
A continuación realizaremos un estudio de la tecnología a utilizar, para así poder utilizar la que más se adapte a este proyecto. Evitar hacer esto implicaría limitar demasiado la funcionalidad del proyecto o en cambio, usar una tecnología demasiado sofisticada la cual podríamos reemplazar por una más básica. Estos estudios los detallo más adelante, con comparativas y la razón de la elección de cada una.
Figura 1.6: Viñeta simulando los problemas al desarrollar un proyecto sin una comunicación ni estudio adecuados.
Con la elección de un software y hardware adecuado no queda más que ponerse a con la implementación y las distintas pruebas hasta que lleguemos a conseguir nuestro objetivo. Como he dicho anteriormente, más adelante detallaré estos objetivos y todo el funcionamiento del proyecto.
Para ayudarme a esto, he utilizado la plataforma Trello, un sitio web en el cual se dividen las tareas en diferentes tarjetas, y las vas desplazando según vayas avanzando en el proyecto. Es una buena forma de comunicación también con mi coordinador. Este método obliga a llevar un trabajo constante y a medir los tiempos de forma correcta.
1.4. Estructura del proyecto
La memoria está estructurada en los siguiente puntos:
Capítulo 1 Introducción:
Este es el capítulo que acabo de detallar, en el que se muestra el problema a resolver, y las distintas soluciones propuestas para ello.
Capítulo 2 Ingeniería del software:
En este punto veremos los requisitos que debe de contener el proyecto, así como un analisis de los costes y la forma en que el usuario interactuará con las diferentes aplicaciones.
Capítulo 3 Estudio del módulo Arduino:
Este punto está destinado únicamente al módulo Arduino. Aquí encontraremos los diferentes tipos de módulos que existen y el material utilizado para el proyecto.
Capítulo 4 Estudio de las tecnologías de desarrollo de las apps:
Aquí se detallarán las diferentes tecnologías utilizadas tanto para el diseño de la web como de la app móvil.
Capítulo 5 Desarrollo:
En el apartado de diseño está detallado el proceso de implementación tanto de las apps como del módulo Arduino.
Capítulo 6 Pruebas de validación y usabilidad:
Se comentan las diferentes pruebas realizadas sobre el proyecto para comprobar que cumple los requisitos previos mencionados en el capítulo 2.
Capítulo 7 Conclusión y futuras mejoras:
Conclusión del proyecto y mención de algunas mejoras que se podrían llevar a cabo en el proyecto.
Anexo Manuales de instalación:
Aquí habrá un manual por cada una de las tecnologías utilizadas en el proyecto. En estos se detallará los pasos a seguir para crear desde cero tanto la aplicación web como la móvil.
Capitulo 2: Ingeniería
del software
Para la planificación de este proyecto se propuso una serie de tareas.
Comenzamos mostrando información y datos sobre el problema a resolver mediante este proyecto. Una vez que somos conscientes de que el problema es real, mediante estudios de diferentes superficies, nos dispondremos a montar la arquitectura y diseño que llevará este proyecto. Para ello me he documentado sobre las tecnologías más “pioneras” y que mejor se adaptan a las necesidades y recursos de los que dispongo. Con las ideas claras, el siguiente paso es la implementación y diseño del software. Cuando esté terminado pasamos a la fase de testeo, y a la de posibles mejoras futuras.
Para mostrar el tiempo utilizado en cada una de las partes del proyecto voy a crear un diagrama de Gantt. El diagrama de Gantt es una herramienta gráfica cuyo objetivo es exponer el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de esto, el diagrama de Gantt no indica las relaciones existentes entre actividades [1].
Figura 2.1: Diagrama de Gantt.
2.1. Análisis de costes
A continuación voy a mostrar una tabla detallada con el análisis de costes de desarrollo del proyecto. Voy a estructurar el presupuesto en sueldo de trabajador/es, que en este caso solo es uno, y el hardware que ha sido necesario:
Hardware:
El precio del ordenador portátil es de 800€ el cual tendrá un tiempo de durabilidad medio de unos cinco años. Por lo tanto si calculo el tiempo de usabilidad durante el desarrollo del proyecto (129 días) el precio será de: 56,55€. Lo mismo pasa con el teléfono móvil, pero en este caso el tiempo de duración es de unos dos años. El precio para dos años del móvil es de 150€. Por lo que el coste en este tiempo será de: 26,51€.
Concepto Descripción Coste
Ordenador portátil Msi i7-7700HQ 56,55 €
Teléfono móvil Huawei p8 lite 26,51 €
Placa Arduino Mega 2560 13,99 €
120 cables Conexiones Arduino 6,96 €
Protoboard 400 pines 1,65 €
4 LCD 1602 + IIC/I2C 15,96 €
Módulo para Arduino Ethernet Shield 11,99 €
Total 133,61 €
Tabla 2.1: Costes de hardware
Maqueta de madera:
Concepto Descripción Coste
Tablas 4 tablas de madera 6 €
Tornillos 10 tornillos 1€
Total 7 €
Tabla 2.2: Costes de maqueta de madera
Alquiler de hosting:
Descripción Tiempo Coste
Alojamiento y dominio 3 y 12 meses respectivamente
8,14 €
Total 8,14 €
Tabla 2.3: Costes de alquiler de hosting
Sueldo trabajador/es:
El sueldo de un analista programador está establecido según convenio publicado en el BOE en 1438,08€ mensuales [2]. Este sueldo se divide en unas 40 horas de trabajo semanales, normalmente dividido en unos 5 días a la semana a 8 horas cada día. Este cálculo nos da como resultado: 71,9€ al día.
Descripción Precio Tiempo Coste
Persona que se encargará de desarrollar el
proyecto
71.9€/día 129 días 9275,62 €
Construcción y montaje de la
maqueta
10 €/hora 2 horas 20 €
Total 9295,62 €
Tabla 2.4: Costes de sueldo de trabajador
Cabe destacar que todo el software utilizado para la creación de este proyecto es gratuito y se puede descargar fácilmente de internet (incluido en los manuales), o estaba ya incluido en la compra de los dispositivos.
Todo esto hace un total de: 9444,37 €. A este precio habría que sumarle el mantenimiento del software y además si se desea añadir más display para más productos, ya que para este proyecto solo visualizaré cuatro productos.
2.2. Perfiles de usuario
Antes de explicar los requisitos que componen el proyecto es importante indicar los diferentes tipos de usuario que van a utilizar las aplicaciones. Dentro de la clasificación de usuarios podemos distinguir entre dos tipos:
2.2.1. Usuario cliente:
Dentro del usuario cliente tenemos dos perfiles:
El primero tendrá conocimientos sobre el funcionamiento de los smartphone y de algunas de sus aplicaciones. Debe de tener acceso a internet desde cualquier sitio. Este perfil de usuario tiene la libre elección de reservar los productos directamente desde la app, o comprar los productos en el local directamente.
El segundo tipo de usuario no tendrá conocimientos tecnológicos, por lo que comprará los productos en el local. La app de supermercado 4.0 es de fácil uso, pero es cierto que se puedo complicar para alguien que nunca ha utilizado un móvil inteligente.
2.2.2. Usuario administrador
El usuario administrador tiene conocimientos informáticos, ya que es la persona encargada de gestionar los productos del comercio (crear productos, modificar ofertas etc). A esto hay que incluirle la gestión de las reservas de los clientes, ya que él decide si la reserva será o no aceptada. Por lo tanto, siempre deberá llevar un dispositivo (móvil o tablet) consigo, con internet desde cualquier lado. Hay que tener en cuenta que además de estas gestiones también tiene vinculado un número de teléfono y un correo como contacto para los clientes. Cabe recordar que todo esto lo gestionará desde la app web.
2.3. Requisitos funcionales
A continuación voy a indicar los requisitos funcionales que debe cumplir la app para un cliente. En este caso tenemos dos tipos de clientes, uno tipo usuario (estándar) y otro tipo administrador. Cada usuario respectivamente utilizará una app. Para el usuario estándar hablaré de los requisitos funcionales de la app móvil. Para el usuario administrador mencionaré la funcionalidad de la web.
2.3.1. Usuario estándar (app móvil):
Puede loguearse en la app mediante su cuenta de correo de google.
Visualizará los distintos tipos de productos que ofrece el comercio mediante categorías.
Dentro de cada categoría podrá hacer búsquedas de los productos.
Puede reservar un producto, siempre y cuando, esté en stock.
Visualizará en el map de google la localización del comercio físico.
Podrá ponerse en contacto con los supervisores del comercio mediante vía telefónica o mediante gmail.
Puede visualizar sus reservas y ver si estas han sido canceladas, aceptadas o están en espera.
Puede clasificar sus reservas por fechas.
Acceder a las ofertas y reservarlas antes de que acabe la oferta, siempre y cuando siga en stock.
Realizar búsquedas de las ofertas en activo.
Recibir notificaciones de nuevas ofertas.
Cerrar sesión.
2.3.2. Usuario administrador (web):
Loguearse en la web mediante un usuario y password predefinidos.
Visualizar todos los productos del comercio.
Crear nuevos productos.
Modificar productos.
Eliminar productos.
Seleccionar tipos de ofertas para cada producto.
Visualizar las reservas de cada usuario.
Aceptar o cancelar las ofertas de los usuarios.
Cerrar sesión.
2.4. Requisitos no funcionales
2.4.1. Interfaz de ambas aplicaciones:
Ambas aplicaciones, tanto móvil como web, usarán unos colores acordes al
problemas visuales a la hora de interactuar con las apps. Cabe destacar el uso de un tamaño de letra lo bastante apto para personas con hipermetropía, al igual que el de las imágenes. La interfaz debe ser intuitiva y de fácil uso para el aprendizaje de las apps.
2.4.2. Accesibilidad:
A la app móvil podrá acceder cualquier dispositivo que utilice el sistema operativo Android. A la web se puede acceder desde cualquier dispositivo que contenga conexión a internet y un navegador web.
2.4.3. Rendimiento:
Debe tener cuidado con el consumo de CPU, de RAM y de batería de nuestros dispositivos a la hora de acceder a alguna de las apps.
2.4.4. Usabilidad:
El tiempo de respuesta de cada acción que realice el usuario debe ser rápida y clara, para que este no se “aburra” de utilizar la app.
2.5. Casos de uso
Un caso de uso es la descripción de una acción o actividad. Un diagrama de caso de uso es una descripción de las actividades que deberá realizar alguien o algo para llevar a cabo algún proceso. Los personajes o entidades que participarán en un diagrama de caso de uso se denominan actores [3].
2.5.1. Diagrama de caso de uso:
En este esquema se muestra un diagrama de caso de uso. Tenemos dos actores principales. Por una parte el cliente, que es el usuario que realizará las reservas de los productos con la app móvil. Por otra un usuario administrador, que será un trabajador del negocio en cuestión, el cuál se encargará de la gestión de las reservas y de los productos. En el diagrama se muestran las actividades que realizará cada uno.
Figura 2.2: Diagrama de caso de uso.
2.5.2. Declaración de casos de uso (historias de los casos) A continuación voy a realizar un análisis de los requisitos del proyecto al objeto de obtener una declaración detallada de los distintos actores intervinientes y de los casos de uso asociado:
Actor Use case Business value
ID
1 Cliente Visualizar
productos/ofertas
El cliente puede ver todos los productos y las ofertas
del comercio
2 Cliente Realizar una reserva El cliente puede realizar la reserva de un producto.
3 Cliente Visualizar reservas El cliente puede visualizar sus reservas
4 Administrador Gestionar productos El administrador podrá crear, editar o eliminar los
productos del comercio
5 Administrador Visualizar
productos/ofertas
El administrador podrá ver todos los productos 6 Administrador Aceptar/Cancelar
reservas
El administrador decidirá si acepta o no una reserva
realizada por un cliente 7 Administrador Visualizar reservas El administrador
visualizará todas las reservas realizadas por
clientes.
Tabla 2.5: Declaración de casos de uso
Descripción textual “Visualizar productos/ofertas”: En esta tabla se muestra los pasos que seguirán el cliente y el administrado para visualizar los productos del negocio en sí:
Use case Visualizar productos/ofertas Primary actor Cliente y Administrador
System Supermercado 4.0
Participants Cliente y Administrador
Preconditions Administrador y cliente tienen credenciales
Basic flow
1 Login
2 Seleccionar categoría 3 Visualizar producto/oferta 4 Exit
Alternative flow
1.A Si login es incorrecto, va al 6 4.A Si no hay ofertas, va al 2
Tabla 2.6: Descripción textual “Visualizar productos"
Descripción textual “Realizar oferta”: A continuación se describe textualmente los pasos a seguir por el cliente para realizar una reserva, y las rutas alternativas que tendría.
Use case Realizar reserva
Primary actor Cliente
System Supermercado 4.0
Participants Cliente
Preconditions Cliente tienen credenciales
Basic flow
1 Login
2 Seleccionar categoría 3 Visualizar producto 4 Realizar reserva 5 Exit
Alternative flow
1.A Si login incorrecto, va a 5 4.A if (stock==0) va al 3
Tabla 2.7: Descripción textual “Realizar oferta"
Descripción textual “Gestionar productos”: Descripción de los pasos a seguir por el administrador cuando gestione los productos en la app web.
Use case Gestionar productos
Primary actor Administrador
System Supermercado 4.0 Participants Administrador
Preconditions Administrador tiene credenciales
Basic flow
1 Login
2 Crear nuevo producto 3 Modificar producto 4 Eliminar producto 5 Guardar producto 6 Exit
Alternative flow
1.A Si login es incorrecto, va al 6
2.A Si creas un nuevo producto, va al 5.
3.A Si modificas un producto, va al 5
Tabla 2.8: Descripción textual “Gestionar productos"
Descripción textual “Visualizar reservas”: Camino a seguir por el cliente y el administrador a la hora de visualizar una reserva realizada por un determinado cliente.
Use case Visualizar reservas
Primary actor Cliente y Administrador
System Supermercado 4.0
Participants Cliente y Administrador
Preconditions Administrador y cliente tienen credenciales
Basic flow
1 Login
2 Seleccionar reservas
3 Visualizar reservas 4 Exit
Alternative flow
1.A Si login es incorrecto, va al 4 4.A Si no hay reservas, va al 2
Tabla 2.9: Descripción textual “Visualizar reservas"
Descripción textual “Aceptar/Cancelar reservas”: El administrador tendrá el poder de aceptar o cancelar la reserva que ha realizado un cliente. En esta tabla se muestran los pasos a seguir para que llegue a realizar esta tarea,
Use case Aceptar/Cancelar reservas
Primary actor Administrador
System Supermercado 4.0
Participants Administrador
Preconditions Administrador y cliente tienen credenciales
Basic flow
1 Login
2 Seleccionar gestionar reservas 3 Visualizar reservas pendientes 4 Aceptar
5 Cancelar 6 Exit
Alternative flow
1.A Si login es incorrecto, va al 6
3.A Si no hay reservas pendientes, va al 2
Tabla 2.10: Descripción textual “Aceptar/Cancelar reservas"
2.6. Diagrama de máquina de estados:
Este tipo de diagramas permite detallar el funcionamiento interno del sistema o de alguna de sus partes. Modela el comportamiento de un solo objeto, especificando la secuencia de eventos que un objeto atraviesa durante su tiempo de vida en respuesta a los eventos.
2.6.1. Diagrama de app móvil
En este diagrama se detalla el funcionamiento que tendrá la app móvil con el usuario cliente.
Figura 2.3: Diagrama de máquina de estados (I).
El usuario inicia sesión. Si no está registrado en el sistema se le pedirá que se registre con su cuenta de gmail. Una vez registrado tiene distintas opciones a las que acceder. A la hora de reservar un producto, tanto estando en oferta como no, debe comprobar que el producto este disponible (stock>0) y que la oferta no finalice
antes de reservarlo. Una vez finalizadas todas la trasacciones que quiera realizar, puede cerrar sesion y el ciclo vuelve a comenzar.
2.6.2. Diagrama de app web
En este diagrama se detalla el funcionamiento que tendrá la app móvi con el usuario admistrador.
Figura 2.4: Diagrama de máquina de estados (II).
El usuario inicia sesión. Ya que los datos de acceso están predeterminados, si no introduce los datos correctamente no podrá acceder al sistema, y no tiene opción de registrarse. Una vez iniciada la sesión, puede acceder a los distintos productos para realizar un CRUD sobre ellos. También puede gestionar las reservas que tenga pendientes de los usuarios. Una vez finalizada la tarea a realizar, cerrará sesión.
2.7. Diagrama de clases
El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus relaciones con los demás objetos, pero no muestra información temporal.
Con el fin de facilitar la comprensión del diagrama, se pueden incluir paquetes como elementos del mismo, donde cada uno de ellos agrupa un conjunto de clases.
Los elementos básicos del diagrama son:
Clases:
Una clase describe un conjunto de objetos con propiedades (atributos) similares y un comportamiento com n. Los objetos son instancias de las clases.
No existe un procedimiento inmediato que permita localizar las clases del diagrama de clases. stas suelen corresponderse con sustantivos que hacen referencia al ámbito del sistema de información y que se encuentran en los documentos de las especificaciones de requisitos y los casos de uso.
Dentro de la estructura de una clase se definen los atributos y las operaciones o m todos.
Los atributos de una clase representan los datos asociados a los objetos instanciados por esa clase.
Las operaciones o m todos representan las funciones o procesos propios de los objetos de una clase, caracterizando a dichos objetos.
Relaciones:
siguientes:
Asociación. Las relaciones de asociación representan un conjunto de enlaces entre objetos o instancias de clases. Es el tipo de relación más general, y denota básicamente una dependencia semántica. Por ejemplo, una Persona trabaja para una Empresa.
Herencia.
cual se hereda se denomina superclase, y la que hereda subclase.
Generalización. define una superclase a partir de otras. Por ejemplo, de las clases profesor y estudiantes obtiene la superclase persona. La especialización o especificación es la operación inversa, y en ella una clase se descompone en una o varias subclases. Por ejemplo, de la clase empleado se pueden obtener las subclases secretaria, t cnico e ingeniero.
Agregación que - parte- motor, ruedas, carrocería son parte de automóvil.
Co posición.
ones entre la clase máquina y producto, o entre máquina y depósito de monedas
Dependencia.
una clase y una interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus servicios.
Figura 2.5: Diagrama de clases app móvil
2.8. Diseño de la app móvil
2.8.1. Metáfora visual
Es un recurso que consiste en utilizar un objeto para designar a otro y así apropiarse de sus cualidades. En este apartado se explican los significados de cada icono utilizado en las aplicaciones.
Figura 2.6: Metáfora visual (I)
En la vista principal de la app móvil nos encontraremos con un icono en la barra superior. Si pinchamos este icono accedemos al menú de productos y de información del usuario.
Figura 2.7: Metáfora visual (II)
Dentro de la vista de contacto, nos encontramos con estos dos iconos. Si pulsamos el primero (teléfono), llamaremos directamente al número de teléfono que tenemos en la información de al lado. El icono de Gmail, nos indica que una vez que rellenemos los campos descritos y pulsemos enviar, la información recogida se mandará por Gmail.
Figura 2.8: Metáfora visual (III)
En la vista de tiendas, nos encontramos con estos cuatro iconos. El más y el menos de la derecha sirven para usar el zoom en el mapa. Este icono , abre google maps con la ubicación marcada en el mapa. La flecha azul que marca hacia la derecha, abre google maps con la opción de cómo llegar.
Figura 2.9: Metáfora visual (IV)
Flecha de retroceso entre vistas. Cuando pulsemos este icono volveremos a la vista principal.
Figura 2.10: Metáfora visual (V).
Dentro de la vista de las ofertas y de los productos, nos encontramos con este icono. Indica que podemos realizar búsqueda de los productos por nombre.
Figura 2.11: Metáfora visual (VI).
En la vista de las ofertas veremos el icono de un reloj y un contador descendente. Este nos indica el tiempo restante antes de que finalice una oferta.
Figura 2.12: Metáfora visual (VIII).
Al iniciar sesión en la app web, nos encontraremos con esta opción en el menú lateral. Si pinchamos sobre ella tendremos la opción de añadir un nuevo producto a la aplicación.
Figura 2.13: Metáfora visual (IX).
Cuando accedemos a la información de un determinado producto, podemos ver en la línea estos dos iconos. El primero es para editar la información del producto, y el segundo para eliminarlo de la aplicación.
Figura 2.14: Metáfora visual (X).
Cuando queremos editar o añadir un nuevo producto, al lado del campo de tipo de oferta nos encontramos con un icono azul con una “i” en el interior. Si pinchamos sobre él, aparecerá una ventana emergente con información de los distintos tipos de ofertas que existen.
Figura 2.15: Metáfora visual (XI).
Una vez que un usuario ha realizado una reserva, esta aparecerá reflejada en la gestión de reservas del administrador. Este último tiene la opción de aceptar o de cancelar dicha reserva. Si pincha sobre el icono verde la aceptará, y en cambio, el icono rojo la cancelará.
2.8.2. Storyboard
Un Storyboard es un concepto que puede tener varios significados, ambos conectados al sector del marketing digital. Por una parte, puede hablarse de él como una ristra de viñetas o ilustraciones similares a un cómic, pero mucho más sencillas, con las que se plantea la guía a seguir a la hora de realizar una animación o plantear un vídeo. Por otra, puede usarse también para hablar, en el campo de la experiencia de los usuarios, de cómo funcionará un producto o un servicio.
A continuación voy a mostrar los storyboard tanto de la app móvil como de la aplicación web. Cabe destacar, como indica un storyboard, que esta no es versión final de la interfaz, pero si mantiene al menos el 90% de lo que se puede visualizar en las siguientes imágenes.
Estos storyboards han sido diseñados en un sitio web llamado marvelapp, donde además de poder crear el diseño te da la opción de similar el funcionamiento de la app que quieras crear. Para ver el funcionamiento del storyboard de la app
móvil puedes acceder a este enlace
https://marvelapp.com/5h6a71g/screen/56514320.
Figura 2.16: Storyboard app móvil (I)
Figura 2.17: Storyboard app móvil (I)
Figura 2.18: Storyboard app móvil (III)
Figura 2.19: Storyboard app móvil (IV)
Figura 2.20: Storyboard app móvil (V)
Figura 2.21: Storyboard app móvil (VI)
Figura 2.22: Storyboard app móvil (VII)
Figura 2.23: Storyboard app móvil (VIII)
2.9. Diseño de la app web
Este es el storyboard de la aplicación web. En este enlace se puede simular su funcionamiento: https://marvelapp.com/391379a/screen/59001516.
Figura 2.24: Storyboard app web (I)
Figura 2.25: Storyboard app web (II)
Figura 2.26: Storyboard app web (III)
Figura 2.27: Storyboard app web (IV)
Figura 2.28: Storyboard app web (V)
Figura 2.29: Storyboard app web (VI)
2.10. Base de datos
Comentaré la estructura de la base de datos donde tengo almacenados los productos y las reservas, así como, el usuario administrador. Esta ha sido creada bajo el software de Firebase. Cabe destacar que este tipo de base de datos utiliza estructura nosql. Para el acceso del administrador a la app web he usado una base de datos relacional desde el hosting donde tengo alojado mi sitio web.
Nosql: Los datos almacenados no requieren estructuras fijas como tablas, normalmente no soportan operaciones JOIN, ni garantizan completamente ACID (atomicidad, consistencia, aislamiento y durabilidad) y habitualmente escalan bien horizontalmente. Los sistemas NoSQL se denominan a veces
"no sólo SQL" para subrayar el hecho de que también pueden soportar lenguajes de consulta de tipo SQL [4]. Cabe añadir a esta definición que en este caso la forma en la que se almacena la información es en una estructura json, es decir, en forma de árbol.
Sql Para esta ocasión he utilizado una base de datos sql: Es un lenguaje de dominio específico utilizado en programación, diseñado para administrar, y recuperar información de sistemas de gestión de bases de datos relacionales.
Una de sus principales características es el manejo del álgebra y el cálculo relacional para efectuar consultas con el fin de recuperar, de forma sencilla, información de bases de datos, así como realizar cambios en ellas [5].
Figura 2.30: Estructura productos en la bddd.
Esta es la forma en la que se almacena un producto. Como vemos la estructura se clasifica por niveles. En el primer nivel tenemos el nombre de nuestro proyecto:
“arduino-1308”. Dentro de este diferenciamos dos niveles al mismo nivel, por un lado
“Productos” y por otros “Reservas”. Dentro del primero, diferenciamos cada producto por un identificador, y dentro de este tenemos los atributos del producto. Podemos elegir distintos tipos de datos para los atributos, yo he preferido usar cadena de texto (string) para cada uno:
categoría: Indica la categoría a la que pertenece dicho producto. Es una forma de clasificarlo para mostrarlo en la app móvil.
fechaCaducidad: Es la fecha en la que el producto caducará.
id: Identificador del producto, lo pongo como “atributo” para poder acceder de formas más cómoda a él.
imagen: Es la ruta URL de la imagen del producto que se mostrará en app móvil.
nombre: Breve descripción del producto.
nuevoPrecio: Nuevo precio que el producto tiene después de haberle aplicado el descuento de una oferta.
porcientoOferta: Tanto por ciento de descuento que se le aplicará al producto cuando esté de oferta.
precio: Precio original del producto.
stock: Número de unidades que existen de ese producto.
tipoOferta: Según el tipo de oferta que apliquemos al producto (específica, general o ninguna), lo indicaré con un dos, uno o cero respectivamente.
Figura 2.31: Estructura “Reservas” en la bbdd.
aceptada: Verifica el estado de la reserva. Tiene tres estados, en espera, aceptada o cancelada (cero, uno o dos respectivamente).
detallesProducto: Muestra la información del producto que se ha reservado
fechaAceptacion: Fecha en la que el administrador ha aceptado o cancelado la reserva.
fechaReserva: Fecha en la que el usuario realizó la reserva.
idProducto: Identificador del producto que se ha reservado.
idUsuario: Identificador del usuario que ha realizado la reserva.
nombreUser: Nombre del usuario que realizó la reserva.
precioProducto: Precio por el que el usuario ha realizado la reserva.
Figura 2.32: Estructura “Ofertas específicas” en la bbdd.
Para las ofertas específicas ha sido necesario almacenar los valores aplicados por el administrador. Cabe destacar que los valores de tiempo recogidos son en minutos. Esto es para hacer la simulación durante la presentación del proyecto.
%final: Porcentaje de descuento final en el que acabará el producto.
%inicial: Porcentaje de descuento inicial que tendrá el producto.
idProducto: Identificador del producto asociado a dicha oferta.
tiempoComienzo: Es el tiempo restante entre el actual y el de caducidad, en el cual comenzará la oferta.
tiempoReduccion: Es la fracción de tiempo que durará la oferta antes de aplicarle un nuevo descuento.
Esta base de datos está orientada a la gestión de productos, ofertas y reservas del proyecto.
La siguiente base de datos es utilizada para el acceso a la web del administrador
Figura 2.33: Atributos tabla user
id: Clave primaria de la tabla user. Es autoincrementable.
username: Nombre de usuario para que el administrador acceda a la web.
password: Clave de acceso del administrador a la web.
grupo: Selecciona el grupo al que pertenece el administrador, “1” en este caso, para darle acceso a las diferentes vistas de la web. Es un método utilizado para la seguridad de acceso de la web.
Cabe destacar que el username y password del administrador será creado predeterminadamente, de manera que si otro usuario quiere tener acceso a la web tendrá que ponerse en contacto con el servico técnico del proyecto.
Capítulo 3: Estudio del
módulo Arduino
Arduino es una compañía de código y hardware abierto que se enfoca en construir dispositivos digitales e interactivos que puedan controlar objetos del mundo real. Se enfoca en acercar y facilitar el uso de la electrónica y programación de sistemas embebidos en proyectos multidisciplinarios.
El hardware consiste de un microcontrolador conectado bajo la configuración de “sistema mínimo” sobre una placa de circuito impreso a la que se pueden conectar placas de expansión (shields) a través de la disposición de los puertos de entrada y salida presentes en la placa seleccionada.
El software consiste en dos elementos:
Un entorno de desarrollo (IDE) basado en el entorno de processing y en la estructura del lenguaje de programación Wiring.
Cargador de arranque, que es ejecutado de forma automática dentro del microcontrolador en cuanto este se enciende.
Las placas de Arduino se programan mediante un computador, usando comunicación en serie.
Figura 3.1: Arduino Mega
3.1. Tipos de Arduino
Existen distintos tipos de Arduino que según la memoria flash que contiene o el número de pines de entrada y salida del dispositivo. A continuación voy a exponer una pequeña tabla con las principales diferencias entre unos y otros:
Modelo Características
Arduino UNO Microcontrolador: ATmega328
Voltaje de funcionamiento: 5 V Pines I/O digitales: 14 (de los cuales 6 proveen salida PWM)
Pines de entradas análogas: 6 Corriente DC por cada pin I/O: 40 mA
Corriente DC en el pin de 3.3 V: 50 mA
Memoria Flash: 32 KB (ATmega328) de los cuales 0.5 KB son utilizados por el bootloader
SRAM: 2 KB (ATmega328) EEPROM: 1 KB (ATmega328) Velocidad de reloj: 16 MHz
Arduino Leonardo Microcontrolador: ATmega32u4
Voltaje de funcionamiento: 5 V Pines I/O digitales: 20
Canales PWM: 7
Pines de entradas análogas:12 Corriente DC por cada pin I/O: 40 mA
Corriente DC en el pin de 3.3 V: 50 mA
Memoria Flash: 32 KB (ATmega32u4) de los cuales 4 KB son utilizados por el bootloader
SRAM: 2 KB (ATmega32u4) EEPROM: 1 KB (ATmega32u4) Velocidad de reloj: 16 MHz
Arduino Due Microcontrolador:AT91SAM3X8E
Voltaje de funcionamiento:3.3 V Pines I/O digitales: 54 (de los cuales 12 proveen salida PWM)
Pines de entradas análogas:12 Corriente DC total en todos los pines I/O: 130 mA
Corriente DC en el pin de 5 V:800 mA
Corriente DC en el pin de 3.3 V: 800 mA
Memoria Flash: 512 KB disponibles
para las aplicaciones de usuario.
SRAM: 96 KB (dos bancos: 64KB Y 32 KB)
Velocidad de reloj: 84 MHz
Arduino Yún Microcontrolador AVR Arduino:
ATmega32u4
Voltaje de funcionamiento: 5 V Pines I/O digitales: 20
Canales PWM: 7
Pines de entradas análogas:12 Corriente DC por cada pin I/O: 40 mA
Corriente DC en el pin de 3.3 V: 50 mA
Memoria Flash: 32 KB (de los cuales 4 KB son utilizados por el bootloader SRAM: 2.5 KB
EEPROM: 1 KB
Velocidad de reloj: 16 MHz Procesador Linux: Atheros AR9331 Arquitectura: MIPS @400MHz Ethernet: IEEE 802.3 10/100Mbit/s WiFi: IEEE 802.11b/g/n
USB Tipo A: 2.0
Lector de tarjeta: sólo Micro-SD RAM: 64 MB DDR2
Memoria Flash:16 MB
Arduino Robot Microcontrolador: ATmega32u4
Voltaje de funcionamiento: 5 V Pines I/O digitales: 5
Canales PWM: 6
Canales de entradas análogas: 4 (de los pines digitales I/O)
Canales (multiplexados) de entradas análogas: 8
Corriente DC por cada pin I/O: 40 mA
Memoria Flash: 32 KB (ATmega32u4) de los cuales 4 KB son utilizados por el bootloader
SRAM: 2 KB (ATmega32u4)
EEPROM (interno): 1 KB (ATmega32u4)
EEPROM (externo): 512 KB (I2C) Velocidad de reloj: 16 MHz Teclado: 5 teclas
Perilla: Potenciómetro conectado a un pin análogo
LCD a color: Comunicación SPI Lector de tarjetas SD: Para tarjetas formateadas FAT16
Altavoz: 8 Ohms
Compás digital: Proporciona la desviación desde el norte geográfico en grados
Áreas de prototipado: 4
Arduino Esplora Microcontrolador: ATmega32u4
Voltaje de funcionamiento: 5 V Memoria Flash: 32 KB de los cuales 4 KB son utilizados por el bootloader SRAM: 2.5 KB
EEPROM: 1 KB
Velocidad de reloj: 16 MHz 4 Push bottons
Joystick análoga con un push botton central
Potenciómetro lineal Micrófono
Fotorresistor
Sensor de temperatura Acelerómetro de 3 ejes Buzzer
Led RGB
Conector para LCD
Arduino Mega ADK Microcontrolador: ATmega2560
Voltaje de funcionamiento: 5 V Pines I/O digitales: 54 (de los cuales 15 proveen salida PWM)
Pines de entradas análogas:16 Corriente DC por cada pin I/O: 40 mA
Corriente DCen el pin de 3.3 V: 50 mA
Memoria Flash: 256 KB de los cuales 8 KB son utilizados por el bootloader SRAM: 8 KB
EEPROM: 4 KB
Velocidad de reloj: 16 MHz
Arduino Ethernet Microcontrolador: ATmega328
Voltaje de funcionamiento: 5 V Pines I/O digitales: 14 (de los cuales 4 proveen salida PWM)
Pines de entradas análogas: 6 Corriente DC por cada pin I/O: 40 mA
Corriente DC en el pin de 3.3 V: 50 mA
Memoria Flash: 32 KB (ATmega328) de los cuales 0.5 KB son utilizados por el bootloader
SRAM: 2 KB (ATmega328)
