Costó y bastante, pero los diagramas de secuencia de "Recibir y Cotejar" ya están más ó menos terminados.
1) Se agregó interacción con el operador
2) Se finalizaron las validaciones de la info entrante
3) Se agegaron métodos para generar/enviar reportes, que no especifiqué como se armaban (son todas consultas, no lo consideré relevante)

1) incorporación del operador para recibir la info del Prestador y cargarla en el Sistema
2) Inclusión de la validación del formato del archivo

version con las modificaciones que pidio Clark

Se saca la baja automatica al 3 mes de morosidad.

Cambie lo que "No me gustaba" (ver log anterior).

Ahora la consulta se resuelve a través de afiliado, asumiendo en él una coleccion de autorizaciones.

La relación entre "Autorizacion" y "Afiliado" es ahora de agregacion.

Asi cierra mejor.

Se arreglo el CUso.
La pregunta es. Si un afiliado inhabilitado quiere saldar su deuda, ¿que pasa?
Se me ocurre que tiene que hacer el tramite personalmente y se da de alta en el
momento. Esto quiere decir que actualizar morosos solo da de baja afiliados, no
puede dar alta (o mejor dicho reactivar) a ninguno.

Bueno...
Hice un diagrama de secuencia de "Pedir autorizacion automatica".
Aca defino muchos metodos, que en otro momento agregare a los diagramas correspondientes.

Mirenlo, critiquenlo, lo que sea...

Algo que no me gusto como quedo:
Necesitaba saber la cantidad de prestaciones que se hizo un afiliado con determinada prestación (Por el tema del limite anual). Y puse que se averigua con un metodo en autorizacionDataService. No me gusta porque se supone es de acceso a datos nada mas, pero tampoco encontre otra clase a quien asignarla. Quizas alguna "admin". QUe se yo, dejo eso abierto. Si se les ocurre algo mejor cambienlo, pero recuerden que las clases de dominio no ven las clases persistencia...

Aclaré que hay un tipito cargando la info enviada por el Prestador...
- Contra de ésto: IMPLICA OTRO CU!!!!

Cambios menores de aspecto

Decidí partir el diagrama de secuencia de éste CU en dos porque era muy largo
- Éste contiene toda la lógica de validación de los datos enviados por el Prestador

Hice cambios en base a los comentarios que hizo el ayudante en el mail que mando esta mañana...

Especifique un poco mas. Nada importante.

Cambie el nombre de la capa Aplicacion, por Controlador.

Asi queda mas claro que en esa capa, no tiene que haber mucha logica de negocio, solo lo necesario ya que es la unica que conoce al "dominio" y a la capa "persistencia" al mismo tiempo.

Modificaciones segun la correccio de Tomaskskwksy.
Cito una correccion que mando Daniel: "que quieren decir en el punto 2 ?
Aclarar". Para mi esta muy claro.

Se detallan un par de cosas. No son cambios muy importantes.

Bueno, aca el "Punta pié inicial".
Queda TODO por definir. Yo voy a definir algunas cosas... Pero la idea es que entre todos lo vayamos completando.
Aclaraciones relevantes:

1. Puse una sola clase AutorizacionDataService, porque no tienen mucha diferencia una manual de una automatica en cuanto a los datos, ni en cuanto a la funcionalidad que debe proveer hacia ellos. Sera lo suficientemente inteligente para saber que hacer en cada caso.

2. Con Persona hice exactamente al reves, cree un DataService por hijo. Pues quedaba horrible manejar todo lo referente al afiliado de Persona. Pero es una opinion...

Sientanse libre de toquetear, cambiar, explotar, implotar sarazarasa todo lo que quieran a su antojo (y lo mas importante, haganlo =D).

Se agrega opción para no incluir métodos (-n).

Se pasan los tipos a algo más DB friendly.

Extiendo el script para que ponga los métodos también.
Hago que la salida sea en HTML (más fácil de importar en un editor de texto).

Se pone que la carencia y permanenciaMinima es en meses, se borran comentarios
con preguntas y se completan/mejoran otros comentarios.

-Actualización de validaciones según el mail de Ricardo Rubén Daniel.

- Unidad de tiempo = meses

- Modifique Mantener planes de acuerdo a lo que hablamos en clase y al mail que mando Juan Daniel
- Agregue al diagrama de clases los metodos que invoco desde el cuso
- Corregi algun error ortografico en agregar afiliado

Paso diagrama a XML sin comprimir y lo pongo para que entre en una página.

Paso diagramas a XML sin comprimir y los pongo para que entren en una página.

- Se agrega en los comentarios las reglas de integridad referencial (explicado
  medio coloquialmente porque no recordaba los nombres) en el DER.
- Se agregan condiciones de nulidad de cada campo en los comentarios.
- Se agrega fechaBaja a Prestacion, Prestador y Categoria.
  Porque si no no se puede hacer bajas lógicas y bajas físicas es complicado
  porque hay que borrar las autorizaciones, cosa no del todo agradable.

