Segundo Parcial ISO PDF

Resumen Ingeniería de Software I – Segundo parcial Calidad En el desarrollo de so+ware, la calidad no es un atributo que se da por sentado; debe ser planificada, monitoreada y controlada. Pressman describe un enfoque sistemá=co para garan=zar que los productos de so+ware cumplan con los requisitos d...

Resumen Ingeniería de Software I – Segundo parcial Calidad En el desarrollo de so+ware, la calidad no es un atributo que se da por sentado; debe ser planificada, monitoreada y controlada. Pressman describe un enfoque sistemá=co para garan=zar que los productos de so+ware cumplan con los requisitos de calidad esperados. A través del aseguramiento de la calidad (QA) y el control de la calidad (QC), las organizaciones se aseguran de que el so+ware no solo funcione correctamente, sino que también sa=sfaga las expecta=vas del cliente y sea confiable en diversos contextos. Además, el planeamiento de la calidad implica definir cómo se implementarán estos principios de manera efec=va a lo largo del ciclo de vida del proyecto. Aseguramiento de la calidad y estándares de calidad El aseguramiento de la calidad (QA) consiste en establecer procedimientos y estándares que aseguren que los productos de so+ware se desarrollen correctamente desde el principio. QA busca prevenir defectos mediante la implementación de procesos estandarizados y auditorías. Los estándares de calidad proporcionan las bases para definir lo que se considera "calidad" en un contexto específico. § Definición: Ac=vidades y prác=cas para prevenir errores en el desarrollo de so+ware, enfocándose en el proceso en vez del producto final. § Enfoque: Proac=vo y preven=vo, mejora el proceso para evitar defectos. § Estándares de calidad: Guían el desarrollo según criterios de funcionalidad, seguridad y rendimiento. Planeamiento de la calidad El planeamiento de la calidad abarca la definición de los procedimientos, herramientas y ac=vidades necesarias para garan=zar que el so+ware cumpla con los requisitos establecidos. Incluye la planificación de revisiones, auditorías y métricas que guiarán el proceso de desarrollo para que sea consistente con los estándares de calidad. 1. Obje=vos de calidad: Expecta=vas en funcionalidad, rendimiento y seguridad. 2. Métodos y herramientas de QA: Pruebas de integración, revisiones de código, etc. 3. Procedimientos de auditoría: Revisiones para cumplimiento de estándares. 4. Criterios de aceptación: Condiciones para avanzar en el desarrollo. 5. Plan de pruebas: Cronograma y estrategia de pruebas. Control de la calidad y normas de calidad El control de la calidad (QC) se centra en la iden=ficación y corrección de defectos en el so+ware, a través de ac=vidades como pruebas y revisiones. Mientras que QA es preven=vo, QC es reac=vo, y ambos son complementarios. Las normas de calidad, como ISO/IEC 25010, brindan guías específicas sobre cómo medir y mantener la calidad en diferentes dimensiones. Las revisiones técnicas formales son una parte crucial de este proceso, ya que permiten evaluar el so+ware en las primeras etapas y detectar problemas antes de que se conviertan en errores crí=cos. § Definición: Proceso reac=vo para detectar y corregir errores en el producto final o fases avanzadas. § Enfoque: Correc=vo, asegurando que el so+ware cumpla con los requisitos antes de la entrega. § Diferencia QA vs. QC: QA se orienta al proceso, QC al producto. Los conceptos de calidad de so+ware se abordan principalmente desde dos perspec=vas clave: la calidad del producto y la calidad del proceso. Normas de Calidad en QA § ISO/IEC 25010: Modelo de calidad que evalúa funcionalidad, seguridad y eficiencia. § ISO 9001: Principios generales de ges=ón aplicables al desarrollo de so+ware. § CMMI: Modelo para mejorar la madurez y ges=ón de procesos en proyectos. Ac=vidades de Control de Calidad (QC) § Pruebas unitarias: Verificación de módulos individuales. § Pruebas de integración: Validación de interacción entre módulos. § Revisión de código: Inspección para mejorar eficiencia y estándares. § Pruebas de sistema: Evaluación de todo el sistema en su entorno. § Pruebas de aceptación: Validación final con cliente o usuarios antes de implementación. Estas ac=vidades aseguran la estabilidad, funcionalidad y ausencia de errores crí=cos en el so+ware antes de su lanzamiento. Pressman describe la calidad del producto de so+ware como el conjunto de caracterís=cas que determinan si el so+ware cumple con los requerimientos, especificaciones y expecta=vas del usuario. Estas caracterís=cas incluyen: 1. Funcionalidad 2. Fiabilidad 3. Eficiencia 4. Mantenibilidad 5. Usabilidad 6. Seguridad 7. Portabilidad § Funcionalidad: El grado en que el so+ware sa=sface los requisitos definidos y sus capacidades, § como la corrección y adecuación. § Fiabilidad (Reliability): Se refiere a la capacidad del so+ware para mantener su nivel de rendimiento bajo § condiciones específicas durante un =empo determinado. Pressman lo describe como la estabilidad del so+ware, § la ausencia de fallos y su capacidad de recuperación. § Eficiencia: Está relacionada con el rendimiento del so+ware en el uso de los recursos del sistema, § como el =empo de procesamiento, la memoria y el uso de recursos computacionales. § Mantenibilidad: Enfa=za la facilidad con la que se pueden realizar modificaciones § para corregir errores, mejorar el rendimiento o adaptarse a cambios en el entorno. § Esto incluye la modularidad, reusabilidad y analizabilidad. § Usabilidad: Es el grado en que el so+ware puede ser u=lizado por los usuarios con facilidad y sa=sfacción. § Pressman enfa=za la importancia de hacer interfaces de usuario comprensibles, fáciles de aprender § y efec=vas para que los usuarios logren sus obje=vos. § Portabilidad: La capacidad del so+ware para ser transferido de un entorno a otro, lo que incluye su adaptabilidad § y facilidad para ser instalado en diferentes plataformas. § Seguridad: Pressman menciona la seguridad como un aspecto importante de la calidad, dado que el so+ware § debe proteger los datos y prevenir accesos no autorizados o comportamientos maliciosos. La calidad del proceso se refiere a los métodos, procedimientos y herramientas u=lizadas para desarrollar el so+ware. Algunos de los aspectos clave incluyen: § Cumplimiento con estándares: Asegurarse de que los procesos de desarrollo sigan estándares y buenas prác=cas, como los definidos en modelos de calidad como CMMI o ISO/IEC 12207. § Revisión y auditoría: La realización de revisiones con=nuas y auditorías durante el desarrollo del so+ware para asegurar que los productos intermedios cumplen con los requisitos de calidad. § Medición de la calidad: Pressman sugiere medir la calidad en todo momento, a través de métricas, tanto del producto (como defectos por cada mil líneas de código) como del proceso (como =empos de ciclo de desarrollo). Agilidad en el Desarrollo de So0ware La agilidad en el desarrollo de so+ware es un enfoque que prioriza la capacidad de adaptación rápida y eficiente ante los cambios, la colaboración entre los equipos y los clientes, y la entrega con=nua de valor. Surgió a principios de los años 2000 como una respuesta a las metodologías tradicionales, como el modelo en cascada, que resultaban rígidas y dificultaban la respuesta ágil ante requerimientos cambiantes y entornos inciertos. El Manifiesto Ágil, publicado en 2001 por un grupo de desarrolladores y expertos en so+ware, estableció los principios fundamentales que guían este enfoque. Los cuatro valores centrales del manifiesto son: 1. Individuos e interacciones sobre procesos y herramientas. 2. So+ware funcional sobre documentación extensa. 3. Colaboración con el cliente sobre negociación de contratos. 4. Respuesta ante el cambio sobre seguir un plan rígido. Principios de la Agilidad El desarrollo ágil se basa en una serie de principios que permiten a los equipos crear so+ware de manera itera=va e incremental, promoviendo la flexibilidad y la mejora con=nua. Algunos de los principios clave incluyen: Entregas tempranas y frecuentes: La agilidad favorece la entrega con=nua de versiones funcionales del so+ware en cortos periodos de =empo, conocidos como iteraciones o sprints, lo que permite a los equipos recibir retroalimentación constante. Adaptación al cambio: En lugar de seguir un plan fijo desde el inicio, los equipos ágiles están preparados para ajustar el alcance, los requisitos y las prioridades a medida que surgen nuevas necesidades o desahos. Colaboración cercana con el cliente: El cliente está involucrado ac=vamente durante todo el proceso de desarrollo, lo que garan=za que el producto final se ajuste a sus necesidades reales y evolucione con sus expecta=vas. Equipos autoorganizados y mul=funcionales: En lugar de depender de una estructura jerárquica, los equipos ágiles se autoorganizan y son responsables de la planificación, ejecución y entrega de cada iteración. Mejora con=nua: Al final de cada iteración, el equipo reflexiona sobre lo que salió bien y qué puede mejorarse, ajustando procesos y prác=cas para el siguiente ciclo de trabajo. Metodologías Ágiles Existen varias metodologías que adoptan los principios ágiles. Entre las más populares se encuentran: Scrum: Un marco que divide el trabajo en sprints de duración fija (generalmente entre 2 y 4 semanas). Los equipos realizan reuniones diarias llamadas daily stand-ups para coordinarse, y al final de cada sprint se realiza una revisión del progreso. Kanban: Un sistema visual de ges=ón de tareas que ayuda a los equipos a mejorar su flujo de trabajo, limitar el trabajo en progreso y centrarse en la entrega con=nua. Extreme Programming (XP): Enfocado en la mejora con=nua de la calidad del so+ware y las buenas prác=cas de desarrollo, como la programación en pareja y las pruebas automá=cas. Impacto de la Agilidad en el Desarrollo de So+ware La agilidad ha transformado la forma en que las organizaciones desarrollan y entregan so+ware. Algunas de las ventajas más destacadas incluyen: Mayor capacidad de respuesta: Al permi=r cambios en los requisitos durante el desarrollo, los equipos ágiles pueden adaptarse rápidamente a las demandas del mercado y de los clientes. Reducción de riesgos: Al entregar versiones funcionales del so+ware de manera frecuente, los problemas pueden detectarse y resolverse temprano en el ciclo de desarrollo. Sa=sfacción del cliente: La colaboración cercana con el cliente y la capacidad de incorporar su retroalimentación de manera con=nua aseguran que el producto final cumpla con sus expecta=vas. Origen y Fundamentos de la Agilidad El desarrollo ágil surgió en los años 90 y principios de los 2000 debido a las limitaciones de metodologías tradicionales, como el modelo en cascada, que generaban proyectos de so+ware con retrasos, sobrecostos y fracasos. En 2001, 17 desarrolladores crearon el Manifiesto Ágil en Utah, proponiendo un enfoque flexible que priorizara la colaboración, el feedback constante y la adaptabilidad a cambios. Este manifiesto se basa en cuatro valores: § Valorar individuos e interacciones sobre procesos y herramientas. § So+ware funcionando sobre documentación extensiva. § Colaboración con el cliente sobre negociación contractual. § Respuesta ante el cambio sobre seguir un plan. Problemas antes de la Agilidad Antes de la agilidad, los proyectos de so+ware frecuentemente no cumplían con las expecta=vas del cliente debido a la falta de flexibilidad de las metodologías tradicionales, que no permiman adaptarse a cambios en los requisitos. Esto generaba productos que no respondían a las necesidades actuales del mercado y elevaba el riesgo de fallos en los proyectos. Principales Metodologías Ágiles Scrum: Organiza el trabajo en ciclos cortos (sprints) y promueve la autoorganización. Kanban: Basa el trabajo en un flujo con=nuo visual, con límites en tareas ac=vas. Extreme Programming (XP): Enfoca la calidad del código y la colaboración con=nua. Roles Específicos en Scrum Scrum Master: Facilita el proceso ágil y ayuda a resolver obstáculos. Product Owner: Representa al cliente y prioriza tareas según su valor. Development Team: Desarrolla el producto colabora=vamente. Implementación en la Industria Empresas como Google y Amazon usan agilidad en todos los niveles para responder rápidamente a cambios de mercado. Sin embargo, la adopción ágil puede enfrentar resistencia cultural y requiere ajustar roles y prác=cas organiza=vas. Medición del Éxito Ágil El éxito en agilidad se mide por la entrega de valor con=nuo, usando métricas como la velocidad del equipo, la tasa de finalización de tareas y el feedback del cliente, priorizando la adaptación y obje=vos a corto plazo sobre planes fijos. Agilidad y Calidad del So+ware La agilidad mejora la calidad del so+ware mediante iteraciones y retroalimentación constante con el cliente. La integración con=nua y las pruebas automa=zadas aceleran el desarrollo y mejoran la estabilidad del producto. Cultura Organizacional en la Agilidad La agilidad fomenta la colaboración, autoorganización y una estructura horizontal en el equipo, promoviendo reuniones periódicas de revisión (stand-ups, retrospec=vas) para impulsar mejoras y adaptaciones constantes. Adaptación y Flexibilidad La agilidad es ideal para proyectos con incer=dumbre o cambios frecuentes en requisitos. Sin embargo, para proyectos grandes se u=lizan marcos de escalado como SAFe o LeSS, que man=enen los principios ágiles a gran escala. Crí=cas y Limitaciones Las crí=cas a la agilidad incluyen falta de documentación y sobrecarga de reuniones. Para proyectos regulados, suelen usarse metodologías híbridas (e.g., Agile-Waterfall) para cumplir con requisitos estrictos sin perder flexibilidad. Agilidad en Sectores no Tecnológicos Áreas como marke=ng y recursos humanos adoptan la agilidad para ges=onar cambios constantes en entornos de alta incer=dumbre, usando una planificación flexible y entregas de valor que no siempre son productos tangibles. Sa=sfacción del Equipo La autonomía en los equipos ágiles mo=va y compromete al personal, aunque requiere altos niveles de comunicación y cooperación, lo que puede ser desafiante en organizaciones con estructuras rígidas. Retos en la Transformación Ágil La adopción ágil implica un cambio de mentalidad organizacional, especialmente en estructuras jerárquicas. La capacitación y la implementación de proyectos piloto exitosos son esenciales para superar la resistencia al cambio. Medición de la Efec=vidad Ágil Las métricas clave en agilidad incluyen la velocidad de sprints, Lead Time, sa=sfacción del cliente y calidad del producto, que evalúan tanto la produc=vidad como la alineación del equipo con los obje=vos del cliente. Aprendizaje Con=nuo La agilidad fomenta la mejora con=nua a través de retrospec=vas regulares, permi=endo ajustes en cada ciclo para incrementar la eficiencia y calidad del proceso y del producto. Evolución y Futuro de la Agilidad La agilidad ha evolucionado, integrándose con otras disciplinas, como DevOps, que combina desarrollo y operaciones para lograr una entrega con=nua. La agilidad sigue siendo un enfoque adaptable, aplicable en diversos sectores y proyectos, incluso en contextos no tecnológicos. Teoría General de los sistemas Roger Pressman, en su obra sobre ingeniería de so+ware, u=liza conceptos de la Teoría General de Sistemas para abordar la inspección de sistemas de so+ware, enfocándose en cómo los componentes de so+ware interactúan y cómo estas interacciones pueden evaluarse y mejorarse. Según Pressman, algunos conceptos clave son: Sistema como conjunto de componentes interdependientes: Pressman describe el so+ware como un sistema compuesto de módulos y componentes que interactúan para cumplir obje=vos específicos. Las inspecciones son fundamentales para iden=ficar problemas de integración y asegurar que cada componente funcione correctamente dentro del sistema en su conjunto. Obje=vos y beneficios de las inspecciones de so+ware: Explica cómo las inspecciones permiten encontrar errores temprano en el desarrollo, lo cual ayuda a reducir costos y mejora la calidad. También puedes mencionar cómo, desde la perspec=va de la TGS, las inspecciones sirven para mantener la coherencia y funcionalidad del sistema completo. Proceso de inspección en ingeniería de so+ware: Detalla los pasos mpicos en una inspección formal, incluyendo la planificación, preparación, reunión de inspección, revisión de hallazgos y el seguimiento. Cada paso se puede relacionar con los principios de la TGS, enfa=zando cómo una revisión me=culosa contribuye a la armonía del sistema global. Entropía y control de calidad: Explora el concepto de entropía aplicado al so+ware, que se refiere al desorden que puede generarse a medida que el sistema evoluciona y cambia. Las inspecciones permiten mi=gar esta entropía, asegurando que el sistema se mantenga ordenado y controlado. Tipos de inspecciones y revisiones: Describe diferentes =pos de inspecciones, como la revisión de código, inspecciones de diseño, revisiones de requisitos, y cómo cada una aborda dis=ntos aspectos del sistema desde la TGS, garan=zando que cada parte funcione dentro del todo. Retroalimentación y mejora con=nua: En la TGS, la retroalimentación permite al sistema adaptarse y mejorar. En las inspecciones de so+ware, esta retroalimentación se da a través de los reportes de errores, permi=endo ajustar y mejorar los procesos de desarrollo de forma con=nua. Interdependencia de los componentes: Profundiza en cómo cada componente del so+ware depende de los demás para cumplir con el obje=vo del sistema en su conjunto. La TGS enfa=za la interrelación entre componentes, y Pressman u=liza las inspecciones para asegurarse de que todos los módulos colaboren de manera efec=va. Roles y responsabilidades en las inspecciones: Explica los roles mpicos en una inspección (moderador, autor, lector, etc.) y cómo cada uno contribuye a la evaluación del sistema. Estos roles garan=zan que la revisión sea completa y minuciosa, asegurando la efec=vidad y adaptabilidad del sistema. Métricas de inspección y análisis de defectos: Introduce métricas que suelen u=lizarse para evaluar la eficacia de una inspección, como la tasa de defectos encontrados, el =empo de inspección, etc. Relaciona esto con la TGS y cómo medir el rendimiento del sistema y sus componentes ayuda a mantener el sistema en equilibrio. Inspección como mecanismo de aprendizaje: Las inspecciones también ayudan a los equipos a aprender y mejorar sus prác=cas de desarrollo. Según la TGS, este proceso con=nuo de aprendizaje y ajuste permite al sistema (el equipo) evolucionar y mejorar. Teoría General de los Sistemas (TGS): Es un enfoque interdisciplinario que estudia los sistemas en general, entendidos como conjuntos de elementos interrelacionados. La TGS busca entender cómo funcionan, se organizan y evolucionan los sistemas, aplicándose en diversas áreas, como la biología, la economía y la ingeniería. Sistema: Es un conjunto de componentes que interactúan entre sí para lograr un obje=vo común. Cada componente =ene una función específica, y su interdependencia permite que el sistema funcione como un todo cohesionado. Sistema de Información: Es un =po de sistema que recopila, procesa, almacena y distribuye información para apoyar la toma de decisiones, la coordinación y el control en una organización. Combina tecnología, personas y procesos para ges=onar datos de manera eficiente. So+ware: Es el conjunto de programas, instrucciones y datos que le indican a una computadora cómo realizar tareas específicas. Incluye sistemas opera=vos, aplicaciones y herramientas que permiten a los usuarios ejecutar diversas funciones en disposi=vos electrónicos. El so+ware es intangible, en contraste con el hardware, que es la parte hsica del sistema. Sistemas de la información La definición de Sistemas de Información (SI) se centra en los componentes y procesos que permiten la recopilación, almacenamiento, procesamiento y distribución de información dentro de una organización para facilitar la toma de decisiones, coordinar ac=vidades y controlar procesos. Un sistema de información es un conjunto de recursos interrelacionados, que incluye personas, datos, procesos, tecnología y infraestructura, organizados para cumplir obje=vos específicos. Los SI integran el uso de tecnología, como bases de datos, so+ware y redes de comunicación, junto con procedimientos y roles que aseguran el flujo de información de manera precisa y oportuna. Desde la perspec=va de la Teoría General de Sistemas (TGS), los Sistemas de Información son vistos como un conjunto de componentes interdependientes que, en su conjunto, permiten el procesamiento y el flujo de datos para que el sistema organizacional cumpla con su propósito. Los SI no solo procesan información, sino que también facilitan la toma de decisiones estratégicas, tác=cas y opera=vas en las organizaciones. Componentes principales de los Sistemas de Información § Personas: Son los usuarios finales y administradores que interactúan y ges=onan el sistema. Son clave en el funcionamiento y en la interpretación de los datos. § Datos: Cons=tuyen la base de cualquier sistema de información. Incluyen toda la información bruta que, una vez procesada, se convierte en información ú=l. § Hardware: Comprende los componentes hsicos, como servidores, computadoras, redes y otros disposi=vos, que facilitan el procesamiento y el almacenamiento de datos. § So+ware: Incluye todas las aplicaciones y programas que procesan los datos para conver=rlos en información ú=l. Esto abarca desde sistemas opera=vos hasta aplicaciones empresariales especializadas. § Redes y comunicación: Permiten la conexión entre los diferentes componentes del sistema y facilitan el intercambio de información entre diferentes usuarios y ubicaciones. § Procesos: Son los métodos y las reglas que determinan cómo se recopilan, almacenan y u=lizan los datos. Estos procesos definen la estructura y opera=va del sistema de información. Importancia de los Sistemas de Información Los SI son esenciales para cualquier organización, ya que: § Facilitan el flujo eficiente de información entre diferentes áreas y niveles de la organización. § Ayudan en la toma de decisiones al proporcionar datos relevantes y procesados a los responsables. § Permiten el almacenamiento y recuperación de datos, lo cual es esencial para la con=nuidad del negocio y para la creación de valor a largo plazo. § Automa=zan procesos ru=narios, lo que mejora la eficiencia y permite a los empleados enfocarse en tareas de mayor valor. § Mejoran la comunicación y la colaboración, tanto interna como externamente, entre socios, proveedores y clientes. En los Sistemas de Información (SI), los conceptos de privacidad, integridad y seguridad son fundamentales para garan=zar que los datos se manejen de forma segura, confiable y conforme a los derechos de los usuarios. Estos tres conceptos son esenciales para proteger los recursos de información y mantener la confianza en el sistema. A con=nuación se describen cada uno de ellos en detalle: Privacidad La privacidad en los Sistemas de Información se refiere a la protección de la información personal y sensible contra accesos no autorizados. Este concepto garan=za que solo las personas autorizadas puedan acceder a datos confidenciales, cumpliendo con norma=vas de privacidad y derechos individuales.  § Confidencialidad de los datos: La privacidad implica que los datos de los usuarios y de la empresa se manejen de acuerdo con las polí=cas de confidencialidad. Esto asegura que la información personal no sea divulgada sin permiso. § Cumplimiento legal: Existen regulaciones, como el GDPR en Europa o la Ley de Protección de Datos Personales en muchos países, que establecen estándares estrictos para garan=zar la privacidad de los usuarios. § Minimización de datos: Solo se recopila la can=dad mínima de datos necesaria para cumplir el propósito del sistema, evitando la recopilación excesiva que puede poner en riesgo la privacidad. Integridad La integridad en los Sistemas de Información se refiere a la precisión y consistencia de los datos en el sistema a lo largo del =empo. Este concepto garan=za que la información sea fiable y que los datos no se alteren de forma no autorizada. § Exac=tud de los datos: La integridad asegura que los datos se mantengan correctos y sin errores desde el momento de su recopilación hasta su eliminación. § Protección contra alteraciones: Esto incluye proteger los datos frente a modificaciones no autorizadas o accidentales, lo que se consigue mediante controles de acceso, auditorías y mecanismos de verificación. § Consistencia y verificación: Los datos deben mantenerse coherentes en todos los módulos del sistema y a lo largo del ciclo de vida de la información, lo que permite que las decisiones basadas en estos datos sean precisas y confiables. Seguridad La seguridad en los Sistemas de Información se centra en proteger el sistema y los datos contra amenazas que puedan comprometer la privacidad o la integridad. Incluye prác=cas y tecnologías que previenen accesos no autorizados, uso indebido, o destrucción de los datos y recursos del sistema. § Control de acceso: La seguridad incluye la implementación de permisos de usuario y auten=cación robusta, como contraseñas fuertes, auten=cación de múl=ples factores y permisos de acceso según el rol de cada usuario. § Protección contra amenazas externas: Esto incluye medidas contra ataques ciberné=cos como malware, phishing, y hacking, implementando firewalls, cifrado y sistemas de detección de intrusos. § Resiliencia y con=nuidad del sistema: La seguridad también implica planes de recuperación ante desastres y copias de seguridad que permitan restaurar el sistema y los datos en caso de pérdida o corrupción. Relación y Relevancia de Privacidad, Integridad y Seguridad Estos tres conceptos están interrelacionados y juntos forman el marco de protección de los Sistemas de Información. La privacidad depende de la seguridad para evitar accesos no autorizados, y la integridad requiere tanto seguridad como privacidad para garan=zar que los datos se manejen de manera controlada y precisa. En su conjunto, la privacidad, integridad y seguridad son esenciales para mantener la confianza en los sistemas, cumplir con los marcos legales y é=cos, y asegurar que la información en la organización se maneje de forma segura y confiable. Diagramas UML UML (Unified Modeling Language) es un lenguaje de modelado visual estandarizado que permite visualizar, especificar, construir y documentar los componentes de un sistema de so+ware. Desarrollado en los años 90, UML unifica diferentes métodos de modelado y es u=lizado principalmente en el contexto de la programación orientada a objetos. Tipos de Diagramas UML: Diagramas estructurales: Representan la estructura de un sistema o Diagrama de clases: Representa las clases del sistema, sus atributos, métodos y relaciones entre ellas. o Diagrama de componentes: Muestra los componentes hsicos del sistema (como módulos de so+ware) y cómo interactúan entre ellos. Es decir todo aquel recurso desarrollado para un fin concreto y que puede formar solo o junto con otros, un entorno funcional requerido por cualquier proceso predefinido. o Diagrama de objetos: Similar al diagrama de clases, pero enfocado en instancias específicas de clases en un momento dado.  o Diagrama de despliegue: Representa la disposición hsica de los nodos y componentes del sistema en la infraestructura. Diagramas de comportamiento: Muestran el comportamiento del sistema o Diagrama de casos de uso: Describe las interacciones entre los actores externos y el sistema. o Diagrama de secuencia: Muestra la interacción entre objetos a través del intercambio de mensajes, ordenados por el =empo. o Diagrama de ac=vidades: Representa los flujos de trabajo o procesos dentro del sistema. o Diagrama de estados: Muestra los diferentes estados de un objeto a lo largo del =empo y las transiciones entre esos estados. UML: La vista está=ca modela las propiedades y relaciones del dominio. Existen grupos de diagramas de estructura y grupos de diagramas de comportamiento. En el diagrama de clases, los atributos =enen dis=ntos niveles de visibilidad (privado y público). No se permite que las clases tengan nombres repe=dos en el mismo espacio de nombres. Los diagramas de estructura no están enfocados en dar visibilidad a las funciones, sino en la organización está=ca del sistema. Los diagramas de comportamiento son los que tratan más sobre funciones y ac=vidades. UML =ene un total de 14 =pos de diagramas Modelo está=co: está formado por la representación de clases y objetos y describe su estructura. Se denomina está=co por que muestra todas las relaciones posibles a lo largo del =empo, no las que corresponden a un cierto momento. La principal representación es con el diagrama de clases y asociaciones Componentes: diagrama de clases y diagrama de objetos. Clasificadores: en=dad básica del modelo está=co formado por clases, =pos de datos e interfaz que describe las operaciones de una clase que son visibles desde otra. Paquetes: se consideran como una caja que con=ene elementos que pueden ser algún =po de los clasificadores Representación de objetos: surgida a par=r de las clases que ya se iden=ficaron en el modelo de dominio. Modelo dinámico: El obje=vo del modelo Dinámico es presentar o describir el comportamiento del sistema a través del =empo. Componentes: o Vista de Interacción o Diagramas de Secuencia o Diagramas de Colaboración o Modelo de Máquina de Estados o Diagrama de Estados o Vista de Ac=vidades o Diagrama de Ac=vidades Interacciones o La Vista de Interacción presenta las interacciones del usuario con el o sistema a través del intercambio de mensajes o Conjunto de mensajes que intercambian entre sí los objetos que o componen un sistema o Estos mensajes se intercambian a través de enlaces Mensaje: Un mensaje se define como una comunicación unidireccional entre objetos, adicionalmente puede contener parámetros. Colaboración: se define como una colección de objetos que interactúan entre ellos para representar un comportamiento en un determinado contexto. Está formada por ranuras de =empo que son ocupadas por objetos y ligas entre ellos en =empo de ejecución. Cada objeto o liga =enen un rol dentro de una colaboración y un objeto puede par=cipar en más de una colaboración Diagrama de Secuencia: muestra la interacción entre los objetos a través del intercambio de mensajes, ordenados según el =empo. Este diagrama pertenece a los diagramas de comportamiento en UML y muestra cómo los objetos se comunican entre sí enviando mensajes, y en qué orden temporal lo hacen. Los mensajes se muestran a lo largo del =empo en un eje ver=cal, lo que permite visualizar el flujo de interacción entre los objetos par=cipantes. Se representa con un gráfico en dos dimensiones, el elemento fundamental es una línea ver=cal que representa el eje del =empo En la dimensión horizontal se presentan los dis=ntos roles o estereo=pos presentes en una colaboración Cada estereo=po =ene una línea que representa su línea de vida representada por una línea punteada Diagrama de Estados: muestran el conjunto de estados por los que pasa un objeto durante su ciclo de vida en la aplicación cuando se presentan diversos eventos. Estado: representa la condición de un determinado objeto durante la realización de una ac=vidad Evento: representa un acontecimiento significa=vo en el =po que puede o no generar un cambio de estado Transicio2n: relación entre dos estados que refleja las acciones que ocurrieron para que un objeto pase del estado A al B Diagrama de Clases: es otro =po de diagrama en UML que se usa para modelar la estructura está=ca de un sistema. Representa las clases que forman parte del sistema, los atributos y métodos de esas clases, y las relaciones entre ellas. Este diagrama está orientado a describir cómo está organizado el sistema internamente en términos de objetos y relaciones. Elementos clave: Clases: Representan un conjunto de objetos con caracterís=cas y comportamientos comunes. Atributos: Son las propiedades o variables que caracterizan a una clase. Métodos: Son las funciones o comportamientos que puede realizar una clase. Relaciones: Muestran cómo las clases interactúan o se conectan entre sí. Las relaciones pueden ser de herencia, asociación, agregación, o composición. El propósito de un diagrama de clase es describir las clases que conforman el modelo de un determinado sistema. Se puede decir que existen tres perspec=vas diferentes desde las cuales se pueden u=lizar los diagramas de clase: Relaciones del diagrama de clases: Asociaciones: representan las relacionas más generales (con menor contenido semán=co) entre clases. Se representan con una línea sin sen=do asociado o Simple o Inversa o Reflexiva o Agregación: es una asociación con unas connotaciones semán=cas más definidas: la agregación es la relación parte-de, que presenta a una en=dad como un agregado de partes (en orientación a objeto, un objeto como agregado de otros objetos: clientes empresa o Composición: La composición implica que los componentes de un objeto sólo pueden pertenecer a un solo objeto agregado, de forma que cuando el objeto agregado es destruido todas sus partes son destruidas también. Se relaciona con el concepto de relación u objeto fuerte del que depende otro. (rombo relleno): Débil Fuerte Cardinalidad: número de ocurrencias que se asocian a través de una relación (uno-uno; muchos-muchos; uno- muchos; etc.) Herencia: relación de generalización/especialización entre clases. En UML la herencia se representa mediante una flecha, cuya punta es un triángulo vacío. La flecha que representa a la herencia va orientada desde la subclase a la superclase. Cuando de una superclase se derivan varias subclases existen dos notaciones diferentes, aunque totalmente equivalentes, para su representación. o Especificación o Generalización Dependencia Diagrama de ac=vidades: Los diagramas de ac=vidades sirven para representar el comportamiento dinámico de un sistema haciendo hincapié en la secuencia de ac=vidades que se llevan a cabo y las condiciones que guardan o disparan esas ac=vidades Estado inicial: Marca el punto de inicio del flujo de ejecución Estado final: Marca el punto final del flujo de ejecución Actividad/Acción: Representan la realización de un paso del flujo de ejecución Flujo de control: Determina qué actividad va a continuación de otra (se le puede asociar un nombre) En los libros aparecen ejemplos con la notación de la versión 1.5 Decisión: Decisión: Marca la existencia de flujos alternativos Condición/guarda: [cond.] Se escribe encima de un flujo de control e indica la condición que se debe cumplir para que el flujo continúe a través de él Fusión (Merge): Sirve para juntar dos o más flujos alternativos de ejecución que se han producido por una decisión Flujos concurrentes: División: Marca el inicio de flujos de actividades en paralelo Unión: Marca el fin de flujos de actividades en paralelo Subac=vidades: Subactividad: La actividad se describe más en detalle en un diagrama de actividades aparte  Ya conocemos: Estado final: Marca el punto final de todos los flujos de ejecución UML 2.0 incorpora la noción de: Final de flujo: Marca el punto final de un flujo, dejando en ejecución el resto de flujos Reglas: Una división =ene un flujo de entrada y dos o más flujos de salida Una unión =ene dos o más flujos de entrada y un flujo de salida El flujo de salida de una unión se dispara cuando se han finalizado todos los flujos de entrada en la unión (todos ellos discurren en paralelo) Un diagrama de ac=vidades demasiado grande nos debe hacer pensar que igual conviene incluir alguna subac=vidad para simplificarlo Una acción representa un paso del flujo de ejecución que se considera atómico, mientras que una ac=vidad representa un comportamiento compuesto de elementos individuales que son acciones. Restricciones: Un estado inicial no puede ser des=no de una transición Toda ac=vidad =ene al menos un flujo de entrada y otro de salida Puede haber cero o más estados finales (por ejemplo, un proceso con=nuo no tendrá estado final) Una decisión =ene un flujo de entrada y dos o más de salida Todo flujo de salida de una decisión debe estar e=quetado con una condición Las condiciones de todos los flujos de salida de una decisión deben ser disjuntas y completas Se puede u=lizar la condición else para representar el flujo que se sigue en caso de que ninguna de las otras condiciones sea cierta Una fusión =ene dos o más flujos de entrada y un flujo de salida Todos los vectores (de entrada y salida) deben tener el mismo tamaño Existe al menos un nodo de expansión de entrada y cero o más nodos de expansión de salida Si un nodo de expansión =ene nombre entonces corresponde al nombre de un elemento individual La ejecución para cada uno de los elementos puede ser: en paralelo: las ejecuciones son independientes itera=va: secuencial, una detrás de otra como corriente: una vez empezada la ejecución sigue recibiendo elementos de entrada Recomendaciones: Conviene colocar (no es obligado) el estado inicial en la parte superior izquierda del diagrama Flujos concurrentes: Un diagrama de ac=vidades también nos permite representar flujos que ocurren de forma concurrente (en paralelo). También permite indicar ac=vidades que se pueden hacer en cualquier orden (si lo hicieran elementos dis=ntos lo podrían hacer a la vez) Por ejemplo: A la vez que se expulsa una tarjeta no válida se le muestra un mensaje al usuario. Supongamos que el código y la can=dad se pueden introducir en cualquier orden.