ISI/DSS Junio 2004

Examen Resuelto
Normas a seguir:
Los apellidos, nombre y DNI se deben escribir en todas las hojas.
Se debe entregar cada pregunta en hojas separadas.

Pregunta 1 (3 puntos)

A partir del Diagrama de Flujo de Datos de la figura adjunta (ver reverso de

página) se pide:

a) identificar el número de transacciones existentes

b) derivar y refinar el/los diagrama/s de estructura correspondiente/s para cada
transacción/es
Pregunta 2 (1 punto)

Dado el diagrama de clases de la Fig. 1, definid en OCL las siguientes restricciones:

Anuncio-Controlador
-visualizaDatos
-dependeDe 1 +inicializa()
* +muestraAnuncio()
+actualiza()
Anuncio-Modelo
-datosBásicos 1 -actualiza
-conjuntoVistas[0..*]
+asociaVista()
+desenlazaVista()
+notifica()
+getDatosAnuncio()
+modificaAnuncio() 1

1 -actualiza Anuncio-Vista

+inicializa()
* +cambiaAnuncio()
+actualiza()

- El número de controladores asociados a un modelo debe coincidir con el

número de vistas asociadas a dicho modelo.
(Puntuación 0.5 ptos.)

context Anuncio-Modelo
inv: self.anuncio-Controlador->size() = self.anuncio-Vista->size()

- Para todo controlador asociado a un modelo debe existir una vista asociada
al modelo que a su vez esté relacionada con dicho controlador.
(Puntuación 0.5 ptos.)

context Controlador
inv: self.dependeDe=self.anuncio-Vista.actualiza

Si os fijáis en la cardinalidad de las relaciones, observaréis cómo cada modelo tiene n vistas, y cada vista
tiene un solo controlador asociado (y uno distinto para cada vista). Por tanto, un modelo debe tener tantos
controladores como vistas. Esto implica que la restricción se puede reescribir diciendo que el conjunto de
controladores asociados con un modelo debe coincidir con el conjunto de controladores asociados a las
vistas del modelo.

context Anuncio-Modelo
inv: self.AnunciosVista.AnunciosControlador=self.AnunciosControlador

Pregunta 3 (2 puntos)

A continuación se muestra un extracto del comportamiento dinámico del sistema

modelado por el D. Clases de la Fig. 1.
“... El controlador de anuncios recibe el evento cambiaAnuncio(), procedente de un
actor externo. Como respuesta, el controlador invoca la operación
modificaAnuncio() del objeto Anuncio-Modelo correspondiente.

La ejecución del método subyacente causa un cambio en el modelo que se debe

propagar a todos los controladores y vistas que actualmente están registradas en el
modelo (cuyas referencias se mantienen en el atributo Anuncio-
Modelo.conjuntoVistas). Para ello, el anuncio-modelo realiza dos acciones:
1.- invoca a su propio método notificar(), que a su vez provoca el envío de un
mensaje actualiza() al objeto anuncio-vista. Ese objeto responde a este mensaje
solicitando los datos al modelo para actualizarse.
2.- Además, el modelo envía también un mensaje de actualiza() al controlador de
anuncios, que a su vez pide (igual que hacía el objeto anuncio-vista) los datos que
necesita al modelo... “

PLAN 93: Dibujad el diagrama de secuencia que modela este escenario

:Anuncios-Controlador :Anuncios-Modelo :Anuncios-Vista

cambiaAnuncio()

modificaAnuncio()

notifica()

actualiza()
Actor1

muestraAnuncio()

getDatosAnuncio()
actualiza()

getDatosAnuncio()

PLAN 2001:
a) ¿Qué patrón está representando el modelo? ¿Qué ventajas presenta
respecto a otros tipos de patrones arquitecturales? ¿Qué inconvenientes?
(Puntuación 0.5 ptos.)

El patrón representado es el patrón Modelo-Vista-Controlador (de acuerdo con las

transparencias del caso de estudio dado en teoría) . Las ventajas de este patrón
son:
- Soporte para múltiples vistas: puesto que la vista se separa del modelo y no
hay ninguna dependencia directa entre vista y modelo, la interfaz de usuario
puede mostrar múltiples vistas de los mismos datos al mismo tiempo. Por
ejemplo, múltiples páginas en una aplicación Web pueden utilizar los
mismos elementos del modelo.
- Mayor soporte a los cambios: los requisitos de interfaz tienden a cambiar
más rápidamente que las reglas de negocio. Puesto que el modelo no
depende de las vistas, la adición de nuevos tipos de vista al sistema
generalmente no afectan al modelo. Por tanto, el ámbito del cambio se
limita a la vista.

Por otro lado sus principales inconvenientes son:

 - Complejidad. El patrón MVC introduce nuevos niveles de indirección y por
tanto incrementa ligeramente la complejidad de la solución. También
incrementa la naturaleza dirigida por eventos del código de la interfaz de
usuario, que puede por tanto ser más difícil de depurar.
- Coste de actualizaciones frecuentes: si el modelo sufre cambios frecuentes,
podría sobrecargar a las vistas con solicitudes de actualización. Algunas
vistas, como dispositivos gráficos, pueden tardar un tiempo en redibujarse.
Por tanto, la vista puede estar desactualizada. Esto se puede solucionar en
parte si el diseñador piensa en las vistas cuando codifica el modelo y, por
ejemplo, envía varias actualizaciones juntas en una sola notificación a la vista.

b) Dibujad un posible diagrama de componentes que incluya las

dependencias existentes entre dichos componentes.
(Puntuación 1.5 ptos.)

Nota: Suponed que existe una interfaz Observador que define el método
actualiza() y que puede implementar en caso de ser necesario cualquiera de los
componentes que defináis.

«archivo»
FicherosUI
Observador
«biblioteca»
ModeloAnuncios AccesoBD
«ejecutable»
Observador
ControladorUIAnuncios

Nota: En realidad tb existen dependencias entre (a) Vista y Controlador y entre (b)
Controlador y Vista, aunque en la interacción descrita en el ejemplo no se refleje.