1. Introducción
La Ingeniería de Software no comienza con la escritura de código. Antes de construir una solución es necesario comprender el problema, representar el sistema, analizar alternativas y comunicar la solución propuesta.
Para realizar estas actividades, el Ingeniero de Software utiliza herramientas que permiten transformar ideas y requisitos en representaciones más precisas.
En esta lección estudiaremos tres grupos principales:
- Herramientas CASE (Computer-Aided Software Engineering)
- Lenguajes de modelado
- Herramientas de prototipado
Estas herramientas se utilizan principalmente durante las etapas de análisis y diseño, aunque también pueden acompañar otras fases del ciclo de vida del software.
2. Herramientas CASE
Las herramientas CASE (Computer-Aided Software Engineering) son aplicaciones diseñadas para proporcionar soporte automatizado a diferentes actividades de la Ingeniería de Software.
Su propósito es aplicar al desarrollo de software un principio similar al utilizado por otras disciplinas de ingeniería: utilizar herramientas especializadas para diseñar, documentar, analizar y controlar la construcción de un producto antes y durante su implementación.
Una herramienta CASE puede proporcionar soporte para actividades como:
- análisis de requisitos;
- modelado de procesos;
- diseño de sistemas;
- modelado de bases de datos;
- generación de diagramas;
- documentación;
- generación de código;
- ingeniería inversa;
- mantenimiento de modelos.
De manera general:
Necesidad del negocio
↓
Análisis
↓
Modelado
↓
Diseño
↓
Implementación
↓
Mantenimiento
↑
Herramientas CASE
Por tanto, CASE no representa una única aplicación, sino una categoría de herramientas que automatizan o facilitan actividades de Ingeniería de Software.
3. Clasificación de las herramientas CASE
Tradicionalmente, las herramientas CASE pueden clasificarse según las etapas del ciclo de vida que apoyan.
Upper CASE
Las herramientas Upper CASE se concentran principalmente en las primeras etapas del desarrollo.
Por ejemplo:
- análisis;
- requisitos;
- modelado de procesos;
- diseño conceptual;
- arquitectura.
REQUISITOS
↓
ANÁLISIS
↓
DISEÑO
↑
Upper CASE
Son especialmente útiles para representar el sistema antes de comenzar su construcción.
Lower CASE
Las herramientas Lower CASE proporcionan apoyo principalmente a etapas posteriores.
Pueden incluir funcionalidades relacionadas con:
- implementación;
- generación de código;
- pruebas;
- mantenimiento;
- ingeniería inversa.
IMPLEMENTACIÓN
↓
PRUEBAS
↓
MANTENIMIENTO
↑
Lower CASE
Integrated CASE
Las herramientas I-CASE (Integrated CASE) intentan integrar varias etapas del ciclo de desarrollo.
Requisitos
↓
Análisis
↓
Diseño
↓
Construcción
↓
Mantenimiento
↑
│
I-CASE
Un modelo es una representación simplificada de una realidad o de un sistema.
En Ingeniería de Software se utilizan modelos porque un sistema complejo puede resultar difícil de comprender directamente a partir de miles de líneas de código.
Considere un sistema compuesto por:
Clientes
Usuarios
Productos
Ventas
Facturas
Inventario
Pagos
Reportes
Servicios externos
En lugar de intentar comprender inmediatamente su implementación, podemos construir diferentes modelos que representen determinadas perspectivas del sistema.
SISTEMA
│
┌────────────┼────────────┐
↓ ↓ ↓
Procesos Datos Software
↓ ↓ ↓
BPMN ERD UML
Cada modelo responde a preguntas diferentes.
5. ¿Por qué modelamos software?
El modelado permite reducir la complejidad mediante abstracción.
Un buen modelo no necesariamente representa todos los detalles del sistema. Representa aquellos elementos que son importantes para el objetivo del análisis.
Por ejemplo, si queremos comprender quién interactúa con un sistema:
Cliente ──────→ Sistema de Ventas
↑
Vendedor ────────────┘
Si queremos comprender sus componentes:
Frontend
↓
Backend
↓
Base de Datos
Y si queremos comprender los datos:
CLIENTE
│
└──── realiza ──── VENTA
│
└──── DETALLE_VENTA
Los tres modelos pueden representar el mismo sistema desde perspectivas diferentes.
6. UML
UML (Unified Modeling Language) es uno de los lenguajes de modelado más conocidos en Ingeniería de Software.
UML proporciona diferentes tipos de diagramas para representar aspectos estructurales y de comportamiento de un sistema.
Entre los diagramas más utilizados se encuentran:
Diagrama de casos de uso
Representa las funcionalidades del sistema desde la perspectiva de sus actores.
Sistema de Ventas
Cliente ─────→ (Realizar compra)
Vendedor ────→ (Registrar venta)
Administrador → (Gestionar productos)
Permite responder principalmente:
¿Qué puede hacer cada actor dentro del sistema?
Diagrama de clases
Representa clases, atributos, operaciones y relaciones.
┌─────────────────┐
│ Cliente │
├─────────────────┤
│ idCliente │
│ nombre │
│ documento │
├─────────────────┤
│ registrar() │
└─────────────────┘
│
│ realiza
▼
┌─────────────────┐
│ Venta │
├─────────────────┤
│ idVenta │
│ fecha │
│ total │
└─────────────────┘
Diagrama de secuencia
Representa la interacción entre componentes a través del tiempo.
Usuario Sistema Base de Datos
│ │ │
│── Login ────→│ │
│ │── Consultar ───→│
│ │←── Usuario ─────│
│←─ Resultado ─│ │
Diagrama de actividades
Representa flujos de actividades y decisiones.
Inicio
↓
Seleccionar producto
↓
¿Existe stock?
│
┌┴─────────┐
Sí No
↓ ↓
Registrar Mostrar
venta mensaje
↓
Fin
UML contiene otros diagramas, como componentes, despliegue, estados, objetos y paquetes.
7. Modelado de procesos con BPMN
Mientras UML está orientado principalmente al modelado de sistemas, BPMN (Business Process Model and Notation) está especialmente orientado a representar procesos de negocio.
Por ejemplo:
Cliente Ventas Almacén
│ │ │
Solicita
producto
│───────────────→│
│── Verificar ───→│
│←── Stock ───────│
│
Registrar venta
│
│←── Confirmar ──│
BPMN permite representar:
- actividades;
- eventos;
- decisiones;
- participantes;
- mensajes;
- secuencias;
- procesos alternativos.
Antes de automatizar un proceso es importante comprender cómo funciona el negocio que será soportado por el software.
8. Modelado de datos
Las herramientas de modelado también permiten representar la estructura de los datos.
Uno de los modelos más conocidos es el Modelo Entidad-Relación (MER o ERD).
Por ejemplo:
CLIENTE
----------------
IdCliente
Nombre
Documento
│
│ 1
│
│ N
▼
VENTA
----------------
IdVenta
Fecha
Total
IdCliente
Este tipo de representación ayuda a definir:
- entidades;
- atributos;
- relaciones;
- cardinalidades;
- identificadores;
- restricciones.
Posteriormente, estos modelos pueden servir como base para implementar una base de datos.
9. Modelado de arquitectura
Los modelos también pueden utilizarse para representar la arquitectura de una aplicación.
Por ejemplo:
┌──────────────────────┐
│ FRONTEND │
│ Next.js │
└──────────┬───────────┘
│ HTTPS
▼
┌──────────────────────┐
│ BACKEND │
│ API REST │
└──────────┬───────────┘
│
▼
┌──────────────────────┐
│ BASE DE DATOS │
│ SQL Server │
└──────────────────────┘
Para arquitectura de software pueden utilizarse modelos como C4, que propone diferentes niveles de abstracción:
Nivel 1 → Contexto
Nivel 2 → Contenedores
Nivel 3 → Componentes
Nivel 4 → Código
La idea es comenzar con una visión general y progresivamente mostrar mayor detalle.
10. Herramientas utilizadas para modelado
Existen numerosas aplicaciones para construir modelos y diagramas.
| Herramienta | Aplicaciones frecuentes |
|---|---|
| diagrams.net / Draw.io | Diagramas generales, arquitectura, UML |
| Lucidchart | Diagramación colaborativa |
| Visual Paradigm | UML, BPMN, ERD y modelado de software |
| Enterprise Architect | Modelado y arquitectura empresarial |
| PlantUML | Diagramas definidos mediante texto |
| Mermaid | Diagramas mediante sintaxis textual |
| ERDPlus | Modelado de bases de datos |
| Microsoft Visio | Diagramación general y procesos |
Algunas son herramientas especializadas en Ingeniería de Software, mientras que otras son herramientas generales de diagramación.
11. Herramientas de prototipado
Un prototipo es una representación preliminar de un producto que permite explorar y validar una solución antes de construir completamente el sistema.
Supongamos que el equipo necesita desarrollar una aplicación móvil.
Una alternativa sería:
Requisitos
↓
Programación
↓
Aplicación terminada
↓
Usuario la prueba
↓
"Esto no era lo que necesitaba"
En este escenario, descubrir un problema demasiado tarde puede generar un alto costo de modificación.
El prototipado permite introducir una etapa previa:
Requisitos
↓
Prototipo
↓
Validación con usuario
↓
Correcciones
↓
Desarrollo
El objetivo es obtener retroalimentación antes de invertir completamente en la implementación.
12. Wireframes
Un wireframe es una representación básica de una interfaz.
Su objetivo principal es establecer:
- distribución;
- jerarquía;
- navegación;
- ubicación de componentes.
Por ejemplo:
┌─────────────────────────────────┐
│ LOGO USUARIO │
├─────────────────────────────────┤
│ │
│ SISTEMA DE VENTAS │
│ │
│ Producto: [____________] │
│ │
│ Cantidad: [____] │
│ │
│ [ AGREGAR ] │
│ │
├─────────────────────────────────┤
│ TOTAL: Bs. 250 │
│ │
│ [ CONFIRMAR ] │
└─────────────────────────────────┘
El wireframe no necesita tener la apariencia definitiva del sistema.
Su propósito principal es analizar la estructura de la interfaz.
13. Mockups
Un mockup proporciona una representación visual con mayor nivel de detalle.
Puede incluir:
- colores;
- tipografías;
- iconos;
- imágenes;
- espaciados;
- estilos;
- componentes visuales.
Podemos considerar:
Wireframe
↓
Estructura
Mockup
↓
Apariencia
El mockup permite aproximarse visualmente al producto final sin necesidad de desarrollar todavía toda su funcionalidad.
14. Prototipos interactivos
Un prototipo interactivo permite simular la navegación y determinadas interacciones.
Por ejemplo:
┌─────────────┐
│ LOGIN │
│ │
│ [Ingresar] │
└──────┬──────┘
│ click
▼
┌─────────────┐
│ INICIO │
│ │
│ [Productos] │
└──────┬──────┘
│ click
▼
┌─────────────┐
│ PRODUCTOS │
│ │
│ [Nuevo] │
└─────────────┘
El usuario puede experimentar un flujo parecido al sistema real aunque todavía no exista la aplicación completamente implementada.
Esto resulta especialmente útil para evaluar:
- navegación;
- comprensión;
- experiencia de usuario;
- organización de información;
- flujos principales.
15. Fidelidad de los prototipos
Los prototipos pueden clasificarse según su nivel de fidelidad.
Baja fidelidad
Son representaciones simples.
Pueden realizarse mediante:
- papel;
- pizarras;
- diagramas;
- wireframes sencillos.
Su ventaja es la rapidez.
Baja fidelidad
↓
Rápida
↓
Barata
↓
Fácil de modificar
Alta fidelidad
Intentan aproximarse más al producto final.
Pueden incluir:
- diseño visual completo;
- navegación;
- animaciones;
- componentes;
- interacciones.
Son especialmente útiles cuando se necesita evaluar con mayor precisión la experiencia propuesta.
16. Herramientas de prototipado
Entre las herramientas conocidas para diseño y prototipado encontramos:
| Herramienta | Uso |
| Figma | Diseño de interfaces y prototipos colaborativos |
| Penpot | Diseño y prototipado de interfaces |
| Balsamiq | Wireframes de baja fidelidad |
| Axure RP | Prototipos interactivos y complejos |
| Sketch | Diseño de interfaces |
| Framer | Diseño y prototipos interactivos |
Estas herramientas permiten construir representaciones visuales antes de implementar completamente la interfaz.


¿cuáles son los diagramas UML que se consideran estrictamente indispensables documentar antes de pasar a la fase de implementación para no caer en sobrecarga de documentación?
En un diagrama UML de secuencia, ¿cuál es la diferencia conceptual entre un mensaje sincrónico y uno asincrónico a nivel de ejecución?
¿Cuál es el propósito fundamental de las herramientas CASE en la Ingeniería de Software?