Módulo 2 Clase 1 Intro sistemas y arquitecturas

Módulo 2: Introducción a la Arquitectura

Análisis de Exámenes Anteriores

• Se inicia el módulo dos de arquitectura, mencionando que se compartirá un análisis de los exámenes de años anteriores para orientar las clases.

• La enseñanza se basa en un enfoque teórico y práctico, buscando preparar a los estudiantes para aprobar el examen.

Enfoque en Modelos de Examen

• Se destaca la importancia de entender cómo se han formulado las preguntas en exámenes previos, ya que la tecnología es vasta y siempre hay más por aprender.

• Este año no se pidieron casos de uso ni diagramas de contexto; se enfocaron directamente en el modelo lógico.

Detalles del Modelo Lógico

• Los estudiantes deben identificar módulos lógicos y sus responsabilidades, así como las funcionalidades e interfaces entre ellos.

• Se menciona la necesidad de proponer una arquitectura física, algo que también fue requerido en el examen A2.

Abstracción en Informática

• El módulo abordará la arquitectura lógica independientemente de la tecnología utilizada (Java, .NET, etc.).

• Se enfatiza el concepto de abstracción; los estudiantes deben ser capaces de separar módulos conceptuales sin profundizar demasiado en la tecnología subyacente.

Preparación para Preguntas Específicas

• La preparación incluye familiarizarse con preguntas sobre arquitectura física y lógica, así como modelos de datos.

• Se hace hincapié en que aunque algunos temas pueden parecer irrelevantes al principio, son esenciales para responder correctamente durante el examen.

Arquitectura Física y Lógica

Estructura del Examen A1

• En el examen A1 se preguntó sobre la descripción funcional y arquitectónica; esto ha sido útil para preparar a los estudiantes.

Preguntas Comunes del Examen A2

• En el examen A2 suelen preguntar sobre casos de uso y diagramas contextuales.

• La pregunta sobre realizar un diagrama físico del nuevo servicio Confire es considerada compleja pero relevante.

Integración y Autenticación

• Los estudiantes deben describir cómo integrar Fire con aplicaciones cliente y discutir mecanismos posibles de autenticación.

Importancia del Conocimiento Técnico

• Aunque no se profundice mucho en sistemas específicos, es crucial tener conocimientos básicos sobre arquitecturas físicas.

Arquitectura y Desarrollo de Aplicaciones Móviles

Conceptos Básicos de Arquitectura

• La arquitectura física de las Velans es consistente, lo que facilita su comprensión. Se menciona que no es complicado entenderla si se sigue un diagrama de arquitectura lógica de componentes.

• Se discute la importancia del modelo de datos y la trazabilidad en el contexto tecnológico, mencionando la futura incorporación de un sistema de firma basado en una aplicación móvil.

Análisis DAFO y Opciones Tecnológicas

• Es esencial aprender a realizar un análisis DAFO, especialmente para los estudiantes del A2, ya que se ha incluido en los exámenes recientes.

• En TICA 1, se enfatiza la necesidad de conocer varias opciones tecnológicas y sus ventajas e inconvenientes para abordar supuestos prácticos.

Desarrollo de Aplicaciones Móviles

• Se deben considerar diferentes enfoques para el desarrollo móvil: nativo, híbrido o SPA (Single Page Application). Cada opción tiene sus propias ventajas y desventajas.

• La aplicación híbrida permite acceso a propiedades del dispositivo y simplifica la distribución entre plataformas como Android e iOS.

Preguntas Clave sobre Arquitectura

• Se plantea si la aplicación debe solicitar permisos específicos; esto es crucial para el diseño arquitectónico.

• En exámenes anteriores se han solicitado diagramas específicos como casos de uso y diagramas de clases junto con soluciones tecnológicas elegidas.

Propuestas Tecnológicas y Diseño

• Los estudiantes deben proponer diagramas que representen subsistemas necesarios bajo normativas como RGPD, así como justificar las elecciones tecnológicas para movilidad.

• El módulo abarca tres partes clave: arquitectura lógica del sistema, diagramas de paquetes y componentes. Se sugiere combinar ambos tipos para una representación más efectiva.

Reflexiones sobre Aprendizaje

