Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 1/8. Apellidos: Nombre: Núm.:

Transcripción

1 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 1/8 Apellidos: Nombre: Núm.: PD1 (4 Ptos.): Responda razonadamente a las siguientes cuestiones: 1. Qué diferencia existe entre un diagrama de clases de análisis y un diagrama de clases de diseño? Si bien ambos diagramas utilizan los mismos elementos de modelado, mientras que en el primer caso las clases representan abstracciones de conceptos del mundo real que no han de tener necesariamente una correspondencia con otras clases de implementación, en el segundo caso representan a clases de objetos que si tienen correspondencia con clases de la implementación. Por otra parte, en los DCD abundan las clases que no tienen correspondencia con abstracciones de conceptos reales, p.e., fábricas, indirecciones, adaptadores, etc. 2. Qué sabe sobre la conocida como Ley de Demeter? Consultar apuntes y/o pág 316 de Larman. 3. Qué se entiende por punto de variación y de evolución? Qué GRASP trata de manera más directa con ambos puntos? Qué otros nombres recibe dicho GRASP? Un punto de variación representa a una variación contemplada en la especificación de requisitos o documento de entrada del diseño. Por ejemplo, el formato de compresión de las imágenes podrá variar en el futuro. Un punto de evolución es un punto de variación sobre cuya existencia se conjetura (especula). Por ejemplo, a partir del requisito el formato de compresión deberá ser GIF el diseñador puede especular sobre la evolución del sistema y tomar la decisión de protegerse sobre la variación del formato de compresión para dar cabida en el futuro p.e a JPEG. El diseñador experto suele se reconoce, entre otros rasgos, por su acierto a la hora de definir estos puntos. El patrón GRASP variaciones protegidas, llamado Principio Abierto/Cerrado por Meyer o Principio de Ocultación de la Información por Parnas los utiliza en su solución para conseguir minimizar el impacto de las variaciones en los elementos de diseño (clases, subsistemas, ) NO OLVIDE INDICAR SU NOMBRE COMPLETO, SIN USAR ABREVIATURAS. GRAPE O UNA POR LA ESQUINA LOS FOLIOS CORRESPONDIENTES A CADA EJERCICIO

2 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 2/8 4. Qué entiende Craig Larman por principios evaluativos? Indique al menos dos ejemplos de dichos principios. Son principios a tener en mente durante todas las decisiones de diseño (Larman, pág 219). Por ejemplo el acoplamiento y la cohesión son principios que deben ser valorados cada vez que se asigna una responsabilidad o se toma una decisión de diseño. 5. Describa lo más detalladamente posible alguna situación en la que resulte claramente ventajoso aplicar el PD Adaptador haciendo uso de herencia en lugar de composición. Consultar apuntes. También se ha discutido en la lista de la asignatura. 6. Discuta la veracidad de la afirmación "el diseño es independiente del lenguaje de programación". (Discutida en la lista) La veracidad de la afirmación es más que discutible, debiéndose matizar un poco: En el contexto de este curso, al decir que "el diseño es independiente del lenguaje de programación (LP)", tratamos de trasladar la idea de que el diagrama de clases (en UML hay más diagramas que forman parte de un diseño que no se han visto en este curso: de despliegue, de componentes, etcétera) puede transformarse a un fragmento de código escrito en prácticamente cualquier LP orientado a objetos. De hecho, en muchos manuales de UML se comenta como realizar esa transformación de manera sistemática, incluso hay herramientas que permiten hacerlo automáticamente (Rational, Visio,..) Sin embargo, hay que recordar la necesidad de diseñar sabiendo que es posible su implementación. Es posible que un diseño no pueda ser implementado tal cual simplemente por desconocer la semántica del LP empleado. Por ejemplo, un diseño que plantee una herencia múltiple puede ser implementado en C++, pero no en Java. 7. Discuta la motivación y los aspectos a tener en cuenta cuando se trata de implementar el PD Método Fábrica en Java. Consultar los apuntes de clase.

