├── .DS_Store ├── lectures ├── .DS_Store ├── tmp │ └── .DS_Store └── pdf │ ├── IIC2173-02-NFR.pdf │ ├── IIC2173-04-Conectores.pdf │ ├── IIC2173-01-Introduccion.pdf │ ├── IIC2173-05-Escalabilidad.pdf │ ├── IIC2173-06-Performance.pdf │ └── IIC2173-03-Patrones_y_Estilos.pdf ├── lander-pf ├── .DS_Store ├── .classpath └── .project ├── Pautas ├── Ies │ ├── I1-pseudopauta.docx │ └── I2-enunciado_pseudopauta.v2.docx ├── Presentaciones │ └── Presentacion 1.md └── Controles │ ├── C3.md │ ├── C2.md │ └── C1.md ├── Ayudantias ├── Guias │ └── Tutorial AWS.pdf ├── AY01 │ └── IIC2713_AY1_cloud_intro.pdf └── AY02 │ └── IIC2713_AY2_linux_intro.pdf ├── .gitignore ├── Proyecto ├── E0 │ └── README.md ├── E2 │ └── Entrega 2.md ├── E1 │ └── Entrega 1.md ├── Entrega final │ └── Entrega_final.md └── Enunciado general.md └── README.md /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/.DS_Store -------------------------------------------------------------------------------- /lectures/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/.DS_Store -------------------------------------------------------------------------------- /lander-pf/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lander-pf/.DS_Store -------------------------------------------------------------------------------- /lectures/tmp/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/tmp/.DS_Store -------------------------------------------------------------------------------- /Pautas/Ies/I1-pseudopauta.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/Pautas/Ies/I1-pseudopauta.docx -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-02-NFR.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-02-NFR.pdf -------------------------------------------------------------------------------- /Ayudantias/Guias/Tutorial AWS.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/Ayudantias/Guias/Tutorial AWS.pdf -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-04-Conectores.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-04-Conectores.pdf -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-01-Introduccion.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-01-Introduccion.pdf -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-05-Escalabilidad.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-05-Escalabilidad.pdf -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-06-Performance.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-06-Performance.pdf -------------------------------------------------------------------------------- /Ayudantias/AY01/IIC2713_AY1_cloud_intro.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/Ayudantias/AY01/IIC2713_AY1_cloud_intro.pdf -------------------------------------------------------------------------------- /Ayudantias/AY02/IIC2713_AY2_linux_intro.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/Ayudantias/AY02/IIC2713_AY2_linux_intro.pdf -------------------------------------------------------------------------------- /Pautas/Ies/I2-enunciado_pseudopauta.v2.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/Pautas/Ies/I2-enunciado_pseudopauta.v2.docx -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | lectures/*.key 2 | ./lectures/*.key 3 | lectures/tmp/* 4 | ./lectures/tmp/* 5 | tarea/*.tmp 6 | ./tarea/*.tmp 7 | 8 | 9 | -------------------------------------------------------------------------------- /lectures/pdf/IIC2173-03-Patrones_y_Estilos.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/iic2173/2019-02/HEAD/lectures/pdf/IIC2173-03-Patrones_y_Estilos.pdf -------------------------------------------------------------------------------- /lander-pf/.classpath: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | -------------------------------------------------------------------------------- /lander-pf/.project: -------------------------------------------------------------------------------- 1 | 2 | 3 | lander-pf 4 | 5 | 6 | 7 | 8 | 9 | org.eclipse.jdt.core.javabuilder 10 | 11 | 12 | 13 | 14 | 15 | org.eclipse.jdt.core.javanature 16 | 17 | 18 | -------------------------------------------------------------------------------- /Proyecto/E0/README.md: -------------------------------------------------------------------------------- 1 | # IIC2173 - Entrega 0 2 | 3 | ## Fecha límite 4 | 5 | Debe ser entregada a más tardar a las 23:59 del 6 de Septiembre. Las condiciones de entrega están explicadas más abajo. 6 | 7 | ## Objetivo 8 | 9 | La entrega tiene por objetivo ser una introducción al trabajo con servicios en la nube. Para esto, deberán configurar un servidor básico en la nube y *deployear* una pequeña aplicación. 10 | 11 | ## Requisitos 12 | Les daremos indicaciones de como crear un servidor en AWS y montar su aplicacion. En este deberán configurar un servicio web que implemente un chat anónimo, donde los usuarios puedan hablar con un alias temporal. Adicionalmente, el sitio deberá consultar alguna API de internet (que ustedes consideren pertinente, lo que ustedes prefieran), y mostrar los resultados en el sitio. 13 | 👀: **No es necesario que el sistema esté conectado a una base de datos**. 14 | 15 | El servicio de chat pueden desarrollarlo con el framework que deseen, **EXCEPTO**: 16 | 17 | * Koa/express 18 | * Ruby on Rails 19 | * PHP 20 | 21 | Pueden utilizar cualquier otro que esté basado en: 22 | 23 | * C/C++ :ok_hand: 24 | * ASP.NET 25 | * Python 26 | * Javascript 27 | * Rust 28 | * Go 29 | * Java 30 | * Kotlin 31 | * Prolog 32 | * Brainfuck 33 | 34 | Pueden preguntar en las *issues* si quieren usar otro lenguaje. 35 | 36 | Cada servidor tendrá que tener un dominio TK, ML o GA asignado. Los dominios TK son gratuitos, y pueden conseguirlos fácilmente en Freenom. 37 | 38 | Finalmente, en el servidor deberán configurar un servicio *proxy* inverso con NGINX o Apache, que soporte SSL vía *Let's encrypt*. 39 | 40 | ## Enlaces relevantes 41 | 42 | * https://phoenixnap.com/kb/ssh-to-connect-to-remote-server-linux-or-windows 43 | * https://www.digitalocean.com/community/tags/deployment?type=tutorials 44 | * https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-18-04-quickstart 45 | * https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/ 46 | * https://www.freenom.com/es/index.html?lang=es 47 | * https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/ 48 | 49 | ## Criterios de evaluación 50 | 51 | La entrega tendrá 47 puntos. 47 puntos equivalen a un 7.0 52 | 53 | ### Requisitos funcionales 54 | 55 | * **RF1: (10p)** Se debe poder enviar mensajes y que se registre su timestamp. 56 | * **RF2: (8p)** Se debe poder ver los últimos 100 mensajes enviados en páginas de 5 mensajes cada una. 57 | * **RF3: (5p)** Se debe desplegar correctamente el contenido de la API. 58 | 59 | ### Requisitos no funcionales 60 | 61 | * **RNF1: (10p)** Debe haber un proxy inverso Nginx o Apache configurado. 62 | * **RNF2: (5p)** El servidor debe tener un nombre de dominio .tk, .ml o .ga 63 | * **RNF3: (8p)** El dominio debe estar asegurado por SSL. 64 | * **RNF4: (1p)** No usar PHP. 65 | 66 | ## Método de entrega 67 | 68 | Se abrirá un form para que entreguen el nombre de su dominio. Además, deben subir el código de su solución junto al archivo de configuracion de Nginx o Apache en el repositorio que se les asignará. 69 | -------------------------------------------------------------------------------- /Pautas/Presentaciones/Presentacion 1.md: -------------------------------------------------------------------------------- 1 | --- 2 | tags: iic2713_ayud 3 | --- 4 | 5 | # Pauta evaluacion presentaciones entrega 1 6 | 7 | ## Criterios 8 | 9 | * Presentación de cada una de las ideas de juego de los grupos. 10 | * Propuesta de interfaz y mockups de la interfaz general, detallando los puntos de acceso (en interfaz) para cada grupo del macrogrupo. 11 | * Flujo de la aplicación 12 | * Diagrama de deploy de la solución completa. 13 | * Propuestas de interacción entre los grupos y su correspondiente explicación. Al menos deben haber 4 tipos de interacción. De éstos, se les pedirá que 3 incluyan todos los juegos del macrogrupo. 14 | 15 | ## Puntuacion 16 | 17 | Cada punto principal (negro) tiene asociado un puntaje, y un ponderador 18 | * 0 (0) Ausente 19 | * 1 (0.2) Sumamente deficiente 20 | * 2 (0.4) Deficiente 21 | * 3 (0.6) Algunas deficiencias 22 | * 4 (0.8) Suficiente 23 | * 5 (1) Bien logrado 24 | * 6 (1.2) Sobresaliente 25 | 26 | ## Ideas de juego y "The Steam"(35%) 27 | 28 | * Originalidad 29 | * La complejidad del juego es apropiada. 30 | * Difiere del juego en que se inspiro (en caso de que se haya inspirado). 31 | * Calidad de las ideas 32 | * Es factible desarrollarla en el plazo pedido (lo justifican) 33 | * Presenta buena jugabilidad 34 | * Las tecnologías estan bien explicadas 35 | * Flujo de la aplicacion 36 | * Es posible entender el flujo de la aplicacion de forma lógica 37 | * Estan presentes todos los elementos básicos de funcionamiento de la aplicación 38 | 39 | ## Calidad técnica (35%) 40 | 41 | * Diagrama UML de deploy 42 | * Representa claramente la solución propuesta 43 | * Están todos los componentes principales. 44 | * Están todas los conectores principales. 45 | * Capacidad de abstracción. 46 | 47 | * Calidad de solución en la integración 48 | * Acoplamiento de componentes bajo. 49 | * No se ven requisitos no funcionales afectados. 50 | 51 | * Interaccion 1 52 | * Se explica porque la interaccion es significativa 53 | * Se ve como la interaccion comunicará con The Steam 54 | * La interaccion no es solo una feature de The Steam, implica presencia de modulos que interactuan en ambos lados 55 | * Interaccion 2 56 | * Mismos criterios que la *Interaccion 1* más 57 | * La interaccion comunica con los demás juegos de *The Steam* 58 | * Interaccion 3 59 | * Mismos criterios que la *Interaccion 2* 60 | * Interaccion 4 61 | * Mismos criterios que la *Interaccion 2* 62 | 63 | ## Calidad estética (20%) 64 | * Calidad del presentador 65 | * Cautiva al público. 66 | * Da a entender el juego y las soluciones con claridad 67 | * Buen formato de presentación 68 | * Diseño lógico 69 | * Texto legible 70 | * Faltas de ortografía. 71 | * Faltas < 2. Cada falta reduce en un punto este item 72 | * Cumple con el tiempo. 73 | * +-20 segundos. Cada 15 segundos, reduce en un punto este item 74 | 75 | ## Seccion preguntas (10%) 76 | 77 | * Respuesta correcta a las preguntas 78 | * Las aclaraciones en este ítem pueden hacer que la calificacion suba en los otros ítems 79 | * Justificacion de los requisitos no funcionales de uno o más juegos 80 | * Los miembros del grupo deben responder a las preguntas de al menos uno de los juegos -------------------------------------------------------------------------------- /Pautas/Controles/C3.md: -------------------------------------------------------------------------------- 1 | # IIC2173 - Pauta C3 2 | 3 | --- 4 | 5 | **P1.** ¿Qué es la escalabilidad? ¿Cuáles son sus tipos (cómo se puede llevar a cabo) y las características de cada uno de éstos? **(3 puntos)** ? 6 | 7 | **R:** La escalabilidad es un tipo de requerimiento no funcional, esta define la capacidad del software de adaptarse para alcanzar nuevos requisitos de tamaño y alcance. 8 | 9 | * **Horizontal:** Añadir más máquinas. 10 | * **Vertical:** Mejorar la máquina existente. 11 | 12 | **Comentario:** 13 | 14 | * 1 punto por definición correcta de escalabilidad. 15 | * 0.5 por cada tipo de escalabilidad nombrado. 16 | * 0.5 por explicación correcta del tipo de escalabilidad. 17 | 18 | 19 | --- 20 | **P2.** ¿En qué consiste el teorema CAP? Explique en no más de 6 líneas. **(2 puntos)** ? 21 | 22 | **R:** El teorema de CAP dice que, para un sistema de servidores distribuidos, es imposible garantizar simultáneamente la **consistencia, disponibilidad y tolerancia a la partición**. 23 | - Si tenemos alta disponibilidad y tolerancia de partición, entonces no podemos asegurar consistencia. 24 | - Si tenemos alta consistencia y tolerancia de partición, entonces no podemos asegurar disponibilidad. 25 | - Si tenemos alta consistencia y disponibilidad, entonces no podemos asegurar tolerancia de partición. 26 | 27 | 28 | **Comentario:** 29 | 30 | * 0.5 por cada definición 31 | * 0.5 por explicación correcta 32 | 33 | --- 34 | 35 | **P3.** ¿Cúal/es de las siguientes afirmaciones son correctas acerca de "Sharding"? **(2 puntos)** 36 | 37 | **R: Al tener menos tuplas, es más rápido indexar cada instancia de las tablas.** 38 | 39 | 40 | **OJO:** ¿Por qué no? 41 | > Al tener menos tuplas, es más rápido hacer todo tipo de consulta 42 | 43 | No todo tipo de consultas, si realizamos alguna que requiera recorrer todas nuestras particiones, pues entonces es más lento que tener todo junto. Recordar que las particiones se realizan para beneficiar alguna consulta que sea recurrente en nuestra base de datos. 44 | 45 | **Comentario:** 46 | 47 | * 2 puntos por alternativa correcta 48 | * 1 punto de descuento por alternativa incorrecta 49 | 50 | 51 | --- 52 | 53 | **P4.** Con una muy buena amiga usted quiere construir una pagina de adopción de gatitos en línea, donde las personas se registren y se les haga seguimiento. Esperan tener éxito instantáneo y cientos de clientes concurrentes. ¿Qué medidas de las siguientes son apropiadas para la capa que manejará la carga? **(2 puntos)** ? 54 | 55 | **R:** 56 | 57 | 1. ❌ Al ser una página que transita informacion sensible (básicamente informacion de usuarios), no se puede sacrificar seguridad por una ganancia marginal en performance (para el 2019). 58 | 2. ✅ Cachear las imágenes reduce tiempos de carga y tráfico en servidores, y es difícil que la imagen misma cambie. Los e-tags hacen mas eficiente la cache. 59 | 3. ✅ Natural. 60 | 4. ❌ Habrá que replicar la información para cada uno de los servidores, lo que tiene un costo enorme en espacio y transacciones a la hora de escribir. 61 | 5. ❌ El calor y el pelo suelto que sale de los gatos obstruye el funcionamiento de los servidores, reduciendo su vida útil y tapando el flujo de aire. 62 | 63 | **Comentario:** 64 | 65 | * 1 punto por respuesta correcta. 66 | * 1 punto de descuento por alternativa incorrecta. 67 | 68 | --- 69 | 70 | **P5.** Los CDN, content delivery networks, son intermediarios que uno puede utilizar (pagado por supuesto) para proporcionar contenido a los usuarios de forma acelerada, ofreciéndoles cierto tipo de archivos en un servidor de archivos mas cercano físicamente al usuario. ¿Como podría un CDN ayudar en el performance de una aplicación web? Menciona al menos 2 puntos clave. **(4 puntos)** ? 71 | 72 | **R: Ver comentario** (Puede haber más respuestas correctas). 73 | 74 | **Comentario:** 75 | 76 | * 2 puntos por mencionar que la aplicacion web ya no debe ocuparse de servir el contenido sino que se delega al CDN, liberando recursos. 77 | * 2 puntos por reconocer que la cercania fisica al usuario reduce la cantidad de saltos y por lo tanto la latencia. 78 | --- 79 | -------------------------------------------------------------------------------- /Pautas/Controles/C2.md: -------------------------------------------------------------------------------- 1 | 2 | # IIC2173 - Pauta C2 3 | 4 | --- 5 | 6 | **P1.** ¿Cuál de los siguientes conceptos NO es un rol que cumplen los conectores? **(2 puntos)** ? 7 | 8 | **R: Ninguna de las anteriores.** 9 | 10 | **Comentario:** Comunicación, Conversión, Facilitación y Coordinación son roles de los conectores. 11 | 12 | 13 | --- 14 | 15 | **P2.** ¿Cuál/es es/son una/s característica/s del conector de rol Coordinación **(2 puntos)**. 16 | 17 | **R: Separan el control del procesamiento y determinan el flujo de control.** 18 | 19 | 20 | **Comentario:** La interacción entre componentes que buscan interoperar (proveer una funcionalidad conjunta) no es una función de Coordinanción sino de Facilitación. Separar la comunicación del procesamiento es una funcionalidad de los Comunicadores. 21 | 22 | * 1 pts por colocar 1/2. 23 | * 0 pts por colocar 0/2. 24 | * Por cada respuesta mala 1 punto de descuento. 25 | 26 | 27 | --- 28 | 29 | 30 | **P3.** Si tuviera que diseñar un software que requiera la implementación de notificaciones para su funcionamiento. ¿Qué tipo de conector utilizaría para su solución? ¿Por qué? **(4 punto)**. 31 | 32 | **R:** Se debe utilizar un conector de Coordinación y Comunicación, Eventos. Esto debido a que transfiere datos sobre el evento a los componentes interesados y no se encarga de procesar la información. 33 | 34 | 35 | **Comentario:** 36 | 37 | * 1 punto por señalar el conector. 38 | * 3 puntos por explicación. 39 | 40 | 41 | --- 42 | **P4.** Las distribuciones de actualizaciones de software vía "OTA update" [https://en.wikipedia.org/wiki/Over-the-air_programming] para dispositivos embebidos es clave hoy en día. Te piden implementar una versión de este servicio de distribución. ¿Con qué composición de conectores (al menos dos conectores, pero pueden ser más) lo implementarías? ¿Qué valores deberían tener sus dimensiones? Menciona al menos dos dimensiones por conector. **(3 puntos)**. 43 | 44 | **R:** El conector depende de la explicación, pero algunos pueden ser: 45 | * **Eventos:** Para notificar al dispositivo que debe ser actualizado. Bajo las dimensiones: Notificación y síncronicidad. 46 | * **Streams:** Para la transferencia de datos que permitan llevar a cabo la actualización. Bajo las dimensiones: Localidad, Sincronicidad, Formato y Cardinalidad. 47 | * **Árbitro:** Para la encriptación y desencriptación de los datos, ya que no queremos que la transferencia sea intervenida. Bajo las dimensiones: Seguridad y Planificación. 48 | 49 | **Comentario:** 50 | 51 | * 1 punto por cada conector. 52 | * 0.25 puntos por cada dimensión. 53 | 54 | --- 55 | #### P5 56 | Hoy en día, esta muy en boga el concepto de "Serverless computing", (Ej: Google cloud functions, AWS lambda) este consiste en que los proveedores de cloud se preocupan de buena parte de la infraestructura, y cobran solamente por los recursos necesarios para ejecutar una función (RAM, espacio, tiempo, etc). ¿Cómo podrías integrar este nuevo paradigma a los estilos invocación implícita y Pipe and filter? Menciona al menos 3 aspectos clave para cada caso. (Hint: Recuerda que el control es de conectores) **(6 puntos)**. 57 | 58 | **R:** 59 | 60 | Es una pregunta de interpretacion, y los principales puntos que deberian verse son: 61 | 62 | Pipe and filter 63 | - Responder a los outputs de los filtros de forma escalable, sin limitar el flujo de datos del stream y escalando facilmente 64 | - Lograr algun procesamiento paralelo al stream completo, sin interrumpir el flujo principal 65 | - Fragmentar el stream en varias funciones serverless 66 | 67 | Invocacion implicita 68 | - En pub-sub: Atender de forma escalable las llamadas pub mas complejas que requieran procesamiento adicional para responder a los suscriptores 69 | - Acelerar los eventos del event-pipe que requieran procesamiento escalable para acelerar el flujo, en partes que necesitan alto paralelismo 70 | - Responder a solicitudes que no usan directamente el pipe de eventos, pero requieren atencion, como metadatos del servidor y estadisticas o creacion de logs de gran tamaño. 71 | 72 | 73 | **Comentario:** 74 | 75 | * 1 pto por cada aspecto clave. (3 para cada estilo) 76 | -------------------------------------------------------------------------------- /Pautas/Controles/C1.md: -------------------------------------------------------------------------------- 1 | # IIC2173 - Pauta C1 2 | 3 | --- 4 | 5 | **P1.** ¿Cúal de las siguientes alternativas no es un requerimiento no funcional (RNF) **(1 punto)** ? 6 | 7 | **R: Diseño.** 8 | 9 | **Comentario:** El diseño es un **requisito funcional**. 10 | 11 | 12 | --- 13 | 14 | **P2.** Imagine que implementará un sistema de votación universal donde las encuestas se pueden crear mediante clientes (CLI) para realizar encuestas y/o votaciones. Además, la votaciones se realizan con otro tipo de cliente (web o en app). La diferencia principal con los demás sistemas es que el mecanismo de registro de las votaciones se realiza con Blockchain. ¿Cual(es) de los siguientes atributos de calidad debería(n) ser fundamental(es) para el sistema? (hasta 3) **(1 punto)**. 15 | 16 | **R: Seguridad, Escalabilidad y Disponibilidad.** 17 | 18 | 19 | **Comentario:** ¿Por qué no performance? A priori no nos interesa si el sistema tiene un buen desempeño en el registro (guardar más rápido o más lento) ni procesamiento de los votos (de hecho, podría realizarse con otro servicio). Primero nos interesa que sea seguro (esencia de las votaciones), que sea escalable (universal) y que esté disponible la mayor parte del tiempo (cualquier horario). 20 | 21 | * 0.5 pts por colocar 2/3. 22 | * 0 pts por colocar 1/3. 23 | 24 | 25 | --- 26 | 27 | 28 | **P3.** Seleccione la(s) ventaja(s) del patrón arquitectónico "Pipe and filter" **(1 punto)**. 29 | 30 | **R:** 31 | * **Se puede reusar fácilmente** 32 | * **Cada filtro que implementemos puede ser utilizado en paralelo a los otros.** 33 | 34 | **Comentario:** La ventajas se encontraban en las diapositivas de las clases. 35 | 36 | * *Pipe and filter* **no** soporta aplicaciones interactivas porque el *stream* de datos tendría que ser serializado de byte a carácter (Contrario a lo que se desea, ya que queremos que los datos "fluyan" y olvidarnos de la fuente). 37 | * *Pipe and filter* **debe** ser implementada de forma secuencial (Es la forma de su arquitectura). 38 | 39 | Mas información en [Pipe and filter.](https://cs.uwaterloo.ca/~oadesina/slides/D2_Pipe_and_Filter.pdf) 40 | 41 | 42 | --- 43 | **P4.** Si tuviera que diseñar un software que requiera la implementación de notificaciones para su funcionamiento. ¿Qué patrón arquitectónico utilizaría para su solución? ¿Por qué? **(2 puntos)**. 44 | 45 | **R: Cualquiera del estilo "Invocación Implícita". Es decir Pub/Sub o Basado en eventos.** 46 | 47 | **Comentario:** Las notificaciones se manejan principalmente como eventos, ya que no hay un método que las desencadene. 48 | 49 | En el caso de Publisher/Subscriber: 50 | 51 | **Subscriptores** se registran/de-registran para recibir mensajes específicos o contenido específico. **Publicadores** difunden mensajes a subscriptores de manera síncrona o asíncrona. 52 | 53 | * 1 pto por nombrar el correcto. 54 | * 1 pto por buena explicación. 55 | 56 | **Nota:** ¿Por qué no MVC? Porque MVC es un patrón que se utiliza para interacciones con el usuario/cliente, donde él es el que llama a los métodos disponibles. Si existen "notificaciones" entre **sus** componentes, pero son netamente para la interacción con el usuario/cliente. 57 | 58 | 59 | --- 60 | **P5.** Se desea desarrollar un sistema para analizar el lecho marino a grandes profundidades mediante la utilización de submarinos que deben transferir la información y localizaciones a través de ondas de baja frecuencia entre ellos, para así mejorar la recolección de datos y sus interpretaciones. ¿Qué patrón arquitectónico utilizaría para su solución? ¿Por qué? **(2 puntos)**. 61 | 62 | **R: Peer-to-peer**. 63 | 64 | **Comentario:** Dado que los submarinos son la "fuente" de la información y se requiere que todos la compartan para mejorar la recolección de datos, el patrón que más se adecúa es Peer-to-peer, ya que cada submarino funciona como un nodo en la red bajo el agua, por lo que la transferencia de datos es mucho menos compleja que un servidor centralizado, sobre todo si están a "grandes profundidades". 65 | 66 | * 1 pto por nombrar el correcto. 67 | * 1 pto por buena explicación. 68 | 69 | *O también* 70 | 71 | * 1 punto por mencionar el patrón "Pizarra" y dar una buena explicación. 72 | 73 | **Nota:** ¿Por qué no Sensor-Controlador-Actuador? Este pudo haber sido un buen acercamiento al software que requiere el submarino para la propia recolección de datos. Sin embargo, el enfoque del problema era la transferencia de datos entre los submarinos y la complejidad de tener que hacerlo a grandes profundidades, lo cual limita bastante la posibilidad de utilizar un servidor en la superficie, además de que lo hace mucho menos confiable (en este caso). -------------------------------------------------------------------------------- /Proyecto/E2/Entrega 2.md: -------------------------------------------------------------------------------- 1 | 2 | # IIC2173 - Entrega 2 3 | 4 | ## Plazo 5 | 6 | Fecha de entrega en repositorio: 18 de octubre a las 23:59pm. 7 | Fecha de entrega coevaluación: 20 de octubre a las 23:59pm. 8 | Presentación: 18 de octubre a las 10:00am. 9 | 10 | ## Introducción 11 | 12 | Ya han definido como y que quieren hacer: es momento de lanzarse al desarrollo! 13 | 14 | En esta fase deberán entregar un prototipo funcional del juego y de *The Steam*, más la configuración de desarrollo operacional. 15 | 16 | ## Entregables 17 | 18 | Para la segunda entrega, tanto como **grupo** y **macrogrupo**, les pediremos que realicen lo siguiente: 19 | 20 | - Prototipo del juego/The Steam 21 | - No se espera grandes avances, sino que se pueda ver que existe un esqueleto simple del juego/The Steam, en algunas de sus características. 22 | 23 | - Deploy de su aplicación 24 | - Deberán montar sus propios servidores. 25 | - Se debe utilizar servicios **IaaS**. 26 | - Se puede tener más de un servidor por grupo/macrogrupo. (**ojo** con el manejo de los créditos) 27 | - Dominios 28 | - Cada servidor utilizado en el desarrollo su aplicación tendrá que tener un dominio TK, ML o GA asignado. 29 | - Los dominios TK son gratuitos, y pueden conseguirlos fácilmente en Freenom. 30 | - Docker 31 | - Deben configurar sus ambientes de desarrollo con Docker, en vista a usar docker-compose, AWS ECS, EKS u otro servicio de orquestado de containers. 32 | - Esto se debe realizar para The Steam, ya que es un servicio web. Y los grupos que tengan servicios web también deberán tener Docker implementado. De no tener web, no será necesario. 33 | - Continuous integration 34 | - Se pedirá asociar el repositorio a Travis CI/Circle CI. 35 | - No será necesario que se haga *deploy* automáticamente en sus servidores (debido a la dificultad), sino que se ejecuten los tests cada vez que hagan pull request a _development_. 36 | - Esto sólo se realizará para The Steam. 37 | - Testing 38 | - Se deberán testear las funcionalidades realizadas, principalmente las interacciones. 39 | - El objetivo es que el CI que utilicen corra estos tests, por lo que deberían ser tests unitarios/integración. 40 | - Requisitos no funcionales 41 | - Esto lo realizará solo el **grupo**. 42 | - Performance: El juego debe demorar máximo 2 segundos en empezar. Y menos de 1.5 segundos para el 90% de los casos. 43 | - Seguridad: la mensajería entre componentes y aplicaciones debe realizarse de forma encriptada. Además, todas las contraseñas y variables de entorno **no** deben ser públicas. 44 | - Confiabilidad: El juego debe poder guardar los datos de la partida ante alguna caída. El sistema de puntos debe reflejar los resultados reales de las partidas. 45 | - Disponibilidad: En el caso de que un juego deje de funcionar o que la conexión a Steam se vea perjudicada por el internet u otro factor, se debe poder seguir utilizando el sistema. El usuario no puede saber que se cayó el sistema. 46 | - Escalabilidad: Se deben realizar tests de carga para las interacciones entre los juegos ya que si se desean colocar más juegos o aumenta la carga del sistema, entonces las funcionalidades no podrán fallar. 47 | - Usabilidad: se debe realizar, con al menos 15 personas, pruebas de funcionalidad de las interacciones de la aplicación. Deben poder ser fácilmente usables desde el punto de vista del usuario. 48 | 49 | 50 | Finalmente, se les pedirá que como macrogrupo, hagan una presentación en formato PDF que incluya lo siguiente: 51 | 52 | - Nombre del macrogrupo 53 | - Presentacion de los avances de cada uno de los grupos. 54 | - Demo simple de los juegos del grupo. 55 | - Demo simple de *The Steam*. 56 | 57 | 58 | La presentación de esta entrega se hará en horario de ayudantía, y **debe asistir al menos una persona por grupo**, haciendo así **4 personas al menos por macrogrupo**. 59 | 60 | La presentación tendrá una duración de 10 minutos. Además, habrán 5 minutos para preguntas. 61 | 62 | ## Evaluación 63 | 64 | Esta entrega genera dos notas, **E1 grupal** por los artefactos pedidos para el grupo y **E1 macro** por la presentacion del macrogrupo. 65 | 66 | ### Grupal 67 | 68 | La nota grupal se calcula como: 69 | 70 | **E1 grupal = E1 grupo individual * 0.7 + E1 macro * 0.3** 71 | 72 | ### Individual 73 | 74 | Segun el programa del curso, esto se evalua como: 75 | 76 | **E1 = 1 + ((E1 grupal - 1) * Fg)** 77 | 78 | Donde Fg es un factor de coevaluación asignado por el grupo que va de 0 a 1.2. Para esto se enviará un form de coevaluación donde cada integrante deberá evaluar a sus compañeros de grupo con una puntuación entre 1 y 5. 79 | 80 | **No podrán asignarle 5 puntos a más de un compañero, y sí lo hacen, se considerará que se entregó un máximo de 4 puntos a cada compañero**. 81 | 82 | De no realizar la coevaluación, asumiremos que se le entregó el mismo puntaje de coevaluación a cada integrante, es decir 4 puntos. 83 | -------------------------------------------------------------------------------- /Proyecto/E1/Entrega 1.md: -------------------------------------------------------------------------------- 1 | # IIC2173 - Entrega 1 2 | 3 | ## Plazo 4 | 5 | * Fecha de entrega en repositorio: 25 de septiembre a las 23:59pm. 6 | * Fecha de entrega coevaluación: 26 de septiembre a las 23:59pm. 7 | * Presentación: 27 de septiembre a las 10:00am. 8 | 9 | ## Introduccion 10 | 11 | ***Se les sugiere fuertemente que lean el enunciado general antes de este enunciado.*** 12 | 13 | Esta es una entrega principalmente de planificación para lo que deben hacer, así que tiene un plazo más corto. 14 | 15 | En esta fase deberán entregar una propuesta de juego y de diseño, de acuerdo a *The Game* y que pueda ser utilizado por *The Steam*. 16 | 17 | ## Entregables 18 | 19 | Para la primera entrega como **grupo** les pediremos que entreguen un informe con lo siguiente: 20 | 21 | * Nombre del grupo. 22 | * Máx 2 planas explicando la propuesta de juego que desarrollarán durante el semestre, junto con las reglas del juego. 23 | * Explicación de las tecnologías que usarán en backend y frontend, y justificación de la elección. 24 | * Elección de 3 requisitos no funcionales generales que priorizarán en su software junto a su justificación correspondiente. De aquellas que escojan, se les pedirán ciertas metas y métricas objetivo para la siguiente entrega. Las elecciones disponibles son: 25 | * Performance 26 | * Seguridad 27 | * Confiabilidad 28 | * Disponibilidad 29 | * Escalabilidad 30 | * Usabilidad 31 | 32 | * Distribución del grupo, indicando los roles prioritarios de los miembros para el desarrollo del software. Además, se debe seleccionar a **dos** integrantes que serán los encargados de trabajar en representación del grupo. Ellos se encargarán de que su software funcione con el de los demás grupos pertenecientes al **macrogrupo**. 33 | * Diagrama UML de componentes de su solución particular. 34 | * Mockups de interfaz y actividades de usuario, detallando aspectos principales del juego. 35 | 36 | En la ayudantía de lanzamiento se les mostrarán ejemplos del nivel de juego que pueden presentar. Pueden preguntar a los ayudantes si la propuesta de juego que tienen es suficiente y es válida para el alcance del proyecto. Una vez escogida la propuesta, **no se puede cambiar después de esta entrega**. 37 | 38 | Se les pedirá además que, como **macrogrupo**, hagan una presentación en formato PDF que incluya lo siguiente: 39 | 40 | * Nombre para el macrogrupo. 41 | * Presentacion de cada una de las ideas de juego de los grupos. 42 | * Propuesta de interfaz y mockups de la interfaz general, detallando los puntos de acceso (en interfaz) para cada grupo del macrogrupo. 43 | * Diagrama de deploy de la solución completa. 44 | * Propuestas de interacción entre los grupos y su correspondiente explicación. Al menos deben haber 4 tipos de interacción. De éstos, se les pedirá que 3 incluyan todos los juegos del macrogrupo. 45 | 46 | 47 | (* Por interacción nos referimos a características y funcionalidades de los juegos, que hagan que los juegos puedan ser usados en una misma interfaz y/o plataforma. Por ejemplo: un chat de party. ) 48 | 49 | La presentación de esta entrega se hará en horario de ayudantía, y **debe asistir al menos una persona por grupo**, haciendo así **4 personas al menos por macrogrupo**. 50 | 51 | La presentación tendrá una duración de 10 minutos. Además, habrán 5 minutos para preguntas. 52 | 53 | ## Evaluación 54 | 55 | Esta entrega genera dos notas, **E1 grupal** por los artefactos pedidos para el grupo y **E1 macro** por la presentacion del macrogrupo. 56 | 57 | ### Grupal 58 | 59 | La nota grupal se calcula como 60 | 61 | **E1 grupal = E1 grupo individual * 0.7 + E1 macro * 0.3** 62 | 63 | ### Individual 64 | 65 | Segun el programa del curso, esto se evalua como: 66 | 67 | **E1 = 1 + ((E1 grupal - 1) * Fg)** 68 | 69 | Donde Fg es un factor de coevaluación asignado por el grupo que va de 0 a 1.2. Para esto se enviará un form de coevaluación donde cada integrante deberá evaluar a sus compañeros de grupo con una puntuación entre 0 y 5. 70 | 71 | **No podrán asignar a más de un compañero 5 puntos y sí lo hacen, se considerará que se entregó un máximo de 4 puntos a cada compañero**. 72 | 73 | De no hacer la coevaluación asumiermos que le entregó el mismo puntaje de coevaluación a cada integrante, es decir 4 puntos. 74 | 75 | 86 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # IIC2173 — Arquitectura de Sistemas de software 2 | 3 | ## Tabla de contenidos 4 | 5 | 6 | - [Equipo](#equipo) 7 | - [Profesor](#profesor) 8 | - [Ayudantes](#ayudantes) 9 | - [Objetivos](#objetivos) 10 | - [Contenidos](#contenidos) 11 | - [Evaluación](#evaluación) 12 | - [Interrogaciones y examen](#interrogaciones-y-examen) 13 | - [Controles](#controles) 14 | - [Proyecto](#proyecto) 15 | - [Criterio de aprobación](#criterio-de-aprobacion) 16 | - [Foro](#foro) 17 | - [Bibliografia](#bibliografia) 18 | - [Política de integridad académica](#política-de-integridad-académica) 19 | 20 | --- 21 | 22 | ## Equipo 23 | 24 | ### Profesor 25 | 26 | Nombre | GitHub | Email 27 | -------------- | ----------- | --------------------- 28 | Hans Findel | [@hansfindel] | [hjfindel@uc.cl] 29 | 30 | ### Ayudantes 31 | 32 | Nombre | GitHub | Email 33 | ---------------- | ------------- | ---------------- 34 | Nicolas Acosta | [@nacosta-cl] | [nlacosta@ing.puc.cl] 35 | Alejandro Ramirez | [@Elramirezv123] | [elramirez@uc.cl] 36 | Ignacio Contreras | [@nachocontreras] | [icontreras1@uc.cl] 37 | 38 | 39 | [@hansfindel]: https://github.com/hansfindel 40 | [@nacosta-cl]: https://github.com/nacosta-cl 41 | [@elramirezv123]: https://github.com/elramirezv123 42 | [@nachocontreras]: https://github.com/nachocontreras 43 | 44 | 45 | [hjfindel@uc.cl]: mailto:hjfindel@uc.cl 46 | [nlacosta@ing.puc.cl]: mailto:nlacosta@ing.puc.cl 47 | [elramirez@uc.cl]: mailto:elramirez@uc.cl 48 | [icontreras1@uc.cl]: mailto:icontreras1@uc.cl 49 | 50 | 51 | ## Objetivos 52 | - Tomar los requisitos para un sistema y desarrollar arquitecturas de software y diseños de alto nivel. 53 | - Diseñar software distribuido 54 | - Diseñar software usando componentes COTS (commercial off-the-shelf) 55 | - Aplicar frameworks y arquitecturas al diseñar una amplia variedad de software 56 | - Diseñar e implementar software usando tecnologías middleware 57 | 58 | 59 | ## Contenidos 60 | - Modelado y diseño de software flexible al nivel arquitectónico 61 | - Fundamentos de arquitectura dirigida por modelos 62 | - Estilos y patrones arquitectónicos 63 | - Armazones (frameworks) para middleware y para aplicaciones 64 | - Diseño usando software comercial off-the-shelf (COTS) 65 | - Configuraciones y gestión de la configuración 66 | - Líneas de productos 67 | 68 | 69 | ## Evaluación 70 | 71 | El curso posee 3 tipos de evaluación 72 | 73 | - Interrogaciones y Examen acumulativo 74 | - Controles 75 | - Proyecto 76 | 77 | 78 | ### Interrogaciones y examen 79 | 80 | El curso contará con 2 interrogaciones a lo largo del semestre. Estas serán en horario de clases en las siguientes fechas: 81 | 82 | Interrogación | Fecha 83 | :----------------:| ----------------------- 84 | 1 | Jueves 26 de septiembre 85 | 2 | Jueves 17 de octubre 86 | 87 | También el curso contará con un examen obligatorio. Este será un día de noviembre (fecha, hora, duración y sala por confirmar). 88 | 89 | Se calificara con nota NIE 90 | 91 | **NIE = 0.7 * PROMEDIO(I1,I2) + 0.3 * NE** 92 | 93 | ### Controles 94 | 95 | El curso contará con controles rápidos en clases o ayudantías sobre los contenidos del curso que se vayan viendo. Estas evaluaciones serán sorpresa y se notificarán a criterio del profesor. 96 | 97 | La nota de los controles **NC** se calcula como el promedio simple de las notas de controles, descontando el(los) peor(es) control(es). La falta a un control será calificada con nota 1 98 | 99 | **NC = (C1+...+Cn-minx(C1+...+Cn))/n-x** 100 | 101 | Donde n es el numero de controles que se hagan en el semestre y x la cantidad a descontar 102 | 103 | ### Proyecto 104 | 105 | El curso contará con una entrega introductoria individual (E0) y un proyecto a lo largo del semestre. 106 | 107 | Entrega | Publicación | Entrega 108 | --------------| ---------- | ------- 109 | E0 | 21 de agosto | 6 de septiembre 23:59 110 | 111 | El proyecto grupal tiene 4 fases y estas son 112 | 113 | ID fase | Publicación | Entrega | Presentacion | Fase 114 | --------------| ------ | --- | ---- | --------- 115 | E1 | 7 de septiembre | 25 de septiembre | 27 de septiembre | Propuesta y diseño 116 | E2 | 22 de septiembre | 18 de octubre | 18 de octubre | Prototipo 117 | E3 | 17 de octubre | 8 de noviembre | 8 de noviembre | MVP 118 | E4 | 9 de noviembre | TBA | TBA | Producto finalizado 119 | 120 | Se especificará en clases o ayudantía que se espera del proyecto y la estructuración de los equipos, ademas del desafio a resolver. 121 | 122 | Habrá un enunciado disponible para las fases 123 | 124 | La entrega grupal tiene un factor de ponderacion por macrogrupo, que se hace de la siguiente forma 125 | 126 | **Ei grupal = Egrupo individual * 0.7 + Ek macro * 0.3** 127 | 128 | Cada entrega tiene un componente de coevaluación, evaluado en 129 | 130 | **Ei = 1 + ((Ei grupal - 1) * Fg)** 131 | 132 | Donde Fg es un factor de coevaluación asignado por el grupo que va de 0 a 1.2 133 | 134 | La nota del proyecto total individual se calcula como 135 | 136 | **NP = 0.15 * E0 + 0.85 * PROMEDIO(E1,E2,E3,E4)** 137 | 138 | ### Criterio de aprobación 139 | 140 | Todas las notas se calculan con dos decimales, excepto la nota final que se entrega con un decimal. 141 | El curso se calificará con las siguientes ponderaciones 142 | 143 | **Ncalc = 0.6 * NIE + 0.3 * NP + 0.1 * NC** 144 | 145 | Para aprobar el curso se requiere que 146 | 147 | **NE >= 4.00** 148 | **NIE >= 4.00** 149 | **NP >= 4.00** 150 | **NC >= 4.00** 151 | 152 | La nota final, si se cumplen los criterios anteriores se calcula como 153 | 154 | **NF = Ncalc** 155 | 156 | Y aprueba si y solo si 157 | 158 | **NF >= 4.00** 159 | 160 | En otro caso 161 | 162 | **NF = max(3.9, Ncalc)** 163 | 164 | # Foro 165 | 166 | La página de [_issues_](https://github.com/IIC2173-2019-2/syllabus/issues) se utilizará como foro para preguntas. 167 | 168 | # Bibliografia 169 | 170 | - Richard N. Taylor, “Software Architecture, Foundations, Theory and Practice”, Wiley, 2010. 171 | - Spinellis & Gousios, “Beautiful Architecture”, O’Reilly, 2009. 172 | - Ian Gorton, “Essential Software Architecture”, Springer, June, 2006. 173 | - Martin Fowler et al., “Patterns of Enterprise Application Architecture”, Addison Wesley, 2002 174 | 175 | # Política de integridad académica 176 | 177 | Los alumnos de la Escuela de Ingeniería de la Pontificia Universidad Católica de Chile deben mantener un comportamiento acorde a la Declaración de Principios de la Universidad. En particular, se espera que **mantengan altos estándares de honestidad académica**. Cualquier acto deshonesto o fraude académico está prohibido; los alumnos que incurran en este tipo de acciones se exponen a un Procedimiento Sumario. Es responsabilidad de cada alumno conocer y respetar el documento sobre Integridad Académica publicado por la Dirección de Docencia de la Escuela de Ingeniería (disponible en SIDING). 178 | 179 | Específicamente, para los cursos del Departamento de Ciencia de la Computación, rige obligatoriamente la siguiente política de integridad académica. Todo trabajo presentado por un alumno para los efectos de la evaluación de un curso debe ser hecho individualmente por el alumno, sin apoyo en material de terceros. Por _trabajo_ se entiende en general las interrogaciones escritas, las tareas de programación u otras, los trabajos de laboratorio, los proyectos, el examen, entre otros. 180 | 181 | **En particular, si un alumno copia un trabajo, o si a un alumno se le prueba que compró o intentó comprar un trabajo, obtendrá nota final 1.1 en el curso y se solicitará a la Dirección de Docencia de la Escuela de Ingeniería que no le permita retirar el curso de la carga académica semestral.** 182 | 183 | Por _copia_ se entiende incluir en el trabajo presentado como propio, partes hechas por otra persona. **En caso que corresponda a _copia_ a otros alumnos, la sanción anterior se aplicará a todos los involucrados**. En todos los casos, se informará a la Dirección de Docencia de la Escuela de Ingeniería para que tome sanciones adicionales si lo estima conveniente. 184 | 185 | Obviamente, está permitido usar material disponible públicamente, por ejemplo, libros o contenidos tomados de Internet, siempre y cuando se incluya la referencia correspondiente. 186 | 187 | Lo anterior se entiende como complemento al [Reglamento del Alumno de la Pontificia Universidad Católica de Chile]. Por ello, es posible pedir a la Universidad la aplicación de sanciones adicionales especificadas en dicho reglamento. 188 | 189 | [Reglamento del Alumno de la Pontificia Universidad Católica de Chile]: http://admisionyregistros.uc.cl/alumnos/informacion-academica/reglamentos-estudiantiles 190 | -------------------------------------------------------------------------------- /Proyecto/Entrega final/Entrega_final.md: -------------------------------------------------------------------------------- 1 | # Entrega final - N de M 2 | 3 | Dada la contingencia nacional, hemos dicidido reajustar la última entrega del curso, con el fin de que esté acotada a los objetivos de este y para que puedan experimentar algunas tecnologías que quizás no conozcan. 4 | 5 | Para esta entrega pueden (y recomendamos) utilizar el código de su E0. Deberán asociarse en **grupos de 3 o 4 o 5**, y pueden utilizar la E0 que estimen conveniente. 6 | 7 | La idea de la entrega es que puedan completar al menos 4 de los 8 desafíos que proponemos. Cada uno vale 15 décimas por lo que completar 4 es equivalente a la nota 7.0 (la nota parte desde 1.0). Si intentan un 5to desafío, lo harán por diversion, porque no lo vamos a poder revisar. 8 | 9 | ## Desafíos 10 | 11 | #### 1) *Make my life serverless*: Agregar 3 servicios consumidos vía servicios AWS lambda (o cloud functions en gcloud) 12 | 13 | * RNF evaluado: 14 | * Niveles de logro. 15 | * 3x **(0.5)** Por cada servicio conectado con lambda 16 | 17 | **Tutoriales** 18 | 19 | * ¿Qué son las funciones Lambda? [https://www.youtube.com/watch?v=eOBq__h4OJ4](https://www.youtube.com/watch?v=eOBq__h4OJ4) 20 | * [https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) 21 | * [https://stackify.com/aws-lambda-with-python-a-complete-getting-started-guide/](https://stackify.com/aws-lambda-with-python-a-complete-getting-started-guide/) 22 | * https://medium.com/@gulikholmatova/building-a-serverless-react-app-using-aws-lambda-dynamodb-and-an-api-gateway-f846696f34cd 23 | 24 | 25 | 26 | --- 27 | 28 | 29 | #### 2) *Screw db hacks*: Encriptar algún tipo de chat end-to-end con Vault (secreto compartido entre peers y no con el server) 30 | 31 | * RNF evaluado: Seguridad 32 | * Niveles de logro 33 | * (1.5) Demostrar el funcionamiento final 34 | 35 | 36 | **Tutoriales** 37 | 38 | ¿Qué es Vault? [https://www.youtube.com/watch?v=VYfl-DpZ5wM](https://www.youtube.com/watch?v=VYfl-DpZ5wM) 39 | 40 | 41 | * [https://www.vaultproject.io/intro/getting-started/index.html](https://www.vaultproject.io/intro/getting-started/index.html) 42 | 43 | * [https://www.linode.com/docs/applications/configuration-management/use-hashicorp-vault-for-secret-management/](https://www.linode.com/docs/applications/configuration-management/use-hashicorp-vault-for-secret-management/) 44 | 45 | 46 | 47 | --- 48 | 49 | #### 3) *Local NSA*: Monitoreo de lo que tengan (de servers y ojalá de red) 50 | 51 | * Niveles de logro 52 | * **(0.5)** Conectar los logs de aplicacion y deploy con servicios de la nube (Cloudwatch o el nativo de la cloud que se use) 53 | * **(1.0)** Conectar herramientas ad-hoc como Prometheus, NewRelic o algún APM 54 | 55 | **Tutoriales** 56 | 57 | * [https://www.edureka.co/blog/amazon-cloudwatch-monitoring-tool/](https://www.edureka.co/blog/amazon-cloudwatch-monitoring-tool/) 58 | * [https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-tutorials.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-tutorials.html) 59 | * [https://prometheus.io/docs/prometheus/latest/getting_started/](https://prometheus.io/docs/prometheus/latest/getting_started/) 60 | 61 | 62 | 63 | 64 | --- 65 | 66 | #### 4) *Containers for breakfast*: Montar los n servicios de chat en K8s o docker-compose, para modo dev y para deploy. 67 | * RNF evaluado: 68 | * Niveles de logro 69 | 1. **(0.3)** Containerizar cada servicio que lleven del grupo 70 | 2. **(0.4)** Tener una versión funcional del código en docker-compose para desarrollo. 71 | 3. **(0.8)** Subir este código como containers a ECS, EKS o algun servicio en la nube que esten usando 72 | 73 | **Tutoriales** 74 | 75 | ¿Qué es Docker? [https://www.youtube.com/watch?v=Q5POuMHxW-0&feature=emb_title](https://www.youtube.com/watch?v=Q5POuMHxW-0&feature=emb_title) 76 | 77 | * [https://medium.com/@khandelwal12nidhi/docker-setup-on-aws-ec2-instance-c670ff3d5f1b](https://medium.com/@khandelwal12nidhi/docker-setup-on-aws-ec2-instance-c670ff3d5f1b) 78 | * [https://aws.amazon.com/es/getting-started/tutorials/deploy-docker-containers/](https://aws.amazon.com/es/getting-started/tutorials/deploy-docker-containers/) 79 | * [https://aws.amazon.com/getting-started/projects/deploy-kubernetes-app-amazon-eks/](https://aws.amazon.com/getting-started/projects/deploy-kubernetes-app-amazon-eks/) 80 | 81 | 82 | --- 83 | 84 | 85 | #### 5) *Beyond Travis*: AWS codepipeline (build, deploy) para la app de la entrega 0 (*No usar travis, ni Circle CI, solo codepipeline*) 86 | * *Pueden usar Google Deployment Manager, pero no tiene diagramas al parecer)* 87 | * RNF evaluado: 88 | * Niveles de logro: 89 | 1. **(0.5)** Construir buildspec.yml, y tener un build exitoso. 90 | 2. **(0.8)** Construir un appspec.yml y lograr un deploy exitoso a una instancia EC2 (o ECS o lo que usen) desde su repositorio en Github contra un push de la rama master (no usar github activites) 91 | 3. **(0.2)** Exponer los logs del deploy a cloudwatch u otra app 92 | 93 | **Tutoriales** 94 | 95 | * Video con animaciones simpáticas [https://www.youtube.com/watch?v=YxcIj_SLflw](https://www.youtube.com/watch?v=YxcIj_SLflw) 96 | * [https://aws.amazon.com/es/getting-started/tutorials/continuous-deployment-pipeline/](https://aws.amazon.com/es/getting-started/tutorials/continuous-deployment-pipeline/) 97 | * [https://www.sumologic.com/insight/aws-codepipeline/](https://www.sumologic.com/insight/aws-codepipeline/) 98 | 99 | 100 | --- 101 | 102 | #### 6) Implementar un load balancer con su app e integrar un CDN en la solución (En el caso de AWS, Cloudfront + Elastic Load Balancer) 103 | 104 | * RNF evaluado: Escalabilidad y performance. 105 | * Niveles de logro 106 | 1. **(0.5)** Montar la solución en un ASG (auto-scaling group) 107 | 2. **(0.2)** Apuntar desde el load-balancer al ASG y que venga con la URL, que quede un registro del server que manejó el request 108 | 3. **(0.3)** Log compartido a nivel del ASG 109 | 4. **(0.5)** Requests de assets estáticos cacheados en el CDN. 110 | 111 | **REVISAR APP A IMPLEMENTAR** 112 | 113 | **Tutoriales** 114 | * ¿Qué es Elastic Load Balancing?[https://www.youtube.com/watch?v=VIgAT7vjol8](https://www.youtube.com/watch?v=VIgAT7vjol8) 115 | * [https://learnetto.com/blog/cloudfront-s3](https://learnetto.com/blog/cloudfront-s3) 116 | * [https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-getting-started.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-getting-started.html) 117 | * [https://intellipaat.com/blog/what-is-aws-elb-load-balancer/](https://intellipaat.com/blog/what-is-aws-elb-load-balancer/) 118 | 119 | 120 | 121 | 122 | --- 123 | 124 | #### 7) *Arquipowerpoint*: Terraform u CloudFormation 125 | * RNF evaluado: Consistencia y Confiabilidad. 126 | * Niveles de logro 127 | * **(1.0)** Generar el "script" (yml) para subir la infra de un servicio básico (Balanceador, ASG, db) 128 | * **(0.5)** Documentación asociada a los posibles errores para poder ejecutarlo sin problemas. 129 | 130 | **Tutoriales** 131 | * ¿Qué es AWS CloudFormation? [https://www.youtube.com/watch?v=Omppm_YUG2g](https://www.youtube.com/watch?v=Omppm_YUG2g) 132 | * [https://aws.amazon.com/cloudformation/getting-started/](https://aws.amazon.com/cloudformation/getting-started/) 133 | 134 | * [https://blog.gruntwork.io/an-introduction-to-terraform-f17df9c6d180](https://blog.gruntwork.io/an-introduction-to-terraform-f17df9c6d180) 135 | * [https://learn.hashicorp.com/terraform/getting-started/install.html](https://learn.hashicorp.com/terraform/getting-started/install.html) 136 | 137 | 138 | 139 | --- 140 | 141 | #### 8) *Mastermind*: Conectar el chat con alguno de otro grupo. 142 | 143 | * RNF evaluado: Consistencia y Confiabilidad. 144 | * Niveles de logro 145 | * **(0.6)** Crear una mini API (online) que pueda adaptar 3 o más chats y canalizar los mensajes de la sala principal de cada chat 146 | * **(0.3)** Tener una API REST documentada para esto 147 | * **(0.6)** Que los mensajes recibidos se vean en ambas aplicaciones 148 | 149 | **OJO:** Deben hacer este desafío en la plataforma de la nube que escogieron, sin usar firebase o algun equivalente. 150 | * *No es necesario que funcione en tiempo real, puede ser con un refresh* 151 | 152 | --- 153 | 154 | #### X) Propuesta 155 | 156 | * Pueden proponer alguna feature y niveles de logro para esta. 157 | * Deben dividir los niveles de logro en 3, para poder evaluarlos 158 | * Se recomienda consultar antes, ya que puede no ser aprobada y tendrán que elegir la otra que hayan escogido en el form de inscripción. 159 | 160 | 161 | ## Entrega 162 | 163 | 13 de diciembre - 23:59 para el código. 164 | Debe estar detallado en el README.md los detalles de su implementacion y como revisarla (links a las partes abiertas de las apps) 165 | 166 | ## Evaluación 167 | 168 | Reunión online con mayoría simple del grupo, la semana siguiente a la de la entrega. Será por google meet y deberá durar entre 15-20 min, con una demo sencilla de lo que hicieron (podran compartir su pantalla y mostrar lo necesario). 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | -------------------------------------------------------------------------------- /Proyecto/Enunciado general.md: -------------------------------------------------------------------------------- 1 | # IIC2173 - Proyecto semestral 2 | 3 | ## Objetivos 4 | 5 | - Tomar los requisitos para un sistema y desarrollar arquitecturas de software y diseños de alto nivel. 6 | - Diseñar software distribuido 7 | - Diseñar software usando componentes COTS (commercial off-the-shelf) 8 | - Aplicar frameworks y arquitecturas al diseñar una amplia variedad de software 9 | - Trabajar en sub equipos intercoordinados 10 | - Diseñar e implementar software usando tecnologías middleware 11 | 12 | ## Introducción 13 | 14 | Los juegos multijugador son una gran forma de testear las habilidades de un arquitecto de sistemas de software. Esto se debe a la complejidad de implementación y a las recurrentes fallas de servicio que puede generar una mala implementación de patrones, conectores, entre otras cosas. 15 | 16 | ## The Game 17 | 18 | En este asombroso proyecto, les pediremos que entreguen, por **grupo**, un juego relativamente simple, de reglas limitadas, que tendrá que responder a atributos de calidad para poder ser considerados como *arquitectónicamente eficientes*. 19 | 20 | Algunos ejemplos de juegos (que no podrán copiar pero si derivar) son: 21 | 22 | - [Smash TV](https://youtu.be/PRHSi4hBHSM?t=269) 23 | - [RallyX](https://www.youtube.com/watch?v=TdLATjA5cn8) 24 | - Doom (1993) 25 | - Galaga 26 | - [Achikaps](https://www.youtube.com/watch?v=P6F0qh1BiUI) 27 | - Mario bros 28 | - [Hoplite](https://www.youtube.com/watch?v=aB_oG-_pYog) 29 | - [Mindustry](https://mindustrygame.github.io/) (No pueden usar nada del codigo fuente de este, ni referenciarlo) 30 | - BBtan 31 | - Algun juego tower defense 32 | - etc ... 33 | 34 | Algunos ejemplos de juegos buenísimos pero insuficientes: 35 | 36 | - Real time chess 37 | - Asteroids 38 | - Pong 39 | - Space invaders 40 | - Damas 41 | - Ajedrez (asumiendo que no programan el motor) 42 | - etc ... 43 | 44 | Algunos de estos podrían cambiar si utilizan multijugador. 45 | Juegos sobredimensionados para este proyecto debido a sus complejas interfaces y reglas (no los vamos a restringir) serían: 46 | 47 | - Limbo 48 | - Spore 49 | - Starcraft 50 | - World of goo 51 | - World of Warcraft 52 | - Doom (2016) 53 | - etc ... 54 | 55 | Para el desarrollo de este juego podrán escoger los servidores, *frameworks* y lenguajes de programación que ustedes prefieran. Siempre y cuando cumplan con los requisitos del proyecto. 56 | 57 | El juego debe ser desarrollado en alguno de los siguientes entornos 58 | 59 | - C# 60 | - Unity 61 | - UWP 62 | - WPF 63 | - Python 64 | - Pygame 65 | - PyQt 66 | - Tk 67 | - Panda3d 68 | - Javascript 69 | - Java 70 | - Kotlin 71 | - C++ 72 | - Unreal engine 73 | 74 | Puede ser en celular, escritorio o web. Cualquier otro software que deseen utilizar debe ser permitido en las *issues*. 75 | 76 | Aunque ofrecemos varias opciones, al haber pasado programación avanzada en algun momento, debieron usar *pyqt*, lo que es suficiente para comenzar. Eso si, a diferencia de la tarea, seremos mucho más exigentes, puesto que sera un grupo de 5-6 y todo un semestre. 77 | 78 | Lo importante es que la lógica de juego sea expresada en código y que pueda comunicarse de alguna forma con otro software, junto con que ustedes mismos lo hayan escrito. 79 | 80 | A la hora de evaluar sus resultados, el enfoque será en la lógica de juego implementado y que sea muy usable, no por la estética. 81 | 82 | 83 | ## The Steam 84 | 85 | Aunque el juego que hayan realizado sea espectacular, no sirve de nada si es que no puede ser jugado por el público. Es por esto que, dada la necesidad de compartir sus ideas y puntajes con el mundo, como **macrogrupo** deben realizar una sencilla plataforma de distribución digital (algo similar a *Steam big picture*). 86 | 87 | En ésta, se deberá poder acceder a los distintos juegos desarrollados por los grupos dentro de su macrogrupo y ser utilizados correctamente. *The Steam* debe estar en la nube y debe poder accederse desde cualquier parte. 88 | 89 | Si el juego es web, la plataforma *The Steam* debe proveerlo directamente. En otro caso, debe proporcionar un ejecutable exe o apk unico que pueda lanzar el juego. No se aceptaran .ipa debido a que es muy dificil probarlos. 90 | 91 | Además de la plataforma base, los juegos tienen que tener lo que llamamos "interacciones" en línea. Las interacciones son implementaciones de funcionalidades que permiten interactuar a los juegos entre si. Ejemplos de interacciones son *scoreboards* conectados, mensajeria in-game, etc. 92 | Todas estas interacciones deben ser en tiempo real y **la plataforma debe implementar 4**. 93 | 94 | Así, los juegos tendrán que comunicarse con *The steam* y proveerlo de información relevante para estas interacciones y que tengan efectos en los otros juegos, ya sea independientes o que tengan que ver con la lógica del otro juego. 95 | 96 | Para todo esto, se deberán asignar 2 miembros de cada grupo como representantes en el macrogrupo. Estos deberan ocuparse de la interfaz del grupo y de hacer fluir la conversacion entre los grupos del macrogrupo 97 | 98 | *The steam* puede hacerse en **cualquier framework web** que el macrogrupo escoja, pero debe contener un backend programado por ustedes. No se les exigira que usen alguna libreria o framework para el frontend, pero se recomienda. 99 | 100 | ## Requisitos 101 | 102 | #### Servidor 103 | 104 | Para hacer el *deploy* de su aplicación deberán montar sus propios servidores. Se debe utilizar **servicios IaaS**. Se puede tener más de un servidor por grupo/macrogrupo. 105 | 106 | Cada servidor deberá tener configurdo un servicio proxy inverso con NGINX o Apache, que soporte SSL vía *Let's encrypt*. 107 | 108 | #### Dominio 109 | 110 | Cada servidor utilizado en el desarrollo del software tendrá que tener un dominio TK, ML o GA asignado. Los dominios TK son gratuitos, y pueden conseguirlos fácilmente en Freenom. 111 | 112 | #### Bases de datos 113 | 114 | Su aplicación deberá utilizar una base de datos poderosa acorde a sus necesidades(no de juguete, ej. *sqlite*). Un ejemplo de esto: *PostgreSQL* $\ge$ 11.5. 115 | Pueden usar el free tier de Amazon RDS o Google Cloud SQL 116 | 117 | #### Requisitos no funcionales 118 | 119 | Se deberán elegir 3 requisitos no funcionales generales que priorizarán su software. De aquellas que escojan, se deberán realizar y completar metas y métricas objetivo. 120 | 121 | Entre los requisitos funcionales que pueden elegir se encuentra: 122 | - Performance 123 | - Seguridad 124 | - Confiabilidad 125 | - Disponibilidad 126 | - Escalabilidad 127 | - Usabilidad 128 | 129 | #### Git 130 | 131 | Para versionar el código de su aplicación utilizarán un repositorio de *git*. Se les exigirá *"buenas prácticas"* sobre los *commits*. 132 | 133 | Además, para coordinar el desarrollo sobre éste deben seguir la metodología de *branching* *Gitflow*. No es necesario seguirlas al pie de la letra, pero como mínimo deben hacer la diferencia entre *master*, *development* y las *branches* de funcionalidades. 134 | 135 | #### Docker 136 | 137 | Deben configurar sus *ambientes de desarrollo* con *Docker* ya que los correctores probarán sus aplicaciones y correrán sus tests a través de esta herramienta. 138 | 139 | #### CI 140 | 141 | Se les pedirá realizar Continous Integration y Continous Deployment. Les indicaremos en que consiste en la entrega apropiada. 142 | 143 | #### Tests 144 | 145 | Se les pedirá desarrollar tests para *The steam*. Les indicaremos en que consisten en la entrega apropiada. 146 | 147 | #### *README .md* 148 | 149 | Sus repositorios deben contener archivos *README .md* atingentes al desarrollo que contengan toda la información necesaria para corregir las entregas (como por ejemplo funcionalidades desarrolladas/por desarrollar, link a servidor, pasos necesarios para ejecutar la aplicación y sus tests). 150 | 151 | ## Grupos y macrogrupos 152 | 153 | Por **grupo** se entenderá como el conjunto de 5 a 6 personas (ej. G01, G09). 154 | 155 | Por **macrogrupo** se entenderá como el conjunto de 4 grupos. En este caso: 156 | 157 | - Macrogrupo 1: G01, G02, G03, G04 158 | - Macrogrupo 2: G05, G06, G07, G08 159 | - Macrogrupo 3: G09, G10, G11, G12 160 | - Macrogrupo 4: G13, G14, G15, G16 161 | 162 | ## Fases y entregas 163 | 164 | El proyecto grupal tiene 4 fases y estas son 165 | 166 | ID fase | Publicación | Entrega | Presentación | Coevaluación | Fase 167 | --------------| ------ | --- | --- | ---- | --------- 168 | E1 | 7 de septiembre | 23 de septiembre | 27 de septiembre | 24 de septiembre | Propuesta y diseño 169 | E2 | 24 de septiembre | 11 de octubre |11 de octubre | 12 de octubre | Prototipo 170 | E3 | 12 de octubre | 8 de noviembre | 8 de noviembre | 9 de noviembre | MVP 171 | E4 | 9 de noviembre | TBA | TBA | TBA | Producto finalizado 172 | 173 | Las presentaciones de las entregas E1, E2 y E3, se realizarán en horario de ayudantía, y **debe asistir al menos una persona por grupo**, haciendo así **4 personas al menos por macrogrupo**. La E4 aún no tiene fecha de entrega ni de presentación. 174 | 175 | Para cada entrega E2, E3 y E4 se espera obtener un producto funcional. 176 | 177 | Se corregirá el último *commit* en la rama *master* de cada repositorio utilizado para el desarrollo del software. 178 | 179 | Cada presentación tendrá una duración de entre 10 a 12 minutos. Además, habrán 5 minutos para preguntas. 180 | 181 | ## Restricciones y alcances 182 | 183 | * Solo se permite usar las herramientas mencionadas aqui para construir su código, a menos que se especifique que una parte es libre. Pueden preguntar si algun lenguaje/framework/paquete esta permitido, abriendo una issue o preguntando en la instancia de reunion con sus ayudantes por macrogrupo (sera anunciado) 184 | 185 | 186 | * Esta tarea debe tener codigo fresco desarrollado por el grupo y macrogrupo, y está regida por el [Código de honor de Ingeniería](https://www.ing.puc.cl/wp-content/uploads/2015/08/cdigo-de-honor.pdf). Cualquier uso de snippets o librerias debe ser referenciado debidamente. 187 | 188 | * Tendrán hasta 24 horas después del plazo de entrega de la fase para subir el README al repositorio. 189 | Entregas con atraso de más de 24 horas tendrán calificación grupal mínima (1.0). 190 | 191 | ## Evaluación 192 | 193 | ### Grupal 194 | 195 | **E1 grupal = E1 grupo individual * 0.7 + E1 macro * 0.3** 196 | 197 | ### Extras 198 | 199 | Existen extras para cada entrega que mejoran la nota, pero solo si funcionan. De no funcionar, éstos no aplicarían: 200 | 201 | * Multiplayer por juego (en tiempo real): 5% 202 | 203 | 204 | Actuan como ponderadores sobre la nota total del grupo. Ej.: Si la aplicacion tiene multiplayer y tuvieron un 5.3 205 | 206 | $5.3 * 1.05 = 5.7$ 207 | 208 | ### Individual 209 | 210 | **E0 = 1 + ((E0 grupal - 1) * Fg)** 211 | 212 | Donde Fg es un factor de coevaluación asignado por el grupo que va de 0 a 1.2. Para esto se enviará un form de coevaluación donde cada integrante deberá evaluar a sus compañeros de grupo con una puntuación entre 0 y 5. 213 | 214 | **No podrán asignar a más de un compañero 5 puntos y sí lo hacen, se considerará que se entregó un máximo de 4 puntos a cada compañero**. 215 | 216 | De no hacer la coevaluación asumiermos que le entregó el mismo puntaje de coevaluación a cada integrante, es decir 4 puntos. 217 | 218 | NP = 0.15 * E0 + 0.85 * PROMEDIO(E1,E2,E3,E4) 219 | --------------------------------------------------------------------------------