fabiostyle
10-09-2012, 12:44
Riporto questo stralcio di esercizio
il cliente può richiedere assistenza on-line per l’apparecchio.Se la richiesta di assistenza perviene dopo oltre due anni dalla registrazione dell’apparecchio (ossia data richiesta assistenza - data registrazione >2 anni) la richiesta viene rifiutata, altrimenti la richiesta viene accettata e registrata,...
Allora, per far pervenire un dato Cliente può fare da 0 a n Richieste d'assist, Un Apparato può rientare da 1 a n Richieste, e n Clienti sono associati a n Apparati.
La richiesta come entità deve sempre esistere, indifferentemente se viene rifiutata o meno (almeno credo): bene o male bisogna comunque sapere se è stata rifiutata.
Ok, VENIAMO AL DUNQUE: da Richiesta io avevo pensato di generalizzare una Richiesta accettata e una rifiutata, però mi sono sorti dei problemi ai quali spero possiate rispondermi:
*quando creo la richiesta devo istanziare un oggetto Richiesta, in cui ci sarà la data di richiesta assistenza; solo dopo che ho inserito la data nell'oggetto posso sapere se è accettata o rifiutata 8proprio in base alla data di richiesta assistenza). Perciò, dopo, per specializzarla, mica posso distruggere l'oggetto Richiesta originario e creare uno nuovo RichiestaAccettata/RichiestaRifiutata? Mi sembra estremamente improduttivo... Oppure c'è un modo che non conosco per tramutare Richiesta in RichiestaAccettata in un modo elegante e soprattutto concettualmente corretto?
E sotto questi dubbi ho semplicemante fatto una associazione tra RichiestaAssist e l'entità nuova RichiestaAccettata, senza fare nessuna generalizzazione nè creare RichiestaRifiutata. Ma in questo caso sorge un ulteriore problema concettuale se non sbaglio: se voglio far comunicare una RichiestaAccettata con una Riparazione, per esempio, è come se non fosse associata direttamente alla Richiesta (ma indirettamente tramite RichiestaAccettata)
DELUCIDATEMI, PERCHE' STO ANDANDO IN PARANOIA PER STE COSE SERIE!!!
il cliente può richiedere assistenza on-line per l’apparecchio.Se la richiesta di assistenza perviene dopo oltre due anni dalla registrazione dell’apparecchio (ossia data richiesta assistenza - data registrazione >2 anni) la richiesta viene rifiutata, altrimenti la richiesta viene accettata e registrata,...
Allora, per far pervenire un dato Cliente può fare da 0 a n Richieste d'assist, Un Apparato può rientare da 1 a n Richieste, e n Clienti sono associati a n Apparati.
La richiesta come entità deve sempre esistere, indifferentemente se viene rifiutata o meno (almeno credo): bene o male bisogna comunque sapere se è stata rifiutata.
Ok, VENIAMO AL DUNQUE: da Richiesta io avevo pensato di generalizzare una Richiesta accettata e una rifiutata, però mi sono sorti dei problemi ai quali spero possiate rispondermi:
*quando creo la richiesta devo istanziare un oggetto Richiesta, in cui ci sarà la data di richiesta assistenza; solo dopo che ho inserito la data nell'oggetto posso sapere se è accettata o rifiutata 8proprio in base alla data di richiesta assistenza). Perciò, dopo, per specializzarla, mica posso distruggere l'oggetto Richiesta originario e creare uno nuovo RichiestaAccettata/RichiestaRifiutata? Mi sembra estremamente improduttivo... Oppure c'è un modo che non conosco per tramutare Richiesta in RichiestaAccettata in un modo elegante e soprattutto concettualmente corretto?
E sotto questi dubbi ho semplicemante fatto una associazione tra RichiestaAssist e l'entità nuova RichiestaAccettata, senza fare nessuna generalizzazione nè creare RichiestaRifiutata. Ma in questo caso sorge un ulteriore problema concettuale se non sbaglio: se voglio far comunicare una RichiestaAccettata con una Riparazione, per esempio, è come se non fosse associata direttamente alla Richiesta (ma indirettamente tramite RichiestaAccettata)
DELUCIDATEMI, PERCHE' STO ANDANDO IN PARANOIA PER STE COSE SERIE!!!