Buenas tardes:

Os adjunto los comentarios a la entrega opcional 2.

Cualquier duda que tengáis, mandad un mensaje al aula virtual y responderé lo antes
posible.

Tenéis 2 puntos en esta entrega.

Saludos,
Manolo

IMPORTANTE: HAY QUE SEGUIR EL ORDEN DE LA PLANTILLA SUBIDA AL AULA VIRTUAL PARA LOS
APARTADOS.
ESPECIALMENTE RELEVANTE ES ENTREGAR CADA CDU-DSS-CONTRATO-COLABORACIÓN SEGUIDO,
ADEMÁS HAY QUE SEGUIR EL ORDEN TEMPORAL DE PRECEDENCIA DE LOS CDU SEGÚN EL DIAGRAMA
DE ACTIVIDADES.

------------------
DIAGRAMA DE ACTIVIDADES
------------------

- No incluido.

------------------
IDENTIFICACIÓN CDU
------------------

- Mejorada la versión inicial.

------------------
DOMINIO
------------------

- Mejorada la versión inicial.

- Falta relevante: combate final con luchadores y ganador, y el premio.

------------------
ESPECIFICACIÓN COMPLEMENTARIA
------------------

- No incluida.

- Sobran RF que son cdu y ya están allí representados (quizá como pasos).
- Hay que incluir prioridad e identificador en cada requisito.
- Los RNF está mezclados con las reglas de negocio. Deben quitarse del apartado 3.2
y ponerlos en la descripción de los objetos.
- Faltan reglas de negocio.

- Requisitos funcionales: No incluido.

- Requisitos no funcionales y restricciones de diseño: No incluido.
- Reglas de negocio: No incluido.
- Glosario: No entregado. Hacer un glosario con todos los objetos que aparecen en
el modelo del dominio.

------------------
CONTRATOS-DSS-COLABORACIONES
------------------
Para todos los casos:
- Mirar transparencias “Como escribir CDU."
- Mirar los videos de ejercicios resueltos de colaboraciones.

Generales:

Plantillas cdu:
- En los CDU el sistema tiene que hacer algo para interactuar con el actor.

DSS:
- Todos los DSS empiezan con un actor.
- La segunda parte de un DSS siempre es igual y es SISTEMA como caja negra.
- No se pueden pasar colecciones como parámetros, por ejemplo: una colección de
clientes para los que comprar entrada.
- Los tipos de los parámetros son siempre básicos (int, string, etc). No se pueden
pasar colecciones ni objetos si no han sido creados previamente en otra operación.

Contratos:
- Las post-condiciones solamente son creación, modificación y eliminación de
objetos y asociaciones entre objetos.
- Hay que indicar qué objetos cambian su estado o el estado que tienen cuando se
crean y las asociaciones.
- Hay que indicar las asociaciones explícitamente entre qué objetos con su nombre,
ej c:Campeonato con j:Junta.
- Tenéis que repasad y visionar los vídeos de las prácticas de los ejercicios de
colaboraciones de Megasubasta y los ejercicios.
- Hay que revisar el diagrama del dominio para ver las asociaciones inicialmente
establecidas para cada objeto creado (puede que en el diagrama de clases haya
otras no identificadas inicialmente).

Colaboraciones:

- Revisad los controladores: no pueden estar sobrecargados ni ser poco cohesivos.

- Dos controladores no pueden hablar entre sí.
- No puede haber un único controlador genérico.

- Hay que inicializar los objetos, con atención a las colecciones vacías.
- La última opción para crear un objeto es que sea el controlador el que lo haga.
- Si un objeto se obtiene de un repositorio se debe haber incluido en el
repositorio correspondiente cuando se crea.

- Todos los objetos dentro de las colaboraciones tienen que tener un nombre, por
ejemplo "c:Campeonato", no se puede dejar ":Campeonato".
- Los repositorios sólo son accesibles desde el controlador. Los objetos del
dominio no pueden hacerlo.

