UML Receptions e AcceptEventActions

2

Quale deve essere la relazione tra le ricezioni di una classe (era un classificatore prima della correzione di Aadaam) e le AcceptEventActions nell'attività che descrive il comportamento delle sue istanze?

Capisco che il primo è legato alla ricezione di segnali del tipo mentre il secondo è correlato agli eventi ReceiveSignalEvent di runtime delle istanze di classe (oggetti). Ma non mi è del tutto chiaro come esprimere la coerenza tra questi costrutti.

Sto definendo un insieme di trasformazioni M2M e M2T (mediante QVT e MOFM2T). Tuttavia indipendentemente da ciò che sto cercando di fare sono curioso di sapere qual è la sintassi corretta per tali modelli.

    
posta Silli 30.07.2012 - 09:22
fonte

1 risposta

2

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).

    
risposta data 31.07.2012 - 01:12
fonte

Leggi altre domande sui tag