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!!!!
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)
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...
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
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.
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).
Diego Marcet [Mon, 2 May 2005 14:24:31 +0000 (14:24 +0000)]
- 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
- 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.
**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 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"
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).
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.
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.
Sebastian Lavena [Thu, 28 Apr 2005 20:16:38 +0000 (20:16 +0000)]
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.
* 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)
- 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.
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
Sebastian Lavena [Tue, 26 Apr 2005 21:27:06 +0000 (21:27 +0000)]
Observaciones solo tiene sentido en Autorizacion Manual, se elimina del padre "Autorizacion". Para motivos de rechazo sigue estando fundamentosResolucion
projects / z.facultad / 75.10 / miklolife.git / log