<aside> 💡 Se toma de base el siguiente PDF y otros parciales de este año.

</aside>

PreguntasTeoricoDiseno_-_Meles.pdf

Unidad 2

Principio de Diseño

Realice un cuadro comparativo para explicar características, ventajas y desventajas de las relaciones de generalización, realización y agregación/composición

• Define una jerarquía "es un" clara. | - Promueve la reutilización de código.
• Facilita la extensibilidad y el mantenimiento del sistema. | - Riesgo de abuso en la herencia, conduciendo a jerarquías complejas.
• Puede complicar el cambio y la comprensión si la jerarquía es muy profunda. | | Realización
• • • -|> | - Se utiliza para implementar interfaces, donde una clase se compromete a realizar la ****especificación de la interfaz.
• Define un contrato que la clase debe cumplir. | - Separa la especificación de la implementación.
• Favorece el bajo acoplamiento y la programación hacia la interfaz. | - La implementación debe ser coherente con todas las interfaces que realiza, lo cual puede aumentar la complejidad. | | Agregación ◇—> | - Tipo de asociación que indica una relación "todo-parte" con un acoplamiento más débil que la composición.
• Las partes pueden existir independientemente del todo. | - Útil para modelar sistemas donde las partes tienen una cierta autonomía. | - Puede llevar a un diseño menos intuitivo debido a la naturaleza no exclusiva de la relación. | | Composición ◆—> | - Versión más fuerte de la agregación.
• Indica que la parte es exclusiva del todo y su existencia está fuertemente ligada a la del todo.
• La destrucción del todo lleva a la destrucción de las partes. | - Claridad en la dependencia de ciclo de vida entre el todo y sus partes.
• Modela claramente la propiedad y el alcance. | - Puede imponer restricciones innecesarias en el diseño si se malinterpreta o se utiliza incorrectamente.
• Flexibilidad reducida para las partes en el diseño del sistema. |

Definir principio de diseño y explicar los principios de diseño básicos

Los principios de diseño son una guía que sirve como fundamento para estructurar el software de una manera que facilite su mantenimiento, extensión, prueba y colaboración.

Un buen diseño debe considerar Independencia de componentes, Identificación y tratamiento de excepciones, y la prevención y tolerancia de defectos. Un buen diseño apunta a brindar una alta cohesión y bajo acoplamiento, lo cual promueve la independencia de componentes.

1. DRY (Don’t Repeat Yourself): Este principio enfatiza la importancia de evitar la duplicación de código. Si un fragmento de código se repite en todo el sistema, los cambios en ese código deben hacerse en varios lugares, lo que conlleva dificultades de mantenimiento. Al reutilizar componentes de código y encapsular la lógica repetida mediante la creación de abstracciones, cada requerimiento se encuentra en un único lugar y por lo tanto el sistema se vuelve más fácil de mantener y menos propenso a errores. Está vinculado a la herencia y a SRP.
2. SoC (Separación de Responsabilidades): SoC consiste en aislar la aplicación de software en secciones separadas. Cada sección debe abordar una preocupación distinta que tenga poca superposición con otras secciones. La separación de intereses se puede aplicar principalmente en 2 niveles: arquitectónico (capas) y de programación (niveles). Facilita la extensión e independencia de componentes, reduce fragilidad de los módulos, gestiona la complejidad, mejora la cohesión y disminuye el acoplamiento, y aumenta la mantenibilidad.
3. YAGNI (You ain’t gonna need it): Este principio aconseja no agregar funcionalidad hasta que sea absolutamente necesario. La “sobre-ingeniería” puede llevar a una complejidad y un peso innecesarios.
4. KISS (Keep It Simple, Stupid): KISS busca favorecer la simplicidad en el diseño y la implementación. Al evitar la complejidad innecesaria, el código se vuelve más fácil de mantener, más flexible y fácil de ampliar, modificar, mejorar y menos propenso a errores. Está vinculado a YAGNI y a DRY.
5. Ley de Demeter: Esta ley promueve el bajo acoplamiento al restringir la cantidad de objetos con los que un objeto interactúa. Específicamente, un objeto solo debería comunicarse con sus colaboradores inmediatos y no con los colaboradores de sus colaboradores. Una desventaja es que requiere una gran cantidad de métodos de envoltorio para transportar información entre objetos distantes, ya que la información no se puede recuperar de otra manera. También se denomina don’t talk to strangers, o principio del menor conocimiento.
6. Tell, don’t ask: En lugar de hacer consultas a un objeto para obtener datos y luego actuar en función de esos datos, este principio sugiere que se le debe decir al objeto lo que se quiere que haga. Esto conduce a un código más encapsulado y cohesivo, y fomenta un mejor diseño orientado a objetos. Está vinculado al polimorfismo. Por ejemplo, una mala práctica sería tener una clase <<control>> que tenga toda la lógica y sólo pida los datos encapsulados en cada clase, mientras que lo correcto sería que cada clase también tenga lógica incorporada a sus funciones correspondientes.
7. Programar hacia la interfaz, no hacia la implementación: Este principio dice que es más importante pensar en cómo ofrecer un mejor servicio (interfaz) a las clases cliente en lugar de pensar en cómo lo voy a resolver (implementación), de manera tal que se comunique con abstracciones en lugar de concreciones. Para el cliente resulta transparente, porque sólo se comunica con la interfaz. Esto ofrece un código más flexible y extensible, lo cual facilita la adaptación a los cambios en los requisitos.
8. Composite Reuse: Este principio enfatiza la composición sobre la herencia. Al construir objetos nuevos a partir de objetos existentes a través de la composición en lugar de heredar atributos y comportamientos, el código se vuelve más modular y menos enredado en jerarquías de herencia complejas. La delegación y las relaciones de agregación y composición, permiten una mayor flexibilidad, mantenibilidad, reusabilidad y extensibilidad.

De una definición aplicable al proceso de diseño y explique detalladamente qué aspectos del software se diseñan

Diseño. Proceso mediante el cual se aplican varias técnicas y principios con el objetivo de definir un dispositivo, un proceso o un sistema con suficiente nivel de detalle como para permitir su realización física. Es entonces un proceso iterativo de transformación de un modelo lógico en un modelo físico, teniendo en cuenta las restricciones del negocio.

Aspectos a diseñar

• Diseño arquitectónico. Da respuesta a los requerimientos de calidad del software, con decisiones estratégicas
• Diseño de Datos. Transforma los requerimientos en las estructuras de datos necesarias para hacer persistente el software
• Diseño de Procesos. Transforma elementos estructurales en una descripción procedimental de los componentes del software
• Diseño de experiencia de usuario. Es la disciplina relacionada con el diseño, evaluación e implementación de sistemas computacionales interactivos para uso humano. Es atravesada por otras disciplinas, como sociología, psicología, diseño, programación, AI, ergonomía, etc.
• Diseño de E/S. Describe cómo se ingresa información al software y cómo se presentarán las salidas del mismo. Las entradas suelen ser formularios, y las salidas podrían ser dashboards interactivos o reportes.
• Diseño de Procedimientos Manuales. Describe cómo integra el software al Sistema de Negocio. Relaciona el modelo de negocio con el modelo de sistema de información.