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

arreglo palabras mal escritas y pongo un par de acentos

Se agrega relación entre Afiliado y Solicitante, porque el Solicitante podría
decir a la hora de pedir una solicitud que se quiere agregar al Plan familiar
del Afiliado titular X.

La modifique porque tenia un pequeño error y ademas para que quede mas parecido el formato a las que hice con mazzi

Renombre de archivo... me habia salteado la "u"

Se adjunta al pie un comentario de cada evento, explicando el CU y el actor que hace efectiva la transición de estados.

Versión inicial del diagrama de estados de una autorización manual.
La idea es que quien tenga dudas de como es la vida de una autorizacion manual, simplemente abra este diagrama.
Cada estado tiene asociado un comentario con las condiciones (una por renglón) para que se pueda decir que la autorización está en ese estado específico. No debería haber ambigüedad de estados.

especificación actualizada. Falta refinar los datos a pedirle a la Clínica, pero la base está. :)

No habiamos eliminado al solicitante

Se cambio nombre de atributo.

Si, sigo cambiando. Cada tanto me acuerdo de algo...

El tema de fecha de vencimientos: Ahora es 2 meses a partir de cuando se aprueba la autorización y no de cuando se emite.

Nombre mas copado de "Analizar Consumos y Prestaciones"

Faltaba el tema de grabar el prestador para donde se realizará la prestación.

1) Reordenacón de atributos de Autorización
2) Saqué los underscores de todos los nombres de atributos para unificar notación. Esto después nos va a facilitar la lectura de clases->tablas y el mapeo.

fecha de vencimiento estaba 2 veces...

Se rehizo. Quiero aclarar que todo lo que comitie hoy lo hizo mazzi.

Bueno teniamos un problema... En ningun lado se guardaba si se aprobaba o no la autorizacion!

Nuevo atributo:

Aprobada: bool

Solo tendrá sentido si fecha_resolucion != null

Se corrige detalle menor.

Se agrega 'Consultar solicitante'. Falta especificar

Cambie el nombre de 2 atributos:
Clase: Autorizaciones

FechaAprobacion por FechaResolucion
descripcion_rechazo por fundamentos_resolucion

Para que ambos atributos sirvan en caso de aprobación/rechazo y no en un solo caso.

* Hay que ponerle titular (que es un afiliado) al solicitante en caso de que
  quiera depender de uno. Representarlo en el diagrama de clases.
* Si el solicitente existe como inactivo y se quiere volver a afiliar, hace
  falta llamar a "consultar estado de cuenta"? o podemos verificar el atributo
  "Afiliado::moroso" directamente?
* Si un ex afiliado, conserva la antigüedad si quiere reafiliarse? (nosotros
  pensamos que no, que es un nuevo afiliado) Esto es por las PK en las tablas.

Saque lo de requisitos minimos (Leasé moroso, etc, etc.) Ahora siempre lo verá un auditor.

Se actualiza con lo hablado en la reunión del 24/04. También se pule bastante
para que deje de ser una mezcla entre DER y DC y empiece a ser un DC de verdad
=) El principal cambio es que se sacan atributos pertenecientes a relaciones.

Actualizado a la reunion dominguera del 24 de abril.

Modifiqué el CU dejando de lado las autorizaciones pendientes y agregué un archivito de decisiones tomadas

- Arregle las especificaciones de acuerdo a lo que me acordaba que dijo el ayudante
- Agregue la clase Hoja de Ruta y atributos al solicitante

Agregué perolata

Paso el diccionario de datos adentro del diagrama. Saque un par de atributos que estaban mal (en general de relaciones entre clases que estaban al revés). Igual falta MUCHO por hacer, puse muchas preguntas...

Bueno, aca esta el hermano del anterior... Este actualiza la autorizacion manual. En realidad es la nueva version del "Revisar autorizaciones manuales", al rtf anterior le di "delete", pero no estoy seguro si lo borro localmente o tambien en el servidor. Asi que si el otro todavia existe, no sirve mas, borrenlo al carajo.

Actualice el cuso agregando el diccionario de datos y le saque la parte de “criterios minimos de aceptación”. Antes funcionaba de manera que si un afiliado no tenia cobertura o era moroso se rechazaba automáticamente antes que lo vea un auditor. Por todo lo que hablamos hasta ahora, asumo que esa decisión le corresponde al grone con corbata.