[Ingegneria del software] UML e casi d'uso
Ciao a tutti, sono di nuovo qui a chiedere il vostro aiuto 
questa volta per il progetto di ingegneria del software. MI trovo a dover modellare un'applicazione web di aste online ed ho un dilemma sui casi d'uso. In pratica nella mia applicazione ci sono gli oggetti messi in vendita ed ogni asta ha ovviamente una scadenza. Alla scadenza devono succedere delle cose: gli oggetti per i quali l'asta si è conclusa non devono più essere visualizzati e non deve più essere possibile fare offerte per loro, poi chiaramente alla conclusione dell'asta ci sarà un vincitore, ma il sistema prevede solo che alla scadenza dell’asta sulla pagina di descrizione dell’oggetto verrà visualizzato l’username dell’utente che ha fatto l’offerta maggiore e l’importo dell’offerta che ha vinto l’asta.
Più precisamente:
Gli utenti registrati possono accedere ad una propria pagina profilo che riporta i dati con i quali è avvenuta la registrazione; gli oggetti per i quali è stata effettuata una offerta (con indicazione dello stato: asta chiusa e oggetto aggiudicato, asta chiusa e oggetto non aggiudicato, asta in corso e offerta migliore, asta in corso e offerta superata) e gli oggetti posti in vendita (con indicazione dello stato: asta in corso, asta conclusa).
Alla conclusione di un’asta l’utente che ha offerto l’importo maggiore si aggiudica l’oggetto. Dopo la scadenza dell’asta, se c’è un vincitore, il sistema mostrerà nella pagina di descrizione dell’oggetto messo in vendita: il nome dell’utente che si è aggiudicato l’asta e l’importo con il quale si è aggiudicato l’oggetto. Non sono richiesti ulteriori sistemi di notifica. Una volta conclusa l’asta gli oggetti non appaiono più nella lista di quelli messi in vendita ma sono accessibili solo dalle pagine di profilo del venditore e dei partecipanti all’asta.
A questo punto la domanda è: secondo voi nella modellazione dei casi d'uso di questo sistema il TEMPO deve essere un attore?
Grazie
questa volta per il progetto di ingegneria del software. MI trovo a dover modellare un'applicazione web di aste online ed ho un dilemma sui casi d'uso. In pratica nella mia applicazione ci sono gli oggetti messi in vendita ed ogni asta ha ovviamente una scadenza. Alla scadenza devono succedere delle cose: gli oggetti per i quali l'asta si è conclusa non devono più essere visualizzati e non deve più essere possibile fare offerte per loro, poi chiaramente alla conclusione dell'asta ci sarà un vincitore, ma il sistema prevede solo che alla scadenza dell’asta sulla pagina di descrizione dell’oggetto verrà visualizzato l’username dell’utente che ha fatto l’offerta maggiore e l’importo dell’offerta che ha vinto l’asta.Più precisamente:
Gli utenti registrati possono accedere ad una propria pagina profilo che riporta i dati con i quali è avvenuta la registrazione; gli oggetti per i quali è stata effettuata una offerta (con indicazione dello stato: asta chiusa e oggetto aggiudicato, asta chiusa e oggetto non aggiudicato, asta in corso e offerta migliore, asta in corso e offerta superata) e gli oggetti posti in vendita (con indicazione dello stato: asta in corso, asta conclusa).
Alla conclusione di un’asta l’utente che ha offerto l’importo maggiore si aggiudica l’oggetto. Dopo la scadenza dell’asta, se c’è un vincitore, il sistema mostrerà nella pagina di descrizione dell’oggetto messo in vendita: il nome dell’utente che si è aggiudicato l’asta e l’importo con il quale si è aggiudicato l’oggetto. Non sono richiesti ulteriori sistemi di notifica. Una volta conclusa l’asta gli oggetti non appaiono più nella lista di quelli messi in vendita ma sono accessibili solo dalle pagine di profilo del venditore e dei partecipanti all’asta.
A questo punto la domanda è: secondo voi nella modellazione dei casi d'uso di questo sistema il TEMPO deve essere un attore?
Grazie
Risposte
Sinceramente non credo che il tempo abbia un qualche ruolo nella modellazione dei casi d'uso. Non è un utente e il sistema può essere implementato senza alcuna necessità di avere un qualche "evento" o processo che cambi lo stato della tua asta.
Nel mio libro c'è scritto che il tempo può anche essere un attore, faceva l'esempio del caso di un sistema in cui ci siano dei backup programmati. Cito:
Modellando dei sistemi ci si può rendere conto che ci sono certe funzionalità che non si attivano necessariamente perché un utente deve raggiungere uno scopo, ma sono attività che partono periodicamente e automaticamente (es. un backup di sistema automatico che parte ogni notte alla stessa ora), in questo caso si modella rendendo il TEMPO un attore a sua volta, esso può essere l’attore inizializzatore che fa partire quella certa attività. Spesso rappresentato con l’icona di un orologio.
Non riesco a capire se può essere il mio caso.
Modellando dei sistemi ci si può rendere conto che ci sono certe funzionalità che non si attivano necessariamente perché un utente deve raggiungere uno scopo, ma sono attività che partono periodicamente e automaticamente (es. un backup di sistema automatico che parte ogni notte alla stessa ora), in questo caso si modella rendendo il TEMPO un attore a sua volta, esso può essere l’attore inizializzatore che fa partire quella certa attività. Spesso rappresentato con l’icona di un orologio.
Non riesco a capire se può essere il mio caso.
Sono sinceramente abituato ad attribuire il ruolo di attore ad un qualche sottosistema che abbia il ruolo di eseguire periodicamente o automaticamente tale operazione piuttosto che al tempo. Ma sono scelte personali suppongo.
Come ho scritto alla fine del mio precedente commento non sono comunque convinto che sia questo il caso. Puoi certamente modellarlo in questo modo, ma non esistono sistemi di notifica che abbiano bisogno di avvenire in un particolare momento. Puoi insomma verificare che un'asta sia chiusa quando un utente chiede informazioni su di essa. Se per esempio hai una tabella con tutte le aste, è sufficiente confrontare la data di chiusura con quella corrente per sapere se un'asta è finita e per sapere chi ha vinto devi semplicemente trovare l'utente con l'offerta massima. Nulla ti vieta tuttavia di avere un sistema che ad intervalli regolari fa questa verifica e aggiorna il database in modo da facilitare l'accesso a tali operazioni (ed eventualmente implementare altre funzionalità di notifica in futuro).
Come ho scritto alla fine del mio precedente commento non sono comunque convinto che sia questo il caso. Puoi certamente modellarlo in questo modo, ma non esistono sistemi di notifica che abbiano bisogno di avvenire in un particolare momento. Puoi insomma verificare che un'asta sia chiusa quando un utente chiede informazioni su di essa. Se per esempio hai una tabella con tutte le aste, è sufficiente confrontare la data di chiusura con quella corrente per sapere se un'asta è finita e per sapere chi ha vinto devi semplicemente trovare l'utente con l'offerta massima. Nulla ti vieta tuttavia di avere un sistema che ad intervalli regolari fa questa verifica e aggiorna il database in modo da facilitare l'accesso a tali operazioni (ed eventualmente implementare altre funzionalità di notifica in futuro).
Effettivamente non posso dire che il tempo in questo caso "attivi" qualche procedura, semplicemente determina la scadenza di un'asta ma questo non fa partire procedure in automatico, a meno che non si possa considerare azione il fatto che lo stato di un oggetto cambi.
Grazie
Grazie
Avrei un'altra domanda. Non ho ben capito fino a che punto bisogna spingersi nel dettaglio coi casi d'uso.
Ad esempio, dovendo modellare questo scenario:
1. l'amministrazione può eliminare un oggetto in vendita
2. l'amministratore può aggiungere nuove categorie
3. l'amministratore può modificare il nome di una categoria esistente
4. l'amministratore può aggiungere sottocategorie
5. l'amministratore può eliminare domande e risposte
6. l'amministratore può eliminare le offerte
Sarebbe più giusto fare dei casi d'uso generici tipo "Gestire categorie" per la 2,3,4, un caso d'uso "Gestire domande e risposte" per la 5, e un caso d'uso "Gestione aste" per la 1 e la 6, oppure ognuna di quelle azioni va rappresentata con un caso d'uso a sé?
Grazie.
Ad esempio, dovendo modellare questo scenario:
1. l'amministrazione può eliminare un oggetto in vendita
2. l'amministratore può aggiungere nuove categorie
3. l'amministratore può modificare il nome di una categoria esistente
4. l'amministratore può aggiungere sottocategorie
5. l'amministratore può eliminare domande e risposte
6. l'amministratore può eliminare le offerte
Sarebbe più giusto fare dei casi d'uso generici tipo "Gestire categorie" per la 2,3,4, un caso d'uso "Gestire domande e risposte" per la 5, e un caso d'uso "Gestione aste" per la 1 e la 6, oppure ognuna di quelle azioni va rappresentata con un caso d'uso a sé?
Grazie.
Dipende da che cosa vuoi rappresentare o comunicare. Se ti è stato richiesto di rappresentare quei punti io cercherei di rappresentarli come usi a se stanti piuttosto che creare un insieme di categorie non particolarmente precise.
Non ho richieste specifiche a riguardo.
Io ho pensato di fare così:
- UC "Elimina domanda" che INCLUDE "Elimina risposta"
- UC "Gestisci categorie" che è una generalizzazione di "Aggiungere categoria" e "Rinominare categoria". Ho un dubbio per "aggiungere sotto-categoria", dev'essere a sua volta una specializzazione di "aggiungere categoria" oppure è anch'esso una specializzazione di "Gestisci categorie"? C'è da dire che una sotto-categoria può avere a sua volta sotto-categorie, non so come rappresentare questo fatto "iterativo" nei casi d'uso (e se va fatto). Ho visto che dei miei colleghi hanno fatto l'EXTEND del caso d'uso "aggiungi categoria" con se stesso, nominando l'extension point "aggiungi sotto-categoria". Ma per me non ha senso questa cosa, non mi risulta che si possano estendere casi d'uso con se stessi, o sbaglio?
- UC "Elimina offerta"
- UC "Elimina oggetto in vendita".
Che ne pensi?
Grazie!
Io ho pensato di fare così:
- UC "Elimina domanda" che INCLUDE "Elimina risposta"
- UC "Gestisci categorie" che è una generalizzazione di "Aggiungere categoria" e "Rinominare categoria". Ho un dubbio per "aggiungere sotto-categoria", dev'essere a sua volta una specializzazione di "aggiungere categoria" oppure è anch'esso una specializzazione di "Gestisci categorie"? C'è da dire che una sotto-categoria può avere a sua volta sotto-categorie, non so come rappresentare questo fatto "iterativo" nei casi d'uso (e se va fatto). Ho visto che dei miei colleghi hanno fatto l'EXTEND del caso d'uso "aggiungi categoria" con se stesso, nominando l'extension point "aggiungi sotto-categoria". Ma per me non ha senso questa cosa, non mi risulta che si possano estendere casi d'uso con se stessi, o sbaglio?
- UC "Elimina offerta"
- UC "Elimina oggetto in vendita".
Che ne pensi?
Grazie!
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo