RECOMENDACIONES PARA EL EXÁMEN

Estimados alumnos,

El examen consiste en el desarrollo completo de un caso de uso (como en la AC). El

tiempo del examen no puede superar las 2 horas y resulta imposible simplificar el
escenario como para que resulte holgado. El planteamiento del ejercicio tiene un orden
secuencial pero, tal y como recomienda la asignatura, la elaboración implica constantes
revisiones y modificaciones de los pasos anteriores. El tiempo es escaso y las
preguntas tienen puntuaciones muy distintas, por lo que se recomienda:

1. Pida todas las hojas que vaya a necesitar (aproximadamente 8, una por pregunta)
y úselas, desde el principio, para hacer 'en sucio' cada pregunta en una (o más)
hoja.
2. Lea muy atentamente el enunciado. Piense que, el objetivo, es codificar el
programa.
3. Sólo va a trabajar en un caso de uso. Identifíquelo y determine los actores
principales (sólo los que interactúan directamente con el programa). Esboce con
ello el diagrama de casos de uso. Ya volverá a refinar el diagrama.
4. Piense en lo que tiene que hacer el programa. Escriba sólo los 4 ó 5 pasos mas
importantes en la escritura del caso de uso. Piense qué información necesita (el
programa) para ejecutar esos pasos e identifique algunos elementos que van a
contener esa información.
5. Esbozar las dos preguntas anteriores debe ocupar unos minutos. Lo importante es
el Modelo de Dominio (2 puntos). No se le ocurra hacerlo definitivamente ahora
porque, seguramente, se acabará el examen y no estará ni bien ni completo.
Empiece a hacer un borrador con los elementos identificados en el punto anterior.
Empiece ya a pensar qué van a hacer, para qué sirven y qué información van a
necesitar para hacer eso (atributos, vaya rellenando los objetos con ellos; con
cuidado, sin duplicidades). ¡Ojo con las relaciones! La mayoría de las relaciones del
Diagrama de Domino son de inclusión, composición, información... generalmente
estáticas. Las etiquetadas con verbos llevan a pensar en acciones, métodos o
responsabilidades que se asignarán más adelante a las clases. Se va a volver a
este borrador muchas veces.
6. Para el DSS del caso de uso, se recomienda hacer otro borrador. Represente el
actor que genera el evento de comienzo del CU. No ponga al otro lado al 'Sistema',
hágalo llegar a quién decida que va a ser el Controlador del evento (o el principal
del CU). Hágalo así con el resto de mensajes, hágalos llegar a la clase que decida
que va tener la responsabilidad de hacer el imperativo del mensaje (o porque tiene
la información necesaria). Seguramente necesitará volver al Modelo de Dominio y
cambiar cosas. Vale la pena pero hágalo rápidamente, sin mucha profundidad.
Esta pregunta vale poco y sólo es rentable para decidir qué contratos
desarrollamos en 5 y 6. Pero ¡ojo! se nota mucho si, en la elección, se utilizan
operaciones irrelevantes y de poca actividad. Deje la escritura de las operaciones
para cuando lo tenga más claro.
7. Las preguntas 5 y 6 son fundamentales. Cada pregunta, una operación de la
pregunta 4. Normalmente, la operación comienza con un evento (que proviene de
un actor) o un mensaje desde otra clase. Aquí se decide quién hace de controlador
(porque se le asigna esa responsabilidad y tiene -o puede obtener- los datos para
 ejecutarla). Hay que numerar, la secuencia de acciones. La acción de una flecha
entrante a una clase significa que, esa clase, tiene ese método (DCD) y maneja la
información necesaria para ejecutarlo (atributos que se anotan en el Modelo de
Dominio). De igual forma, si devuelve un valor, será información que maneja la
clase de origen (atributos que se anotan en el Modelo de Dominio). Nada puede
salir 'de la nada'. Ni valores, ni atributos, ni tipos (clases). Ninguna clase puede
manejar valores que no contenga (atributo, completar MdD) ni hacer cosas para
las que no tenga un método definido (construir el DCD). Seguramente haya que
corregir, también, el DSS de la pregunta 4. Vale la pena emplear la mayor parte
del tiempo en estas dos preguntas porque, al final, ya está casi todo hecho.
8. En este punto, creo que, lo más rentable, es pasar a 'limpio' las preguntas 3, 5 y
6. Después, el DSS de la 4 y escribir los contratos de las operaciones elegidas. A
continuación, las preguntas 1, 2, 7 y 8 (sin complicarse). Por último, las de 'Bonus
Points': 9 y 10.

Espero que sea útil para el examen. También he incluido unas recomendaciones para
algunos aspectos de los contenidos de la asignatura. Gracias y un saludo,

José Félix Estívariz

 RECOMENDACIONES DE LA ASIGNATURA

Estimados alumnos,

Habida cuenta de los trabajos calificados, en este curso, y de la experiencia en

los anteriores, creo conveniente llamar la atención sobre los siguientes aspectos:

1. El objetivo es el diseño, es decir, codificar un programa. Algo que parece

