Presentación

Programar una aplicación sencilla es fácil y puede ser incluso divertido. Pero la fabricación profesional de Software exige productos de funcionalidad generalmente sofisticada, con prestaciones y valores cualitativos que lo provean de ventajas competitivas en el mercado —lo que se denomina objetivos de negocio—. Y hacerlo requiere un buen número de destrezas y habilidades adicionales.

Ningún recurso es ilimitado y todos tienen un coste. Las tecnologías de desarrollo que se usen en la fabricación —y cómo se utilicen— repercuten en el coste. Precisamente hacia esto se enfoca la Ingeniería —en concreto, la Ingeniería del Producto Software—, que incorpora paradigmas en la producción como modularidad, flexibilidad, mantenibilidad, reusabilidad, desacoplamiento o genericidad. Porque no hay que olvidar que los objetivos de negocio se traducen en un balance entre las prestaciones del producto —su funcionalidad, sus restricciones y sus atributos, cualitativos o no— y sus costes.

En cualquier modelo de ciclo de vida, la secuencia de construcción incluye el trinomio Análisis y definición de requisitos, Diseño y Codificación. La asignatura se centra en el Diseño, donde se definen las 'piezas' y los mecanismos de funcionamiento —el cómo—, que van a implementar la totalidad de las prestaciones del producto. Buena parte de las características que se exigen actualmente al Software aconsejan —para que los costes sean razonables— afrontar el desarollo utilizando tecnologías que se basen en la orientación a objetos. Por tanto, el Diseño significa definir elementos de código —las clases—, lo que hacen, cómo lo hacen y cómo colaboran unas partes con otras.

Si hubiera que definir una destreza única para esta asignatura, se reduciría a 'Asignar Responsabilidades a los Componentes del Software'. El mayor nivel de abstracción en la Arquitectura la hace más adecuada para incorporar y verificar los atributos cualitativos.

El Diseño no se puede realizar sin el Análisis y tampoco estudiar el uno sin el otro. Mediante los Casos de Uso y los Diagramas de Secuencia, la OO establece unas pautas bien definidas para derivar los requisitos, que serán las 'cerchas' para la construcción del Diseño Detallado. Pero aún quedan muchas preguntas sin resolver en el Diseño: ¿Qué componentes definimos? ¿Cómo les asignamos responsabilidades? ¿Por dónde empezamos, por la Arquitectura o por el Diseño Detallado? ¿Como incorporamos en el sistema los requisitos no funcionales —los atributos cualitativos— para alcanzar los objetivos de negocio?

El modelo de ciclo de vida iterativo se adecúa mucho mejor al comportamiento real del proceso de fabricación y favorece el refinamiento progresivo, que ayuda a paliar algunos de los problemas anteriores. Es el modelo que utiliza la asignatura, una simplificación del Proceso Unificado, que establece un camino bien definido para eliminar la incertidumbre del estudiante sobre qué debe hacer en cada instante del desarrollo.

Para resolver el objetivo principal —qué componentes definimos y cómo asignamos sus responsabilidades—, el núcleo de acero de la asignatura es el uso de los patrones de diseño. Un patrón es una solución contrastada y comprobada con éxito para una familia de problemas, y a la que se ha llegado tras catalogar un buen número situaciones y 'destilar' las soluciones en un único resultado abstracto. La asignatura no está enfocada al estudio profundo del catálogo de patrones ni a su aplicación —un libro de referencia es "Design Patterns", de Gamma, Helm, Johnson y Vlissides; la llamada 'Pandilla de los Cuatro', GoF—. La andadura controlada del Proceso Unificado permite introducir los patrones progresivamente, pero sólo a partir del punto en que tengamos la información organizada de tal forma que ya resulte más fácil asignar responsabilidades mediante los 'Principios Generales para Asignar Responsabilidades' —patrones GRASP: General Responsibility Assignment Software Pattern—. El autor los llama patrones por hacer una analogía con el concepto fundamental del patrón de diseño pero, cada GRASP, es un principio o directriz para realizar el diseño. Los principios GRASP enseñan a asignar responsabilidades de manera que el diseño incorpore las especificaciones funcionales y algunos de los atributos cualitativos deseados. Tras los principios GRASP, los patrones GoF más comunes enriquecen el diseño con los atributos que faltaban y favorecen el refinamiento de los que ya estaban. Nótese que esta manera de trabajar construye, de manera simultánea y coherente, el Diseño Detallado y la Arquitectura. Si se aplican correctamente los principios GRASP y los patrones, se tienen garantías de que el Diseño Arquitectónico incluye los atributos cualtitativos deseados, se puede evaluar y refinar para mejorar tanto el comportamiento del sistema como el cumplimiento de los objetivos de negocio.

Contextualización

Esta asignatura forma parte de la materia de Ingeniería de Software —con 18 ECTS—, tiene carácter obligatorio y se sitúa en el quinto semestre del Grado en Ingeniería Informática. Su contribución al perfil profesional del Título está directamente vinculado al calificativo 'Ingeniería' de su nombre y, con ello, su incidencia en las competencias, destrezas y habilidades relacionadas, simultáneamente, con la Ingeniería y el Desarrollo de Software.

Es el colofón para las asignaturas fundamentales orientadas al Desarrollo de Software, cuya trayectoria se inicia, en los primeros cursos, con las asignaturas relacionadas con los fundamentos de programación, las estructuras de datos y la algoritmia. Sus contenidos son más de tipo fundamental y metodológico que tecnológico; aunque sus enseñanzas estén estrechamente relacionadas y cimentadas con otras asignaturas que sí lo son —como 71901014 - Fundamentos de Sistemas Digitales; 71901066, 71902025 y 71012018 - Ingeniería de Computadores I, II y III; etc.—.

El antecedente inmediato de esta asignatura es 71902077 - Introducción a la Ingeniería de Software, en la que se accede a la antesala de las tecnologías de fabricación del Software como un producto comercial. El Diseño es una de las fases del desarrollo y es contigua a la codificación, la más directamente relacionada con lo que entendemos como Programación. Sin embargo, en este ámbito, la codificación se une a la intención ingenieril para convertirse en tecnologías que pretenden obtener del producto valores y cualidades adicionales que lo hagan competitivo. Por ello, es muy interesante relacionar esta asignatura con los conceptos de producción y objetivos empreses a través de 71902031 - Gestión de Empresas Informáticas.

En lo que respecta a la Programación, el estudio del Diseño como vía para obtener ventajas y mejoras en los productos, no se puede abordar sin los paradigmas de la Orientación a Objetos, como ya se ha argumentado en la presentación. Por eso, la asignatura 71901072 - Programación Orientada a Objetos, es una referencia obligada.

En la frontera superior se encuentran otras asignaturas, obligatorias y optativas, con carácter tecnológico e ingenieril. Pero es en el octavo semestre donde se culmina la materia de Ingeniería de Software con la asignatura 71014052 - Gestión de Proyectos Informáticos, con una visión integradora desde la gestión de todas las actividades.