Bit di uno sfondo: UML è la Universal Modeling Language. L'obiettivo per la versione 2.0 era quello di afferrare tutti i diversi standard di diagrammi / modelli esistenti nell'IT e di metarizzarli, mentre si cercava di aiutare l'analisi statica sui modelli. In questo modo avrebbero potuto creare la vera lingua francese dell'IT.
Ecco perché MOF ha circa 400 classificatori. L'unica cosa che puoi dire è OMG.
Uno di questi standard di modellazione introdotti era l'SDL delle telecomunicazioni. Ecco da dove provengono AcceptEventActions: fondamentalmente ci sono due universi paralleli, con un insieme parallelo di token, e AcceptEventActions sono i "sensori" che "percepiscono" questo universo parallelo e si attivano accettando un token da esso.
È come quando una telefonata arriva alla tua rete fissa: non è il tuo telefono ad avere l'evento, l'evento arriva dal mondo esterno.
Ora un classificatore è tutto ciò che ha un attributo classificatore, cioè una classe è qualcosa che costituisce un insieme: per ogni cosa nel mondo, puoi dire che appartiene alla classe, mentre l'altro no. È una cosa abbastanza ampia.
Pertanto, un classificatore non ha alcuna ricezione - potrebbe avere, potrebbe non avere, beh, chi ha qualcosa chiamato reception costituisce una classe.
In senso lato, un classificatore è un insieme di caratteristiche comuni che i membri (istanze) della classe condividono, o meglio, in cui sono interessanti. Cioè, se dico che un gatto è classificato per il colore degli occhi, l'età, la razza e il colore della pelliccia, ciò significa che mi aspetto che le istanze della classe del gatto siano diverse in queste proprietà, ma non mi aspetto qualcuno di loro ha allergia al latte: l'amore per il latte è comune al set, e finché non devo definire questa classe contro la classe dei cani, ad esempio, non ci interessa, e noi non modellalo.
Quello di cui potresti parlare è object node . Un nodo oggetto rappresenta un'istanza di una classe (non un classificatore, chi era quello che ha scritto quello ...), che esiste in un determinato momento. Si usa semplicemente per classificare il messaggio che viaggia tra due nodi, cioè ti dice che la funzione A ritorna con un oggetto di classe C, che sarà un input per la funzione B. Può anche essere, che entrambe queste funzioni abbiano un un'interfaccia molto più ristretta (ad esempio, A restituisce un oggetto con l'interfaccia I mentre B si aspetta qualcosa con l'interfaccia F, entrambi implementati da tutti i membri della classe C), è solo una nota che hey, avremo qualche volta un oggetto, che è un'istanza di classe C.
È fondamentalmente un'etichetta lucida. È come scrivere su un tubo: "acqua fredda": la lavatrice si aspetta acqua fredda, la torre dell'acqua fornisce acqua fredda, quindi la condizione è soddisfatta (beh, ad eccezione di alcune parti di Londra e dell'Inghilterra in generale, ma non entriamo che)
Ora questa etichetta, questa pipa è parte del sistema. Non viene dall'aria, deve essere definito in altre parti del sistema, in qualche modo, devi preoccupartene, devi crearlo da qualche parte, devi assicurarti che raggiunga tutti i destinatari previsti, ecc. .
Tuttavia, una telefonata arriva "dall'aria". Non ti importa di come è stato fatto, di come è stato creato, ti rendi conto solo che è una telefonata ed è lì. Questo è un evento. Viene dal mondo esterno.
Pertanto, non esiste un flusso di controllo in entrata di un AcceptEventAction (poiché è fondamentalmente un segno iniziale , ma esiste un flusso di controllo in uscita nel caso in cui i flussi di controllo siano modellati (attiva il sistema)
Immagino che questo sia semplicemente stupido:
(creditoimmagine:Gentleware / Poseidon . Riprodotto in fede di fair use)
Questo perché AcceptEventAction è un segnale iniziale . non ha alcuna ricezione di controllo dal sistema. Il controllo viene perso dopo la richiesta di pagamento, e viene riconquistato dopo la conferma, come sa chiunque abbia mai costruito un client gateway di pagamento o un client gateway SSO.
Suppongo che potrebbe avere un flusso di oggetti in entrata o un flusso di oggetti in uscita (ovvero un evento parametrizzato, come un id del chiamante).
Tuttavia, un nodo oggetto ha sempre un flusso di oggetti in entrata e un flusso di oggetti in uscita (dato che si trova all'interno del sistema, voglio dire, viene visualizzato un oggetto e quindi viene raccolto immediatamente garbage collection? Allora perché lo abbiamo creato), ma < em> nessun flusso di controllo (poiché è solo un'etichetta).