- Se mejoró la especificación de datos
- Se revisaron las validaciones y corrigieron
- Se lo puso un poco más lindo

**AVISO**: éste diagrama está por la mitad. Lo subo para poder continuarlo mañana en la oficina y de paso ya hay un bosquejo de primer diagrama de secuencia.
-Puede servir para ver la notación (creo que está mas ó menos bien... pero uno nunca sabe).
-Armo una carpeta secuencia dentro de diagramas por si en el futuro son muchos.
-Acompaño el diagrama con un txt donde fui anotando las responsabilidades que tenía que asignarle a los objetos para lograr mi "cometido". Ayuda mucho para hacer el diagrama.

Agrego Solicitante.guardar(), Solicitante.borrar() y Afiliado.guardar().

Se hace que entre en una página.

Agrego una carpeta "arquitectura" para los modelos/documentacion acerca de la arquitectura del sistema.
Dentro va:
- Una idea de arquitectura general, basada en una arquitectura tipo capas, representada con paquetes lógicos
- La especificación del paquete lógico "Dominio"

Corrección de "NULL" a "NOT NULL" del atributo fechaResolucion para el estado Vencida
Es lo que corrigió la última vez el ayudante de éste diagrama

Llamada a metodos Afiliado.guardar() y a Solicitante.borrar()

Agregue llamado a metodo Solicitante.guardar()

estaba de más, y mal escrito

Agregue la descripción del solicitante...

Queda la de tiempo, se describe al actor tiempo? no tengo idea... de última va algun chamuyo de los de siempre y fue.

Agrego el directorio Documentacion para mandar ahi todo lo 'coloquial' que
tenga que ir en el informe. El m01 significa 'modelo 01'. Es para que quede
ordenado en el dir. Igual ya saben, cambien lo que quieran :)
Quedaron dos actores que no se como describir. Estos son el 'Solicitante de
Autorizacioes' (iak!) y 'Tiempo' (¿va? ¿no va? creo que si).

Separo diagrama de clases y de relaciones porque al agregar métodos se va a hacer incontrolable.

Se agrega a Afiliado y Solicitante existe() y getNext().

Se cambio el nombre FEO de 'Solicitador de Autorizaciones' por 'Solicitante de Autorizaciones'

Modificaciones menores.

Se corrigio este CUso.
Agregar los siguientes metodos en las siguientes clases.

int Afiliado.existe()
int Solicitante.existe()

La idea es que devuelva un true o false. En caso de true, los atributos se
completan con los datos encontrados. Si se encuentra mas de uno, se devuelve la
cantidad encontrada y se llena el objeto con los atributos del primero. Se
puede iterar con otro metodo que se llame getNext() o como quieran.

agregué devolverListado y cambié afiliarCliente por agregarAfiliado

Se agrega Cap.codigo como propuso Julian.

Se ponen + a los PK y - a los FK.

Cambio Prestacion.codigo a int como en el nomenclador.

Se agregan las claves primarias 'naturales' con un # adelante.

Saco Cobertura.id.

- Se pone la relación entre Autorizacion y Prestacion que faltaba.
- Se corrije Persona.idDireccion como FK.

Cambios en clases y der
- Se elimino Afiliado.activo ya que se puede chequear por fechaBaja == NULL
- Se puso fechaBaja en planes para poder realizar mantenimiento a largo plazo.
  Tambien ¿soluciona? problema de cambio de plan compulsivo
- Cobertura.tiempPermanencia se renombra a Cobertura.carencia.
- Se borra la relacion entre Autorizacion y Cobertura. Estaba por el porcentaje
  de Cobertura pero ahora lo almacenamos.

Bueno, para tener coherencia con la especificación que vamos a presentar hoy, tube que modificar el diagrama.

Verificar cobertura no lo incluye nadie (se hará con un metodo mas adelante en los cuso que corresponda).

A raiz de esto, quedaba colgado en el diagrama, asi que lo saque.
Cualquier cosa lo hablamos despues...

Tambien cambie la relacion de include en Actualizar autorizacion manual... porque consultar afiliado NO existe. Mas adelante vemos como resolvemos esto, pero ahora cierra un poco mejor asi.

Se incluye caso de uso atender consulta.

Se embebe el Telefono en Direccion y se pone la Direccion como una composición.

Elimino este CU que Guillermo incluyó en el CU de los consumos

 pequeño fix

 * actualizo con algunas consultas
   - Consultar Afiliad y se ajustan flechitas (mirar y consultar antes de tocar!!!!!!)
 - Consultar Planes (aca no me gusta como quedan los CUSO que se incluyen)
 - Consultar Promotores (por si alguien llama para verificar si quien esta en
 la puerta es realmente un promotor)

DER preliminar.