• El enfoque práctico incluye dibujar diagramas simples antes de avanzar a representaciones más complejas.

• La clase busca fomentar un pensamiento crítico entre los estudiantes sobre las soluciones informáticas presentadas en los supuestos prácticos.

Conclusión General

• El instructor anima a los alumnos a participar activamente durante las clases, compartiendo sus conocimientos previos y experiencias en programación.

Introducción a la Arquitectura de Aplicaciones

Historia y Conceptos Básicos

• Se plantea el inicio de la discusión sobre la historia de la informática, arquitecturas y aplicaciones, enfatizando la necesidad de un entendimiento amplio antes de abordar arquitecturas específicas.

• Se menciona que los actores del sistema son fundamentales; estos incluyen usuarios humanos que interactúan con el sistema.

Interfaz Gráfica y Lógica de Negocio

• La interfaz gráfica es crucial para la interacción del usuario, permitiendo el acceso a través de diferentes plataformas como intranets o aplicaciones móviles.

• La lógica de negocio se describe como el núcleo del procesamiento en una aplicación, variando en complejidad según las necesidades del negocio.

Acceso a Datos y Persistencia

• Se discute la capa de acceso a datos, que incluye almacenamiento en bases de datos y archivos, destacando su importancia en la arquitectura general.

• La interoperabilidad es clave; se mencionan servicios web como métodos para acceder e interactuar con otros sistemas.

Seguridad y Monitorización

• La seguridad se considera una capa transversal esencial para proteger aplicaciones y garantizar integridad y confidencialidad.

• La monitorización es vital para recopilar información sobre rendimiento y estado en tiempo real, lo cual es especialmente relevante en arquitecturas modernas como microservicios.

Persistencia Común en Bases de Datos

• Se hace hincapié en las opciones comunes para persistencia, sugiriendo que aunque hay tecnologías disruptivas (como blockchain), lo habitual sigue siendo bases de datos relacionales.

• El proceso desde modelo entidad-relación hasta modelo físico se explica brevemente, resaltando su implementación práctica en sistemas como Oracle o MySQL.

¿Qué son las bases de datos y su importancia?

Bases de datos relacionales vs. no relacionales

• Las bases de datos relacionales, como Oracle o MySQL, permiten almacenar tablas que pueden no estar relacionadas entre sí, pero tienen un costo en términos de recursos computacionales.

• Se mencionan las bases de datos no SQL para manejar grandes volúmenes de datos no estructurados, como logs o redes sociales, destacando su flexibilidad en el manejo de diferentes formatos (XML, JSON).

• Ejemplos como Voldemort y HDFS se citan como sistemas diseñados para gestionar grandes cantidades de datos no estructurados utilizando modelos flexibles.

• En ciencia de datos, se utilizan estas bases debido a la naturaleza masiva y a menudo desestructurada de los datos que manejan.

Data Warehouses: Almacenamiento y análisis

• Los data warehouses son esenciales para la visualización y análisis de datos agregados sin sobrecargar las bases de datos relacionales.

• Se utiliza un proceso ETL (Extracción, Transformación y Carga) para integrar los datos desde diversas fuentes hacia el data warehouse.

• Un data warehouse centraliza la gestión y almacenamiento de grandes volúmenes de información con el objetivo principal de proporcionar una vista analítica consolidada.

• La analítica descriptiva es fundamental en estos sistemas para facilitar la toma decisiones empresariales mediante informes estadísticos.

Capas del sistema: Persistencia y almacenamiento

• Los data warehouses están optimizados para consultas complejas e históricos; además se menciona la importancia del sistema archivos en el almacenamiento económico frente a las bases relacionales.

• Se discute el uso del sistema archivos junto con gestores documentales para almacenar documentos completos (PDF), resaltando su eficiencia económica comparado con las bases relacionales.

LDAP: Autenticación y directorios

• El uso del LDAP se menciona como una estructura que almacena información sobre objetos en red (usuarios, grupos), siendo útil cuando se requiere autenticación organizacional.

Reflexiones sobre arquitecturas monolíticas

• Se introduce una reflexión sobre arquitecturas monolíticas donde todos los componentes son parte integral del mismo ejecutable, lo cual puede limitar la escalabilidad y flexibilidad del software.

