26. Niveles de abstracción: diagramas conceptuales, de análisis y de diseño

26.1 Introducción

Un mismo sistema puede representarse con distintos niveles de abstracción. Un diagrama puede mostrar conceptos del problema sin hablar de tecnología, puede representar el comportamiento esperado desde el análisis o puede describir decisiones concretas de diseño cercanas a la implementación.

Comprender los niveles de abstracción evita mezclar ideas incompatibles. No es lo mismo modelar qué significa un Turno para el negocio que diseñar qué clases, servicios y repositorios se usarán para implementarlo. Ambas vistas pueden ser útiles, pero responden preguntas diferentes.

26.2 Qué es la abstracción

Abstraer significa seleccionar lo importante para un propósito y dejar fuera detalles que no aportan en ese momento. Un diagrama no debe representar toda la realidad; debe representar la parte de la realidad que se necesita comprender, comunicar o diseñar.

Un nivel alto de abstracción muestra ideas generales. Un nivel bajo de abstracción muestra detalles más concretos. La calidad del modelo depende de elegir el nivel adecuado para la pregunta que se quiere responder.

26.3 Tres niveles frecuentes

En UML es frecuente distinguir diagramas conceptuales, diagramas de análisis y diagramas de diseño. Los conceptuales ayudan a entender el dominio. Los de análisis describen requisitos, comportamiento esperado y responsabilidades generales. Los de diseño representan decisiones más cercanas a la solución técnica.

26.4 Nivel conceptual

El nivel conceptual se concentra en conceptos del problema. Evita detalles de implementación y busca representar el vocabulario del dominio. En este nivel aparecen términos que las personas del área pueden reconocer: Cliente, Pedido, Producto, Turno, Profesional, Agenda, Factura.

Un diagrama conceptual ayuda a aclarar qué cosas existen en el dominio, cómo se relacionan y qué reglas generales se deben comprender antes de diseñar la solución.

26.5 Ejemplo de nivel conceptual

En un sistema de turnos médicos, un diagrama conceptual puede mostrar Paciente, Profesional, Especialidad, Agenda y Turno. También puede indicar que un Profesional tiene una Agenda y que un Turno se asigna a un Paciente.

En este nivel no hace falta mostrar ControladorTurnos, RepositorioTurnos, tablas, frameworks ni endpoints. Esos elementos pertenecen a niveles más cercanos al diseño o la implementación.

26.6 Nivel de análisis

El nivel de análisis se enfoca en comprender qué debe hacer el sistema y cómo se comporta desde el punto de vista de requisitos. Puede incluir casos de uso, actividades, estados, secuencias conceptuales y clases de análisis.

En este nivel se busca aclarar funcionalidades, reglas, escenarios, alternativas, responsabilidades generales y restricciones importantes, sin comprometer todavía todos los detalles técnicos de la solución.

26.7 Ejemplo de nivel de análisis

Para Solicitar turno, un diagrama de actividades de análisis puede mostrar pasos como seleccionar especialidad, consultar disponibilidad, elegir horario, confirmar reserva y recibir comprobante. También puede incluir caminos alternativos si no hay disponibilidad o si el paciente cancela la operación.

El diagrama explica el comportamiento esperado, pero no necesariamente decide qué clases o servicios exactos implementarán cada paso.

26.8 Nivel de diseño

El nivel de diseño representa decisiones de solución. Aquí pueden aparecer clases de diseño, servicios, controladores, repositorios, interfaces, componentes, dependencias, patrones y artefactos cercanos a la implementación.

Este nivel responde cómo se organizará el software para cumplir los requisitos. No se limita al dominio del problema; incluye elementos técnicos necesarios para construir la solución.

26.9 Ejemplo de nivel de diseño

Para implementar la reserva de turnos, un diagrama de diseño puede incluir InterfazTurnos, ControladorTurnos, ServicioTurnos, RepositorioTurnos, ValidadorDisponibilidad y ServicioNotificaciones. Un diagrama de secuencia puede mostrar mensajes entre esos participantes.

Este modelo ya está más cerca del código. Puede orientar implementación, pruebas técnicas y distribución de responsabilidades internas.

26.10 Diferencia entre dominio y solución

El dominio describe el problema. La solución describe cómo se resolverá con software. Confundir ambos niveles puede producir modelos difíciles de entender. Por ejemplo, Paciente y Turno pertenecen al dominio; ControladorTurnos y RepositorioTurnos pertenecen a una solución técnica.

No está mal que ambos aparezcan en el curso o en el proyecto, pero conviene no mezclarlos sin aclarar el nivel del diagrama.

26.11 Nivel de abstracción por tipo de diagrama

