Tema 0-1: Introducción a la Ingeniería del Software y al Modelado

Resumen Ejecutivo En esta sesión introductoria se establecen los fundamentos de la disciplina, diferenciando el software del resto de ingenierías debido a su naturaleza inmaterial y cambiante. Se analiza la evolución histórica de los costes y paradigmas (Estructurado vs. Orientado a Objetos) y se introduce UML no como un proceso, sino como el lenguaje estándar para modelar sistemas mediante diagramas de estructura y comportamiento.

1. Naturaleza y Evolución del Software

Definición Formal

El software no es solo código. Se define como el conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático.

El Coste del Software vs. Hardware

Históricamente, ha habido un cambio drástico en la distribución de costes: * Años 60: El hardware era lo costoso; el software era un añadido menor. * Actualidad: El coste del software supera ampliamente al del hardware. * Desarrollo vs. Mantenimiento: Hace 40 años, crear software nuevo costaba tanto como mantenerlo. Hoy en día, la inmensa mayoría del coste y esfuerzo se dedica al mantenimiento (evolución) de software existente, no a la creación desde cero.

La Curva de Fallos: Hardware vs. Software

Esta es una diferencia fundamental que justifica la necesidad de una ingeniería propia:

Hardware (Curva de Bañera): Tiene una alta tasa de fallos inicial ("mortalidad infantil"), luego se estabiliza, y finalmente sube debido al desgaste físico y deterioro ambiental.
Software (Curva Ideal vs. Real):
- Idealmente: Los fallos bajan tras corregir los errores iniciales y se mantienen estables. El software no se rompe físicamente.
- Realidad (Curva de Deterioro): El software sufre cambios continuos (actualizaciones). Cada cambio introduce nuevos errores, provocando picos de fallos que elevan la tasa base. El software no se desgasta, se deteriora debido al cambio.

Explicación del Profesor: A diferencia de un túnel o un coche, donde el entorno físico (la montaña) no cambia, en el software el "dominio del problema" cambia constantemente. El cliente cambia de opinión o el entorno de negocio evoluciona, lo que obliga a modificar el software constantemente, introduciendo el deterioro.

Complejidad Creciente

La complejidad ha explotado exponencialmente. * Ejemplo: Windows 3.1 (1993) tenía ~4 millones de líneas de código. Windows 10 (2015) tiene ~80 millones. Google maneja repositorios de ~2.000 millones de líneas.

2. Ingeniería del Software: Definición y Capas

La Ingeniería del Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software.

El Enfoque Multicapa (La Pila)

La ingeniería se apoya en cuatro pilares, de abajo a arriba: 1. Enfoque de Calidad: La base de todo. Cualquier proceso busca que el resultado sea mejor, más mantenible y barato. 2. Proceso: El marco de trabajo que une las capas (qué se hace y cuándo). 3. Métodos: Las técnicas técnicas para hacer las cosas (cómo se hace: ej. análisis de requisitos, diseño). 4. Herramientas: El soporte automático o semi-automático para los procesos y métodos (ej. CASE, IDEs).

El Método de Ingeniería Adaptado

El ciclo clásico de ingeniería se adapta al software en tres fases generales: 1. Definición (Qué): Formulación y análisis del problema. Recolección de requisitos (Entender qué necesita "Fruterías Paqui"). 2. Desarrollo (Cómo): Diseño del sistema y codificación. Búsqueda de la mejor solución técnica e implementación. 3. Soporte: Mantenimiento y gestión del cambio.

3. Metodologías: Estructuradas vs. Orientadas a Objetos (OO)

Esta es una distinción crítica para el examen sobre cómo abordar el diseño del software.

Paradigma Estructurado (Antiguo)

Enfoque: Separa drásticamente los Datos de los Procesos (Funciones).
Flujo: Análisis (DFD, Diagramas de Flujo de Datos) Diseño (Estructura de tablas/Relacional) Implementación.
Concepto Clave: Funciona por Transformación. Pasas de un lenguaje a otro mediante reglas estrictas (ej. pasar de Entidad-Relación a Tablas SQL tiene reglas fijas).

Paradigma Orientado a Objetos (Moderno)