Aplicaciones de Escritorio: Ventajas y Desventajas

Desarrollo de Aplicaciones Pesadas

• Las aplicaciones pesadas de escritorio se desarrollan como una única entidad, integrando todas las funciones y procesos en un solo paquete.

• A pesar de sus limitaciones, las aplicaciones de escritorio son utilizadas debido a sus ventajas inherentes, como la escalabilidad vertical que permite aumentar la potencia del nodo.

Limitaciones Técnicas

• La dependencia del hardware es crítica; si la máquina tiene poca RAM, el rendimiento se ve afectado, especialmente con algoritmos de machine learning.

• La comunicación entre componentes es rápida en aplicaciones pesadas porque están compilados juntos, pero esto también presenta serias desventajas en términos de mantenimiento.

Evolución y Mantenimiento

• Históricamente, las aplicaciones estaban atadas a servidores locales y bases de datos centralizadas, lo que complicaba su actualización y mantenimiento.

• Las actualizaciones del sistema operativo pueden causar problemas significativos en el funcionamiento de estas aplicaciones debido a dependencias complejas.

Dependencia en Entornos Administrativos

• Muchas aplicaciones monolíticas dependen del entorno administrativo para funcionar correctamente; esto incluye software antiguo que sigue siendo utilizado por falta de alternativas.

• La dependencia tecnológica puede crear problemas cuando los sistemas informáticos centrales fallan o no están disponibles.

Cambios hacia Arquitecturas Distribuidas

• Con mejoras en la conectividad y confianza en las comunicaciones modernas (como VPN), hay un cambio hacia arquitecturas distribuidas que permiten dejar atrás las aplicaciones pesadas.

• Actualmente, se considera poco práctico desarrollar nuevas aplicaciones con interfaces gráficas pesadas para Windows debido a estas tendencias.

Aplicaciones Legacy y su Migración

Desafíos de las Aplicaciones Legacy

• Las aplicaciones Legacy son software antiguo que sigue funcionando, pero su migración puede ser problemática debido a su estructura no relacional y a la falta de criterios técnicos en su desarrollo inicial.

• La automatización de procesos robóticos (RPA) se utiliza para interactuar con estas aplicaciones, facilitando la migración de datos y el mantenimiento del acceso a expedientes antiguos.

• A menudo, se mantiene una versión antigua del software en un servidor o computadora para acceder a documentos necesarios, lo que complica aún más la gestión de datos.

Problemas Prácticos en Administración

• En situaciones prácticas dentro de la administración pública, es común encontrar problemas como software sin licencias o configuraciones inadecuadas que pueden complicar el trabajo diario.

• Se discute la necesidad de evitar aplicaciones pesadas y optar por arquitecturas distribuidas que permitan una mejor separación de responsabilidades entre los componentes del sistema.

Arquitectura Distribuida

Características Fundamentales

• La arquitectura distribuida implica separar los componentes del sistema en diferentes servidores o mantenerlos todos juntos, pero con claras responsabilidades asignadas.

• Los sistemas distribuidos requieren una comunicación fiable; si esta falla, el funcionamiento general se ve comprometido. Por ello, es esencial contar con redundancia en las conexiones.

Escalabilidad y Tolerancia a Fallos

• La escalabilidad horizontal permite añadir más nodos al sistema mientras que la vertical aumenta la capacidad de cada nodo existente. Esto es crucial para mejorar el rendimiento general.

• La tolerancia a fallos permite que un sistema siga funcionando incluso si uno o varios nodos fallan. Esto asegura que otros procesos continúen operativos sin interrupciones significativas.

Cohesión y Acoplamiento en Arquitecturas

Importancia del Diseño Estructural

• Al diseñar arquitecturas de tres capas, se busca aumentar la cohesión (trabajo conjunto hacia objetivos comunes) y minimizar el acoplamiento (dependencia entre componentes).

• Es fundamental establecer límites claros en el diseño para asegurar que todos los elementos trabajen hacia un fin común sin diluirse en funciones ajenas al propósito original.

¿Qué es la cohesión y el acoplamiento en sistemas de software?

Definición de Cohesión y Acoplamiento

• La cohesión se refiere a cómo los componentes de un sistema están dirigidos hacia un objetivo común, lo que implica que están bien organizados y separados en capas o microservicios.

