Diseño de Software (Primer semestre, tercer curso)
Código 71013035. 6 créditos
 |
Grado en Ingeniería Informática |
 |
|
|
Grado en Ingeniería Informática |
|
Código 71013035. 6 créditos
Programar una aplicación sencilla es fácil y puede ser incluso divertido; sobre todo, si se hace de forma lúdica. Bastaría con idear algoritmos que automaticen las tareas del problema y traducirlos a código mediante un lenguaje conocido, cuyos recursos se dominen. Pero sumergirse en una cadena de fabricación para producir software 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 del cliente y del desarrollador—, es algo bien distinto. Por supuesto, el primer objetivo que debe cumplir el producto es que se comporte con la funcionalidad nuclear, definida y acordada para la que se concibió. Pero ningún recurso es ilimitado y todos tienen un coste. La manera en que se fabrique el producto —es decir, qué tecnologías de desarrollo se usen y cómo se utilicen—, incluso para lograr alcanzar ese 'primer objetivo', repercuten en el coste. Tanto más la incorporación de aquellos atributos cualitativos que lo hagan competitivo en el dominio del negocio. 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. En definitiva, 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.
Sea cual sea el ciclo de vida utilizado, la secuencia de construcción es el trinomio Análisis y definición de requisitos, Diseño y Codificación. Antes de codificar, es 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. Actualmente son primordiales los objetivos como la adaptabilidad, independencia de la plataforma de uso, mantenibilidad y reusabilidad; características que, por ahora, sólo es viable afrontar 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 Diseño Arquitectónico trabaja con los componentes o módulos principales del producto y define la implementación de la mayor parte de sus atributos, que se resuelven en el Diseño Detallado. Ese mayor nivel de abstracción en la Arquitectura la hace más adecuada para incorporar y verificar los atributos cualitativos.
Sin embargo, antes de asignar responsabilidades o de crear sus receptores, es obligado conocer y concluir qué comportamiento, funcionalidad o atributo deseado para el sistema, motiva esa labor. El Diseño no se puede realizar sin el Análisis. 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. En la fase de Análisis, la obtención de requisitos no es cerrada ni se comporta linealmente: el cliente no expone sus necesidades de forma definitiva, de manera que el analista pueda deducir los requisitos completamente, idear una solución conceptual y, acto seguido, pueda comenzarse el trabajo de diseño. En el Diseño también hay múltiples cuestiones sin resolver: ¿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?
Actualmente, salvo excepciones muy concretas, el proceso de desarrollo no es tan rígido y secuencial como el ciclo de vida en cascada. Un modelo iterativo se adecua mucho mejor al comportamiento real del proceso de fabricación. Además, el refinamiento progresivo —a base de idas y venidas por la secuencia Análisis y definición de requisitos, Diseño y Codificación— ayuda a paliar algunos de los problemas anteriores. En la asignatura se utiliza un modelo evolutivo, 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. De esta manera, es posible centrar la atención sobre el cómo hay que hacer las cosas para resolver el resto de los problemas planteados.
Para alcanzar el objetivo principal —qué componentes definimos y cómo asignamos sus responsabilidades—, el núcleo de acero de la asignatura es el uso de unos principios de diseño, denominados GRASP, que posibilitarán la comprensión del proceso de diseño y la aplicación adecuada de los patrones de diseño. Aunque pueda decirse que la Programación y la Ingeniería de Software son jóvenes aún, ya se han estudiado innumerables situaciones de codificación y soluciones Software a los problemas. Fruto del rigor de esos estudios, se ha conseguido catalogar un buen número de problemas y se ha llegado a 'destilar' las soluciones hasta que cada resultado, abstracto, es una buena solución —contrastada y comprobada con éxito— para una familia de problemas concretos. Eso es un patrón. En realidad, se está enmascarando la respuesta al objetivo de la asignatura porque: en lugar de reinventar la rueda en cada caso, utilizamos una solución genérica de éxito probado; pero esto nos obliga a saber identificar a qué familia del catálogo pertenece nuestro problema, qué patrón es el que se aplica y cómo se ajusta para resolverlo. Y ya hay una miríada de patrones.
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 nos permite introducir los patrones progresivamente, pero sólo a partir del punto en que tenemos 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—. Los nueve patrones GRASP enseñan a asignar responsabilidades de manera que el diseño incorpore las especificaciones funcionales y algunos de los atributos cualitativos deseados. Además, el uso de esos patrones —que se incorporan progresivamente, durante la primera y la segunda iteracción— prepara el sistema para que se enriquezca con patrones GoF. De los 23 patrones GoF presentados por Gamma, en la asignatura se estudia cómo se aplican y utilizan los 15 más comunes. Los patrones GoF se aplican durante la 2ª y 3ª iteración y añade al diseño los atributos que faltaban y facilita 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 patrones, se tienen garantías de que el Diseño Arquitectónico incluya los atributos cualitativos deseados y, a partir de la 3ª iteración, la Arquitectura se puede evaluar y refinar para mejorar el comportamiento del sistema y el cumplimiento de los objetivos de negocio.
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. Esos 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.—. Con relación al desarrollo del software, en estas asignaturas se aprende a manejar los recursos de un lenguaje de programación, a crear algoritmos que realicen determinadas tareas simples, a organizar la información y los datos en estructuras útiles que, junto a los recursos del lenguaje, permiten construir código e implementar esos allgoritmos de manera que satisfagan unos requisitos funcionales sencillos.
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, también es una referencia obligada. En esta asignatura se aprende a incorporar las peculiaridades funcionales de los objetos, el encapsulamiento de su actividad junto con la estructura de la información que manejan, su privacidad y ocultación, la herencia, el polimorfismo, etc., en la elaboración de ese código que satisface unos requisitos funcionales sencillos.
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. En primer lugar, la Ingeniería del Software organiza las actividades del proceso de desarrollo para permitir su visibilidad, planificación y seguimiento: el ciclo de vida. 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 empresariales a través de 71902031 - Gestión de Empresas Informáticas. Las características cualitativas que, para incrementar el valor del producto software, se buscan al aplicar los procedimientos recomendados por la Ingeniería de Software, se refieren a dos ámbitos estrechamente relacionados entre sí:
El propio proceso del desarrollo: planificación, controlabilidad, tiempo y otros costes del desarrollo, economía de recursos, rendimiento, etc.
El producto final: no sólo su funcionalidad, o que cumpla con los requisitos de aceptación, sino su adaptabilidad y su facilidad para modificarlo y adecuarlo a las condiciones más ventajosas; la comprensibilidad de su funcionamiento, su facilidad de uso, etc. Estas cualidades dependen directamente de cómo esté hecho el código y, más concretamente, de cómo se organice su funcionalidad y el comportamiento que produce dicha organización. Es decir, del diseño.
Los resultados del aprendizaje en la asignatura de Introducción a la Ingeniería de Software que más afectan a ésta de Diseño de Software son: qué es diseño y qué se debe obtener con el diseño.
El diseño es una representación del contenido del producto final, de su código. Es una especificación técnica que define todos los elementos que componen el código, el funcionamiento de cada uno, cómo se organizan para colaborar entre sí y generar el comportamiento deseado (el que satisface los requisitos funcionales).
El diseño (o la especificación del código, de sus elementos y su funcionamiento) necesita ser: funcionalmente independiente (con acoplamiento débil y cohesión alta), comprensible (facilitar la comprensión de su organización y funcionamiento) y adaptable (flexible y fácilmente modificable).
Sin embargo, en la asignatura de Introducción a la Ingeniería de Software no se aprende cómo se hace el diseño para conseguir esos objetivos, que es el principal objetivo de la asignatura Diseño de Software.
Por todo ello, la asignatura incide en las siguientes competencias:
Genéricas y Transversales (comunes a los grados de la UNED):
Competencias de gestión y planificación: Iniciativa y motivación. Planificación, coordinación y organización (establecimiento de objetivos y prioridades, secuenciación y organización del trabajo y el tiempo de realización, etc.).
Competencias cognitivas superiores: selección y manejo adecuado de conocimientos, recursos y estrategias cognitivas de nivel superior apropiados para el afrontar y resolver diversos tipos de problemas planteados en el desarrollo de software, con distinto nivel de complejidad y novedad:
Competencias de gestión de la calidad y la innovación: Seguimiento y evaluación del trabajo. Aplicación de medidas de mejora. Innovación.
Competencias de expresión y comunicación (a través de distintos medios y con distinto tipo de interlocutores): Comunicación y expresión matemática, científica y tecnológica.
Competencias en el uso de las herramientas y recursos de la Sociedad del Conocimiento: Manejo de las TIC. Competencia en la búsqueda de información relevante. Competencia en la recolección, gestión y organización de la información y los datos.
Trabajo colaborativo:
Compromiso ético. Se fomentan actitudes y valores éticos, especialmente vinculados a un desempeño profesional ético. En un entorno competitivo, se previene contra la utilización ilícita de materiales y tecnologías con derechos de propiedad; animando a las soluciones originales o al planteamiento de la subcontratación.
Específicas:
Capacidad para diseñar, desarrollar, seleccionar y evaluar, aplicaciones software, asegurando su fiabilidad, seguridad y calidad, conforme a los principios éticos y a la legislación y normativa vigente.
Capacidad para implantar y peritar proyectos, servicios y sistemas software, liderando su puesta en marcha y mejora continua y valorando su impacto económico y social.
Capacidad para comprender la importancia de la negociación, los hábitos de trabajo efectivos, el liderazgo y las habilidades de comunicación en entornos de desarrollo de software.
Capacidad para analizar, diseñar, construir y mantener aplicaciones de forma robusta, segura y eficiente.
Conocimiento y aplicación de los principios, metodologías y ciclos de vida de la ingeniería de software.
Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la Ingeniería del Software.
Capacidad para identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teorías, modelos y técnicas actuales.
Las competencias anteriores son complejas. En algunos casos, la asignatura matiza y complementa aspectos que ya se han desarrollado parcialmente en las asignaturas mencionadas más arriba. En otros casos, aporta y desarrolla completamente facetas concretas de cada competencia; en particular las que se refieren al análisis y diseño orientados al desarrollo robusto y eficiente de productos de calidad, a su mejora y valoración para su implantación o peritación.
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.
La formación previa que deberían tener los alumnos para el adecuado seguimiento de esta asignatura es la propia del segundo curso de este Grado. En concreto:
Conocimiento y experiencia en algún lenguaje de programación orientado a objetos. En particular, Java.
Conocimiento de los conceptos generales de la tecnología de objetos: clase, instancia, interfaz, abstracción, polimorfismo, encapsulación y herencia.
Estos conocimientos y destrezas se pueden adquirir mediante las asignaturas "71901020 - Fundamentos de Programación" y "71901072 - Programación Orientada a Objetos".
Para poder entender y aprovechar la acusada intención ingenieril de esta asignatura, es muy recomendable conocer los principios fundamentales de la Ingeniería de Software. La asignatura "71902077 - Introducción a la Ingeniería de Software" proporciona la formación necesaria para asimilar los aspectos de Ingeniería del Desarrollo de Software que se tratan en esta asignatura.
Con carácter general, el estudiante debe adquirir el conocimiento necesario para pasar desde el desarrollo de aplicaciones sencillas, a partir de especificaciones funcionales —u otras de tipo técnico—, a saber cómo incorporar atributos cualitativos que le permitan construir software robusto, mantenible, de altas prestaciones, calidad competitiva y costes razonables. Como resultado del aprendizaje de los contenidos de esta asignatura, el alumnado estará en la situación siguiente:
Conoce la Ingeniería de Requisitos y las técnicas específicas de diseño de software enfocadas al desarrollo orientado a objetos.
Establece la relación entre el diseño software y la facilidad con que se alcanzan las restricciones técnicas y atributos cualitativos del sistema. Conoce qué es y cuáles son los estilos arquitectónicos más importantes.
Relaciona el diseño software con los objetivos de negocio de la organización. Identificar las restricciones y atributos de calidad que debe cumplir un sistema. Construye una arquitectura en función de los requisitos cualitativos que debe cumplir un sistema sencillo.
Representa un diseño en relación a los requisitos cualitativos y las restricciones que debe cumplir.
Analiza, valora y razona las ventajas e inconvenientes de un diseño utilizando criterios técnicos, cualitativos y del dominio del negocio.
Es capaz de debatir y defender las conclusiones con argumentos sólidos y bien fundados.
Conoce y sabe aplicar herramientas de soporte orientadas a evaluar los aspectos cuantitativos y económicos para tomar decisiones, en el desarrollo de un diseño, que se conjuguen adecuadamente con los objetivos de negocio de la organización.
Aplica las técnicas de optimización aprendidas para el diseño arquitectónico, en arquitecturas que gestionen la variabilidad y mejoren la flexibilidad de la producción y la competitividad de la organización.
Los resultados del aprendizaje anteriores, se traducen en conocimientos (qué va a conocer o a saber), destrezas y habilidades (qué va a saber manejar o hacer) y aptitudes (para qué estará capacitado), que se adquieren una vez superada la asignatura.
Conocimientos
Adquirirá —y deberá demostrar— los siguientes conocimientos:
Conocer y saber aplicar los principios y metodologías del ciclo de vida evolutivo.
Saber identificar los requisitos, restricciones y atributos de calidad que debe cumplir un sistema.
Saber relacionar el diseño software con la especificación funcional y los objetivos de negocio de la organización.
Saber construir un diseño en función de los distintos tipos de requisitos y atributos de un sistema sencillo.
Saber qué son los patrones de diseño y su utilidad.
Saber los 9 principios fundamentales en el diseño de objetos y asignación de responsabilidades. Saber cómo aplicarlos.
Conocer algunos patrones GoF y saber qué mejoras proporcionan al diseño.
Conocer qué es y cuáles son los estilos arquitectónicos más importantes. Saber establecer la relación entre una arquitectura software y la facilidad con que se alcanzan las restricciones técnicas y atributos cualitativos del sistema.
Destrezas
Tras el estudio de la asignatura el alumno deberá:
Saber utilizar la notación de UML.
Identificar Casos de Uso primarios y registrarlos de forma completa en el estilo esencial.
Identificar las clases conceptuales, asociaciones y sus atributos en el dominio del problema y recogerlas en un modelo conceptual mediante la notación UML.
Identificar eventos del sistema y representarlos en un diagrama de secuencia mediante UML.
Asignar responsabilidades y diseñar colaboraciones entre los componentes del Software mediante patrones GRASP e ilustrar el resultado mediante diagramas de colaboración en UML.
Resolver las definiciones de clases en un diagrama de clases en UML.
Refinar el diseño y mejorar la arquitectura mediante la incorporación de parones GoF.
Hacer corresponder los artefactos de diseño con definiciones de clases en un lenguaje de programación orientada a objetos.
Analizar, valorar y razonar las ventajas e inconvenientes de un diseño arquitectónico utilizando criterios técnicos y cualitativos del dominio de negocio.
Habilidad para debatir y defender las conclusiones con argumentos sólidos y bien fundados.
Aptitudes
Una vez superada la asignatura el alumno estará capacitado para:
Analizar, diseñar y construir aplicaciones de forma robusta, segura y eficiente, eligiendo las tecnologías de desarrollo más adecuadas.
Desarrollar, mantener y evaluar servicios y sistemas software que satisfagan los requisitos del usuario, las necesidades del cliente y los objetivos del dominio de negocio.
Identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teorías, modelos y técnicas actuales.
El programa de la asignatura se estructura en tres unidades didácticas y recoge cinco temas que se corresponden con los 34 primeros capítulos del texto base. Este programa realiza un recorrido, gradual y detallado, por las actividades y los aspectos significativos del diseño y desarrollo de cualquier producto software. La misma estructura de los contenidos establece un método incremental de trabajo, válido para afrontar tanto el estudio de la asignatura como las actividades implicadas en la elaboración de software.
Unidad Didáctica I
Contenidos: El Análisis y Diseño Orientado a Objetos: objetivos. El Proceso Unificado y el desarrollo iterativo: método de trabajo. Sistema de punto de venta: escenario práctico de seguimiento.
Resumen: En este capítulo se plantean los objetivos globales de la asignatura y se justifican desde el enfoque de la adquisición de competencias y destrezas muy importantes para mejorar la capacidad de producción de Software y la calidad del producto. También se establece un método de trabajo para el estudio, adherido a un modelo de ciclo de desarrollo incremental e iterativo: el Proceso Unificado. Por último, se presenta un ejemplo concreto que será el escenario o marco de referencia en los aspectos prácticos del proceso de aprendizaje de la asignatura.
Objetivos:
Materiales:
Capítulos 1, 2 y 3 de Craig Larman, UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Segunda edición, 2003. Pearson Educación S.A. ISBN: 978-84-205-3438-1.
Lecturas complementarias
Martin Fowler y Kendall Scott, "UML Distilled. A Brief Guide to the Standard Object Modelling Language". Third Edition. Addison Wesley Professional, 2003.
Philippe Kruchten, "The Rational Unified Process - An Introduction". Third Edition. Addison Wesley Professional, 2003.
Contenidos: Fase de Inicio. Comprensión de los requisitos. Modelo de Casos de Uso: escritura de los requisitos en el contexto. Identificación de otros requisitos. Transición a la elaboración.
Resumen: De las cuatro fases definidas en el Proceso Unificado, el Inicio consiste en un análisis de alcance del producto o análisis del negocio o una prospección de evidencias suficientes que justifiquen que se continúe con el desarrollo y se comiencen las siguientes fases iterativas. Las actividades de esta fase se orientan a construir una visión aproximada del producto, su alcance, un análisis del negocio y estimaciones imprecisas. Los artefactos que más destacan en esta fase son los requisitos y, aunque es muy notable el esfuerzo que significa su elaboración, su grado de definición, completitud y fiabilidad es muy bajo —entre el 10% y el 20%—. Lo realmente importante es construir una Visión del producto y un Análisis del Negocio para comprender el alcance del desarrollo.
Objetivos:Capítulos 4 a 8 del texto básico.
Cockburn, A. "Writing Effective Use Cases". Reading, MA.: Addison Wesley, 2001.
Unidad Didáctica II
Contenidos: Modelo de Casos de Uso: representación de los Diagramas de Secuencia. Modelo del Dominio: registro de conceptos, añadir asociaciones, añadir atributos y añadir detalles con los contratos de las operaciones. De los requisitos al diseño. Notación de los diagramas de iteracción. GRASP: diseño de objetos con responsabilidades (patrones). Modelo de Diseño: elaboración de los Casos de Uso con patrones GRASP, determinación de la visibilidad, creación de los Diagramas de Clases de diseño. Modelo de Implementación: transformación de los diseños en código.
Resumen: Aunque los requisitos estén muy poco desarrollados, casi todos están identificados y se tiene una comprensión del dominio suficiente como para haberlos clasificado desde el punto de vista de su importancia y riesgo y para haber planificado el enfoque de la primera iteración. También se parte de una estructura nuclear de la arquitectura del sistema. Para comprender el comportamiento deseado para las operaciones básicas que se afrontan en esta iteración, primero, se elaboran los Diagramas de Secuencia del Sistema –DSS- para escenarios específicos de un caso de uso. A continuación se construye el Modelo del Dominio. El tercer paso es aumentar el nivel de detalle en la descripción del comportamiento del sistema cuando la ejecución de una operación genera cambios de estado en los objetos del Modelo del Dominio. El incremento de detalle se realiza añadiendo 'contratos de operación' en el Modelo de Casos de Uso.
Y, por fin, se comienza el diseño de los objetos software que consiste –como se ha dicho- en asignar responsabilidades. Las responsabilidades están relacionadas con las obligaciones de un objeto en cuanto a su comportamiento y, básicamente, pueden ser de dos tipos: hacer o conocer.
Utilizando el concepto de patrón software como analogía, se agrupan en un Principio General de Asignación de Responsabilidades las formas y técnicas comúnmente admitidas para asignar las responsabilidades en una familia de situaciones tipificadas. Y, con ello, se hace un patrón GRASP. Por tanto, los patrones GRASP son heurísticas que permiten deducir cómo se asignan responsabilidades a los objetos. Los 5 principios que se abordan en este tema son:
Experto en información (o Experto): asignar la responsabilidad a la clase que tiene la información necesaria para realizarla.
Creador: si B es una agregación o contiene o registra o utiliza estrechamente o es un Experto en la creación de objetos de A, asignar a B la responsabilidad de crear instancias de A.
Acoplamiento bajo: asignar las responsabilidades para mantener bajo el acoplamiento.
Cohesión alta: asignar las responsabilidades para mantener alta la cohesión.
Controlador: cómo asignar la responsabilidad para tratar un evento del sistema.
La elaboración del Modelo de Diseño se hace aplicando los patrones GRASP en el Modelo de Casos de Uso –mediante las realizaciones de los casos de uso- y en el Modelo de Dominio, simultáneamente, y agregando la visibilidad para obtener los Diagramas de Colaboración y los Diagramas de Clases de Diseño. El trabajo con el Modelo de Diseño amplía y clarifica la comprensión del sistema, por lo que puede producir ajustes en los modelos del análisis y el consiguiente refinamiento.
Objetivos:
Materiales:
Capítulos 9 a 20 del texto básico.
Lecturas complementarias
Martin Fowler. "Analysis Patterns: Reusable Object Models". Reading, MA.: Addison Wesley, 1996.
Wirfs-Brock, R.; Wilkerson, B. y Wiener, L.; "Designing Object-Oriented Software". Englewood Cliffs, NJ.: Prentice-Hall, 1990.
Contenidos: Requisitos de la iteración 2. Más patrones GRASP para asignar responsabilidades. Patrones GoF para diseñar las realizaciones de los Casos de Uso.
Resumen: En el tema anterior, la parte desarrollada del sistema se ha integrado completamente, probado y estabilizado como versión de base —línea base— interna. Por motivos pedagógicos, para esta segunda iteración se van elegir cuatro requisitos complejos, que ya estaban recogidos en los escenarios de éxito del caso de uso ProcesarVenta, muy interesantes para introducir los 4 principios GRASP que quedan y algunos patrones GoF.
Los patrones GRASP que se tratan en este tema son:
Polimorfismo: asignar comportamientos diferentes —aunque relacionados— a los objetos –tipos- en los que se diferencia dicho comportamiento, mediante operaciones polimórficas.
Fabricación pura: cuando la aplicación del principio Experto lleva a una asignación que contraviene algún otro GRASP, conviene crear una clase software artificial —no proviene de un objeto del modelo del dominio— a la que se asigna la responsabilidad. De aquí en adelante, casi todos los patrones de diseño son de este tipo —siguen este principio—, incluidos los GoF.
Indirección: consiste en crear un objeto intermedio —de desacoplo— para romper un acoplamiento indeseable entre otros dos.
Variaciones protegidas: cuando los destinatarios de alguna responsabilidad pueden tener una gran variabilidad, o incertidumbre, en su implementación, es conveniente crear una interfaz invariable para asignarle dicha responsabilidad. Este principio fundamental motiva la mayoría de los mecanismos de programación y diseño orientados a dotar de flexibilidad y a protegerse de las variaciones; como son: mecanismos básicos (encapsulación, interfaces, indirección, polimorfismo y estándares), diseños dirigidos por los datos, búsqueda de servicios, diseños dirigidos por un intérprete, diseños reflexivos o de meta-nivel, acceso uniforme, principio de sustitución de Liskov, diseños de ocultación de la estructura ('no hable con extraños' o ley de Demeter), ocultación de la información (Parnas) y principio abierto-cerrado.
A partir del dominio de los 9 principios fundamentales GRASP se está en disposición de poder estudiar, con alcance, los patrones de diseño más frecuentes y conocidos, como los GoF. En este tema se presentan los patrones Adaptador, Factoría, Singleton, Estrategia, Composite, Fachada y Observador / Publicar-Suscribir / Delegación de Eventos.
Atención: Como se puede intuir de todo lo anterior, GRASP no son 'verdaderos' patrones de diseño; sino principios o reglas generales para su elaboración. Por la experiencia docente de cursos anteriores, se ha decidido excluir de la evaluación (exámenes) los patrones GoF. En el libro, estos patrones se presentan como un hallazgo del diseño, obtenido de forma natural al aplicar los principios GRASP. Por ello, es extremadamente recomendable que profundice en los conceptos de los 9 principios GRASP, que se familiarice con su uso y, sobre todo, que aprenda a aplicarlos (los mecanismos que se utilizan) para resolver los problemas que se plantean en los requisitos, aunque no sepa cómo se llama el patrón GoF, equivalente, que se puede utilizar para ello. Esto no significa, en absoluto y en ningún caso, que eluda la lectura y estudio de los capítulos 24 y siguientes del libro. Sin ellos, no va a obtener la comprensión del conjunto, imprescindible para superar la asignatura.
Objetivos:
Materiales:
Capítulos 21 a 23 del texto básico.
Lecturas complementarias
Gamma, E.; Helm, R.; Johnson, R. y Vlissides, J. (GoF); "Design Patterns". Reading, MA.: Addison-Wesley, 1995. Referencia para el diseño con patrones.
Unidad Didáctica III
Contenidos: Requisitos de la iteración 3. Relaciones entre Casos de Uso. Modelado de la Generalización. Refinamiento del Modelo de Dominio. Ampliación de DSSs y contratos. Modelado del comportamiento con Diagramas de Estado. Diseño de la Arquitectura lógica con patrones. Organización de los paquetes de los Modelos de Diseño e Implementación. Introducción al Análisis de Arquitecturas y el SAD. Diseño de más realizaciones de Casos de Uso con objetos y patrones. Diseño de un 'marco de trabajo' (framework) de persistencia con patrones.
Resumen: En la tercera iteración se van a incorporar los siguientes requisitos:
Para continuar con el proceso, el tema incorpora dos tipos de relación entre los casos de uso y su representación en los Diagramas de Casos de Uso. La incorporación de las relaciones entre casos de uso (extensiones) en el Modelo Conceptual necesita de una estructuración jerarquizada del modelo: la Generalización. El Modelo del Dominio también precisará incorporar relaciones de asociación, agregación y composición, caracterizar y calificar roles y asociaciones. Cuando el modelo crece puede ser muy conveniente organizarlo en paquetes.
Con estas herramientas, ya se está en disposición de incorporar los requisitos de esta iteración. Los que se refieren a la gestión de pagos implican nuevas colaboraciones con sistemas externos; por lo que habrá que incorporar nuevos DSS y contratos. Otra forma de recoger estas operaciones es mediante los Diagramas de Transición de Estados.
Los capítulos 30 a 32 se centran en las consideraciones arquitectónicas del desarrollo. Sin embargo, su estudio excede el ámbito de esta asignatura y sus contenidos están recogidos en otras, en el nivel de máster y en la materia de Ingeniería de Software, como '31105039 - Arquitecturas para Sistemas Software'. Aunque no es materia de evaluación, se recomienda al lector el recorrido atento de estos capítulos, tomando buena nota del alcance de lo que ahí se dice y, sobre todo, de la organización, las dependencias y relaciones entre los módulos del sistema PDV. La arquitectura presentada en dichos capítulos es la que se usa para el trabajo indicado a continuación.
Al incorporar el requisito de 'robustez ante fallos de los servicios externos' se aprovecha la caché definida en la arquitectura de PDV y se relacionan algunos patrones para el tratamiento de fallos, uso de excepciones y manejo de errores. Se presenta el patrón GoF Proxy para resolver el problema. El 'soporte para el manejo de dispositivos externos' se puede conseguir con el patrón Adaptador o Factoría Abstracta (GoF). Y la 'gestión de distintas formas de pago' con Polimorfismo u otros patrones equivalentes.
Por último, se incorpora el requisito de la necesidad de la persistencia de la información en el sistema como excusa para ver cómo se diseña un framework con objetos y en UML.
Objetivos:
Materiales:
Capítulos 24 a 34 del texto básico.
José Félix Estívariz López
Javier Arellano Alameda
La metodología que se usa en la enseñanza de la asignatura es la propia de la UNED y está basada en el aprendizaje a distancia ayudado por la infraestructura, los recursos materiales de la Universidad y humanos a nuestro alcance y apoyado por el uso de las tecnologías de la información y el conocimiento.
En este apartado hemos de distinguir entre cómo aprenderá el alumno esta asignatura (actividades formativas) y con qué medios cuenta para llevar a cabo dicho aprendizaje.
Las actividades formativas para el estudio de la asignatura son:
Estudio de los contenidos relativos a los procedimientos y tecnologías de desarrollo del programa: En esta actividad el alumno debe desarrollar un trabajo autónomo que consiste en el estudio de la materia utilizando el libro de texto básico ("UML y Patrones").
Realización de ejercicios teórico-prácticos: Esta actividad consiste en la realización, por parte del alumno y de forma autónoma, de los desarrollos ilustrativos y ejemplos prácticos que utiliza el texto básico para mostrar cómo se ejecutan las actividades y los planteamientos conceptuales de las tecnologías de desarrollo. A este respecto, el texto de referencia utiliza un único escenario —Sistema de Punto de Venta (SPV)— para ilustrar los contenidos del programa.
Los materiales útiles y necesarios para el aprendizaje son: la Bibliografía Básica, el Curso Virtual y la página Web de la asignatura.
La Bibliografía Básica consta de:
El texto básico que el alumno debe usar para el estudio teórico-práctico de la materia objeto de la asignatura. El programa de la asignatura se ajusta a los 34 primeros capítulos del libro, que está perfectamente adaptado al estudio autónomo. Cada tema del programa está correlacionado con un grupo de capítulos adyacentes en el libro y, cada uno de estos, incluye la contextualización de sus contenidos, los objetivos y resultados esperados de aprendizaje. Análogamente, en cada tema del programa, hay una colección de cuestiones para el repaso y la reflexión de sus contenidos, así como referencias para la lectura e información adicionales.
En el Curso Virtual de la asignatura el alumno encontrará:
Un calendario con la distribución temporal de los temas a lo largo del cuatrimestre y con las fechas de entrega de las distintas actividades teórico-prácticas que el alumno puede realizar para su evaluación. Lógicamente la distribución del estudio de los temas es totalmente orientativa y no está obligado a seguirla salvo en lo referente a las fechas de entrega de las pruebas de evaluación a distancia calificables que, tras la fecha de entrega, se cerrará la aplicación informática y no serán posible entregarlas.
Una guía de estudio en la que se hace una descripción detallada del plan de trabajo propuesto con el fin de orientar al alumno en el estudio de cada uno de los temas de la asignatura. Además, se especifican los conceptos y desarrollos más importantes, así como las habilidades y aptitudes que el alumno debe haber conseguido tras el estudio de dicho tema.
La relación y descripción de las pruebas de evaluación a distancia calificables, y las normas y condiciones que deben tener en cuenta para la entrega de dichas actividades.
El software de ayuda para modelado y representación gráfica Astah/Community, x64 (descontinuado; también para Mac OS: aquí), concebido para usar UML v2.x.
Nota: Desde el día 26 de septiembre de 2018, se ha descontinuado Astah/Community. Además, la licencia 'student', que se obtiene mediante la acreditación con el correo de la UNED (@alumno.uned.es) y que otorgaba el uso anual de Astah Professional, provee ahora una versión intermedia (entre Community y Professional) por el mismo procedimiento: Astah UML.
Otra opción gratuita es ArgoUML, aunque no soporta las versiones 2.x de UML y se está estudiando su capacidad para expresar la semántica que se utiliza en la asignatura.
También, para establecer una comunicación fluida entre profesores y alumnos, dentro del Curso Virtual existen las siguientes facilidades:
Los foros por medio de los cuales los profesores y/o tutores aclararán las dudas de carácter general y específicas de cada uno de los temas. También se usarán para comunicar todas aquellas novedades que surjan a lo largo del curso.
Calendario de planificación y alertas, para la organización del estudiante.
Comunicación mediante correo electrónico a través del servicio interno de la plataforma aLF.
Área de entrega y calificación de las pruebas de evaluación calificables.
Servicio de repositorio documental, para disponer de materiales y documentación adicionales.
Además, para respaldar el soporte y la comunicación entre profesores y alumnos, a nivel general en la asignatura, se dispone:
El correo electrónico swdesign@issi.uned.es mediante el cual, de forma privada, se puede comunicar con los profesores para plantear todas aquellas dudas o cuestiones académicas que se les presenten o consideren oportunas.
La atención personal por parte del Equipo Docente, en el despacho, los días de guardia y por medio del teléfono para aquellos casos que lo requieran. Así mismo, los Tutores atienden personalmente a los alumnos en las tutorías que tienen lugar en los Centros Asociados.
En el proceso de aprendizaje es de gran relevancia poder evaluar tanto el grado y la calidad en que los conocimientos y destrezas exigidos en la asignatura han sido adquiridos por el estudiante como la manera en que se han transmitido y la evolución del alumnado en este proceso. Además de la evaluación o examen final, una manera adecuada de conseguirlo es realizar una evaluación continua a lo largo del semestre, con el fin de informar a docentes y alumnado de la trayectoria del aprendizaje. Hay que hacer notar que no son dos tipos distintos de evaluación, sino dos formas que participan del propio proceso de maduración en la asignatura. Si bien el examen final tiene un carácter no-interactivo, determinista o finalista más acusado, la evaluación continua significa un excelente entrenamiento para la prueba final (que será similar) y provee de mecanismos muy valiosos para la auto-supervisión y seguimiento por parte del alumnado y los docentes. Cada forma de evaluación consta, a su vez, de varios apartados que cubren las distintas competencias, habilidades y destrezas que debe haber adquirido el estudiante una vez que ha superado dicha asignatura.
Dentro de este tipo de evaluación consideramos dos modalidades: Actividades de Autoevaluación y Actividades Calificables. Esta evaluación la realiza el Profesor Tutor.
Ejercicios y Actividades de Autoevaluación.
La autoevaluación es de gran importancia en el proceso general de aprendizaje de la asignatura, ya que informa al alumno de la trayectoria que va llevando en la adquisición del conocimiento de la materia durante el proceso de aprendizaje autónomo. Para ello, al final de cada tema del programa, en el capítulo correspondiente del texto base, hay un epígrafe denominado "No se entiende «concepto» cuando...". Los epígrafes contienen una colección de cuestiones y planteamientos que el alumno debe saber responder tras haber estudiado y comprendido adecuadamente el tema correspondiente y sobre los que debe reflexionar para auto evaluarse o establecer otros puntos de vista en la comprensión de esos contenidos.
Actividades calificables por el Profesor Tutor.
Esta evaluación continua la realiza el Profesor Tutor del Centro Asociado —o el que corresponda en la virtualización—, mediante las Pruebas de Evaluación a Distancia. Consisten en una actividad cuya descripción e instrucciones para su realización y entrega están descritas con detalle en la Segunda Parte de la Guía de Estudio y en el material del curso virtual de la asignatura. Tendrá un esquema idéntico a la primera sección del examen final.
La actividad debe entregarse en la forma, la fecha y por el procedimiento que se indican en la Segunda Parte de la Guía de Estudio. Es importante tener en cuenta que no hay posibilidad de entregar ninguna actividad una vez superada la fecha indicada, porque se cerrará la aplicación y es imprescindible que se realice y evalúe en el semestre en el que se imparte la asignatura. Por tanto, en la convocatoria de septiembre se mantiene la nota obtenida en la actividad durante dicho semestre.
Como ya se ha comentado, son evaluadas por el Profesor Tutor del Grupo Territorial de Centros Asociados (Grupo de Tutoría Virtual) correspondiente y la calificación obtenida se tienen en cuenta en la nota final de la asignatura de la siguiente forma:
La Actividad de Evaluación a Distancia se puntúa sobre 10. Estará superada si su calificación es de 5 o mayor.
Para que esta Nota obtenida en la Prueba de Evaluación a Distancia se tenga en cuenta en el cómputo de la Nota Final de la Asignatura es imprescindible cumplir las siguientes condiciones:
Haber aprobado la Actividad Calificable a Distancia (NPED≥5).
Que la calificación obtenida en la Prueba de nivel Presencial o Examen Final sea mayor o igual a 4'5 (sobre 10).
Si se cumplen las anteriores condiciones, la Nota Final de la Prueba de Evaluación a Distancia siempre es aditiva en el cómputo de la Nota Final de la Asignatura y la máxima contribución es de 2 puntos (sobre 10). Es decir, en el peor escenario, en el que se haya obtenido 4'5 en el Examen Final y la puntuación de la Actividad Calificable fuera de 5, la aportación de la Prueba de Evaluación a Distancia sería 5 x 2 / 10 = 1, valor que se sumaría a 4'5 para obtener la Nota Final de la Asignatura (aprobada). En el mejor caso, con un 10 en la PED, su aportación sería un 2, que se sumaría a la calificación del examen (si supera el 4'5).
En el caso de que la calificación de la PED contribuya a la Nota Final de la Asignatura (esté aprobada y se haya obtenido 4'5 o más en NE1s, ver cuadro más abajo), su aportación será del 20% siempre.
La evaluación final se corresponde con el Examen Final o Prueba Presencial de la asignatura. Se realiza en los Centros Asociados, tiene una duración de 2 horas y para su ejecución se permitirá el uso del libro de texto básico de la asignatura, pero ningún otro material adicional.
La Prueba Presencial consiste en una batería de preguntas teórico/prácticas y ejercicios (alrededor de 8), formulados en torno a un escenario o el dominio de un problema concreto. En este tipo de asignaturas la solución de un problema no es única y existe un sinfín de variantes sobre una respuesta correcta estandarizada. Cada uno de los apartados del examen requiere que se construya la respuesta basándose en la respuesta del apartado anterior. Se puntúa sobre 10, pero la puntuación de los apartados no es la misma para todos: las preguntas relativas a los Casos de Uso tienen menor puntuación, ya que son relativamente inmediatas y su respuesta no está directamente relacionada con las habilidades del diseño orientación a objetos. Por el contrario, las cuestiones relacionadas con la asignación de responsabilidades y diseño de colaboraciones tienen las puntuaciones más altas.
Adicionalmente, la prueba tiene dos o tres cuestiones de carácter conceptual y de conclusiones sobre los contenidos de la asignatura, cuya máxima puntuación conjunta es de 1 punto. Esta sección se utiliza para elevar la calificación final de la asignatura (BP); siempre y cuando la puntuación de la otra sección del ejercicio (NE1s) sea mayor o igual que 6'25 y se haya aprobado la PED (CPED = NPED x 2 / 10).
¡Atención! La puntuación mínima para superar la asignatura (NF) es 5. El cálculo para determinar los límites se hace, exclusivamente, con las puntuaciones obtenidas en la primera sección —la batería de preguntas teórico/prácticas, NE1s—. Para calcular la calificación final de la asignatura se utilizan cuatro tramos (definidos por el valor obtenido en NE1s: menor de 4'5, entre 4'5 y 5, entre 5 y 6'25 y mayor de 6'25), en los que se aplican algoritmos diferenciados (ver cuadro). En el primer tramo (NE1s < 4'5), la nota final es la obtenida en NE1s, la PED no se tiene en cuenta (aunque, si está aprobada, la calificación se mantiene para la convocatoria de septiembre) y la asignatura está suspensa. En el segundo tramo (NE1s entre 4'5 y 5), NF es la suma de NE1s y el 20% de PED (si está aprobada). Para NE1s entre 5 y 6'25, NF es el valor más alto entre NE1s y la suma del 80% de NE1s más el 20% de PED (si está aprobada). En el último tramo, la nota final es la suma del 80% de NE1s más el 20% de PED (si está aprobada) más BP.
La asignatura estará superada con una calificación igual o mayor que cinco (NF ≥ 5). A continuación se incluye un cuadro-resumen con los algoritmos utilizados para la calificación de las diferentes partes de la evaluación.
Nota PED
Nota Examen Final
Nota Final Asignatura
Calificación PED (NPED)
Contribución PED (CPED)
Primera Sección (NE1s)
Puntos adicionales (BP)
Nota Examen (NPP)
NPED
CPED = 0
NE1s < 4'5
BPNPP = NE1s
NF = NPP
NPED < 5
CPED = 0
4'5 ≤ NE1s < 5
BPNPP = NE1s + CPED
NF = NPP
5 ≤ NPED
CPED = NPED x 0'2
NPED < 5
CPED = 0
5 ≤ NE1s < 6'25
BPNPP = (NE1s x 0'8) + CPED
NF = Máx {
NE1s
5 ≤ NPED
CPED = NPED x 0'2
NPP
NPED < 5
CPED = 0
6'25 ≤ NE1s
BP
NPP = (NE1s x 0'8) + CPED
NF = Máx {
NE1s
5 ≤ NPED
CPED = NPED x 0'2
NPP+BP
Atención: En este curso, se permite el uso del libro de texto de la asignatura en la realización de los exámenes presenciales. Se recomienda prestar especial atención para no dejarse engañar por esta medida: la utilización del libro durante las pruebas, no va a remediar la falta de práctica o de habilidad para aplicar los conceptos de la asignatura y resolver el examen con éxito.
Importante: En el transcurso de los años anteriores, se han ido recogiendo diversas recomendaciones, consejos e indicaciones orientadas a facilitar la realización de las pruebas de evaluación y el enfoque de los contenidos de la asignatura de cara a ellas. Por ello, se recomienda encarecidamente el manejo de esta documentación adicional:
La actividad calificable consiste en la elaboración del diseño correspondiente a un ejemplo o escenario concreto de un sistema software que se pretende desarrollar. El enunciado consiste en la presentación y descripción abreviada del escenario, del sistema software. La elaboración está dirigida, y se organiza, mediante aproximadamente ocho secciones en las que se solicita realizar determinadas operaciones y tareas. Cada una de estas secciones recopila gran parte de los resultados del aprendizaje y conclusiones de un grupo temático de tareas correspondiente al plan de actividades no evaluables programado en la asignatura. Por tanto, el objetivo de cada sección es que el estudiante vaya contrastando sus progresos en el aprendizaje y en la elaboración de las tareas no calificables, con la madurez y las capacidades exigidas en la asignatura.
Aunque la entrega de la actividad es hacia el final del semestre, si su elaboración no se realiza acompasada con el estudio de los temas y el trabajo de las actividades no evaluables correspondientes a cada sección, se malogrará enormemente su eficacia. La recomendación es que se estudien los contenidos a los que hace referencia una sección, se realicen los ejercicios y actividades no evaluables correspondientes, se reflexione sobre ello, -en algún caso- se intenten nuevas aproximaciones y, al fin, se elabore la respuesta a la sección. Las preguntas de cada sección se apoyan en las respuestas de la sección anterior. Globalmente, la actividad sigue el mismo esquema incremental iterativo que el ciclo de vida del desarrollo utilizado en la asignatura: el proceso unificado. Por ello, puede ser que, en una sección posterior, el estudio lleve al lector a nuevas consideraciones y puntos de vista que le hagan revisar las secciones anteriores. Este proceso de refinamiento enriquece al estudiante y mejora el resultado final; pero la ayuda desaparece si no se hace este refinamiento por no sincronizar el estudio con las actividades.
La estructura y el formato de la actividad es idéntico al de la Prueba Presencial final; sólo que si ésta se realiza en 2 horas, la actividad se puede elaborar en 10 semanas. Por tanto, además de ejercicio para asentar los conocimientos y capacidades del estudiante, cumple la función de entrenamiento para la Prueba Presencial Final. Por el mismo motivo, la evaluación de la actividad tiene los siguientes objetivos y resultados de aprendizaje esperados:
Importante: En el transcurso de los años anteriores, se han ido recogiendo diversas recomendaciones, consejos e indicaciones orientadas a facilitar la realización de las pruebas de evaluación y el enfoque de los contenidos de la asignatura de cara a ellas. Por ello, se recomienda encarecidamente el manejo de esta documentación adicional:
La realización de la actividad no es obligatoria. Sin embargo, para que sea calificada, sí es de obligado cumplimiento que la elaboración y la entrega se hagan en un período de tiempo definido, correspondiente al primer cuatrimestre del curso. En concreto, entre el 28 de noviembre y el 13 de diciembre de 2021. La corrección de estas pruebas corresponde al período de actividad de los Tutores en esta asignatura, por lo que no se admitirán entregas ni trabajos fuera de estas fechas. La calificación obtenida en enero para la actividad, se mantiene para el cálculo de la nota final en la convocatoria de septiembre.
La entrega y la calificación se hará a través del curso virtual, en el apartado de 'Entrega de trabajos'. Para la entrega se depositará un único fichero con las respuestas. El trabajo consistirá en un documento con la siguiente información:
Si, por algún motivo, necesita entregar más de un fichero –por incluir diagramas en otro formato, o código fuente, etc.- deberá empaquetar todos en un único archivo –zip, rar, arj, etc.- porque, en la entrega, el curso virtual sólo guarda el último fichero depositado. El resto se perderá.
Texto base por el que se sigue la asignatura:
Craig Larman. Ed: Pearson Educación, S.A. Madrid, 2003. ISBN: 9788420534381.
Material que puede ser útil para profundizar en algunos aspectos de la asignatura:
Martin Fowler y Kendall Scott. Ed: ALHAMBRA MEXICANA, S.A. México, 1999. ISBN: 9789684443648.
Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. Ed: ADDISON-WESLEY. Madrid, 2002. ISBN: 9788478290598.
Para ayudar en el estudio de la asignatura, el estudiante dispondrá de diversos medios de apoyo. Así, podemos destacar los siguientes:
El equipo docente que está a disposición de los estudiantes para orientarle y ayudarle en el aprendizaje de la asignatura y en la preparación de las pruebas presenciales.
El curso virtual que constituye el principal punto de apoyo.
Las tutorías presenciales en el Centro Asociado correspondiente y que son un gran apoyo para el estudiante. En ellas el profesor tutor resuelve dudas y cuestiones académicas y explica aquellos conceptos y/o temas que resultan más complicados.
Existen también muchos recursos en Internet. No sólo información y documentación sobre POO, Diseño y patrones, sino herramientas para el modelado, CASE o entornos de programación OO. El equipo docente no recomienda que el estudiante desvíe su atención con la búsqueda, instalación, configuración y aprendizaje de herramientas adicionales. Es más aconsejable reflexionar, usar papel y lápiz. En última instancia, sí es recomendable codificar los diseños y comprobarlos con un entorno como BlueJ o Eclipse.
José Félix Estívariz LópezDirección:
Dpto. de Ingeniería de Software y Sistemas Informáticos. Despacho 2.20.
Lunes lectivos, de 16h a 20h. Teléfono 913987792. Correo: swdesign@issi.uned.es
Javier Arellano Alameda
Dpto. de Ingeniería de Software y Sistemas Informáticos. Despacho 2.21.
Viernes lectivos, de 16h a 20h. Teléfono 913988735. Correo: javier@issi.uned.es
El procedimiento recomendado para comunicar con los profesores es el correo electrónico dentro del Curso Virtual de la asignatura o bien mediante el teléfono en el horario de guardias y permanencias. También puede usar el correo electrónico de la asignatura swdesign@issi.uned.es.
Si, al realizar una llamada por teléfono, los profesores del equipo docente no le pueden atender en ese momento, le recomendamos que dejen un mensaje en el contestador. En ese caso, es muy importante que deje bien claro su nombre completo, su número de teléfono y la asignatura objeto de la llamada, para que el equipo docente le pueda devolver la llamada.