Antes de construir una solución de software conviene comprender el problema, sus conceptos principales, sus reglas, sus actores, sus procesos y las relaciones entre sus partes. A esta actividad la llamamos análisis. Para comunicar y razonar sobre esa comprensión usamos modelos.
Un modelo es una representación simplificada de una parte de la realidad o de la solución. Puede ser un diagrama, una tabla, una lista estructurada, un prototipo o una descripción organizada. No muestra todo, sino aquello que necesitamos entender o discutir.
El análisis y el modelado ayudan a reducir ambigüedad, detectar errores temprano y construir software más alineado con las necesidades reales.
Analizar software significa estudiar el problema y la solución antes o durante la construcción para tomar mejores decisiones. No se trata solo de leer requisitos, sino de comprender qué ocurre en el dominio, qué necesitan los usuarios y qué condiciones debe respetar el sistema.
Durante el análisis se busca responder preguntas como:
Un modelo es una representación simplificada que ayuda a comprender, comunicar o evaluar una parte del sistema. Como el software es complejo e invisible, necesitamos modelos para hacerlo más manejable.
Ejemplos de modelos:
Un modelo no es la realidad completa. Es una herramienta para pensar y comunicar.
Los modelos pueden cumplir varios propósitos dentro de un proyecto:
Un buen modelo debe ayudar a decidir o comprender algo. Si no aporta claridad, probablemente necesita simplificarse o eliminarse.
La abstracción consiste en concentrarse en lo importante y dejar de lado detalles que no son necesarios para el objetivo actual. Es una habilidad central en análisis y modelado.
Por ejemplo, si estamos analizando un sistema de biblioteca, puede ser importante representar socios, libros, préstamos y devoluciones. Pero quizá no sea necesario representar el color de la tapa del libro si esa información no afecta el proceso.
El nivel de detalle depende de la pregunta que queremos responder:
Conviene distinguir entre modelos orientados al problema y modelos orientados a la solución.
| Tipo de modelo | Pregunta principal | Ejemplo |
|---|---|---|
| Modelo del problema | ¿Cómo funciona el dominio que queremos comprender? | Conceptos como socio, libro, préstamo y vencimiento. |
| Modelo de la solución | ¿Cómo organizaremos el sistema para resolver el problema? | Módulos de préstamos, catálogo, usuarios y notificaciones. |
Ambos son útiles, pero no deben confundirse. Primero conviene entender el problema; después se decide cómo resolverlo.
Existen muchos tipos de modelos. Algunos se enfocan en estructura, otros en comportamiento, otros en interacción o datos.
| Tipo | Qué representa | Ejemplo de uso |
|---|---|---|
| Modelo de dominio | Conceptos principales del negocio y sus relaciones. | Cliente, pedido, producto, pago y envío. |
| Modelo de procesos | Pasos de un flujo de trabajo. | Proceso de inscripción a un curso. |
| Modelo de casos de uso | Objetivos de actores al interactuar con el sistema. | Reservar turno, cancelar turno, consultar historial. |
| Modelo de datos | Información que debe almacenarse y relacionarse. | Tablas o entidades para alumnos, cursos e inscripciones. |
| Modelo de estados | Estados posibles de un objeto y transiciones. | Pedido pendiente, pagado, enviado, entregado o cancelado. |
| Modelo de arquitectura | Componentes principales y sus relaciones. | Frontend, API, base de datos y servicio de notificaciones. |
| Prototipo de interfaz | Aspecto o flujo de pantallas. | Boceto de pantalla de registro. |
Una clasificación útil distingue entre modelos estructurales y modelos de comportamiento.
| Tipo | Qué muestra | Ejemplo |
|---|---|---|
| Estructural | Elementos, conceptos, componentes y relaciones relativamente estables. | Un modelo de dominio con cliente, pedido y producto. |
| De comportamiento | Acciones, eventos, pasos, cambios de estado o interacción en el tiempo. | Un flujo para registrar una compra o un diagrama de estados de un pedido. |
Ambos se complementan. Saber qué conceptos existen no alcanza; también hay que entender cómo cambian e interactúan.
Un modelo es útil si mejora la comunicación. No debe hacerse solo para cumplir una formalidad. Un diagrama sencillo, bien explicado y validado con usuarios puede ser más valioso que un modelo muy completo que nadie entiende.
Al usar modelos para comunicar conviene:
El modelado ayuda a descubrir y mejorar requisitos. Al representar un proceso o concepto, pueden aparecer preguntas que no estaban claras.
Por ejemplo, al modelar una reserva, el equipo puede descubrir preguntas como:
Estas preguntas pueden convertirse en requisitos, reglas de negocio o criterios de aceptación.
El análisis se orienta a comprender el problema. El diseño se orienta a decidir cómo será la solución. El modelado puede participar en ambas actividades.
En análisis, un modelo puede mostrar cómo trabaja actualmente una organización. En diseño, puede mostrar cómo se organizará el sistema para soportar ese trabajo.
Ejemplo:
| Modelo de análisis | Modelo de diseño |
|---|---|
| Un pedido tiene cliente, productos, pago y estado. | El sistema tendrá módulos de catálogo, carrito, pagos y órdenes. |
| Un turno puede estar disponible, reservado, cancelado o atendido. | Se implementará una entidad Reserva con reglas de transición de estado. |
Los modelos también pueden formar parte de la trazabilidad. Un requerimiento puede estar relacionado con un proceso, una entidad del dominio, un caso de uso, una pantalla o una decisión de arquitectura.
Por ejemplo:
Esta relación permite comprender cómo cada modelo apoya decisiones concretas.
Supongamos que se analiza un sistema para gestionar cursos en línea.
Durante el análisis pueden identificarse conceptos como:
También pueden identificarse procesos:
Modelar estos elementos ayuda a detectar reglas, como: un alumno solo obtiene certificado si aprueba la evaluación final y completa las clases obligatorias.
Un error común es intentar modelar todo con máximo detalle desde el inicio. Otro error es no modelar nada y confiar únicamente en conversaciones informales. El nivel adecuado depende del riesgo, la complejidad y el uso del modelo.
Conviene aumentar el detalle cuando:
Conviene mantener modelos simples cuando el objetivo es explorar, conversar o validar una idea inicial.
Se pueden usar muchas herramientas para modelar. La herramienta importa menos que la claridad del modelo.
Lo importante es que el modelo pueda compartirse, entenderse y mantenerse cuando sea necesario.
Al analizar y modelar software suelen aparecer errores como:
Al comenzar a modelar, conviene aplicar algunas prácticas simples:
El análisis y el modelado permiten comprender mejor el problema antes de comprometer decisiones de construcción. Ayudan a descubrir requisitos, aclarar reglas, comunicar ideas y reducir el riesgo de construir una solución equivocada.
Para quien comienza, la idea principal es esta: modelar no significa dibujar por dibujar, sino representar lo necesario para entender, discutir y decidir mejor.
En el próximo tema veremos modelado de dominio y conceptos del negocio, una forma fundamental de comprender las entidades, relaciones y reglas principales del problema.