• El acoplamiento describe el grado de interdependencia entre los componentes; en aplicaciones con alto acoplamiento, los cambios en un componente pueden afectar a otros.

Ejemplo de Desacoplamiento

• Un sistema desacoplado permite cambiar la interfaz gráfica sin afectar la lógica del negocio ni el acceso a datos. Por ejemplo, se puede migrar una interfaz Angular a una aplicación Android sin reescribir toda la lógica subyacente.

• Este enfoque facilita la adaptación y evolución del software al permitir reemplazar partes individuales sin necesidad de modificar todo el sistema.

Arquitectura Cliente-Servidor

Fundamentos del Modelo Cliente-Servidor

• Las arquitecturas distribuidas se basan en el modelo cliente-servidor, donde los clientes solicitan servicios a los servidores, que son responsables de proporcionar esos servicios.

• En este contexto, un servidor puede ser cualquier tipo de servicio como DNS, FTP o HTTP; cada uno tiene su propio cliente correspondiente (por ejemplo, navegadores web).

Protocolo HTTP

• HTTP es un protocolo ligero y sin conexión que no mantiene estado entre las solicitudes; esto significa que cada interacción requiere información adicional para identificar al usuario (como cookies).

• A diferencia de las conexiones telefónicas que reservan recursos durante una llamada, HTTP no establece una conexión persistente entre cliente y servidor. Esto permite mayor flexibilidad pero también requiere más gestión por parte del cliente para mantener el estado.

Interacción entre Clientes y Servidores

Comunicación Eficiente

• La comunicación entre clientes y servidores se basa en un modelo de petición-respuesta; cada solicitud del cliente genera una respuesta del servidor. Esto es fundamental para entender cómo funcionan las aplicaciones web modernas.

• Ejemplos prácticos incluyen servicios como WhatsApp donde la aplicación móvil actúa como cliente interactuando con servidores para enviar mensajes a otros usuarios mediante protocolos específicos.

Desacople en Capas

• Al desacoplar las capas dentro de una arquitectura, la comunicación entre diferentes niveles (como presentación y negocio) puede realizarse mediante HTTPS, lo cual mejora la seguridad y modularidad del sistema.

Introducción a Microservicios y Arquitectura en Tres Capas

Conceptos Básicos de Microservicios

• Se menciona la invocación de servicios mediante GRPC o servicios web por HTTP, destacando la importancia de entender el paradigma cliente-servidor.

• Gisela comparte su experiencia laboral en GIS, enfocándose en la infraestructura que soporta procesos como la revalorización de pensiones.

Aplicaciones Prácticas

• La infraestructura genera ficheros que son enviados a un servidor para ser impresos y enviados a los hogares, ilustrando cómo se manejan los datos en el contexto real.

• Se enfatiza la relevancia de conectar conceptos teóricos con aplicaciones prácticas para facilitar el entendimiento.

Arquitectura en Tres Capas

• Se introduce el concepto de arquitectura en tres capas: presentación, negocio y datos. El presentador destaca su experiencia positiva con este modelo.

• Se anticipa una clase dedicada a microservicios, sugiriendo que es un tema complejo pero esencial para destacar profesionalmente.

Importancia del Control en Microservicios

• En 2024, se espera que haya un control significativo sobre arquitecturas basadas en microservicios debido a su creciente adopción por organismos públicos.

• Se presenta un diagrama UML que ilustra las tres capas mencionadas anteriormente, resaltando su utilidad durante exámenes previos.

Desacoplamiento y Ventajas de Microservicios

• La arquitectura de microservicios permite un mayor desacoplamiento entre componentes, lo cual es fundamental para mejorar la independencia operativa.

• Aunque cada microservicio puede tener su propia base de datos, también existe la posibilidad de utilizar bases monolíticas; se promete una clase futura dedicada al tema.

Definición y características de los microservicios

Definición inicial de microservicios

• Se cuestiona la definición presentada de microservicio, señalando que le falta información clave. La comunicación entre servicios es importante, pero se sugiere que debe ser a través de "servicios de grano fino".

Comunicación y escalabilidad

