Guillermo Rugilo [Thu, 26 May 2005 05:06:15 +0000 (05:06 +0000)]
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
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
Nicolás Dimov [Wed, 25 May 2005 03:55:04 +0000 (03:55 +0000)]
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
Sebastian Lavena [Mon, 16 May 2005 00:59:58 +0000 (00:59 +0000)]
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".
Guillermo Rugilo [Tue, 10 May 2005 23:54:32 +0000 (23:54 +0000)]
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)
Guillermo Rugilo [Tue, 10 May 2005 23:51:56 +0000 (23:51 +0000)]
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.
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).