Metodi "da duplicare"

[ZanSara]

Sto modellando lo sblocco dell'auto. Ne esce che:

• l'utente preme Sblocca
• la GUI chiede a Remote_Car_Manager: .unlock(user, car)
• RCM verifica la legalita' della richiesta e poi chiede a /[carID]/Local_Car_Manager: .unlock()

Vedi gia' il problema. Noi abbiamo definito un solo metodo .unlock(user, car), non il secondo .unlock()

In che punto del DD questa cosa va specificata? Forse nella sezione in cui crei Remote_Car_Manager e Local_Car_Manager?

[ZanSara]

Idem per la telemetria. I sequence diagram secondo me sono una piaga quando si tratta di modellare comunicazioni a messaggi, ma in questo caso specifico non mi e' chiaro se CAR/Telemetry e' un metodo del server o dell'auto.

[siscia]

No aspetta.

La gui chiede come hai detto bene te Remote_Car_Manager.unlock(user, car) a questo punto, se l'azione è legale, un messaggio di unlock è mandato via pub-sub alla macchina.

Motivo per cui il CAR_MANAGER è a metà tra la macchina ed il server.

Il tuo problema ora è, "si OK, ma che cazzo ci scrivo nel seq diagram tra il server e la macchina?" Giusto?

[siscia]

Io lo eviterei di scrivere qualsiasi cosa, essendo il car manager tra macchina e server, una volta che lo invochi o la macchina si apre perchè l'autenticazione è corretta o ti ritorna un errore che dice che non puoi sbloccare quella macchina.

[ZanSara]

Eh si' 😅 Il sequence e' praticamente fatto su misura per RPC. Non so come cavarmela con il PubSub.

[siscia]

Ma non lo modellare il pub-sub, te mandi il messaggio al CAR_MANAGER e fine.

Sbaglio?

[siscia]

Non modellare server e macchina, modella car_manager

[ZanSara]

Ok si, credo sia l'unico modo sensato di procedere :+1:

[siscia]

Mi sto perdendo qualcosa?

[ZanSara]

No no va bene... devo costringermi a restare sull'astratto con i sequence, tento continuamente di modellare i dettagli quando non devo (e non posso) farlo. Ora mi torna :)