Posible solución al segundo parcial

Ingeniería del Software II - 8 de junio de 2007
Pág: 1/13
Apellidos y nombre
D.N.I. o pasaporte
Los tests pueden tener una, varias o ninguna respuesta correcta. En caso de marcar todas las respuestas correctas sumará 0’2 ptos.; en caso de
marcar alguna respuesta incorrecta o no marcar
todas las respuestas correctas restará 0’1 ptos.; si
no marca ninguna respuesta, entonces no puntuará;
si no queda clara cuál es su respuesta a alguna
pregunta, su nota en el test correspondiente será de
0 ptos. Si marca como respuesta “d. Ninguna de las
anteriores”, debe justificar brevísimamente su decisión. Indique sus respuestas en la siguiente tabla.
Para marcar una respuesta escriba una equis (x).
No se dará por válida ninguna otra marca.
T1
a
b
c
1
Alta cohesión, bajo acoplamiento
y variaciones protegidas
2
3
d
T3
X
2
5
X
a
B
1
c
d
X
X
X
3
X
4
X
5
X
3
X
4
X
5
X
6
7
X
X
X
9
X
Modelo de análisis modela el
dominio del problema y modelo
de diseño modela el software
X
X
X
8
X
X
c
Nota
d
Abierto para extensión, pero
cerrado para modificación
X
4
2
b
1
10
T2
a
Código
Pág: 2/13
Ingeniería del Software II
Ingeniería del Software II - 8 de junio de 2007
Apellidos y nombre
Pág: 3/13
D.N.I. o pasaporte
Código
Nota
T1 (1 Punto): Principios de asignación de responsabilidades (GRASP)
1. Los tres patrones GRASP más importantes son:
a.
b.
c.
d.
Alta cohesión, bajo acoplamiento e indirección
Experto en información, indirección y variaciones protegidas
Baja cohesión, alto acoplamiento y variaciones protegidas
Ninguna de las anteriores.
2. ¿En qué consiste el principio de sustitución de Liskov?
a. En que hay que reducir al máximo las interacciones con otras clases. Es lo que también se conoce como el principio de mínimo conocimiento.
b. En que una clase padre debe poder sustituirse por cualquiera de sus clases hijas sin que afecte
al correcto funcionamiento del sistema.
c. En que, en ocasiones, es necesario sustituir una clase por otra para conseguir que la cohesión
de la aplicación mejore.
d. Ninguna de las anteriores.
3. ¿Cuáles de los siguientes mecanismos forman parte del GRASP Variaciones Protegidas?
a. Asegurar que si dos clases implementan una misma interfaz, podemos sustituir una por otra en
el sistema de manera transparente, es decir, sin que afecte al correcto funcionamiento del sistema.
b. Crear una clase que no representa un concepto del dominio del problema.
c. Tratar que nuestro sistema esté abierto para la extensión, pero cerrado para la modificación.
d. Ninguna de las anteriores.
4. ¿Cómo se mide el acoplamiento de una clase?
a. Sumando el número de clases con las que interactúa y dividiéndolo entre el número total de clases que hay en el sistema.
b. Es difícil medir el acoplamiento, pero, en general, podemos fijarnos exclusivamente en si tiene
muchas clases hijas o no. Si tiene muchas subclases entonces el acoplamiento es elevado.
c. Es difícil medir el acoplamiento, lo que importa es tener una idea del grado de acoplamiento y de
si, el incrementarlo puede dar lugar a problemas.
d. Ninguna de las anteriores.
5. Respecto al GRASP Fabricación Pura:
a. Define el principio en el que se basan los patrones de diseño Fábrica Abstracta y Método Fábrica.
b. Las fabricaciones puras suelen ser cohesivas y en muchas ocasiones mejoran el acoplamiento.
c. Una fabricación pura ofrece una solución específica para la creación de objetos.
d. Ninguna de las anteriores.
Pág: 4/13
Ingeniería del Software II
T2 (1 Punto): Introducción a los patrones de diseño.
1. El principio de Hollywood:
a. Es el utilizado en los frameworks para que al añadir las piezas que faltan podamos modificar el
código del framework fácilmente. Esto se consigue dado que es nuestro código el que llama al
framework, y no es éste el que tiene que llamarnos a nosotros.
b. Es utilizado en las bibliotecas pues no es la biblioteca la que llama a nuestro código, sino que es
nuestro código el que llama al de la biblioteca.
c. Es usado en los frameworks de forma que es el framework el que llama al código que nosotros
proporcionamos.
d. Ninguna de las anteriores
2. Los patrones de diseño son útiles porque:
a. Dan soluciones generales a problemas comunes que luego yo puedo aplicar a mi diseño adaptándolos a mi caso concreto.
b. Me proporcionan una buena forma de reutilizar conocimiento.
c. Garantizan la ausencia de errores en su implementación.
d. Ninguna de las anteriores.
3. ¿Por qué se le da tanta importancia al nombre de los patrones de diseño?
a. Porque es la única forma de diferenciarlos de los idioms.
b. Porque sirven para construir un vocabulario de ingeniería del software.
c. Porque es la manera comúnmente aceptada para definir cuál es el problema general que resuelve un patrón de diseño.
d. Ninguna de las anteriores.
4. Los antipatrones:
a. Son patrones de diseño que contrarrestan las desventajas de otros patrones de diseño
b. Definen malas técnicas de diseño para que puedan ser evitadas
c. Se pueden asociar siempre a un patrón de diseño creando un par patrón/antipatrón. De esta
forma, cuando un patrón de diseño es necesario y no se aplica, aparece su antipatrón
d. Ninguna de las anteriores
5. ¿Cuál de las siguientes es una diferencia entre los modelos de clases de análisis y los de diseño?
a. Los modelos de análisis no usan herencia para relacionar clases, mientras que los de diseño sí.
b. Aunque tanto el modelo de análisis como el de diseño están modelando el dominio del problema,
el modelo de análisis es menos detallado, mientras que el de diseño da un mayor nivel de detalle.
c. La notación para representar modelos de análisis y modelos de diseño es totalmente diferente.
d. Ninguna de las anteriores
Ingeniería del Software II - 8 de junio de 2007
Apellidos y nombre
Pág: 5/13
D.N.I. o pasaporte
Código
Nota
T3 (2 Puntos): Patrones de diseño.
1. El principio abierto/cerrado quiere decir que:
a. Las clases se deben poder modificar fácilmente para cambiar la funcionalidad.
b. Debemos escribir aplicaciones de código abierto en lugar de código cerrado, pues así se facilita
el que otros programadores puedan realizar el mantenimiento del software.
c. Las clases deben estar abiertas para la modificación de la implementación, pero cerradas para
cambios en la interfaz.
d. Ninguna de las anteriores.
2. Si queremos conectarnos a un subsistema que proporciona una interfaz adecuada:
a. Usaremos fachada en caso de que el código existente utilice una interfaz distinta a la proporcionada y la modificación del código existente sea más costosa que añadir un adaptador o varios.
Así podremos usar el subsistema directamente en aquellos casos en los que nos interese
b. Usaremos adaptador en caso de que el código existente utilice una interfaz distinta a la proporcionada y la modificación del código existente sea más costosa que añadir un adaptador o varios
c. Usaremos decorador para modificar el código que consume la interfaz del subsistema. Así podremos modificar en tiempo de ejecución el subsistema a consumir aplicando un decorador u
otro.
d. Ninguna de las anteriores
3. El patrón decorador:
a. Utiliza la herencia como mecanismo para extender comportamiento.
b. Únicamente se debe utilizar cuando se produzca una explosión de herencia.
c. Se utiliza como alternativa a la herencia cuando se pueden quitar y añadir responsabilidades dinámicamente.
d. Ninguna de las anteriores.
4. ¿Qué diferencia existe entre el adaptador de clase y el adaptador de objeto?
a. El adaptador de clase, como utiliza la herencia, permite adaptar una clase y a cualquiera de sus
hijas, mientras que el adaptador de objeto sólo permite adaptar una única clase.
b. El adaptador de clase utiliza composición para realizar la adaptación, mientras que el de objeto
hace uso de la herencia.
c. El adaptador de objeto puede servir para adaptar a una clase y a todas sus hijas, mientras que el
adaptador de clase sólo permite realizar la adaptación de una única clase.
d. Ninguna de las anteriores.
5. El patrón método plantilla:
a. Permite cambiar en tiempo de ejecución la forma en que se ejecuta un algoritmo.
b. Utiliza herencia y composición. Herencia para añadir nuevo comportamiento al algoritmo y composición para poder variarlo en tiempo de ejecución.
c. Es adecuado para implementar frameworks.
d. Ninguna de las anteriores
Pág: 6/13
Ingeniería del Software II
6. Al usar la Fábrica Simple estamos pasando el problema de creación del cliente a otra clase (la fábrica),
pero no lo evitamos. ¿Qué conseguimos con esto?
a. Realmente no se consigue nada porque la fábrica simple sólo tiene sentido cuando se pone junto al patrón estrategia. Entonces conseguimos desacoplar las estrategias concretas del cliente.
b. Estamos consiguiendo incrementar la cohesión de nuestra aplicación porque la responsabilidad
de crear objetos de un determinado tipo, en lugar de estar distribuida a lo largo de la aplicación,
se encuentra centralizada en una única clase.
c. Estamos consiguiendo disminuir el acoplamiento de nuestra aplicación, pues la fábrica desacopla los clientes de las distintas implementaciones de una interfaz.
d. Ninguna de las anteriores.
7. ¿Cuáles son las ventajas de usar el PD Fábrica Abstracta para manejar familias de productos?
a.
b.
c.
d.
Me asegura que todos los productos que estoy usando pertenecen a una misma familia.
Permite añadir fácilmente nuevos productos cuando los necesito.
Permite cambiar de una manera sencilla de usar una familia de productos a otra.
Ninguna de las anteriores.
8. ¿De qué manera nos protege del cambio el PD Estrategia?
a. Utiliza la herencia, de manera que se definen los pasos comunes del algoritmo en una clase abstracta y usa clases concretas para detallarlos.
b. Definiendo una interfaz común para los distintos algoritmos haciéndolos así intercambiables y
usando composición para delegar en un algoritmo concreto.
c. Sugiere utilizar el PD Singleton para que, al cambiar de estrategia, no tengamos que crear un
objeto nuevo cada vez.
d. Ninguna de las anteriores.
9. Entre las diferencias entre el patrón fachada y el adaptador están:
a. El adaptador sólo se puede aplicar a una clase, mientras que la fachada se puede aplicar a varias.
b. La diferencia es en la intención: el adaptador pretende alterar la interfaz para convertirla a la que
necesitamos, mientras que la fachada simplifica un subsistema.
c. Puede haber muchos adaptadores para una interfaz, pero la fachada es única para cada subsistema.
d. Ninguna de las anteriores.
10. Entre las diferencias entre el patrón estrategia y el método plantilla están:
a. El patrón estrategia utiliza composición para definir familias de algoritmos, mientras que el método plantilla usa la herencia para reutilizar los pasos del algoritmo.
b. El método plantilla permite cambiar el algoritmo en tiempo de ejecución, mientras que el estrategia no lo permite.
c. El método plantilla nos permite reutilizar comportamiento, mientras que en el patrón estrategia
nunca se reutiliza código.
d. Ninguna de las anteriores.
Ingeniería del Software II - 8 de junio de 2007
Apellidos y nombre
Pág: 7/13
D.N.I. o pasaporte
Código
Nota
P1 (3 Puntos):
Se desea añadir un subsistema de pedidos de compra a la aplicación de consulta de libros, música y películas
vista en las prácticas de la asignatura. Dicho subsistema permitirá que una clase "OrderFrm“ del interfaz de
usuario muestre al usuario registrado en la aplicación las órdenes de compra que tiene pendientes y las que ya
ha realizado obteniéndolas de la base de datos. Además le permitirá agregar nuevas órdenes de compra. Una
misma orden de compra puede contener distintas líneas de detalle de la compra. Cada línea de detalle solicitará
una determinada cantidad de un producto concreto. De cada orden de compra el usuario podrá solicitar información sobre la misma: fecha de la orden de compra (orderDate), fecha de recepción de la orden de compra por
parte del usuario (deliverDate), productos comprados, … . Si la orden de compra aún no ha sido recibida por el
usuario podrá consultar además información del estado en que se encuentra: medio de transporte y localización
actual de la orden de compra. Esta información será aportada por un subsistema externo que depende de la
compañía de mensajería utilizada para la orden de compra. Actualmente se tiene contrato con la compañía
"QuickPostal" pero se prevé que pueda cambiar de compañía de mensajería en el futuro.
El diseño inicial propuesto para este nuevo subsistema, en el que se obvian las clases no relevantes, es el siguiente:
Pág: 8/13
Ingeniería del Software II
Se pide:
A. Evalúe el diseño anterior utilizando los GRASP evaluativos.
•
•
•
OrderFrm:
i. Baja Cohesión: métodos poco cohesivos entre sí como por ejemplo “getOrders” para
obtener las órdenes de compra almacenadas en la base de datos, “get---Info” para obtener la información del subsistema de la compañía de mensajería, “addOrders” para añadir más pedidos de un usuario y otros para mostrar la información en la interfáz gráfica
de usuario.
ii. Alto Acoplamiento: con el subsistema de la compañía de mensajería (que sabemos
que va a variar en el futuro), y con Order.
Order:
i. Alta Cohesión: puesto que sus métodos tienen que ver con las líneas de detalles de
una orden de compra específica.
ii. Bajo Acoplamiento: ya que no se a pesar de estar muy acoplada con la clase “Deail”,
no se dice en el enunciado que dicha clase vaya a variar a en un futuro.
Detail:
i. Alta Cohesión: puesto que sus métodos sólo servirán para obtener o fijar los atributos
de la clase.
ii. Bajo Acoplamiento: ya que no está acoplada con ninguna otra clase del sistema.
B. Modifique el diseño propuesto haciendo uso de los GRASP y patrones de diseño que estime oportuno.
PD:
• Adaptador para los distintos subsistemas de las compañías de mensajería.
• Fechada para el acceso a la base de datos.
Ingeniería del Software II - 8 de junio de 2007
Pág: 9/13
Apellidos y nombre
D.N.I. o pasaporte
Código
Nota
A parte se ha refactorizado las responsabilidades que hacían a OrderFrm poco cohesiva, como por ejemplo
las de acceso a la BD para recuperar las órdenes, así como la de añadir una nueva orden de compra del
usuario e incluso la responsabilidad de almacenar las órdenes de compra.
isw2.traceSystem
qPostal.traceSystem
QPostalTrace
Adapter: “Target”
«interfaz»
ITrace
+getTransportInfo(entrada idOrder : string)
+getLocalizationInfo(entrada idOrder : string)
+TransportInfo(entrada codOrder : string)
+LocalizationInfo(entrada codOrder : string)
new.traceSystem
...Trace
Adapter: “Adapter”
QPostalTrace
NewTrace
+getTransportInfo(entrada idOrder : string)
+getLocalizationInfo(entrada idOrder : string)
+getTransportInfo(entrada idOrder : string)
+getLocalizationInfo(entrada idOrder : string)
Adapter: “Adaptee”
+...()
isw2.gui
Adapter: “Client”
OrderFrm
+doShowOrders(entrada client : userProfile)
+doAddOrder()
+doShowOrderInfo(entrada idOrder : string)
isw2.dataBase
Isw2.sale
Orders
-orders : Set<Order>
+getOrders(entrada client : userProfile) : Set<Order>
+addOrder(entrada client : userProfile)
Order
Detail
-idDetail : string
-quantity : int
-item : Item
BD
-idOrder : string
-details : Set<Detail>
-state : string
-client : userProfile
-orderDate : Date
-deliverDate : Date
+addDetail(entrada quantity : int, entrada item : Item)
+deleteDetail(entrada idDetail : string)
Pág: 10/13
Ingeniería del Software II
C. Justifique el diseño anterior mediante el número de memorandos técnicos que necesite, prestando especial atención a los GRASP aplicados y a la mejora conseguida en lo referente a cohesión y acoplamiento.
Mediante uno o varios memorandos habría que indicar al menos la siguiente información:
• Cohesión: Ha mejorado la cohesión de la clase “OrderFrm” mediante la refactorización de las
responsabilidades de las clases. Creándose una nueva clase “Order” que se encarga de aquellas responsabilidades que hacían a OrderFrm poco cohesiva, como por ejemplo las de acceso a
la BD para recuperar las órdenes, así como la de añadir una nueva orden de compra del usuario
e incluso la responsabilidad de almacenar las órdenes de compra.
•
Acoplamiento: Se ha reducido el acoplamiento entre los subsistemas debido a la inclusión de un
adaptador entre el subsistema de la compañía de mensajería y la clase orderFrm.
Nota.- También se podría haber utilizado una Fachada en lugar de un Adaptador, e incluso una fábrica utilizada por la clase Order para crear las órdenes de compra.
Ingeniería del Software II - 8 de junio de 2007
Apellidos y nombre
Pág: 11/13
D.N.I. o pasaporte
Código
Nota
P2 (3 Puntos):
Se desea realizar un subsistema de cobro de pedidos para la aplicación de consulta de libros, música y películas
vista en las prácticas de la asignatura. Dicho subsistema cobrará al usuario la cuantía total de un pedido (un
objeto de la clase Order del enunciado del P1) mediante su tarjeta de crédito. Para ello, la clase Order incorpora el método pay() para realizar el pago. Las tarjetas de crédito que pueden utilizarse para realizar compras
son MisterCard, PISA y AmericanEspresso, haciendo uso de distintos servicios externos para el cobro mediante
cada una de ellas. Los proveedores de dichos servicios externos obligan a las aplicaciones que los usen a que el
usuario incorpore su número de tarjeta mediante una ventana independiente que muestre su logotipo respectivo.
Ya se ha implementado en la clase PayFrm una ventana que muestra los datos del pedido del usuario activo y
solicita al mismo que seleccione el medio de pago que vaya a utilizar. Según el medio de pago seleccionado en
esta ventana, la aplicación mostrará una nueva ventana correspondiente al medio seleccionado, para que el
usuario introduzca el número de su tarjeta.
Una vez el usuario introduzca su número de tarjeta, se volverá a la ventana implementada por PayFrm para realizar el pago correspondiente.
Se pide:
A. Ilustre mediante un diagrama de clases UML el diseño propuesto para el subsistema de cobro, tanto de
las ventanas como de la funcionalidad de cobro, teniendo en cuenta los comentarios del enunciado.
Realice en el diagrama las anotaciones que estime oportunas.
Pág: 12/13
Ingeniería del Software II
1
Order
PayFrm
+pay()
1
+showAccountFrm()
1
PD Estrategia: Context = Order;
Strategy = IPayMethod;
ConcreteStrategies = PISAAdapter, etc.
PD Método Plantilla
ShowLogo es abstracto
PD Adaptador
1
AccountFrm
«interfaz»
IPayMethod
+pay(entrada Account : String, entrada Amount : float)
PISAAdapter
MisterCardAdapter
+showLogo()
+getAccount() : String
AExpressoAdapter
«instance»
PISAFrm
«instance»
«instance»
MisterCardFrm
«instance»
«instance»
PISA
PISAFactory
MisterCardFactory
AExpressoFactory
+createPayMethod()
+createPayFrm()
+createPayMethod()
+createPayFrm()
+createPayMethod()
+createPayFrm()
MisterCard
AExpresso
«interfaz»
AbsFactory
+createPayMethod()
+createPayWindo()
AExpressoFrm
Ingeniería del Software II - 8 de junio de 2007
Apellidos y nombre
Pág: 13/13
D.N.I. o pasaporte
Código
Nota
B. Justifique el diseño anterior mediante el número de memorandos técnicos que necesite.
C. Se desea que el subsistema desarrollado sea capaz de soportar nuevos tipos de tarjeta de crédito (incluyendo el cobro y la ventana particularizada) sin necesidad de que para ello se modifique el código fuente. Modifique el diseño anterior incluyendo anotaciones en el diagrama con detalles de implementación.
Incluir un nuevo tipo de tarjeta de crédito (pej. 4B) supondrá el desarrollo de su propia ventana (4BFrm),
su adaptador con el sistema externo de cobro (4BAdapter) y la implementación de la fábrica abstracta
correspondiente (4BFactory). No sería necesario recompilar puesto que la aplicación tomaría los tipos de
tarjeta de crédito disponibles desde un archivo de configuración (pej. En formato XML).