• Se menciona que los microservicios pueden comunicarse mediante GRPC o API REST, lo cual permite un desacoplamiento total. Una característica esencial es la capacidad de escalar cada microservicio independientemente.

Orquestación y complejidad

• La orquestación en arquitecturas de microservicios es difícil de definir en una sola frase. Se reconoce que la definición previa era insuficiente.

Servicios en la nube y su importancia

Crecimiento del uso de servicios en la nube

• Se destaca el aumento en la contratación de servicios en la nube por parte de organismos, sugiriendo que esto debe ser considerado al diseñar soluciones prácticas.

Tipos de servicios en la nube

• El Software as a Service (SaaS) se presenta como el modelo más común, ejemplificado con Google Drive. Este modelo implica que las aplicaciones son alojadas por un proveedor y accesibles a través de internet.

Sistema dinámico para adquisición y licencias

Proceso de contratación centralizada

• Se introduce el sistema dinámico para adquisiciones centralizadas, destacando su relevancia para contratar licencias tanto para software instalado como para aplicaciones basadas en la nube.

Ejemplos prácticos

• Se menciona un caso específico donde se está utilizando SaaS para herramientas como Jira y Confluence, enfatizando su utilidad para gestión documental y KPIs sin necesidad de instalación local.

Cumplimiento normativo y ventajas del SaaS

Normativas aplicables

• Se discuten las cláusulas relacionadas con el cumplimiento del RGPD y otras normativas relevantes al utilizar software como servicio, incluyendo aspectos sobre copias de seguridad.

Beneficios del modelo SaaS

• El modelo SaaS permite a los gestores evitar preocupaciones sobre infraestructura física. A pesar del costo potencialmente mayor, ofrece actualizaciones automáticas y soporte continuo garantizado por acuerdos robustos.

Power BI y el Cuadrante Mágico de Gartner

Introducción a Power BI

• Se menciona que Power BI es un cuadro de mandos de Microsoft, reconocido como uno de los mejores en el cuadrante mágico de Gartner.

• El cuadrante mágico clasifica diferentes aplicaciones de CRM (gestión de relaciones con clientes), destacando líderes del mercado y jugadores innovadores.

Importancia del Cuadrante Mágico

• En supuestos prácticos, se argumenta que al elegir herramientas como Power BI, se debe mencionar su posición en el cuadrante mágico para justificar la elección.

• Se sugiere incluir frases sobre la elección de herramientas tecnológicas basadas en su clasificación en Gartner durante las evaluaciones.

Herramientas y Modelos en la Nube

• Se discuten diferentes modelos como Software as a Service (SaaS), Platform as a Service (PaaS), e Infrastructure as a Service (IaaS).

• PaaS proporciona una plataforma completa para desarrollo en la nube, permitiendo a los desarrolladores centrarse en crear aplicaciones sin preocuparse por la infraestructura subyacente.

Infraestructura como Servicio

• IaaS ofrece recursos informáticos virtualizados a través de internet, incluyendo máquinas virtuales y almacenamiento.

• Los usuarios tienen control sobre sistemas operativos y aplicaciones, pero no sobre la infraestructura física subyacente.

Normativas y Servicios Compartidos

• Se menciona que existen normativas que obligan a organismos públicos a utilizar servicios declarados como compartidos.

• La ESGAT debe revisar cualquier contrato relacionado con tecnologías antes de su implementación para asegurar cumplimiento normativo.

Nubesara y la Infraestructura como Servicio

Introducción a Nubesara

• Nubesara proporciona servicios comunes, incluyendo soporte para Muface. Se planea que ofrezca servicios a otros organismos como infraestructura como servicio.

• La infraestructura se refiere a máquinas virtuales donde el usuario debe instalar y pagar por las licencias de software, como Red Hat y SQL Server.

Almacenamiento en la Nube

• Se menciona que es posible montar sistemas operativos en diversas plataformas de nube (AWS, Azure, Google Cloud Platform, etc.), destacando la importancia del almacenamiento.

• El almacenamiento debe ser separado del cómputo; se enfatiza que el almacenamiento no necesita cómputo sino espacio físico.

Ahorro de Costos y Eficiencia

• Utilizar servicios de almacenamiento simples (como S3) permite ahorrar costos y energía al evitar la necesidad de máquinas virtuales para almacenar objetos.

