Riferimenti architetturali
Non sarebbe meglio mettere il link PDF con 07 prima di quello con 08?
2.1
,è (manca lo spazio, prima riga)
'il formalismo (di) UML 2.5' (si può scrivere 'abbiamo deciso di utilizzare UML2.5 perchè ...')
3.1
estragga un testo corrisondente al suo contenuto.
3.2
l'avvenimento di un qualcosa ---> il verificarsi un evento
dell'avvenimento di un qualcosa ---> il verificarsi dell'evento (stesso).
la componente Recorder (che si occupa della registrazione audio), deve prima "aspet-
tare" che qualche individuo parli per potersi attivare, oppure deve "aspettare" che il riproduttore
audio abbia terminato la riproduzione prima di potersi rimettere in ascolto di un qualche individuo
che parli ---> toglierei la virgola dopo "audio)" oppure scrivere "[...]Recorder, che si occupa della registrazione audio, deve[...].
Inoltre cambierei da "[...]prima di potersi rimettere in ascolto di un qualche individuo che parli" a "[...]prima di potersi rimettere in ascolto"
(si capisce da prima che c'è qualcuno che parla).
"Il client vocale è composto da diverse componenti, le quali realizzano diverse funzionalità." credo non serva,
nel senso che è ovvio che le componenti abbiano funzionalità diverse. Piuttosto la unirei in una frase unica
con quella sotto con qualcosa del tipo "Il client vocale è composto dalle seguenti componenti:".
Ad ogni voce dell'elenco puntato toglierei "questa componente", perchè è già detto a inizio dell'elenco "Queste componenti".
3.2.2
Back-end::VirtualAssistant::VAResponse: (su ResponseBody bisogna segnare che alcuni campi sono opzionali?)
3.3.1
capibili per un'applicazione ---> (anzichè capibili metterei processabili o compresi), non PER ma DA
"Per ogni applicazione, si dovrà definire un agente." ---> forse toglierei la virgola (ma vedi te)
"consentendo lo sviluppo di diverse funzionalità da parte di sviluppatori diversi, e l'integrazione di eventuali funzionalità già esistenti senza dover modificare
direttamente gli agenti di api.ai." ---->
ripetizione di funzionalità, "affidando la realizzazione e l'integrazione di queste a diversi sviluppatori, senza[...]"
"gli agenti utilizzabili, in maniera tale che gli agenti utilizzabili" ---> ripetizione di "agenti utilizzabili" ---> in modo tale che vengano utilizzati solo
quelli definiti e registrati
dell'avvenuta ---> l'avvenuta
"il quale potrebbe essere utilizzato magari per fini di machine learning." ---> toglierei il magari (tanto stai già ipotizzando)
Di seguito vengono esposti i vari passaggi (di che cosa? io lo scriverei)
Come viene inviato il token?
Response
" contexts ":" ObjectArray " in Pragma è " contexts ":" ObjectAssocArray "
Sia per response che per request bisogna segnare i campi opzionali?
3.3.2
Il formato utilizzato da Slack è consultabile qui https://api.slack.com/docs/message-buttons. ---> se metti qui uno metterebbe il link sulla parola "qui".
Toglierei qui e metterei "[...]è consultabile al seguente link [link]"
Back-end::Notifications::NotificationChannel è diversa in PragmaDB
Back-end::Notifications::NotificationMsg non esiste in PragmaDB
3.3.3
Sulla risposta /auth/users con il metodo GET: dal disegno sembra ci siano sempre e solo due utenti. (Domanda mia: ma i metodi? il micorservizio non mi
ritorna oggetti e quindi anche i metodi?)
????
Method: DELETE;
Descrizione: viene eliminato un utente;
Method: GET;
Descrizione: vengono ricevuti i dati relativi ad un utente;
Response: la risposta deve contenere i campi organizzati come descritto in
Back-end::Auth::User:
????
Manca qualcosa in mezzo?
3.3.4
/impostazioni (stesso discorso per auth): con il get non ritornamimo oggetti? Quindi non ritorniamo anche i metodi?
/impostazioni/:id Method: DELETE mancano descrizione request e disegno
(In generale, in alcune immagini la tabulazione è diversa da altre)
(In generale, negli array mettiamo sempre due elementi, ma non è meglio mettere anche dei "..." per dire che ce ne possono essere quanti vogliamo?)
Riferimenti architetturali Non sarebbe meglio mettere il link PDF con 07 prima di quello con 08?
2.1
3.1
3.2
l'avvenimento di un qualcosa ---> il verificarsi un evento dell'avvenimento di un qualcosa ---> il verificarsi dell'evento (stesso).
la componente Recorder (che si occupa della registrazione audio), deve prima "aspet- tare" che qualche individuo parli per potersi attivare, oppure deve "aspettare" che il riproduttore audio abbia terminato la riproduzione prima di potersi rimettere in ascolto di un qualche individuo che parli ---> toglierei la virgola dopo "audio)" oppure scrivere "[...]Recorder, che si occupa della registrazione audio, deve[...]. Inoltre cambierei da "[...]prima di potersi rimettere in ascolto di un qualche individuo che parli" a "[...]prima di potersi rimettere in ascolto" (si capisce da prima che c'è qualcuno che parla).
"Il client vocale è composto da diverse componenti, le quali realizzano diverse funzionalità." credo non serva, nel senso che è ovvio che le componenti abbiano funzionalità diverse. Piuttosto la unirei in una frase unica con quella sotto con qualcosa del tipo "Il client vocale è composto dalle seguenti componenti:".
Ad ogni voce dell'elenco puntato toglierei "questa componente", perchè è già detto a inizio dell'elenco "Queste componenti".
3.2.2 Back-end::VirtualAssistant::VAResponse: (su ResponseBody bisogna segnare che alcuni campi sono opzionali?)
3.3.1 capibili per un'applicazione ---> (anzichè capibili metterei processabili o compresi), non PER ma DA
"Per ogni applicazione, si dovrà definire un agente." ---> forse toglierei la virgola (ma vedi te)
"consentendo lo sviluppo di diverse funzionalità da parte di sviluppatori diversi, e l'integrazione di eventuali funzionalità già esistenti senza dover modificare direttamente gli agenti di api.ai." ----> ripetizione di funzionalità, "affidando la realizzazione e l'integrazione di queste a diversi sviluppatori, senza[...]"
"gli agenti utilizzabili, in maniera tale che gli agenti utilizzabili" ---> ripetizione di "agenti utilizzabili" ---> in modo tale che vengano utilizzati solo quelli definiti e registrati
dell'avvenuta ---> l'avvenuta
"il quale potrebbe essere utilizzato magari per fini di machine learning." ---> toglierei il magari (tanto stai già ipotizzando)
Di seguito vengono esposti i vari passaggi (di che cosa? io lo scriverei)
Come viene inviato il token?
Response
" contexts ":" ObjectArray " in Pragma è " contexts ":" ObjectAssocArray "
Sia per response che per request bisogna segnare i campi opzionali?
3.3.2
Il formato utilizzato da Slack è consultabile qui https://api.slack.com/docs/message-buttons. ---> se metti qui uno metterebbe il link sulla parola "qui". Toglierei qui e metterei "[...]è consultabile al seguente link [link]"
Back-end::Notifications::NotificationChannel è diversa in PragmaDB
Back-end::Notifications::NotificationMsg non esiste in PragmaDB
3.3.3
Sulla risposta /auth/users con il metodo GET: dal disegno sembra ci siano sempre e solo due utenti. (Domanda mia: ma i metodi? il micorservizio non mi ritorna oggetti e quindi anche i metodi?)
???? Method: DELETE; Descrizione: viene eliminato un utente; Method: GET; Descrizione: vengono ricevuti i dati relativi ad un utente; Response: la risposta deve contenere i campi organizzati come descritto in Back-end::Auth::User: ???? Manca qualcosa in mezzo?
3.3.4
/impostazioni (stesso discorso per auth): con il get non ritornamimo oggetti? Quindi non ritorniamo anche i metodi?
/impostazioni/:id Method: DELETE mancano descrizione request e disegno
(In generale, in alcune immagini la tabulazione è diversa da altre) (In generale, negli array mettiamo sempre due elementi, ma non è meglio mettere anche dei "..." per dire che ce ne possono essere quanti vogliamo?)