- Saco Autorizacion::tipo, para eso tenemos 2 clases distintas.
- Cambio Autorizacion::get_estado() por Autorizacion::getEstado().
- Saco agregación (o sea, se pasa a asociación común) a Prestador-Autorización,
  Cobertura-Autorización, Afiliado-Autorización y Cobertura-Prestación.
- Se cambia "Historia de planes" por HistoriaPlan (estaba mal, porque no
  representaba al conjunto de planes sino a las fechas de alta y baja de un
  plan, el historial de planes sería la colección que tiene el afiliado). Se
  corrijen las cardinalidades que también estaban mal.
- Se corrije cardinalidad de Plan-Afiliado que estaba mal.

Agregue comentarios respecto los atributos "fundamentosResolucion" y observaciones.

La clase "Automatica" Ahora es "AutorizacionAutomatica" para mantener coherencia con la nomenclatura.

Cambie comentarios de atributo fundamentosResolucion y obvesercaciones de Autorizacion y AutorizacionManual resp.

Se le saca el tipo binario para que se puedan hacer merges.

Se convierte a RTF porque se había subido con formato de Word.

Eliminé el CU "Generar Reporte de Consumo" e incluí su funcionalidad en "Recibir y Cotejar Consumos y Prestaciones".
Los motivos son varios:
1) Ningún otro CU lo incluía
2) No representaba un diálogo completo entre actor-sistema, sino que dependía de la finalización de un paso detallado en el CU "Recibir y cotejar..."
3) Molestaba y agregaba mugre en el diagrama de CU sin sentido

Eliminé el CU "Generar Reporte de Consumo" e incluí su funcionalidad en "Recibir y Cotejar Consumos y Prestaciones"

Agregué, en cada uno,una nota explicando cómo interpretar los diagramas

Se modificó un párrafo que decía incorrectamente el momento a partir del cual se establece la fecha de vencimiento de una Autorización.

de todo un poco
un cuso nuevo

en afiliar cliente cambie la precondicion por otra que calza mejor e incluye a la que estaba... en el otro no hice nada, lo hago mañana..

ooootra vez corregi la bosta del estado
ahora digo solamente que se obtiene el estado, no de donde lo saca ni como

- Agregue el campo activo a la clase Plan y actualice en base a eso el CU Mantener planes y el archivo de decisiones

Se completaron las descrpciones faltantes de los atributos de cada clase.

Observaciones solo tiene sentido en Autorizacion Manual, se elimina del padre "Autorizacion". Para motivos de rechazo sigue estando fundamentosResolucion

Se actualizaron las decisiones en cuanto a las Autorizaciones

Saqué un comentario que estaba de más

Actor nuevo: "Solicitador de autorizaciones"

Cambie el actor protagonico.

Saque el tema de observaciones. Para que dejar que alguien ponga motivos de la autorizacion si los va a aprobar una maquina y nadie lo va a leer?

Si fuera necesario poner motivos, deberia pedir una autorizacion manual.

Especifiqué las validaciones que se hacen sobre la info que envía el Prestador

Saco la transición entre "Pendiente" y "Vencida"... Sólo pueden vencer las autorizaciones aprobadas, porque la fecha de vencimiento se setea cuando se aprueba/rechaza una autorización.

adapte todo al diagrama de clases actualizado hace un rato, arregle algunas cosas y detalle otras

hice mas detalles, modifique como sacar el estado de la autorizacion utilizando el metodo de la clase, etc

Detalle en diccionario de datos... faltaba lo de prestador y prestacion

Cambie la fechaResolucion de lugar.
Ahora esta en Autorizacion Manual (hijo de autorizacion) y no esta mas en el padre. Pues en las autorizaciones automaticas esta fecha es identica a fechaSolicitud.

cambie el actor Tiempo por Tiempo (diariamente) al mejor estilo rivadulla

Diagrama de estados de una autorización automática. Al igual que con la manual, con éste diagrama la idea es que queden perfectamente claros los estados, transiciones y eventos que disparan las transiciones de una autorización manual.
También se colocan las notas que explican como se define cada estado a nivel clase.

Se aplican cambios mencionados en el RFC 1 =)
- Afiliado.nroAfiliado pasa a ser Afiliado.codigo
- Zona.codigo pasa a ser Zona.nombre
- Se borra Prestador.codigo
- Se borra Prestacion.codigo
(faltaría actualizar los CU para que usen los nuevos nombres)

- a pedido de Flor(C)

New! Éste CU existía en el diagrama pero aún no estaba especificado.

- Faltaba cambiar el nombre dentro del CU.
- Se pasó la especificación de datos del reporte de consumo al CU "Generar Reporte de Consumo"

actualizada con los campos segun el diagrama de clases vigente, detalle algunas cosas (mientras veo la profesia 3)

- Agregue la especificacion mantener planes
- Agregue tipo de atributo a clase plan
- Saque atributo precio del plan (asumo q igual q para las prestaciones, nosotros no tocamos costos de planes) y agregue categoría

- Elimine el caso de uso Consultar Solicitante porque estaba 2 veces