Diseño y arquitectura de software PDF

...

Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMATICAS Y FISICA Carrera: SOFTWARE Materia: Diseño y arquitectura de software Docente: ING. Roberto Collantes Integrantes de grupo: Chinga Quimis Carlos Estrada Molina Dereck Martínez Orrala Guillermo Orrala Villón Douglas Reyes Gonzabay Miguel (Líder) Curso: SOF- S-NO-5-4  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software La Arquitectura Orientada a Servicios (SOA) surgió como una respuesta a las limitaciones de los sistemas monolíticos y la creciente necesidad de integrar aplicaciones heterogéneas en un entorno empresarial cada vez más complejo. Causas que impulsaron el surgimiento de SOA: Sistemas monolíticos: Estos sistemas, grandes y complejos, eran difíciles de mantener, actualizar y escalar. Un cambio en una parte del sistema podía afectar a todo el conjunto. Integración de sistemas heterogéneos: Las empresas tenían una gran variedad de sistemas heredados que necesitaban ser integrados para funcionar de manera conjunta. Necesidad de agilidad: El mercado exigía que las empresas fueran más ágiles y respondieran rápidamente a los cambios en las demandas de los clientes. Reutilización de software: Se buscaba una forma de reutilizar componentes de software para reducir costos y acelerar el desarrollo. Arquitectura orientada a servicios (SOA) La Arquitectura Orientada a Servicios es un estilo arquitectónico de software que estructura una aplicación como una colección de servicios interoperables. Estos servicios, que pueden ser comparados con módulos autónomos, realizan tareas específicas y se comunican entre sí a través de un conjunto de protocolos bien definidos, generalmente servicios web.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Fundamentos de SOA Servicios: Son las unidades fundamentales de SOA. Cada servicio encapsula una función específica y expone una interfaz bien definida que otros servicios pueden utilizar. Contratos: Definen cómo los servicios interactúan entre sí. Especifican los mensajes que se intercambian, los formatos de datos y las reglas de negocio. Esqueleto de servicios: Proporciona una capa de abstracción que simplifica la interacción entre servicios, gestionando tareas como la seguridad, el enrutamiento de mensajes y la gestión de transacciones. Repositorio de servicios: Almacena información sobre los servicios disponibles, facilitando su descubrimiento y reutilización. Gobernanza de servicios: Establece las políticas y procedimientos para gestionar el ciclo de vida de los servicios, desde su diseño hasta su retirada. Objetivos de SOA Reutilización: Maximizar la reutilización de código y componentes de software. Flexibilidad: Facilitar la adaptación de las aplicaciones a los cambios en los requisitos del negocio. Escalabilidad: Permitir que los sistemas se expandan para manejar volúmenes de trabajo crecientes.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Interoperabilidad: Integrar diferentes sistemas y aplicaciones de manera eficiente. Agilidad: Aumentar la velocidad de desarrollo y despliegue de nuevas aplicaciones. Beneficios de SOA Mayor eficiencia: Reduce los costos de desarrollo y mantenimiento al reutilizar componentes. Mayor flexibilidad: Permite adaptar los sistemas a los cambios de negocio de manera más rápida. Mejor integración: Facilita la integración de sistemas heterogéneos. Mayor escalabilidad: Permite que los sistemas crezcan de forma gradual y controlada. Mayor mantenimiento: Simplifica la gestión y el mantenimiento de los sistemas. Cómo se Implementa SOA Identificación de servicios: Se identifican las funciones clave del sistema y se definen como servicios individuales. Diseño de interfaces: Se diseñan las interfaces de los servicios, especificando los mensajes que se intercambian y los formatos de datos.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Implementación de servicios: Se desarrollan los servicios utilizando las tecnologías adecuadas. Integración de servicios: Se integran los servicios mediante un mecanismo de comunicación estándar, como servicios web. Gestión de servicios: Se establecen procesos para gestionar el ciclo de vida de los servicios. Tecnologías Utilizadas en SOA Servicios web: El protocolo de comunicación más común utilizado en SOA. ESB (Enterprise Service Bus): Un middleware que facilita la integración y gestión de servicios. BPM (Business Process Management): Permite modelar y automatizar procesos de negocio que involucran múltiples servicios. XML: Un formato estándar para el intercambio de datos entre servicios. Ejemplos de Aplicación de SOA E-commerce: Cada etapa del proceso de compra (catálogo, carrito, pago, envío) puede ser un servicio independiente. Banca: Los servicios pueden gestionar transacciones, cuentas, préstamos y otros servicios financieros.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Gobierno electrónico: Los servicios pueden proporcionar acceso a información pública, trámites en línea y otros servicios gubernamentales. Desafíos de SOA Complejidad: Diseño: Diseñar una arquitectura SOA robusta y escalable requiere una planificación cuidadosa y una comprensión profunda de los principios de SOA. Gestión: La gestión de un gran número de servicios y sus interdependencias puede resultar compleja. Costo: Implementación: La implementación de SOA implica una inversión inicial significativa en infraestructura, herramientas y capacitación. Mantenimiento: El mantenimiento continuo de los servicios y la infraestructura subyacente puede generar costos operativos elevados. Rendimiento: Latencia: La comunicación entre servicios puede introducir latencia, lo que puede afectar el rendimiento de la aplicación, especialmente en sistemas en tiempo real. Seguridad:  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Vulnerabilidades: La exposición de servicios a través de redes puede aumentar el riesgo de ataques cibernéticos. Dependencia de estándares: Evolución: La evolución de los estándares puede requerir actualizaciones frecuentes de los servicios. Gobernanza: Políticas: Establecer y hacer cumplir políticas de gobernanza para los servicios puede ser desafiante. No es adecuada para todos los casos: Proyectos pequeños: Para proyectos pequeños y simples, SOA puede resultar excesiva. Aplicaciones con alta latencia: SOA puede no ser la mejor opción para aplicaciones que requieren tiempos de respuesta extremadamente bajos. Casos en los que SOA puede no ser la mejor opción: Aplicaciones con alto nivel de transferencia de datos: La sobrecarga de comunicación entre servicios puede afectar el rendimiento. Aplicaciones que no requieren de implementación del tipo request/response: SOA está diseñada para sistemas basados en peticiones y respuestas.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Aplicaciones con un corto periodo de vida: El costo de implementación de SOA puede no justificarse para proyectos a corto plazo. Arquitectura orienta a REST Cuando hablamos de lógica sobre las cuales podemos construir un API, no podemos pasar por alto a REST. Actualmente REST es la lógica más utilizada para la construcción de APIs de aplicaciones de software interactivas. Que trabajan sobre un esquema cliente servidor, es muy importante tener en cuenta que hablar de APIs, hablar de REST y hablar de REST FULL API significa hablar de tres términos totalmente diferentes. Una API, es una abstracción de funciones y procedimientos. REST, como tal, es una lógica de restricciones y recomendaciones bajo la cual se puede construir una API. Podríamos decir que es un estilo de arquitectura. Finalmente, una REST FULL API es una API ya implementada que está construida utilizando la lógica de REST. Lo que quiere decir que cuando implementamos nuestra app utilizando REST como lógica e implementación, se dice que tenemos una REST FULL API. Arquitecturas orientadas a Rest  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software REST es un acrónimo que significa (REpresentational State Transfer) Transferencia de Estado Representacional y es una manera de crear APIs. Es una arquitectura de desarrollo de aplicaciones introducida en el año 2000 por Roy Fielding como parte de su disertación doctoral. Esta arquitectura que propone algunos principios que ayudan a que una aplicación web sea estándar y de fácil uso por casi cualquier dispositivo conectado a internet. Pero para comenzar a entender estos sistemas, hay algo que es muy importante para esta clase de sistemas: Sistemas basados en recursos Los sistemas creados con rest deben ser sistemas basados en recursos, no en acciones. Por ejemplo, en un sistema encargado de gestionar ordenes en una pizzería, en este sistema una "Orden" sería un recurso, mientras que "cambiar orden" es una acción. Del mismo modo, el "Repartidor" sería un recurso, mientras que "Repartir pizza" es una acción. Principios de REST Cliente-Servidor Esto se refiere a que para que REST exista debe haber dos actores, un cliente que consuma y un servidor que almacen o genere información. Stateless  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software El hecho de que no almacena estado se refiere a que el servidor no almacena información del cliente para servir a los propósitos de la aplicación. Toda la información necesaria para hacer funcionar a la aplicación debe provenir del cliente. Esto significa que las peticiones deben ser autocontenidas, deben proveer la autenticación en caso de ser necesarias, deben contener el tipo de operación que se va a realizar o la información que se debe modificar. Interfaz Uniforme Los recursos se exponen a través de URls, direcciones http como las que pones en la barra del navegador. Siguiendo con restricción de que debe estar centrado en recuros, es importante que en estas direcciones no se haga referencia a acciones. Por ejemplo, /order es una url válida, mientras que /order/edit no lo es. Las acciones para manipular los recursos se especifican dentro de la petición misma, no en la dirección del recurso. Representaciones A pesar de que es una arquitectura basada en recursos, la información que se transmite entre cliente y servidor no es más que la "representación" del recurso. También es importante que puedan existir más de una representación de un recurso, que estos dependerán del nivel de detalle que requiere la operación que se está realizando.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Por ejemplo, estas podrían ser dos representaciones de un mismo recurso pero que sirven distintos propósitos: Para manipular los recursos se usan algunos los verbos HTTP: POST para crear recursos GET para obtener un recurso PUT para actualizar un recurso DELETE para eliminar un recurso Arquitectura REST FULL API  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Las REST FULL API funcionan estrictamente bajo una arquitectura cliente- servidor, utilizando HTTP como protocolo de comunicación. En esta comunicación, un cliente puede ser nosotros, utilizando y realizando requerimientos desde una aplicación web o móvil, y el servidor es el que recibirá nuestros requerimientos y ejecutará las acciones acordes a nuestra petición. Pero cuando nosotros realizamos un requerimiento, ¿cómo sabe el servidor qué acciones ejecutar? Aquí es donde entra en juego las especificaciones de REST: Las REST FULL API funcionan estrictamente bajo una arquitectura cliente- servidor, utilizando HTTP como protocolo de comunicación. En esta comunicación, un cliente puede ser nosotros, utilizando y realizando requerimientos desde una aplicación web o móvil, y el servidor es el que recibirá nuestros requerimientos y ejecutará las acciones acordes a nuestra petición. En REST, cada procedimiento de nuestra app está compuesto por tres partes importantes: Un verbo HTTP, una dirección URL única y la información necesaria que requiere el servidor para satisfacer el requerimiento, incluyendo la información de autenticación del cliente. Los verbos HTTP son identificadores que determinan el objetivo de un requerimiento del cliente. Entre los verbos HTTP más utilizados tenemos: POST, PUT, PATCH y DELETE, y cada uno de estos cumplen con un propósito específico:  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software GET se utiliza para los procedimientos que devuelven información al cliente. POST se utiliza para que el cliente pueda crear recursos dentro del servidor, por ejemplo, agregar un registro dentro de una base de datos. PUT y PATCH se utilizan para que el cliente pueda editar recursos ya existentes dentro del servidor, finalmente, DELETE se utiliza para eliminar recursos dentro del servidor. Prioriza el uso de hypermedia La forma en que los desarrolladores trabajan con esta información es a través de "hypermedia", o Hipermedia Como Motor del Estado de la Aplicación, pues bien, lo que esto significa que de algún modo, el estado de las aplicaciones se maneja a través de hipermedia, o para que no quede tan libre este término, enlaces. Las representaciones de los recursos con los que responde el servidor deben incluir enlaces a otros recursos relacionados, en el caso de las órdenes de pizza tal vez podríamos tener algo como esto:  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Cacheable Parte del almacenamiento que puede suceder en el cliente es el cacheo de las peticiones, esto con la finalidad de reducir la carga en el servidor y agilizar el tiempo de respuesta. La responsabilidad de establecer si un recurso puede o no ser cacheado depende del recurso que se esté manejando. Por ejemplo, en un recurso llamado "Reporte de ventas", cuya URL sea /reporte_ventas que actualiza una sola vez al día, justo a la 1 de la mañana, ¿qué sentido tendría tener que solicitarle al servidor más de una vez al día el reporte de ventas si siempre nos va a responder con la misma información? Eso sí, el cacheo depende completamente del cliente y este puede decidir ignorar la información que tiene en la caché y hacer las peticiones de cualquier modo. Debido a que el servidor necesita que cada requerimiento tenga toda la información necesaria para poder ejecutar un procedimiento, se dice que REST es estéril, ya que no se necesita guardar información o el estado de peticiones anteriores para poder satisfacer peticiones nuevas.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Cada petición es independiente de otras, He allí el significado de sus siglas: Representational State Transfer. Sin embargo, la arquitectura REST sí admite la implementación de caché para guardar la respuesta de peticiones hechas con anterioridad y de esta forma utilizarlas para poder satisfacer nuevas peticiones de los mismos recursos de manera rápida. Esto se utiliza en los requerimientos de tipo GET. Sistema Multicapa Una aplicación cliente no sabe inicialmente (ni debería interesarle) si está conectada directamente con el servidor o si hay componentes intermedios que incrementan la seguridad o distribuyen la carga entre los servidores de la aplicación. Lo interesante de REST es que la implementación de estos procedimientos del servidor no le interesa al cliente. Ni al servidor le importan las implementaciones dentro del cliente. Para realizar los requerimientos, son como dos cajas negras intercambiando información entre sí. Es decir, a ninguno le importa en qué lenguaje está programado el otro o qué frameworks utiliza el otro. Y esto se puede lograr debido a que en la lógica REST, el servidor debe recibir toda la información necesaria para poder ejecutar cada requerimiento. Haciendo un servicio RESTful A diferencia de los otros conceptos, REST es algo que está expuesto a un tercero y lo ideal sería que si prometes que tienes un servicio RESTful, (así se le llama a los servicios que exponen una API que cumple al 100% con REST), este se cumpla por completo.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Con la creciente demanda de servicios web en el mundo REST ha tomado una popularidad impresionante, y al menos por ahora es el rey de las APIs en el internet O al menos, contando solo las que están expuestas al público. La ventaja de implementar nuestras APIs bajo la lógica REST es que obtendremos APIs de fácil mantenimiento y tendremos una arquitectura modular y escalable dentro de nuestra API. Por ahí existen otras formas de obtener información en la web: el corporativo protocolo SOAP y el nuevo lenguaje GraphQL. Frameworks para concluir hay que decir que, si se realiza una aplicación web que funcione bajo los principios REST, no tiene que hacerse sola. Hay diversos frameworks como Sinatra y Grape para Ruby, LoopBack y ExpressJS para JavaScript, Slim y Silex para PHP, Nancy y Web API para C#, que pueden ayudar a tu cometido.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Caso práctico, Arquitectura orientada a Servicios Un caso práctico destacado de una arquitectura orientada a servicios (SOA) es el de la compañía de transporte y logística FedEx. FedEx adoptó SOA para mejorar la integración de sus diversos sistemas y proporcionar servicios más eficientes y ágiles a sus clientes. Caso Práctico: FedEx Descripción de la Empresa FedEx es una de las mayores compañías de transporte y logística del mundo, proporcionando servicios de envío de paquetes y carga en todo el mundo. La empresa opera con una red global de servicios que necesita integrar múltiples sistemas y aplicaciones para gestionar eficientemente las operaciones. Problema Inicial Antes de implementar SOA, FedEx enfrentaba varios desafíos: Sistemas Heterogéneos: FedEx utilizaba múltiples sistemas desarrollados en diferentes plataformas y lenguajes de programación, lo que dificultaba la integración y la interoperabilidad. Duplicación de Funcionalidades: Había una duplicación de funcionalidades en varios sistemas, lo que aumentaba los costos de mantenimiento y desarrollo.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Agilidad y Tiempo de Mercado: La falta de integración eficiente y la duplicación de esfuerzos impedían a FedEx responder rápidamente a las demandas del mercado y a las necesidades cambiantes de los clientes. Solución: Arquitectura Orientada a Servicios (SOA) FedEx adoptó SOA para abordar estos desafíos, logrando una integración más eficiente y reutilización de servicios a través de toda la organización. A continuación, se describen algunos componentes y servicios clave en su implementación de SOA: 1. Servicio de Rastreo de Paquetes: Responsabilidad: Proporcionar información en tiempo real sobre la ubicación y el estado de los envíos. Tecnología: Utiliza servicios web SOAP para garantizar la interoperabilidad entre diferentes sistemas. 2. Servicio de Gestión de Envíos: Responsabilidad: Gestionar el proceso completo de envío, desde la creación del pedido hasta la entrega final. Tecnología: Expuesto como un servicio reutilizable que puede ser invocado por diversas aplicaciones internas y externas. 3. Servicio de Facturación y Pagos:  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Responsabilidad: Procesar la facturación y los pagos de los clientes, integrándose con sistemas de contabilidad y bancos. Tecnología: Implementado utilizando servicios web RESTful para facilitar la integración con plataformas modernas. 4. Servicio de Notificaciones: Responsabilidad: Enviar notificaciones por correo electrónico y SMS a los clientes sobre el estado de sus envíos. Tecnología: Utiliza servicios web y colas de mensajería para asegurar la entrega fiable de notificaciones. Comunicación y Orquestación Bus de Servicios Empresarial (ESB): FedEx implementó un ESB para facilitar la comunicación entre servicios. El ESB actúa como un middleware que enruta las solicitudes, transforma mensajes y gestiona la seguridad y la fiabilidad. Registro de Servicios: Un registro centralizado de servicios permite descubrir y reutilizar servicios disponibles, reduciendo la duplicación y mejorando la eficiencia. Beneficios Obtenidos Interoperabilidad Mejorada: SOA permitió que los sistemas de diferentes plataformas y lenguajes de programación se comunicaran de manera eficiente, mejorando la integración y la colaboración.  Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Reutilización de Servicios: La creación de servicios reutilizables redujo la duplicación de esfuerzos y los costos de desarrollo y mantenimiento. Agilidad: La capacidad de integrar rápidamente nuevos servicios y modificar los existentes permitió a FedEx responder más ágilmente a las necesidades del mercado y a las demandas de los clientes. Escalabilidad y Flexibilidad: La arquitectura SOA proporcionó una base escalable y flexible que podía adaptarse al crecimiento y a los cambios en las operaciones de la empresa. Desafíos y Soluciones Gestión de Servicios: La administración y el monitoreo de numerosos servicios pueden ser complejos. FedEx abordó esto implementando herramientas de gestión de servicios y monitoreo para asegurar la calidad y el rendimiento. Seguridad: Garantizar la seguridad de los servicios expuestos fue crucial. FedEx implementó políticas de seguridad robustas, incluyendo autenticación, autorización y encriptación de datos. Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas Carrera de Software  UNIVERSIDAD DE GUAYAQUIL Facultad de Ciencias, Matemáticas y Física Ingeniería de Software Alumnos grupo #8: Alvarado Padilla Israel Lozada Castro Kevin Alberto Narváez Moreira Andrea de los Ángeles Orbe Rojas Jordan Arturo Villegas Jaramillo Joseph Anthony Curso: SOF-S-NO-5-4 Docente: ING. Roberto Collantes Fecha: 10 de diciembre del 2024 Página 1 de 7 Arquitecturas Orientadas a Servicios: REST y SOA Introducción Este tema es crucial en el desarrollo de software moderno, ya que estas arquitecturas permiten la creación de sistemas escalables, flexibles y fáciles de integrar. ¿Qué es una arquitectura orientada a servicios? Primero, una arquitectura orientada a servicios (SOA, por sus siglas en inglés) es un enfoque de diseño de software en el que las funcionalidades del sistema se dividen en módulos independientes llamados "servicios". Estos servicios pueden interactuar entre sí mediante protocolos de comunicación estandarizados. Dentro de este paradigma, REST (Representational State Transfer) y SOA son enfoques diferentes que cumplen el objetivo común de integrar servicios. Arquitectura REST REST es un estilo arquitectónico que se basa en los principios del protocolo HTTP. Algunos de sus conceptos clave son: 1. Recursos: En REST, todo se trata como un recurso, identificado por una URL única. 2. Operaciones CRUD: Los recursos se manipulan utilizando los métodos HTTP: GET (obtener datos), POST (crear datos), PUT (actualizar datos) y DELETE (eliminar datos). 3. Stateless: Cada petición al servidor es independiente, es decir, no se almacena información del estado entre peticiones. 4. Formato de datos: Generalmente, REST utiliza JSON o XML para intercambiar información. Ejemplo práctico: API REST para el clima en Guayaquil 1. Planteamiento del caso: Solicitud de API integrada por nombre de ciudad , para este ejemplo vamos a usar el api rest de OPEN Weather para ellos se debe crear una cuenta para generar un Api key Página 2 de 7 2.- Petición por medio de URL como se muestra en la documentación de la página de OpenWeather. https://api.openweathermap.org/data/2.5/weather?q=Guayaquil&app id=83c2e961d17d457761f23c8fb23ab800 Como resultado nos devolverá un Json con toda la información solicitada. Página 3 de 7 3.- Aplicativo en código Python mostraremos la información de forma mas ordenada (se debe instalar el api request para poder importar y hacer el llamado por medio de la URL ) Arquitectura SOA Por otro lado, SOA es un enfoque más general que permite la interoperabilidad entre diferentes aplicaciones, usualmente en entornos empresariales. Algunas de sus características principales incluyen: 1. Servicios: Cada servicio en SOA está diseñado para realizar una función específica, como procesamiento de pagos o gestión de usuarios. 2. Protocolos estandarizados: SOA utiliza protocolos como SOAP (Simple Object Access Protocol) para la comunicación entre servicios. Página 4 de 7  3. Interoperabilidad: Los servicios pueden estar en diferentes plataformas o lenguajes de programación y aun así interactuar sin problemas. 4. Flexibilidad: Permite integrar aplicaciones existentes sin necesidad de rehacerlas. Caso práctico: Implementación SOA en Moodle Escenario Una universidad utiliza Moodle como su plataforma de aprendizaje en línea. Sin embargo, también cuenta con otros sistemas independientes, como el sistema de gestión de estudiantes (SIS), un portal financiero y una biblioteca virtual. El objetivo es integrar estos sistemas para ofrecer una experiencia fluida a los estudiantes y profesores. Implementación SOA con Moodle 1. Servicios Definidos o Servicio de Autenticación y Gestión de Usuarios: Moodle se integra con un servicio de autenticación centralizado que utiliza LDAP o SAML, permitiendo que los usuarios accedan con las mismas credenciales en todos los sistemas. Página 5 de 7  o Servicio de Gestión de Inscripciones: El sistema SIS proporciona la información de los cursos y las inscripciones de los estudiantes a través de una API. o Servicio de Gestión de Pagos: El portal financiero verifica si un estudiante ha pagado sus cuotas antes de permitirle acceder a cursos en Moodle. o Servicio de Biblioteca Virtual: Los estudiantes pueden acceder a recursos académicos desde Moodle a través de un servicio de biblioteca virtual que expone su catálogo por medio de una API REST. 2. Protocolos Estándar o Moodle utiliza REST APIs para consumir servicios externos. Por ejemplo, las inscripciones de estudiantes son sincronizadas desde el SIS mediante una API REST que devuelve datos en formato JSON. o También puede usar SOAP para interactuar con sistemas más antiguos que no soportan REST. 3. Interoperabilidad o El sistema SIS está desarrollado en.NET, el portal financiero en Java y la biblioteca virtual en Python. o Moodle, construido en PHP, interactúa con todos estos sistemas gracias al uso de estándares como REST o SOAP. 4. Flexibilidad o Si la universidad decide agregar un sistema de análisis de datos educativos, este nuevo servicio puede consumir datos directamente de Moodle y otros sistemas a través de las APIs expuestas sin necesidad de modificar las plataformas existentes. Ventajas de SOA en Moodle Integración fluida: Los usuarios tienen una experiencia integrada, accediendo a varios sistemas desde Moodle. Página 6 de 7  Reutilización de servicios: Los mismos servicios (como autenticación o gestión de inscripciones) pueden ser utilizados por otras aplicaciones de la universidad. Escalabilidad: Es fácil integrar nuevos sistemas o reemplazar los existentes sin afectar la funcionalidad de Moodle. Comparación entre REST y SOA Aunque REST y SOA tienen objetivos similares, existen diferencias clave: 1. Simplicidad: REST es más simple y ligero, mientras que SOA suele ser más complejo debido al uso de SOAP y otras herramientas. 2. Interoperabilidad: SOA está más orientado a sistemas empresariales heterogéneos, mientras que REST es ideal para aplicaciones web modernas. 3. Estado: REST es stateless, mientras que en SOA es común tener servicios que mantienen información del estado. 4. Formato de datos: REST utiliza JSON o XML, mientras que SOA generalmente utiliza XML. REST y SOA Tanto REST como SOA son arquitecturas esenciales en el desarrollo de software. REST es ideal para soluciones ligeras y fáciles de implementar, mientras que SOA es más adecuado para entornos empresariales complejos. La elección entre ambas dependerá de los requisitos específicos del proyecto. Página 7 de 7  UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCAS MATEMATICAS Y FISICA CARRERA INGENIRIA EN SOFWARE MATERIA: DISEÑO Y ARQUITECTURA EN SOFTWARE PROFESOR: COLLANTES FARAH ALEX ROBERTO TEMA: ATRIBUTOS Y METRICAS DE DISEÑO INTEGRANTES: OMAR MITE JHON MOREIRA JEAN MARQUEZ VICTOR HIDALGO ANTHONY DELGADO CURSO: 5-4 PERIODO: 2024- 2025 CII GUAYAQUIL - ECUADOR  Atributos de diseño en la Arquitectura de Software Son características que definen la calidad y el comportamiento de un sistema. Estos atributos son fundamentales para asegurar que el software cumpla con los requisitos funcionales y no funcionales. 1. Modularidad Se refiere a la división del sistema en módulos o componentes independientes. Este enfoque facilita la comprensión del sistema, ya que cada módulo puede ser analizado y desarrollado de manera aislada. Además, la modularidad mejora el mantenimiento del código, ya que los cambios en un módulo no afectan necesariamente a otros. También permite la reutilización de componentes en diferentes proyectos, lo que optimiza el tiempo y los recursos de desarrollo. Un ejemplo de modularidad es un sistema de comercio electrónico donde el inventario, los pagos y la gestión de usuarios se implementan como módulos separados. 2. Cohesión Mide qué tan bien se relacionan las responsabilidades de un módulo. Un módulo con alta cohesión tiene una única responsabilidad bien definida, lo que mejora la claridad del diseño. Esto no solo facilita la comprensión del módulo por parte de otros desarrolladores, sino que también hace que sea más fácil de mantener y reutilizar en diferentes contextos. En general, se busca que los módulos sean lo más cohesivos posible para maximizar su efectividad. Por ejemplo, un módulo de autenticación con alta cohesión solo maneja tareas relacionadas con el inicio de sesión y la verificación de usuarios. 3. Acoplamiento Indica el grado de dependencia entre módulos. Un bajo acoplamiento es deseable, ya que permite que los módulos se modifiquen y evolucionen sin afectar a otros. Esto es esencial para la flexibilidad del sistema, ya que los cambios en un módulo no deberían requerir cambios en otros. Un diseño con bajo acoplamiento contribuye a la mantenibilidad y escalabilidad del software. Por ejemplo, un sistema que separa la lógica de negocio del acceso a datos permite realizar cambios en la base de datos sin afectar a la lógica. 4. Escalabilidad Es la capacidad del sistema para manejar un aumento en la carga de trabajo o en el número de usuarios. Un sistema escalable puede crecer sin necesidad de ser rediseñado completamente, lo que es crucial para adaptarse a las necesidades cambiantes del negocio. Esto implica que el diseño debe contemplar la posibilidad de expansión y la incorporación de nuevos recursos sin comprometer el rendimiento. Por ejemplo, un sistema de streaming puede escalar horizontalmente distribuyendo servidores en distintas regiones.  5. Reusabilidad Se refiere a la facilidad con la que un componente puede ser utilizado en diferentes contextos. Un diseño que favorece la reusabilidad permite que los desarrolladores aprovechen componentes ya existentes, lo que ahorra tiempo y recursos en el desarrollo de nuevas funcionalidades. Esto es especialmente valioso en entornos donde se requiere agilidad y eficiencia. Un ejemplo sería una biblioteca de autenticación que puede ser utilizada en múltiples aplicaciones desarrolladas por la misma empresa. 6. Mantenibilidad Es la facilidad con la que se pueden realizar cambios en el software. Un diseño mantenible reduce el costo y el tiempo necesarios para implementar actualizaciones y correcciones. Esto es fundamental en un entorno donde los requisitos pueden cambiar con frecuencia, ya que permite que el software evolucione de manera eficiente sin generar un alto costo en reestructuración. 7. Desempeño Se refiere a la eficiencia del sistema en términos de tiempo de respuesta y uso de recursos. Un buen desempeño es crucial para la satisfacción del usuario, ya que un sistema lento o ineficiente puede frustrar a los usuarios y afectar la adopción del software. Por lo tanto, es importante considerar el desempeño desde las fases iniciales del diseño. Por ejemplo, un motor de búsqueda debe ser capaz de responder a consultas en milisegundos, incluso con millones de usuarios simultáneos. 8. Seguridad Es la protección del sistema contra accesos no autorizados y ataques. Un diseño que prioriza la seguridad asegura la integridad y confidencialidad de los datos. Esto es especialmente importante en aplicaciones que manejan información sensible, ya que cualquier brecha de seguridad puede tener consecuencias graves para la organización y sus usuarios. Un ejemplo sería un sistema bancario que utiliza cifrado de extremo a extremo y autenticación multifactor. 9. Usabilidad Se refiere a la facilidad con la que los usuarios pueden interactuar con el sistema. Un diseño centrado en la usabilidad mejora la experiencia del usuario y facilita la adopción del sistema. Esto implica que la interfaz debe ser intuitiva y accesible, permitiendo que los usuarios cumplan con sus tareas de manera eficiente y satisfactoria. Por ejemplo, una plataforma de gestión de proyectos debe ofrecer flujos claros e instrucciones simples para que los usuarios puedan trabajar sin necesidad de formación intensiva.  Métricas de Diseño en la Arquitectura de Software Las métricas de diseño son herramientas cuantitativas que se utilizan para medir la calidad, eficiencia y características del diseño del software. Estas métricas permiten evaluar y mejorar los atributos de diseño mencionados. 1. Métricas de Complejidad Complejidad Ciclomática: Mide la cantidad de rutas independientes en el código. Es útil para determinar la dificultad de realizar pruebas y mantener el sistema. Fórmula: V(G)=E−N+2 Donde E es el número de aristas y N el número de nodos del grafo de control. Ejemplo: Si un módulo tiene 15 aristas y 8 nodos, su complejidad será V(G) = 15 - 8 + 2 = 9, lo cual indica moderada complejidad. Complejidad de Halstead: Evalúa la cantidad de operadores y operandos en el código, determinando su esfuerzo cognitivo. Ejemplo: Para un código con 30 operadores y 25 operandos totales, y 10 operadores y 8 operandos únicos, el esfuerzo cognitivo es considerable. 2. Métricas de Cohesión Cohesión LCOM: Mide el grado en que los métodos de una clase trabajan en conjunto. Un valor bajo indica alta cohesión, que es deseable. Fórmula simplificada: LCOM = |M| - |M a| / |M| Donde |M| es el número de métodos y |M a| el número de métodos que acceden a atributos comunes. Ejemplo: Si una clase tiene 10 métodos y solo 4 comparten atributos, LCOM sería 0.6, lo que indica baja cohesión y posible necesidad de refactorización. 3. Métricas de Acoplamiento Acoplamiento entre Módulos: Mide el número de clases con las que una clase interactúa directamente. Fan-in y Fan-out: Fan-in: Número de módulos que llaman a un módulo específico. Fan-out: Número de módulos que son llamados por un módulo específico. Ejemplo: Un módulo con Fan-in de 5 y Fan-out de 10 indica que está sobrecargado, lo cual podría ser un problema de dependencia excesiva. 4. Métricas de Tamaño Líneas de Código: Mide el número total de líneas de código en un programa o componente. Puntos de Función: Evalúa el tamaño funcional del sistema basado en entradas, salidas, consultas y archivos internos. Ejemplo: Un sistema con 10 entradas y 5 salidas de complejidad media podría sumar 45 puntos de función. 5. Métricas de Modularidad Índice de Modularidad: Evalúa el número de módulos y el grado de independencia entre ellos. Razón de Reutilización de Módulos: Calcula el porcentaje de módulos reutilizados frente al total de módulos creados. Ejemplo: Si 30 de 50 módulos son reutilizados, la razón será del 60%. 6. Métricas de Rendimiento Tiempos de respuesta: Tiempo que toma el sistema para responder a una solicitud. Uso de CPU y memoria: Mide el porcentaje de recursos consumidos por el sistema. Ejemplo: Un tiempo de respuesta de 2 segundos podría ser aceptable en aplicaciones web, pero inadecuado para sistemas críticos. 7. Métricas de Pruebas Cobertura de Código: Porcentaje de código ejecutado durante las pruebas. Ejemplo: Un 80% de cobertura indica buen control, pero queda margen para mejorar. Densidad de Defectos: Número de defectos detectados por cada línea de código o puntos de función. Ejemplo: Un sistema con 5 defectos en 1000 líneas tiene una densidad de 0.005, lo cual es razonable.  UNIVERSIDAD DE GUAYAQUIL Facultad de Ciencias, Matemáticas y Física Ingeniería de Software Alumnos grupo #8: Alvarado Padilla Israel Lozada Castro Kevin Alberto Narváez Moreira Andrea de los Ángeles Orbe Rojas Jordan Arturo Villegas Jaramillo Joseph Anthony Curso: SOF-S-NO-5-4 Docente: ING. Roberto Collantes Fecha: 23 de enero del 2025 Página 1 de 10 Patrones de diseño ¿Qué son los patrones de diseño? Los patrones de diseño o design patterns, son una solución general, reutilizable y aplicable a diferentes problemas de diseño de software. Se trata de plantillas que identifican problemas en el sistema y proporcionan soluciones apropiadas a problemas generales a los que se han enfrentado los desarrolladores durante un largo periodo de tiempo, a través de prueba y error. Cada patrón de diseño tiene un propósito específico y ofrece una solución a un problema de diseño común. Es importante tener en cuenta que los patrones de diseño no son algoritmos o código listo para usar, sino más bien pautas y descripciones de soluciones de diseño. Los patrones de diseño de software se basan en principios y prácticas de diseño que han evolucionado a lo largo del tiempo. A menudo, se describen utilizando terminología y notaciones específicas para facilitar su comprensión y aplicación. Características principales de los patrones de diseño: Reusabilidad: Se pueden aplicar a diferentes proyectos, reduciendo el esfuerzo de resolución de problemas repetidos. Flexibilidad: Ayudan a estructurar sistemas que puedan adaptarse fácilmente a los cambios. Comunicabilidad: Ofrecen un lenguaje común entre desarrolladores, mejorando la comunicación en equipos de trabajo. Mantenibilidad: Fomentan la escritura de código limpio, modular y fácil de entender. Tipos de patrones de diseño de sotware Los patrones de diseño más utilizados se clasifican en tres categorías principales, cada patrón de diseño individual conforma un total de 23 patrones de diseño. Las cuatro categorías principales son: 1. Patrones creacionales Su objetivo es resolver los problemas de creación de instancia. Estos ayudan a delegar responsabilidad de creación de objetos en situaciones necesarias. Página 2 de 10 Sus pilares fundamentales son encapsular el conocimiento de las clases y Ocultar cómo se crean y se instancian. Se subdividen a su vez así: Singleton (Instancia única): nos garantiza la existencia de una única instancia para una clase. Prototype (prototipo): Clona las instancias ya existentes. Abstract Factory: Permite proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas. Builder: Ayuda a crear objetos complejos de manera sencilla, legible y escalable. Se utiliza en situaciones en las que debe construirse un objeto repetidas veces. Factory Method: Nos ayuda a tener instancias de un objeto dado el tipo. 2. Patrones estructurales Su nombre es muy descriptivo, se ocupa de resolver problemas sobre la estructura de las clases, es decir, se enfocan en cómo las clases y objetos se componen para formar estructuras mayores. Aquí encuentras: Bridge (Puente): Separa la abstracción de la implementación. Decorator (Decorador): Agrega funcionalidades a una clase de forma dinámica. Facade (Fachada): Nos provee una interfaz unificada y simple para acceder a un sistema más complejo. Adapter: Cuando dos clases no se entiende, el adapter es mediador y adapta una clase para que la otra la entienda. Composite: Ayuda a construir objetos complejos a partir de otros más simples. Flyweight: Página 3 de 10 Se refiere a los objetos que queremos reutilizar para crear objetos más ligeros. Proxy: Es un elemento que se encarga de introducir un nivel de acceso a una clase. Ese nivel de acceso puede ser por seguridad o por complejidad. 3. Patrones de comportamiento Nos ayuda a resolver problemas relacionados con el comportamiento de la aplicación. Ofrece soluciones respecto a la interacción y responsabilidad entre objetos y clases. Por ejemplo: Observer (Observador): Un objeto le pasa el estado interno a muchos objetos que están interesados. Chain of Responsibility: Simplifica las interconexiones de objetos. Command: Separa acciones que pueden ser ejecutadas desde varios puntos diferentes de la aplicación a través de una interfaz sencilla. Iterator: Este se utiliza en relación a objetos que almacenan colecciones de otros objetos. Mediator: Define un objeto que media entre otros objetos. Memento: Se utiliza para restaurar el estado de un objeto a un estado anterior. State: Permite a un objeto alterar su comportamiento cuando su estado interno cambia. Strategy: Permite que un objeto tenga parte o todo su comportamiento definido en términos de otro objeto que sigue una interfaz particular. Template Method: Se centra en la reutilización del código para implementar pasos para resolver problemas. Visitor: Página 4 de 10 Se utiliza para separar la lógica y las operaciones realizadas sobre una estructura compleja. Ejemplo práctico: Singleton Supongamos que estamos desarrollando un sistema de logging y queremos asegurarnos de que solo exista una instancia de la clase que maneja los logs. Este problema se resuelve con el patrón Singleton: Este patrón asegura que: Solo exista una única instancia de una clase durante la ejecución del programa. Esa instancia sea accesible globalmente. 1. Atributo _instance La variable de clase _instance (definida como None al inicio) se utiliza para almacenar la única instancia de la clase. Es estática porque pertenece a la clase y no a las instancias individuales. 2. Método __new__ Este método especial se invoca cuando se crea un objeto de la clase. Usamos este método para controlar la creación de la instancia única. Página 5 de 10 Patrones Arquitectónicos ¿Alguna vez te preguntaste cómo se diseñan los grandes sistemas empresariales? Antes de que comience un importante desarrollo de software, debemos elegir una arquitectura adecuada que nos proporcione la funcionalidad deseada y los atributos de calidad. Por lo tanto, debemos entender diferentes arquitecturas, antes de aplicarlas a nuestro diseño. ¿Qué es un patrón arquitectónico? Los patrones arquitectónicos son soluciones generales y reutilizables para problemas recurrentes en la arquitectura de software dentro de un contexto específico. Estos patrones proporcionan estructuras y prácticas probadas que facilitan el diseño y desarrollo de sistemas de software robustos y mantenibles. A continuación, se describen algunos de los patrones arquitectónicos más comunes: 1. Patrón de capas Este patrón se puede utilizar para estructurar programas que se pueden descomponer en grupos de subtareas, cada una de las cuales se encuentra en un nivel particular de abstracción. Cada capa proporciona servicios a la siguiente capa superior. Las 4 capas más comúnmente encontradas de un sistema de información general son las siguientes. Capa de presentación (también conocida como capa UI ) Capa de aplicación (también conocida como capa de servicio ) Capa de lógica de negocios (también conocida como capa de dominio ) Capa de acceso a datos (también conocida como capa de persistencia ) Uso Aplicaciones de escritorio generales. Aplicaciones web de comercio electrónico. Página 6 de 10  2. Patrón cliente-servidor Este patrón consiste en dos partes; un servidor y múltiples clientes. El componente del servidor proporcionará servicios a múltiples componentes del cliente. Los clientes solicitan servicios del servidor y el servidor proporciona servicios relevantes a esos clientes. Además, el servidor sigue escuchando las solicitudes de los clientes. Uso Aplicaciones en línea como correo electrónico, uso compartido de documentos y banca. 3. Patrón maestro-esclavo Este patrón consiste en dos partes; maestro y esclavos. El componente maestro distribuye el trabajo entre componentes esclavos idénticos y calcula el resultado final de los resultados que devuelven los esclavos. Uso En la replicación de la base de datos, la base de datos maestra se considera como la fuente autorizada y las bases de datos esclavas se sincronizan con ella. Periféricos conectados a un bus en un sistema informático (unidades maestra y esclava). Página 7 de 10  4. Patrón de filtro de tubería Este patrón se puede usar para estructurar sistemas que producen y procesan una secuencia de datos. Cada paso de procesamiento se incluye dentro de un componente de filtro. Los datos que se procesarán se pasan a través de las tuberías. Estas tuberías se pueden utilizar para el almacenamiento en búfer o con fines de sincronización. Uso Compiladores Los filtros consecutivos realizan análisis léxico, análisis sintáctico y generación de código. Flujos de trabajo en bioinformática. 5. Patrón del agente Este patrón se usa para estructurar sistemas distribuidos con componentes desacoplados. Estos componentes pueden interactuar entre sí mediante invocaciones de servicios remotos. Un componente de intermediario es responsable de la coordinación de la comunicación entre los componentes. Los servidores publican sus capacidades (servicios y características) a un intermediario. Los clientes solicitan un servicio del intermediario y el intermediario redirecciona al cliente a un servicio adecuado desde su registro. Uso Software de Message Broker como: Apache ActiveMQ , Apache Kafka , RabbitMQ y JBoss Messaging. Página 8 de 10  6. Patrón de igual a igual En este patrón, los componentes individuales se conocen como pares. Los pares pueden funcionar tanto como un cliente, solicitando servicios de otros pares, y como un servidor, proporcionando servicios a otros pares. Un par puede actuar como un cliente o como un servidor o como ambos, y puede cambiar su rol dinámicamente con el tiempo. Uso Redes de intercambio de archivos como Gnutella y G2 ) Protocolos multimedia como P2PTV y PDTP. 7. Patrón de modelo-vista-controlador Este patrón, también conocido como patrón MVC, divide una aplicación interactiva en 3 partes, como Modelo: contiene la funcionalidad y los datos básicos Vista: muestra la información al usuario (se puede definir más de una vista) Controlador: maneja la entrada del usuario Esto se hace para separar las representaciones internas de información de las formas en que se presenta y acepta la información del usuario. Desacopla los componentes y permite la reutilización eficiente del código. Uso Arquitectura para aplicaciones World Wide Web en los principales lenguajes de programación. Marcos web como Django y Rails. Página 9 de 10  8. Patrón de bus de evento Este patrón trata principalmente con eventos y tiene 4 componentes principales; fuente de evento, escucha de evento , canal y bus de evento. Las fuentes publican mensajes en canales particulares en un bus de eventos. Los oyentes se suscriben a canales particulares. Los oyentes son notificados de los mensajes que se publican en un canal al que se han suscrito anteriormente. Uso Desarrollo de Android Servicios de notificación Página 10 de 10  Integrantes grupo# 2: ARTEAGA BERRONES KLEBER ISAAC BAQUE QUIROZ DIEGO LEANDRO IZQUIERDO VALLEJO GALO ANTONIO JACHO CEDEÑO MARIO MAURICIO QUINDE ASPIAZU NICOLAS ISMAEL FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA: SOFTWARE DISEÑO Y ARQUITECTURA DEL SOFTWARE Contenido Diseño de Sistemas en Red y Móviles.........................................................................................3 Diagramas, clases y objetos........................................................................................................9 Lenguaje Unificado de Modelado (UML)..................................................................................12 Notaciones de Diseño DFD (Diagrama de Flujo de Datos)........................................................19 Diseño Detallado.......................................................................................................................21 Referencias Bibliográficas.........................................................................................................28  Diseño de Sistemas en Red y Móviles 1. Introducción El diseño de sistemas en red y móviles se centra en la creación de soluciones tecnológicas que conectan dispositivos y servicios a través de redes locales, globales o móviles. Este tipo de sistemas soporta aplicaciones que van desde servicios empresariales hasta aplicaciones personales en dispositivos como smartphones y tabletas. Se debe definir la estructura interna de una aplicación, su interacción con otros sistemas y su desempeño. Este nivel de diseño se enfoca en los detalles técnicos, como la arquitectura, los algoritmos, las interfaces de programación y la base de datos. ¿Por qué es importante el diseño detallado? Calidad: Un diseño detallado bien estructurado garantiza la calidad del software, reduciendo errores y facilitando el mantenimiento. Eficiencia: Permite optimizar el uso de recursos y mejorar el rendimiento de la aplicación. Escalabilidad: Facilita la adaptación del software a futuras necesidades y a un aumento en el número de usuarios. Reutilización: Permite la creación de componentes reutilizables, lo que agiliza el desarrollo de nuevas funcionalidades. Los sistemas en red y móviles son fundamentales en la era digital actual, donde la conectividad constante es esencial. Estos sistemas deben ser diseñados para ser eficientes, seguros, escalables y adaptables a diferentes entornos. Objetivos principales: Proveer conectividad confiable entre dispositivos. Garantizar el acceso eficiente a los datos. Optimizar la experiencia del usuario. 2. Fases del Diseño Detallado 1. Análisis de Requisitos: o Recopilación: Se recolectan todos los requisitos funcionales y no funcionales del sistema a través de entrevistas, talleres y documentación.  o Especificación: Los requisitos se documentan de manera precisa y concisa, utilizando técnicas como los casos de uso. o Validación: Se verifica que los requisitos sean completos, consistentes y comprensibles para todos los involucrados. 2. Diseño de la Arquitectura: o Selección del patrón de diseño: Se elige el patrón de diseño más adecuado (MVC, MVP, MVVM, etc.) en función de los requisitos del sistema y las tecnologías utilizadas. o Definición de componentes: Se identifican los principales componentes del sistema y sus responsabilidades. o Definición de interfaces: Se establecen las interfaces de comunicación entre los diferentes componentes. o Diseño de la base de datos: Se define la estructura de la base de datos, incluyendo las tablas, las relaciones y los índices. 3. Diseño de la Interfaz de Usuario (UI): o Diseño visual: Se crea una interfaz visual atractiva y fácil de usar, siguiendo las pautas de diseño de la plataforma (iOS, Android, web). o Diseño de interacción: Se define la forma en que el usuario interactúa con la aplicación, incluyendo la navegación, los gestos y los controles. o Prototipado: Se crean prototipos interactivos para validar el diseño con los usuarios. 4. Diseño de la Lógica de Negocio: o Definición de algoritmos: Se diseñan los algoritmos necesarios para implementar las funcionalidades del sistema. o Validación de datos: Se establecen las reglas de validación de los datos ingresados por el usuario. o Manejo de errores: Se definen las acciones a tomar en caso de errores o excepciones. 5. Diseño de la Base de Datos: o Modelo de datos: Se crea un modelo de datos que representa la información que el sistema debe almacenar. o Optimización de consultas: Se diseñan consultas eficientes para acceder a los datos. o Seguridad: Se implementan medidas de seguridad para proteger los datos. 3. Sistemas en Red Un sistema en red conecta múltiples dispositivos, facilitando la comunicación y el intercambio de información. 3.1. Tipos de Redes LAN (Local Area Network): Conexión en un área limitada, como una oficina. WAN (Wide Area Network): Conexión de redes a nivel global. MAN (Metropolitan Area Network): Redes que cubren áreas metropolitanas. 3.2. Tecnologías Asociadas Ethernet: Utilizada en redes LAN. Wi-Fi: Conexión inalámbrica para dispositivos. 5G: Red móvil de alta velocidad. 4. Sistemas Móviles Los sistemas móviles están diseñados para operar en dispositivos portátiles y aprovechar las redes inalámbricas. 4.1. Características Movilidad: Los usuarios pueden acceder al sistema desde cualquier lugar. Interactividad: Interfaces intuitivas para mejorar la experiencia. Adaptabilidad: Diseño responsivo para diferentes dispositivos. 4.2. Desafíos Limitaciones de hardware: Procesadores menos potentes y menor capacidad de batería. Conectividad intermitente: Redes inestables o lentas. Compatibilidad: Diversidad de sistemas operativos y versiones. 4.3. Tecnologías Asociadas APIs RESTful: Facilitan la comunicación entre aplicaciones. Frameworks móviles: Como Flutter, React Native o Xamarin. Servicios de localización: Basados en GPS para funcionalidades geográficas. 5. Metodologías de Diseño 5.1. Arquitectura del Sistema Componentes Principales: Identificación de servidores, clientes, bases de datos y dispositivos móviles involucrados. Modelo de Arquitectura: o Cliente-servidor, N capas, arquitectura RESTful, microservicios o arquitectura distribuida. Protocolos de Comunicación: o Protocolos de transporte como HTTP, HTTPS, TCP/IP o UDP. o Protocolos de red específicos como MQTT para IoT o WebSocket para aplicaciones en tiempo real. 5.2. Interfaces del Sistema Diseño de API: o Métodos HTTP (GET, POST, PUT, DELETE). o Especificaciones como OpenAPI/Swagger para documentación. o Control de versiones de API. Interfaces de Usuario: o Mockups o prototipos de aplicaciones móviles/web/desktop. o Principios de diseño adaptativo (Responsive Design) para múltiples dispositivos. 5.3. Modelo de Datos Esquema de Base de Datos: o Tablas, relaciones, índices y vistas. o Bases de datos SQL (MySQL, PostgreSQL) o NoSQL (MongoDB, Firebase). Estructura de Datos en Memoria: o Caching con herramientas como Redis o Memcached. Flujos de Datos: o Diagramas de flujo o mapeo de interacciones entre los módulos. 5.4. Detalles de la Lógica del Negocio Algoritmos y Procesos: o Validación de datos.  o Reglas de negocio específicas (cálculos, integridad de transacciones). Gestión de Sesiones y Estados: o Mecanismos como JWT (JSON Web Tokens), OAuth o sesiones del servidor. 5.5. Seguridad Cifrado de Datos: En tránsito (TLS/SSL) y en reposo. Autenticación y Autorización: o Single Sign-On (SSO), OAuth 2.0, autenticación multifactor. Protección contra Ataques: o Filtrado de entrada para prevenir inyecciones SQL y XSS. o Políticas de firewall y detección de intrusos. 5.6. Conectividad y Sincronización Gestión de Conexiones: o Balanceo de carga y escalabilidad horizontal. Sincronización de Datos: o Mecanismos de actualización en tiempo real (Firebase, WebSocket). o Sincronización offline con estrategias de almacenamiento local. 5.7. Pruebas y Validaciones Pruebas de Red: o Simulación de latencia, pérdida de paquetes y pruebas de ancho de banda. Pruebas de Sistema: o Pruebas de estrés y rendimiento (con JMeter o Gatling). Pruebas de Usabilidad: o Evaluaciones en dispositivos móviles con diferentes tamaños de pantalla y sistemas operativos. o Evaluaciones Heuristicas. 5.8. Consideraciones de Movilidad Optimización para Dispositivos Móviles: o Minimización del consumo de batería y datos.  o Uso eficiente de sensores y hardware móvil (GPS, acelerómetro). Compatibilidad Multiplataforma: o Uso de frameworks como Flutter o React Native para aplicaciones móviles híbridas. Gestión de Recursos en Red: o Mecanismos para trabajar en condiciones de conectividad intermitente. 5.9. Documentación Diagramas UML: o Diagramas de clases, secuencia y casos de uso para explicar interacciones. Manual Técnico: o Instrucciones detalladas para desarrolladores e integradores. Guía de Usuarios: o Instrucciones simplificadas para los usuarios finales. 6. Consideraciones Especiales para Redes y Móviles Conectividad: Diseñar aplicaciones que funcionen de manera confiable en entornos con baja conectividad o intermitente. Seguridad: Implementar medidas de seguridad robustas para proteger los datos del usuario. Escalabilidad: Diseñar aplicaciones que puedan manejar un gran número de usuarios y una gran cantidad de datos. Rendimiento: Optimizar el código para garantizar una respuesta rápida y una experiencia de usuario fluida. Plataformas: Adaptar el diseño a diferentes plataformas (iOS, Android, web) manteniendo una experiencia de usuario consistente. 7. Ejemplo Práctico: Aplicación de Mensajería Requerimientos: Enviar y recibir mensajes en tiempo real. Sincronización de mensajes entre dispositivos. Opciones de privacidad y seguridad. Solución Diseñada: 1. Arquitectura: Cliente-servidor con soporte para WebSocket. 2. Protocolos: Cifrado TLS para seguridad. 3. Escalabilidad: Balanceo de carga con servidores en la nube. 4. Interfaces: Diseño responsivo para web y móvil. 8. Conclusión El diseño de sistemas en red y móviles requiere considerar aspectos técnicos, de experiencia de usuario y de seguridad para garantizar un funcionamiento eficiente. La adopción de buenas prácticas y el uso de tecnologías modernas permiten crear soluciones que satisfacen las demandas de un mundo interconectado y en constante movimiento. Un diseño bien estructurado es fundamental para el éxito de cualquier proyecto de software, ya que garantiza la calidad, la eficiencia y la escalabilidad del producto final. Diagramas, clases y objetos Los diagramas, clases y objetos son conceptos fundamentales en el desarrollo de software, especialmente dentro de la programación orientada a objetos (POO). Estos elementos permiten representar, organizar y estructurar sistemas complejos de manera más comprensible y manejable. Diagramas Un diagrama es una representación gráfica que ayuda a visualizar la estructura y el comportamiento de un sistema. En el contexto de la POO, los diagramas de clases son una herramienta esencial proporcionada por el Lenguaje Unificado de Modelado (UML, por sus siglas en inglés). Estos diagramas muestran las clases, sus atributos, métodos y las relaciones entre ellas. Componentes principales de un diagrama de clases: 1. Clases: Representan entidades del sistema, como "Usuario" o "Producto". Se representan con un rectángulo dividido en tres secciones: o Nombre de la clase. o Atributos (propiedades o características de la clase). o Métodos (funciones o comportamientos asociados a la clase). 2. Relaciones: Los diagramas de clases incluyen varios tipos de relaciones entre clases, como:  o Asociación: Conexión lógica entre dos clases. o Herencia: Representa la especialización entre una clase padre y sus clases hijas. o Agregación: Relación "todo-parte" donde una clase puede existir independientemente de la otra. o Composición: Relación más fuerte que la agregación, donde la existencia de una clase depende completamente de otra. 3. Modificadores de visibilidad: Indican el acceso a atributos y métodos: o "+": Público, accesible desde cualquier lugar. o "#": Protegido, accesible solo desde la misma clase y sus subclases. o "-": Privado, accesible solo dentro de la misma clase. Los diagramas son útiles para planificar y documentar sistemas antes y durante el desarrollo. Clases Una clase es una plantilla o modelo que define las características y comportamientos de un conjunto de objetos similares. En términos simples, una clase establece las propiedades (atributos) y acciones (métodos) que tendrán los objetos creados a partir de ella. Estructura básica de una clase: Elementos importantes de una clase: 1. Atributos: Representan las características o datos asociados a la clase. En el ejemplo, nombre y edad son atributos de la clase Persona. 2. Constructores: Métodos especiales utilizados para inicializar objetos. 3. Métodos: Funciones que definen el comportamiento de la clase. Por ejemplo, el método saludar permite a la clase Persona realizar una acción. Objetos Un objeto es una instancia de una clase. Representa una entidad concreta en el sistema, con valores específicos en sus atributos y la capacidad de ejecutar métodos definidos en la clase. Creación y uso de un objeto: En este ejemplo, persona1 es un objeto de la clase Persona. Tiene valores específicos (“Juan” y 25) para sus atributos y puede ejecutar el método saludar. Características clave de los objetos: 1. Estado: Representado por los valores de sus atributos. 2. Comportamiento: Determinado por los métodos que puede ejecutar. 3. Identidad: Cada objeto es único, incluso si pertenece a la misma clase. Relación entre Clases y Objetos Las clases actúan como moldes, mientras que los objetos son las instancias concretas que toman forma a partir de estas. Por ejemplo, la clase Persona puede tener múltiples objetos como persona1, persona2, etc., cada uno con su propio estado. Importancia de Diagramas, Clases y Objetos El uso de diagramas facilita la planificación y comprensión de sistemas complejos, mientras que las clases y los objetos permiten implementar soluciones modulares, reutilizables y fáciles de mantener. En conjunto, estos elementos forman la base para diseñar y desarrollar aplicaciones robustas y escalables.  Lenguaje Unificado de Modelado (UML) UML es un lenguaje de modelado visual diseñado para representar de manera detallada la arquitectura, el diseño y la implementación de sistemas complejos. Aunque se utiliza principalmente en el desarrollo de software, también tiene aplicaciones en otras áreas, como la gestión de procesos en la industria manufacturera. UML permite describir los límites, la estructura y el comportamiento de un sistema y sus componentes, de forma similar a los planos utilizados en disciplinas como la arquitectura o la ingeniería. Aunque no es un lenguaje de programación, UML está estrechamente vinculado con el análisis y diseño orientados a objetos. Además, existen herramientas que permiten convertir sus diagramas en código de distintos lenguajes. Requisitos de UML UML está diseñado para cumplir con tres objetivos principales: 1. Definir la semántica de sus conceptos: Proporciona una base independiente de la tecnología para garantizar que los conceptos puedan ser desarrollados por computadoras. 2. Especificar elementos de notación visual: Facilita la representación comprensible de los conceptos a través de diagramas, con reglas claras para su combinación. 3. Fomentar la compatibilidad entre herramientas UML: Esto incluye el uso de formatos de intercambio basados en XML (XMI) que permiten interoperabilidad. Tipos de Diagramas UML UML utiliza elementos y relaciones para crear diagramas que representan aspectos estructurales y de comportamiento de un sistema. Diagramas Estructurales Estos capturan la estructura estática del sistema: Diagrama de clases: El más común, describe las clases, sus atributos, operaciones y relaciones en sistemas orientados a objetos.  Diagrama de componentes: Representa la relación estructural entre los componentes de un sistema, especialmente útil en sistemas complejos.  Diagrama de implementación: Ilustra el hardware y software de un sistema, ideal para configuraciones en múltiples máquinas. Diagrama de objetos: Representa las relaciones entre objetos en un momento específico, útil para ilustrar escenarios concretos.  Diagrama de paquetes: Agrupa elementos del sistema y muestra dependencias entre niveles o módulos. Diagramas de Comportamiento Estos reflejan los aspectos dinámicos y funcionales del sistema: Diagrama de actividades: Representa flujos de trabajo o procesos operativos.  Diagrama de comunicación: Destaca los mensajes entre objetos, similar a los diagramas de secuencia. Diagrama de secuencia: Describe cómo interactúan los objetos y el orden de los eventos.  Diagrama de máquina de estados: Detalla cómo cambia el estado de un objeto según sus condiciones actuales. Diagrama de temporización: Representa el comportamiento de objetos durante un intervalo de tiempo.  Diagrama de caso de uso: Ilustra las funcionalidades del sistema y sus interacciones con los actores.  Notaciones de Diseño DFD (Diagrama de Flujo de Datos) Un Diagrama de Flujo de Datos (DFD) es una representación gráfica que muestra cómo la información fluye dentro de un sistema. Es ampliamente utilizado en el diseño de sistemas para modelar procesos y su interacción con datos. Las notaciones son fundamentales para entender y representar estos diagramas correctamente. Aquí se describen las notaciones más comunes: 1. Componentes básicos y su notación gráfica a) Entidades Externas Descripción: Representan los actores fuera del sistema que interactúan con él (proveedores, clientes, otros sistemas). Símbolo: Un rectángulo o cuadrado. Ejemplo: Cliente, Usuario, Sistema externo. b) Procesos Descripción: Representan transformaciones o actividades que convierten entradas en salidas. Símbolo: Un círculo o un óvalo (dependiendo del estándar). Ejemplo: "Procesar pedido", "Generar reporte". c) Flujo de Datos Descripción: Representan la transferencia de datos entre procesos, entidades externas y almacenes de datos. Símbolo: Una flecha etiquetada. Ejemplo: Datos de clientes, Transacciones. d) Almacenes de Datos Descripción: Representan lugares donde los datos se almacenan dentro del sistema. Símbolo: Un rectángulo con líneas horizontales en sus extremos (o simplemente un rectángulo abierto en algunas notaciones). Ejemplo: Base de datos, Archivo físico. 2. Notaciones más comunes a) Gane y Sarson Característica: Utiliza rectángulos redondeados para procesos y símbolos de tipo ficha para almacenes de datos. Ventaja: Proporciona un diseño limpio y moderno, especialmente útil en sistemas grandes. b) Yourdon y DeMarco Característica: Usa círculos para procesos y rectángulos abiertos para almacenes de datos. Ventaja: Es más simple y minimalista, adecuado para diagramas conceptuales. c) Notación UML (adaptación para flujos) Aunque no es estándar para DFD, UML puede adaptarse para representar flujos con sus diagramas de actividad y casos de uso. 3. Niveles de DFD 1. DFD de Nivel 0 (Diagrama de Contexto) Representa todo el sistema como un único proceso con sus entradas y salidas principales. o Ejemplo: "Sistema de Ventas". 2. DFD de Nivel 1 Detalla los subprocesos del sistema principal, mostrando interacciones entre ellos. 3. DFD de Nivel 2 y superiores Ofrecen un desglose más detallado, llegando a procesos específicos. 4. Herramientas para diseñar DFD Software especializado: o Microsoft Visio o Lucidchart o Draw.io o Bizagi o StarUML  Diseño Detallado Especificación formal La especificación formal es el proceso de definir los requisitos y el comportamiento de los sistemas de software con técnicas matemáticas y lógicas rigurosas. A diferencia de las especificaciones informales, que suelen basarse en descripciones y diagramas en lenguaje natural, las especificaciones formales utilizan lenguajes formales precisos para describir exactamente lo que debería hacer el sistema. Este enfoque proporciona una descripción clara e inequívoca del comportamiento previsto del sistema. Las especificaciones formales constan de varios componentes clave: Lenguaje formal: se utiliza para expresar los requisitos del sistema con una sintaxis y una semántica precisas. Modelos matemáticos: representan los componentes del sistema y sus interacciones. Pruebas lógicas: se emplean para demostrar que el sistema cumple con su especificación, lo que garantiza su corrección. Beneficios de la especificación formal La especificación formal, a través del uso de lenguajes matemáticos precisos, ofrece una serie de ventajas cruciales en el desarrollo de software, especialmente en sistemas complejos y críticos donde la precisión y la confiabilidad son primordiales. Precisión y claridad: Elimina la ambigüedad inherente al lenguaje natural, donde las palabras pueden tener múltiples interpretaciones. Cada elemento en una especificación formal tiene un significado único y bien definido, lo que reduce drásticamente las posibilidades de malentendidos y errores de interpretación. Esto asegura que todos los involucrados en el proyecto, desde los clientes hasta los desarrolladores, compartan una comprensión común del sistema. Consistencia y completitud: Permite verificar rigurosamente que las diferentes partes de la especificación no se contradigan entre sí y que se cubran todos los casos posibles, incluso aquellos que podrían pasar desapercibidos en un diseño informal. Esto garantiza un comportamiento coherente del sistema en todas las situaciones. Verificación rigurosa: Facilita la aplicación de técnicas de verificación formal para comprobar matemáticamente que el sistema cumple con la especificación. Esta capacidad de demostrar la corrección del software aumenta la confianza en su funcionamiento, especialmente en sistemas críticos donde los fallos pueden tener consecuencias graves.  Reducción de errores: Al detectar errores en las etapas tempranas del desarrollo, se evitan costosas correcciones posteriores. La precisión de la especificación formal ayuda a identificar y resolver problemas antes de que se propaguen al código, ahorrando tiempo y recursos a largo plazo. Mayor confiabilidad: La rigurosidad matemática de la especificación formal aumenta la confianza en la corrección del software, lo que es esencial en sistemas críticos como los de control de tráfico aéreo, dispositivos médicos o sistemas financieros, donde los fallos pueden tener consecuencias catastróficas. Mejora de la mantenibilidad: Una especificación formal clara y precisa facilita la comprensión del sistema, lo que simplifica su mantenimiento y evolución. Sirve como una documentación de alta calidad que permite a los desarrolladores comprender, modificar y actualizar el sistema de manera más eficiente a lo largo de su ciclo de vida. Documentación de alta calidad: La especificación formal en sí misma sirve como una documentación precisa, completa y rigurosa del sistema. Esta documentación facilita la comunicación entre los miembros del equipo, la gestión del conocimiento y la toma de decisiones informadas durante el desarrollo y mantenimiento del software. Lenguajes de especificación formal En la búsqueda de la precisión y la confiabilidad en el desarrollo de software, se han creado diversos lenguajes de especificación formal. Cada uno de ellos, con sus propias características y enfoques, proporciona herramientas poderosas para describir y verificar sistemas complejos. A continuación, exploramos algunos de los lenguajes más destacados: Z: Basado en la teoría de conjuntos y la lógica de primer orden, Z utiliza una notación matemática rigurosa para describir el estado del sistema y las operaciones que lo modifican. Su enfoque en la precisión y la consistencia lo hace ideal para aplicaciones críticas como sistemas de control de tráfico aéreo, donde la seguridad es primordial. Z emplea "esquemas" para definir estructuras de datos y operaciones, ofreciendo una forma clara y concisa de modelar el comportamiento del sistema. VDM (Vienna Development Method): VDM emplea la lógica de predicados para especificar el comportamiento del sistema, haciendo hincapié en la verificación formal. Se utiliza en áreas donde la seguridad y la confiabilidad son cruciales, como en sistemas médicos o financieros. VDM permite definir  funciones y operaciones con precisión, y facilita la demostración de propiedades del sistema mediante pruebas matemáticas. Alloy: Con un enfoque en la lógica relacional, Alloy permite modelar sistemas como conjuntos de relaciones y analizar sus propiedades. Es particularmente útil para la verificación de sistemas concurrentes y distribuidos, donde la interacción entre componentes puede ser compleja. Alloy incluye un analizador automático que puede verificar propiedades del modelo y generar contraejemplos, lo que ayuda a identificar errores de diseño. Larch: Buscando el modularidad y la reusabilidad, Larch combina especificaciones algebraicas con aserciones en un lenguaje de programación. Este enfoque permite descomponer sistemas complejos en componentes más pequeños y manejables, facilitando su diseño, comprensión y mantenimiento. Larch se ha utilizado en la especificación de sistemas operativos, compiladores y bases de datos. TLA+: Basado en la lógica temporal y la teoría de conjuntos, TLA+ se centra en la descripción del comportamiento de sistemas concurrentes y distribuidos. Se utiliza en la verificación de protocolos y algoritmos distribuidos, donde la sincronización y la comunicación entre procesos son críticas. TLA+ permite modelar el sistema como una "máquina de estados" y verificar propiedades temporales, como la ausencia de interbloqueos o la corrección de la secuencia de eventos. Método B: Este método se basa en el concepto de "máquinas abstractas" y el refinamiento paso a paso para construir sistemas con un alto nivel de seguridad. Comienza con una especificación abstracta del sistema y la refina gradualmente hasta llegar a una implementación concreta, garantizando la corrección en cada etapa. El Método B se utiliza en sistemas embebidos, sistemas de transporte y aplicaciones financieras, donde la confiabilidad es esencial. Limitaciones de la especificación formal Si bien la especificación formal ofrece ventajas significativas en el desarrollo de software, su aplicación también presenta desafíos que es importante considerar: Curva de aprendizaje: Requiere un conocimiento sólido de lenguajes y técnicas matemáticas, como la lógica de predicados, la teoría de conjuntos o el álgebra relacional. Esto puede ser desafiante para algunos desarrolladores, quienes podrían necesitar capacitación adicional para adquirir las habilidades necesarias. Invertir en la formación del equipo en métodos formales es crucial para el éxito de su aplicación. Costo inicial: La creación de una especificación formal puede requerir más tiempo y esfuerzo en la etapa inicial del desarrollo en comparación con métodos informales. Es necesario analizar cuidadosamente si los beneficios a largo plazo justifican la inversión inicial, especialmente en proyectos con recursos limitados o plazos ajustados. Complejidad: Para sistemas grandes y complejos, la especificación formal puede volverse difícil de manejar. La cantidad de detalles y la complejidad de las interacciones pueden hacer que la especificación sea extensa y difícil de comprender, incluso para expertos. Se deben utilizar estrategias de modularidad y abstracción para controlar la complejidad y facilitar el mantenimiento de la especificación. Herramientas limitadas: Aunque existen herramientas para la especificación y verificación formal, su disponibilidad y madurez pueden variar según el lenguaje de especificación elegido. Es importante evaluar las herramientas disponibles y su integración con el entorno de desarrollo antes de adoptar un enfoque formal. Falta de experiencia: La especificación formal no es una práctica generalizada en la industria del software. Encontrar profesionales con experiencia en métodos formales puede ser difícil, lo que puede dificultar la adopción de esta técnica en algunos equipos. Mitigando las limitaciones A pesar de estos desafíos, existen estrategias para mitigar las limitaciones de la especificación formal: Capacitación y formación: Invertir en la capacitación del equipo en lenguajes y técnicas de especificación formal es esencial. Herramientas adecuadas: Seleccionar herramientas que faciliten la creación, el análisis y la verificación de la especificación puede mejorar la productividad y reducir la complejidad. Enfoque gradual: Comenzar con la especificación formal de partes críticas del sistema y expandir gradualmente su uso a medida que el equipo adquiere experiencia. Modularidad y abstracción: Dividir el sistema en módulos más pequeños y manejables y utilizar técnicas de abstracción para ocultar detalles innecesarios puede simplificar la especificación. Aplicaciones de la especificación formal La especificación formal desempeña un papel crucial en varias áreas críticas de la ingeniería de software, en particular en sistemas críticos para la seguridad. En dominios como el aeroespacial, el automotriz y los dispositivos médicos, donde las fallas del sistema pueden tener consecuencias graves, los métodos formales son esenciales para garantizar la seguridad y la confiabilidad. Por ejemplo, la NASA emplea métodos formales para verificar el software para misiones espaciales, donde cualquier falla podría resultar en la pérdida de misiones y equipos valiosos. De manera similar, los fabricantes de dispositivos médicos utilizan métodos formales para garantizar la seguridad y la corrección de sus productos. La especificación formal también beneficia el desarrollo de sistemas de software complejos. Al proporcionar un modelo claro y preciso del comportamiento del sistema, los métodos formales ayudan a gestionar la complejidad de sistemas grandes e intrincados. Este enfoque es valioso para sistemas empresariales de gran escala y sistemas distribuidos, donde la coherencia y la fiabilidad son cruciales. Ejemplo: Sistema de cuenta bancaria simple Queremos especificar un sistema de cuenta bancaria simple que admite operaciones básicas: depósito, retiro y consulta de saldo. Definir los tipos de datos En Z, comenzamos definiendo los tipos de datos y las variables que utilizará nuestro sistema. Para este ejemplo, definiremos un tipo de datos para la cantidad de dinero y un tipo de datos para la cuenta bancaria en sí. [ Cantidad ] // Un tipo de datos básico para representar la cantidad de dinero Aquí, Amount representa una cantidad genérica de dinero. Definir el esquema de estado A continuación, definimos el esquema de estado de nuestra cuenta bancaria. Este esquema describe el estado del sistema, incluidas las variables que almacenan el saldo de la cuenta. Saldo de la cuenta bancaria : Monto // El saldo de la cuenta bancaria En este esquema, BankAccount tiene una variable, balance, que contiene el saldo actual de la cuenta. Definir operaciones Ahora, especificamos las operaciones que se pueden realizar en la cuenta bancaria: Deposit, Withdraw, y CheckBalance. Operación de depósito: Depósito ΔCuentaBancaria // Esta operación cambia el estado de la CuentaBancaria amount?: Amount // El monto a depositar // El saldo después del depósito 'saldo' = saldo + importe? En esta operación, indica que se modifica ΔBankAccount el estado de. representa el importe del depósito. La condición posterior especifica que el nuevo saldo ( ) es el saldo anterior más el importe depositado. BankAccountamount?balance' = balance + amount?balance' Operación de retiro Retirar ΔCuentaBancaria // Esta operación cambia el estado de la CuentaBancaria amount?: Amount // El monto a retirar // El saldo debe ser suficiente para el retiro saldo ≥ monto? saldo' = saldo - monto? Para la Withdraw operación, ΔBankAccount indica que modifica el estado. amount? representa el monto del retiro. La condición previa balance ≥ amount? asegura que el saldo sea suficiente para el retiro. La condición posterior balance' = balance - amount? especifica que el nuevo saldo ( balance') es el saldo anterior menos el monto retirado. Operación de Consulta de Saldo CheckBalance BankAccount // Esta operación no cambia el saldo del estado: Monto // Devuelve el saldo actual La CheckBalance operación no modifica el estado ( BankAccount) y simplemente devuelve el saldo actual.  Referencias Bibliográficas Lucidchart. (s. f.). Tutorial de diagrama de clases UML. Recuperado el 23 de enero de 2025, de https://www.lucidchart.com/pages/es/tutorial-de-diagrama-de-clases-uml Miro. (s. f.). Diagrama de clases: Qué es, cómo hacerlo y ejemplos. Recuperado el 23 de enero de 2025, de https://miro.com/es/diagrama/que-es-diagrama-clases-uml/ Venngage. (s. f.). Cómo crear un diagrama de clases [+Ejemplos]. Recuperado el 23 de enero de 2025, de https://es.venngage.com/blog/diagrama-de-clases/ ClickUp. (s. f.). Ejemplos de diagramas UML para el diseño de proyectos de software. Recuperado el 23 de enero de 2025, de https://clickup.com/es- ES/blog/238455/ejemplos-de-diagramas-uml Edrawsoft. (s. f.). Ejemplos de Diagrama de Clases UML - EdrawMax. Recuperado el 23 de enero de 2025, de https://www.edrawsoft.com/es/example-uml-class-diagram.html  UNIVERSIDAD DE GUAYAQUIL DISEÑO DE SOFTWARE TAREA: ATRIBUTOS DE DISEÑO MÉTRICAS DE DISEÑO ESTUDIANTES: GUTIERREZ PAREDES ANDY LUIS GALARZA RUGEL DIEGO FRANCISCO GELVEZ PIN JONATHAN DAVID SALAZAR FIALLO MIGUEL FACULTAD DE CIENCIAS, MATEMÁTICAS Y FÍSICA CARRERA: SOTFWARE  ATRIBUTOS DE DISEÑOS Los atributos de diseño en la arquitectura de software son propiedades medibles que determinan la calidad y el comportamiento de un sistema. Estos atributos son fundamentales para asegurar que el software cumpla con las expectativas de los usuarios y los requisitos del negocio. A continuación, se presenta un contexto teórico, ventajas y desventajas, características, y ejemplos prácticos que ilustran el uso de estos atributos. Contexto Teórico Los atributos de diseño se consideran como requerimientos no funcionales, lo que significa que no están directamente relacionados con las funciones específicas del software, sino con cómo se comporta y se siente. Según la norma ISO/IEC 25010, algunos de los atributos más importantes incluyen: Rendimiento El rendimiento se refiere a la capacidad del sistema para ejecutar sus funciones dentro de límites de tiempo aceptables. Esto incluye aspectos como la velocidad de procesamiento, la capacidad de respuesta y la utilización eficiente de recursos. Características Latencia: Tiempo que tarda el sistema en responder a una solicitud. Throughput: Cantidad de datos procesados en un periodo determinado. Uso de recursos: Eficiencia en el uso de CPU, memoria y otros recursos. Ejemplo Práctico En un sistema de comercio electrónico, el rendimiento es crucial durante períodos de alta demanda, como el Black Friday. Un buen rendimiento asegura que los usuarios puedan navegar y realizar compras sin retrasos significativos. Escalabilidad La escalabilidad es la capacidad del sistema para manejar un aumento en la carga de trabajo sin degradar su rendimiento. Esto puede lograrse mediante escalado vertical (mejorando hardware) o escalado horizontal (agregando más máquinas). Características Escalabilidad vertical: Aumentar los recursos en una sola máquina.  Escalabilidad horizontal: Añadir más máquinas al sistema. Adaptabilidad a cambios: Capacidad para ajustarse a nuevas demandas sin reestructuración significativa. Ejemplo Práctico Un servicio de streaming como Netflix debe ser escalable para soportar millones de usuarios simultáneamente, especialmente durante el lanzamiento de nuevas series o películas. Mantenibilidad La mantenibilidad se refiere a la facilidad con la que se puede modificar el software para corregir defectos, mejorar su rendimiento o adaptarlo a cambios en el entorno operativo. Características Modularidad: Diseño del software en componentes independientes. Documentación clara: Facilita la comprensión del código por parte de nuevos desarrolladores. Facilidad para realizar pruebas: Permite verificar cambios sin afectar otras partes del sistema. Ejemplo Práctico En una aplicación bancaria, la mantenibilidad es esencial para actualizar regulaciones o implementar nuevas funcionalidades sin interrumpir el servicio existente. Seguridad La seguridad se refiere a las medidas implementadas para proteger el software contra accesos no autorizados y ataques maliciosos. Esto incluye la protección de datos sensibles y la garantía de que solo los usuarios autorizados puedan acceder a ciertas funcionalidades. Características Autenticación: Verificación de identidad del usuario. Autorización: Control sobre qué recursos puede acceder un usuario. Cifrado: Protección de datos sensibles mediante técnicas criptográficas. Ejemplo Práctico En aplicaciones financieras, como PayPal, la seguridad es primordial para proteger las transacciones y datos personales de los usuarios contra fraudes y robos. Usabilidad La usabilidad se refiere a la facilidad con la que los usuarios pueden interactuar con el sistema. Un software con buena usabilidad permite a los usuarios completar sus tareas de manera eficiente y efectiva. Características: Intuitividad: El sistema debe ser fácil de entender y usar. Accesibilidad: Debe ser accesible para todos los usuarios, incluyendo aquellos con discapacidades. Satisfacción del usuario: Los usuarios deben sentirse cómodos y satisfechos al usar el sistema. Ejemplo Práctico: Una aplicación de banca en línea que permite a los usuarios realizar transacciones fácilmente, con un diseño claro y opciones accesibles. Fiabilidad La fiabilidad se refiere a la capacidad del sistema para funcionar de manera consistente y correcta bajo condiciones específicas durante un período determinado. Características: Tolerancia a fallos: Capacidad para continuar operando incluso cuando ocurren errores. Recuperación: Capacidad para recuperarse rápidamente de fallos. Consistencia: El sistema debe producir resultados confiables en diferentes ejecuciones. Ejemplo Práctico: Un sistema de gestión de vuelos que garantiza que la información sobre horarios y disponibilidad sea precisa y esté actualizada en todo momento. Portabilidad La portabilidad es la facilidad con la que un software puede ser transferido de un entorno a otro. Esto incluye la capacidad para ejecutarse en diferentes plataformas o sistemas operativos. Características: Adaptabilidad a diferentes entornos: El software debe poder ejecutarse en diversas configuraciones sin necesidad de modificaciones significativas. Instalación sencilla: Debe ser fácil de instalar en diferentes sistemas. Ejemplo Práctico: Una aplicación web que funciona sin problemas tanto en navegadores de escritorio como en dispositivos móviles, garantizando una experiencia consistente para todos los usuarios. Interoperabilidad La interoperabilidad se refiere a la capacidad del software para interactuar y funcionar con otros sistemas o aplicaciones. Esto es crucial en entornos donde múltiples sistemas deben comunicarse entre sí. Características: Intercambio de datos: Capacidad para compartir información con otros sistemas. Compatibilidad: Debe ser capaz de trabajar con estándares abiertos y protocolos comunes. Ejemplo Práctico: Un sistema de gestión hospitalaria que puede intercambiar datos con otros sistemas médicos, permitiendo un acceso fluido a la información del paciente entre diferentes instituciones. Ventajas y Desventajas Ventajas Mejora la calidad del software: Al enfocarse en atributos como rendimiento y seguridad, se puede crear un software más robusto. Facilita la toma de decisiones: Proporciona criterios claros para elegir tecnologías y patrones arquitectónicos. Aumenta la satisfacción del usuario: Un software bien diseñado satisface mejor las necesidades de los usuarios. Desventajas Puede incrementar costos: La implementación de ciertos atributos puede requerir más tiempo y recursos. Dificultad en la medición: Algunos atributos son difíciles de cuantificar y evaluar objetivamente. Conflictos entre atributos: A veces, mejorar un atributo puede afectar negativamente a otro (por ejemplo, aumentar la seguridad puede reducir la usabilidad). Características Los atributos de diseño son:  Medibles: Se pueden evaluar mediante métricas específicas. Interrelacionados: Cambios en un atributo pueden afectar a otros. Contextuales: Su importancia puede variar seg