Saber Pro Diseño de Software key terms

Actividad de ingeniería que transforma los requisitos en una descripción estructurada de la solución: componentes, responsabilidades, interfaces y decisiones, antes de escribir el código.

Conjunto de decisiones estructurales de alto nivel sobre los elementos del sistema, sus relaciones y las restricciones que condicionan el resto del diseño y la evolución del producto.

Propiedad medible del sistema distinta de la funcionalidad, como rendimiento, disponibilidad, seguridad o modificabilidad, que guía y permite evaluar las decisiones de diseño.

Enunciado concreto con fuente, estímulo, artefacto, entorno, respuesta y medida que hace verificable un atributo de calidad y permite evaluar si el diseño lo satisface.

Decisiones de diseño reutilizables orientadas a lograr un atributo de calidad, por ejemplo caché para rendimiento o replicación para disponibilidad, aplicadas dentro de una estrategia mayor.

Solución general y reutilizable a un problema recurrente de estructura del sistema, como capas, microservicios o arquitectura hexagonal, que define la organización global de los componentes.

Organización del sistema en niveles donde cada capa ofrece servicios a la superior y consume los de la inferior, favoreciendo la separación de responsabilidades y la sustituibilidad de cada nivel.

Estilo que aísla el núcleo de dominio detrás de puertos y adaptadores, de modo que la lógica de negocio no dependa de bases de datos, interfaces de usuario ni frameworks externos.

Estilo que descompone el sistema en servicios pequeños desplegables de forma independiente, comunicados por interfaces ligeras, cada uno dueño de sus datos y de un contexto de negocio.

Estilo en el que los componentes publican y consumen eventos de forma asíncrona, desacoplando productores y consumidores y favoreciendo la extensibilidad y la reactividad del sistema.

Representación parcial de la arquitectura centrada en un conjunto de intereses, como la vista lógica, de procesos, de despliegue o de casos de uso, para comunicar decisiones a distintos interesados.

Enfoque de documentación que describe la arquitectura en cuatro niveles de zoom: contexto, contenedores, componentes y código, cada uno dirigido a una audiencia distinta.

Principio según el cual un módulo o clase debe tener una sola razón para cambiar, es decir, una única responsabilidad asignada dentro del diseño del sistema.

Principio que exige que los módulos sean abiertos a extensión pero cerrados a modificación, de modo que se añada comportamiento nuevo sin editar el código ya probado.

Principio que exige que un subtipo pueda reemplazar a su tipo base sin alterar la corrección del programa, respetando el contrato y las invariantes de la superclase.

Principio que recomienda dividir interfaces amplias en interfaces pequeñas y específicas, para que los clientes dependan solo de las operaciones que realmente utilizan.

Principio que hace que los módulos de alto nivel y los de bajo nivel dependan de abstracciones, y que las abstracciones no dependan de los detalles de implementación.

Grado en que las responsabilidades de un módulo están relacionadas entre sí; una cohesión alta indica un módulo enfocado y más fácil de comprender y mantener.

Grado de dependencia entre módulos; un acoplamiento bajo reduce el impacto de los cambios y facilita probar, reemplazar y reutilizar partes del sistema.

Unidad de descomposición del software que agrupa elementos relacionados y expone una interfaz definida, ocultando su implementación interna al resto del sistema.

Técnica que oculta el estado y los detalles internos de un componente y expone solo una interfaz controlada, protegiendo las invariantes y reduciendo el acoplamiento.

Contrato que declara las operaciones que un componente ofrece a sus clientes, sin exponer cómo se implementan, y que permite sustituir implementaciones sin afectar a los consumidores.

Capacidad de un mismo mensaje o llamada de resolverse en implementaciones distintas según el tipo real del objeto, permitiendo tratar variantes mediante una abstracción común.

Solución nombrada y reutilizable a un problema recurrente de diseño de objetos o clases en un contexto dado, que describe participantes, colaboraciones y consecuencias.

Patrón de comportamiento que encapsula familias de algoritmos intercambiables detrás de una interfaz común, permitiendo elegir el comportamiento en tiempo de ejecución sin condicionales rígidos.

Patrón de comportamiento en el que un sujeto notifica automáticamente a sus observadores registrados cuando cambia su estado, desacoplando al emisor de los receptores.

Patrón creacional que centraliza la creación de objetos detrás de una interfaz o método, de modo que el cliente no dependa de clases concretas ni de su lógica de construcción.

Solución aparentemente razonable que en la práctica genera problemas recurrentes de mantenimiento o rendimiento, documentada para reconocerla y corregirla a tiempo.

Costo futuro acumulado por decisiones de diseño rápidas o incompletas; si no se gestiona con refactorización, encarece cada cambio posterior del sistema.

Transformación controlada del código que mejora su estructura interna sin cambiar el comportamiento observable, apoyada en pruebas automatizadas que verifican la equivalencia funcional.

Indicio superficial en el código, como un método demasiado largo o duplicación, que sugiere un problema de diseño más profundo y orienta posibles refactorizaciones.

Diagrama UML que muestra clases, atributos, operaciones y relaciones como asociación, herencia o composición, usado para modelar la estructura estática del diseño.

Diagrama UML de interacción que representa el intercambio de mensajes entre objetos ordenado en el tiempo, útil para verificar el cumplimiento de un escenario de diseño.

En UML, especificación del número de instancias que pueden participar en una asociación, por ejemplo uno, cero o muchos, y que restringe las cardinalidades válidas del modelo.

Descripción de una interacción entre actores y el sistema orientada a un objetivo de valor, que sirve como entrada para derivar responsabilidades y escenarios de diseño.

Enunciado breve de una necesidad desde la perspectiva de un usuario, con criterios de aceptación, que alimenta la planificación y las decisiones de diseño incremental.

Prueba automatizada que verifica el comportamiento de una unidad aislada del diseño, como una clase o función, y que habilita la refactorización con seguridad.

Técnica en la que un componente recibe sus colaboradores desde fuera en lugar de crearlos internamente, facilitando el desacoplamiento, la configuración y las pruebas con dobles.