• Separar el almacenamiento del servicio principal ayuda a optimizar recursos y reducir gastos innecesarios.

Base de Datos como Servicio

Ventajas de las Bases de Datos en la Nube

• Se discute cómo elegir bases de datos como Oracle para simplificar procesos sin necesidad de configurar instancias complejas.

• La opción de utilizar bases de datos en la nube elimina la necesidad de administradores dedicados (DBAs), facilitando el desarrollo ágil.

Comprensión del Entorno Cloud

• La charla resalta cómo entender los conceptos cloud es crucial para quienes trabajan con microservicios y herramientas colaborativas como Confluence.

Proceso Analítico en Métrica

Análisis y Especificación

• En métrica, se realiza un análisis exhaustivo durante la fase inicial, recopilando requisitos desde una perspectiva cercana al usuario.

• Los analistas funcionales crean diagramas que representan casos de uso y clases, estableciendo un modelo claro para el sistema.

Diseño Arquitectónico

• El diseño arquitectónico implica definir módulos del sistema basándose en los requisitos analizados previamente.

• Las decisiones sobre tecnologías específicas (Angular, Java, microservicios) son fundamentales para crear una arquitectura coherente.

Mediadores y Arquitectura Lógica

Introducción a los Mediadores

• Se establece que los mediadores se van a esperar, lo que sugiere una fase de preparación para el desarrollo del sistema.

Consulta de Mediadores

• Un ciudadano puede realizar consultas sobre mediadores. Se propone utilizar un diagrama de contexto para extraer módulos y practicar la creación de arquitecturas lógicas.

Diagramas de Casos de Uso

• El presentador menciona que en su examen utilizó diagramas de casos de uso, aunque no eran requeridos, ya que le resulta fácil transitar entre estos y los módulos del sistema.

Proceso de Registro del Mediador

• Se describe el proceso donde un mediador proporciona datos para su registro, siendo aprobado por un empleado del ministerio. Ambos deben autenticarse, destacando la importancia del flujo correcto en el registro.

Comunicación con el BOE

• Una vez aprobado, se comunica al BOE sobre el nuevo mediador concursal. Este proceso es parte fundamental en la gestión administrativa y legal relacionada con los mediadores.

Estructura del Sistema

• Se comienza a dibujar las capas del sistema: presentación, lógica de negocio y datos. La coherencia entre los elementos es crucial para asegurar una correcta representación en todos los diagramas.

Importancia de la Coherencia

• La coherencia es esencial; si se menciona un usuario o rol en un diagrama debe aparecer también en otros contextos como el diagrama de casos de uso.

Interfaz Web para Usuarios

• Se discute la necesidad de crear interfaces web específicas para cada rol (mediador, funcionario, ciudadano), considerando cómo estas pueden centralizarse o dividirse según las funcionalidades requeridas.

Diseño Adaptativo según Roles

• Dependiendo del número y tipo de roles involucrados (como tramitador o autorizador), se plantea si es más eficiente tener interfaces separadas o una única interfaz adaptativa.

Conclusiones sobre Interfaces Web

• La decisión sobre cómo estructurar las interfaces web debe basarse en las necesidades funcionales específicas y la experiencia del usuario final dentro del sistema administrativo propuesto.

¿Cómo organizar subsistemas y módulos en un sistema?

Identificación de Subsistemas

• Se discute la preferencia por no utilizar flechas al dibujar diagramas, sugiriendo el uso de líneas simples para representar información.

• Se introduce el concepto de subsistema como una entidad significativa que puede contener varios módulos o componentes.

• La importancia de usar vocabulario del enunciado al nombrar subsistemas es enfatizada, ya que esto ayuda a evitar plantillas genéricas que pueden ser confusas.

Ejemplos de Subsistemas

• Se menciona el "subsistema de inscripción de mediadores" como un ejemplo específico, destacando la necesidad de adaptarse a las características del sistema.

• Se propone un "subsistema de consulta del registro", lo cual proporciona servicios a diferentes interfaces dentro del sistema.

Lógica y Funcionalidad

• La lógica detrás del diseño se centra en ofrecer servicios desde la lógica de negocio hacia las interfaces, asegurando claridad en la estructura.

