ISI/DSS Junio 2005

Examen Resuelto Planes 93/2001

Normas a seguir:
Los apellidos, nombre y DNI se deben escribir en todas las hojas.
Se debe entregar cada pregunta en hojas separadas.
Debéis indicar si sois alumnos ERASMUS o si estáis en 5ª/6ª convocatoria.
No olvidéis entregar las preguntas en el montón correspondiente a vuestro plan
de estudios

PLAN 93 (sustituye al test): Pregunta 1 (3 puntos)

Responded BREVEMENTE a las siguientes cuestiones:
1) ¿Cuáles son los principales niveles de acoplamiento que se pueden
identificar en un diagrama de estructura? Define brevemente cada uno
de ellos.

Solución:

Acoplamiento normal: módulo A invoca a B, B realiza su función y

devuelve control a A. Todos los datos necesarios están presentes en
las interfaces.
Datos: Los parámetros son datos elementales
Estampado: Los parámetros son estructuras
Control: Algunos de los datos q se intercambian sirven para
controlar lógica interna del módulo destino.

Acoplamiento Común: Módulos acceden a datos comunes situados en

una misma zona global de datos.

Acoplamiento Por Contenido: Un módulo referencia el interior de otro

módulo (1) modificando o leyendo sus datos internos, (2) saltando al
interior de su código (sentencia GOTO) o (3) cambiando el código
interno del mismo

2) ¿Qué elementos pueden asociarse a una transición entre estados de un

diagrama de estados UML? Define brevemente cada uno de ellos

Solución:
a. Evento: Ocurrencia en el sistema que hace que se active la
transición. Pueden ser implícitos (e.g. finalización de una
actividad) o explícitos.
b. Condición Guarda: condición que debe cumplirse para que, ante la
ocurrencia del evento, se desate la transición
c. Acción: efectos colaterales de la transición

3) ¿De qué constructores consta un Diagrama de Secuencia? Describe

brevemente cada uno de ellos

Solución:

• Objetos: instancias de las clases del Diagrama de Clases

• Líneas de vida (lifelines): representan la existencia de un objeto a
lo largo del tiempo
• Mensajes: intercambiados entre objetos.
Pregunta 2 (3 puntos)

A partir del Diagrama de Flujo de Datos de la figura adjunta se pide:

Fig. 1: DFD correspondiente a una actualización de registros

a) Identifica el número de transacciones existentes

b) ¿Qué tipo de análisis aplicarás?
c) ¿Promueves o alquilas un jefe?
d) Realiza el Diagrama de estructura correspondiente
 R
O
R
R
_E
LE
AL
ET
D
L
VA
E_
U
_N
O
TR
G
R
A
D
LI
VA
E_
U
_N
C
E
R U
O _N
R
R C
_E
LE
AL
ET
D
R
O
R
ER
E_
A LL
ET
D
A
ID
AL
_V
NT
_A
C
T
N
_A
C
Pregunta 3 (2 puntos)

GestiónMatriculación

Fig. 2: Paquete GestiónMatriculación correspondiente a un sistema de gestión de una universidad

Dado el Paquete GestiónMatriculación de la Fig. 2 correspondiente a un sistema de

gestión de cursos de una universidad, definid en OCL las siguientes restricciones:

-- El número de matrículas en cada asignatura durante el año 2005 no debe

superar la capacidad total de los lugares donde se imparte la asignatura.

context Asignatura
inv:self.horario->select(anyo=2005).lugar.capacidad-
>sum()>=self.matricula-> select(getAnyoMatr()=2005)->size())

-- Para que un alumno pueda matricularse en una asignatura, ésta debe

pertenecer al curso que está cursando el alumno.

Context Alumno::matricular(asig:Asignatura,tipo:TipoMatricula): Boolean

pre: self.curso=asig.curso
pre: self.curso.asignatura->includes(asig)
-- Tras matricularse el alumno, si el resultado del método es verdadero, el
número de matrículas de la asignatura debe haberse incrementado en 1

context Alumno::matricular(asig:Asignatura,tipo:TipoMatricula): Boolean

post: result=true implies asig.matricula->size()=asig.matricula@pre->size()+1

-- Todos los alumnos matriculados en ISI se tienen que haber presentado al menos
a una convocatoria (junio, septiembre o diciembre) en cada matrícula que hayan
realizado (sea en el año que sea).

context Alumno
inv:self.matricula->select(asignatura.nombre='ISI')->
forAll(calificacionJ.isDefined() or calificacionS.isDefined() or
calificacionD.isDefined())

Pregunta 4 (2 puntos)

A continuación se muestra un extracto de la entrevista mantenida con el diseñador

del sistema gestor de la universidad, que nos describe cómo funciona el subsistema
de matriculación
“... El subsistema de matriculación está disponible para los alumnos desde
Internet. Los alumnos se identifican en nuestra página Web y proporcionan un ID
de alumno y una contraseña. Una vez que se les ha permitido el acceso, el sistema
les muestra el listado de asignaturas que tienen disponibles. Los alumnos pueden
seleccionar de una en una las asignaturas de las que desean matricularse, hasta
cubrir el número máximo de créditos (60) permitidos por curso. Además, el alumno
puede visualizar en cualquier momento la información detallada de cada asignatura
del listado. Al final del proceso, el alumno debe confirmar su matrícula, lo que
causa que todos los datos se hagan persistentes. Un alumno puede decidir cancelar
su proceso de matriculación en cualquier instante antes de dicha confirmación, en
cuyo caso no se guardarán los cambios en el sistema. “

PLAN 93: Dibujad el diagrama de actividad que modela esta descripción

funcional
 Alumno Sistema

Introducir login/passwd

[correcto=false] [correcto=true]
MostrarAsignaturas

[numCred<60]SeleccionarAsig VerInfoAsig AbandonarSistema

[numCred>=60]

ConfirmarMatricula

GuardarInfoBD

PLAN 2001: Suponed el siguiente diagrama de Casos de Uso para el sistema

completo de gestión de la universidad.

Fig. 2: D. Casos Uso Sistema Gestión Universidad

Además, sabemos que el sistema debe implementar una interfaz JDBC para el
acceso a los datos de la Universidad, y que también debe implementar servicios de
seguridad (interfaz de control de acceso) y de persistencia (interfaz persistencia).
Con estos datos, dibujad un posible diagrama de componentes que refleje en lo
posible vuestra propuesta de particionado de dominio y particionado arquitectural.

Solución
Las aplicaciones web tienen un número de usuarios grande o desconocido,
distintos usuarios con distintos requisitos de interfaz, una implementación
distribuida y configuraciones en cliente descontroladas o desconocidas. Esto implica
la elección de una arquitectura n-capa (mínimo 3) caracterizada por clientes
ligeros. Dicha arquitectura separa la interfaz de cliente (presentación de pantallas)
de la lógica que maneja el comportamiento de la interfaz. Las ventajas principales
de esta configuración son (1) aplicaciones cliente mucho más pequeñas, (2)
tiempos de descarga más pequeños y (3) mejor acceso a los servicios en las capas
inferiores.
En nuestro ejemplo la capa de seguridad y persistencia puede ser vista como
una capa de lógica de bajo nivel, pero aún separada de la gestión de datos, por lo
que la solución planteada será una cuatro capas. Un posible diagrama de
componentes que respete esta arquitectura cuatro capas y que ofrezca los servicios
e interfaces especificados sería:

Fig. 3: Solución diagrama de componentes Sistema Gestión Universidad