Los atributos externos de calidad son las características del software que pueden ser percibidas directamente por el usuario final durante su uso. Reflejan cómo el sistema se comporta y si cumple con las expectativas del cliente.

• Eficiencia: mide el rendimiento del sistema, considerando el tiempo de respuesta, el uso de recursos y la capacidad para manejar múltiples tareas sin afectar la estabilidad.

• Usabilidad: se refiere a qué tan fácil resulta para el usuario aprender y manejar el sistema. Un software usable debe ser intuitivo, claro y accesible.

• Confiabilidad: evalúa la capacidad del sistema para operar correctamente sin errores durante un período determinado.

• Portabilidad: indica la facilidad con la que el software puede trasladarse o adaptarse a distintos entornos o plataformas.

• Seguridad: garantiza la protección de los datos frente a accesos no autorizados o pérdidas de información.

Estos atributos determinan la calidad percibida del producto y la experiencia del usuario.

2. Atributos externos de calidad: mantenibilidad y desempeño

• Mantenibilidad:
  Representa la facilidad con la que un sistema puede ser modificado, corregido o mejorado después de su entrega. Un software mantenible permite incorporar nuevas funciones, corregir errores o adaptarse a cambios sin afectar el resto del sistema. Este atributo depende de la claridad del código, su modularidad y una documentación adecuada.

• Desempeño:
  Evalúa la eficiencia operativa del software, considerando la velocidad de ejecución, el tiempo de respuesta y el consumo de recursos. Un buen desempeño garantiza que el sistema funcione de manera ágil, estable y eficiente, incluso bajo condiciones de alta demanda.

  
  

3. Atributos internos de calidad: legibilidad y cohesión

Los atributos internos de calidad se centran en las propiedades del código fuente y su estructura interna. Afectan directamente al desarrollo, comprensión y mantenimiento del software.

• Legibilidad:
  Es la facilidad con la que un programador puede leer, entender y modificar el código fuente. Un código legible es claro, bien estructurado y utiliza nombres descriptivos para variables, funciones y clases. La legibilidad mejora la detección de errores y la colaboración entre desarrolladores.

• Cohesión:
  Mide el grado en que los elementos de un módulo trabajan juntos para cumplir una función específica. Un módulo con alta cohesión tiene partes bien relacionadas y enfocadas en una sola tarea, lo que favorece la claridad, la mantenibilidad y la calidad general del software.

  
  

4. Relación entre los atributos internos y los principios de diseño

La cohesión se relaciona directamente con el principio de responsabilidad única (SRP), que establece que cada clase o módulo debe tener una sola razón para cambiar. Esto fomenta que los elementos de un componente trabajen unidos para cumplir una función clara, logrando así una alta cohesión. También se vincula con el principio de encapsulamiento, ya que agrupar datos y comportamientos relacionados dentro de una misma entidad mantiene el código organizado y enfocado.

La legibilidad del código se asocia con los principios KISS (Keep It Simple, Stupid) y DRY (Don’t Repeat Yourself). Mantener el código simple, claro y sin repeticiones innecesarias facilita su comprensión y reduce errores. Además, seguir convenciones de codificación y nombres consistentes mejora la lectura y la mantenibilidad del sistema.

La mantenibilidad y el desempeño también se benefician de principios como el bajo acoplamiento y la alta cohesión, que permiten modificar, probar o extender el software sin generar efectos colaterales, garantizando un rendimiento óptimo y una arquitectura limpia.

Marleny, Adrian, Lucero.

El DOO es una metodología de diseño que facilita la creación de aplicaciones flexibles, modulares, fáciles de mantener y escalables, al centrarse en la interacción de entidades que combinan datos y comportamiento.

Conceptos Clave del DOO

Los cuatro pilares fundamentales, a menudo denominados los cuatro pilares de la POO (Programación Orientada a Objetos), son esenciales para entender el DOO:

1. Clases

Una Clase es una plantilla, un plano o un prototipo para crear objetos. Define la estructura de los objetos, especificando los datos (atributos o propiedades) y las funcionalidades (métodos o comportamientos) que todos los objetos de ese tipo poseerán.

• Ejemplo: La clase Coche definiría atributos como color, marca y velocidadMáxima, y métodos como acelerar(), frenar() y encender().

2. Objetos

Un Objeto es una instancia concreta de una clase. Es una entidad del mundo real (o del sistema) que tiene un estado (los valores actuales de sus atributos) y un comportamiento (los métodos que puede ejecutar).

