PARCIAL 2 MODELADO - Resumen Modelado de Software PDF

RESUMEN MODELADO DE SOFTWARE parcial 2 Toma de requerimientos: Antes de comenzar el desarrollo de un sistema de software, es esencial comprender claramente el problema a resolver, atendiendo a las necesidades de los usuarios y objetivos del proyecto. Esto se realiza mediante una fase de anális...

RESUMEN MODELADO DE SOFTWARE parcial 2 Toma de requerimientos: Antes de comenzar el desarrollo de un sistema de software, es esencial comprender claramente el problema a resolver, atendiendo a las necesidades de los usuarios y objetivos del proyecto. Esto se realiza mediante una fase de análisis, cuyo propósito es identificar el QUÉ debe hacer el sistema. En esta etapa se recopilan los requerimientos a través de diversas técnicas de Educción (obtención de información) como entrevistas, encuestas y sesiones de brainstorming. Documentos generados en el análisis: Durante esta fase se crean artefactos que detallan los requerimientos, tales como: -Historias de usuario -Diagramas de casos de uso -Diagramas de estado y de actividades Diagrama de clases: Este se elabora en la etapa de diseño, mostrando el CÓMO se estructurará el sistema, mientras que el análisis se centra en el QUÉ. Técnicas de Educción: Entrevistas: Conversaciones estructuradas o abiertas con usuarios para comprender el contexto. Cuestionarios y encuestas: Recolectan datos cuando hay muchas personas o dificultad para realizar entrevistas directas. Las preguntas pueden ser abiertas (detalladas) o cerradas (respuestas breves). Brainstorming: Sesiones grupales para generar ideas y posibles soluciones sin restricciones. Este proceso asegura que el sistema a desarrollar esté alineado con las expectativas y necesidades del cliente y los usuarios. HISTORIAS DE USUARIO: Las historias de usuario son descripciones breves de las funcionalidades del sistema desde la perspectiva del usuario, organizadas en secciones para asegurar su claridad y precisión. Están compuestas por: Enunciado: Describe en términos simples lo que necesita el usuario, como "Yo, como [rol de usuario], quiero [funcionalidad] para [lograr un objetivo]". Criterios de Aceptación: Son requisitos específicos que permiten verificar que la funcionalidad está completa y cumple con lo esperado. Incluyen roles, comportamiento del sistema y validaciones. Casos de Uso: Son los flujos de acciones que el usuario puede realizar con esa funcionalidad. Se definen caminos como el “camino feliz” (caso ideal) y posibles casos de borde (excepciones). Estimación: Durante el Sprint Planning, se asigna un valor en puntos de historia a cada historia, que representa el esfuerzo requerido. Esta estimación no es tiempo exacto, sino una medida de esfuerzo, complejidad y riesgo; por ejemplo, 5 puntos de historia podrían aproximarse a 5 días de trabajo de un desarrollador. Se utilizan técnicas como Planning Poker o Fibonacci para asignar estos puntos. Cada historia de usuario debe cumplir con estas características: Independientes: Cada historia debe ser atómica, es decir, autosuficiente y sin dependencia de otras historias. Negociables: Deben ser abiertas a ajustes, dejando detalles a especificarse en los criterios de aceptación. Valoradas: Deben aportar valor al cliente, ayudando a priorizar según su impacto. Estimables: Su alcance debe estar claro para poder asignar una estimación de esfuerzo. Atómicas: Su duración debe oscilar entre dos días y dos semanas, para facilitar su manejo en el sprint. Verificables: Deben incluir criterios de aceptación claros para validar que se cumplieron las expectativas del cliente. Estas historias permiten estructurar el desarrollo ágilmente y centrarlo en el valor para el usuario, facilitando la planificación, la priorización y la adaptación al cambio. DISEÑO DE SOFTWARE: En el ciclo de vida de un sistema, la fase de diseño sigue a la etapa de análisis y se enfoca en definir CÓMO debe implementarse el sistema para satisfacer los requisitos. Basado en el paradigma orientado a objetos, el diseño del software busca representar la estructura y la lógica de la solución, utilizando diagramas para visualizar la comunicación entre los componentes. Diseño de Software: Definición: Es el proceso de creación y desarrollo de un sistema que combina aspectos técnicos y de relaciones humanas, buscando una solución comprensible y lógica. Características de un Buen Diseño: Simplicidad: Debe ser claro y entendible para todos los involucrados. Calidad: Un buen diseño asegura un producto de calidad, esencial para que el software sea mantenible, adaptable y extensible. Esto significa que permite corregir errores sin afectar otras partes y facilita agregar nuevas funcionalidades sin reescribir el código. Adaptabilidad: Capacidad del sistema para adaptarse a cambios en el entorno o en las necesidades de los usuarios. Prácticas y Principios de Diseño: Para alcanzar la calidad en el diseño, se aplican principios y patrones ya probados, que guían y estructuran el proceso de desarrollo. Los principales principios que se estudian en esta materia son: Principios SOLID: Conjunto de cinco principios que promueven un diseño sólido y escalable. Patrones GRASP: Patrones de asignación de responsabilidades para garantizar una organización coherente. Patrones GoF (Gang of Four): Conjunto de patrones de diseño orientado a objetos ampliamente reconocidos para resolver problemas comunes de diseño. Un buen diseño de software no solo aporta claridad y organización, sino también permite que el sistema evolucione y se mantenga a lo largo del tiempo con un alto estándar de calidad. SOLID SOLID es un conjunto de principios de diseño para programación orientada a objetos, creado por Robert C. Martin, que facilita la creación de software mantenible, comprensible y adaptable. Estos principios ayudan a reducir el esfuerzo y los problemas al hacer cambios en el código, especialmente después de que el sistema está en producción, permitiendo agregar o modificar componentes sin afectar otras partes. Principios SOLID: Single Responsibility Principle (SRP): Cada clase debe tener una única responsabilidad, es decir, una razón para cambiar. Esto mejora la claridad y facilita el mantenimiento. Open/Closed Principle (OCP): El software debe ser abierto para su extensión pero cerrado para su modificación. Esto significa que se debe poder agregar nuevas funcionalidades sin cambiar el código existente, promoviendo la reutilización. Liskov Substitution Principle (LSP): Las clases derivadas deben ser sustituibles por sus clases base sin alterar el correcto funcionamiento del programa. Así se garantiza que el sistema es estable y predecible. Interface Segregation Principle (ISP): Los clientes no deben estar obligados a depender de interfaces que no utilizan. Esto permite que las interfaces sean más específicas y evita la sobrecarga de métodos innecesarios. Dependency Inversion Principle (DIP): Las clases de alto nivel no deben depender de clases de bajo nivel, sino de abstracciones. Este principio promueve una arquitectura más flexible y facilita el cambio en dependencias. Estos principios guían el desarrollo de código modular y flexible, reduciendo la complejidad y permitiendo que el software se adapte y evolucione sin comprometer su calidad. PATRONES GRASP: Los patrones GRASP (General Responsibility Assignment Software Patterns) son un conjunto de principios que guían la asignación de responsabilidades en la programación orientada a objetos. Estos patrones ayudan a definir los objetos y clases del sistema, promoviendo un diseño más coherente, fácil de mantener y escalable. Los 9 Patrones GRASP: Experto: Asigna la responsabilidad a la clase que tiene la información necesaria para cumplir con ella. Promueve la eficiencia y minimiza la necesidad de consultas externas. Creador: Determina cuál clase debería crear instancias de otra clase, generalmente aquella que está más relacionada con el objeto creado o depende de él. Alta Cohesión: Las clases deben tener una única responsabilidad o tarea específica, facilitando la claridad y el mantenimiento. Bajo Acoplamiento: Minimiza las dependencias entre clases, haciendo el sistema más flexible y resistente a cambios. Controlador: Define un objeto encargado de manejar los eventos del sistema, como un intermediario entre la interfaz de usuario y el modelo lógico. Polimorfismo: Utiliza la herencia y la sobrecarga para permitir que las clases respondan de manera distinta a la misma interfaz, facilitando la extensibilidad. Fabricación Pura (Pure Fabrication): Crea una clase "ficticia" que no pertenece al modelo del negocio, pero que ayuda a cumplir con los principios de diseño (por ejemplo, clases de utilidad). Indirección: Introduce un intermediario para reducir la dependencia directa entre clases, mejorando la flexibilidad y la modularidad del sistema. No Hables con Extraños (Don't Talk to Strangers): Limita las interacciones directas a solo aquellos objetos conocidos, evitando acoplamientos innecesarios y mejorando la seguridad de los datos. Estos patrones facilitan el diseño de software de calidad, promoviendo una estructura clara y mantenible al tiempo que aseguran que las clases y objetos tengan asignaciones de responsabilidades lógicas y eficientes. PATRONES GoF: Patrones Creacionales: Facilitan la creación de objetos abstractos, separando al sistema de las clases específicas de los objetos creados. Abstract Factory: Permite crear familias de objetos relacionados sin especificar sus clases concretas. Es útil cuando se necesitan diferentes variantes de objetos (por ejemplo, distintos tipos de muebles: silla, mesa, sofá) que deben ensamblarse con componentes de la misma "familia" o estilo. Builder: Separa el proceso de creación de un objeto complejo, permitiendo construirlo paso a paso. Esto es útil para objetos que necesitan ser creados con múltiples configuraciones. Por ejemplo, construir una casa seleccionando materiales y diseño de cada parte. Factory Method: Define un método para crear objetos, delegando la creación a subclases que deciden qué tipo de objeto crear. Este patrón oculta los detalles de instanciación de clases y permite que las subclases determinen el tipo de objeto necesario. Prototype: Crea nuevos objetos clonando una instancia ya existente. Es útil para evitar costosos procesos de creación de objetos desde cero, copiando una "plantilla" que puede modificarse según sea necesario. Singleton: Garantiza que una clase tenga una única instancia y proporciona un punto de acceso global a ella. Este patrón se usa para clases que deben tener un único objeto, como una conexión a base de datos. 2. Patrones Estructurales: Se enfocan en cómo se organizan y relacionan las clases y objetos para formar estructuras más grandes. Adapter: Permite que dos clases incompatibles trabajen juntas adaptando sus interfaces. Es como conectar un enchufe de un tipo en una toma de corriente de otro, haciendo posible su uso en el sistema. Bridge: Divide una clase grande o un conjunto de clases estrechamente relacionadas en dos jerarquías (abstracción e implementación) para permitir cambios y desarrollos independientes. Composite: Organiza objetos en una estructura de árbol para representar jerarquías de "todo-partes". Permite tratar a objetos individuales y compuestos de manera uniforme, como una carpeta con archivos y subcarpetas en una computadora. Decorator: Agrega dinámicamente comportamientos adicionales a los objetos al envolverlos en clases de decoradores. Por ejemplo, añadir distintas prendas para protegerse del clima sin alterar la estructura básica de la persona. Facade: Proporciona una interfaz simplificada para un conjunto complejo de clases o sistemas. Es como un recepcionista en un hotel, que simplifica las interacciones con múltiples servicios. Flyweight: Reduce el uso de memoria compartiendo elementos entre objetos cuando estos tienen características similares. Útil para cuando muchos objetos tienen atributos idénticos, como caracteres en un editor de texto. Proxy: Proporciona un sustituto o marcador de posición para otro objeto, controlando el acceso a él. Puede incluir lógica adicional como control de acceso o carga diferida (carga solo cuando es necesario). 3. Patrones de Comportamiento: Ayudan a definir la comunicación entre objetos y el control del flujo de trabajo en el programa. Chain of Responsibility: Permite que una solicitud pase por una cadena de manejadores hasta que uno de ellos la procese. Es útil cuando múltiples objetos pueden manejar una solicitud, pero no se sabe cuál será el adecuado. Command: Convierte una solicitud en un objeto independiente, permitiendo que se almacene, encole y ejecute de manera independiente. Esto es útil para operaciones de "deshacer" y "rehacer". Interpreter: Define una gramática para un lenguaje y un intérprete para analizar oraciones en dicho lenguaje. Se usa en aplicaciones que requieren evaluar expresiones o realizar cálculos. Iterator: Permite recorrer elementos de una colección sin exponer su estructura interna. Es útil para colecciones complejas como listas, pilas, o árboles. Mediator: Simplifica las interacciones entre un grupo de objetos al centralizar la comunicación en un objeto mediador. Esto reduce dependencias directas entre objetos, facilitando el mantenimiento. Memento: Permite almacenar y restaurar el estado interno de un objeto sin violar su encapsulación. Útil para implementar funcionalidades de "deshacer" en aplicaciones. Observer: Define una relación de suscriptor, donde múltiples objetos dependen de otro y se actualizan cuando este cambia. Esto es común en interfaces gráficas o sistemas de notificación. State: Permite que un objeto cambie su comportamiento según su estado interno. Cada estado se implementa en una clase diferente, facilitando cambios de comportamiento sin condicionales complejos. Strategy: Define una familia de algoritmos que son intercambiables, permitiendo al objeto cliente elegir el más adecuado en tiempo de ejecución. Template Method: Define los pasos de un algoritmo, permitiendo a las subclases redefinir ciertos pasos sin cambiar la estructura general. Útil cuando se necesita consistencia en la estructura, pero variación en los detalles. Visitor: Permite definir nuevas operaciones en clases sin modificarlas. Esto es útil cuando se necesita realizar distintas operaciones en una jerarquía de objetos sin agregar lógica compleja en cada clase.