Un mismo tipo de diagrama puede usarse en distintos niveles. Un diagrama de clases puede ser conceptual o de diseño. Un diagrama de secuencia puede mostrar interacción entre actor y sistema o mensajes técnicos entre servicios. Un diagrama de componentes puede ser una vista general o una vista técnica detallada.

Por eso no alcanza con decir "diagrama de clases". También conviene aclarar si se trata de un modelo conceptual, de análisis o de diseño.

26.12 Tabla comparativa

26.13 Cómo elegir el nivel adecuado

El nivel adecuado depende de la conversación. Si se está validando vocabulario del negocio, conviene un nivel conceptual. Si se están revisando requisitos y flujos, conviene análisis. Si se está preparando implementación, conviene diseño.

Elegir mal el nivel puede bloquear la comunicación. Un diagrama técnico puede confundir una conversación de requisitos. Un diagrama demasiado conceptual puede ser insuficiente para guiar desarrollo.

26.14 Mezclar niveles con intención

A veces se pueden combinar niveles, pero debe hacerse con intención. Por ejemplo, un diagrama de secuencia puede mostrar al actor, la interfaz y algunos servicios internos. Esa mezcla puede ser útil para explicar cómo una acción del usuario llega a la lógica de aplicación.

El problema aparece cuando la mezcla no está controlada. Si se agregan conceptos del dominio, tablas, clases técnicas, servicios externos y pantallas sin criterio, el diagrama se vuelve confuso.

26.15 Nombres según el nivel

Los nombres deben acompañar el nivel de abstracción. En un modelo conceptual, nombres como Pedido, Cliente y Producto son adecuados. En diseño, pueden aparecer ServicioPedidos, ControladorPedidos y RepositorioProductos.

Si un nombre técnico aparece en un diagrama conceptual, debe haber una razón. Si un concepto del negocio aparece en un diagrama de diseño, debe quedar claro si representa una entidad, un objeto de dominio o una estructura técnica.

26.16 Documentar el propósito del diagrama

Una forma simple de evitar confusión es indicar el propósito del diagrama. Por ejemplo: "Modelo conceptual de turnos", "Flujo de análisis para solicitar turno" o "Secuencia de diseño para registrar reserva".

Ese título orienta la lectura y ayuda a interpretar qué nivel de detalle se espera.

26.17 Relación con el avance del proyecto

Al inicio del proyecto suelen predominar diagramas conceptuales y de análisis. A medida que se toman decisiones de solución, aparecen diagramas de diseño, componentes y despliegue. Sin embargo, esto no es una regla rígida.

En proyectos iterativos, los niveles pueden convivir. Una funcionalidad nueva puede estar en análisis mientras otra ya está en diseño o implementación.

26.18 Criterios de revisión

• ¿El propósito del diagrama está claro?
• ¿El nivel de abstracción coincide con la pregunta que se quiere responder?
• ¿Los nombres corresponden al nivel elegido?
• ¿Se evita mezclar dominio y solución sin criterio?
• ¿El nivel de detalle es suficiente sin ser excesivo?
• ¿El público del diagrama puede interpretarlo correctamente?
• ¿El diagrama se relaciona coherentemente con otras vistas del sistema?

26.19 Errores frecuentes

• Incluir clases técnicas en un diagrama conceptual sin necesidad.
• Usar un diagrama demasiado general para orientar implementación.
• Mezclar términos del negocio con nombres de tablas, controladores y frameworks sin aclaración.
• No indicar si un diagrama de clases es conceptual o de diseño.
• Agregar detalles de código durante una discusión de requisitos.
• Eliminar detalles importantes cuando el objetivo es diseño.
• Crear diagramas que no responden a ninguna pregunta concreta.

26.20 Qué debes recordar de este tema

• La abstracción consiste en mostrar lo importante para un propósito.
• Los diagramas conceptuales ayudan a comprender el dominio.
• Los diagramas de análisis ayudan a comprender requisitos y comportamiento esperado.
• Los diagramas de diseño ayudan a organizar la solución técnica.
• Un mismo tipo de diagrama puede usarse en distintos niveles.
• Mezclar niveles sin criterio produce confusión.
• El título y el propósito del diagrama deben orientar su lectura.

26.21 Conclusión

Los niveles de abstracción permiten usar UML de manera más precisa. Un diagrama conceptual, uno de análisis y uno de diseño pueden representar el mismo sistema, pero con preguntas y detalles diferentes. Elegir el nivel adecuado mejora la comunicación y evita modelos confusos.

En el próximo tema veremos errores frecuentes al modelar con UML y cómo evitarlos.