Notifier

[ZanSara]

Ho visto che hai aggiunto un NOTIFIER come elemento del backend. Non e' piuttosto un elemento del frontend che dovrebbe quindi essere descritto nella sezione 2.2?

[siscia]

No, aspetta non è un elemento del backend, è un elemento del sistema. Che in effetti sarà condiviso tra il backend ed il frontend.

[ZanSara]

Hm. Ma allora che cos'e' il macroelemento UI di cui hai definito le funzionalita' nella 2.2? Pensavo fosse un modo per dire "frontend".

[siscia]

UI è per User Interface.

L'idea di come leggere è questa, sicuro che devo esprimerlo meglio.

Partiamo da quello che dobbiamo offrire all'utente e chiamiamo il tutto UI. Se ci fosse della magia il nostro lavoro sarebbe finito.

La magia non c'è e per offrire quelle cose UI/bar all'utente ci servono altri pezzi, Sy/foo.

Ora che abbiamo tutti i Sy/* li possiamo organizzare in componenti per strutturare la nostra applicazione, strutturandoli come è meglio. Single responsability principle e alto decoupling.

Ora abbiamo quindi questi componenti, che implementano delle funzionalità, ma è ancora "magia", per renderlo fattibile questi componenti vanno messi su dei computer.

Ecco che distribuiamo i vari componenti su tutta quello che può fare computazione in modo tale che abbia un senso.

Può succedere che un componente logico sia distribuito su più nodi fisici, come nel caso del componente "position" o del "notifier". In questi casi avremo un componente software diverso per ogni nodo. Ad esempio ci sarà il componennte software che manda le notifiche sul server ed il componente software che mostra le notifiche sulla app. Logicamente il componente è lo stesso e ha una sola funzione => notificare l'utente di qualcosa, praticamente però ci serve su due punti separati.

[ZanSara]

Ok ci sono. UI allora e' fuorviante secondo me, sembra che stiamo modellando la user interface vera e propria. Potremmo chiamarlo qualcosa come "System Boundary", "External Interface", qualcosa del genere.

[siscia]

Perchè tutta sta menata, perchè in questo modo alla fine abbiamo quello che ci serve, cioè un documento di design, ma, in più, abbiamo mostrato tutto il nostro processo di reasoning, abbiamo motivato le nostre scelte e abbiamo dato una struttura logica e coerente a quello che abbiamo fatto.

Vorrei evitare di dire, questi sono i componenti che ci servono e sono fatti così, perchè, non segue un processo logico ed è facilemente / giustamente attaccabile. Perchè ti serve quel componente? Sei sicuro? Puoi evitare di usarlo?

Le stesse domande possono essere fatte a noi, ma leggendo il doc dovrebbe essere chiaro il perchè delle nostre scelte. Poi uno può non essere d'accordo, ma almeno le scelte sono motivate e lineari. (Spero.)

[ZanSara]

Inoltre a questo punto, nel design dell'UX devo fare piu' attenzione a rispettare le funzioni che abbiamo definito nella 2.2... devo ricordarmi di rivedere anche questo. PS: io voto per System Boundary o anche solo Boundary.

[siscia]

Continuiamo su #39