3 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 3/8 Apellidos: Nombre: Núm.: PD2 (3 Ptos.): Para realizar los siguientes problemas, asuma la existencia de una clase Folder que guarda una relación de agregación con la clase File y de una clase Compressor. Considere el contrato sintáctico que estime oportuno con la semántica habitual de un sistema de archivos. Si en algún caso se indica de manera explícita otras clases de objetos, considere los contratos sintáctico y semántico que estime oportunos. A) Elabore el diagrama de colaboración correspondiente a la acción de comprimir una carpeta. B) Elabore el diagrama de secuencias correspondiente a la acción de borrar una carpeta. Debe tenerse en cuenta que los archivos superiores a un tamaño predeterminado, p.e. de 10 Mb., no van a la papelera de reciclaje. NO OLVIDE INDICAR SU NOMBRE COMPLETO, SIN USAR ABREVIATURAS. GRAPE O UNA POR LA ESQUINA LOS FOLIOS CORRESPONDIENTES A CADA EJERCICIO

4 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 4/8 C) Elabore el diagrama de colaboración correspondiente a la acción de comprimir una carpeta y enviarla por correo electrónico. Cada apartado del problema tiene varias soluciones, sólo se indica una de las posibles.

5 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 5/8 Apellidos: Nombre: Núm.: PD3 (3 Ptos.): Se necesita diseñar un módulo con la finalidad de comprimir archivos teniendo en cuenta los siguientes condicionantes: 1. El módulo ofrecerá a sus clientes la posibilidad de comprimir uno o varios archivos del modo indicado en el siguiente fragmento de código Java. 1 Class Test { 2 Public static void run() { 3 Compressor c= new Compressor(); 4 c.compress ( test1.doc ); 5 c.compress ( test2.doc ); 6 List l= new ArrayList(); 7 l.add( test1.jpg ); 8 l.add( test2.jpg ); 9 c.compress (l); 10 } 11 } 2. El método de compresión (ZIP, RAR, etcétera) a emplear dependerá del contenido del archivo a comprimir. Para averiguar el formato de compresión más adecuado en cada caso, se deberá emplear el Singleton DoctorCompression, más concretamente su método string getbestmethod (String namefile), el cual devuelve en una cadena de texto el método de compresión más adecuado para el fichero indicado. 3. Se deben emplear las clases ZIPCompressor y RARCompressor para comprimir archivos en formato ZIP y RAR respectivamente. Ambas clases implementan la interfaz ICompressor cuya definición en Java es: interface ICompressor { void compress(string filename); } 4. El grado de cohesión de las clases del diseño propuesto debe ser tan alto como sea posible. 5. Las clases DoctorCompression, ZIPCompressor y RARCompressor no deben ser modificadas. NO OLVIDE INDICAR SU NOMBRE COMPLETO, SIN USAR ABREVIATURAS. GRAPE O UNA POR LA ESQUINA LOS FOLIOS CORRESPONDIENTES A CADA EJERCICIO

6 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 6/8 A) Justifique brevemente en lenguaje natural los GRASP y patrones de diseño que considera aplicables en el diseño de este módulo. A partir del enunciado se desprende que existe un único punto de variación: el método de compresión. Proteger al módulo de dicha variación encaja con la motivación del PD Estrategia por lo que en principio sería un primer candidato. De los patrones relacionados con Estrategia, si utilizamos el GRASP Indirección o Fabricación Pura para que la clase Compressor no sea responsable de crear un compresor concreto, conseguimos una mayor cohesión de la clase Compressor. B) Elabore el diagrama de secuencias asociado al comportamiento del módulo para la petición de compresión de la línea 9 de la clase Test. No realice ninguna consideración sobre el mejor método para comprimir los archivos.

7 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 7/8 Apellidos: Nombre: Núm.: C) Ilustre con diagrama de clases UML el diseño propuesto para el modulo solicitado, haciendo uso de anotaciones para explicar la semántica de los métodos más relevantes. NO OLVIDE INDICAR SU NOMBRE COMPLETO, SIN USAR ABREVIATURAS. GRAPE O UNA POR LA ESQUINA LOS FOLIOS CORRESPONDIENTES A CADA EJERCICIO

8 Ingeniería del Software de Gestión II 2 de febrero de 2005 Pág: 8/8 D) Uno de los inconvenientes potenciales del PD Estrategia es la creación redundante de objetos estrategias. Proponga en lenguaje natural dos alternativas para resolverlos indicando las ventajas e inconvenientes de cada una de ellas. Discutido parcialmente en la lista