olvidado, pero que no se puede perder de vista. Todo lo que se haga, debe
ser codificable. El diagrama y la escritura de CU sirven para construir el
Modelo de Dominio y, éste, para definirqué debe hacer el programa, qué
elementos activos hay y qué información maneja cada uno. Los DSS y los
Diagramas de Colaboración sirven para establecer cómo actúa cada
elemento y, con todo ello, se construye el DCD que 'ya es casi codificable'.
2. Para empezar, el enfoque es sólo sobre un caso de uso. Se van a considerar
solamente los actores que interactúan con el caso de uso (externos al
programa y que producen alguna 'entrada' en él). Nótese que un 'camarero'
no puede hacer nada con un 'platoID', un identificador, un número. Pero sí
puede hacer una selección sobre un menú de descripciones o fotos (que,
internamente, están asociadas al identificador). Estas asociaciones no se
crean por 'arte de magia', son operaciones que hay que codificar.
3. El principio de Controlador establece que debe haber algún elemento que
reciba los 'eventos del sistema' (por ejemplo, órdenes de un actor) y los
procese o los reenvíe a otro objeto. Frecuentemente, este principio se
combina con el de Experto o Creador por el que, cada objeto, sólo puede
manejar la información que conoce (generalmente porque la contiene). De
eso depende que, el controlador, procese o reenvíe el evento. Ahora bien,
en el ejemplo del libro, sólo hay una caja, un Registro que procesan una
venta a la vez. Por ello, el Registro actúa como Controlador Singleton. Es
más frecuente que se estén realizando varias 'instancias' del mismo caso de
uso a la vez; en cuyo caso, se requiere un Controlador general que maneje
(por ejemplo, mediante un 'login') los controladores específicos (en ese
caso, 'de sesión').
4. Tampoco hay que confundir Controlador con Registro. Un Registro es un
elemento que recoge la información y las operaciones de las transacciones
(intercambio de información o servicios) para almacenar, analizar o
procesar posteriormente o en otro ámbito. En todos los ejemplos vistos
hasta ahora (libro, exámenes y PEC anteriores), se producen estas
transacciones y es necesario un Registro. En el libro, el Registro coincide
con el Controlador, pero podría no ser así. Como en otras ocasiones,
depende del principio de Experto: cada objeto maneja sólo la información
que conoce, lo cual nos lleva a
5. "Llevar la casa a cuestas produce un acoplamiento inaceptable"
Parece ser que, el mecanismo de mayor entropía para eludir el problema
del Experto, es que, cada clase, contenga a todas las otras que vaya a
manejar. ¡¡¡ E R R O R !!! No puede ser que Comanda contenga una lista
de instancias Plato y, cada plato, contenga la receta y la lista de Opciones
y, cada receta, la lista de Ingredientes, Tareas y Recursos de Cocina, etc.
En el libro, Registro sólo maneja los ID de los artículos. Si necesita saber el
 precio, consulta el catálogo y, éste, le lleva a EspecificacionDelProducto,
donde obtiene el precio. Igualmente, Comanda sólo maneja platoID. Si
necesita saber el precio, accede a Carta, que le lleva a EspecDelPlato, que
le da el precio. Cada información, en su sitio. El estudio de bases de datos
no es el ámbito de la asignatura y mejor es no meterse en esos 'jardines'
pero, sería equivalente a manejar sólo la clave de búsqueda, en lugar de
toda la tabla. Nótese la estructura de representación que se repite una y
otra vez: el catálogo es una lista Map en la que se emparejan el
identificador del objeto (clave) y la información, que se define como un tipo
(clase) aparte. Carta empareja platoID con EspecDelPlato (precio).
Libro_Recetas empareja platoID con Receta (recetaID). Inventario
empareja ingreID con EspecIgred (cantidad). Mapa_Cocina empareja
rec_C_ID con Espec_Rec (dutyTimeLine). Y, así, sucesivamente.
Recomendación: manejar sólo los ID de los objetos y, al organizar la
información que describe el objeto, no pensar en las BB de DD, sino en las
operaciones que van a usar sólo esa información. La estructura anterior
funciona muy bien.
6. La forma de hacer todo esto es, ordenadamente, pero con constantes idas y
venidas. Es la causa y la consecuencia de desarrollar 'orientado' a la
codificación. Ni la escritura del caso de uso puede hacerse completamente,
desde el principio, ni conviene desarrollar totalmente el Modelo de Dominio
antes de asignar las responsabilidades. El código obtenido siguiendo los
principios GRASP es 'normal', ni mejor ni peor que cualquier otro pero,
aunque dichos principios son 'de sentido común' parece (a tenor de los
resultados) extremadamente complicado obtener un diagrama de clases y
una porción de código 'razonables'. Para asentar los aprendizajes, se va a
incidir, sólo, en los 5 primeros principios GRASP. De cualquier forma, a la
hora de asignar métodos (responsabilidades) a las clases, es inadmisible
que aparezcan 'de la nada', que no sea una operación definida en esa clase
o que manejen parámetros referidos a información (atributos) desconocidos
para la clase. Todo se debe construir de manera que sea
codificable (fácilmente) en Java y, si se hace, compile sin errores y
funcione.

Espero que estas indicaciones sean de ayuda. Muchas gracias y un saludo,

José Félix Estívariz