• Ejemplo: Si Coche es la clase, un objeto podría ser miCoche, que es una instancia de Coche con el estado: color = "Rojo", marca = "Toyota", velocidadMáxima = 200.

3. Herencia

La Herencia es un mecanismo que permite que una clase (la subclase o clase hija) herede atributos y métodos de otra clase (la superclase o clase padre). Esto promueve la reutilización de código y modela relaciones jerárquicas del mundo real (la relación "es un").

• Ejemplo: La clase CocheDeportivo puede heredar de la clase Coche. Esto significa que CocheDeportivo automáticamente tiene color, marca y el método acelerar(), y podemos agregarle atributos o métodos específicos, como alerón y activarTurbo(), sin reescribir la funcionalidad básica de un coche.

4. Polimorfismo

El Polimorfismo significa "muchas formas". Es la capacidad de un objeto de tomar múltiples formas o, más concretamente, la habilidad de diferentes objetos para responder a un mismo mensaje (llamada a un método) de maneras distintas, según su propia implementación.

• Ejemplo: Supongamos que la clase Animal tiene un método abstracto llamado hacerSonido().

  • Un objeto de la subclase Perro implementará hacerSonido() como "Guau, guau".

  • Un objeto de la subclase Gato implementará hacerSonido() como "Miau".

  • Cuando se llama a animal.hacerSonido() con una referencia a un Perro o un Gato, el resultado es diferente, aunque se use el mismo nombre de método.

Conexión del DOO con un Principio de Diseño Clave: La Abstracción

El concepto clave del DOO que se conecta más profundamente con los principios de diseño es la Abstracción.

Principio de Abstracción: Simplificación y Relevancia

La Abstracción es el principio de mostrar solo la información esencial y ocultar los detalles de implementación complejos e innecesarios al usuario o a otras partes del sistema.

• Definición: Permite a los desarrolladores centrarse en lo que un objeto hace (su interfaz) en lugar de cómo lo hace (su implementación interna).

• Relevancia con el DOO: La abstracción es la base para definir las Clases y sus Interfaces. Cuando interactúas con un objeto, solo necesitas conocer los métodos públicos que expone; no necesitas saber el código exacto dentro de esos métodos.

Ejemplo de Abstracción:

Piensa en el objeto televisor .

1. Lo que ves (Abstracción): Tienes botones simples como "Encender/Apagar", "Subir Volumen" y "Cambiar Canal". Esta es la interfaz (los métodos de alto nivel) que la clase Televisor te expone.

2. Lo que se oculta (Implementación): No necesitas saber nada sobre los circuitos internos, la modulación de señales, o cómo el software maneja los píxeles en la pantalla. Todos esos detalles complejos están abstraídos de ti.

En DOO, la abstracción se logra a través de:

• Clases e Interfaces Abstractas: Definen métodos que deben ser implementados por subclases, actuando como contratos.

• Encapsulamiento: Oculta los datos internos del objeto y restringe el acceso directo, obligando a interactuar a través de métodos públicos (getters y setters), que es una forma de aplicar la abstracción.

La abstracción es crucial porque: reduce la complejidad, mejora la mantenibilidad y permite la evolución del código sin afectar a las partes que dependen de la interfaz abstracta.

Bibliografía y Referencias

Los conceptos del Diseño Orientado a Objetos (DOO) y sus principios fundamentales se basan en décadas de investigación y experiencia en ingeniería de software. A continuación, se presentan algunas referencias clave en el campo:

1. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software (Patrones de Diseño: Elementos de Software Orientado a Objetos Reutilizable). Addison-Wesley.

   • Nota: Este libro, a menudo conocido como el libro de la "Banda de los Cuatro" (Gang of Four o GoF), es una obra seminal que cataloga 23 patrones de diseño que resuelven problemas comunes en el DOO.

2. Meyer, B. (1997). Object-Oriented Software Construction (Construcción de Software Orientado a Objetos). Prentice Hall.

   • Nota: Una referencia fundamental que establece las bases teóricas de la POO, la herencia, el polimorfismo y, en particular, el principio de Diseño por Contrato (Design by Contract).

3. Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices (Desarrollo Ágil de Software, Principios, Patrones y Prácticas). Prentice Hall.

   • Nota: En este y otros trabajos, Robert C. Martin (conocido como "Uncle Bob") popularizó los principios SOLID del diseño orientado a objetos (que incluyen Abierto/Cerrado y la Inversión de Dependencia, muy ligados a la abstracción).