Pongo numeros cual fueran burbujas...

Y CAMBIO notación en cuso. Alguien ya lo había dicho, pero queda esta notación:

Clase.metodo(param1,...)

(_NO_ Clase::Metodo)

Bueh, subo esta cosa.

Cambie atributos en AutorizacionController (defini tipos, y cambie uno para que sea escalar)

voy a hacer los comits de a uno...
Aca agregue metodos en AutorizacionDataService
1. actualizar(Autorizacion aut)
2. obtenerAutorizacionesPendientes():ArrayOfAutorizaciones

zaracatunga

Actualizacion completa del CUso Mantener Planes a arquitectura del sistema y con las correcciones del topo giggo

Estupideces de centrado y numeré métodos...

1. Decreto todos los metodos empezarán con minuscula  (eran más los que estaban así).

2. Tema de manejo de errores, lo comento en otro mail.
 (aca cambio valor de retorno en autorizaciones)

agregue un metodo a la clase de prestaciones

numere el cu

numeré el cuso y le agregue llamada al nuevo metodo del controlador

Varias cosas:
*) Modifiqué Recibir y Cotejar para acercarlo más a lo que le gusta a Garbarineta. (ACLARO: el diagrama de secuencia NO está actualizado)
*) Especifiqué la clase RecibirPrestacionesController
*) Subí un template del formato que usé para la especificación de la clase (taría bueno que todos lo usemos) --> Luca, si estás de acuerdo, forzá a que se cumpla éste formato, así nos quedan las cosas un poco más lindas y parejas

agregue un metodo de validacion del nomenclador

Se numeran CU y se arreglan "includes".

es la tercera vez que intento, cambié cosas. No quiero escribir más PUNTO :P
Agregué los métodos que Nico mencionó en la especificacion de su controlador en los diagramas de controlador y de persistencia y cosas mías bobas

string de vuelta

cambie a string una cosita

 * Agrego metodos del AfiliadoSolicitanteController
    Alguien que agregue al diagraam :
  - buscar
- get

O los nombres que mas le gusten

 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