- Hay que hacer el diagrama de clases del diseño a la vez para que aparezcan las
operaciones y los atributos.
- La navegabilidad se va estableciendo de manera incremental conforme se hacen las
colaboraciones.
- Los métodos del diagrama de clases se deben corresponder con los mensajes en las
colaboraciones.
- Los métodos "setEstado" son privados de cada clase, los mensajes que se envían
pueden ser del tipo "anular()", y luego la clase haría "setEstado('anulado')".

Notación:
- Los nombres de las clases y las líneas de vida van en MAYÚSCULAS.

Formato:
- La columna de la izquierda en las plantillas de los cdu hacedla más estrecha para
que haya más hueco para los pasos a la derecha y así ocupe todo menos.
- La columna de la izquierda en los contratos más estrecha para que haya más hueco
para los pasos a la derecha y así ocupe todo menos.

IMPORTANTE:
- LAS POST-CONDICIONES VAN EN PASADO.
- LAS ASOCIACIONES NO SON ASIGNACIONES DE ATRIBUTOS: EJ: luchador.armas = armas es
incorrecto.
- Las líneas de vida tienen todas ":", por ejemplo "e:Equipo", no "Equipo" ni "e
Equipo".
- Todos los objetos tienen nombre menos los repositorios y controladores accesibles
globalmente, pero tienen ":" también, ej: ":RepositorioXX"

Los casos de uso en los que hay que crear la plantilla para su descripción y luego
realizar el DSS, contratos y colaboraciones son los siguientes. Los otros casos de
uso se dejarán identificados con una descripción breve de un párrafo, pero no hará
falta extenderlos y describirlos en detalle en la práctica.

GENERAL:ESTÁN MEZCLADAS LAS PLANTILLAS DE LOS CDU CON LOS CONTRATOS. EN LOS
CONTRATOS NO HAY ESCENARIO PRINCIPAL.

cdu1- Se registra el equipo de artes marciales.

· Hay que hacer por separado las operaciones del equipo y de los luchadores.
· Hay que considerar que se puede meter el mínimo y máximo de armas posibles.
· Hay que considerar que se puede meter el mínimo y máximo de artes marciales
posibles.
· No se pueden pasar colecciones en el dss.
· Para indicar al sistema que el usuario ha acabado de introducir todo, hace falta
una operación "finalizar".

· Faltan post-condiciones según el cdu.

· No se asocia equipo a campeonato?
· Post-condicioens no cumplen las normas. Ej: "cada equipo debe conocer".
· Revisar trapas 81 para delegar desde el controlador.

cdu2- Se reservar un dojo para el entrenamiento.

· Inicialización de atributos de reserva: estado, fecha, precio.

· No estáis delegando, el flujo lo lleva el controlador.
· ¿Controlador es el creador?

cdu3- Se autoriza la reserva para el entrenamiento.

· La junta no es necesaria en la colaboración.

cdu4- Se seleccionan las katas a ejecutar.

· Post-condiciones vacías.
· ¿Y no se crean aquí las ejecuciones de kata?

cdu5- El asistente al concurso califica la ejecución de una kata.

· No se asocia con el asistente?

· ¿De dónde sale la ej:Ejecución?
· Falta actualizar la puntuación media.

cdu6- Se solicita un combate final.

· No estáis delegando, el flujo lo lleva el controlador.

· ¿Controlador es el creador?

cdu7- Se registra el resultado del combate final, asignando y repartiendo los

premios.

· Hay que repartir el premio según las reglas de negocio.

· No estáis delegando, el flujo lo lleva el controlador.
· ¿Controlador es el creador?

------------------
DIAGRAMA DE CLASES DEL DISEÑO
------------------

- No hay dependencias.
- Aquí no hay id como asociaciones. Ej ¿"Ejecución" tiene idEquipo1?
- Hay muchos objetos sin métodos, eso indica que no son responsbles de nada. No es
correcto.
- Recuerdo: Hay que incluir un diagrama separado con los controladores,
repositorios y dependencias.
- Faltan clases: armas, artes marciales.
- Sólo poned las clases qeu aparezcan en las colaboraciones. ¿Habéis usado
"Tribunal" en alguna colaboración?

------------------
DIAGRAMAS ESTADO
------------------

- No incluidos.