• Se plantea la pregunta sobre cómo los usuarios identifican los subsistemas y se sugiere que deben estar claramente nombrados según el enunciado para facilitar su comprensión.

Descripción Detallada

• Al describir módulos o dominios lógicos, se debe detallar sus funcionalidades e identificar las interfaces y su integración entre ellos.

• Cuanto más descriptivo sea el diseño, mejor encapsulará los requisitos necesarios para la lógica del negocio.

Módulos Específicos

• En todos los ejemplos presentados, se incluye un "subsistema de servicios funcionales" donde se agrupan diversos módulos relevantes.

• Ejemplos específicos incluyen: módulo de autenticación, módulo de registro entrada/salida y módulo de intermediación. Estos son esenciales para proporcionar servicios coherentes dentro del sistema.

Cumplimiento Normativo

• Se menciona el "módulo RISP y transparencia", resaltando la obligación legal que tienen las administraciones públicas para compartir información sectorial.

• La posibilidad de abrir APIs para compartir datos es discutida como una forma efectiva de cumplir con normativas legales relacionadas con la transparencia.

Consideraciones Finales

• El enfoque personal sobre cómo estructurar diagramas arquitectónicos es mencionado; se prefiere tener más elementos visuales para evitar diseños demasiado simples o sosos.

• La importancia de incluir múltiples cajas (módulos/servicios funcionales), así como notificaciones dentro del diseño final, es subrayada como parte integral del proceso.

Diagrama de Contexto y Módulos para Mediadores

Introducción al Diagrama de Contexto

• Se menciona que el diagrama de contexto está incompleto y se busca mejorar su contenido a medida que avanza la discusión.

• Se propone incluir un módulo especial para mediadores concursales, sugiriendo que cada módulo debe tener una descripción clara de sus funciones.

Estructura del Diagrama

• Se discute la necesidad de agrupar funcionalidades en secciones específicas, como "módulo de mediadores concursales" y otras secciones relevantes.

• La importancia de preparar los supuestos con antelación es destacada, ya que las arquitecturas lógicas tienden a ser similares entre los estudiantes.

Requisitos y Subsistemas

• Se identifican requisitos para ser mediador, así como subsistemas necesarios como consulta y aprobación, incluyendo módulos específicos para validación y aceptación/rechazo.

• El enfoque en el análisis detallado en el A2 es considerado crucial, ya que permite profundizar más en los aspectos técnicos del proyecto.

Procedimientos Electrónicos

• Se establece la necesidad de un procedimiento electrónico para gestionar altas, bajas y modificaciones, además del cumplimiento publicitario.

• La inclusión de un gestor documental y herramientas adicionales como cuadros de mando es discutida para mejorar la funcionalidad del sistema.

Capas Transversales y Seguridad

• La capa de acceso a servicios se menciona como esencial; incluye autenticación mediante diferentes métodos (como BOE).

• Se plantea la implementación interna de firma electrónica utilizando librerías propias en lugar de depender completamente de servicios externos.

Interoperabilidad y Normativas

• En las capas transversales se incluyen conceptos clave como interoperabilidad, seguridad y monitorización.

• La discusión sobre seguridad abarca normativas específicas (RGPD), asegurando el cumplimiento a nivel conceptual dentro del sistema propuesto.

Estrategias de Seguridad y Monitorización en Desarrollo de Software

Importancia de la Seguridad y Monitorización

• La seguridad debe reflejarse en todas las capas del software, incluyendo HTML y CSS, aplicando medidas adecuadas para proteger la aplicación.

• Se menciona el uso de ELK stack para la ingesta de logs y monitorización, destacando su importancia en la gestión de información del servidor.

Interoperabilidad y Normativas

• Se discute la necesidad de considerar la interoperabilidad como un aspecto transversal en los diagramas arquitectónicos, aunque no siempre se asocie directamente con el código.

• La inquietud sobre cómo integrar normativas como el esquema nacional de interoperabilidad dentro del desarrollo se plantea como un desafío conceptual.

Perspectivas sobre Diagramas Arquitectónicos

• Se argumenta que al incluir elementos transversales en un diagrama lógico, se está sugiriendo que hay código presente en todas las capas.

