ingeniería del software de gestión ii

I NGENIERÍA DEL S OFTWARE
G ESTIÓN II
B OLETÍN DE EJERCICIOS
A NTONIO R UIZ -C ORTÉS
O CTAVIO M ARTÍN
S EVILLA , 21
DE ENERO DE
2005
DE
First published in January 2005 by
The Distributed Group
ETSI Informática
Avda. de la Reina Mercedes s/n
Sevilla, 41012. SPAIN
­
Copyright c MMV The Distributed Group
http://www.tdg-seville.info
[email protected]
In keeping with the traditional purpose of furthering science, education and research,
it is the policy of the publisher, whenever possible, to permit non-commercial use and
redistribution of the information contained in the documents whose copyright they
own. You however are not allowed to take money for the distribution or use of these
results except for a nominal charge for photocopying, sending copies, or whichever
means you use redistribute them. The results in this document have been tested carefully, but they are not guaranteed for any particular purpose. The publisher or the
holder of the copyright do not offer any warranties or representations, nor do they
accept any liabilities with respect to them.
Índice General
Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1 Introducción al diseño software . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Cuestiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Técnicas de representación . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Cuestiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Patrones generales de software para asignar responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Cuestiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Patrones de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Cuestiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
ii
Índice General
Índice de Figuras
3.1 Dominio de información sobre gestión ferroviaria . . . . . . . . . . . . . . . . . . 7
1
2
3
4
5
6
Diagrama de clases y de secuencias del problema 4.3 . . . . . . . . . . . . . . .
Diagrama de clases del problema 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencias del problema 4.4 . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de clases y de secuencias del problema 4.3 . . . . . . . . . . . . . . .
Diagrama de clases del problema 4.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de secuencias del problema 4.4 . . . . . . . . . . . . . . . . . . . . . . . .
21
22
23
27
28
29
iv
Índice de Figuras
Prólogo
El presente documento recopila algunas cuestiones teóricas y problemas
relacionadas con la materia de la asignatura Ingeniería del Software II correspondiente al tercer curso de la Ingeniería Técnica en Informática de Gestión.
El principal objetivo de esta asignatura es introducir al alumno en la problemática del diseño orientado a objetos. Para lograr dicho objetivo adecuándonos al estado actual de la cuestión, se ha visto conveniente revisar sus contenidos, razón por la que en el curso 2004/05 se ha procedido a reordenar
algunos contenidos de años anteriores y a introducir algunos nuevos.
Una de las consecuencias de estos cambios en la asignatura, es la obsolescencia de los ejercicios y exámenes propuestos en cursos académicos anteriores. Si a esto añadimos que la asignatura no había dispuesto hasta la fecha
de boletín de problemas, no cabe duda que la necesidad de elaborar este documento era todavía mayor.
Hay dos características que marcan el contenido de este boletín. En primer
lugar, se tratan de cuestiones del mismo tipo de las que se pueden y de hecho
se han propuesto en exámenes oficiales de la asignatura. Con ellos pretendemos que el alumno pueda autoevaluarse al tiempo que familiarizarse con el
mismo tipo de cuestiones con las que será evaluado.
En segundo lugar, se trata de un boletín que no incluye todas las soluciones
a las cuestiones, lo que sin duda, será motivo de queja para una parte de los
alumnos. No obstante, dado que de este modo aumentan las probabilidades
de que el alumno intente resolver las cuestiones y problemas planteándoselas
desde el principio, estamos convencidos de que también aumentarán sus probabilidades de aprender y aprobar. Por otra parte, se recuerda a los lectores
que también son alumnos, que la asignatura cuenta con una lista de correo
en la que se puede y recomienda discutir la resolución de estas cuestiones y
problemas.
vi
Prólogo
En cuanto a la estructura del documento, esté se ha organizado en los mismos capítulos que el temario de la asignatura más un capítulo con las soluciones de algunas cuestiones y problemas. Cada capítulo tiene una sección
de preguntas de carácter teórico y otra de carácter más aplicado cuando la
materia lo requiere.
Los autores
Sevilla, enero de 2.005
Capítulo 1
Introducción al diseño software
1.1 Cuestiones
CUESTIÓN 1.1:
¿Que relación existe entre el cuerpo de conocimiento de la
Ingeniería del Software y el reconocimiento de ésta como profesión?
CUESTIÓN 1.2:
¿A qué representa las siglas SWEBOK? ¿Qué asociaciones
relacionadas con la informática han auspiciado dicho proyecto?
CUESTIÓN 1.3:
¿En qué aspectos suelen coincidir la mayoría de las definiciones de Ingeniería del Software?
CUESTIÓN 1.4: Discuta sobre si el diseño es o no una actividad compleja.
CUESTIÓN 1.5: Defina los siguientes conceptos y describa mediante un
ejemplo la relación que existe entre ellos si es que existe: atributo básico y
derivado de calidad, requisito no funcional, requisito de calidad, catálogo de
atributos.
CUESTIÓN 1.6: Comente su interpretación sobre la gráfica propuesta por
Osmond para ilustrar los posibles caminos durante el proceso de desarrollo
software.
CUESTIÓN 1.7: Discuta sobre la madurez de la Ingeniería del Software
respecto de las ingenierías clásicas y otras profesiones.
2
Capítulo 1. Introducción al diseño software
Capítulo 2
Técnicas de representación
2.1 Cuestiones
CUESTIÓN 2.1:
Discuta sobre los criterios que suelen seguirse para decidir
entre utilizar agregación o composición.
CUESTIÓN 2.2:
¿De qué otra manera se conocen las agregaciones no compartidas en UML? ¿Por qué?
CUESTIÓN 2.3:
¿Qué diferencia existe entre un diagrama de clases de
análisis y un diagrama de clases de diseño?
CUESTIÓN 2.4:
CUESTIÓN 2.5:
¿Qué sabe sobre los diagramas de interacción de UML?
Muestre con un ejemplo simple la forma de expresar una
iteración en un diagrama de colaboración.
2.2 Problemas
Para realizar los siguientes problemas asuma la existencia de una clase
que guarda una relación de agregación con la clase y de una clase . 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.
4
Capítulo 2. Técnicas de representación
PROBLEMA 2.1: Elabore el diagrama de colaboración correspondiente a
la acción de comprimir una carpeta.
PROBLEMA 2.2:
Elabore el diagrama de colaboración correspondiente a la
acción de comprimir una carpeta asumiendo que la clase dispone
de un método para comprimir el contenido completo de una carpeta.
PROBLEMA 2.3: Elabore el diagrama de colaboración correspondiente a
la acción de comprimir una carpeta y de enviarla por correo electrónico.
PROBLEMA 2.4:
Elabore el diagrama de colaboración 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.
PROBLEMA 2.5:
Elabore el diagrama de secuencias equivalente a los diagramas de colaboración requeridos en los anteriores problemas.
Capítulo 3
Patrones generales de software para
asignar responsabilidades
3.1 Cuestiones
CUESTIÓN 3.1: ¿Qué contraindicación tiene el GRASP ?
CUESTIÓN 3.2: ¿Qué contraindicación tiene el GRASP ?
CUESTIÓN 3.3: ¿Qué contraindicación tiene el GRASP ?
CUESTIÓN 3.4: Comente al menos tres mecanismos propuestos para la
protección de alguna variación.
CUESTIÓN 3.5:
Discuta sobre los otros nombres que ha recibido el GRASP
.
CUESTIÓN 3.6:
Discuta sobre si el acoplamiento es o no una propiedad
no deseable.
CUESTIÓN 3.7:
CUESTIÓN 3.8:
¿Qué sabe sobre la conocida como “Ley de Demeter”?
¿Qué entiende Craig Larman por principios evaluativos?
Indique al menos dos ejemplos de dichos principios.
CUESTIÓN 3.9:
¿Qué sabe acerca de la medición del grado de cohesión de
una clase?
CUESTIÓN 3.10: Justifique razonadamente su opinión sobre si es posible
sistematizar la asignación de responsabilidades durante el diseño.
6
Capítulo 3. Patrones generales de software para asignar responsabilidades
CUESTIÓN 3.11: ¿Qué entiende por punto de variación y de evolución?
¿Qué GRASP trata de manera más directa con ambos puntos y qué otros nombres recibe dicho GRASP?
CUESTIÓN 3.12:
¿Qué sabe sobre el conocido como ”principio de sustitu-
ción de Liskov”?
3.2 Problemas
PROBLEMA 3.1: En un sistema de gestión ferroviaria debe mantenerse
la información relativa a trayectos y trenes que los realizan. La información
relacionada está estructurada según el diagrama de clases de la figura 3.1.
Dos de las operaciones del sistema son: establecer nuevos trayectos y suprimir trayectos. La definición de dichas funciones son:
!
"
#$
donde y son referencias a la estación de origen y destino respectivamente, y las horas de salida y llegada, y una lista de referencias a estaciones
de tránsito y la hora de dicho tránsito. Esta operación debe buscar un tren que
esté disponible e incluir el nuevo trayecto en el sistema según el diagrama de
clases propuesto.
% $
donde y son referencias a la estación de origen y destino respectivamente, y y las horas de salida y llegada. Esta operación debe: (1) buscar el
trayecto en cuestión, (2) suprimir tanto su origen como su destino, (3) suprimir
todos los tránsitos, y (4) liberar al tren que realizaba el trayecto.
A) Justifique brevemente en lenguaje natural los GRASP que considera aplicables para asignar las responsabilidades que se derivan de realizar ambas operaciones.
B) El diagrama de clases resultante de asignar las responsabilidades que se
derivan de realizar ambas operaciones.
C) El diagrama de colaboración correspondiente a la operación de establecer un trayecto.
D) El diagrama de secuencias correspondiente a la operación de suprimir
un trayecto.
3.2. Problemas
7
ofrece
1
Compañía
Ferroviaria
1..*
1
1..*
1
Tren
*
realiza
posee
Trayecto
*
*
*
Partida
Destino
Horario
Horario
1
1
Estación
*
Figura 3.1: Dominio de información sobre gestión ferroviaria.
Tránsito
Horario
8
Capítulo 3. Patrones generales de software para asignar responsabilidades
Capítulo 4
Patrones de diseño
4.1 Cuestiones
CUESTIÓN 4.1:
¿Un paquete con clases para construir ventanas de diálogo
es un framework o una biblioteca?
CUESTIÓN 4.2:
¿Qué entiende por idiom? ¿Qué relaciones encuentra
entre idiom y patrón de diseño?
CUESTIÓN 4.3:
¿Cuál es la diferencia entre un toolkit y un framework? ¿y
entre un framework y un patrón de diseño?
CUESTIÓN 4.4:
Describa lo más detalladamente posible los aspectos a
tener en cuenta cuando se trata de implementar el PD Singleton en JAVA.
CUESTIÓN 4.5:
Justifique mediante un ejemplo o contraejemplo si existe
o no en JAVA alguna posibilidad de extender en una clase derivada el comportamiento de un método definido como & en su clase base.
CUESTIÓN 4.6:
¿Qué condición debe cumplirse para considerar que un
método es un método plantilla?
CUESTIÓN 4.7:
Uno de los inconvenientes del PD Estrategia es que el
cliente de la estrategia está obligado a conocer las clases que implementan las
diferentes estrategias. Si el número de estrategias y de criterios de decisión es
elevado ¿existe alguna manera de facilitar el uso de estrategias por parte del
cliente?
CUESTIÓN 4.8: Uno de los inconvenientes potenciales del PD Estrategia es
la creación innecesaria de objetos estrategias. Proponga el diseño de al menos
10
Capítulo 4. Patrones de diseño
dos alternativas para resolverlos indicando las ventajas e inconvenientes de
cada una de ellas.
CUESTIÓN 4.9:
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.
CUESTIÓN 4.10:
Discuta sobre si le parece contradictoria o no la expresión
”nuevo patrón de diseño”.
CUESTIÓN 4.11:
Describa la relación, si es que existe, entre patrón de
diseño y GRASP.
CUESTIÓN 4.12:
Discuta razonadamente sobre las ventajas e inconvenientes de aplicar el PD Singleton cuando se aplica el PD Factoría.
CUESTIÓN 4.13:
Indique la motivación, la estructura estática y un ejemplo
de uso por parte del JDK de JAVA del PD Adaptador.
4.2 Problemas
En esta sección se presentan algunos problemas propuestos en examenes
de la asignatura Ingeniería del Software II de Ingeniería Informática. La mayoria de sus apartados pueden ser realizados con los conocimientos impartidos
en Ingeniería del Software de Gestión II de Ingeniería Técnica en Informática
de Gestión.
PROBLEMA 4.1: [ISW2-nov02] Se desea construir un módulo para conver-
tir documentos escritos con el procesador de textos de la empresa ACME. La
lista de formatos de salida que debe contemplar la aplicación no se conoce en
su totalidad, aunque se sabe que deberá incluir los formatos PDF (Portable Document Format) y PS (PostScript). En el caso de la conversión a PS se dispone
de un programa externo (%'() que realiza la conversión de un archivo en formato ACME a un archivo en formato PS. Proponga un diseño basado
en patrones para dicho módulo respetando el principio abierto/cerrado y garantizando que con dicho módulo no sea posible realizar dos conversiones al
mismo tiempo.
A) Indique el diagrama de clases UML de su diseño teniendo presente que:
¯ La instrucción para utilizar el programa % sigue el formato:
% )' )'
.
4.2. Problemas
11
¯ El formato ACME considera que un archivo tiene dos tipos de elementos: palabra y comando
¯ Utilice notas para indicar la responsabilidad de cada clase y la signatura completa de sus métodos
¯ Debe documentar los aspectos de implementación más relevantes
(esto es, los que se han destacado en las clases de teoría)
B) Indique el diagrama de secuencias correspondiente a una conversión a
formato PS.
C) Indique el fragmento en lenguaje JAVA correspondiente a la invocación
(desde el cliente) de dos conversiones consecutivas: una del archivo
*)+,' a PS y otra del archivo *)+-' a PDF.
PROBLEMA 4.2: [ISW2-feb03] A partir del código indicado se le pide que:
a) Indique su diagrama de clases asociado.
b) Indique el diagrama de objetos asociado a la ejecución del método de la clase .
c) Indique la salida del programa por la consola.
d) Indique en lenguaje natural la responsabilidad, que en su opinión, tiene
cada una de las clases.
e) Indique justificadamente los patrones de diseño de los que, en su opinión, se está haciendo uso.
f) ¿Qué papel juega en su opinión la clase ...
? Discuta
sobre las consecuencias de su eliminación.
/ +''0
'0
& 1 2
3 4/$
3 4/% $
5
& 1 42
1 % 1 $
1 % $
5
12
Capítulo 4. Patrones de diseño
& 16 (
1 1 425
6 16 2
+ 4 7 8 )4$
+ % &7 99
3 4/ $ 2 4/&$ 5
3 4/ % $ 2
1 3 7 1 $ '$
7 '4/$
$
5
1 % $ 2 1 $ '
$ 5
1 % 1 $ 2 1 $ '
$5
5
2
$25
+ %"# $ 2
1 &7 8 $
1
7 1
$ &'4/9*9$
'
$
1
:7 1
$ &'4/9;19$
:'
$
6 &7 8 6 $
1
7 1
$ &'4/9*9$
'
$
1
:7 1
$ &'4/9;19$
:'
$
1
7 1
$ &'4/9*<=9$
& 77$
%
''9>? 8 9$
1
-7 1
$ &'4/9*<=9$
-'
$
&- 77 $
%
''9> )+ 8 &
9$
%
''91& )
+) &9$
5
5
/ '0
344@*!'0
& 1
2 + $ 5
4.2. Problemas
13
1 2
% &7 9*9
3 4/ $ 2 4/&$
3 4/ % $ 2
3 & 'A
9*9$$ 7 8 *
$
7 8 ;1
$
5
5
6 (
6 2
6 $ 2
9*91 $ 8 *
$$
9;191 $ 8 ;1
$$
9*<=91 $ 8 *<=
$$
5
5
;1
1
2
;1
$2%
''9 ;1
9$5
+ $2%
''9
'''9$5
5
*<=
1
2
*<=
$2%
''9 *<=
9$5
+ $2%
''9
'''9$5
5
*
1
2
14/ *
$2
7 8 4/
$
%
''9 *
9$
5
+ $2
%
''9
'''9$
'9*
9B$
'* 9%,'
99%,'
9$
'* 9,'(99,'(9$
'
$
5
5
*
1 2
3 4/$2 1
$ 8 *
$5
3 4/% $ 2 1
$ 8 *
$5
5
;1
1 2
3 4/$2 4/99$5
14
Capítulo 4. Patrones de diseño
3 4/% $ 2 8 ;1
$5
5
*<=
1 2
+ 3 7 3 4/$2 C1
99$5
3 4/% $ 2 C1
$5
5
): 3 C1
% $2
& 77$ 7 8 *<=
$
5
+ $ 2 &D7 $ 7 5
PROBLEMA 4.3: [ISW2-feb03] En la biblioteca de .NET existe una clase de
nombre 61& que proporciona acceso a la información de un directorio. De acuerdo con la especificación del fabricante, dicha clase no proporciona
ningún método para obtener los archivos que cuelgan de dicho directorio y de
todos sus subdirectorios. Dado que dicha funcionalidad es estrictamente necesaria para nuestra aplicación y queremos mantener un estilo de programación
orientada a objetos. Proponga una solución con la que se consiga definir una
clase de nombre con un método de nombre E)
y todos los
métodos que ofrece 61&, teniendo en cuenta que:
¯ La clase 61& no puede ser extendida, es decir, que no pueden
definirse clases que deriven de ella.
¯ Debe respetarse el principio abierto/cerrado y mantener el máximo grado de desacoplamiento.
Estructure la solución en los siguientes apartados:
A) Diagrama de clases.
B) Implementación de los métodos relevantes de la clase de acuerdo
a la siguiente definición:
5
& 61&2
61& ) $
FF ) A FF &
(
$
FF ++ ) (
FF &
'
'''
4.2. Problemas
15
C) Ejemplo en JAVA de cómo comprobar si existe una determinada carpeta
o directorio.
D) Diagrama de objetos o de interacción asociado a dicho ejemplo.
E) Indicación de los patrones de diseño utilizados. (Sólo si procede)
PROBLEMA 4.4: [ISW2-jun03] Se necesita diseñar un módulo para comprimir archivos en diferentes formatos. Los formatos que debe soportar son ZIP
y RAR, pero es más que probable que en el futuro se necesite desarrollar una
nueva versión del módulo que soporte otros formatos. El módulo debe ofrecer
métodos para que los clientes soliciten la creación de objetos de un subtipo de
1
(ver apartado A) de acuerdo al formato solicitado por el cliente.
En esta solicitud, se debe poder indicar que se desea el registro de todas las
peticiones de compresión realizadas por el cliente. Proponga un diseño basado en patrones para dicho módulo respetando el principio abierto/cerrado y
buscando el mayor rendimiento y la máxima reutilización de su implementación.
A) Indique el diagrama de clases UML (con la signatura completa de sus
métodos) de dicho diseño teniendo presente que:
¥ La definición en JAVA de la interfaz 1
es:
& 1
2
+ % &G$
5
¥ Existe una clase de objetos de nombre que proporcionan la
funcionalidad necesaria para registrar mensajes en un archivo de
log. Dicho clase implementa la interfaz 1 cuya definición en
JAVA es
& 1 2
+ % $
5
¥ Debe documentar los aspectos de implementación más relevantes
(esto es, los que se han destacado en las clases de teoría)
B) Defina en JAVA una clase de nombre ( que muestre las posibilidades de uso de dicho módulo por un cliente que desea comprimir el
archivo de nombre '.
16
Capítulo 4. Patrones de diseño
PROBLEMA 4.5: [ISW2-mar04] Se necesita diseñar un framework para facilitar el desarrollo de ventanas de diálogo de autenticación. Deberá contemplar
que el procedimiento de acceso a la información sobre las cuentas de usuario
podrá variar para cada aplicación construida a partir del framework y que una
misma aplicación podrá necesitar utilizar diferentes mecanismos de acceso.
También deberá contemplar que el comportamiento ante una autentificación
fallida podrá variar entre aplicaciones y que éste debería poderse seleccionar
en tiempo de ejecución.
Proponga el diseño de una aplicación de ejemplo que a partir del framework permita:
¯ el acceso de usuarios con cuentas en H)'I y usuarios con cuentas almacenadas en un fichero local.
¯ seleccionar el comportamiento ante autentificaciones fallidas: permitir
un máximo de tres reintentos o un número ilimitado de intentos en el
que el tiempo de respuesta se duplique por cada reintento.
A) Indique el diagrama de clases UML (con la signatura completa de sus
métodos) de dicho diseño teniendo presente que:
¥ La interfaz de las clases que implementan el mecanismo de autenticación es:
& 1
8)/ 2
)/% % 8$
5
¥ El método )/J
de la clase 4( es responsable de autenticar a los usuarios de Hotmail, y su contrato sintáctico es: )/J
% % 8$ donde representa al nombre de la cuenta sin el dominio. Por ejemplo, el login del usuario
K)' sería ¥ La clase base para construir ventanas de autenticación es !6.
Su método )8 es responsable de su visualización en pantalla y su
método abstracto ) será invocado cada vez que se solicite la autenticación al pulsar el botón de aceptar (no es relevante
para el problema en cómo será invocado). Su contrato sintáctico es:
+ ) % % 8$
¥ La interfaz de las clases que implementan el comportamiento ante
fallos es:
& 1*)<+ 2
4.2. Problemas
5
17
+ )% % 8$
¥ Debe documentar los aspectos de implementación más relevantes
(esto es, los que se han destacado en las clases de teoría)
B) Muestre el diagrama de secuencias asociado a un escenario en el que un
usuario se identifica en el sistema con su cuenta en '
PROBLEMA 4.6: [ISW2-sep04] Se necesita diseñar de un módulo para resolver sistemas de ecuaciones teniendo en cuenta los siguientes condicionantes:
1 El método de resolución a emplear dependerá del sistema a resolver. La
relación de métodos de resolución no se conoce a priori
2 La interfaz de las clases que implementan algún método de resolución
debe ser: & 1%+ !
%+% $ donde el método %+ debe devolver una de las posibles soluciones del sistema como una lista de valores. El orden de dicha lista se corresponde con el
orden lexicográfico de sus incógnitas. Por ejemplo, para el sistema formado por L7M y N7,, se obtendría un objeto del tipo !
del JDK con
los valores 3 y 2.
3 Para resolver sistemas lineales, debe utilizar objetos de la clase <
!*4,
que tiene un contrato semántico equivalente al de 1%+, pero con un
contrato sintáctico diferente: +%
!
$ donde representa a la clase del JDK que implementa la
interfaz !
4 Para conocer el tipo de un sistema, debe usar el singleton 64), más
concretamente su método %
%$ %
%
A) Justifique brevemente en lenguaje natural los patrones de diseño que
considera aplicables en el diseño de este módulo.
B) 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. Se recomienda un diagrama apaisado.
C) Defina una clase de nombre Example que muestre el uso del módulo
para resolver el sistema formado por L7M y N7,.
18
Capítulo 4. Patrones de diseño
D) Justifique brevemente en lenguaje natural los patrones de diseño que
considera aplicables al diseño del apartado B y las modificaciones necesarias para que el módulo pudiera registrar el tiempo invertido en solucionar un sistema de ecuaciones.
PROBLEMA 4.7: [ISW2-dic04] Se necesita diseñar un módulo del sistema
de gestión de una tienda que permita calcular el precio final de cada venta
realizada, teniendo en cuenta que:
¯ La política de precios puede variar a lo largo del tiempo. Durante un
período podría aplicar un descuento del 10% si el importe de la venta es
superior a un determinado valor umbral. En otro período podría ser el
10% independientemente del importe.
¯ El módulo deberá estar protegido de la incorporación de nuevas políticas de precios.
¯ El módulo deberá permitir que el administrador del sistema pueda variar la política de precios en cualquier momento.
¯ Uno de los posibles clientes del módulo está representado por una clase
de objetos de nombre cuyo método %6
devuelve el precio sin descuento de una venta y cuyo método devuelve el precio resultante de aplicar el correspondiente descuento.
A) Justifique brevemente en lenguaje natural los GRASP y patrones de diseño que considera aplicables en el diseño de este módulo.
B) 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 (se recomienda un diagrama apaisado).
C) Defina una clase de nombre que muestre el uso del
módulo para obtener el precio final de un producto cuyo valor supera el
umbral para aplicar el 10% de descuento
D) Elabore el diagrama de secuencias asociado a la operación de obtener
precio final del ejemplo anterior. Incluya las interacciones entre los objetos del módulo.
E) Justifique brevemente en lenguaje natural los GRASP y/o patrones de
diseño que considera necesarios para modificar el modulo anterior a fin
dar la posibilidad de que existan diferentes políticas de precios al mismo
tiempo y que el cálculo del precio final de cada venta sea el mejor para
el cliente o el mejor para la tienda según lo decida el vendedor.
Respuestas
CUESTIÓN 1.1: Un requisito indispensable para considerar una profesión como tal es que ésta cuente con un cuerpo de conocimiento generalmente
aceptado.
CUESTIÓN 1.2: Se corresponde con Software Engineering Body of Knowledge. ACM/IEEE.
CUESTIÓN 1.3:
En el interés en desarrollar productos a tiempo y de acuerdo a un presupuesto. También, aunque en menor medida, en la necesidad de
utilizar métodos y técnicas procedentes de otras disciplinas.
CUESTIÓN 2.2:
La agregación en UML puede ser compartida (rombo
hueco) y no compartida (rombo relleno), ésta última también conocida como
agregación de composición o simplemente composición. El calificativo de no compartida subraya la exigencia de que la parte de la agregación sea miembro de
un único objeto conpuesto, en otras palabras, que no esté compartida.
CUESTIÓN 3.6:
El acoplamiento entre clases es estrictamente necesario,
de otro modo, tendríamos que codificar cualquier programa orientado a objetos en una única clase. El acoplamiento deja de ser deseable en el momento
en el que alguna de las clases que intervien es inestable, pues los cambios en
la sintaxis o semántica de esta requerirán modificar las clases desde las que se
utiliza.
PROBLEMA 4.3:
A) La figura 4.a muestra el diagrama de clases de una posible solución.
B) La implementación de los métodos relevantes de la clase se encuentra en las notas de la figura 4.a:
20
Respuestas
C) El siguiente fragmento de código JAVA ilustra como utilizar la clase para saber si existe la carpeta “c://temp”. determinada carpeta o directorio.
2
+ $ 2
&7 8 HFFI$
& &'(
$$
%
''H
/I$
%
''HI$
5
5
D) La figura 4.b, muestra el diagrama de secuencias correspondiente al
ejemplo de la sección anterior.
E) Si se considera que la clases 61& ofrece una interfaz que sólo
puede ser utilizada por el cliente si ésta se extiende, está claro que estamos ante un problema donde resulta aplicable el PD Adapter. Dado que
la clase a adaptar no puede ser extendida, estamos obligados a realizar
una adaptación por delegación.
PROBLEMA 4.4:
A) La figura 5 muestra el diagrama de clases propuesto.
B) La definición en JAVA de la clase ( es la siguiente:
( 2
+ $ 2
1
&7 '1
$
FF )+ H
'I & ;1
7 &'
H;1I$
'
H
'I$
FF )+ & <*< FF A 7 &'
H<*<I$
'
H
'I$
5
5
Aunque no se pedía en el enunciado, la figura 6, ilustra el diagrama de
secuencias asociado al ejemplo de uso de la clase (.
Respuestas
21
(a) Diagrama de clases.
(b) Diagrama de secuencias.
Figura 1: Diagrama de clases y de secuencias del problema 4.3.
22
Figura 2: Diagrama de clases del problema 4.4.
Respuestas
Respuestas
Figura 3: Diagrama de secuencias del problema 4.4.
23
24
Respuestas
This document was typeset on // using RC–BOO
K « . for LATEX¾¯ .
Should you want to use this document class, please send mail to
[email protected].