Architettura pulita di Android - Usi separati, Caso monouso, o non un Usecase?

0

Sto lavorando al refactoring di un mio progetto precedente per seguire il paradigma di Clean Architecture (e amarlo fino ad ora) e uno dei miei componenti mi sta causando un po 'di confusione in relazione al fatto che debba esistere o meno come Usecase.

Esempio semplice Ad esempio, il requisito è che ci sia una schermata di informazioni di contatto, che visualizzi le risposte precedenti e dia agli utenti la possibilità di inviare aggiornamenti.

Ho due casi d'uso (1 utente invia informazioni di contatto, 1 visualizza informazioni di contatto).

O è solo 1 UseCase (Modifica le informazioni di contatto, con 2 funzioni per tornare precedente e anche inviare)?

Il mio esempio effettivo Grassetto è il caso d'uso di cui non sono sicuro se vuoi saltare a quello.

Lo schermo stesso è una griglia di 10 immagini che l'utente può selezionare per avere quell'immagine presente altrove nell'applicazione. Nove di queste immagini sono risorse nel progetto, una è un punto in cui un utente può caricare un'immagine propria e la selezione dell'utente è memorizzata in Preferenze condivise.

Use Cases:

  1. L'utente seleziona un'immagine

    Questo è sicuramente un caso d'uso e la logica di business che sta dietro sentimi perché L'utente sta compiendo un'azione nel livello vista e aggiornerò il mio livello dati (repository) con la loro selezione. Perfetto.

  2. L'utente carica la propria immagine- Anche questo è un caso d'uso. Utente carica la propria immagine e fa del lavoro per memorizzarla, oltre che selezionare è come la loro selezione. Quindi due pezzi di funzionalità in un solo utilizzo caso, che ha senso. Si adatta all'intero requisito. Perfetto

  3. Opzioni di visualizzazione per utente?     - Questo è quello che mi lancia per un giro. Quindi, quando l'utente naviga su questa schermata, ho bisogno di avviarlo visualizzando il 10 opzioni per l'utente da selezionare tra, oltre all'evidenziazione l'immagine selezionata in precedenza. Quindi è un caso d'uso separato per me dire Opzioni di visualizzazione o ottenere opzioni? Oppure, dal momento che 9 di queste immagini sono in risorse, questa è solo una parte della mia impostazione? Se è così, posso creare solo un caso d'uso per recuperare l'immagine caricata dell'utente?

So di avere alcune altre istanze come questa in cui è presente un set di set di dati iniziale.

La maggior parte delle volte proviene da un'API o dal database e fa parte di una regola aziendale più completa che ha senso come UseCase. Sono solo un po 'insicuro per casi come questo, dove forse sto leggendo da un file o caricando da alcune risorse esistenti.

Grazie per il consiglio!

    
posta Kyle 18.07.2018 - 19:41
fonte

1 risposta

2

Riguarda il caso d'uso o l'interfaccia utente?

Quello che chiami caso d'uso sembra essere la specifica dettagliata di un'interfaccia utente:

  • The screen itself is a grid of ...
  • User Selects an Image ...
  • User Uploads their own image ...

In altre parole, il tuo obiettivo è più su "come" che su "cosa". Quindi la prima domanda da porsi è ciò che vuoi documentare.

È l'interfaccia utente?

Potresti ovviamente usare casi d'uso (UC) per questo scopo. Ma potrebbero essere un overkill non ottimale: il collegamento tra le azioni descritte nell'UC e gli elementi dell'interfaccia utente non è chiaro; Inoltre, UC non intende documentare una sequenza ordinata di azioni con alternative.

Spontaneamente preferirei usare un paio di wireframes per esprimere queste cose in modo molto efficace.

Se l'interfaccia utente è complessa e richiede una serie di azioni, puoi prendere in considerazione i diagrammi delle attività piuttosto che casi d'uso.

O riguarda lo scopo del sistema?

I casi d'uso sono più efficaci nel descrivere lo scopo di un sistema, ad esempio per quali obiettivi l'utente interagirà con il sistema. L'attenzione dovrebbe essere sul quadro generale piuttosto che sui dettagli.

Ad esempio, capisco che l'obiettivo degli utenti dell'applicazione non è quello di gestire e caricare le immagini né di combattere con le griglie; l'obiettivo è gestire le risorse (caso d'uso principale). I casi d'uso potrebbero essere scomposti per indicare quali obiettivi secondari l'utente desidera raggiungere, ad es. cosa il sistema deve consentire all'utente di fare con le risorse. In genere potrebbero essere cose come mantenere un catalogo di risorse di risorse, descrivere risorse individuali, allocare risorse a progetti, ecc ...

Il modo in cui questi casi d'uso saranno raggiunti nel sistema dipende dal suo design. Ad esempio, si potrebbe immaginare un'applicazione a schermo singolo che consente di avviare tutti i casi d'uso. In alternativa, puoi anche definire un sistema transazionale, in cui ogni caso d'uso avrebbe la sua specifica interfaccia utente.

Letture aggiuntive

Ti consiglio vivamente il Use Case 2.0 ebook gratuito di Ivar Jacobson. Jacobson ha inventato l'approccio caso d'uso di UML. In questo ebook, chiarisce l'intento principale dei casi d'uso e come potrebbero essere utilizzati in un contesto agile moderno.

    
risposta data 19.07.2018 - 15:39
fonte