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 dicho 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. 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.

Etimológicamente, el término general 'diseño' se refiere a la representación de la o las propuestas que dan solución a un reto o problema planteado (designio). Es decir, significa la representación de un propósito (de algo aún no realizado), pero que requiere definir cómo se construye y de qué manera resuelve el problema. De igual forma, el verbo 'diseñar' es el proceso que conduce a esa representación, al diseño, e involucra acciones como la observación, la investigación, el análisis, el modelado y las pruebas, ajustes o adaptaciones previas a la producción definitiva. En ingeniería, "diseño" es el conjunto de especificaciones técnicas que definen la solución propuesta.

La asignatura se centra en el Diseño, donde se definen las 'piezas' y los mecanismos de funcionamiento —el cómo va a funcionar la aplicación, cada una de sus partes, y cómo se van a ensamblar para que funcione así—, las cuales 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 desarrollo 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.

Sin embargo, a no ser por las técnicas de modelado (y su representación), o por las relativas a cómo organizar las actividades en el proceso del diseño, las asignaturas precedentes a ésta capacitan completamente al estudiante para elaborar, con código, una solución que satisfaga los requisitos funcionales de un problema software (ver los programas de las asignaturas de programación, algoritmia, estructuras de datos, etc., que se referencian en el epígrafe de "Contextualización"). Quizás no sepa representarlo adecuadamente, pero ya lleva tiempo haciendo diseños. A partir de la asignatura Introducción a la Ingeniería de Software, esas capacidades para el manejo de los recursos de los lenguajes de programación convergen con un proceso sistemático del desarrollo y, sobre todo, con la valoración de ciertas cualidades de las soluciones buscadas: la independencia funcional, la adaptabilidad y la comprensibilidad de los diseños.

Por consiguiente, es extremadamente importante que el estudiante comprenda que, aunque esta asignatura incide en cómo organizar las actividades involucradas en el diseño, dentro de un proceso de desarrollo, y en cómo representar las conclusiones y artefactos obtenidos en ellas, no pretende detenerse en enseñar cómo obtener un diseño (algo para lo que el estudiante ya debe estar capacitado), sino que su objetivo principal es enseñar cómo conseguir que la solución funcional propuesta (el diseño) sea funcionalmente independiente, adaptable y comprensible. Todos los contenidos y materiales de estudio de esta asignatura están enfocados a este objetivo.

Si hubiera que definir una destreza única para esta asignatura, se reduciría a 'Asignar Responsabilidades a los Componentes del Software'. Un mayor nivel de abstracción, en la Arquitectura, la hace más adecuada para incorporar y verificar los atributos cualitativos que se quieren conseguir en el producto final. Pero éstos no se inyectan en los módulos de la arquitectura, sino que están imbricados en los elementos más atómicos de código que los constituyen (en el diseño detallado).

En cualquier modelo de ciclo de vida, la secuencia de construcción incluye el trinomio { Análisis y definición de requisitos — Diseño — Codificación }. El Diseño ni se puede realizar sin el Análisis ni tampoco estudiar el uno sin el otro. Mediante los Casos de Uso y el registro de la secuencia de las interacciones que se producen en cada uno de ellos (o los Diagramas de Secuencia del Sistema), 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 (funciones y métodos)? ¿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 responder alguna de las preguntas 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 la utilización de unos principios de diseño. Mediante el uso y la aplicación de los 'Principios Generales para Asignar Responsabilidades' —principios GRASP: General Responsibility Assignment Software Pattern—, en el ámbito controlado del Proceso Unificado, se consigue organizar la información del sistema en desarrollo de tal forma que ya resulte más fácil asignar responsabilidades. Únicamente a partir de este punto es posible introducir los 'patrones', progresivamente, en el diseño. Un patrón de diseño 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—. El autor del libro de esta asignatura llama patrones a los principios GRASP por hacer una analogía con el concepto fundamental del patrón de diseño en su aplicación a una familia de problemas y situaciones bien conocida 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, se tienen garantías de que el Diseño Arquitectónico incluya los atributos cualitativos deseados, y 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 de empresa 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.