Consultar afiliado

Agregué coberturas y planes controller

Hice lo de prestaciones y actualicé el diagrama de persistencia y de los controladores, agregué la especificacion en el directorio Controllers

arquitectura y diseño de las pantallas de la aplicación

Que limitado que soy!

Dale que ya sale!!

- El tipo mete afiliados desde los papeles que le trae el moncho del promotor
- El CU devolver listado es una bosta y esta como el orto!!!!!!!!!!
- Al metodo AfiliadoSolicitanteController.guardarAfiliado le tuve que pasar el
  tipo y numero de documento del titular para que se haga la relacion.
- Muchas cosas mas que no me cierran
- Si sigo siendo el unico que hace algo (ademas de Luca) y encima esta todo
  mal, nos van a cojer de parados.
  Laburen putos

no se me ocurrio otra forma pero estoy dispuesto a cambiarlo si es necesario

arreglo afiliarcliente y agrego cosas para que vaya tomando la forma que decidimos, luca: corregilo

Arregle las especificaciones de Autorizaciones para respetar arquitectura, ahora se llama solo a clases controller desde cuso.

Agregue AutorizacionController en diag controller.
Cambie de lugar un metodo de autorizaciones que era muy groncho que este en el dominio, y lo pase a capa "Controller".

Paso diagramas a XML sin comprimir.

Diagrama de clases inicial de controladores.
- Sólo especifiqué la clase que necesité yo para el CU "Recibir y Cotejar"
- La idea es agregar todas las clases controladoras con sus métodos a medida que se vayan desarrollando los diagramas de secuencia.
- Éstas son las únicas clases que interactúan con la Presentación!!! (y por lo tanto, las únicas que pueden ser mencionadas en los CU)

Creación del paquete de clases controladoras.
- Especifiqué una posible organización de subpaquetes, modifíquenla si lo creen apropiado.
- A tocar por todos cada vez que se agregue una clase controladora, para poder tener una visión de más alto nivel de cómo va quedando la cosa.

actualizaciones para reflejar la toma de archivos de un FTP

Actualizado especificando que los datos que envía el Prestador se los levanta de un sitio FTP.

subo lo que mandé hoy por mail

Ajustes para que se impriman legibles
Odio el DIA de mier** y la rep*** madre a este programa hijo de una gran p**a.

Vuelvo pa atras porque ya lo habian subido y habian modificado mas cosas, perdon por el ruido.

Subo lo del flor.

ojo que lo mergee a mano con lo que agrego flor P y puede que se arme quilombo..

Flor Updates

ahora si, version 75.10 de lo que es un caso de uso

 me dicen por aca que estos dos no van mas...

Nuevo cuso.
Actor: Operador
Nombre: Armar cartilla

se agrega un item a las lista,.. . aver si se anotan

Mas cambios de Flor...

Voy en partes porque me saltaron un par de conflictos

Archivo que subio Flor...

Archivos que mando Flor

ahi puse todo lo que falta.. hay cosas que no tienen sentido (directorios y demas) pero cada uno sabe que se puede asignar y que no

lo borro porque esta como el orto.. asi no lo imprimimos al pedo

FlorC:
Arreglé pelotudeces y le di formato al archivo

FlorC:
agregarAfiliado:
llama a SolicitanteDataService.eliminar() y a AfiliadoDataService.agregar();

devolver_listado:
modificado según mail del ayudante

FlorC:
AfiliadoDataService : agregué obtenerTodos y agregar
SolicitanteDataService: casi lo mismo, ya no me acuerdo

No sé como manejarán ABM así que puse agregar(A), guardar (M) y eliminar (B)

mas clark updates...

Diagramas:
Agrego metodos que use en diagrama de secuencia para resolver las autorizaciones.

Cuso... Agregue un par de llamadas a metodos como quiere clark

Modelo 4 empezado (en estado vergunzoso, pero bué...)
- Metí frutilla a más no poder. De golpe me dí cuénta que no sé exactamente qué tiene que hacer Pagos al cruzar los dos informes... AYUDA SI ALGUIEN SABE!!!!

Agregado de métodos que fueron saliendo durante la creación del diagrama de secuencia de "Recibir y Cotejar"

Agregué una sobrecarga del método getEstado, para adecuarlo a mis necesidades

detalles estéticos

modificaciones mínimas de ajustes...

Agregué un paquete de reportes.
Decidí no meterlo adentro de la capa de dominio, porque son mas bien informes acerca de info extraída del dominio, pero no definen entidades de negocio.
Aparte, puede que a futuro los reportes varíen mucho, y no es deseable que eso forme parte del dominio.

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