• La observancia normativa es vista como una dimensión importante a considerar, aunque no necesariamente vinculada al código.

Debate sobre Protocolos y Representación Gráfica

• Se expresa incomodidad respecto a cómo se representan los protocolos (como HTTPS) entre diferentes capas en diagramas arquitectónicos lógicos.

• El diálogo resalta que mezclar aspectos técnicos con representaciones gráficas puede generar confusión; se sugiere ser más purista al representar estos elementos.

Reflexiones Finales sobre Prácticas Profesionales

• La discusión concluye con una reflexión sobre encontrar un equilibrio entre ser ortodoxo y flexible al aplicar notaciones técnicas en diagramas.

• Se enfatiza la importancia de sentirse cómodo con las soluciones adoptadas durante el proceso profesional, lo cual es clave para el éxito.

Arquitectura Lógica y Subsistemas en Programación

Comodidad en la Enseñanza

• El instructor menciona que con el tiempo se genera una comodidad al explicar conceptos a los alumnos, lo que permite realizar cambios y adaptaciones en la enseñanza.

Interoperabilidad y Presentación de Datos

• Se discute la importancia de presentar información de manera clara, donde cada alumno puede decidir qué aspectos son relevantes para ellos, como la interoperabilidad.

Capas de Arquitectura

• Se habla sobre la separación entre lógica de negocio y tecnología, enfatizando que es crucial mantener una arquitectura lógica conceptual antes de entrar en detalles técnicos.

Comunicación entre Capas

• La comunicación entre capas se establece mediante protocolos como HTTPS y JDBC. Esto ayuda a mantener un diagrama más limpio y organizado.

Comprensión del Código

• Un alumno pregunta sobre subsistemas y módulos, aclarando que un módulo es un fragmento de código dentro de un programa, mientras que un subsistema agrupa varios módulos.

División Funcional en Proyectos

Estructuración del Trabajo por Módulos

• Se explica cómo dividir el trabajo en equipos utilizando subsistemas para facilitar la gestión del proyecto, especialmente durante las fases de programación e integración continua.

Importancia del Análisis y Diseño

• El objetivo principal de una arquitectura lógica es preparar el camino para construir el sistema. En esta fase se definen los módulos necesarios según las necesidades del sistema.

Este formato proporciona una visión clara y estructurada sobre los temas tratados en el transcript, facilitando su estudio y comprensión.

División en Ingeniería del Software

Conceptos de Cohesión y Acoplamiento

• La división en ingeniería del software se basa en la identificación de subsistemas, como instrucción, registro de solicitudes, resolución y estadísticas.

• Se introduce el concepto de cohesión, que es fundamental para entender cómo los módulos deben interactuar entre sí.

• El desacoplamiento es clave; se busca minimizar el acoplamiento entre módulos para mantener la lógica de negocio separada.

• Aunque no se logra un desacoplamiento total (como con microservicios), los subsistemas pueden estar en un mismo servidor (ej. Apache Tomcat).

• Los módulos están interconectados pero permiten cierta independencia; si uno falla, no afecta a los demás.

Desafíos y Aprendizajes

• Al dividir en subsistemas, se facilita la identificación y corrección de errores sin impactar todo el sistema.

• La complejidad puede ser abrumadora para quienes son nuevos en estos conceptos; requiere tiempo para asimilarlo.

• Se enfatiza la importancia de repasar las clases anteriores y practicar con ejemplos semanales para mejorar la comprensión.

Interoperabilidad y Seguridad

• Gisela menciona que ha logrado conectar conceptos previos con lo aprendido hoy, destacando su progreso personal.

• Se discute la necesidad de aclarar aspectos relacionados con seguridad y monitorización dentro del contexto actual del examen A2.

Estrategias Prácticas

• Se aconseja adoptar una actitud flexible al abordar problemas prácticos; a veces es mejor ser ingenioso que perfecto.

• La importancia de integrar elementos adicionales al trabajo práctico para enriquecerlo aunque no refleje completamente la realidad técnica.

Futuras Clases y Proyectos

• En las próximas clases se revisarán supuestos previos para establecer conexiones más claras entre casos de uso y arquitectura lógica.

• Se planea introducir temas más complejos como plataformas de datos, ciencia de datos y machine learning.