Enfoque: Integra datos y procesos en Objetos. Es más cercano a la realidad.
Flujo: Análisis (Clases) Diseño (Clases refinadas) Implementación (Clases codificadas).
Concepto Clave: Funciona por Evolución (o Elaboración). No se transforma drásticamente; el modelo crece y se detalla. Un objeto Cliente en el análisis sigue siendo un Cliente en el código, pero con más detalle.

4. UML (Unified Modeling Language)

¿Qué es y qué NO es?

Es: Un LENGUAJE estándar para visualizar, especificar, construir y documentar. Es un conjunto de "dibujos" estandarizados para comunicarnos.
NO es: No es una metodología ni un proceso. No te dice cómo trabajar, te da los símbolos para expresarte.

Historia: Los "Tres Amigos"

UML nace de la unificación de tres métodos de los años 90: 1. OMT (Rumbaugh) - Orientado a datos. 2. Objectory (Jacobson) - Orientado a casos de uso/requerimientos. 3. Booch (Grady Booch) - Orientado a diseño/implementación. Ellos crearon el Proceso Unificado (UP) y el lenguaje UML. Aunque el Proceso Unificado ya casi no se usa (superado por Ágiles), UML sigue siendo el estándar industrial.

Tipos de Diagramas UML

Se dividen en dos grandes categorías:

A. Diagramas de Estructura (Estáticos)

Representan "lo que hay" en el sistema. * Diagrama de Clases: El más importante. Muestra las clases y sus relaciones. * Diagrama de Componentes: Partes modulares del sistema. * Diagrama de Despliegue: Hardware y nodos donde se ejecuta el software. * Diagrama de Paquetes: Organización lógica del código.

B. Diagramas de Comportamiento (Dinámicos)

Representan "lo que hace" el sistema o cómo cambia. * Casos de Uso: Qué hace el sistema desde el punto de vista del usuario (funcionalidad). * Secuencia: Interacción entre objetos a lo largo del tiempo (mensajes). Nota del profesor: No le gustan, prefiere los de actividad, pero entran en temario. * Actividad: Flujo de trabajo paso a paso (similar a diagramas de flujo). * Máquina de Estados: Cómo cambia un objeto según eventos (ej. un pedido pasa de "pendiente" a "pagado").

¡OJO AL DATO! (Pistas de Examen)

Estructura del Examen: El profesor mencionó que suele poner una parte tipo test (teoría) y una parte de "Supuestos Teórico-Prácticos".
Ejercicio Clave: Un ejercicio recurrente es presentar un Diagrama de Clases (UML) y pedir al alumno que lo "traduzca" a texto.
- Ejemplo: Ver un diagrama con una clase Ventana que contiene dos Botones y explicar: "La clase Ventana agrega dos instancias de la clase Botón, y si se destruye la Ventana, se destruyen los Botones (composición)".
Concepto de Transformación vs. Elaboración: Es vital entender que las metodologías estructuradas funcionan por transformación (cambio de reglas entre fases) y las Orientadas a Objetos por elaboración/evolución (refinamiento continuo).

Preguntas de Autoevaluación

¿Cuál es la diferencia fundamental entre la curva de fallos del hardware y la del software real?
- Respuesta: El hardware sigue la curva de bañera (desgaste físico). El software idealmente se estabiliza, pero en la realidad su tasa de fallos aumenta debido a los efectos colaterales de los cambios (deterioro por evolución), no por desgaste físico.
¿UML es una metodología de desarrollo?
- Respuesta: No. UML es un lenguaje de modelado. El Proceso Unificado es la metodología/proceso. UML solo proporciona la notación estándar para comunicarse.
Explica la diferencia entre el paso de Análisis a Diseño en el enfoque Estructurado vs. el enfoque Orientado a Objetos.
- Respuesta: En el estructurado, se produce una transformación (cambio de notación y reglas, ej. DFD a Tablas). En Orientado a Objetos, se produce una elaboración o evolución (el objeto identificado en análisis se enriquece con detalles técnicos en el diseño, pero sigue siendo el mismo objeto).
Si quiero representar cómo interactúan físicamente los servidores y los nodos de los clientes en mi sistema, ¿qué diagrama UML debo usar?
- Respuesta: Diagrama de Despliegue (Diagrama de estructura).