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. 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.
Esta asignatura forma parte de la materia de Ingeniería de Software —con 18 ECTS—, tiene carácter obligatorio, 6 ECTS (150 horas lectivas) 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 los 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.
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:
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. En el libro, los patrones de diseño (Gof) 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 del 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 de la asignatura: En esta actividad el alumno debe desarrollar una labor autónoma que consiste en el estudio de la materia utilizando el libro de texto básico ("UML Y PATRONES. UNA INTRODUCCIÓN AL ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS Y AL PROCESO UNIFICADO. SEGUNDA EDICIÓN").
Para guiar e interpretar el estudio de los contenidos del libro es imprescindible utilizar la extensa documentación adicional de apoyo, las indicaciones para el aprendizaje y los vídeo-tutoriales disponibles en el Curso Virtual, en la versión extendida de esta Guía (privada para los matriculados) o en el repositorio de contenidos audiovisuales de INTECCA.
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 (PdV)— 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.
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.
Acceso a la obtención del software de ayuda para modelado y representación gráfica Astah UML, concebido para usar UML.
Además, 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.
Áreas de entrega y calificación de la prueba de evaluación continua (PEC) y del Trabajo Final Obligatorio de cada convocatoria (PUF en febrero y TAS en septiembre).
Servicio de repositorio documental, para disponer de materiales y documentación adicionales.
En esta página Web de la asignatura el alumno encontrará:
Toda la información de naturaleza estática existente en el Curso Virtual, incluida la presentación, Guía Didáctica de la asignatura, Plan de Trabajo, integrantes del Equipo Docente, direcciones de contacto, etc.
Una relación y el acceso a los documentos con las actividades de autoevaluación y pruebas de evaluación calificables.
El sistema de evaluación y calificación, con las normas y condiciones que deben tener en cuenta al evaluar los resultados del aprendizaje individuales.
Las herramientas y utilidades de soporte y ayuda que resulten de interés para el seguimiento de la asignatura; cuando sea viable su distribución al alumnado.
Cualquier información, documento u otro elemento que sea de interés para la asignatura, se actualizará o añadirá en esta página, durante el transcurso del semestre, y en el Curso Virtual.
Además, para respaldar el soporte y la comunicación entre profesores y alumnos, 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 los foros de los Grupos de Tutorías a los que, respectivamente, estén adscritos.
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 (Pruebas de Evaluación Continua PEC). 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.
Pruebas de Evaluación Continua (PEC), calificadas 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 Continua (PEC). 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 (parte privada, accesible tras la matriculación) y en el curso virtual. 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 Prueba de Evaluación Continua (PEC) 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 Continua (PEC) se tenga en cuenta en el cómputo de la Nota Final de la Asignatura es imprescindible cumplir las siguientes condiciones:
Haber aprobado la Prueba de Evaluación Continua (PEC) (NPEC≥5).
Que la calificación obtenida en la Prueba de nivel Final Obligatoria, o Trabajo Final (Trab), sea mayor o igual a 4'5 (sobre 10).
Si se cumplen las anteriores condiciones, la Nota Final de la Prueba de Evaluación Continua (PEC) 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 Trabajo Final y la puntuación de la Prueba de Evaluación Continua (PEC) fuera de 5, la aportación de la PEC 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 PEC, 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 PEC 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.
Las pruebas fundamentales para la evaluación final de la asignatura son: un Trabajo Final Obligatorio (Trab) y un Examen de Control (ExControl). Ambas pruebas son una combinación indivisible y sustituyen al examen presencial de los cursos precedentes.
Trabajo Final Obligatorio (Trab).
La realización de esta actividad es obligatoria, junto con el examen de Control (ExControl), en cada convocatoria que se evalúe. En la convocatoria ordinaria de febrero, el Trabajo (Trab) se denomina PUF y, en la extraordinaria de septiembre, TAS.
Las competencias de esta asignatura se refieren al diseño y, en la evaluación, se restringen al diseño detallado. En coherencia, la solución que se pide en la evaluación consiste en una especificación de diseño detallado, formalmente correcta y cualitativamente adecuada.
"Formalmente correcta" significa:
"Cualitativamente adecuado" significa que el diseño, o el funcionamiento que especifica, sea:
El Trabajo (Trab, tanto PUF como TAS) tiene dos partes:
Se dispondrá de aproximadamente 10 semanas para elaborar esta prueba.
Examen de Control (ExControl).
Este examen de Control (ExControl), junto con el Trabajo (Trab), son las pruebas fundamentales para la evaluación de la asignatura. Ambas pruebas son una combinación indivisible y sustituyen al examen presencial de los cursos precedentes.
La contribución en la calificación final de la asignatura se refiere al resultado obtenido en el Trabajo (Trab) entregado previamente por el estudiante (en tiempo y forma) en esa misma convocatoria. Por tanto:
La evaluación final se corresponde con la entrega del Trabajo (Trab), de forma indivisible con la realización del Examen Final, Prueba Presencial o Examen de Control (ExControl). Este último (ExControl) se realiza en los Centros Asociados, tiene una duración de 1 hora y para su ejecución se permitirá cualquier material escrito en soporte de papel.
El Trabajo (Trab, denominado PUF en febrero y TAS en septiembre) consiste en una batería de ejercicios prácticos (alrededor de 7), formulados en torno a un escenario o el dominio de un problema concreto. 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 de la mejora de un diseño y la 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).
Por otro lado, la Prueba Presencial (ExControl) son 6 preguntas que se refieren al contenido exacto de las respuestas personales que se han entregado, con anterioridad, en el Trabajo obligatorio (Trab, PUF o TAS). Es decir, el Examen de Control (ExControl) no tiene validez si no se ha entregado el Trabajo obligatorio (Trab).
¡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 PEC
Nota Examen Final (trabajo PUF o TAS)
+ ExControlNota Final Asignatura
(Indispensable ExControl: 0, 0,3 o 1)Calificación PEC (NPEC)
Contribución PEC (CPEC)
Primera Sección (NE1s)
Puntos adicionales (BP)
Nota Examen (NPP)
NPEC
CPEC = 0
NE1s < 4'5
BPNPP = NE1s
NF = NPP*ExControl
NPEC < 5
CPEC = 0
4'5 ≤ NE1s < 5
BPNPP = NE1s + CPEC
NF = NPP*ExControl
5 ≤ NPEC
CPEC = NPEC x 0'2
NPEC < 5
CPEC = 0
5 ≤ NE1s < 6'25
BPNPP = (NE1s x 0'8) + CPEC
NF = ExControl*Máx {
NE1s
5 ≤ NPEC
CPEC = NPEC x 0'2
NPP
NPEC < 5
CPEC = 0
6'25 ≤ NE1s
BP
NPP = (NE1s x 0'8) + CPEC
NF = ExControl*Máx {
NE1s
5 ≤ NPEC
CPED = NPEC x 0'2
NPP+BP
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 11 de diciembre de 2022. 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ópez
Dpto. de Ingeniería de Software y Sistemas Informáticos. Despacho 2.20.
Lunes lectivos de 16h a 20h. Teléfono 913987792
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
El procedimiento recomendado para comunicar con los Profesores Tutores es a través de los foros temáticos, que correspondan, en el Curso Virtual e, igualmente, con los profesores del equipo docente. En este caso, además, se puede utilizar 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 pueden 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 el que 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.