aspetta: ogni caso d'uso avrà il suo diagramma. poi, se l'utente interagisce col db tramite l'applicativo, sarà l'applicativo che lavora col db, non l'utente. ma di che tipo di diagramma stai parlando?
aspetta: ogni caso d'uso avrà il suo diagramma. poi, se l'utente interagisce col db tramite l'applicativo, sarà l'applicativo che lavora col db, non l'utente. ma di che tipo di diagramma stai parlando?
sto parlando dei diagrammi di casi d'uso. Ho un utente che interagisce direttamente con un sistema web, però agisce su dei dati/risultati che sono accessibili dall'applicazione web grazie a del lavoro svolto con un database e con un altro server e con in realtà un altro tipo di applicazione.Originariamente inviata da optime
e vorrei modellizzare con un diagramma di casi d'uso tutto cio.
cioè in pratica quello che succede è questo:
1) tramite una certa applicazione/tool dedicata all'integrazione dati, recupero dei dati da un server esterno e li integro inserendoli all'interno di un database.
2) l'utente accede dall'interfaccia dell'applicazione web e fa una serie di cose tramite i dati precedentemente integrati nel database a partire dal server esterno sopra citato.
io vorrei modellizzare tutto ciò in un diagramma di casi d'uso
Lo Use Case Diagram non è adatto alla rappresentazione che vuoi fare tu, perché ciò di cui stai parlando è un dettaglio architetturale e non ha nulla a che vedere con il caso d'uso.
Mi spiego meglio: se voglio creare un diagramma di casi d'uso per un bancomat, ciò che vedrò sarà il sistema, l'utente comune possessore del bancomat come attore, e le operazioni che si possono fare, tipo prelievo, deposito, visualizzazione conto, ricarica telefono, ecc.
Questi che ho indicato sono i casi d'uso. L'utente che si presenta al bancomat non ha come caso d'uso "l'interazione con il DB", che è un dettaglio architetturale: a lui interessa esclusivamente fare l'operazione per la quale si è presentato, poi come questa venga implementata ed espletata dal sistema con cui interagisce, sono "affari interni" che nulla hanno a che vedere con la fruizione della funzionalità, e pertanto vanno rappresentate - se lo si vuole fare - in altri diagrammi fatti apposta per questo, come un Sequence Diagram se vuoi dare l'idea di come è implementata nello specifico una determinata feature, oppure un Component Diagram se vuoi mostrare le parti del sistema che interagiscono (senza concentrarsi sul "come"), fino al Class Diagram se vuoi rappresentare la struttura delle classi che implementano tali parti.
Nel diagramma dei casi d'uso, roba come "accedere al DB" non va nemmeno citata, a meno che non stiamo parlando di un software dedicato a un utente che fa il Database Administrator, e allora ha senso nel contesto.
Ciao!
MARCO BREVEGLIERI
Software and Web Developer, Teacher and Consultant
Home | Blog | Delphi Podcast | Twitch | Altro...
Lo Use Case Diagram non è adatto alla rappresentazione che vuoi fare tu, perché ciò di cui stai parlando è un dettaglio architetturale e non ha nulla a che vedere con il caso d'uso.
Mi spiego meglio: se voglio creare un diagramma di casi d'uso per un bancomat, ciò che vedrò sarà il sistema, l'utente comune possessore del bancomat come attore, e le operazioni che si possono fare, tipo prelievo, deposito, visualizzazione conto, ricarica telefono, ecc.
Questi che ho indicato sono i casi d'uso. L'utente che si presenta al bancomat non ha come caso d'uso "l'interazione con il DB", che è un dettaglio architetturale: a lui interessa esclusivamente fare l'operazione per la quale si è presentato, poi come questa venga implementata ed espletata dal sistema con cui interagisce, sono "affari interni" che nulla hanno a che vedere con la fruizione della funzionalità, e pertanto vanno rappresentate - se lo si vuole fare - in altri diagrammi fatti apposta per questo, come un Sequence Diagram se vuoi dare l'idea di come è implementata nello specifico una determinata feature, oppure un Component Diagram se vuoi mostrare le parti del sistema che interagiscono (senza concentrarsi sul "come"), fino al Class Diagram se vuoi rappresentare la struttura delle classi che implementano tali parti.
Nel diagramma dei casi d'uso, roba come "accedere al DB" non va nemmeno citata, a meno che non stiamo parlando di un software dedicato a un utente che fa il Database Administrator, e allora ha senso nel contesto.
Ciao!
Un diagramma delle attività, che è tipo un flowchart?
tipo con un diagramma di attività non è possibile creare due sistemi a parte e poi magari connetterli per fare si che il secondo parta dal risultato del primo??? perchè io ho due macro sistemi praticamente(tutto il lavoro con database eserver come primo sistema ed il secondo quello relativo all'interazione utente-web application acquisendo i dati risultato del primo sistema)
Ultima modifica di Chiello9; 20-03-2021 a 14:40
E' difficile capire quello che devi fare e di conseguenza consigliarti; anche perché UML comprende diversi diagrammi https://it.wikipedia.org/wiki/Unified_Modeling_Language, ognuno concepito per rappresentare una specifica necessità (come ha spiegato benissimo alka), in base anche a chi deve leggere il diagramma.
Se spieghi bene cosa devi fare ti si aiuta
UML non è un linguaggio di programmazione, ma un linguaggio documentale, quindi all'interno rappresenti di fatto ciò che vuoi del tuo sistema, scegliendo il diagramma appropriato a seconda del tipo di visione che vuoi dare (le classi, le azioni, la comunicazione tra gli oggetti, i componenti finali del sistema, ecc.).
Non ci sono degli obblighi di realizzazione di determinati diagrammi: la scelta è libera a seconda di ciò su cui si vuole porre l'accento.
Come ti è già stato richiesto, spiega qual è lo scenario e quali sono le necessità, che non sono assolutamente chiare, e a quel punto vedremo qual è il diagramma - o i diagrammi - che ti possono aiutare, e come realizzarli.
Ciao!
MARCO BREVEGLIERI
Software and Web Developer, Teacher and Consultant
Home | Blog | Delphi Podcast | Twitch | Altro...
fase 1: viene interrogato un server tramite un tool di integrazione dati e si recuperano dei dati che poi si introducono in un database. (fase di lavoro iniziale).UML non è un linguaggio di programmazione, ma un linguaggio documentale, quindi all'interno rappresenti di fatto ciò che vuoi del tuo sistema, scegliendo il diagramma appropriato a seconda del tipo di visione che vuoi dare (le classi, le azioni, la comunicazione tra gli oggetti, i componenti finali del sistema, ecc.).
Non ci sono degli obblighi di realizzazione di determinati diagrammi: la scelta è libera a seconda di ciò su cui si vuole porre l'accento.
Come ti è già stato richiesto, spiega qual è lo scenario e quali sono le necessità, che non sono assolutamente chiare, e a quel punto vedremo qual è il diagramma - o i diagrammi - che ti possono aiutare, e come realizzarli.
@optime @alka ho risposto ad entrambi
Ciao!
fase 2: un utente accede all'interfaccia dell'applicazione web,quindi si logga, e poi fa una serie di operazioni che non sto ad elencare tramite questi dati.(tipo seleziona un area precisa, clicca un bottone, ecc..)
quindi:
ho un tool di integrazione ----> interroga un server per recuperare dati
dati acquisiti ---> inseriti nel database
Poi ho un utente generico che accede a questa interfaccia dell'applicazione e compie una serie di operazione tramite dei dati presenti nelle tabelle del database e visualizzabili dall'interfaccia:
prende questi dati nella tabella presenti nella web application e li trascina, poi clicca un bottone e fa altre cose
@optime ho risposto anche a te
Ultima modifica di Chiello9; 20-03-2021 a 16:20
Rispondi quotando
